Главное Авторские колонки Вакансии Образование
Выбор редакции:
249 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

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

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

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

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


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

Первый этап любого проекта — бизнес-обследование. В ходе обследования мы проводим глубинные интервью по участкам с ключевыми пользователями, руководителями подразделений. Интервью нужны не для того, чтобы «понять, как настроить 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?

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

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

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

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

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.