Подготовка к внедрению ERP систем

Подписание контракта на внедрение

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

На стадии заключения контракта по внедрению ERP обычно невозможно достоверно определить наиболее важный показатель — объем проекта (и, соответственно, его временные рамки, стоимость и т. д.). Поэтому вендоры очень внимательно следят за тем, что входит в проект, а что нет. Компании со своей стороны стоит в рамках контракта также настоять на ряде важных моментов.

Объем проекта и вопрос дополнительных работ

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

Что означает на практике не предусмотреть такой пункт? Одна из FMCG-сетей, действующая и в Украине, при заключении контракта оговорила лишь процесс внедрения, обойдя дополнительные работы вниманием (предполагалось, что в Украине будет проведена адаптация системы, параллельно внедряемой во всей компании). В результате каждый запрос на изменения проходил как почасовая работа ИТ-специалистов вендора, и, кстати, вовсе не от жадности последнего. Внедряющая организация планирует время своих сотрудников и, когда появляются непредусмотренные заказы клиентов на мелкие работы, просто вынуждена считать их по максимальной ставке. Как следствие компания понесла не только повышенные затраты, но и, что более важно, незапланированные проблемы решались достаточно долго.

Радикально другим путем пошла одна из сетей в секторе игорного бизнеса. Работы по внедрению системы велись «в открытую» — специалисты заказчика потоком высказывали пожелания, которые (после необходимой обработки) немедленно включались в объем проекта. Здесь изначально в проект были включены только покупки необходимых лицензий на программное обеспечение и инсталляцию стандартной функциональности системы.

Скажем так: лучшее решение для большинства компаний — среднее между упомянутыми примерами. Это означает купить лицензии на программу, на функционалы, оговорить объем проекта, создать резервный фонд.

К вопросу о дополнительных работах — эту процедуру стоит максимально упростить. Для обоих случаев — для случая, когда компания заказывает дополнительные работы, и случая, когда компания заказывает (безоплатно) исправление проблем с купленной стандартной функциональностью системы. Реально для таких заявок единственно важное — их фиксация, и чем меньше бюрократии, тем лучше. Если контрактом будет предусмотрена специальная форма на английском языке на пяти страницах с требованием дополнить заявку скриншотами проблемы или детальным описанием заявки на изменение стандарта, то множество мелких проблем не будет решаться или будет решаться крайне медленно. Лучше взвалить бюрократию на вендора — от заказчика обязана поступить почта с кратким описанием проблемы, вендор делает всю бюрократию на своей стороне и реагирует в определенное контрактом время.

Команда по внедрению

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

В качестве операционного управляющего проектом целесообразнее назначать представителя компании, а не привлекать на временной основе специалиста из компании-вендора, что иногда имеет место. В последнем случае руководитель проекта будет поставлен на пересечении интересов вендора и клиента — это может только повредить. Такой специалист будет отлично знать программу, но не потребности компании, и лучше понимать аргументы внедряющей организации. Это кажется малой проблемой — потребности можно пояснить, интересы — соблюсти. Но различия могут быть слишком значительными. К примеру, проект упомянутой выше FMCG-сети частично приостановился на 1,5 месяца только потому, что руководитель проекта (сообразуясь с информацией от вендора и будучи сам ИТ-специалистом) счел работы по фронт-офису завершенными, в то время как бухгалтерия компании считала иначе.

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

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

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