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

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2012-2013) Все мероприятия

Джон Гриффитс, Обещанного 3 года ждут : чем мерить достижения и влиять на вероятности (RU)

Предыдущая Следующая

Джон Гриффитс

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

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

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

Безусловно, вы сталкивались с такими вещами в своей практике. Я, безусловно, видел, как это все происходило в тех программах, в которых участвовал сам. Как избежать наступления на эти «любимые грабли»?

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

Следующий пункт, который у нас называется Design for Value – проектирование ради ценности, концентрация на ценности. Естественно, когда мы составляем бизнес-кейс, мы уже предполагаем, какие процессы должны быть изменены. Может быть, этот список не исчерпывающий, но основное в нем намечено: в результате изменения бизнес-процессов эффективность бизнеса возрастет. Мы понимаем, какие изменения произойдут, формируем карту этих изменений. И в проекте нашего решения, тем более, если это IT-решение, эти изменения должны быть отражены.

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

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

Рекомендация

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

Есть и другие факторы получения ценности, которые нужно учесть. То есть это — замкнутый цикл. Мы последовательно проходим через все эти этапы и на каждом этапе сверяемся с бизнес-кейсом. Здесь приведен пример бизнес-кейса. Общая оценка экономии составляет где-то 200 миллионов долларов, и дальше идет детализация.

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

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

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

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

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

Рекомендация

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

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

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

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

А дальше вы переходите к детализации. Во-первых, выражаете количественно: сколько можно сэкономить или заработать. Цель ставите: зачем это вам нужно? Объясняете себе: зачем нужен этот процесс, зачем нужно зарабатывать эти деньги? А дальше приводите примеры KPI – финансовых KPI. Финансовые KPI нужны для того, чтобы вы помнили о цели: зачем вы этим занимаетесь?

Возьмем, например, такую область, как отчетность. Здесь могут быть такие цели: стандартизация финансовой отчетности, процессов и определение терминов. А KPI может быть какой-то общий финансовый, например - доля затрат департамента на создание отчетов в общем объеме административных общих расходов или в проценте от выручки. Это область, где мы можем получить дополнительную выгоду. Разрабатываем KPI, выделяем владельца — скорее всего, это будет CFO или сотрудник с аналогичной ролью. Мы описываем через изменение процесса — как он должен поменяться, чтобы мы получили соответствующие показатели и выполнили соответствующий финансовый KPI.

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

Итак, мы составили карту и теперь переходим к определению KPI. Зачем мы так настаиваем на измерении всего и вся? Потому что только с помощью измерения мы поймем, насколько улучшится ситуация. Это результаты исследований, которые мы проводили на рынке. Если вы не измеряете полученную ценность, то лищь 11 процентов таких проектов укладываются в сроки или заканчиваются раньше, чем предполагались сроки изначально. А если вы постоянно в процессе имплементации измеряете извлекаемую ценность, то уровень успеха повышается до 73 процентов. А успех – это попадание в бюджет и в сроки, соответственно.

Рекомендация

Не пренебрегайте измерениями и анализом хода проекта. Если вы этого не делаете, то повышаете вероятность его провала.

KPI


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

KPI бывают двух типов: они могут быть частью жизненного цикла программы. Это самые очевидные показатели: соответствие срокам и бюджету, и они, как правило, заканчиваются вместе с завершением программы. Но эти KPI заканчиваются вместе с программой, как правило. А еще нас, безусловно, интересуют длительные KPI, которые сохраняются и после завершения программы. Как мы уже с вами обсудили, часто выгоду мы начинаем чувствовать через какое-то время после завершения программы. То есть постоянные или длящиеся KPI нужны именно для этого.

Аналогична и разница между PMO и VMO – PMO, скорее всего, будет распущен после завершения программы, а VMO будет продолжать существовать, чтобы продолжать отслеживать KPI по этой программе.

Карта определения KPI
Рассмотрим факторы извлечения ценности или реализации ценности. Это выходит за рамки IT, потому что тут речь идет о факторах процесса и о его управлении. Для достижения выгоды могут потребоваться изменения в структуре управления — не только с точки зрения технологии и процесса, но и с точки зрения организации отчетности, подотчетности, иерархии управления.

Рекомендация

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

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

Мы определились с вами, какие изменения должны быть внесены в процесс, и теперь переходим к этапу проектирования – Blueprint. Если мы говорим, к примеру, про внедрение ICP, то это уже Blueprint - изменение процесса. Какие элементы нам обеспечат соответствующие изменения, и пересмотр, уточнение этих элементов проекта? Это checking-list – проверочный список. Он особенно полезен на ранних этапах имплементации. Он напоминает нам, что мы должны сделать для получения желаемых результатов.

Рекомендация

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

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

Аудит – это более строгий процесс отслеживания работы VMO, чем то, к чему мы привыкли по прошлому опыту. Метрики KPI, эффективность программы – все это можно выделить в отдельный процесс управления эффективностью программы. Можно даже трактовать это как HR-процесс, с помощью которого мы можем измерять производительность отдельных людей, участвующих в программе. Необходимо, чтобы у людей была достаточная мотивация к достижению целей, предусмотренных бизнес-кейсом.

Рекомендация

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

И последнее, о чем хотелось бы здесь сказать – это quality-gates, «ворота качества» – мы их рекомендуем. Может, у вас уже есть подобная практика в ваших программах и проектах. Смысл в том, чтобы отдельные элементы ценности были привязаны к каждому этапу реализации проекта, жизненного цикла вашей программы. Это еще один способ убедиться в том, что вы на правильном пути, и одна из передовых практик управления процессом. Вот краткий экскурс в то, что обычно делается на этапе имплементации для получения ценности.

Об авторе

ДЖОН ГРИФФИТС
SAP 
Главный Консультант по Трансформации Бизнеса
Джон – один из самых опытных консультантов в области трансформации.
Джон Гриффитс занимался реорганизацией и созданием бизнес-стратегий как в консалтинговых компаниях, так и на стороне клиента. Он участвовал в многомиллионных ИТ проектах в роли руководителя проекта, руководителя программы, и консультанта по изменениям.
Как командный игрок, Джон помогает людям максимально реализоваться. Он с легкостью решает возникающие перед ним проблемы и является отличным наставником, регулярно помогающим своим коллегам добиться поставленных целей.

strong