Референтные модели для бизнес архитектуры

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

Витрувий, архитектор времен Римской империи

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

В телекоммуникационных компаниях России давно уже прижилась практика применения референтной модели Enhanced Telecom Operations Map (eTOM), ориентированной на бизнес-процессы операторов услуг и других представителей индустрии информационно-коммуникационных технологий. Модель используется как шаблон для управления и реорганизации процессов, а так же для упрощения взаимодействия с партнерами и другими операторами услуг. В банковской же индустрии, к сожалению, на просторах России не применяют подход построения и анализа процессов с опорой на референтные модели, разрабатываемые международными организациями. Как небольшие микрофинансовые предприятия, так и крупные банки строят свои процессы, основываясь на опыте и ошибках своих сотрудников. Поисковый запрос о применении стандартизированных методик (международного уровня) для построения и анализа архитектуры предприятия в банковской индустрии в России выдает лишь одну компанию – поставщика IT-решений для финансового сектора (на момент написания данной статьи), принимающей участие как в разработке самого стандарта BIAN, так и при анализе своих решений. При этом часто встречается информация о том, что таких моделей попросту не существует, хотя это не так. Возможно, это связано с отсутствием в достаточной мере такого рода информации в русскоязычных специализированных (интернет-) сообществах.

Целью моей статьи является привлечение внимания к одной из таких моделей, а именно, к референтной модели BIAN, о которой пойдет речь ниже.

В своей статье для верхнеуровнего обзора стандарта BIAN я прибегну к частичному переводу документа «BIAN How-to Guide – INTRODUCTION TO BIAN V6.0» с акцентом на ключевые аспекты стандарта. Ознакомиться с документом можно по ссылке. Также при переводе я буду позволять себе делать отступления от оригинала и давать свои комментарии там, где посчитаю это необходимым.

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

1. Введение в BIAN (Banking Industry Architecture Network)

Banking Industry Architecture Network (BIAN) – это ассоциация архитекторов банков, поставщиков банковского программного обеспечения и провайдеров услуг с общей целью создания стандартной семантической среды банковских сервисов. По ожиданиям разработчиков BIAN классификация бизнес-функций и взаимодействий внутри любого банка в оформленном стандарте принесёт значительную пользу отрасли.

Основные документы, составляющие и дополняющие стандарт BIAN:

  • высокоуровневая карта сервисов «BIAN Service Landscape» — «Ландшафт сервисов»;
  • коллекция документов «BIAN How-to Guide»;
  • метамодель «BIAN Metamodel»;
  • определение бизнес-сценариев «BIAN Business Scenario»;
  • классификация на бизнес функции/области (сервис-домены) и их услуги (сервис-операции) «BIAN Service Domain Definitions»;
  • бизнес-словарь «BIAN business vocabulary»;
  • и объектная модель «BIAN Business Object Model».

Стандарт BIAN публикуется в репозитории с доступом на чтение к HTML версии, обратиться к нему можно через навигацию по веб-сайту BIAN bian.org. Кроме того, с каждой опубликованной версией стандарта BIAN ведется и выпускается сборник сопроводительных документов, включая серию руководств «How-to Guide».

Часто стандарт участниками ассоциации именуется как «BIAN Service Landscape». Более формальное название – «BIAN SOA Framework». Описание для разработчиков самого стандарта представлено во втором документе BIAN «How to Guide – Developing Content».

Содержание руководств «How-to Guide»

Документы «How-to Guide» описывают подходы работы со стандартом. В состав руководств на момент написания статьи входит:

  1. BIAN How-to Guide – INTRODUCTION TO BIAN V6.0
  2. BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0 – Документ ориентирован на бизнес-архитекторов и системных архитекторов. Здесь объясняются подходы для применения и реорганизации процессов с помощью стандарта BIAN.
  3. BIAN How-to Guide – DEVELOPING CONTENT V6.0 – Документ предназначен для участников рабочей группы BIAN. Объясняет принципы, шаблоны и инструменты, используемые при разработке стандарта.
  4. BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 – Целевой аудиторией документа являются технические специалисты, которым предстоит применение подходов BIAN при непосредственном внедрении (развертывании) систем.
  5. BIAN How-to Guide – SEMANTIC API V6.0 — Данный документ описывает, как стандарт BIAN может использоваться для разработки интерфейса прикладных программ (API). В ближайшее время планируется практическое руководство для разработчиков.

Каждый документ рассчитан на свою аудиторию.

В совокупности руководства в деталях раскрывают подход стандарта BIAN для внедрения базовой модели ИТ-инфраструктуры, создаваемой по стандартам сервис-ориентированной архитектуры (SOA).
Также стоит отметить, что совсем недавно стандарт BIAN рассматривался в контексте спецификации интерфейсов прикладного ПО (API) и адаптации его для микросервисных «архитектур».

Далее приводится краткий обзор по документам из серии «BIAN How-to Guide» под номерами 2, 3 и 4 из списка выше.

2. Принципы и методы проектирования (Design principles and techniques)

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

Схема ниже описывает ключевые идеи проектирования, используемые в стандарте BIAN:

Рисунок 1. Принципы и методы проектирования

С детальным описанием каждого блока на схеме можно ознакомиться непосредственно в BIAN How-to Guide – INTRODUCTION TO BIAN V6.0.

3. Разработка стандарта (Developing Content)

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


Рисунок 2. Разработка стандарта BIAN

С детальным описанием каждого блока схемы рисунка 2 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Также любой элемент BIAN описывается в самом же стандарте. Например, диаграмма классов базовых элементов стандарта BIAN представлена на рисунке ниже.


Рисунок 3. Разработка содержимого стандарта BIAN

4. Применение стандарта BIAN (BIAN How-to Guide – Applying the BIAN Standard)

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


Рисунок 4. Применение стандарта BIAN

С детальным описанием каждого блока схемы рисунка 4 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Экскурсия по стандарту

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

Карта сервисов «BIAN Service Landscape» иерархически сформирована из следующих представлений:

  1. Business Area (Бизнес – направление);
  2. Business Domain (Бизнес – область);
  3. Service Domain (Сервисный домен).

На карте самым «элементарным» компонентом является сервисный домен. Он же и считается неделимым.

Рассмотрим бизнес-направление «Поддержка бизнеса». В частности, посмотрим на бизнес-область «Направления бизнеса» с акцентом на сервисный домен (функцию) «Business Architecture» (Рисунок 5).


Рисунок 5. BIAN Service Landscape

При навигации по карте сервисов «BIAN Service Landscape» перейдем к обзору сервисного домена «Бизнес-архитектуры».


Рисунок 6. Обзор сервисного домена «Business Architecture»

Домен «Business Architecture» выделяет одноименный объект (Asset) «Business Architecture» с функциональным паттерном работы (pattern) над ним «Design». Артефактом будет являться спецификация «Specification».

Важно отметить, что любой домен на карте сервисов «BIAN Service Landscape» раскладывается на составляющие, описываемые в семантических терминах (таких как Asset Type, Functional pattern и др.) и переиспользуемые в других доменах.

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

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

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

(Обновление: здесь вы можете ознакомиться со второй статьей, посвященной BIAN).

Системный архитектор,
© Ирина Блажина

Источник

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

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

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

Существенно упростить и ускорить получение результатов, а, значит, сократить сроки и свое участие в проекте консультанту позволяет использование референтной модели.

Что такое референтная модель?

Референтная модель — концептуальная модель, формализующая рекомендованные практики ведения бизнеса в определенной области.

Отличительными признаками референтной модели являются:

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

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

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

Кому это нужно?

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

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

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

Здесь на помощь консультанту может прийти

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

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

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

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

  • быстро разработать рекомендации для реинжениринга;
  • разработать регламенты работ;
  • провести оптимизацию или стандартизацию процессов.

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

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

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

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

В ходе обследования консультант должен найти ответы на ряд вопросов:

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

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

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

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

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

Функциональная модель «как должно быть» будет отражать, в том числе, функции, которые должны быть автоматизированы.

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

Наличие на предприятии нескольких несвязанных систем автоматизации может привести:

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

Существует два варианта решения этой проблемы — замена существующих систем автоматизации комплексной системой планирования ресурсов предприятия (ERP-системой) и связывание существующих систем в единый программный комплекс с помощью интеграционного решения.

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

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

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

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

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

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

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

В общем случае, референтная модель торгово-промышленного предприятия позволяет:

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

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

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

Источник

Классификатор типовых процессов от APQC (American Productivity & Quality Center, Американского центра производительности и качества)

APQC

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

Да, такой перечень бизнес-процессов существует и называется он Process Classification Framework. На русский язык этот термин переводят по-разному: фреймворк классификации процессов, классификатор типовых процессов, структура классификации процессов и т.п.

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

Разрабатывает классификатор типовых процессов некоммерческая организация, признанный лидер в области бенчмаркинга, управления знаниями и оценки качества – American Productivity & Quality Center, Американский центр производительности и качества или просто APQC.

