UPD: меня обвинили в плагиате, поэтому я вынуждена изменить название статьи. В самой статье изменений не произошло.
Дисклеймер: пост не претендует на объективность. Исключительно субъективное мнение на основании не слишком большого опыта внедрения ERP на стороне клиента. В статье описаны некоторые действия, которые желательно сделать до заключения контракта на внедрение ERP-системы.
Что такое «консалтинг»?
Предлагаю для начала определиться с терминологией.
Мне кажется при внедрении ERP представители бизнеса несколько по-иному понимают понятие «услуги консалтинга», чем представители компании-исполнителя. Давайте попробуем внести ясность. Определение из Википедии:
«Консалтинг (консультирование) — деятельность по консультированию руководителей, управленцев по широкому кругу вопросов в сфере финансовой, коммерческой, юридической, технологической, технической, экспертной деятельности. Цель консалтинга — помочь системе управления (менеджменту) в достижении заявленных целей.»
Так вот, цель проекта – внедрение ERP-системы. Именно это прописывается в договоре с исполнителем. В рамках проекта внедрения консультанты НЕ будут выполнять аудит и реинжиниринг бизнес-процессов как таковых.
В рамках проекта внедрения ERP консультанты выполняют анализ существующих процессов и пожеланий пользователей для их корректного отражения в новой системе, не более того. Операции, выполнение которых планируется вне системы, вообще выпадают из зоны их внимания.
Как правило, всесторонний аудит процессов с целью достижения определенных бизнес-показателей (например, сокращение товарных остатков, сокращение времени поставки клиенту) выполняют консалтинговые компании другого профиля по отдельному договору и за отдельные деньги.
Действительно, при внедрении ERP происходит «оптимизация…, повышение…, минимизация…» бизнес-показателей, но это происходит только, если выполняется хотя бы один из пунктов ниже:
- автоматизируются процессы, ранее выполняемые вручную или не исполняемые вовсе;
- заказчик четко понимает, какую новую логику/структуру/наполнение он хочет заложить в процессы новой системы и какой выигрыш планирует получить от этого. Другими словами, заказчик сам (или с помощью сторонних компаний) провел аудит бизнес-процессов с целью оптимизации бизнес-показателей и у него есть желание отразить полученные рекомендации во внедряемой ERP системе;
- стандартные процессы внедряемой системы устроены на порядок лучше, чем текущие процессы заказчика. И заказчик готов подстраиваться под эти процессы;
Если в процессе внедрения будет простое переложение процессов из имеющихся систем в новую ERP без существенных изменений в логике – не нужно ждать прорывных улучшений по бизнес-показателям. Т.е. предлагаю не путать консалтинг непосредственно бизнес-процессов и консалтинг процессов при внедрении ERP-системы. Впрочем, иногда консультанты и при внедрении ERP предлагают красивые нетривиальные решения для бизнес-задач, но это все-таки больше исключение, чем правило на проектах внедрения.
Что нужно сделать ДО заключения договора с консалтинговой компанией
- Сформулировать цель проекта и донести ее до всех представителей бизнеса, кто будет причастен к проекту. Вот только не надо обтекаемых формулировок типа «повышение эффективности деятельности предприятия за счет внедрения ERP». Пусть эти эпистолярные упражнения остаются на откуп внедренцам, уж что-что, а составлять такие формулировки для договора они умеют все: не каждый проект по внедрению ERP успешен, но для каждого проекта еще в самом начале декларируются красивые цели, достижение которых не всегда можно однозначно замерить при завершении проекта.
Нужно простыми словами пояснить и бизнесу, и компании-исполнителю зачем необходима ERP–система. Ведь что-то же сподвигло рассматривать вопрос о ее внедрении? Что именно? Зачем? Необходимо сформулировать эту мысль и изложить на бумаге.
На предприятии все должны понимать для чего внедряется новая система, какие улучшения она должна принести на предприятие, насколько сильно изменения коснутся конкретных подразделений бизнеса.
В этом случае бизнес будет понимать ради чего вся эта свистопляска с дополнительной нагрузкой в виде общения с консультантами, изучения толстых документов с непонятной терминологией, необходимости изучения нового софта и т.д. Особенно это актуально для подразделений, в чьей работе не предвидится каких-либо кардинальных изменений и для них смена самописки на промышленную систему выглядит как мена шила на мыло. На одних только вопросах и стенаниях консультантам типа «А зачем вы внедряете нам свою систему?», «А нас всех уволят после внедрения вашей системы?», «У нас все хорошо работает, не надо нам ни чего внедрять!» и т.д. можно сэкономить значительное количество дорогого консультантского времени.
Изначально сформулированная цель будет полезна и исполнителю. Это поможет консультантам понять вектор, в направлении которого заказчик желает развиваться, применять «правильные» критерии при выборе конкретного варианта решения задач из нескольких возможных, упростит налаживание продуктивных контактов с пользователями.
- Составить перечень необходимой функциональности к новой системе. Как правило, эта работа выполняется во время подготовки договора на внедрение консультантами, но на мой взгляд, клиенту это лучше начать делать самостоятельно еще до начала общения с потенциальными исполнителями. В наших реалиях ситуации бывают разные, может проект инициироваться на дружеской вечеринке ТОПов с фразы «Нам тут производство нужно автоматизировать. Возьметесь?». И даже хлопнут по рукам, а потом линейные сотрудники компании интегратора осознают, что заказчик под автоматизацией производства понимал «не совсем» производство в ERP, а что-то из списка ниже:
- Интеграцию производственного оборудования с ИС. При чем в качестве управляющей системы заказчик подразумевает имеющуюся самописную систему;
- Позаказный учет затрат на производстве;
- Автоматическое формирование последовательности производственных заказов с учетом имеющихся ограничений;
- Планирование производства на длительный горизонт на основе плана продаж (который тоже нужно автоматизировать в новой системе. А разве это не само собой разумеющееся?) с возможностью варьировать параметры и выбирать наиболее оптимальный план производства.
Это не всякому IT-специалисту понятно, что не все вышеперечисленные задачи решаются в ERP-системе, но откуда это знать директору производственного предприятия, отлично разбирающемуся в производстве и продажах ТНП, но далекого от IT? Надеюсь вашей фантазии хватит для того, чтобы представить насколько анекдотично развиваются такие ситуации в реальности: ни кто же не возьмется вслух сказать, что ТОПы не правы (один в постановке задачи, другой в ее оценке).
Поэтому перечень требований к функциональности системы:
- способствует взаимопониманию между заказчиком и исполнителем;
- позволяет исполнителю сделать более точный расчет по цене и срокам;
- сокращает время подготовки договора со стороны исполнителя: эти требования могу стать основой для раздела «Функциональный объем проекта» в договоре;
- позволяет осознать свою долю ответственности за проект владельцам бизнес-процессов. По моему мнению, внутренние IT-специалисты компании могут и должны привлекаться к этой работе, но ответственность за полноту первоначального списка, как и за полноту «Функционального объема проекта» в договоре должна лежать именно на владельцах бизнес-процессов.
Еще важно, чтобы в этих требованиях было указано что должна делать система, но не нужно описывать как это должна делать система. Определить и описать каким образом в новой системе будут реализовываться процессы – это уже полностью задача консультантов. И совершенно не факт, что процессы в новой системе будут выглядеть так, как их на начальном этапе представляет бизнес.
- Попросить референс-визит. Вряд ли получится организовать референс-визит в компанию конкурента, а вот в компанию совершенно из другой отрасли – вполне возможно. Можно заранее проанализировать, какие процессы могут быть похожи и уделить им особое внимание, отсекая работы, совершенно не релевантные. Например, если у вас производство бытовой химии, вряд ли вам хоть чем-то поможет референс на машиностроительное производство (хотя в части HR – как знать), но при визите на предприятие пищевой промышленности уже можно почерпнуть что-то полезное, например, в продажах, отгрузках, в работе с дебиторкой.
Альтернатива референсу — демонстрация каких-либо важных процессов в уже настроенной системе. У компании-интегратора могут быть свои учебные и/или тестовые базы, на которых они могут продемонстрировать какие-либо типовые процессы.
Даже если будут показаны / продемонстрированы процессы, совершенно не пригодный для использования на проекте, но при этом у заказчика появятся более конкретные вопросы относительно реализации, и он получит исчерпывающие ответы на эти вопросы – это не будет бесполезной тратой времени.
- Оценить различные варианты внедрения системы – поэтапный и «все сразу».
При сравнении стоит обратить внимание на следующие моменты:- Объем и сложность интеграции. Абсолютно понятно, что поэтапный вариант имеет больший объем интеграции за счет временных интерфейсов. И сравнивать по этому критерию «большой взрыв» и «слона, разделанного на кусочки» бессмысленно, результат известен априори. Имеет смысл сравнивать между собой несколько вариантов поэтапного внедрения. Возможно, по этому параметру можно найти более оптимальный вариант, чем тот, который кажется очевидным при первом взгляде на процессы предприятия. Для проработки этого вопроса желательно привлечь эксперта со знанием архитектуры внедряемой системы и знатока существующих IT-систем предприятия.
- Необходимость модернизации старой / развертывание новой инфраструктуры. Для организации инфраструктуры, соответствующей потребностям проекта, необходимы время и деньги. При разных вариантах внедрения – разное количество времени и денег. Инфраструктура — из самых очевидных задач, сопутствующих проекту внедрения. Но удивляет количество случаев, когда ей не устанавливают должного приоритета, а то и просто забывают.
- Планы предприятия на естественное развитие, например, ввод в эксплуатацию новых складов, закупка нового оборудования, выход на новые рынки. Необходимо проанализировать, каким образом эти планы накладываются планы по внедрению системы и как эти планы влияют друг на друга.
Надеюсь, что моя статья уменьшит количество вопросов «А что, и так можно было?» на чьем-либо проекте.
Автор: pebble
