ТО для бизнеса. 40 типовых операционных проблем и как их решить

5. Совершенный — IPS — часть ежедневного ритма. 90% проблем решаются на операционном уровне.

КЛЮЧЕВАЯ МЫСЛЬ ГЛАВЫ

До 90% операционных проблем решаемы силами линейного персонала — если он обучен IPS-инструментам и получает по ним постоянную обратную связь.

ПРОБЛЕМА 6. Много приоритетов — значит, ничто не в приоритете

«Умение работать умно означает умение говорить „нет“ тому, что не является приоритетом».

Стив Джобс

Суть проблемы

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

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

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

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

Проблема возникает на двух уровнях:

1. Индивидуальный: сотрудники не различают важное и срочное. День заполнен активностью, которая не приближает к результату.

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

ПРОВЕРЬТЕ СЕБЯ: есть ли у вас проблема с приоритизацией?

☐ На вопрос о приоритете сотрудники называют несколько задач вместо одной

☐ У разных членов команды разное понимание того, что сейчас главное

☐ Важные задачи регулярно откладываются из-за срочных, но менее значимых

☐ Руководитель часто меняет фокус команды в течение недели или дня

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

☐ Нет регулярной синхронизации приоритетов на уровне команды

☐ KPI конкурируют между собой и не дают ясного фокуса

☐ Совещания проходят без чёткого понимания конечного результата

☐ Ключевые проекты системно не доводятся до завершения

☐ Разрыв между запланированным и выполненным стабильно высокий

Если вы отметили 3 и более пункта — эта проблема присутствует в вашей организации.

ПРАКТИЧЕСКИЕ СОВЕТЫ

Быстрая диагностика. Спросите у линейного персонала смены: «Какой приоритет у смены на сегодня?» Разброс ответов — индикатор пробела в своевременной и последовательной коммуникации приоритетов сверху-вниз.

Решение 6.1. Еженедельная сверка: один приоритет, который невозможно упустить

Еженедельная сверка синхронизирует команду без сложных систем. Один вопрос: «Каков мой главный приоритет на этой неделе и как он связан с общими целями?»

Принцип «одного приоритета»

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

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

По плану работы отклонение допустимо. По приоритету — нет.

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

Алгоритм внедрения

1. Подготовка до планёрки. От каждого участника представить: полный план → выделить один-два приоритета → зафиксировать статус прошлой недели. Неподготовленный участник — сигнал: нет системы планирования или понимания важности. Оба варианта требуют коучинга.

2. Руководитель открывает планерку. Команда видит: его приоритет связан со стратегическими целями. Это задаёт контекст для согласования приоритетов.

3. Тайминг для каждого участника — 2—3 минуты. Приоритет: что, почему, ожидаемый результат. Краткий обзор плана. Статус прошлой недели.

4. Командная верификация. Соответствуют ли приоритеты общим целям? Нет ли конфликтов между участниками? Нужно ли перераспределить ресурсы?

5. Нарушение — коучинг на месте. Приоритет не определён, не связан с целями или нарушен без объяснения — короткий разбор прямо на планёрке.

Сверка приоритетов для команды из 6—8 человек — не более 10 минут.

ПРАКТИЧЕСКИЕ СОВЕТЫ

1. Начинайте с себя. Система не работает, если руководитель сам не применяет её. Задавайте темп личным примером.

2. Первые 2—3 недели — коучинг, а не критика. У части команды не будет чёткого приоритета. Навык формируется — помогайте, не осуждайте.

3. Отслеживайте системные отклонения. Участник несколько недель не выполняет приоритет — сигнал: системная перегрузка, проблема с планированием или неверно сформулированный приоритет. Каждый вариант — отдельный разговор.

ПОПРОБУЙТЕ СЕЙЧАС 10 мин.,

каждый понедельник 10-минутная сверка приоритетов

Запустите еженедельную сверку приоритетов в ближайший понедельник.

1. Объявите команде: каждый понедельник в 9:00 — 10—15-минутная сверка приоритетов.