На сайте организации (https://www.apqc.org) приводится изречение её основателя, Джексона Грейсона, которое можно трактовать как миссию APQC:

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

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

  • Aerospace
  • Automotiv,
  • Broadcasting/Radio/TV/Cable/Medi,
  • Consumer Products/Packaged Good,
  • Energy and Utilit,
  • Financial Services/Bankin,
  • Petroleum/Oil/Ga,
  • Pharmaceutica,
  • Telecommunication

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

APQC

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

На верхнем уровне классификатор типовых процессов представляет собой 13 бизнес-процессов:

APQC

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

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

Помимо иерархического кода (Hierarchy ID), у каждого бизнес-процесса есть также уникальный код, не связанный с иерархией (PCF ID).

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

Например, для процесса 1.0 «Разработка видения и стратегии» предусмотрены две метрики:

  • 101337 «Количество новых бизнесов, запущенных на протяжении последних трёх отчётных периодов в соотношении к 1$ миллиарду выручки»
  • 101339 «Количество новых бизнесов, запущенных на протяжении последних трёх отчётных периодов в соотношении к 100$ миллионам затрат на НИОКР»

Общее количество процессов на всех пяти уровнях составляет 1621 (!).

Для примера, я приведу группу процессов 1.0 «Разработка видения и стратегии» полностью:

10002       1.0               Разработка видения и стратегии                                                  Y

17040       1.1               Определение концепции и долгосрочных перспектив бизнеса       N

10017       1.1.1            Оценка внешней среды                                                                  Y

19945       1.1.1.1         Определение конкурентов                                                             N

10021       1.1.1.2         Анализ и оценка конкурентов                                                        N

10022       1.1.1.3         Определение экономических тенденций                                     N

10023       1.1.1.4         Определение политического и нормативно-правового окружения  N

10024       1.1.1.5         Оценка технологических инноваций                                            N

10025       1.1.1.6         Анализ демографической ситуации                                             N

10026       1.1.1.7         Определение производственного процесса                                N

10027       1.1.1.8         Определение влияния на экологию                                              N

16790       1.1.1.9         Определение возможностей защиты и охраны интеллектуальной собственности           N

16791       1.1.1.10       Оценка возможностей приобретения интеллектуальной собственности  N

10018       1.1.2            Исследование рынка и выявление потребностей и пожеланий клиентов  N

10028       1.1.2.1         Проведение качественного/количественного исследования и оценки       N

19946       1.1.2.2         Фиксирование потребностей и пожеланий клиентов                  N

19947       1.1.2.3         Оценка потребностей и пожеланий клиентов                             N

10019       1.1.3            Оценка внутреннего окружения                                                    N

10030       1.1.3.1         Анализ характеристик предприятия                                             N

19948       1.1.3.2         Анализ организации работы на предприятии                              N

10031       1.1.3.3         Описание базового состояния текущих процессов                    N

10032       1.1.3.4         Анализ систем и технологий                                                         N

10033       1.1.3.5         Анализ финансового состояния                                                    N

10034       1.1.3.6         Определение ключевых компетенций                                         N

10020       1.1.4            Отслеживание спецификаций на сырье и материалы               N

19949       1.1.4.1         Формулирование стратегического видения                                 N

10035       1.1.4.2         Приведение заинтересованных сторон в соответствие со стратегическим видением N

10036       1.1.4.3         Информирование заинтересованных сторон о стратегическом видении   N

16792       1.1.5            Проведение возможной реструктуризации организации           N

16793       1.1.5.1         Определение возможностей для реструктуризации                  N

16794       1.1.5.2         Проведение комплексной оценки предприятия                          N

16795       1.1.5.3         Проведение анализа вариантов сделки                                       N

16796       1.1.5.3.1      Оценка параметров приобретения                                               N

16797       1.1.5.3.2      Оценка параметров слияния                                                         N

16798       1.1.5.3.3      Оценка параметров разделения                                                   N

16799       1.1.5.3.4      Оценка параметров отчуждения активов                                    N

10015       1.2               Разработка стратегии предприятия                                              N

10037       1.2.1            Разработка миссии организации                                                   N

10044       1.2.1.1         Расчёт и оптимизация плана отправки для точки доставки      N

10045       1.2.1.2         Формулирование миссии                                                                N

10046       1.2.1.3         Расчёт и оптимизация планов загрузки для точки доставки    N

10038       1.2.2            Определение и оценка вариантов стратегии достижения целей     N

10047       1.2.2.1         Определение вариантов стратегии                                              N

10048       1.2.2.2         Оценка и анализ последствий каждого варианта                       N

13289       1.2.2.2.1      Определение влияния на ключевые элементы операционной бизнес-модели, требующие изменения                                                                                                         N

13290       1.2.2.2.2      Определение влияния на ключевые аспекты технологии         N

16800       1.2.2.3         Разработка стратегии работы с корпоративными клиентами   N

16801       1.2.2.3.1      Разработка стратегии услуга-как-продукт                                  N

16802       1.2.2.4         Разработка стратегии работы с частными лицами                    N

16803       1.2.2.5         Разработка стратегии партнёрства или создания альянсов     N

16805       1.2.2.6         Разработка стратегии слияния/разделения/приобретения/выхода N

16806       1.2.2.7         Разработка стратегии инновации                                                 N

14189       1.2.2.8         Разработка стратегии устойчивого развития                              N

19950       1.2.2.9         Разработка стратегии глобальной поддержки                            N

19951       1.2.2.10       Разработка стратегии использования единого центра услуг   N

14197       1.2.2.11       Разработка стратегии бережливого производства/непрерывного улучшения                 N

19952       1.2.2.12       Разработка стратегии и методики инноваций                             N

10039       1.2.3            Выбор долгосрочной стратегии                                                    N

10040       1.2.4            Разработка стратегии поиска поставщиков                                N

10041       1.2.5            Создание организационной структуры                                        N

10049       1.2.5.1         Оценка широты и глубины организационной структуры           N

10050       1.2.5.2         Сопоставление специфичных ролей и анализ добавленной стоимости    N

10051       1.2.5.3         Разработка диаграмм активности ролей для оценки переходных процессов                 N

10052       1.2.5.4         Организация семинаров по изменению организации                 N

10053       1.2.5.5         Составление плана отношений между организационными единицами      N

10054       1.2.5.6         Взаимодействие с поставщиками по определению возможностей снабженческого характера                                                                                                 N

10055       1.2.5.7         Оценка влияния допустимых альтернатив на предприятие     N

10056       1.2.5.8         Переход к новой организации                                                       N

10042       1.2.6            Разработка и постановка целей организации                             N

19953       1.2.6.1         Определение целей организации                                                 N

19954       1.2.6.2         Фиксирование базовых значений показателей                           N

19955       1.2.6.3         Мониторинг достижения целей                                                     N

10043       1.2.7            Обработка/рассмотрение заявок                                                  N

19956       1.2.7.1         Анализ бизнес-подразделений стратегии                                   N

19957       1.2.7.2         Определение ключевых компетенций каждого подразделения      N

19958       1.2.7.3         Размещение/распределение заказов                                           N

19959       1.2.8            Разработка стратегии клиентского опыта                                   N

19960       1.2.8.1         Оценка клиентского опыта                                                            N

19961       1.2.8.1.1      Исследование/разрешение конфликтов                                      N

19962       1.2.8.1.2      Оценка клиентского опыта в точках взаимодействия               N

19963       1.2.8.1.3      Мониторинг/управление информацией о поставщиках              N

19964       1.2.8.2         Подготовка/анализ закупок и качества работы поставщиков   N

16612       1.2.8.2.1      Формулирование и управление профилями потенциальных клиентов      N

19965       1.2.8.2.2      Создание карты взаимодействия с клиентом                             N

19966       1.2.8.2.3      Формулирование единого взгляда на клиента со стороны организации    N

19967       1.2.8.2.4      Определение видения клиентского опыта                                  N

19968       1.2.8.2.5      Проверка на реальных клиентах                                                  N

19969       1.2.8.2.6      Приведение клиентского опыта в соответствие с ценностями бренда и стратегией организации                                                                                                      N

19970       1.2.8.2.7      Разработка стратегии контента                                                    N

19971       1.2.8.3         Планирование структур, отвечающих за взаимодействие с клиентом       N

19972       1.2.8.3.1      Определение необходимых компетенций                                   N

19973       1.2.8.3.2      Определение влияния на функциональные процессы              N

19974       1.2.8.4         Разработка плана мероприятий по развитию и реализации компетенций, необходимых для поддержки клиентского опыта                                                           N

18916       1.2.9            Доведение стратегий внутри и вне организации                         N

10016       1.3               Реализация и измерение хода реализации стратегических инициатив     N

10057       1.3.1            Разработка стратегических инициатив                                        N

19975       1.3.1.1         Определение стратегических приоритетов                                 N

19976       1.3.1.2         Разработка стратегических инициатив, основанных на ценностях бизнеса/клиентов      N

19977       1.3.1.3         Обсуждение с заинтересованными лицами                                N

10058       1.3.2            Оценка стратегических инициатив                                               N

19978       1.3.2.1         Определение ценности каждого стратегического приоритета для организации                 N

19979       1.3.2.2         Определение ценности каждого стратегического приоритета для клиентов                 N

10059       1.3.3            Выбор стратегических инициатив                                                N

19980       1.3.3.1         Расстановка приоритетов стратегических инициатив               N

19981       1.3.3.2         Доведение стратегических инициатив до подразделений и заинтересованных сторон      N

10060       1.3.4            Разработка мер на высоком уровне                                             N

19982       1.3.4.1         Выявление факторов, влияющих на стоимость предприятия   N

19983       1.3.4.2         Фиксирование базовых значений факторов, влияющих на стоимость предприятия               N

19984       1.3.4.3         Отслеживание изменений относительно базовых значений     N

19507       1.3.5            Реализация стратегических инициатив                                       N

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

Источник

В своей статье для верхнеуровнего обзора стандарта BIAN я прибегну к частичному переводу документа «BIAN How-to Guide – INTRODUCTION TO BIAN V6.0» с акцентом на ключевые аспекты стандарта. Ознакомиться с документом можно по ссылке. Также при переводе я буду позволять себе делать отступления от оригинала и давать свои комментарии там, где посчитаю это необходимым.

1. Введение в BIAN (Banking Industry Architecture Network)

Banking Industry Architecture Network (BIAN) – это ассоциация архитекторов банков, поставщиков банковского программного обеспечения и провайдеров услуг с общей целью создания стандартной семантической среды банковских сервисов. По ожиданиям разработчиков BIAN классификация бизнес-функций и взаимодействий внутри любого банка в оформленном стандарте принесёт значительную пользу отрасли.

Основные документы, составляющие и дополняющие стандарт BIAN:

  • высокоуровневая карта сервисов «BIAN Service Landscape» — «Ландшафт сервисов»;
  • коллекция документов «BIAN How-to Guide»;
  • метамодель «BIAN Metamodel»;
  • определение бизнес-сценариев «BIAN Business Scenario»;
  • классификация на бизнес функции/области (сервис-домены) и их услуги (сервис-операции) «BIAN Service Domain Definitions»;
  • бизнес-словарь «BIAN business vocabulary»;
  • и объектная модель «BIAN Business Object Model».

Стандарт BIAN публикуется в репозитории с доступом на чтение к HTML версии, обратиться к нему можно через навигацию по веб-сайту BIAN bian.org. Кроме того, с каждой опубликованной версией стандарта BIAN ведется и выпускается сборник сопроводительных документов, включая серию руководств «How-to Guide».

Часто стандарт участниками ассоциации именуется как «BIAN Service Landscape». Более формальное название – «BIAN SOA Framework». Описание для разработчиков самого стандарта представлено во втором документе BIAN «How to Guide – Developing Content».

Содержание руководств «How-to Guide»

Документы «How-to Guide» описывают подходы работы со стандартом. В состав руководств на момент написания статьи входит:

  1. BIAN How-to Guide – INTRODUCTION TO BIAN V6.0
  2. BIAN How-to Guide – DESIGN PRINCIPLES TECHNIQUES V6.0 – Документ ориентирован на бизнес-архитекторов и системных архитекторов. Здесь объясняются подходы для применения и реорганизации процессов с помощью стандарта BIAN.
  3. BIAN How-to Guide – DEVELOPING CONTENT V6.0 – Документ предназначен для участников рабочей группы BIAN. Объясняет принципы, шаблоны и инструменты, используемые при разработке стандарта.
  4. BIAN How-to Guide – APPLYING THE BIAN STANDARD V6.0 – Целевой аудиторией документа являются технические специалисты, которым предстоит применение подходов BIAN при непосредственном внедрении (развертывании) систем.
  5. BIAN How-to Guide – SEMANTIC API V6.0 — Данный документ описывает, как стандарт BIAN может использоваться для разработки интерфейса прикладных программ (API). В ближайшее время планируется практическое руководство для разработчиков.

Каждый документ рассчитан на свою аудиторию.

В совокупности руководства в деталях раскрывают подход стандарта BIAN для внедрения базовой модели ИТ-инфраструктуры, создаваемой по стандартам сервис-ориентированной архитектуры (SOA).
Также стоит отметить, что совсем недавно стандарт BIAN рассматривался в контексте спецификации интерфейсов прикладного ПО (API) и адаптации его для микросервисных «архитектур».

Далее приводится краткий обзор по документам из серии «BIAN How-to Guide» под номерами 2, 3 и 4 из списка выше.

2. Принципы и методы проектирования (Design principles and techniques)

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

Схема ниже описывает ключевые идеи проектирования, используемые в стандарте BIAN:

Рисунок 1. Принципы и методы проектирования

С детальным описанием каждого блока на схеме можно ознакомиться непосредственно в BIAN How-to Guide – INTRODUCTION TO BIAN V6.0.

3. Разработка стандарта (Developing Content)

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


Рисунок 2. Разработка стандарта BIAN

С детальным описанием каждого блока схемы рисунка 2 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Также любой элемент BIAN описывается в самом же стандарте. Например, диаграмма классов базовых элементов стандарта BIAN представлена на рисунке ниже.


Рисунок 3. Разработка содержимого стандарта BIAN

4. Применение стандарта BIAN (BIAN How-to Guide – Applying the BIAN Standard)

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


Рисунок 4. Применение стандарта BIAN

С детальным описанием каждого блока схемы рисунка 4 можно ознакомиться непосредственно в How-to Guide – INTRODUCTION TO BIAN V6.0.

Экскурсия по стандарту

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

Карта сервисов «BIAN Service Landscape» иерархически сформирована из следующих представлений:

  1. Business Area (Бизнес – направление);
  2. Business Domain (Бизнес – область);
  3. Service Domain (Сервисный домен).

На карте самым «элементарным» компонентом является сервисный домен. Он же и считается неделимым.

Рассмотрим бизнес-направление «Поддержка бизнеса». В частности, посмотрим на бизнес-область «Направления бизнеса» с акцентом на сервисный домен (функцию) «Business Architecture» (Рисунок 5).


Рисунок 5. BIAN Service Landscape

При навигации по карте сервисов «BIAN Service Landscape» перейдем к обзору сервисного домена «Бизнес-архитектуры».


Рисунок 6. Обзор сервисного домена «Business Architecture»

Домен «Business Architecture» выделяет одноименный объект (Asset) «Business Architecture» с функциональным паттерном работы (pattern) над ним «Design». Артефактом будет являться спецификация «Specification».

Важно отметить, что любой домен на карте сервисов «BIAN Service Landscape» раскладывается на составляющие, описываемые в семантических терминах (таких как Asset Type, Functional pattern и др.) и переиспользуемые в других доменах.

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

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

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

© Системный архитектор, Ирина Блажина



Источник

4.1.Понятия эталонной и референтой модели

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

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

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

Внастоящее время не существует однозначного понимания и применения терминов

«эталонная модель» и «референтная модель».

Наиболее логичным представляется терминология, представленная выше.

4.2.Эталонная 13-процессная модель процессов

Международная бенчмаркинговая палата Американского Центра производительности и качества (American Productivity & Quality Center, APQC) разработала перечень типовых бизнес-процессов предприятия в виде Структуры классификации процессов (Process Classification Framework).

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

В Структуру классификации процессов вошло 13 процессов, что дало название эталонной модели как «13-процессная эталонная модель».

Все процессы разделены но основные и вспомогательные. Процессы управления включены в состав вспомогательных.

Каждый из 13 основных и вспомогательных процессов, представленных на верхнем уровне описания эталонной модели, имеет еще 2-3 уровня детализации.

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

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

При использовании эталонной модели для конкретного предприятия структура процессов будет постепенно изменяться, наполняться связями, логикой, другими объектами.

Рис. 41. Классификация процессов (Process Classification Framework, PCF). APQC, 1991-2003

Ниже представлен фрагмент модели классификации бизнес-процессов Международной Бенчмаркинговой Палаты.

I. Основные процессы

Тема 2. Разрабатывать видение и стратегию

1.1.Определять концепцию бизнеса и долгосрочное видение

1.2.Развивать стратегию ведения бизнеса

1.3.Управлять стратегическими инициативами

Тема 3. Разрабатывать и улучшать концепцию продуктов и услуг 2.1. Разрабатывать продукты и услуги

Тема 4. Осуществлять маркетинговую деятельность и продавать продукты и услуги

3.1.Развивать стратегию маркетинга, распространения и определения каналов сбыта

3.2.Разрабатывать и управлять стратегией взаимодействия с потребителем

3.3.Управлять рекламой, ценообразованием, продвижением продукта

3.4.Управлять взаимоотношениями с партнерами и группами партнеров по продажам

3.5.Управлять конъюнктурой рынка и новыми каналами для сбыта

3.6.Вводить, обрабатывать, следить за выполнением — управлять заказами

Тема 5. Производить и распространять продукцию

4.1.Планировать потребности и приобретать необходимые ресурсы – планировать схему поставок

4.2.Обеспечивать материалами и услугами

4.3.Производить/ перерабатывать/ распространять продукт

4.4.Доставлять продукты / услуги потребителю

4.5.Управлять логистикой и хранением

Тема 6. Производить и распространять услуги

6.Управлять обслуживанием клиентов

6.1.Развивать стратегию по удовлетворению клиента / оказанию услуг клиентам

6.2.Собирать и управлять сведениями о клиенте

6.3.Управлять деятельностью по оказанию услуг клиентам

6.4.Осуществлять управление счетами

II. Процессы управления и вспомогательные процессы

7.Развивать персонал и управлять им

7.1.Разрабатывать и управлять планированием, политикой, стратегией в области управления персоналом

7.2.Набирать/ привлекать/ отбирать персонал

7.3.Развивать и обучать персонал

7.4.Поощрять сотрудников

7.5.Повышать и понижать сотрудников в должности

7.6.Управлять информацией о персонале

8.Управлять информационными технологиями и знаниями

8.1.Планировать управление информационной системой

8.2.Разрабатывать и поддерживать приложения

8.3.Управлять информационными технологиями/ инфраструктурой/операциями с хранилищами данных

8.4.Поддерживать сервис в сфере информационных технологий

8.5.Обеспечивать совместную работу

8.6.Внедрять новые технологии, используя принципы управления изменениями

9.Управлять финансовыми ресурсами

9.1.Планировать и управлять ведением бух.учета

9.2.Выполнять учет доходов

9.3.Вести общий учет и составлять отчеты

9.4.Управлять основными средствами

9.5.Оформлять платежную ведомость

9.6.Обрабатывать информацию по оплачиваемым счетам и затратам на компенсации

9.7.Управлять финансовыми операциями

9.8.Управлять внутренним контролем

9.9.Управлять налогами

10.Приобретать, создавать и управлять собственностью

10.1.Разрабатывать и строить сооружения

10.2.Управлять рабочими площадями и активами

10.3.Размещать рабочие места и оборудование

10.4.Управлять физическими рисками

10.5.Управлять основным капиталом

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

11.1.Определять воздействия на здоровье и безопасность персонала и окружающую

среду

11.2.Разрабатывать и выполнять программу по охране здоровья и защите окружающей среды

11.3.Обучать сотрудников

11.4.Осуществлять мониторинг и управлять программами по охране здоровья и защите окружающей среды

11.5.Обеспечивать соответствие деятельности установленным нормам и правилам

11.6.Управлять процессом улучшений

12.Управлять внешними связями

12.1.Выстраивать взаимоотношения с инвесторами

12.2.Управлять взаимоотношениями с правительством и промышленными структурами

12.3.Управлять взаимоотношениями с советом директоров

12.4.Управлять правовыми и внутренними вопросами

12.5.Управлять PR-программами

13.Управлять улучшениями и изменениями

13.1.Оценивать деятельность организации

13.2.Управлять оценками осуществления процессов

13.3.Управлять оценками знаний

13.4.Проводить бенчмаркинг

13.5.Управлять изменениями

4.3.Пример графического представления верхнего уровня 13процессной эталонной модели

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

Для описания процессов верхнего уровня использована модель типа VAD (Value-Added- Diagram), диаграмма цепочки добавленной стоимости (добавленного качества).

На диаграмме выделены основные и вспомогательные процессы эталонной модели в полном соответствии с документом «Структура классификации процессов».

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

Основные процессы

Изучение рынков

Разработка видения

и потребителей

и стратегии

Маркетинг и

Производство и

Послепродажная

работа с

продажи

поставка продуктов

потребителями

Производство и

поставка услуг

Разработка продуктов

и услуг

Вспомогательные и управляющие процессы

Управление

Управление

Управление

Исполнение программы

Управление

Управление

информационными

финансовыми и

человеческими

ресурсами и

материальными

управления охраной

внешними

улучшениями

ресурсами

окружающей среды

связями

и изменениями

технологиями

ресурсами

Рис. 42. Пример графического представления верхнего уровня 13-процессной эталонной

модели

4.4.Представление групп процессов 13-процессной эталонной модели

Группы процессов эталонной 13-процессной модели являются детализацией процессов верхнего уровня. В ARIS они представляются в виде диаграмм VAD, как и процессы верхнего уровня.

Первоначально группы процессов представляются в виде «деревьев процессов» в соответствии со списком процессов, приведенном в документе «Структура классификации процессов».

Диаграммы групп процессов «Управление улучшениями и изменениями» и «Производство и поставка продуктов» имеют вид «деревьев процессов», соответствующих исходному документу.

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

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

9 Первым выполняется процесс «Планирование управления информационными ресурсами» 9 Далее происходит параллельное выполнение 6 процессов, для которых выполнялось

планирование 9 Наконец, выполняется процесс «Оценка и аудит качества информации»

Основныепроцессы

Группа процессов

Изучениерынков

Разработкавидения

ипотребителей

истратегии

«Управление

продажи

Производствои

Послепродажная

поставкапродуктов

работас

Маркетинги

потребителями

информационными

Разработкапродуктов

Производствои

поставкауслуг

ресурсами и технологиями»

иуслуг

Вспомогательныеиуправляющиепроцессы

Управление

Управление

Управление

Управление

Исполнениепрограммы

Управление

Управление

информационными

финансовымии

человеческими

ресурсамии

материальными

управленияохраной

внешними

улучшениями

информационными

ресурсами

технологиями

ресурсами

окружающейсреды

связями

иизменениями

ресурсамии

технологиями

Разработкаи

развертывание

корпоративных

системподдержки

Внедрение

системконтроля

ибезопасности

Планирование

Управление

Оценкаи

управления

хранениеми

аудиткачества

информационными

получением

информации

ресурсами

информации

Управление

ресурсамии

сетевыми

операциями

Управление

информационными

услугами

Управление

комуникациями

информации

Группа

процессов

«Управление

улучшениями и

изменениями»

Управление

улучшениями

иизменениями

Измерение

Проведение

Проведение

Улучшение

Реализация

производительности

процессов

оценкикачества

бенчмаркинга

TQM

организации

исистем

Создание

Проведениеоценки

Разработкасредств

Порождение

Порождение

обязательств

системы

качестванаоснове

выполнения

приверженности

попроведению

измерений

внешнихкритериев

бенчмаркинга

TQM

улучшений

Измерениекачества

Проведениеоценки

Проведение

Реализация

Разработкаи

продуктов иуслуг

качестванаоснове

бенчмаркинга

непрерывных

реализация

организации

внутреннихкритериев

внутреннихпроцессов

улучшений

системTQM

Измерение

Проведение

Реинжиниринг

Управление

конкурентного

бизнес-процессов

жзненным

стоимости

бенчмаркинга

исистем

цикломTQM

качества

Измерение затрат

Измерение

временныхциклов

Измерение

производительности

Группа процессов «Производство и поставка продуктов»

Производствои

поставкапродуктов

Планированиеи

Преобразование

Транспортировкаи

Управлениеи

приобретение

ресурсовиисходных

доставкаматериалов

выполнение

необходимых

компоненотоввресурсы

ипродуктов

процессапоставки

ресурсов

Отбори

Разработкаи

Организация

Документированиеи

настройкапроцесса

отгрузки

мониторинг

сертификация

производства

продуктов

статусазаказа

поставщиков

Управление

Закупка

Разработкаграфика

Доставкапродуктов

наличиемпродуктов

производства

потребителям

средств

наскладе

производства

Закупка

Подвозматериалов

Установкапродукта

Обеспечение

материалови

иресурсов

употребителя

качества

продукта

комплектующих

Приобретение

Создание

Выявлениетребований

Планированиеи

подходящей

продукта

ктехобслуживанию

выполнение

технологии

Идентификацияи

техобслуживания

Овладание

Упаковка

Мониторинг

планирование

соответствующей

продукта

ресурсовдля

ограниченийпоохране

технологией

техобслуживания

окружающейсреды

Складированиеи

Предоставление

техобслуживания

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

конкретным

потребителям

Отборпродуктов

дляпоставки

Рис. 43. Представление групп процессов 13-процессной эталонной модели

4.5.Представление процесса «Управление улучшениями и изменениями» в виде группы процессов

Группа процессов «Управление улучшениями и изменениями» представлена в виде «дерева». Несмотря на упрощенное представление диаграммы, из нее видно, что для управления улучшениями и изменениями необходимо:

1.Измерять производительность организации;

2.Проводить оценку качества;

3.Проводить бенчмаркинг;

4.Улучшать процессы и системы;

5.Реализовать управление качеством по методу TQM. На каждой из этих ветвей «растут листья».

1.Для того, чтобы выполнить измерение производительности организации, необходимо: 9 Создать систему измерений 9 Измерить качество продуктов и услуг 9 Оценить стоимость качества 9 Оценить затраты 9 Измерить временные циклы

9 Измерить производительность

2.Для оценки качества необходимо:

9 Оценивать качество на основе внешних критериев

9 Оценивать качество на основе внутренних критериев

Ит.д.

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

А эталонная модель является хорошим помощником для детального описания процессов.

Управление

улучшениями и изменениями

Измерение

Проведение

Проведение

Улучшение

Реализация

производительности

процессов

оценки качества

бенчмаркинга

TQM

организации

и систем

Создание

Проведение оценки

Разработка средств

Порождение

Порождение

обязательств

системы

качества на основе

выполнения

приверженности

по проведению

измерений

внешнихкритериев

бенчмаркинга

TQM

улучшений

Измерение качества

Проведение оценки

Проведение

Реализация

Разработка и

продуктов и услуг

качества на основе

бенчмаркинга

непрерывных

реализация

организации

внутреннихкритериев

внутреннихпроцессов

улучшений

системTQM

Измерение

Проведение

Реинжиниринг

Управление

конкурентного

бизнес-процессов

жзненным

стоимости

бенчмаркинга

и систем

цикломTQM

качества

Измерение затрат

Измерение временныхциклов

Измерение

производительности

Рис. 44. Представление процесса «Управление улучшениями и изменениями» в виде группы процессов

4.6.Модернизированная классификация процессов (PCF). APQC, 2004

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

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

Такие изменения, по-видимому, будут происходить и в дальнейшем.

Рис. 45. Модернизированная классификация процессов (PCF). APQC

4.7.Эталонная модель оценки и аттестации процессов жизненного цикла программных средств и информационных систем по ИСО/МЭК ТО

15504

4.7.1. Термины и определения

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

Стандарт ИСО/МЭК ТО 15504 (ISO 15504), разработан на базе концепций CMM (Capability Maturity Model for Software – управление качеством разработки ПО на основании т.н. зрелости процессов).

Стандарт ИСО/МЭК ТО 15504 предоставляет основу для аттестации процесса жизненного цикла программных средств. Эта основа может быть использована организациями, занимающимися планированием, управлением, наблюдением, контролем и совершенствованием приобретения, поставки, разработки, эксплуатации, развития и поддержки программных средств. Стандарт состоит из 9 частей: ИСО/МЭК ТО 15504:1-9, взаимосвязь которых представлена на рисунке ниже. Часть 9 содержит словарь (глоссарий).

Рис. 46. Структура стандарта ИСО/МЭК ТО 15504

Стандарт ИСО/МЭК ТО 15504 предоставляет структурный подход к аттестации процесса жизненного цикла программных средств, проводящейся:

9организацией или от ее имени с целью выяснения состояния ее собственных процессов для их усовершенствования;

9организацией или от ее имени с целью определения пригодности ее собственных процессов для выполнения определенного требования или класса требований;

9организацией или от ее имени с целью определения пригодности процессов другой

организации для определенного договора или класса договоров. ИСО — Международная Организация по Стандартизации.

МЭК — Международная Электротехническая Комиссия.

Аттестация процесса (process assessment) — формальная оценка процесса жизненного цикла программного средства, принятого в организации, в соответствии с моделью, совместимой с эталонной.

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

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

Все вместе это позволяет расставить приоритеты при усовершенствовании процессов.

Стандарт ISO 15504:1-9:1998 — Оценка (аттестация) процессов жизненного цикла программных средств — предоставляет базу для реализации на предприятиях и в проектах процессов жизненного цикла ПС, регламентированных стандартом ISO 12207. Рубрикации основных процессов в этих двух стандартах подобны. В стандарте ISO 15504 модернизирован и несколько расширен состав организационных процессов, и более подробно детализированы работы во всех стандартизированных процессах жизненного цикла ПС. Поэтому оба стандарта целесообразно применять совместно при конкретизации жизненного цикла реальных проектов сложных комплексов программ.

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

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

Покупателям и заказчикам ПС выгодно использование аттестации процессов ЖЦ при определении зрелости поставщика, что:

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

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

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

9приведет к общему пониманию необходимости использования результатов аттестации для

усовершенствования процессов и оценки зрелости поставщика при прогнозировании характеристик ЖЦ ПС.

Для достижения устойчивых результатов в процессе развития технологии и организации управления жизненным циклом ПС в стандарте ISO 15504 рекомендуется методология обеспечения качества сложных программных средств СММ (Capability Maturity Model) — система и модель оценки зрелости комплекса, применяемых технологических процессов. Модель основана на формализации и использовании пяти уровней зрелости технологий поддержки ЖЦ ПС, которые определяют потенциально возможное качество и безопасность создаваемых комплексов программ. Эти уровни зрелости характеризуются степенью формализации, адекватностью измерения и документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов и инструментальных средств автоматизации работ, наличием и полнотой реализации функций системой обеспечения качества технологических процессов и их результатов. Они, в некоторой степени, подобны семи оценочным уровням доверия в стандарте ISO 15408-3.

Уровень 1 Начальный. Наиболее массовые разработки проектов ПС характеризуются относительно небольшими объемами программ в несколько тысяч строк, создаваемых несколькими специалистами. Они применяют простейшие не формализованные технологии с использованием типовых инструментальных компонентов операционных систем. Основные процессы ЖЦ ПС на этом уровне не регламентированы, выполняются не совсем упорядоченно и зависят от некоординированных индивидуальных усилий специалистов. Успех проекта, как правило, зависит от энергичности, таланта и опыта нескольких руководителей

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

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

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

иквалификация специалистов.

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

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

Уровень 5 Оптимизируемый. Дальнейшее последовательное совершенствование и модернизация технологических процессов ЖЦ ПС для повышения качества их выполнения и расширение глубины контроля за их реализацией. Одна из основных целей этого уровня сокращение проявлений и потерь от случайных дефектов

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

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

Инженерная категория (ENG) включает виды деятельности, которые непосредственно определяют, реализуют или поддерживают программный продукт и документацию на него.

Управленческая категория (MAN) определяет все аспекты управления проектом и координацию использования его ресурсов в ЖЦ или при предоставления услуг, удовлетворяющих заказчиков ПС. Вспомогательная категория (SUP) виды деятельности, которые обеспечивают реализацию и совершенствование основных процессов, а также поддерживают производительность и качество процессов в проекте. Организационная категория (ORG) определяет цели предприятия-разработчика и формирует методы управления, необходимые для повышения качества использования ресурсов и всего ЖЦ ПС.

Девять частей стандарта ISO 15504, посвящены различным базовым задачам, относящимся к оцениванию, аттестации и совершенствованию зрелости процессов ЖЦ ПС на предприятии. Стандарт ISO 15504 связан с другими международными стандартами, он дополняет некоторые стандарты и другие модели для оценки зрелости, качества и эффективности предприятий и процессов ЖЦ ПС. Этот стандарт преследует ту же цель, что

исерия стандартов ISO 9000:2000 — формализации и обеспечения уверенности в достаточности системы управления качеством продукции у поставщика. Одновременно предоставляется потребителям основа для оценки того, обладают ли потенциальные поставщики производственными возможностями, отвечающими потребностям заказчиков. Аттестация процессов дает пользователям возможность оценивать зрелость процессов обеспечения ЖЦ ПС по непрерывной шкале таким образом, что эти оценки сопоставимы и повторяемы. Стандарты ISO 12207 и ISO 15504 дополнительно поддерживаются группой стандартов, детализирующих отдельные этапы и процессы жизненного цикла, которые целесообразно применять для обеспечения функциональной безопасности и высокого качества сложных программных средств:

ISO 12182:1998. ИТ. Классификация программных средств.

ISO 9126:1991. ИТ. Оценка программного продукта. Характеристики качества и руководство по их применению. ISO 14598-1-6:1998-2000. Оценивание программного продукта. Ч.1. Общий обзор. Ч. 2. Планирование и управление. Ч. 3. Процессы для разработчиков. Ч.4. Процессы для покупателей. Ч.5. Процессы для оценщиков. Ч. 6. Документирование и оценивание модулей.

ISO 14756: 1999. ИТ. Измерение и оценивание производительности программных средств компьютерных вычислительных систем.

ISO 12119:1994. ИТ. Требования к качеству и тестирование.

ISO 15846:1998. ТО. Процессы жизненного цикла программных средств. Конфигурационное управление программными средствами.

ISO 14764: 1999. ИТ. Сопровождение программных средств.

ISO 15910:1999. ИТ. Пользовательская документация программных средств. ISO 6592:2000. ОИ. Руководство по документации для вычислительных систем.

ISO 9294:1990. TO. ИТ. Руководство по управлению документированием программного обеспечения.

4.7.2. Категории процессов эталонной модели ИСО/МЭК ТО 15504

ИСО/МЭК ТО 15504-2 определяет эталонную модель процессов и их зрелости, которая формирует базис для любой модели, используемой для аттестации процессов. Эталонная модель содержит двумерный подход к оцениванию зрелости процессов — одно измерение определяет процессы, подлежащие аттестации, другое описывает шкалу для измерения т.н. зрелости процессов.

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

(Зрелость процесса – способность процесса достигать требуемой цели)

Рис. 47. Категории процессов и атрибуты

4.7.3. Эталонная модель процессов по ИСО/МЭК ТО 15504 (верхний уровень)

Основные

процессы

Категория CUS

Категория ENG

«Потребитель —

Представление

Инженерная

поставщик»

основных процессов

на верхнем уровне

CUS.1

ENG.1

эталонной модели

Приобретение

Разработка

Основные

процессы

CUS.2

ENG.2

поставщик»

Инженерная

Категория CUS

Категория ENG

«Потребитель —

Поставка

Сопровождение

Приобретение

Разработка

CUS.1

ENG.1

CUS.2

ENG.2

системыи

Поставка

Сопровождение

требований

системыи

программныхсредств

программныхсредств

CUS.3

Выявление

CUS.3

CUS.4

Эксплуатация

Вспомогательные

Организационные

Выявление

процессы

процессы

требований

Категория SUP

Категория MAN

Категория ORG

Вспомогательная

Управленческая

Организационная

SUP.1

SUP.2

MAN.1

Документиро-

Управление

Административное

ORG.1

ORG.2

вание

конфигурацией

управление

Организационные

Усовершенство-

установки

вание

SUP.3

SUP.4

MAN.2

ORG.3

CUS.4

Обеспечение

Верификация

Управление

ORG.4

качества

проектами

Административное

управление

Создание

SUP.5

SUP.6

MAN.3

инфраструктуры

кадрами

Повторное

Эксплуатация

Проверка

Совместные

Управление

Измерения

соответствия

проверки

качеством

ORG.5

ORG.6

SUP.7

SUP.8

MAN.4

использование

Аудит

Разрешение

Управление

проблем

рисками

Вспомогательные

Организационные

процессы

процессы

Рис. 48. Эталонная модель процессов по ИСО/МЭК ТО 15504 (верхний уровень)

4.7.4. Эталонная модель по ИСО/МЭК ТО 15504 (вспомогательные процессы, верхний уровень)

Основные

Категория SUP

процессы

«Потребитель —

Инженерная

Категория CUS

Категория ENG

Вспомогательная

поставщик»

Приобретение

Разработка

CUS.1

ENG.1

CUS.2

ENG.2

Поставка

Сопровождение

системыи

CUS.3

программныхсредств

Выявление

требований

CUS.4

SUP.1

SUP.2

Эксплуатация

процессы

процессы

Вспомогательные

Организационные

Документиро-

Управление

Категория SUP

Категория MAN

Категория ORG

Вспомогательная

Управленческая

Организационная

вание

конфигурацией

Документиро-

Управление

Административное

ORG.1

ORG.2

SUP.1

SUP.2

MAN.1

вание

конфигурацией

управление

Организационные

Усовершенство-

установки

вание

SUP.3

SUP.4

MAN.2

Обеспечение

Верификация

Управление

ORG.3

ORG.4

качества

проектами

Административное

управление

Создание

инфраструктуры

SUP.5

SUP.6

MAN.3

кадрами

SUP.3

Проверка

Совместные

Управление

SUP.4

соответствия

проверки

качеством

ORG.5

ORG.6

Измерения

Повторное

SUP.7

SUP.8

MAN.4

использование

Разрешение

Управление

Обеспечение

Аудит

проблем

рисками

качества

Верификация

Представление

SUP.5

SUP.6

вспомогательных

Проверка

Совместные

процессов на верхнем

соответствия

проверки

уровне эталонной модели

(категория SUP)

SUP.7

SUP.8

Разрешение

Аудит

проблем

Рис. 49. Эталонная модель ИСО/МЭК ТО 15504 (вспомогательные процессы, верхний уровень)

4.7.5. Эталонная модель по ИСО/МЭК ТО 15504 (организационные процессы, верхний уровень)

Основные

процессы

Категория MAN

Категория ORG

«Потребитель —

Категория ENG

Категория CUS

поставщик»

Инженерная

Управленческая

Организационная

CUS.1

ENG.1

Приобретение

Разработка

CUS.2

ENG.2

Поставка

Сопровождение

системыи

CUS.3

программныхсредств

Выявление

требований

MAN.1

CUS.4

Эксплуатация

Административное

ORG.1

ORG.2

Вспомогательные

Организационные

процессы

процессы

управление

Организационные

Усовершенство-

Вспомогательная

Управленческая

Организационная

Категория SUP

Категория MAN

Категория ORG

SUP.1

SUP.2

MAN.1

установки

вание

Документиро-

Управление

Административное

ORG.1

ORG.2

вание

конфигурацией

управление

Организационные

Усовершенство-

установки

вание

SUP.3

SUP.4

MAN.2

MAN.2

Обеспечение

Верификация

Управление

ORG.3

ORG.4

качества

проектами

Административное

управление

Создание

SUP.5

SUP.6

MAN.3

инфраструктуры

кадрами

Повторное

Управление

ORG.3

Проверка

Совместные

Управление

Измерения

соответствия

проверки

качеством

ORG.5

ORG.6

ORG.4

SUP.7

SUP.8

MAN.4

использование

проектами

Аудит

Разрешение

Управление

Административное

проблем

рисками

управление

Создание

инфраструктуры

Представление

MAN.3

кадрами

организационных

Управление

процессов на верхнем

качеством

ORG.5

ORG.6

уровне эталонной модели

Измерения

Повторное

MAN.4

использование

(категории MAN, ORG)

Управление

рисками

Рис. 50. Эталонная модель по ИСО/МЭК ТО 15504 (организационные процессы, верхний уровень)

4.7.6. Эталонная модель по ИСО/МЭК ТО 15504 (уровень группы процессов: ORG2 «Усовершенствование»)

ORG.2

Усовершенство-

вание

Основные

процессы

Создание

Аттестация

Усовершенствование

«Потребитель —

Категория ENG

Категория CUS

поставщик»

Инженерная

процессов

процессов

процессов

CUS.1

ENG.1

Приобретение

Разработка

CUS.2

ENG.2

Создать

Поставка

Сопровождение

Планировать

Исследовать

Выявление

системыи

программныхсредств

CUS.3

стандартный

требований

работы

потребности

CUS.4

наборпроцессов

Эксплуатация

Вспомогательные

Организационные

Определить

Собирать

Инициировать

процессы

процессы

Категория SUP

Категория MAN

Категория ORG

работыи

данныео

усовершенствование

Вспомогательная

Управленческая

Организационная

Документиро-

Управление

Административное

ORG.1

ORG.2

продукты

процессах

SUP.1

SUP.2

MAN.1

вание

конфигурацией

управление

Организационные

Усовершенство-

установки

вание

Разработать

Провести

SUP.3

SUP.4

MAN.2

управление

Создание

Обеспечение

Верификация

Управление

ORG.3

инфраструктуры

Подтвердить

SUP.5

SUP.6

MAN.3

кадрами

качества

проектами

Административное

ORG.4

стратегию

соответствия

проверки

качеством

ORG.5

ORG.6

данные

аттестацию

Проверка

Совместные

Управление

адаптации

Аудит

проблем

рисками

Измерения

использование

SUP.7

SUP.8

MAN.4

Разрешение

Управление

Провести

Собирать

Сформировать

анализ

данныео

рейтинги

результатов

процессах

процессов

Реализовать

Детализация организационного процесса Создать усовершенствование

верхнего уровня ORG2 «Усовершенствование»

отчет

Подтвердить

усовершенствование

Поддерживать

усовершенствование

Провести мониторинг усовершенствования

Рис. 51. Эталонная модель по ИСО/МЭК ТО 15504 (уровень группы процессов: ORG2 «Усовершенствование»)

4.7.7. Референтная модель SAP/R3

Референтная модель SAP R/3 в методологии ARIS

Референтная модель процессов, реализуемых в SAP R/3 в ARIS построена на основе информации, содержащейся в ASAP* (AcceleratedSAP).

Референтная модель SAP R/3 доступна в виде базы данных ARIS, что позволяет значительно сократить усилия и расходы на создание и документирование концепции организации бизнеса компании.

Референтная модель содержит полный функционал SAP, что позволяет осуществить выбор объема внедрения SAP на основании визуализированных и объективных данных. Референтная модель использует 4 типа диаграмм ARIS: eEPC (процессы), PSD (сценарии процессов), RAD (описание экранов и ролей), FAD (окружение функций).

*ASAP – методология и инструментальное средство управления проектом внедрения SAP R/3.

4.7.8.Иерархическая структура референтной модели SAP R/3

1.Уровень компании (Модель eEPC)

(Company area)

2. Уровень сценариев (Модели eEPC, PSD) (Scenario)

3. Уровень групп

процесов

(Модели eEPC)

(Process group)

4. Уровень процессов

(Модели eEPC)

(Process)

5. Уровень функций

(Модели eEPC, FAD, RAD)

(Function)

Рис. 52. Иерархическая структура референтной модели SAP R/3

4.7.9. Отраслевые модели-прототипы компании SAP (Solution Maps)

Общие сведения о SAP Solution Maps.

SAP Solution Maps – средство представления моделей-прототипов (отраслевых и межотраслевых).

SAP Solution Maps – позволяет осуществить выбор программного продукта компании SAP и ее партнеров на основании требований к бизнес-процессам организации.

Solution Maps имеет следующую структуру:

9 Solution Map (карта решений)

oProcess Category (категория процесса)

Main Process (главный процесс)_

•Process (процесс)

Пример карты решений для предприятий с дискретным производством

Рис. 53. Карта решений для предприятий с дискретным производством

Формирование решения для конкретного предприятия

Рис. 54. Формирование решения для конкретного предприятия

Последовательность формирования решения в Solution Maps (шаги 1,2)

Шаг 1

Шаг 2

Категории процессов

Главные процессы

Процессы

Рис . 55. Последовательность формирования решения в Solution Maps (шаги 1,2)

Последовательность формирования решения в Solution Maps (шаги 2,3)

Процессы

Шаг 2

Ключи

Продукты

Рис. 56. Последовательность формирования решения в Solution Maps (шаги 2,3)

4.7.10. Построение деятельности ИТ-подразделения в соответствии со стандартом ITIL (Information Technology Infrastructure Library)

Стандарт ITIL.

ITIL — проект правительства Великобритании, обобщение опыта управления ИТ на протяжении 20 лет:

9Больший фокус на пользователях IT сервисами

9Улучшение управляемости, качества и стоимости

9Улучшение коммуникаций с IT департаментом

9Более эффективное использование в бизнесе IT ITIL – процессно-ориентированный подход к управлению ИТ.

Библиотека ITIL содержит в себе передовой опыт по управлению ИТ – подразделением, описание процессов, целей и метрик (ключевых показателей результативности); ITSM (IT Service Management) — разработанная в проекте модель процессов ИТ; Возможно построение системы управления ИТ – подразделением с использованием библиотеки ITIL на основании системы сбалансированных показателей (BSC); Существуют ИТрешения поддерживающие данные подходы.

Основные положения ITIL:

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

9ИТ подразделение не предоставляет в пользование оборудование, а предоставляет услуги, необходимые для конечных пользователей, которых в таком контексте предпочтительнее именовать «потребителями услуг»

9Следует перейти от отношений владелец-пользователь оборудования (приложений) к отношениям покупатель-продавец услуг

9Должны быть выработаны способы измерения качества предоставляемых услуг: невозможно оценить то, что нельзя померить

9Качество предоставляемых услуг находится в непосредственной зависимости от их стоимости: не могут качественные услуги быть дешевыми, а дешевые — удовлетворять завышенным требованиям потребителей

9Нельзя гарантировать качество предоставляемых услуг без осуществления его непрерывного контроля и без своевременного принятия управленческих решений по его обеспечению

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

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

спредставителями иных подразделений.

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

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

расходы за счет повышения качества предоставляемых сервисов ИТ и улучшения ситуации для бизнеса в целом.

Пример процессов верхнего уровня ИТподразделения

Предоставление сервисов

Поддержка сервисов

(Service Delivery)

(Service Support)

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

Управление кофигурациями

(Service Level Management)

(Configuration Management)

Управление мощностями

Взаимодействие с пользователями

(Capacity Management)

(Service Desk)

Управление доступностью

Управление проблемами

(Availability Management)

(Problem Management)

Управление затратами

Стратегическое

Управление инцидентами

(Cost Management)

управление и мониторинг

(Incident Management)

Управление непрерывностью

Управление релизами

(Continuity Management)

Бизнес-прогноз

(Software Control & Distribution)

Управление безопасностью

(Business Assessment)

Управление изменениями

(Security Management)

Разработка ИТ-стратегии

(Change Management)

Управление услугами

(IT Strategy Development)

Управление операциями

сторонних организаций

Управление

(Operation Management)

целями и задачами

Мониторинг

Вспомогательные

процессов

Проектирование и

Управление клиентами

процессы

внедрение

(Customer Management)

Управление

Планирование услуг

Выбор ИТ-решения на

инвестициями

(Service Planning)

автоматизацию

Управление

Проведение

Разработка технического

качеством

независимого аудита

задания и технического проекта

Управление

Управление

Закупка, установка и поддержка

финансами

рисками

технологической инфраструктуры

Управление

Закупка, установка и поддержка ПО

персоналом

Управление

Внедрение ИС

проектами

Предоставление

Тестирование и

обучения

опытная эксплуатация

Рис. 57. Пример процессов верхнего уровня ИТподразделения

Группа процессов управления уровнем сервиса ИТ-подразделения

Верификация

уровней сервисов и

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

возможностей их

(Service Level Management)

повышения

Привязка

Определение

Определение

Разработка

Переговоры с

Оценка требований специфических

необходимости

клиентом

клиента

требований

создания

Service

Service

клиента к

специфического

Level Agreement Level Agreement

стандартным сервисам сервиса

Анализ

Определение

Мониторинг

Обсуждение

специфического

Создание обзоров Предложения по

для клиента

цикла обзоров

сервиса с

результатов

уровня

производительности

точки зрения

мониторинга

производительности

улучшению

производительности

сервисов

клиента

с клиентом

сервисов

сервисов

сервисов

% сервисов,

Наличие

Свидетельства

Какой % целей

% сервисов,

включенных

по сервисам

мониторинга и

разрешения

в SLA, накрытых

выполнен, насколько

покрытых SLA

субординированными

регулярных

вопросов,

серьезны бреши

контрактами

отчетов

поднятых в SLA

в сервисах

Разработка

иподдержка

каталога

сервисов

Ключевыепоказателирезультативностипроцессов

Рис. 58. Группа процессов управления уровнем сервиса ИТ-подразделения

4.7.11.Другие эталонные и референтные модели

9Референтные модели, разрабатываемые консалтинговыми компаниями для выполнения реальных проектов в различных отраслях экономики.

9Модель eTOM (enhanced Telecom Operations Map), является расширенной версией стандарта TOM, используемого для управления операционными процессами в сфере телекоммуникаций. Расширение связано со смещением акцентов стандарта в сторону

бизнес-процессов.

TOM (Telecom Operations Map) — Модель Операций Телекома.

Создана TeleManagement Forum(ранее называвшимся Network Management Forum) — некоммерческой организацией, объединяющей более 350 членов из 40 стран — в рамках инициативы SMART TMN. Программа TMN (Telecommunications Management Network) — Сеть Управления Телекомом — направлена на разработку решений по интеграции систем операционной поддержки и по автоматизации ключевых процессов в Телекоме. Она состоит из четырех компонентов: Telecom Operations Map, Central Information Facility, Technology Map и Catalyst Projects. С точки зрения организации сеть TMN

представляется пятью иерархическими уровнями: сетевые элементы (Network Element Layer, NEL),

управление элементами (Element Management Layer, EML), управление сетью (Network Management Layer, NML), управление услугами (Service Management Layer, SML) и управление бизнес-процессами (Business Management Layer, BML). Пирамида TMN — основа концепции построения систем управления сетями связи, которые реализуют набор функций, определенный в TOM.

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

выполнения, обеспечения и учета (Fulfillment, Assurance, Billing, FAB).

В настоящее время TeleManagement Forum работает над проектом NG OSS (New Generation Operations Support Systems), в рамках которого акценты в модели смещаются в сторону бизнес-составляющей и как часть ее разработана eTOM (Enhanced Telecom Operations Map).

9Модель SCOR (Supply Chain Operations Reference model), была разработана и развивается Supply Chain Counsil (SCC) в качестве межотраслевого стандарта управления цепочками поставок. SCC был создан в 1996 году как независимая некоммерческая организация; на сегодняшний день в него входят уже 800 ведущих компаний мира, среди которых производители, дистрибуторы, провайдеры

логистических услуг, разработчики программного обеспечения.

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

SCOR основана на:

¾стандартизации взаимоотношений между бизнес-процессами;

¾стандартных метриках, позволяющих измерить и сравнить показатели эффективности процессов;

¾практики управления цепями поставок, которые помогают достичь «best-in-class» результатов.

oSCOR охватывает сферы:

¾управление отношениями с потребителями товаров (от получения заказа на доставку до оплаты счета);

¾управление материальными (товары) и нематериальными (услуги) потоками, идущими от поставщиков поставщиков до потребителей потребителей (включая управление потоками оборудования, запасных частей, ИТ компонентов);

¾управление отношениями с поставщиками (от формирования заявки до выполнения каждого заказа на поставку).

Структура SCOR:

Уровень 1 — Первый — уровень типов процессов. Определяет рамки и содержимое Референтной Модели, все бизнес-процессы компании однозначно группируются в базисные процессы: Plan, Source, Make,

Deliver, Return. На этом уровне компания формирует конкурентные цели для своей цепи поставок. На этом этапе компания определяет свои бизнес-цели и стратегию в отношении планирования, выбора источников поставок, производства и распределения продукции Уровень 2 — Второй – уровень конфигураций. Дает определение 26 основным категориям процессов,

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

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

Уровень 4 — Четвертый уровень определяет процедуры внедрения усовершенствований цепи поставок компании. Эти процедуры не определяются в SCOR модели, т.к. они уникальны для каждой конкретной компании.

Тема 5. Методологии описания деятельности

6.1.Описание деятельности организации

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

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

6.2.Моделирование деятельности организации

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

9Изменения способов ведения бизнеса не предполагают очевидной необходимости использования моделей.

9Для чего нужны модели? Модели бизнеса:

¾вводят точность и методологичность;

¾обеспечивают единственное, последовательное представление;

¾интегрируют процессы, ИТ-системы, оргструктуру, информацию и данные4

¾позволяют увидеть и проанализировать взаимосвязи;

¾помогают проводить проверку правильности, просмотр и тестирование процессов;

¾обеспечивают информативную среду для оценки сценариев типа «а что,

если…»;

¾являются основой для быстрого внедрения изменений процессов.

6.3.Общие принципы моделирования

I.Принцип корректности. Корректность моделей зависит от полноты и согласованности. синтаксиса конкретной метамодели

II.Принцип релевантности. Модель не должна содержать информации больше, чем необходимо

III. Принцип соизмеримости затрат и выгод. Соотношение объема усилий для создания моделей и полезности моделирования конкретного сценария, продолжительности использования моделей

IV. Принцип прозрачности. Разбиение моделей на различные типы представлений (подмодели) облегчает понимание моделей

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

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

Метамодель (мета – общность, греч.) – «модель моделей». Модель, обобщающая модели конкретной методологии моделирования.

6.4.Принципы моделирования деятельности организации

1)Учет целей моделирования

