Аксиоматическое проектирование: почему оргструктура - это не весь организационный дизайн

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

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

Прошло несколько месяцев — и обнаружилось, что:

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

Что пошло не так?

Возможно, мы изменили структуру, но не изменили дизайн системы.

Если посмотреть на организацию как на систему, структура оказывается только одним из элементов ее конструкции. Есть как минимум:

Можно изменить структуру и оставить все остальное прежним. И тогда старая организация довольно быстро «восстановится» поверх новой схемы.

В инженерии редко начинают проектирование с вопроса: «Как расположить детали?» Сначала определяют: что система должна делать? А уже затем ищут конструкцию, которая позволит это обеспечить.

Именно на этом принципе построено аксиоматическое проектирование (Axiomatic Design) - методология проектирования, разработанная Нам П. Су в MIT.

Ее исходная область - инженерные системы, но логика метода применима и к сложным организационным системам. Главная идея для нас очень проста:

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

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

А что на самом деле хочет получить бизнес?

Например:

Вот теперь мы начинаем проектировать.

Получается последовательность: функции → требования → конструкция системы

а не: структура → роли → попытка заставить систему работать.

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

Чем сложнее организация, тем опаснее проектировать ее только через орг чарт.

Представьте, что нам нужно одновременно:

Можно построить структуру, которая формально отвечает всем этим требованиям.

Но затем обнаружить:

То есть элементы дизайна начинают влиять сразу на несколько функций. И здесь возникает одно из центральных понятий аксиоматического проектирования:

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

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

А в смысле последовательности рассуждения.

Мы можем спросить:

1. Что должна обеспечивать организация? Функциональные требования.

2. Какие ограничения существуют? Регуляторика, технологии, рынок, бюджет, география, существующие обязательства.

3. Какую конструкцию мы создаем? Структура, роли, полномочия, процессы, информационные связи.

4. Насколько эта конструкция действительно обеспечивает нужные функции? Здесь начинается проверка дизайна.

5. Где возникают нежелательные взаимные зависимости? Здесь мы ищем связанность.

И вот здесь появляется очень полезный вопрос:

В следующем материале перейдем от идеи к инструменту и разберемся с Design Matrix.

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

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