Применение Теории Ограничений Систем для постановки процесса

В деятельности менеджера всегда есть какая-то доля работы связанная с постановкой бизнес-процессов. Как правило это необходимо когда появляются новые потребности компании, бОльший оборот, лучшая стабильность по денежному потоку или просто внедрить каике-то улучшения. Иногда бывает, что мы сталкиваемся только с симптомами или нежелательными явлениями, когда что-то идет не так: «продалбываем» сроки, заказчик недоволен, слишком большие расходы на содержание инфраструктуры или иные издержки. Между этими двумя позициями есть общая деталь: если есть потребность к изменению значит что-то эти улучшения сдерживает, и это можно расценивать как нежелательное явление. Когда мы начинаем разбираться в ситуации, то можем собрать множество разрозненных фактов из которых понятно только то, что изменения требуются. но с чего начать? Как минимальными усилиями провести изменения?

И тоже самое можно сказать о конфликтах в команде. Когда видишь конфликт интересов но решить его в лоб, административным рычагом, будет не самым правильным выходом. Нужно искать корневую причину конфликта и решать ее.

Ищем причины

Часто, анализируя деятельность компании мы видим множество разрозненных но очевидных фактов типа:

• заказчик недоволен
• много ошибок в коде
• много доработок при сдаче
• не успеваем со сроками
• долго разрабатываем

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

Диаграмма называется «дерево текущей реальности» и её следует читать как: «ЕСЛИ мы не успеваем со сроками ТО заказчик недоволен».
Можно на этом и остановиться, и сказать «Ура! я нашел проблему и пойти долбать разработчика.» И даже если вы найдете идеальных разработчиков проблемы не решатся.
Потому что скорее всего это не является истинной причиной проблемы. И нужно копать дальше.
Именно об этом говорит пятый шаг 5 ТОС «не поддавайтесь инерции». Конечно дерево не полное, И факт «много ошибок в коде» тоже может быть следствием какой-то другой более системной проблемы. Для того чтобы это выявить нужно просто задать вопрос «Почему?» Почему у нас много ошибок в коде?

И при ответе на эту группу вопросов можно выявить что:

• Много ошибок в коде ПОТОМУ ЧТО нет тестирования
• Нет тестирования ПОТОМУ ЧТО не хватает времени
• Не хватает времени ПОТОМУ ЧТО контракт заключен поздно.
• Не хватает времени ПОТОМУ ЧТО неправильно оценен объем проекта до заключения контракта.
• Неправильно оценен объем проекта ПОТОМУ ЧТО не существует готовых метрик.
• Не существует готовых метрик ПОТОМУ ЧТО не проводится анализ проектов.

Ух ты, оказывается что проблема лежит вовсе не на стороне разработки, а закопана глубже, и лежит еще в области подготовки к заключению договора.
Но ВАЖНО что на поверхности эти проблемы не лежали. И строя полную картинку

Можно найти ключевую проблему с которой и нужно применять изменения бизнес процессов. Данный пример короткий, но показывает что не все что лежит на поверхности действительно является ключевой проблемой. И при анализе состояния может выявиться еще 50 различных фактов влияющих на систему, а встраивая их всех в дерево причинно следственных связей и выявляя что является следствием а что причиной можно найти именно то самое ограничение системы которое нужно исправлять в первую очередь.

Решаем проблемы

При разборе этого примера мы нашли что ключевой проблемой является отсутствие учета результатов ретроспектив, Для которых, хорошо было бы иметь какие-то артефакты проекта типа проектной документации. Да и результаты ретроспективы тоже имеет смысл оформлять в виде документа о выученных уроках.
И здесь мы можем прийти к конфликту.
Для того чтобы делать проект быстро мы должны экономить время, и соответственно не должны писать документов (Коммуникации важнее документации). Одновременно с этим мы должны думать о поддержке проекта и перспективах развития поэтому мы должны писать документацию.
И здесь мы приходим к еще одному инструменту ТОС «Диаграмма Ключевого конфликта» или «грозовая туча», которая представляет собой маленькую схему показывающую не конфликтующие между собой условия достижения цели, но конфликтующие методы обеспечения условий.

