Что нужно знать для предсказуемого внедрения 1С:ERP с гарантированным результатом?
Лисин Н. Г.
Для начала немного философии. Попробуем, без лишней “заумности”, разобраться в невероятных сложностях внедрения систем ERP, и каким образом эти сложности преодолеть.
Много говорят о том, что при внедрении ERP-класса недостаточно просто разработать Техническое задание (ТЗ), как это делается при внедрении систем учета хозопераций, а надо детально обследовать автоматизируемые бизнес-процессы предприятия, очень глубоко “встроиться” в жизнь пользователей и предприятия, выполнить моделирование бизнес-процессов в ERP-системе вместе с Заказчиком, двигаться итерациями в виде тестовых эксплуатаций с выявлением реальных, а не вымышленных требований…
Все это так. Но мы попробуем копнуть глубже.
В последнее время иногда встречаются нарекания к внедрению систем ERP. Что они не оправдывают возлагаемых на них надежд, проекты внедрения не окупаются, система создается ради самой себя и только усложняет работу персонала, что проще внедрять отдельные программы решающие конкретные задачи и так далее.
Так почему же благие намерения при внедрение ERP-системы могут оказаться неоправданной тратой денег? Почему внедрение обычных учетных систем, например, в бухгалтерии и на складе, обычно дает ожидаемый результат, но с ERP возникают какие-то мистические проблемы? Виновата сложность функционала ERP, недостаточная методическая проработка в предлагаемых ERP-системах или что-то другое?
Почему ERP сложнее внедрить чем учетную систему? Две проблемы
ERP – это не просто учетная система. Это система управления.
Система управления моделирует оперативную деятельность и взаимоотношения между сотрудниками, а также поддерживает оперативное принятие решений на основе получаемой информации.
Отсюда уже видно, насколько сложнее, по сравнению с учетной системой:
А) обеспечить функциональность ERP, соответствующую всем тонкостям работы предприятия – чтобы она облегчала работу сотрудников, повышала качество и скорость процессов, а не стала обузой, усложняющей работу;
Б) встроить ERP-программу в работу компании. Можно сказать, что внедрение ERP-это имплантация новой нервной системы в живой организм – предприятие.
Проблема № 1. Сложность определения оптимального функционала
Почему так сложно определить именно тот ERP-функционал, который будет оптимален для данного предприятия?
Все знают аксиому: «Практика – критерий истины». Что это значит в случае внедрения ERP-системы?
Это значит что никакие теоретические изыскания и моделирование, разговоры с пользователями, анализ их пожеланий, и постановки задач и так далее, не позволят написать ТЗ для настройки ERP-системы «под ключ». Нельзя подходить к ТЗ на ERP как к архитектурному проекту строительства, по которому можно качественно построить дом в соответствии со всеми требованиями.
Причина проста: архитектурный проект описывает целевой материальный объект, а ТЗ ERP описывает деятельность людей, во взаимосвязи различных событий и ситуаций.
Деятельность людей намного более многогранная и содержит множество нюансов.
– Материальный объект проще описать, представить заказчику во всех разрезах и свойствах, поскольку он статичен, а требования конечны. Дом не меняется с течением времени и имеет три измерения.
– Деятельность людей динамична, процесс разворачивается в четвертом измерении – времени…
Математики в таком случае говорят, что задача имеет “большую размерность”.
Какие следствия из этого утверждения?
Самое важное: понять как должна работать ERP-система на данном предприятии, можно только заставив пользователей начать в ней работать. Работать в прототипе, типовом тиражном решении, в котором есть более-менее приближенная к предприятию модель бизнес-процессов.
Самый простой пример: Понять где жмут новые ботинки можно только тогда, когда начинаешь в них ходить. Даже примерка в магазине не выявляет всех потенциальных проблем.
Надежды все расчертить, продумать, расписать в ТЗ, запрограммировать и получить в красивой обертке готовый работающий продукт – нереалистичны.
Вспомним старые картинки о выполнении проектов. Этот комикс любят вешать ИТ-шники в своих кабинетах. Наверное, таким образом они ищут оправдание в глазах пользователей :)
Видим, что проблема налицо, но мы постарались показать выше глубинные и объективные причины такого развития событий. Комикс не о бестолковости заказчика и разработчика, как можно подумать… Ничего таинственного! Просто ни заказчик, ни разработчик ни разу в жизни не видели качели. И вот к чему пришли в результате: качели в итоге получились, но не вполне удобные! Очевидно, что если бы сразу стали вешать веревки, прилаживать доски и пробовать конструкцию в деле, то результат получился бы куда лучше.
Со временем к вендорам и интеграторам начало приходить абсолютное понимание, как наиболее быстро и с наименьшими затратами создать и запустить ERP-систему. Этот подход, как было сказано выше, есть ни что иное, как «Доводка системы в процессе ее эксплуатации».
Вот веселый видеролик “Если бы программисты строили самолеты”:
Наглядно, не правда ли?
В мире 1С такие подходы называются «Технология быстрого внедрения», «Технология быстрого результата» и тому подобные.
Уже многие компании заявляют свое конкурентное преимущество:
«Пока наши конкуренты 3 месяца пишут ТЗ, мы за это время уже начинаем работать в типовом решении и выдаем первые результаты, дорабатываем на практике. А в ТЗ все предусмотреть нельзя».
Наши рекомендации
Итак, вопрос ставится так – что лучше:
А) обследовать процессы, моделировать, разрабатывать ТЗ?
Б) или сразу “бросаться в бой” пользуясь типовым функционалом?
По нашему мнению, однозначного рецепта на все случаи – нет. Более подробно об этом будет рассказано чуть ниже, здесь же дадим общие рекомендации.
Для большого предприятия со сложными и специфичными процессами, большим количеством пользователей и отделов, широким охватом процессов в автоматизированной системе – попытка сразу использовать типовой функционал неминуемо вызовет отторжение новой системы пользователями. Особенно, если пользователи привыкли к старой системе. Выяснится, что новая система в имеющемся виде вообще непригодна.
В этом случае, необходимо предварительная адаптация системы на основе тщательного моделирования бизнес-процессов и самыми необходимыми доработками, которые видны уже на этом этапе. И только потом – внедрение и выявление на практике окончательных требований к системе, в процессе опытной эксплуатации.
Это наш классический подход к выполнению больших проектов.
О проектной технологии компании ИТРП (полный проектный) цикл можно прочитать здесь>>>
Для небольшого предприятия, с несложными или достаточно типовыми поцессами, подлежащими автоматизации, попытка сразу использовать типовое решение, действительно может быстро выявить на практике необходимые доработки, и тем самым значительно сократить бюджет проекта. Более того, в нашей практике были случаи, когда типовой функционал вообще не потребовал доработок!
Проблема № 2. Имплантация системы в переменчивую среду
Теперь рассмотрим вопрос – почему так сложно встроить ERP в процессы компании, в отличие, например, от блока регламентированного учета?
Начнем с того, что система учета и система управления – это разные системы.
• Система учета – фиксирует прошедшие события.
• Система управления – фиксирует не только прошедшие, но и будущие события.
Прошлое – фиксировано, будущее переменчиво!
Регистрировать в системе будущие события намного сложнее. Потому что любое будущее событие, регистрируемое в системе, с некой вероятностью может быть пересмотрено и изменено. А у любого события есть следствия – зависимые события!
Соответственно, если изменяется “начальное” событие – то нужно внести изменения во все зависимые события.
Элементарный пример: Принят заказ клиента, соответственно, сформирован заказ производству, под требуемые материалы сформирован заказ поставщику и согласован с поставщиком, выставлен счет клиенту, введена заявка на оплату поставщику, которая запущена по цепочке согласования… А теперь представим, что заказ клиента скорректирован. Система должна уметь в соответствии с изменением заказа – перестроить всю эту цепочку. Автоматически или вручную – это отдельный вопрос. Главное – результат.
В системе управления, данные введенные в систему одним пользователем, через минуту становятся основой принятия решений другим пользователем, и это решение фиксируется в виде какого-то документа (других введенных данных). Этот документ может оказаться исходным для ввода последующего документа и так далее. Таких цепочек может быть достаточно много.
Тронем одно звено – развалится вся цепочка!
Цепочки в системе управления должны работать и перестраиваться в режиме реального времени. Потому что будущее всегда корректируется, принятые решения могут меняться, и документы содержащие данные о будущих событиях могут корректироваться.
А теперь ответим на вопрос – корректируется ли прошлое (данные учета)? Например, фактически выполненная хозоперация оприходования на склад товара. Ответ очевиден: да! Но только если нужно исправить ошибку ввода. Поскольку прошлое фиксировано, его нельзя изменить, а можно только правильно учесть…
Именно в этом состоит тайная причина сложности внедрение систем управления, по сравнению с системами учета!
Не зря общепринятым подходом в западных ERP системах является правило: зафиксированное событие нельзя изменить «задним числом». А только скорректировать, сторнировать другим событием (документом).
Проблема № 3. Пользователи – зло?
Еще одна сложность подстерегает при внедрении системы управления – это пользователи, не привыкшие к точному и оперативному вводу данных, не желающие мириться с возросшим объемом работы, с необходимостью учиться работе в новой системе.
Рассмотрим, в чем возможные причины саботажа пользователей и как ему противодействовать.
Кого проще научить вводить точные данные по жестким правилам в систему – бухгалтера, для которого точный учет – его профессия, или же мастера смены, учет для которого не является основной профессией, который всю жизнь выпуск продукции отражал каракулями в амбарной книге?
Кто будет больше сопротивляться и делать ошибки в уже работающей системе? У кого появится больше новых непривычных обязанностей на рабочем месте, невыполнение которых будет караться руководством? У бухгалтера или у мастера смены? Ответ очевиден.
Понятно, почему автоматизацию бухгалтерии запустить в новой системе гораздо проще, чем системы оперативного учета, планирования и управления.
Парадоксом в данном вопросе является то, что бухгалтерия чаще сопротивляется (по причине своего консерватизма и осмотрительности) новой системе в начале проекта, когда система еще не запущена, но после запуска вынуждена полностью и тщательно выполнять свои обязанности в работе в новой системе.
С другой стороны, рядовые пользователи оперативного уровня (кладовщики и операторы, мастера в производстве, менеджеры) в основном сопротивление новой системе могут оказывать после запуска системы. Причем, выражаться это может в организации параллельной работы в excel, и скрытии того факта, что данные новой системы в бизнес-процессе не используются, а ввод данных в систему превращаются в формальную обязанность, чтобы не получить нагоняй от руководства.
Новая система, таким образом, выключается из бизнес-процесса и существует в “параллельной реальности”.
Как с этим бороться? Один из методов – требовать предоставление всех отчетов, только полученных в новой системе.
Саботаж пользователей может похоронить любой проект – об этом всегда надо помнить. Поэтому, пользователи должны быть мотивированы – премированием/депремированием, удобством работы, исключением рутинных операций, повышение в должности и ЗП, возможным увольнением, если не смог освоить систему и т.д. Возможно, по каждому ключевому пользователю надо искать свой подход. Редко встречаются рядовые пользователи, с энтузиазмом включающиеся в проект.
А бывает еще, что пользователь в принципе не заинтересован в системе, поскольку его работа становится прозрачной, а он сам уже не будет незаменимым. И это самый тяжелый неизлечимый случай, т.к. саботаж будет носить подрывной, партизанский характер. Таких пользователей-заказчиков надо обязательно выявлять. В нашей практике были случаи, когда такие саботажники оказывались в рабочей группе, как функциональные заказчики!
Кроме проблем саботажа, при внедрении может возникнуть масса прочих организационных проблем. Множество пользователей разных подразделений вводят множество данных в разное время, а также исправляют их и не видят, что сейчас делают другие пользователи. Данные связаны между собой. Как сделать так, чтобы система была устойчивой к ошибкам пользователей и всевозможным корректировкам, а разные данные всегда были взаимоувязаны?
Какой должна быть схема внедрения, чтобы оно прошло наиболее безболезненно и принесло максимальную пользу?
Ответим на эти вопросы.
Технология создания и внедрения ERP-системы.
Риски проекта внедрения ERP-системы
Читаем о рисках в проектах создания ERP-систем. В том числе невыдуманная история одного проекта – как организационные сложности заказчика привели к стагнации проекта. Обязательно прочитайте – не узнаете ли свое предприятие?
[evc_social_likes]
19.05.2016