2)Использование эталонных и референтных моделей

3)Моделирование «сверху-вниз»

4)Принцип разумной достаточности. Решение не должно быть слишком сложным по сравнению с самой решаемой задачей

5)Обеспечение целостности описания

6)Учет эргономических критериев (ограничение числа объектов и геометрического размера модели)

7)Соизмеримость моделей одного уровня детализации по степени обобщения информации

8) Концентрация ресурсов на ключевых аспектах деятельности и на «болевых точках»

9)Учет целей моделирования (модели создавать с учетом последующих шагов их использования)

10)Использование эталонных и референтных моделей в качестве отправной точки описания бизнес-процессов

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

12)Принцип разумной достаточности (оптимизация уровней детализации и числа моделей и используемых в них типов объектов и типов связей). Помните о знаменитом принципе «бритва Оккама» Уильяма Оккама «не следует умножать сущности без необходимости». Решение не должно быть слишком сложным по сравнению с самой решаемой задачей

13)Обеспечение целостности описания деятельности

14)Учет эргономических критериев (ограничение числа объектов модели, и, как следствие, ограничение геометрического размера модели форматом А4)

15)Соизмеримость моделей одного уровня детализации по степени обобщения описываемой информации

16)Концентрация ресурсов на ключевых аспектах деятельности и на «болевых точках»

