Просмотр исходного текста страницы Архитектура предприятия

'''Архитектура предприятия''' (business architecture, enterprise architecture) — план [[Предпринятие|предприятия]] (enterprise), который обеспечивает общее понимание организации  (основные организационные и логистические решения), стратегические цели и тактические требования.

== Терминология ==
* '''«[[Предприятие]]»''' является бизнес ассоциацией, состоящей из признанной совокупности взаимодействующих бизнес функций. Она способна работать как независимая, отдельная организация. Согласно такому определению, могут существовать предприятия в пределах предприятий. Например, организационная единица внутри общей корпоративной организации может быть рассмотрена как предприятие при наличии возможности независимого функционирования. Предприятие можно также рассматривать как «Расширенное предприятие (Extended Enterprise)»; это означает, что масштаб архитектуры предприятия может также включать взаимосвязи с внешними организациями. Такими как: поставщики, бизнес-партнеры и клиенты.
* '''«[[Архитектура]]»''' обеспечивает базовую концепцию. Она определяет и описывает платформу, необходимую предприятию для достижения своих задач и своего видения. Ее можно определить как: совокупность принципов, ориентиров, правил, моделей, стандартов и процессов, соответствующих требованиям бизнес стратегии и информации, направляющих выбор, создание и внедрение решений для будущих направлений бизнеса.

== Моделирование процессов в организации ==
Задача моделирования "процессов" чаще всего появляется в следующих случаях:
* '''"Чтобы было"''' - для отчетности инвесторам, в том числе формального доклада Совету Директоров, или для покупки сертификата серии [[ISO 9000]]. 
* '''Налаживание хода "регулярного менеджмента"''', когда делается попытка формализовать текущий оргбардак с целью провести хоть какую-то реорганизацию - т.е. для помощи менеджерам в принятии решений.
* '''При запуске нового сервисного продукта''' для договоренностей о том, как будет происходить работа множества разных служб в сложном "операционном дне": кто что кому передаёт, и во сколько, чтобы успеть для какого-нибудь важного производственного цикла.
* '''Создание какой-то информационной системы'''. Быстро выясняется, что система живёт не в вакууме, а в организации, и требуется отмоделировать организацию, что и делают через "процессы".

Наиболее сложным подходом является моделирование процессов организации и создание "[[ERP-система|корпоративной информационной системы]]" (под которой понимается всё, что хоть как-то относится к компьютерам, т.е. сети, сервера, рабочие станции, данные и разнообразный софт). Люди, которые занимаются информационной системой хоть сколько-нибудь больших масштабов быстро приходят к тому, что им нужна '''"архитектура предприятия"''' (enterprise architecture) и тут же попадают в практику [[системная инженерия|системной инженерии]]: рассматривается предприятие как [[система]], в котором информационная система является подсистемой, а само рассмотрение ведется в терминах [[Принцип множества групп описаний|множества групп описаний]].

== Подходы к описанию архитектуры предприятия ==
см. [[:Категория: Архитектурные подходы]]

== Языки моделирования ==
* [[ArchiMate]] ([http://ailev.livejournal.com/988360.html ссылки]) и архитектурный язык [http://pubs.opengroup.org/architecture/archimate2-doc/ OpenGroup ArchiMate 2.0].

== Критика архитектурных подходов ==
Опыт показывает, что все архитектурные подходы не слишком адекватны:
* группы описаний заставляют описать много лишнего, но не выявляют сущностного
* языки это сущностное не позволяют выражать

Поэтому продолжается поиск "сущностного" в организации, и адекватных описаний этого "сущностного". В последнее время выявлено несколько таких "сущностностей":
# '''Органиграмма''' как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то "органиграмма" оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
# '''Структуры целей организации''': например, Business motivation model ([[OMG BMM]]), или голдраттовское Strategic & Tactics Tree ([[S&TT]]).
# '''Правила работы''' (Business rules), например [[OMG SBVR]]. "Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке".
# '''Процессы'''
#* '''Процессы моделируется как цепочка поручений работы''' (напр., от запроса клиента до выполнения заказа), которая обязательно возращается (будь это внутренний "заказ", или "внешний", по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать "организационную сущность": кто что кому поручает, саму "организованность людей". Представителем такого подхода к "процессам" является [[DEMO]] (Design & Engineering Methodology for Organizations).
#* '''Процессы документируются'''. Поскольку организация должна выполнять разные функции, эти функции нужно [[документирование|задокументировать]]. Этим занимаются главным образом люди, проникнувшиеся [[ISO 9000]] и тамошнего понимания "процессов" как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции - это не работы ("конструкция"), это функции, и об этом забывают. На диаграммах [[IDEF0]] (наиболее часто используемый стандарт изображения функций, раньше это называлось [[SADT]]) в верхнем левом углу рисуется не "самый первый шаг", а "самая важная функция на листе". То есть "процесса", как развертки времени, в IDEF0 нет.
#* '''Документирование процесса во времени'''. Процесс, как развертка во времени из выполняемых шагов, или workflow ("ход работ") это и есть [[BPM]] (business process management) - [[IDEF3]] в наиболее древней нотации, в России хорошо известна нотация [[Event-Driven Process Chain|EPC]] (event-driven process chain) из [[ARIS]], а главным современным стандартом является [[OMG BPMN]] 2.0, который поддерживают все "движки процессов". Каждую неделю очередная фирма заявляет о поддержке BPMN 2.0 моделирования, и компьютерного исполнения процессов, отмоделированных в BPMN 2.0.
#* '''Практики жизненного цикла''' (по-английски это иногда processes, а иногда practices). Развертка во времени тут - это сам [[жизненный цикл]] (life cycle), понимаемый как "последовательность стадий", где каждая стадия соответствует примерной одинаковости состояния системы в ходе работ по ее инженерии (замысел, проектирование, сооружение, эксплуатация и т.д. - хоть спички, хоть организации, хоть космодрома). А вот в ходе стадий выполняются те или иные практики, причем подробно не рассказывается, как их делать "шаг за шагом", зато указываются руководства, требования к квалификации сотрудников, выполняющих эти практики, нужный инструментарий, используемые языки и нотации представления информации. Именно из описания жизненного цикла можно узнать, используются ли в работе "итерации", или никаких итераций нет, и "возврат на доработку" - это ЧП. Стандарты такого описания - [[OMG SPEM]], [[ISO 24744]] и вновь разрабатываемый подход [[SEMAT]]. Таким подходом занимаются люди, придерживающиеся [[SME|ситуационной инженерии методов]]: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
# '''Проекты'''.

== Примеры архитектуры предприятия ==
* [https://www.youtube.com/watch?v=mkJ-Uy5dt5g Autodesk] - изменение организационной структуры
* [https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ Spotify] - отряды и племена

== См. также ==
* [[Развитие]]
* [[Совершенствование]]
* [[ISO 15704]]

[[Категория:Концепции]]