|
Разработка PraxOS
[Recent Entries][Archive][Friends][User Info]
Below are the 10 most recent journal entries recorded in the "Разработка PraxOS" journal:[<< Previous 10 entries]
|
03:21 pm
[ailev]
[Link] |
Стратегирование, инженерия, операции.
Меня лично интересуют максимально большие предпринятия, на которые способно человечество. Построить атомную станцию, запустить космический корабль, создать сеть сотовой связи и т.д.. Ну, и чтобы это было без предписанного законом насилия (инженерные шарашки, космические запуски на отобранные у налогоплательщиков деньги, привелигированная в силу закона "естественная монополия" в электроэнерегетике и т.д.) -- о полномочиях и ответственностях должна быть договорка, они не должны появляться в силу принуждения. В маленьких предпринятиях очень легко договориться о разделении труда. В больших предпринятиях очень трудно договориться: какого-то вида труда будет избыток, а какого-то вполне может не будет хватать. Поэтому полезны чеклисты, проверяющие проверить наличие у предпринятия всех необходимых возможностей (capabilities)/сервисов, позволяющих этому предпринятию выполнить своё назначение и произвести на свет целевую систему/целевой сервис. Эти же чеклисты могут лечь в основу образовательных программ, готовящих специалистов для крупных предпринятий. Ниже -- классификаторы самого верхнего уровня для такого чеклиста деятельностей/дисциплин/практик. Это я пишу в развитие http://praxos.livejournal.com/14627.html.
Предпринятие -- это когда кто-то конкретный (а хоть и сговорившаяся группа людей) хочет что-то предпринять, и есть договорка о разделении ресурсов и труда (полномочиях по распоряжении ресурсами и ответственностях за какие-то работы).
Сообщество -- это когда есть люди с близкими интересами, которые трепятся друг с другом, и каждый занят своим собственным делом (т.е. нет договорки о разделении ресурсов и труда, а каждый работает самостоятельно).
Больше размер -- больше роль сообщества, меньше предпринятия:
-- Общество, страна, город -- сообщества.
-- Эко-система (business eco-system, современное понимание "отрасли", ибо выходит за рамки традиционных "отраслей". Например, эко-система мобильной телефонии, в которую входят и провайдеры, и производители телефонов и планшетов, и программисты операционных систем и приложений, традиционно относящиеся к разным "отраслям") -- сообщество.
-- Расширенное предприятие (все компании из цепочки поставок какого-нибудь сложного продукта: атомной станции или самолёта) -- предпринятие, разделение полномочий и ответственности в силу явных контрактов.
-- Холдинг, предприятие -- предпринятие, разделение полномочий и ответственностей в силу уставных документов.
-- Подразделение предприятия, корпоративный проект, рабочая группа и т.д. -- предпринятие.
-- Субботник во дворе, проведение концерта и прочие "проекты" -- предпринятие.
Всю основную (направленную на получение целевой системы/сервиса) деятельность предпринятия я делю по назначениям (целям) дисциплин этих деятельностей:
-- низкоуровневое (т.е. маркетинг) стратегирование: заказ того класса целевых систем, которым нужно было бы заняться (формулирование требований к продукции).
-- инженерию: обеспечение функциональных (других ведь не бывает) требований заказчика и других заинтересованных сторон.
-- операции: обеспечение минимального по использованию ресурсов прохождения работ по сети выполнителей.
Кроме основной деятельности предпринятия я отдельно выделяю его организационно-технологическое развитие (организовывание -- замысел, изготовление, модернизация сети выполнителей/сервисов основной деятельности, а технологическое развитие -- смена технологических платформ, "управление технологиями"):
-- высокоуровневое (т.е. формулирование миссии и видения) стратегирование: заказ организации. Это предпринимательская активность, угадайка по поводу будущего. Кто смел, тот и съел. Ну, или того и съели.
-- организационную инженерию: обеспечение технологии (сети выполнителей/сервисов и способов маршрутизации работ между ними) создания целевых систем.
-- организационные операции: обеспечение минимального по использованию ресурсов прохождения работ по организационно-технологическому развитию.
Каждое из этих направлений предполагает два вида работ:
-- содержательную: собственно выполнение работ по стратегированию, инженерии, операциям.
-- лидерскую: катализирование сотрудничества в стратегировании и инженерии (евангелизм), операциях (традиционно понимаемое лидерство менеджеров). Это деятельность по согласованию личных интересов, убеждений и предпочтений (стратегических, инженерных, операционных) и требуемых организацией как машиной по созданию целевой системы.
Тем самым на предприятии я бы выделил стратегов (предпринимателей), инженеров (целевых систем и организационных), инженерных/операционных менеджеров (обеспечивающих операции по созданию целевой системы/сервиса и операции оргразвития). Ещё есть "просто менеджеры", которые удерживают целостность всего описанного: основную деятельность и развитие в их стратегической, инженерной и операционной части, наличие как содержательных работ, так и необходимого стратегического, инженерного и менеджерского лидерства.
В этом списке интересно всё, но "нельзя объять необъятное", профессионализироваться "во всём" невозможно. Пожалуй, ключевой для масштаба предпринятия деятельностью является операционная. Операции по созданию пиццы существенно отличаются от операций по созданию атомной станции или стадиона просто потому, что требуют осознанной координации огромных потоков материалов, денег, людей, работ, данных. Атомную станцию или стадион не построит "рынок" или "сообщество", это должно сделать какое-то предпринятие, а это предпринятие нужно организовать.
Собственно, всем этим много лет и занимаемся. Вот, например, постинг 2007г. "Организация операций" -- http://ailev.livejournal.com/462573. Но с тех пор много воды утекло и появилось как новое понимание представления хода работ (не только "проектное управление" или "управление процессами", но и "адаптивное управление кейсами"), а также новые добавки в тамошний список вариантов специализации (поддисциплины, практики). Это более-менее отдельные дисциплины/специализации, которые раньше были "размазаны" кусочками по остальным дисциплинам:
м) управление конфигурацией и управление изменениями (нарезка на объекты работ, которые затем проходят по сети выполнителей предпринятия). Это про PLM (тема "управление жизненным циклом").
н) управление данными и информацией. Это тема федерации систем, интеграции данных жизненного цикла, ISO 15926
о) управленческий учёт (throughput accounting) -- учет "прохода денег" по сети выполнителей (проход денег обратен проходу объектов работ). Это мы занимались Голдраттом.
Теперь нужно освободить содержание всех этих "специализаций" (дисциплин, практик) операционного менеджмента от неизбежного в силу профессионального шовинизма (за многими этими специализациями стоят отдельные профессии -- специализации ВУЗов, профессиональные ассоциации, специализированный софт и т.д.) дублирования практик других специализаций/дисциплин и особенностей принятой тем или иным сообществом терминологии. То есть нужно срочно продвинуться в теме классификации/типологизации/структурирования/прототипирования специализаций/дисциплин/практик.
|
|
08:22 pm
[ailev]
[Link] |
Классификация практик инженерного предпринятия по отношению их к целевой системе
Художник, паталогоанатом и политик смотрят на женщин в ходе своих профессиональных занятий абсолютно по-разному. Разные практики работают с одними и теми же объектами работ абсолютно по-разному. Эти практики можно классифицировать разными способами, в зависимости от того, что вы собираетесь с этими практиками делать.
В постинге "системная инженерия, инженерный менеджмент и инженерные сервисы" (http://ailev.livejournal.com/1005515.html) я приводил классификацию дисциплин как группирование практик по "социологическому" основанию: какие есть профессиональные тусовки с их конференциями, учебниками, ассоциациями и сертификациями. Эта классификация удобна для закупки/подготовки специалистов и закупки софта. Проблемы начинаются там и тогда, где и когда требуется обеспечить интеграцию всех этих практик в работе конкретного предпринятия. Для такой интеграции нужно описать практики содержательно: чтобы можно было легко найти дублирования практик отдельных дисциплин (в силу неизбежного профессионального шовинизма), чтобы иметь достаточную детальность описания типовых практик для выбора из них нужных шаблонов и увязывания фрагментов практик в целостный набор сервисов предпринятия, способный породить целевую систему.
Для этого рассортируем практики по отношению практикующих (выполнителей, деятелей) к целевой системе, уточняя почти трёхлетней давности постинг "Четыре группы описаний жизненного цикла в PraxOS" (http://ailev.livejournal.com/764492.html).
Минимально есть три отношения выполнителей к целевой системе (любой -- от коробка спичек, до марсохода):
1. отношение целеполагания: со стороны внешних системы, в которой целевая система является частью с определенной функцией (назначением).
2. инженерное отношение: со стороны устройства самой системы (части системы и их взаимодействие) -- 4D проект "в классах", а затем и "в бетоне и железе", как его видят проектанты с технологами.
3. логистическое отношение: со стороны работы обеспечивающей системы по протягиванию конфигурации целевой системы по жизненному циклу, как его видят специалисты по операционному менеджменту.
А поскольку у нас появилась еще и обеспечивающая система, то введем дополнительно косвенное для целевой системе отношение к обеспечивающей системе:
4. (косвенное) отношение организовывания и развития: практику создания и развития предпринятия, как обеспечивающей системы из выполнителей, их сервисов и объектов работы.
Тут, конечно, много спорных мест (например, выделение целеполагания вместе с инженерией требований в отдельную группу практик, но у меня есть основания считать, что так будет лучше).
Это очень похоже на группирование практик жизненного цикла системной инженерии в ISO 15288 (куда тоже попали отнюдь не только "инженерные", т.е. технические, практики). Но есть и множество отличий. В качестве упражнения, найдите их сами. Хинт: обратите внимание на подход с "описыванием жизненного цикла" vs подхода с "архитектурой предпринятия", обращение к теории ограничений и adaptive case management против подхода проектного управления и ISO 9000 -- ну, вы поняли идею. Ну, и терминологические замены. Я всегда с трудом объяснял людям про "обеспечение проектов" в ISO 15288. Так что я постарался выбирать слова, наиболее точно отражающие специфический профессиональный взгляд на целевую систему со стороны той или иной практики. Один и тот же болт может быть одновременно для совместно работающих выполнителей разных практик и "элементом конструкции", и "конфигурационной единицей", и "элементом очереди на обработку", и "комплектующим", и "предметом снабжения". Вот я и постарался как то подчеркнуть в названиях специфику разных по типу отношения к целевой системе групп практик:
1. Практики целеполагания (стратегирования, мотивирования, определения требований, маркетинговых исследований).
Внешние требования к целевой системе, которые может понять заказчик, надзоры, операторы и другие стейкхолдеры времени эксплуатации целевой системы: назначение, эксплуатационные свойства и требования к операционному (времени эксплуатации) окружению. Получением этих описаний занимается инженерия требований. Ключевое тут -- "польза", value.
Для собачьей будки это будут:
-- интерфейс к собаке: внутренние размеры, размер входа, нетоксичность, теплопроводность пола и стенок, наличие крепления для привязи и т.д.
-- интерфейс ко двору: внешние размеры, внешний вид
-- интерфейс к оператору: удобство уборки, удобство крепления на месте и последующего переноса,
-- интерфейс к собственнику будки: срок службы, стоимость эксплуатации и ремонтопригодность, стоимость приобретения.
-- интерфейс к собственнику предпринятия-будкостроителя: прибыльность начинания.
Из софта используется бумажный блокнот и скайп.
2. Инженерные (технические) практики.
Инженерное задание целевой системы, и технологическая часть производства: как функция поддерживается конструкцией (какие там части системы -- 3D модель) и механизмом (как части системы взаимодействуют -- "модель поведения", процесс времени эксплуатации), и инженерные планы (планы разработки -- говорят о 4D, процесс времени проектирования). Получением этих описаний занимается архитектурное проектирование (куда входят как инженерия системной архитектуры, так и разные специальные инженерии, включая работу технологов). Ключевое тут -- "4D проект: геометрия, схемы и имитационные модели, технологические карты хода изготовления".
Для собачьей будки это будет:
-- 3D модель из крыши, разных стенок, крепежа.
-- прочностные модели, модели теплообмена (имитационные собаки в имитационной будке в имитационном климате)
-- заказная спецификация на детали (сами детали делаются инженерами по специальности, а также закупаются)
-- технологическая последовательность изготовления, а затем и сборки (4D)
Из софта тут используются самые разные САПРы и системы инженерного моделирования.
3. Инженерные сервисы и логистика: "оперативное управление".
Задание движения объектов (как материальных, так и привязанных к носителям данных) в пространстве-времени: по пространственно размещенным выполнителям в ходе жизненного цикла:
-- оформление объектов работы (конфигурационных единиц), которые нужно передавать по логистическим маршрутам. Это configuration and data management.
-- оформление маршрутов (передач конфигурационных единиц между выполнителями). Это шаблоны adaptive case management. Часть знания о маршрутах при этом приходит из инженерных технологических описаний (методологий разработки и технологических карт), а часть задаётся принятым способом учёта инженерной неопределённости (change management) и тесно связано с практиками configuration and data management.
-- определение и снятие ограничений (заторов) на маршрутах. Это operation research в разных его вариантах (например, теория ограничений).
-- работа с логистикой особого объекта: денег (throughput accounting, подход "прохода денег через производственную сеть" к управленческому финансовому учёту).
Для собачьей будки это будет:
-- выбор системы кодирования, идентификация конфигурационных единиц 4D проекта (будка breakdown structure, breakdowd structure работ по сборке будки и т.д.), определение процедуры "выпуска" (окончания изменений, готовность к передаче дальше -- для согласования или использования) по облегчённой процедуре (ибо вопрос "кому сидеть" для будок не такой острый).
-- оформление маршрута проектирования по рабочим местам, а затем маршрута закупки, изготовления, сборки и испытаний с учётом существующих производственных мощностей-сервисов (взятых из моделей архитектуры предприятия). Подготовка рабочих заданий, контроль их исполнения.
-- компьютерное моделирование хода разработки и изготовления, калибровка моделей.
-- ведение учёта переменных финансовых издержек (затрат и расходов) на проектирование и производство будок.
Из софта тут используются PLM (как интегрирующие инженерные данные) и ERP-системы (в которых важны алгоритмы планирования), системы supply change management, issue trackers и системы документооборота для работы с кейсами и процессами, 1С бухгалтерия для финансовой работы, спец.софт управления проектами (в которых важен алгоритм определения критического ресурсного пути -- "критической цепочки работ") -- то есть софт для "единого информационного пространства", "управления процессами", "управления проектами" и "управленческой бухгалтерии".
4. Организация и развитие предпринятия как пула доступных сервисов необходимых выполнителей: добыча/развитие качественных личностей и закрепление за ними ответственности и полномочий по распоряжению ресурсами, включая оборудование, деньги, и выдачу поручений другим людям (организация обеспечивающей системы), а также удовлетворение потребностей производства в технологиях (оборудовании).
-- практики организационной инженерии: задание архитектуры предпринятия (из людей, софта и оборудования), выполняющей все необходимые работы практик из предыдущих пунктов, а также реализация этой архитектуры в жизни (включая снятие ограничений -- ибо оперативное управление может и должно не столько снимать ограничения, сколько подстраиваться под них) -- "управление изменениями" aka "проекты развития" (не путать с "управлением изменениями" у инженеров). Это вотчина организационных инженеров.
-- лидерство (какие конкретные люди какой деятельностью займутся: назначение живых индивидов на занятие позиций в неживой оргструктуре). Это вотчина менеджеров, которые умеют работать с людьми. Оргинженеры тут отдыхают.
Конечно, "инженерный менеджер" подразумевается при этом как профессия человека, который может и архитектуру предпринятия разработать, и с людьми договориться -- как амфибия, выжить в обоих мирах. Но нам сейчас это неважно, нам бы на типы практик указать, в которых целевой системой является обеспечивающая система первых трех (целеполагания, инженерии, логистики) практик.
Из софта изредка используется система моделирования предприятия (чаще органиграмма составляется в Ворде), и MS Office для всех мыслимых потребноестей, которые есть у менеджеров. Ну, и данные всех остальных систем, которые есть. И даже данные социальных сетей, а чо!
Для собачьей будки это будет:
-- проверить, всё ли у нас есть для старта будкоделательного предпринятия. Докупить софт моделирования (ишь ты, конкуренты начали публиковать тепловые характеристики своих будок!) в службу Проектирования обиталищ.
-- назначить Василия Петровича на все роли системных инженеров по этому проекту, он собак любит, и у него много друзей собачников (а во включении кинолога в команду разработчиков в качестве "голоса пользователя" -- отказать). И студента Колю поставить на все САПРы сразу, ему давно пора расти как инженеру. Не будет справляться -- терпеть, пока научится.
-- последовательное прокручивание цикла снятия ограничений (студент Коля зашился со своими САПРами, ему нужно срочно подмогу! Комплектующие приходят неправильные, от обратной логистики лихорадит всех -- срочно разобраться, почему у нас заказывают эту гадость!).
-- уговорить Дядю Петю потратить полдня на учёт интересов собаки при проектировании 3D, и уговорить Тётю Дусю всё-таки закупать метизы в фирме "Заваляшка", где ей грубят и хамят, но зато там не бывает задержек с поставками и грубых ошибок комплектации.
-- троих из сборочного кошачьих домиков, у которых аллергия к кошкам (вот идиоты! Кошек же на сборке этих домиков нет!) переучить на работу по сборке будок. Или даже лучше набрать новых, а тех троих уволить. Зачем нам люди с заморочками?
|
|
12:20 am
[ailev]
[Link] |
Roadmap PraxOS 3.0
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-системы -- почему бы и нет?).
Ну, понеслась! Это ведь всё вполне обозримо и выполнимо. Не боги горшки обжигают.
|
|
04:58 pm
[ailev]
[Link] |
Релиз PraxOS 3.0
Общая цель релиза PraxOS 3.0 -- получить библиотеку архитектурных шаблонов для моделе-ориентированных инженерного менеджмента и системной инженерии (предыдущие планы релиза 2.3 -- http://praxos.livejournal.com/455.html).
I. Приложение методов -- консультирование
-- выполнение реальных консультационных проектов с использованием библиотеки паттернов. На эту тему мало что можно сказать подробнее: в Сети можно найти очень незначительное количество архитектурных диаграмм предприятий, потому что такая информация обычно не раскрывается. Это верно и для использования PraxOS: раскрыть можно только шаблоны, но не итоговые модели. Работа с клиентами не терпит публичности.
II. Пополнение библиотеки архитектурных шаблонов и их освоение -- профессиональный рост
Начальный (существенно неполный -- просто пример) классификатор шаблонов:
1. Инженерный менеджмент
1.1. Проекты развития
1.1.1. адаптивная архитектура предприятия
1.1.2. реализация изменений
1.1.3. целеполагание (стратегирование)
1.1.3.1. управление технологиями
1.1.3.2. теория ограничений (TOC)
1.2. Маржинальный финансовый учёт
1.2.1. KPI
1.2.2. Динамическое бюджетирование (beyond budgeting)
1.2.3. РСБУ+МСФО
1.2.4. Управление портфелем проектов
1.2.5. учёт прохода (throughput accounting)
1.3. Управление проектами
1.3.1. 4D реализация системы
1.3.2. adaptive case management
1.3.3. CCPM и factory physics
1.3.4. LastPlanner
1.3.5. SCOR (включая обратную логистику и прочие прелести)
1.4. Управление информацией
1.4.1. Интеграция данных жизненного цикла: ISO 15926 outside
1.4.2. Обмен информацией между контракторами: ISO 29481 (VISI)
2. Системная инженерия
2.2. Инженерия требований
2.3. Инженерия системной архитектуры
2.3.1. ТРИЗ, аксиоматический дизайн, DSM
2.3.2. Архитектурные языки
2.4. Верификация и валидация
III. Методология -- инструментарий
В текущем релизе методология должна уже быть поддержана софтом. На базе софта .15926 нужно сделать софт PraxOS, отличающийся от всем известного Archi следующим:
1. Поддержка модульности и управления конфигурацией (как библиотеки шаблонов, так и результирующего архитектурного описания КонкОрга)
2. Удобная специализация ("копирование с наследованием и возможностью уточнений")
3. Возможность работы с несколькими классификаторами одновременно (прежде всего, классификатор паттернов)
4. Реификация отношений
5. Семантика (отношения настоящие, а не "нарисованные" -- т.е. на них можно опираться при мэппинге)
6. Расширяемость типов (class_of_class) на базе полного ISO 15926
7. Поддержка мэппинга модели во внешние представления (как конфигурационные файлы разного работающего с индивидами корпоративного софта, так и генерация отчётов типа "Положение о подразделении")
8. Возможность создания учебных курсов (задач) по библиотеке шаблонов
9. Выход на детальное моделирование взаимодействия (interoperability): федерирование объектов работы (целевая система), работ (обеспечивающая система, ACM), трансакций (перформативы из LAP/DEMO).
|
|
03:10 pm
[ailev]
[Link] |
PraxOS 3.0: адаптивная архитектура предпринятия
1. Предпринятие (endeavour или endeavor) -- это организованные на достижение какой-то цели люди. Организованные -- это с понятными полномочиями, и ответственностями по имеющимся в их распоряжении трудом, программами, оборудованием и объектами работы.
Типичные предпринятия -- это:
-- традиционное предприятие (и его работы -- проекты/кейсы, процессы, практики),
-- расширенное предприятие (работы нескольких предприятий в рамках одного проекта),
-- эко-система (http://www.investopedia.com/terms/b/business-ecosystem.asp, http://en.wikipedia.org/wiki/Busineгss_ecosystem -- где нужно говорить уже не столько о проектах/кейсах, сколько о производственных программах),
-- любые другие организованности (банда, церковь, бригада, рабочая группа, департамент, филиал, октябрятская звёздочка и отряд бойскаутов).
Есть цель и достигающая её группа людей с оборудованием и предметами работы -- есть предпринятие для её достижения.
2. Каждое предпринятие может (и должно) рассматриваться в совокупности его:
-- выполнителей работ, т.е. людей (с их компетенциями, соответствующими ролями в работах) и технологий (технологической платформы -- программы и оборудование), вместе дающие возможности (capabilities)
-- работ (процессы, проекты/кейсы/жизненные циклы конечных объектов работы, программы), в том числе внутренних и внешних сервисов
-- объектов работы (в том числе исходных, промежуточных и конечных).
-- предпринятий развития (в которых объектом работы становится само исходное предпринятие, рекурсивно).
Выполнители работ, работы и объекты работы одинаково важны в системном рассмотрении предпринятия, но разные люди могут выпячивать одно или другое. Так, многие предпринятием называют именно структуру выполнителей работ (по аналогии с предприятием -- это люди и оборудование), но в последний десяток лет появилось много людей, которые предпочитают говорить о предпринятиях как о сервисах, проектах и программах, кейсах ("процессно"). Пока очень мало тех, кто говорит о предпринятии как потоках обрабатываемых объектов работы -- но уже есть и такие.
Тем самым предпринятием вполне может называться и проект (который так и определяется, как временное предпринятие -- A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives -- http://en.wikipedia.org/wiki/Project_management).
3. Предпринятие уникально и находится в реальности (нашем пространстве-времени). Онтологически это individual -- оно имеет протяженность (extension) в пространстве-времени. Примеры:
-- ООО "ТехИнвестЛаб.ру" (в названии выпячен структурный аспект -- выполнители: люди, программы и оборудование)
-- проект развития "интеграция данных жизненного цикла PLM-систем" в ОАО "Газнефтьводка России" (выпячены работы, это именно проект)
-- эко-система мобильной телефонии (с одной стороны, выпячен структурный аспект -- выполнители, с другой стороны они поименованы косвенно, через конечный объект работы)
-- кейс устранения ошибки, найденной клиентом (выпячены работы с заранее неизвестной структурой, направленные на достижение определенной цели)
4. Каждое предпринятие (в том числе структурные организованности, соответствующие отдельным проектам/кейсам/жизненным циклам конечных объектов работы) имеет архитектуру -- самое важное, что можно сказать про то, как организовано предпринятие как система: каким образом конструкция/структура (выполнители и объекты работы) и механизм (выполняемые работы) предпринятия позволяют достигать его целей (эти цели определяются заинтересованными сторонами, имеющими влияние на предприятие).
Эта архитектура может быть выражена в одном или нескольких архитектурных описаниях.
В архитектурном описании (да и в детальных описаниях предпринятия, "организационной рабочке" -- если можно так говорить о регламентах работы, "бумажных текстом" для людей и выполняемых софтом "электронных формализованных") показываются:
-- типовые выполнители: организационные звенья и их роли (оргструктура), а также виды программ и оборудования (структура: развернутая в организации технология производства работ, гарантирующая воспроизводимость результатов работы), ибо составляющие эти организационные звенья живые люди, исполняемые программы и экземпляры устройств вполне могут быть заменены без изменения архитектуры.
-- типовые работы: шаблоны проектов (ибо сами проекты -- не в архитектуре, а в предпринятии, т.е. в жизни), практики и процессы (ибо в самом предпринятии -- экземпляры работ), виды жизненного цикла (ибо сами прохождения жизненных циклов -- в предпринятии, т.е. в жизни), типы кейсов (ибо сами кейсы -- в жизни)
-- типы объектов работы (а сами экземпляры объектов работы -- в жизни).
Типовые объекты -- это означает, что речь идёт о классах (множествах) реальных объектов "из жизни". От абстрактной идеи (абстрактного объекта, не имеющего протяженности в пространстве и времени -- например, "типа", "класса" и даже "класса классов", "вида") до существующего в реальности объекта (индивида, имеющего протяженность во времени и пространстве) может быть много ступенек членства в классе (уровней классификации).
Архитектурное описание (да и рабочее описание) предпринятия выполняется обычно как "типовое", как будто этих предпринятий может быть по этой архитектуре создано много. Это пример так называемого "проектирования в классах" (хотя на эту тему и ведутся многочисленные дискуссии с приверженцами "проектирования в индивидах") -- архитектура отражает типовые аспекты предпринятия, верные для многочисленных (проводившихся, ведущихся и будущих проводиться) в нём работ.
Понятное дело, что речь идёт об "архитектуре предпринятия" (т.е. и проекта в том числе), но мы будем сознательно в речи путать "архитектуру предпринятия" и "архитектуру предприятия" -- считая, что это одно и то же. То есть мы, говоря об "архитектуре предприятия" не будем ограничиваться архитектурой одного юридического лица, а будем говорить об общей архитектуре той или иной организованности людей для выполнения каких-то целей.
5. Архимейт (http://ailev.livejournal.com/988360.html) -- это один из лучших на сегодня арихтектурных подходов (включающий набор групп описаний и архитектурный язык) к описанию предпринятий.
Архимейт имеет не слишком аккуратный и богатый язык для описания предпринятий, но "за неимением гербовой будем писать на простой".
Ограниченность Архимейта проявляется главным образом в отсутствии возможности показать классификацию (отношения "реализации" Архимейта очень близки в некоторых случаях по сути, но выражают они совсем другое и имеют явные ограничения). Это означает, что в Архимейте трудно показывать что-то "типовое" по отношению к чему-то более конкретному. Некоторые исследователи предлагают вместо отношений классификации пользоваться отношениями специализации (приговаривая при этом "онтологи этого не любят, но простые люди вряд ли заметят подвох" -- предложено Donald Firesmith в его метамодели описания метода OPF, http://opfro.org).
5. Между предпринятиями развития других предпринятий и этими другими развиваемыми предпринятиями как раз отношение классификации/реализации: проекты (а в случае "департамента развития" можно говорить и о программах -- это ведь всё тоже "предпринятия") развития воплощают разработанные абстрактные "типовые архитектуры" (информационные модели) в реальности.
Есть два времени проведения таких "проектов развития":
-- явный, перед целевой работой, когда разворачивается технология (обучаются люди, закупаются и настраиваются/разворачиваются программы и оборудование), а потом получившееся предпринятие начинает выполнять свои работы. В Архимейте 2.0 для описания таких проектов существуют отдельные расширения (extensions) "целеполагания" и "реализации и перехода к новой архитектуре".
-- неявный (и тогда это даже "развитием" или "организовыванием" не называется), то есть прямо во время целевой работы. Такого сорта работы принято называть не "проектами" или "процессами", а "кейсами". В "кейсах" предпринятие создаётся кейс-менеджером по ходу дела (например, лечение пациента или устранение аварии -- в этих случаях можно много сказать про имеющихся в наличии потенциальных выполнителей, но много меньше про выбранных из них в конечном итоге реальных выполнителей и проводимые ими работы, а также объекты работы: они будут выясняться постепенно по ходу кейса). Предпринятие-кейс адаптивно "творит себя" в рамках основной деятельности родительского предпринятия-по-ведению кейсов, и поэтому адаптивное управление кейсами (http://ailev.livejournal.com/946134.html) нужно описывать средствами ядра (core) Архимейта (а вот организацию адаптивного управления кейсами как метода работы родительского предпринятия -- в рамках проектов развития, средствами расширений целеполагания и реализации и перехода к новой архитектуре).
Я как-то замечал, что в проектном подходе проект-предпринятие отражён во всех учебниках, но в софте проектного управления также можно встретить "шаблон проекта" -- это как раз фрагмент архитектурного описания родительского предпринятия для подобных типовых проектов. В процессном подходе в учебниках именно описан процесс как фрагмент архитектурного описания предпринятия, а в жизни можно обнаружить не типовое "описание процесса", а лишь его экземпляры (например, прохождения конкретного договора с его индивидуальным номером) -- эти экземпляры тоже можно встретить в софте, но в учебниках о них практически ничего не говорится.
Кейсы в этом плане много сложнее процессов и проектов: нет "типового кейса", но вполне могут существовать какие-то шаблоны организации кусочков работ, которые будут использованы примерно так же, как "шаблоны проекта" или "описания процессов" -- с той лишь разницей, что:
а) речь будет идти наверняка не о шаблоне всего кейса от открытия до закрытия, а только о каких-то отдельных шаблонах (например, шаблонах самой процедуры формального открытия и закрытия кейса, или процедурах формального назначения доступных людей для продвижения кейса). То есть для кейсов есть "библиотека/каталог шаблонов", и кейс приходится конструировать из элементов этого каталога описаний выполнителей-работ-объектов работ прямо по ходу дела, для каждого кейса отдельно.
б) большая вероятность не обнаружить какого-то нужного элемента в библиотеке/каталоге шаблонов: работы тогда должны быть спланированы непосредственно в момент обнаружения в них надобности (то, что потом можно будет сделать реверс инжиниринг этих работ и пополнить библиотеку новым шаблоном -- это только возможность, не факт, что ей воспользуются. В принципе, этот "обратный инжиниринг работ для выявления типов работ" называется process mining, это очень свежий тренд -- http://en.wikipedia.org/wiki/Process_mining. Грубо говоря, это попытки найти протоптанные людьми тропинки, чтобы их потом заасфальтировать. Другое дело, что сама постановка вопроса в "процессном управлении", предполагающем сначала проложить асфальтовые процессы, а затем карать за сход с асфальта, существенно извращает суть этого process mining).
в) процессы (и их экземпляры) и проекты (и их шаблоны) могут быть представлены как частные случаи кейсов -- когда значительная часть организационной работы и планирования работ делается up front, перед собственно выполнением работ. Но кейсы включают в себя и рутинную реорганизацию предпринятия-кейса по ходу дела, по мере обнаружения привходящих обстоятельств (что в проектном и процессном подходах рассматривается как ситуация кризисов).
6. Архитектурное описание должно выражать архитектуру -- самое важное в том, как организовано предпринятие:
-- для процессных предпринятий это классические "бизнес-процессы" из книжки (цепочки действий, провязанные отношением передачи "выходов" одних операций на "входы" других). Архимейт особо хорошо приспособлен для описания именно таких предпринятий, причем только для описания информационной работы в предпринятиях.
-- для проектно-ориентированных предпринятий (как это понимается в традиционных учебниках менеджмента) оно описывает жизненный цикл целевой системы как объекта работ и практики этого жизненного цикла (становящиеся процессами, как только мы говорим о развёртке выполнения этих практик во времени жизненного цикла). Для описания типовых жизненных циклов (шаблонов проектов разработки) чаще всего используется подход ситуационной инженерии методов (стандарты ISO 24744, OMG SPEM 2.0).
-- для кейс-ориентированных предпринятий (например, больниц, в которых любая процедура и лекарство типовые, но вот последовательность этих процедур невозможно предугадать. Ну, или программотехническая фирма, в которой никто не знает, какой баг вылезет завтра, и как его будут удавливать) отражаются не столько "процессы", сколько практики (группирование работ по ролям, чтобы их было легче назначать компетентным исполнителям) и какие-то короткие цепочки процессов, похожие не на типовой и длинный "бизнес-процесс, пересекающий границы подразделений и выходящий за границы предприятия", а на "шаблон проекта", выполняемого какими-то уполномоченными на это людьми. Специальных подходов для описания кейс-ориентированных предпринятий нет, и вполне можно использовать подходы архитектуры предприятия и ситуационной инженерии методов.
7. Также существуют и другие описания предпринятий, выражаемые какими-то стандартами, затрагивающими только один метод описания (тематическую группу описаний) из их множества.
Эти стандарты могут быть действительно стандартами (ISO 15288 как стандарт практик системной инженерии, например) или просто типовыми описаниями того, "как обычно бывает" (стандарты де-факто, и еще см. "об институты" -- http://ailev.livejournal.com/982274.html). В любом случае, можно говорить о том, что предпринятие соответствует (compliant) какому-то стандарту ("удовлетворяют требованиям стандарта"), или оно "реализует" этот стандарт, если предпринятие (в жизни) соответствует такому частному описанию. Конечно, одно и то же предпринятие может удовлетворять требованиям многих стандартов (если они не требуют чего-то прямо противоположного).
7. ОргЛан основан на идее, что предпринятия, их разбиения и отношения можно описать в рамках архитектурного подхода (системной инженерии, приложенной к предприятию как системе систем -- http://ailev.livejournal.com/991792.html).
Это, в частности, означает возможность использования архитектурного языка (Орглана -- http://praxos.livejournal.com/13689.html) не только для:
а) традиционно понимаемой архитектуры предпринятия, но и
б) описаний видов жизненного цикла (т.е. вместо ISO 24744, OMG SPEM 2.0), как методов разработки (ситуационная инженерия методов -- http://ailev.livejournal.com/905099.html), а также
в) создания библиотек шаблонов для кейсов, что очень похоже на каталоги компонент методов из предыдущего пункта (б), только происходит по ходу дела, а не заранее в момент организации работ. Сюда же отнесём частные случаи кейсов: описания процессов и планы проектов.
Для этой цели архитектурный язык должен включать в себя возможность выражения не только запланированных связных последовательностей работ (процессов), выполняемых определенными исполнителями, но и потенциальных работ, последовательность и исполнители которых неизвестны. Это ровно тот подход "каталогизации компонентов методов", который развивался в ситуационной инженерии методов (http://praxos.livejournal.com/9600.html, http://praxos.livejournal.com/11084.html), но дополненный до всех аспектов организации предпринятия (например, включающего сведения о распределении полномочий -- то есть дополненный до архитектурного "всё важное"), а не ограниченного только описанием метода.
Тем самым можно говорить (по аналогии с ситуационной инженерией методов -- http://ailev.livejournal.com/905099.html) о ситуационной архитектуре предпринятия, и обсуждать каталоги архитектурных компонентов -- из которых и набирать ситуационные архитектуры, как об этом рассказывается в ситуационной инженерии методов.
Но и этого мало: "ситуационная архитектура" примерно соответствует "динамическому управлению кейсами" (когда содержимое каталога известно до начала работы). Я бы склонялся к термину "адаптивная архитектура предпринятия", учитывая именно архитектуры предприятий, заточенные под адаптивное управление кейсами.
Соответствующие архитектурные описания включали бы в себя:
а) библиотечные (то есть уже имеющиеся в культуре, готовые "из коробки") компоненты (паттерны, шаблоны) поддержки кейсов, ведения кейсов, технические, координационные -- тут я явно процитировал типологию практик системной инженерии из ISO 15288.
б) специфичные для данного предпринятия компоненты (паттерны, шаблоны), которых не было в библиотеке. Тут важно еще и то, что данные архитектурные компоненты могут быть созданы в любой момент (проектами развития, или кейсами -- тут уже не так важно).
в) целевые архитектурные описания, выполненные с использованием наличных компонент.
8. Тем самым предпринятие PraxOS (pun intended) создаёт не каталог компонентов методов для создания ситуационных методов, но расширяемый и пополняемый каталог архитектурных компонентов для создания адаптивных архитектур.
Тем самым можно говорить о планах релиза PraxOS 3.0 (предыдущие планы релиза 2.3 уже совсем устарели -- http://praxos.livejournal.com/455.html).
|
|
10:07 pm
[ailev]
[Link] |
Неформальное введение в понятия ОргЛана
Я решил, что черновой вариант, соответствующий начальным шагам реализации пункта 7 из августовских "10 тезисов к разработке ОргЛана" (http://praxos.livejournal.com/12907.html) нужно публиковать в 2011, заканчивая первую стадию работы с ним по методу time boxing -- не "по готовности", а "в старом году".
Это описание нужно далее:
-- почистить и исправить очевидные ошибки. В 2012 году я буду потихоньку улучшать текст прямо в этом постинге, внося правку по месту -- пока не возникнет необходимость переписать всё заново. Так что возвращайтесь время от времени, текст будет меняться -- и набор понятий и их отношений, и используемая терминология, и определения. Все изменения будут без особого предупреждения.
-- сделать к нему парочку примеров для КонкОрга, чтобы потренироваться в разговоре на этом языке. У меня есть давняя мечта повторить проект "Ивановские ситцы" (был такой проект художественного описания приватизации, чтобы помочь отождествить многочисленные формальные регламенты с реалиями жизни).,
-- отмоделировать в ISO 15926, чтобы получить классы и шаблоны ОргЛана.
А далее уже с формальной микротеорией ОргЛана на руках:
-- придумать формальную нотацию (вернее, нотации) ОргЛана,
-- мэппинг ОргЛана в существующие стандарты (и тем самым обеспечение частичной поддержки софтами. Например, мэппинг в Архимейт даёт возможность пользования редакторами Архимейта),
-- реализацию непосредственной поддержки ОргЛана софтом ПраксОС.
Обращу внимание, что данный текст не является "Рассказом о ПраксОС", ибо он не предписывает лучшие методы организации: тут ничего не написано "как делать", только "из чего состоит предприятие" -- один из ввариантов организационной онтологии, а именно "онтология ПраксОС".
В данном тексте я буду выделять понятия ОргЛана (OrgLan), давая им русские и английские имена -- но на данном шаге такое выделение понятий не является ни полным, ни строгим. Я также почти не давал формальных определений (таковыми обычно считают "X -- это специализация Y в том-то и том-то"). Я буду там и сям давать ссылки на различные источники, знание которых необходимо для понимания этого рассказа (ибо не думайте, что всё написанное придуманно лично мной и представляет собой "онтологию одного человека"), и я не сверял немногие выданные определения с этим источниками.
Когда мы рассматриваем предприятие (enterpise), то нужно четко различать в нём:
-- предпринятие (endeavour): то, что происходит в действительности -- актуальные работы с железками, а также производственными (production) и координационными (сoordination) фактами (facts).
-- справочные данные (reference data): это "знания" -- то, что мы знаем про "жизнь вообще": общую для всех предприятий картину мира и методы, а также существование общих для всех предприятий объектов (каталожных классов рабочих продуктов, адресных баз других предприятий, клиентов).
Без понимания этого различения (между реальными объектами и отношениями, индивидами (individual) и классами (class) объектов и отношений) понять ПраксОС невозможно, это основа основ. Это понимание при моделировании примерно соответствует различению methodology domain и endeavour из ISO 24744, reference data и project data в ISO 15926. Тем самым "предприятие = предпринятие + данные = кусок мира + знания о внешнем мире".
Предпринятие, как имеющее отношение к реальности, имеет приоритет над справочными данными. Много разных вариантов справочных данных может быть соотнесено с одним и тем же предпринятием (то, что для одних -- таскание камней, для других -- строительство храма, для третьих -- бессмысленная трата сил).
Любое рассмотрение должно начинаться и заканчиваться с предпринятия, а не со справочных данных. С другой стороны, справочные данные дают возможность накопить опыт разных предпринятий, чтобы каждый раз не изобретать велосипед при описании предпринятий, их создании/выращивании/развитии -- но это только информация (сведения), в реальности объектов справочных данных нет. Можно летать на самолёте с серийным номером в какое-то конкретное время (этот алюминиевый самолёт и его полёт существуют в реальности, в предпринятии), но нельзя летать на классе самолёта в классе времени полёта (это знание, а на знаниях далеко не улетишь. Даже если это знание вынести в реальность в виде данных на носителях, то и на фрагменте диска с данными самолёта тоже далеко не улетишь). Простые тесты отнесения к реальному миру: "можно увезти на тачке", "можно указать пальцем".
Предпринятие (endeavour) -- это организованные (с определенными ролями, полномочиями и ответственностями) люди и оборудование, здания, сооружения, материалы и рабочие продукты. Такое определение полностью соответствует ISO 15288 (там оно использовано для предприятия в целом, включая справочные данные, но подчеркивается принадлежность к реальному миру). Предпринятие -- это разворачивающаяся в актуальном пространстве-времени физическая система (индивид -- хотя и очень сложно устроенный, и непрерывно меняющийся), об этом разворачивании во времени известны производственные и координационные факты (верные на какой-то момент актуального времени). Предпринятие (в отличие от юридически определяемого предприятия) характеризуется тем, что система-предпринятие имеет четко определенную функцию, которую необходимо максимизировать (goal по Голдратту), изменяя конструкцию предпринятия.
Напомню, что предприятие в юридических документах часто определяется как существующее не только "вечно", но и для достижения определенной цели. В том числе предприятие может не иметь юридического лица. Более того, предпринятие (в отличие от предприятия) вовсе необязательно целью имеет получение денег -- например, церковь целью имеет спасение людей, а политическая партия завоевание власти. Главным для нас является то, что предпринятие имеет цель -- какой-то критерий, по которому определяется глобальный максимум. В книжках по теории ограничений можно найти много обсуждений о разнице "стремления к максимизации показателя" как goal и "удовлетворению критерию, а дальше хватит стараться" как target. В юридической литературе тоже много обсуждений о предприятиях как юридических лицах или созданных без образования юридических лиц, созданных на время или для достижения какой-то цели, и созданных "навечно", но нам сейчас это неважно. Важно, что "глобальней предпринятия системы нет". Расширенное предприятие (extended enterprise), которое определяется как система предприятий, выполняющих крупный инженерный проект, а также новомодное слово эко-система (eco-system) для того же самого на потребительских рынках (например, "эко-система фирмы Apple, объединяющая саму фирму и ее поставщиков, телефонных операторов, разработчиков приложений, пользователей телефонов и т.д.") -- это всё тоже предпринятия, которые реальны.
Предпринятие ведёт кейсы (case) -- системы, некоторые аспекты которых нужно перевести из текущего состояния в целевое (не путать целевые состояния кейса с целевым состоянием предпринятия -- этого "целевого состояния", ведущего к "закрытию предприятия" и вовсе может не быть! А кейс обычно есть заинтересованность закрыть!). Кейсы именуются указанием целевой системы и указания на группу описаний состояния: "здоровье пациента" в больнице, "работоспособность прибора" в ремонтном предприятии, "справедливость для истца" в случае судебного дела, "катастрофа на местности" в случае спасательных мероприятий. Кейсы "открываются", когда предприятие становится обеспечивающей системой для этих кейсов, и закрываются, когда целевая система переходит в зону ответственности другой обеспечивающей системы. Кейсы (системы) тем самым проходят жизненный цикл кейса, включающий в себя стадии, контрольные точки, на них выделяются ресурсы, они являются предметом проектов (которые понимаются как постадийное выделение ресурсов на кейсы), с ними работают процессы (которые понимаются как последовательности работ, нужные для изменения состояния кейса). Кейс нетождественен целевой системе, кейс -- это темпоральная часть целевой системы. В этом плане максимизация результата кейса всегда подчинена достижению глобального максимума предпринятия (задаваемого обеспечивающей системой) и глобального максимума, задаваемого для владельцем целевой системы. Кейсом владеет обеспечивающая система, а целевой системой владеет ее владелец.
Впрочем, есть ситуация, когда владелец кейса и целевой системы -- одно и то же лицо: кейс, когда владелец предпринятия пытается добиться чего-то от собственного предпринятия (например, освоить ПраксОС, поднять прибыльность на небывалую высоту, выйти на зарубежные рынки, первыми высадиться на Марс). Обычно про такие кейсы говорят как про "организационное развитие" -- сюда в том числе относится кейсы M&A, кейсы управления технологиями, реорганизации.
Кейсы в свою очередь делятся на issues, затрагивающие мелкие аспекты изменения состояния системы и имеющие свои локальные цели. Кейсы отличаются тем, что закрытия кейса контролирует владелец целевой системы (валидация: то, что сделано, удовлетворяет владельца), а вот закрытия issues контролируются работниками предпринятия, как обеспечивающей системы. С этой точки зрения кейс задаёт глобальный максимум, а issues служат локальному максимуму.
Ведение кейса и его issues от открытия до закрытия включает в себя производство самых различных работ (work), которые занимают конкретное время и требуют возможностей предприятия по их совершению: сервисов (services) предпринятия. Предпринятие, как обеспечивающая система, имеет готовность проводить эти работы через определенные каналы (места, интерфейсы) -- т.е. внешнее поведение обеспечивающей системы (функции для клиентов) структурировано как сервисы. Сервисы понимаются так же, как в Архимейте: они представляют собой готовое к осуществлению поведение обеспечивающей системы, как активной структуры. В этом плане продукт -- это предоставление обеспечивающей системой-предпринятием для систем в его операционном окружении сервисов (работ по ведению кейса -- изменения состояния целевой системы), связанных контрактом. Это вполне архимейтовское понимание сервиса. Обращаем внимание, что функции предпринятия с точки зрения его (обеспечивающей системы) владельца и сервисы предпринятия с точки зрения владельца целевой системы -- это абсолютно разные сущности.
Кейсы и issue в предпринятии являются целевыми (т.е. над которыми ведется работа -- "пассивная структура" в терминах Архимейта, work product в терминах ISO 24744) системами-подсистемами разного уровня композиционной иерархии, причем эти целевые системы-подсистемы могут находиться в разные моменты времени в разных состояниях, не теряя при этом своей идентичности. Будем называть их "объекты" (подчеркивая пассивность). Возможны различные классификации объектов (в том числе и гибридные -- где основание классификации меняется на каждом уровне иерархии):
-- по уровню абстракции (деятельностные объекты, данные, "в железе")
-- по отношению к целевой системе (сама система, модель системы, документ с моделью системы),
-- по описанию в каком-то конкретном виде документации
-- по известным методам работы (обработки исходного состояния или получения целевого состояния).
-- по возможности закупки (каталожное оборудование, длинноцикловое оборудование)
Работы предпринятия выполняются акторами (в ISO 24744 producers, в Архимейте это "пассивная структура") -- людьми-деятелями (actors) и их агентами-инструментами, в том числе -- компьютерными. Агенты всегда работают в рамках полномочий, данных им деятелями-принципалами, деятели несут ответственность за деятельность их агентов. Если вам банкомат неправильно поменял купюру, вы будете искать телефон ответственного за этот банкомат деятеля, а не ругаться с самим банкоматом). Деятели и инструменты обычно назначаются на роли акторов (в частности, "автоматизация" часто выглядит как назначение робота-агента на ту же производственную роль, на какой раньше был деятель -- если отвлечься от того факта, что при автоматизации обычно меняются и роли).
Возможны различные (в том числе гибридные) классификации акторов:
-- по технологиям (соответствие акторов каким-то методам работы)
-- по полномочиям (органиграмма структура)
Соответственно, конкретные акторы предпринятия занимают те или иные роли в шаблонах описания акторов (в смысле ISO 15926) и согласно этим ролям называются "исполнители", "топ-менеджеры", "инфраструктура", "подразделения", "филиалы" и т.д.
Работы, осуществляемые в порядке осуществления сервисов, могут быть сгруппированы очень по-разному (в скобках -- дисциплины, описывающие способ группировки, но гибридные классификации тоже очень распространены, например в любой WBS можно узнать такую гибридную классификацию):
-- по единству полномочий и ответственности исполнителей работ (традиционные "орг.функции")
-- по единству учёта ресурсов для кейса (project management)
-- по последовательности осуществления (process management, total quality management)
-- по направленности на ту или иную целевую систему (case management)
-- по появлению ранее не встречающихся работ (adaptive case management)
-- по используемым в данном предпринятии методам работы (situational method engineering)
Соответственно, конкретные работы предпринятия занимают те или иные роли в шаблонах описания работ (в смысле ISO 15926) -- и согласно этим ролям называются "проекты", "экземпляры процессов", "работы кейса", и "работы по method enactment" и т.д.. Это всё "классификации", многие из которых абсолютно неспецифичны для конкретного предпринятия, и тем самым относятся уже к справочным данным.
Справочные данные (reference data) определяются по ISO 15926 -- как общие для нескольких предпринятий (чаще говорят о НСИ), или даже нескольких кейсов предпринятия (чаще говорят о мастер-данных, MDM. Заметим, что концепция MDM не работает для отраслевых случаев, а работает только для предприятий с жесткой организацией). Эти данные реализуют ("реализуют" понимается как в Архимейте -- реализацию данными для соответствующих объектов деятельности) сведения о:
-- внешних по отношению к предпринятию системах (операционное окружение самого предпринятия -- его партнеры, клиенты, надзоры и т.д.);
-- возможностях закупки (каталожное оборудование, справочники сервисов);
-- нормативах, стандартах, отраслевом и гос.регулировании
-- классификаторы, словари, тезаурусы и прочие справочники;
-- методы (библиотеки компонент методов, библиотечные архитектурных методов описания), куда входит знание о типовых работах (т.е. видах работ), типовых объектах (видах объектов), типовых акторах (видах акторов).
Важно заметить, что есть два способа формирования справочных данных:
-- непосредственно описывая виды объектов, работ и акторов как "классы классов" (подход ISO 15926). Это "традиционный научный способ объект-ориентированного описания": описывать классы, потом порождать соответствующие им объекты (особо заметим, что речь тут не идет о объект-атрибутной модели, а речь идет о платоновской парадигме "классы сначала, объекты потом").
-- используя предыдущие описания предпринятия в качестве основы для справочных данных: это примерно соответствует "прототипному подходу к объект-ориентированности", и весьма точно соответствует "производственному способу".
В этой части (порождения справочных данных по данным предпринятия -- а не наоборот, порождения данных предпринятия в соответствии со справочными данными, "по метамодели") исследований нет, и книжка BORO тут пока не помощник. Особо отметим, что речь идет только о способе описания. Ежели же брать ПраксОС как набор методов, то в части описаний поведения это модная сейчас и остродискуссионная тема process mining: там обсуждаются совсем другие вопросы -- нужно ли "асфальтировать протоптанные дорожки" в качестве шаблонов для процессов. Ибо это могут оказаться дикарские тропы, а не "правильные пути", которые можно было бы спроектировать при традиционном подходе upfront конструирования справочных данных.
С Новым Годом, с новым ПраксОС-2012!
|
|
10:36 pm
[ailev]
[Link] |
Дважды контринтуитивность Праксос: мощные идеи предмета и мощные идеи по его описанию
В моих поисках контринтуитивных мощных идей (http://ailev.livejournal.com/500732.html) я нахожу
1. Предметная контринтуитивность: за счет нахождения предельно эффективного метода. Примером может служить отобранный в пункте 7 моих десяти тезисов по ОргЛану короткий списочек организационных практик и связанных с ними метамоделей (http://praxos.livejournal.com/12907.html): EA (Archimate), SME (ISO 24744), ACM (CMMN), business rules (SBVR) и т.д.
2. Описательная контринтуитивность (использование Онтолана и Орглана, http://praxos.livejournal.com/13095.html): эти практики из пункта 1 я описываю с использованием 4D онтологии -- то есть пытаясь понять, "что такое" представляет из себя по онтологическому типу (индивид? класс? отношение? интервал времени? момент времени? физический предмет? и т.д.). Такой метод описания позволяет:
а) существенно компактифицировать результирующие описания каждого из предметных методов, заодно формализовав их в достаточной степени для работы с информационными системами (компактификация за счет использования 4D формализма -- это объясняется в работах типа книжки BORO, http://ailev.livejournal.com/938647.html). Формализм осваиваем в рамках проекта ![[info]](http://l-stat.livejournal.com/img/community.gif?v=92.2) dot15926.
б) частично отождествить аналогичные описания в разных методах (выявить correspondence rules) и нормализовать эти описания уже для всего набора методов (http://ailev.livejournal.com/872954.html).
Обращу особое внимание, что работы нынешних организационных онтологов (поищите в Гугль organizational ontology -- увидите очень много материалов) меня полностью не устраивают. Они отличными онтологическими методами работают с допотопными представлениями об организации. Толку от этого немного.
Мы же применяем онтологическую работу к новинкам организационной работы. Тем самым получаем praxos как "новый товар в новой упаковке", контринтуитивно оформленные контринтуитивные идеи.
|
|
11:03 pm
[ailev]
[Link] |
Орглан и Онтолан (Orglan and Ontolan)
Традиционно архитектурные языки и подходы (они же, как нам рассказали Захман и Диетц, теперь называются "организационные онтологии") структурируют свой предмет (scope) в виде каких-нибудь "матриц" или "трехмерных матриц". Для Архимейта это куб "субъект -- поведение -- объект / бизнес -- приложения -- технология / внутреннее -- внешнее" (то, что это не "таблица", а именно "куб", подробно рассказывается в книжке) и треугольничек "общие понятия -- понятия Архимейта -- понятия предприятия". Для подхода Захмана в версии 3 -- это матрица "что-где-когда-как-почему / уровни реификации".
Оказывается, что в enterprise architecture не так много специфических именно для этой архитектуры различений. Огромное их количество оказывается связано с upper ontology -- выбором того, как мы представляем мир. Предприятие -- это часть мира, и онтологические выборы оказываются крайне важными для описания предприятия. Если вы в мире не выделяете системы из их окружения, то архитектура предприятия у вас тоже будет бессистемной (pun intended).
Для определения предмета (scope) Орглана нужно как-то взглянуть на предметную область с птичьего полёта -- задать что-то типа таблички и треугольничка Архимейта, или матрицы Захмана. В качестве шага для этого можно предложить следующие возможные "размерности" (различения) для этих треугольничков и табличек:
1. "Пирамида знаний"
Обычно "пирамида знаний" рисуется треугольничком отдельно от всяких "матриц", в которые пытаются упихнуть разные другие различалки. В этой пирамиде показываются "уровни общности понятий".
1.1. формализм -- representational ontology, мета-мета-модель. В SysML/UML это MOF, в ISO 15926-2 это EXPRESS, в ISO 15926-7 это FOL, в Archimate -- это квадратики разной формы и разнообразные стрелочки (т.е. формализм в явном виде не задан, и это очень плохо).
Мы выбираем в качестве формализма .15926L (т.е. не FOL, не EXPRESS, а сразу тьюринг-полный язык).
Это обычно в "треугольничке" пирамиды не показывают: это тот материал, из которого сделана сама пирамида, тот холст, на котором нарисована её картинка.
1.2. Онтолан (Ontolan, от ONTOlogy LANguage -- странно, такого слова Гугль еще не знает), upper ontology -- "школьное" (т.е. для изучения в средней школе) подмножество ISO 15926-2, или аналогичное "улучшенное", но отмэпленное в ISO 15926-2 (например, подмножество HQDM). Вряд ли стоит сейчас замахиваться на собственное "улучшение" типа HQDM, которое потом нужно будет самостоятельно мэппить в ISO 15926, но наверняка придется озаботиться выбором более точных и удачных слов.
Что точно должно войти:
-- множественные специализации (классификации, хотя речь идет не о членстве в классе: ненавижу эту запутывающую терминологию)
-- многоуровневая конкретизация-порождение (уровни абстракции, мета)
-- мереология (части и целое, в том числе темпоральные части)
-- время: моменты и интервалы
-- системный подход: функциональные места и модули
-- агенты, действия, продукты
-- информация, данные, информационные продукты
-- "география" (места, адреса, площадки)
Что точно не должно войти (ибо должно попасть в "расширения" Орглана):
-- стереометрия (3D, формы)
-- "естественные науки" (молекулы, атомы, живое-неживое)
-- парсинг (правая-левая часть имени) и прочая информатика
В чем есть сомнения:
-- свойства и UoM (обычно нужно ддля описания продуктов, но в архитектурных языках часто этого просто нет -- например, в ArchiMate). С другой стороны, как в школьном языке без свойств?
Про всякие кардинальности и ограничения пока умолчу.
1.3. Орглан (Orglan -- ORGanization LANguage): организационная онтология (мета-модель), т.е. специализация понятий и отношений Онтолана до специфически организационных понятий и отношений -- на которых можно выразить предметную область PraxOS (заметим, что сам PraxOS -- это каталог компонентов методов. Методы же написаны с использованием понятий Орглана. Тем самым PraxOS -- это тексты, написанные с использованием понятий Орглана (а без учета нюансов -- "Праксос написан на Орглане"). PraxOS относится к Орглану как "Сказка о царе Салтане" Александра Сергеевича Пушкина к словарю Владимира Ивановича Даля (со всей прилегающей дискуссией о влиянии поэзии Пушкина на состав словаря Даля).
При рассмотрении сегодняшних мета-моделей архитектурных языков оказывается, что значительная часть их понятий относится к Онтолану (т.е. выражает общеонтологические понятия, а не специфические именно для организации), а вот собственно специфичный для организации Орглан (специализация общеонтологических понятий, использующихся именно для организации и enterprise architecture, он же -- микротеория организации, он же -- middle level ontology for organization) оказывается не такой объемный.
Моя сегодняшняя гипотеза: Орглан состоит из тех понятий из разных организационных дисциплин, перечисленных в пункте 7 моих 10 тезисов (http://praxos.livejournal.com/12907.html), которые связаны между собой различными correspondence rules.
1.4. Мета-модели организационных дисциплин. Они связаны между собой corresponding rules, ибо мэппированы к связке Онтолан+Орглан.
1.5. Расширения (для выражения внешних моделей -- моделей продуктов, моделей экзотических организационных дисциплин, имитационных моделей и т.д.).
2. Разбиения (сборка-разборка, части-целое).
Системный подход -- это как раз оно: выделение холархий (т.е. иерархий по отношению часть-целое), модульность и связанные с модульностью интерфейсы.
Я нарочно не использую слово "детализация", потому как оно обычно используется и для разбиений (часть-целое), и для уровней абстракции. C другой стороны -- метасистемный переход обычно подразумевает смену типа описания при переходе к очередному уровню холархии (так, описывать работу органелл в клетке нужно одним способом, работу клеток -- другим, работу органов -- третьим, работу организма -- четвертым). Но это не разные уровни абстракции описания, это разные виды описаний для разного уровня разбиений.
3. Уровни абстракции (как туманно выразился Захман -- "реификации", уровни воплощения идеи в реальность -- от свёрнутых высказываний через порождение/generation к системе "в бетоне и металле", а в случае организаций -- "в людях и компьютерах"). Это совсем "детализация целого на уровне частей", а построение мета-модели с оглядкой на мета-мета-модель, модели с оглядкой на мета-модель, системы в реальности с оглядкой на модель.
4. Различение акта деятельности -- высказывания "продюсер/агент -- работа -- продукт" (в Архимейте это активная структура -- поведение -- пассивная структура).
5. Альтернативы (выборы и принятие решений, как в Goal).
6. Динамика (архитектура as is, архитектура to be, архитектура as built).
Еще раз обращу внимание, что практически все эти различения (если не все!) относится к общеонтологическим (ну, и немного инженерным -- у нас ведь деятельностная онтология), а не специфически организационным. Архитектурные языки -- это языки, описывающие основные принципы организации чего угодно, необязательно организации.
На первый взгляд, это всё сильно сложнее того же Архимейта или Захмана. Но это только на первый взгляд: просто часть сложности из неявной вышла наружу и названа явно. И эта часть разделена между Онтоланом и Оргланом.
Сразу оговорюсь, что дискуссия по Архимейту подвела черту под тем, как используется архитектура в целях коммуникации: архитектурные артефакты предназначены прежде всего для понимания специально обученными людьми, а для топ-менеджеров и прочих стейкхолдеров от рядовых сотрудников до заинтересовавшихся вдруг архитектурой приглашенных консультантов по случаю готовятся разные презентации (ага, в PowerPoint и без использования формализмов). Так что я не боюсь, что Онтолан+Орглан окажутся контринтуитивны и потребуют специального обучения. Любая хорошая контринтуитивная идея поначалу является непопсовой, и широко не распространяется. Затем мощность этой идеи берет своё, и она становится интуитивной. Мы надеемся ровно на такой сценарий с Онтоланом и Оргланом.
Итак, теперь нужно сделать Онтолан (и сразу -- учебный по нему курс, чтобы быть уверенными, что люди понимают его контринтуитивность).
|
|
06:18 pm
[ailev]
[Link] |
10 тезисов к разработке ОргЛана
1. ОргЛан -- это архитектурный язык и метод архитектурного описания (architectural language и architectural framework в смысле ISO 42010) для PraxOS. Пока мы продолжаем считать PraxOS промышленным каталогом компонент методов (http://praxos.livejournal.com/11084.html), содержащим лучшие методы организационной работы. В этом смысле ОргЛан является языком и нотацией, которые нам даёт для описания организаций каталог компонент методов PraxOS.
2. ОргЛан -- это также язык софта PraxOS, он же -- язык "корпоративного органайзера" (май 2007 (http://ailev.livejournal.com/485066.html, и в связи с этим древним постингом я бы напомнил, что название нынешней главной книжки по adaptive case management заканчивается на get things done - http://ailev.livejournal.com/946134.html, так что мы вполне современны).
Необходимый уровень детальности ОргЛана определяется в том числе и тем, что модель ОргЛана сразу предлагается делать не только "для генерации отчётов/исполнительной документации", но и исполняемой (т.е. не повторяем ошибок с удивлением по поводу "неисполняемого UML" или "неисполняемого BPMN" или "неисполняемого описания в ОргМастер" -- и последующим зоопарком решений этих проблем "недоформализованности"). Причём исполнение (т.е. интерпретация модели на ОргЛане софтом-"выполнителем") может быть сразу во многих смыслах: адаптивного управления кейсами -- case execution, автоматизированного порождения ситуационного метода или шаблона кейса (generative case management/method engineering) и т.д.
А для исполнимости не в среде софта PraxOS можно использовать мэппинги ОргЛана для других моделеров и исполняемых сред.
3. Можно считать, что про user needs и способы реализации мы писали более чем достаточно (а хоть и в марте 2011 -- http://praxos.livejournal.com/12277.html, или в июле 2011 --http://praxos.livejournal.com/12576.html -- мы тут в praxos только об этом и пишем, похоже) и можно приступать к архитектурной работе над ОргЛаном. До сих пор мы считали проектирование ОргЛана проблемой, в том числе не могли указать прототип. Данный постинг бьёт проблему языкотворчества на задачи, а для каждой задачи указывает свой прототип и пути решения.
4. В отличие от традиционных определяемых UML-метамоделями языков описания систем и деятельности (типа ISO 24744, ISO 42010 и т.д.), ОргЛан должен быть
4.1. онтологическим в смысле его типов данных (то есть отражающим структуру реальности), т.е. принципиально расширяемым в целях моделирования любых необходимых структур данных. Для этого ОргЛан будет выражен как микротеория на основе foundational ontology ISO 15926-2 (как IDEAS является foundational ontology для метамодели DoDAF 2.0 -- http://dot15926.livejournal.com/24543.html, а MOF является foundational ontology для метамодели SysML и SPEM). В принципе, мы будем считать синонимами "метамодель" (из мира MDA, UML и MOF) и "микротеорию" (из мира онтологий).
Это существенное отличие от традиционного хода на "онтологическое обогащение UML" (каковое мы видим, например, в OPDL http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371 и в ConML http://www.conml.org/), или "изобретение своей минимальной foundational ontology (как это вышло у ArchiMate). Мы хорошо осознаём тот факт, что изобретать foundational ontology и форматы представления онтологических описаний сегодня неприлично даже в масштабах одного университета (как недавно было сформулировано в ontolog-forum), что уж говорить о нашем маленьком проекте. Мы также не идём по пути OWL, декларируя только самые базовые объекты и отношения. Также мы наследуем работу по линии 4D онтологий IDEAS и ISO 15926 -- но возьмем не IDEAS (опять-таки, близкую к UML и даже используемую в архитектурной работе), а ISO 15926.
Вот схема из спецификации ArchiMate (рис.2 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html):
А вот схема для OrgLan:
Для программирования деятельности на ОргЛане тем самым недостаточно знать только сами понятия ОргЛана. Это знание не освобождает от понимания задаваемой foundational ontology "картины мира", т.е. необходим тренинг в 4D extensionalism. Это будет "входной билет", "образовательный ценз", и от этого никуда не уйти. По хорошему, 4D extensionalism в части моделирования данных вообще должен изучаться в школьной программе информатики, ибо это парадигмальная штука, и в ВУЗе это изучать уже поздно (кстати, это не только моё мнение). Поэтому программа адаптивного обучения "программиста/модельера на ОргЛане" должна включать в себя программу онтологического ликбеза.
Мы имеем следующие выгоды такого подхода:
а) гарантированную расширяемость ОргЛана (хотя эта гарантия и несколько "дутая": универсальных онтологий не бывает, но тщательно разработанная foundational ontology тут много лучше любых ad hoc решений) на другие предметные области
б) совместимость с детальными описаниями рабочих продуктов, инженерными описаниями и т.д. (по факту, мы просто даём детальную микротеорию для описания организационных систем, в то время как ISO 15926 "из коробки" имеет микротеорию для описания непрерывных производств). То есть наш "каталог организационных методов" в принципе совместим с "каталогом промышленного оборудования" (http://praxos.livejournal.com/11084.html).
в) возможность использования имеющегося инструментария и опыта работы по моделированию (в данном случае -- моделирования организационных систем, софта ISO 15926, учебников типа книжки о методе BORO -- http://ailev.livejournal.com/938647.html).
Про "ОргЛан для самых обычных пользователей" пока забываем. Нам нужен не "организационный бейсик для одного из организационных аспектов", а приличный универсальный язык. Текстовая и графическая нотация ОргЛана по факту будут текстовой и графической нотацией для DSL в "универсальном моделере" (http://dot15926.livejournal.com/24612.html). Пока не поддерживается многодиаграммность (т.е. не "как UML", или "как внешние DSL", а "как ArchiMate" и "как внутренние DSL на базе одного языка и синтаксиса".
4.2. ОргЛан должен быть полным по Тьюрингу в алгоритмическом смысле (ибо любой язык будет развиваться, пока не станет полным по Тьюрингу -- так лучше мы сразу это предусмотрим).
4.3 Возможны "сурово денормализованные" варианты языка -- в том числе порожденные генератором отчетов, выдающим всяческие "положения", "регламенты" и прочая "распорядительная документация". Т.е. для текстов на ОргЛане должен быть предусмотрен не только "парсинг", но и "рендеринг": http://ailev.livejournal.com/925813.html?thread=9257845).
5. Версии
5.1. В версии 0.1 ОргЛан мы будем описывать примерно на том же уровне формализма, как в ArchiMate -- то есть неформально.
5.2. Затем в версии 0.2 ОргЛана будут использованы только классы и отношения части 2 (характеризация).
5.3. В версии 0.3 затем будут сформулированы шаблоны (часть 7 ISO 15926).
5.4. В версии 0.4 для перехода к Тьюринговой полноте будет использован .15926L.
6. ОргЛан задается системой, состоящей из частей:
6.1. архитектурного описания (основная организация и принципы разработки) -- заготовкой для него является настоящий постинг.
6.2. описывающей деятельность микротеории ОргЛана в составе библиотеки справочных данных PraxOS (соответствует "метамодели" в традиционном понимании ArchiMate, ISO 24744 и т.д.)
6.3. текстовой и графической нотаций для выражения моделей, соответствующих этой микротеории (метамодели).
6.4. механизма описания рендеринга (по мотивам XSLT -- ну, или что-то более удобное и приемлемое), но это будем определять позднее
6.5. механизма расширения ОргЛана, который суть ISO 15926 во всей его полноте.
6.6. адаптивного механизма обучения
6.7. примера моделера и исполняющих сред -- софт PraxOS (две среды: отчёты/рендеринг и execution кейсов в стиле ACM).
6.8. примера описания на ОргЛане (описание КонКорга, типа описания ArchiShurance или примера из ISO 24744)
6.9. По потребности можно будет делать мэппинг в исходные метамодели для частных стандартов -- если это нужно будет для передачи данных оргмодели, задействования чужого софта, переработки терминологии в литературе методов-источников (ISO 24744, ArhciMate, ACM и т.д.) в учебные материалы для PraxOS.
7. За основу в определении scope берём "матрицу предметных областей" из ArchiMate, наглядно показывающую его scope (рис. 5 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html):
Но мы будем нещадно модифицировать эту матрицу в сторону расширения domains (берем из недавнего обзора http://praxos.livejournal.com/12576.html и годичной давности спецификации http://praxos.livejournal.com/9003.html), прежде всего в сторону business architecture (по сравнению с традиционными IT-центрированными описаниями), но также и в сторону execution-orientation по сравнению с analysis orientation (на что указывают в adaptive case manatement). За основу моделирования берём (и это как раз определяет scope -- после унификации "похожих" концептов) следующие мета-модели:
7.1. enterprise architecture -- ArhciMate (http://ailev.livejournal.com/940819.html). Сюда же -- доопределиться с описанием системы/подсистемы/надсистемы и показом модульности/сервисов/интерфейсов.
7.2. situational method engineering -- ISO 24744 (набор понятий -- http://ailev.livejournal.com/816938.html).
7.3. adaptive case management -- OMG CMMN (http://neffics.eu/wp-content/uploads/2011/06/11-05-12-CMMN.pdf и много дополнительных материалов в http://ailev.livejournal.com/946134.html). Тут нужно задуматься, как учесть BPMN 2 (простыковаться с которым так хотят управляющие кейсами), и нужно ли его учитывать сразу. Сюда же -- WS Human Task 1.1 -- http://docs.oasis-open.org/bpel4people/ws-humantask-1.1.html
7.4. business rules -- OMG SBVR в части собственно rules (т.е. примерно 10% стандарта, а остальные 90% там про бизнес-онтологию) -- http://praxos.livejournal.com/8380.html
7.5. strategy/motivational model (включая обоснования/предположения -- rationale/assumptions) -- карта действий и результатов (http://praxos.livejournal.com/6777.html)
7.6. business model generation -- http://businessmodelgeneration.com/book, но вот в форме метамодели это придется разрабатывать самостоятельно.
7.8. много ценных идей -- DEMO (с учётом критики из http://www.cordys.com/ufc/file2/cordyscms_sites/download/731375d512f6789e8dd8a2775d26c123/pu/cor0027_modeling_rfi_white_paper_lr_v1.pdf). Координационные и производственные акты, B, I, D-организации и т.д.
7.9 управление вариантами (ибо у нас evolving описание) вкупе с управлением конфигурацией (идентификация, учёт и т.д.). Для двух целей: прохождение развилок (trade-offs) и для поддержки типовых решений (паттернов, шаблонов, "рыб" и т.д.).
7.10. Обмены и контракты -- REA2 и NOMOS (http://ailev.livejournal.com/876070.html), legal кусочек из service science: http://www.loa-cnr.it/Papers/FerrGuarFern.pdf.
7.11. Из TOC: ограничение (роль элемента ОргЛана) и критическая цепь (агрегат workunits) -- придется разработать самим. Все эти "управление проектом через отслеживание его буфера времени" -- это сюда.
7.12. Модель стоимости (потоки, маржиналистский учёт). Придётся разработать самим.
7.13. Модель для KPI. Нужны исследования -- обсуждается это и в GORE, и во многих других местах. Плюс нужно разобраться: нужно ли это вообще, или это просто морок.
7.12 что-то из учебных стандартов (ибо нужно уметь представлять "дисциплины" -- что грузится в голову) -- поглядеть на наличные стандарты для всяких курсов. Но, возможно, придётся разработать самим -- в очередной раз изобрести велосипед.
...
По идее, за каждой строчкой тут стоит какой-то отобранный в PraxOS метод организационной работы. Особо отмечу, что ISO 15288 тут никак пока не участвует: он может потом быть записанным на ОргЛане, ежели будет нужно. Или будет записан новый стандарт "моделеориентированной системной инженерии". Или "инженерии системы систем". Или ещё какой-нибудь. Но это уже "используемый метод работы", а не организационный метод (хотя для групп обеспечения проектных практик, проектных практик и практик соглашения можно было бы и поспорить).
Понятно, что для начала нужно будет взять компактное ядро, поэтому "последовательность интеграции" этих всех частных и разнородных метамоделей отражена в том порядке, каком я их привёл: начинаем с головы списка, и далее медленно-медленно идем до его конца, по метамодели за раз. Но нам нужен сразу весь список, чтобы нарисовать нашу domain-таблицу.
Основные идеи по этому "мегамэппингу" (мэппингу на уровне не столько понятий, сколько domains):
а) добавить разделение на 24744:каталог vs endeavor и ACM:design-time vs run-time (в том числе идея, что case -- это как раз в endeavour). Как это показывать на диаграмме?
б) 24744:workunits, workproducts, producers = ArchiMate:behaviour, passive structure, active structure
в) 24744:нотации, языки трактовать в составе методов описания ISO 42010. Как эти 24744:resources = 15926:reference data показывать на диаграмме?
г) 42010: Stakeholders = actors, причем "не бывает нефункциональных требований", вводим понятие stakeholder case как расширение user case -- и далее думаем, как это связано с ACM
... и так далее.
Нарисовать "карту ОргЛана" с описанием domains нужно в первую очередь.
8. Собственно, неформальное задание языка и его неформальная метамодель будут в какой-то степени похожими на таковое в ArchiMate (http://www.springerlink.com/content/pwh613/back-matter.pdf)
Тем самым на "подложке" из "диаграммы domains" из предыдущего пункта показаны классы и отношения предметной области (а про шаблоны и тьюринг-полновость -- нужно будет еще подумать. Пока же -- Gellish и ArchiMate наши рулевые).
В качестве графической среды на "неформальной стадии" разработки микротеории/метамодели можно пробовать использовать VUE -- http://ailev.livejournal.com/895091.html. Дальше, конечно, работаем с .15926 Editor.
Фишка в том, что metamodel для каждого из этих domains содержит 30-70 понятий, которые существенно между собой пересекаются (весь вопрос только в том, насколько существенно!). Так что в идеале от рефакторинга этих метамоделей мы можем получить более компактное представление предметной области -- но помня при этом про эффект "14 стандартов" (http://xkcd.com/927/). Про соотношение между "рефакторить" (компактифицировать знание) и "интегрировать" (мэппить исходные стандарты) подробнее -- http://ailev.livejournal.com/872954.html.
Я бы сделал следующую оценку:
-- foundational ontology дана нам в 201 типе сущностей части 2 ISO 15926, а
-- организационная онтология вся должна уместиться в 300 классах и отношениях, если выбраны достаточно выразительные классы и отношения.
-- плюс мэппинги (но они формально не входят в ОргЛан. Мэппинги возможны и не в исходные стандарты -- они потом возможны в любые стандарты и могут делаться независимо)
9. ArchiMate также является прототипом того, каков наш подход к определению view: это "отфильтрованные куски полной модели" для показа концептов, относящихся только к какой-то тематической группе описаний, а viewpoint тем самым -- это паттерн фильтра, накладываемого на семантическую сетку модели. Этот вариант явно предусмотрен в ISO 42010, так что мы даже соблюдаем при этом стандарт.
Еще раз: не нужно путать domains с view (ибо domain -- это научный предмет, а view это способ комбинировать модели для этих предметов для более удобного их восприятия, в том числе для понимания их связей между собой. То есть соотношение domain и view как М:N).
В ОргЛане прямо сейчас определяются предметные области (domains), но пока не делается предположений о необходимых view -- если их можно будет задавать динамически "паттернами", то библиотека таких паттернов появится "сама собой", в том числе она будет уникальна для каждого кейса-предпринятия использования PraxOS и ОргЛана. Так что (в соответствии с заветами ACM) мы определение view сдвигаем на run-time -- то есть определяем как "динамическое", а шаблоны для этих veiw (т.е. viewpoints) будут создаваться тоже run-time в community library. С учетом возможности расширения самого состава элементов в этих view (расширяемости ОргЛана) это также можно назвать и "адаптивным" заданием view.
10. Предполагается, что обучение ОргЛану происходит "сержантским методом" -- модельеры проходят много-много упражнений (http://ailev.livejournal.com/907435.html), а учебный комплект состоит из:
-- объяснений и главной последовательности комплексных упражнений
-- регистра затруднений и пояснений к ним (нужно разобраться, в чем именно ментальный затык ученика: какой элементарный навык в комплексной задаче у него дефицитен -- и назвать его)
-- (некомплексных) упражнений на отдельные затруднения (зная, как называется элементарный пропущенный навык -- находим пачку упражнений на его тренировку, а потом возвращаемся к выполнению комплексных упражнений)
-- софта, который способен автоматически определять успешность выполнения упражнений (в первой версии) и затруднения во второй версии. О генерации упражнений пока и не мечтаем.
Понятно, что этот алгоритм сначала нужно описать подробно -- это еще ждет своей очереди. Но эта часть крайне важна, и она обязана входить в комплект поставки. Моделирование на ОргЛане контринтуитивно, затрагивает несколько разных парадигмальных сдвигов, и нужен интенсивный тренинг, чтобы пройти соответствующие метанойи. Это сознательный выбор: контринтуитивные очень мощные модели предметных областей плюс тренинг по преодолению этой контринтуитивности против "интуитивных моделей", "минимального тренинга" и соответствующих им "дурацких методов работы с неадекватными описаниями".
|
|
11:40 am
[ailev]
[Link] |
Что моделировать в организации, или опять о софте PraxOS как "универсальном моделере"
Можно было бы определить предметную область PraxOS как "то, что моделируется софтом PraxOS" (и наоборот: что является предметной областью PraxOS, то и моделируется софтом PraxOS). Ну, и что должно быть описано на ОргЛане?!
1. Организационная архитектура (enterprise architecture) -- можно думать об ArchiMate (http://ailev.livejournal.com/940819.html) с его business, applications, technology покрытием. Несмотря на всеохватность этой терминологии, сама выразимая на ArchiMate архитектура не так уж и велика. Так, уже сегодня обсуждаются добавки по целеполаганию (motivational).
2. Но если поглядеть, что поддерживают своим софтом конкуренты архитектурных моделеров, то свежий июльский 2011 обзорчик Enterprise Architecture Tool Selection Guide (http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.2.pdf) показывает следующие предметные области:
-- governance, risk, compliancy
-- program management
-- enterprise/IT-portfolio management
-- Business/IT strategy
-- Enterprise Architecture
-- Solution Architecture
-- Software Engineering
Обращает на себя внимание "айтицентрический" взгляд на организацию. Несмотря на все заклинания про нужность связи деятельности предприятия и его IT, предметная область деятельности предприятия затрагивается "внутри" самого предмета IT, а не сама по себе.
Тем самым по факту вводится два уровня моделирования организации: А) "общеархитектурное" (эскизный проект), верхнеуровневое и Б) в рамках создания самого софта, "рабочее" (детальное).
3. Ключевое тут -- это упор в "архитектурах" из полноценного описания метода работы (и сопутствующего моделирования предпринятия/endeavour) на именно что моделирование "технологии" (инструментов и артефактов), но не:
-- собственно ситуационного метода работы (http://ailev.livejournal.com/905099.html). Даже если выполнить элементарные отождествления (ArchiMate:object/passive structure=ISO24744:WorkProduct, ArchiMate:behaviour=ISO24744:WorkUnit, AchiMate:subject/active structure=ISO24744:Performer), многое остаётся за бортом: метод ("методология разработки", как что-то сделать: независимо от организации/управления ходом работ, упор на предметное содержание) часто крутится вокруг понятия "жизненный цикл" (http://ailev.livejournal.com/917251.html), но я не встречал в архитектурных языках какого-либо упоминания "жизненного цикла".
-- "дисциплины" (то, что грузят в голову, http://ailev.livejournal.com/930608.html) и сюда бы я отнёс также методы описаний (viewpoints) -- guides, models, languages и notations из ISO 24744, architectural framework из ISO 42010.
-- "организации в узком смысле" (распределение полномочий по задействованию акторов и обработка отказов/"выходы в дискурс": работа с координационными актами в DEMO),
-- стратегирования/обоснований (что не совсем точно относить к мотивационным моделям: http://praxos.livejournal.com/6777.html).
4. Поддержки эволюции организации и модели (прежде всего а)работа с вариантами оргмодели, и контроль конфигурации модели в ходе изменений -- поддержка соответствия между разными оргбазисами). Это должна быть явная поддержка управления технологиями, как метода перескока с одного поколения технологии на другое (http://ailev.livejournal.com/928711.html). Пример того, что нужно было бы уметь поддерживать явно в развертке во времени: http://ailev.livejournal.com/939027.html, только на место "системной инженерии" там поставьте любой другой метод и соответствующие ему дисциплины и технологию.
5. Есть многое другое, что пока непонятно, как реализовывать:
-- работу с ограничениями (т.е. эксплицитное моделирование "потока", throughput и ограничений на нём), чтобы реализовать "фокусирование по Голдратту".
-- dynamic case management dynamic case management (http://ailev.livejournal.com/711517.html, плюс http://www.itbusinessedge.com/cm/community/features/interviews/blog/case-management-is-step-forward-in-bpm-evolution/?cs=39882 и много-много других работ), для которого непригодны практики BPM (business process management), к которым традиционно тяготеет современная enterprise architecture.
-- сюда же можно отнести разбирательство с complex event processing, а также работу с business rules -- они тоже пока никак не затронуты мейнстримом организационного моделирования
6. Несмотря на то, что все архитектурные языки, а также метамодели ситуационной инженерии методов поддерживают "расширения", вряд ли этих расширений будет хватать. Это общеметодологическое замечание: как микротеорию (предмет) не растягивай, толку не будет, ибо не бывает универсальных онтологий. Современным выходом из ситуации выглядит опора всех архитектурных, методических, реализационных, технологических, дисциплинарных и прочих описаний на какую-то компактную и максимально общую "верхнюю" (foundational, upper) онтологию -- а все остальные группы описаний обязаны быть привязаны к типам этой онтологии. В DoDAF это 4D онтология IDEAS, в PraxOS по факту мы выбираем близкого родственника -- ISO 15926, тоже 4D.
7. В таком подходе софт PraxOS поддерживает не только каталог компонент методов PraxOS, но тесно связанную с ним организационную архитектуру (enterprise architecture), а также много чего другого -- чем, конечно, сильно отличается от типичных "организационных моделеров". Так что задаваемый в июльском 2011 обзорчике Enterprise Architecture Tool Selection Guide (http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.2.pdf) списке требований к софту оргмоделирования можно было бы выделить три группы:
-- поддерживаемые модели (вопросы типа "поддерживаем ли ArchiMate и TOGAF 9")
-- характеристики самого софта (работа с репозиторием, многопользовательская работа, лицензирование и т.д.)
-- цели и способы использования в организации.
Софт PraxOS вполне мог бы унаследовать требования по характеристикам самого софта, но вот поддерживаемые модели и цели и способы использования в организации наследовать из традиционных оргмоделеров не нужно.
8. Интересно, что задача "догнать и перегнать гигантов современного оргмоделирования" не кажется такой уж несбыточной:
а) реализация мощного движка онтологического программирования с поддержкой DSL общего вида (проект dot15926, реализующий подход language workbench в части онтологического программирования) может дать фору в собственно программистской работе: реализация софта PraxOS как настройки этого софта "универсального моделера" на ряд определенных в PraxOS DSL оргмоделирования может оказаться более эффективной и масштабируемой по предметным областям, нежели реализация специализированного софта.
б) некоторый онтологический тренинг в разы увеличивает скорость понимания проблем тех или иных предлагаемых методов описаний (я думаю, что имеющие опыт моделирования в ISO 15926 люди читают тексты спецификации ArchiMate абсолютно другими глазами, нежели опытные объект-ориентированные или даже функциональные программисты), что даёт шанс быстрой разработки как-то совместимого между собой за счёт опоры на ISO 15926 набора микротеорий для помянутых в предыдущих пунктах постинга разных предметных областей организации деятельности.
Трудность и огромные риски проигрышу "мейнстриму оргмоделирования" лежит в задаче удобного и понятного рендеринга (см. про соотношение "написания парсеров" и "написания рендеров" в http://ailev.livejournal.com/925813.html?thread=9257845). Можно сказать, что по части "парсинга" мы вполне можем быть впереди планеты всей, но по причине де-факто нашего игнорирования рендеринга мы можем отстать принципиально. Так что сейчас в PraxOS нужно обратить особое внимание на нотации и рендеринг, чтобы дать в проект .15926 надлежащие вводные на этот счёт.
|
[<< Previous 10 entries] |
