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

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

Оглавление

Введение

Глава 1.     Анализ архитектуры данных в составе архитектуры предприятия

.1      Архитектура предприятия как инструмент управления изменениями

.2      Архитектура данных

.3      Модели данных

.3.1   Концептуальная модель данных

.3.2   Логические модели данных

.3.3   Физическая модель данных

.4      Процесс формирования архитектуры данных

.5      Методы проектирования архитектуры предприятия

1.5.1 TOGAF

.5.2   Модель Захмана

.5.3   Gartner

.5.4   FEAF

.5.5   DoDAF

1.6    Анализ методик проектирования архитектуры данных

.7      Проектирование архитектуры данных по TOGAF

.8      Выводы по Главе 1

Глава 2.     Формирование методики проектирования целевой АД

.1      Интеграция BPM и архитектуры предприятия

.2      Проектирование целевой данных на основе модели BPMN

.2.1   Определение объекта управления

.2.2   Описание потоков данных

.2.3   Определение источников данных

.2.2   Интеграция данных

.2.3.  Преобразование данных

.2.4   Доступ к данным

.2.5   Синхронизация данных по времени

.3      Методика проектирования архитектуры данных для BPMS-систем с помощью TOGAF

.4      Выводы по Главе 2

Глава 3.     Реализация методики

.1      Описание процесса

.2      Описание концептуального уровня

.3      Описание логического уровня

.4      Описание физического уровня

.5      Выводы по Главе 3

Заключение

Библиографический список

Приложение А. Расчеты матриц с помощью МАИ

Введение

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

Существует несколько подходов к управлению информационными потоками, во-первых, функциональное управление, применяемое большинством компаний. В функциональном подходе используются информационные системы, основанные на аналитических моделях бизнес-процессов, например, системы, основанные на реляционных базах данных - ERP, или системы, использующие многомерные базы данных - BI. Однако такие системы являются отражением статичного предприятия, так как не учитывают изменения бизнес-процессов. Для отражения динамики предприятия компании внедряют процессный подход, который использует модели бизнес-процессов как основу для проектирования информационных систем. Процессный подход использует BPM (Business Process Management). BPM - это система управления бизнес-процессами. Процессный подход является более трудоемким для управления, так как модели BPM требуют постоянного мониторинга. Для решения данной проблемы разрабатываются системы, автоматизирующие BPM. Эти системы называются BPMS (Business Process Management System). Они позволяют снизить сложность разработки систем и неопределенность данных, так как модели бизнес-процессов являются исполняемыми в системах BPMS.

Переход к системе BPMS требует комплексного анализа всех элементов предприятия, от представления о текущем статусе предприятия до состояния «как должно быть». Одним из инструментов, позволяющих сформировать полноценное видение бизнеса и его структуру, является архитектура предприятия. Согласно документу «Federal Enterprise Architecture Framework», архитектура предприятия - это стратегическая информационная основа, определяющая [1]:

-       информацию, необходимую для ведения бизнеса;

-       структуру бизнеса;

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

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

Управление архитектурой предприятия осуществляется на основании следующих шагов: описание существующей (AS-IS) архитектуры, проектирование целевой (TO-BE) архитектуры, разработка плана перехода от существующей к целевой архитектуре. Целевая архитектура является идеальной моделью предприятия, в основе которой заложены [2]:

-       анализ тенденций рынка и среды деятельности организации;

-       стратегические требования к бизнес-процессам;

-       требования к ИТ-архитектуре;

-       информация о «узких местах» и способах их устранения.

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

В качестве объекта исследования определен процесс разработки архитектуры данных в контексте архитектуры предприятия.

Предметом исследования является методы проектирования целевой архитектуры данных при формировании BPMS систем.

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

Для достижения цели необходимо решить следующие основные задачи:

1.         Описать уровни и функции целевой архитектуры предприятия.

2.         Описать процесс формирования целевой архитектуры данных.

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

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

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

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

Структура работы.

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

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

Во второй главе описана интеграция архитектуры предприятия и BPMS систем. Сформированы основные этапы проектирования целевой архитектуры данных.

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

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

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

Глава 1.     Анализ архитектуры данных в составе архитектуры предприятия

В данной главе планируется рассмотреть следующие задачи:

)        изучить функции и структуру архитектуры предприятия;

)        проанализировать состав архитектуры данных;

)        описать процесс формирования архитектуры данных;

)        выполнить анализ методик проектирования данных.

1.1    Архитектура предприятия как инструмент управления изменениями

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

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

Одним из средств управления изменениями является архитектура предприятия, обеспечивающая следующие функции [3]:

-       анализ потенциальных изменений и их реализация;

-       создание основы для построения ИТ-организации в целом;

-       предоставление единого хранилища всех данных организации;

-       обеспечение поддержки принятия решений.

Архитектура предприятия - это динамическая система, которая описывает текущее состояние (AS IS), целевое состояние (TO BE) и план перехода от архитектуры AS IS к TO BE.

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

Целевая архитектура - желаемое будущее состояние компании, которое является идеальной моделью предприятия, в основе которой заложены: стратегические требования к бизнес-процессам и ИТ, информация о выявленных «узких местах» и путях их устранения, анализ технологических тенденций и среды бизнес-деятельности предприятия [4].

Целевая архитектура создается на основании миссии, видения и стратегии компании [4].

Миссия компании - это большая, труднодостижимая цель, которая заставляет двигаться вперед сотрудников компании.

Видение компании - это описание того, как компания будет выглядеть в будущем. Например, какая будет прибыль, с какими потребителями будет работать.

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

Реализация целевой архитектуры отражается в документе, который называется план перехода. Этот план содержит список и последовательность ИТ‐проектов, которые потребуется реализовать для достижения целевой архитектуры. Плана перехода является основой для планирования ресурсов и определения сроков проектов. План помогает оценить, возможна ли реализация целевой архитектуры. Если план не реализуем в эти сроки и с доступными ресурсами, то необходимо пересмотреть целевую архитектуру и скорректировать её.

Последовательность действий, направленная на создание архитектуры, называется архитектурным процессом. Эффективный архитектурный процесс обеспечивает [5]:

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

-       контроль соответствия стратегии развития предприятия современным тенденциям в отрасли;

-       быструю разработку и внедрение новых информационных систем.

Архитектурный процесс заключается в разработке следующих уровней архитектуры предприятия:

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

-       ИТ-архитектуры, или системной архитектурой (включающей архитектуру данных, архитектуру приложений и технологическую архитектуру).

Согласно исследованию Gartner «Magic Quadrant for Enterprise Architecture Consultancies» (от 24.06.2015), на разработку бизнес-архитектуры уходит 27% рабочего времени, а на системную архитектуру - 73%. При этом, меньше всего времени уделяется архитектуре данных - 14% [6]. Однако, в будущем эта цифра значительно увеличится из-за развития таких технологий как большие данные (Big Data) или интернет вещей (IoT), а значит, архитектура данных будет требовать более тщательной проработки.

1.2    Архитектура данных

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

-       принципы управления информацией;

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

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

Модели обработки информации позволяют определить связь данных с бизнес-ролями или конкретными организационными структурами. Такие модели часто формируются в виде «CRUD» матриц. «CRUD» матрицы определяют уровень доступа к информации: создание (C), чтение (R), изменение (U), удаление (D).

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

-       концептуальный;

-       логический;

-       физический.

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

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

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

Особенности уровней абстракции при разработке архитектуры данных приведены в Таблице 1.1.

Таблица 1.1. Описание уровней данных