Функциональная оргструктура (Functional Structure)

Функциональная организационная структура (Functional Structure) — способ построить организацию, при котором сотрудники группируются по специализированной функции, которую они выполняют: производство, продажи, маркетинг, финансы, разработка, персонал. Подразделение отвечает за свою область для всех продуктов, клиентов и регионов сразу. Это самая старая и самая распространённая форма (в англоязычной литературе её называют U-form, от unitary), и она хорошо решает одну задачу — глубокую экспертизу и эффективное использование специалистов; но она плохо решает другую — быструю и слаженную работу нескольких функций над одним продуктом или клиентом.

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

Материал разбирает: откуда идея и как она соотносится с классификацией Лютера Гьюлика; что сказали об ограничениях структуры Чандлер (DuPont и General Motors), Лоуренс и Лорш, Гэлбрейт; документированные примеры (DuPont и GM в 1920-е годы, Microsoft в 2013 году, Toyota с системой главных инженеров); как сохранять преимущества функциональной модели и лечить «силосы»; когда пора переходить к дивизиональной или матричной структуре; метрики; типовые ошибки; и как устроен фрейм OrgDevTools.

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

Функциональная группировка опирается на принцип разделения труда (Адам Смит, 1776) и на классическую теорию управления. Лютер Гьюлик в очерке «Notes on the Theory of Organization» (в сборнике Гьюлика и Линдалла Урвика «Papers on the Science of Administration», 1937) выделил четыре основания группировки работ в подразделения: цель (purpose — что делает подразделение: например, «здравоохранение»), процесс (process — каким способом: например, юристы, инженеры, бухгалтеры), люди или вещи, обслуживаемые подразделением (persons or things — клиентура), и место (place — территория). Функциональную структуру относят к основанию «процесс». Гьюлик писал, что все четыре основания можно комбинировать, но при этом «нельзя выбрать всё сразу»: выигрыш по одному основанию означает потери по другим (подробнее — в материале о департаментализации). Оговорка: работа Гьюлика была частью доклада Комитета Браунлоу для президента США (1937) и описывала принципы государственного управления; применение к бизнесу — позднейшая интерпретация.

Главное историческое свидетельство ограничений функциональной формы — исследование Альфреда Чандлера «Strategy and Structure» (1962): он проследил, как крупные американские компании (DuPont, General Motors, Standard Oil of New Jersey, Sears) переходили от централизованной функциональной структуры к многодивизиональной по мере расширения географии, вертикальной интеграции и диверсификации продуктов. Тезис Чандлера: структура следует за стратегией; функциональная форма годится для компаний с одной линейкой продуктов и одним рынком, а при диверсификации центр не справляется с координацией функций сразу по многим продуктам. Оливер Уильямсон (1975) объяснил это «гипотезой M-формы»: отделение стратегических решений от оперативных повышает эффективность.

Исследования координации. Пол Лоуренс и Джей Лорш («Organization and Environment», 1967) показали, что подразделения (например, производство, продажи, исследования) в успешных компаниях естественно «дифференцируются» — у них разные цели, горизонт и стиль, — и чем сильнее различия, тем больше нужна интеграция (посредники, комитеты, группы). Джей Гэлбрейт («Designing Complex Organizations», 1973) описал набор механизмов координации: правила и процедуры, иерархия, планирование, прямые контакты, связующие роли, временные группы, постоянные команды, интегрирующие роли и матрица; чем больше неопределённость и взаимозависимость, тем более «дорогие» механизмы нужны. Том Бёрнс и Джордж Сталкер («The Management of Innovation», 1961) различили «механистические» (иерархичные, с чёткими функциями) и «органические» (гибкие) структуры и связали их с стабильностью и изменчивостью среды. Генри Минцберг описал «машинную бюрократию» и другие конфигурации, в которых функциональная логика доминирует (см. организационные архетипы Минцберга).

Документированные кейсы

Кейс 1. DuPont и General Motors (1920–1921): предел функциональной структуры