2. Правило команды: каждый приходит с одним приоритетом (максимум двумя) на неделю.

3. Вы называете свой приоритет первым — команда видит связь с целями бизнеса.

4. Каждый: приоритет + статус прошлой недели (выполнен / не выполнен / почему).

5. Нарушение правила «приоритет выполняется на 100%» обсуждается публично на следующей сверке.

Инструментальная база: цветовая кодировка в Outlook

Практический элемент, который значительно повышает эффективность системы, — цветовое форматирование задач в Outlook-календаре по заранее согласованной легенде.

Простой пример цветовой схемы, которую использую уже более 20 лет:

Табл. 6.1а. Цветовое кодирование задач в Outlook

Открытые и единообразно отформатированные календари: руководитель за 30 секунд видит распределение времени каждого — выявляет перегрузку, отсутствие фокуса или конфликт приоритетов до того, как они стали проблемой.

Рис. 6.1а. Пример расстановки приоритетов в календаре Outlook

Матрица Эйзенхауэра как вспомогательный инструмент

Для команд, которым сложно самостоятельно определить приоритеты среди множества задач, полезно использовать матрицу Эйзенхауэра — инструмент разделения задач по двум осям: важность и срочность.

Табл. 6.1б. Матрица Эйзенхауэра

Большинство руководителей работают в Квадрантах I и III — реагируют на срочное. Однако стратегические результаты создаются в Квадранте II — важном и несрочном, который текучка постоянно вытесняет. Еженедельная сверка — системная защита Квадранта II.

РЕЗУЛЬТАТЫ

✓ Фокус. Приоритет назван вслух и подкреплён правилом «100% выполнения». То, что неделями откладывалось, начинает выполняться.

✓ Синхронизация. Команда прекращает работать в режиме «каждый со своей версией важного». Сверка делает конфликты приоритетов видимыми.

✓ Управленческая прозрачность. Руководитель видит реальное распределение времени и усилий, а не только отчёты. Корректировка курса — до возникновения проблемы.

✓ Культура ответственности. Публично назван приоритет — публично ожидается результат. Личная ответственность перестаёт быть абстракцией.

ДИАГНОСТИКА: зрелость приоритизации

Оцените текущее состояние вашей организации по шкале 1—5:

1. Критический — нет единого понимания приоритетов. Каждый работает по своей версии «важного».

2. Начальный — приоритеты называются на совещаниях, но не выполняются системно.

3. Развивающийся — еженедельная сверка проводится, но правило 100% исполнения приоритетной задачи не соблюдается.

4. Зрелый — сверка ежемесячно. Приоритеты выполняются. Невыполнение открыто разбирается.

5. Совершенный — команда синхронизирована. Каждый знает командный приоритет и свой вклад в него.

КЛЮЧЕВАЯ МЫСЛЬ ГЛАВЫ

Приоритет — это одна задача, которая выполняется при любых обстоятельствах.

ПРОБЛЕМА 7. Изменения запущены. Результатов нет

«Улучшить — значит изменить; быть совершенным — значит часто меняться».

Уинстон Черчилль

Суть проблемы

Суть менеджмента — положительные изменения: целенаправленные, последовательные, контролируемые изменения в отношении людей, процессов и систем для получения других (лучших!) результатов. Всё остальное: технологии, процессы, системы, KPI — лишь инструменты на пути к этой цели.

Казалось бы, за десятилетия академической и практической работы человечество накопило достаточно знаний об управлении изменениями, чтобы делать это хорошо. Качественных методологий достаточно: «Динамическая психология» Левина, «8 шагов к успешным переменам» Коттера, OODA-петля Джона Бойда, ADKAR Хайатта, цикл PDCA — SDCA Деминга — Шухарта.

Все нужные практики есть.

Грамотного внедрения изменений — почти нет.

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

