По моим наблюдениям, при создании ОЦО есть два принципиально разных подход

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

При втором подходе процессы забирают «как есть», а уже потом их пытаются привести в порядок.

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

Главное забрать, а потом разберёмся

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

Основные плюсы

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

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

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

Основные минусы

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

ОЦО получает зоопарк процессов и ИТ-систем (даже если это формально одна система) с огромным количеством ручных «костылей» и недокументированных возможностей. И если для локальных HR это может и был зоопарк, но «свой» — где каждая зверюшка давно изучена и приручена, то для сотрудников ОЦО, недавних выпускников вуза, это как выпускника циркового техникума, который до этого видел льва только на плакате, сразу запереть в клетке с дикими львами и тиграми. А HR активов в это время «покупают попкорн» и наблюдают — в лучшем случае ждут, справится ли ОЦО, а в худшем ещё и подливают масла в огонь.

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

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