- PVSM.RU - https://www.pvsm.ru -
UPD: меня обвинили в плагиате, поэтому я вынуждена изменить название статьи. В самой статье изменений не произошло.
Дисклеймер: пост не претендует на объективность. Исключительно субъективное мнение на основании не слишком большого опыта внедрения ERP на стороне клиента. В статье описаны некоторые действия, которые желательно сделать до заключения контракта на внедрение ERP-системы.
Предлагаю для начала определиться с терминологией.
Мне кажется при внедрении ERP представители бизнеса несколько по-иному понимают понятие «услуги консалтинга», чем представители компании-исполнителя. Давайте попробуем внести ясность. Определение из Википедии:
«Консалтинг (консультирование) — деятельность по консультированию руководителей, управленцев по широкому кругу вопросов в сфере финансовой, коммерческой, юридической, технологической, технической, экспертной деятельности. Цель консалтинга — помочь системе управления (менеджменту) в достижении заявленных целей.»
Так вот, цель проекта – внедрение ERP-системы. Именно это прописывается в договоре с исполнителем. В рамках проекта внедрения консультанты НЕ будут выполнять аудит и реинжиниринг бизнес-процессов как таковых.
В рамках проекта внедрения ERP консультанты выполняют анализ существующих процессов и пожеланий пользователей для их корректного отражения в новой системе, не более того. Операции, выполнение которых планируется вне системы, вообще выпадают из зоны их внимания.
Как правило, всесторонний аудит процессов с целью достижения определенных бизнес-показателей (например, сокращение товарных остатков, сокращение времени поставки клиенту) выполняют консалтинговые компании другого профиля по отдельному договору и за отдельные деньги.
Действительно, при внедрении ERP происходит «оптимизация…, повышение…, минимизация…» бизнес-показателей, но это происходит только, если выполняется хотя бы один из пунктов ниже:
Если в процессе внедрения будет простое переложение процессов из имеющихся систем в новую ERP без существенных изменений в логике – не нужно ждать прорывных улучшений по бизнес-показателям. Т.е. предлагаю не путать консалтинг непосредственно бизнес-процессов и консалтинг процессов при внедрении ERP-системы. Впрочем, иногда консультанты и при внедрении ERP предлагают красивые нетривиальные решения для бизнес-задач, но это все-таки больше исключение, чем правило на проектах внедрения.
Нужно простыми словами пояснить и бизнесу, и компании-исполнителю зачем необходима ERP–система. Ведь что-то же сподвигло рассматривать вопрос о ее внедрении? Что именно? Зачем? Необходимо сформулировать эту мысль и изложить на бумаге.
На предприятии все должны понимать для чего внедряется новая система, какие улучшения она должна принести на предприятие, насколько сильно изменения коснутся конкретных подразделений бизнеса.
В этом случае бизнес будет понимать ради чего вся эта свистопляска с дополнительной нагрузкой в виде общения с консультантами, изучения толстых документов с непонятной терминологией, необходимости изучения нового софта и т.д. Особенно это актуально для подразделений, в чьей работе не предвидится каких-либо кардинальных изменений и для них смена самописки на промышленную систему выглядит как мена шила на мыло. На одних только вопросах и стенаниях консультантам типа «А зачем вы внедряете нам свою систему?», «А нас всех уволят после внедрения вашей системы?», «У нас все хорошо работает, не надо нам ни чего внедрять!» и т.д. можно сэкономить значительное количество дорогого консультантского времени.
Изначально сформулированная цель будет полезна и исполнителю. Это поможет консультантам понять вектор, в направлении которого заказчик желает развиваться, применять «правильные» критерии при выборе конкретного варианта решения задач из нескольких возможных, упростит налаживание продуктивных контактов с пользователями.
Это не всякому IT-специалисту понятно, что не все вышеперечисленные задачи решаются в ERP-системе, но откуда это знать директору производственного предприятия, отлично разбирающемуся в производстве и продажах ТНП, но далекого от IT? Надеюсь вашей фантазии хватит для того, чтобы представить насколько анекдотично развиваются такие ситуации в реальности: ни кто же не возьмется вслух сказать, что ТОПы не правы (один в постановке задачи, другой в ее оценке).
Поэтому перечень требований к функциональности системы:
Еще важно, чтобы в этих требованиях было указано что должна делать система, но не нужно описывать как это должна делать система. Определить и описать каким образом в новой системе будут реализовываться процессы – это уже полностью задача консультантов. И совершенно не факт, что процессы в новой системе будут выглядеть так, как их на начальном этапе представляет бизнес.
Альтернатива референсу — демонстрация каких-либо важных процессов в уже настроенной системе. У компании-интегратора могут быть свои учебные и/или тестовые базы, на которых они могут продемонстрировать какие-либо типовые процессы.
Даже если будут показаны / продемонстрированы процессы, совершенно не пригодный для использования на проекте, но при этом у заказчика появятся более конкретные вопросы относительно реализации, и он получит исчерпывающие ответы на эти вопросы – это не будет бесполезной тратой времени.
Надеюсь, что моя статья уменьшит количество вопросов «А что, и так можно было?» на чьем-либо проекте.
Автор: pebble
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/erp/261624
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/334826/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.