8 (800) 500-61-51

8 (495) 600-61-81


Что нужно знать для предсказуемого внедрения 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-систем. В том числе невыдуманная история одного проекта — как организационные сложности заказчика привели к стагнации проекта. Обязательно прочитайте — не узнаете ли свое предприятие?

Читать далее>>>



Нет времени читать? Нажмите на кнопку и сохраните у себя статью:

Проекты и решения на 1С для производства

1С:ERP, 1C:УПП, 1С:MES, 1C:ТОИР

Заказать демонстрацию

Предсказуемое внедрение.
Гарантированный результат.
Выверенные технологии внедрения.

Подробнее

Ближайшие вебинары, курсы, конференции

Получайте расписание новых мероприятий на свою электронную почту

Подписаться

Обсудите вашу задачу с нашим специалистом

Сможем ли мы решить именно вашу задачу? Сколько это будет стоить? Сколько времени займет проект?
Оставить заявку
youtube.complus.google.comvk.com
-->