OberonCore

Итак, показатель эффективности, приведённый Орловым, не вводится в рамках ТРИЗ - это новый системотехнический результат, который новая версия ТРИЗ, напротив, сама использует. Поэтому и аргументы к оценке ТРИЗ (как уже сказал, могу их принять с необходимыми уточнениями) к нему не имеют отношения.
Чем вызвано введение этого определения показателя? На мой взгляд - прежде всего осознанием некоторыми "западно-активными", т.е. по мировоззрению находящимися, пользуясь терминологией Девятова и Мартиросьяна, в "чётном рационализме" (к ним, конечно, принадлежит и Орлов) того факта, что орг[тех]система (предприятие, учреждение), работающая по критерию "максимизации транзакций", становится "генератором затрат" для общества, которые можно "списывать" лишь до поры... а дальше начинается "возмещение затрат" методами, всем хорошо известными... в общем, "реформа во избежание революции". Думаю, вполне логично в рамках такого типа мировоззрения и может послужить приведению системы к безопасному курсу - если не жулить с составом и оценкой составляющих числителя и знаменателя

Нет. Открытия тем и хороши, что позволяют перейти к инженерии, в данной теме, к конструированию конструированию (модели) предприятия из формальных структур по формальным правилам. То есть, открытие происходит один раз, а используется... по мере необходимости. Чтобы сегодня рассчитать полет снаряда, не надо ждать пока нужное яблоко упадет на нужную голову.

Каким способом "показано"?.. (позвольте полюбопытствовать...) С помощью примеров (практики)?.. С помощью логических (строгих) доказательств?..
Думаю, что многое прояснится, если вспомнить/уточнить понятие алгоритма. Вот для примера:
Как видите, многие исследователи сходятся во мнении, что алгоритм не может быть записан неформальным языком (т.е., допускающим неоднозначное толкование). Это первое. Второе, алгоритм должен обеспечивать получение результата, если исходные данные удовлетворяют поставленным требованиям. В Вашем случае это соблюдается?.. (с моей точки зрения, нет).

Ну я где-то так и подумал

Да, там есть примеры, как были сделаны изобретения по процедуре вывода (мета-АРИЗ)... но не открытия, конечно Кстати, учитывается и то очём Вы говорили "Формализация полезна не до... а после того, как открытие свершилось." - в основе пополнения методической базы лежит анализ сделанных изобретений и открытий - т.н. "реинвентинг".

Ну, это не моя точка зрения а Орлов в цитированном фрагменте оперирует некими математическими сущностями... Где-то я тоже согласен, что это максимум вводимая в "искусственном интеллекте" процедура в доалгоритмическом смысле - с ослабленными требованиями к детерминированности - т.е. "рецепт"...

Пользы от этого анализа не так много... Гораздо важнее понять то, как человек приходит к открытию... то самое: "Познай себя". (IMHO, разумеется)
Что же касается примеров, то... примеры ничего доказать не могут. Известное изречение о том, что "практика - критерий истины" - ложно. Практика может быть только критерием ложности. (Практика может выявить ошибку, но ничего не может сказать про отсутствие ошибок, о безошибочности, истинности).

Ответил в ЛС.

По поводу верификации бизнес-процессов.
Как человек, немного знакомый с методами верификации программ, я весьма скептически отношусь к использованию в данном случае математики. Хотя, конечно, чуда хочется.

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

Выявление, устранение и всяческая оптимизация таких мест и есть верификация бизнес процессов. ARIS с этим хорошо справляется.

Для такого анализа не требуются Моцарты, и даже моцарты. Обычная рутина.

С моей точки зрения, дело не в математике, но в методе написания программ, и, как следствие, в используемых средствах. Строго говоря, верифицировать, прежде всего, надо не программы, а модели...
Строгое доказательство правильности построения/работы программы.
Для того, чтобы увидеть неполноту, надо иметь... полное представление о том, что и как должно делать подразделение (желательно еще знать, нормы времени и ресурсов на каждую функцию подразделения). Здесь мы снова возвращаемся к семантике...
Несколько лет назад, два консультанта из разных фирм (одна занималась управленческим консалтигом, другая - СМК - системами менеджмента качества) чуть не подрались, у заказчика, отстаивая правильность своих описаний... одного и того же подразделений (совокупности бизнес-процессов)... Это не было смешным...
Может быть...

Любопытно. По идее, правильность описания должен определять заказчик. Но, подозреваю, что описания были столь сложными (хотя бы по количеству разнообразных элементов), что заказчик мало что понимал. Интересно было бы узнать подробности.

