Введение
Несмотря на то, какая методология лежит в основе внедрения корпоративной информационной системы, будь то каскадная, итерационная или спиралевидная, этап анализа требований является одним из первых и наиболее критичных [1]. В рамках этапа анализа выявляются наборы требований, предъявляемых бизнес-пользователями к разрабатываемой системе, ведется их приоритизация для понимания наиболее важных, а также фиксация объема проекта.
В случае использования гибких методологий внедрения, построенных на базе итерационной или спиралевидных моделях имплементаций ERP-систем, процедура сбора требований может повторяться неоднократно, что кардинально отличает их от классической каскадной модели. Здесь нет противоречия, так как многопроходные и однопроходная модели решают принципиально разные задачи и ориентированы на отличные способы выстраивания фаз проекта, включая анализ требований.
Критичность фазы анализа состоит еще и в том, что полученные результаты этого этапа применяются в последующих активностях проектирования системы, где требования лишь уточняются и детализируются, но не идентифицируются с нуля. Таким образом, нужна адекватная стратегия, описывающая порядок анализа требований, получаемые результаты и заинтересованных сторон.
Цель и задачи
Цель статьи состоит в рассмотрении процедуры анализа требований в проектах внедрения ERP-систем. Полученные результаты позволяют эффективно внедрять ERP-системы, следуя изначальному план-графику проекта. Выполним следующие задачи для реализации поставленной цели:
- обзор способов выявления требований;
- документирование и обработка требований;
- проведение Fit/Gap-анализа;
- классификация требований по RICEF;
- подготовка стратегии анализа.
1. Идентификация требований
Несмотря на то, что доступно множество методов для идентификации требований, не все из них применимы (рис. 1). Основным вспомогательным средством, конечно же, является наличие опыта реализации схожих ERP-проектов, так как типовые отраслевые требования от компании к компании близки. Спасает в этих случаях и использование референтных отраслевых моделей, описывающих ключевые бизнес-процессы, а значит и требования к ним. В любом случае речь идет о базе знаний исполнителя, содержание которой можно применить в ходе обработки требований [2].
Проведение опросов достаточно редко используется в ERP-проектах, если и применяется, то, как шаг перед проведением более детального анализа. Нередко опросники используются в проектах формирования технико-экономического обоснования для имплементации ERP-системы, но не более. К наиболее действенным механизмам выявления требований можно отнести прототипирование и демонстрацию работающей системы. Под прототипом понимают усеченную версию приложения для показа ограниченного набора изолированных процессов, подпрограмм и данных. В зависимости от типа прототипа, а они бывают эволюционными и одноразовыми, определяется потребность в его дальнейшем использовании и развитии до готового продукта или уничтожении. Прототип программы позволяет уточнить требования к разрабатываемой системе, в случае высокой степени бизнес-неопределенности [3].
Рис. 1. Способы анализа требований
Демонстрация работоспособной версии программы всегда выглядит выигрышно, так как пользователи имею возможность увидеть прообраз будущей программной системы намного раньше этапа ее реализации. Показ может вестись непосредственно самой программы или копий пользовательских экранов всех программ. Важно, что выполняется обзор всех процессов, связанных между собой E2E-цепочкой. В ходе демонстрации и дискуссий определяются требования, которые фиксируются в реестре требований. В зависимости от методологии внедрения ERP-системы реестр может называться матрицей отслеживания требований, бэклогом продукта или бэклогом спринта. Ограничимся рассмотрением каскадной методологии имплементации корпоративных информационных систем, в которой применяется первая формулировка.
Полный текст статьи: https://corpinfosys.ru/archive/2018/issue-2/139-2018-2-analysisstrategy
