Быстрые, значит живые: практики цифровизации промышленного холдинга

Публикации
Поделиться:

Евгений Герасимов

Руководитель процессного офиса в ПАО "Микрон"

Член Ассоциации BPM-профессионалов

Кандидат экономических наук

Наталья Кондратенко

Процессный архитектор процессного офиса в ПАО «Микрон»

Член Ассоциации BPM-профессионалов

Представляем успешный опыт процессной трансформации ПАО «Микрон», победителя национального конкурса «BPM-проект года 2019» в номинации "Самый инновационный проект". Команде в сжатые сроки удалось кардинально перестроить ключевые процессы компании и запустить автоматизированные сервисы закупок и продаж. Но главный итог проекта — смена культурной парадигмы его участников, открывший многим из них «процессное зрение», в фокусе которого теперь процессные роли внутреннего заказчика и исполнителей.

Видеопрезентация проекта:


Предпосылки к проекту

ПАО «Микрон» является участником глобальных цепочек и трендов в микроэлектронике. Конкуренция высока и постоянно растет. Выигрывают быстрые и дешевые. В последнее время «Микрон» столкнулся с трудностями на рынках присутствия. Поддержание высоких стандартов качества на устаревающих технологиях затратно. Естественным ответом бизнеса в этих условиях стал запрос на изменения внутренних процессов. Требовалась адекватная гибкость в ответ на негативную рыночную динамику.

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

Особенность циклов на «Микроне» (в условиях крупносерийного производства) — контрактация в момент, когда готовая продукция уже на складе. С контрактами на поставку аналогично — поставка без аванса невозможна. Почти все контракты уникальны. Нормальная проработка контракта, предусматривающего все нюансы поставки и гарантии качества — не один месяц живой коллективной работы.

В этих условиях контрактация (в ней формируются и согласуются условия и параметры сделки) — наиболее очевидный кандидат на быструю оптимизацию длительности операционного цикла. Контрактация охватывает закупки и продажи, поэтому эти процессы и попали в периметр проекта.

Советы практикующим:

  1. До начала проекта процессный офис уже должен быть развернут и спозиционирован в системе управления проектами (ключевые «топ-менеджеры» должны войти в процессный/проектный комитет или его аналоги). Браться за такую работу «партизанским отрядом» — дорогая утопия.
  2. Отсутствие описанных и регламентированных процессов и/или целых архитектурных слоев, не является препятствием. Наличие таковых в компаниях, которые уже потратились на такую работу, само по себе не делает их более зрелыми. Зачастую они управляются в традиционной туннельно-функциональной парадигме.
  3. Стандартизация процессов до workflow в «бумагу» для компаний, нацеленных на высокую адаптивность, в долгую, — дорогое и ненадежное самопознание. Правила исполнения процессов «в бумаге» никогда не совпадут с автоматизированными. Автоматизация неизбежно потребует закрепления новых процессных границ и ролей. Целиться сразу нужно туда. Начинайте с людей, а не с фреймворков.

Цели проекта

Закупки и продажи — самые нагруженные процессы на «Микроне». Свыше 10000 инициаций в год, свыше 3000 контрактов, средняя продолжительность согласования по контракту 1,5 — 2 месяца (иногда и более). Более чем в 80% случаев — циклы повторного согласования, доработок/переработок, протоколов разногласий, протоколов их урегулирования и т. п.

В рамках стратегической инициативы высшим руководством была сформулирована цель «не менее, чем трехкратного сокращения длительности процедур согласования и подписания контракта в составе процессов закупок и продаж». Предложенное решение должно быть системным и неограниченно обеспечивать воспроизводимость достигнутых результатов и их масштабируемость на предприятиях ГК «Микрон».

Проект сразу виделся как комплексный. Он объединил в себе создание двух сервисов: закупок и продаж в составе корпоративной ERP-платформы. К этому времени техническая часть ERP-системы уже была развернута

Сложности реализации проекта

Сложность проекта при инициации проекта оценивалась, как средняя, и была обусловлена следующими факторами.

Рыночные и процессные факторы:

  1. Рынок покупателя. Высокие стандарты качества изделий микроэлектроники. Ресурсные ограничения и технологическая зависимость от импортного сырья. Объективные ограничения к применению типовых контрактов.
  2. Множественность сценариев процессов. Внутренние границы процессов в основном не определены. Не смотря на зрелую СМК преобладает стиль управления по поручениям (на основе делегирования в СЭД).
  3. Вся предконтрактная работа вне корпоративной ERP.
  4. «Зоопарк» ИС и преобладающая доля неавтоматизированных операций.

Ментальные факторы:

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

Советы практикующим:

  1. О целях. «В недалеком будущем останутся два вида компаний — быстрые и мертвые» (Дэйв Вайс). Цели должны спускаться (строго) сверху (генеральный директор, главный акционер). Цели формулируются в терминах требований к скорости процессов. Они ясны и понятны всем и исключают трактовки. Традиционные оценки операционной эффективности (по стоимостным метрикам прямой и косвенной экономии, в т. ч. ее удельных значений на единицу эффекта) не включают трудно измеримые факторы ценности отложенной альтернативы, которая со временем только возрастает. Скорость при высокой плотности оцифровки всей процессной семантики — основная цель. Монетизация скорости — следующий этап, продолжительность которого почти не ограничена и определяется темпами сокращения субъектности в процессах на фоне проникновения в них соответствующих digital-технологий (AI, RPA, ML и др.).
  2. Процессы «as-is» без СЭД зачастую лучше, чем автоматизированные в СЭД — они еще не стали частью корпоративной культуры. СЭД «склеивает» процессы в парадигме маршрута документа (запросы, заявки, договоры), закрепляя за согласователями их контрольно-надзорный статус, что, противоречит bpm-культуре. Эксперименты с «дорожками» согласующих в СЭД ограничены семантикой результата: «согласовано», «согласовано с замечаниями», «не согласовано». Типовой функционал в СЭД стимулирует к применению правил делегирования задачи, неограниченно умножая сумму работ с контрактом. Сценарии процесса строятся на отклонениях от типового маршрута, а не на потребительской ценности.

Методы и инструменты. Анализ процессов и проектирование улучшений

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

К моменту выхода на этап проектирования процессный офис организационно уже был в стадии регулярной процессной работы: был подобран и обучен квалифицированный персонал, появились стандарты работы с процессами (соглашение о моделировании, регламенты моделирования процессов и проектирования процессных улучшений), была спроектирована высокоуровневая процессная архитектура в среде Business Studio.

В сжатые сроки были собраны UseCase᾽s всех сценариев процессов, как их видели участники. Начались отработки оптимизационных сценариев, в рамках которых изучались множественные дублирования однотипных операций в разных ИС и/или разными исполнителями. Рассматриваемые оптимизационные сценарии «лечения» процессов давали только 20–30% эффект и не годились для решения.

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

Основные принципы реализации реинжиниринга процессов закупок и продаж на «Микроне»:

  1. Демонстрация «офисной бюрократии» невозможности масштабирования ее скорости работы в верхнеуровневые целевые установки.
  2. Термин «согласование» под запретом.
  3. Выявление и создание бизнес-правил там, где их не было.
  4. Согласующий выполняет строго конкретную задачу по информационному сопровождению сделки в зоне своей ответственности и не может сказать «нет» (при редких исключениях).
  5. Спецификация всех сценариев процесса и их оркестровка. Все активности распределены по своим «дорожкам».
  6. Шаг процесса — этап в приращении ценности. Шаги только вперед.
  7. Табу на циклы и повторные рассмотрения.

Что касается непосредственно технологии проектирования изменений, то моделирование бизнес-процессов выполнялось в системе Business Studio в нотации BPMN 2.0 в аналитической парадигме при строгом соблюдении соответствующей методологии.

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

Базовый принцип построения workflow — быстрое насыщение заявки/заказа информацией по месту нахождения источника. И если источник был распределен и/или отсутствовал единый ответственный за нее, то создавались бизнес-правила, по которым такой ответственный появлялся, а источник информации становился целостным. Минимум переходов.

С экономистами, например, мы подняли целый пласт их бизнес-правил и интегрировали систему их справочной информации (в Excel) в общекорпоративную ERP. Мы выяснили и показали им и остальным, что ценообразование по принципу «затраты + прибыль» во многих случаях — простая задача, решаемая на основе шаблонов, и для этого не нужно каждый раз подключать узкого специалиста по ценообразованию, который должен подтвердить цену контракта. Задачу выполнит менеджер при наличии доступной структурированной информации.

Аналогично отрабатывались все остальные ответственные контролеры-согласователи, в числе которых служба безопасности. Нам нужно было сдвинуть фокус их участия с самого контракта в предконтрактную фазу, где определялся контрагент. Мы создали им условия для рейтингования и оценки коммерческих предложений поставщиков по критерию благонадежности, разработали шкалу, автоматизировали рабочее место в ERP. Для них это был прорыв.

Рис. 1. Автоматизированное в 1С: ERP рабочее место сотрудника службы безопасности

Мы выявили сценарии потоков, которые по ряду управляющих признаков должны «бежать» быстрее, вынули их из общего workflow, и за короткие 1–2 шага устремили к финишу. А это оказалось годным для более половины всех инициаций.

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

Разные по смыслу и последовательно выполняемые задачи, находящиеся в зоне ответственности одного исполнителя, работающего в одной экранной форме ИС, объединялись в один процессный «контейнер» для исключения генерации атомарных задач самому себе.

