Топ-5 советов по организации замены ИТ-системы

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

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

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

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

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

Итак, чтобы смена программного обеспечения прошла максимально гладко, нужно:

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

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

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

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

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

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