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