1. OrgLan -- это концептуальная модель в ISO 15926. Назначаем в качестве OrgLan 0.1 мэппинг Архимейта к ISO 15926.
2. Мэппим теперь оттуда, где есть нужные данные: метамодель
http://opfro.org/ в OrgLan 0.1 (то есть к ISO 15926), дополняем и исправляем -- получаем OrgLan 0.2.
3. Льём полное содержание OPFRO (примерно 1100 компонент методов), а затем редактируем [считаем, что более-менее удобное редактирование к этому моменту появится -- хоть "в деревьях", хоть "в таблицах", на диаграммы не надеемся] справочные данные -- переводим на русский, корректируем и дополняем методами из списка по пункту II в
http://praxos.livejournal.com/14273.html (начального классификатора шаблонов практик PraxOS). Корректируем метамодель PraxOS по итогам этого редактирования, получаем OrgLan 0.3 (и, конечно, на нём в этот момент будет доступна начальная библиотека справочных данных PraxOS).
4. Обеспечиваем работу редактора архитектурного описания предприятия (очень надеюсь, что это будет на базе .15926 Editor -- ибо Archi совсем не подходит) для кастомизации (специализации, или клонирования-редактирования) справочных данных PraxOS -- для КонкОрга. Как минимум, на этой стадии "научные имена" заменяются на имена с отраслевой спецификой КонкОрга, сервисы распределяются по оргструктуре, и уточняется IT-решение (уровни программ и оборудования). Это, пожалуй, первая польза -- у нас появляется архитектурная модель КонкОрга, созданная на основе наших чудесных и правильных методов работы PraxOS.
5. Делается генератор распорядительной документации, чтобы из модели предприятия получить все необходимые должностные инструкции, положения об отделах и т.д. -- это сильно поможет проектам развития. В принципе. этот же генератор документации может отрендерить и вебсайт по практикам, аналогичный текущему opfro.org, только вот справочные данные PraxOS в этот момент уже легко и удобно редактировать (сейчас opfro.org можно редактировать только руками в виде HTML документов -- ужас-ужас!).
6. Делается генератор конфигурационных файлов для настройки корпоративного софта (например, для конфигурирования issue tracker в PLM).
В принципе, за последние лет пять таких "праксосов" развелся миллион и маленькая тележка (от "оглавлений полезной литературы по методам" типа
http://www.npd-solutions.com/bok.html до
http://www.bkcase.org/sebok-075/ -- со всеми промежуточными остановками). Наши отличия:
-- качество справочных данных по содержанию: мы считаем, что отобранные нами методы работы лучшие!
-- качество справочных данных по форме: они формальны по составу, и поэтому качество наших описаний выше. Это уже не столько "описание", сколько "модель".
-- возможность непосредственного использования в качестве начальных шаблонов (архитектурных паттернов) для архитектуры предпринятия (т.е. привязка практик и их ролей к оргструктуре, планирование IT-решения -- всё то, чем хороша архитектура предприятия, и чего не хватает в ситуационной инженерии методов). Можно генерировать регламенты, положения, инструкции, приказы, планировать проекты развития.
-- а поскольку у нас появляется формальная архитектура предпринятия (на ОргЛане, т.е. на ISO 15926 -- достаточно формальное представление), то можно думать о генерации конфигурационных файлов для прикладного софта (а хоть и такого сложного, как PLM-системы -- почему бы и нет?).
Ну, понеслась! Это ведь всё вполне обозримо и выполнимо. Не боги горшки обжигают.