Про саботаж сотрудников и другие риски на пути анализа бизнес-процессов

Приведу примеры из практики.

Пример 1

Производственная Компания “Х” захотела перемен. Основные черты “Икса”:

• монополист
• давно на рынке
• среди сотрудников 50/50 старичков и новичков (как по возрасту, так и по давности работы в Компании)
• процессы вокруг людей
• своячничество
• насиженные места
• неготовность к изменениям
• ни ERP, ни CRM, ни ЭДО (из ПО только “1С Бухгалтерия”)

Анализ процессов вместе с повышением до заместителя директора поручили мне. Я как проектный человек с горящими глазами погрузилась с головой. Насобирала информации, показала "узкие места", нашла дублирование и зоны безответственности и т.д. За что Директор сказал "спасибо", но обозначил, что Компания пока не готова к изменениям, уж слишком много внутренних “политических моментов”. Это был очередной эксперимент (как сейчас в тренде говорить - “гипотеза”) под названием “а что если”. Поразмыслив над ситуацией я приняла решение уйти из “Х”, так как не видела смысла работать с людьми, которые живут по принципу “и так сойдет, мы монополисты”.

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

Пример 2

Сотрудничество с IT-Компанией в качестве аналитика. Назовем Компанию “У”. “Игрек” занималась автоматизацией процессов девелопмента. Какие сложности мы встречали на этапе интервьюирования сотрудников:

• “когда я работал в другой Компании, у нас было вот так. Сделайте нам также.”
• “В Вашем ПО не предусмотрена только одна вот эта функция, поэтому оно нам вообще не подходит”
• “У нас есть “один эска”, нам и так нормально.
• назначение менеджерами проекта оптимизации сотрудников, не заинтересованных в изменениях или заинтересованных только в развитии своего подразделения.

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

Были среди Заказчиков и те, кто давно уже запутался в своем хаосе и надо было хоть что-то готовое внедрить, чтобы не в своем разбираться, а идти по шаблону наработанных процессов. “Игрек” как предоставлял такой шаблон ключевых процессов девелопмента.

Итак, обобщим сказанное:

• если у Гендира нет понимания, зачем нужен анализ процессов, то лучше вообще не влезать в такие проекты;
• вовлеченность Заказчика в анализ бизнес-процессов - один из ключевых факторов успеха Проекта;
• “так исторически сложилось” - боль Айтишников и процессных аналитиков;
• обязательно учитывать нюансы оргструктуры (своячничество, процессы вокруг людей и т.д.) и дважды подумать, влезать ли в такой проект, если Гендира все устраивает;
• если кто-то не готов к изменениям, не надо настаивать - их время еще не пришло;
• не всегда надо углубляться в анализ, иногда лучше использовать ПО с готовыми процессами;
• если в процессах Компании нет экосистемы, то точно есть, куда стремиться.