[Из песочницы] Идеальное внедрение ERP или управляемый взрыв
В данной статье я хотел бы поделиться своим опытом работы внедрения ERP-систем на больших проектах. Статья была написана в 2013 году в момент внедрения большого проекта на 1С, так сказать по горячим следам.
Вступление: два вида клиентов
Обычно внедрение новой программы бывает в двух случаях:
1. Когда компания еще не вела учет в специальной программе, а работали только в Экселе
2. Когда вела учет в старых программах, из которых уже выросла — база стала тормозить, не возможно развить функциональность, нестабильная работа и прочее.
В первом случае компании имеют небольшой штат сотрудников и объем внедрения небольшой. Компания только перешагнула через критическую точку объема информации, когда требуется какая либо система учета. Ручной режим в Экселе больше не устраивает руководство.
Плюсы таких клиентов — не нужно думать о старом функционале системы и перегрузки справочников и остатков, ибо ее просто нет. Достаточно прост сам запуск — после создания программы (конфигурации 1С), можно просто начать всем пользователям работать — в случае каких либо проблем в программе в виде отсутствия предусмотренной функциональности работа компании не останавливается, т.к. пользователи всегда могут продолжить работать по старинке — вручную или в Экселе, пока программисты допиливают программу 1С.
Минусы: требуется обучение пользователей работе в 1С, загрузки данных из Экселя. Например был у меня клиент, у которого пользователи были избалованы разнообразием печатных форм в Экселе (практически для каждого заказчика своя, причем, разная для разных его филиалов), поэтому они требовали сделать такую же поддержку в 1С. Необходим большой административный ресурс для того чтобы унифицировать формы, а также сдвинуть внедрение с мертвой точки: пользователи начали обучаться, пользователи начали выполнять новую непривычную для них работу, например, поддержку справочников контрагентов и номенклатуры в актуальном состоянии.
Во втором случае это переход со старых систем, например, программы 1С 7-й версии или другие устаревшие программы, которые не отвечают современным требованиям, например у меня был клиент с программой RS-Balance 3.16, которая жутко тормозила.
Обычно это клиенты с большим числом рабочих мест — более 100, у них уже ведется учет на старой системе, поэтому вначале нужно перенести старые бизнес-процессы на новые рельсы (на новую платформу 1С 8), так чтобы деятельность компании ни на минуту не остановилась, а уже потом дорабатывать бизнес процессы. Есть два способа выполнить начальный запуск: методом большого взрыва — когда вся компания переходит на новую программу и методом встраивания отдельных рабочих мест — перевод выполняется по отдельным пользователям, при этом между системами выполняется двухсторонняя синхронизация данных. Данные введенные в одной системы тут же попадают в другую систему, в итоге пол-фирмы может работать в одной программе, а оставшаяся часть другой. Этот способ внедрения наиболее удобный и безопасный с точки зрения сохранения деятельности компании, но он самый технически сложный для исполнителя. Но оказалось возможным для перехода с таких программ как 1С 7.7 и RS-Balance.
Идеальное внедрение
Это такое внедрение, когда руководство узнает об окончании внедрения после того как ему приносят на подпись акт о выполненных работах. Т.е. полное отсутствие трений между исполнителем и сотрудниками заказчика.
Сотрудники заказчика работают с 9 до 18, они работаю в привычном своем русле заданий: они не хотят напрягать мозги — выполнять новую работу или обучаться, они не хотят иметь проблемы с начальством если сбоит программа и из-за этого не могут выполнить свои обязанности, например из-за недоработок программы товар не отгружается со склада. Идеальный случай — это повторение старого интерфейса программы (тогда сотруднику не придется обучаться новому) и создание двухсторонней синхронизации данных (в случае сбоя в новой программе пользователи не останавливаясь продолжают работать в старой программе)
В данной статье я буду всячески агитировать за использование двухсторонней синхронизации данных, т.к. это позволяет избежать множества ошибок и обеспечить быстрое внедрение новой программы с малой кровью.
Один из аргументов — это при таком подходе автоматическая реализация принципа «ничего не забыть», дело в том что в момент создания обработок переноса данных выполняется скрупулезное изучение структуры данных старой программы. Изучается реквизит за реквизитом, таблица за таблицей. Уже на этапе разработки задаются вопросы пользователям старой программы о значении тех или иных данных. Причем вопросы задаются обо всех 100% данных старой программы, поэтому вероятность пропуска чего то важного крайне мала, но даже если такое случится то мы всегда можем временно перевести блока из новой программы в старую путем нажатия одной кнопки.
Управляемый взрыв
Как это делается
Создается механизм регистрации изменений объектов (например: для 1С 8 подойдет встроенных механизм регистрации или можно использовать механизм подписки на события, для 1С 7 версии используется внешняя компонента Мигратор 1С, для RS-Balance используются пользовательские макросы переопределяющие стандартные методы записи справочников и документов «Update» и «UpdateDoc»).
В 1С 8 создается обработка умеющая выгружать и загружать измененные объекты между программами. Помимо прочего она должна иметь специальный монитор корректности переноса данных. Проблемы переноса данных должны отображаться в специальной таблице, где ошибки связанные с только неудачными транзакциями должны автоматически обрабатываться при следующий сеансах обмена, а ошибки требующий вмешательства программиста (например неверные сценарии перелива данных) — исправляться вручную программистом (сначала правится код обработки обмена, а потом вручную инициируется обмен).
Создается механизм прав для пользователей определяющий в какой программе они могут работать. Далее установкой прав задается работа каждого пользователя в той или иной программе.
Что мы узнали
Оказывается что основная продуктивная работа ведется тогда, когда программа начинает внедряться и ей начинают пользоваться люди. В в этом момент появляется такое количество заданий, которое не в состоянии быстро выполнить команда внедренцев. Оказывается что на этапе обследования не было учтено миллион вещей, про которые одни не знали, а другие не вспоминали. Например, нужно было сделать еще один документ учета брака, предусмотреть отдельный документооборот, сделать отчеты, статусы и прочее, прочее… Поэтому чтобы учесть все факторы — все бизнес-процессы, нужно создавать регулируемый процесс внедрения по одному рабочему месту за раз, создавать локальный взрыв мозга в рамках одного рабочего места, в рамках работы с одним человеком. Внедрив программу на одном рабочем месте, переходить к другому.
Вместо эпилога: парадокс внедрения управляемым взрывом
Большие компании (от 100 автоматизированных рабочих мест) переходят на новую систему в том случае если старая система их не устраивает. Это очевидно. Но почему их не устраивает? Потому что нет людей которые могут контролировать внутренности системы — либо произошла ротация программистов, либо изначальна была выбрана слабая платформа, которая не справляется с большой нагрузкой, либо создано такой набор заплаток, что проще перейти на новую систему, чем пытаться разобраться в существующей. Зачастую присутствуют все перечисленный причины. Развитие существующей системы зашло в тупик, т.е. как сейчас говорят — программа больше не удовлетворяет потребности бизнеса.
Для того чтобы перейти на новую систему методом управляемого взрыва, т.е. последовательно по одному рабочему месту, нужно детально разбираться в обоих системах. Все это нужно чтобы настроить полноценный информационный обмен между двумя системами на переходный период времени. Иначе ничего не получится. Но как только вы начинаете разбираться в старой системе и полностью начинаете понимать механизмы работы, то получается, что появляется тот человек, который может контролировать существующую старую систему и получается что уже нет острой необходимости переходить на новую систему.
Пожалуй, парадокс объясняется тем, что таких людей которые могут разобраться в недокументированном хаосе информации не так много. С ней не справятся специалисты занимающиеся только поддержкой системы. Очень важный момент в том, что тут требуется особая мотивация которая заставит выполнить титаническую работу, т.к. эта работа не благодарна, ее основная масса скрыта под водой — эту работу можно увидеть только как результат перехода на новую программу.
