Портал №1 по управлению цифровыми
и информационными технологиями

Разбираемся с Business Relationship Management – часть 2

Опубликовано 28 ноября 2016
Рубрики: ITIL, ITSM, SLA, SLM, BRM
Комментарии

Продолжение заметки "Разбираемся с Business Relationship Management".

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

brm_through_service_lifecycle

Service Strategy

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

На стороне ИТ, при должном уровне зрелости, есть стратегическое планирование. В идеальном мире, потребности бизнеса определяют ИТ-стратегию. ИТ-стратегия определяет все намерения ИТ – изменения, проекты, программы, которые необходимо реализовать, чтобы закрыть текущие и будущие (в рамках горизонта планирования) бизнес-потребности. Бизнес-потребности конечно меняются вслед за изменением внутренних и внешних факторов: вывод на рынок новых продуктов, необходимость обеспечения соответствия, реагирование на действия конкурентов… Бизнес редко торопится ставить ИТ в известность. И нужен кто-то, кто будет держать руку на пульсе: знать заказчика, какие задачи он решает, как меняется его деятельность и соответственно структура спроса на услуги так, чтобы люди в ИТ обладали возможностью своевременно менять курс.

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

ITIL Service Strategy

Service Design

На основании стратегии ИТ-функция разрабатывает решения. При старте инициативы бизнес уточняет свои требования, которые:

  • он, как правило, затрудняется сформулировать
  • сервис-провайдер, как правило, затрудняется расшифровать

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

Эта нескочаемая череда постоянных уточнений может превратиться для сервис-провайдера в настоящий ад. Очень емко и жизненно на этот счет написано в ITIL:

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

ITIL Service Strategy

ITIL советует сервис-провайдеру, неважно внутреннему или внешнему, использовать «marketing mindset» – маркетинговый способ мышления, и отвечать не на вопрос «Что мы должны предоставить?», а на следующие три вопроса:

  • Какие задачи выполняет заказчик? Как ИТ ему в этом будут помогать?
  • Каких результатов хочет достичь заказчик?
  • Какие ограничения могут не позволить заказчику достичь желаемого? Как сервис-провайдер может снять эти ограничения?

Service Transition

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

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

Service Operation

Начинается предоставление, сопровождение и поддержка услуги, а вместе с ним – мониторинг, формирование и предоставление отчетности заказчику, проверка соответствия формальным требованиям.

Задача BRM на этой стадии убедится в том, что заложенная ценность извлекается (заказчик достигает необходимых результатов), ожидания заказчика оправдываются (заказчик доволен), а если этого не происходит сгладить острые углы. Существенное внимание в описании процесса в ITIL уделено жалобам: основаниям для регистрации, типам жалоб, правилам обработки. Основные выводы, которые можно сделать из текста: жалобы неизбежны, нужен формальный процесс по их обработке; ни одну жалобу нельзя оставить без внимания; по каждой жалобе нужно подготовить ответ; жалоба – сигнал о явной или скрытой проблеме, ее нужно идентифицировать.

CSI

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

BRM в реальном мире

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

Однако шансы найти BRM в "живой природе" вовсе не нулевые.

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

В случае внешнего сервис-провайдера проработка возможностей плавно перетекает в процесс продаж, и в задачах BRM может оказаться (но необязательно) подготовка КП и дальнейшая передача дел для организации проработки решения менеджеру проектов/менеджеру по предоставлению услуг. И здесь предостережение: неаккуратное сочетание задач BRM с sale и pre-sale активностями может быстро выхолостить само понятие business relationships, которые не про продажи и прибыль сервис-провайдера, а про партнерство с заказчиком.

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

  • совместного с ключевыми заказчиками планирования развития услуг/систем на следующий период (как правило, год)
  • оптимизации портфеля услуг (как бы это не называлось) и принятия решений по выводу новых услуг в эксплуатацию, архивации существующих и так далее
  • кураторства комплексных проектов

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

Подозреваю, что список можно продолжить. Если у вас есть примеры BRM в реальной жизни, напишите пару строк. Очень интересно.

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

Комментариев: 2

  • Наталия

    Павел, добрый день! Спасибо за статьи и вебинар, интересно и полезно. Пример из  реальной жизни есть: 10 месяцев назад мы приняли в ИТ департамент управляющей компании сотрудника, должность называется «менеджер по автоматизации  ключевых бизнес-процессов». Мы и раньше пытались ввести такие должности для ключевых процессов/заказчиков, но здесь необходимость (вернее конфликт с заказчиком), что называется, назрела  и нам хоть одну ставку, но выделили. Менеджер был сосредоточен на потребностях блока маркетинга и продаж. Конечно, не получилось реализовать все так, как  мы планировали – год для Концерна был просто экстремальный.   Так вот, даже в таких условиях положительный результат на лицо – отношения с заказчиком и результаты улучшились даже за счет  того, что ИТ-поставщик предстал перед заказчиком в виде  конкретного лица, который всегда рядом, какие бы задачи бизнес перед ИТ не ставил. Конечно, функции других сотрудников (бизнез-аналитиков, менеджеров проектов, системных аналитиков и т.д.) никто не отменял, но менеджер по автоматизации отрабатывает именно на этапе формирования потребности (как на схеме у Павла), а потом уже передает в работу бизнес-аналитикам, менеджерам проектов и т.д. и курирует исполнение этой потребности. Сейчас, к сожалению, в результате реструктуризации эта должность сокращена, но  этого сотрудника с удовольствием взяли к себе в штат бизнес-единицы нашего Концерна. Так что посмотрим, как будут развиваться события. Мы, планируем, что он продолжит выполнять свою роль, но только на стороне бизнес-заказчика, а не ИТ. Своего рода, эксперимент получается.

    P.S. На мой взгляд , одним из основных плюсов ITIL3 является  как раз формализация роли BRM:  технологии – вторичны, люди и их отношения все по сути и определяют.

  • Игорь

    Хотелось бы отметить одну из пролем, возникающих у внутренних BRM. Если Account в коммерческой организации приносит потенциальный контракт – в его реализации заинтересованы все, так как прибыль = бонусы. Большинство ИТ подразделений весьма консервативны и новый контракт/продажа/идея/потребность ни с чем ктроме лишнего геморроя не ассоциируется. Отсюда проблема – идеи есть, желания реализовывать – не всегда.


Добавить комментарий для НаталияОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM