Как одним управленческим решением развалить IT архитектуру, созданную за недолгие 9 месяцев

Исходные данные: торгово-производственное предприятие специализирующееся на производстве и монтаже неких инженерных систем.

Более 15 лет на рынке. Предприятие оснащено системой 1С, которую, к слову сказать, многие, до сих пор, считают системой управления продажами. 1С это система управления деньгами, товарам, документами, отгрузками и пр и пр., но никак не система управления продажами.

Заказчик приходит к заключению, что, все-таки, необходима система предназначенная для управления именно продажами и принимает решение о внедрении CRM системы.

Что ж, решение принято, работаем. Все по технологии:

1. Определяем процессы

2. Отрабатываем логику и правила взаимодействия подразделений

3. Создаем сквозной процесс

4. Воссоздаем его в IT системе

5. Обучаем сотрудников

6. Запускаем

Заняло 4 месяца.

👉🏻Далее, на протяжении ещё 4 месяцев вносим правки, расширяем систему на смежные подразделения (маркетинг+продажи; колл-центр+продажи; продажи+инженерный отдел) отрабатываем технологию, стабилизируем воронку продаж, собираем первую аналитику и…

🏆собственник нанимает на работу нового руководителя отдела продаж, который обладает неким набором технических знаний о внедренной системе и чётким видением того, как данная система должна работать…

Для его отдела.

А далее происходит то, что всегда происходит в стройке, когда ей управляют два конкурирующих прораба или, когда на кухне одновременно готовят две враждующие хозяйки. Хаос.

В системе неожиданно появляется 23000 новых необработанных лидов, нарушаются правила разграничения доступа, сотрудники одного отдела начинают работать с клиентами другого отдела…

С точки зрения IT проект еще жив. Нет никакой проблемы почистить систему от появившегося хлама и вернуть разграничение прав.

А вот с точки зрения бизнес архитектуры проекту, и предприятию в целом, нанесен удар. Выраженный в том, что правильная, в целом, логика работы нового отдела продаж, никак не сопряжена с глобальной логикой, в которой уже сосуществуют 5+ подразделений предприятия.

С точки зрения IT подрядчика, я безмерно радуюсь таким поворотам в проекте, потому что это практически 60% дополнительных денег от первоначального бюджета проекта. (Цинично, конечно, но бизнес есть бизнес)

А вот с точки зрения порядочного архитектора мне больно и горько, от того, что проект продолжительностью 9 месяцев тонет, всего лишь потому, что никто не озаботился вопросом сопряжения новой и действующей логики.

Что делать, когда больно? Лечить. Или, в нашем случае - фасилитировать.

Организовал встречу между собственником, действующим руководителем и новым. Нашли точки разграничения ответственности. Договорились о новых правилах разграничений и доступов. Приняли решение о том, как “делить” клиентов. Приняли изменения в системе и составили график работ. И все это за 2 часа.

2 часа, которые:

- сохранили проект продолжительностью 9 месяцев

- сэкономили около 1,5 млн руб на “судорожных изменениях в IT”

- сохранили проект общей стоимостью 3,7 млн руб

- избавили от корпоративного конфликта, потенциальный ущерб от которого грозил упущенной выгодой на сумму от 120 до 200 млн. руб.

Почему люди не разговаривают?