Бизнес архитектура предприятия описывает как

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

Терминология

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

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

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

Что такое Архитектура предприятия ?!

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

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

Архитектура бизнеса. Общий обзор. Что это и зачем

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

Языки моделирования

• ArchiMate (ссылки) и архитектурный язык OpenGroup ArchiMate 2.0.

Критика архитектурных подходов

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

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

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

1. Органиграмма как описание делёжки орг.ресурсов в терминах статичного административного подчинения. Отделы, службы и прочие подразделения. Споры начинаются уже в том месте, когда нужно описать место начальника подразделения (начальник представляет собой всё подразделение в дереве органиграммы, или только входит в него? Ответ загадочен при нескольких уровнях, в разных системах моделирования ответы на этот вопрос разные). Когда же речь заходит о проектных организациях, то «органиграмма» оказывается нужна разве что для выпуска приказов на уход в отпуск, но не для организации работ.
2. Структуры целей организации: например, Business motivation model (OMG BMM), или голдраттовское Strategic TT).
3. Правила работы (Business rules), например OMG SBVR. «Если клиенту за 60, и он клиент больше года, то выдать скидку 5% при любой покупке».
4. Процессы
5. Процессы моделируется как цепочка поручений работы (напр., от запроса клиента до выполнения заказа), которая обязательно возращается (будь это внутренний «заказ», или «внешний», по письменному контракту, или без оного). Такой подход, основанный на теории коммуникативного действия (парадигмы речевых актов) позволяет моделировать «организационную сущность»: кто что кому поручает, саму «организованность людей». Представителем такого подхода к «процессам» является DEMO (Design процессов» как оргфункций. Проблема в том, что в оргфункциях нет даже времени, и функции — это не работы («конструкция»), это функции, и об этом забывают. На диаграммах IDEF0 (наиболее часто используемый стандарт изображения функций, раньше это называлось SADT) в верхнем левом углу рисуется не «самый первый шаг», а «самая важная функция на листе». То есть «процесса», как развертки времени, в IDEF0 нет.
6. Документирование процесса во времени. Процесс, как развертка во времени из выполняемых шагов, или workflow («ход работ») это и есть BPM (business process management) — IDEF3 в наиболее древней нотации, в России хорошо известна нотация EPC (event-driven process chain) из ARIS, а главным современным стандартом является OMG BPMN 2.0, который поддерживают все «движки процессов». Каждую неделю очередная фирма заявляет о поддержке BPMN 2.0 моделирования, и компьютерного исполнения процессов, отмоделированных в BPMN 2.0.
7. Практики жизненного цикла (по-английски это иногда processes, а иногда practices). Развертка во времени тут — это сам жизненный цикл (life cycle), понимаемый как «последовательность стадий», где каждая стадия соответствует примерной одинаковости состояния системы в ходе работ по ее инженерии (замысел, проектирование, сооружение, эксплуатация и т.д. — хоть спички, хоть организации, хоть космодрома). А вот в ходе стадий выполняются те или иные практики, причем подробно не рассказывается, как их делать «шаг за шагом», зато указываются руководства, требования к квалификации сотрудников, выполняющих эти практики, нужный инструментарий, используемые языки и нотации представления информации. Именно из описания жизненного цикла можно узнать, используются ли в работе «итерации», или никаких итераций нет, и «возврат на доработку» — это ЧП. Стандарты такого описания — OMG SPEM, ISO 24744 и вновь разрабатываемый подход SEMAT. Таким подходом занимаются люди, придерживающиеся ситуационной инженерии методов: их задача описать используемый в организации метод работы (а не, например, административное подчинение работников, или последовательность нажатия кнопок и принятия отдельных решений в ходе пошагового выполнения четкой инструкции).
8. Проекты.

Примеры архитектуры предприятия

• Autodesk — изменение организационной структуры
• Spotify — отряды и племена

Источник: sewiki.ru

Бизнес архитектура предприятия описывает как

Для того чтобы разобраться, какой должна быть архитектура информационных систем предприятия, попробуем вначале определить самые общие рамки данного понятия. С одной стороны, она должна отражать специфику, связанную с информационными технологиями, с другой – отражать бизнес-аспекты деятельности Предприятия.

«Корпоративная Архитектура» или «ИТ-Архитектура» являются терминами, которые специалисты очень часто используют, но при этом редко бывает ясно, что имеется в виду на практике. В реальности профессионалы в области информационных технологий, как уже отмечалось, понимают под архитектурой ИТ достаточно большой спектр понятий – структурированное семейство технических руководств, включая концепции, принципы, правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличие от них, профессионалы в области бизнеса не рассматривают этот вопрос как вопрос исключительно технологий. Наоборот, они разговаривают в терминах бизнес-моделей, бизнес-процессов и иногда – бизнес-архитектуры.

Рисунок 3.7 условно показывает эволюцию понятия «Архитектура предприятия». Каждый этап этой эволюции означал все более комплексный и всеобъемлющий подход к описанию и практике использования информационных технологий по обеспечению основной деятельности организации и, как результат, получение все более широкого спектра преимуществ.

Рис. 3.7. Эволюция термина «Архитектура предприятия»

В ранних работах ИТ-архитектура понималась в основном как Технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры были сосредоточены на формировании технологических стандартов и принципов, включая проведение инвентаризации различных технологий, используемых в организации. Такой подход позволяет добиться определенных частных выгод, связанных прежде всего с уменьшением стоимости закупок и эксплуатации информационных систем и уменьшением затрат на разработку приложений и обучение персонала. Однако он является заведомо ограниченным, так как не подразумевает ориентацию на решение бизнес-задач, таких как, например, формирование единых в масштабе компании данных по клиентам.

Следующей ступенью явилось понятие Корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). Стало понятно, что усилия по описанию архитектуры предприятия должны включать в себя описание архитектуры информации и архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем.