Причина не в дефиците информации. Причина в том, что обладание информацией — это не то же самое, что опыт её применения. И в том, что организации продолжают ставить технологию выше психологии, показатели выше взаимоотношений, P&L выше корпоративной культуры. А именно культура — первична. Именно она определяет, приживутся ли изменения или превратятся в очередную «корпоративную деформацию».

Примечание. Это решение основано на материалах и практике Андрея Левченко — эксперта в области бизнес-психологии, управления изменениями и развития лидерства.

ПРОВЕРЬТЕ СЕБЯ: почему изменения не дают результата?

☐ Изменения запускаются, но через несколько месяцев всё возвращается к прежнему состоянию

☐ Сотрудники формально «соглашаются», но фактически работают по-старому

☐ Новые инициативы воспринимаются со скепсисом или даже цинизмом

☐ Решения принимаются быстро, без анализа готовности и рисков

☐ Цели и KPI по проекту корректируются «по ходу», чтобы показать результат

☐ Нет чёткого плана коммуникации — сотрудники узнают об изменениях постфактум

☐ Ответственность за результат размыта или не закреплена

☐ Прогресс по изменениям не виден — нет быстрых результатов

☐ Руководители используют давление вместо вовлечения и коучинга

☐ Изменения запускаются как проекты, но не закрепляются в ежедневной работе

Если вы отметили 3 и более пункта — эта проблема присутствует в вашей организации.

Семь фундаментальных ошибок

Ошибка 1. Технология важнее психологии. Организация вкладывает в систему или процесс и рассчитывает на автоматическую адаптацию людей. «Мы объяснили — почему не делают?» Потому что поведение меняется не тогда, когда человек понимает логику, а когда он готов к изменениям эмоционально и культурно.

Ошибка 2. Волюнтаризм при запуске. Главный аргумент — «Хочу!» — без диагностики готовности и оценки рисков. Проект стартует не в нужное время и не с нужными ресурсами.

Ошибка 3. DAO вместо OODA. Decide → Act → Orient (Решать — Действовать — Ориентироваться) вместо Observe → Orient → Decide → Act (Наблюдать — Ориентироваться — Решать — Действовать). Сначала решение и действие — потом попытка понять, что происходит. Системный менеджер начинает с наблюдения.

Ошибка 4. Несвоевременность или деструктивность. Изменения несвоевременны, излишни или ломают смежные процессы. Корень — отсутствие системного мышления: неспособность видеть организацию как взаимосвязанную систему.

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

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

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

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

Решение 7.1. Семь правил, без которых любые изменения обречены

Семь правил — чек-лист для управления изменениями, независимо от масштаба проекта, типа и отрасли бизнеса. Каждое нарушенное правило — предсказуемая причина провала.

Правило 1. Начинайте с OODA. OODA-loop (Observe→Orient→Decide→Act) — цикл Джона Бойда для условий неопределённости. Начинать с наблюдения, не с решения — вот что отличает системного менеджера от импульсивного. Работает на протяжении всего проекта.

Рис. 7.1а. Петля OODA

Правило 2. Три железобетонных аргумента на старте. Три ответа для каждого уровня организации:

• «Неотвратимость»: это произойдёт в любом случае. Снимает «А надо ли?»

• «Безотлагательность»: почему именно сейчас? Снимает «А почему не потом?»

• «Личная ценность»: что это даёт конкретно мне? Снимает «А причём тут я?»

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

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

Табл. 7.1. Сценарный анализ проекта изменений

Правило 5. Коттер + ADKAR. 8 шагов Коттера — организационный маршрут. ADKAR — индивидуальная диагностика. На практике: идёте по шагам Коттера и на каждом шаге проверяете готовность каждого человека через ADKAR. Застрял на Awareness — информируйте. На Desire — работайте с мотивацией. На Knowledge — обучайте. Коттер без ADKAR — маршрут без GPS. ADKAR без Коттера — диагностика без плана.

Рис. 7.1б. Шаги ADKAR

