2.3.Fit-gap анализ разных систем
Рассмотрим более детально вопросы анализа сближений (fit) и разрывов (gap) пригодности ERP-системы для компании согласно ее требованиям. Как провести такой анализ (исполнителю) по полученной спецификации функциональных требований и как потом эти результаты трактовать (заказчику)?
Если исполнителями являются не внешние специалисты, а команда сотрудников в штате компании, то подход тот же самый. Здесь и далее «исполнитель» – это специалисты, отвечающие за автоматизацию и хорошо знающие рассматриваемую ERP-систему, а «заказчик» – заинтересованная в проекте сторона, путь даже внутри одной и той же компании.
При fit-gap анализе за основу берется список требований от заказчика, он передается в составе RFP, разбит по разделам (модулям) системы: продажи, закупки, бухгалтерский и налоговый учет, производство, казначейство и прочие. Этот список переводится в таблицу, если изначально был не в виде таблицы, и к нему добавляются столбцы для оценок анализа.
Типовой шаблон таблицы для проведения fit-gap анализа содержит столбцы:
- Наименование требования – краткое описание критерия для оценки;
- Приоритет – важность и очередность для автоматизации: 1 – высший приоритет, 10 – низший;
- Обязательность – критичность реализации на первом этапе для запуска в эксплуатацию (так называемое must have – должно быть сразу);
- Поддержка – поддерживается штатно «из коробки»;
- Настройка – поддерживается настройкой системы (не требует программирования);
- Модификация – поддерживается доработкой (требует программирования);
- 3-я сторона – поддержка решениями третьих сторон;
- Будет в следующих версиях – поддержка анонсирована в следующих версиях решения;
- Не поддерживается – нельзя сделать, технические и функциональные ограничения;
- Комментарий к требованию – пояснения к требованию, ссылки на другие документы с детальным описанием;
- Комментарий к оценке fit-gap – пояснения выбранной отметки при анализе.
Варианты оформления таблицы для анализа разные, зависят от применяемой методологии (могут входить как готовые шаблоны в приложение к методологии). Шаблон может требоваться самим заказчиком, что логично: потом все сводить к единому виду.
Например, можно не разделять столбцы Модификация и Настройка, считая их доработкой, но разница между ними есть. Нужно привлекать разработчика или нет, потом такие доработки в коде нужно аккуратно проверять на совместимость при обновлениях системы на новые версии. Еще может быть разная трудоемкость работ по доработке модификацией системы или настройками опций, прав доступа, внешнего вида форм и т. п.
Разница между Поддерживается и Настройка тоже есть, хотя можно утверждать, что если что-то настраивается без доработок – то это уже поддерживается. Но на практике это могут быть разные трудозатраты: есть сразу по умолчанию или нужно настроить, описать правила работы, помоделировать варианты.
Выделение поддержки за счет сторонних решений тоже интересно – эти места потребуют интеграции и дополнительных затрат на приобретение самих решений.
Так или иначе, список критериев оценки может быть короче, если разделение не критично. В частных случаях это может быть два столбца в таблице: fit (поддерживается) и gap (не поддерживается). Собственно, потому и анализ fit-gap. Но нюансы существенны. Их тогда придется описывать в комментарии. Например, «не поддерживается» – да, но можно доработать. Или наоборот – «поддерживается» – да, но не из «коробки», а после модификаций или установки сторонних решений.
Потому выше рассмотрена более общая структура таблицы fit-gap анализа, где такие тонкости вынесены в отдельные столбцы.
Еще вариант этой таблицы: один столбец «fit-gap», в который ставится числовая оценка сближения или разрыва. Например, по шкале от 10 до 0, где 10 – подходит идеально, 1 – не подходит, 0 – нельзя доработать. Тогда промежуточные оценки показывают степень и сложность доработок.
Рис. 2.1. Пример таблицы fit-gap анализа требований
Как, собственно, заполнить этот файл на стороне исполнителя?
Привлекаются все эксперты (коллеги по компании-исполнителю) по системе:
- рассылкой по электронной почте для оценок каждым своего блока и первоначального знакомства с требованиями;
- в виде мозгового штурма в переговорной комнате, где все собираются и обсуждают, что имеется в виду под каждым пунктом требований, как это соотносится с возможностями системы и можем ли мы это доработать и настроить.
Если что-то неясно, то эти моменты уточняются у заказчика: потребуется еще итерация дооценок либо уточнения сразу по телефону у ответственного с той стороны. Ставится оценка, исходя из понимания, и пишется комментарий к оценке, что под этим понималось, если возможна неоднозначность трактовки.
На данном этапе по названию требования и нескольким фразам комментария детально понять потребность в доработке или то, как именно нужно все настроить, сложно. Скорее, это быстрый анализ: есть ли такая возможность в ERP-системе как заявленная в спецификации к программному продукту или это ограничение, которое известно (неизвестно), как преодолеть. Тут нужны реальный экспертный опыт проектной команды и хорошая интуиция, чтобы отметки были как можно точнее.
Для исполнителя такой беглый анализ покажет места, которые нужно будет прорабатывать детальнее для большего понимания и уточнения оценок бюджета внедрения уже в процессе полноценного проекта, в фазе анализа и дизайна.
Заказчик, собирая такие fit-gap таблицы по своим требованиям, может их соотнести между собой, это позволит определить применимость той или иной ERP-системы, если идет выбор между разными системами. Поэтому столбцы для fit-gap анализа желательно добавить сразу на стороне заказчика, чтобы все участники тендера работали с одним шаблоном RFP и потом можно было соотносить результаты.
Если таблица объемная и зрительно сравнить затруднительно, вводится дополнительный столбец с оценками по каждой отметке, где проставляются баллы: поддержка «из коробки» – максимум, «не поддерживается» – ноль. Далее по сумме баллов определяется победитель.
Может получиться, что по каким-то разделам одна система лучше другой, а по другим разделам все наоборот. Выбор непростой, когда явного лидера нет. Нужно смотреть системы вживую на следующем этапе тендера, в его очной части, и учитывать уже факторы нефункциональных требований (стоимость, производительность и т. п.).
Зато если система не подходит совсем, то это сразу будет видно по сплошным «разрывам» в анализе.
На практике fit-gap анализ скорее редкость или его детализация довольно поверхностная, не сотни строк в таблице, а десятки. Связано это с тем, что детальные функциональные требования заказчику собрать самостоятельно на начальном этапе сложно – это задача для специалистов на проектное обследование. И это самостоятельный мини-проект, целью которого является получить документ, содержащий требования и сразу результат анализа применительно к ERP-системе.
