Привлечение вендора к реализации проекта: увеличение расходов или сокращение издержек?

• 
  Умирханов Владимир
• 30 июля 2024
• Статьи

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

На данном этапе перед Заказчиком встаёт следующий выбор:

1. Направить специалистов своего IT-отдела к вендору на обучение внедрению платформы для последующего внедрения своими силами.
2. Нанять на проект компанию-интегратора.
3. Заключить договор на внедрение с вендором, условия которого позволяют привлекать подрядные организации (компании-интеграторов) по согласованию с Заказчиком.

Рассмотрим плюсы и минусы каждого из представленных вариантов

Проведение внедрения собственными силами:

Плюсы:

• Формирование и развитие внутренней экспертизы по Системе в результате проекта.
• Возможность технического сопровождения Системы на первой линии своими силами.
• Все проектные решения можно выработать, согласовать и реализовать, не выходя за рамки компании Заказчика (если это не сложные проектные решения и не вопрос не менее сложных интеграций).
• Доступность проектной команды к пользователям Системы. Внутри своей компании проще выстроить продуктивное взаимодействие между проектной командой и конечными пользователями программного продукта, так как все находятся в едином фоне и доступе.

Минусы:

• Увеличенные сроки внедрения. Для формирования компетенций в области внедрения и настройки выбранного решения необходимо пройти обучение по внедрению, настройке и программированию на базе выбранного решения, которые предоставляет вендор. Формирование компетенций у технических специалистов Заказчика посредством прохождения такого обучения всё равно занимает время, за которое силами интегратора можно было бы настроить уже некоторую часть бизнес-процессов. Также знания, полученные во время прохождения обучения, необходимо закреплять живыми кейсами внедрения, формировать опыт, набивать «шишки» и решать такие ситуации. Навыки любого из выбранных интеграторов по внедрению и настройке системы будут значительно выше, чем у технических специалистов Заказчика, прошедших обучение.
• Выход за рамки первоначального бюджета/сроков проекта. Минус, связанный со сроками увеличения проекта, также влечёт за собой неминуемое увеличение затрат на него. При увеличении времени решения задачи (во время проекта) также и растёт стоимость такой работы. Менее опытная команда делает всё значительно дольше, но также команда может и меняться во время проекта – необходимо обучать дополнительных сотрудников и учитывать такие накладные расходы.
• Организация привлечения экспертной команды вендора к решению сложных вопросов, возникших во время внедрения, требует дополнительного времени для понимания командой вендора сути решаемой задачи, что, в свою очередь, повлечёт за собой непрогнозируемые затраты.
• Привлечение заведомо менее опытной команды (команда Заказчика не имеет опыта внедрения выбранной Системы).

Поручение проекта компании-интегратору:

Плюсы:

• За процесс внедрения отвечает привлечённая компания, выполняющая работы на договорной основе, с прописанными сроками и качеством работ – имеются юридические основания требовать результат в установленные сроки и объёмы (в отличие от внутренней команды).
• Сокращение сроков и снижение стоимости внедрения.
• Привлечение полноценной проектной команды со всеми необходимыми в ней специалистами нужной квалификации. Оптимальное управление проектом.
• Команда интегратора имеет больший опыт во внедрении выбранной Системы, чем команда Заказчика.
• Возможность выбрать исполнителя «под свою команду». Заказчик может подобрать команду для выполнения работ, опираясь не только на профессиональные навыки команды (сколько внедрений производили, их сложность и пр.), но также и по «софт-скилам», чтобы было комфортнее выстраивать рабочие взаимоотношения.

Минусы:

• Возможность ошибиться с выбором интегратора.
• Сроки и качество результата сильно зависят от качества коммуникации между Заказчиком и Интегратором для одинакового понимания целей автоматизации и задач пользователей.
• Риск утраты технической поддержки Системы в дальнейшем. Компания-интегратор может сменить направление своей деятельности и перестать заниматься проектами выбранного вендора в дальнейшем, также компания может перестать существовать – эти и иные факторы порождают риск вынужденной смены исполнителя работ и поиска новой компании-интегратора или перехода на поддержку команды вендора.

Работа по договору с вендором в формате генподрядных работ:

Плюсы:

