работы, а не инженерные/технические практики сами по себе. То, из чего состоит мир (в том числе предприятие) обычно называют онтологией. Так что Ян Дитц (Jan Dietz) назвал свою книгу, объясняющую организацию с точки зрения теории речевых действий, “Enterprise Ontology”:

Архитектура предприятия

Jan Dietz не единственный, кто называет определение основных организационных решений онтологией предприятия (enterprise ontology). Основные решения, определяющее предприятие, называются архитектурой. Но компоненты, модули, размещения (и разные другие объекты) предприятия не так просто определить — поэтому люди обращают внимание на вопрос, “что это в нашем мире?”, т.е. от собственно архитектурного вопроса переходят к вопросу онтологическому.

Тут ещё нужно обратить внимание, что чаще в данном случае говорят про архитектуру предприятия (enterprise, у которого есть конкретный владелец, хотя иногда и коллективный — “акционеры”), и практически никогда про архитектуру предпринятия (endeavour, т.е. включающую и организацию отдельных проектов внутри предприятия, так и объединение нескольких предприятий для создания крупной системы). Но ничто не мешает определять архитектуру предпринятия по тем же принципам, что и архитектуру предприятия.

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

Архитектура предприятия — это то, как оно организовано. Как организовано (архитектура) — это кто над чем работает, и кому эта работа нужна. Предприятие всегда как-то организовано, хорошо или плохо. Организация (онтология, архитектура) предприятия невидима, но можно сделать вполне видимое архитектурное описание. Если есть архитектурное описание, то можно его использовать для обсуждения организации предприятия всеми стейкхолдерами предприятия (включая компетентных в вопросах организации людей) — и тогда

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

Архитектурное описание состоит из ряда диаграмм, по которым люди водят пальчиком, чтобы понять устройство организации и затем договориться, что нужно в организации поменять (обычно это верно и для любых других целевых систем: люди договариваются, что менять в системах, водя по архитектурным их диаграммам пальчиком). Архитектурное описание прежде всего — это инструмент для заключения “договорок” важных людей (заинтересованных сторон) по поводу важных аспектов организации работ. Не нужно путать организационные регламенты (в которых написано и важное, и не очень важное, и вообще много слов) с архитектурным описанием, в котором есть только самое-самое важное, зато выраженное максимально формально с целью избежать ошибок.

Опять же, большинство архитектурных диаграмм предприятия изображают какието процессы, процедуры, практики, проекты, функции, дела, деятельности, шаблоны проекта, экземпляры процессов, структуры подчинения. Нужно хорошо понимать, чем они все отличаются друг от друга, и что именно изображено на весьма и весьма похожих диаграммах. Мы возвращаемся к вопросу “что это” — говоря об объектах, из которых состоит деятельность, т.е. к онтологическому вопросу:

Подход Захмана к архитектуре предприятия