6.5.Предметные области моделирования деятельности организации

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

6.6.Целостное описание деятельности организации

Уровни детализации процессов

Иерархии предметных областей

Элементыорг.

Цели

Функции

Полномочия

Знания

Продукты/

Документы

Информац. Технические

Материалы

структуры

Услуги

Элементы

системы

ресурсы

Генеральный

Полномочия

Module class

Оборудование

Material

директор

ARIS

для контроля

class

Коммерческий

Исполнительный

Главный

директора

Сервер1

Сервер2

….

Локальный

качества

сервер

директор

директор

бухгалтер

Кадровые

Финансовые

Папки

БДКонфигурации

ARIS

ARIS

Измерительное

Контрольное

Испытательное

Material type

Клинкер

Смесь

Отдел

Отдел кадров

Финансовый

вопросы

вопросы

Фильтры

Easy Design

Easy Design

оборудование

оборудование

оборудование

цемента

цемент

маркетинга

отдел

Папкис

Папки со вспомог.

Прием

Заключение

Заключение

Испытатель-

Сопутству-

Производственный

моделями

информацией

Шаблоны

ARIS

ARIS

ARIS

Вольтметры

Склад

отдел

наработу

договоров

договоров

Модели

Шрифты

ABC

Administrator

Attributes

Проходные