Корпоративная информационно-технологическая архитектура масштаба предприятия описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как элементы бизнеса связаны между собой.

Такой подход обеспечивает более эффективное взаимодействие различных структурных подразделений организации:

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

Получаемые преимущества носят, в основном, тактический характер.

Очевидным логическим шагом для эффективного описания существующих в организации процессов и планируемых изменений явилось, по мнению авторов [3.13], введение понятия архитектуры предприятия (Enterprise Architecture), которая объединяет корпоративную ИТ-архитектуру масштаба предприятия c бизнес-архитектурой и позволяет обеспечить достижение стратегических целей предприятия. В реальности это две стороны одной медали, которые связаны неразрывно. По сути дела, это должна быть одна архитектура предприятия, показывающая, как связаны друг с другом все элементы ведения бизнеса, что включает также все элементы, связанные с информационными технологиями. Заметим, что в данном контексте мы не различаем деятельность коммерческих и государственных организаций. Действительно, для описания деятельности и функций государственных организаций за рубежом очень часто используется термин «бизнес государственных организаций», что пока не принято в условиях российской действительности.

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

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

В графическом виде связь таких понятий, как бизнес-архитектура, корпоративная ИТ-архитектура и «архитектура предприятия», показана на рис. 3.8.

Источник: citforum.ru

Когда, кому и зачем нужна Архитектура Предприятия

Начал работать с одной компанией на тему архитектуры предприятия (Enterprise Architecture) и решил скорректировать своё представление об EA, сделать его понятней и проще. Обычно, датой рождения EA считают публикацию John A. Zachman «A Framework for Information Systems Architecture» 1987 года, хотя сам термин появлялся и в боле ранних работах.

Не смотря на то, что архитектура предприятия вещь довольно молодая, она успела уже подпортить себе репутацию. Как и любая другая архитектура, архитектура предприятия не имеет точного определения(см., например, 10 Definitions of Enterprise Architecture), но зато имеет большое число неудачных проектов (см. Gartner Identifies Ten Enterprise Architecture Pitfalls или 8 Reasons Enterprise Architecture Programs Fail). Обычно, после завершения проекта по разработке архитектуры предприятия можно услышать такую фразу: «Мы нарисовали все необходимые картинки, но не имеем ни малейшего представления как извлечь из этого хоть какую-то пользу». Поэтому, давайте проговорим все с самого начала.

А начнем мы издалека. Существуют две точки зрения на полезность информационных технологий. Согласно первой точке зрения информационные технологии позволяют повысить производительность труда, т.е. люди буду работать эффективнее, если их деятельность автоматизирована.