Одним из отцов-основателей архитектурного моделирования предприятий был John Zahman, который предложил подход к описанию архитектуры предприятия в виде матрицы. Он выпустил всего три версии такого описания. В третьей версии он ввёл подзаголовок “The Enterprise Ontology” (tm), подтверждая важность онтологического разбирательства с вопросом “из каких объектов состоит предприятие”, плюс намеренно исключил все упоминания информационных технологий (даже упоминание данных предприятия) — с его точки зрения, определять предприятие должны не программисты и администраторы базы данных, а полномочные топ-менеджеры (и если просто упомянуть что-то айтишное, то

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

Захман рассматривает какой-то жизненный цикл (от задумки до воплощения) элементов предприятия — reification transformation, и каждую стадию жизненного цикла связывает с определённой профессиональной ролью (стейкхолдером предприятия):

1.Scope context (identifications) — executive (business scope planners)

2.Business concepts (definitions) — business management (business concept owners)

3.System logic (representations) — architect (business logic designers)

4.Technology physics (specifications) — engineer (business logic builders)

5.Tool components (configurations) — technician (business components implementers)

6.Operations instances (instantiations) — users, The Enterprise (то есть уже индивид,

а не класс).

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

стадии работ стейкхолдеров (позиционеров-профессионалов). Онтологически предприятие по Захману состоит из следующих объектов:

1.Активы (inventory sets) — сущности и отношения.

2.Ход работ (process flows) — трансформации, и что на входе/выходе этих трансформаций. Захман, конечно, представитель процессного подхода.

3.Распределительные сети (distribution networks) — это операционное управление, логистические сети, руление потоками.

4.Ответственность/полномочия (responsibility assignments) — это и есть “организация”.

5.Временные циклы (Timing Cycles) — и обратите внимание, что "жизненный цикл" потихоньку уступает место "временнЫм циклам" (в том числе из-за давления

путаницы с case life cycle и project life cycle — они-то уж точно не про "всю жизнь от замысла до смерти", речь не о жизни и смерти, а о кусочке времени в этой жизни). Захман тут следует общей тенденции выделять временнОй аспект деятельности как отдельный от описания практик (т.к. слово “жизненный цикл” закрепляется не столько за описанием стадийности, сколько за описанием деятельности в части используемых в ходе этой деятельности практик работы). Так, в стандарте ситуационной инженерии методов ISO 24744 (это предшественник OMG Essence)

говорится: Stage-WithDuration/*Kind is, in turn, specialized into TimeCycle/*Kind (having as objective the delivery of a final product or service), Phase/*Kind (having as objective the transition between cognitive frameworks) and Build/*Kind (having as major objective the delivery of an incremented version of an already existing set of work products). TimeCycle/*Kind also holds a whole/part relationship to Stage/*Kind, allowing for the recursive composition of time cycles and other stages. Да, timing cycles и в ISO 24744 и у Захмана — это интервалы и моменты времени.

6. Деятельностное намерение (Motivation Intentions) — цели и средства, какие средства помогают достигать каких целей. Обратите внимание на то, что слово motivation обычно означает именно “мотивированное использование средств для достижения целей”, речь не идёт о “мотивации” в смысле “как заинтересовать когото поработать”.

Все эти объекты провязаны друг с другом через correspondence rules — как и предполагается в ISO 42010 (и слово rules тут не случайно. См. постинг http://www.ronross.info/blog/2011/09/06/where-are-your-business-rules- %E2%80%A6-in-a-big-p-process-dead-zone/ с разъяснениями — хотя я и понимаю,

что business rules и correspondence rules далеко не одно и то же, но смысл использования каких-то логических пропозиций при обсуждении связи моделей из разных тематических групп описаний остаётся).

Бизнес-архитектура

Вархитектуре предприятия часто выделяют определение того, как предприятие будет получать возможности — бизнес-архитектуру. Есть два подхода:

●бизнес-архитектура — это просто часть общей архитектуры предприятия в целом.

●бизнес-архитектуры отдельна от любых других определений предприятия.

Вбизнес-архитектуре особо выделяются описание сети пользы и бизнес-модели.

Сети пользы (value networks), позволяющие обсудить то, как добавляется польза от выстраивания каких-то цепочек обменов (value chain, value-added):

На основе согласованных между собой и объединённых восьми разных способов описания цепочек “добавления пользы” (ибо value не точно переводится как “стоимость”, т.е. “добавление стоимости” это слишком русско-марксистский перевод, а слово “ценность” уж слишком пафосно) был создан стандарт OMG VDML

(Value Delivery Modeling Language): http://www.omg.org/spec/VDML/

Альтернативый язык описания бизнес-архитектуры это OMG BMM (business motivation model, http://www.omg.org/spec/BMM/) — на этом языке, как и обычно при использовании слова motivation, говорится о бизнес-целях (goals) их связях со средствами их достижения (means):

Помним, что каждое слово (mission, vision, goal, objective и т.д.) каждый стандарт, каждый язык определяет по-своему! Всегда выясняйте, что именно имеет ввиду тот или иной стейкхолдер, когда говорит о “миссии” или “цели” или даже о “бизнесе” (так, отнюдь не все, произносящие слово “бизнес-процесс” задумываются именно о бизнесе, “как заработать деньги”!).

Бизнес-модель — это ответ на вопрос, “как вы зарабатываете деньги на том, что делаете”. Есть множество разных способов описания бизнес-модели (от текстовых эссе до моделирования в VDML). Но сейчас набрал популярность способ описания при помощи “порождения бизнес-модели” (business model generation — http://www.businessmodelgeneration.com) — книга, которая предлагает описывать бизнес-модель через ключевые деятельности, ключевых партнёров, ключевые ресурсы, структуру затрат, отношений с клиентами, сегментирование клиентов, предложение пользы, каналы продаж, источники доходов — и для удобства изображать всё это на определённого типа диаграмме-”холсте” (canvas, http://www.businessmodelgeneration.com/downloads/businessmodelgeneration_previe w.pdf, генератор .pdf файлов на разных языках -- http://www.bimoga.com/):

Бизнес-архитектура является традиционной вотчиной экспертов из McKinsey & Co, Bain & Co, Booz & Co, BCG, Palladium и прочих всеми ругаемых "консультантов не по делу". Именно это преподаётся в разных университетах в курсах MBA. Ключевые слова тут — "кому это нужно" (полезность, value), "справляемся ли мы с" (capability, над переводом думать и думать), "мы банда" (сообщество, кластер, фирма, рабочая группа) и т.д. Обратите внимание, как этот "предпринимательский" разговор (начинающийся с вопроса о том, кому всё это нужно и зачем мы всё это делаем) отличается от "работ/процессов", "акторов", "функций" и прочего привычного менеджерского и инженерного разговора, очень важного для организации эффективного производства (которое крайне важно, когда вы уже знаете, что производить, и вам нужно сделать подешевле и побыстрее). Кроме "побыстрее" и "подешевле", или даже "чтобы результат был качественный" (инженерный взгляд на вещи), бизнесменам нужно ответить на вопрос "зачем это вообще делать" (не технологическая причинно-следственная цепочка, а ценностная — нужна ли комунибудь затеваемая деятельность).

На сегодня есть:

●гильдия бизнес-архитекторов — http://www.businessarchitectureguild.org/

(главный продукт — Business Architecture Body of Knowledge, BIZBOK™, уже версия 3.0). Это новое объединение, организации всего пара лет, они делают акцент на то, что это "знание архитекторов от сохи".

http://www.linkedin.com/groups/When-Stars-Align-Business-Architecture- 4379346.S.130420677).