ный стенд

Песок

ющие

Песок

Увольнение

Изменение

Изменение

Объекты

Языки

Форматшрифтов

ARIS

ARIS

ARIS

Ваттметры

калибры

Установка

материалы

Отдел

сработы

зарплаты

зарплаты

Определение

Chart

Configuration

Database

Непроходные

для

Добавка

Размель

Добавка

продаж

Связи

диаграмм

Converter

испытания

читель

Менеджер по

Иванов И.И.

ЗадачиCPI

ARIS

ARIS

ARIS

Омметры

калибры

Аппарат

оптовым

Встроеные

Усовершенст-

Export/

продажам

Merge

Explorer

Import

Эпштейна

Сырые

Packaging

Сырые

Менеджер по

Петров П.П.

объекты

вования CPI

ARIS

ARIS

оптовым

Ползователи

ARIS

Контрольные

материалы

material type

материалы

продажам

и ихгруппы

Script

Model

Process

Менеджер

КузнецовК.К.

Editor

Generator

Generator

весы

по розничным

ARIS

ARIS

продажам

ARIS

RTF

Semantic

Server

Editor

Check

Процессы первого (верхнего) уровня

Процессы второго уровня

Цели Элементы орг.структуры

Продукты/Услуги

Процессы третьего уровня

Цели

