Стратегия анализа в проектах внедрения ERP-систем

Подробности

Опубликовано: 02.04.2018 09:00

Автор: Терентьев Илья Михайлович

Просмотров: 2810

Аннотация: в статье описываются способы анализа, приоритизации и оценки требований. Подчеркивается целесообразность применения прототипирования и демонстрации работающей системы для идентификации требований. Рассмотрены подходы приоритизации потребностей, критичными являются те требования, которые относятся к законодательным или обеспечивают непрерывность бизнеса. Проанализированы способы оценки требований на основе метода Оценщика и экспертной оценки. Сформировано содержание стратегии анализа, заданное методами выявления и оценки бизнес требований.
Скачать: PDF (статья), PDF (выпуск №2).
Ключевые слова: анализ бизнес требований, базовые требования к ERP-системе, fit gap анализ, гэп анализ, RICEFW SAP, воркшопы по SAP, анализ требований к программному обеспечению, сбор и анализ требований к программному продукту, разработка требований к программному обеспечению, пользовательские требования, сбор требований к ПО, разработка требований к ПО, управление требованиями, выявление требований, трассировка требований, прототип ИТ продукта, MVP продукта.

Введение

Несмотря на то, какая методология лежит в основе внедрения корпоративной информационной системы, будь то каскадная, итерационная или спиралевидная, этап анализа требований является одним из первых и наиболее критичных [1]. В рамках этапа анализа выявляются наборы требований, предъявляемых бизнес-пользователями к разрабатываемой системе, ведется их приоритизация для понимания наиболее важных, а также фиксация объема проекта.

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

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

Цель и задачи

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

• обзор способов выявления требований;
• документирование и обработка требований;
• проведение Fit/Gap-анализа;
• классификация требований по RICEF;
• подготовка стратегии анализа.

1. Идентификация требований

Несмотря на то, что доступно множество методов для идентификации требований, не все из них применимы (рис. 1). Основным вспомогательным средством, конечно же, является наличие опыта реализации схожих ERP-проектов, так как типовые отраслевые требования от компании к компании близки. Спасает в этих случаях и использование референтных отраслевых моделей, описывающих ключевые бизнес-процессы, а значит и требования к ним. В любом случае речь идет о базе знаний исполнителя, содержание которой можно применить в ходе обработки требований [2].

Проведение опросов достаточно редко используется в ERP-проектах, если и применяется, то, как шаг перед проведением более детального анализа. Нередко опросники используются в проектах формирования технико-экономического обоснования для имплементации ERP-системы, но не более. К наиболее действенным механизмам выявления требований можно отнести прототипирование и демонстрацию работающей системы. Под прототипом понимают усеченную версию приложения для показа ограниченного набора изолированных процессов, подпрограмм и данных. В зависимости от типа прототипа, а они бывают эволюционными и одноразовыми, определяется потребность в его дальнейшем использовании и развитии до готового продукта или уничтожении. Прототип программы позволяет уточнить требования к разрабатываемой системе, в случае высокой степени бизнес-неопределенности [3].

Рис. 1. Способы анализа требований

Демонстрация работоспособной версии программы всегда выглядит выигрышно, так как пользователи имею возможность увидеть прообраз будущей программной системы намного раньше этапа ее реализации. Показ может вестись непосредственно самой программы или копий пользовательских экранов всех программ. Важно, что выполняется обзор всех процессов, связанных между собой E2E-цепочкой. В ходе демонстрации и дискуссий определяются требования, которые фиксируются в реестре требований. В зависимости от методологии внедрения ERP-системы реестр может называться матрицей отслеживания требований, бэклогом продукта или бэклогом спринта. Ограничимся рассмотрением каскадной методологии имплементации корпоративных информационных систем, в которой применяется первая формулировка.

2. Матрица отслеживания требований

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

• проведение Fit/Gap-анализа;
• RICEF-классификация разработок;
• предложение концепции решения;
• и/или оценка трудозатрат разработки.

Рис. 2. Пример части матрицы отслеживания требований

Fit/Gap-анализ позволяет понять, реализовано ли уже текущее требование в коробочном ERP-решении или требуется его донастройка или доработка. В первом случае потребность маркируется как Fit, во втором – Gap. В дальнейшем для каждого требования, относящегося к категории Gap, предлагается верхнеуровневое концептуальное решение, а также определяются следующие параметры:

