Собственные разработки в реестре российского ПО Санкт-Петербург · работаем по всей России
ГлавнаяБлогПлан внедрения
Внедрение

План внедрения автоматизации: чек-лист

Что сделать до старта, как разбить работы на этапы и на чем проекты чаще всего срываются.

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

Шаг 1. Определиться, что именно внедряем

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

Формулировка в таком виде решает сразу две задачи. Она позволяет ограничить объем работ — понятно, что входит в первый этап, а что подождет. И она дает критерий приемки: через квартал можно посмотреть на цифру и сказать, получилось или нет.

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

Шаг 2. Назначить ответственного со стороны компании

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

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

Шаг 3. Аудит и описание процесса как есть

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

На этом шаге полезно собрать:

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

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

Шаг 4. Привести в порядок данные

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

Полностью вычищать историю не нужно, это отдельный долгий проект. Достаточно привести в порядок справочники, с которыми пойдет ежедневная работа, и перенести данные за разумный период. Остальное остается в архиве.

Шаг 5. Разбить работы на этапы с приемкой

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

Рабочая разбивка обычно такая:

  • Базовый контур. Основные объекты, формы, права доступа, простой маршрут. Уже можно работать.
  • Интеграции. Обмен с учетной системой, телефония, почта, сайт. Настраивается после того, как контур работает, а не одновременно с ним.
  • Автоматические правила. Уведомления, сроки, эскалации, автосоздание задач. Их пишут по живой практике, иначе половина окажется лишней.
  • Отчетность. В последнюю очередь: считать имеет смысл по данным, которые уже накопились.

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

Шаг 6. Обучение и опытная эксплуатация

Запускать сразу на всю компанию рискованно. Разумнее выбрать одно подразделение или одну категорию операций и поработать так пару недель. За это время вылезают все несостыковки: поля, которые никто не заполняет, маршрут, который не учитывает отпуск согласующего, шаг, о котором забыли рассказать на аудите.

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

Отдельно предупредим: в первые недели работы становится больше. Люди учатся, ошибаются, ворчат и просят вернуть таблицы. Это нормальный этап, а не признак провала, но его нужно закладывать в план и в ожидания руководства. Как мы учим сотрудников, описано отдельно.

Шаг 7. Сопровождение и следующий контур

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

Тогда же имеет смысл смотреть на следующий процесс. Он выбирается сам: это контур, который упирается в соседний. Продажи упираются в остатки — значит следующим идет склад. Склад упирается в поставки — значит снабжение.

На чем срываются проекты

  • Нет ответственного с полномочиями. Решения принимаются неделями, подрядчик ждет, срок плывет.
  • Объем растет по ходу. В процессе выясняется, что «раз уж мы тут», надо еще десять вещей. Лечится фиксацией границ этапа и переносом нового в следующий.
  • Настроили, но не научили. Система есть, работают по-старому. Самый обидный сценарий, потому что деньги потрачены полностью.
  • Автоматизировали то, о чем не договорились. Если не решено, кто отвечает за срок, система просто зафиксирует срыв.
  • Запустили сразу на всех. Ошибки настройки умножаются на количество людей, и доверие теряется в первый же день.

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

Автор статьи
Юлия Руссу Руководитель отдела внедрения, СИР Технологии
Составим план под ваш процесс

Разберем, что автоматизировать первым, разложим работы по этапам с приемкой и назовем сроки. Аудит бесплатный.

Позвонить Telegram-канал