Роман Пантелеев пишет:

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

Легко!

Я надеюсь, что Вы не потребуете определять ключевые показатели для каждого условия? Эту работу тоже можно сделать - студенты у меня это делают в дисциплине управление процессами.
Как я понимаю, IOM разрабатывается не для того, чтобы "гонять" цифру, а лишь как мыслительный инструмент для выявления UDE.
Управление процессами предприятия - это совсем другая задача

Роман Пантелеев пишет:

Александр, я цель компании просил - Вы выбрали уровень пониже (что существенно проще), .

Можно стоить и вверх - там ой как много можно нарисовать блоков на разных уровнях - но это бессмысленно.
Оперативная память человека сильно ограничена и можно делать очень подробные модели. У меня программист в отделе делал модель работы программы почтовый сервер - у него больше 300 блоков было и порядки 4-6 уровней.
Специалисты рекомендуют вместо огромной, неуправляемой модели, которую трудно прочесть и понять, создают серию небольших, управляемых и понятных моделей.

Александр Запорожцев пишет:

Роман Пантелеев пишет:

Александр, я цель компании просил - Вы выбрали уровень пониже (что существенно проще), .

Можно стоить и вверх - там ой как много можно нарисовать блоков на разных уровнях - но это бессмысленно.
Оперативная память человека сильно ограничена и можно делать очень подробные модели. У меня программист в отделе делал модель работы программы почтовый сервер - у него больше 300 блоков было и порядки 4-6 уровней.
Специалисты рекомендуют вместо огромной, неуправляемой модели, которую трудно прочесть и понять, создают серию небольших, управляемых и понятных моделей.

Я не предлагал сделать больше блоков. Просто чем выше цель, тем сложнее ее реализовать и декомпозировать в оцифрованные цели/НУ сохраняя логику.

Александр Запорожцев пишет:

Роман Пантелеев пишет:

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

Легко!

Я надеюсь, что Вы не потребуете определять ключевые показатели для каждого условия? Эту работу тоже можно сделать - студенты у меня это делают в дисциплине управление процессами.
Как я понимаю, IOM разрабатывается не для того, чтобы "гонять" цифру, а лишь как мыслительный инструмент для выявления UDE.
Управление процессами предприятия - это совсем другая задача

Уже лучше, но Вы не оцифровали саму Цель.
И не оцифровали третий уровень. Но уже можно проверять логику (буду править формулировки на ходу).
1) Если мы имеем "Постоянное выявление несоответствий", то "Количество несоответствий <1 в месяц". Что то не бьется (но это Ваша личная ошибка - IOM тут не при чем). По-моему верно обратное утверждение: "если мы не выявляем несоответствия, то количество выявленных несоответствий будет <1 в месяц" . Смысл выявления несоответствий, чтобы они были. А Вы говорите что выявление нужно чтобы их не было - нарушение логики. Если правильно понимаю примерно так выявляют ковид в июне...
2) Если мы имеем "Постоянное управление работой по несоответствиям" И "Постоянное выявление причин несоответствий" И "Постоянно разрабатываем КиПД" (последнее верно? а то смахивает на разовую операцию), то "Результативность КиПД составляет 95% успешных". Опять что то не то (а вот это системная ошибка IOM)... Как Вы гарантируете что эти три составляющие дадут не меньше 95% результативности? А если существует "золотой ключик", который Вы не указали, то какой смысл копаться в этих 3-х NC, если его отсутствие не даст Вам требуемый результат? А если Вы эти три условия оцифруете - будет еще веселее: я попрошу связать эти числа с результативностью в 95% проверяя логикой необходимости и достаточности.

"лишь как мыслительный инструмент для выявления UDE"

Еще раз. Если у Вас некорректное дерево целей, по которому Вы собираете UDE, то проблема не где то там в корне - а здесь - отсутствие необходимого условия для выполнения цели. Вы тупо кому то задачу не поставили и он сделал 10 заготовок, а тот кому поставили задачу сделать 20 изделий - смог сделать только 10. Какой смысл копать до корня? Искать конфликт. Решать его. Причина ближе - подсистема не была синхронизирована с остальной деятельностью системы. Ну 5Why можно тут использовать, а CRT - смысла нет. IOM не может быть чем то отличным от того что стремилась сделать компания, но не справилась. Правильный IOM - такой в котором бьется логика и гарантируется получение цели (исключая черных лебедей, но только черных - то что серые будут мы точно знаем и IOM должен их учитывать).

Роман Пантелеев пишет:

Но уже можно проверять логику (буду править формулировки на ходу).
1) Если мы имеем "Постоянное выявление несоответствий", то "Количество несоответствий <1 в месяц". Что то не бьется (но это Ваша личная ошибка - IOM тут не при чем). По-моему верно обратное утверждение: "если мы не выявляем несоответствия, то количество выявленных несоответствий будет <1 в месяц" . Смысл выявления несоответствий, чтобы они были. А Вы говорите что выявление нужно чтобы их не было - нарушение логики. Если правильно понимаю примерно так выявляют ковид в июне...
.

Блоки КФУ критические факторы успеха введены в IOM только для того, чтобы определить те показатели, по которым будет определяться степень достижения цели. Между Целью и КФУ проверять связь не нужно.
Кроме того, при описании IOM Dettmer рекомендует 7. Verify the Connections • Necessity logic, not sufficiency • Cross-check finished connections with your intuition (“10,000-foot view”)
Почему Вы проверяете связь на соответствие критерию достаточности?

Александр Запорожцев пишет:

Блоки КФУ критические факторы успеха введены в IOM только для того, чтобы определить те показатели, по которым будет определяться степень достижения цели. Между Целью и КФУ проверять связь не нужно.
Кроме того, при описании IOM Dettmer рекомендует 7. Verify the Connections • Necessity logic, not sufficiency • Cross-check finished connections with your intuition (“10,000-foot view”)
Почему Вы проверяете связь на соответствие критерию достаточности?

А какой смысл в таком IOM? Ну создали мы какое то дерево с частичной логикой. Для достижения целей мы его использовать не можем. На каком основании мы будем по нему UDE собирать? Где гарантия что так мы соберем все UDE которые выведут нас на корневую проблему? Но даже проверка необходимости - что она даст возвращаясь к моему вопросу про оцифровку?

Допустим цель компании EBITDA 1 млрд
CSF1 Продажи 2.5 млрд
CSF2 Расходы 1 млрд
CSF3 ОЕ 0.5 млрд

Отлично. А теперь какое оцифрованное необходимое условие Вы напишите к CSF1? Почему именно это, а не другое число в NC будет необходимым? Вариантов чисел там великое множество.
А если Вы не напишите там какое то число - как Вы UDE для этого NC напишите? На каком основании там возникнет UDE - Вы же не указали конкретный показатель. А если Вы будете указывать только инфраструктурные NC (где важен факт есть/нет), выкинув те которые надо оцифровывать, то где гарантия что Вы из написанных наберете достаточно UDE для выхода на корневую проблему?

Вот и получается что по сути IOM - это творчество интуиции. Есть опыт в области - нарисуете что то более-менее похожее, нет - даже браться не стоит. Но если есть опыт в области - зачем Вам IOM? Вы можете сразу UDE собирать.

Версия: получается NC->CSF строгая логика не проверяется и IOM ты рисуешь чисто разогнать интуицию где искать UDE и все? Т.е. IOM это не логический инструмент, а просто некий эскиз, по которому Вы ведете опрос, чтобы собрать UDE?

Если все так, то однозначно потом надо 3UDE пользовать. Невозможно из примерно набранных UDE надежно выйти на корневую проблему - повезет интуиции получится, не повезет... (и поиск UDE - интуиция и CRT - интуиция...). Я бы не назвал это ТОС.

Роман Пантелеев пишет:

Вот и получается что по сути IOM - это творчество интуиции. Есть опыт в области - нарисуете что то более-менее похожее, нет - даже браться не стоит. Но если есть опыт в области - зачем Вам IOM? Вы можете сразу UDE собирать.

Compare Reality with Benchmarks of System Success
With the assurance that you know what the system’s goal, critical success factors, and necessary conditions are, start comparing these elements one by one with what you know and can document (by measurement, testimony, or some other verifiable evidence) is currently happening in your system
Нужно сравнивать элементы IOM с реальностью. Есть хорошая аналогия IOM есть ТРИЗ - там используется идеальный вариант - абстрактный вариант технического решения. IOM - это тоже идеальный вариант системы. Проверяем все идеальные условия с реальностью и находим UDE

Роман Пантелеев пишет:

CRT - интуиция...). Я бы не назвал это ТОС.

CRT - это знание фактов + логика

Александр Запорожцев пишет:

Роман Пантелеев пишет:

CRT - интуиция...). Я бы не назвал это ТОС.

CRT - это знание фактов + логика

В подходе Детмера CRT это способ поиска корневой проблемы