April 23rd, 2006

2019

Современные технологии организации -- итоги семинара по оргмоделированию

Есть четыре области, в которых необходимо разбираться при оргмоделировании:

1. Метаонтология (не Upper Ontology, а собственно сам язык представления знаний). Бывает -- семантическая сеть (ОргМастер), бывает UML, бывает OWL. В этом месте мы договариваемся, что в мире бывают типизированные сущности и связи, а некоторые свойства сущностей наследуются вдоль некоторых типов связей.

2. Оргонтология (а это как раз Upper Ontology, но в одной предметной области). В этом месте мы договариваемся, что мы можем узреть в организации. Как правило, это ролевая структура, штатная структура, функции/процессы (тут мутное место), документы/данные, базы данных, архивы, статусы типа "утверждений" и "согласований, сотрудники и т.д. Эта оргонтология, как правило, должна быть расширяема, и поэтому сразу выражается в терминах метаонтологии. Выделяются три уровня (название произвольны): оргонтология -- минимальный набор сущностей и связей, необходимых для моделирования любой организации; опорная онтология -- это расширение оргонтологии для случая некоторого важного типа организаций (государство, фирма, церковь и т.д.), референсная онтология -- расширение опорной онтологии для какой-то образцовой организации. Работа в типичном случае -- это моделирование с использованием референсной онтологии, в редких случаях требуется обращение к моделированию на уровне опорной онтологии. Опорная онтология шевелится крайне редко, раз в год по итогам многих проектов. Каждое изменение организационной онтологии -- крупное событие в мире оргмоделирования.

Тут нужно заметить, что вполне можно представить себе оргонтологию, выраженную и в UML, и в орглане (в фирме БИГ этот язык называют OReL), и в OWL. Только выражение развитой оргонтологии в терминах конкретной метаонтологии -- весьма и весьма нетривиальная задача, которая должна включать в себя проверку на сотнях моделирований самых разных организаций самыми разными людьми. Проблема тут в том, что развитых организационных онтологий (формальных способов описания организации), операционно удобно синтезирующих самые разные знания об организации -- от стратегических ее целей до полей документов в каких-то конкретных процессах, от структуры холдинга до отражения статусов и содержания наполовину завизированного месячного кассового плана -- известно немного. Много известно про метаонтологии (например, любую организацию можно описать на фортране, или на UML, или на макроассемблере, если договориться со специалистами по организации, как это делать), но мало известно случаев, когда специалисты по организации договорились.

Отдельно ставится вопрос про машинного исполнителя процессов, описанных в моделях, или экспорта "исполнимого кода" (скажем, можно ли из информации модели синтезировать текст BPEL -- тут мне приходит в голову именно "синтез программ из описаний", ибо вряд ли процесс можно моделировать на BPEL, указывая где-то связь процесса с его стратегическими целями, показателями бюджетирования, привязкой к должностям исполнителей и прочим всяким, что там получается в процессе. Вопрос о том, как запускать планировщик типа critical chain или MRP II над десятком процессов, выраженных в BPEL, я вообще опущу). Конечно, код должен быть исполнимым, если дело дошло до кода. Но меня интересуют и те случаи, в которых дело до кода не доходит, а модель используется исключительно человеком с целью поразмышлять об организации. Получить отчет из модели для размышления над ним человеком и для размышления над ним каким-нибудь BPEL-движком -- это абсолютно однотипные операции.

3. Типовые отчеты. Это разные типы нотации для моделей, в которых для разных категорий пользователей модели (разработчиков, исполнителей, начальства, любопытных со стороны и т.д.) удобно обозревать разные формы. Для случайной работы очень удобны графические картинки, для профессиональной -- всякие текстовые формы (скажем, табличный эквивалент IDEF0-диаграммы. Видел, внушаить). Это все можно потестить на каких-нибудь фокус-группах. Если есть типовые отчеты, то можно говорить о каком-то WYSIWYG во вводе моделей, а если нет -- то это будет какое-то другое редактирование (более быстрое, удобное, но много менее понятное и интуитивное). Если есть типовые отчеты, можно учить людей их читать. Если есть типовые отчеты, то можно сравнивать модели разных организаций.