Необязательно. Простой пример: "кладовщик проверяет правильность заполнения документов и принимает товар на склад". А если документы заполнены неправильно, что ему делать - неизвестно. Неполнота обнаруживается чисто формально.

Чтобы проверить правильность описания, в голове заказчика уже должна существовать правильная модель (представления), но именно за получение такой модели... он и платит деньги.
Вообще, это давняя история... В начале 00-х годов приезжал к нам Ляпидус (они свой филиал открывали Приоритет-Урал), ну, и проводил он встречу... Я тогда его спросил об этом... на примере. Есть мол директор предприятия, которое "поймало волну" и быстро развивается. Пока коллектив был маленький, вроде бы все было под контролем. Но коллектив рос... Решили поучится тому, как правильно управлять, пригласили консультантов. Те пришли, начали описывать бизнес-процессы. Оставили пухлые тома, рассказали, как все делать правильно, научили всех натягивать улыбки и заставили зазубрить слоганы... Прошло какое-то время, решили сертифицироваться по ISO:900х (так солиднее на рынке представляться). Приехали консультанты, взялись снова описывать бизнес-процессы. "Эй", - закричал директор: "Постойте! Вот тут до вас уже поработали, все описали!!!", - и он натянул дежурную улыбку. Консультанты хмуро полистали пухлые тома и вынесли резюме: "Это не по стандарту. Надо все переделать". И... переделали. И на самом деле, бизнес-процессы стали другими. Сотрудники покорно выучили новые слоганы и тексты, которые надо говорить проверяющим СМК.
Прошло время... Решили поставить автоматизированную систему. Приехали консультанты... начали описывать бизнес-процессы... поскольку их бизнес-процессы "заточены" под ту систему, которую они продают... Сотрудники привычно положили в карман буклеты, которые им предстоит выучить...
Знаете, что мне сказал по этому поводу Ляпидус?.. Дословно, конечно, не помню, но суть такая: "Это правильно, что каждый рисует свой взгляд на бизнес-процессы, поскольку у них цели разные". У консультантов, может быть цели и разные, а вот у руководства предприятия?.. Но до их проблем никому похоже нет дела...

PS. Если Вы думаете, что эта история уникальна... то отнюдь... каждое предприятие, которое проходило через эти стадии... все это пережило.

Почему же неизвестно? Он, как материально-ответственное лицо не имеет права принимать материальные ценности на склад, если документы оформлены неправильно. Однако, проблема не в кладовщике... она возникла еще раньше. Дело в том, что кладовщик, в принципе, не может проверить правильность документов... Его задача проверить, что ассортимент и количество товаров соответствовали тому, что в документах... а правильность оформления документов, вне его компетенции.

В принципе Орлов и на это замахивается - в Гл. 20-21 (в основном опираясь на упоминаемые результаты современных исследований мышления), но это надо ещё осмыслить... и компетентное мнение не помешало бы. Вот результаты Бехтеревой с сотрудниками - это м.б. такой независимый взгляд...
Насчёт практики - по сути, известное утверждение о смысле тестирования систем (что оно может выявить только конечное число ошибок, но не доказать безошибочность) есть частный случай сделанного Вами

Вот именно это и сделано в model checking.
Ясное дело. При той же проверке моделей не только модель записывается на языке - кстати, не полуформальном, а прогязыке РВ - но и представления о том "что и как", записываются на другом формальном языке - темпоральной логики. При получении ТЛ-формул, IMHO, как раз волей-неволей выявляется неполнота доформального описания (разумеется, в пределах тех свойств, которые сочинитель поставил себе целью сформулировать - но поскольку в мышлении "многое связано со многим" - то он уточняет и что-то за пределами этого).
Да, рутина, только математическая... и к этому надо готовить. Потому что справляется всё-таки человек - проверка лишь показывает "узкие места" (в model checking - в виде контрпримеров)...
А вот что языки моделирования д.б. на графической основе - это не вопрос. Вот над этим бы и поработать...

Большое спасибо за рассказ.
Ну и где здесь место для математики?

Ну так ровно это и имелось в виду. Что ему делать, если не соответсвует.

Что чётко определили при анализе совместно с заказчиком - то и делать Это либо прямо определено действующим законодательством - либо ему не противоречит

Это рассказ о том... как порой правильность моделей проверяет заказчик. Вы же об этом говорили и... хотели подробностей.