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