Рассказ об организационном моделировании

Материал из PraxOS

(Различия между версиями)
Перейти к: навигация, поиск

Версия 11:07, 5 августа 2007

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

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

Организационная модель обладает следующими важнейшими свойствами:

  • она отражает реальное устройство организации (т.е. не вводит в заблуждение)
  • она является отчуждаемой от конкретных людей (т.е. записана, учтена)
  • существуют правила ее ведения, запрещающие произвольное внесение изменений

Организационная модель определяет основную информацию, которую нужно учитывать для организации (или так: учет соответствует организационной модели). Сама Организационная модель создается с использованием компьютерного организационного языка ( ОргЛана ), который в свою очередь отражает основные принципы и понятия организационной системы. Тем самым мы имеем цепочку:

  • приципы и практики организационной системы (например, организационной системы PraxOS), записанные обычными текстами
  • ОргЛан, понимаемый софтом организационной системы (например, софтом PraxOS)
  • организационную модель, записанную на ОргЛане (хранится софтом организационной системы и настраивает этот софт на условия конкретной организации).
  • симултрек -- систему учет организации, определяемую организационной моделью.

Организационная модель отвечает на вопросы "что, как, где, кто, когда, почему", но строго выборочным образом: если формализовывать и записывать 100% того, что известно об организации, и затем жестко этого придерживаться, то результирующая организация неминуемо будет косной и бюрократическо, быстро потеряет связь с реальностью, а менеджеры будут действовать не в соответствии с организационной моделью (т.е. свойство отражения реального устройства организации не будет выполняться). Гибкие методы требуют существенно ограничивать объем информации, содержащийся в организационной модели. Поскольку организационная система определяет состав организационной модели, то это противоречие ("записывать все, что обсуждается и все результирующие договоренности -- обсуждать все устно и не тратить время на записи") в явном виде учитывается в организационной модели.

История

До середины 80-х годов организационная модель до 1993 года традиционно представляла собой модель иерархической или матричной структуры подчиненности подразделений. Эти схемы подготоваливались в виде диаграмм на бумаге.

Примерно в это время прошла мода на бизнес-реинжиниринг (business reengineering), и стало уделяться много больше внимания процессам, проходящим через границы функциональных подразделений, и далее за границы организации, а также обеспечивающим эти процессы компьютерам. В 1993 году была учреждена WfMC (Workflow Management Coalition), в которой к языкам описания организационной структуры были добавлены языки описания хода работ как процессов.

Организационная модель стала связываться прежде всего с "процессным подходом": появились языки описания процессов семейства IDEFx, далее это направление было поддержано описаниями на UML и близко связанными описаниями на BPML (business process markup language). Эти описания стали использоваться для настройки корпоративного софта на условия конкретной организации. Структурные схемы подчиненности подразделений продолжали готовиться в формате, "понимаемом" только людьми -- в виде диаграмм на бумаге.

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

В то же время было понимание, что требуется одновременное системное представление разнородной информации о том, как устроена организация (каковы замыслы тех, кто ее строит -- какова "архитектура организации", enterprise architecture). Впервые целостное представление этого подхода было предложено в работах доктора Захмана в 1987г., и все это направление получило название "корпоративная архитектура". Предполагалось, что для представления корпоративной архитектуры в компьютере и последующего ее использования для настройки корпоративного софта будут использоваться различные стандарты -- и до настоящего времени группой OMG предложено 9 таких стандартов. Софт, в котором представляется такая архитектура, получил название моделлеров.

Быстро выяснилось, что язык (у нас -- ОргЛан), на котором Захман описывал архитектуру различных организаций, не соответствует различным организационным системам. Для разных принципов и организационных практик в организационной архитектуре (т.е. организационной модели) было важно выражать те или иные свойства, не предусмотренные Захманом. Поставщики программных средств стали предлагать метамоделлеры , позволяющие сначала описать те свойства организации, в терминах которых затем можно было описывать архитектуру организации (описание получило название framework, например "framwork Захмана" для первого из предложенных frameworks). Появилось множество конкурирующих между собой метамоделлеров, которые разделились на два больших класса:

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

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

Организационное моделирование вырастает из того направления, в котором модели главным образом использовались для организации коммуникации между людьми в организации. Если люди с учетом некоторых заранее оговоренных ими принципов договорятся по поводу того, как "на самом деле" (as is) устроена их организация, и как она должна быть устроена (to be), то дальше будет безопасно поддерживать эти договоренности корпоративным софтом. При этом совсем необязательно использование сегодняшних "тяжелых" софтверных стандартов, можно идти другим путем (например, использовать языки сверхвысокого уровня типа Smalltalk в качестве ОргЛана, а не работать с семейством 9 различных языков).