Печать
Категория: Управление изменениями

Я сам работал в консалтинговых компаниях, знаю эту кухню изнутри. До 2006 года несколько лет занимался внедрением ERP-систем. Любое реальное внедрение так или иначе сопровождается организационными изменениями. Хочу поделиться своим опытом по пробуждению заказчика. Эта заметка будет ссылаться на презентацию в разделе «Файлы».

Я видел массу неудачных проектов и разобрался в причинах этих неудач. Отчасти они были связаны с бездумным следованием формальным (и устаревшим) методологиям водопадного типа, где после обследования делается ТЗ или Дизайн, т.е. некий массивный документ (часто многотомный), который не дает наглядного представления о будущем устройстве информационной системы и самого процесса обработки данных. Тем не менее, методология рекомендует утвердить этот документ у Заказчика и далее делать именно то, что там написано. Часто на практике происходило так. Шаблоны документов с заполнением на 90% были уже готовы. Так называемое «решение - to be» было заранее описано и базировалось на стандартном функционале предлагаемой ERP-системы и ранее сделанных разработках компании. В итоге, заказчику впаривали «шаблон» под видом индивидуального (уникального) решения. Все вынужденные доработки минимизировались. На этапе внедрения правда вскрывалась и начиналась вторая волна: доработки на основе доп.соглашений к основному договору. В результате консалтинговая компания получала дополнительные деньги, которые с лихвой компенсировали скидки на этапе переговоров и тендера. Это стандартная и порочная практика приводила к большим потерям времени и денег и получению посредственного результата.

Мне удалось на определенном проекте преодолеть этот шаблон работы и успешно испытать собственную методику внедрения. Суть её в пробуждении заказчика и раннем прототипировании будущей системы, в создании единой рабочей группы (заказчик + исполнитель) и устранении противостояния, в непрерывной приемке результатов.

Некоторые принципы этой методики можно увидеть в презентации «Сильный заказчик – успешный проект». Презентация делалась для того, чтобы поделиться успешным опытом с другими сотрудниками консалтинговой компании. Я считал и сейчас еще больше уверен, что работа с сильными (грамотными и заинтересованными) заказчиками всегда на пользу консалтинговой компании, потому что это заставляет её развиваться (не стоять на месте) и повышать свою конкурентоспособность. Сильного заказчика нужно делать! И это должно быть частью проекта!

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

Не следует слепо копировать предложенный подход. Всегда нужно работать вдумчиво и на 100% отвечать за свой выбор, но при этом не зашориваться.

Мне показалось, что мой опыт в IT-сфере, связанный с организацией совместной работы с заказчиком и проведением организационных изменений, будет полезен для продвижения ЛИН-культуры на конкретных предприятиях (управление изменениями) и для более эффективного взаимодействия с внешними консультантами.