Разрывы в общем виде могут быть такими:
- между рыночным предложением компании (в самом широком смысле) и существующим на рынке уровнем спроса;
- между текущей деятельностью или бизнес-процессами и их характеристиками и видением того, как должно быть в идеале или с точки зрения руководства;
- между действительными целями и задачами работы компании в целом и сотрудников в частности с одной стороны и теоретически необходимыми целями и задачами с другой;
- между текущими показателями работы и лучшими показателями в отрасли (benchmarks).
Суть, ради чего проводится Gap-анализ, можно выразить простой формулой:
Желаемое = Имеющееся + Необходимое
или
Желаемое — Имеющееся = Необходимое
Результатом Gap-анализа независимо от области является идентификация «разрывов» и разработка мероприятий по их устранению.
Применение в области внедрения ИТ-систем
Каким же образом Gap-анализ может применяться в сфере внедрения информационных технологий?
Большинство проектов по внедрению программного обеспечения (ECM, ERP и пр.) направлено на то, чтобы адаптировать некий стандартный «коробочный» продукт под особенности и потребности конкретного заказчика. При этом к внедрению зачастую используется два подхода:
- «от процессов» — когда детально исследуются бизнес-процессы заказчика, формируются, а затем и реализуются требования к системе. На выходе, как правило, мы получаем продукт, значительно отличающийся от типового (стандартного);
- «от системы» — когда организация бизнес-процессов, заложенная в «коробку», выступает неким эталоном и происходит «подгонка» бизнес-процессов заказчика под её функционал.
Разумеется, если в вашем распоряжении не коробочный продукт, а набор инструментов для создания информационных систем определенного класса, то ни о каком внедрении «от системы» речи быть не может. Однако если в руках команды внедрения есть готовый, самодостаточный продукт, то наиболее эффективным будет именно внедрение «от системы».
Вот в этом случае нам и пригодится методика Gap-анализа.
Если вновь обратиться к формуле Желаемое = Имеющееся + Необходимое, то нетрудно догадаться, что «Желаемым» в данном случае будут потребности заказчика, а «Имеющимся» — функционал внедряемой «коробки».
Таким образом, задача команды внедрения — сопоставить «Желаемое» и «Имеющееся» и найти «Необходимое». Рассмотрим более детально, как выполнить эту задачу.
Как выявить разрывы (отклонения)?
Рассмотрим два варианта, которые чаще всего применяются в нашей практике.
Вариант №1. Демонстрация системы и онлайн-моделирование.
Подход предполагает собрание рабочей группы заказчика, чтобы продемонстрировать перед ней систему и по итогам этой демонстрации выявить отклонения от текущих процессов.
Преимущества:
- низкая трудоёмкость и высокая оперативность работ проектной команды, так как весь процесс анализа можно уложить в несколько моделирующих сессий.
Недостатки/риски:
- при подобных «мозговых штурмах» заказчик может неправильно сформулировать некоторые требования или вообще забыть о них, что чревато определенными проблемами при внедрении.
Вариант №2. Индивидуальные беседы с представителями рабочей группы.
Более традиционный подход к выявлению отклонений — организация индивидуальных встреч с представителями рабочей группы (желательно прямо на рабочем месте). Проводится сбор требований к процессам, пожеланий, ожиданий от внедрения и, самое главное, текущих проблем. По результатам исследования составляется перечень отклонений функционала «коробки» от имеющихся потребностей заказчика.
Далее проектная команда демонстрирует результаты исследования рабочей группе. При этом упор делается на то, как будут решены «узкие места» и текущие проблемы, которые удалось выявить в результате бесед. Следующий шаг — демонстрация системы с акцентом на функционал, который позволит повысить эффективность текущих процессов и сократить количество «узких мест».
Преимущества:
- более точное выявление отклонений благодаря полноте сбора требований и индивидуальному общению.
Недостатки/риски:
- Высокая трудоёмкость анализа в сравнении с моделированием «на лету», как в варианте № 1.
При выборе того или иного подхода необходимо отталкиваться от характера заказчика, сложности автоматизируемых процессов и объема ресурсов, выделенных на проект. Например, если бюджет проекта ограничен, но специалисты заказчика готовы активно участвовать в исследовании, то наиболее подходящим будет вариант №1. В случае высокой занятости представителей рабочей группы и отсутствия возможности собирать всех в одном месте на длительные совещания — лучше остановиться на втором варианте.
Что делать с отклонениями?
Оба рассмотренных способа анализа на выходе дают нам один и тот же результат — перечень отклонений стандартного функционала внедряемого продукта от текущих особенностей бизнес-процессов и потребностей заказчика. Задача проектной команды– разработать план мероприятий по сведению выявленных отклонений к минимуму. Все мероприятия делятся на три группы:
- адаптация функционала коробки под бизнес-процессы заказчика за счет бюджета проекта;
- организационные изменения в бизнес-процессах;
- вынесение за рамки текущего проекта с целью дальнейшего развития.
Рассмотрим их подробнее.
Адаптация под бизнес-процессы за счет бюджета проекта
Устранение наиболее критичных отклонений, которые обычно относятся к ключевым бизнес-процессам компании и не подлежат организационным изменениям.
По нашему опыту к таким процессам можно отнести управление документами и делопроизводство. Так как в организациях среднего размера, схожих по корпоративной культуре (например, современных, клиенториентированных, развивающихся либо тяготеющих к строгой регламентации и иерархии), бизнес-процессы, связанные с управлением документами, чаще всего похожи. Возможности коробочных продуктов позволяют делать настройку в пределах, достаточных для внедрения.
Пример 1.
На предприятии отдел продаж формирует и согласовывает договоры на поставку, на проектирование, на сервисное обслуживание; отдел снабжения — договоры закупки; административно-хозяйственный отдел — договоры аренды. Для разных типов договоров установлен разный регламент согласования. В ходе анализа определяется, все ли требования могут быть реализованы. Настройка по основным видам документов обычно включается в этап адаптации. На иллюстрациях приводятся два типа регламентов, которые подлежат настройке.
Важно: Объем отклонений, которые попадут в эту группу в ходе адаптации системы, зависит не только от возможностей продукта, но и от бюджета, выделенного на проект, и временных рамок. Так, часть изменений, менее критичных, не сложных, может быть вынесена за рамки текущего проекта, то есть в группу 3.
Организационные изменения в бизнес-процессах заказчика.
В данном случае подразумевается адаптация бизнес-процессов заказчика под функционал системы с целью сокращения выявленных «узких мест». Часто на этот этап выносятся те мероприятия, которые направлены на методически верное выстраивание процессов, подтвержденное опытом внедрения СЭД и управленческих консультаций, — то есть унификация и оптимизация бизнес-процессов.
Пример 2.
На одном предприятии в каждом управлении создано свое место регистрации. При этом документ может первоначально поступить в канцелярию, и дальше его передают в управления. Для того, чтобы не потерять документ, в управлениях его также регистрировали, но уже каждый раз под своим номером. Кроме того, управления могли получать документы напрямую, и они также регистрировались там.
При внедрении СЭД было решено упразднить регистрацию документов в управлении, если они уже были зарегистрированы в другом месте (например, в канцелярии), так как в СЭД можно отследить прохождение документа по всем исполнителям и определить его текущее местоположение и статус. Кроме того, исчезла путаница с регистрационными номерами, потому что у документа остался единственный регистрационный номер.
Пример 3.
В существующих на предприятии процессах юрист регистрирует договорные документы после того, как договор будет подписан генеральным директором.
При работе с электронным документом после подписания электронной подписью никакие изменения, в том числе вписывание номера, производиться не должны и не могут. Документ с новым номером — это уже измененный документ, а значит, электронная подпись на него уже не распространяется. То есть при переводе процесса в электронный вид необходимо изменить процессы.
Приведенные заказчику доводы позволили провести организационные изменения, и было принято решение изменить процесс. Регистрация договорных документов будет производиться, как в эталоне, т.е. перед подписанием генеральным директором.
Пример 4.В системе, которая использовалась на предприятии раньше, а теперь подлежит замене, в карточке договора было поле «Вид оплаты» с возможными значениями «Разовый», «Рассрочка» и поле «Условия оплаты» с возможными значениями «Предоплата» и «Постоплата». Во внедряемом продукте имеется только поле «Условие оплаты». По результатам анализа выяснилось, что для всех этих характеристик пользователям достаточно одного этого поля.
Вынесение за рамки текущего проекта
Некритичные отклонения и пожелания к системе не включаются в содержание проекта и оставляются заказчику на дальнейшее развитие системы.
Пример 5.
Организация с государственным участием. В соответствии с 44-ФЗ при подготовке процедуры закупки необходимо согласование планов закупок подразделений. Порядок согласования отличается от договорных и организационно-распорядительных документов.
В системе не предусмотрен подобный бизнес-процесс, но его могут создать и настроить специалисты предприятия, прошедшие необходимое обучение. Это отклонение не помешает автоматизации других бизнес-процессов, и оно выносится за рамки проекта.
Очевидно, что в интересах менеджера проекта, который ограничен в ресурсах, сократить объём адаптации внедряемой системы и как можно больше отклонений устранить за счет организационных изменений или вообще отложить реализацию «на ближайшее будущее». Заказчик, напротив, намерен настаивать, чтобы все его требования были выполнены. Тут важно соблюдать принцип разумной адаптации системы и бизнес-процессов друг под друга. Должно быть движение навстречу, обеспечивающее оптимальный эффект от внедрения.
В этой методике делается акцент на то, что важен результат, — то есть нет «нереализованных пожеланий», есть отклонения, и по каждому из них приняты решения. Если какое-то отклонение не может быть закрыто адаптацией (настройкой) и/или не может быть вынесено на развитие системы, значит, по нему должно быть принято организационное решение — либо о признании его несущественным, либо о перестройке процессов внутри организации. В таблице мы приводим пример оформления результатов исследования по Gap-анализу для внедрения СЭД.
