Front-Back Office Model

Клиент звонит менеджеру и просит нестандартные условия. Менеджер обещает «решить сегодня», передаёт заявку в операционный отдел, но в форме нет ни причины исключения, ни срока, который он назвал клиенту. Операционист работает по регламенту, отклоняет заявку как неполную и возвращает её. Через три дня клиент снова звонит менеджеру. Ни менеджер, ни операционист не ленились: каждый делал то, ради чего его подразделение создано. Проблема — в стыке между ними. Модель «front office — back office» делит организацию на часть, обращённую к клиенту и настроенную на гибкость, и часть, настроенную на стандартную, дешёвую и безошибочную обработку, и требует проектировать стык между ними так же тщательно, как сами части. Термины используют в двух смыслах — операционном (кто контактирует с клиентом, а кто нет) и организационном (по Джею Гэлбрейту: «фронт» строится вокруг клиентов и рынков, «бэк» — вокруг продуктов). В этой статье разобраны оба смысла по первоисточникам, показано, где проходит граница, как проектировать интерфейс передачи задач, где модель ошибается и как использовать фрейм OrgDevTools.

Что такое Front-Back Office Model и когда она нужна

В общем употреблении front office — часть компании, которая контактирует с клиентами: маркетинг, продажи, обслуживание. Back office — ресурсы компании, направленные на создание продукта или услуги: ввод данных, расчёт зарплаты, бухгалтерия, администрирование, логистика, планирование, управление запасами и цепочками поставок, кадры. По справочному описанию, в широком смысле работа back office влияет на расходную часть отчёта о результатах, а работа front office — на доходную; фронт называют «лицом» компании, а бэк редко бывает на виду, но вносит значимый вклад в успех бизнеса. Back office часто размещают не в головном офисе, а там, где ниже аренда и стоимость труда, и функции бэк-офиса можно передавать подрядчикам, в том числе в другие страны.

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

Происхождение и исследовательская база

У модели две интеллектуальные линии. Первая — операционная. Ричард Чейз в статье «Where Does the Customer Fit in a Service Operation?» (Harvard Business Review, ноябрь–декабрь 1978 года, т. 56, № 6, с. 137–142) предложил классифицировать сервисные системы по степени контакта клиента с системой и её персоналом. Его главный тезис: чем меньше прямого контакта клиента с сервисной системой, тем выше её потенциал работать с максимальной эффективностью, а там, где контакт высок, потенциал эффективности ниже. Оговорка: статья Чейза в работе не читалась, тезис приведён по библиографическим описаниям и аннотациям.

Вторая линия — визуальная. Линн Шостак, руководитель банка, описала в Harvard Business Review в 1984 году технику сервисного блюпринта (service blueprint), которая изображает процесс оказания услуги глазами клиента. На нём выделяют действия клиента, «фронт-сценические» действия контактных сотрудников (шаги лицом к лицу с клиентом), «закулисные» действия контактных сотрудников (невидимые для клиента шаги, например приём брони по телефону) и вспомогательные процессы — действия тех, кто клиента не контактирует, но без кого услуга не будет оказана. Линия видимости отделяет фронт от бэка, а линия взаимодействия отделяет действия клиента от действий поставщика. Блюпринт используют и для проектирования услуги, и для диагностики операционных слабостей и избыточности; наиболее ценен он в межфункциональной работе, где каждый отдел владеет «точкой контакта».

Третья, организационная линия — работа Джея Гэлбрейта (1939–2014), американского теоретика организационного дизайна, автора «Star Model». В статье «The Evolution of Enterprise Organization Designs» он описывает «фронт–бэк организацию» (front-back model, у него же — гибридную организацию) как способ реализовать стратегию массовой кастомизации и ссылается на свои работы 1993 и 2002 годов. Ключевое отличие от операционной трактовки: у Гэлбрейта «фронт» — не отдел продаж, а вся часть организации, построенная вокруг клиентов, стран и сегментов, а «бэк» — часть, построенная вокруг продуктов. Ниже — рерайт этих источников. Оговорка: книги Гэлбрейта («Designing Organizations», «Designing the Customer-Centric Organization») в работе не читались; использованы его статья и документ о гибридной организации; исторические утверждения о «банковской практике середины XX века» из прежней версии статьи не подтверждены источниками и удалены.

