Технология внедрения ERP-систем

Лисин Николай

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

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

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

Технологии создания ERP-систем в настоящее время развиваются. Если еще лет 10 назад мы ориентировались на серию 34-х ГОСТов, то сейчас мало кто про них вспоминает. Возможно, лет через 10 мало кто вспомнит и про технологии, которые применяются сейчас.

Современная технология создания ERP-системы качественно отличается в том, что процесс как правило является итерационным: результат выполнения предыдущей операции (этапа работ) определяет параметры выполнения следующей операции (этапа). Заказчик и Исполнитель двигаются к результату отдельными итерациями, на каждой итерации уточняя в том числе требования к системе.

Не выполнив очередную операцию (итерацию-этап), нельзя в точности знать, что и как мы будем делать на следующей операции. Почему происходит именно так – покажем чуть ниже. Основная причина – исследовательский характер работы обеих сторон (Заказчика и Исполнителя) на ERP-проекте. Исследование – это не процесс создания материального товара, где заранее точно известен результат и способы его получения.

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

При этом изначально известны, как правило, только несколько основных целей и некоторый небольшой объем исходных данных.

А сейчас покажем, какие логические шаги (этапы) лучше всего выполнить при создании ERP-системы. Наши цели:

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

• Установление взаимотношений доверия, сотрудничества и полного взаимопонимания на проекте между Заказчиком и Подрядчиком. Это возможно, если заранее определены, поняты и приняты правила игры обеими сторонами, стремящимися работать честно и добросовестно, одинаково заинтересованными в результате. Если таких отношений нет, то скорее всего, проект обречен на провал. Правила игры – это и есть проектная технология.

С чего можно начать?

Отметим, что очень редко система автоматизации создается сразу на все бизнес-процессы, и запускается сразу тоже по всем процессам.

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

Например, сначала запустить оперативный учет, а потом – диспетчеризацию производства.

Рассмотрим плюсы и минусы такого подхода.

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

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

В случае внедрения по очередям – риск несистемности нивелируется правильной последовательностью очередей. Например, не следует запускать вначале регламентированный учет, если целью стоит автоматизация управления производством.

В случае внедрения на пилотное зоне – риск нивелируется выбором наиболее сложной для автоматизации зоны.

Плюсы в большинстве случаев на практике перевешивают минусы.

Семь раз отмерь – один раз отрежь?

Следующая рекомендация: попробуем усовершенствовать классическую «каскадную» модель работы.

В каскадной модели декларируется “системный подход”: сначала составлялась исчерпывающая проектная документация, продумывалась вся система в целом, затем выполнялись настройки – и только затем пользователей допускали «пощупать» систему в ходе опытной эксплуатации.

В каком направлении надо двигаться?

Обсуждения, совещания и поиск решения «на бумаге», как это было принято при каскадном подходе – можно считать теоретическими изысканиями. Сначала спроектировали – потом реализовали. В соответствии с пословицей «Семь раз отмерь – один раз отрежь». Хорошо ли это?

Что удивительно – этот очевидный подход для многих отраслей (например, для строительства), в ИТ-технологиях, оказывается, не самый оптимальный. Как это ни странно…

Представим себе, что заказчик нарисовал набросок дома, после чего привозятся стройматериалы и начинается немедленно строительство. Каменщики втыкают кирпичи, клиент сразу смотрит что получается, критикует, каменщик кладет кирпич на другое место… По ходу строительство клиент “созревает” где у него должно быть окно, а где – балкон… Бред?

Очевидно, что так строить дома нельзя. Может получиться вот что: :)