Как выстроить сквозное управление изменениями в ОЦО

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

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

ЦКР изменения могут касаться любой составляющей бизнеса: услуги, бизнес-процесса, ИТ-системы или проекта. Раньше такие запросы поступали по разным каналам и обрабатывались с различной скоростью. В результате компания уже работала по-новому, а описания процессов, показатели, каталог услуг, тарифы, СОП, риски и контроли могли не отражать последние изменения.

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

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

Чтобы отслеживать эту цепочку не постфактум, а до начала реализации, в ЦКР сделали отправной точкой оценки операционную модель.

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

Анализ изменения с точки зрения операционной модели позволяет определить:

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

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

Комплексная оценка требует участия нескольких функций: одна команда не может одновременно определить влияние на процесс, экономику, персонал и контрольную среду (см. рис. 1).

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

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

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

Функции качества и операционной эффективности отвечают за актуальность показателей, SLA, КПЭ, каталога услуг и операционной модели.

Инициатором при этом не обязательно является владелец процесса. Запрос может поступить от клиента, соседнего подразделения, методологической функции или через Центр идей. Особенно важно здесь отметить роль Центра идей в формировании изменений. За три с половиной года сотрудники направили через него более 900 предложений. В процесс вовлечено свыше 25% сотрудников, а более четверти ежегодной программы операционной эффективности реализуется за счет поступивших идей.

Подход оформлен в единый маршрут, обязательный для всех типов изменений (см. рис. 2).

Сквозной процесс включает пять этапов:

• Инициация
• Оценка влияния
• Утверждение
• Реализация
• Закрытие запроса

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

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

Запрос закрывается только после подтверждения результата (см. рис. 3).

Первоначально процесс зафиксировали в регламенте, согласованном всеми участниками. Затем запустили временную схему, а позже автоматизировали маршрут на внутреннем портале ЦКР.

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

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

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

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

Сам подход ЦКР разработал своими силами, без отдельного проекта, консультантов и внешних подрядчиков. Автоматизацию реализовали как доработку внутренней сервисной платформы.

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

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

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

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

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

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

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

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

Тестировать вместе с будущими пользователями. Автоматизированный процесс сначала протестировала внутренняя команда. Однако после подключения подразделений появились новые сценарии. В связи с необходимостью доработки финальное тестирование удалось провести только через несколько месяцев.

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

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

Опыт ЦКР можно свести к трем принципам.

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

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

Третий — закреплять кросс-функциональную ответственность. Единый регламент должен поддерживаться ролевой моделью, автоматизированным маршрутом и системой целей.

ЦКР продолжает развивать процесс: собирать обратную связь, пересматривать отдельные этапы и искать возможности для роботизации и автоматизации.

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