Элементы орг. структуры

Продукты/Услуги Полномочия

Документы (носители инф)

Знания

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

Технические ресурсы

Материалы

Рис. 59. Целостное описание деятельности организации

6.7.Моделирование процессов

РАОЕЭС

Стратегическое

Расчет и

ФЭК

планирование

защитатарифов

Государственные

РАО ЕЭС

учреждения

Составление

Контроль, учет

бюджетови

Исполнение

и

анализ

документовдля

бюджета

деятельности

VAD

внешних пользователей

Оперативная

СОЦДУ

комиссияРАО

ЕЭС

Формирование

Формирование

Расчет запоставленную

балансаэлектроэнергии

диспетчерского

электроэнергию

ФОРЭМ

и мощности

графика

и контрольплатежей

Потребители

Министерства

электроэнергии

РАОЕЭС

Планирование

Воздействиена

Контроль

воздействий

оборудование

выполнения

наобъект и НИОКР

и НИОКР

работ иоплаты

Контрагенты

1

Планирование

ремонтов

Планирование

Планирование

Разработка

работ

проектапо

ТПиР

пообъекту

ТПиР

Планирование

Разработка

нового

проектапоновому

строительства

строительству

Корректировка

планов

Группапроцессов

Проведение Закупки ремонтов

2