Существует и противоположная точка зрения, выраженная, например, в таких книжках как «Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом» Николаса Дж. Карра или «Чего хочет бизнес от IT» Терри Уайта. Удивительно то, что обе эти точки зрения правильные.

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

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

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

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

Следующая проблема заключается в том, что такую картинку нельзя подготовить впрок. (В этом месте архитекторы наговорят вам много заумных слов о различных точках зрения, представления, стейкхолдерах и консернах). Поэтому, отвечать на вопрос «Зачем мы делаем архитектуру предприятия?» надо с самого начала. Я позволю себе выделить три наиболее частых варианта ответа:

1. У нас есть стратегия, отвечающая на вопрос что мы хотим, но мы не знаем как это сделать.
2. У нас нет стратегии, но есть поток запросов на изменения, с которыми мы не можем справиться.
3. Информация о нашей деятельности противоречива и мы не успеваем разобраться в каждом конкретном случае, почему так происходит.

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

В первом случаем нам надо сделать из Стратегии –> План. Речь идет, в основном, о бизнес-стратегии. Выглядит она, обычно, как набор некоторых дельт между тем, что есть и тем чего хочется, выраженных в довольно простых показателях: доля рынка по выручке, объем клиентской базы и пр.

В общем, сами знаете, стратегия – это документ про завтрашних ёжиков, которыми предстоит стать сегодняшним мышкам. О том, что следует делать в этом случае, я напишу в отдельном сообщении, а пока несколько слов о том, как организовать такой процесс. На мой взгляд, организационная форма разработки архитектуры предприятия это проект, продолжительностью 8-16 недель.

Методология – TOGAF ADM и т.п. Ресурсы следует привлекать, в основном, внутренние. Результатами проекта являются: дорожная карта, список организационных и процессных изменений, риски, предложения по контролю и управлению движением в заданном направлении. В общем, все, что делается в традиционных проектах на фазе планирования и называется красивым словом мастер-план. Про команду такого проекта, набор активностей и артефактов – то же в одном из следующих сообщений.

Вариант номер 2: Change management. Вместо стратегии есть набор различных целей у различных бизнес-заказчиков. Одни должны сократить затраты, другие – время вывода на рынок новых продуктов и услуг, а третьим следует повысить степень удовлетворенности клиентов (см. Об архитектуре предприятия парой фраз). Все заказчики люди уважаемые и каждому надо помочь.

Но complexity уже выросло и как помочь всем одновременно мы не понимаем. Простой и неправильный способ выстроить всех в одну очередь с красивым названием, например «Единый лист приоритетов», а способ распределения задач по информационным системам – «Свободная касса!» – кто сумеет сделать быстрее и дешевле, тому и поручим.

Правильное решение – многофакторная классификация запросов, проще говоря – таксономия. Методология – в стиле Захмана. Организация – создание функционального подразделения. В предыдущей заметке Бизнес-аналитики – друзья, соседи или дальние родственники? я написал, что с появлением и принятием третьей версии BABOK эту работу смогут делать бизнес-аналитики. Но пока что не могут.

На текущий момент бизнес-аналитики умеют отвечать на вопрос «Что надо сделать?», а архитекторы решений на вопрос «Как это сделать?». Здесь же требуется ответ на вопрос «Зачем?», как это изменение связано с существующими продуктами и процессами, другими изменениями, приложениями.

Ну и напоследок ситуация, когда complexity уже победила и осознание этого есть у руководителей организации. Про те самые картинки, которых нет, когда они нужны, чтоб быстро разобраться в противоречивой проблеме и которые лежат совершенно никчемным грузом все остальное время. Эта ситуация – разговор об архитектурном репозитории.

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

Если у разработчика информационной системы нет простых, понятных и готовых к использованию APIs для получения типов клиентов, списка филиалов, функциональной орг.структуры и пр., то он обязательно нафигачит в своей информационной системе еще одну табличку, в которую заставит пользователей вводить данные этих справочников заново. Мне неизвестен ни один EA Tool одинаково пригодный и для демонстрации красивых картинок топ-менеджерам и одновременно обладающий врожденной интеоперабильностью для интеграции в реальные бизнес-приложения. Надеюсь, что такие, рано или поздно, появятся. И тогда вариант номер три превратиться в простой проект по внедрению информационной системы и последующему её использованию и развитию.

Продолжение (истории про архитектуру предприятия) следует!

Источник: mxsmirnov.com