По исследованию Чандлера, после Первой мировой войны DuPont расширилась в несколько существенно различающихся продуктовых линий (краски, пластмассы, искусственные волокна и др.), но управлялась централизованной функциональной организацией; кризис запасов 1920–1921 годов показал, что она не справляется с координацией функций по разным продуктам и рынкам. Компания перешла к многодивизиональной структуре с самостоятельными подразделениями по продуктам. Тем же путём пошла General Motors под руководством Альфреда Слоуна: децентрализация в 1920-х годах позволила высшему руководству сосредоточиться на стратегии и распределении капитала, а дивизионам — на операциях. Оба случая стали классикой в истории менеджмента, а многодивизиональная форма распространилась на другие крупные компании.

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

Кейс 2. Microsoft (2013): возврат к функциональной структуре ради «одной компании»

11 июля 2013 года Microsoft объявила реорганизацию «One Microsoft»: вместо самостоятельных продуктовых бизнес-единиц (Windows, Office, Server и другие), введённых предыдущей реформой, компания перешла к функциональной структуре — группам по дисциплинам: инженерия (с четырьмя направлениями: операционные системы, приложения, облако и устройства), маркетинг, развитие бизнеса и евангелизация, перспективные стратегия и исследования, финансы, персонал, юридическая служба, операционная деятельность. Цель, как её формулировали в компании, — ускорить инновации и снизить внутреннюю конкуренцию подразделений, мешавшую совместной работе над сквозными продуктами. Журналист Курт Айхенвальд в статье «Microsoft’s Lost Decade» (Vanity Fair, 2012) описывал культуру внутренней конкуренции и оценки сотрудников по сравнению друг с другом («stack ranking»), которая, по его материалам, препятствовала сотрудничеству. Аналитики и журналисты сомневались, решит ли такая реорганизация проблемы: функциональная структура упрощает координацию по технологиям, но затрудняет ответственность за продуктовые результаты.

Как читать. Это пример осознанного выбора функциональной формы для компании, чьи продукты (ОС, облако, устройства, приложения) тесно связаны и должны работать как единая экосистема; выбор — компромисс: больше интеграции и общих стандартов, меньше самостоятельности продуктов. Оговорки: оценка результата реформы неоднозначна и смешана с другими изменениями (смена руководителя в 2014 году, стратегические решения, конъюнктура); структура позднее менялась. Нельзя приписывать итог только структуре.

Кейс 3. Toyota: функциональная структура с «интегратором» — главным инженером

Исследователи разработки продукта в Toyota (Собек, Лайкер и Уорд, «Another Look at How Toyota Integrates Product Development», Harvard Business Review, 1998) описали организацию, в которой инженеры работают в сильных функциональных группах (кузов, двигатель, шасси), а продукт «сшивает» главный инженер (shusa) — фигура с широкими полномочиями по концепции, но без формальной власти над функциональными руководителями, которая влияет через авторитет, документы и процессы. Идея: сохранить глубину экспертизы и добавить интегрирующую роль и стандартные механизмы (визуальные обзоры, стандарты, обучение). Оговорка: это описание одной компании и конкретной эпохи; перенос практики требует и культуры, и системы обучения.

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

1. Принцип: группировка по функции максимизирует специализацию

   Специалисты одной области работают вместе: накапливают экспертизу, делятся приёмами, растут по профессиональной лестнице, эффективно используют дорогие ресурсы (лаборатории, станки, системы). Это даёт экономию масштаба и предсказуемость. Функциональную структуру ценят, когда качество в профессиональной области — главный источник конкурентоспособности.

2. Принцип: подходит для стабильной и предсказуемой деятельности

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

3. Принцип: силосы возникают естественно и требуют противодействия

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

4. Принцип: подотчётность за результат для клиента

   В чистой функциональной структуре никто из функциональных руководителей не отвечает за итог для клиента или продукта целиком. Решения: назначить владельца продукта или процесса («сквозного» результата) поверх функциональной иерархии; включить в оценку функциональных руководителей общие показатели; определить, кто принимает решения при конфликте функций (см. роли RAPID/BAIN).

5. Принцип: структура следует за стратегией

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

6. Принцип: метрики

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

7. Принцип: применение в организации (аналогия)

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

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

Типовые ошибки

1. Ошибка 1: сохраняют чисто функциональную структуру при росте продуктового разнообразия.

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

   Как избежать

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