Мы сильно упростили весь процесс, хотя модель в нотации BPMN 2.0 выглядела громоздкой, и бизнес-пользователи отмечали это, сравнивая с видимой простотой маршрута документооборота, который обходился в 5–6 переходов между «дорожками» согласующих. Просто в такой детальности эти процессы никто никогда не видел и по-настоящему не задумывался о настоящей реальности их исполнения. А неизбежные циклы согласования при наличии замечаний, которые требуют повторного согласования остальными, в понимании такой простоты процесса со стороны бизнеса как бы игнорировались.

Рис. 2. Фрагмент модели сервиса Закупок в нотации BPMN 2.0

Вновь созданные сервисы закупок и продаж укрупненно состоят из однотипных этапов:

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

Качество моделей на протяжении всей работы счетно подтверждалось на основе соответствующих метрик. В первом приближении минимизировалась стоимость процесса на основе минимизации общей суммы неизбежных работ (в человеко-часах) и общей длительности каждого шага процесса. Далее таргетировалась скорость общего потока работ. Итеративность. Проверялся каждый сценарий.

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

Применение Business Studio, включая возможности инструмента в части ФСА, помогли успешно преодолеть сопротивление изменениям со стороны бизнеса. Оцифрованная аргументация в пользу новых моделей была наиболее убедительной основой для принятия решения об их состоятельности.

Советы практикующим:

  1. Акценты на архитектурный метод (детальная проработка всех слоев архитектуры). Статичные процессные фреймворки оказались малопригодными для решения комплексной задачи проекта. Традиционные подходы к разметке границ между процессными категориями и бизнес-функциями не позволяли установить единого владельца процесса end-to-end. Применялись сервис-ориентированные подходы к построению архитектуры решений.
  2. Если проект комплексный с выходом на автоматизацию, то на этапе моделирования и проектирования лучше не надеяться на «бесплатные» инструменты, поскольку:
    • многослойный «процессный пирог» из многих десятков задач, управляемых бизнес-правилами, требует строгого использования методологии BPMN 2.0 для обеспечения адекватной стыковки на уровне единой объектной модели;
    • UseCase᾽s и их артефакты должны «собираться» по мере продвижения проекта и необходима поддержка разных версий моделей в сочетании с их разными источниками;
    • требуется быстрая техническая валидация всей процессной семантики и полная корректность часто вносимых в модель изменений.

Внедрение изменений и преодоление сопротивления

Автоматизация сервисов осуществлялась на платформе 1С:ERP. «Движком», обеспечивающим генерацию задач, выбрана система класса BPMS на основе low-code, обеспечивающая «бесшовную» интеграцию с ERP-системой.

На этапе прототипирования у нас все получилось довольно быстро. Однако вышеописанные аргументы «за» сами по себе не могли снять вопросы скорого и безусловного принятия новых принципов отношений между участниками взаимодействий. Серия контраргументов со стороны группы «deep enterprise»: «здесь так было всегда!», «давайте просто сделаем согласование параллельным!», «где вы такое видели?», «это нигде не работает!» и т. п. требовала от проектной команды постановки и решения новых задач по проекту, связанных с внедрением улучшений.

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

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

  • механизма фиксация требований заказчика к результату;
  • порядка приема-передачи результатов;
  • механизма внесения изменений в продукт.

Со стороны бизнеса наметилась тенденция к постоянному пересмотру ранее достигнутых договоренностей. Сервис закупок валидировался 5 раз с реконструкцией полной логики. Это было одно из самых влиятельных подразделений в составе бэк-офиса. Десятки человек, каждый из которых вел свой уникальный участок, образующий почти всегда уникальный сценарий работы… Люди просто не были готовы к любым изменениям в своих процессах.

В этой ситуации мы были вынуждены учитывать почти все, что бизнес запрашивал в рамках продуктовых улучшений. Речь о большом числе доработок типового функционала в «коробочной» ERP, которые увеличили длительность проекта почти в 2 раза. Мы «пилили» стандартные экранные формы, создавали новые, повсеместно насыщали общую функциональность — это была неизбежная «плата» за приобретаемую лояльность стейкхолдеров — участников процессов. Следует отметить, что мы бы и так это делали. Но было бы это в рамках развития продукта, а не на стадии начального создания и развертывания системы.

Параллельно началось давление со стороны высшего руководства. Попытка эскалации проблем наверх вызывала отторжение. Были недовольны сдвигом сроков завершения работы. У проектной команды началось «выгорание». В такой ситуации сразу и не ясно было что делать… Но мы все-таки «дожали». Помогли простые человеческие отношения и правильные решения со стороны куратора проекта.

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

