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

Начнем с основ: потребности заказчика в информационной системе покрываются или ее доработкой, или ее донастройкой, или уже реализованы и не требуют дополнительных усилий. Первые два исхода задают Gap-область, последняя – Fit (рис. 1). Все доделки Gap-области можно классифицировать согласно RICEFS подходу [2], что представляет собой сокращение от англоязычных слов: Report, Interface, Conversion, Enhancement, Form и S (отчет, интерфейс, программа обработки данных, расширение, печатная форма и настройка). Введя термин сложности (низкая, средняя, высокая и очень высокая), можно построить элементарный Оценщик (от английского Estimate, оценивать) [3]. В нем для каждой пары «Тип разработки – сложность» эмпирически задаются плановые трудозатраты для этапов проектирования и разработки, то есть ресурсы функциональных консультантов на фазе дизайна и разработчиков для этапа разработки (табл. 2). Более сложные формы оценщика включают дополнительные параметры: новая разработка или модификация имеющейся, %-переиспользования, а также оценку трудозатрат не только для фаз проектирования и реализации, но и этапов анализа, теста и перехода.

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

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

Трудозатраты = Трудозатраты(сложность) * (1 + (N-1)*%– переиспользования),

где Трудозатраты(сложность) – затраты в зависимости от сложности согласно Оценщику, N – число оргуровней, %-переиспользования аналогичен схожему параметру при оценке разработок и принимает значение 50% по умолчанию (см. табл. 3, требование 14). Если сложность для разных оргуровней сильно отличается, то предлагается поступить так же, как и в случае с разработками: разбить группы настроек по оргуровням в разрезе сложности и оценить их по формуле выше независимо (см. табл. 3, требований 3.1-3.2).

Оценке трудозатрат по указанной схеме подлежат как пользовательские требования из технического задания (ТЗ), так и функциональные потребности, которые могут отсутствовать в документе ТЗ. Функциональные требования, представляют собой обязательные технические требования, без реализации которых программное решение попросту не заработает. Например, в ТЗ явно прописана необходимость согласования документов заказов на закупку, что представляет собой пользовательское требование, однако явно не указана потребность в создании, изменении и удалении подобных документов. Тогда функционал ведения заказов есть ни что иное как функциональное требование, над которым будет настраиваться схема подтверждения (см. табл. 2).

Весь перечень как пользовательских, так и функциональных требований агрегируется и подлежит оценке в матрице отслеживания требований, служащим единым хранилищем всех потребностей к программному продукту. Пример подобной матрицы, содержащий оцененные трудозатраты для проектирования и реализации, дан в табл. 3. Предлагаемая схема оценки трудозатрат может быть использована как для проектов реализации кастомных разработок, так и коробочных решений. В случае оценки кастомных программ никаких настроек не ожидается. При оценке трудозатрат внедрения коробочных решений, стоит обратить внимание на вендора: так в SAP проектах достаточно большое число требований покрывается настройками, в то время как 1С решения содержат меньший объем настроек и больший разработок.

Для полноценной работы предложенной схемы для расчета плановых трудозатрат требуется предварительное формирование Оценщика (см. табл. 1). Кроме того, найденные значения трудозатрат следует дополнить: так трудозатраты, оцененные для реализации, относятся только к разработчикам, следовательно схожий по трудозатратам объем работ необходимо запланировать для функциональных консультантов и/или тестировщиков, которые будут участвовать в модульном или системном тестировании, для чего возможно воспользоваться методом построения ресурсного плана на основе бенчмаркинга этапов [3] ...

Таблица 1. Оценщик трудозатрат проектирования и реализации

Таблица 2. Пользовательские и уточненные функциональные требования

Таблица 3. Матрица отслеживания требований с результатами Fit/Gap-анализа и оценкой трудозатрат

Литературный источник

Катасонова Н.С. RICEFS-классификация разработок и настроек для оценки трудозатрат // Корпоративные информационные системы. – 2023. – №4 (24) – С. 26-37. – URL: https://corpinfosys.ru/archive/2023/issue-24/230-2023-24-ricefclassification.