Не пытайтесь реформировать бизнес, если не понимаете его архитектуру. Бизнес архитектура


3. Бизнес – архитектура предприятия

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

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

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

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

  • Классическая или, другими словами, эталонная архитектура предприятия является идеальной моделью построения организации.

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

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

Построение бизнес - архитектуры начинается с описания контекста бизнес - архитектуры (рисунок 1.8.).

Общее видение бизнес - архитектуры предприятия включает анализ основных функций, цепочек создания добавленной стоимости (ValueLandscapeAnalysis), модели бизнес – сценариев (BusinessScenarioModels), анализ информационных связей и процессов (InformationValueChainAnalysis).

Рисунок 1.8. Контекст бизнес архитектуры

Основу архитектуры предприятия составляет: анализ бизнес событий (BusinessEventAnalysis), декомпозиция функций и процессов (Function/ProcessDecomposition), модель расположения (LocationModel), модель интеграции (IntegrationModel).

Бизнес - архитектура представляется в виде набора бизнес моделей. Бизнес модели – это «набор событий, связанных с бизнесом, в который вовлечены различные функции бизнеса, организационные единицы и активы предприятия».

В настоящее время существуют различные методики описания бизнес - архитектуры предприятия. Например, в работах Джона Захмана выделяются следующие типы бизнес моделей:

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

  • Динамические модели бизнес-процессов, включающие детализированное описание функционирования компании.

  • Организационная структура компании.

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

В рамках курсов «моделирование бизнес - процессов» как правило, рассматриваются такие инструменты, как декомпозиция функций и процессов; анализ бизнес событий; моделировании местоположения функций и процессов, модель интеграции функций и процессов.

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

В ходе проведения декомпозиции бизнес процессов необходимо выполнить следующие шаги:

  • определить границы анализа за счет рассмотрения основных функций предприятия;

  • выделить ключевые бизнес-процессы;

  • выделить дублирующие бизнес-процессы и точки их пересечения.

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

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

Модель интеграцииопределяет связь бизнес-процессов и бизнес - событий.

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

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

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

4. ИТ - архитектура предприятия

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

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

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

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

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

  • Enterprise Information Architecture (EIA) – информационная архитектура.

  • Enterprise Solution Architecture (ESA) – архитектура прикладных решений.

  • Enterprise Technical Architecture (ETA) – техническая архитектура.

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

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

studfiles.net

В чем заключается роль бизнес-архитектора в компании / Хабр

В последнее время стал часто встречать упоминание роли «Enterprise Architect». Решил покопаться в теме и наткнулся на немного сумбурное, но достаточно интересное обсуждение за круглым столом, что же такое или кто же такой «Enterprise Architect». Возможно, наши коллеги по цеху немного однобоко смотрят на роль «Enterprise Architect» исключительно со стороны IT, но обсуждение в любом случае полезное.

Обсуждение за круглым столом, модератором которого была Дэйна Гарднер, главный аналитик Interarbor Solutions, началось с утверждения:

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

Участники круглого стола, Жанна Росс, директор и ведущий исследователь MIT Center for Information Systems Research, Дейв Хорнфорд, главный специалист по бизнес-архитектуре Integritas Solutions и председатель The Open Group Architecture Forum, и Лен Фескенс, вице-президент направления по развитию навыков и способностей The Open Group, помогли сформулировать следующее:

— Как совершить преобразование ИТ из загадочного мастерства в развитую и структурированную науку и каким образом бизнес-архитекторы получают уникальную возможность предвосхитить концепцию бизнес-архитектуры и повлиять таким образом на гибкость бизнеса.

По мнению Лена Фескенса, бизнес-архитектура сейчас находится, с точки зрения массового сознания, на тех же позициях, что ныне полноценные профессии вроде медицины или юриспруденции 200-300 лет назад. Нет не только сертификации, но и само тело этой науки характеризуется, в первую очередь, весьма частным характером знаний:

— Мы сейчас на примерно той стадии, как были в свое время юристы, востребованность которых зижделась на секретных знаниях и процедурах, известных только им самим и из-за незнания которых у вас при мысли о судебном разбирательстве руки тряслись. Или вот врачи, которые говорят: «Обращайтесь в нашу клинику, потому что только мы разбираемся в лечении конкретно этой болезни».

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

Росс также отметила:

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

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

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

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

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