4. Софт редактора и других конверторов импорта, софт генератора отчетов и других конверторов экспорта. Тут, конечно, пусть расцветают сто цветов, если есть стандарты по предыдущим трем пунктам. Победит удобнейший и дешевейший. Пока самый дешевый софт этого рода -- программа ГосМастер (GPL), но она не является удобнейшей. Тем не менее, в нее заложено несколько очень крутых интерфейсных решений, которые дают ей фору перед многими другими "красивыми графическими решениями". Тут, правда, нужно сразу оговориться, какие пользователи будут у этого софта (так, в Ворде писать компьютерные программы совершенно неудобно, а в рабочих средах для программирования неудобно верстать документацию).

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

Я бы лично во всем этом месиве из computer science, usability и organizational engineering отдал приоритет качеству оргонтологии, а качество оргонтологии тестировал бы на легкости моделирования голдратовщины на предприятиях (да, с throughput accounting вместо ABC) и возможности описывать государство. Либо вы очень четко говорите, что такое организация в ее целостности, и какова должна быть методика ее описания, либо вам не поможет никакой стандарт метаонтологии и качественный софт.

Пока я считаю, что такой случай организационно-центричного описания (плохого и кривого, конечно, но существующего в природе) и сопутствующей практики более-менее единообразного подхода к оргмоделированию разных типов организаций есть в подходе фирмы БИГ. Метаонтология там -- семантическая сеть с весьма навороченными возможностями, организационная онтология тоже довольно кучерява, выходные формы небезинтересны. А главное -- все они согласованы друг с другом. Дьявол кроется, конечно, в семантике -- а она спрятана в исполнителях, которые ползают по этой сети. А исполнители воплощены в софте, что вроде как нехорошо, но поведение этих исполнителей может быть описано. Да и софт этот (в простейшем, правда, виде: программа ГосМастер -- без хелпа и с неправильно прописанной лицензией, но работает) доступен (http://www.elrussia.ru/62148, а методики и стандарты брать тут -- http://www.elrussia.ru/59559 UPDATE -- это обрезанная по свойствам ОргМастера, но рабочая версия, а учебная полная по свойствам, но ограниченная по размерам модели версия лежит в обмен на анкету с вашими координатами тут -- http://www.big.spb.ru/bigmaster/demo/edu/), что делает персонажей этого варианта весьма харизматическими лидерами при всех их прочих недостатках. А недостатков, конечно, более чем есть. У наличествующей и бесплатной вещи всегда больше недостатков, нежели у платной и отсутствующей, это понятно.
2019

Современные технологии организации -- итоги семинара по оргмоделированию (2)

Интегральное моделирование идет паровозиком: миссия-измерители-функционал-процессы-структуры данных. Вопрос, как обеспечить целостность всего паровозика. Увы, не только руководство, но и консультанты предпочитают концентрироваться на каком-то вагончике или смежной парочке из этого паровозика. Так, огромное количество "гуру по управлению" натаскивают на разборки с миссией и функционалом, операционные аналитики сконцентрированы на процессах, а программисты -- на структурах данных. Дальше все как в том анекдоте Райкина про костюмчик: к пуговицам претензий нет, а костюмчик не сидит. Ибо каждый из этого паровозика оптимизирует свою часть работы, воспринимая соседей просто как пейзаж (который нужно либо игнорировать, либо наоборот, подстроиться под него).

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

Поскольку все эти экспертизы разорваны, то и адекватного интегрального инструментария для моделирования организации нет. Частные модели весьма развиты, а интегральной модели, которой могли бы пользоваться разные группы пользователей -- нет. А сложность оргмодели делает соответствующий софт трудоемким в его дизайне и программировании. Ну, а если нет массового дешевого софта -- то слабо развита и сама предметная область интегрального оргмоделирования.
* * *
В организации необходимо явно и всегда выделять две деятельности: организовывание и собственно работу. Это разделение используется многократно:

1. Процессы и проекты различаются тем, что в проекте организовывание проводится каждый раз, когда выполняется работа, а в процессе организовывание происходит однократно, а выполнение работы потом -- много раз. Отсюда и частое отождествление в процессных организациях слова "проекты" за "проектами организовывания" (проектами управления изменениями) процессов работ. Тут можно вспомнить и о программах -- они подразумевают процессы (т.е. повторяемость) в организовывании в отличие от разовых "организационных изменений". Скажем, у Голдратта его "процесс непрерывных улучшений" -- явная программа, ибо совершенно непонятно, куда и как долго идти и каковы будут "проекты". Тем самым легко разобраться с "поручениями", которые попадут либо в проекты (если их нужно один раз организовать и выполнить) или в процессы (если их выполнение нужно организовать только один раз, а затем они организованно выполняются).

2. Для позиционного разделения "горизонтальных" и "вертикальных" компетенций различых управленцев и соответствующего разделения управленческих работ. Руководитель подразделения (вертикаль) рассказывает своим сотрудникам, как делать их операции. Но не он говорит, какие входы у этих операций, какие выходы, какие ресурсы для этих операций необходимо использовать -- это прерогатива "горизонтального", процессного руководства, которое не столько руководит производством работ, сколько организовывает сам процесс.

3. Организовывание относится к созданию сети производства работ, это управление сетью. А руководство работами относится к эксплуатации этой сети, прохождению работ по сети. Организовывание ориентировано на глобальный оптимум и устойчивость организации, а руководство работами ориентировано на локальный оптимум каждого участка работ.

4. Для разделения процессов организации ("управленческих процессов") и процессов выполнения работ в моделировании: путаницы в модели получается много меньше, а думать раздельно об организовывании и о собственно работе получается проще.

Один из вариантов, как об этом разделении думать -- это как о разделении законодательной и исполнительной властей. Хотя все эти "разделения", как известно, шиты белыми нитками.

Еще можно выделить несколько "уровней организовывания": стратегический, операционный...
* * *
"Организационное звено", оргзвено -- это очень удачное название, много лучше "узла" и "подразделения". Мало того, что оно не так зависит от парадигмы одного отдельного коммерческого предприятия (не любое организационное звено -- это подразделение. Так, коллегиальные органы, или аутсорсеры, или предприятия какого-нибудь холдинга не являются подразделениями), так для меня в нем есть еще и прямой намек на сеть (часто также называемую "цепь" -- chain, а регулярно так и вообще chain network). Организация -- это всегда цепочка передач работы из рук/машин в руки/машины, работопроводящая сеть.
* * *
В подходе БИГ функции и процессы -- это во многом одно и то же. Функции мыслятся как "готовые к выполнению (то есть как-то уже организованные) процессы". Процессы мыслятся как "выполняемые". Функции -- это возможность выполнить операцию (без контекста "кому, что, когда и зачем"), процессы -- это проведение операций с учетом контекста "кому, что, когда и зачем". В принципе, отдельные операции могут быть группированы многими путями -- по "профессиям", по организационным звеньям (те самые функции), по развертке во времени (процессы). Думаю, это еще не все способы группировки. Сюда и нужно думать: как это так получается, что все операции ("функционал"), которые приписаны к разным организационным звеньям (оргструктуре), вдруг да склеиваются в правильную цепочку операций процесса или проекта. Тем самым "процессный подход" так же однобок, как функциональный или оргструктурный. Правильно было бы говорить о системном/деятельностном подходе: искать повторяющиеся паттерны в различных аспектах операций и их организации.
* * *
Операции в процессе связаны не бинарными отношениями "операция Б следует за операцией А". Это обычно тернарное отношение "операция Б берет на вход Нечто из выхода операции А". Дальше быстро выясняется, что эти отношения n-арны (нужно указать кто делает и кому передает и т.д.), аппетит в моделировании процесса приходит во время еды. Дальше весь вопрос, сколько вообще раз выполнится та или иная операция, и во сколько обойдется ее сбой -- это определит точность, с которой нужно моделировать. Тем не менее, залезать в процессы необходимо даже для сбора функций: чтобы определить реальную способность организации выполнять какую-то деятельность (т.е. производственную функцию), нужно копнуть много подробней, поразбираться в процессах.
* * *
Принцип открытой модели (он же -- инженерии знаний): моделируя, никогда заранее не знаешь, что тебе будет важным. Поэтому средства моделирования должны позволять моделировать жизнь как таковую, а не только организацию в предписанных заранее терминах. Отсюда важна качественная метаонтология и софт по ее поддержке.