10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Меня зовут Евгений Грибков, я – руководитель внедренческого центра «Раздолье».

Наша компания специализируется на внедрениях 1С:ERP и 1С:Управление холдингом – в основном на промышленных предприятиях.

Ежегодно наши проекты становятся победителями конкурса «1С:Проект года». По данным Справочника внедрённых решений фирмы «1С» у нас самое большое количество успешных внедрений 1С:ERP на крупных промышленных предприятиях.

Мы работаем с разными отраслями – машиностроение, пищевая отрасль, фармакологическая, добывающая промышленность и т.д.

Естественно, в ходе этих проектов мы набиваем много шишек, систематизируем их и по итогам выработали список типовых рисков.

О десяти таких рисках я и собираюсь рассказать в докладе. Надеюсь, это поможет вам избежать хотя бы одного из них – это будет уже ценно.

Риск №1. Нет бизнес-цели

Первый риск – это риск проектов, у которых нет бизнес-цели.

Это может быть проект, который инициируется управляющей компанией, холдингом.

Если не проработан вопрос бизнес-целей для самого предприятия, на котором внедряется, например, ERP-система, такие проекты в подавляющей части в нашем опыте заканчиваются очень плохо:

• в лучшем случае рождается система, которая постепенно деградирует до бухучета;

• в худшем случае такой проект вообще не завершается успешно.

Так происходит из-за того, что любое внедрение ERP-системы – это довольно большой объём работ со стороны заказчика. Если заказчик не понимает, для чего он это делает, он и относится к этому формально. В результате получается система, которая не особо нужна бизнесу.

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

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

Если пользователи не понимают, что они приобретают при внедрении новой системы – они будут как минимум требовать повторения функциональности, интерфейсов и т.д. старой системы.

Риск №2. Заказчик не готов выделять время своих специалистов

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

Естественно, так не бывает. В любом проекте внедрения ERP-системы цели исполнителя и заказчика слегка отличаются.

• цель исполнителя – выполнить проект, уложиться в бюджет, в сроки и в те границы, на которые договорились;

• цель заказчика – получить какой-то профит для бизнеса, что-то упростить, получить какие-то возможности, которые позволят что-то улучшить в бизнесе.

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

Как с этим риском можно управляться?

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

• И руководителю проектов со стороны заказчика в обязательном порядке нужно это время запланировать. И не надо надеяться, что ключевые пользователи смогут сделать это между делом. Они обычно на то и ключевые, что сильно заняты, и между делом они просто проигнорируют проектные задачи.

Риск №3. Переход с сильно доработанного старого решения

Следующий риск, о котором хочу рассказать – это переход с сильно доработанного старого решения.

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

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

• либо проект с очень большим бюджетом на кастомизацию, когда вы во многом будете повторять механизмы, интерфейсы и т.д. старой системы в новой;

• либо, если заказчик в лице первых лиц хочет использовать типовые механизмы – это будет довольно сложный проект с политической точки зрения проекта, потому что придется бороться с пользователями.

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

Риск №4. На этапе моделирования – излишние требования пользователей

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

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

Поэтому либо берите опытного исполнителя, который будет с этим бороться, либо боритесь с этим сами.

Риск №5. Изменение процессов в ходе проектирования системы

Пятый риск – изменение процессов в ходе проектирования системы.

Эта ситуация обычно выглядит так: запускается новый завод. Он строится, и в этот момент начинается проектирование будущей ERP-системы.

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

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

Если бюджет не ограничен, можно сделать два проекта.

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

Риск №6. Команда проекта не имеет компетенций в области внедрения

Следующий риск, о котором я хочу рассказать – это когда команда проекта не имеет компетенций в области внедрения. Например, они хорошо знают ERP, но никогда ранее в вашей отрасли не работали.

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

Риск №7. Нехватка времени на подготовку данных

Следующий риск, о котором скажу – это нехватка времени на подготовку данных. Этот риск в основном свойственен проектам, которые выполняются не очень опытными командами.

Проблема связана с тем, что иногда период подготовки данных для загрузки системы – это несколько месяцев. И когда исполнитель говорит, что система готова к запуску, в нее нужно грузить данные, а у вас еще ничего нет – вы получаете отсрочку в проекте. А это всегда печально.

Управление этим риском довольно простое – об этом просто надо не забывать и прорабатывать этот вопрос с самого начала проекта.

Риск №8. Саботаж пользователей при запуске

Следующий риск – саботаж пользователей при запуске проекта.

Какую бы суперсистему мы ни сделали, подавляющая часть пользователей все равно не захочет осваивать новую систему. Люди консервативны, так происходит почти всегда.

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

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

Это, наверное, единственный способ. Как только пользователи начинают чувствовать, что руководство поддерживает вероятность того, что новая система не будет запущена, пользователи предпримут все усилия, чтобы система не была запущена.

Риск №9. Люди не успевают вносить данные в 2 программы

Девятый риск – люди не успевают вносить данные в две системы.

Довольно часто, чтобы стабилизировать новую систему, учет какое-то время ведется в двух системах (в новой и старой). Это не всегда правильно, но так бывает.

В этом случае пользователи, естественно, не успевают вносить данные в обе системы.

Этот риск можно решить через:

• вопрос мотивации – возможна дополнительная мотивация;

• набор людей-операторов на момент параллельного ведения учета;

• и очень важно не упустить, что в этот период главной системой должна стать новая система – в старую систему данные должны вноситься только после того, как они внесены в новую. Либо они должны переноситься из новой системы, если это возможно сделать технически. Тогда вероятность того, что после опытной эксплуатации система останется живой, сильно повышается.

Риск №10. Ошибки при сравнении данных со старой программой

Следующий риск, о котором расскажу – это ошибки при сравнении данных со старой программой.

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

Наш опыт показывает, что получить такие же данные, как в старой системе, практически никогда не удается. Это связано:

• с ошибками ввода данных;

• с тем, что старая система работает неправильно – так происходит в огромном числе случаев, почти всегда;

• к тому же в разных системах может быть разная логика ведения учета.

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

Вопросы и ответы

Если вернуться к первому риску, который звучит как «бизнес не является заказчиком» – как же быть в тех проектах, где действительно ИТ подталкивает бизнес? Например, если проект – переход с УПП на ERP. Понятно, что это риск, но что, ничего не делать?

Здесь есть три варианта.

• Первый вариант (более правильный): все-таки совмещать переход с УПП на ERP с внедрением какой-то функциональности, которая принесет пользу бизнесу. И тогда бизнесу станет понятно, зачем им тратить на это время – в этом будет хоть какой-то смысл.

• Либо нужна сильная политическая воля, чтобы ломать все претензии пользователей.

• Либо большой бюджет на то, чтобы все кастомизировать и делать ERP похожей на УПП.

Все это усугубляется тем, что некоторые механизмы УПП и ERP организованы таким образом, что пользователям больше нравятся УПП-шные варианты. И очень сложно перевести их на ERP – нужно объяснять, почему они теряют некоторые удобства, которые у них были. Т.е. мы дополнительно сталкиваемся с риском противодействия.

Поэтому все равно надо искать выгоду для бизнеса. В противном случае это будет дорого и бессмысленно.

На тему рисков удобно иметь чек-лист, чтобы прогонять их в течение проекта – не забывать о нем, показывать руководству и спонсорам.

Я с вами абсолютно согласен. Риски – это обязательный раздел для статус-совещаний, которые должны проводиться на большом нудном заводе раз в неделю пусть без первых заместителей, но хотя бы с руководством проекта.

На тех проектах, где участвует собственник, это можно делать реже, и основная задача здесь конечно же анализировать, что сработало. Чаще всего мы же указываем риски заказчика. Например, если нет сервера к старту проекта – все, проект остановился.

Указывать свои риски или нет – это зависит от уровня доверия между вами и заказчиком. Вопрос откровенности между исполнителем и заказчиком очень разный. Это примерно как вопрос: «Можно применять Agile на фикспрайсовых проектах или нельзя?» Если доверие есть, то можно. Если его нет, это будет очень странная игра с закрытым бюджетом в открытые границы.

Что для вас значит «провал проекта»? Увеличение сроков, увеличение бюджета – это провал?

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

Если проект перехода на новую систему закончился тем, что переход состоялся, какие-то доработки были сделаны, но бюджет вырос многократно, и по окончании проект был признан не достигшим определенных целей – считать ли этот проект провалом и для заказчика, и для исполнителя?

Мы к этому относимся так: если заказчик систему использует, для нас это успешный проект. Да, он, естественно, может быть с разными показателями: убыток, не убыток, не та прибыль, но если система используется, мы считаем внутри компании, что проект успешный.

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

Мы запускаем множество проектов по разным системам, в которых должны быть задействованы разные службы холдинга. Но у нас не получилось подготовить для них какой-то единый формат опросника, чтобы сразу при старте проекта можно было ввести туда все возможные риски. Чтобы представители разных служб подписали этот документ и взяли на себя часть ответственности, что есть риск в том, том и в том. Если руководитель службы подпишется за эти риски, нам будет легче внедрять. Есть ли у вас какой-то определенный шаблон опросника, с которым вы работаете?

Если вы не видите часть рисков, значит их пока нет в вашей области управления. Количество рисков нарастает по ходу проекта и по ходу получения опыта на других проектах и т.д.

Если наоборот, вы видите очевидный риск, но бизнес-заказчик с ним не согласен, я бы аккуратно шел в такой проект, потому что заказчик, видимо, не очень понимает, зачем ему система.

Но заказчик действительно в 95% проектов не понимает, зачем ему система.

Ну а тогда зачем?

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.