В продолжение дискуссии о проблеме перспективной ценности бизнес-архитекторов Фескенс заявил:

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

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

Росс предостерегла, что потенциальную ценность бизнеса далеко не всегда можно извлечь сразу же — обычно это происходит в перспективе:

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

Гарднер подвела черту под обсуждением следующим образом:

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

Роль бизнес-архитекторов в компаниях со временем меняется. Если 20 лет назад мало кто знал о том, чем же занимаются архитекторы, то сегодня многие компании считают архитектуру предприятия фундаментом его работоспособности. Обязанности архитекторов значительно изменились – от технических обязанностей (суперразработчик) до бизнес-архитектуры и лидерства. Эта профессия продолжает переживать изменения, и до сих пор остается загадкой, какой же курс она примет к концу текущего дня.

habrahabr.ru

А Вы знаете, что такое проектирование бизнес-архитектуры компании? : Энциклопедия результативного маркетинга

И нужна ли она Вам?

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

Что представляет из себя бизнес-архитектура?

проектирование бизнес-архитектуры

Многим руководителям и бизнес-аналитикам известно, что компания – очень сложная система. Чтобы правильно провести изменения в ней (будь то оптимизация деятельности, создание отдела или внедрение информационной системы), необходимо сделать качественный анализ взаимосвязей всех ее элементов. Как правило, дело это очень непростое.

Почему так происходит? Дело в том, что человеку достаточно трудно удержать в голове полную структуру компании со всеми элементами и связями, необходимыми для принятия верных решений, потому что компания, как система, слишком сложна для этого.

В чём же выход? Давайте представим бизнес в форме здания. Для строительства здания архитектору необходим его «чертёж». То же самое происходит и с компанией. Создание такого «чертежа» компании, в свою очередь, называется «бизнес-моделированием», а сам «чертёж» — «бизнес-архитектурой».

Проектирование бизнес-архитектуры компании

проектирование бизнес-архитектуры

Главным этапом строительства или улучшения системы является проектирование, в рамках которого система или ее изменения сначала моделируются. Проектирование позволяет избежать огромного количества ошибок! И чем сложнее система, тем более важен этот этап.

Бизнес — очень сложная система, поэтому его тоже необходимо проектировать.

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

проектирование бизнес-архитектуры

Бизнес-архитектура — это модель бизнеса, содержащая следующие элементы и их связи:

  1. Цели бизнеса.

  2. Бизнес-процессы.

  3. Организационную структуру.

  4. Информационные системы.

  5. Ресурсы и данные.

Зачем нужно бизнес-моделирование?

проектирование бизнес-архитектуры

Единственная цель бизнес-моделирования — создание эффективного бизнеса. При этом бизнес-моделирование решает следующие задачи:

  1. Дать детальное представление об устройстве компании всем заинтересованным лицам.

  2. Обеспечить создание оптимальной бизнес-архитектуры.

  3. Сформировать требования к информационным системам.

  4. Обеспечить сотрудников базой знаний, содержащей алгоритмы и методики работы.

Справляться с решением данных задач помогает система бизнес-моделирования Business Studio, разработанная ГК «Современные технологии управления», которая, в свою очередь, является партнёром Zolle.

проектирование бизнес-архитектуры

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

Более подробно о возможностях BS я расскажу Вам в следующей статье.

Если у Вас остались вопросы — задавайте их в комментариях.

Валерия Репина,бизнес-аналитик

Статьи в тему

blog.zolle.ru

Бизнес-урок 6. Архитектура бизнес-процессов Laravel 5

В предыдущей статье мы рассмотрели порядок разработки организационной концепции и подробно обсудили три ее элемента: (1) состав основных процессов верхнего уровня, (2) описание этих процессов и (3) карту процессов. Чтобы завершить обсуждение этой темы, рассмотрим следующие два элемента организационной концепции: (4) схема центров ответственности, (5) концептуальное описание центров ответственности. Но прежде необходимо дополнить состав наших бизнес-процессов. Дело в том, что мы рассмотрели только основные процессы компании, в то время как помимо них имеются обеспечивающие процессы, процессы развития и процессы управления.

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

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

Процессы управления

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

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

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

Следование этим принципам обеспечивает надежную основу для управления стратегией компании.

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

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

