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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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