Я прочитал статью «Как решать сложные проблемы», и увидел там сильную рамку для решения задач, но ее фокус на том, что уже проявилось. Да, можно использовать авторскую методику, и через пару месяцев увидеть, что проблема повторилась. В этой статье предлагаю посмотреть на решение сложных задач с иной стороны – проактивной, с помощью диверсионного анализа. Суть метода в том, чтобы просчитать то, что еще не случилось. Мои советы будут полезны тем управленцам, которые отвечают за проекты, где могут быть существенные последствия от не обнаруженных вовремя рисков.
Как работает диверсионный анализ
Нужно провести «диверсию» против вашего же решения или проекта. Это инструмент ТРИЗ, который, с одной стороны, помогает найти причину, не оставившую следа в фактах, с другой стороны – предсказать негативные события от решений до того, как они случатся.
Ключевой парадигмой диверсионного анализа является инверсия. Вместо того чтобы спрашивать «Что вызывает негативный эффект?» или «Почему происходит негативный эффект?», ставим вопрос в обратном порядке: «Как создать негативный эффект?» или «Как сломать систему?». Разберем работу этого подхода по пунктам.
1. Инверсия задачи вместо поиска причин
Чтобы решить проблему, необходимо собрать факты, но что делать, когда их недостаточно, чтобы выйти на коренную причину, даже используя метод «пять почему» или более продвинутый RCA? Как на этапе проектирования новой системы увидеть риски, мешающие достижению ее целей? Вместо вопроса «Почему это произошло?» или «Что может пойти не так?» задать перевернутый вопрос: «Как мы сами можем создать нежелательный эффект? Какие ресурсы системы позволяют реализовать этот нежелательный эффект?».
Приведу пример из личной практики. Клиент пожаловался на дефекты полиэтиленовых мешков возле запаянного шва. При этом во время отгрузки с предприятия мешки были целые, и в этот же период от других клиентов претензий не было. Мы инвертировали вопрос на «как сделать так, чтобы мешки рвались у клиента и не рвались на предприятии?». Провели функциональный анализ системы запайки мешков и выявили ошибку в настройке запаечной машины. Мешок с продуктом выходил запаянный и герметичный, но при входном контроле у клиента рвался. Почему только у одного клиента? Видимо, другие просто не делали тест на разрыв мешка с продуктом. Устранили ошибку в настройке, которая была в системе почти год после пуско-наладки. В итоге – контракт на несколько тысяч тонн продукции был сохранен без скидок на дефекты и выполнен полностью, а клиент после поставки пролонгировал договор.
Вывод: там, где фактов не хватает, диверсионный анализ генерирует гипотезы о скрытых механизмах. Затем их проверяем и выходим на настоящую причину быстрее, чем наблюдение за симптомами или исследование факторов, приведших к проблемам.
2. Правила и стимулы превращаются в ресурс для диверсии
Любое негласное правило или стимул может быть использовано как ресурс для создания вредного эффекта. Диверсионный анализ ищет такие ресурсы системно: время, пространство, информация, функциональность и т.д. Минимально полный перечень ресурсов для бизнеса в ТРИЗ содержит порядка 30 наименований ресурсов, которые могут быть рассмотрены для конкретной ситуации.
Вспомним пример с бригадой из статьи «Как решать сложные проблемы»:
- Ресурс времени: простой между сменами. Диверсионный анализ предлагает вопрос – как простой между сменами может создать проблему?
- Ресурс информации: знание реальных причин задержек. Вопрос – как знание реальных причин задержек приведет к еще большим задержкам? В ТРИЗ есть такой прием как усиление нежелательного эффекта, чтобы в итоге найти решение.
- Ресурс функциональности: способность бригады самоорганизоваться. Вопрос – как эта способность приведет к саботажу?
- Ресурс стимулирования. Вопрос: как поощрение за сокращение времени простоев может привести к еще большим простоям?
Диверсионный анализ не просто констатирует, что правило вредно. А показывает конкретную механику, как правило соединяется с ресурсом и порождает вредную функцию. Это дает руководителю не абстрактную рекомендацию «менять культуру», а точную карту – что надо сделать с ресурсом или условием, при котором ресурс становится оружием против системы. В итоге – не допустить этого.
3. Предсказание побочных эффектов или рисков
В статье «Как решать сложные проблемы» был описан кейс, где улучшение времени восстановления сервиса разрушило петлю обучения. Автор статьи честно признает: этого можно было избежать, если бы метрики были заданы заранее. Из этого возникает два вопроса:
- Как предусмотреть эту ситуацию заранее?
- Как узнать, какие именно метрики задать, чтобы не прозевать скрытую угрозу?
Диверсионный анализ прогнозирует – что именно сломается, в том числе применительно к метрикам. Как это работает:
- Берем планируемое решение, например, сократить среднее время восстановления сервиса с 2 часов до 30 минут.
- Задаем вопрос: «Как намеренно разрушить систему/оборудование при сокращении времени восстановления сервиса?».
- Имеем пул ответов: вместо полноценного восстановления функциональности системы «подшаманить» видимые дефекты, убрать фиксацию паттернов ошибок, не мотивировать персонал на повышение коэффициента технической готовности (КТГ) и/или коэффициента эксплуатационной готовности (КЭГ), не устанавливать коренные причины отказов, использовать аналоги вместо оригиналов. Ответов может быть множество – в зависимости от специфики системы.
- Далее исследуем – какими имеющимися ресурсами и условиями реализовать каждый из сценариев, и отсекаем те сценарии, где ресурсов недостаточно для его реализации.
Диверсионный анализ в этом случае не добавляет бюрократии. А подсвечивает негативные сценарии, которые реализуются рано или поздно, потому что в системе есть и ресурсы, и условия для реализации. В том числе, анализ помогает определить контрольные метрики прицельными (КТГ, КЭГ, показатель сохранности из статьи), а не страховочными «на всякий случай».
4. Проверка гипотезы на прочность до запуска
Эксперимент по проверке гипотезы показывает, работает ли решение в нормальных условиях, и одновременно не показывает – выдержит ли решение атаку особых обстоятельств, человеческой ошибки или злонамеренности, о которых не продумали на этапе создания решений. Диверсионный анализ может добавить к проверке «анти-эксперимент» – мысленную или имитационную попытку обрушить решение, используя его же собственные компоненты.
Например, вы решили запустить регулярные разборы потерь с бригадой. До начала эксперимента проведите анти-эксперимент: «Как сделать так, чтобы эти разборы превратились в фикцию и усилили недоверие?». Возможные сценарии: усложнить разбор, не давать обратную связь, давить авторитетом, искать виноватых, критиковать «безумные» идеи... Тогда к началу реального эксперимента получаем перечень стоп-условий – что в разборе делать запрещено всем, в том числе и руководителю. Это превращает руководителя из реактивного «решателя проблем» в архитектора, который проектирует систему с запасом прочности.
5. Проектирование устойчивости бизнеса
Диверсионный анализ расширяет горизонт решения проблемы, задает вопрос не только о том, что может пойти не так внутри системы, но и о том, как конкуренты или внешняя среда могут использовать ваше решение против вас же, и таким образом выводит мышление на уровень стратегических рисков. Например, как наше новое правило лояльности может быть атаковано, как изменение в цепочке поставок превратит наше сильное решение в уязвимость.
Приведу известный пример. Герберт Доу владел небольшой компанией в США, производящей бром. Продавал его по 36 центов за фунт. Предприятие завоевывало американский рынок, но при этом была негласная договоренность, что Доу не «идет» в Европу, а крупный немецкий концерн, продававший бром по 49 центов в Европе, не лезет в США. Прошло время, у Доу начались проблемы с бизнесом, и ему надо было расширяться, чтобы оставаться на плаву. Он начал продавать бром в Англии. Тогда немцы намекнули ему, что лучше свернуть экспорт, иначе будут последствия. Доу их проигнорировал. Вскоре на рынке США появился немецкий бром по цене 15 центов, что убивало весь бизнес Доу. Если бы немецкий концерн провел диверсионный анализ перед демпингом, например, задав вопрос «Как Доу может использовать наш дешевый бром против нас?», то ответ лежал бы на поверхности: «скупить и перепродать в Европу». Но анализ не был сделан и Доу победил немцев их же оружием.
Выводы
В решении сложных проблем диверсионный анализ надстраивает уровень стратегической безопасности, превращая методы решений из инструмента «ремонта» в инструмент «проектирования устойчивого будущего». Вместе они дают решение, которое остается сильным под давлением времени, людей и внешних обстоятельств.
Еще одно преимущество: мозгу банально легче придумать, как что-то сломать, чем объяснить – почему это сломалось. В этот момент креативность взлетает, решения приходят быстрее, ощущается прилив энергии. Не зря говорят: «Ломать – не строить».
Также читайте:
Вопрос на очень много миллиардов. Над этим долгие десятилетия бьются лучшие умы.
Вас больше интересуют причины провалов стартапов или крупных проектов?
Этого делать не стоит, при всем уважении. Мы поступаем строго наоборот: перед запуском так работаем с командой, чтобы удались все следы сомнений в успехе. На старте это трудно, потому что нет возможности опираться на показатели финасового плана - единственный объективный критерий качества работы. Причина такого подхода простая: стадия запуска - очень ответственная, и от неё во многом зависит дальнейшая судьба проекта. У команды не должно быть ни тени сомнения в успехе. Напротив. на этой стадии даже оправдан избыточный энтузиазм, который потом приходится притормаживать. На старте нужно разогнаться максимально быстро, а вы предлагает притормозить, посеяв сомнения. Это руководитель должен сомневаться в определенном смысле, но комнада - только рвать удила. Есть еще один негативный нюанс: ставя вопрос таким образом. руководитель показывает команде, что сам не верит в проект, а вот это уже смерти подобно. На этой стадии - запуске- руководитель должен выглядеть деемиургом, божеством, которое не может задавать никакие вопросы, потому что сам знает все ответы, а команда должна лишь слушать. Потом вожжи можно отпустить, и спрашивать, и советоваться,хотя там тоже есть подводные камни. Но только не на старте.
Вы говорите о старте проекта?
В этом случае не вижу смысла не говорить о том, что может произойти, если не уделять должное внимание профессиональной работе с рисками в проекте, тем более - есть этот проект большой, сложный и важный. Успех сам собой не приходит, а открыто высказанные сомнения - лишний повод что-то обсудить и уточнить или изменить заранее.
Каждый должен как можно лучше заниматься своим делом. А менеджер проекта и риск-менеджер проекта в круглосуточном режиме следят за тем, чтобы проект не вышел из-под контроля и принимают меры в случае необходимости.
Не обязательно. Критерии успеха проекта определяются, формулируются и согласовываются как можно раньше, но могут меняться в ходе проекта и даже после его завершения. Жизнь на месте не стоит.
Меня интересует и то и другое ) Я не лучший ум ) но исследую этот вопрос лет 15 и кое-что в этом, надеюсь )) понимаю.
Никакой софт или рациональный анализ и инструменты не просчитают, что руководитель отдела маркетинга тайно конфликтует с руководителем отдела продаж, и они будут саботировать задачи друг друга. А ведущий разработчик Вася планирует уволиться через два месяца, потому что ему надоел проект.Это риски человеческого фактора, интуиции и когнитивных искажений, – возвращаясь к нашим баранам )
Уверен, что какие-то выводы Вы сделали. Но это очень большая тема. Или две.
Это о стартапах? Кто-то еще не слышал о конфликтах? А вопросы саботажа в зоне ответственности топ-менеджмента организации. Все отчитываются о своей работе и часто общаются.
Такое не скроешь.
Не знаю, говорите ли Вы о проекте или стартапе, но - для начала - это риски из списка стандартных. Вполне типичные для любого проекта, внутреннего или внешнего. Что-то заранее обсуждается, какие-то замены планируются.
Дело же не в неожиданно появившемся желании уволиться. Любой может заболеть. Я, к примеру, с таким сталкивался.
Или получить лучшее предложение. Или не справиться с порученной работой, несмотря на все ожидания и обещания. Или заговорить о карьерном росте или срочном улучшении пакета.
Не совсем привычная формулировка. Вы не могли бы пояснить, кому и зачем нужно делегировать (!) бизнес-процессы алгоритмам?
Автоматизация - не делегирование.
Я бы не стал это объединять это две разные темы, у которых что-то может быть похожие чуть-чуть, но при более детального анализа решение я и лечения разные, причём довольно существенно.
Также я бы стал разделять "решение" и "реализацию этого решения", но это все знают с моей точки зрения, хотя часто я часто сомневаюсь
Именно этим и был вызван мой вопрос. Это две разные темы - как минимум, но, возможно, есть и смежные, не менее важные и интересные.
А что такое "решение" в общем виде? Слишком зависит от контекста.
Опять неправильно с точки зрения теории, но я решаю по-разному, потому что я нахожусь в разных ролях. Не «тип решения» определяет, как я действую, а кто я сейчас и в какой ситуации.
Каждая роль требует своего режима. Их нельзя смешивать. В сложных продажах все нужно переключаюсь между собой
Матрица простая: Кто я сейчас? В какой ситуации? Что я делаю?