Управление заказами – пример процесса оперативного уровня. Это важнейший процесс для компаний, которые работают в режиме позаказного производства. В организационной концепции таких компаний необходимо описать основные принципы управления заказами, определив, как принимаются и обрабатываются заказы клиентов, как происходит планирование и мониторинг их выполнения, как измеряются и оцениваются показатели выполнения заказов.

Процессы развития

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

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

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

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

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

Концепция управления проектами развития содержится в материалах вебинара "Управление проектами. Суть дела". Используйте эти материалы для создания организационной концепции вашей компании.

Центры ответственности

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

  • Определив процессы, мы идентифицируем исполнителей и их функции.
  • Определив функции, мы идентифицируем компетенции, необходимые для исполнения этих функций.
  • Выделив компетенции, мы группируем их в центры ответственности – структурные подразделения компании.

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

Возвращаясь к примеру компании, предоставляющей услуги интернет-маркетинга, мы видим в ее структуре директора по маркетингу. На момент разработки организационной концепции в этой компании не было ни директора по маркетингу, ни процессов маркетинга. Но, когда в ходе проектирования основных процессов были определены процессы (1) выбора целевых сегментов рынка, (2) привлечения клиентов, (3) прямого маркетинга, стало ясно, что существует целая область деятельности, которая в компании отсутствует, и что для выполнения соответствующих функций необходимы специальные компетенции и особый центр ответственности.

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

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

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

Сколько времени необходимо для архитектурного проектирования компании? Компетентная и мотивированная управленческая команда может справиться с этим проектом за 2-3 месяца. Важно, чтобы в этой работе участвовали все топ-менеджеры компании. После создания архитектуры процессов, проект внедрения процессного управления может разветвиться, как дерево. Каждый топ менеджер возьмет на себя руководство проектированием и внедрением процессов в своей области ответственности. При этом все руководители будут действовать согласованно и слаженно на основе единой концепции, которая, как корни дерева, будет питать все ветви проекта.

iteam.ru

Бизнес-архитектура предприятия.

Элементы архитектуры предприятия

Архитектура информационных технологий и архитектура предприятия являются основными механизмами интерпретации и реализации целей организации через адекватные ИТ-инфраструктуру и системы.

Бизнес-модели описывают стратегию организации, структуры управления, требования, ограничения и правила, а также основные бизнес процессы, зависимости между ними.

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

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

Технологическая архитектура – описание ИТ-сервисов, которые требуются для реализации перечисленных выше трех других областей архитектура.

Архитектура предприятия – завершается физическими моделями, которые определяются технологиями, аппаратными и программными платформами, выбранными для реализации ИТ-сервисов.

Понятие «Архитектура предприятия» объединяет корпоративную ИТ-архитектуру масштаба предприятия с бизнес архитектурой и позволяет обеспечить достижение стратегических целей предприятия.

Бизнес-архитектура
Требования к информации Функциональные требования Операционные требования
↑↓ ↑↓ ↑↓
Архитектура информации ← → Архитектура приложений ← → Технологическая архитектура
ИТ
             

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

Основа бизнес-архитектуры:

· бизнес стратегия – собрание целевых установок, планов, руководящих принципов, политик, стандартов и процедур, поддерживающих реализацию этой стратегии. ( на ее основе стоится архитектура информационных технологий)

· Архитектура БП-определяет основные функциональные возможности организации.

· показатели эффективности.

· модели процессов (потоков работ)

· функциональные модели

· модели данных ресурсов

· временные модели типа диаграммы ганта

· модели причинно-следственных связей

Основное внимание при разработке должно уделяться картине в целом.

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

Дальнейшая детализация выполняется с использованием таких инструментальных средств как:

· Декомпозиция функций(процессов)

· Анализ бизнес-событий

· Моделирование местоположений выполняемых функций/процессов

· Модель интеграции функций и процессов

Декомпозиция бизнес-процессов состоит в идентификации под процессов, отделении границ основных организационных единиц.

Декомпозиция функций/процессов должна

· Задавать границы анализа/рассмотрения наиболее важных функций бизнеса

· Идентифицировать основные процессы обеспечивающие выполнение функций организации

· Идентифицировать меж функциональные процессы

· Идентифицировать пересечения и излишние функции /процессы.

 

Выбор аппаратно программной платформы.

Выбор той или иной аппаратной платформы и конфигурации определяется и рядом общих требований, которые предъявляются к характеристикам современных вычислительных систем. К ним относятся:

