Обсуждение

В последнем абзаце предприятия вместо предпринятия опечатка?

И да, и нет. Всё-таки "архитектура предприятия" это устаканившийся термин (enterprise architecture), поэтому в таких словосочетаниях всегда есть сомнения по использованию слова "предпринятие". Хотя по смыслу да -- всякие "стратегии развития системы повышения квалификации сотрудников" это, безусловно, стратегии развития предпринятия. ОК, уговорили. Сейчас исправлю )))

В первом абзаце - та же фигня в третьем буллете.

О! Тут точно опечатка, без оговорок! Спасибо!

Дерево текущей действительности, дерево будущей действительности и дерево перехода из ТОС обеспечивают процентов 70 от этого всего с нормальной формализацией.

У того же Голдратта для этого есть специальное дерево, стратегии и тактики (и я в тексте его помянул). С другой стороны, предлагаемое Голдраттом это 70% от всей механики целеполагания (например, у него нет ничего про "интересы" и нет явно выписываемых стейкхолдеров). И у него даже больше, чем в motivation model: более подробные обоснования, и мы этим ещё займёмся. Но предлагаемый моим постом подход позволяет и архитектуру предпринятия представить в нужной степени детальности -- спроектировать и организацию дел, и организацию софтов и даже прикинуть оборудование. Сам замысел ArchiMate был ровно в этом: чтобы на одном наборе диаграмм обсуждать всю полноту вопросов развития предпринятия, включая и важнейшие в современном предпринятии айтишные аспекты. У Голдратта всё это обсуждение деталей реализации уносится вовне модели стратегии. А у меня нет: стратегия подробно моделируется, и результат её применения (целевая архитектура стратегии развития) тоже подробно моделируется.

Насчёт моделирования "возможности", а так же ряда других понятий. Как мы в конце концов определяем, что некая цель достигнута? Фиксируя некое феноменальное состояние, до этого отмаркированное, как "целевое", "должное", отличаемое от "насущного" до выполнения действия и неотличаемое от него в случае успеха. Сколь-нибудь сложные изменения, и тем более - стратегические изменения, включают в себя множественные такие состояния. По факту нужно отслеживать широкую феноменологичную картину мира. Разные подразделения и специалисты обычно отвечают за изменение отдельных частей этой картины, а архитекторы сводят её в компактные модели, снижая разнообразие состояний до уровня, когда оно может быть потреблено отдельным человеком в короткое время с небольшим усилием: чеклисты, диаграммы, таблицы и прочая. Стратегическое моделирование выполняется человеком, и потому мы вынуждены использовать компактные представления, нотацию типа той, что в ArchiMate. В ней мы даём короткие метки большим картинам мира, чтобы запихать их в нормально воспринимаемую модель. Но мы должны всегда иметь ввиду, что за этим стоят большие количества состояний, каждое из которых для изменения или достижения требует отдельного действия от соответствующего оператора. "Возможность" в таком разрезе - это картина мира (или её десигнатор), которая понимается стейкхолдерами как в данном бизнес контексте достижимая с помощью имеющейся практики, и соответствующим образом маркированная в модели. Т.е. констатируются явно или неявно (1) картина наличного состояния системы, часто неявно; (2) картина целевого состояния, маркированная как "возможность" - явно; (3) общий для первых двух контекст - ресурсные ограничения и целеполагание, позволяющие маркировать (2) - неявно; (4) ресурсообеспеченная практика, переводящая систему из (1) в (2) в рамках (3) - неявно. И лучше говорить не о 3D-картинах, а о 4D-сценариях. "Маркировки" нужны для управления картиной мира модельера-архитектора в процессе стратегирования, чтобы осуществлять навигацию в пространстве различных картин мира/сценариев, один из которых должна рано или поздно быть направлена на исполнение операторам, а качественная коммуникация остальных (невозможные, рискованные, желательные и пр.) должна привести к правильной параметризации первого. "Невозможность" - это констатация отсутствия (4). "Способность" (capability), для которой я пока вообще не видел внятного определения, можно определить как возможность, привязанная к оператору (или классу). Т.е. "способность = констатация наличия у оператора некоторой ресурсообеспеченной практики А для реализации сценария Б". Можно в таком же духе [рекурсивно] расписать и необходимость/need, и ограничение/constraint прочие концепты, приводя всё к относительно небольшому переносимому базису, собранному из исполняемых сущностей. Правда, это далеко и от Essense, и от ArchiMate. ЗЫ: у вас там "всеховатный язык"

