Сначала «как есть»: почему изменения проваливаются на старте

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

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

Это вторая лекция по управлению изменениями из программы MBA CIO. В первой мы разбирали матрицу выбора подхода и почему всё решает смысл. Здесь — практическая часть: как устроена диагностика и что делать с противоречивыми ожиданиями людей.

Три задачи, которые решают по очереди

Любое изменение в организации проходит три этапа, и путать их дорого.

flowchart LR
    A["1. Диагностика<br/>системная модель<br/>организации"] --> B["2. Проектирование<br/>системы, в которых<br/>проблемы нет"]
    B --> C["3. Внедрение<br/>чтобы новое зажило<br/>своей жизнью"]
    A -. "пропустили —<br/>лечим симптомы" .-> C

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

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

Жёсткие и мягкие ситуации

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

Тип ситуации	Признак	Чем решается
Жёсткая	понятно, что не так и что считать результатом	управление операциями, реинжиниринг процессов, управление качеством, шесть сигм
Пограничная	часть ясна, часть — нет	попытаться свести к жёсткой, но осознанно
Мягкая	не сходятся даже мнения о том, в чём проблема	работа со смыслами, культурой, ожиданиями

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

Карта проблем и схемы под каждый узел

Диагностика начинается не с интервью по списку, а с карты.

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

• Кабель: отсутствует (воруют, задержки производства, задержки перевозки) или бракованный.
• Люди: прогулы, болезни, текучка из-за тяжёлых условий и постоянных переездов.
• Оборудование: для монтажа и для связи — отсутствует, приходит не вовремя, некачественное.
• Погода: зимой мёрзлый грунт, летом затопление траншей.

Шаг второй — к каждому узлу подобрать тип схемы: диаграмма влияния, схема входов и выходов, схема последовательности, системная карта. Смысл в том, чтобы каждый узел стал описуемым, а не остался словом на доске.

Отдельное правило про глубину: детализировать до бесконечности не нужно. Чем подробнее карта, тем тяжелее её сдвинуть. Достаточно уровня, на котором видно проблему и понятно, чем её описывать.

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

Будущее состояние: пять шагов до инструментов

Когда «как есть» описано, начинается работа с «как надо». И здесь порядок такой же жёсткий.

flowchart TB
    A["1. Состав заинтересованных сторон"] --> B["2. Что каждая сторона<br/>хочет на самом деле"]
    B --> C["3. Миссия:<br/>свести ожидания<br/>непротиворечиво"]
    C --> D["4. Тип культуры,<br/>который этой миссии<br/>соответствует"]
    D --> E["5. Что делать на трёх уровнях:<br/>человек · группа · организация"]

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

Группа	Чего хочет на самом деле
Владелец	узнаваемости, общих ценностей, гордости за компанию, понятного языка внутри
Топ-менеджеры	больше зарабатывать, статус, жёсткую вертикаль без придирок
Старые сотрудники	признания заслуг, роста зарплаты, чтобы ничего не менялось
Новые сотрудники	не перерабатывать, высыпаться, зарабатывать, не лезть в чужие дела

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

Правило непротиворечивой миссии

Дальше — самая тонкая часть, где чаще всего ломается доверие.

Миссия собирается по понятной рамке: кто мы → куда хотим попасть → как это сделаем → что получат заинтересованные стороны. Но к ней два жёстких требования.

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

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

Где сегодня помогает AI. Свести десяток противоречивых ожиданий в непротиворечивый текст — как раз задача, где модель полезна: она быстро перебирает формулировки и показывает, где обещание одной группе задевает другую. Решение всё равно за человеком, но черновиков не жалко.

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

Вывод

Три вещи стоит унести. Инструмент выбирают последним — сначала «как есть», потом «как надо», иначе метод начнёт диктовать вам картину реальности. Симптом — не проблема: «текучка» и «брак» это следствия, и ремонт следствий не держится. И миссия проверяется подсветкой: если под ожиданиями группы нечего подчеркнуть в тексте, для этой группы вы ничего не написали.

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