2. Ошибка 2: не строят механизмы кросс-функциональной координации.

   Организация полагается на иерархию; рождаются силосы, теряется целостная перспектива клиента и продукта.

   Как избежать

   вводить совместные команды, регулярные межфункциональные обзоры, общие цели и метрики, интегрирующие роли (как главный инженер в Toyota).

3. Ошибка 3: нет подотчётности за итоговый результат.

   Ни один функциональный руководитель не отвечает за результат для клиента; при провале виноваты «другие функции».

   Как избежать

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

4. Ошибка 4: локальные метрики без общих.

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

   Как избежать

   добавить общие метрики уровня процесса или клиента в оценку функциональных руководителей.

5. Ошибка 5: реорганизация вместо изменения процессов и стимулов.

   Схема структуры меняется, а решения, метрики и оценка остаются прежними; эффекта нет, усталость растёт.

   Как избежать

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

6. Ошибка 6: копируют структуру известной компании.

   Схема Microsoft, Toyota или Google переносится без контекста стратегии, культуры и технологий.

   Как избежать

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

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

   Очереди на решения, споры о приоритетах и «горячие» эскалации считаются нормой; момент смены упущен.

   Как избежать

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

План внедрения

1. Неделя 1: оценить разнообразие и стабильность

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

2. Неделя 2: спроектировать функции и зоны ответственности

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

3. Неделя 3: внедрить механизмы координации

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

4. Неделя 4: назначить подотчётность за клиентский результат

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

5. Далее: мониторинг пределов структуры

   Раз в год проверять признаки перегрузки (очереди решений, споры приоритетов, рост числа продуктов) и рассматривать альтернативы — дивизиональную, матричную или гибкую структуру.

Как реализовать этот план с помощью фрейма «Функциональная оргструктура (Functional Structure)» в OrgDevTools

Фрейм «Функциональная оргструктура (Functional Structure)» в OrgDevTools — сетка из четырёх блоков-карточек в два столбца с тремя вкладками: «Карточки», «Визуализация» и «Итоги». Он построен на общем движке карточек: блоки не привязаны к неделям плана, порядок заполнения свободный.

• Вкладка «Карточки» — четыре блока: «Глубина специализации» (эффект масштаба экспертизы в каждой функции — неделя 2), «Механизмы кросс-функциональной координации» (явные процессы против силосов — неделя 3 и ошибки 2 и 4), «Проверка на масштабируемость» (не превышает ли рост продуктового разнообразия возможности функциональной модели — неделя 1 и ошибки 1 и 7) и «Подотчётность за клиентский результат» (кто отвечает за итог для клиента поверх функциональной иерархии — неделя 4 и ошибка 3). В каждом блоке — список пунктов свободного текста: пункт добавляется по кнопке или клавишей Enter, пункты можно удалять.

• Вкладка «Визуализация» — столбчатая диаграмма: число заполненных пунктов в каждом из четырёх блоков.

• Вкладка «Итоги» — итог и кнопка «Создать задачу →»; название задачи не задано отдельно, поэтому используется стандартное «Продолжить проработку фрейма», а в описание подставляются незаполненные блоки или отметка «Все блоки заполнены — проверить и внедрить результат».

• Итог считает только заполненные пункты: если пунктов нет — просит начать с любого блока; если какие-то блоки пусты — перечисляет их; если заполнены все четыре — сообщает общее число пунктов и самый насыщенный блок. Итог «зелёный» уже при одном пункте в каждом блоке.

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

Рабочие настройки фрейма, которых нет в методике. Индекс давления от 0,6 — повод рассмотреть дивизиональную или матричную структуру. Порог — рабочая настройка фрейма.

Книги по теме

Лютер Гьюлик, Линдалл Урвик (ред.) — «Papers on the Science of Administration» (1937). Классическое изложение четырёх оснований департаментализации, включая функциональную (процессную) группировку.

Альфред Чандлер — «Strategy and Structure: Chapters in the History of the Industrial Enterprise» (1962). Исторический анализ перехода от функциональной к многодивизиональной структуре (DuPont, General Motors, Standard Oil, Sears).

Пол Лоуренс, Джей Лорш — «Organization and Environment» (1967). Дифференциация и интеграция подразделений и зависимость структуры от среды.

Джей Гэлбрейт — «Designing Complex Organizations» (1973). Механизмы координации и выбор структуры в зависимости от неопределённости и взаимозависимости.