Правило 6. PDCA → SDCA в течение всего проекта. Проект изменений — итеративный цикл, не прямая линия. PDCA — фаза внедрения. SDCA — фаза закрепления: работающее изменение фиксируется как стандарт — иначе через месяц всё вернётся. SDCA зачастую игнорируют. Поэтому даже те проекты, что поначалу казались успешными, спустя полгода бесследно исчезают.

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

ПОПРОБУЙТЕ СЕЙЧАС 60 мин.

Перевод проекта в SDCA-цикл

Реализуйте SDCA-цикл для недавно завершенного проекта.

1. Выберите один проект, который «завершён» — но результаты не закреплены.

2. Спросите: «Новый способ работы зафиксирован в стандарте?» Если нет — сделайте это прямо сейчас.

3. Спросите: персонал обучен новому стандарту? Если нет — запланируйте обучение на эту неделю.

4. Спросите: новый стандарт включён в LSW и DMS-проверки? Если нет — добавьте.

5. Теперь результат закреплён. Повторите для каждого завершённого проекта.

ПРАКТИЧЕСКИЕ СОВЕТЫ

Цикл SDCA — стандартизация достигнутых результатов — важнее самих изменений (PDCA). Самая распространённая ошибка: достигли результата — закрыли проект. Через полгода всё вернулось. Результат без стандартизации — это событие, а не изменение.

РЕЗУЛЬТАТЫ

✓ Рост успешности проектов изменений — снижение доли «формально завершённых, но не работающих» инициатив.

✓ Снижение сопротивления персонала — за счёт ясной логики, вовлечения и личной пользы.

✓ Повышение скорости внедрения — меньше откатов, пауз и «зависших» этапов.

✓ Предсказуемость реализации — готовность к разным сценариям вместо реакции «по факту».

✓ Устойчивость результатов — за счёт связки PDCA → SDCA и фиксации в стандартах.

✓ Развитие культуры изменений — открытость, обучение на ошибках, рост управленческой зрелости.

ДИАГНОСТИКА: зрелость управления изменениями

Оцените текущее состояние вашей организации по шкале 1—5:

1. Критический — изменения объявляются и затихают. Нет плана, нет SDCA, нет коммуникации.

2. Начальный — есть план внедрения, но фаза закрепления пропускается. Откат — норма.

3. Развивающийся — PDCA применяется полноценно. SDCA — частично.

4. Зрелый — проекты завершаются через SDCA. Коттер и ADKAR используются осознанно.

5. Совершенный — изменения приживаются. Персонал воспринимает их как норму, а не угрозу.

КЛЮЧЕВАЯ МЫСЛЬ ГЛАВЫ

Большинство трансформаций терпят неудачу не на этапе внедрения — а на этапе после. Культура побеждает стратегию не просто потому, что она сильнее, а потому, что саму культуру никто не включил в план изменений.

ПРОБЛЕМА 8. Проекты не движутся. Дело в процессах или в людях?

«Основная причина провала трансформаций — недооценка силы человеческих эмоций».

Джон Коттер

Суть проблемы

Стратегия разработана. Бизнес-кейс просчитан. Цели чёткие. Ресурсы выделены. Спонсор проекта на борту. Во главе — опытный руководитель. Старт проекту дан…

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

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

Это не те причины.

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

Иными словами: проект застрял не в процессах. Он уперся в человеческий фактор.

И пока команда изменений пытается «продавить» решение или «объяснить логику» тем, кто сопротивляется — она работает не с реальной проблемой. Она работает с симптомами, не понимая причины.

ПРОВЕРЬТЕ СЕБЯ: проекты застревают из-за людей, а не процессов?

☐ Согласования занимают недели без чётких и обоснованных причин

☐ Решения регулярно пересматриваются и обсуждаются повторно

☐ Совещания заканчиваются без конкретных решений и следующих шагов

☐ Скорость проекта зависит от присутствия конкретных людей

☐ Участники проекта по-разному понимают цели и подход к реализации

☐ Команда «объясняет», но ключевые стейкхолдеры не принимают решения

☐ Одни участники требуют больше деталей, другие — скорости