Как внедрять ERP на предприятии?

Ну вот, уже кажется разрешение внедряться есть, и НСИ в PLM созревает, и ERP систему выбрали, и пора бы начать, НО следующая проблема – как? Что сделать в первую очередь? Выпустить приказ о начале внедрения на предприятии? Просто послать бригаду ИТшников в подразделения, где собрались внедряться? Срочно закупать технику? Или что-то ещё…

Чуть позже, уже с началом внедрения Вы начинаете понимать, что на самом деле было бы неплохо сделать уже тогда, когда ещё процесс внедрения не закрутился.

Предыдущая статья: Внедрение ERP на предприятии. Ресурсы.

Команда ИТ службы.

Как правило, на крупных и средних предприятиях, решившихся на внедрение ERP, уже есть ИТ отдел или даже несколько, независимых друг от друга. Есть также какая-то система, или ряд АРМов, уже работающих на предприятии.

Всё это наследство подлежит серьезной трансформации перед внедрением – во многом очень болезненной трансформации.

Для начала Вам придется провести слияние ИТ подразделений предприятия под единое ИТшное начало. Это решит сразу несколько задач:

1. концентрация ресурсов перед крупным внедрением;
2. систематизация и оптимизация имеющихся ИТ ресурсов + полная оценка состояния ИТ инфраструктуры;
3. снятие сопротивления от смежных ИТ структур, не участвующих напрямую во внедрении.

Далее Вам предстоит провести разделение сотрудников по планируемой степени вовлеченности в работы в новой системе:

1. минимальное вовлечение – как правило, это персонал, обладающий значительным опытом и знаниями по текущим задачам и существующим на предприятии процессам. Их участие в адаптации ИТ персонала и подготовке данных текущих систем для миграции в новую систему будет НАИБОЛЬШИМ среди всех участников процесса, но к задачам именно в новой системе они будут привлечены меньше всего;
2. средний уровень вовлеченности – чаще всего это чистые программисты, люди, которые не занимаются оптимизацией бизнес-процессов напрямую, и не участвуют в построении логики именно процессов целиком, а не отдельно взятых сеансов или отчетов. На крупных предприятиях таких специалистов ещё очень и очень много, хотя частный бизнес явно показывает, что ИТшник, глубоко не владеющий какой-то предметной областью в серьезных задачах может использоваться только на короткий промежуток времени и требует особого внимания со стороны разработчиков с постоянными пояснениями, что и как надо, чтобы было увязано. При внедрении ERP на этих людей ложиться большая часть работы по кодированию миграции между системами, глубокого изучения языка программирования новой ERP и частичной доработки сеансов ERP системы. На самом деле на них ляжет очень ответственная часть работы и общаться им придется со всеми категориями участников процесса, кроме внешних служб, НО задачи они будут решать довольно узкие;
3. максимально вовлеченные – в эту категорию чаще всего попадают программисты-предметники, архитекторы-программисты, чистые предметники, архитекторы. Да именно в такой последовательности, потому что, к сожалению, даже классный архитектор без знаний хотя бы основ программирования - иногда чистое зло, как и просто разработчик-предметник. В силу неумения писать код, а следовательно непонимания как работает машина и что на самом деле можно выжать из кода системы и какой ценой, они порой придумывают идеальные бизнес-процессы, реализация которых настолько сложна в системе, что число ограничений при этом просто ломают всю задачу, а порой их вообще несет в фантазиях… Тем не менее, именно эта категория ИТ специалистов будет наиболее вовлеченной в процесс, потому что именно на их плечи ляжет и построение модели миграции на стороне ERP, и глубокое погружение в функциональность ERP, и в процессы предприятия, и в код ERP, и именно эти люди будут определять объем изменений в ERP и в бизнес-процессах предприятия.

Если не провести эту работу, скорее всего:

