Исследование при внедрении ИТ-систем по методу GAP-анализа

Николай Комлев, руководитель проектов DIRECTUM

Gap в переводе с английского языка может означать: брешь, пролом, щель, интервал, пробел, лакуна, пропуск, расхождение, разрыв, пропасть и т.д. Для перевода названия методики Gap Analysis лучше всего подойдет слово "разрыв", так как речь в целом идет об анализе разрывов между действительным настоящим состояниям (где мы сейчас) и желаемым (куда мы хотим попасть). Методика разработана Стэнфордским исследовательским институтом (США, Калифорния).

Разрывы в общем виде могут включать:

●    Разрыв между рыночным предложением компании (в самом широком смысле) и существующим на рынке уровнем спроса

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

●    Разрыв между действительными целями и задачами работы компании в целом и сотрудников в частности с одной стороны и с другой стороны — теоретически необходимыми целями и задачами

●    Разрыв между текущими показателями работы и лучшими показателями в отрасли (benchmarks).

Суть, ради чего проводится Gap-анализ, можно выразить простой формулой:

Желаемое = Имеющееся + Необходимое

или

Желаемое – Имеющееся = Необходимое

Результатом Gap-анализа, независимо от области, является идентификация «разрывов» и разработка мероприятий по их устранению.

Применение в области внедрения ИТ-систем

Каким же образом Gap-анализ может применяться в сфере внедрения информационных технологий?

Большинство проектов по внедрению программного обеспечения (ECM, ERP-класса и пр.) заключаются в том, чтобы адаптировать некий стандартный «коробочный» продукт под особенности и потребности конкретного заказчика. При этом, зачастую используется 2 подхода к внедрению:

●    «От процессов» – когда производится детальное исследование бизнес-процессов заказчика, формируются требования к системе и последующая их реализация. На выходе, как правило, мы получаем продукт, значительно отличающийся от типового (стандартного).

●    «От системы» – когда организация бизнес-процессов, заложенная в «коробку», выступает неким эталоном, и происходит «подгонка» бизнес-процессов заказчика под её функционал.

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

Именно в этом случае нам пригодится методика Gap-анализа.

Если вновь обратиться к формуле Желаемое = Имеющееся + Необходимое, то нетрудно догадаться, что «Желаемым», в данном случае, будут потребности заказчика, а «Имеющимся» – функционал внедряемой «коробки».

Таким образом, задача команды внедрения – сопоставить «Желаемое» и «Имеющееся» и найти «Необходимое». Рассмотрим детальнее как выполнить эту задачу.

Как выявить разрывы (отклонения)?

Рассмотрим два варианта, которые наиболее часто применяются в нашей практике:

Вариант №1. Демонстрация системы и онлайн-моделирование.

Подход предполагает собрание рабочей группы заказчика, проведение демонстрации системы и выявление отклонений от текущих процессов по итогам демонстрации.

Преимущества:

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

Недостатки/Риски:

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

Вариант №2. Индивидуальные беседы с представителями рабочей группы.

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

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

Преимущества:

●    Более точное выявление отклонений благодаря полноте сбора требований и индивидуальному общению.

Недостатки/риски:

●    Высокая трудоёмкость анализа в сравнении с моделированием «на лету» как в варианте 1.

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

Что делать с отклонениями?

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

1. Адаптация функционала коробки под бизнес-процессы заказчика за счет бюджета проекта.

2. Организационные изменения в бизнес-процессах.

3. Вынесение на развитие системы (за рамки текущего проекта).

Рассмотрим их подробнее.

Адаптация под бизнес-процессы за счет бюджета проекта

Устранение наиболее критичных отклонений, которые обычно относятся к ключевым бизнес-процессам компании и не подлежат организационным изменениям.

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

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

Бизнес-процесс 1.

Бизнес-процесс 2.

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

Организационные изменения в бизнес-процессах Заказчика

В данном случае подразумевается адаптация бизнес-процессов Заказчика под функционал системы с целью сокращения выявленных «узких мест». Часто на этот этап выносятся мероприятия направленные на методически верное выстраивание процессов, подтвержденное опытом внедрений СЭД и управленческих консультаций – то есть унификация и оптимизация бизнес-процессов.

Вынесение за рамки текущего проекта

Некритичные отклонения и пожелания к системе не включаются в содержание проекта и выносятся на дальнейшее развитие системы у заказчика. 

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

Важно, что в этой методике делается акцент на то, что важен результат – то есть, нет «нерелизованных пожеланий», есть отклонения и по всем приняты решения. Если какое-то отклонение не может быть закрыто адаптацией (настройкой) и/или не может быть вынесено на развитие системы, значит по нему должно быть принято организационное решение: либо о признании его несущественным, либо перестройка процессов внутри организации.

Пример оформления результатов исследования по Gap-анализу для внедрения СЭД

Источник: Intelligent Enterprise