# Сначала «как есть»: почему изменения проваливаются на старте
> Разбор второй лекции по управлению изменениями из программы MBA CIO: жёсткие и мягкие ситуации, карта проблем и системные схемы, чем симптом отличается от проблемы, порядок работы с будущим состоянием — стейкхолдеры, миссия, тип культуры — и правило непротиворечивой миссии.
Источник: https://blog.uspeshnyy.ru/blog/snachala-kak-est-diagnostika-izmeneniy/
Автор: Александр Успешный · blog.uspeshnyy.ru
Опубликовано: 2015-01-30
Теги: MBA, система, стратегия, аналитика, Управление изменениями, Олег Бекбулатов
---
Компания решает меняться. Первый вопрос, который обычно звучит на совещании: «какую систему внедряем» или «какую методологию берём». И это ровно та точка, где всё идёт не туда.
Правильный порядок другой: сначала описать, **как есть**, потом договориться, **как надо**, и только потом выбирать инструменты. Если начать с инструмента, мышление сразу зашорено: вы будете объяснять реальность выбранным методом вместо того, чтобы смотреть на неё.
Это вторая лекция по управлению изменениями из программы MBA CIO. В первой мы разбирали [матрицу выбора подхода и почему всё решает смысл](/blog/upravlenie-izmeneniyami-matrica-i-smysl/). Здесь — практическая часть: как устроена диагностика и что делать с противоречивыми ожиданиями людей.
## Три задачи, которые решают по очереди
Любое изменение в организации проходит три этапа, и путать их дорого.
Первая — **диагностика**: построить системную модель организации и найти в ней проблемы. Вторая — **проектирование**: спроектировать системы, свободные от этих проблем. Третья — **внедрение**: сделать так, чтобы спроектированное зажило своей жизнью.
Пропуск первого этапа — самая частая и самая дорогая ошибка. Без модели вы лечите то, что заметнее, а не то, что болит.
## Жёсткие и мягкие ситуации
Прежде чем выбирать метод, нужно понять, с какой ситуацией имеете дело.
| Тип ситуации | Признак | Чем решается |
|---|---|---|
| **Жёсткая** | понятно, что не так и что считать результатом | управление операциями, реинжиниринг процессов, управление качеством, шесть сигм |
| **Пограничная** | часть ясна, часть — нет | попытаться свести к жёсткой, но осознанно |
| **Мягкая** | не сходятся даже мнения о том, в чём проблема | работа со смыслами, культурой, ожиданиями |
Ключевой момент — про пограничную. Её **можно** редуцировать к жёсткой: искусственно сузить рамку, объявить часть вопросов решёнными и взяться за понятный метод. Но это ответственное решение, и принимать его надо вслух, понимая, что вы упрощаете. Иначе получится знакомая картина: внедрили систему, а причина осталась.
## Карта проблем и схемы под каждый узел
Диагностика начинается не с интервью по списку, а с карты.
**Шаг первый — карта памяти.** Рисуете структуру проблемного поля: подразделения, процессы, узлы, где что-то идёт не так. Пример из разбора реального кейса: снижение финансового результата → срыв сроков монтажа → а дальше расходятся ветки:
- **Кабель:** отсутствует (воруют, задержки производства, задержки перевозки) или бракованный.
- **Люди:** прогулы, болезни, текучка из-за тяжёлых условий и постоянных переездов.
- **Оборудование:** для монтажа и для связи — отсутствует, приходит не вовремя, некачественное.
- **Погода:** зимой мёрзлый грунт, летом затопление траншей.
**Шаг второй — к каждому узлу подобрать тип схемы**: диаграмма влияния, схема входов и выходов, схема последовательности, системная карта. Смысл в том, чтобы каждый узел стал описуемым, а не остался словом на доске.
Отдельное правило про глубину: детализировать до бесконечности не нужно. Чем подробнее карта, тем тяжелее её сдвинуть. Достаточно уровня, на котором видно проблему и понятно, чем её описывать.
**И самое важное различение.** «Система, порождающая брак», «система, порождающая текучесть» — это **симптомы**, а не проблемы. Проблема лежит глубже, и от симптомов к ней поднимаются отдельной техникой. Если начать чинить симптом, получите ремонт, который не держится.
## Будущее состояние: пять шагов до инструментов
Когда «как есть» описано, начинается работа с «как надо». И здесь порядок такой же жёсткий.
Начинается всё со **стейкхолдеров** — и не с абстрактных «сотрудников», а с конкретных групп и их настоящих желаний. Вот как это выглядело в разобранном кейсе:
| Группа | Чего хочет на самом деле |
|---|---|
| Владелец | узнаваемости, общих ценностей, гордости за компанию, понятного языка внутри |
| Топ-менеджеры | больше зарабатывать, статус, жёсткую вертикаль без придирок |
| Старые сотрудники | признания заслуг, роста зарплаты, чтобы ничего не менялось |
| Новые сотрудники | не перерабатывать, высыпаться, зарабатывать, не лезть в чужие дела |
Эти ожидания **противоречат друг другу** — и это нормально. Задача не в том, чтобы объявить одну группу неправой, а в том, чтобы написать текст, который каждая узнаёт как свой.
## Правило непротиворечивой миссии
Дальше — самая тонкая часть, где чаще всего ломается доверие.
Миссия собирается по понятной рамке: кто мы → куда хотим попасть → как это сделаем → что получат заинтересованные стороны. Но к ней два жёстких требования.
**Первое: не обещать того, чего не сделаете.** Написать «каждый сотрудник получит отдельный кабинет» можно. Но когда люди увидят, что их обманули, рухнет не только миссия — рухнет вся затея с корпоративной культурой, и второй попытки не будет.
**Второе: доказать, что ожидания учтены.** Механизм проверки простой: берёте список ожиданий каждой группы и подсвечиваете в тексте миссии фрагменты, которые их закрывают. Владелец хотел узнаваемости — вот эта строчка. Топы хотели зарабатывать — вот эта. Если для какой-то группы подсветить нечего, миссия для неё пустая.
**Где сегодня помогает AI.** Свести десяток противоречивых ожиданий в непротиворечивый текст — как раз задача, где модель полезна: она быстро перебирает формулировки и показывает, где обещание одной группе задевает другую. Решение всё равно за человеком, но черновиков не жалко.
Только после миссии определяется **тип корпоративной культуры**, который ей соответствует, и составляется матрица: что делать на индивидуальном, групповом и организационном уровнях, чтобы культура двинулась в нужную сторону.
## Вывод
Три вещи стоит унести. **Инструмент выбирают последним** — сначала «как есть», потом «как надо», иначе метод начнёт диктовать вам картину реальности. **Симптом — не проблема**: «текучка» и «брак» это следствия, и ремонт следствий не держится. И **миссия проверяется подсветкой**: если под ожиданиями группы нечего подчеркнуть в тексте, для этой группы вы ничего не написали.
**Следующий шаг:** возьмите изменение, которое собираетесь запускать, и честно ответьте — вы уже выбрали инструмент? Если да, отложите его на час и нарисуйте карту: что именно не так, из чего это следует и кто в этом участвует. Скорее всего, инструмент останется тем же — но вы будете знать, что именно он должен починить.