Свяжитесь с нами
Или мы Вам перезвоним
Заказать звонок
Нажимая на кнопку, я даю согласие на обработку персональных данных в соответствии с Политикой конфиденциальности
Спасибо, Ваше обращение принято!
Мы свяжемся с Вами в самое ближайшее время.
Личный кабинет
Уже были у нас? Войти
Спасибо, Ваше обращение принято!

Мы свяжемся с Вами в самое ближайшее время.

Мы Вам перезвоним
Нажимая на кнопку, я даю согласие на обработку персональных данных в соответствии с Политикой конфиденциальности
Внедрение, сопровождение, интеграция 1С:Предприятия
+ 7 (812) 325-40-45
Заказать звонок

Успешные практики повышения оперативности управления проектами при сохранении качества внедрения 1С

В статье мы проанализируем плюсы и минусы популярных методологий управления проектами и наш опыт их оптимизации, приведем примеры успешных кейсов.

В первую очередь мы подразумеваем проекты внедрения крупных систем: 1С:ERP, 1С:Комплексная автоматизация, 1С:Управление холдингом. Методы гибкой разработки, по нашему опыту, дают слабый результат, так как такие системы требуют комплексного сбора потребностей по сквозным аналитикам и параметрам учета, а значит и комплексной реализации.

В этой связи растет запрос на более оперативные методы управления при сохранении качества внедрения программных продуктов. Причины роста такой потребности:

  • Большие сроки проектов

  • Значительные бюджеты проектов

  • Длинный путь до получения осязаемого результата

  • Высокие риски получить систему, которая не отвечает запросу заказчика

  • Высокая изменчивость внешней и внутренней среды

Существующие методологии управления проектам по автоматизации

Во внедрении систем 1С обычно используются следующие методологии:

"Водопад" – классический метод управления проектами 

Внедрение системы идет по этапам из-за чего схема напоминает собой водопад:

Методология Водопад

На схеме отражены этапы:

  • Подготовка проекта, сбор требований, иногда называют обследованием

  • Проектирование – моделирование, создание прототипа будущей системы

  • Реализация – разработка и доработка системы, ее настройка

  • Подготовка к опытно-промышленной эксплуатации (ОПЭ) – интеграция с системами, перенос данных

  • Опытно-промышленная эксплуатация – работа в системе в тестовом режиме

  • Переход в промышленную эксплуатацию (ПЭ) – устранение замечаний

  • Промышленная эксплуатация

Плюсы методологии "Водопад":

  • Все шаги четко зафиксированы, имеют строгую последовательность и регламентированный результат,

  • Высокая гарантия получаемого результата,

  • Низкий риск ошибок,

  • Полная и достоверная документация по всему жизненному циклу проекта.

Минусы методологии "Водопад":

  • Долгий срок внедрения из-за чего бюджет проекта оказывается большим,

  • Сложно управлять изменениями за счет долгих согласований.

Методы гибкой разработки: Agile, SCRUM и другие 

Они предполагают работу короткими циклами, которые обычно длятся две-три недели.

Плюсы гибкой разработки:

  • Быстрое получение первых результатов,

  • Удобно управлять изменениями в проекте.

Минусы гибкой разработки:

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

  • Большой объем переделок и изменений в течение проекта ведет к сложностям в прогнозировании достигаемого результата.

Поблочный запуск

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

Плюсы поблочного запуска:

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

Минусы поблочного запуска:

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

Запуск в формате MVP

Запускается типовая или минимально доработанная система под специфику предприятия, а улучшения вносятся уже при эксплуатации системы.

Плюсы формата MVP:

  • Небольшой срок окупаемости инвестиций за счет быстрой автоматизации большей части компании.

Минусы формата MVP:

  • Часть потребностей компании на старте не учитывается, так как она дорабатывается в процессе эксплуатации.
  • Частое переучиванию пользователей по мере развития функционала и необходимости корректировки данных.
  • Появляются временно не автоматизированные сотрудники и даже отдельные области учета.

Наш опыт оптимизации методологий управления проектами внедрения 1С

В нашей практике мы пошли в сторону оптимизации методологии Водопада. К новым методам мы выставили следующие требования:

  • Сохранение всех преимуществ "Водопада"

  • Оптимизация сроков и стоимости проекта

  • Повышение прозрачности этапов проекта

  • Ускорение получения осязаемого и понятного результата

  • Упрощение управления изменениями

При этом поставили несколько ограничений:

  • Сохранение комплексного подхода к проекту

  • Сохранение «документального следа» проекта

  • Недопущения роста бюджета проекта по сравнению с использованием обычной методики водопада.

Оптимизация методологии "Водопад"