• Экспертиза. Вендор определённо точно знает, как решить задачи, возникающие в вашей компании при работе Системы. Вендор знает, как делать не надо, и может объяснить это Заказчику, отстоять решение.
• Поддержка и развитие. Изменение мира, а тем более IT-сферы, происходит слишком быстро. Нужно понимать, что как только установили Систему — она начинает устаревать. И роль вендора — продолжать отношения с Заказчиком, чтобы компания понимала, что её с этой системой ждёт дальше и как она будет развиваться.
• Работа на перспективу. Команда вендора – это стабильный ресурс, который не утрачивает внутри знаний о продукте, а только развивает и наращивает их со временем. Данный тезис применим не только к знаниям о Платформе, но также к проектной работе, к которой команда активно привлекалась. Это позволяет не только сохранить компетенции в проектном решении и тех задачах и проблемах, с которыми сталкивались при реализации проекта, но и организовать активное вовлечение прошлой команды интегратора или новой при развитии решения, ведь потребности требования Заказчика тоже не стоят на месте – придёт такой момент, когда потребуется расширение функциональных возможностей системы у заказчика (или корректировка текущих процессов).
• Планы развития продукта. У вендора всегда имеется план по развитию продукта, который будет лучше соответствовать целям компании Заказчика, которые они ставят перед данной системой.
• Вендор гораздо лучше знает своих партнёров (компании-интеграторов), их опыт и навыки. Более точно подберёт команду под нужды проекта.
• При работе в связке «вендор-интегратор» у команд налажен более тесный контакт, и все сложные вопросы по проекту решаются значительно быстрее как в технической части, так и в организационной.
• Более тщательная процедура сдачи-приёмки работ. Основным Заказчиком у интегратора в таком случае выступает вендор – результаты по проекту сдаются сперва вендору, а после прохождения такой «сдачи-приёмки работ» представляются Заказчику. Вендор более скрупулёзно подходит к качеству результатов работ своего партнёра, что позволяет добиться наилучшего качества.
• Управление проектом осуществляется на нескольких уровнях (внутри команды интегратора, а также со стороны вендора).
• Подготовка полного пакета документации по продукту. У вендора больше примеров и «готовых» описаний модулей и функциональных возможностей. По итогу проведения адаптации имеющихся материалов под нужды проекта совместно с компанией-интегратором будет сформирован полный пакет документации.

Минусы:

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

Мы рассмотрели варианты реализации проекта внедрения Системы, их плюсы и минусы. Но успех проекта также зависит от команды. Давайте рассмотрим роли в проекте: заказчика, вендора, интегратора.

Глобальные роли в проекте

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

Команда заказчика:

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

Заказчик должен понимать, что он является полноценным участником команды, а его роль сводится не только к тому, чтобы «гонять исполнителя» за сроки и результаты, но и формированию чёткого, однозначного представления о результатах проекта на этапе проектирования/аналитики, своевременного согласования документации, выдачи необходимых доступов/материалов, ответу на все вопросы исполнителя. Оперативность в решении вопросов на стороне Заказчика, а также его максимальная заинтересованность в результатах проекта поможет реализовать проект в установленные сроки и с должным результатом.

Команда вендора:

Документооборот в компании – один из самых важных процессов на текущий момент. Если говорить про внедрение СЭД, то в данном случае роль вендора в проекте очень важна. Участие вендора в проекте интеграции СЭД позволит не только внедрить выбранную систему быстрее и качественнее, но также и совместно с Заказчиком проработать планы её развития с учётом потребности компании Заказчика, а также планами развития выбранной платформы. Вендор помогает выработать такой курс и методологию внедрения, которая позволит использовать максимально внутренние ресурсы и возможности платформы, минимизировать стороннюю разработку.

Команда интегратора:

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

Вывод:

В данной статье были рассмотрены все возможные сценарии внедрения ECM/BPM-платформ. Оптимальным вариантом внедрения системы корпоративного уровня является формат привлечения вендора к реализации проекта как генерального подрядчика. Именно в таких взаимоотношениях между Заказчиком, вендором и командой-интегратором удастся достичь лучшего результата от процесса внедрения, а также результата внедрённой Системы.

Стоит также отметить, что вендора можно привлекать и в формате осуществления «Авторского надзора» над реализацией проекта силами привлечённых подрядчиков. Про данный подход рассказал в своей статье Виктор Сущев, директор по консалтингу «ДоксВижн». 

Умирханов Владимир

Руководитель проектов