Издержки широкой функциональности

↑

⇐ ПредыдущаяСтр 3 из 15Следующая ⇒

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

Типовой процесс внедрения ERP системы включает следующие стадии:

1. Заключение договора, в котором формулируются принципиальные требования к системе.

2. Написание технического задания, в котором основные требования будут сформулированы более развёрнуто. Здесь заказчик подтверждает, что он действительно хочет получить именно такой результат.

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

4. Разработку технического проекта. Здесь формируются наиболее детальные требования к системе, по которым она и будет настроена. На этом этапе заказчик старается максимально обезопасить себя, придираясь к каждой детали. Но оказывается, что в рамках утверждённого им же календарного плана на удовлетворительную с его точки зрения проработку этого у него нет времени. А изменение календарного плана в соответствие с подписанным им же договором, влечёт за собой и изменение финансирования проекта. Заказчик подписывает в надежде отшлифовать систему во время приёмки.

5. Составление требований к контрольному примеру. Тут заказчик подтверждает, что действительно, если на основе таких-то исходных данных будет получен такой-то результат, то это будет означать, что система обеспечивает необходимую функциональность. Заказчик понимает, что контрольный пример хоть и соответствует техническому проекту, но будет моделировать некоторую идеальную ситуацию.

6. Составление требований к пусконаладочным испытаниям. Здесь заказчик узнаёт, что принимать ему предстоит некую демо-версию системы, построенную на утверждённых им контрольных примерах.

7. Составление требований к пусконаладочным работам. Из этого документа заказчик узнаёт, что на этом этапе он может рассчитывать только на обучение персонала и исправление недочётов в рамках технического проекта.

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

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

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

Познавательные статьи:



Алгоритмические операторы Matlab

Конструирование и порядок расчёта дорожной одежды

Исследования учёных: почему помогают молитвы?

Почему терпят неудачу многие предприниматели?