Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
272 |
●SIG в OMG — http://bawg.omg.org/ (стандарт VDML — это как раз их рук дело,
презентации http://bawg.omg.org/12-06-01.pdf)
●дискуссионная группа в LinkedIn — http://www.linkedin.com/groups/Business- Architecture-Perspectives-Transforming-Business-4379346
●разные вебсайты типа http://www.bainstitute.org/ (утверждают, что там комьюнити более 40тыс. членов, родственные сайты BPMinstitute.org и
SOAinstitute.org — ну, вы поняли).
●школы типа http://paularthurbodine.com/the-chicago-school-of-business- architecture/
●… и много чего другого, ссылки наверху даже не надводная часть айсберга, это махонький кусочек.
Архитектура предприятия (включая тамошнюю архитектуру деятельности) — это то, чем сегодня занимаются не столько стратеги, сколько выходцы из айтишников, включая "бизнес-аналитиков" (которые опять же, про "деятельность" как тип для повторяющихся в чём-то дел, но не про "бизнес" в предпринимательском смысле этого слова), тоже вырастающих из “бывших программистов”. Это часть enterprise engineering, которая в свою очередь часть systems engineering в части систем предприятий. А вот бизнес-архитектура — это часть менеджерской/стратегической деятельности, предпринимательство, а не инженерия.
Органиграмма
Органиграмма — это структура подразделений, декомпозиция предприятия, модульная его структура. Любую функцию предприятия должен кто-то поддержать: компоненты должны быть реализованы какими-то модулями. Если почту не отсылает канцелярия, то почту должна отсылать хозяйственная служба, или каждый работник сам. Как и любая архитектура, архитектура предпринятия считается созданной только тогда, когда вместе удалось совместить логическую архитектуру (требуемые деятельности — поведения, функции, процессы, практики, коммуникации) и физическую структуру, включающую обычно определение полномочий по распоряжению её физическими ресурсами. Традиционная “органиграмма” (organizational chart) как раз и выражает такую модель, при этом в ней обычно по понятным причинам перемешаны начальники и сотрудники (каждый начальник считается представляющим всех подчинённых ему сотрудников, он олицетворяет все его подразделения!):
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
273 |
В этом примере из Википедии (Departments in advertising agencies, http://en.wikipedia.org/wiki/Organizational_chart#mediaviewer/File:Deprtments_in_adv ertising_agencies.jpg) это хорошо видно — и невпопад сказанное слово system (указание на то, что “над департментальным разбиением люди думали, оно неслучайно”), и отождествление всего агентства с президентом, и одновременное указание названия службы и главы этой службы (”vice president creative services”) и название подразделений по их ведущим практикам (Research, Art/Copy). Это типично для органиграмм.
Много более запутанные структуры возникают при попытках отразить наличие множества совмещаемых между собой структур предпринятия-системы — например, гибридные диаграммы с показом соответствия функций и подразделений, а также диаграммы с показом наложенных друг на друга предпринятий (предпринятий-проектов и предпринятий-подразделений — так называемые “матричные” структуры).
Это всё требует специального рассмотрения, но понимание онтологической сути дела (множественности тематических описаний, иерархичности в каждом из описаний, физичности воплощения системы, отражённого в каждом из тематических описаний, отождествления темпоральных частей каждого из представлений в силу 4D extensinalism) позволяет довольно легко с этим разобраться.
Писцы против инженеров
Помним, что инженер — это тот, кто преобразует информацию и вещество, а не тот, кто записывает чужие мысли. Писарь или писец своих мыслей не имеют, они пишут под диктовку, или записывают в порядке учёта то, что видят.
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
274 |
Архитекторы предпринятия — это те, кто определяют деятельность и информационные системы предпринятия, кто имеет полномочия их менять! Если же это отставные программисты, которые назвали себя “аналитиками” и лишь зарисовывают известными им иероглифами тайных архитектурных языков наговорённые им “старшими товарищами” или подсмотренные ими в жизни архитектуры, то это не архитекторы. Это живые диктофоны, машинописное бюро, даром что пишут они специальными значками в моделерах.
Интересно, что “инженер предпринятия” — нет такого понятия, хотя “архитектор предпринятия” есть.
Неархитектурные описания предпринятия
Конечно, предпринятие моделируется довольно подробно в самых разных информационных системах — и отнюдь не все организационные, технологические, операционные/логистические описания являются архитектурными. Как и в случае архитектуры любой системы, а не только системы-предпринятия, отнесение описаний к архитектурным или неархитектурным зависит от решения архитектора: считает ли он, что при изменении этого решения придётся много чего переделывать-переорганизовывать-переосваивать в предпринятии, или же не так много. Что для одного покажется огромной работой и крайне важным (т.е. потянет на элемент архитектуры), другой выполнит “на автомате” и даже не заметит — и поэтому в архитектуру это не попадёт.
В предпринятии можно обнаружить самые разные описания деятельности — разного уровня детальности, для разных стейкхолдеров. Так, в ERP системе можно найти детальную (а не только архитектурную) информацию о том, какие именно ресурсы предпринятия наличествуют сейчас, и какие планируются на конкретную дату. В CRM-системе можно узнать не только архитектурные сведения про наличие важнейших стейкхолдеров, но и узнать совершенно неархитектурные данные о телефонах представителей каких-то групп стейкхолдеров.
Так, деятельность по «утренней продувке трубопровода низкого давления» можно обнаружить в крупном предприятии по-разному описанной минимум четырежды в самых разных подразделениях:
●в архитектуре предприятия, чтобы понимать, какие информационные системы её поддерживают, при этом архитектура предприятия часто будет разбита на два отдельно моделируемых куска:
●«бизнес-процессы» и регламенты работы будут отмоделированы в
"службе обеспечения качества" — ибо есть стойкое поверье, что описание процесса помогает именно качеству выполнения работ, и будет использован “процессный подход” (т.е. описана
Системноинженерное мышление |
TechInvestLab, 2 апреля 2015 |
275 |
последовательность шагов по продувке).
●архитектура информационных систем и аппаратного комплекса будут отмоделированы в «IT-службе» как IT-архитектура (а иногда и этот кусок бьют на отдельно архитектуру программного обеспечения и архитектуру компьютерного и связного оборудования).
●в описании метода/практики: что-то, близкое к описаниям ситуационной инженерии методов — какие рабочие продукты, инструменты, компетенции, отдельные операции нужно выполнять для обслуживания трубопровода низкого давления, для продувок трубопроводов и т.д.
●в обучающих “пакетах” (чаще всего в соответствии со стандартом SCORM) дистантного образования. Чаще всего это поддерживается HR-службой, именно в их задачах учить новых людей специфической для данного предпринятия деятельности.
●в системе документооборота, или системе процессного управления (BPM), или трекере ведения дел/выполнения поручений/документооборота (issue tracker, система adaptive case management), или системе проектного управления – для целей планирования работ и контроля их выполнения. Тут нужно обратить внимание, что все эти разные компьютерные системы позволяют планировать работы и отслеживать выполнение работ, опираясь на разные подходы к их описанию: issue tracker чаще всего связывается с “управлением делами” (case management) как одним из ярко выраженных представителей информационно-ориентированного/опирающегося на рабочие продукты подхода и не подразумевает прописывание цепочек операций, а вот система проектного управления чётко предпишет место и время этой работы среди других работ (это вариант “процессного подхода”).
Это всё системный подход
Все эти архитектурные и неархитектурные описания предпринятия, выраженные в текстах, компьютерных моделях/базах данных, регламентах, стандартах, приказах, протоколах, компьютерных программах (в коде программ, шаблонах отчётов баз данных и т.д.) представляют собой описания совместной деятельности людей, зачастую включая описания взаимодействия людей с информационными системами и производственным оборудованием и инструментами, а также описания работы информационных систем и производственного оборудования и инструментов. Эти разные описания удовлетворяют интересы разных заинтересованных сторон (stakeholders) предпринятия путём задействования разных тематических методов описания (viewpoints) для создания разных тематических групп описаний (views), включающих в себя отдельные более и менее формальные модели — разве что методы описания предпринятия/деятельности не похожи методы описания для “железных” или “программных” систем. Но вот то, как и что описывается в предпринятии-системе можно обсуждать примерно так же, как это можно обсуждать в отношении любой другой (программной или “железной”) системы. Это и есть мощь системноинженерного подхода: экономия мышления.
Всё, что говорилось про определение системы, оказывается верным и по отношению к предпринятию — например, необходимость управления конфигурацией/изменениями. Самые разные модели должны отражать одну и ту же планируемую и актуальную деятельность, версии разных моделей должны