Для того чтобы решить эту «тучу» можно применить несколько различных методов

• мозговой штурм.
• теорию решения изобретательских задач. (ТРИЗ)
• шесть шляп мышления

Или применить тот же самый логический подход, и выявить ложные предпосылки приводящие выбору методов обеспечения наших условий. Такак метод выбирается не только для обеспечения условия но на основании каких-то еще влияющих факторов. Иногда бывает что метод выбран правильно, но ошибка может крыться в условиях которые приводят к этим методам и тогда нужно поставить под сомнение сами условия приводящие к конфликту. Для этого тоже нужно исследовать предпосылки.
Для выявления предпосылок применяется рассмотренное ранее дерево текущей реальности, которое мы достраиваем с использованием вопросов «Почему?» «Зачем?» и соответственно ответов а них «ПОТОМУ ЧТО...» и переводя из абстрактной плоскости «экономить время» в конкретную «сэкономить 20 часов» задавая вопросы «Сколько вешать в граммах?», «А в чем это выражается?» чтобы получить измеримые факты. (да-да критерии SMART)

1. Экономия времени — Зачем? Сколько времени даст экономия? Есть ли другие способы экономии времени?
2. Долгая поддержка — Насколько долгая? Как часто меняются команды? Какой прогноз темпов развития? Есть ли другие способы обеспечения условия?
3. Не писать документацию — К чему это приведет? Какие будут нежелательные явления? Какие риски возрастут? Какой будет положительный эффект? Какие будут убытки?
4. Писать документацию — Сколько это стоит? Сколько денег это принесет? Что для этого нужно? Какую именно документацию нужно писать? Как определить что это мы пишем а это не пишем?

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

Проверяем последствия

Если в результате анализа выявлено что наши условия действительно верные, но грозовая туча не решается, то можно проверить воздействия каждого из методов на систему в целом анализируя желательные эффекты (ЖЭ) и нежелательные явления (НЖЯ). Это можно проверить построив дерево будущей реальности:
Например:
Если мы будем писать документацию то

• ЖЭ. У нас будет больше информации о принятии решений в будущем что повысит нашу стабильность выполнения работ.
• НЖЯ. Но одновременно с этим нужно будет тратить время на документирование
  • Но мы можем встроить документирование в процесс обдумывания проектных решений
    • ЖЭ. ТОГДА документы будут рождаться как побочный продукт и
    • ЖЭ. Проектные решения будут лучше продуманы.

• НЖЯ. любой документ устаревает в момента написания
  • Описание на уровне свойств, характеристик и поведения без детализации снизит скорость устаревания
    • ЖЭ. Большая часть документов будут актуальны долгое время.

Если мы НЕ будем писать документацию то

• ЖЭ. мы сможем быстрее делать продукт
• НЖЯ. при смене разработчика вся информация уйдет с ним
• НЖЯ. Стоимость замены сотрудника возрастет
• НЖЯ. появляются непредсказуемые финансовые риски.

Оценка на уровне дерева будущей реальности последствий наших действий дает понимание о стоимости внедрения того или иного метода и всех нежелательных явлениях которые могут возникнуть в процессе внедрения.
Выбранное решение называется «прорывом» и оно влияет сразу на всю тучу. Решение может лежать и за пределами тучи и может быть найдено через методики мозгового штурма ТРИЗ и «шести шляп мышления». Воздействия на систему в процессе модулирования дерева называются «инъекциями».
Но полученное решение нужно будет проверить на логическом дереве с анализом последствий нашего воздействия на систему в целом. И решение о выбранном варианте можно проверить на предмет желательных эффектов и нежелательных явлений. И количество нежелательных явлений может сыграть существенную роль в выборе решения прорыва.

Данные методики также могут быть использованы и в оценке какой-то ситуации или при переговорах. Однако, при моделировании сценария вместо решения прорыва и инъекций можно использовать ваши действия с ответную реакцию оппонента которая может быть положительной (желательный эффект) и отрицательной (нежелательное явление).

Что почитать по теме

• Цель. Процесс непрерывного совершенствования. Элия М. Гольдратт, Джеф Кокс
• Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию. Уильям Деттмер

Автор: sbase

Источник