• получите людей и руководителей низкого уровня, занимающихся пересекающимися функциями;
• часть людей (не важно с каких позиций – рядовые сотрудники или руководители) из ИТ, наиболее агрессивно сопротивляющихся переменам, уйдут, и, к сожалению, чаще всего это люди с наибольшим опытом.

Необходимо отметить, что в России используются как минимум ещё две модели подбора и распределения функций в команде ИТ при внедрении крупных систем.

1. Аутсорсинг

Весь коллектив средней и максимальной вовлеченности находится на аутсорсе. Он может быть выведен до или во время внедрения, а может быть внешней компанией холдинга, как это происходит в Росатоме. Модель доказала свою жизнеспособность, о чем можно судить хотя бы потому, что продолжает существовать уже несколько лет.

Логика внедрения – ИТ специалисты проводят на каких-то предприятиях отрасли внедрение по классической схеме. В процессе внедрения ведут доработки системы, разрабатывают документы по описанию конкретных бизнес-процессов и бизнес-правил. Как только, по мнению руководства, стадия внедрения переходит в состояние стабильной работы (промышленной эксплуатации), выработанное решение масштабируется.

Этапы масштабирования:

• команда аутсорсеров присылает на предприятие версию системы для установки;
• админами предприятия, при поддержке аутсорс команды, развертывается система;
• каждый сотрудник предприятия получает доступ к видеоурокам для самоподготовки по системе в соответствие со своими функциями;
• проводится удаленное тестирование персонала, не прошедшие тесты не допускаются до работы в системе, остальных подключают к промышленной базе;
• при возникновении вопросов, сотрудники пишут письма с описанием проблем в свободной форме и ожидают пояснений или доработок системы;
• сотрудники ауторс компании практически не бывают на предприятии весь период реализации проекта.

Плюсы такого подхода:

• внедрение идет быстро и без какого-либо явного сопротивления со стороны сотрудников и руководства предприятия;
• качество внедрения зависит от уровня проработки системы и сложности автоматизируемых задач, чем проще задача – тем качественнее внедрение.

Риски:

• при внедрении никак не учитывается эффект от масштаба;
• при внедрении никак не учитывается специфика и устоявшаяся организация на предприятии, словно все предприятия одинаковые как гвозди.

2. Варяги

Эта модель в разных отраслях и на задачах разного масштаба стала встречаться в стране всё чаще. Большая (сильно доминирующая) часть сотрудников ИТ службы являются нанятыми до внедрения и возможно только на внедрение сотрудниками со всей страны. Внедрение идет по классической схеме, но с особенностями:

• внедрение сопровождается большим числом увольнений и заменой людей на разных должностях, включая ТОП менеджеров и даже генерального директора;
• в большинстве случаев процессы на предприятии ломаются под систему или предыдущий опыт нанятых извне специалистов;
• как правило, на начальных стадиях (первые 2 года) внедрение ведется в очень сжатые сроки, с огромной динамикой, что, безусловно, сказывается и на числе ошибок и на качестве не лучшим образом.

Плюсы такого подхода:

• практически мгновенное приобретение огромного опыта в лице найма носителей этого опыта;
• приобретенное лояльное отношение многих ИТ структур поставщиков ПО и оборудования, поскольку чаще всего эти самые лучшие кадры забираются именно из таких частных структур;
• опыт нанятых сотрудников позволяет избегать очевидных ошибок при внедрении.

Риски:

• необходимость иметь огромный гарантированный бюджет как минимум на ближайшие 5 лет, поскольку нанимаются лучшие по специализации. Вы сами можете прикинуть за какие деньги поедет, например проф Java-предметник или архитектор из Москвы пусть даже в областной центр, но значительно дальше МКАДа;
• много «звёзд» в одной команде и по одному направлению очень часто не могут договориться между собой – нужен грамотный и продуманный подбор варягов, и тут встает вопрос – «а судьи кто?»;
• варяги идут к эффективности по принципу «лес рубят щепки летят», часто не обращая внимания, что размеры щеп сильно похожи на габариты тех самых деревьев. Именно по этой причине, сотрудники предприятий, где происходят внедрения по такой модели, называют варягов – «люди без Флага и Родины».

Выбор модели работы всегда остается за предприятием, если только его не «взял под крыло» какой-нибудь холдинг :)

На самом деле современный уровень развития городской и международной ИТ инфраструктуры, а также европейский опыт  дают все основания полагать, что уже очень скоро на российском рынке появятся новые модели организации команд для внедрения, симбиозы из озвученных выше, а возможно и совсем новые.

Команды в подразделениях.

В каком бы подразделении или подразделениях Вы не начали внедрение системы, Вы должны подготовить:

• ответственного за внедрение со стороны подразделения;
• команду по внедрению со стороны подразделения.

К своему огромному сожалению, я вынужден признать, что мы пошли по классической модели, которую предлагали и до сих пор предлагают консультанты и консалтеры – выбор и обучение ключевых пользователей в подразделении.

А в чем же разница между командой внедрения и командой ключевых пользователей? В принципах подбора и подготовке.

Ни одно подразделение на уровне исполнителей, да и на уровне руководителей, не желает изменений, которые проводятся не по их инициативе и их сценарию, и ERP не исключение. Возникает скрытое сопротивление, и в команду ключевых пользователей чаще всего попадают:

• специалисты подразделения, не лучше всех владеющие ситуацией по работе и функциям подразделения;
• специалисты, не имеющие права принятия решения прямо на совещании или встрече, что называется с листа.

В дальнейшем это очень усложнит работу по внедрению и будет постоянно держать высокий градус общения между ИТ и руководством подразделения.

Что мы сделали не так, и как было бы лучше?

На этапе, когда уже было очевидно, что внедрению быть – мы, ИТ специалисты, не стали для сотрудников подразделения людьми, с которыми им плыть в одной лодке.

ИТ специалисты прошли обучение функциональности системы у консультантов, а уже потом кусками и порциями выдавали знания в подразделение – язык совместного общения приобрел серьезные пробелы.

Правильными были бы следующие шаги:

1. формирование и согласование раздела ТЗ соответствующего функциям подразделения с самим подразделением и разбор всех узкий и тонких мест ТЗ, которые потребуют отдельных решений завязанных на то, как это реализовано в функциональности системы;
2. объяснять и согласовывать с руководством подразделения совместную команду ИТ специалистов и специалистов подразделений;
3. согласовать обязательное участие и возглавление команды подразделения её руководителем или замом;
4. совместная учеба функциональности системы командой ИТ специалистов и специалистов подразделений у консультантов;
5. только совместное, трехстороннее тестирование функциональности, изменений в бизнес-процессах, ЧТЗ.

Планирование работы.

Не надо рассчитывать на то, что проект станет столь популярной темой, что планы по его реализации появятся в каждом подразделении и будут выполняться и контролироваться на уровне руководства этих подразделений, а может быть и выше. Возможно, где-то чудеса и случаются, НО чаще всего всю работу по планированию и синхронизации планов реализации проекта берет на себя служба ИТ. И к этому надо быть готовым.

При внедрении у себя мы также совершили ошибку, не критичную, но…

С самого начала работа по планированию внедрения имела следующую градацию:

1. приказы и указания по предприятию с укрупнено обозначенными задачи, плановыми сроками начала и окончания работ по задаче и ответственными подразделениями за исполнение пункта;
2. очень подробные планы работ на месяц внутри ИТ службы по каждому сотруднику с указанием сколько дней каждый сотрудник должен потратить на данную задачу, в каком периоде (месяце) закончить выполнение, сколько процентов выполнения было на начало планового периода.

По первому пункту контроль только сроков осуществлялся на уровне предприятия и промежуточный контроль через совещания и оперативное общение. Однако, корректировка планов при таком подходе, крайне затруднительна, поскольку надо перевыпускать приказ или указание, а это означает зарисоваться перед руководством предприятия, что что-то идет не так – а этого, как правило, никто не хочет, в том числе и сама ИТ служба.

