Система роста: Как выстроить организацию, которая работает без сбоев

5. Какие решения мы должны перестать принимать?

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

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

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

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

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

Операционная модель: как связать цели, команды и ресурсы

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

В 8:19 начальник производства посмотрел на график оборудования и увидел, что свободного окна почти нет. В 8:27 инженер сообщил, что окончательная спецификация ещё не согласована. В 8:41 руководитель сервиса впервые узнал о заказе: он получил письмо с вопросом, кто будет готовить монтажную бригаду.

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

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

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

Этим и занимается операционная модель.

Не схема подразделений, а устройство работы

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

В ней должны быть согласованы несколько вещей:

• результат, который важен клиенту;

• поток работы, создающий этот результат;

• компетенции, без которых поток не справится;

• команды и их взаимодействие;

• права принимать ключевые решения;

• люди, деньги, время и мощности;

• показатели, показывающие, работает ли система.

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

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

Начинать нужно не с вопроса «Как нарисовать подразделения?», а с вопроса «Какой клиентский результат мы обязаны уметь создавать снова и снова?».

Шаг первый. Перевести приоритет в результат клиента

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

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

Эта формулировка сразу меняет поле внимания. Успех — это не только отгруженное изделие. Если оно вовремя покинуло завод, но не прошло приёмку или не может быть установлено, обещание не выполнено.

Полезно разделять три уровня показателей:

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

2. Здоровье потока. Время от подтверждения заказа до готовности к отгрузке, объём незавершённой работы, задержки на согласованиях.

3. Защитные показатели. Качество, безопасность, маржинальность, нагрузка на ключевых специалистов.

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

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

Шаг второй. Увидеть поток целиком

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

Для «Вектора» маршрут может выглядеть так:

1. Уточнение потребности. Коммерческая команда выясняет задачу клиента, ограничения площадки и критерии успеха.

2. Проверка реализуемости. Инженеры, производство, снабжение и сервис оценивают технические риски, сроки и необходимые ресурсы.

3. Подтверждение предложения. Компания фиксирует состав решения, цену, срок, допущения и зоны риска.

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

5. Изготовление и проверка. Производство собирает заказ, контроль качества подтверждает соответствие требованиям.

6. Поставка и запуск. Логистика и сервис обеспечивают доставку, монтаж, ввод в работу и передачу знаний клиенту.

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

Такое описание ещё не является моделью. Это карта, на которой видны переходы между участниками — места, где часто теряются информация, время и ответственность. Для каждого перехода стоит спросить: какой пакет данных должен перейти дальше? Кто подтверждает, что он достаточен? Что происходит, если данных не хватает?

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

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

Шаг третий. Определить необходимые способности

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