Сбор требований при внедрении 1С:ERP

Автор: Дмитрий Изыбаев, руководитель проектов, IT-компания Lad

C чего начинается каждый проект внедрения 1С:ERP? Знакомство с заказчиком, аудит бизнес-процессов, предпроектное обследование, интервью с владельцами процессов и ключевыми пользователями? Важное место в этом ряду занимает сбор требований.

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

Требования: определение, типы, характеристики

Под «требованиями» на проектах 1С понимают:

  1. Функционал, который позволяет пользователям решать рабочие задачи.
  2. Ожидания ключевых стейкхолдеров относительно результатов проекта.
  3. Документ, в котором описаны собранные требования: например, «Отчет об обследовании», «Техническое задание к проекту», «Матрица функциональных требований».

В зависимости от того, какие параметры проекта описывают требования, можно выделить:

  1. Функциональные: описывают ключевую бизнес-функцию.
  2. Управленческие: описывают организационные и административные аспекты — NDA, уровни доступа к информации, регулярность проведения встреч, договорные обязательства, опыт и компетенции проектной команды, стандарты ведения документации.
  3. Эргономические: описывают удобство работы пользователей — количество кликов при оформлении операций, интерфейс рабочих мест, внешний вид документов, справочников.
  4. Архитектурные: описывают архитектуру конфигурации и проекта в целом — формат разработки, серверы, структура объектов.
  5. Интеграционные: описывают взаимодействия с внешними системами.

На проектах внедрения 1С:ERP важно, чтобы все участники трактовали требования однозначно. Формулируя требования, проверяйте их на соответствие четырем характеристикам:

Характеристика

Правильно

Неправильно

Выполнимость

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

После внедрения проекта продажи должны увеличиться на 1 000 000%

Однозначность Обмен с «Честный ЗНАК» по типовым API-протоколам Реализовать обмен со всеми EDI-провайдерами
Проверяемость План продаж должен рассчитываться аналогично примеру Excel Детальный план производства рассчитывается в системе автоматически
Детальность Печатная форма «Маркировка сырья» адаптирована под размер 40х50 мм Печатные формы должны быть адаптированы под принтеры

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

Как разложить требования «по полочкам»

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

Где вести учет требований? На небольших проектах, где работают 3-5 консультантов, удобно работать в Google документах с возможностью совместного редактирования. Если на проекте 10-20 аналитиков или несколько проектных команд, лучше использовать специализированные инструменты: 1С:СППР, Битрикс24.

Большой проектной командой мы собрали требования с большого количества сотрудников заказчика. Что дальше с ними делать? Выявить взаимосвязи, которые также бывают разными:

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

Зачем собирать требования и управлять ими

Будет правильно, если заложить прочный фундамент и уже с первых этапов подготовить успешный финал проекта.

Грамотно собранные требования позволят нам:

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

Не забываем, что собранные перед началом проекта требования — это хоть и фундамент, но не монолит: они могут изменяться по мере протекания проекта. Мы это помним и не игнорируем, а потому своевременно корректируем требования, удаляем старые и регистрируем новые.


6531

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.