Совокупность стилей изменения

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

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

Изменения ролей

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

6.8.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"). Инфраструктура моделирования CIMO­SA представляется в форме куба (рис. 6.11).

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

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

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

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

Третья ось ("поэтапная генерация") опи­сывает различные типы моделей информа­ционной системы. Цели этой "проекции" направлены на создание типов описаний.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В рамках каждого типа представления со­здаются модели, отражающие ту или иную сто­рону исследуемой системы. Методология ARIS включает большое количество методов модели­рования, в том числе, известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление информацией предполагает планирование, регулирование и внедрение "информационного" ресурса. Здесь можно выделить три аспекта: управление инфраструктурой (управление информационными технологиями), управление прикладной системой и управление внедрением информационных систем. Эти определения вписываются в концепцию ARIS. Перв­ая задача, связанная с инфраструктурой, охватывает уровни информационных техно­логий и спецификации проекта, представ­ленные на рис.6.16.

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

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

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

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

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

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

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

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

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

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

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

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

Пятый компонент концепции АБИ объеди­няет уровни I–IV в единую инфраструктуру. Инфраструктуры содержат информацию о соответствующей архитектуре и приложе­ниях, конфигурируя реальные приложения с помощью инструментария уровней II и III, a информацию по предметной области для них – из моделей-прототипов (уровень 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-технологии открывают широкие возможности в исследовании организационных структур на основе эффективного моделирования бизнес-процессов и позволяют обеспечить разработку информационных систем управления фирм и корпораций, что создает таким экономическим системам конкурентные преимущества на современном рынке.