Внедрение 1С. Почему так долго?

Сегодня мы обсудим важную составляющую любого проекта автоматизации – длительность, время которое проходит от старта до запуска.Каждую неделю мы встречаемся с самыми разными компаниями – нашими будущими клиентами. Обсуждаем с ними их задачи и цели, возможные сроки и бюджеты проектов, путь, которым можем пройти.Угадать два самых частых вопроса несложно.1. Почему это столько стоит?2. Так почему это так долго?Попробуем разобрать второй вопрос – почему проект внедрения 1С это так долго, что влияет на длительность и можно ли ее сократить?

Для начала разберемся с определениями.

Длительность проекта – время между стартом проекта и его завершением. Измеряется в месяцах или иногда годах. Проект завершается, как правило, передачей внедренного решения на поддержку внешней организации или внутреннему подразделению, ИТ-отделу. Учетная система, в которой работают пользователи, сдается раньше, чем завершается проект.

Срок завершения проекта – дата, когда проект должен быть завершен. Обычно не так важен, как «срок запуска».

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

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

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

Обследование.
Моделирование.
Реализация (настройка системы, доработки, интеграции).
Подготовка инструкций, обучение и пробный запуск.
Запуск и опытная эксплуатация.

Этап «Обследование» в свою очередь, состоит из:

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

И далее каждый следующий этап складывается из задач которые необходимо сделать. При расчете длительности обязательно помним про задачи Заказчика – без них проект не получится:

Встречи с ключевыми сотрудниками – ушел в отпуск коммерческий директор, а с ним встреча по графику стояла. Плюс неделя к сроку.
Прочтение документов и обратная связь на них. В договоре написано 5 рабочих дней, но кто смотрит на договор?
Принятие решений. Иногда в проекте заказчику нужно решить – делать так, или так. И кроме него никто не решит, а он не может решиться.

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

Давайте пропустим этап Х, и перейдем сразу к этапу Y.

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

Можно ли выполнить этапы не последовательно, а параллельно?

Скорее нет, чем да. Для того чтобы делать модель, нужно иметь согласованные процессы. Для того чтобы делать доработки, нужны согласованные требования. Для того чтобы загружать данные, нужно чтобы база уже была настроена.

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

А если увеличить число специалистов, работающих одновременно?

Заманчивая идея, если позволяет бюджет – «нагнать» толпу программистов, аналитиков… Но есть разумные ограничения численности специалистов, занимающихся любой задачей. Каждый новый человек, добавленный в команду, добавляет и усилия на синхронизацию работы, контроль, время нужное на взаимодействие с остальными участниками.

Два плиточника действительно справятся быстрее чем один с отделкой ванной комнаты. А вот пятеро – будут больше мешать друг другу, ругаться и спорить, чем работать.

Есть исключения, о них поговорим ниже, в разделе «как сделать проект быстрее».

Сначала подумаем, а нужно ли его вообще ускорять? Сокращение срока почти всегда ведет к росту рисков, и росту стоимости проекта. В каких случаях реально нужно «резать сроки»:

Наша учетная система в полночь превратится в тыкву. Например, иностранные «партнеры» отключат SAP.
У нас есть только одно затишье в году, и оно через 3 месяца.

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

Но если действительно нужно сжимать срок, то можно:

Уменьшить объем своих пожеланий – обсуждать с подрядчиком, что из «хотелок» существенно влияет на сроки и отказываться от всего не критически нужного.
Насколько возможно ускориться в проекте самим – быстрее читать документы и давать обратную связь, собираться настолько часто, насколько это необходимо. В целом быть более погруженными, быстрее принимать решения.
Предложить подрядчику свои ресурсы (включили этот пункт, так как этот вариант существует). Он применим редко, к сожалению, штатные специалисты обычно загружены поддержкой текущих систем. А еще для подрядчика довольно сложно встроить сторонних программистов, аналитиков, в свою систему планирования и отчетности.
Предупреждать своего подрядчика об обстоятельствах, влияющих на сроки с вашей стороны: выставки, отпуска, командировки ключевых пользователей. Если подрядчик будет знать об этом заранее, возможно он сможет уменьшить последствия для сроков проекта, например, переставив работы в плане. Если он узнает об этом последним, скорее всего его команда будет простаивать, а проект – растягиваться.
Обсудить с подрядчиком экспериментальные, альтернативные и рискованные пути запуска проекта. Мы в качестве «эксперимента» в одном из проектов совместили этапы «моделирование» и «реализация». Заказчику были очень критичны сроки. Получилось хорошо (срок проекта 4 месяца вместо 9). Из минусов – огромные затраты времени Заказчика. Ежедневные рабочие встречи, ежедневные статусы, одновременно и подготовка данных, и прочтение документов, и посещение демо. Любой сбой – «разваливает» план.

Напомним, у любого проекта есть 3 основных ограничения: объем проекта, срок и бюджет. Вы можете зафиксировать критичную для вас дату запуска новой системы, и как следствие срок проекта. Договориться со своим подрядчиком о том, что именно срок – критически важен.

При этом, все остальное должно быть подчинено сроку:

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

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

Если все потенциальные партнеры, к которым вы пришли за оценкой своего проекта, называют ваши сроки нереальными, возможно, они действительно нереальны. Скажете, кто не рискует, тот не пьет шампанского?

Не всегда риск сопровождается «питием шампанского». Иногда – загубленным проектом, потраченными зря деньгами и временем, и болью пользователей. Девять женщин за месяц ребенка не родят. Даже если им заплатить.

Успешных вам проектов

Из чего складывается длительность проекта?

Неправильные варианты сокращения сроков проекта

Как же все-таки сделать проект быстрее?

Вместо завершения