ИТ-проекты глазами заказчика: как выбирают поставщика и оценивают результат

Почему я смотрю на ИТ-проект с двух сторон

Эта статья выросла из трёх мыслей, которые я когда-то сформулировал для выступления перед ИТ-компаниями. Меня интересовало не то, как поставщик описывает свой delivery, а то, как тот же проект выглядит из кабинета заказчика.

За годы работы мне приходилось находиться в разных ролях: руководить проектным офисом крупного холдинга, участвовать в выборе ИТ-решений и подрядчиков, выстраивать взаимодействие бизнеса и технических команд, а позднее — самому отвечать за presale, scope и delivery ERP-проектов. Возможность видеть обе стороны изменила мой подход.

Большая часть конфликтов начинается не из-за недобросовестности участников. Поставщик оценивает объём настройки и разработки. Заказчик думает о непрерывности операций, сотрудниках, данных, внутренних согласованиях и собственной репутации перед руководством. Обе картины правильны, но каждая неполна.

Чтобы проект стал управляемым, стороны должны соединить три контура: коммерческий выбор поставщика, внутреннюю готовность заказчика и рабочую модель совместных решений.

Заказчик покупает изменение бизнеса, а не ИТ-систему

CRM, ERP, портал или аналитическая платформа появляются не ради набора функций. За проектом стоит бизнес-причина: управлять растущим объёмом операций, сократить ручную координацию, выполнить требования клиента, повысить прозрачность или заменить систему, которая ограничивает развитие.

Поставщик естественно говорит языком модулей, интеграций, миграции и релизов. Заказчик оценивает другое: заработает ли процесс, смогут ли сотрудники выполнять обязанности, не остановятся ли продажи или склад и сможет ли руководство доверять новым данным.

Поэтому функциональное соответствие — необходимое, но недостаточное условие. Решение может пройти технические тесты и не выдержать реальную операцию. Или, наоборот, часть второстепенных функций может быть отложена, но критический процесс начнёт работать и создаст ценность.

До обсуждения архитектуры я стараюсь зафиксировать изменение простыми словами: что компания делает сегодня, что должна делать после проекта, какие роли изменятся и по каким признакам руководство увидит результат. Эта рамка помогает оценивать и предложения поставщиков, и последующие компромиссы.

Как крупный заказчик принимает решение о поставщике

Со стороны ИТ-компании процесс выбора часто кажется конкурсом продукта и цены. В крупной организации решение почти всегда сложнее. На него влияют бизнес-заказчик, ИТ, безопасность, закупки, финансы, юристы и будущие пользователи. У каждого участника свои риски и собственное право остановить сделку.

Функциональная демонстрация отвечает только на вопрос, умеет ли продукт выполнять нужный сценарий. Она не доказывает, что поставщик способен провести проект в конкретной организации. Заказчик оценивает качество вопросов, зрелость подхода к scope, реалистичность плана, прозрачность допущений и готовность обсуждать неприятные ограничения.

Особенно важна конкретная команда. Известный бренд поставщика снижает часть рисков, но проект выполняют люди. Заказчику нужно понимать, кто будет вести discovery, принимать архитектурные решения, управлять планом и отвечать в критической ситуации. Сильный presale, после которого приходит неизвестная delivery-команда, разрушает доверие ещё до начала работ.

Цена также оценивается не изолированно. Низкая стоимость предложения может означать эффективный подход, а может — пропущенный объём, оптимистичные допущения или расчёт на будущие change requests. Зрелый заказчик сравнивает не только итоговую сумму, но и состав работ, обязанности сторон и полную стоимость получения результата.

• понимание бизнес-задачи и критического процесса;
• релевантный опыт конкретных специалистов;
• ясные границы scope и список допущений;
• реалистичный план и участие команды заказчика;
• архитектурная совместимость и требования безопасности;
• механизм изменений, эскалаций и выхода из проекта.

Что поставщик должен показать до подписания договора

Заказчику не нужна уверенность, что «всё возможно». Ему нужна уверенность, что поставщик умеет отличать известное от неизвестного и не скрывает неопределённость внутри коммерческого предложения.

Хороший поставщик показывает, какие процессы уже понятны, какие требуют discovery, какие интеграции зависят от третьих сторон и какие решения должен принять сам заказчик. Он объясняет не только целевую архитектуру, но и путь перехода: миграцию данных, тестирование, обучение, запуск и поддержку.

Я настороженно отношусь к предложениям, в которых подробно оценена разработка, но почти отсутствуют работы бизнеса. Обычно это означает, что подготовка справочников, очистка данных, описание правил, тестирование и организационные изменения молча переданы заказчику без оценки их влияния на общий срок.

