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

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

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

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

Откуда берутся изменения

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

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

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

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

1. Идеи (просто идеи что можно улучшить, хочешь бери, хочешь нет)
2. Рекомендации (мы уверены, что эти изменения нужны заказчику, хотя и не относятся к нашему проекту)
3. Задачи клиента (изменения, которые необходимо выполнить, чтобы автоматизация принесла пользу и вообще «взлетела»)

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

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

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

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

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

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

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

1. Какая цель будет достигнута ее решение (зачем)
2. Какие риски сработают при не выполнении задачи (а что если не делать)
3. И что конкретно нужно сделать в рамках решения задачи — шаги

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

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

1. Нужные люди не наняты
2. Изменения в процессах не приняты и не внедрены (регламентами и так далее)
3. Нет инфраструктуры — не куплены компьютеры, терминалы, нет сети на точках и прочее

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

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

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

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

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

1. Изменения не нужны. Вы в явном виде поставили задачу — автоматизировать ровно то, что есть сейчас, никаких улучшений не будет, как сейчас люди работают, так и будут. Ничего не меняется, только вместо «системы Х» будет 1С. Возможно, у вас идеальная компания с идеальными процессами?
2. У вас идет проект внедрения регламентированного учета. Такой учет (зарплата, кадры, бухгалтерский отчет и отчетность) достаточно жестко регламентирован государством. Бухгалтеры, расчетчики, кадровики знают свои обязанности, если вам повезло с ними. И выполняют их одинаково хоть в 1С, хоть в БЭСТ или другой системе. Часто тут не нужно ничего перестраивать.
3. Ваш партнер про изменения не подумал. Ну что же, в таком случае вам предстоит их самостоятельно найти. Посмотрите на отчет об обследовании, если он у вас есть, сравните схемы процессов, ролевую матрицу, список задач сотрудников с тем, как оно у вас происходит сейчас. Составьте список различий, и возьмите в работу — если хотите облегчить жизнь своему подрядчику, а главное себе во время внедрения.

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

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

1. К прогону бизнес-процесса А на готовой системе
2. К моменту начала обучения
3. К началу загрузки данных
4. К дате запуска системы
5. И так далее

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

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

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

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

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