Управление взаимоотношениями с бизнесом - 1

Записаться

Место процесса и основной тезис

Рассматривается последний процесс из книги стратегий услуг — управление взаимоотношениями с бизнесом (Business Relationship Management, BRM). Ранее уже обсуждалась гипотеза: бизнес-клиент или бизнес-заказчик внутри организации удовлетворён взаимодействием с департаментом только потому, что департамент оказывает качественные услуги. Это сильное упрощение.

Удовлетворённость зависит от множества соображений, часто вообще не связанных с услугами. Среди них:

• личные отношения заказчика и аккаунт-менеджера (account manager) со стороны ИТ-департамента;
• поведение ИТ-департамента как контрагента: партнёрское или оппортунистическое, направленное на сближение или изоляцию;
• мнение других заказчиков, которые работают с этой организацией;
• лидеры мнений (opinion makers) — люди, чья позиция сильно влияет на заказчика.

Почему удовлетворённость не сводится к услугам

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

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

Поэтому отбрасывать управление взаимоотношениями с бизнесом неправильно. В ITIL v2 этой теме уделялось очень мало внимания. В ITIL 2011 для неё уже существует отдельная активность и отдельный процесс.

Как понимается процесс в ITIL 2011

Цель процесса понимается достаточно утилитарно. Связи между аккаунт-менеджером и заказчиком устанавливаются для того, чтобы провайдер услуг (service provider) понимал бизнес-требования (business requirements) клиентов и мог предоставлять соответствующие услуги.

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

Цели процесса и спорная приоритизация

В ITIL 2011 формулируются цели процесса:

• обеспечить высокий уровень удовлетворённости клиента;
• установить и поддерживать конструктивные взаимоотношения между провайдером и клиентом на основе понимания;
• точно формулировать бизнес-требования.

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

Похожая ситуация уже встречалась в ITIL v2, где были приоритеты инцидентов. Здесь же речь идёт о приоритетах создания услуг, их важности для бизнеса и очерёдности. Возникает вопрос: почему провайдер услуг должен расставлять эти приоритеты? Если разные заказчики требуют разные услуги, с точки зрения провайдера они равноправны.

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

Кто должен определять приоритеты

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

Далее должна действовать простая схема. Провайдер говорит: есть план работ. Часть услуг уже оказывается, они были заказаны раньше. Есть определённые возможности высвободить ресурсы по плану и взять какие-то новые услуги. Но только часть. Какую часть? Решать должны заказчики. Провайдер сообщает, сколько ресурсов занимает та или иная услуга и сколько ресурсов доступно. Дальше бизнес планирует, что для него важнее.

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

Почему ITIL 2011 так настойчиво держится за идею назначения приоритетов работами силами ИТ-специалистов, непонятно.

Идея ИТ как третейского судьи

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

Возникает вопрос: при чём здесь ИТ? Что они могут сказать? Как они могут разрешить конфликт интересов или ресурсов? Никак. Тем не менее это практически цитата из ITIL 2011, которая вызывает недоумение.

Роль доверия

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

Без доверия никакие инициативы организации не будут поддержаны. Никакие стратегические цели, планы и видения не будут восприниматься всерьёз, если организации не верят. Как завоевать доверие? Это сложный вопрос. Существует исследовательская литература, где предлагаются разные способы управления доверием. Но в ITIL 2011 на эту тему ничего интересного не говорится.

Краткие итоги

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

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

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