Представляем успешный опыт процессной трансформации ПАО «Микрон», победителя национального конкурса «BPM-проект года 2019» в номинации "Самый инновационный проект". Команде в сжатые сроки удалось кардинально перестроить ключевые процессы компании и запустить автоматизированные сервисы закупок и продаж. Но главный итог проекта — смена культурной парадигмы его участников, открывший многим из них «процессное зрение», в фокусе которого теперь процессные роли внутреннего заказчика и исполнителей.
Предпосылки к проекту
ПАО «Микрон» является участником глобальных цепочек и трендов в микроэлектронике. Конкуренция высока и постоянно растет. Выигрывают быстрые и дешевые. В последнее время «Микрон» столкнулся с трудностями на рынках присутствия. Поддержание высоких стандартов качества на устаревающих технологиях затратно. Естественным ответом бизнеса в этих условиях стал запрос на изменения внутренних процессов. Требовалась адекватная гибкость в ответ на негативную рыночную динамику.
В фокус попали все основные процессы: производство, продажи, закупки, управление поставками и отгрузками, образующие операционный цикл. Требовалось найти быстрые решения, которые бы удешевили и ускорили операционный цикл.
Особенность циклов на «Микроне» (в условиях крупносерийного производства) — контрактация в момент, когда готовая продукция уже на складе. С контрактами на поставку аналогично — поставка без аванса невозможна. Почти все контракты уникальны. Нормальная проработка контракта, предусматривающего все нюансы поставки и гарантии качества — не один месяц живой коллективной работы.
В этих условиях контрактация (в ней формируются и согласуются условия и параметры сделки) — наиболее очевидный кандидат на быструю оптимизацию длительности операционного цикла. Контрактация охватывает закупки и продажи, поэтому эти процессы и попали в периметр проекта.
Цели проекта
Закупки и продажи — самые нагруженные процессы на «Микроне». Свыше 10000 инициаций в год, свыше 3000 контрактов, средняя продолжительность согласования по контракту 1,5 — 2 месяца (иногда и более). Более чем в 80% случаев — циклы повторного согласования, доработок/переработок, протоколов разногласий, протоколов их урегулирования и т. п.
В рамках стратегической инициативы высшим руководством была сформулирована цель «не менее, чем трехкратного сокращения длительности процедур согласования и подписания контракта в составе процессов закупок и продаж». Предложенное решение должно быть системным и неограниченно обеспечивать воспроизводимость достигнутых результатов и их масштабируемость на предприятиях ГК «Микрон».
Проект сразу виделся как комплексный. Он объединил в себе создание двух сервисов: закупок и продаж в составе корпоративной ERP-платформы. К этому времени техническая часть ERP-системы уже была развернута
Сложности реализации проекта
Сложность проекта при инициации проекта оценивалась, как средняя, и была обусловлена следующими факторами.
Рыночные и процессные факторы:
- Рынок покупателя. Высокие стандарты качества изделий микроэлектроники. Ресурсные ограничения и технологическая зависимость от импортного сырья. Объективные ограничения к применению типовых контрактов.
- Множественность сценариев процессов. Внутренние границы процессов в основном не определены. Не смотря на зрелую СМК преобладает стиль управления по поручениям (на основе делегирования в СЭД).
- Вся предконтрактная работа вне корпоративной ERP.
- «Зоопарк» ИС и преобладающая доля неавтоматизированных операций.
Ментальные факторы:
- Исторически развитые бюрократические практики, большой состав согласующих лиц.
- Взгляд на инициатора сделки как на потенциального растратчика.
- Традиционное «туннельное» мышление менеджеров.
- Неготовность к изменениям со стороны ключевых стейкхолдеров. Устойчивые ментальные паттерны неприятия альтернативы контрольно-разрешительной логики согласования.
Методы и инструменты. Анализ процессов и проектирование улучшений
Постановка задачи выглядела как вызов для проектной команды, поскольку ее участники со стороны бизнеса не понимали, как можно в 3 раза ускорить работу по согласованию контрактов, учитывая, что для многих из них эта работа была не основной. Таких резервов времени у бизнеса не было, и данная целевая метрика напрямую не масштабировалась в отдельные метрики исполнителей.
К моменту выхода на этап проектирования процессный офис организационно уже был в стадии регулярной процессной работы: был подобран и обучен квалифицированный персонал, появились стандарты работы с процессами (соглашение о моделировании, регламенты моделирования процессов и проектирования процессных улучшений), была спроектирована высокоуровневая процессная архитектура в среде Business Studio.
В сжатые сроки были собраны UseCase᾽s всех сценариев процессов, как их видели участники. Начались отработки оптимизационных сценариев, в рамках которых изучались множественные дублирования однотипных операций в разных ИС и/или разными исполнителями. Рассматриваемые оптимизационные сценарии «лечения» процессов давали только 20–30% эффект и не годились для решения.
В итоге было решено прибегнуть к реинжинирингу процессов, в основе которого лежит трансформация роли контролера-согласователя контракта в бизнес-роль исполнителя, ответственного за информационное сопровождение сделки в зоне своей ответственности. Так проект стал трансформационным. Учитывая неизменность позиции высшего руководства, риск успешного завершения проекта казался оправданным.
Основные принципы реализации реинжиниринга процессов закупок и продаж на «Микроне»:
- Демонстрация «офисной бюрократии» невозможности масштабирования ее скорости работы в верхнеуровневые целевые установки.
- Термин «согласование» под запретом.
- Выявление и создание бизнес-правил там, где их не было.
- Согласующий выполняет строго конкретную задачу по информационному сопровождению сделки в зоне своей ответственности и не может сказать «нет» (при редких исключениях).
- Спецификация всех сценариев процесса и их оркестровка. Все активности распределены по своим «дорожкам».
- Шаг процесса — этап в приращении ценности. Шаги только вперед.
- Табу на циклы и повторные рассмотрения.
Что касается непосредственно технологии проектирования изменений, то моделирование бизнес-процессов выполнялось в системе 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С:ERP. «Движком», обеспечивающим генерацию задач, выбрана система класса BPMS на основе low-code, обеспечивающая «бесшовную» интеграцию с ERP-системой.
На этапе прототипирования у нас все получилось довольно быстро. Однако вышеописанные аргументы «за» сами по себе не могли снять вопросы скорого и безусловного принятия новых принципов отношений между участниками взаимодействий. Серия контраргументов со стороны группы «deep enterprise»: «здесь так было всегда!», «давайте просто сделаем согласование параллельным!», «где вы такое видели?», «это нигде не работает!» и т. п. требовала от проектной команды постановки и решения новых задач по проекту, связанных с внедрением улучшений.
Особенность нашего проекта в том, что он позиционировался как трансформационный проект, инициируемый высшим руководством, но его реализация через создание отдельных автоматизированных сервисов свела его к двум продуктовым проектам (по числу автоматизированных сервисов продаж и закупок).
На предфинальной стадии проекта выяснилось, что сдавать результаты нужно будет коммерческой дирекции и дирекции по закупкам. А главный заказчик изменений в лице высшего руководства как бы отошел в сторону и уступил свое право руководителям этих бизнес-функций. Сразу ощутились проблемы отсутствия обязательных проектных механизмов, о которых обычно договариваются в начале проекта:
- механизма фиксация требований заказчика к результату;
- порядка приема-передачи результатов;
- механизма внесения изменений в продукт.
Со стороны бизнеса наметилась тенденция к постоянному пересмотру ранее достигнутых договоренностей. Сервис закупок валидировался 5 раз с реконструкцией полной логики. Это было одно из самых влиятельных подразделений в составе бэк-офиса. Десятки человек, каждый из которых вел свой уникальный участок, образующий почти всегда уникальный сценарий работы… Люди просто не были готовы к любым изменениям в своих процессах.
В этой ситуации мы были вынуждены учитывать почти все, что бизнес запрашивал в рамках продуктовых улучшений. Речь о большом числе доработок типового функционала в «коробочной» ERP, которые увеличили длительность проекта почти в 2 раза. Мы «пилили» стандартные экранные формы, создавали новые, повсеместно насыщали общую функциональность — это была неизбежная «плата» за приобретаемую лояльность стейкхолдеров — участников процессов. Следует отметить, что мы бы и так это делали. Но было бы это в рамках развития продукта, а не на стадии начального создания и развертывания системы.
Параллельно началось давление со стороны высшего руководства. Попытка эскалации проблем наверх вызывала отторжение. Были недовольны сдвигом сроков завершения работы. У проектной команды началось «выгорание». В такой ситуации сразу и не ясно было что делать… Но мы все-таки «дожали». Помогли простые человеческие отношения и правильные решения со стороны куратора проекта.
На стадии опытно-промышленной эксплуатации вновь созданных сервисов осуществлялась работа по их регламентации с одновременным созданием комплекса всей пользовательской документации на уровне автоматизированных рабочих мест. Осуществлялось обучение пользователей навыкам работы в новых модулях ERP. К моменту ввода в промышленную эксплуатацию данная работа была финализирована, границы процессов и полномочия всех ответственных были точно определены и соответствовали новым управленческим принципам.
Результаты проекта
Данный проект выполнил свою главную миссию, определенную руководством компании. Мы кардинально изменили ключевые процессы, создав автоматизированные сервисы закупок и продаж, управляемые на основе формальной бизнес-логики быстрее и дешевле, чем раньше:
- возросла стабильность и управляемость процессов, исключена потеря заявки или заказа;
- модели сервисов закупок и продаж управляются бизнес-правилами (более 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-маркировки для различных отраслей цифровой экономики.
Август 2020 г.
Поделиться: