Наверх

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

Время чтения: 12 минут
0
Исследование при внедрении ИТ-систем по методу GAP-анализа

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

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

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

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

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

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

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

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

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

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

или

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 2.

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

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

Пример 3.

В существующих процессах на предприятии юрист регистрирует договорные документы после подписания договора Генеральным Директором.

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

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

Пример 4.

На предприятии в системе, которая использовалась ранее и подлежит замене, в карточке договора было поле "Вид оплаты" с возможными значениями: "Разовый", "Рассрочка" и поле «Условия оплаты» с возможными значениями «Предоплата», «Постоплата». Во внедряемом продукте имеется только поле «Условие оплаты». По результатам анализа выяснилось, что для всех этих характеристик пользователям достаточно одного поля «Условие оплаты».

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

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

Пример 5.

Организация с государственным участием и работает по 44-ФЗ, и в ходе подготовке процедуры закупки необходимо согласование планов закупок подразделений. Порядок согласования отличается от договорных и организационно-распорядительных документов.

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

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

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

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

Отклонение

Эталон (Коробка)

Приоритет

Тип мероприятия

Суть мероприятия

При согласовании нетипового договора поставки в согласовании участвует главный бухгалтер

Типовой маршрут по согласованию документов

Высокий

Адаптация системы

В маршрут добавить главного бухгалтера.

При согласовании документа должно быть видно, какой документ основной для согласования, а какие - приложения

Типовой маршрут по согласованию документов

Высокий

Адаптация системы

В параметрах типового маршрута отдельно указывать основной документ для согласования и приложения.

Юрист регистрирует договорные документы после подписания договора Генеральным Директором.

Юрист регистрирует договорные документы перед подписанием договора в договорном отделе (т.е. непосредственно перед парафированием).

Высокий

Организационные изменения

Регистрация договорных документов будет производиться как в Эталоне, т.е. перед подписанием Генеральным Директором.

Ранее было поле "Вид оплаты" с возможными значениями: "Разовый", "Рассрочка".

Поле «Условия оплаты»

Высокий

Организационные изменения

Использовать для всех вариантов поле «Условие оплаты».

Разработать сценарий по согласованию планов закупок подразделений

Сценарий отсутствует

Средний

Вынесение на развитие системы

Разработка нового сценария согласно требованиям

В отчете по исполнительской дисциплине необходимо изменить расцветку

Стандартное оформление отчета

Низкий

Вынесение на развитие системы

Реализация в рамках сопровождения системы

Источник: Intelligent Enterprise

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 0

Чтобы прокомментировать, или зарегистрируйтесь