И Essence, и ArchiMate довольно ограничены -- поэтому-то и трудности с выражением возможности. Так, ни в ArchiMate, ни в Essence нельзя чётко показать using system, которая существенно связана с возможностями и к которой относятся needs. И время там исключительно 3D, никаких темпоральных частей (но зато есть события, чем я и попытался воспользоваться). > у вас там "всеховатный язык" Моё движение -- это SysMoLan, в котором "всеохватность языка" как раз дизайн-цель. Я рад, что в моём посте это оказалось заметным.

Так тут как раз фундаментальное ограничение: модель - это коммуникация операторов (using system - это про одного такого), где один создаёт картину мира (или приращение таковой) для того, чтобы изменить поведение/картину мира другого (ну или сохранить её на экзокортексе для себя самого). Но операторы и их интенции, как неотделимый контекст модели, сами не моделируются. Получаются "вечные" модели - только тут уже не [только] время, как размерность, исключена, а исключён момент действия модели в рамках коммуникации операторов. На это постоянно натыкаются, но преодолевать пытаются не увеличением размерности модели, "вверх", а увеличением количества "плоских" проекций, "вбок". Это как 3D-моделирование с помощью карандаша и ватмана - не даёт разгуляться. Концепция Stakeholders в .42012 очень пассивна, это только намёк. Да и она, насколько я могу видеть, в своём роде одинока. Больше нигде я ничего внятного не встречал. На мой взгляд, тут нужен некий агентно-ориентированный подход, смасштабированный в zoom-глубь и в meta-высь, чтобы эти ограничения преодолеть и не погибнуть. SysMoLan - это нужное движение, в котором интересно было бы поучаствовать, но в данном контексте я хотел обратить внимание только на опечатку в слове) зы: очень высокотехнологичная у вас капча стала.

Илья Бидер как-то заметил, что для многих и многих систем переделка (переинженерия, переобучение и переорганизация) стейкхолдеров должны входить в инженерный проект. И дальше можно разбираться -- то ли это стейкхолдеры для using system, то ли составная часть using system. И да, проект четырёхмерен, а ArchiMate существено 3D -- тут даже Essence с её состояниями альф лучше.

Это замечание вполне может быть справедливо для каких-то или многих (некневсе) проектов, но я немного о другом. Возьмём пример ArchiMate motivation extension, концепцию Goal. Видим диаграмму, бокс с мишенью и каким-нибудь qualitative word. Быстро возникающий у практиков вопрос "а что кому с этим боксом делать?" подразумевает, например, вопрос "чья это цель?" Простой ответ - "это цель моделируемого предпринятия" - для простых случаев подходит и в дополнительных концепциях и нотациях не нуждается. Для чуть более сложных случаев можно как-то использовать неочевидные знания контекста и выводить, что вот эта часть декомпозиции относится к такому-то оператору, а эта - к такому. Чуть усложняем - и всё, ценность диаграммы, как выразительницы знания упадёт, а стоимость создания, согласования и поддержки - возрастёт. Можем ввести swimlanes, partitions и т.п. - кое-что облегчит, скорее всего ненадолго. Можем ещё что-то ввести, чтобы ещё переразвить переразвитое :) Изображение — открыть источник

Анатолий Игоревич, вы не все знаете про OMG Essence ;-) https://www.youtube.com/watch?v=7S8es1KyY9A

Точно! Этого я ещё не видел! )))

На самом деле в Archimate 3.1 как раз есть уже физические объекты (станки и др) — так что описанное в статье ограничение снято еще в 2019 году

Текст 2015 года, при этом поменялось и всё остальное (а Архимейт вообще выкинули из рассмотрения, включая все его нововведения). Курс стратегирования вошёл в курс системного менеджмента, вот тут: https://system-school.ru/systems-management (и там даются три модели как способы документирования результатов стратегирования).