Об оргмоделирование

Jul 05, 2009 23:56

Про болото стандартов словарей организаций хорошее представление дает списочек из https://www.opengroup.org/projects/si/uploads/40/19580/Enterprise_Vocabulary_Workshop_-_Additional_Input.pdf

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

Основная печаль тут еще и в том, что на "SBVR 15926" Гугль выдает сплошь мои постинги. Первая же цитата из результата поиска -- "Люди из ISO 15926 об SBVR, похоже, не знают. Нужно будет им написать письмо (хотя я заранее знаю, что они ответят -- "отлично! вот и займись этим")". Глас вопиющего в пустыне.
* * *
С моделерами общего назначения (Artisan, Objecteering, Rational, Modelio, ModelPro, Eclipse MDT или EMF, Enterprise Architect и несть им числа) ситуация равно плохая: все они устроены одинаково -- представляют моделирование в картинках UML2 с целью довести результат до кода. Вся поддержка стандартов сводится к тому, что моделеры позволяют организовать "профайлы" (картриджи, плагины), поддерживающие те или иные стандарты. Эти "профайлы" между собой, как правило, не связываются. Изредка находятся герои, которые объединяют штук пять стандартов в один "профайл" (например, KnowEnterprise представляет такой "профайл" к Artisan Studio для SBVR, BMM, OSM, BPMN и еще ряду айтишно-ориентированных), но в моделерах общего назначения результат профайлирования ужасен: простым людям разобраться в этом программистко-ориентированном на UML2 мире нельзя, на диаграммах всего не увидишь, и приходится хитро манипулировать моделером, чтобы понять происходящее -- а моделер поддерживает прежде всего UML2 и все действия делаются не в терминах модели, а в терминах UML2.

Все эти моделеры с "профайлами" оказываются по факту редакторами базы знаний, используемыми не столько для стадии Knowledge Aсquisition и последующей отладки знаний, сколько для накатанной дорожки производства кода в заходе MDA и документации к этим кода кодам (прежде всего речь идет о конверсии модели в текст требований ТЗ для подписания договора, и уж только затем речь заходит о "документации к наваянному"). Так, даже в Systems Engineering Edition для Enterpise Architect (http://www.sparxsystems.com/products/ea/systems.html) главная фича -- это генерация кода из UML моделей. Код генерится в Verilog, VHDL, Ada, исполнимом SysML, а также в си (трех разновидностей), яве и прочие вижуал бейсиках.

База знаний оказывается при этом на UML2/MOF, куски целевой (в нашем случае организационной) онтологии подгружаются в виде "профайлов", отображение базы знаний на экране делается не в терминах удобных пользовательских DSL ("стереотипы" у меня язык не поворачивается называть DSL), а в терминах "иконок с подписями" -- в итоге в качестве нотации мы имеем диаграммно-иероглифическое письмо (можно поглядеть, например, на бесконечное количество иконок для SoaML, каковой язык моделирования услугоориентированной архитектуры так и определен как "UML профиль и метомодель для услуг" -- SoaML/UPMS: http://www.omg.org/docs/ad/08-08-04.pdf. Интересно, этих иконок больше, или иконок дорожных знаков?). Как честно там написано, Every attempt has been made to keep the notation extensions consistent with UML2 practice. This includes avoiding depending on color and keeping shapes easy to draw by hand. Ну да, они заботятся, чтобы их иероглифы можно было нарисовать тушью на бумаге!

Я понимаю, зачем системы оргмоделирования программистам. Но хотелось бы получить систему оргмоделирования, которая была бы развернута в сторону организаторов людей, а не писателей кодов. Решения, в которых организационные знания выражаются в UML2, не похожи на правильные. Нельзя людей заставлять набирать организационные нормы в стиле детского tile-программирования, из иконок-слов, которые нужно выбирать мышкой из огромных словарных деревьев (а именно такое решение предлагается в KnowEnterprise/Artizan. Правда, там можно подключить внешний редактор для этих целей, но и внешний редактор не сильно лучше).
* * *
Второй класс моделеров -- это системы представления знаний, если вы, конечно, сможете эти "системы представления знаний" отличить сходу от предыдущего класса UML-моделеров, см., например http://www.ajrhem.com/AJRhem-KAF%20Demo/index.cfm.htm. С "представлением знаний" произошла сильная девальвация, это сейчас "понятное программистам представление знаний для компьютеров", а не "формализация знаний для обеспечения человеческой коммуникации". О целях типа тех, которые ставит тусовка BusinesRulesGroup в OMG (иметь "формализованное для целей человеческой коммуникации представление знаний, заодно понятное компьютерам") я уж молчу. Меня устроило бы фактоориентированное представление знаний, к которому нельзя отнести даже OWL. Ибо OWL -- это тот же UML2, только в недотекстовом виде, без иероглифов. Почему "недотекстовом"? А вы попробуйте глазками прочесть "знания" на этом OWL!

Первое же наблюдение: оставь стандарты, всяк сюда входящий. Все стандарты "де факто" от человека или фирмы (типа CYC), или они вообще не стандарты и не опубликованы (типа БигМастер), или таки коллективной разработки и даже стандарты, но плохо структурированной в пространстве, времени и оргформах группы людей (типа Gellish).

Инструменты иногда есть. Иногда наборот, есть только стандарты (типа ISO 15926, включая WIP), но нет развитых инструментов -- к которым отношу прежде всего возможность сгенерировать какой-нибудь понятный альбом схем, пригодный для подписания генеральным директором в качестве приложения к приказу по предприятию (если уж вообще говорить о целях организационного моделирования, то это и есть цель: сделать модель организации "to be" и утвердить ее приказом директора. А потом утверждать изменения этой модели).

Бродить среди этих "не для программистов" университетских разработок "моделирования знаний" можно долго, и все они крайне перспективны. Но хочется-то а) стандартов и б) инструментов. А стандарты и инструменты появляются там, где обитают программисты. А программисты быстро-быстро все превращают в передачу токенов и машину состояний -- и их стандарты не помогают...

