Приведу примеры из практики.
Пример 1
Производственная Компания “Х” захотела перемен. Основные черты “Икса”:
- монополист
- давно на рынке
- среди сотрудников 50/50 старичков и новичков (как по возрасту, так и по давности работы в Компании)
- процессы вокруг людей
- своячничество
- насиженные места
- неготовность к изменениям
- ни ERP, ни CRM, ни ЭДО (из ПО только “1С Бухгалтерия”)
Анализ процессов вместе с повышением до заместителя директора поручили мне. Я как проектный человек с горящими глазами погрузилась с головой. Насобирала информации, показала "узкие места", нашла дублирование и зоны безответственности и т.д. За что Директор сказал "спасибо", но обозначил, что Компания пока не готова к изменениям, уж слишком много внутренних “политических моментов”. Это был очередной эксперимент (как сейчас в тренде говорить - “гипотеза”) под названием “а что если”. Поразмыслив над ситуацией я приняла решение уйти из “Х”, так как не видела смысла работать с людьми, которые живут по принципу “и так сойдет, мы монополисты”.
Года через 3 после моего ухода из Компании в "Иксе" всё-таки взялись за оптимизацию бизнес-процессов, в том числе и внедрение бережливого производства. Конечно же три года - это слишком большой срок, чтобы сидеть и выжидать, пока кто-то созреет до изменений.
Пример 2
Сотрудничество с IT-Компанией в качестве аналитика. Назовем Компанию “У”. “Игрек” занималась автоматизацией процессов девелопмента. Какие сложности мы встречали на этапе интервьюирования сотрудников:
- “когда я работал в другой Компании, у нас было вот так. Сделайте нам также.”
- “В Вашем ПО не предусмотрена только одна вот эта функция, поэтому оно нам вообще не подходит”
- “У нас есть “один эска”, нам и так нормально.
- назначение менеджерами проекта оптимизации сотрудников, не заинтересованных в изменениях или заинтересованных только в развитии своего подразделения.
Среди Заказчиков были довольно крутые Компании с уже частично налаженными процессами, но при этом не было экосистемы, когда сотрудники взаимодействуют в едином цифровом поле. Здесь то мы и были полезны.
Были среди Заказчиков и те, кто давно уже запутался в своем хаосе и надо было хоть что-то готовое внедрить, чтобы не в своем разбираться, а идти по шаблону наработанных процессов. “Игрек” как предоставлял такой шаблон ключевых процессов девелопмента.
Итак, обобщим сказанное:
- если у Гендира нет понимания, зачем нужен анализ процессов, то лучше вообще не влезать в такие проекты;
- вовлеченность Заказчика в анализ бизнес-процессов - один из ключевых факторов успеха Проекта;
- “так исторически сложилось” - боль Айтишников и процессных аналитиков;
- обязательно учитывать нюансы оргструктуры (своячничество, процессы вокруг людей и т.д.) и дважды подумать, влезать ли в такой проект, если Гендира все устраивает;
- если кто-то не готов к изменениям, не надо настаивать - их время еще не пришло;
- не всегда надо углубляться в анализ, иногда лучше использовать ПО с готовыми процессами;
- если в процессах Компании нет экосистемы, то точно есть, куда стремиться.