— Какие симптомы в компании становятся триггером для запуска проекта по созданию ОЦО? Что на вашей практике было тем самым красным флажком?

На самом деле для создания ОЦО не нужны красные флажки, не нужны никакие триггеры. Готовность к созданию ОЦО характеризует определённую зрелость компании.

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

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

Вот такая совокупность — это уже хорошо. Если на нее ещё накладываются единая IT-архитектура, зрелый менеджмент, готовность предприятий и кадровый кризис в регионах, где они расположены, это будет большим плюсом.

— Как определить, что общий центр обслуживания действительно нужен компании, а не является просто модным трендом?

Это уже давно не модный тренд, это мейнстрим. Так делают компании не мелкого размера по всему миру.

При этом стратегию, как правило, выстраивают комплексно. Самые зрелые компании распределяют: вот этот кусок мы переводим в общий центр обслуживания, в общие сервисы — глобально или локально, а вот этот передаем на аутсорсинг.

Аутсорсинг помогает выстроить сервисы с меньшими затратами и по модели управления сервисами, когда подрядчик отвечает за результат. Ты уже не просто содержишь отдел. Плюс это позволяет перейти на переменные затраты: платить за единицу сервиса.

— Как правило, при переходе к модели ОЦО компании сокращают затраты на обслуживающие функции на 20–40% при условии правильного дизайна процессов. Но как понять, что это именно ваш случай?

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

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

Руководство при этом может усилить цели или принять их в таком виде. Примерно так.

— Какую цель лично вы ставите перед ОЦО в первую очередь: сокращение затрат, повышение качества или освобождение экспертного времени для стратегических задач?

Абсолютно все три цели достигаются. Но среди них, наверное, есть та, которая является ведущей для данной компании.

Если у компании есть дефицит экспертных кадров и это движет ею при создании ОЦО — эту задачу решаем, параллельно ещё и затраты сократим. Если это повышение качества, то и его достигнем: установив жёсткие цели и прикрутив систему менеджмента качества.

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

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

— С чего нужно начинать проект по созданию ОЦО: с диагностики, целевой модели или поиска пилотной функции? Что, на ваш взгляд, самое важное и самое сложное?

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

Диагностика, верхнеуровневый анализ, верхнеуровневые расчёты и прикидка по бизнес-кейсу, с которым мы потом пойдём в проект, — наверное, разумный первый шаг.

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

— Какие этапы создания ОЦО вы считаете максимально критическими с точки зрения рисков? Где чаще всего случаются сбои и почему?

Великолепный вопрос. Это вообще про любой проект внедрения изменений.

Есть три стадии. Сначала прикидка, скажем так, дизайн. Потом непосредственно перевод: уже сформированы целевые процессы, и мы запускаем изменения. И есть момент, когда мы переключаем тумблер, — и всё начинает прекрасно или не прекрасно работать.

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

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

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

— Какие функции в первую очередь стоит выводить в ОЦО, а какие категорически не стоит?

Самые интересные и результативные проекты, наверное, — когда берутся сразу за несколько функций. Тогда не возникает вопроса, кого первым. Возникает вопрос, как реализуются изменения и в какой очередности туда идут предприятия, регионы, дивизионы или другие единицы.

Во-вторых, сразу можно переходить на сквозные бизнес-процессы. Переводить отдельно кадры, отдельно зарплату, отдельно бухгалтерию хуже, чем переводить их разом и сразу выстраивать процесс — например, тревела в компании. Создание мультифункционального ОЦО даёт возможность построить сервисы.

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

Но на практике бывает, что инициатива исходит из конкретных функций. Какие-то идут вперёд, какие-то позже, исходя из своей зрелости.

У нас точно так же происходило: сначала пошли финансы, потом быстренько за ними, буквально по следам, — HR. Дальше присоединялись закупки, продажи, когда у них созрела готовность, немного позже юристы.

Поэтому многое зависит от компании, от воли, масштаба действий и готовности к изменениям.

— Что эффективнее выводить в ОЦО: отдельные операции или сквозные процессы целиком? Как это работает на практике?

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

— Какую роль играет IT-инфраструктура компании и её готовность к интеграции? Что делать, если инфраструктура разная?

Инфраструктурный вопрос при построении общих центров обслуживания очень, очень и очень важный.

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

На практике эти работы приходится закладывать в капитальные затраты проекта и проводить в сроки создания ОЦО. И это сильно влияет на скорость его создания.