По второму пункту контроль три раза в неделю и ежемесячный контрольный сбор факта с отметками выполнения в процентах – перед планированием на следующий период.

Понимание того, что в планировании и контроле, что-то идет не так наступает, когда:

• вы переносите одну и туже задачу по срокам дважды и начинаете понимать, почему это случилось только после очередного переноса сроков;
• больше 20% задач получают комментарии в плане «совместно со следующими группами», и список групп, у которых в плане тоже есть такая задача, только с чуть другим названием, поскольку в этой задаче они решают свой кусок, но таким же комментарием.

К чему я всё это говорю? На многих предприятиях, описанная мной модель является классической, а на ряде - нет и месячных планов у службы ИТ. Внедрение в таких условиях очень быстро превратится в хаотичные действия, которые иногда не спасает ни квалификация консультантов, архитекторов и предметников на проекте, ни всех их вместе взятых.

Моя рекомендация – выберите и внедрите в службе ИТ систему управления проектом с иерархической структурой планирования задач. Автоматизируйте эту деятельность хотя бы в части контроля ветвей и сроков плана. Поверьте – такой план сразу покажет Вам все белые пятна, которые Вы не замечали без планирования или при плоском планировании.

Обеспечение в службе ИТ и подразделениях.

Это очень короткий, но обязательный пункт – документацией, НОВЫМИ ПК, принтерами и системой связи типа Skype,  должны быть обеспечены все сотрудники ИТ службы и сотрудники команды подразделений, в которых намечено внедрение.

При этом:

• ПК ИТ специалистов должны быть на порядок  мощнее, ПК пользователей;
• сразу приучайте пользователей к сетевым принтерам;
• ставьте ПК только на те рабочие места, непосредственная работа на которых или учеба именно этих сотрудников, начнется буквально на следующей неделе, не давайте ПК просто стоять – их обязательно найдут как использовать на рабочих местах, но это точно пойдет во вред или системе, или ИТ безопасности.

Подготовка персонала.

Чуть выше эта тема уже затрагивалась, однако,  считаю, что её необходимо выделить.

Многие полагают, что на первом этапе достаточно обучить базовой функциональности специалистов ИТ и команды подразделений. Как показывает практика – этого может достаточно, НО совместная работа становится значительно эффективнее, если:

1. учеба базовой функциональности будет проведена консультантами для совместной команды ИТ и подразделений;
2. учеба по переносу данных из старых систем в ERP будет проведена специалистами ИТ для команды подразделений;
3. учеба по языку программирования будет проведена специалистами компании внедренца ERP специалистам ИТ;
4. постоянные учебы (консультации – 2-4 часа) по выходу новых решений и регламентов по измененным бизнес-процессам будут проводиться сотрудниками ИТ для команды подразделений.

Подготовка персонала – это не задача, это процесс – постоянно действующий процесс! Только качественная и систематическая подготовка персонала позволят команде предприятия разговаривать на одном языке, находиться внутри одного процесса, одинаково понимать состояние и проблемы задачи – быть полноценной командой.

---

Всё, что сказано в предыдущих трех статьях – подготовка к внедрению и может показаться, что многое из этого – лишние, необязательные движения. Со временем ты начинаешь понимать, что качественная подготовка закладывает серьезный фундамент в основу внедрения, резко повышая не только вероятность удачного внедрения, но и делая его мягче.

Лучше потратить много времени на подготовку, при отсутствии затрат на проект и жестких сроках реализации, уже завязанных на партнеров по внедрению, чем уже во время внедрения осознавать, как много ты не учел и идти либо с опозданием, либо жертвуя тем, что не учел сразу. При этом, можете не сомневаться, что даже при самой качественной подготовке, Вы всё равно что-то не учтете!

Следующая статья: Как внедрять ERP. Этап 1 - складской учет.

Автор: Андрей Лабутин