Архитектура предприятия — различия между версиями

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

Версия 19:27, 15 мая 2016

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

Моделирование процессов в организации

Задача моделирования "процессов" чаще всего появляется в следующих случаях:

  • "Чтобы было" - для отчетности инвесторам, в том числе формального доклада Совету Директоров, или для покупки сертификата серии ISO9000.
  • Налаживание хода "регулярного менеджмента", когда делается попытка формализовать текущий оргбардак с целью провести хоть какую-то реорганизацию - т.е. для помощи менеджерам в принятии решений.
  • При запуске нового сервисного продукта для договоренностей о том, как будет происходить работа множества разных служб в сложном "операционном дне": кто что кому передаёт, и во сколько, чтобы успеть для какого-нибудь важного производственного цикла.
  • Создание какой-то информационной системы. Быстро выясняется, что система живёт не в вакууме, а в организации, и требуется отмоделировать организацию, что и делают через "процессы".

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

Подходы к описанию архитектуры предприятия

Для описания архитектуры предприятий разработано много подходов (frameworks), определяющих различные наборы методов описаний (viewpoints):

Опыт показывает, что все эти подходы не слишком адекватны:

  • группы описаний заставляют описать много лишнего, но не выявляют сущностного
    • языки это сущностное не позволяют выражать

Поэтому продолжается поиск "сущностного" в организации, и адекватных описаний этого "сущностного". В последнее время выявлено несколько таких "сущностностей":

  1. Органиграмма как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то "органиграмма" оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
  2. Структуры целей организации: например, Business motivation model (OMG BMM), или голдраттовское Strategic & Tactics Tree (S&TT).
  3. Правила работы (Business rules), например OMG SBVR. "Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке".
  4. Процессы
    • Процессы моделируется как цепочка поручений работы (напр., от запроса клиента до выполнения заказа), которая обязательно возращается (будь это внутренний "заказ", или "внешний", по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать "организационную сущность": кто что кому поручает, саму "организованность людей". Представителем такого подхода к "процессам" является DEMO (Design & Engineering Methodology for Organizations).
    • Процессы документируются. Поскольку организация должна выполнять разные функции, эти функции нужно задокументировать. Этим занимаются главным образом люди, проникнувшиеся ISO 9000 и тамошнего понимания "процессов" как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции - это не работы ("конструкция"), это функции, и об этом забывают. На диаграммах IDEF0 (наиболее часто используемый стандарт изображения функций, раньше это называлось SADT) в верхнем левом углу рисуется не "самый первый шаг", а "самая важная функция на листе". То есть "процесса", как развертки времени, в IDEF0 нет.
    • Документирование процесса во времени. Процесс, как развертка во времени из выполняемых шагов, или workflow ("ход работ") это и есть BPM (business process management) - IDEF3 в наиболее древней нотации, в России хорошо известна нотация 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. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
  5. Проекты.

Сравнение подходов

Сравнение произвел Роджер Сешнс, Компания ObjectWatch, Inc. Май 2007 [1].

Каждой методологии присвоена оценка по каждому из критериев. Оценки выставляются следующим образом:

  1. Плохо работает в этой области
  2. Недостаточно хорошо работает в этой области
  3. Приемлемо работает в этой области
  4. Очень хорошо работает в этой области
Характеристика Описание характеристики ZF TOGAF FEA Gartner
Полнота таксономии насколько методология пригодна для классификации различных архитектурных артефактов 4 2 2 1
Полнота процесса насколько полно в методологии представлен пошаговый процесс создания архитектуры предприятия 1 4 2 3
Руководство по эталонным моделям полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология FEA 1 3 4 1
Практическое руководство насколько методология позволяет воплотить в жизнь умозрительное представление об архитектуре предприятия и сформировать культуру, в которой эта архитектура будет использоваться 1 2 2 4
Модель готовности насколько методология позволяет оценить эффективность использования архитектуры предприятия в различных подразделениях 1 1 3 2
Ориентированность на бизнес ориентирована ли методология на использование технологии для повышения ценности бизнеса, где ценность бизнеса определяется как снижение затрат или увеличение доходов 1 2 1 4
Руководство по управлению насколько методология полезна в понимании и создании эффективной модели управления для архитектуры предприятия 1 2 3 3
Руководство по разбиению полезность методологии в эффективном разбиении предприятия на отделы, что весьма важно при управлении сложностью 1 2 4 3
Наличие каталога насколько эффективно методология позволяет создать каталог архитектурных активов, которые можно будет использовать в дальнейшем 1 2 4 2
Нейтральность по отношению к поставщикам услуг вероятность того, что при внедрении методологии вы окажетесь привязанными к конкретной консалтинговой организации 2 4 3 1
Доступность информации количество и качество бесплатных или относительно недорогих материалов по данной методологии 2 4 2 1
Время окупаемости инвестиций продолжительность периода, в течение которого вы будете использовать данную методологию, прежде чем сможете построить на ее основе решения, обеспечивающие высокую ценность бизнеса 1 3 1 4
ИТОГО: 17 31 31 29