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