В своей работе мы выявили и применили несколько способов оптимизации, они представлены на схеме ниже.

 Оптимизация методологии Водопад

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

 Мы выделили следующие виды оптимизации, которые применяем в своей работе:

  1. Объединение этапов подготовки проекта и проектирования. Специалисты идут по блокам системы последовательно, одновременно создавая и описывая концепт будущей системы.

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

  3. Вариант объединяет два предыдущих: после краткого сбора требований для определения ландшафта бизнес-процессов заказчика, в рамках единого потока ведется работа по уточнению требований заказчика, формированию модели будущей системы и определяются требования к системе. По итогам формируется документ "Проектное решение", который полностью описывает процесс со всеми предъявляемыми требованиями.

  4. Документ "Концептуальная модель" сразу пишется так, чтобы далее его можно было использовать как инструкции для пользователей (с незначительными доработками).

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

Рассмотрим подробнее каждый вариант оптимизации и опыт их применение на наших проектах.

Объединенный этап подготовки и проектирования

Плюсы:

  • Снижение затрат и срока первых двух этапов.

  • Уменьшение количества промежуточных, служебных документов.

  • Получение целевого видения системы в два-три раза быстрее.

Минусы:

  • Падение детализации конечного документа. Это сказывается, если в системе нужны доработки.

  • Уменьшение промежуточных документов, сложность с отслеживанием первоисточника – этот момент также является минусом, поскольку не всегда возможно установить источник данных и могут возникнуть разные интерпретации данных.

  • Необходимость уточнения отдельных механизмов перед написанием технических заданий

Успешный кейс:

Этот метод мы применяли на проекте для заказчика «ОМБ» (фармацевтика). В итоге, за полтора месяца была собрана, систематизирована и подготовлена к реализации информация по внедрению ключевого блока системы заказчика. При стандартном подходе весь процесс мог бы занять 3-4 месяца.

Объеденный этап моделирования и формирования технического задания

Плюсы:

  • Конечная документация представляет собой полное описание бизнес-процесса заказчика в системе.

  • Уменьшение времени до передачи системы в разработку.

Минусы:

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

  • Потребность в наличии в команде заказчика специалиста, знакомого с продуктами 1С и документацией на разработку.

Успешный кейс:

На проекте АО «Птицефабрика «Северная» формирование технических заданий на специфические доработки выполнялось одновременно с уточнением требований и моделированием в системе окружения данной доработки.

Это позволило нам сократить время на формирование прототипа системы и передать в разработку на полтора месяца раньше, чем при классическом "Водопаде".

Объеденный этап обследования, моделирования и формирования технического задания

Плюсы:

  • Высокая вовлеченность заказчика во все три ключевых этапа проекта, поскольку они идут одновременно.

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

  • Уменьшение времени и затрат: нет долгих согласований и больших документов между этапами.

Минусы:

  • Увеличение трудозатрат на разработку. Документ "Проектное решение" больше описывает процессы, а не технические характеристики, которые не влияют на функционал, но важны разработчикам. Поэтому они тратят дополнительное время на уточнение.

  • Заказчик определяет только функциональность, но не интерфейс – эта часть остается на стороне разработчиков.

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

Успешный кейс:

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

Реализация моделирования как основы для инструкций

Плюсы:

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

Минусы:

  • Необходимость уточнения текста документа после реализации доработок.
  • Излишняя подробность документа «Концептуальная модель» создает сложности для восприятия с точки зрения целостной работы системы.

Успешный кейс:

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

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

Привлечение IT-службы заказчика к работам

Плюсы:

  • Снижение затрат на проект, поскольку часть задач IT-служба заказчика берет на себя.
  • Повышение вовлеченности команды проекта.
  • Повышение качества обратной связи на выполняемые доработки.
  • Повышение качества итогового результата.
  • Улучшения качества взаимодействия команд.

Минусы:

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

Успешный кейс:

Данный метод оптимизации мы использовали на проекте АО «СПАРК». Это позволило снизить затраты на 14%, а также повысить вовлеченность команды заказчика в проект. Это важно, поскольку АО «СПАРК» – большая компания со сложными процессами и многоуровневой системой согласования. Такое привлечение IT-службы позволило создать Центр Компетенции по системе у заказчика: уже на этапе разработки сотрудники понимали, как работают доработки и как с ними обращаться.

Выводы

  • При гибком подходе к использованию методологии "Водопад" можно существенно повысить эффективность проектного внедрения.
  • Предлагаемые варианты оптимизации позволяют сократить срок и затраты на ведение проекта.
  • Предлагаемый нами подход позволяет варьировать используемые методы, отталкиваясь от потребностей, возможностей и готовности заказчика.
  • Использование оптимизированной методологии позволяет сократить путь до получения конечного результата, что, в условиях высокой изменчивости, может стать ключевым критерием при принятии решения о запуске проекта автоматизации, а также по внесению изменений.
  • Наш опыт использования оптимизированной методологии показывает, что её применимость допустима, а востребованность растет, так как заказчики все чаще не готовы ждать год-полтора до получения первого осязаемого результата. Например, комбинирование оптимизации с методикой поблочного ввода и MVP позволяет сократить срок получения первых рабочих блоков системы до 2-3 месяцев.
  • Нельзя утверждать, что оптимизированная методология подойдет всем заказчикам. Наша цель – предложить оптимальное решение, которое позволит достичь поставленных целей и обеспечит ожидаемый заказчиком результат.