Другой важный признак — способность поставщика говорить «нет» или предлагать этапность. Если команда обещает одновременно реализовать все пожелания к фиксированной дате и бюджету, не задавая вопросов о приоритетах, это не клиентоориентированность. Это будущая проблема управления ожиданиями.

Главная недооценённая работа находится на стороне заказчика

В плане ИТ-проекта хорошо видны настройка системы, разработка, интеграции и техническое тестирование. Гораздо хуже виден объём работы, которую должна выполнить сама компания. Именно этот контур часто определяет реальную дату запуска.

Нужно описать и согласовать целевые процессы, назначить владельцев решений, подготовить справочники, очистить исторические данные, определить правила доступа, проверить документы, выделить пользователей для тестирования, изменить инструкции и обучить сотрудников. Ни одна из этих задач не выполняется автоматически после покупки системы.

У внутренних экспертов при этом остаётся основная работа. Для поставщика интервью или тестирование — запланированная задача. Для руководителя склада, бухгалтера или менеджера продаж — дополнительная нагрузка поверх операционной деятельности. Если проектный план учитывает только часы подрядчика, он описывает меньше половины системы исполнения.

Поэтому я включаю работы заказчика в общий план: с владельцами, сроками, зависимостями и подтверждённой загрузкой. Если справочник продукции должен быть очищен до миграции, это не «ожидание клиента», а полноценная задача критического пути.

Данные — не техническое приложение к проекту

В старой системе могут существовать дубли контрагентов, свободные названия товаров, неполные адреса, устаревшие статусы и логика, которую понимает только один сотрудник. Перенос таких данных не исправляет проблему — он делает её частью новой системы.

Поставщик может предложить шаблон, правила преобразования и инструменты загрузки. Но только бизнес способен решить, какая запись верна, какие данные нужно сохранить и что означает каждый атрибут. Эта ответственность не исчезает при передаче миграции подрядчику.

Работу с данными следует начинать на discovery, а не перед go-live. Сначала определяется минимальный набор для запуска и владельцы доменов. Затем проводится пробная выгрузка, профилирование качества, очистка и тестовая миграция. Пользователи проверяют не количество загруженных строк, а способность выполнить на этих данных сквозной сценарий.

Отдельно нужно определить, что не переносится. Исторические данные можно оставить в архиве или перенести агрегированно, если это не нарушает требования бизнеса и законодательства. Попытка перенести всё часто увеличивает стоимость и риск без сопоставимой ценности.

• какие данные необходимы для первого рабочего дня;
• кто владеет качеством каждого справочника;
• какие правила очистки и сопоставления применяются;
• как бизнес проверяет тестовую миграцию;
• где и сколько хранится неперенесённая история.

Бизнес-процессы нельзя отложить до обучения

Фраза «система стандартная, пользователи разберутся» обычно скрывает отсутствие решений. Даже типовой продукт требует определить роли, последовательность действий, исключения и точки контроля. Если этого не сделать до настройки, спор о процессе переместится в приёмочное тестирование.

Автоматизация быстро обнаруживает различия между формальным регламентом и реальной работой. Один филиал создаёт заказ до подтверждения оплаты, другой — после. Один менеджер может менять цену самостоятельно, другому нужно согласование. Пока эти варианты живут в таблицах и переписке, компания может не замечать противоречия. Система заставляет сделать выбор.

Поставщик способен фасилитировать обсуждение и показать практику продукта, но решение о целевом процессе принимает владелец бизнеса. Если такого владельца нет, техническая команда начнёт принимать организационные решения по умолчанию, а затем отвечать за недовольство пользователей.

Обучение должно объяснять не только кнопки, но и новый способ работы: кто выполняет действие, зачем оно нужно следующей роли, какой документ или статус создаётся и что делать при исключении. Только тогда система становится операционной моделью, а не новым интерфейсом поверх старых привычек.

Как разделить ответственность заказчика и поставщика

Формула «поставщик отвечает за систему, заказчик — за бизнес» слишком общая. На практике каждая сторона трактует её в свою пользу. Ответственность нужно разложить по конкретным результатам и решениям.

Поставщик отвечает за качество архитектуры, настройки и разработки, технический план, прозрачный прогноз и своевременную эскалацию. Заказчик — за бизнес-приоритеты, доступность экспертов, качество исходных данных, решения по процессам и принятие результата. Совместными остаются требования, миграция, тестирование, обучение и запуск.

Для каждого совместного результата полезно назначить двух владельцев: delivery owner со стороны поставщика и business owner со стороны заказчика. Это не размывает ответственность, если заранее определено, кто готовит, кто проверяет и кто принимает решение.

Отдельно фиксируются сроки решений заказчика. Если выбор модели учёта блокирует настройку, у решения должна быть дата и понятный путь эскалации. Иначе задержка сначала выглядит незначительной, а через месяц превращается в спор о виновной стороне.

Методы взаимодействия, которые используются реже, чем следует

Статус-встречи и протоколы необходимы, но сами по себе не создают сотрудничество. В сложных проектах полезны механизмы, которые делают различия в понимании видимыми раньше.

Первый механизм — совместный discovery workshop по сквозному процессу. Не отдельные интервью функций, а сессия, где продажи, операции, финансы и ИТ проходят один реальный сценарий от начала до конца. На стыках обычно обнаруживаются главные противоречия.

Второй — playback: поставщик своими словами показывает, как он понял процесс, требования и ограничения. Заказчик исправляет картину до начала дорогой разработки. Документ на десятки страниц редко создаёт такое же общее понимание.

Третий — журнал решений. В него входят не все обсуждения, а значимые выборы: принятое решение, варианты, причина, владелец и последствия. Через несколько месяцев он помогает понять, почему система устроена именно так, и не возвращаться к закрытому спору.

Четвёртый — демонстрация на данных и сценариях заказчика как можно раньше. Типовая презентация продукта показывает возможности. Рабочий сценарий обнаруживает разрыв между возможностью и реальным процессом.

Пятый — pre-mortem перед критическим этапом. Команда представляет, что запуск провалился, и называет вероятные причины. Этот простой приём позволяет обсудить риски, которые участники не решаются поднимать в обычном статусе.

• совместный разбор сквозного процесса;
• playback понимания поставщика;
• журнал управленческих решений;
• ранние демонстрации на реальных сценариях;
• pre-mortem перед миграцией или запуском;
• единый список вопросов и владельцев решений.

Почему прозрачность важнее постоянного оптимизма

Заказчик способен принять плохую новость. Гораздо тяжелее принять её слишком поздно, когда вариантов уже не осталось. Поэтому доверие строится не на зелёных индикаторах, а на качестве прогноза.

Если срок или scope под угрозой, поставщик должен показать причину, последствия и варианты: сократить первый релиз, добавить ресурс, изменить последовательность или перенести дату. Заказчик, в свою очередь, должен быстро принять решение и не наказывать команду за своевременно выявленный риск.

Проблема без владельца и запроса на решение остаётся информацией. Хорошая эскалация указывает, что произойдёт при бездействии, кто обладает полномочиями и до какого момента выбор ещё сохраняется.

Такая модель требует зрелости обеих сторон. Поставщик не скрывает сложность ради коммерческого спокойствия. Заказчик не перекладывает внутренние задержки на подрядчика. Вместо переговоров о виноватых участники управляют общей системой обязательств.

Что заказчик должен увидеть в результате проекта

Техническая готовность остаётся обязательной, но итоговая оценка должна вернуться к исходной бизнес-причине. Работает ли критический процесс? Пользуются ли системой целевые роли? Достоверны ли данные? Перешла ли поддержка в устойчивый режим? Получены ли операционные эффекты, ради которых утвердили инвестицию?

Часть ответов появляется при go-live, часть — только после периода стабилизации. Поэтому полезно разделять приёмку продукта, закрытие проекта и benefits review. Команда может завершить delivery, а владелец процесса продолжит отвечать за adoption и эффект.

Я считаю успешным взаимодействие, после которого у заказчика остаётся не только работающая система. У компании должны появиться понятный процесс, внутренние владельцы, знания и способность развивать решение без постоянной зависимости от людей, участвовавших в первом запуске.

ИТ-компании важно понимать эту перспективу ещё на этапе продажи. Крупный заказчик выбирает партнёра не только по тому, что тот обещает построить. Он оценивает, поможет ли команда пройти неизбежные решения и оставить бизнес в более управляемом состоянии.

Три вывода для обеих сторон

Первый: выбор поставщика — это оценка команды и модели delivery, а не только продукта, бренда и цены. Сильное предложение показывает границы, неопределённость и обязанности заказчика.

Второй: данные, процессы и участие внутренних экспертов являются полноценной частью проекта. Их нужно оценивать, планировать и контролировать так же, как разработку и интеграции.

Третий: отношения с заказчиком строятся через совместные решения и раннюю проверку понимания. Демонстрации, playback, журнал решений и прозрачные эскалации снижают риск лучше, чем длинные отчёты после возникновения проблемы.

Когда эти принципы соблюдаются, граница между «заказчиком» и «исполнителем» не исчезает — договорные роли остаются. Но появляется общая управленческая модель, в которой обе стороны отвечают за свою часть единого результата.

• выбирать конкретную команду и способ работы;
• включать работы бизнеса в общий план;
• начинать подготовку данных на discovery;
• назначать владельцев процессов и решений;
• проверять понимание на реальных сценариях;
• оценивать успех по изменению бизнеса, а не факту установки системы.