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