· отношение стоимость/производительность

· надежность и отказоустойчивость

· масштабируемость

· совместимость и мобильность программного обеспечения.

Отношение стоимость/производительность. Для сравнения различных компьютеров между собой обычно используются стандартные методики измерения производительности. Эти методики позволяют разработчикам и пользователям использовать полученные в результате испытаний количественные показатели для оценки тех или иных технических решений, и в конце концов именно производительность и стоимость дают пользователю рациональную основу для решения вопроса, какой компьютер выбрать.

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

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

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

Совместимость и мобильность программного обеспечения.

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

 

Концепция MRP

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

Основными целями автоматизированных MRP-систем являются:

· удовлетворение потребности в материалах, компонентах и продукции для планирования производства и доставки потребителям;

· поддержка уровней запасов не выше запланированных;

· планирование производственных операций, расписаний доставки, закупочных операций.

Шаги планирования

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

· Заказы (Orders) упорядочиваются, например, по приоритетам или по срокам отгрузки.

· Формируется объемный план-график производства (Master Schedule). Обычно он создается по группам продукции и может быть использован для планирования загрузки производственных мощностей.

· Для каждого изделия, попавшего в план-график производства, состав изделия «детализируется» до уровня заготовок, полуфабрикатов, узлов и комплектующих изделий.

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

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

Выход: План заказов, отчет изменений в плане заказов,отчет об «узких местах» плана планирования, отчёт о прогнозах

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

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

 

Стандарт MRP II.

CRP – система – совокупность компьютерных программ для составления детального календарного плана загрузки производственных мощностей, необходимого для реализации плана выпуска продукции на заданный период

Вход: План выписки продукции, технологический маршрут

Выход: план потребности в производственных мощностях.

MRP II система – совокупность компьютерных программ, обеспечивающих формирование плана производства продукции и детальных взаимосвязанных календарных планов эффективного использования ресурсов, необходимых для его (плана производства продукции) осуществления в рамках заданного периода.

Суть концепции: прогнозирование, планирование и контроль производства осуществляются по всему производственному циклу, от закупки сырья до отгрузки товара потребителю.

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

Задачи решаемые MRP II:

· планирование продаж и производства

· планирование материальных потребностей

· спецификации конечных продуктов

· планирование производственных мощностей CRP

· финансовое планирование

· управление спросом

· планирование и управление инструментальными средствами

· оценка результатов деятельности и т.д.

MRPII – центральная часть любой КИС на производственных предприятиях.

Преимущества MRP II

· улучшение обслуживания заказчиков за счет своевременного исполнения поставок;

· сокращение цикла производства и цикла выполнения заказа, следовательно, более гибкая реакция на спрос;

· сокращение незавершенного производства, т.к. работа не будет выдаваться, пока не потребуется “точно ко времени” для удовлетворения конечного спроса;

· значительное сокращение запасов, что позволяет более экономно использовать складские помещения и сокращает расходы на хранение;

· сбалансированность запасов – уменьшение дефицита и устаревших запасов;

· повышение производительности, т.к. людские ресурсы и материалы будут использоваться в соответствии с заказами с меньшими потерями; также возможно использовать анализ “что-если”, чтобы проверить, соответствует ли производство задачам предприятия по получению прибыли;

 

 

Концепции ERP.

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

ERP – это методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета при исполнении заказов клиентов в сферах производства, дистрибуции и оказания услуг.

