Такая же, но с перламутровыми пуговицами: особенности замены ИТ-системы
Руководитель практики ALP Group по управлению финансами Юлия Орлова рассказывает, что интегратор может сделать для того, чтобы переход на новую учетную систему не был встречен в штыки.
Хорошо, когда вас позвали внедрять автоматизированную систему в компании, где весь учет традиционно велся только в Excel — не с чем сравнивать, улучшения очевидны, эффект автоматизации априори высокий.
Но бывает и так (а в последнее время всё чаще и чаще), что интегратору необходимо внедрить новую систему взамен той, что уже много лет используется в компании-заказчике. Топ-менеджмент может принять непопулярное решение о переходе в силу разных причин:
- текущее решение — устаревшее, не поддерживается вендором, не содержит актуальных возможностей для автоматизации, а поддерживать и актуализировать функциональность уже становится слишком трудозатратно;
- компания хочет объединить работу всех дочерних обществ в едином решении с целью унификации и снижения затрат на эксплуатацию;
- компания следует общему тренду на импортозамещение программного обеспечения.
Говорю «непопулярное», потому что всем людям свойственно отвергать новое в пользу привычного старого. Это часть нашей психологии. В ИТ-сфере, с ее ошеломляющей скоростью обновления решений, это неприятие нового особенно бросается в глаза («Дуров, верни стену!»). Если человек годами вел, скажем, бухгалтерский учет в одной системе, а потом ему вдруг установили на компьютер новую, то всё в этой новой системе кажется ему не таким, как надо. Эта кнопка расположена «не с той» стороны, эта функция спрятана в другом подменю, да и вообще, перламутровых пуговиц не хватает!
Сопротивление новому будет всегда, однако есть пара хитростей, которые помогут обеспечить выполнение целевых сроков и достижение нужных результатов. Сразу оговорюсь, что все приведенные советы основаны на личном опыте работы на проектах по внедрению финансового учета в крупных российских холдингах, но могут применяться в отношении любого ИТ-перехода.
Итак, чтобы смена ПО прошла максимально гладко, нужно:
1. Правильно оценить проект. Для этого в некоторых случаях можно сделать отдельный договор с заказчиком для проведения предпроектного обследования, в рамках которого можно будет зафиксировать требования и описать все текущие бизнес-процессы. Результатом такого договора будет полный отчет об обследовании, план-график внедрения, ресурсный план и корректная оценка перехода.
Здесь же хочется указать, что необходимо провести детальную инвентаризацию используемого функционала, поскольку в каждой системе, которая работает долгое время, есть ряд неиспользуемых процессов и доработок, которые не нужно перетаскивать в новую систему.
Отдельно стоит выделить вопрос анализа инфраструктуры: возможно, потребуется закупка новых серверов, ПО под программные продукты и интеграцию.
2. Обсуждать на этапе проектирования, какие изменения будут внесены. К сожалению, на практике мы часто видим, как заказчик ставит требование «максимально использовать типовой функционал» нового решения, а на этапе опытно-промышленной эксплуатации приходится судорожно всё переделывать под то, «как привыкли пользователи». Чтобы этого не допустить, важно представить в функционально-техническом задании подробные описания «как работает сейчас» и «как будет».
3. Закладывать на переход достаточные сроки, а не классическое «надо сделать вчера». В частности, нельзя забывать об актуальных требованиях в области информационной безопасности. Я бы сказала, что эти требования расширяются семимильными шагами, поэтому необходимо отдельно закладывать резерв времени на их удовлетворение.
4. Следовать принципу «есть слоненка по частям». Не нужно планировать единовременный запуск всех интеграций и всех модулей системы сразу. Такие запуски сложны и для пользователей и для команды проекта. Пул вопросов на пике запуска всегда существенный, и умножать его в несколько раз просто бессмысленно. Лучше правильно распланировать запуски функциональных блоков и интеграций для последовательного внедрения. Также не стоит пытаться приурочить к переходу на новое решение сразу все задумки и нововведения — сам по себе переход это уже стресс, а всё и сразу сделать всё равно не получится.
5. Не рубить сплеча и уважать стремление пользователей сохранить привычные функции из старого наследуемого решения. Ни в коем случае нельзя в одночасье отключать старую систему и включать новую. Риск остановки критических бизнес-процессов высок, и не принимать его во внимание — большая ошибка. Решение нужно проектировать так, чтобы у компании всегда была возможность сделать шаг назад. Например, когда мы внедряли модуль Казначейство, то сохранили возможность формирования заявок на платеж как в новом, так и в старом решении, с последующей выгрузкой в систему бухучета, и таким образом ни разу не попали в ситуацию остановки платежей.
Правда, здесь хочется добавить, что необходимо организационно регулировать переход, иначе есть и другой риск — получив возможность выбирать, пользователи по привычке продолжат еще сто лет работать в старой системе :)
Ключевое на всех этих этапах — это заинтересованность заказчика (особенно в лице владельца системы) в успешном внедрении. Ни один крупный проект не обходится без проблем и трудностей, но все они решаемы для команды, заряженной на результат.