Бизнес-процессы устарели

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

Я не знаю, насколько этот кейс был реальным, а насколько результат креативного использования генеративного ИИ, но решил написать почему такой подход не только неэффективен, но и вреден на практике. Перечислять буду списком в произвольном порядке:

➤ Очень сложно создать набор контролей, которые корректно описывают нюансы прохождения процесса. Например, закупка на малые суммы не должна занимать столько ресурсов и времени, как конкурс с НМЦ более 50 млн. Метрика будет или слишком высокоуровневая и за счет усреднения не будет репрезентативной, или их станет слишком много

➤ SLA должно зависеть от характера работы. Берем ту же закупку под ремонты. Если ремонт аварийный, то будет стоят у закупки приоритет, но его ставят не закупщики, а инициаторы. Если же ставить SLA без учета дополнительных данных, то контроль времени будет идти по верхней границе и ситуацию со срочными закупками из примера мы просто не контролируем

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

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

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

➤ Каждое подразделение будет заинтересовано в выполнении своих метрик. Метрики часто будут противоречивыми. Закупки могут снизить закупочную цену за счет агрегации заказов и нескольких циклов переторжки, но это увеличит срок закупки и сорвет сроки проведения работ другого подразделения

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

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

Разобраться с человеческим фактором будет дорого - понадобиться или отдельная должность "политрука" или выделение значительной части времени руководителя на эти задачи.

Не надо путать подходы из ITIL или концепцию объединенного центра обслуживания (ОЦО) с отказом от сквозных бизнес-процессов. ОЦО или ITIL-enabled департамент ИТ предполагает создание отдельного бизнес юнита с полноценными бизнес-процессами внутри. Включая и процессы контроля качества обслуживания внутреннего заказчика. Это дополнительные затраты, которые окупаются только на большом масштабе. Например, превращение 4-5 независимых финансовых отделов в один. А не когда вы каждый отдел делаете отдельной "организацией" не выделяя ресурсы на управление этой организацией, а надеясь на самоорганизацию.

#holy_wars@hammered_screw