Реализовать и не разориться: как техническая оценка спасает ИТ-проекты в Казахстане

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

Компания в Казахстане объявляет тендер на миграцию корпоративной системы. Участники получают техническое задание, оценивают объем, называют цену. Проект стартует. А через год выясняется, что бюджет занижен в полтора раза, сроки сорваны на полгода, а система бюджетирования запустилась позже, чем закрылся финансовый год в старой. В итоге финансовая отчетность не закрыта ни в одной из систем, а заказчик не понимает, что делать и как дальше быть. А ведь грамотная предпроектная подготовка снижает вероятность неудачного внедрения исхода примерно на 70%.

И такой сценарий при реализации крупных ИТ-проектов во всем мире не редкий. По данным Gartner, от 55 до 75% проектов по внедрению корпоративных систем не достигают заявленных целей, а средний перерасход бюджета составляет 189%.

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

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

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

В практике IBA Group был случай, когда заказчик использовал модуль, разработанный сторонней компанией с закрытым исходным кодом. Любые изменения требовали обращения к вендору, собственная команда не могла работать с системой самостоятельно. Именно техническая оценка позволяет выявить такие зависимости до старта проекта и заложить в план их устранение, а не разбираться с ними в разгар внедрения».

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

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

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

При этом мотивация выполнять техническую оценку у компаний разная. Одни проводят ее, чтобы сэкономить. Ведь точное понимание объема позволяет сократить часть статей бюджета еще до старта. Другие хотят снизить риск при выборе подрядчика. Третьи решают более конкретные задачи. Например, одна крупная компания перед миграцией на SAP S/4HANA хотела разобраться, как реализовать нестандартную методику расчета себестоимости на стандартных инструментах, не повторяя ошибок предыдущего внедрения.

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

Для большинства крупных компаний Казахстана такая ситуация вполне реальна в контексте перехода на SAP S/4HANA. Масштаб задачи здесь выше, чем при обычном обновлении системы: меняется не только технология, но и логика бизнес-процессов. Системы, которые работали годами, могут содержать сотни нестандартных доработок, закрытых интеграций и решений, принятых еще на этапе первого внедрения. Без технической оценки все это обнаруживается уже в ходе проекта и приносит множество проблем.

Сложно судить о всем рынке, но при реализации таких переходов в IBA IT Park проводят оценку как отдельный проект: анализируют текущее состояние системы, определяют объем автоматической конвертации, выявляют риски и формируют реалистичный план миграции с вариантами и оценкой бюджета. За более чем 13 лет работы на рынке Казахстана и СНГ такой подход доказал свою жизнеспособность, позволяя выполнять проекты качественно и вовремя.

Грамотная предпроектная подготовка снижает вероятность негативного исхода примерно на 70%. Остальное — форс-мажор, который не предусмотришь никаким планированием. Но управляемая часть рисков поддается контролю, если потратить время на подготовку до старта. Техническая оценка требует времени и бюджета. Но проект, который стартовал без нее, обходится значительно дороже.