Шеер. Бизнес-процессы. Основные понятия. Теория. Методы

Подождите немного. Документ загружается.

интегрированная информационная система для промышленных предприятий на базе концепции

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

Коммерческая ценность описания информационных систем снижается по мере развития и

совершенствования технических средств реализации. Одновременно ослабевает и стабильность

концепций, поскольку стремительное развитие ИТ, как правило, не может не сказываться на

технической реализации информационных систем. При подготовке книг к печати автор

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

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

Рис. Б. Технический профиль книг автора

А. Преимущества ARIS для пользователя

Аббревиатура ARIS расшифровывается как «Архитектура интегрированных

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

области информационных технологий (ИТ) оно служит для описания:

 их типа,

 функциональных свойств,

 взаимоотношений между отдельными «кирпичиками» информационной системы.

Термин «архитектура» широко употребляется в концепциях ИТ. Некоторые специалисты,

в частности Крцмар и Штрунц, пытались этимологически объяснить перенос этого понятия из

области строительства в сферу ИТ. Однако, по мнению автора этой книги, дело здесь не

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

термин «архитектура», часто встречающийся в американских публикациях, прочно

ассоциируется с такими понятиями, как планирование, регламентация, структуризация и

координация деятельности деловых партнеров. Все эти понятия типичны для информационных

систем. В таком значении термин «архитектура» употребляется также для описания аппаратных

систем и баз данных.

В первом издании этой книги речь шла о применении архитектуры ARIS к разработке

инфраструктуры для комплексного описания (моделирования) автоматизированных

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

концентрировали внимание прежде всего на информационных системах и на их роли в

поддержке бизнес-процессов.

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

роль моделирования бизнес-процессов существенно возросла. Модели бизнес-процессов,

построенные на базе концепции ARIS, находят применение даже в таких классических областях

ведения бизнеса, как пооперационное исчисление стоимости, организация и реорганизация

процессов, управление качеством. Это ведет к тому, что моделирование бизнес-процессов все

чаще рассматривается как еще один аспект управления бизнесом.

К сожалению, управленческая терминология грешит рядом недостатков: зачастую она

неоднозначна, расплывчата, а подчас и откровенно противоречива. По этой причине, словесные

формулировки как правило, оказываются неадекватными при описании характеристик

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

описания вопросов, связанных с принятием решений и планированием в сфере управления

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

не в каждом случае.

Именно поэтому при моделировании в среде ARIS для описания проблем в области

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

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

обеспечивают превосходный старт для дальнейшей обработки информационными системами

(ИС).

Благодаря новым методам и инструментам модели бизнес-процессов все больше

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

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

приоритет перед вопросами реализации.

Полуконцептуальные графические методы, такие как организационные диаграммы или

сетевые графики, широко применяются в сфере управления бизнесом. Однако концепция ARIS

идет дальше, предоставляя в распоряжение менеджера справочное руководство по

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

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

документированием знаний и опыта компании. «Управление знаниями» и «корпоративная

память» — это всего лишь два понятия терминологии, применяемой в этом контексте. Значение

ARIS как инфраструктуры управления знаниями продолжает возрастать.

Концепция ARIS прежде всего позволяет зафиксировать широкий спектр описательных

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

наложения методов и выявить пробелы в описании. Преимущества ARIS очевидны как при

решении административных и организационных вопросов бизнеса, так и при проектировании

компьютеризованных информационных систем

А. 1. Преимущества для управления бизнесом и организационных

процессов

Формулировка глобальной цели, или целевая корпоративная установка, определяет

содержание и форму производственного процесса, а также использование его материального

выхода (результата) и услуг путем сочетания производственных факторов. Выполнение этих

задач зависит от множества субъектов и технических средств, которые должны тесно

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

организацию.

Структурная (функциональная) или иерархическая организация характеризуется

постоянными (статическими) правилами, такими как иерархия или топология предприятия. Это

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

выход, информационные или коммуникационные технологии. Эти отношения описываются с

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

Организация процессов, напротив, связана с нестационарным и логическим

(динамическим) поведением процессов, необходимых для выполнения программной

корпоративной установки.

Между иерархической структурой организации и структурой процессов существует тесная

взаимосвязь.

В течение многих лет одной из ключевых тем в теории бизнеса были иерархические

организации. Однако благодаря прочно вошедшим в моду «ученым» выражениям типа

«инжиниринг бизнес-процессов» на авансцену в последние годы вышла организация процессов.

Вообще говоря, бизнес-процесс для предприятия представляет собой непрерывную серию

задач, решение которых осуществляется с целью создания выхода (результата). Исходной

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

корпоративные или внешние «потребители».

Бизнес-процессы позволяют добиваться высокой эффективности деятельности

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

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

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

поддаются строгому определению (например, сократить цикл бизнес-процесса «разработка

продукта» на 30%), и они являются объектами учета стоимости (пооперационного определения

стоимости).

