Как централизовать новые сервисы с пользой для бизнеса

Централизация функций — не только способ сэкономить, но и путь к повышению прозрачности процессов, качества сервисов, снижению рисков. В БЕ «Поддержка бизнеса» X5 за 5 лет выстроили эффективную модель передачи сервисов. Наталья Гайнуллина, Финансовый директор БЕ «Поддержка бизнеса», X5 Group, рассказала Клубу ОЦО об основных этапах перевода новых сервисов, возможных сложностях на каждом этапе и о методах работы с ними.

Прием сервиса от бизнеса: цели и роли

Передача процессов/сервисов от бизнес-единиц в централизованные сервисы — не самоцель. В X5 Group этот процесс всегда начинается с вопроса: зачем мы это делаем?

Целей может быть несколько, и не всегда это экономия. Часто бизнес приходит с запросом о повышении качества, снижении рисков или повышении удобства взаимодействия. Инициатива централизовать сервисы может исходить и от БЕ «Поддержка бизнеса». Например, когда новый сервис – часть крупного end-to-end процесса, большая часть которого уже централизована. На первом этапе инициатива чаще исходила от нас и тогда нам приходилось работать с возражениями и опасениями. В любом случае команда заранее оценивает потенциал: какие процессы можно перевести, есть ли эффекты от централизации, в чем именно будет улучшение. 

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

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

Процесс передачи сервисов в X5 выстроен поэтапно, всего мы выделяем 6 этапов – инициация проекта; анализ процессов as is (как есть); разработка концепции процессов to be (какими они будут); передача сервиса; стабилизация и закрытие проекта; оценка эффектов. Далее рассмотрим каждый из этапов более подробно.

Инициация проекта

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

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

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

Кроме того, у нас есть типовой план (шаблон) проекта, который затем адаптируется под конкретный проект, а также план коммуникаций.

Возможные сложности

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

Нет бюджета. Достаточно распространена ситуация, когда Заказчик хочет передать функционал, но не ставки, в том числе и потому, что функционал распределен между разными людьми. В этом случае мы стараемся найти оптимальный для обеих сторон выход – смотрим по регионам, где может быть полная ставка, которую возможно передать; есть ли возможность отказаться от избыточного функционала, перераспределить задачи внутри, забираем бюджет без ставок. Бывает, что берем на себя часть нагрузки, если видим потенциал для будущего эффекта.

Нет четкой цели передачи сервиса. Если экономические эффекты неочевидны, то важно понять цель – зачем сервис передается в Блок поддержки и каковы ожидания заказчика.

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

Дискавери анализ – «as is»

На этом этапе происходит анализ текущего состояния сервиса. Мы изучаем и отрисовываем процессы, нормативные документы и регламенты, проводим GAP-анализ, замеряем текущую трудоемкость, анализируем текущий SLA (не всегда он есть) и уровень удовлетворенности, формируем карту рисков и карту стейкхолдеров/ коммуникаций. 

Далее принимается решение, по какому сценарию мы будем двигаться: забираем сервис «как есть» (as is) или проектируем целевую модель «с нуля» (to be) (см. рис. 2). От чего зависит выбираемый сценарий? Если важна скорость передачи, то мы забираем сервис «as is». Также если процесс очень критичен для бизнеса, и мы не хотим получить эффект «большого взрыва», то стараемся забрать его в том виде, как он есть, а уже затем оптимизировать. Бывает, что процесс достаточно четко выстроен, и не требуется его оптимизация на этапе перевода.

Возможные сложности

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

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

Отсутствие документации. Случается, что процесс не описан и не задокументирован, тогда приходится отрисовывать и документировать процессы с нуля.

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

Разработка «to be»

На основании проведенного на предыдущем этапе анализа строится целевая модель — to be. Мы описываем будущий процесс, рассчитываем трудоемкость и ТЭО, составляем матрицу RACI и матрицу эскалации — как мы будем работать в нестандартных ситуациях. 

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

На этом же этапе при необходимости мы сразу закладываем доработки в ИТ-системах (затраты по доработке покрываем за счет будущих эффектов) и формируем гипотезы/план по оптимизации.

При передаче сервиса мы считаем технико-экономическое обоснование, в котором учитываем все преимущества, которые можно получить при переводе сервиса (подробнее рассмотрим этот вопрос в разделе «Оценка эффективности»).

Возможные сложности

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

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

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

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

Передача сервиса

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

Кроме того, происходит доработка ИТ-систем, а также составляется акт передачи бюджета.

Возможные сложности

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

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

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

Кадровый дефицит. Часто встает вопрос: где взять людей? Мы начинаем найм заранее или переводим опытных сотрудников на новый функционал, а на их место набираем новичков.

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

Стабилизация и закрытие проекта

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

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

Возможные сложности

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

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

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

Оценка эффективности

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

При передаче сервисов эффект может быть не только количественным, но и качественным.

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

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

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

Сокращение time-to-market. Это особенно заметно в проектах, где скорость запуска влияет на выручку. Например, при ускорении ввода новинок на полки, оптимизации мастер-данных или запуске новых форматов взаимодействия.

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

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

Советы тем, кому предстоит перевод нового сервиса

Передача сервисов — это комплексные проекты. И чем раньше вы выстроите правильный подход, тем меньше рисков и больше эффектов получите в итоге. Вот несколько принципов, которые помогают нам.

1. Фиксируйте договоренности. Это защитит от сюрпризов: смена заказчика, изменение приоритетов, пересмотр целей. Паспорт проекта — не бюрократия, а инструмент прозрачности и предсказуемости.
2. Работайте со стейкхолдерами. Часто при передаче всплывают заинтересованные лица, о которых изначально никто не думал. Карта стейкхолдеров помогает заранее увидеть всех участников процесса и избежать конфликтов.
3. Пилот важен при передаче больших сервисов. Большие проекты проще запускать поэтапно: по регионам, по функционалу, по волнам. Это снижает риски и дает возможность быстрее выявлять и устранять ошибки.
4. Готовьтесь к обучению. Не стоит полагаться на регламенты — их редко читают. Готовьте простые инструкции, проводите встречи, записывайте обучающие сессии. Это инвестиция, которая потом сэкономит массу времени.
5. Не затягивайте закрытие. Когда сервис передан, важно это зафиксировать и перейти в режим сопровождения. Иначе проект может  затянуться.
6. Оценивайте не только экономику. Эффект может быть не только в прямой экономии ФОТ, оценивайте и другие эффекты: снижение  рисков, повышение качества, увеличение скорости, которая может влиять на эффекты в бизнесе. 
7. Давайте заказчику время. Не все готовы сразу передавать сервис. Дайте им понять, что вы умеете — и со временем клиенты придут к вам сами. Иногда чуть позже, но с большей готовностью.

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

Подробнее о том, как выстроена работа БЕ «Поддержка бизнеса» X5, можно будет узнать на референс-визите в X5, который состоится 10 сентября в рамках 32-й конференции «Общие центры обслуживания» в Нижнем Новгороде.