• RICEF-тип, где R задает разработку вида отчет, I – интерфейс, С – программу миграции, F – печатную форму, F – расширение функционала предыдущих четырех типов. Нередко также добавляют атрибут S, характеризующий не разработку, а настройку системы;
• сложность, подразумевающая значения низкая, средняя и высокая;
• процент переиспользования, когда одно программное решение может быть реализовано с частичным использованием другого.

Тройка «RICEF – сложность - %-переиспользования» позволяет определить плановые трудозатраты, необходимые для подготовки функциональных спецификаций и их разработки или документов настроек и их конфигурации, на базе эмпирически подобранных значений. Таким образом, оценка всех разработок и настроек ведется унифицированным способом, который часто называют методом использования Оценщика. Альтернативой является независимое экспертное оценивание каждого требования, для которого не требуется знание тройки вышеприведенных параметров.

Матрица отслеживания может содержать сотни, а то и тысячи требований. Процедура оценивания позволяет определить ожидаемые трудозатраты, необходимые для реализации этих требований. Если ERP-проект ведется по контракту фиксированной цены (Fix Price), то выполняется сравнение изначальных требований из технического задания с их обновленной интерпретаций по результатам анализа, т.е. рассчитывается разница плановых и фактических трудозатрат. Образовавшаяся отрицательная разница является следствием нашей недооценки требований в ходе подачи коммерческого предложения, что обычно компенсируется величиной погрешности, увеличивающей стоимость изначального проекта для заказчика. В проектах вида «Время и материалы» (Time and Material) подобная ситуация не столь значима.

3. Приоритизация потребностей

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

Заключение

Так что же для нас будет представлять стратегия анализа? Зададим ее следующими параметрами, которые мы детально рассмотрении в материале выше:

• способ выявления требований, подразумевающий прототипирование или демонстрацию системы;
• метод оценки требований, в частности на основе экспертной оценки или Оценщика. Случай применения Оценщика подразумевает под собой выполнение Fit/Gap-анализа, а также RICEF-классификации.

В данной работе подчеркивается целесообразность сбора требований путем демонстрации схожей системы в онлайн или офлайн режимах. Офлайн режим подразумевает показ копий экранов критичных подпрограмм для формирования раннего представления о будущей системе. Поясняется критичность отнесения каждого из требований к категории Fit или Gap, для Gap-требований в последующем проводится RICEF-классификация. Упоминается расширение общеизвестной классификации программных разработок стратой настроек. Тем самым финальная классификация будет выглядеть как RICEFS, где параметр S определяет настройку.

Стратегия анализа, определяющая способы проведения анализа, порядок приоритизации требований, детали проведения Fit/Gap-анализа, а также классификации разработок согласно RICEFS-подходу, позволяет более структурированно подойти к вопросу формирования состава работ и предварительного их планирования. Документ стратегии готовится на ранних этапах реализации ERP-проекта: обычно на фазе подготовки к проекту, следуя общему принципу необходимости существования накануне старта той фазы, где она может потребоваться. 

Литература 

1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
2. Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. – 2015. – т.87, №3. – c.180-191. – URL: https://stepanovd.com/science/30-article-2015-1-erpappl.
3. Степанов Д.Ю. Бизнес и технологическая неопределенности в проектах имплементации корпоративных информационных систем на основе каскадной и многопроходных моделей внедрения // Высокопроизводительные вычислительные системы и технологии. – 2021. – №2 (66). – c.118-128. – URL: https://stepanovd.com/science/article/110-2021-2-uncertanties.

Выходные данные статьи

Терентьев И.М. Стратегия анализа в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2018. – №2 – С. 23-29. – URL: https://corpinfosys.ru/archive/issue-2/139-2018-2-analysisstrategy.

Об авторе

Терентьев Илья Михайлович – эксперт по системам управления складами. Сертифицированный консультант SAP по модулю управление материальными потоками. Принимал участие более чем в 10 проектах имплементации корпоративных систем. Имеет обширный опыт внедрения складских систем в проектах «с нуля», а также тиражирования. Регулярно издает статьи в электронно-сетевом журнале «САПер». Электронный адрес: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №2

1. Стартапы;
2. Стратегия реализации в проектах КИС;
3. Управление изменениями в проектах ERP-систем;
4. Стратегия анализа в проектах внедрения ERP-систем;
5. Использование SQL-запросов при подготовке спецификаций.