Готов? - Пошел!
Как определить, готово ли предприятие к внедрению ERP-системы? Видимо, основной критерий - наличие у его руководства некоторых проблем, а точнее, осмысленных глобальных задач (проблемы - запрещенное слово в консалтинге). Например, предприятие ставит перед собой цель выйти на международные биржи, либо владельцы хотят через некоторое время выгодно продать предприятие, либо компания оказалась в аутсайдерах в ситуации жесткой конкуренции и желает исправить положение.
Второе - осознание этой главной задачи высшим менеджментом и его способность декомпозировать ее на определенный набор целей. Вообще целеполагание является зачастую самой главной проблемой в начале проекта, особенно когда возникает разрыв между топ-менеджерами, которые ставят задачу внедрения, и средним звеном управленцев, отвечающими за него со стороны заказчика. Порою в российских компаниях среднее звено пытается "экранировать" свое руководство от консультантов, ограничить "доступ к телу", что приводит к формированию искаженной картины, полученной через призму восприятия среднего менеджмента. В результате консультант формализует неправильные цели и получаются неправильные результаты внедрения, т. е. те, которых не ждали.
TeamTrack 6 демонстрирует ход работ над
проектом в самых разных проекциях
Ну и третий критерий - это наличие ресурсов. В зависимости от того, насколько верно позиционирован проект по внедрению ERP-системы в компании, ее руководство находит либо не находит ресурсы. Если такой проект входит в тройку первоочередных, стратегически важных, то ресурсы всегда найдутся. Причем и финансовые, и человеческие. Очень важно предусмотреть и то и другое. Ведь зачастую клиент занимает такую позицию: "Я, заказчик, деньги вам выделил, а вы теперь идите работайте и возвращайтесь ко мне с результатом". Подобная постановка недопустима, поскольку внедрение тяжелых ERP-систем - это не проект консультанта, а проект клиента. Консультант - человек, всего-навсего дающий советы. Ему даже не обязательно уметь конфигурировать систему или описывать бизнес-процессы. Он должен объяснить клиенту правильную последовательность действий и помочь ему интерпретировать их результаты. На мой взгляд, основной результат проекта по внедрению ERP-систем, таких как, например, Oracle E-Business Suite, - не установленный софт, а тот коллектив на предприятии, который после ухода консультантов будет способен развивать и эксплуатировать систему. Поэтому если заказчик согласен выделить деньги, но не готов выделить людей - это свидетельство того, что он не готов к внедрению.
Кого куда прогибать будем?
Что делать, если система не ложится на те бизнес-процессы, что сегодня существуют на предприятии? Возможны два решения: либо мы подвергаем реинжинирингу бизнес-процессы, т. е. идем на оргпреобразования, либо начинаем ломать систему - кастомизируем ее. А что правильнее? Конечно, лучше идти на оргпреобразования, потому что в системах этого класса заложен наилучший опыт крупнейших международных компаний и наиболее успешных менеджеров. Но все же вопрос всегда решается индивидуально.
Рассматривается достаточно много аспектов. Самый главный - экономический. Нужно прикинуть: если мы изменим бизнес-процесс, то что получим в результате? Что сэкономим? Или что мы выиграем, если кастомизируем систему? Ведь ни для кого не секрет, что кастомизация на самом деле имеет много минусов: затрудняет сопровождение системы в будущем, переход на следующую версию и пр. Документация на доработанную систему весьма объемна, и разобраться в том, что можно трогать, а чего нельзя, очень сложно. Поэтому функциональное развитие системы, когда мы хотим что-то добавить к ней, тоже затрудняется.
Нужно, чтобы не консультант формировал ожидания, а сотрудники со стороны заказчика. А если они не в состоянии это сделать, то консультант должен им помочь облечь неосознанное в осязаемые формы. |
К тому же зачастую требования клиента вызваны не реальными нуждами, а просто "хотелками", связанными с определенными привычками ("я всегда делал так, почему теперь я это должен делать по-другому?"). Если это дань привычке, то консультант должен использовать весь свой опыт, чтобы объяснить, почему целесообразнее изменить бизнес-процесс, убедить клиента в том, что это даст положительный эффект.
В то же время иногда встречаются реальные особенности, скажем, технологического или местного характера, действительно требующие кастомизации, - тогда это вынужденный шаг, на который идти необходимо. И тут, наверное, ни один консультант спорить не будет.
Но я оцениваю квалификацию консультанта (наряду с прочими критериями) в том числе и по количеству кастомизаций в его проектах. Чем их меньше, тем выше квалификация консультанта. Ведь программу написать каждый может, а ты вот изучи досконально систему, пойми, как эту богатейшую функциональность можно использовать для реализации даже не совсем обычных требований. Чем лучше консультант понимает систему, тем легче он решает эти задачи.
Можно ли измерить удовлетворенность?
Я, как и 99,9% российских граждан, находясь в зарубежных гостиницах, игнорирую анкету посетителя. У нас такой менталитет. А иностранцы эти анкеты педантично заполняют. Я был просто поражен, когда увидел, как мой коллега из Oracle UK, уезжая из Магнитогорска и задерживая ждущее внизу такси, сидит и проставляет "птички". Их так приучили. Они хотят, чтобы в следующий раз их обслужили еще лучше.
При серьезном внедрении ERP тоже прибегают к социометрии и психометрии, достижения которых сегодня широко используются при составлении всевозможных тестов. В Oracle есть процедура, называемая ESM (Engagement Satisfaction Management). Смысл ее вот в чем. Спонсору проекта (кому-то из руководства предприятия) предлагается некий опросник, где по каждому пункту он ставит две оценки - степень важности, с его точки зрения, упомянутого показателя, и его реальная оценка по пятибалльной шкале. (Большую градацию, наверное, делать не имеет смысла, человек не всегда способен к детальному дифференцированию.) Там порядка 35 вопросов, охватывающих разные аспекты внедрения: насколько консультанты хорошо знают индустрию, в которой работает клиент; хорошо ли они передают знания сотрудникам заказчика; каково качество выходных документов в проекте и т. д. Потом проводится обработка и выставляется сводная оценка.
Вообще-то, это некий консалтинговый инструмент, достаточно формальный, если к нему подходить формально. Но что происходит при выполнении этой процедуры? Скажем, если менеджер проекта или директор по консалтингу встречается со спонсором проекта, с лицом достаточно высокопоставленным, и получает возможность обсудить какие-то проблемы в проекте, то наряду с получением этих формальных цифр удается составить и свое субъективное мнение, насколько этот руководитель удовлетворен нашей работой. У консультантов появляется возможность задать трудные вопросы, а у клиента - высказать свои опасения. В этом смысле такая процедура очень полезна. По правилам Oracle она проводится раз в квартал.
На "Метафраксе", к примеру (где наша работа получила 4,75 баллов из 5 возможных), мы проводили опрос членов управляющего совета и выводили некую среднюю оценку. Но главное - в процессе обсуждения завязывался неформальный разговор, в ходе которого мы получали дополнительную информацию от заказчика и решали определенные психологические проблемы, а их в консалтинговых проектах конечно же очень много. Так что подобное анкетирование - это не просто измерение степени удовлетворенности, но еще и способ проактивного воздействия на людей, оказывающих существенное влияние на компанию.
К автору, директору по консалтингу "Oracle СНГ", можно обратиться по адресу: Michael.Sidorenko @oracle.com.