Забавно, что в 80-х я довольно много (в самых разных проектах и на разных местах работы) работал с этой предметной областью "представления знаний" как говорили раньше и "моделирования", как говорят сейчас, отмываясь от дурной репутации программистского "искусственного интеллекта" и не связываясь с гуманитарным "управлением знаниями". Что изменилось за прошедшие 20 лет? Вместо "редактора форм" или текстового редактора для редактирования используются графические редакторы -- а двадцать лет назад просто не было мышки. Сказать, что это принципиальное нововведение, я не могу. В некоторых задачах объемы информации стали огромны -- старые машины просто это не смогли бы переварить. Но никакого перехода количества в качество не наблюдается. Чуть больше внимания уделяется формальной полноте языков представления моделей: двадцать лет назад этому вообще не уделялось внимания, а теперь формализмами хотя бы чуть-чуть интересуются. Негусто, совсем негусто.

Нужно также понимать, что в указанной группе продуктов есть самые интересные: предназначенные не для генерации кода, а для обеспечения понимания. Именно к такому классу продуктов относится, например, БигМастер -- универсальный моделер, который разрабатывался как средство knowledge acquisition и последующей генерации не столько кодов, сколько отчетов.

Вот такое и нужно прежде всего -- удобное, ориентированное на людей, но соответствующее стандартам и с проработанной онтологией (это важно для связи с другими системами: одиноко торчащие приложения сегодня мало кому нужны). Ну, и где такое взять?!
* * *
Третий класс моделеров -- это IDE для DSL. Представления знаний, как осознанного моделирования тут вообще нет, все кодируется "просто языком" и называется DDE (domain-driven engineering).

Мне это направление кажется невероятно перспективным. По сути -- это тот же моделер, что и существующие UML-моделеры, но
а) представление моделей в памяти в них не ограничено MOF. Это может быть и фактоориентированное представление, и любое другое. Обратная сторона этой медали -- проблемы с обменом такими моделями с другими приложениями. Но обмениваться можно и в XMI, ежели приспичило. Сгенерировать UML -- это совершенно не то, что в нем работать.
б) представление моделей на экране в них не ограничено UML-диаграммами, и может быть сделано удобным для эксперта-непрограммиста. "Редактор языков/моделей общего назначения" или language workbench -- это очень и очень новый класс софта.

Увы, в этой области нет еще вообще ничего: ни нормальных DSL (есть какие-то очень узкие "тестовые примеры"), ни нормальных редакторов (три штуки, кочующие из обзора в обзор), ни заточки на генерацию просматриваемых человеком документов-выписок (поскольку делают это все программисты, то заточка существующих polyDSL-IDE делается на генерацию кода -- конечно, на Java). Про управление конфигурацией, многопользовательскость и прочие черты "промышленного программирования" я вообще молчу: это все будет, конечно, но "когда-нибудь".
* * *
Теперь несколько слов о примерах использования (user stories) организационных моделей -- это крайне важно для оценки того софта, который сейчас может быть использован для целей оргмоделирования.