— Как долго длится типичный проект по созданию ОЦО? Какие факторы влияют на сроки — от диагностики до стабилизации процессов?

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

Если мы идём в глобальную компанию, это может длиться дольше: есть волны по странам. Брать проектную команду отдельно на каждую страну неэффективно. Она всё-таки одна, обеспечивает единство методологии проекта и волнами перемещается между подразделениями.

Но где-то от шести до девяти месяцев — это реалистично.

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

— Как вы выстраиваете взаимодействие между ОЦО и бизнес-подразделениями, чтобы центр воспринимали как партнёра, а не как чёрный ящик?

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

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

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

На этих встречах обсуждаем показатели на выходе из сервиса — SLA. Обсуждаем качество на входе — OLA, потому что это может быть очень влияющим фактором. Почему? Несвоевременно подал — несвоевременно обработал. Некачественно прислал — пришлось вернуть и перерабатывать.

И обсуждаем customer satisfaction. Иногда, с особо чувствительными клиентами, мы измеряем его с двух сторон. Отношение группы функционального заказчика к нашему исполнителю может очень сильно влиять, местами иметь деструктивные эффекты. Мы обязаны это отслеживать и открыто обсуждать с заказчиком, насколько это влияет.

— Меняются ли требования к персоналу ОЦО по мере его развития и усложнения задач? Как вы выстраиваете систему подбора и обучения?

Требования меняются не сильно. Всё равно есть рядовые позиции, сотрудники на которых работают по инструкции. Для них самое важное — система адаптации.

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

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

Есть рутинная, транзакционная сторона. И здесь вырастают коллеги, которые принимают на себя руководство в той или иной ипостаси.

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

Требования к квалификации снижаются постепенно или резко — в зависимости от модели: набираем всех новых сразу или пока сохраняем исторический персонал. Позиции удешевляются, на них принимается менее квалифицированный или неквалифицированный персонал. А на экспертные позиции — эксперты.

— Как вы проектируете процессную модель ОЦО, распределяя зоны ответственности между центром и бизнес-подразделениями?

Это достаточно отстроенная схема. В рамках управления изменениями и целевого дизайна процессов мы выстраиваем матрицу ответственности.

Распределяем, кто в целевой модели за что отвечает, как движутся документы, информация, расчёты. Этот дизайн ложится в целевую модель, а дальше — в рабочие инструкции и описания бизнес-процессов.

Всё это остается в качестве материальных артефактов в подразделении общего центра обслуживания и служит основой для взаимодействия между ним и функцией.

— Какие задачи в ОЦО вы пока не можете автоматизировать и почему? Где человеческий фактор остается критически важным?

У меня была прекрасная история. Руководительница сказала, что к ней обратились бизнес-подразделения: «Что же такое, вы как-то стали хуже взаимодействовать». Что случилось? «Да вы смайлики перестали ставить в электронных письмах!»

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

Да, взаимодействий будет меньше. Операции будут больше автоматизироваться, роботизироваться, теперь уже переводиться на агентов.

Но тема человеческого, клиентского опыта, наоборот, встаёт со всё большей силой. Потому что этих взаимодействий, касаний становится меньше — и крайне важно, с каким качеством они проводятся.


— Какие самые распространенные ошибки вы видели в проектах по созданию ОЦО?

О, это прямо на отдельную статью тянет.

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

Это только примеры навскидку. Всё решается, опыт нарабатывается, возможность привлечения консультантов остаётся.

Ещё одна важная ошибка — не оценивать эффективность на входе, не измерять, как было и как стало. И дальше не внедрять постоянное совершенствование, когда всё постепенно переводится на прежние рельсы.

— Если бы вы сегодня начинали проект по созданию ОЦО заново или в другой компании, что сделали бы иначе?

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

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

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

— Какие риски при создании ОЦО чаще всего недооценивают на старте? Как их заранее предусмотреть?

Об этом я рассказывала в разделе про ошибки. Они же и риски.

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

Поэтому важно удерживать и мотивировать ключевую команду, которая уже пришла. Понимать, что люди годны именно для этой работы и тянут её.

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

— Каким вы видите ОЦО через пять лет: центром затрат, центром компетенций или драйвером бизнес-трансформации? Какие тренды считаете самыми важными на ближайшие три года?

Я вижу его центром цифрового управления процессами. Это точно наше будущее на среднесрочный горизонт.

Я сомневаюсь, что ОЦО будет драйвером бизнес-трансформации. Но считаю, что возможности новых технологий — именно про нас.

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

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