Переход с SAP на 1С: предпроектное обследование, GAP-анализ

Процесс выявления функциональных разрывов
Советы по выявлению функциональных разрывов

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

В ходе этого этапа

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

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

Наглядное представление о гэпах можно получить при составлении и сопоставлении моделей бизнес-процессов As Is (как есть) и To Be (как будет) в нотациях, например, BPMN. Это наиболее удобная и эффективная форма для отображения текущей ситуации в учете предприятия и представления планируемого решения.

Но как быть в условиях ограниченности времени, когда проведение полноценного предпроектного обследования с моделированием бизнес-процессов As Is невозможно?

Как выявить функциональные разрывы, когда MVP (минимально жизнеспособный продукт) нужно получить, например, через 4-5 месяцев после старта проекта, потому что к этому времени истечет срок действия лицензий на зарубежное ПО?

Оговоримся сразу, что подобные проекты ГК «КомЛайн» реализует с использованием гибридного подхода, когда классическая каскадная модель внедрения Waterfall сочетается с фреймворком Scrum. При применении гибких методологий внедрения, в отличие от каскадной модели, процедура сбора требований может повторяться неоднократно, а выявленные первоначально требования в дальнейшем уточняются и детализируются.

Итак, как выявить функциональные разрывы в такой нестандартной ситуации?

Процесс выявления функциональных разрывов

Первый этап — предпроектное интервьюирование ключевых пользователей системы.

У специалистов ГК «КомЛайн» есть опыт проведения подобных интервью, в ходе которых обсуждаются основные бизнес-процессы в компании, требования к системе, уточняются детали, за два дня.

Очевидно, что за такой период собрать все гэпы и даже большую их часть невозможно, особенно на проектах по импортозамещению в IT, например, при переходе с SAP на 1С:ERP, где даже логика систем разная. Но и цель здесь другая, а именно:

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

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

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

Второй этап — фиксация дефицитов функционала в ходе моделирования бизнес-процессов в 1С:ERP.

В ходе этого этапа специалисты «КомЛайн» демонстрируют ключевым пользователям, как процессы, которые те описали в ходе блиц-интервью, будут выглядеть в 1С:ERP, а также показывают выявленные функциональные разрывы.

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

Третий этап — выявление дополнительных требований и функциональных разрывов при самостоятельном тестировании системы пользователями.

Это происходит, например, в ходе опытной эксплуатации или даже промышленной — если функционал не является критичным для запуска системы в продуктив.

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

Чем тщательнее проведены обследование и моделирование бизнес-процессов предприятия, чем четче сформулированы и зафиксированы требования к системе учета, тем проще и упорядоченнее реализуется проект внедрения 1С:ERP. Поэтому очень важно выделить на первый этап достаточно времени. Иначе выявление дефицитов функционала может продолжаться безостановочно.

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

Советы по выявлению функциональных разрывов

1. Проведение серии коротких интервью

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

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

2. Фиксация функциональных разрывов в листах требований и технического задания

Выявленные потребности интегратор фиксирует в листах требований, каждый из которых в виде отдельной user story (истории пользователя) продолжает свой жизненный цикл в ILM системе.

О том, как выстраивается работа по фиксации выявленных гэпов и их устранению с помощью специальных инструментов, читайте в статье «Подходы к разработке по фреймворку Scrum».

3. Приоритизация задач

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

4. Отказ от доработок в пользу типового функционала

Если времени на кастомизацию каких-то процессов нет и они не оказывают влияния на непрерывность бизнеса, можно ограничиться возможностями типовой конфигурации. Это значительно сократит сроки перехода на новую систему, в том числе с SAP на 1С. При необходимости систему в части этих бизнес-процессов можно будет доработать позже.