Внедрение ERP-системы

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

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

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

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

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

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

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

www.management.com.ua

Март 3, 2008 — Рубрика: Национальные особенности
Метки: , , ,