Продолжение заметки "Разбираемся с Business Relationship Management".
Месяц назад я уже публиковал заметку, в которой предпринял попытку разобраться с задачами управления взаимоотношениями бизнесом в целом и ролью BRM в формировании удовлетворенности заказчика в частности. Сегодня хочу сделать еще один шаг вперед и разобраться с видами деятельности BRM в течение жизненного цикла услуги, перекинув основные мостики между миром ИТ и миром бизнеса.
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 в реальной жизни, напишите пару строк. Очень интересно.
Павел, добрый день! Спасибо за статьи и вебинар, интересно и полезно. Пример из реальной жизни есть: 10 месяцев назад мы приняли в ИТ департамент управляющей компании сотрудника, должность называется «менеджер по автоматизации ключевых бизнес-процессов». Мы и раньше пытались ввести такие должности для ключевых процессов/заказчиков, но здесь необходимость (вернее конфликт с заказчиком), что называется, назрела и нам хоть одну ставку, но выделили. Менеджер был сосредоточен на потребностях блока маркетинга и продаж. Конечно, не получилось реализовать все так, как мы планировали – год для Концерна был просто экстремальный. Так вот, даже в таких условиях положительный результат на лицо – отношения с заказчиком и результаты улучшились даже за счет того, что ИТ-поставщик предстал перед заказчиком в виде конкретного лица, который всегда рядом, какие бы задачи бизнес перед ИТ не ставил. Конечно, функции других сотрудников (бизнез-аналитиков, менеджеров проектов, системных аналитиков и т.д.) никто не отменял, но менеджер по автоматизации отрабатывает именно на этапе формирования потребности (как на схеме у Павла), а потом уже передает в работу бизнес-аналитикам, менеджерам проектов и т.д. и курирует исполнение этой потребности. Сейчас, к сожалению, в результате реструктуризации эта должность сокращена, но этого сотрудника с удовольствием взяли к себе в штат бизнес-единицы нашего Концерна. Так что посмотрим, как будут развиваться события. Мы, планируем, что он продолжит выполнять свою роль, но только на стороне бизнес-заказчика, а не ИТ. Своего рода, эксперимент получается.
P.S. На мой взгляд , одним из основных плюсов ITIL3 является как раз формализация роли BRM: технологии – вторичны, люди и их отношения все по сути и определяют.