Использование GAP-анализа для выявления и согласования задач по проекту

05.07.17

Управление проектом

Данная статья размещена здесь для тех, кто хочет знать больше про GAP анализ и как его использовать на проекте. Так как формат статьи не позволяет рассказать все, я постарался рассказать основное по этой теме. Больше, если получится, я расскажу на Event 2017, если мой доклад наберет достаточное количество голоcов. Ссылка на доклад http://event.infostart.ru/2017/agenda/#item643129

Существует множество методов оценки эффективности работы компании в целом или на уровне определенных бизнес-процессов, которые включают в себя выявление «узких мест», описание непосредственно проблематики, выявление разницы между желаемым уровнем эффективности и реальной ситуацией. Я уже рассказывал о том, как на практике можно использовать различные методы для выявления проблемных «узких мест», для планирования работы, для взаимодействия с заказчиком и демонстрации предложенных решений. Все это и многое другое вы можете прочитать в статьях Краткое описание BPMN с примером и Знакомство с нотацией IDEF0 и пример использования.

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

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

  • Определение участка приложения усилий;
  • Постановка задач и планирование действий;
  • Оценка стоимости проведения работ;
  • Согласование необходимых работ и решений с заказчиком.

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

Основные этапы работы по проекту


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

Основные этапы сотрудничества по проекту (Источник “Управленческое консультирование. Введение в профессию” под редакцией Милана Кубра):

  1. Знакомство;
  2. Диагностика;
  3. Планирование действий;
  4. Внедрение;
  5. Завершение сотрудничества.


Если этап знакомства обычно вопросов не вызывает, как и внедрение или завершение сотрудничества, то о диагностике стоит поговорить подробнее. Я считаю диагностику – важнейшим этапом работы, который условно можно также разделить на некую последовательность действий:

  1. Анализ цели;
  2. Анализ проблемы;
  3. Сбор информации;
  4. Обратная связь с клиентом.


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

Почему так важна диагностика?


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

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

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

В различных случаях этап диагностики может занимать и менее 1 дня, и 2 недели и даже более. Все зависит от сложности поставленных задач и необходимых работ, относящихся к этому этапу. В отдельных случаях (при выполнении предпроектного обследования и т.д.) этап диагностики может быть очень трудоемким, а результат этого этапа будет отдельной оплачиваемой услугой.

Но в любом случае результаты должны быть следующие:

  1. Список задач (на основе обсуждения с заказчиком или по итогам проведенного обследования ситуации в компании);
  2. Предлагаемые решения и их обоснование;
  3. Цена каждой задачи и срок ее выполнения.


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

Виды диагностики


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

Самые распространенные варианты я разделяю следующим образом:

  • Экспресс-диагностика;
  • Разработка технического задания (ТЗ);
  • Предпроектное обследование;
  • GAP-анализ.


Давайте разберем каждый из этих видов подробнее.

Экспресс-диагностика


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

Например, может понадобиться уточнить, с какой учетной системой работает компания, на какой CMS реализован сайт, кто является телефонным провайдером или уточнить еще какие-то моменты, способные повлиять на методы реализации и, как следствие, на общую стоимость работ. Этот вид диагностики можно применять в случаях, когда заказчику требуются какие-то виды типовых услуг, которые будут проводиться по шаблону. Длительность этого вида диагностики – до 1 рабочего дня (чаще 1-2 часа). Результат – калькуляция для клиента или выставленный счет к оплате.

Разработка технического задания (ТЗ)


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

ТЗ от заказчика: плюсы и минусы:

  • Плюс получения готового техзадания очевиден – экономия времени специалистов. Готовый документ с перечнем всех задач, которые максимум, могут потребовать небольших корректировок со стороны специалиста, причем, далеко не всегда.
  • Основной минус заключается в том, что заказчики редко являются достаточно компетентными, чтобы составить качественное ТЗ. Если бы у них были необходимые знания, скорей всего, они бы не стали обращаться к сторонним специалистам, за исключением отдельных технических исполнителей с узкой специализацией (специалист 1С, веб-разработчик и т.д.). 


Желание заказчика добросовестно описать все свои пожелания иногда выливается даже в анекдотичные случаи. Так, когда-то я получил техническое задание, состоящее из 300 страниц! К нему прилагалось письмо от заказчика, который сетовал, что он никак не может выбрать исполнителя, так как все, к кому он обращался, либо отказываются от работы, либо выставляют счета, явно очень завышенные. Очевидно, что такие ТЗ просто никто не читает, именно потому и возникли перечисленные в письме проблемы.

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

Предпроектное обследование


Такое обследование является само по себе отдельным видом работы, сравнительно сложным и трудоемким. В процессе обследования специалист:

  • Изучает работу компании на основе документальной информации;
  • Проводит интервью с руководителем компании, начальниками и сотрудниками различных подразделений;
  • Часто лично бывает на производстве или наблюдает работу склада, отдела продаж, магазина и пр.


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

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

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

Причина такого явления – отсутствие в отчете предпроектного обследования необходимых в ТЗ технических данных, часто собранных в таблицы: соответствие и описание определенных параметров, например, соответствие полей в CRM и 1С при постановке задачи интеграции, другие таблицы с техническими параметрами. Одно такое описание вместе с комментариями к нему может занимать 3-5 страниц.

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

GAP-анализ


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

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

Здесь очень важно понимать грань. Часто специалисты, которые сами выявляют «тонкие места» в бизнесе, предлагают решения для реализации бизнес-процессов так, как они видят, что и как должно быть. При работе с GAP-анализом я всегда показываю разрыв между ситуацией реальной и тем, как должно быть с точки зрения заказчика, в его формулировках, в его видении. Т.е. концентрируюсь на решении поставленных задач. И здесь графические нотации нужны именно для понимания заказчиком всех нюансов. 

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

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

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

Преимущества GAP-анализа


О том, что графические нотации – это один из очень удобных и эффективных вариантов работы с заказчиками при обсуждении любых изменений в бизнесе (внедрение IT-программ, оборудования для автоматизации, внедрение изменений в управленческий процесс и т.д.). Графические нотации позволяют избавиться от тысячи слов, а взаимопонимание с заказчиком будет намного выше, чем при отправке многостраничного текстового отчета. При этом экономится время – и ваше, и вашего клиента.

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

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

См. также

Компетенции и навыки РП Руководитель проекта

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

05.11.2024    1120    0    MariaTemchina    1    

27

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    3672    0    biimmap    39    

39

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    5029    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3837    0    user1853337    8    

29

Инструменты управления проектом Руководитель проекта Бесплатно (free)

Мы собрали здесь самые распространенные ошибки в проектном управлении, которые обходятся очень дорого... Если вы не уверены, что сможете завалить проект самостоятельно, то ниже мы собрали несколько советов, как гарантированно добиться результата.

01.04.2024    3190    0    MariaTemchina    6    

22

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    4919    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15739    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6569    0    stnslv    5    

25
Оставьте свое сообщение