Пугающие изменения. Как мы заставляем клиентов меняться

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

Что за изменения, отсутствие которых может «похоронить» проект, или обеспечить проекту жесткое «трение» при запуске?

Мы давно придерживаемся мнения, что проект автоматизации – это проект организационных изменений. Пишем и говорим об этом постоянно. Пришло время разобраться подробнее, какие они могут быть, и как можно навредить проекту, если их не проводить.

Первый этап любого проекта – бизнес-обследование. В ходе обследования мы проводим глубинные интервью по участкам с ключевыми пользователями, руководителями подразделений. Интервью нужны не для того, чтобы «понять, как настроить 1С», а для того чтобы разобраться в работе компании, ее процессах, ролях и подчиненности сотрудников.

Расхожая фраза «если автоматизировать хаос, получится автоматизированный хаос» - абсолютно правдива. Вне зависимости от выбранного метода проектного управления: классическая каскадная технология, эджайл, или смешанный подход, нужно точно понимать процессы компании и особенности ее работы.

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

Все найденные нами улучшения, изменения, мы фиксируем в несколько списков:

Все эти улучшения мы собираем в отдельный документ – «Концепция решений». В нем и предложения по развитию, и необходимые организационные изменения на стороне заказчика, и предлагаемые варианты архитектуры систем, конфигураций 1С, с обоснованиями, направлениями обменов и так далее.

У команды заказчика в ходе проекта есть работа, в этом мало кто сомневается. Но какая? Первое, что приходит в голову – сделать так чтобы нужные сотрудники пришли на интервью, а затем и на обучение. Почитать документы, дать замечания и обсудить вопросы, и в итоге согласовать. Посмотреть демо прохождения процессов в системе и дать обратную связь. Предоставить доступы к своей инфраструктуре. Предоставить данные для загрузки или параметры для настройки интеграций.

Это все важные задачи, они на поверхности. Забыть про них сложно.

Но есть и другое, скрытое и неизвестное. Это задачи, которые перечислены в «Концепции», по крайней мере в рамках нашей проектной технологии.

Задачи иногда простые и технические, иногда сложные - HR, административные, управленческие. Чаще всего мы можем помочь в их выполнении, и чаще всего заказчик говорит "нет, я сам справлюсь".

Мы не просто перечисляем задачи заказчика, но и фиксируем:

Например, нескольких задач из реальной концепции реального проекта.

А если задачи не делать? Так бывает, если мы не обеспечили надлежащий контроль и давление. Подходим к запуску, а изменения которые были согласованы, не выполнены:

Каждый кто хотя бы раз запускал новую систему знает, это стресс.

«Натягивание» информационной системы, разработанной под новые процессы, на организацию со старыми процессами – двойной стресс.

Не сказать, чтобы это было невозможно. Но это очень больно.

Что если проект автоматизации в разгаре, подрядчик вовсю «пилит» вашу новую учетную систему, а у вас нет никакого списка изменений, которые нужно сделать? Возможны три варианта:

Мы добавляем в план проекта задачи заказчика. И там не только задачи типа «предоставить доступ», «дать обратную связь на документ». Там зафиксированы также задачи, связанные с изменениями в бизнесе, которые необходимо выполнить к какой-то вехе в проекте, например:

Теперь идя по плану проекта, смотря на него на каждой статус-встрече, в начале каждого этапа, и мы и заказчик видим критичные для проекта изменения. Мы спрашиваем нашего клиента, сделал ли он уже свою задачу 1, задачу 2 и начал ли делать задачу 3?

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

Мы напоминаем про риски, про проблемы, которые будут у нас (и у клиента), если эти изменения не реализовать. Настаиваем, напоминаем, требуем.

Если вы в своем проекте остались с изменениями наедине – придется требовать их с себя самим.

Не забывайте про организационные изменения. Управляйте ими. Желаем вам проектов не просто успешных, а максимально гладких.