Многие элементы инжиниринга и реинжиниринга бизнес-процессов (BPR) вошли в

предыдущие концепции построения организации. Например, модель Y-CIM (CIM

компьютеризованное управление производством) описывает контекст между разработкой

продукта и процессом материально-технического обеспечения (логистикой) на промышленном

предприятии, акцентируя внимание на организации бизнес-процессов. Еще в 1984 году автор

описал бизнес-процессы и их реализацию с помощью диаграмм цепочки процессов.

Для создания моделей бизнес-процессов существует множество причин, например:

оптимизация организационных изменений (побочный продукт BPR),

хранение корпоративных знаний, в том числе в виде моделей-прототипов,

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

сертификата ISO-9000 и других,

исчисление стоимости бизнес-процессов,

эффективное использование информации о процессах для реализации стандартных

программных решений или систем workflow и адаптации их к конкретным нуждам.

В рамках этих категорий методы моделирования можно применять и с более широкими

целями. Реинжиниринг бизнес-процессов (BPR) позволяет «высветить» их компоненты,

требующие внимания.

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

бизнес-процессов, назовем лишь следующие:

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

позволяет устранить лишние циклы и сделать структуру более рациональной,

изменение структуры организационной отчетности и повышение квалификации

сотрудников путем комплексного совершенствования процесса,

сокращение объема документации, рационализация и ускорение документооборота и

потока данных,

рассмотрение возможных мер по привлечению внешних ресурсов (т. е. по передаче

функции создания выхода внешнему исполнителю),

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

Эти примеры относятся к множеству аспектов и категорий моделирования, таких как

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

(данные), внешний или внутренний выход, а также ресурсы производства и информационных

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

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

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

объектов моделирования, так и необходимую степень структурирования, или уровень

детализации.

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

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

воспроизводят фрагменты реальности. Они создаются путем абстрагирования от свойств

реальных объектов, при этом основная структура и поведение этих объектов остаются

нетронутыми (гомоморфизм). Степень возможного абстрагирования от несущественных

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

возможностей методов описания. Если, скажем, выбран объектно-ориентированный (например,

метод сетей Петри) или системно-теоретический подход, то модель будет содержать только

такие объекты, которые вписываются в синтаксис или семантику этих методов.

Во избежание «зацикливания» на определенных методах концепция ARIS не

привязывается к какому-то конкретному методу, она обеспечивает общее описание бизнес-

процесса. В частности, ARIS не имеет конкурентов в области создания моделей управления

производством на уровне предприятия.

А. 2. Преимущества для пользователя при разработке

информационных систем

Информационные системы можно разрабатывать самостоятельно, создавая

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

решений. Если на первых порах популярностью пользовались специализированные

приложения, то теперь нормой стали интегрированные стандартные решения. С появлением

новых типов программного обеспечения (например, компонентного, где приложения

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

случаев) в последнее время получает распространение смешанный вариант, сочетающий оба

этих способа. ARIS поддерживает все три варианта: специализированные приложения,

стандартные программные решения и компонентную сборку.

Разработка специализированных приложений обычно обходится дорого и часто

осложняется из-за таких факторов неопределенности, как продолжительность цикла разработки

или затруднения при оценке стоимости. Поэтому наблюдающая тенденция к переходу от

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

«фабриках программного обеспечения» не вызывает удивления.

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

программного обеспечения. Они различаются как по целевому объекту, ставя в центр внимания

различные аспекты процесса разработки программного обеспечения, так и по подходу к

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

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

программного обеспечения. К их числу относятся монографии Бальцерта и Соммервилла, а

также отчеты конференций рабочей группы 8.1, опубликованные IFIP. Это лишь малая доля

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

В настоящее время рынок перенасыщен обилием методов, почти неотличимых друг от

друга. Необъятное множество продуктов и способов фактически затормозило развитие

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

методологию, интегрирующую различные методы разработки.

Ниже приведены типичные вопросы, ответы на которые позволяют более эффективно

использовать возможности этой методологии:

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

автоматизированных информационных систем?

Если нет, то насколько схожи эти методы? Если да, то почему так много разных способов?

Существует ли оптимальный способ разработки информационной системы?

Где начинается и где заканчивается процесс разработки?

Как выглядит конечный продукт процесса проектирования?

Сколько этапов необходимо для получения результата разработки?

Следует ли использовать только один определенный вид информационной системы или

же требуется несколько методов - свой для каждой системы? По каким критериям следует

выбирать эти методы?

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

Однако только одного их решения мало. Есть и вторая группа факторов, которые дают

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

из того обстоятельства, что в сложных проектах разработки обычно участвует несколько

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

частично накладываются друг на друга. Только инфраструктура, интегрирующая отдельные

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

способна привести к взаимопониманию. Очевидно, что такая инфраструктура может и должна

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

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

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

Концепция ARIS создает направляющие ориентиры для разработки, оптимизации и

реализации интегрированных прикладных систем. В то же время она наглядно показывает

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

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

