Организация работ по внедрению систем ERP

Правило 4.

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

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

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

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

Правило 5.

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

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

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

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

Правило 6. Модификаций программных продуктов не должно быть.

Имеется в виду дописывание программных систем силами предприятия после их приобретения и установки. На практике этому правилу не всегда удаётся следовать, но прибегать к модификации надо только в исключительных случаях, когда нет иного выхода. Чтобы уменьшить вероятность модификаций, следует при выборе системы обращать особое внимание на гибкость её приспособления к меняющимся условиям. Модификации программных систем нежелательны по следующим причинам:

1. Возможны нарушения внутреннего единства системы, её интеграционных свойств.
2. Возможны программные ошибки.
3. Накапливаются отличия реальной программной системы от её документации.
4. Модификация может затруднить переход к новым версиям
программной системы.

Ещё одно средство избавиться от неоправданных изменений в программной системе - модифицировать не программный продукт, а внести изменения в бизнес-процессы.

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