Пугающие изменения. Как мы заставляем клиентов меняться
Много факторов мешает проекту дойти до конца — сопротивление сотрудников и руководителей, изменения в бизнесе и среде, которых никто не ждал. А так же, как ни странно, отсутствие необходимых изменений.
Что за изменения, отсутствие которых может «похоронить» проект, или обеспечить проекту жесткое «трение» при запуске?
Мы давно придерживаемся мнения, что проект автоматизации — это проект организационных изменений. Пишем и говорим об этом постоянно. Пришло время разобраться подробнее, какие они могут быть, и как можно навредить проекту, если их не проводить.

Откуда берутся изменения
Первый этап любого проекта — бизнес-обследование. В ходе обследования мы проводим глубинные интервью по участкам с ключевыми пользователями, руководителями подразделений. Интервью нужны не для того, чтобы «понять, как настроить 1С», а для того чтобы разобраться в работе компании, ее процессах, ролях и подчиненности сотрудников.
Расхожая фраза «если автоматизировать хаос, получится автоматизированный хаос» — абсолютно правдива. Вне зависимости от выбранного метода проектного управления: классическая каскадная технология, эджайл, или смешанный подход, нужно точно понимать процессы компании и особенности ее работы.
Мы в своем обследовании фиксируем сразу процессы с зоной ближайшего развития — с теми изменениями и улучшениями, которые необходимо выполнить. Например, если несколько закупщиков управляют поставками по-разному, есть смысл сразу привести их к единому процессу, и автоматизировать его, новый четкий и описанный процесс. А не разнообразие вариантов, кто и как на своем месте придумал работать.
Все найденные нами улучшения, изменения, мы фиксируем в несколько списков:
- Идеи (просто идеи что можно улучшить, хочешь бери, хочешь нет)
- Рекомендации (мы уверены, что эти изменения нужны заказчику, хотя и не относятся к нашему проекту)
- Задачи клиента (изменения, которые необходимо выполнить, чтобы автоматизация принесла пользу и вообще «взлетела»)
Все эти улучшения мы собираем в отдельный документ — «Концепция решений». В нем и предложения по развитию, и необходимые организационные изменения на стороне заказчика, и предлагаемые варианты архитектуры систем, конфигураций 1С, с обоснованиями, направлениями обменов и так далее. У команды заказчика в ходе проекта есть работа, в этом мало кто сомневается. Но какая? Первое, что приходит в голову — сделать так чтобы нужные сотрудники пришли на интервью, а затем и на обучение. Почитать документы, дать замечания и обсудить вопросы, и в итоге согласовать. Посмотреть демо прохождения процессов в системе и дать обратную связь. Предоставить доступы к своей инфраструктуре. Предоставить данные для загрузки или параметры для настройки интеграций. Это все важные задачи, они на поверхности. Забыть про них сложно. Но есть и другое, скрытое и неизвестное. Это задачи, которые перечислены в «Концепции», по крайней мере в рамках нашей проектной технологии. Задачи иногда простые и технические, иногда сложные — HR, административные, управленческие. Чаще всего мы можем помочь в их выполнении, и чаще всего заказчик говорит «нет, я сам справлюсь». Мы не просто перечисляем задачи заказчика, но и фиксируем: Например, нескольких задач из реальной концепции реального проекта. А если задачи не делать? Так бывает, если мы не обеспечили надлежащий контроль и давление. Подходим к запуску, а изменения которые были согласованы, не выполнены: Каждый кто хотя бы раз запускал новую систему знает, это стресс. «Натягивание» информационной системы, разработанной под новые процессы, на организацию со старыми процессами — двойной стресс. Не сказать, чтобы это было невозможно. Но это очень больно. Что если проект автоматизации в разгаре, подрядчик вовсю «пилит» вашу новую учетную систему, а у вас нет никакого списка изменений, которые нужно сделать? Возможны три варианта: Мы добавляем в план проекта задачи заказчика. И там не только задачи типа «предоставить доступ», «дать обратную связь на документ». Там зафиксированы также задачи, связанные с изменениями в бизнесе, которые необходимо выполнить к какой-то вехе в проекте, например: Теперь идя по плану проекта, смотря на него на каждой статус-встрече, в начале каждого этапа, и мы и заказчик видим критичные для проекта изменения. Мы спрашиваем нашего клиента, сделал ли он уже свою задачу 1, задачу 2 и начал ли делать задачу 3? Если необходимо, мы выделяем отдельного специалиста со своей стороны, который может помочь с различными изменениями: выступить клиенту бизнес-консультантом, семейным доктором, трекером. Мы напоминаем про риски, про проблемы, которые будут у нас (и у клиента), если эти изменения не реализовать. Настаиваем, напоминаем, требуем. Если вы в своем проекте остались с изменениями наедине — придется требовать их с себя самим. Не забывайте про организационные изменения. Управляйте ими. Желаем вам проектов не просто успешных, а максимально гладких.

Задачи клиента — какие они могут быть


Проект есть, а изменений нет

Наличие плана — уже отлично. Но недостаточно