оборудованияи

зап. частей

Проведение Закупки ТПиР услуг

Новое

строительство

VAD

Окружениефункции

Процессыверхнегоуровня

Сценарийпроцесса

Сценариипроцесса

Main process

consists of

consistsof

consists of

cons

S

oicenar

Штатные

Временно

Работающие

работающие

сотрудники

подоговорам

сотрудники

leb

ongs

Определение

Определение

Определение

Определение

потребности

потребностей

потребностей

потребностей

to

leb

Отбор

Отбор

Отбор

Отбор

ongs

персонала

персонала

персонала

персонала

to

leb

Приемна

Приемнаработу

Приемнаработу

Заключение

ongs

работу

штатного

временного

договора

to

сотрудника

сотрудника

b

to ongsle

Сбор

Сборсведений

Сборсведений

сведенийо

оперсонале

оперсонале

персонале

b

PSD

Предложение

FAD

Предложение

Предложение

Ответственный

заснабжение

5

Приеми

рассмотрение

Предложения

Приняток

MS Word

Предложение

рассмотрению

Факс

Осуществление

процедуры

«холодного» back up

Alpha Server

«Холодный»

Наступил

back up данных

первый

Ежедневно,

Alpha Server

день

втечение

осуществлен

кампании

кампании

успешно

Подготовка

Подготовка

кпроцедуре

кпроцедуре

«горячего» back up

«холодного» back up

Alpha Server

Alpha Server

Касетаспроцедурой

Новаякасета

«горячего» back up

дляпроцедуры

28-дневнойдавности

«холодного» back up

изархиваизъята

подготовлена

Тестирование

процедуры

back up

Alpha Server

Тестирование

Тестирование

процедуры

процедуры

«горячего» back up

«холодного» back up

3

Alpha Server

Alpha Server

прошлоуспешно

прошлоуспешно

Осуществление

процедуры

Осуществление

«горячего» back up

процедуры

Alpha Server

«

холодного» back up

Alpha Server

eEPC

4

Согласование

eEPC

Предложение

условий

Предложение

Поступили

Предложения

отпоставщиов

Предложение

Ответственный

заснабжение

Приеми

рассмотрение

Предложения

MS Word

Приняток

Предложение

рассмотрению

Факс

Предложение

Предложение

отклоненопо

приняток

формальным

Тендеру

признакам

Ответственный

Ответственный

Приняток

Предложение

заснабжение

Отклонено

Предложение

заснабжение

рассмотрению

Включение

Предложенияв

Архивирование

список

MS Excel

предложения

Система

Вработе

Список

управления

Архивирование

Предложений

документами

Отклоненные

Предложение

Утверждение

Ответственный

предложения

архивировано

списка

заснабжение

Предолжений

Утвержден

Список

Предложений

Консультационные

Список

услуги

предложений

утвержден

Процедура

Рис. 60. Моделирование процессов

6.8.Эволюция методологий моделирования

Методология моделирования – учение о структуре, логической организации, методах и средствах деятельности в области структурного анализа.

Бизнес

Информационные

Методологии

Бизнес +

системы

структурногоподхода

DFD, STD,

ERD, FDD, ARIS

SADT, IDEF

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

Методологии

Методологии,

объектно-ориентированного

ориентированныена

подхода

бизнес-процессы

UML, RUP

Рис. 61. Эволюция методологий моделирования

6.9.Методологии структурного подхода

1)DFD (Data Flow Diagrams) – диаграммы потоков данных, обеспечивающих анализ требований и функциональное проектирование информационных систем.

2)STD (State Transition Diagram) – диаграммы перехода состояний для проектирования систем реального времени.

3)ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь».

4)структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов.

5)FDD (Functional Decomposition Diagrams) – диаграммы функциональной декомпозиции.

6)SADT (Structured Analysis and Design Technique) — технология структурного анализа и проектирования.

7)семейство IDEF (ICAM — Integrated Computer Aided Manufacturing Definition).

6.10.Семейство IDEF

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

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

3)IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “сущность-связь” (ER – Entity-Relationship) и используется для моделирования реляционных баз данных.

4)IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets).

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

6)IDEF4 — методология объектно-ориентированного проектирования. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы.

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

CASE-системы (Computer-Aided Software/System Engineering ): BPwin, Erwin и др.

