Если начинать говорить о BRM (Business Relationship Management), то сразу возникает проблема перевода. Как перевести? Управление деловыми отношениями? Управление деловыми коммуникациями? Управление бизнес-отношениями? В российской теории менеджмента термин BRM практически не встречается, поэтому так и не получил общепринятого определения. Однако на западе BRM — довольно известная управленческая дисциплина, построенная вокруг партнерских отношений, которые трактуются в максимально широком контексте.
Попытаемся разобраться, в чем основные особенности BRM-подхода к управлению, чем эта дисциплина отличается от BPM (Business Process Management) и нужна ли она бизнесу?
Что такое BRM?
В широком контексте BRM принято рассматривать как дисциплину, которая рассматривает деловые коммуникации по схеме «сервис-провайдер — партнер».
Представьте, что каждое подразделение компании выступает в роли потребителя услуг другого подразделения. Отношения между ними можно выстроить по принципу «как в продажах»: есть клиент, есть продукт, есть производитель продукта, есть уровень удовлетворенности продуктом. По сути происходит перенос принципов CRM (Client Relationship Management) на другие коммуникаций, включая HR, IT, закупки и т.д.
Однако BRM все же тесно связан с именно с ИТ-услугами, о чем говорят примеры стандартов и фреймворков, разработанных под влиянием этой дисциплины.
ITIL — распространенный в ИТ фреймворк для управления ИТ-услугами. Включает подробное описание практик управления деловыми отношениями, а также стандарт ISO/IEC 20000 для проектирования систем управления услугами (SMS);
COBIT 5® — фреймворк для руководства ИТ-предприятием, который разработан под задачи аудиторов. Подробно описывает сущность BRM, но не дает практических рекомендаций.
The Skills Framework for the Information Age (SFIA) — руководство для ИТ-профессионалов по подбору специалистов с нужными бизнесу навыками. В этом фреймворке для должностей высшего уровня описаны требования к экспертизе в BRM.
В контексте ИТ Business Relationship Management является способом повысить качество услуг и продуктов за счет более тесной коммуникации с партнерами (под это определение попадают также внутренние подразделения компании). Предполагается, что между ИТ и непосредственным потребителем услуг существует коммуникационный барьер. Бизнес говорит на одном языке, ИТ говорит на другом. Также в цепочке коммуникаций появляются посредники, что вызывает эффект «испорченного телефона». Непонимание нужно преодолеть с помощью внедрения практик BRM.
Способности и процессы
В центре BRM лежат понятия способности (capability) и процесса (process).
способность — что сервис-провайдер должен уметь делать, чтобы удовлетворить потребности бизнеса;
процесс— как сервис провайдер может реализовать свои бизнес-способности.
Какие способности бывают?
способность управлять спросом;
способность создавать цепочку ценности;
способность поддерживать непрерывную деятельность.
Как способности выглядят со стороны BRM?
| Спрос |
|
| Цепочка создания ценности | Повышение осведомленности бизнеса о возможностях сервис-провайдера → выявление потребностей бизнеса → предоставление консалтинговых услуг → содействие взаимовыгодному сотрудничеству |
| Поддерживающая деятельность |
|
Из таблицы видно, что функции BRM-менеджера находятся на пересечении маркетинга, продаж, производства и сервисного обслуживания. Все BRM способности являются частью бизнес-способностей организации и могут быть декомпозированы до уровня отдельных бизнес-процессов.
BPM и BRM — есть ли разница?
Одна из целей BPM — повысить клиентоориентированность бизнеса. Примерно тем же занимается и BRM, однако в чем между ними разница? В области компетенций. BPM — это о процессах как таковых, BRM — это больше о навыках и знаниях, которые находят применение в рамках отдельных суб-процессов. То есть их трудно структурировать и связать воедино в рамках одного сквозного бизнес-процесса, как это любят делать специалисты по BPM.
Пример того, какие суб-процессы BRM выделяет ITIL:
поддержка связи с клиентами — удостовериться, что сервис-провайдер понимает текущие потребности бизнеса и продолжает находить новых клиентов;
выявление уровня востребованности услуг — понимать и формулировать на языке клиента выгоды от оказания услуг, а также принимать решение о реструктуризации портфеля услуг;
продажа стандартного набора услуг — удостовериться, что существующий портфель услуг полностью соответствует потребностям нового заказчика;
исследование удовлетворенности клиентов — планировать, проводить и оценивать результаты исследований, которые помогают выявить и предупредить несоответствие между ожиданиями клиентов и результатами работы сервис-провайдера;
обработка претензий — квалифицировать жалобы от клиентов;
мониторинг работы с претензиями — контролировать работу по удовлетворению поступивших претензий.
С точки зрения BPM большинство из описанных подпроцессов логично вписываются в бизнес-процессы продаж и маркетинга.
Главное отличие: BPM решает проблемы координации всех участников процесса, BRM решает проблемы взаимопонимания всех участников процесса.
BRM не нужен?
Научная теория менеджмента зародилась в последней четверти XIX века (1885 год). За это время сформировалось множество подходов, которые возникали по мере того, как менялись социально-экономические отношения и условия производства.
Почему BRM появился в ИТ? Потому что возникла ситуация технологического бума, когда появилось огромное количество программных продуктов, методов и инструментов разработки. Возможности огромны, но реализовать их мешает узкая специализация участников. Поэтому на уровне стратегического менеджмента организации появляется еще одна должность, которая обладает экспертизой одновременно в технологиях и бизнесе. Для российского уха привычней не аббревиатура BRM, а аббревиатура CDTO (Chief Digital Transformation Officer), директора по цифровой трансформации. Область компетенций этих двух специалистов примерно одинакова, хотя полномочия могут сильно отличаться. Всегда ли имеет смысл вводить такие должности? Ответ банален — зависит от ситуации.
Насколько глубока пропасть между знаниями специалистов внутри партнерской сети?
Нужно ли заниматься постоянным выравниванием стратегических целей?
Насколько компания заинтересована в постоянных изменениях?
Насколько велик портфель проектов и партнерский пул?
Насколько велика степень инновационности продукта?
Насколько широк пул используемых технологий?
Например, менеджер по продажам сразу может оценить, насколько продукт компании подходит клиенту, потому что продукт всего один. Разница в экспертизе между владельцем продукта и менеджерами по продажам не столь существенна, чтобы они не смогли быстро найти общий язык. Потребности клиентов уточняются за счет хорошей координации между отделами маркетинга и продаж. В этом случае, скорее всего, BRM-менеджер не нужен. Если все наоборот, и компания постоянно расширяет портфель услуг, выпускает сложные продукты, курирует одновременно несколько проектов разработки, то BRM будет необходим хотя бы на уровне экспертизы высшего менеджмента.
Что предлагает Comindware?
Comindware Business Application Platform позволяет проектировать процессы так, как они протекают в организации. Раз BRM-менеджер работает на стыке маркетинга, продаж, сервисного обслуживания и проектной деятельности, то гибкая платформа для управления процессами поможет эффективно ввести новую должность.
Comindware Business Application Platform можно использовать для разработки решений, который учитывают позицию BRM-менеджера в управленческой структуре организации.
ITSM-решение — основа эффективного управления ИТ-услугами. Вы можете взять за основу решение Comindware и быстро адаптировать под свои задачи c учетом позиции BRM-менеджера;
CRM для ИТ-компании — у Comindware есть собственная CRM, разработанная для поддержки внутренних процессов отдела продаж. Разрабатывалась как замена Salesforce — достаточно популярной CRM в крупных западных ИТ-компаниях. То есть у Comindware есть экспертиза, которая поможет создать продукт именно под ваш бизнес;
Комплексная автоматизация маркетинга — возможности платформы позволяет автоматизировать процессы даже в такой сложной области, как маркетинг.