ERP -системы ориентированы на работу с сетьюудаленных производственных и непроизводственных объектов (включают еще и механизм планирования потребностей при распределенных запасах (Distribution Requirements Planning).

Основа ERP-систем - принцип создания единого хранилища (репозитория) данных для всей, корпоративной информации.

ERP Система – набор компьютерных программ, реализующих методологию MRP II, дополненных средствами оптимизации управления производственными и сбытовыми подразделениями размещенными в разных странах.

Современная ИСУП соответствует концепции ERP, помимо блока реализуемого требованиям стандарта MRP, должна включать подсистемы:

· Управления цепочками поставок

· Конфигурации системы

· Интеллектуального анализа бизнеса

· Электронной коммерции

· И т.д.

Концепция ERP имеет такую важную черту как возможность глобального управления производством, товарами и услугами.

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

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

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

Достоинства

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

Реализуемая в ERP-системах система разграничения доступа к информации предназначена для противодействия как внешним угрозам, так и внутренним. Внедряемые в связке с CRM-системой и системой контроля качества, ERP-системы нацелены на максимальное удовлетворение потребностей компаний в средствах управления бизнесом.

Недостатки

· Небольшие компании не могут позволить себе инвестировать достаточно денег в ERP и адекватно обучить всех сотрудников.

· Внедрение является достаточно дорогим.

· Система может страдать от проблемы «слабого звена» — эффективность всей системы может быть нарушена одним департаментом или партнёром.

· Проблема совместимости с прежними системами.

 

 

Функциональные подсистемы ERP

· Планирование продаж и производства. Результатом действия блока является разработка плана производства основных видов продукции.

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

· Укрупненное планирование мощностей. Используется для конкретизации планов производства и определения степени их выполнимости.

· Основной план производства (план-график выпуска продукции). Определяется продукция в конечных единицах (изделиях) со сроками изготовления и количеством.

· Планирование потребностей в материалах. Определяются виды материальных ресурсов (сборных узлов, готовых агрегатов, покупных изделий, исходного сырья, полуфабрикатов и др.) и конкретные сроки их поставки для выполнения плана.

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

· Планирование потребностей в мощностях. На данном этапе планирования более детально, чем на предыдущих уровнях, определяются производственные мощности.

· Маршрутизация / рабочие центры. С помощью этого блока конкретизируются как производственные мощности различного уровня, так и маршруты, в соответствии с которыми выпускаются изделия.

· Проверка и корректировка цеховых планов по мощностям.

· Управление закупками, запасами, продажами.

· Управление финансами (ведение Главной книги, расчеты с дебиторами и кредиторами, учет основных средств, управление наличными средствами, планирование финансовой деятельности и др.).

· Управление затратами (учет всех затрат предприятия и калькуляция себестоимости готовой продукции или услуг).

· Управление проектами/программами.

· Управление персоналом.

 

Концепции ERP II.

В ноябре 2000 года на ежегодном ИТ-симпозиуме в Каннах компания Gartner объявила о разработке и начале продвижения на рынок новой концепции построения комплексных систем управления ресурсами предприятий ERP II. В данной концепции сделана попытка объединения концепций ERP, CRM (Customer Relationship Management, концепция управления взаимоотношениями с клиентами), SCM (Supply Chain Management, концепция управления цепочками поставок) и электронной коммерции в единую систему управления всеми (внутренними и внешними) ресурсами предприятия.

Помимо расширения и углубления функциональности и использования возможностей Интернета еще одной характерной чертой новой концепции ERP II является тенденция к специализации систем на отраслевых/промышленных сегментах. Прогнозируется снижение значимости универсальности решений для достижения конкурентных преимуществ на рынке.

Отличия от ERP:

· Изменена роль ERP-системы в деятельности предприятия.

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

· Расширена область применения ERP-систем.

o Если раньше основными потребителями ERP-систем были производственные и дистрибьюторские предприятия, то пользователями ERP II-систем должны стать предприятия всех секторов и сегментов рынка.

· Расширен функционал ERP-систем.

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

· Меняется характер процессов, протекающих в недрах ERP-системы.

o Внутренние и строго конфиденциальные процессы становятся внешними и открытыми. Все тайны корпоративной информации должны быть раскрыты.

· Существенным образом меняется архитектура ERP-систем.

o Закрытая монолитная платформа традиционных ERP-систем с весьма ограниченным выходом в Интернет (через отправку электронных писем или публикацию статистических отчетов на корпоративном Web-сайте) уступает место открытым, Web-ориентированным приложениям, построенным по принципам компонентных программных моделей.

· Данные, которые раньше генерировались и потреблялись самим же предприятием, должны стать доступными для всех членов бизнес-сообщества.

· Новые типы приложений, отвечающие за связь предприятия с внешним миром, такие как:

o программы для управления взаимоотношениями предприятия с ее клиентами/заказчиками (CRM - Customer Relationship Management),

o системы управления цепочками поставок (SCM - Supply Chain Management),

o системы электронного бизнеса/электронной коммерции (набор автоматизированных бизнес-процессов, осуществляемых с использованием Интернет-технологий).

· Расширение внутренней структуры - за счёт

o HRM (Human Resources Management) и

o KM (Knowledge Management) модулей.

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

KM-системы предназначены для управления корпоративными знаниями.Исторически эти системы создавались для накопления корпоративных знаний и использовались для внутреннего потребления. С развитием CRM-систем оказалось, что KM-системы идеально подходят для создания автоматизированных справочных бюро (Help Desks) и решения задач интеллектуального анализа информации по клиентам (выявление потребительских пристрастий, профилирование и пр.)

ERP   ERP II
Оптимизация процессов предприятия Роль Участие в цепочке, обеспечивающей увеличение стоимости, создание условий для совместной коммерции
Производство и дистрибуция Область деятельности Все сегменты и секторы
Производство, торговлю (дистрибуция) и финансовые процессы Функции Межотраслевые и отраслевые секторы, специфичные производственные процессы
Внутренние, спрятанные Тип процессов Связанные на внешнем уровне
С элементами, позволяющими работать с Web, закрытая, монолитная. Архитектура Интернет-ориентированная, открытая, компонентная
Генерируемые и используемые внутри предприятия Данные Предназначены как для внутреннего, так и для внешнего использования

 

 

 

Концепции Workflow.

WorkFlow-системы предназначены для комплексной автоматизации управления бизнес-процессами и являются развитием систем маршрутизации документов.

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

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

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

Согласно модели workflow-система должна включать следующие службы:

· систему визуального описания последовательности этапов (аctivities) и инфраструктуру для хранения шаблонов бизнес-процессов;

· сервис, обеспечивающий запуск и исполнение бизнес процессов;

· клиентское рабочее место для доступа к ручным функциям в ходе бизнес-процесса;

· средства мониторинга исполнения бизнес-процессов, а также средства, обеспечивающие взаимодействие различных workflow-систем между собой

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

Концепция workflow предполагает наличие центра управления.



infopedia.su

Как понимание архитектуры бизнеса помогает его перестраивать

Какой самый устоявшийся взгляд на бизнес? Бизнес – это деятельность, направленная на получение прибыли от производства и реализации продуктов и услуг. Шире: есть рынок, он охватывает ту или иную долю клиентов, которые имеют определенные потребности, и их нужно удовлетворить. Исходя из этого понимания, компании и создают свое «внутреннее убранство».

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

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

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

Поиск решения

Объясняя значимость и необходимость учитывать вышеуказанные стрессоры, чаще всего я сталкивался со следующим ответом: «Что вы нам тут рассказываете! Мы пять (10, 15) лет в бизнесе. Уже собаку съели на всех этих ваших проблемах! И ничего нового быть не может, у нас такая отрасль, здесь все так живут...». А потом происходит что-то неожиданное – и бизнес уходит в турбулентное пике. Хотя уменьшить негативный эффект было можно, и для этого требовалось заранее предусмотреть ряд мер, способствующих укреплению организации.

В попытках донести яснее потребность в разумном отношении к различным сторонам бизнеса, я начал исследовать то, как велись дела в древности. Полагая, что все наши взгляды пришли из далеких лет, и стоит именно там поискать необходимые рычаги для создания сильной и процветающей организации, я углубился в изучение мудрости, которая дошла до нас через столетия. Сенека, Тит Ливий, Плутарх, Аристотель, Витрувий, Макиавелли – эти и другие бессмертные мыслители навели меня на иное понимание делового предприятия. Так появилась идея о бизнес-архитектуре.

Концепция, которая будет представлена далее – альтернатива устоявшимся взглядам на форму организации и принципы управления ею. Она проста и доступна каждому. Для ее понимания не нужно получать MBA или создавать целый департамент аналитиков. Достаточно отступить на пару шагов в сторону от привычного взгляда и посмотреть на бизнес под иным ракурсом.

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

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

Каждая компания с момента своего зарождения формирует свою бизнес-архитектуру. Выглядит она следующим образом:

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

Увеличить изображение

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

Основание

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

Следующий блок – «Информация». Он включает в себе все, что требуется компании для принятия разумных бизнес-решений: информация об окружении (клиенты, конкуренты, партнеры), информация о внутренних процессах фирмы, накопленные знания и опыт. Все это собрано и структурировано посредством IT и простой документации в форме отчетов, регламентов, соглашений и прочих форм консолидации данных.

Далее следует блок «Люди». Он содержит представление о том, как выстроено взаимодействие сотрудников компании между собой через оргструктуру. Что собой представляет система стимулирования. Каким образом компания привлекает к себе людей, развивает их и удерживает внутри. Этот блок один из самых важных.

«Люди, оружие, деньги и хлеб – вот жизненная сила войны. Из этих четырех условий всего важнее первые два, ибо с людьми и оружием всегда можно достать денег и хлеба, но с одним хлебом и деньгами ты не достанешь ни людей, ни оружия», – это слова Фабрицио Колонна из трактата «О военном искусстве» Никколо Макиавелли. Если перевести их на современный язык бизнеса, то выходит, что без сотрудников невозможно создать процветающую компанию, даже если у вас много денег, и вы можете скупить половину рынка. Разумное управление людьми – один из основных постулатов концепции. Как бы это ни было очевидным, многие управленцы не придают этому должного значения, что в итоге выливается в массу проблем.

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

Процессы

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

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

Культура и интересы

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

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

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

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

Для целей бизнес-архитектуры эти интересы приведены к одному наименованию – корпоративные интересы. Они также имеют свою структуру, которая представлена иерархией организационных потребностей.

Пять уровней пирамиды организационных потребностей

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

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

Применение бизнес-архитектуры

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

И для целей изучения сформировавшегося бизнеса, и для создания нового есть определенный путь, которому стоит следовать, исходя из его рациональности, о которой я писал выше. Путь такой: ресурсы → информация → люди → рабочие процессы → корпоративная культура → интересы бизнеса. Схематически он показан на рисунке:

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

Увеличить изображение

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

Инструменты бизнес-архитектуры

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

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

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

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

Далее – люди. Инструменты оценки их организации широко представлены в открытом доступе. Важным направлением для исследования являются: оргструктура (ее уровни и их совместимость), процессы адаптации, система стимулирования и подготовки персонала.

Даже беглое исследование первых трех элементов дает возможность оценить базис, на котором стоит компания – сильна она, или ее положение в зоне риска.

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

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

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

Кроме потребностей, в этом разделе необходимо изучить интересы заинтересованных сторон – собственников, клиентов и партнеров. Инструментом здесь может стать интервью, маркетинговое исследование (самостоятельное!), рабочие встречи с партнерами по вопросам улучшения взаимодействия, изучение материалов в открытых источниках – отзывов и мнений.

Выводы

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

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

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

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

www.e-xecutive.ru

моделирование полезности (value) и справляемости с (capabilities): ailev

Бизнес-архитектура (business architecture) это совсем не то же самое, что "просто часть архитектуры предприятия" (enterprise architecture) с тамошней "архитектурой деятельности" (как правильно было бы переводить в большинстве околоайтишных случаев слово business, в буквальном его переводе "бизнес" явно имеющее предпринимательский смысл). Я бы честно переводил по-разному "архитектуру деятельности" в разных околоайтишных подходах типа Архимейт и "родную" business architecture с её лозунгом "начинайте с бизнес-модели". Традиционная (не-айтишная) бизнес-архитектура -- это "про всё важное" (помним про определение архитектуры!) для бизнеса, т.е.:-- предпринимательскую стратегию-- формулирование/документирование этой стратегии-- переход к выполнению сформулированной стратегии.

Бизнес-архитектура является традиционной вотчиной экспертов из 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.businessarchitectsassociation.org/ (главный продукт -- сертификация бизнес-архитекторов), это смычка университетов и консалтеров. Обратим внимание, что гильдия бизнес-архитекторов придерживается других взглядов на предмет, чем ассоциация (отчетливо это проявляется в репликах William Ulrich треда http://www.linkedin.com/groups/When-Stars-Align-Business-Architecture-4379346.S.130420677).-- SIG в OMG -- http://bawg.omg.org/ (стандарт VDML -- это как раз их рук дело, презентации http://bawg.omg.org/12-06-01.pdf, текст последней версии -- http://neffics.eu/wp-content/uploads/2012/06/12-05-02.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 в части систем предприятий. Распознать, с какой именно архитектурной школой мы имеем дело легко: айтишники мыслят прежде всего "процессно" (в крайнем случае -- сервисно), что позволяет относительно легко объяснять, как используется софт. Даже "антипроцессники" с трудом понимают, о чем вообще эти "бизнес"-архитекторы говорят (см., например, недоумения Max Pucher по поводу VDML -- http://www.linkedin.com/groups/VDML-ACM-DCM-2452802.S.88269024, он видит в capabilities и value chains главным образом motivation model, а затем быстро переходит к GRL-для-предприятий, собственно как и реализовано в "стратегии-для-айтишников" OMG BMM). Обратный ход от "стратегов" к айтишникам тоже делается -- вот, например, попытка: http://www.valuenetworksandcollaboration.com/advanced/processworkflowvna.html (опять же, обратите внимание упор на intangibles -- это явно не artifact-based!).

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

В "большой системной инженерии" (читай: военной системной инженерии) этот тренд на "бизнес-архитектуру" проявляется в резком сдвиге от обсуждения системы-как-сервисной к обсуждению всяческих capabilities в systems of systems engineering. Никакого "бизнеса" у военных, но вот самый верхний "стратегический" уровень заказа работ системным инженерам (acquisition) -- это заказ capabilities, а не systems или services. Заказывается поддержка возможности что-то делать, а не системы или сервисы этих систем. Это тот же тренд, что и в организациях, от которых требуют "конкурентоспособности", а не "поддержки сервиса по выигрышу конкуренции".

ArchiMate 2.0 (http://pubs.opengroup.org/architecture/archimate2-doc/) является неплохой попыткой гармонизации мира "бизнесОв" и "операционистов-процессников", но и там айтишники с их "сквозными процессами" на диаграммах являются главными, а все эти value и "стратегические" дополнения версии 2.0 только аннотируют основное процессное блюдо, а не являются полноценными главными объектами для архитектурной работы. То же можно сказать про все остальные enterprise architecture frameworks: их делали айтишники, менеджерам с ними плохо, они не про "бизнес", а больше про "операции".

Так что стоит задача в части архитектуры предприятия гармонизировать не просто несколько стандартов, а несколько совершенно разных групп описаний (viewpoints), адресующих совершенно разные интересы абсолютно разных заинтересованных сторон:-- бизнес-стратегов (VDML, гармонизирующий сам по себе довольно много, а также всяческие canvas типа http://businessmodelgeneration.com/)-- управленцев-операционщиков (BMM, ArchiMate 2.0 и т.д.. CMMN, Essence/SPEM 2.0 и BPMN 2.0 наряду со SBVR попадают сюда же). Все эти case management, critical chain -- отсюда. Организационный аспект (кто что кому может поручить, кто чем распоряжается -- DEMO) это тоже главным образом сюда, это "коммуникативная парадигма" процессов, хотя у Koskela на этот счёт это "инженерный" аспект дела (пункт 2.1. в http://ailev.livejournal.com/603806.html -- кто что кому обещает определяется содержанием работы прежде всего).-- содержательных людей (инженеров), которых прежде всего интересуют стандарты описания продукции и управления конфигурацией, а также выбор адекватной для объектов работы технологии. Удивительно, но про "артефакты" aka "объекты работы" (work products) в стратегических или операционных стандартах практически ничего сказать нельзя, ибо детализация объектов работ в тех описаниях не предусмотрена. Тут интересны новинки типа языков описания variability, а также тренда использования онтологий (типа ISO 15926 и ISO 15629) как средств отражения разнообразия. Действительно, видов объектов в разы и разы больше, чем задействующих их видов процессов, и само это разнообразие тут является проблемой. Ну, и инженеров волнуют неожиданные (ибо природа упруго сопротивляется) изменения, отсюда issue tracking и adaptive case management в связи с управлением конфигурацией.

Нужно чётко понимать, что эти взгляды на деятельность какого-то предпринятия (ценностный, потоковый и технологический) абсолютно разные, но это не отменяет задачу создать компактный язык (мета-модель, онтологию), позволяющий отражать договорки бизнесменов (кому выгодно и кто заплатит), менеджеров (как делать эффективно и кто будет делать) и инженеров (как и из чего получить годный результат). Я не первый раз об этом пишу (вот, например, в 2008г. я писал про "коскеловщину", ср. с пунктом 2 в http://ailev.livejournal.com/603806.html -- ведь ровно то же самое, хотя чуток другими словами. Собственно, это очередной пост в рамках сказанного в том давнем посте "А теперь нужно самому крепко подумать, и выдать обобщающий для всего этого месива фреймворк". Это, конечно, предмет проекта ПраксОС, praxos).

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

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

ailev.livejournal.com


Смотрите также