Программное обеспечение для управления бизнесом включает модули для бухгалтерского

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

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

затрагивает многих сотрудников организации и внешних деловых партнеров. Это становится

очевидным в условиях органично интегрированной обработки данных, где данные совместно

используются множеством приложений. В числе примеров можно назвать реализацию на

предприятиях комплексных ИС-ориентированных концепций, компьютеризованное управление

производством (CIM) на промышленных предприятиях, системы управления товарами с ИС-

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

финансовых учреждениях.

До середины 90-х годов соотношение между усилиями по внедрению финансовых

прикладных пакетов в организации и ценой их приобретения зачастую превышало 5:1.

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

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

(стратегического характера) они хотят достичь с помощью данной системы, как этого добиться,

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

сконфигурировать и технически внедрить данный пакет.

В ранней модели жизненного цикла, приведенной на рис. 1а, системы программного

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

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

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

По этой причине пользователям прежде приходилось вырабатывать свои собственные деловые

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

Безусловно, для этого требовалось обладать серьезными познаниями и навыками в области

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

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

В результате быстрого снижения стоимости аппаратных и программных средств

отмеченная диспропорция еще более усугубилась. Мелкие и средние предприятия оказались не

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

популярности инфраструктур, методов и инструментов, позволяющих уменьшать стоимость

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

программных решений.

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

цикла

Рис. 1б. Способы сокращения организационных усилий

Для этого существует ряд способов (см. рис. 1б):

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

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

прототипов;

создание определения требований за счет эффективного использования методов

моделирования для детализации описания;

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

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

применение семантических моделей для максимального автоматического согласования

определения требований целевой концепции со стандартным программным обеспечением, что

сокращает необходимость специальных знаний в области информационных систем;

эффективное использование семантических моделей в качестве отправной точки для

максимальной автоматизации системы и настройки конфигурации применительно к

конкретным нуждам.

При создании концепции ARIS ставилась цель повысить эффективность этих способов,

ускорить внедрение стандартного программного обеспечения и сократить усилия по его

внедрению за счет включения интегрированных методов и инструментов (ARIS Toolset).

Функциональные возможности ARIS обеспечивают:

инфраструктуру (архитектуру) для полного описания стандартных программных решений;

интеграцию в эту архитектуру наиболее подходящих методов моделирования

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

предоставление моделей-прототипов в качестве инструментов управления прикладным

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

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

эффективно используя стандартные программные решения, ARIS-здание бизнес-

инжиниринга (НОВЕ) предлагает архитектуру для управления бизнес-процессами. Благодаря

использованию систем workflow, она слабо связана со программными «кирпичиками» (бизнес-

объектами). ARIS обеспечивает инфраструктуру для описания сборки программных

компонентов, позволяя создавать деловые информационные системы, которые идеально

подходят для конфигурирования систем

workflow, создания фильтров и определения параметров приложений.

Б. Базовая модель бизнес-процесса в ARIS

Для работы в среде ARIS необходимо сначала тщательно изучить соответствующий

объект, что, в свою очередь, приводит к созданию простейшей модели бизнес-процесса,

опирающейся в основном, на знание деятельности предприятия. Затем эта модель расширяется

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

Б.1. Исходная модель бизнес-процесса

Поясним ключевые моменты описания бизнес-процессов на простом примере обработки

заказов. Для начала изложим общий сценарий.

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

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

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

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

последующего планирования заказа предприятие изготавливает изделия в соответствии с

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

Теперь рассмотрим этот сценарий с различных точек зрения.

В теории систем мы можем разграничить структуру системы и ее поведение. Начнем с

описания субъектов (сущностей) ответственности и отношений, участвующих в бизнес-

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

Выходные потоки описывают результаты выполнения процесса, а информационные потоки —

обмен документами, участвующими в процессе.

Функции, производители выхода (организационные единицы), выходные и

информационные объекты представлены различными символами. Потоки обозначены

стрелками.

Б. 1.1. Субъекты ответственности и их отношения

На рис. 2а представлены субъекты ответственности (организационные единицы),

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

взаимосвязи (отношения) в виде контекстных диаграмм или диаграмм взаимодействия.

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

исходное представление о структуре бизнес-процесса. В сложных процессах несметное

множество обменов между различными деловыми партнерами подчас может привести в

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

ответственности. На диаграмме это сделано лишь в нескольких местах.

Диаграммы взаимодействия широко применяются в теории бизнеса. Рис. 2б отражает

довольно типичную картину взаимоотношений между клиентом, производителем и

поставщиком и результаты (выходы) их взаимодействия.

Б. 1.2. Поток функций

На рис. 3 тот же бизнес-процесс описывается при помощи подлежащих выполнению

функций с указанием их последовательности. Главная роль здесь отводится не субъектам

ответственности, как это было на статичной диаграмме взаимодействия, а динамичной

последовательности функций. Для наглядности на рис. 3 представлены и операционные

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

не столь очевидна.