Задача бэка — глобальный масштаб, задача фронта — местная адаптация (Дж. Гэлбрейт; перевод формулировки из его статьи об эволюции организационных дизайнов).

Академическая теория: как устроена модель

Первый смысл: операционный — по степени контакта с клиентом

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

Блюпринт Шостак превращает эту идею в инструмент. Линия видимости показывает, какие шаги клиент видит, а какие происходят «за кулисами»; линия взаимодействия — где клиент и поставщик встречаются. Слабое место процесса нередко находится не в самом шаге, а на линии: клиент не понимает, что происходит за кулисами, а бэк не знает, что пообещали на фронте. Поэтому в блюпринте вспомогательные процессы и связи между ними изображают отдельно.

Второй смысл: организационный — по Гэлбрейту

Гэлбрейт описывает фронт–бэк организацию как модификацию матрицы функций, бизнесов и стран. Фронт организован вокруг клиентов, стран и (или) клиентских сегментов, бэк — вокруг продуктов. Бэк должен достигать глобального масштаба, фронт — обеспечивать локальную адаптацию. Цепочка поставок, продуктовый маркетинг и разработка продуктов становятся более глобальными и региональными; матрицы «страна–бизнес» нет. Ориентированный на клиента фронт сосредоточен на глубоком знании клиента, перекрёстных продажах и индивидуальных решениях; маркетинг на фронте локальный и посвящён сегментации, местному распределению и пониманию клиентов. Прибыль (P&L) могут отвечать либо один из концов, либо оба. По Гэлбрейту, эта модель подходит для стратегии массовой кастомизации: массовая часть остаётся в бэке, индивидуальная — на фронте.

Примеры из статьи. Компания Unilever устроена как трёхмерная организация (функции, бизнесы, страны), а у P&G, Nike и IBM клиент или клиентский сегмент становится четвёртым измерением. «Четырёхстолпная» организация P&G включает бизнес-функции, глобальные бизнес-подразделения, региональные рыночные организации и команду клиента Wal-Mart; по данным статьи, на Wal-Mart приходилось около 35 % мировых продаж P&G, а команда клиента насчитывала около 250 человек в разных местах мира. Глобальные бизнес-подразделения создают глобальные платформы, а регионы и команды клиентов адаптируют их: например, платформу шампуня Pantene создаёт подразделение по уходу за волосами, а в Японии местный продуктовый менеджер уменьшает количество отдушки (японки предпочитают более тонкие ароматы) и добавляет кондиционера (у азиатов более густые волосы). Обобщение автора: подразделения обрабатывают массовую часть продукта, а регионы и команды клиентов — индивидуальную. Оговорка: цифры и примеры относятся ко времени написания статьи и не отражают нынешнего состояния компаний.

Почему разделение растёт: закон необходимого разнообразия

Гэлбрейт называет одним из двигателей роста организации закон необходимого разнообразия Эшби (1956): по мере размножения элементов среды внутри предприятия должны множиться подразделения, отвечающие им. Пример из статьи: маркетинг прошёл путь от массового рынка к сегментам и микросегментам, а крупные пищевые компании могут вести более 650 микросегментов потребителей. Вывод для модели: чем больше различий между клиентами, тем сильнее давление создать «фронт», способный отвечать на них, и тем важнее, чтобы «бэк» оставался единым и масштабным, иначе разнообразие клиентов разорвёт операции.

Гибрид как способ совместить клиентов и продукты

В другом документе Гэлбрейта, посвящённом решениям для клиентов, описано, как продуктовые компании добавляют клиентскую составляющую. Например, Nokia перешла от продуктовой компании к продуктовой с добавленным клиентским компонентом — гибриду продуктов и клиентов. Чтобы связать продукты и клиентов, нужны дополнительные управленческие процессы: разработка решений, обеспечение выполнения, единые механизмы планирования. Полезное наблюдение: решения имеет смысл делать тиражируемыми, иначе на них нельзя заработать — сначала инвестируют в решение вместе с ключевым клиентом, затем продают его другим похожим. Чем больше в выручке доля решений, тем больше специализированных клиентских подразделений: у Motorola при доле решений около 10 % и менее достаточно одного подразделения, у IBM — около двенадцати подразделений, каждое для своего клиентского сегмента. Оговорка: примеры компаний относятся ко времени написания документа.

