Внедрение практически любой 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 – число оргуровней, %-переиспользования аналогичен схожему параметру при оценке разработок ...

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