Советы практикующим:

  1. Изначально считалось, что особых препятствий на пути реализации воли высшего руководства проект испытывать не будет. Это была наша ошибка. Менеджмент на всех уровнях не был готов к изменениям. Мы убедились на своем опыте — исключений нет.
  2. Нужна проектная мотивация для членов команды. Критично для тех, кто, наряду с основной работой, будет вовлечен в проект.
  3. Проработку группы стейкхолдеров «deep enterprise» необходимо начинать еще до формального старта проекта. Их лояльность критична на момент старта проекта.
  4. Эмпирическое правило. Проект внедрения комплексных улучшений на уровне бизнес-системы в целом неизбежно будет трансформирован в продуктовый(е) проект(ы) (по числу ИС или модулей КИС, затрагивающих автоматизируемые процессы). А у продуктовых проектов всегда найдется свой «функциональный начальник», мыслящий границами (в основном старыми!) «своей» бизнес-функции. Сдавать проект придется ему с учетом того, что инициатором проекта он не являлся.
  5. К моменту выхода на стадию технической валидации моделей сервисов в команде проекта (в составе группы разработки) должны быть лица, которые впоследствии будут обеспечивать регулярное внесение в нее изменений. В этот момент требуется создание всех трех линий поддержки пользователей и соответствующих сервисных процессов.
  6. Важно обеспечить доступ к моделям процессов, регламентам, отчетам по процессам, с помощью которых осуществляется бизнес-валидация всех моделей, обеспечивается постоянная обратная связь с бизнесом.
  7. Плохая новость Agile-практикам — придется оставить надежду на минимальный жизнеспособный продукт. Лояльность «продуктового» бизнес-заказчика, когда инициатор проекта не он, потребует сразу глубокого «запила» под его нужды.
  8. Не смотря на проектную инициативу сверху, потребуется формализация и полное документирование проекта в соответствии с принятыми у вас профилями управления проектами (устав/паспорт, ресурсный план-график, план по контрольным точкам, план управления рисками, план коммуникаций со стейкхолдерами, механизмы сдачи/приемки результатов и внесения изменений в проект), и их защита на проектном/процессном комитете. Даже если инициатива высшего руководства материализована в форме прямого поручения вам, создавайте документацию (!) и защищайте параметры проекта в ваших коллегиях. Так вы сэкономите массу времени и усилий, когда проект будет близок к финалу (как вам будет это казаться).

Результаты проекта

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

  • возросла стабильность и управляемость процессов, исключена потеря заявки или заказа;
  • модели сервисов закупок и продаж управляются бизнес-правилами (более 100 вновь созданы), которые для более чем 90% всех процессных треков обходятся без ручного делегирования;
  • в 4 раза снижена вероятность возврата документов на доработку;
  • на 40–50% снижена длительность нахождения готовой продукции на складе в период контрактации;
  • на 12 FTE* сокращена общая трудоемкость работы на всех этапах работы с контрактом;
  • общая длительность процессов закупок и продаж end-to-end с момента инициации заявки / поступления заказа сокращена: для доходного договора — в 1,6 раз, для расходного договора — 1,8 – 2,5 раза, в т. ч. в бюрократической фазе сделки (согласование и подписание контракта) — в 2,4 – 3,5 раза.

Сотрудники понимают свою роль и настроены на конкретные результаты. Открыты возможности для дальнейших улучшений на уровне потоков работ. Мы изменили (или, может быть, нам так хочется думать) трудовую ментальность. Люди стали говорить в терминах сервиса и удовлетворенности. Нет больше уполномоченных по договору и уполномоченных на его согласование (эти роли соответствовали корпоративным стандартам договорной работы). Реализация этого проекта — определяющий шаг в сторону цифровой трансформации.

По результатам проекта на уровне крупного производственного холдинга оказались технически избыточными:

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

Перед началом проекта мы поставили себе цель, что, автоматизируя наши новации, мы сделаем их неизбежными. Не будет возможности выполнить их не так, как мы спроектировали. И мы это сделали!

Рис. 3. #МыДелаемПроцессыНеизбежными


Статья подготовлена по мотивам участия ПАО "Микрон" в конкурсе "BPM-проект года" (победа в номинации "Самый инновационный проект", награда сообщества профессионалов управления бизнес-процессов ABPMP Russian Chapter), февраль 2020. Опубликовано в журнале Business Excellence №7 (2020).



ГК «Микрон» — крупнейший производитель и экспортер микроэлектроники в России, центр экспертизы и технологический лидер российской полупроводниковой отрасли. Микрон производит более 700 типономиналов продукции, включая интегральные схемы для защищенных носителей данных, идентификационных, платежных и транспортных документов, управления питанием и RFID-маркировки для различных отраслей цифровой экономики.


Поделиться:

Рекомендуемые материалы по тематике