Работа руководителя — принимать решения. А если вы большой босс — оценивать решения, предлагаемые подчиненными. Можно это делать на интуиции, а можно — правильно.
Правильно — это когда у вас есть определенный алгоритм, проверенный способ (и это сейчас не про «пальцем в небо»), фреймворк, надёжная методика или подсистема, которые позволяют вам решать любые сложные управленческие задачи. Сложные — это значит «не решаемые ранее» задачи. Когда в компании не только нет опыта их решения, но и вообще неизвестно, с какой стороны подойти к решению такого рода задач.
Окружить себя знающими профессионалами с готовыми ответами на все вопросы тоже не получится, поскольку скорее рано, чем поздно, жизнь столкнет их с задачей, которую они тоже никогда не решали.
Частые ошибки при решении сложных управленческих задач
В теории бизнес-анализа (да-да, есть и теория бизнес-анализа –– BABOK®- руководство к своду знаний по бизнес-анализу, разработанное международным институтом бизнес-анализа в Торонто) в контексте решения сложных задач упоминается пайплайн
«Проблема → Потребность → Требование → Решение»
Первая самая часта ошибка в том, что не все, кто берётся за решение какой-либо задачи, вообще знает о таком цикле. А вторая частая ошибка управленческих или ИТ-проектов состоит в путанице и подмене понятий. Исполнители путают:
- проблему и потребность
- потребность и требования
- проблему и требования
и тем не менее резво берутся за генерацию решений, не успев толком разобраться в важнейших вопросах:
- каковы предмет и суть проблемы, можно ли как-то её оцифровать?
- почему это — проблема?
- какие в связи с этим возникают потребности у собственника/ Заказчика?
- как эти потребности можно представить в виде конкретных и измеримых требований?
- как может выглядеть идеальное решение?
- как мы точно поймём, что проблема решена?
и т.д.
и это порождает целый ворох неприятных последствий.
Один главный навык решения управленческих задач, овладев которым вы сильно расстроите партнёров из BIG4 — ведь им не выгодно, чтобы о таком навыке узнали и пользовались их потенциальные клиенты
В свете всего этого, я для себя определил такой навык, на который полагаюсь при решении сложных управленческих задач. Этот навык — умение структурировать проблему.
Зарубежом этот класс навыков называют problem solving skills.
И пример такого problem solving'a я привел в конце этой статьи.
А пока поделюсь с вами некоторыми фреймворками, которыми я сам чаще всего пользуюсь в случаях, когда требуется структурировать незнакомую, нетипичную проблему, чтобы найти решение сложной и масштабной управленческой задачи.
Этот «набор» фреймворков меня еще ни разу не подводил.
Основной фреймворк структурирования проблем, которым я пользуюсь
В первую очередь я определенным образом строю процесс понимания задачи, потому что отдаю себе отчет в том, что правильно сформулированная проблема содержит 50% решения.
Это не преувеличение и 50% здесь не для «красного словца». Иногда даже больше 50% решения находится в правильном понимании задачи, настолько это важный процесс. Лучше неделю «потерять» на выяснение всех обстоятельств и опрос всех стейкхолдеров, чем потом несколько месяцев блуждать впотьмах в поисках решения, и в итоге обнаружить, что всё это время ты решал не ту задачу.
Избежать такого результата и помогает фреймворк ниже:
- Сбор, структурирование и анализ данных
- Определение фактов и предпосылок, описание проблемной зоны особым образом (по определенной структуре)
- Impact-анализ, приоритезация
- Определение областей анализа и плана работ
- Обобщение результатов анализа и синтез решения, подготовка рекомендаций
- Презентация решения, которое устранит проблему наилучшим образом
Эти шесть последовательных этапов неизбежно приводили меня к обнаружению проблемных зон, углубленный анализ которых заканчивался пониманием истинных причин возникновения проблем и способов их нейтрализации.
В целом, это довольно верхнеуровневый фреймворк, который скорее отвечает на вопрос «что делать?» а не «как делать?», поэтому людям без знания других техник его бывает недостаточно для того, чтобы докопаться до истинных причин проблем, и проработать оптимальные варианты их решения.
Поэтому я рекомендую применять и другие канвасы и фреймворки, которые как раз помогают найти ответ на вопрос «как?». О них ниже.
PSW (Problem Statement Worksheet)
Также помогает зафиксировать верхнеуровневое, но довольно всестороннее понимание задачи фреймворк PSW — Problem Statement Worksheet.
Он состоит из цели работы (задачи) и 6 блоков:
- Контекст
- Критерии успеха
- Пространство решений
- Ограничения пространства решений
- Заинтересованные стороны
- Источники информации
которые позволяют уже на старте оценить реалистичность цели, выявить противоречия в целях и способах
Так, в нашем примере выше заявлена цель добиться 50% роста прибыли без инвестиций и заемных средств, и только за счёт улучшения работы розничных точек на фоне х2 падения рынка.
Такая постановка задачи не выглядит решаемой в реальных условиях.
Что делать?
Использовать Root Cause Analysis — поискать корневые причины.
Root Cause Analysis (RCA)
Анализ корневых причин позволяет ответить на вопросы:
- что произошло?
- как произошло?
- почему произошло?
Проблема, чаще всего, будет включать следующие факторы:
- Физический фактор — проблема материальна и осязаема в физическом мире.
- Человеческий фактор, связанный с ошибкой определенного человека.
- Организационный фактор — когда какой-то процесс или система, используемые для принятия решений и выполнения задач, неисправны.
И тут хорошо подходит техника 5W.
Иногда она способна просто с ног на голову перевернуть понимание ситуации и формулировку задачи.
5 WHY
Считается, что 5 WHY или 5 «Зачем?», «5 Почему?» придумали в Toyota. Скорее всего, вы уже знаете в чем её смысл, поэтому не буду повторяться. В целом это очень мощная техника, которая позволяет выйти из множества логических тупиков при поиске решений.
Однако я бы не рекомендовал задавать этот вопрос именно в такой формулировке более 2-х раз подряд, если только вы не хотите вывести из себя интервьюируемого.
Кстати, будет хорошей практикой применять оба вопроса и «зачем?» и «почему?».
- Пример результата применения фреймворков
Problem Solving кейс
Как инструменты RCA могут работать на практике и влиять на управленческие решения?
Давайте рассмотрим такой пример из реальной жизни:
- В крупной компании N есть проблемы с документооборотом: средний срок согласования договора составляет 6 месяцев.
Ну что? Проблема есть, проблему надо решать.
Созвали рабочую группу из руководителей департаментов, обсудили проблему, и внутри себя решили, что их спасёт автоматизация документооборота.
А как же ещё? У всех участников РГ на предыдущих местах работы весь документооборот был автоматизирован. СЭД — мейнстрим.
Объявили тендер среди ИТ-разработчиков такого класса программ.
Главный аналитик победителя тендера не поверил постановщику задачи «на слово», и прошёлся с уточняющими вопросами по всему циклу «Проблема → Потребность → Требования → Решения».
Что он выяснил с помощью RCA?
- Документ согласовывают 20 руководителей
- Владельца процесса «Согласование документа» не существует
- Согласование идет строго последовательно
- Некоторые руководители участвуют в согласовании дважды
Проект по автоматизации был успешно завершен за 6 месяцев и обошёлся заказчику в Х рублей (довольно круглую сумму с шестью нулями). В результате срок согласования договора сократился вдвое: с 6 месяцев до 3.
Но что тут характерно?
Тот же главный аналитик выяснил, что если бы Заказчик просто удалил дублирование, назначил владельца процесса «Согласование» и запараллелил некоторые этапы, то:
- срок реализации проекта «Оптимизация документооборота» составил бы 2 месяца вместо 6
- срок согласования документов сократился бы до 4-х месяцев
- и проект обошелся бы Заказчику в 0 (ноль) рублей дополнительных затрат, поскольку все работы выполнили бы действующие сотрудники в рамках своих должностных инструкций и окладов.
В этом случае победитель тендера просто заработал свои деньги, решив поставленную Заказчиком задачу по автоматизации документооборота.
Исполнитель — молодец, вопросов нет.
Зато есть пара вопросов к Заказчику ...
- Мог ли Заказчик как-то иначе сформулировать свою потребность? — Мог.
- Мог сформировать образ идеального конечного результата в другом виде/форме? — Безусловно, мог.
Ну ок, мог. И что тогда?
И тогда могло бы выясниться, что на самом деле:
1. сохранение в бюджете Заказчика круглой суммы приоритетнее автоматизации процесса, который можно хорошо настроить и «в бумаге»
2. сокращение сроков согласования договоров с 6 до 4-х месяцев — вполне приемлемый результат
3. крайне важно стартовать новый документооборот как можно быстрее
А это уже, согласитесь, в корне иной контекст и иное решение!
Эти немногочисленные вопросы Заказчик мог и должен был «докрутить» «на своей стороне» с помощью RCA методик в том числе, прежде чем объявлять тендер на разработку. Тогда и финансовые результаты периода могли быть другими, ведь даже тем более в успешных организациях каждый миллион на счету. В том смысле что «на учёте».
Да и никакого тендера бы не было — не нужен он тут.
Михаил Морозов, @investcommittee