Инструментальные системы: MS Visio и др.

CASE-системы, — средства автоматизации, поддерживающие CASE-технологии.

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

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

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

6.11.Методологии объектно-ориентированного подхода

Средства UML (Unified Modeling Language):

1)Диаграммы вариантов использования (use case diagrams).

2)Диаграммы классов (class diagrams).

3)Диаграммы взаимодействия (interaction diagrams):

4)Диаграммы последовательности (sequence diagrams).

5)Кооперативные диаграммы (collaboration diagrams).

6)Диаграммы состояний (statechart diagrams).

7)Диаграммы деятельности (activity diagrams).

8) Диаграммы компонентов (component diagrams).

9)Диаграммы размещения (deployment diagrams).

CASE-системы: Rational Rose и другие.

Инструментальные системы: MS Visio и другие.

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

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

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

9диаграмма eEPC (Extended Event driven Process Chain — событийная цепочка процесса);

9диаграмма Чена (ERM — Entity Relationship Model – модель «сущность-связь»);

9язык UML (Unified Modeling Language – универсальный язык моделирования), методика OMT (Object Modeling Technique – методика объектно-ориентированного моделирования);

9методика BSC (Balanced Scorecard – система сбалансированных показателей).

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

Тема 6. Инструментальные системы для моделирования бизнеса

6.1.Инструментальная система ARIS 6.2

ARchitecture of Integrated Information Systems: архитектура интегрированных информационных систем.

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

ARIS 6.2 – это:

9112 типов моделей для описания практически всех сторон деятельности современного предприятия

9Более 211 типов объектов, описывающих различные аспекты предметных областей

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

9Встроенные механизмы для управления, проверки, анализа, экспорта/импорта, архивирования моделей

Разработчик ARIS – компания IDS Scheer AG, г. Саарбрюкен, Германия.

6.2.Типы представлений ARIS

Предприятие Организация

Кто

Произ-

Отдел

водство

продаж

Плани-

Снаб-

Каким

Org 5

жение

образом

рование

Данные

Процессы

Что

Функции

Запрос от

Обслуживание

Заказы

Клиенты

E 1

клиента

F 1

ET 1

ET 2

клиентов

Клиенты

Обработка

Отдел

ОбработкаСоставление

F 11

F 11

F 12

ET 2

запроса

продаж

запроса

заказа

Запрос

Составить

Продукты

F 111

E 2

номенклатуру

ET 3

обработан

Определить

Составление

F 112

На основе

цены

заказа

Заказ

F 12

чего

Для

чего

Продукты/

услуги

Продукты/услуги Изделие Заказ Запрос

Рис. 62. Типы представлений ARIS

6.3.Уровни описаний и количество моделей ARIS

Требования (2)

Организация (5)

Спецификация (1)

Реализация (2)

Процессы (75) Функции (12)

Требования

Требования

Требования

Данные

(14)

(70)

(9)

Спецификация

Спецификация

Спецификация

(19)

(4)

4

(2)

Реализация

Реализация

Реализация

(1)

1

(1)

Продукты

/услуги (1)

Требования (1)

Рис. 63. Уровни описаний и количество моделей ARIS

6.4.Элементы сети ARIS

Сервер ARIS

Конфигурационнаябаза

Сервер 1

Базаданных ARIS

Служебные

Главнаяпапкабазы

папки

Моделибазыданных

Папкибазы

Базаданных ARIS

данных

Сеть ARIS

содержит (subsumes)

Сервер 1

Сервер 2

Сервер N

Локальный

. . .

сервер

Сервер ARIS

является (is a)

Рис. 64. Элементы сети ARIS

6.5.ARIS Explorer – Проводник

Назначение ARIS Explorer:

1)Подключение дополнительных модулей ARIS и их конфигурирование;

2)Взаимодействие с серверами ARIS

3)Управление базами данных: создание, резервное копирование, регистрация, конфигурирование

4)Управление элементами баз данных: пользователями, форматами шрифтов, языками, папками, моделями, объектами

5)Навигация по базам данным, моделям и объектам

Серверы

Базы данных

Контекстное

меню

Папки

Модели

Контекстная помощь

Рис. 65. ARIS Explorer – Проводник

6.6.Окно и панели инструментов ARIS Designer

Назначение ARIS Designer:

1)Создание новых моделей;

2)Модернизация существующих моделей;

3)Распечатка моделей (с возможностью предварительного просмотра);

4)Форматирование объектов моделей;

5)Связывание и встраивание внешних объектов операционной системы;

6)Использование графических примитивов;

7)Детализация объектов на модели;

8) Просмотр и заполнение атрибутов модели, объектов и связей.

Изменение

Контекстная

Выбор

помощь

масштаба

объектов

изображения

Внешние

модели

документы

Управление

Детализация

размерами

объектов

объектов

на модели

Ссылки на

документы

Форматирование

и приложения

объектов

Рис. 66. Окно и панели инструментов ARIS Designer

6.7.Понятие о моделях, объектах и связях ARIS

Модельорганизационнойструктуры

Начало

Конструкторский

процесса

Комната 109

обеспечивает

вноситвклад

отдел

входныеданные

ввыполнение

Орг. единица

Конструктор

Документ 1

Секретарь

Начальник

Руководитель

создает

Фунция 1

Место

отдела

отдела

отдела

навыходе

выполняетсяв

выполнения

Конструктор

Картотека

Технолог_1

Конструктор

Технолог

1 категории

Функция 1

Полномочия

Number of employees: 3

Конструктор

выполнена

Конструктор

поддерживает

2 категории

Информ.

активизирует

требует

Number of employees: 2

система

выполняет

Модельзнанийперсонала

Функция 2

Бизнес-роль

Консультант

Производ.

генерирует

ресурс

является

производст-

Функция 2

50

60

веннымресурсом

выполнена

Цель

Системный

Программные

Продукт 1

используется

поддерживает

системы

анализ

Функция N-1

Должность

80

Теория

Продукт 2

отвечаетза

процессов

производится

выполнение

Методология

Функция N-1

100

100

управления

выполнена

Предметнаяобласть

проектамипо

моделированию

Рис. 67. Понятие о моделях, объектах и связях ARIS

6.8.Информационное наполнение моделей

n-

DocumentAcrobat Видео-клип

MS Word

MS Excel MS Project

Image

HTML

Информационное

наполнение моделей

Рис. 68. Информационное наполнение моделей

6.9.Разработка, проверка, анализ, совершенствование моделей

ARIS Toolset, ARIS Easy Design

ARIS Designer, ARIS Semantic

Check, ARIS Analysis, ARIS

Simulation, ARIS ABC

Bestellanforderungszuordnung

MM-PUR

Bestellan-

Bestellan-

forderung ist

Anfrage ist

forderung ist

fьr Anfrage

zu erstellen

nicht vor-

vorgemerkt

handen

XOR

Angebotsfrist

Bindefrist

festlegen

festlegen

Fristen sind

festgelegt

Anfrageposi-

Anfrage-

Lieferanten-/

tionen aus Be-

positionstyp

anfrage/

stellanford.

auswдhlen

-angebote

ьbernehmen

Anfragepos.

Anfragepo-

sind aus

sitionstyp Nor-

Bestellanf.

mal gewдhlt

ьbernommen

XOR

Lieferanten-

Anfragepo-

Angebots-

bearbeitung

sitionen

bearbeiten

XOR

XOR

Anfragepos.

Anfragepos.

ohne abweichende

mit abweichender

Terminvorgabe

Terminvorgabe

erstellt

erstellt

Einteilung

zu Anfrage

erfassen

Einteilung

ist erfaЯt

XOR

XOR

Lieferanten

bestimmen

Anfragen

sind erstellt

Anfrage

Anfragen

ьberwachen

ьbermitteln

Anfrage wird

Anfragen an

Lieferanten

ьberwacht

ьbermittelt

Lieferanten-

Angebots-

bearbeitung

MM-PUR

Рис. 69. Разработка, проверка, анализ, совершенствование моделей

6.10.Документирование моделей

Отчеты по моделям:

9Штатное расписание;

9Должностные инструкции;

9Технологические карты процессов;

9Инструкции и методики выполнения работ;

9Требования к компетенции персонала.

Скрипт – программа на языке ARIS Sax Basic, позволяющая перенести информацию из графических моделей в файлы документов в соответствии с определенными правилами. Генерация отчета — создание файла документа при помощи скрипта.

6.11.Распределенная работа и публикация моделей в Inranet/Internet

n-

ARIS Web Publisher

ARIS Web Designer

Рис. 70. Распределенная работа и публикация моделей в Inranet/Internet

6.12.Экспорт/импорт моделей

n-

ARIS Export

/Import

Интерфейсы TOOLBUS

BPwin

ERwin

Oracle Designer

Rational Rose

Рис. 71. Экспорт/импорт моделей

6.13.Объекты

Объект — составная часть модели, отражающая неделимый элемент описываемой предметной области.

6.14. Сравнительный анализ возможностей инструментальных средств. ARIS, BPwin, ERwin и Visio

BPwin, Erwin:

9Моделирование организационной структуры;

9Моделирование структуры функций;

9Моделирование потоков данных;

9Моделирование процессов;

9Проектирование информационных систем;

9Генерация баз данных;

9Генерация шаблонов исходного кода и создание приложений.

Visio:

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

ARIS:

9Моделирование системы управления;

9Управление Бизнес-процессами компании;

9Описания взаимодействий с клиентами (Supply Chain Management);

9Управление изменениями на предприятии (Process Improvement & Change management);

9Проектирование новых информационных систем и интеграция старых;

9Внедрение workflow-систем;

9Внедрение ERP-систем (в том числе при помощи ARIS for mySAP);

9Управление знаниями (Knowledge Management);

9Создание системы стратегического управления компанией на основе технологии Balanced Scorecard;

9Сертификация по различным стандартам качества;

9Управление операционными рисками, создание автоматизированного рабочего места риск-менеджера (ARIS Process Risk Scout)4

9Генерация шаблонов исходного кода, создание БД и приложений (при помощи интерфейсов с CASE-средствами).

6.15. Сравнительный анализ возможностей инструментальных средств. ARIS и Rational Rose

ARIS поддерживает все этапы создания информационной системы от анализа требований до реализации.

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

Rational Rose — это средство проектирования различных приложений информационной системы с последующей реализацией и генерацией БД и/или шаблонов исходного кода.

Источник

Понравилась статья? Поделить с друзьями:

Вот еще несколько интересных статей нашего сайта:

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

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии