Авторский надзор от вендора в проектах внедрения ИТ-систем для бизнеса

Разговор касается систем, которые представляют собой не готовую коробку «установил и используй», а предполагают довольно сложный процесс создания уникального заказного решения на базе предметно-ориентированной платформы, базовых элементов и типовых решений. Таких продуктов довольно много среди систем класса ERP, СЭД, CRM и т.д. В этом случае вклад внедрения в конечную ценность для потребителя не меньше ценности самого базового продукта, который лежит в основе. А значит, внедрение требует такого же должного внимания, как и подбор ИТ-продукта.

Варианты организации внедрения и авторский надзор вендора

Какие же варианты есть у бизнеса, чтобы реализовать внедрение ИТ-системы? Наиболее популярны такие:

1. Внедрение силами ИТ-службы заказчика. Плюс в том, что заказчик полностью управляет ресурсами и не зависит от внешних исполнителей. Но сложность в том, что необходимо сформировать и содержать компетентную проектную команду по предметной области и выбранному базовому продукту. Если заказчик стратегически ориентирован на инсорсинг, то лучше реализовать такой подход постепенно: заказать первоначальное внедрение компетентному внешнему исполнителю, в ходе проекта взрастить свою команду, которая будет в дальнейшем сопровождать и развивать решение, привлекая внешних исполнителей только в момент, когда временно необходимо увеличить ресурсы или для особо сложных задач.
2. Внедрение вендором. Плюс в том, что вендор обладает наивысшими компетенциями по базовому продукту и достаточно высокими — в предметной области. Минус в том, что в этом случае заказчик привязан к единственному поставщику не только базового продукта, но и услуг по внедрению. А стоимость услуг вендора, как правило, достаточно высока.
3. Внедрение интегратором (партнером вендора). Плюсы в том, что интегратор, как правило, находится территориально ближе к заказчику, зачастую уже имеет опыт работы с ним, знает его специфику, может оказывать сопутствующие услуги. Сертифицированный партнер имеет достаточно высокую компетенцию по базовому продукту, подтвержденную вендором. При этом заказчик не привязан к одному поставщику услуг, он может выбирать лучшего по соотношению качество/цена среди разных интеграторов-партнеров того же вендора. Пожалуй, это оптимальный вариант. Он уступает только вендору в части компетенций по базовому продукту.

Казалось бы — выбирай и действуй! Но свобода выбора заказчика бывает ограничена политикой вендоров относительно внедрений своего продукта, и это является частью их осознанно выбранной бизнес-модели. Одни вендоры внедряют исключительно или преимущественно сами, другие — исключительно или преимущественно силами партнеров. Но в каждом конкретном случае заказчик выбирает тип исполнителя: вендор или партнер. А нельзя ли в конкретном внедрении совместить эти варианты, взяв от каждого лучшее?

Положительным ответом на этот вопрос является вариант внедрения силами партнера-интегратора с авторским надзором от вендора.

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

1. Наивысшую компетенцию по платформе, глубокое знание ее механизмов.
2. Инновационный задел за счет раннего знания о новинках и даже планируемых возможностях.
3. Кратчайший путь от проблемы, возникшей у заказчика, до группы разработки платформы, которая может ее решить.
4. Обобщенный опыт множества внедрений, выполнявшихся другими партнерами.
5. И, наконец, это наивысшая ответственность за платформу/продукт.

Все это снижает риски и повышает качество проекта, служит дополнительной гарантией его успеха.

Цель и содержание авторского надзора вендора

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

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

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

Вендор предоставляет консультации, заключения и рекомендации по запросам в тикет-системе или непосредственно участвуя в совещаниях по функционально-техническим вопросам проекта.

Оптимальность использования возможностей платформы в проекте рассматривается вендором с различных точек зрения:

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

Важные нюансы авторского надзора вендора

Хочется выделить несколько моментов, которыми нельзя пренебрегать, рассматривая вариант авторского надзора вендора в проекте:

• важно подключать вендора к проекту с самого начала, еще на этапе разработки технического задания на внедрение. Иначе, например, можно столкнуться с тем, что в плане работ не будут предусмотрены документы, необходимые для согласования проектных решений перед началом их реализации. Тогда ревью придется проводить уже по факту реализации, и при наличии замечаний не исключен вариант возврата на этап проектирования, со срывом сроков, перерасходом ресурсов и прочими негативными последствиями;
• надо учитывать, что при осуществлении авторского надзора на исполнителя ложится дополнительная работа по оформлению проектных решений и других рабочих продуктов, чтобы их мог рассматривать сторонний эксперт, но это все работает на обеспечение качества проекта, и без этого авторский надзор теряет смысл;
• конечным результатом по каждому рабочему продукту является согласование его вендором. Но не следует выдавать продукт (например, документ «Технический проект») на рассмотрение вендора, только когда документ будет полностью готов. Это будет задерживать ход проекта на срок согласования «с нуля» и срок исправления, если будут замечания. Рекомендуется организовать работу таким образом, чтобы получать консультации и заключения вендора по проектным решениям в рабочем порядке, по мере их выработки. Тогда согласование итогового документа или другого рабочего продукта не вызовет значительных задержек.

Когда рекомендуется использовать авторский надзор вендора

Всегда ли имеет смысл использовать авторский надзор вендора в проектах внедрения? Это все-таки некоторое удорожание проекта (хотя и не больше, чем если бы проект выполнялся самим вендором). Большинство внедрений, выполняемых сертифицированными партнерами, проходят успешно и без этого. По нашему опыту, использование в проекте опции «авторский надзор вендора» оправдано при сочетании следующий условий:

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

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

Автор: Виктор Сущев.