Как сохранить стабильность бизнес-критичных процессов при запуске ERP-системы
Как внедрить ERP и не обанкротить по пути компанию? Много шишек было набито нами за двадцать лет проектов внедрения систем автоматизации, начиная с самого первого, когда местный губернатор звонил на завод клиента и ругался «почему в детские сады не завезли творожки?». С годами шишек становилось все меньше, но по шрамам на теле можем рассказать о нескольких выученных уроках.
Вообще, тема проектных рисков необъятная, в больших проектах выделяют специальное время на риск-менеджмент, про это можно обзорно почитать в нашей статье. Здесь мы сосредоточимся на более узкой теме – стабильности и непрерывности бизнес-критичных процессов компании в процессе запуска системы в эксплуатацию.
Что такое «критические бизнес-процессы»?
Начнем с базовых понятий, что же такое вообще “критический” бизнес-процесс в контексте внедрения ERP-систем. Единой шкалы критичности, конечно же, нет, и в каждой компании свой набор бизнес-критики.
Для компаний, которые производят пищевую продукцию, особенно с ограниченными сроками годности, это в первую очередь процессы производства и отгрузки. Сбои в этих процессах влекут за собой немедленные финансовые потери в недополученной выручке, в штрафах от клиентов, в списаниях продукции.
Для логистических компаний – процессы планирования поставки, отправления и приемки грузов в распределительных центрах. Для ритейла – это работа кассовой зоны (так называемый «фронт»).
Процесс расчета и выплаты заработной платы сотрудникам в большинстве компаний также считается бизнес-критичным. А в некоторых компаниях с непропорционально сильной финансовой службой бизнес-критичными процессами считают и формирование финансовой отчетности, с той аргументацией, что отсутствие своевременной отчетности влечет ошибочные управленческие решения.
В общем, будем считать критическими все те процессы, в которых компания при сбое этого процесса теряет деньги непосредственно и сразу. Конечно, стабильности этих процессов при старте новой системы должно уделяться наиболее пристальное внимание.
При этом с точки зрения внедрения, из списка критичных процессов можно легко исключить те процессы, которые до старта системы выполнялись в ручном режиме или с минимальной автоматизацией. Причина простая: если процесс не был автоматизирован, то сбои при запуске этого процесса в новой системе не повлияют на бизнес. Всегда можно переключиться к старой схеме и отработать процесс “на руках”: у него есть достаточное количество людей, и они понимают, как это сделать. Поэтому в том случае, когда проект внедрения не является заменой старой системы с бизнес-критичными процессами, риски невысоки, и проект можно делать по более гибкому и недорогому agile/time&material подходу.
Факторы неуспеха
Причин неуспеха старта критичных процессов много, остановимся на трех наиболее частых: “кривая” система, “кривые” процессы и “кривые” люди.
Самый простой и понятный – “кривая” система
Это могут быть как дефекты качества самой системы (ошибки, которые будут всплывать на старте), так и дефекты проектирования, когда критичный процесс плохо покрыт функциональностью системы, или созданное решение не работоспособно на практике.
Последние две проблемы чаще бывают даже более разрушительными, поскольку исправление ошибки часто намного быстрее, чем донастройка или разработка отсутствующего функционала.
Так, на заре юности ФТО, у нас случился эпический провал, когда в проекте с жесткими ограничениями по старту пришлось резать функциональность будущей системы и выносить часть функций во вторую очередь. Под нож попал и интерфейс пакетной печати документов на отгрузку, и в результате вместо того, чтобы по одной кнопке напечатать пакет документов по маршруту и отдать экспедитору, команде проекта, включая РМ, пришлось помогать операторам выписки печатать документы по одному и раскладывать в пакеты. Всю ночь раскладывать бумаги объемом примерно 15 пачек, а утром огребать от директора клиента за сорванную на восемь часов отгрузку — невероятно бодрит.
Второй фактор – “кривые” процессы
Часто случается, что внедрение совмещают с изменениями в процессе – старая система не позволяла улучшить процесс, а в новой-то все можно сделать “как надо”. Или наоборот, сама внедряемая система диктует изменение процесса – если проект идет в концепции минимума изменений в стандартную функциональность.
При этом заказчик часто забывает о том, что эти изменения надо внедрить: документарно (провести изменения договоров, регламентов, должностных инструкций), процессно (обучить людей и проверить, что они умеют работать по новому), договориться с третьими сторонами, если процесс их затрагивает.
Хорошим примером подобного конфуза стало изменение политики контроля кредитного лимита у одного из наших заказчиков. Долгие годы кредитный лимит для его клиентов контролировался только по сумме. Например, при задолженности клиента более чем в 100 тыс рублей отгрузка блокировалась. Новая же система позволяла более продвинутый вариант контроля, по сроку и по сумме. Например, при сроке задолженности более чем 30 дней хотя бы по одной предыдущей поставке отгрузка запрещена.
При этом лимиты были поставлены достаточно волюнтаристски, без детального анализа истории платежей клиентов и не были доведены до торговых представителей и далее до клиентов. В итоге кредитный контролер заказчика в авральном режиме почти 24*7 анализирующий ситуацию по проблемным клиентам и “на ручнике” разрешавший конкретные отгрузки, чтобы не разрушить отношения с клиентами, и наша проектная команда получили еще один хороший урок.
Наконец, “кривые” люди
Люди на самом деле могут быть прекрасными, но они могут быть не проинформированы об изменениях, могут быть не обучены, или обучены, но непонятно насколько хорошо, а ещё им может быть просто наплевать на ваш проект. Кроме того, людей может быть просто недостаточно.
Запуская WMS-систему в распределительном центре одного из заказчиков, производящих продукцию категории fresh, мы никак не могли предполагать внешний риск в виде ФМС. Через две недели после старта, когда проектная команда уже снималась с площадки и уезжала домой, ФМС провела рейд в окрестностях этого РЦ и задержала существенную часть работников склада. Резервов персонала не было, менеджмент площадки вовремя не среагировал наймом или замещением людей. Как следствие – значительное падение отгрузки, затаривание склада, списания просрочки.
Давайте разберем наиболее простые и понятные меры по снижению этих факторов.
“Кривая” система
Самое очевидное – позаботьтесь об отсутствии дефектов в системе. Понятно, что в каждом проекте должно быть проведено юнит-тестирование (тестирование каждой выполненной разработки), но не следует забывать и интеграционный тест. В отличие от юнит-тестирования, интеграционный тест выполняется не по доработкам, а сквозным сценарием, который отрабатывает процесс или несколько процессов целиком. Это позволяет выявить не только ошибки в коде, но и проблемы с настройками, нестыковки этапов процесса или разных процессов. Если бюджет проекта не позволяет делать его по всем процессам, выявите хотя бы бизнес-критичные и проведите интегротест по ним.
Очень полезным рецептом является и проведение “теста одного дня” (ТОД). Здесь мы проверяем систему не только на придуманных сценариях вместе с бизнес-экспертами и ключевыми пользователями заказчика, а прогоняем систему на всем объеме операций компании силами настоящих будущих пользователей непосредственно на их рабочих местах, в параллель с выполнением операций в старой системе, в течение полного цикла работы (например, сутки).
В отличие от интегротеста, ТОД выполняется непосредственно перед стартом – когда пользователи уже обучены, проверены механизмы загрузки начальных данных, а сами начальные данные загружены в каком-то объёме. ТОД — дорогое удовольствие, клиент должен вывести в смену существенно больше сотрудников, для того чтобы обеспечить и свой нормальный цикл работы, и параллельный прогон в новой системе. Но такой подход окупает себя, если размер возможных потерь велик.
Как вариант экономии – сокращение времени ТОД: выбрать интервал времени, минимально покрывающий весь критичный функционал, и провести тест на этом интервале, а не полные сутки. Например, маршрутизация, сбор и отгрузка одной из волн.
В попытке полностью закрыть этот фактор некоторые компании планируют на старте новой системы продолжать отражать операции и в старой – так называемый параллельный учет. Причем, период такой двойной жизни планируется месяц, а один раз мы встречали пожелание и в квартал. Казалось бы, хорошая история. Если что-то не так с новой системой, можно решить задачу с помощью старой системы?
Но мы считаем подобную практику ошибочной, и видели несколько случаев, когда она приводила в беду. Во-первых, у менеджеров, пользователей и внедренцев всегда возникает соблазн вместо того, чтобы отработать проблемы и отладить процесс в новой системе, вернуться к старой. Как результат — при слабой управленческой воле процесс внедрения может затягиваться на месяцы. Во-вторых, и главное, это создает огромные риски по третьему проблемному фактору — людям. От команды заказчика требуется вести двойную работу в старой и новой системе, и, что еще хуже – проводить сверки между ними. Штат при этом никто не расширяет. В итоге пользователи скатываются к работе в старой системе — ведь в ней уже все отлажено, а в новой “все время что-то не работает”.
Клиентам, которые ратуют за параллельный учет из-за боязни того, что результаты расчетов в новой системе будут ошибочны, мы предлагаем провести аналог теста одного дня – тест одного месяца. Выбирается ограниченный периметр тестирования, точечно усиливается команда заказчика, и в течение месяца люди дублируют операции, а затем проводят сверку. Например, в течение месяца оформляются кадровые документы по одному-двум отделам или торговым точкам заказчика, затем проводится расчет заработной платы. Такого рода дополнительное тестирование проводится до старта системы в эксплуатацию и не отвлекает команду от проблем старта. Но нужно понимать, что это дорогое удовольствие.
“Кривые” процессы
Первое и обязательное правило для снижения рисков старта из-за недоработки в процессах – инвентаризируйте изменения процессов! Начинается еще все на этапе дизайна – когда мы видим обсуждения бизнес-экспертов заказчика о том, что вот здесь они хотели бы улучшить свой процесс, а вот тут не понимают, кто это будет делать в новой системе – берем на карандаш. Процесс инвентаризации организационных изменений и контроль проведения их в жизнь – важная роль руководителя проекта со стороны заказчика, о которой часто забывают. Но и роль аналитиков и руководителя проекта со стороны исполнителя нельзя недооценивать. Именно они могут подмечать возможные изменения и доносить заказчику.
У каждого такого изменения должен появиться конкретный ответственный от бизнеса и план проведения этих изменений. Какие нормативные документы готовятся и согласуются, как информация коммуницируется внутри и вовне компании, как и кого мы обучаем и, возможно, аттестуем.
Так же, как мы тестируем новую систему, нужно тестировать и орг.изменения. Либо вручную, либо, если система прошла интегротест – прямо в системе. Очень полезным становится и прописывание “плана В” – что мы будем делать, если процесс не взлетит из-за сложности, неготовности персонала или контрагентов. Например, в упомянутом примере с кредитным контролем было бы правильным до старта системы по двум-трем десяткам разных клиентов проводить новый контроль вручную, чтобы выявить возможные проблемы, а также договориться с руководством о возможности временного отката к старой схеме по клиентам категории А.
Нельзя не предостеречь и от избыточного переусложнения процессов на старте. Например, у нас был неприятный урок, когда финансовое подразделение заказчика в новой системе реализовало свою мечту – сверхдетальный учет затрат с закрытием “прачечных на котельные” до уровня заказов. При этом организационно у клиента не было готовности к анализу себестоимости по этой методике, и как результат – срыв закрытия нескольких первых месяцев учета в новой системе. При этом эффект от такой системы был нематериален – изменения в цифрах относительно старого метода были в копейках. Хорошей работой руководителей проекта с обеих сторон здесь было бы решение о старте на обычной схеме “как раньше”, а затем, после выравнивания операций и качества данных, ее усложнение.
“Кривые” люди
Наконец, поговорим о персонале и начнем с количества. Первое, что нужно сделать — удостовериться в достаточности штата на старте и обеспечить усиленные смены на первые дни (или недели) работы в новой системе, особенно если внедряется сложная система класса ERP. Помните, что люди, как бы хорошо их не учили, работают в новой системе медленнее, чем в старой, и будут выполнять меньше операций в единицу времени. Для наиболее критичных операций (например, прием клиентских заказов) мы на проектах даже проводим замеры времени выполнения операций, сравниваем результаты для старой и новой системы и определяем, сколько человек в смену нужно добавить. Это же позволяет выявить и пробелы в обучении персонала, и успеть их отработать до старта.
Не стоит забывать и о качестве персонала. При проектировании системы аналитики и руководители проекта должны всегда сверять архитектуру решения с тем, а какие люди будут работать в нем. Ошибкой будет создать процесс/систему, которые недоступны пользователям. Неудачный пример у нас был в проекте с компанией, которая являлась одновременно логистическим оператором и дистрибутором известного бренда. В голову пришла “хорошая” идея о том, что можно совместить склады ответственного хранения и собственного товара, и покупать товар у вендора в момент отгрузки “собственных” заказов. На схемах бизнес-процессов все было красиво, но обычные люди на складе (операторы отгрузки и кладовщики) просто утонули в сложности учета, и попытки инвентаризации сводного склада заняли не одну неделю.
Второй ключевой фактор – спрямление коммуникаций и доступность менеджмента. На старте новой системы ее пользователи должны иметь прямой выход на проектную команду (и проектная команда должна быть рядом для сокращения времени реагирования). Ключевые пользователи и руководство проектом должно иметь постоянный прямой доступ к руководителям подразделений, задействованных в старте.
Больной вопрос, о котором все говорят, но мало кто делает – это мотивация команды. Прямой саботаж, конечно, возможен только в случае параллельного учета. Но даже если все хорошо, и мы запускаемся с “отключением” старой системы, команда, мотивированная на достижение цели (причем, не только деньгами, но и повышенным вниманием со стороны руководства клиента), будет гораздо менее склонна к оправданиям и перекидыванию ответственности на проектную команду, и больше времени потратит на решение вопросов вместе с командой. Мотивационный бюджет обычно составляет доли процента (максимум 1-2%) от общих затрат на проект, и это гораздо дешевле, чем провал запуска или сдвижка его на несколько месяцев.
В обычных ERP-проектах управление рисками не является rocket science. Отличие успешных запусков от неуспешных определяется только пониманием у руководства того, что в подготовку качества старта требуется вложение времени (=денег). А также внутренней дисциплиной команды в регулярном выделении времени на “подумать вперед” и выполнение достаточно простых мероприятий.