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

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

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

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

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