Как управлять проектом цифровизации и не поругаться с заказчиком. 3 совета из практики «ТерраЛинк»
08.11.2024
Любой трансформационный проект в крупном бизнесе – будь то цифровизация процессов, внедрение бизнес-систем высокой сложности и масштаба, импортозамещение ИТ-ландшафта – это уравнение с большим количеством неизвестных и переменных. «ТерраЛинк» реализует такие проекты уже 30 лет, но ошибки случаются всегда, т.к. постоянно развиваются используемые решения, меняются технологии, усложняются запросы наших заказчиков и внешний контекст. Делимся с вами сокровенным: 3 совета, как делать сложные проекты цифровизации в связке «заказчик и цифровой партнер». За каждый из них мы заплатили временем команды, нервами на решение конфликтов и большими ресурсами на трансформацию внутренних процессов. Теперь у вас есть возможность этого избежать или минимизировать эту боль.
1. Договоритесь о проектной методологии
Есть три типа ведения проектов цифровизации, которые требуют разных видов менеджмента. Заказчику и интегратору важно договориться «на берегу» о том, по какой методологии будет идти проект, чтобы сформировать команды с соответствующим набором компетенций и иметь общее видение о целях и ходе проекта.
Первый – Waterfall. Перед тем, как внедрять систему, мы првоодим аналитику, детально описываем бизнес-процессы клиента, выбираем технологию и затем реализуем решение на ее основе. Эта методология построена на прозрачности и полном доверии участников команды.
Второй – фирменный подход SAP Activate. Он подразумевает то, что у нас уже есть готовое, полностью сформированное решение, и мы его внедряем. После того, когда оно поставлено и запущено, мы анализируем его и выявляем расхождения с реальной картинкой процессов. Все участники проекта хорошо знают, как система работает.
Третий подход – это Agile. Большую задачу разделяем на маленькие команды, которые в полностью открытом и согласованном порядке разрабатывают и запускают систему маленькими «порциями». Мы не заставляем пользователей сразу жить по-новому, а улучшаем систему по чуть-чуть, пока эти улучшения не станут чем-то бОльшим. В этой методологии ответственность за каждое решение за себя берут конкретные сотрудники и несут ее до тех пор, пока не будет достигнут результат.
2. Договоритесь о том, что такое пилот
Компании, привыкшие к разной методологии, могут понимать под «пилотом» совершенно различные типы проектов. В российской практике под этим часто понимается внедрение решения на определенный объем компаний, после которого не может быть ничего другого, кроме тиражирования. Альтернативный вариант, в котором пилот признается неудачным или требует масштабных доработок, крайне нежелателен, т.к. это связано с огромными репутационными потерями внутри компании.
А, например, в проектной методологии SAP Activate под пилотом подразумевается совершенно иное: внедрение решение «as is», на которое затем внимательно смотрят, ищут «гэпы» (несооответствия) между спецификой бизнес-процессов системы и внутренних процессов компании, исправляют их, улучшают, модифицируют решение.
Несмотря на кажущуюся простоту понятия «пилот», разница в терминологии нас подвела в одном из больших проектов по цифровизации документооборота.
Формат пилота также тесно связан с ресурсной моделью проекта. Наше ожидание: со стороны «ТерраЛинк» есть выделенная проектная команда, которая ставит систему по методу SAP Activate, затем выявляет и исправляет гэпы. Ожидание заказчика: в рамках проекта весь «ТерраЛинк» будет работать только на них, делать только этот проект, методологически обходя все подразделения клиента и снимая с них «показания» по выстраиванию процессов в системе перед ее внедрением, а затем внедрит на часть поздразделений.
Как избежать этого риска: обязательно согласовать план проекта до его старта, договориться о значении пилота и согласно плану букировать ресурсы команды.
3. Будьте готовы к трансформации (или трансформируйтесь уже сейчас)
Бывают проекты, в которых реализуется сразу несколько серьезных рисков. Например, вы по какой-то причине не смогли утвердить методологию, ресурсную модель и план проекта на старте. В нашей практике такое было, и уже в ходе проекта ожидания заказчика о методологии с нашими не совпали. Мы поняли, что ресурсов на проект нужно будет гораздо больше. Бывает, что растет количество требований к системе, в контур проекта добавляются новые юрлица, отделы и бизнес-процессы, система усложняется. Что делать? Есть три варианта.
Первый. Выйти из проекта. Но это серьезный репутационный и финансовый риск.
Второй. «Завалить» проект дешевыми ресурсами с рынка. Но риски для качества проекта и вашей репутации здесь также очевидны.
Третий. Проявить гибкость и способность к трансформации. Мы пошли по этому пути. Значительно усилили команду, выстроили полноценный проектный офис, развили практику DevOps в компании. Если до того судьбоносного проекта мы пользовались единым пулом ресурсов в компании, то сейчас в команде есть отдельные аналитики, отдельный консалтинг по настройкам системы, отдельный пул разработчиков, техподдержки, выстроена система автотестирования, есть отдельные PM, каждый из которых отвечает в проекте за свой участок и имеет свою выделенную команду. «ТерраЛинк» умеет брать на себя большой объем проектов, потому что мы правильным образом распределяем этапы работ и ресурсы между собственными командами.