разрезы и строиться не более 3 минут за месячный период по всем организациям». Впрочем, на начальном этапе сбора списка требований от заинтересованных сотрудников подойдут любые формулировки, они впоследствии будут уточняться и войдут в технические задания уже конкретными и формальными, иначе их просто нельзя будет сделать (программисту и настройщику системы сложно оперировать абстрактными понятиями).
Можно разделить требования к системе на три уровня:
● Есть глобальные цели автоматизации, которые, как правило, озвучивают спонсоры проекта (собственники бизнеса). Это что-то типа: повысить производительность/оборачиваемость, сократить запасы/издержки и т. д.
● Есть задачи линейных руководителей (снабжение, производство и т. д.), как правило, это какие-то функциональные блоки, глобальные консолидированные отчеты, доп. аналитика.
● Требования рядовых пользователей: интерфейсы, кнопки, отчеты, печатные формы, конкретные рабочие места.
При выборе системы крайне важно понимать цели и задачи руководителей, а детальные требования будут сформулированы уже на уровне ТЗ. К сожалению, часто встречаются предпроектные обследования или ТЗ, где большое внимание уделено мелочам («в системе необходима возможность вести справочник номенклатуры») и нет ключевых целей и задач самого проекта и системы автоматизации.
Сводный список требований должны составлять понимающие в вопросах автоматизации и бизнес-процессах компаний специалисты. Такого ответственного нужно еще найти. Возможно, что среди сотрудников компании его нет вовсе и нужно нанимать или привлекать внешних специалистов.
На практике встречается: поручить просто секретарю собрать все требования к системе по электронной почте со всех отделов в единый файл, без дополнительного анализа и формализации специалистом. Такие требования будут носить разрозненный характер, кто-то опишет свои потребности в автоматизации подробно, кто-то только «больные места» сегодняшнего дня. В любом случае в таких письмах будет не формализованное описание для передачи третьей стороне (участникам тендера по выбору ERP-системы), а описание для внутренних нужд, исходя из понимания реалий бизнеса и бизнес-процессов отделов в частности. То есть еще не факт, что такие описания даже в соседнем отделе поймут, если отделы достаточно независимы и, например, в холдинге это разные бизнес-единицы со своими юридическими лицами и удаленными офисами. А ожидается, что список требований поймут потенциальные исполнители будущего проекта внедрения. Собранную информацию (пусть и с помощью секретаря, которая всех знает и у всех все запросит) нужно переработать и формально описать в сводный список для передачи третьим лицам для организации тендера. При этом нужно сохранить информацию об изначальном авторе требования (не для передаче третьей стороне, а для внутренних нужд): это понадобится для последующих уточнений по требованию от исполнителей или согласования отмены либо переформулировки требования в процессе его анализа.
Полноценный и формально описанный список функциональных