1. Команда программистов пришла в организацию и декларировала "ориентацию IT на бизнес-цели". Чтобы это доказать, они вытаскивают UML-моделер, и первым делом делают BMM-модель. Клиент в восторге, его спросили про бизнес и заставили сформулировать показатели для balanced scorecards -- а эти balanced scorecards важны будут, чтобы "информационная система" (к которой все в конечном итоге и сведется) имела сразу "правильные отчеты". Существенным является knowledge aсquisition словаря, а также организационных норм и процессов вкупе с оргструктурой: по ним сразу генерируется код (BPEL с непосредственным исполнением плюс business rules engine), и многочисленные клерки тут же получают свои формочки и дашборды. Очень удобно, все счастливы. Модель процессов вывешивается на стенке в качестве документации, чтобы новые сотрудники понимали, что реально происходит и кто к кому с чем обращается.

Под этот сценарий уже сегодня можно брать UML-моделеры, и всем будет хорошо.

2. Служба развития компании пытается сформулировать новую стратегию и предложить новые организационные процессы. Для этого они организуют проектные сессии с компетентными в формулировании этой стратегии сотрудниками, используя организационную модель в качестве средства документирования и обсуждения "письменно зафиксированной" стратегии, организационных норм, процессов, а затем и оргструктуры. Любые изменения, сделанные в каких-то удобных для непрограммистов группах описаний (view), отражаются (согласно правилам согласования методов описаний, viewpoint correspondence view) в других удобных для непрограммистов группах описаний -- там отлавливаются организационные ошибки, и оргмодель тем самым становится все точнее и подробнее (с точки зрения людей-организаторов. Мнение программистов в этот момент никого не волнует). В какой-то момент менеджмент утверждает эту модель в качестве "руководства к действию" -- и "из неё" генерируются инструкции персоналу, альбомы оргструктуры и процессов, а после получения виз всех разработчиков эти (ага, уже бумажные) альбомы становятся приложениями к утверждающему их приказу.

Под это применение я пока не знаю средств (БигМастер мог бы сгодиться, но его заточенность на eIDEF0 делает его плохим средством моделирования процессов, включая хореографию. А несоответствие многим другим стандартам делает его нестыкуемым с другими видами софта: трудным переход к сценарию 1, в котором по тексту данной модели можно также сгенерировать еще и код. Кроме того, я не видел хороших нотаций DSL для описаний организации, понятных менеджменту. Иероглифику многоиконочных UML-нотаций не предлагать).

3. Создается временная организация для достижения какой-то цели (т.е. проект. Недаром в ISO 15288 слова "проект" и "организация" путаются). Строится организационная модель: определяются цели и задачи (BMM),
определяется процесс (в смысле SPEM -- форма жизненного цикла, стадии, методы работы и т.д.), делается экземпляр процесса и для этого экземпляра процесса планируется график (в смысле "сетевого планирования") проекта -- он же "процесс BPMN". Заключаются необходимые (не всегда письменные и не всегда "внешние") контракты/договорки, оргмодель начинает отражать расширенную организацию с учетом этих контрактов (хореографическая компонента BPMN, сейчас это BPDM, а потом просто BPMN 2). Выделяются ресурсы (добавляется "вписывание" в OSM). Запускается issue tracker + система управления конфигурацией для продуцируемых артефактов (включая управление конфигурацией deliverables), их настройки генерируются из оргмодели.

Для этих целей можно пробовать использовать те куски оргмоделирования (а они там есть!), которые застряли в системах управления проектами, issue trackers и некоторых workflow-системах -- системах управления процессами типа уже упоминавшейся процессно-проектной системы Savvion. Но как это оргмоделирование бедно и как его результаты невозможно утвердить приказом, ибо это оргмоделирование выполняется опять же программистами! Но нет сомнения, что эти обрывки застрявших в этом софте оргмоделеров будет постепенно вырастать в полноценные и более-менее понятные непрограммистам средства оргмоделирования. Очень постепенно, так что за время этого вырастания что-нибудь может произойти с самими классами этого софта (удивительно, но еще год назад я встречал не только множество непрограммистов, но и множество программистов, не знающих про такой класс софта, как issue tracker. А про то, что системы управления проектами внутри себя имеют маленькую собственную систему управленческого финансового учета, тоже мало кто догадывается).

Итого: из оргмодели можно генерировать 1. код софта, 2. тексты распорядительных документов, 3. настройки для систем управления проектами/процессами. Это означает, что фронт-энд "для экспертов" у моделера может быть один и тот же, а вот бэк-энды существенно разные (нельзя ведь говорить, что "софт фронт-энда генерирует просто текст" -- толку-то в такой "просто генерации"!).

Динамическую ситуацию, когда организация работы ежедневно меняется, отражая сознательно меняемую оргмодель (а оргмодель меняется, отражая сознательно изменяемую организацию работ) я пока даже не рассматриваю. Переход от статики к динамике, от "организационной компиляции" к "организационной интерпретации" -- это потом, когда-нибудь.
Previous post Next post
Up