Александр Тимошенко, руководитель программы ИФД "КапиталЪ"
Вокруг факторов успеха и рисков, возникающих при внедрении ERP-систем, очень много мифов. В докладе, состоявшемся на ERP-Forum-2004 весной этого года, руководитель программы ИФД "КапиталЪ" Александр Тимошенко поделился своим опытом и мыслями по поводу основных рисков, возникающих при внедрении ERP-системы, и способах их минимизации.
В целом по опыту выполненных мной проектов, а также тех проектов, которые я аудировал, перечень факторов, способствующих успеху внедрения ERP-системы, выглядит следующим образом:
- четкое понимание целей и задач проекта;
- учет специфики бизнеса;
- реалистичный, но при этом агрессивный план внедрения;
- привлечение лучших специалистов компании;
- выбор "лучшего" партнера для внедрения системы;
- внимательное планирование миграций, интерфейсов и отчетов;
- информирование компании о проекте;
- обучение проектной команды и пользователей;
- вовлечение руководства компании в проект;
- минимизация разработок и изменений в системе;
- достижение результатов, которые можно измерить.
Самое интересное, что факторы риска при внедрении, как правило, совершенно те же.
Вовлечение высшего руководства
"Вовлечение высшего руководства компании в процесс внедрения - один из главнейших факторов успеха", - консультанты повторяют это как заклинание. Безусловно, те руководители, которые определяют политику развития компании, должны быть вовлечены в этот процесс. Но здесь кроется и один из главных рисков проекта. К сожалению, очень часто происходит так, что при наличии общего перечня задач решение о внедрении конкретной системы принимается на основе субъективного ощущения топ-менеджера. Например, мы вовлекаем топ-менеджера в процесс выбора, и он принимает решение - "делать так, как у соседа". Увы, очень часто компании сначала внедряют систему, а потом начинают разбираться, для чего она на самом деле нужна. К сожалению, такие проекты, как правило, обречены на неудачу.
Кроме того, есть разные степени вовлечения руководства в проект. Наиболее предпочтительный - "не мешать". В такой ситуации нет ежедневного руководящего воздействия от главного пользователя в стиле "а давайте вот эту кнопку сделаем чуть больше". С точки зрения проектных результатов лучший вариант вовлечения руководства - это готовность последнего быстро реагировать на нужды проекта, связанные с проведением организационных и операционных изменений, помощь в преодолении сопротивления новым процессам и правилам. Естественно, есть и более "болезненные" степени вовлеченности руководителя в проект.
К тому же в больших компаниях обычно есть конфликт интересов. Например, двум вице-президентам нравится одна система, а еще два вице-президента хотят другую - не потому, что они разбираются в них, а просто, например, название Baan нравится им больше, чем SAP. И эти руководители начинают своих сотрудников, мягко говоря, не поощрять за участие в процессе внедрения другой системы. Принцип "не мешайте" подразумевает и то, что топ-менеджеры компании изначально договорились: внедряется одна система и она нужна всем. В одном из моих проектов, в компании UMC, был выбор между SAP и Oracle - один департамент выступал за SAP, другой - за Oracle. В течение двух месяцев шла скрытая война, пока мы не договорились, что если мы не будем внедрять какую-то одну систему, то не внедрим ничего. В конечном счете мы сделали предпроект на основе одной системы, и стало понятно, какую выбрать.
И наконец, на мой взгляд, требование вовлечения руководства означает, что консультантам очень удобно, когда генеральный директор выступает спонсором проекта или руководителем управляющего комитета. Ведь с ним легко решать любые проблемы. Но проблемы-то у консультантов очень разные: от понятных трудностей, связанных с отсутствием четко сформулированной учетной политики и плана счетов, до "мне не нравится качество стульев, на которых сидят наши консультанты". И порой оказывается, что качество стульев влияет на весь ход проекта и генеральный директор должен лично заниматься этим вопросом. К сожалению, сейчас слишком часто для консультантов необходимость руководящего менеджера, который ставит цели и знает, зачем внедряется система, подменяется формальным вовлечением первого руководителя.
Учет специфики бизнеса
Во всех проектах, которые я вел, всегда проводилось предпроектное обследование. И в одном из проектов - наверное, то был один из худших проектов в этом отношении, - мы получили самый красивый документ о предпроектном обследовании. Он состоял из 1282 страниц и был отпечатан на цветном лазерном принтере. При этом 1257 страниц этого документа представляли собой красиво распечатанное описание функциональности одной из ERP-систем. А на оставшихся 25 страницах говорилось о том, что данную ERP-систему в принципе можно использовать в телекоммуникационной отрасли. Вот на таком уровне после шести недель обследования консультанты поняли бизнес компании. Они не только его не знали, но и не попытались понять.
Это большая проблема, особенно для специфичных отраслей бизнеса. Ведь всегда хочется, чтобы пришедший консультант говорил на твоем языке, чтобы не приходилось объяснять, что такое, скажем, SIM-карта. Однако проблема в том, что консультанты, как правило, понимают это требование очень буквально: они берут на работу сотрудников, обладающих таким специфичным опытом. В результате в компанию приходит молодой выпускник института, который знает термины и даже умеет строить из них какие-то фразы. К сожалению, бизнеса он не понимает и реально помочь компании не может. Важно понять, что он отнюдь не стремится понять проблему компании, - просто он способен говорить с топ-менеджментом компании на одном языке, и все. Это отнюдь не то же самое, что разбираться в бизнесе. Конечно, так поступают не все консультанты, однако это встречается часто.
Качество консультантов
Кроме того, мне кажется, сейчас серьезной проблемой стал рост рынка ERP-систем в России. Когда мы в 1998 году внедряли ERP-систему, список кандидатов, предлагавших соответствующие услуги, был очень коротким, и оставался шанс выбрать правильного партнера. Сейчас внедрением ERP-систем занимается половина компаний на ИТ-рынке, причем получается, что уровень консультантов с годами становится ниже. Чего стоят только перлы из документов, которые пишут консультанты! Вот один из моих любимых: "Правильно сформулированное видение необходимости преобразований, обеспечивает правильные подходы для убеждения руководства в правильности делающихся преобразований". Это дословная цитата… Или еще: "Нам нужно обеспечить хорошее информирование проекта".
Сейчас консультанты почему-то очень любят два слова - "хороший" и "правильный". Возникает ощущение, что сегодня консультанты - не все, конечно, но около 30% тех, с кем мне приходилось сталкиваться, - не думают о системах, не знают их и даже этого не стесняются. Они не знают, что правильно, а что нет, но зато знают, что правильно - это правильно, а хорошо - это лучше, чем плохо. Их подход таков: "мы будем внедрять систему, но ее мы не знаем, а научимся вместе с вами по ходу проекта". Как не существует идеальных систем, так не существует и идеальных консультантов, к этому надо быть готовым.
Жесткий проект
При всей важности учета специфики бизнеса для успешности проекта еще очень существенно, как компания организует этот проект. По моему опыту, проекты должны быть организованы жестко, возможно, некоторые эксперты даже сочли бы их практически невыполнимыми. Но, на мой взгляд, некоторая жесткость проекта не противоречит его реальности. Более того, если команда внедрения и консультанты находятся в состоянии легкого давления на них, некоторой "сжатости", когда время на решение их задач ограниченно, результат получается гораздо лучшим.
Догма методологий
При планировании проектов консультанты любят использовать различные методологии (AIM у Oracle, ASAP у SAP, есть свой набор методологий и у Accenture и IBM Business Consulting Services). Но очень печально, когда из-за следования методологиям теряется большая часть работы. В свое время нам пришлось затратить большие усилия, подолгу объясняя консультантам, что мы хотим увидеть что-нибудь работающее - пусть не полностью работающее, не отвечающее всем нашим требованиям, но хоть что-то реальное на начальных этапах проекта. И причина была проста: мы не хотели такой ситуации, когда наши пользователи рисовали бы квадратики бизнес-процессов, подписывали и согласовывали схемы, а после этого начиналась бы вечная дискуссия: "вы же согласовали этот бизнес-процесс - но мы же не представляли, что бизнес-процесс, нарисованный на экране, в этой системе будет таким…". Поэтому мы долго уговаривали консультантов: давайте сделаем так, пусть даже по AIM такого нет. Разве AIM - это догма? Любая методология - это направление движения, а не жесткий свод законов.
К сожалению, сейчас консультанты пытаются подменить эти два понятия и стараются точно следовать стандартной методологии. Конечно, можно составить идеальный план проекта, выполнить его любыми средствами, но в итоге компания-заказчик, как правило, будет недовольна. Если изменились предпосылки, то почему бы не изменить план? Принятую методологию внедрения нужно разумно использовать, а не слепо следовать ей.
Кроме того, очень часто в компаниях идут параллельные проекты. Например, в ИФД "КапиталЪ" параллельно идет внедрение системы Oracle E-Business Suite и системы бюджетирования. Очень часто менеджеры проектов и руководство компании забывают о том, что изменение одного проекта повлияет и на соседний, а в результате возникает необходимость в "пожарных" действиях по спасению проекта. Очень важно заранее минимизировать негативные последствия того, что мы забудем учесть все другие проекты, происходящие в компании.
Один из компромиссов, которых обычно пытаются достичь в ходе проекта, - это число кастомизаций и доработок. Мы всегда стремимся к их минимизации. Известна точка зрения, что кастомизация - это лишние трудности, доработки потом нуждаются в дополнительной поддержке. Наверное, правильный подход можно сформулировать как 80/20, т. е. нужно стараться 80% функциональности оставлять неизменными, заставляя компанию перестраиваться под эти процессы. Самое страшное, что консультанты могут долго рассказывать о вреде кастомизации, но когда им предлагаешь: "Мы готовы перестроить компанию под ваши процессы, только скажите, почему процессы именно такие, и объясните их логичность", - в ответ тебе говорят: "А вы расскажите, как у вас". В методологии прописано - сначала as is, потом to be, вот так они и поступают. А сразу to be - это не соответствует методологии.
Рутина интеграции
Какие особенности проекта часто приводят к разногласиям между консультантами и заказчиками? Так сложилось, что в моих проектах всегда было много внешних систем, с которыми нужно было обеспечить интеграцию. Почему-то это меньше всего интересовало консультантов, хотя всегда в задании мы писали "нужно интегрировать с 15 системами". Часть консультантов просто не понимает, что такое "непрерывное ведение бизнеса". Они считают, что достаточно внедрить систему, и все. А как она будет работать с другими системами, сможет ли в момент запуска соответствовать всем требованиям, - этот момент, как правило, выходит за рамки проекта. Это самый неинтересный, самый тяжелый, самый рутинный вопрос, и консультанты стараются его обходить. Для консультантов интерфейсы, процедура миграции и т. д. - это нудная, непродуктивная и неинтересная работа.
Обучение и привыкание к новой системе
Привыкание к новой системе - это важнейший момент. В одной из компаний при внедрении ERP-системы провели исследование, и оказалось, что из-за некачественного обучения в конце проекта 95% документов, которые были введены в течение первого месяца, потребовалось вводить заново. Это яркий пример того, что такое плохое обучение. В своих проектах я всегда старался организовать обучение пользователей как можно раньше и проводить его не на какой-то модели или виртуальных данных, а на реальных системах, - чтобы люди почувствовали, что это их система, и готовились с ней работать.
Выбор партнера по внедрению
На мой взгляд, при выборе партнера надо проводить сравнение команд внедрения. И здесь принципиально важно предпроектное обследование. Оно позволяет выяснить, насколько консультанты в состоянии понять бизнес компании и насколько хорошо они знают систему. Проведя предпроектное обследование, - при условии, что те же консультанты будут участвовать в проекте, - вы по крайней мере можете гарантировать прогнозируемость их действий. Если компания не проводит предпроектное исследование, а полагается только на красивые презентации и на лучшие в мире методологии, с очень высокой вероятностью она будет долго эти методологии оплачивать, а потом, может быть, получит какой-то результат. Я уверен, что 50 тыс. долл., потраченных на предпроектное обследование, могут сэкономить несколько миллионов, которые вы бы потратили, выбрав неудачную команду внедрения, будучи вынуждены с ней работать, ее кормить и, несмотря ни на что, довести проект до конца.
При выборе партнера вообще приходится действовать тонко. Консультанты ведь делятся на несколько категорий: просто болтуны; консультанты, хорошо знающие систему, и хорошо знающие бизнес. И для каждого проекта нужно найти баланс, то дополнение, которое будет наилучшим образом соответствовать возможностям команды предприятия. Возможна ситуация, когда в компании-заказчике команда сильна в исполнительском плане. Тогда этой компании нужны в первую очередь специалисты по методологии и в хорошем смысле немного болтуны. А если специалисты компании очень сильны в методологии, у них хорошо поставлены учетные политики, тогда, мне кажется, было бы полезнее взять консультантов, хорошо знающих систему и способных выработать оптимальное решение, которое будет лучшим и для компании, и для системы.
По большому счету я думаю, что для большинства предприятий гораздо важнее не то, какую систему - Oracle, SAP или Baan - внедрять, а то, какая у них команда внедрения и какой консультант.
И в заключение - всегда будьте осторожны с консультантами, потому что не всегда они рассказывают правду. Очень часто это только красивые мифы.
|
Принципы составления плана проекта
Особенности проекта внедрения ERP-системы
Последовательность шагов при выборе системы и партнера по внедрению
|