Интерфейс как главный объект проектирования

Из источников следует, что разделение само по себе — половина дела, вторая половина — механизмы, которые связывают части. Гэлбрейт подчёркивает, что по мере усложнения организации растёт значение управленческих процессов и практик работы с людьми: на них держится сложная многомерная организация. В P&G, по статье, сложность удерживают согласованием целей в процессе планирования (региональные команды клиента согласуют выручку, маржу и рост с регионами, а бизнес-команды — с глобальными подразделениями) и ротацией сотрудников между функциями, подразделениями, регионами, командами клиентов и штаб-квартирой: люди строят личные сети и понимают компанию целиком. В решениях для клиентов у IBM бонусы основаны на удовлетворённости клиентов, у Sun — на устранении сбоев у ключевых клиентов. Для «фронта и бэка» это означает три практических механизма: общие цели и планы, единый формат передачи задач, ротация людей между частями.

Разные метрики и стимулы

Из логики Чейза следует, что фронт и бэк нельзя оценивать одинаково. Фронт оценивают по качеству отношений, скорости и гибкости ответа клиенту; бэк — по точности, стоимости и соблюдению сроков обработки. Star Model Гэлбрейта — согласование структуры, процессов, вознаграждения, метрик и талантов со стратегией — говорит о том же: если структуру разделили, а метрики и вознаграждение оставили одинаковыми, части «потянут» в разные стороны. Оговорка: конкретные наборы метрик фронта и бэка — практическая рекомендация, а не цитата из использованных источников.

Учебный расчёт стоимости стыка

Условная компания принимает 1 000 нестандартных заявок в месяц. В 20 % случаев заявка попадает в бэк без важных для обработки сведений (причины исключения, обещанного срока), и бэк возвращает её на уточнение. На каждую такую заявку уходит в среднем 40 минут: фронт и бэк тратят по 20. Потери: 1 000 × 20 % × 40 мин = 8 000 минут ≈ 133 часа в месяц. Кроме того, каждая возвращённая заявка добавляет в среднем два дня к сроку для клиента. Обязательная форма передачи с шестью полями снижает долю неполных заявок до 5 %: 1 000 × 5 % × 40 мин = 2 000 минут ≈ 33 часа. Экономия — около 100 часов в месяц и заметное сокращение срока для клиента. Числа условные и иллюстрируют расчёт; важен не итог, а то, что стоимость плохого стыка можно измерить.

Ключевые идеи и принципы модели

1. Принцип: разные части оптимизируют по-разному

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

2. Принцип: граница проходит по контакту с клиентом и по смыслу вариативности

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

3. Принцип: стык — главный объект проектирования

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

4. Принцип: разные метрики и вознаграждение

   Фронт и бэк оценивают по разным показателям, но обе оценки связывают общей целью — результатом клиента. Иначе части оптимизируют свои показатели за счёт общего результата.

5. Принцип: держите общий контекст

   Разделение создаёт информационный разрыв: бэк не видит клиента. Его закрывают общими целями, ротацией людей, обратной связью от бэка к фронту и видимостью клиентского результата в бэке.

6. Принцип: не разделять то, что нельзя стандартизировать

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

Как внедрить разделение фронта и бэка: пошаговая инструкция

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

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

Пример из практики: как P&G удерживает фронт и бэк вместе

Гэлбрейт описывает, как P&G, у которого клиентская команда Wal-Mart стала одним из четырёх измерений организации, удерживает сложность: согласованием целей в процессе планирования (региональные команды клиента согласуют выручку, маржу и рост с регионами, бизнес-команды — с глобальными подразделениями) и ротацией сотрудников между функциями, подразделениями, регионами, командами клиентов и штаб-квартирой. Люди строят личные сети и понимают, как устроена компания в целом. Оговорка: это описание автора статьи, а не независимая оценка; данных об эффективности такого устройства в статье нет.

Ограничения, слепые зоны и критика модели

