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

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

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

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

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

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

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

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

Рис.4.9. Предприятие, ориентированное на функции

 

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

Рис. 4.10. Предприятие, ориентированное на процессы

 

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

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

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

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

4.4. CASE-технологии в моделировании бизнес-процессов

За последнее десятилетие сформировалось новое направление в системотехнике — CASE (Computer-Aided Software/ System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Не детализируя, к CASE—технологиям можно отнести совокупность методологий анализа, проектирования, разработки и сопровождения сложных информационных систем, поддержанную комплексом взаимоувязанных средств автоматизации. CASE — это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки информационных систем.

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

Практически ни один серьезный зарубежный программный проект не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT (точнее, ее подмножество IDEFO) принята в качестве стандарта на разработку программного обеспечения (ПО) Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

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

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

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

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

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

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

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

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

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

При согласовании моделей процессов с поведением реальной системы ключевым моментом являются операции. Сторонники этой концепции — Мейер, Вирфс-Брок и Джекобсен. Здесь особо можно отметить метод Use Case, разработанный Джекобсеном и группой других специалистов. Этот метод примечателен использованием концепции UML.

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

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

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

В рамках программы ESPRIT, финансируемой Европейским Союзом (ЕС), осуществлено несколько исследовательских проектов по разработке архитектуры открытых систем (CIMOSA)для компьютеризованных систем управления производством (CIM). Первоначально в проекте CIMOSA участвовало 30 организаций, среди которых были производственники в качестве пользователей, разработчики ИТ и исследовательские институты. Хотя в прикладном отношении проект был ориентирован на системы управления производством, его стратегическая задача заключалась в получении результатов для общего моделирования предприятий. Одной из целей CIMOSA была разработка архитектуры и методологии для создания систем, ориентированных на конкретного потребителя, путем «стыковки» стандартизованных модулей CIM независимо от их производителей (принцип «Plug and Play»). Инфраструктура моделирования CIMOSA представляется в форме куба (рис. 4.12).

Архитектура CIMOSA — трехмерная. Каждое из трех измерений представлено одной из осей куба. На вертикальной оси («ступенчатая деривация») представлены три уровня описания фазовой концепции: определение требований, спецификация проекта и описание реализации. Эти уровни в значительной мере сходны с уровневыми представлениями других CASE-систем.

 

КОНКРЕТИЗАЦИЯ

 

Рис. 4.12. Архитектура моделирования CIMOSA

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

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

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

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

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

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

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

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

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

Всеобъемлющая методология разработки более традиционных информационных систем создана членами одной из рабочих групп Международной федерации по обработке информации (IFIP). IFIP-методологияне сужает объект исследования какими-то конкретными методами разработки ИС. Напротив, она базируется на широком спектре знаний, стремясь охватить как можно больше концепций, среди которых интерактивный метод проектирования (IDA), методология информационного инжиниринга (IEM), один из вариантов высокоуровневых сетей Петри (IML), метод систем разработки Джексона (JSD), метод информационного анализа Нийссена (NIAM), язык постановки задач/анализатор постановки задач (PSL/ PSA), метод структурированного анализа и проектирования (SADT), а также метод Йордона.

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

Рис. 4.13. Типы моделей в архитектуре IFIP

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

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

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

Концепция ARIS(Architecture of Integrated Information Systems — архитектура интегрированных информационных систем) предполагает определенный подход к формализации информации о деятельности организации и представление ее в виде графических моделей, удобном для понимания и анализа. Модели, создаваемые по методологии ARIS, отражают существующую ситуацию с той или иной степенью приближенности. Степень детализации описания зависит от целей проекта, в рамках которого проводится моделирование. Модели ARIS могут быть использованы для анализа и выработки различного рода решений по реорганизации деятельности предприятия, в том числе по внедрению информационной системы управления, разработке систем менеджмента качества.

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

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

Преимущества методологии ARIS:

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

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

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

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

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

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

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

• Функциональная. Определяет функции, выполняемые в организации;

• Подсистемы входов/выходов. Определяют потоки используемых и производимых продуктов и услуг;

• Информационная (подсистема данных). Описывает получение, распространение и доступ к информации(данным);

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

• Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса;

• Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства;

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

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

 

Рис. 4.14. Взаимодействие моделей в ARIS

 

 

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

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

В связи с этим в методологии ARIS выделено четыре основных вида моделей, отражающих основные аспекты организации — пять типов представлений:

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

• функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;

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

■ модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;

• модели входов/выходов, описывающие потоки материальных и нематериальных входов и выходов, включая потоки денежных средств.

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

Рис.4.15. Взаимосвязь видов моделей в ARIS (здание ARIS)

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Фаза 2посвящена определению требований.На этом этапе создаются подробные модели (каждого типа) прикладной системы. И здесь тоже ключевое место занимает организационное содержание бизнеса. На этом уровне следует включить примеры бизнес-процессов.

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

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

Рис. 4.16. Фазовая модель ARIS

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

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

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

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

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

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

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

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

Управление информацией предполагает планирование, регулирование и внедрение «информационного» ресурса. Здесь можно выделить три аспекта: управление инфраструктурой(управление информационными технологиями), управление прикладной системой и управление внедрением информационных систем. Эти определения вписываются в концепцию ARIS. Первая задача, связанная с инфраструктурой, охватывает уровни информационных технологий и спецификации проекта, представленные на рис. 4.17. Вторая задача относится к управлению информационными системами и включает реализацию организационных требований в автоматизированных информационных системах с помощью концепции жизненного цикла ARIS, фокусируя внимание на фазах конструктивного времени. Третья задача — управление внедрением информационных систем — относится к фазе реального времени в модели жизненного цикла ARIS.

Рис. 4.17. Здание ARIS и фазовая модель

 

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

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

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

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

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

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

— На уровне III (управление потоками работ) объекты, подлежащие обработке, например, заказы клиентов с сопутствующей документацией или страховые иски, доставляются с одного рабочего места на другое. Электронные документы доставляются системами класса workflow.

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

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

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

Пятый компонентконцепции АБИ объединяет уровни I—IV в единую инфраструктуру.Инфраструктуры содержат информацию о соответствующей архитектуре и приложениях, конфигурируя реальные приложения с помощью инструментария уровней II и III, а информацию по предметной области для них — из моделей-прототипов (уровень I). Инфраструктуры включают также информацию о составе компонентов и их отношениях.

Программное обеспечение на уровнях инжиниринга и планирования процессов позволяет владельцу бизнес-процесса взглянуть на бизнес с организационной точки зрения. Уровни же управления потоками работ и прикладной системы относятся к конкретной программной реализации. Модель жизненного цикла ARIS применима к каждому из четырех уровней. Поэтому на каждом уровне любая программная система может быть описана с точки зрения определения требований, спецификации проекта и описания реализации. Отношения между уровнями АБИ рассматриваются преимущественно на уровне определения требований, например, как логически перейти от модели процесса на уровне II к модели потоков работ на уровне III. Здесь же анализируется совместимость проектной спецификации для системы моделирования на уровне I с системой workflow на уровне III, включая даже аспекты реализации.

АБИ — это прежде всего концепция, однако ее можно использовать и как инфраструктуру для разработки реальных программных продуктов. Так, концепция АБИ применяется в качестве стандартной корпоративной архитектуры в фирме IDS Prof. Scheer GmbH и основана на практических знаниях и опыте в области реальных прикладных систем.

Хотя концепция АБИ не привязана к конкретным коммерческим разработкам, она может быть использована применительно к различным продуктам ARIS, системе SAP R/3 и Siemens-Nixdorf ComUnity.

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

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

Итак, среди спектра концепций CASE-технологий сегодня архитектура ARIS представляется наиболее эффективной. Подводя итог, можно сказать, что в Архитектуре интегрированных информационных систем (ARIS) можно выделить четыре аспекта:

• концепцию ARIS (здание ARIS), представляющую собой архитектуру для описания бизнес-процессов;

• концепцию ARIS, предлагающую методы моделирования, мегаструктуры которых представлены в информационных моделях;

• концепцию ARIS как фундамент прикладной системы ARIS Toolset, разработанной фирмой IDS Scheer AG для поддержки процесса моделирования;

• ARIS—архитектуру бизнес-инжиниринга (АБИ), представляющую концепцию комплексного автоматизированного управления бизнес-процессами.

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