У нас акцент первоначально делался на управление творческой деятельностью.

Аналогия в следующем. Вот есть инструменты для ЕА - ARIS, Casewise и пр. Эти инструменты позволяют создавать красивые и понятные схемы. Но, они являются исходными данными для программистов. Даже нарисованные процессы сразу невозможно запустить. Кто работает с этими инструментами - бизнес-архитекторы и бизнес-аналитики. У нас любые схемы сразу заставляют пользователей исполнять функции, указанные в этих схемах.

Олег, я вашу позицию услышал -- но как менеджер, не могу с ней согласиться.

Но невозможность редуцирования к процессам -- это отдельная дискуссия, видимо.

Я высказываю мысли, которые у многих лет 5 назад были абсолютной крамолой. На пример, что проект и процесс в рамках единой модели описываются практически одинаково. Сейчас многие это уже понимают. Еще один вопрос, которым я ставил в тупик практически любого эксперта по менеджменту. Что является результатом управленческой деятельности?

По поводу проектов и процессов -- при желании, можно добраться до общего абстрактного предка. Меня волнует вопрос -- зачем, какая будет практическая польза?

Вопрос про результат -- вы имеете в виду outcome, effect или purpose?

Давайте с вами попробуем поработать.
Какой customer journey?

Нет, это вопрос из серии «чем живешь, чем дышишь»...

Есть группа в FB https://www.facebook.com/groups/175407879717900/   Для начала можно посмотреть вместе со мной в Скайпе. Это самый эффективный способ захода. Мой логин asyssoft

По поводу проектов и процессов -- при желании, можно добраться до общего абстрактного предка. Меня волнует вопрос -- зачем, какая будет практическая польза?

Вопрос про результат -- вы имеете в виду outcome, effect или purpose?

Практическая польза - только действия отражают фактическую деятельность. Если мы хотим качественно управлять деятельностью, мы должны управлять действиями всех участников деятельности. На второй вопрос ответ -outcome.

Благодарю, запнулся об "Я за единую теорию управления деятельностью, с единой онтологией, которая не отвергает опыт частных теорий, но, является более общей." и об слово "деятельность" через строчку - демоны Г.П. и П.Г Щедровицких витают в воздухе, но я справляюсь :)

Я искренне уважаю Щедровицкого. Мы пошли немного дальше - кроме теории у нас есть практика. Работающие на этом подходе ИТ-системы и единая цифровая платформа.

Вот слово "единая" меня и волнует.
"Метамодель - это замкнутая система объектов и отношений между ними, из которых строятся модели."

O-AAF, 4.4. Evolution of Products and Systems versus Architecture Evolution:
"In an Agile world, products and systems evolve incrementally through rapid learning cycles. How stable an architecture remains during these iterations can translate into two questions:

- How to design architectures that are resilient to product and system evolution?
- How to evolve an architecture incrementally?"

Если Вы действительно хотите построить результативную и эффективную систему управления деятельностью, надо управлять действиями всех участников деятельности. Логика здесь такая. Если в системе все идет нормально, все проекты, работы, задачи выполняются вовремя - никакой системы управления не нужно. Но, если где-то происходит срыв - нужно объективно проанализировать причины. Вы заранее не знаете кто именно является слабым звеном. Нет иного выхода, как учитывать действия всех. Другое дело как?

Вот слово "единая" меня и волнует.
"Метамодель - это замкнутая система объектов и отношений между ними, из которых строятся модели."

O-AAF, 4.4. Evolution of Products and Systems versus Architecture Evolution:
"In an Agile world, products and systems evolve incrementally through rapid learning cycles. How stable an architecture remains during these iterations can translate into two questions:

- How to design architectures that are resilient to product and system evolution?
- How to evolve an architecture incrementally?"

Практическая польза - только действия отражают фактическую деятельность. Если мы хотим качественно управлять деятельностью, мы должны управлять действиями всех участников деятельности. На второй вопрос ответ -outcome.

В @o_aaf_russia я покажу pilot, реализующий машиночитаемую архитектуру.
Если коротко - то сейчас за минуту я получаю следующую статистику:

Суммарно:
- Архитектура содержит 42 не валидных tech-элементов из Библиотеки
- Библиотека опережает Архитектуру на 30 tech-элементов
- Библиотека опережает Архитектуру на 4 data-элементов
- Разработка опережает на 13 Epic
- Разработка опережает на 199 US
- Разработка опережает на 21 application-метод
- Разработка опережает на 17 grpc-services
- Разработка опережает на 40 grpc-message