Типовые ошибки при разделении фронта и бэка

1. Ошибка 1: интерфейс передачи не спроектирован.

   Бэк получает заявку без контекста и либо запрашивает уточнения, теряя время, либо обрабатывает вслепую и ошибается.

   Как избежать

   описать формат, обязательные поля, правила приёма неполных заявок и владельца стыка.

2. Ошибка 2: фронт и бэк оценивают одинаково.

   Одни и те же метрики (например, только скорость) толкают бэк к спешке, а фронт — к обещаниям, которые нельзя выполнить.

   Как избежать

   задать метрики по целям каждой части и общую цель по клиентскому результату.

3. Ошибка 3: фронт обещает то, чего бэк не умеет.

   Индивидуальные условия оговариваются без учёта возможностей бэка; заявки застревают.

   Как избежать

   согласовать перечень допустимых исключений и порядок согласования нестандартных условий.

4. Ошибка 4: бэк не получает обратной связи от клиентов.

   Сотрудники не видят, как их работа влияет на клиента, и оптимизируют только собственные показатели.

   Как избежать

   показывать бэку клиентские результаты, привлекать его к разборам жалоб и ротации.

5. Ошибка 5: в бэк уносят то, что нельзя стандартизировать.

   Каждая заявка уникальна, бэк превращается в «почтовое отделение», растёт число возвратов.

   Как избежать

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

6. Ошибка 6: смешивают два смысла модели.

   Отдел продаж называют фронтом и на этом основании строят всю организацию «по Гэлбрейту» или наоборот.

   Как избежать

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

7. Ошибка 7: разделение делают один раз и не пересматривают.

   Технологии и ожидания клиентов меняются, а граница остаётся прежней.

   Как избежать

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

Метрики: как оценивать модель

Универсальных нормативов нет; фиксируйте по своим данным:

• Доля заявок, принятых бэком с первого раза: без возврата на уточнение.

• Время прохождения стыка: от передачи заявки до начала обработки в бэке.

• Срок для клиента: от обращения до результата, отдельно по типам запросов.

• Причины возвратов: распределение по типам недостающих сведений.

• Стоимость и точность обработки в бэке: себестоимость операции и доля ошибок.

• Удовлетворённость клиентов: по обращениям, прошедшим через стык, и по остальным.

• Доля нестандартных запросов: сколько заявок требует исключений и как быстро они согласуются.

Разделять фронт и бэк проще, чем построить между ними мост, — но ценность лежит именно в мосте.

План внедрения по неделям

1. Неделя 1: блюпринт

   Нарисуйте блюпринт для двух-трёх ключевых услуг и найдите естественную границу.

2. Неделя 2: ответственность и метрики

   Определите результаты фронта и бэка, метрики и общую цель по клиентскому результату.

3. Неделя 3: интерфейс

   Опишите формат передачи заявки, правила приёма, сроки и владельца стыка.

4. Неделя 4: запуск и измерение

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

   Далее: пересматривайте границу и форму передачи по данным и вводите ротацию между частями.

Как реализовать этот план с помощью фрейма «Front-Back Office Model» в OrgDevTools

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

Книги и материалы по теме

Р. Чейз — «Where Does the Customer Fit in a Service Operation?» (Harvard Business Review, ноябрь–декабрь 1978). Классификация сервисных систем по степени контакта с клиентом; в работе не читалась.

Л. Шостак — «Designing Services That Deliver» (Harvard Business Review, 1984). Первое описание сервисного блюпринта (по справочному обзору).

Дж. Гэлбрейт — «The Evolution of Enterprise Organization Designs» (статья на сайте автора jaygalbraith.com). Фронт–бэк организация, примеры P&G, Nike, IBM, закон необходимого разнообразия.

Дж. Гэлбрейт — «Organizing to Deliver Solutions». Гибридная организация продуктов и клиентов, решения для клиентов, процессы связи.

Дж. Гэлбрейт — «Designing Organizations» (2002) и «Designing the Customer-Centric Organization» (2005). Подробное изложение фронт–бэк модели; в работе не читались.

Справочные статьи «Front office», «Back office» и «Service blueprint» (Wikipedia). Определения и элементы блюпринта.