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

Министерство образования и науки Российской Федерации Федеральное агентство по образованию РФ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ В.А. Силич, М.П. Силич РЕИНЖИНИРИНГ БИЗНЕС-ПРОЦЕССОВ Учебное пособие Рекомендовано Сибирским региональным учебно-методическим центром высшего профессионального образования для межвузовского использования в качестве учебного пособия для студентов вузов, обучающихся по направлению «Информатика и вычислительная техника» Томск 2006 УДК 681.518:339.13 ББК С Рецензенты: кафедра экономики Томского политехнического университета, канд. техн. наук доцент Гвоздев Н.И. профессор кафедры cистемного анализа и управления Томского государственного университета д-р техн. наук Тарасенко В.Ф. Силич В.А., Силич М.П. С Реинжиниринг бизнес-процессов: Учебное пособие. — Томск: Томск. гос. ун-т систем управления и радиоэлектроники, 2006. — 136 с. ISBN Учебное пособие посвящено рассмотрению технологии реинжиниринга бизнес-процессов – нового направления в теории менеджмента. Описаны предпосылки возникновения реинжиниринга и примеры его применения. Рассмотрены принципы проведения реинжиниринга. Большое внимание уделено методологиям моделирования бизнес-процессов. Подробно описана технология реинжиниринга и инструментальные средства поддержки его проведения. Учебное пособие предназначено для студентов специальностей «Государственное и муниципальное управление», «Бизнес-информатика», «Прикладная информатика (в экономике)», а также может быть полезно для бизнесменов, руководителей предприятий, специалистов в области менеджмента и информационных технологий. УДК 681.518:339.13 ББК  Томск. ун-т систем управления и радиоэлектроники, 2006 ISBN  Силич В.А., Силич М.П. 2006 ОГЛАВЛЕНИЕ Введение ………………………………………………….. 5 1. основы технологии реинжиниринга бизнес- роцессов……………………………………. 9 1.1. Предпосылки возникновения технологии BPR ……. 9 1.2. Понятие реинжиниринга бизнес-процессов ……… 16 1.3. Средства реинжиниринга бизнес-процессов ………. 20 1.4. Примеры применения реинжиниринга …………….. 26 1.5. Факторы успеха и риска неудач ……………………. 31 Контрольные вопросы и упражнения …………………... 36 2. Методология моделирования бизнес- процессов ……………………………………………… 38 2.1. Требования к моделям бизнес-процессов ………… 38 2.2. Моделирование бизнеса на языке UML …………… 43 2.2.1. Объектно-ориентированный язык UML ……… 43 2.2.2. Прецедентная модель бизнес-процесса ………. 47 2.2.3. Объектная модель бизнес-процесса …………... 54 2.3. Моделирование бизнеса с помощью методологии IDEF ………………………………………………….. 62 2.3.1. Методология моделирования IDEF …………… 62 2.3.2. Основные элементы IDEF0-методологии …… 63 2.3.3. IDEF0-модель бизнес-процесса ……………… 67 2.3.4. Функционально-стоимостной анализ бизнес-процесса ……………………………………………….. 70 Контрольные вопросы и упражнения ………………….. 73 3. Принципы проведения реинжиниринга …… 75 3.1. Эвристические правила реконструкции бизнеса … 75 3.2. Роль новых информационных технологий в реинжиниринге …………………………………………. 88 3.3. Организационная структура новой компании …….. 96 3.4. Последствия реинжиниринга ………………………. 101 Контрольные вопросы и упражнения ………………….. 105 4. Технология реинжиниринга ………………….. 108 4.1. Директива на проведение реинжиниринга ………… 108 4.2. Подготовительный этап …………………………… 111 4.3. Этап визуализации ………………………………… 122 4.4. Этап обратного инжиниринга ………………………. 129 4.5. Этап прямого инжиниринга ………………………… 133 4.5.1. Построение модели нового бизнеса ………….. 133 4.5.2. Разработка новой организационной структуры 138 4.5.3. Построение информационной системы поддержки ………………………………………. 141 4.6. Тестирование и внедрение нового бизнеса ………... 150 Контрольные вопросы и упражнения ………………… 151 5. инструментальные средства поддержки проведения реинжиниринга ……………………… 153 5.1. Классификация инструментальных средств …………. 153 5.2. Инструментальное средство BPwin …………………... 162 5.3. CASE-средство Rational Rose …………………………. 166 5.4. Средство имитационного моделирования ARENA …. 172 5.5. Интегрированная среда ARIS ………………………… 177 Контрольные вопросы и упражнения …………………... 183 ЗАКЛЮЧЕНИЕ ……………………………………………….. 184 ЛИТЕРАТУРА ………………………………………………… 185 Краткий словарь ………………………………………… 188 Приложение. Методические указания по выполнению курсовой работы по дисциплине «Реинжиниринг бизнес-процессов» ……………………………………………………... 192 ВВЕДЕНИЕ Реинжиниринг бизнес-процессов (Business process reengi-neering, BPR) возник в начале 90-х годов XX века. Одним из первых основополагающих трудов по данному направлению явилась книга М. Хаммера и Дж. Чампи «Реинжиниринг корпораций: революция в бизнесе» ([1]), изданная в 1993 г. В ней М. Хаммер определил реинжиниринг бизнес-процессов, как «фундаментальное переосмысление и радикальное перепроектирование деловых процессов для достижения резких, скачкообразных улучшений в решающих современных показателях деятельности компании, таких как стоимость, качество, сервис и темпы» [1]. Необходимость реинжиниринга вызвана ускорением темпов изменения внешней и внутренней среды компаний. Возросшая конкуренция, быстрые технологические изменения, постоянно меняющиеся потребности клиентов вынуждают компании искать более гибкие способы ведения бизнеса, обеспечивающие высокое качество и конкурентоспособность продукции. Традиционные подходы, основанные на функциональном разделении труда, оказались неэффективными в современных условиях из-за громоздкости иерархических структур управления, длительности бюрократических процедур обмена информацией и принятия решений, незаинтересованности функциональных подразделений в общих результатах деятельности компании. Процессный подход, возникший еще в середине XX века, позволяет успешно решать перечисленные проблемы. Одной из наиболее эффективных концепций менеджмента, ориентированных на процессы, по признанию многих авторов является реинжиниринг. Основная суть данной технологии состоит в том, чтобы переосмыслить правила и предположения (зачастую явно не выраженные), положенные в основу текущего способа ведения бизнеса, полностью перепроектировать бизнес-процессы на новых принципах. Эти принципы направлены, в первую очередь, на упрощение организационных отношений и потоков информации, а также на предоставление большей самостоятельности работникам, устранение лишних «управленцев». Происходит замена существующих громоздких и забюрократизированных процессов на новые, упрощенные и более гибкие. При этом реконструкция бизнес-процессов, как правило, становится возможной только при использовании информационных технологий (ИТ), т.к. именно они зачастую позволяют кардинально изменить сущность процессов. Следствием реконструкции бизнес-процессов становится изменение организационных отношений. Предлагаются новые правила построения организационных структур реконструируемых компаний, с тем, чтобы структуры отвечали новым правилам ведения бизнеса. Новое научно-прикладное направление «Реинжиниринг бизнес-процессов» находится на стыке наук. Оно использует методы следующих научных дисциплин: 1. Теория менеджмента. Возникновение и развитие концепций менеджмента, ориентированных на процессы и на синхронизацию бизнеса с потребностями клиентов и потребителей, а именно: CPI (Непрерывное усовершенствование процессов), TQM (тотальное управление качеством), Just-in-time Manufac-turing (производство «как раз вовремя») и др. подготовило почву для появления технологии реинжиниринга бизнес-процессов. Принципы реинжиниринга, в частности, эвристические правила реконструкции бизнеса и новые принципы построения организационных структур, базируются на новейших тенденциях в организации бизнеса, выявленных и описанных в рамках таких направлений теории менеджмента, как «теория организации», «маркетинговое управление производством». 2. Системный анализ. Аппарат системного анализа составляет методологическую основу реинжиниринга. Подход к построению бизнеса, при котором объектом рассмотрения являются процессы в целом, а не их отдельные части – производственные функции и технологические операции – есть отражение принципа системности. Неудивительно, что методы системного анализа лежат в основе большинства используемых в реинжиниринге методов моделирования и анализа бизнес-процессов. Сам процесс реинжиниринга также рассматривается с системных позиций. Последовательность его проведения базируется на системной методологии ликвидации проблем, включающей этапы постановки целей, анализа существующей системы, выработки решений, организации выполнения решений и анализа результатов. Именно методологически продуманный регламент выполнения BPR позволяет называть его технологией. 3. Информационные технологии. Применение новых ИТ - важнейшая часть реинжиниринга, во многом определяющая направления реконструкции бизнес-процессов. Знание достижений в области ИТ позволяет реорганизовать процессы на новых принципах, с использованием компьютерных систем. Кроме того, сам процесс реинжиниринга, как правило, осуществляется с применением компьютерных средств поддержки, что позволяет существенно снизить риск неудачи. В частности, в практике реинжиниринга широко используются средства управления проектом, CASE-средства (Computer-Aided Software Engineering, CASE), средства имитационного моделирования, инженерии знаний и др. Наибольшее распространение получили средства, основанные на объектно-ориентированном подходе, в связи с чем методологии объектно-ориентированного анализа и моделирования, изначально созданные для разработки информационных систем, стали доминирующими в BPR. 4. Социопсихология, психология труда. Методы этих наук используются для формирования мотивации как у участников команды по реинжинирингу, так и у сотрудников компании, проводящей реинжиниринг. Вопросы мотивации играют важную роль, т.к. последствиями реинжинирнга являются значительные изменения в содержании работ, системе оценок, ценностей и убеждений. Такие изменения могут вызвать у значительной части сотрудников компании обеспокоенность и даже негативное отношение к осуществляемым преобразованиям. В настоящее время накоплен немалый теоретический и практический материал по технологии реинжиниринга, издано множество книг и статей, преимущественно зарубежных авторов. Однако литературы на русском языке издано немного. Наиболее известной и цитируемой является книга Е.Г. Ойхмана и Э.В. Попова «Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии» [2]. В связи с тем, что реинжиниринг стал включаться в учебные программы вузов, возникла потребность в учебной литературе. Настоящее учебное пособие содержит не только теоретические основы реинжиниринга бизнес-процессов, его основные идеи и принципы, но и описание инструментов, средств проведения BPR – регламента технологии, методов моделирования бизнеса, а также инструментальных средств поддержки. Пособие содержит пять разделов и приложения. В первом разделе рассматриваются предпосылки возникновения технологии BPR, даются определения основных понятий, приводятся примеры применения реинжиниринга, факторы успеха и причины неудач. Второй раздел посвящен методам моделирования бизнес-процессов. Приводится классификация методов и характеристика наиболее распространенных методов. Наибольшее внимание уделено объектно-ориентированной методологии моделирования, в частности построению моделей бизнеса с помощью языка UML (Unified Modeling Language), ставшего в настоящее время фактически стандартом в области объектно-ориентированного моделирования. В третьем разделе описаны принципы реинжиниринга – эвристические правила реконструкции бизнеса, использование информационных технологий для изменения старых правил ведения бизнеса на новые, новые принципы построения организационных структур, ориентированных на процессы. Особенностью изложения данного раздела является использование моделей в нотации UML для иллюстрации материала. Четвертый раздел содержит подробное описание технологической последовательности проведения реинижиниринга, начиная от директивы на его проведение и заканчивая внедрением. Материал данной главы лег в основу методических рекомендаций для выполнения курсовой работы по дисциплине «Реинжиниринг бизнес-процессов», приведенных в приложении. Пятый раздел посвящен инструментальным средствам поддержки BPR. Приводится их классификация и анализ возможностей, приводится краткая характеристика наиболее распространенных средств. Материал данного учебного пособия был использован авторами при чтении лекций по дисциплине «Реинжиниринг бизнес-процессов» в Томском государственном политехническом университете и Томском государственном университете систем управления и радиоэлектроники. 1. основы технологии реинжиниринга бизнес-процессов 1.1. Предпосылки возникновения технологии BPR Долгие годы компании (предприятия, фирмы, корпорации) ориентировались на традиционные способы организации производства и управления, опирающиеся на классическую теорию менеджмента, восходящую своими корнями к экономической теории Адама Смита. А.Смит в своем фундаментальном труде «Благосостояние нации», опубликованном в 1776 г., сформулировал принципы организации труда в промышленности, которые оказались по-настоящему революционными для того времени. Производственный процесс предполагалось разбить на элементарные, простые задания (работы), каждое из которых мог выполнить один рабочий. Предполагалось, что исполнители имеют низкую квалификацию, у них мало времени и способностей ее повысить. От рабочего не требовалось умения выполнять работу в целом – достаточно, чтобы он специализировался на одном или на нескольких простейших заданиях. Адам Смит утверждал, что люди работают наиболее эффективно, когда они выполняют простую и легко понятную задачу. Преимущества специализации были проиллюстрированы им на примере мануфактуры по производству булавок. Один рабочий, выполняя все операции самостоятельно, мог производить не более 20 булавок в день. В мануфактуре один рабочий тянул проволоку, другой — выпрямлял ее, третий — обрезал и т.д. Такая специализация позволила десяти работникам производить 48000 булавок ежедневно [3]. Последовательным сторонником специализации был основатель теории «научного управления» Фредерик У. Тейлор (1856–1915 гг.). Основные положения, предложенные им: разделение функций по выполнению работ, по планированию работ и по руководству низовыми звеньями; стандартизация и нормирование труда; использование сдельно-премиальной заработной платы, отбор и обучение рабочих. Анри Файоль описал классические принципы построения организационной структуры, основанной на специализации. Он предложил четырнадцать принципов управления, таких как: разделение труда, единоначалие, централизация, соответствие полномочий и ответственности, единство цели и руководства, принцип скалярной цепи (соподчиненной цепи руководителей от высшей власти до низшего уровня) и др. [4] Линейно-функциональная организационная структура, отвечающая принципам классической теории менеджмента, представляет собой иерархию. В непосредственном подчинении руководителя организации находятся менеджеры, руководящие выполнением той или иной функции — производством, материально-техническим снабжением, маркетингом, сбытом, финансами и т.д. Функции подлежат дальнейшему дроблению и им сопоставляются управляющие более низкого уровня, и так вплоть до исполнительского уровня (рис. 1.1). Такая структура обеспечивает высокую скорость выполнения технологических операций, эффективное решение задач, стоящих перед менеджерами функциональных подразделений, специализирующихся на соответствующих функциях. Однако она имеет и существенные недостатки: 1. Громоздкость структуры управления. Чем выше специализация, тем больше создается подразделений, больше управляющих и уровней управления. Затраты на аппарат управления возрастают. Кроме того, усложняется координация действий функциональных подразделений. Межфункциональные проблемы решаются, как правило, центральным руководством. При этом возникают очень длинные пути прохождения информации (см. рис. 1.1), что негативным образом сказывается на оперативности решения проблем. Структура управления, таким образом, очень медленно реагирует на изменения внешних и внутренних условий. 2. Незаинтересованность в конечном результате. Функциональная ориентация приводит к тому, что менеджеры заинтересованы, в первую очередь, в эффективности выполнения только собственных задач. Ответственность за общий результат лежит только на центральном руководстве. В такой организации очень трудно проследить вклад каждого участника общего процесса в качество конечной продукции и общую прибыльность. Узкопрофессиональная близорукость препятствует инновационной деятельности, стремлению к широким перспективам. 3. Неудовлетворенность работников содержанием труда. При узкой специализации работа сотрудников компании становится однообразной, шаблонной. Исследования показали, что большинству людей не нравится рутинная работа или работа в узких рамках. Прогулы, текучесть кадров нередко являются реакцией работников на монотонность труда [4] Принципы классической теории менеджмента были и остаются весьма эффективными в массовом производстве типовой продукции, выполняемой силами большой армии низко квалифицированных рабочих, использующих простое оборудование. Однако с развитием индустрии классические принципы тейлоризма все менее соответствовали новым требованиям [2]: • продукция перестала быть массовой и должна ориентироваться на узкие группы потребителей; • рынок продуктов стал намного шире, а конкуренция и борьба за потребителя – более агрессивной; • исполнители хорошо образованы, стремятся к ответственности и решению по-настоящему сложных задач. Все это заставляет компании все больше ориентироваться не на производительность, а на удовлетворение требований пользователей, на быструю адаптацию к изменениям рынков и технологий, на дебюрократизацию и привлечение персонала к принятию решений. Одной из первых концепций менеджмента, ориентированных на синхронизацию производства с потребностями потребителя и повышение роли отдельных исполнителей, является подход «Непрерывное усовершенствование процессов» (Continuous Process Improvement, CPI), разработанный Э. Демингом в 40-е годы ХХ века. Деминг предложил четырнадцать принципов управления, основными из которых являются следующие [5]: • ставится цель постоянного повышения качества продуктов и услуг (в отличие от повышения производительности «любой ценой»), причем критерии качества исходят от потребителя; • организация работ для этого трансформируется и динамично совершенствуется; • исследуются и устраняются недостатки производственной системы, а не отдельных работников; • в центр внимания ставится не числовой показатель результата той или иной производственной функции или деятельности, а качество процесса ее выполнения; • снимаются барьеры, установленные производственными подразделениями, организуется групповая (командная) работа; • повышается роль решений и инициативы каждого работника. Деминг начал вводить в практику этот подход в 40-е - 50-е годы в промышленном производстве. Несколько лет его работы консультантом в Японии привели к тому, что он считается одним из отцов «японского чуда». При этом сам Деминг указывал, что трансформация экономики Японии стала возможной после того, как соответствующие идеи превратились в национальную идеологию на производстве. Ключевой эффект состоял в следующем. Несколько талантливых японских инженеров обнаружили, что при повышении качества продукции неизбежно происходит и увеличение производительности. Идеи технологии CPI Деминга впоследствии были использованы в новом подходе – «Глобальное управление качеством» (Total quality management, TQM), разработанном в Японии. TQM представляет собой разновидность методологий управления процессами, ориентированную на достижение результата в области повышения качества продукции за счет «увеличения достоверности качественных результатов производственных процессов», т.е. за счет введения критериев качества выполнения процессов компании. Целью менеджмента качества является постоянное совершенствование процессов, основанное на объективном измерении, для повышения удовлетворенности потребителя и соответствия его требованиям. С середины, еще более - с конца 80-х годов ХХ века темп изменений внешней и внутренней среды промышленных компаний еще более ускорился, в первую очередь за счет развития новых информационных технологий. Массовое внедрение персональной вычислительной техники, бурное развитие компьютерных коммуникаций, появление кооперативных компьютерных технологий (одновременной инженерии) не только изменили процессы внутри компаний, но и изменили способы продвижения товаров и услуг на рынке. Внешние причины возникновения BPR, в основном, связаны с изменением потребностей потребителей. Рассмотрим наиболее существенные из этих причин [5]: 1. Возросла доступность товаров и услуг производителей из любой точки мира. В результате сильно возросла конкуренция в части предложения новых товаров и повышения их качества. В современном мировом рынке конкуренция присутствует буквально повсюду. Товары уже перестали быть локальными и производятся по всему миру. Фирма не может уступать ни в чем своим конкурентам, независимо от того, где они находятся. 2. Резко возросли требования потребителей к качеству товаров и услуг любых видов, к срокам их предоставления. Клиенты больше не допускают, чтобы их рассматривали как часть безликой массы, они ожидают, что с ними будут обращаться как с индивидуальностями. Как сказал М.Хаммер [2]: «Больше не осталось понятия клиент вообще, теперь есть только именно этот клиент». Каждый отдельный клиент нуждается в продукции, которая адаптирована к его конкретным потребностям и поставляется способом, наиболее подходящим для данного клиента. 3. Из-за роста возможностей выбора, который имеют потребители, стало резко уменьшаться время жизни товара или услуги на рынке. Соответственно сокращаются сроки разработки и внедрения новых товаров и услуг. В качестве внутренних причин возникновения BPR, вынуждающих компании искать пути существенных изменений в организации производства, рассмотрим три причины [5]: 1. Рост сложности управленческих задач, связанный с ростом сложности новых продуктов. Рост числа и сложности продуктов привел к тому, что ни отдельный человек, ни даже группа людей не может знать все технические детали производства. Это справедливо и для автомобильной промышленности, и для страховых компаний, и для ресторанов «быстрой еды». 2. Непригодность дальнейшего увеличения числа сотрудников на всех уровнях предприятия. Рост числа работников на средних уровнях менеджмента компаний многие годы являлся ответом на усложнение управленческих задач. Но возникла ситуация, когда рост числа персонала перестал соответствовать росту удовлетворения клиентов. Одна из причин – высокая стоимость труда (в США). Другая причина – нелинейный рост запаздываний и ошибок в управленческих решениях при увеличении числа управленцев. 3. Недостаточная отдача от инвестиций в компьютерные системы. Расчеты на то, что использование компьютеров само по себе решит проблемы эффективного управления производством не оправдались. Пример из бизнеса США: с 60-х годов, когда компьютеры стали доступны многим предприятиям, общие затраты на них составили более двух триллионов долларов. Однако рост производительности, соответствующий росту инвестиций, не был получен. Основная причина состояла в том, что использование компьютеров не меняло организации бизнеса: не менялись траектории и объем потоков документов, точки принятия решений и их число и т.д. Ответом на новые требования явилось создание примерно в 1990 г. новой технологии BPR – Business process reengineering, которая позволила в полной мере реализовать преимущества новых информационных технологий и человеческих ресурсов с целью более полного удовлетворения потребностей потребителя. Наиболее известной является книга М. Хаммера и Дж. Чампи "Реинжиниринг корпораций: революция в бизнесе" ([1]), изданная в 1993 г. Нельзя сказать, что реинжиниринг был «изобретен» учеными, он скорее был «обнаружен» ими в ряде преуспевающих компаний, которые интуитивно использовали его основные свойства. Ученые выделили основные характерные черты реинжиниринга, систематизировали принципы и методы его проведения. Наиболее известными учеными, внесшими значительный вклад в данное направление, кроме М. Хаммера и Дж. Чампи являются Дж. Карлсон, Дж. Мартин, И Якобсон, Т. Давенпорт, Б.Виллох, Х.Юхансон. На протяжении 90-х годов новое направление вызывало активный интерес специалистов в области менеджмента и информационных технологий. Реинжиниринг стал «притчей во языцех». Раньше других (в 1992 - 1993 г.г.) реинжиниринг начал применяться в страховании, телекоммуникации и энергетике, затем он проник в химию, электронику, вычислительную технику, производство товаров широкого потребления. С 1994 г. началось активное внедрение реинжиниринга в банки и правительственные учреждения. Так, правительство США с 1994 г. организовало более 200 проектов по реинжинирингу. Число проектов по БПР в банковской сфере в 1994 г. составило 3,6 на банк. 75% из 400 крупнейших североамериканских банков увеличивают число проектов по реинжинирингу [2]. В настоящее время BPR взят на вооружение почти всеми ведущими компаниями мира. Наибольший интерес он вызвал, кроме Америки, в странах Латинской Америки и Восточной Азии. Все более растущую популярность данная технология приобретает и в нашей стране: проводятся конференции, издается литература [2, 5 - 10]. К настоящему времени по проблеме реинжиниринга написаны десятки монографий, сотни статей, материалов конференций, проводимых ежегодно. Во многих публикациях BPR Хаммера-Чампи рассматривается только как базовая идея, предлагаются собственные адаптированные или расширенные подходы к реконструкции бизнес-процессов [5]. 1.2. Понятие реинжиниринга бизнес-процессов Понятие «реинжиниринг» (англ. reengineering) – производное от понятия «инжиниринг» (англ. engineering). Инжиниринг означает проектирование, создание, построение, изобретательство. Реинжиниринг – перепроектирование, перестройка, реконструкция, реорганизация. Таким образом, в широком смысле «реинжиниринг бизнес-процессов» – это реконструкция существующих бизнес-процес-сов или перепроектирование деятельности промышленных компаний. Однако этот термин так, как он сложился к началу 90-х годов ХХ века, обозначает более узкое понятие, чем просто любое перепроектирование бизнеса. Общепринятым стало определение, данное Хаммером [1, 2]: Реинжиниринг – это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения резких, скачкообразных улучшений в решающих современных показателях деятельности компании, таких как стоимость, качество, сервис и темпы. Рассмотрим ключевые слова и фразы данного определения. Ключевое слово «бизнес-процессы». Приведем достаточно употребительное определение понятия «бизнес-процесс» [5]: «Бизнес-процессы – это логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как Продукт или Услуга». Объектом реинжиниринга являются процессы, а не компания. При традиционном подходе внимание фокусируется на отдельных функциях, работах, исполнителях. Проблема состоит в том, что процессы не удается описывать так же легко, как организационные иерархические структуры. Организационные подразделения, такие как «доставка продукции», «оплата счетов», «прием заявок», как правило, выполняют лишь узкие функции. Процессы же пронизывают организационные структуры. В них участвуют различные подразделения (рис. 1.2). Один из принципов выделения процессов – четкое указание входов и выходов процесса. Т. Давенпорт, в частности, дает следующее определение процесса: «процесс – это специфически упорядоченная совокупность работ во времени и пространстве, с указанием начала и конца и точным определением входов и выходов» [11]. В другом определении, введенном Дж. Мартином, процесс определяется через выход, полезный для клиента: процесс – это «множество законченных, состыкованных действий, которые в совокупности создают некоторую продукцию, имеющую потребительскую ценность для клиента» [12]. Кроме внешних процессов, ориентированных на внешнего заказчика, клиента, выделяют внутренние процессы, выходы которых используются внутри компании. Примерами таких внутренних процессов являются: «Разработка новой продукции», «Исследование рынка», «Внедрение новой техники». Концентрация на процессах, а не функциях, позволяет оценивать все действия с точки зрения конечного результата – соответствия требованиям клиента (причем не массового, а индивидуального), качества продукции, общей стоимости, длительности и т.д. Это позволяет наилучшим образом выполнить, то, что должно быть сделано фирмой в конечном итоге. Усовершенствование же отдельных функций, выполняемых отдельными организационными единицами, рассматриваемых вне взаимосвязи друг с другом и с конечным продуктом компании, зачастую не ведет к повышению эффективности производства в целом, а лишь закрепляет существующую технологию. Ключевая фраза «фундаментальное переосмысление». Реинжиниринг предполагает исследование и ревизию не только способов ведения деловых процессов, но и более фундаментальных вопросов – что компания делает, как и почему она это делает, и что должно быть. В ходе реинжиниринга могут быть полностью переосмыслены правила и предположения (зачастую явно не выраженные), положенные в основу текущего способа ведения бизнеса. Часто эти правила оказываются устаревшими, ошибочными или неуместными. «Реинжиниринг не начинается с заранее заданных предположений, он ничего не принимает на веру» [2]. Так, например, задача «Как более эффективно выполнить проверку пользовательского кредита?» содержит предположение, что надо осуществлять проверку кредита. Хотя во многих случаях цена проверки может превосходить потери, являющиеся следствием отсутствия проверки. Иногда лучше вообще отказаться от проверки. Ключевая фраза «радикальное перепроектирование». Приставка «радикальное» означает перепроектирование, затрагивающее суть явлений, а не поверхностные изменения. Это, скорее, изобретение, а не улучшение или модификация. Улучшения, как правило, не затрагивают последовательности действий, составляющих бизнес-процессы, не сказываются на распределении задач между подразделениями и отдельными сотрудниками, не меняют материальные и информационные потоки, циркулирующие внутри компании. Они ограничиваются ускорением выполнения отдельных операций, снижением брака, сокращением времени передачи информации между подразделениями и т.д. Реинжиниринг же кардинально меняет структуру бизнеса – технологию, организационные отношения, ценности. Ключевая фраза «для достижения резких скачкообразных улучшений». Имеется в виду улучшение показателей деятельности компании в разы и даже десятки раз, а не на 10 - 100%, как при использовании более традиционных методов, например, технологии «управления качеством» или подхода «Непрерывное усовершенствование процессов». Однако традиционные методы усовершенствования бизнеса и реинжиниринг не противоречат друг другу, а дополняют друг друга. Реинжиниринг используется периодически для радикальных преобразований, обеспечивающих существенное повышение эффективности. А в период между этими «скачками» применяются методы постепенного улучшения для «настройки» реконструированных процессов. На рис. 1.3 показаны стадии постепенных улучшений и радикальных преобразований. Ключевая фраза «улучшений в решающих современных показателях деятельности компании, таких как стоимость, качество, сервис и темпы». Данные показатели отражают основные цели реинжиниринга: • лучшее удовлетворение требований клиентов; • повышение эффективности. В конечном счете, реинжиниринг направлен на повышение конкурентоспособности компаний в условиях быстрых и существенных изменений в потребностях клиентов, в рынках сбыта и технологиях. Можно выделить три типа компаний, для которых применение реинжиниринга необходимо и целесообразно [2]: 1. Компании, находящиеся на грани краха в связи с тем, что цены на товары заметно выше, чем у конкурентов, а качество товаров и сервис - значительно ниже. У этих компаний нет выбора: если они не предпримут решительных шагов, они неизбежно разорятся. 2. Компании, не находящиеся в текущий момент в затруднительном положении, но руководство компаний предвидит неизбежность возникновения трудноразрешимых проблем, связанных, например, с появлением новых конкурентов, изменением требований клиентов, изменением экономического окружения и т.п. 3. Компании, не имеющие проблем ни сейчас, ни в ближайшем обозримом будущем. Это компании-лидеры. Они не удовлетворяются текущим хорошим состоянием и с помощью реинжиниринга хотят добиться лучшего. 1.3. Средства реинжиниринга бизнес-процессов Рассмотренное определение реинжиниринга бизнес-процессов дает представление о сущности и результатах данной технологии, однако оно не отвечает на вопрос, за счет чего достигаются цели реинжиниринга, каковы средства его проведения. Реинжиниринг представляет собой технологию, т.е. это упорядоченная последовательность этапов реконструкции бизнеса, для каждого из которых определены состав работ, исходные данные, результаты, используемые методы, инструментальные средства и т.д. Именно такая организация проектирования, основанная на четко выстроенных процессах, позволяет называть BPR технологией. Это новый способ построения компании – взгляд на данный процесс, как на инженерную деятельность. Благодаря хорошо продуманной технологии реинжиниринг становится доступным для большинства компаний, несмотря на то, что это очень сложный и творческий процесс. Использование технологической поддержки позволяет значительно снизить риск неудач. Технологическая последовательность проведения реинжинрига, включает четыре основных этапа (рис. 1.4): На этапе "визуализация" формируется образ будущей компании, определяются ее цели. Спецификацию целей компании предлагается осуществлять на основе анализа окружения – потребителей, клиентов, отрасли, к которой принадлежит компания, ведущих фирм смежных отраслей. По результатам анализа определяется новая стратегия компании, строятся прототипы – сценарии будущего, формируется высокоуровневое описание будущих процессов, определяется список факторов успеха и риска. На этапе "обратный инжиниринг" осуществляется анализ состояния дел. Если предыдущий этап включал в себя, в основном, анализ внешней среды компании, то на данном этапе осуществляется детальное описание существующего состояния самой компании. Результатом работ является модель существующего бизнеса. Поскольку модель существующего бизнеса оказывает влияние на формирование целей новой компании, может быть осуществлен возврат к этапу визуализации для корректировки целей. На этапе "прямой инжиниринг" осуществляется проектирование нового бизнеса. Отталкиваясь от результатов анализа модели существующего бизнеса, в соответствии с образом будущей компании формируется модель нового бизнеса. Она включает в себя описание новых, реконструированных бизнес-процессов. На основе модели бизнеса осуществляется изменение организационной структуры, а также разработка новых информационных систем. Таким образом, прямой инжиниринг предполагает выполнение подэтапов, соответствующих перепроектированию бизнес-процессов, разработке подсистемы организационного взаимодействия и разработке подсистемы информационной поддержки. На этапе "внедрение" кроме собственно внедрения новых бизнес-процессов происходит их оценка и тестирование, по результатам которого может быть принято решение о проведении следующей итерации реинжиниринга. Технологией BPR кроме перечисленных основных этапов предусматривается и подготовительный этап – создание системы управления процессом реинжиниринга. На данном этапе выделяются участники проекта реинжиниринга, для каждого из них определяются роли и обязанности, факторы мотивации их деятельности, определяется структура их взаимодействия. Выполнение этапов BPR предполагает использование инструментов реинжиниринга – регламента проведения реинжиниринга, методологий моделирования бизнес-процессов и компьютерных инструментальных средств поддержки, а также применение новых подходов к реконструкции бизнеса, так называемых принципов реинжиниринга (рис. 1.5). Регламент представляет собой руководящие указания по технологии проведения реинжиниринга. Он содержит рекомендации относительно содержания работ, их взаимосвязи, исходной информации и результатов, используемых методов, инструментальных средств, организации работы, мотивации и т.д. Разными авторами предлагаются разные варианты регламента: одни делают упор на финансовый анализ, другие – на организационный инжиниринг, трети – на компьютерное моделирование. В каждом конкретном случае, приступая к выполнению проекта по реинжинирингу, участникам проекта необходимо разработать собственный план, основываясь на рекомендациях. Основным инструментом анализа и проектирования бизнес-процессов является моделирование. Модели позволяют «визуализировать» информацию о том, как работает компания, представить бизнес-процессы в наглядном виде (в виде схем, диаграмм). Сложность состоит в том, что в одной модели невозможно отразить деятельность компании. Необходимо построить набор согласованных моделей, которые описывают различные аспекты компании. Существует множество различных видов моделей и различных методологий моделирования. При выборе методологии предпочтение следует отдавать тем, которые интегрируют различные методы на базе единого подхода. Примером может служить объектно-ориентрованный язык моделирования UML, объединяющий методы построения восьми видов диаграмм. Он позволяет последовательно строить связанные друг с другом модели, начиная от модели, представляющей общую концептуальную схему деятельности компании, переходя к моделям, описывающим последовательность шагов бизнес-процессов, объекты, участвующие в процессах и т.д. Инструментальные средства поддержки проведения реинжиниринга в виде компьютерных информационных систем специального назначения могут существенно облегчить процесс проведения реинжиниринга за счет автоматизации основных этапов. Они не только упрощают процесс моделирования, но и позволяют анализировать модели, выявлять характеристики моделируемых бизнес-процессов – стоимостные, ресурсные, характеристики времени. Реконструкция бизнес-процессов на этапе прямого инжиниринга осуществляется с применением принципов реинжиниринга, к которым относятся: 1. Эвристические правила реконструкции бизнеса. Они направлены, в первую очередь, на упрощение организационных отношений и потоков информации, на предоставление большей самостоятельности работникам, устранение лишних управленцев. Применение данных правил предполагает не «улучшение» существующих процессов, например, с помощью автоматизации или административно-управленческих приемов (усиление контроля, повышение мотивации и т.д.), а замену существующих громоздких и забюрократизированных процессов на новые, упрощенные и более гибкие. Хаммер выдвинул лозунг[5]: «Реконструируйте работы не автоматизацией, а упрощением или удалением». Такой подход, который можно назвать проектированием «с чистого листа», позволяет преодолеть негативное воздействие сложившихся хозяйственных догм и добиться впечатляющих результатов. Это коренное отличие технологии BPR от других распространенных концепций менеджмента, ориентированных на процессы – TQM, CPI, Just-in-time Manufacturing и др. 2. Использование новых информационных технологий. Информационные технологии играют критически важную роль в BPR. Они рассматриваются как важная составная часть производственных процессов. Но реинжиниринг – это не то же самое что автоматизация, при которой с помощью ИТ автоматизируются существующие бизнес-процессы со всеми их недостатками. Реинжиниринг использует ИТ для автоматизации новых, реконструированных процессов. Более того, сама реконструкция бизнес-процессов, как правило, становится возможной только при использовании информационных технологий, т.к. ИТ зачастую меняют сущность процессов. Например, технология экспертных систем позволяет изменить старое правило: «Сложную работу могут выполнить только эксперты» на новое: «Функции эксперта может выполнить менеджер, снабженный экспертной системой». В результате применения этого правила могут быть изменены бизнес-процессы компании. Новая роль информационных технологий нашла отражение в следующем лозунге, выдвинутом Хаммером [5]: «Используйте компьютеры не только для автоматизации, но и для реконструкции существующих бизнес-процессов». 3. Новые правила построения организационных структур. Оргструктуры реконструируемых компаний должны отвечать новым правилам ведения бизнеса. Традиционные иерархические функционально-линейные структуры, сложившиеся еще в XIX веке, незаменимы для управления сложными многоступенчатыми процессами, разбитыми на отдельные фрагменты. «Бюрократия – это клей, соединяющий вместе подразделения традиционной организации» [2]. Однако бюрократизация несет с собой такие негативные последствия как громоздкость, медлительность, негибкость и др. Попытки снизить размерность и ускорить принятие решений привели в средине XX века к созданию дивизиональных структур, предполагающих автономность отделений, выделенных по территориальному или продуктовому признаку. Чуть позже появились матричные структуры, в которых персонал перемешается от функциональных подразделений к проектным группам – от одной к другой, туда, где требуются их умения. В 80-е г.г. в рамках общей тенденции к дезинтеграции сформировался еще один вид структур – сети, представляющие собой сеть сотрудничающих производственных единиц, координируемых рыночными механизмами [4, 13]. Бурное развитие средств автоматизации производства, активное внедрение информационных систем управления и компьютерных коммуникаций (локальных и глобальных сетей) предоставило новые возможности для дебюрократизации организационных структур. Появилась возможность исключить необходимость передачи бумажных документов, ненужных переездов для проведения совещаний, длительных процедур создания документов, их передачи и согласования. Использование информационных систем поддержки принятия решений, экспертных систем позволило предоставить исполнителям возможность самим принимать решения, оперативно получая всю необходимую информацию из интегрированных баз данных. Все это обеспечивает возможности устранения лишних управленцев, а также совместной работы специалистов различных подразделений. Рабочие группы, опирающиеся на информационные технологии, не используют бюрократические способы управления. Они по-новому организуют распределение прав и обязанностей работников: возрастает значимость таких факторов, как самостоятельность, самореализация, нацеленность на конечный результат. Такой тип отношений был взят на вооружение BPR. Хаммер писал: «Самым последним делом в реинжинириинге является чувство собственной значимости менеджеров, поскольку одна из вещей, диктуемых реинжинирингом, состоит в том, что "заведующий - это не так уж важно"» [5]. Появился новый тип организационных структур – «процессная» структура, воплотившая некоторые черты матричной и сетевой структур. Необходимо подчеркнуть, что изменение организационной структуры не является самоцелью BPR. Это следствие реконструкции бизнес-процессов на основе использования ИТ. Только изменив процессы можно избавиться от бюрократии и перейти к новым организационным отношениям. 1.4. Примеры применения реинжиниринга Приведем несколько примеров успешного реинжиниринга, которые помогут уяснить сущность и методы технологии BPR [1, 2]. 1. Опыт IBM Credit. IBM Credit Corporation является филиалом IBM и занимается кредитованием клиентов, которым IBM продает компьютеры, программы и предоставляет услуги. Проблема IBM Credit состояла в том, что при существующем технологическом цикле решение вопроса о кредитовании клиента занимало в среднем неделю, а в сложных случаях – до двух недель. Чрезмерная длительность принятия решений приводила к потере клиента, так как он за это время мог найти другой источник финансирования. Длительность принятия решения по запросу клиента была вызвана тем, что обработка запроса осуществлялась в пять этапов (30 шагов), выполняемых последовательно в пяти различных подразделениях компании. При этом передача запроса из одного подразделения в другое осуществлялось на бумажном носителе. Компания поручила двум старшим менеджерам самим пройти с несколькими запросами клиентов все пять шагов. При этом они просили исполнителей обрабатывать запросы без задержки. Эксперимент показал, что собственно на обработку запроса затрачивается всего 90 мин., а остальное время расходуется на передачу запроса из одного подразделения в другое. Таким образом, оказалось, что проблема заключена не в эффективности, с которой работают специалисты, а в структуре процесса обработки. Итак, для решения проблемы необходимо было изменить процесс, а не его отдельные шаги. В основе используемого способа обработки лежало предположение, что каждый запрос является сложной задачей, требующей для ее решения участия экспертов разных специальностей. Анализ показал, что это предположение ошибочно, так как большинство запросов являются простыми и их обработка сводится к работе с базой данных, что может сделать обыкновенный клерк. В новом процессе всю обработку выполняет один специалист, снабженный информационной экспертной системой, обеспечивающей принятие решения и доступ ко всем необходимым данным и инструментариям. Теперь в большинстве случаев (более 90% запросов) один специалист обеспечивает решение задачи. В трудных случаях специалист обращается к экспертам. В результате реинжиниринга IBM Credit радикально перепроектировала процесс обработки и достигла скачкообразного улучшения основных показателей деятельности компании: время обработки запроса сокращено с 7 дней до 4-х часов, количество обрабатываемых запросов возросло в 100 раз при уменьшении количества сотрудников. 2. Опыт Ford Motor. В начале 80-х г.г. компания Ford подобно многим другим компаниям Америки искала способы сокращения административных расходов. Было решено сократить расходы в отделении оплаты счетов, где работало более 500 человек. Руководство Ford узнало, что в компании Mazda оплатой счетов занимается всего 5 человек. Хотя Mazda меньше, чем Ford, но явно не в 100 раз. Сначала предполагалось, что сократить число сотрудников можно за счет автоматизации, но это могло дать только 20%-е сокращение. Тогда руководство Ford приняло решение переосмыслить весь процесс, в котором участвует отделение оплаты счетов. Отделение счетов само по себе не могло быть подвергнуто реинжинирингу, так как это подразделение, а не процесс. Процесс в целом, называемый «поставки», начинается с того, что департамент заказов посылает продавцу товаров заказ на их приобретение. При этом копия заказа отправляется в отделение оплаты счетов. Когда продавец отправил товары, и они прибыли в компанию Ford, клерк из отдела получения товаров составляет документ получения и отправляет его в департамент оплаты счетов. Тем временем продавец посылает в отделение оплаты счетов накладную на товары. К этому времени в отделении оплаты счетов находятся три документа на эти товары: заказ на приобретение, документ получения и накладная. Если все три документа соответствуют друг другу (в большинстве случаев именно эта ситуация и имеет место), то клерк оплачивает счет. При несоответствии документов необходимо найти источник ошибки. Основное время в своей работе клерк как раз и тратит на обработку именно таких ситуаций. Новый процесс оплаты счетов, разработанный в компании Ford в ходе реинжиниринга, радикально отличается от старого. Отделение заказов посылает продавцу заказ и одновременно вводит этот заказ в базу данных. Затем продавец посылает заказанные товары в отдел получения. Когда товары поступают в отдел получения, клерк через компьютерный терминал проверяет соответствие присланных товаров товарам, перечисленным в заказе и хранящимся в базе данных. Если соответствие есть, то клерк принимает товары и вводит информацию об этом в базу данных. Компьютер, получив информацию о прибытии товаров, автоматически отправляет продавцу чек об оплате товаров. Если соответствия нет, то клерк отвергает груз и отправляет его обратно продавцу. Суть изменений, проведенных компанией Ford, состоит в авторизации оплаты, выполняемой в отделе получения. Процесс реинжиниринга отменил старое правило бизнеса: «Мы платим, когда получаем накладную» и заменил его на новое: «Мы платим, когда получаем товар». Фактически новый процесс устранил накладную и департамент оплаты счетов. Это привело к существенному сокращению количества сотрудников: весь процесс поставок стало осуществлять 125 человек. 3. Опыт Kodak. В 1987 г. основной конкурент Kodak компания Fuji объявила о выпуске новой 35-мм камеры. Компания Kodak не вела исследования в этом перспективном направлении. Традиционный для Kodak цикл от начала разработки нового изделия до его производства составлял 70 недель. Такое длительное отставание от Fuji позволило бы последней получить большие преимущества на новом перспективном рынке. Для того, чтобы сократить этот цикл, Kodak решила провести реинжиниринг процесса разработки нового продукта. Разработка продукта может выполняться последовательно или параллельно. При последовательной разработке весь проект разбивается на шаги и переход к очередному шагу осуществляется только тогда, когда полностью завершен предыдущий. Очевидно, что при последовательном подходе время разработки больше, чем при параллельном, но при этом подходе меньше объем работ, так как не приходится устранять несоответствия между компонентами, разработанными на параллельно выполняемых шагах. Как правило, несоответствия неизбежны при параллельном подходе. Чтобы ускорить выпуск нового изделия, компания Kodak решила провести реинжиниринг процесса разработки. Было принято решение использовать при разработке последовательно-параллельный подход (т.е. некоторые части камеры разрабатываются одновременно) с использованием технологии CAD/CAM (Computer Aided Design/ Computer Aided Manufacturing). Эта технология позволяет проектировать изделия непосредственно на экране компьютера, не прибегая к чертежам на бумаге, что значительно ускоряет разработку. Использование технологии CAD/CAM и интегрированной базы данных (БД), хранящей текущее состояние проекта, позволило применить параллельный подход. Каждый день в БД добавлялись результаты, полученные параллельно работающими группами. Каждый вечер группа проектировщиков инспектировала БД с целью поиска несоответствий между результатами работы параллельно работающих групп. Если несоответствия обнаруживались, то они тут же исправлялись. При используемой ранее технологии разработки несоответствия могли быть обнаружены только через недели или месяцы, когда параллельно разработанные части собирались вместе. Новый процесс разработки, использованный компанией Kodak, называется одновременной инженерией. Этот подход использовался раньше в космической индустрии. Новый процесс разработки позволил сократить срок выпуска нового продукта с 70 недель до 38 недель. Более того, так как новый процесс позволяет промоделировать сборку продукта до его изготовления, стало возможным выбирать те конструкции, которые проще и дешевле в производстве. Благодаря этому Kodak уменьшила стоимость вновь спроектированной камеры на 25%. Все рассмотренные выше примеры соответствуют определению реинжиниринга: • ориентация на процесс. Во всех случаях положительный результат получен благодаря ориентации не на узкую задачу, решаемую в предопределенных организационных границах, а рассмотрению всего процесса в целом; • фундаментальное переосмысление. Каждая компания неизбежно приходила к необходимости отказаться от установленных ранее незыблемых правил ведения бизнеса. IBM Credit отказалась от предположения, что каждый запрос – это сложная задача, требующая участия различных специалистов. Ford отказалась от правила платить по накладной, Kodak отказалась от линейного упорядочения работ; • радикальное перепроектирование. Новая организация бизнес-процессов кардинально отличалась от прежней. Средствами, которые позволили по-новому организовать процессы, явились новые информационные технологии и новые организационные отношения; • скачкообразные улучшения в таких показателях, как стоимость, качество, сервис и темпы. Все компании добились качественного прорыва в решении поставленных задач. Их не устраивало улучшение на 10-50%, обеспечиваемое простой автоматизацией. Они существенно увеличили темпы (IBM Credit, Kodak), снизили стоимость (Ford, Kodak), улучшили качество и сервис. 1.5. Факторы успеха и риска неудач К сожалению, кроме примеров успешного реинжиниринга немало примеров и неудач. Экспертные оценки показывают, что ранее (до 1993 г.) около 50% проектов по реинжинирингу заканчивались неудачей [2]. С целью выяснения причин неудач и определения необходимых для успеха предпосылок был проведен ряд специальных исследований, опирающийся на опросы консультантов из более чем 40 фирм, оказывающих услуги по менеджменту, информационным технологиям, реинжинирингу, формулировке стратегий бизнеса и т.п. В результате были выявлены факторы, способствующие успеху реинжиниринга и типичные ошибки приводящие к неудачам. Все факторы можно сгруппировать по следующим аспектам реинжиниринга, которые они затрагивают (рис. 1.6): • объект реинжинниринга («Что реконструировать?»); • цели («Зачем реконструировать?», «Что должно быть?»); • руководство и команда («Кто реконструирует?»); • мотивация («Почему мы реконструируем??»); • технология и принципы («Как реконструировать?»); • методы и средства («С помощью чего?»); • финансы и время («Сколько потратить?»). 1. Объект реинжиниринга. Объектом реинжиниринга являются процессы, а не работа отдельных подразделений компании. Реинжиниринг обречен на неудачу до начала работ, если ограничена область его действия или задача поставлена очень узко. Задача реинжиниринга должна быть поставлена в терминах процессов. Нельзя вместо процесса рассматривать только его некоторый фрагмент, выполняемый некоторой организационной единицей. Задача реинжиниринга не укреплять, а разрушать существующие организационные границы. Например, компания Ford в ходе реинжиниринга процесса «поставки» пришла к решению устранить накладную и отделение оплаты счетов. Это решение не могло бы быть выработано, если бы с самого начала компания Ford ограничилась бы только оптимизацией работы отделения оплаты счетов. Ограниченная постановка задачи уже предполагает способ ее решения. Реинжиниринг же начинается с определения результатов, которые должны быть достигнуты, а не с определения способов их достижения. 2. Цели реинжиниринга. Цели должны быть амбициозными. Значительные результаты достигаются только при больших амбициях руководства компании. Здесь не подходит поговорка: «Лучше синица в руках, чем журавль в небе». Наиболее грубой ошибкой, хотя довольно распространенной является попытка улучшить существующий процесс вместо того, чтобы перепроектировать его. Искушение выбрать более легкий путь, сводящийся к усовершенствованиям, оказывается довольно соблазнительным. Менеджеры, например, начинают устанавливать стандарты по эффективности работы на каждом шаге или применять улучшающие методики. Пытаются применять теорию очередей и линейное программирование, чтобы сбалансировать работы между подразделениями и минимизировать время ожидания. Однако совершенствования, как правило, усложняют существующий процесс, а их наслоения делают процесс малопонятным. Кроме того, усовершенствования требуют затрат времени и денег на существующий неэффективный процесс, усложняют управление и прививают культуру «инкрементизма» [2]. Не может привести к значительному успеху и простая автоматизация, так как она не меняет сути процесса. Более того, она увековечивает плохо организованный процесс путем запоминания его в компьютере, что усложняет проведение коренных преобразований в будущем. 3. Руководство и команда. Проект должен выполняться под управлением руководства компании, т.к. реинжиниринг требует прямой и персональной ответственности руководства. Ответственность не может быть делегирована вниз. Реинжиниринг всегда проводится «сверху – вниз». Причина состоит в том, что менеджеры нижнего и среднего уровня не обладают той широтой взглядов, которая необходима для проведения реинжиниринга. Они, как правило, ограничиваются узкими проблемами своего подразделения. Им трудно увидеть процессы в целом, т.к. бизнес-процессы пересекают организационные границы. Кроме того, радикальные преобразования процессов могут привести к уменьшению влияния отдельных менеджеров среднего уровня. Поэтому они могут препятствовать проведению реинжиниринга. Руководитель, возглавляющий проект по реинжинирингу, должен иметь большой авторитет в компании и нести за него ответственность. В команде, выполняющей проект по реинжинирингу, необходимо участие сотрудников, наделенных полномочиями. Кроме людей, хорошо понимающих реконструируемый бизнес, необходимы люди, знающие как изменить этот бизнес. Эксперты (консультанты) в области реинжиниринга могут оказать существенную помощь исполнителям. Важно подчеркнуть, что консультанты выполняют поддерживающую, а не управляющую роль. 4. Мотивация. Роль мотивации трудно переоценить. Сотрудники должны понимать, почему проект приведен в действие. Прежде всего, руководство компании должно верить в необходимость реинжиниринга и должно убедить людей в том, что проект не только выполним, но и необходим для выживания компании. Необходимо предвидеть и учесть неизбежное сопротивление преобразованиям и противопоставить ему положительную мотивацию. То, что некоторые сотрудники будут сопротивляться изменениям, вызванным реинжинирингом – это естественно. Реинжиниринг не приносит всем только радости. В результате его проведения одним сотрудникам приходится изменять характер своей работы, другие могут потерять работу. Афоризм о том, что нельзя приготовить омлет, не разбив яйца, точно отражает суть реинжиниринга. Руководитель проекта должен прилагать усилия для продвижения проекта, создания атмосферы сотрудничества и энтузиазма. После завершения проекта работа по созданию положительной мотивации не заканчивается. Для того, чтобы исполнители эффективно выполняли перепроектированные процессы, они должны иметь побудительные причины. Менеджеры должны сформировать и провести в жизнь новые системы ценностей и убеждений. 5. Технология и принципы. Применение технологии реинжиниринга позволяет рассчитывать на успех. Причины неудач проектов по реинжинирингу заключены не в его непредсказуемости и загадочности, а в незнании или нарушении технологии его проведения. Как отмечают М. Хаммер и Дж. Чампи, с точки зрения риска реинжиниринг подобен игре в шахматы, а не игре в рулетку, т.е. участники реинжиниринга в меру своих знаний и умений могут влиять на результат [1]. Одним из ключевых этапов является прямой инжиниринг, на котором разрабатывается модель новых бизнес-процессов. Участники проекта, реконструирующие бизнес, должны быть знакомы с принципами реинжиниринга, должны иметь представление о новых информационных технологиях, о возможности их использования в конкретном бизнесе. Не менее важно обеспечить реализацию задуманного нового бизнеса. Внедрение перепроектированных бизнес-процессов вызывает значительные изменения в таких областях, как проектирование работ, организационные структуры, системы управления и оценок и др. Разнообразие последствий приводит к тому, что даже менеджеры, заинтересованные в радикальном перепроектировании процессов, избегают проводить все требуемые изменения. Когда команда по реинжинирингу перечисляет руководству все необходимые преобразования, то нередко получает ответ: «Я просил вас сократить время и стоимость, а не переделывать всю компанию». Но реинжиниринг занимается как раз «переделыванием» компании. Преждевременное завершение реинжниринга – одна из распространенных ошибок. Первые трудности и, что удивительно, первые успехи, зачастую становятся предлогом для возврата к более привычному способу ведения бизнеса [2]. 6. Методы и средства. Для проведения работ по реинжинирингу необходима поддержка в форме методик и инструментальных средств. Наибольшее распространение получили CASE-средства, и, соответственно, методы моделирования, поддерживаемые современными CASE-средствами. Большинство из этих методов и инструментариев создавались для поддержки процессов разработки компьютерных информационных систем. Однако, поскольку этапу непосредственно программирования предшествует этап анализа требований к будущей программе и формирования модели автоматизируемой предметной области, CASE-средства стали все больше ориентироваться не столько на автоматизацию написания программ, сколько на моделирование бизнеса. Активное использование именно CASE-средств в проектах по реинжинирингу неслучайно, ведь разработка информационной системы поддержки нового бизнеса – неотъемлемая часть проекта. Применение одних и тех же методов и средств при разработке модели бизнеса и ИС существенно экономит время и средства. В последнее время стало появляться все больше инструментальных средств, созданных специально для реинжиниринга. Это, прежде всего, средства имитационного моделирования бизнес-процессов, а также интегрированные многофункциональные средства, предоставляющие широкий спектр возможностей – от построения статических функциональных диаграмм до имитационного моделирования и автоматической кодогенерации программ. 7. Финансы и время. Проект по реинжинирингу должен иметь свой собственный бюджет. Достижение высоких результатов невозможно без существенных инвестиций. Для успеха реинжиниринга необходимо выделить достаточное количество ресурсов, прежде всего затрат времени и работы наиболее ответственных людей компании. Руководство должно уделять реинжинирингу основное внимание. Реинжиниринг не должен осуществляться на фоне других программ и мероприятий. Компания не должна одновременно осуществлять большое количество проектов по реинжинирингу. Недопустимо, чтобы внимание менеджеров непрерывно переключалось между различными проектами. Все эти факторы должны обеспечить проведение реинжиниринга в достаточно короткие сроки – до одного года. Этого времени достаточно, чтобы пройти путь от декларации целей до завершения первой действующей версии реконструированных процессов. Затраты большего времени приводят тому, что сотрудники становятся нетерпеливыми, встревоженными и сбитыми с толку. Если руководство компании не уделяет реинжинирингу основное внимание, то его проведение обречено на неудачу. Контрольные вопросы и упражнения 1. Охарактеризуйте основные принципы классической теории менеджмента. 2. Каковы основные недостатки линейно-функциональной организационной структуры? 3. Какие изменения привели к тому, что принципы классической теории менеджмента не соответствуют новым условиям? 4. Перечислите основные принципы первой процессно-ориентированной концепции менеджмента «Непрерывное усовершенствование процессов». 5. Каковы внешние и внутренние причины появления технологии реинжиниринга бизнес-процессов? 6. Дайте определение реинжиниринга бизнес-процессов. 7. Что такое бизнес-процесс? В чем его отличие от бизнес-функции? 8. Поясните смысл таких ключевых фраз определения реинжиниринга, как: «фундаментальное переосмысление» и «радикальное перепроектирование». 9. Что означает ключевая фраза определения реинжиниринга: «… для достижения резких, скачкообразных улучшений в решающих современных показателях деятельности компании»? 10. В чем заключаются основные цели проведения реинжиниринга? 11. Для каких компаний целесообразно применение технологии BPR? 12. Почему реинижиниринг бизнес-процессов является технологией? 12. Охарактеризуйте основные этапы реинжиниринга. 13. С помощью каких инструментов осуществляется проведение реинжиниринга? 14. На что направлены эвристические правила реконструкции бизнеса? В чем их основная суть? 15. Какова роль информационных технологий в технологии реинижиринга? В чем разница между реинжинирингом и автоматизацией бизнес-процессов? 16. Как связан реинжиниринг с «выравниванием» организационных иерархий? 17. Поясните на примерах такие аспекты реинжиниринга, как: «ориентация на процесс», «фундаментальное переосмысление», «радикальное перепроектирование», «резкое скачкообразное улучшение показателей». 18. Каковы факторы успеха проведения реинжиниринга по таким аспектам, как «объект реинжиниринга», «цели реинжиниринга», «руководство и команда», «мотивация», «технология и принципы», «методы и средства», «финансы и время»? 19. Каковы факторы риска неудач по таким аспектам, как «объект реинжиниринга», «цели реинжиниринга», «руководство и команда», «мотивация», «технология и принципы», «методы и средства», «финансы и время»? 2. Методология моделирования бизнес-процессов 2.1. Требования к моделям бизнес-процессов Моделирование – основной инструмент анализа и проектирования бизнес-процессов. Приведем определение модели: Модель есть отображение (представление) объекта, системы или понятия в некоторой форме, отличной от формы их реального существования [14]. Существует огромное количество различного рода моделей. Классифицировать модели можно различными способами (рис. 2.1). По способу воплощения модели можно разделить на реальные (материальные, физические) и абстрактные (идеальные). Реальная модель – модель, построенная из реальных объектов. Примерами являются макеты, тренажеры. Для моделирования бизнес-процессов подобные модели практически не используются. Абстрактная модель есть отображение реального объекта в виде идеальных конструкций, выполненных средствами мышления. Выделим два основных класса абстрактных моделей: формальные (математические) и семантические (содержательные). В формальных моделях отражаются математические закономерности, существующие между количественными параметрами. К этому классу моделей относятся, в частности, системы уравнений, статистические модели, модели исследования операций др. Математические модели универсальны в том смысле, что одна и та же модель может описывать весьма различные физические процессы или явления. Основное достоинство математических моделей заключается в том, что они позволяют с помощью формального аппарата вычислений находить решение при заданных условиях. Основная же трудность заключается в том, что не все системы удается адекватно описать некоторой единой математической моделью. При анализе и проектировании бизнес-процессов математические модели используются для расчета отдельных характеристик процессов, например, стоимостных, временных, пространственных. В семантических моделях, в отличие от формальных, сохраняется семантика (смысл, содержание) объекта. Примерами семантических моделей могут служить дерево целей организации, модель организационной структуры, модель информационных коммуникаций компании и т.п. Как правило, семантические модели описывают некие объекты (сущности, системы, подсистемы, элементы), свойства объектов, их состояния и поведение, а также отношения между объектами. В качестве языковых средств семантического моделирования используются графы, диаграммы, таблицы, блок-схемы, естественный язык (язык общения между людьми). Противопоставление семантических моделей формальным вовсе не означает, что в них полностью отсутствует формализация. Как правило, можно формально описать форму, структуру семантической модели, но оперирование моделью, анализ осуществляется не на формальном уровне, а на самой модели – с учетом семантики, заложенной в ней. Семантические модели незаменимы на ранних этапах проектирования сложных систем, когда формируется концепция системы. Интегрированная семантическая модель системы позволяет представить общую картину, составить обобщенное описание, в котором подчеркнуты основные сущности, а детали скрыты. Главное в такой модели – краткость и понятность. Такая модель может служить основой для построения более детальных моделей, описывающих отдельные аспекты, подсистемы. Таким образом, семантическая модель может служить каркасом для построения других моделей, в том числе и математических. Она служит для структуризации информации о моделируемом объекте. Основой большинства семантических моделей являются базовые модели системного анализа – модель «черного ящика», модель состава и модель структуры системы. Модель «черного ящика» описывает только входы и выходы системы, но не ее внутреннее устройство. Модель состава описывает, из каких частей (подсистем, элементов) состоит система. Как правило, модель состава строится путем декомпозиции – последовательного разбиения системы на все более мелкие части. Модель структуры описывает все отношения (связи) между частями системы [15]. В зависимости от того, учитывается или нет в модели фактор времени, семантические модели разделяют на динамические и статические. Статические модели не учитывают временной параметр. Они отражают постоянные, устойчивые состояния объектов (систем, процессов), их состав, структуру, устойчивые внутренние и внешние связи. Динамические модели отображают поток событий, т.е. изменение во времени состояний объектов, последовательность выполнения взаимодействий объектов. Перейдем к рассмотрению требований к модели, описывающей бизнес-процессы компании. Любая компания, как известно, – сложная система. Для нее невозможно построить одну единственную модель, охватывающую абсолютно все детали. В общем случае необходима не одна, а несколько согласованных моделей, отражающих различные аспекты. В интегрированной модели бизнеса должны найти отражение: 1. Функция компании во внешнем мире: что она делает, для кого, с какой целью. Для этого используются модели типа «черного ящика», диаграммы взаимодействия с окружением (например, диаграмма вариантов использования системы окружением – Use Case Diagram). Такая модель описывает: окружающую среду компании, включающую клиентов, поставщиков, партнеров, субподрядчиков и т.д.; основные бизнес-процессы, а также взаимодействие процессов с окружением. Кроме того, для отражения системы целей компании и требований, предъявляемых к ней окружением, могут быть использованы модели типа дерева целей. 2.Описание бизнес-процессов, отдельных шагов процессов (функций, работ, операций). Для описания последовательности выполнения процессов разработаны различные виды моделей. Дадим краткую характеристику наиболее распространенных. Диаграммы деятельности (Activity Diagrams) описывают последовательность действий (в том числе с условными переходами) в виде схем, напоминающих блок-схемы алгоритмов. Диаграммы функциональной декомпозиции (например, модель IDEF0) позволяют описывать процесс на разных уровнях детальности: на верхнем уровне представлен процесс целиком, затем он декомпозируется и описывается взаимовлияние полученных подпроцессов друг на друга. Затем каждый из подпроцессов может быть подвергнут дальнейшему разбиению и для его частей может быть построена диаграмма взаимосвязей. В дополнение к моделям функциональной декомпозиции используются модели функционально-стоимостного анализа (ФСА-модели или ABC - Activity Based Costing), описывающие механизм формирования стоимости продукции на основе стоимости функций и ресурсов, задействованных в бизнес-процессах. Для отражения логики взаимовлияния работ и событий используются диаграммы потоков работ (Work Flow Diagrams). Они позволяют отражать в модели, например, следующие ситуации: «все предшествующие работы должны быть завершены одновременно», «один или несколько следующих процессов запускаются одновременно». Несмотря на то, что перечисленные виды моделей бизнес-процессов отражают последовательность выполнения отдельных шагов, время явно в них не присутствует. Чтобы отразить временные характеристики процессов используют модели календарного планирования (управления проектом), в частности график Ганта, сетевой график и т.д. Наиболее полную картину состояния процесса в любой момент времени позволяют получить компьютерные имитационные модели. Они копируют бизнес-процессы путем отображением «живой» картины процесса (при помощи анимации) в режиме сжатого времени. 3. Описание объектов, участвующих в выполнении бизнес-процессов или обрабатываемых, создаваемых бизнесом и отношений между объектами. Объектами являются исполнители, управленцы, оборудование, инструменты, продукция, сырье, материалы и т.д.. Для отражения свойств, характеристик объектов используются модели данных. Так, например, модель «сущность - связь» (Entity-Relationship Diagram) описывает объекты (сущности), их свойства (атрибуты) и отношения между объектами (связи). Модель классов (Class Diagram) отражает информационную структуру классов объектов и отношения между ними. Для моделирования поведения объектов используются диаграммы состояний (Statechart Diagrams). Они описывают последовательности состояний объекта, события и переходы между состояниями. Взаимодействие объектов во время выполнения бизнес-процессов отражают с помощью статических и динамических диаграмм взаимодействия (Interaction Diagrams). К наиболее важным статическим структурам относится также организационная структура компании. Определим теперь требования к методологиям моделирования бизнеса. Прежде всего, методология должна позволять строить понятные и обозримые модели. Модель должна исключать ненужные детали, акцентируя внимание на наиболее существенных аспектах. Лучше использовать интегрированную методологию, объединяющую методы построения нескольких взаимосвязанных моделей, отражающих различные аспекты моделируемого бизнеса. Необходимо, чтобы язык описания модели был выразителен. С другой стороны, методология должна быть достаточно формализована, т.е. должна включать в себя некоторые довольно четкие процедуры или техники генерации компонент модели. Желательно, чтобы методология поддерживалась инструментальными компьютерными системами. Использование инструментальных средств поддержки существенно облегчает процесс разработки больших проектов, особенно при коллективной разработке, в которой участвуют различные группы разработчиков. В этой главе будут рассмотрены две методологии моделирования бизнес-процессов: объектно-ориентированная методология (язык) UML (Unified Modeling Language – унифицированный язык моделирования) и методология функциональной декомпозиции IDEF (Integrated computer-aided manufacturing DEFinition). Обе методологии используют выразительный графический язык и позволяют строить наглядные, легко воспринимаемые модели. При этом используется принцип многомодельности, т.е. методологии позволяют формировать совокупность взаимосвязанных моделей, отражающих различные представления системы. Так, UML включает восемь видов моделей (диаграмм), IDEF – четыре основных представления. Немаловажным фактором является поддержка этих методологий компьютерными инструментальными средствами. На рынке CASE-средств представлен целый ряд инструментариев. В частности, методология IDEF поддерживается такими популярными средствами, как BPWin, Design/IDEF. Самым известным CASE-средством, ориентированным на язык UML, является Rational Rose. Во многом именно благодаря инструментальной поддержке рассматриваемые методологии получили очень широкое распространение. 2.2. Моделирование бизнеса на языке UML 2.2.1. Объектно-ориентированный язык UML Язык UML был разработан для создания моделей систем с целью их последующей реализации в виде объектно-ориентированных программ. Поскольку в основе UML лежит методология объектно-ориентированного программирования (ООП), необходимо пояснить, в чем ее суть. Традиционно в программировании разделяли понятия данных и процедур. Примерами данных являются: целое число (Integer), действительное число (Real), строка (String) и т.д. Новый тип данных – объект (object) – объединяет в одну структуру совокупность данных (атрибутов) и процедур (методов). Ниже приведено описание типа объекта TGraphObj (графический объект) на языке Pascal: Type TGraphObj = object {имя класса - объектного типа} X, Y: Integer; {атрибуты - координаты реперной точки} Color: Word; {атрибут - цвет линии} Constructor Init (aX,aY: Integer: aColor: Word); {процедура создания объекта} Procedure Draw; virtual; {процедура рисования} Procedure MoveTo (dX,dY: Integer); {процедура сдвига} end; Может быть создано множество объектов данного типа. Таким образом, тип объекта определяет класс однородных объектов. Каждый конкретный объект (экземпляр объекта) содержит свои собственные значения атрибутов. Самым замечательным свойством классов является возможность на основе одних классов создавать другие (наследовать) путем добавления новых атрибутов и методов, а также переопределения методов. Ниже приведено описание класса-потомка TRectan (прямоугольник), наследуемого от класса-предка TGraphObj: Type TRectan = object (TGraphObj) {TRectan наследуется от TGraphObj} dX, dY: Integer; {новые атрибуты - размер прямоугольника} Constructor Init (aX,aY,adX,adY: Integer; aColor: Word); {процедура создания объекта} Procedure Draw; virtual; {переопределенная процедура рисования} end; В определении класса-потомка приводятся только новые атрибуты/методы и переопределенные методы, атрибуты и методы предка наследуются «автоматически». Классы никогда не переписываются, они только расширяются и переопределяются. Это произвело революцию в программировании, т.к. позволило создавать программу из готовых «кирпичиков» - библиотечных объектов. Для различных языков программирования были созданы библиотеки стандартных классов, содержащие классы стандартных визуальных компонент – окон, меню, списков выбора, командных кнопок, кнопок выбора и т.д. Библиотечные классы компонент, построенные на принципах прямого манипулирования, «умеют» в ответ на манипуляции пользователя мышью или ввод с клавиатуры совершать стандартные действия – вызывать соответствующие методы. Появились средства «визуального» программирования или средства быстрой разработки приложений (RAD – Rapid Application Development), с помощью которых программист создает большую часть программы путем манипулирования мышью (передвигая на экране визуальные компоненты) и ввода свойств компонент – соответствующий программный код генерируется автоматически. Внимание программистов переключилось с непосредственного написания программного кода на предшествующие этапы – анализ предметной области и проектирование программы. Появились методы объектно-ориентированного анализа и проектирования (OOA/OOD – Object-Oriented Analysis/Design). Разные авторы создавали различные языки объектно-ориентированного моделирования, отличающиеся составом, видом диаграмм, используемыми обозначениями. Наиболее известными к середине 1990-х годов стали: метод Booch’93 Гради Буча, метод OMT (Object Modeling Technique) Джеймса Румбаха и метод OOSE (Object-Oriented Software Engineering) Айвара Джекобсона. Авторы этих методов решили объединить свои представления и создать унифицированный метод, что и привело к появлению языка UML. Благодаря поддержке консорциума OMG и разработке CASE-средства Rational Rose, ориентированного на UML, этот язык стал фактически стандартом в области объектно-ориентированного моделирования [16]. В технологии реинжиниринга бизнес-процессов, пожалуй, впервые объектно-ориентированные методы (в том числе UML) стали применяться не только и не столько для создании информационных систем, сколько для анализа и перепроектирования бизнес-процессов. Вместо моделей процессов, реализуемых информационной системой, строятся модели бизнес-процессов, даже если они и не будут подвергнуты автоматизации, вместо объектов ИС (программных объектов) в моделях отражаются объекты бизнес-процессов (исполнители, продукция, услуги и т.д.), вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса (поставщики, партнеры, клиенты). Моделирование бизнеса с помощью UML предполагает последовательное построение двух видов моделей – прецедентной модели (П-модели) и объектной модели (О-модели). 2.2.2. Прецедентная модель бизнес-процесса Прецедентная модель описывает бизнес-процессы компании. Если проводить аналогию с моделями системного анализа, то П-модель можно отнести к функциональным моделям, описывающим деятельность системы. Однако, в отличие от системного анализа, где под функцией понимается любое изменение состояние системы во времени (любая деятельность), в BPR понятие «функция» трактуется значительно уже и относится лишь к видам деятельности, выполняемым отдельными функциональными подразделениями. Процесс включает в себя различные виды деятельности (функции), начиная с обработки входов и заканчивая созданием продукции, необходимой клиенту. Например, процесс «обслуживание авиарейса» включает в себя такие функции, выполняемые работниками различных подразделений, как регистрация пассажиров, прием и выдача багажа, техническое обслуживание самолета, проведение полета и т.д. Построение прецедентной модели начинается с формирования, так называемой, внешней диаграммы или диаграммы вариантов использования (Use Case Diagram), описывающей бизнес так, как он виден извне, т.е. как он воспринимается клиентами и другим окружением. Данная диаграмма отражает представление о том, что делает бизнес, а не как делает. Основными элементами диаграммы являются: прецеденты (варианты использования) и акторы (субъекты). Прецедентом или вариантом использования в UML называется законченная совокупность действий моделируемой системы, начинающаяся при получении стимула извне и заканчивающаяся предоставлением некоторого продукта или сервиса актору – пользователю системы [16]. При моделировании информационной системы прецедент соответствует отдельному сервису, предоставляемому ИС пользователю. При моделировании бизнеса прецедент ставится в соответствие бизнес-процессам. Это, прежде всего, «внешние» бизнес-процессы, ориентированные на клиента, т.е. заканчивающиеся получением продукта (товара или услуги) – измеримой потребительской ценности для некоторого индивидуального клиента бизнес-системы. В виде прецедентов могут быть представлены и «внутренние» бизнес-процессы, клиентами которых выступают другие части бизнес-системы, не участвующие в выполнении процесса. Прецеденты представляют собой поток взаимосвязанных событий. При этом прецеденты могут иметь множество вариантов хода событий. Каждый конкретный прецедент (вариант) называется экземпляром. Экземпляр реализует конкретный поток событий в конкретных условиях для конкретного клиента. Похожие варианты хода событий группируются в классы прецедентов. Можно рассматривать класс, как обобщенный прецедент. Например, класс прецедентов «Продажа» описывает общий ход событий, выполняемых при продаже любого продукта любому клиенту. Конкретный экземпляр прецедента «Продажа» может отличаться в деталях, например, в зависимости от того, новый это клиент или нет, компетентный или несведущий и т.п. Акторами или субъектами в модели бизнеса являются элементы окружения – клиенты, партнеры, поставщики. Акторы обозначают все то в окружении, что взаимодействует с бизнесом. Это может быть человек (например, клиент, покупатель), другая компания (например, организация-поставщик, субподрядчик), техническая система (например, компьютерная система другой компании). Актор представляет собой абстракцию кого-либо или чего-либо, использующего бизнес. Он обозначает роль, которую что-то или кто-то может играть по отношению к бизнесу. Не следует путать реальных людей с акторами: реальная личность может играть несколько ролей в бизнес-системе. Например, конкретный человек может быть и клиентом, и поставщиком. Так же, как и для прецедентов, для акторов различают понятия класса и экземпляра. Класс описывает общие характеристики некоторого типа акторов, а экземпляр – характеристики конкретного актора. На диаграмме вариантов использования прецеденты обозначаются эллипсом, а акторы – фигуркой «человечка»1 (рис. 2.2). Как правило, на диаграмме отображаются классы прецедентов и классы акторов. На диаграмме могут быть также отображены примечания в виде прямоугольников с «загнутым» уголком (рис. 2.2). Между прецедентами и акторами могут быть установлены отношения коммуникации (communicate), относящиеся к классу отношений ассоциации. На диаграмме они обозначаются сплошной линией со стрелками (рис. 2.2). Отношения коммуникации отражают взаимосвязи прецедентов с окружением, заключающиеся в обмене веществом (сырьем, инструментами, готовой продукцией), энергией и информацией. Т.о. отношения коммуникации моделируют материальные, энергетические и информационные потоки. Следует заметить, что, как правило, между прецедентами не устанавливаются отношения коммуникации, т..к в процессе своего выполнения они не «обращаются» друг к другу. Допустимо установление отношений зависимости между прецедентами. Между акторами отношения коммуникации также не указываются, т.к. с точки зрения бизнес-системы они не представляют интереса. Следующий шаг в построении П.модели – описание прецедентов последовательностью мелких шагов. Такое описание называется потоком событий. С точки зрения системного подхода осуществляется декомпозиция процесса-прецедента на подпроцессы-события. Рассмотрим для примера описание прецедента «Продажа продукта»: 1. Продавец получает заявку клиента 2. Если в заявке указан готовый продукт, то Продавец проверяет наличие требуемого продукта на складе. Если продукта нет в наличии, прецедент заканчивается. Если продукт есть на складе, то прецедент продолжается с шага 6. 3. Если в заявке указывается заказной продукт, то Продавец формирует заказ и передает его Изготовителю продукта. 4. Изготовитель изготавливает продукт в соответствии с требованиями клиента и сообщает о готовности Продавцу. 5. Изготовитель отправляет продукт на Склад. 6. Продавец сообщает Клиенту о готовности продукта и принимает от Клиента оплату. 7. Продавец сообщает Отправителю количество продукта и адрес клиента и заказывает транспорт. 8. Отправитель получает продукт со склада и доставляет его клиенту. Каждый шаг (событие) прецедента представляет собой некоторое действие, переводящее прецедент в новое состояние. В свою очередь, новое состояние прецедента является стимулом для выполнения следующего шага (события). Таким образом, прецедент рассматривается как машина состояний-событий. Поток событий прецедента может быть представлен в виде диаграммы деятельности (Activity diagram), имеющей некоторое сходство с блок-схемой или структурной схемой алгоритма. Графически диаграмма деятельности представляется в форме графа, вершинами которого являются действия (шаги процесса), а дугами – переходы от одного действия к другому [16]. На диаграмме можно также отразить ветвление, т.е. возможность перехода к различным действиям в зависимости от некоторых условий. На рис. 2.3 приведена диаграмма деятельности для прецедента «Продажа продукта». Начальное состояние, соответствующее началу процесса, обозначается в виде закрашенного кружка; конечное состояние, соответствующее завершению процесса – в виде закрашенного кружка, помещенного в окружность. Действие изображается фигурой, напоминающей прямоугольник с закругленными сторонами, внутри которого записывается выражение действия. Переход изображается сплошной линией со стрелкой. Если после выполнения некоторого действия процесс должен разделиться на альтернативные ветви в зависимости от некоторого условия, то ставится знак ветвления в виде ромба, внутри которого нет никакого текста. В него может входить только одна стрелка. Выходящих стрелок может быть две или более. Для каждой из них указывается соответствующее условие, при котором выполняется данный переход. Прецедент может содержать различные альтернативные потоки событий, в том числе достаточно редкие и исключительные потоки, выполняемые при определенных условиях. Поэтому описание прецедента может быть очень сложным и запутанным, содержать множество условных переходов и проверок. Чтобы упростить описание прецедента, необходимо его структурировать. Рассмотрим два способа структурирования. Первый способ структурирования сложных прецедентов заключается в использовании отношения включения (include). Если из общего описания прецедента с альтернативными потоками событий можно выделить фрагмент, представляющий собой относительно законченную последовательность событий, то данный фрагмент рассматривается как отдельный прецедент и между ним и исходным прецедентом устанавливается отношения включения. Поток событий включенного прецедента «встраивается» в поток событий базового прецедента, т.е. когда экземпляр базового прецедента в процессе своего выполнения достигает точки включения, выполняется последовательность шагов включенного прецедента, после чего продолжается выполнение исходного прецедента. На рис. 2.4 приведен пример структурирования прецедента «Продажа продукта», из которого был извлечен фрагмент, содержащий последовательность действий, выполняемую только в том случае, если клиент в заявке указывает заказной продукт. Этот фрагмент выделен в отдельный прецедент «Исполнение заказа». На диаграмме вариантов использования отношение включения между прецедентами «Продажа продукта» и «Исполнение заказа» обозначено пунктирной линией со стрелкой и ключевым словом “include”. Поток событий прецедента «Исполнение заказа» вызывается из прецедента «Продажа продукта». В диаграмме деятельности вызов вложенной последовательности действий обозначается с помощью действия, имеющего специальную пиктограмму. Частным случаем структурирования с помощью выделения фрагментов является использование отношения расширения (extend). Данное отношение устанавливается между базовым прецедентом и прецедентом, содержащим некоторое дополнительное поведение, выполняемое при определенных условиях. Отношения включения и расширения используются для того, чтобы показать условные части прецедента, смоделировать фрагменты потока событий, выполняемые в особых случаях, а также смоделировать добавление в поток событий нескольких различных фрагментов в любой комбинации. Второй способ структурирования сложных прецедентов основан на использовании отношения обобщения (generali-zation). Если несколько прецедентов имеют похожее поведение, то следует выделить общее поведение в отдельный прецедент (родительский) и установить между ним и исходными отношение обобщения. В этом случае общее поведение описывается только один раз. Описания конкретных прецедентов (потомков) содержат только дополнительные шаги (или модифицированные шаги), которых нет в обобщенном описании. Можно сказать, что прецеденты-потомки наследуются от некоего обобщенного прецедента-родителя, являются его подклассами. Например, чтобы структурировать введенное выше описание прецедента «Продажа продукта», вводится абстрактный класс «Общий вид продаж» и два наследуемых класса – «Продажа готового продукта» и «Продажа заказного продукта». На рис. 2.5. приведена модель взаимосвязей между этими тремя прецедентами. Как видно из рис. 2.5, клиент взаимодействует не с обобщенным прецедентом, а с одним из конкретных прецедентов, который в ходе своего выполнения может вызывать поток событий предка. Поскольку в этом случае сначала начинает выполняться поток событий одного из прецедентов-потомков (либо прецедента «Продажа готового продукта», либо прецедента «Продажа заказного продукта»), то необходимо, чтобы заранее было известно, какой из прецедентов будет выполняться. Например, заказы на готовый продукт и на заказной принимаются разными продавцами в разных отделах, т.е. «Получить заказ на готовый продукт» и «Получить заказ на заказной продукт» – это разные действия, включенные в соответствующие прецеденты (см. рис. 2.5). 2.2.3 Объектная модель бизнес-процесса П-модель иллюстрирует функции бизнеса, его окружение и бизнес-процессы. Однако для более полного понимания бизнеса такого описания не достаточно. Необходима модель, показывающая как, за счет чего реализуются прецеденты. Объектная модель раскрывает внутреннее устройство бизнеса, а именно: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют. Описание О-модели базируется на понятии «объект». Объекты представляют участников процессов (исполнителей, менеджеров) и различного рода сущности (продукцию, предметы, задачи и т.д.). Участники процессов называются активными объектами, сущности – пассивными. Различают классы объектов, описывающие общие характеристики некоторого типа объектов, и экземпляры, описывающие характеристики конкретного объекта. О-модель, представленную в терминах классов объектов, называют идеальной моделью. Такая модель не учитывает некоторых деталей реализации модели на практике. О-модель, описанную в терминах экземпляров объектов, называют реальной. Выделяют следующие категории (роли) объектов [3]: 1. Интерфейсные (Boundary) – активные объекты, осуществляющие взаимодействие с окружением, т.е. с акторами. Примерами интерфейсных объектов являются Продавец, Регистратор, Секретарь. В роли интерфейсного объекта может выступать не только человек, но и, например, информационная система. 2. Управляющие (Control) – активные объекты, участвующие в выполнении процессов, но не имеющие контакта с окружением. Типичные примеры управляющих объектов – Разработчик продукции, Менеджер проекта. Следует отметить, что в роли управляющих объектов выступают не только менеджеры (управленцы), но и исполнители (рабочие, служащие, клерки), а также подразделения компании, информационные системы. 3. Объекты-сущности (Entity) – пассивные объекты, которые обрабатываются бизнесом. Как правило, объекты-сущности не являются человеческими или техническими ресурсами. Типичные примеры сущностей в компании – Продукция, Заказ, Извещение. Один и тот же объект может участвовать не только в одном прецеденте, он может принимать участие во многих событиях в бизнесе. Кроме того, как и в случае с акторами, один реальный человек или подразделение может выполнять роли нескольких объектов. Например, продавец продукции кроме роли интерфейсного объекта, выполняющего контакт с клиентом, может играть роль менеджера. Взаимодействие объектов во время выполнения бизнес-процессов отображается с помощью статических и динамических диаграмм взаимодействия. Примером статической диаграммы взаимодействия объектов является диаграмма кооперации (Collaboration Diagram). На рис. 2.6 представлена диаграмма кооперации для прецедента «Продажа заказного продукта», описанного в предыдущем параграфе. Прежде всего, на диаграмме в виде прямоугольников изображаются объекты. Внутри прямоугольника записывается имя объекта, после которого через слэш может быть указана роль (буквой «и» обозначается роль интерфейсного объекта, буквой «у» – роль управляющего объекта, буквой «с» – роль объекта-сущности), следом через двоеточие может быть указано имя класса. Вся запись подчеркивается, что является признаком объекта, отличающим его от класса. Между объектами устанавливаются отношения. Отношение отображается на диаграмме в виде линии, соединяющей объекты (или объект с актором), рядом с которой может быть указана метка – текст, специфицирующий отношение. Отношения, представленные на диаграмме кооперации, относятся к двум типам: сообщения и связи. Отношение сообщения (message) аналогично отношению коммуникации диаграммы вариантов использования и отражает передачу информации (или некоторый материальный поток) между объектами. При этом прием сообщения инициирует выполнение определенных действий тем объектом, которому сообщение передано. На диаграмме сообщение отображается линией, над которой помещен небольшой отрезок линии со стрелкой и меткой. Метка может содержать номер. Номера сообщений позволяют отразить последовательность передачи сообщений. Следует отметить, что отношения сообщений устанавливаются только между активными объектами или между активным объектом и актором. Отношение связи (link), относящееся к классу отношений ассоциации, отражает некоторую произвольную связь (ассоциацию) между двумя объектами. При моделировании бизнес-процессов в виде отношения связи чаще всего представляют отношения использования, показывающее, что один объект некоторым образом использует другой. Например, объект Продавец создает объект Заказ, объект Изготовитель использует Заказ для получения описания продукта, Отправитель продукта использует Заказ для получения информации о том, куда доставлять продукт. Диаграмма кооперации отражает статический взгляд на реализацию прецедента. Чтобы отразить динамику реализации прецедента участвующими в нем объектами, используется динамическая модель взаимодействия объектов. Примером такой модели является диаграмма последовательности (Sequence Diagram). При ее построении описание взаимодействия объектов как бы «накладывается» на поток событий прецедента, т.е. создается еще одно описание потока событий в терминах участвующих объектов. Методика построения подобных диаграмм использовалась долгое время в сфере телекоммуникаций, в основном, для описания взаимодействия между блоками аппаратуры. И Якобсон предложил использовать эти диаграммы для объектно-ориентированных моделей бизнес-процессов. На рис. 2.7 представлен пример диаграммы последовательности для прецедента «Продажа заказного продукта». На диаграмме последовательности отражаются только отношения сообщений. Каждый объект (актор), участвующий в реалиизации прецедента, изображается в верхней части диаграммы в виде прямоугольника («человечка»), от которого вниз проведена линия («линия жизни»). Сообщение изображается отрезком горизонтальной линии со стрелкой, проведенным от линии жизни объекта (актора), посылающего сообщение, до линии жизни объекта (актора), получающего сообщение. При этом сообщения упорядочены по времени: первое сообщение изображается вверху диаграммы, следующее – ниже, следующее – еще ниже и т.д. Таким образом, ось времени в диаграмме идет сверху вниз. Однако она не связана с метрикой и служит только для идентификации порядка взаимодействия, т. е. расстояние между взаимодействиями (сообщениями) на диаграмме не имеет ничего общего с интервалами времени между событиями. Диаграмма кооперации и диаграмма последовательности одного и того же прецедента должны быть согласованы, т.к. это разные представления одних и тех же взаимодействий. Однако на диаграмме последовательности не отображаются объекты-сущности и отношения связи. Все выше описанные аспекты О-модели – статическая и динамическая модели взаимодействия объектов – были направлены на описание участия объектов в прецедентах. Причем, один и тот же объект может участвовать в различных вариантах прецедента и в различных прецедентах. Для того, чтобы иметь представление обо всех ролях и обязанностях объекта, нужно составить описание объекта. Описание объекта состоит из двух частей: описание свойств и описание поведения. Для составления описания свойств объекта, прежде всего, необходимо выделить все его характеристики, называемые атрибутами. Например, объект Заказ может иметь атрибуты, указывающие название заказываемого товара, его цвет, количество, имя клиента, заказавшего товар и т.д. Как правило, состав атрибутов одинаков для всего класса однотипных объектов. Различные объекты одного класса отличаются лишь набором конкретных значений атрибутов. Например, для разных экземпляров класса Заказ будут указаны разные наименования товара, цвет, количество и т.д. Для описания состава атрибутов классов, а также для отображения взаимосвязей между классами используется диаграмма классов (Class diagram). Пример подобной диаграммы приведен на рис. 2.8. Каждый класс на диаграмме представлен в виде прямоугольника, который может быть разделен на три секции. В первой секции записывается имя класса (имя класса в отличие от имени объекта не подчеркивается), во второй – список атрибутов, в третьей – операции (методы) класса. Атрибут должен иметь имя, после которого через двоеточие может быть указан тип (Integer, Real, String, Class и т.д.). Если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности, то между классами, сопоставленными исходной сущности и ее частям, устанавливается отношение включения (include). Например, вся информация о заказе может быть разбита на две части – информация о клиенте (имя, адрес, телефон и т.д.) и информация о заказываемом продукте (наименование, цвет, количество). В этом случае кроме класса Заказ вводятся классы Клиент и Продукт, и между каждым из новых классов и исходным устанавливается отношение включения (см. рис. 2.8). Если несколько классов имеют одинаковые атрибуты, то можно ввести обобщенный класс, содержащий эти атрибуты, и установить между исходными классами и новым отношение обобщения (generalization). В этом случае общие атрибуты можно описать только в обобщенном классе (классе-предке), а для классов-потомков описываются только те атрибуты, которых нет у предка. Другими словами, потомок наследует все характеристики (атрибуты) предка, однако может иметь дополнительные характеристики. Например, класс Заказ, как и любой другой документ, имеет такие атрибуты, как номер документа, дата создания, создатель документа и т.д. Поэтому можно ввести класс Документ, описать в нем атрибуты, общие для всех документов, и установить между классами Заказ и Документ отношение обобщения. Класс Заказ при этом наследует атрибуты класса Документ и имеет свои собственные атрибуты (рис. 2.8). Описание поведения объекта заключается в выявлении всех его обязательств, т.е. всех взаимодействий объекта с другими объектами и акторами в ходе выполнения всех прецедентов. В [2] описан алгоритм выявления всех обязательств объекта из диаграмм взаимодействия. Поясним суть алгоритма. Как правило, объект фигурирует в нескольких диаграммах взаимодействия, описывающих различные прецеденты или экземпляры прецедентов. Из всех диаграмм, где фигурирует описываемый объект, вычленяются все обязательства объекта (взаимодействия) и объединяются (см. рис.2.9). В результате получается описание всех обязательств объекта во всех прецедентах. Все требования к объекту, состоящие их описания состояний объекта и описания поведения, собираются в документ, называемый спецификацией объекта. 2.3. Моделирование бизнеса с помощью методологии IDEF 2.3.1. Методология моделирования IDEF IDEF-методология была разработана задолго до появления технологии реинжиниринга бизнес-процессов. С середины 1970-х годов правительство и военные ведомства США финансировали многочисленные проекты, ориентированные на разработку методов описания и моделирования сложных систем. Одним из них явился проект ICAM (Integrated Computer-Aided Manufac-turing), предложенный ВВС США, цель которого состояла в разработке подходов, обеспечивающих повышение эффективности производства благодаря систематическому внедрению компьютерных технологий. В соответствии с проектом ICAM было разработано семейство методологий IDEF (ICAM DEFinition), которое состоит из трех самостоятельных методологий моделирования различных аспектов функционирования производственной среды или системы [17]: • IDEF0 – методология создания функциональной модели производственной системы (основана на методе SADT Росса); • IDEF1 – методология создания информационной модели производственной системы (основана на реляционной теории Кодда и использовании ER-диаграмм Чена); • IDEF2 – методология создания динамической модели производственной системы. Позднее на базе методологии IDEF1 было создано ее расширение – методология семантического моделирования данных IDEF1X. Кроме того, была разработана методология IDEF3 класса Work Flow Diagram. IDEF-методологии получили очень широкое распространение. Популярности способствовало и создание CASE-продуктов, поддерживающих IDEF, благодаря которым данная методология стала доступной и простой в употреблении. Рассмотрим основные элементы методологии IDEF0, возможности ее применения для реинжиниринга бизнес-процессов, а также функционально-стоимостной анализ IDEF0-модели. 2.3.2. Основные элементы IDEF0-методологии Методология IDEF0 является одной из самых известных и широко используемых методологий моделирования. Системные аналитики всего мира используют ее для решения широкого спектра проблем, включая разработку программного обеспечения, бизнес-анализ, проектирование, планирование и управление производственными системами, управление финансами и материально-техническими ресурсами, обучение персонала и т.д. [17]. Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований. При создании новых систем IDEF0 может применяться как для определения требований и функций, так и для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. При исследовании уже существующих систем IDEF0 может использоваться для анализа функций и механизмов их исполнения. IDEF0-модель использует графический язык для отражения информации о конкретной системе. Модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения). Основной конструкцией модели является функциональный блок, представляющий собой некоторый процесс или, в терминологии IDEF0, «активность (activity)». Выделяются также наборы различных объектов (сущностей), связанных с активностями в четырех возможных отношениях – Вход (Input), Выход (Output), Управление (Control) и Механизм (Mechanism) [17, 18]: • «Входы» отображают объекты, которые функциональный блок преобразует в «Выходы»; • «Управление» определяет, когда и как это преобразование может или должно произойти; • «Механизм» (человек, оборудование, информационная система) непосредственно осуществляет преобразование. Например, для функционального блока «Произвести изделие» входом является «исходный материал», выходом – «изделие», управлением – «чертеж», «рабочий график», механизмом – «станки», «инструменты», «рабочие». Сущности любого из перечисленных четырех типов связаны с дугой, входящей в блок или выходящей из блока. При этом каждая из сторон блока предназначена строго для одного типа сущностей: левая сторона – для входов, верхняя – для управления, правая – для выходов, нижняя – для механизма. Диаграмма функционального блока с входящими и выходящими дугами приведена на рис. 2.10. Необходимо подчеркнуть, что дуги – это не обязательно входные или выходные потоки. Входящие дуги – это необходимые условия (ограничения) для того, чтобы преобразование могло произойти, выходящие – результат преобразования. Например, оборудование, инструменты необходимы для изготовления изделия, однако они необязательно должны поступать в систему, производящую изделие, т.к. уже могут находиться в системе. Функциональный блок может быть декомпозирован, т.е. представлен в виде совокупности других взаимосвязанных функциональных блоков, которые детально описывают исходный блок. Например, блок «Произвести изделие» может быть расчленен на блоки «Планировать изготовление», «Обеспечить производственные ресурсы», «Изготовить изделие», «Реализовать изделие». На диаграмме блоки соединяются дугами: выходные дуги одних блоков могут являться входами (управлением, механизмом) других. Например, выход блока «Планировать изготовление» («План») является управлением для блока «Изготовить изделие», выход блока «Обеспечить производственные ресурсы» («Ресурсы») является входом блока «Изготовить изделие». При необходимости каждый из этих блоков также может быть декомпозирован, т.е. может породить «дочернюю» диаграмму. Таким образом, IDEF0-модель состоит из набора иерархически связанных диаграмм (см. рис. 2.11). Каждая диаграмма обычно содержит 3 - 5 блоков, размещаемых по «ступенчатой» схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие. Построение модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с внешним окружением. Затем блок, который представляет систему в целом, детализируется на другой диаграмме с помощью нескольких блоков-подмодулей, соединенных дугами. Каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера узлов. Например, блок А0 на диаграмме верхнего уровня А-0 детализируется на диаграмме А0 совокупностью блоков А1, А2 и А3. В свою очередь, блок А1 детализируется на диаграмме А1 совокупностью блоков А11, А12 и А13 (см. рис. 2.11). Дуги связывают различные функциональные блоки вместе и отображают взаимодействие и взаимное влияние блоков. Взаимовлияние может выражаться либо в передаче выхода одного блока на вход другого для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что должна делать другая активность. Дуги могут отображать и отношения обратной связи, могут разветвляться и соединяться различным образом. Каждая из ветвей может представлять один и тот же объект или различные объекты одного и того же типа. Метки указывают назначение дуг. Нужно подчеркнуть, что дуги – это не потоки и не последовательности. Они представляют собой ограничения на работу блока в том смысле, что функция не может быть выполнена, пока не станут доступными данные или объекты, соответствующие входящим дугам. Таким образом, ни последовательность выполнения функций, ни время не указаны явно на IDEF0-диаграммах. Дуги с одним свободным концом имеют источник или получатель вне диаграммы. Для обозначения внешних дуг используются буквы: I (Input), C (Control), O (Output) и M (Mechanism). Эти буквы сопровождаются номером (позиции дуг нумеруются слева направо или сверху вниз). Внешние дуги должны соответствовать входящим и выходящим дугам родительского блока. Например, блок А0 на диаграмме А-0 связан с пятью дугами – двумя входами, одним выходом, одним управлением и одним механизмом (см. рис 2.11). Им на дочерней диаграмме А0 соответствуют внешние дуги I1, I2, O1, C1, M1. Блок А1 на диаграмме А0 имеет один вход, один выход и один механизм. На дочерней диаграмме появляются соответственно I1, O1, M1. Для того, чтобы некоторая дуга не переносилась на дочернюю диаграмму, ее можно поместить в «туннель». При этом вокруг стрелки появляются две круглые скобки. Например, на рис. 2.11 дуга управления блока А3 на диаграмме А0 помещена в туннель. Поэтому она не будет перенесена на дочернюю диаграмму А3 (внешняя дуга С1 не появится). 2.3.3. IDEF0-модель бизнес-процесса В технологии реинжиниринга бизнес-процессов методология IDEF0 может быть использована для описания потоков событий прецедентов бизнес-системы. Каждый шаг прецедента (событие) может быть представлен как функциональный блок IDEF0-диаграммы. При этом объекты, участвующие в выполнении прецедента, представляются как входные и выходные дуги функциональных блоков. Так, интерфейсные и управляющие объекты представляются как дуги механизма, т.к. представляют собой людей, непосредственно осуществляющих выполнение преобразования (события). Объекты-сущности могут представлять входные дуги (если они являются предметом преобразований) или выходные дуги (если они являются результатом преобразований) или дуги управления (если они определяют условия преобразования) или дуги механизма (если они являются инструментом преобразований). Таким образом, с помощью IDEF0-диаграммы можно представить не только события, но и объекты, участвующие в их выполнении. Рассмотрим, как можно представить в виде IDEF0-диаграммы описание прецедента «Продажа заказного продукта» (см. п. 2.2). На исходной диаграмме верхнего уровня А-0 прецедент представляется в виде одного блока и дуг, изображающих его взаимодействие с внешним окружением (см. рис. 2.12). Входящие дуги отражают объекты-сущности, которые поступают извне и необходимы для выполнения прецедента. В частности, от клиента поступает Заявка (информация о заказываемом продукте), а также деньги для оплаты продукта. Кроме того, для выполнения заказа необходимы некоторые материалы, из которых производится продукт. Дуги механизма отражают исполнителей, участвующих в прецеденте – Продавец, Проектировщик, Склад и Отправитель, а также объекты-сущности, с помощью которых выполняется прецедент – Оборудование и Транспорт. Выходящая дуга – это результат выполнения прецедента, представляющий собой доставленный клиенту заказанный продукт. Далее прецедент декомпозируется на блоки, соответствующие основным шагам прецедента – «Получить заявку», «Изготовить и хранить продукт», «Получить оплату» и «Доставить продукт». Диаграмма декомпозиции представлена на рис. 2.13. Для блока А1 «Получить заявку» входом является «заявка», получаемая от клиента. Этому входу соответствует дуга I1, которая переносится с родительской диаграммы. Выходом является «заказ», содержащий: «описание продукта» (предается блоку «Изготовить и хранить продукт») и «адрес клиента» (передается блоку «Доставить продукт»). Механизмом является дуга M1 – «Продавец», который обеспечивает исполнение блока. Для блока А2 «Изготовить и хранить продукт» дуга «описание продукта» является управляющей, т.к. она предписывает, каким образом должно происходить выполнение заказа. Входом являются «материалы», используемые при производстве продукта, а выходом – «готовый продукт» (передается блоку «Доставить продукт»). Кроме того, выходом является «информация о выполнении заказа», которая передается блоку «Получить оплату» в качестве управляющего сигнала. Механизм блока представлен дугами «Изготовитель», «Склад» и «Оборудование». Для блока А3 «Получить оплату» входом являются «деньги», получаемые от клиента. Этому входу соответствует дуга I3, которая переносится с родительской диаграммы. Выходом является «информация об оплате», которая передается блоку «Доставить продукт» в качестве управляющего сигнала. Механизмом является дуга M1 – «Продавец», который обеспечивает исполнение блока. Для блока А4 «Доставить продукт» входом является «готовый продукт», управляющим входом - «информация об оплате». Выходом является «доставленный продукт», который является выходом всего прецедента. Механизмом являются дуги «отправитель» и «транспорт». Блоки могут быть подвергнуты дальнейшей декомпозиции. Например, блок «Изготовить и хранить продукт» может быть разбит на блоки: «Изготовить продукт», «Сообщить о готовности», «Отправить на склад», «Хранить продукт». Блок «Получить оплату» может быть разбит на блоки: «Сообщить клиенту о готовности», «Принять оплату», «Заказать транспорт». 2.3.4. Функционально-стоимостной анализ бизнес-процесса Функционально-стоимостной анализ (ФСА, Activity Based Costing - ABC) является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе департаментом обороны США) для идентификации истинных «движетелей» затрат в организации [19]. Данная методика позволяет проанализировать себестоимость существующих бизнес-процессов, а также провести сравнительный анализ альтернативных вариантов снижения затрат. ФСА-метод отображает финансовое состояние компании лучше, чем это делает традиционный бухгалтерский учет, т.к. он распределяет накладные расходы в соответствии с представлением о процессах, их влиянии на себестоимость и с детальным просчетом использования ресурсов, а не на основании прямых затрат или учета полного объема выпускаемой продукции. ФСА-модели можно использовать для формирования рекомендаций по увеличению прибыли и повышению эффективности деятельности организации. В качестве основы для проведения функционально- стоимостного анализа используется IDEF0-модель бизнес-процесса. Объектами определения стоимости (стоимостными объектами) являются выходы функциональных блоков IDEF0-модели. Суммарная стоимость выходов блока равна стоимости выполнения соответствующей функции. В свою очередь, стоимость выполнения функции определяется через стоимость используемых ресурсов, представленных как входные дуги, дуги управления и механизмов [19] (см. рис. 2.14). Можно выделить стандартные категории расходов (платы за используемые ресурсы), общие для всех функциональных блоков. Эти категории называются в ФСА-методе центрами стоимости (cost centers). Примеры центров стоимости: Рабочая сила зарплата исполнителей функции Оборудование амортизационные отчисления за используемое оборудование Помещение оплата за используемое помещение Материалы оплата расходных материалов Управление затраты на управление (составление графика работ, планирование и т.д.) Стоимость выполнения любого функционального блока определяется как сумма стоимостей по всем центрам затрат. Таким образом, центры затрат трактуются, как статьи расходов на выполнение функции. Стоимость декомпозированных функциональных блоков можно определять через стоимости дочерних блоков (подблоков). Для этого сначала необходимо задать частоту выполнения каждого из дочерних блоков (число раз, которое соответствующая функция выполняется в рамках выполнения родительской функции). Затем стоимость каждого дочернего блока умножается на его частоту и результаты складываются. При этом происходим суммирование по всем центрам затрат (см. рис. 2.15). Этот достаточно упрощенный принцип подсчета справедлив, если функции выполняются последовательно. Если схема выполнения функциональных блоков более сложная, например, некоторые функции выполняются альтернативно, процедура вычисления стоимости родительской функции значительно усложняется. Контрольные вопросы и упражнения 1. Чем отличаются реальные и абстрактные модели, формальные и семантические, статические и динамические? 2. Что должно найти отражение в интегрированной модели бизнеса? 3. Каковы основные требования к методологии моделирования бизнеса? 4. Что понимается под объектом в объектно-ориентированном программировании? 5. В чем разница между экземпляром объекта и классом? 6. Что описывает прецедентная модель бизнес-процесса? 7. Что такое прецедент? Что такое актор? Что обозначают эти понятия при моделировании бизнеса? 8. Приведите примеры экземпляров и классов прецедентов. 9. Приведите примеры экземпляров и классов акторов. 10. Что отображается на диаграмме вариантов использования? 11. Между какими элементами диаграммы вариантов использования могут быть установлены отношения коммуникации? Приведите примеры отношений данного типа. 12. Что такое поток событий прецедента? 13. Каковы основные элементы диаграммы деятельности? 14. Охарактеризуйте способ структурирования прецедентов, основанный на использовании отношения включения. 15. Охарактеризуйте способ структурирования прецедентов, основанный на использовании отношения обобщения 16. Приведите примеры интерфейсных, управляющих объектов и объектов-сущностей. 17. В чем разница между статической и динамической моделями прецедента? 18 Какие отношения между объектами отображаются на диаграмме кооперации? Приведите примеры для каждого вида отношений. 19. Какие отношения между объектами отображаются на диаграмме последовательности? 20. Как связаны между собой диаграммы кооперации и последовательности? 21. Что отражается на диаграмме классов? 22. Как формируется описание поведения объекта? 23. Что отражает каждый из четырех видов входящих и выходящих дуг функционального блока IDEF0-диаграммы: «Входы», «Выходы», «Механизм»и «Управление»? Приведите примеры. 24. Как связаны блоки диаграмм разных уровней иерархии IDEF0--модели? 25. Что означают дуги, связывающие функциональные блоки IDEF0-диаграммы? 26. Что означают внешние дуги на IDEF0-диаграмме? 27. Что означают такие понятия функционально- стоимостного анализа, как «стоимостные объекты» и «ресурсы»? Как связаны эти понятия с элементами IDEF0-диаграммы? 28. Что такое центры стоимости? Приведите примеры. 29. Как вычисляются стоимости функциональных блоков IDEF0-диаграммы при использовании ФСА-метода? 3. Принципы проведения реинжиниринга 3.1. Эвристические правила реконструкции бизнеса Эвристические2 правила представляют собой рекомендации, какими должны быть новые, перепроектированные бизнес-процессы, на каких принципах они должны быть основаны, чтобы обеспечить резкое скачкообразное улучшение показателей деятельности компании. Предлагаемые правила направлены, в первую очередь, на упрощение потоков информации и организационных отношений, устранение лишних работ и связей, а также изменение личной роли работников в сторону увеличения их полномочий и самостоятельности в принятии решений. Рассмотрим основные правила [1, 2, 6]. 1. Несколько работ объединяются в одну (горизонтальное сжатие процесса). При традиционном способе ведения дел процессы представляются в виде сборочного конвейера, на каждом рабочем месте которого выполняются простые задачи. При реинжиниринге ранее различные работы (задания) интегрируются. Рассмотрим в качестве примера использование данного правила в проекте по реинжинирингу, проведенном в компании IBM Credit (см. п. 1.4). На рис. 3.1 представлены модели бизнеса (в виде диаграмм деятельности) до и после реинжинирнга. В бизнес-процессе, существовавшем до реинжиниринга, работа последовательно выполняется пятью специалистами, входящими в различные подразделения компании. В новом бизнес-процессе работа нескольких специалистов объединена в работу, выполняемую одним человеком, имеющим доступ к информационной системе с базой данных (см. рис. 3.1) 3. На рис. 3.1 в диаграммах деятельности использована специальная конструкция языка UML, называемая «дорожки». Поле диаграммы разделено на «дорожки», соответствующие различным исполнителям. Действия, выполняемые определенным исполнителем, помещаются на соответствующую «дорожку» При использовании горизонтального сжатия следует стремиться к тому, чтобы все шаги процесса выполнялись одним человеком. Если это не удается, создается команда. Наличие в команде нескольких человек может приводить к некоторым задержкам и ошибкам при передаче работы между членами команды. Однако при традиционной организации работ, когда исполнители подчинены различным подразделениям, потери значительно больше и, кроме того, никто не несет ответственность за качественное выполнение всей работы. Горизонтальное сжатие процесса не только уменьшает количество людей, но и ускоряет выполнение процесса примерно в 10 раз. Уменьшается количество ошибок и отпадает необходимость держать специальную группу людей для устранения ошибок. Улучшается управляемость за счет уменьшения количества людей и четко распределенной ответственности между ними. 2. Исполнители принимают самостоятельные решения (вертикальное сжатие процесса). При традиционной организации работ исходили из предположения, что исполнители не имеют ни времени, ни склонности, ни глубоких и всесторонних знаний для того, чтобы самостоятельно принимать решения. Реинжиниринг отбрасывает это предположение. Вертикальное сжатие происходит за счет того, что в тех точках, где при традиционной организации работ исполнитель должен обращаться к управленцам, принимающим решения, исполнитель принимает решения самостоятельно. В результате сокращается количество управленцев, уменьшаются временные задержки, снижается стоимость и ускоряется реакция на запросы клиента (см. рис. 3.2). 3. Шаги процесса выполняются в естественном порядке. Реинжиниринг процессов освобождает от линейного упорядочения работ, свойственного традиционному подходу, позволяя выполнять работы в их естественном порядке, в том числе, где это возможно – параллельно. Этот подход был использован в проекте по реинжинирингу, проведенном компанией Kodak и описанном в главе 1 (см. п.1.4). На. рис. 3.3 представлены модели бизнеса (в виде диаграмм деятельности) до и после реинжиниринга. В бизнес-процессе, существовавшем до реинжиниринга, разработка изделия (фотокамеры) велась последовательно: сначала одна группа специалистов разрабатывала один узел, затем другая группа приступала к разработке следующего узла и т.д. В новом бизнесе разработка различных узлов осуществляется одновременно несколькими параллельно работающими группами с использованием информационной технологии CAD/CAM. Все группы полученные результаты своей работы вносят в интегрированную базу данных. Поиск и устранение несоответствий между результатами работы групп осуществляет специальная группа, которая каждый вечер инспектирует базу данных и в случае нахождения несоответствий исправляет ошибки. На рис.3.3 в диаграммах деятельности для разделения и слияния параллельных потоков событий используется специальный символ – «переход», представляющий собой отрезок горизонтальной линии, толщина которой несколько шире основных сплошных линий диаграммы. При разделении потоков событий переход имеет одну входящую стрелку и несколько выходящих (по числу параллельных потоков), при слиянии – несколько входящих стрелок и одну выходящую. Делинеаризация процессов ускоряет их выполнение. Ускорение происходит по двум причинам. Во-первых, ряд работ выполняется параллельно. Во-вторых, уменьшается время, которое тратится на устранение несоответствий между предыдущими и последующими шагами процесса. 4. Процессы имеют различные варианты исполнения. Традиционные процессы выполняются всегда идентично. В связи с этим обычно они оказываются очень сложными, так как учитывают различные исключения и частные случаи. Однако, как правило, сложных случаев не так уж много. – менее 20%. В результате 80% времени тратится на 20% работы. Новые перепроектированные процессы должны иметь различные версии для различных ситуаций, что очень актуально при быстром изменении рынка. При таком подходе процесс начинается с некоторого проверочного шага, определяющего, какая версия наиболее подходит к данной ситуации. Отдельные версии процесса являются ясными и простыми, т.к. каждый вариант ориентирован только на одну соответствующую ему ситуацию. Рассмотрим для примера проект IBM Credit (см п. 1.4). На рис. 3.4 представлены модели бизнес-процесса кредитования (в виде диаграмм деятельности) до и после реинжиниринга. Бизнес-процесс до реинжиниринга осуществлялся идентично вне зависимости от сложности обрабатываемого запроса. Новый процесс имеет три версии: для простых случаев, для средних по сложности случаев и для сложных случаев. Первая версия предполагает обработку запроса простым клерком с помощью базы данных, вторая версия – обработку с помощью экспертной системы, третья версия предполагает обращение к экспертам – высококвалифицированным специалистам, осуществляющим экспертизу. 5. Работа выполняется там, где это наиболее целесообразно. В традиционных компаниях работа организуется вокруг специалистов, сгруппированных в функциональные подразделения: расчетный отдел, отдел заказов, транспортный отдел и т.п. Поэтому если расчетному отделу требуется новый карандаш, то он обращается с заявкой в отдел заказов. Отдел заказов находит производителя, договаривается о цене, размещает заказ, осматривает товар, оплачивает его и передает в расчетный отдел. Описанный процесс является достаточно расточительным и медленным, т.к. он затрагивает несколько подразделений, взаимодействующих друг с другом в письменной форме. На рис. 3.5 представлена модель данного процесса (в виде диаграммы последовательности), а также модель нового бизнеса. В одной из крупных компаний США выявили, что затраты на приобретение батарейки стоимостью 3$ составили 100$. Кроме того, было установлено, что 35% всех заказов составляют заказы стоимостью менее 500$. В результате реинжиниринга было решено, что все отделы самостоятельно (а не через отдел заказов) заказывают себе товары стоимостью менее 500$. Реинжиниринг сдвигает работу между границами подразделений, что устраняет излишнюю интеграцию и приводит к повышению эффективности процесса. 6. Уменьшение проверок и управляющих воздействий Традиционные процессы насыщены проверками и управляющими шагами, не производящими материальных ценностей для заказчика, а проверяющими соблюдение исполнителями предписанных правил. Так, например, отдел заказов до исполнения заказа проверяет право клиента осуществить данный заказ, подлинность подписи клиента и финансовую состоятельность его подразделения или компании. При общей целесообразности проверок многие компании не задумываются над тем, сколько стоит проведение этих проверок. На практике довольно часто оказывается, что стоимость проверок и управляющих воздействий превосходит стоимость потерь, которые бы имели место при отсутствии проверок. Реинжиниринг предлагает более сбалансированный подход. По возможности выполняются только действия, увеличивающие потребительскую ценность продукта (УЦ-действия). Если же проверок не избежать, то вместо проверки всех выполняемых работ в перепроектированном процессе предусматриваются отложенные комплексные проверки и управляющие воздействия. Это заметно сокращает время и стоимость проверок. На рис. 3.6 показаны модели бизнес-процессов (в виде диаграмм деятельности) до и после применения данного правила. 7. Минимизация согласований. Еще один вид работ, не производящих непосредственных ценностей для заказчика – согласования. Задача реинжиниринга – минимизировать согласования в ходе исполнения процесса путем сокращения внешних точек контакта. Суть минимизации согласований можно пояснить на примере проекта, проведенного компанией Ford (см. п. 1.4). На рис. 3.7 показаны модели бизнес-процесса «Поставки» (в виде диаграмм кооперации) до и после реинжиниринга. До реинжиниринга процесс поставки комплектующих (товара) в компанию Ford предполагал наличие трех точек контакта с поставщиками (см. рис. 3.7): • в департаменте заказов в виде заказа на приобретение товара; • в отделе получения в виде документа на получение товара; • в отделе оплаты счетов в виде накладной на получаемый товар. Три точки контакта приводили на практике ко многим несогласованностям. Компания Ford уменьшила количество контактов с трех до двух (см. рис. 3.7), устранив накладную на товар. Теперь при получении товара клерку из отдела получения необходимо только через компьютерный терминал проверить соответствие присланных товаров заказу, хранящемуся в базе данных. Это сделало ненужным согласование противоречивых документов и существенно повысило эффективность работы компании. 8. Уполномоченный менеджер обеспечивает единую точку контакта. Механизм уполномоченного менеджера применяется в тех случаях, когда шаги процесса либо сложны, либо распределены таким образом, что интеграция их силами небольшой команды невозможна. На рис. 3.8 приведены модели бизнес-процессов (в виде диаграмм кооперации) до и после реинжиниринга. В существующем процессе клиент самостоятельно взаимодействует с различными сотрудниками, в новом он контактирует только с уполномоченным менеджером. Уполномоченный менеджер действует как буфер между сложным процессом и клиентом. Чтобы выполнить эту роль, менеджер должен быть способен отвечать на вопросы клиента и решать его проблемы. Поэтому менеджер должен иметь доступ ко всем информационным системам, используемым в этом процессе, и ко всем исполнителям. 9. Преобладает смешанный централизованный / децентрализованный подход. Централизация имеет ряд недостатков, таких, как длительное время принятия решений, плохая осведомленность лица, принимающего решения, о конкретных обстоятельствах, плохой контакт с исполнителями. Однако и полная децентрализация имеет свои недостатки, главный из которых – несогласованность в принятии решений. Проиллюстрируем это на примере работы банков. Многие банки могут осуществлять с одним и тем же клиентом независимые финансовые отношения через свои различные подразделения. Подобный децентрализованный подход может приводить к хаосу, т.к. каждое подразделение отслеживает только ту часть рынка, которая соответствует его профилю. Имел место реальный случай, когда банк, установивший для одного из своих клиентов максимальный кредит в размере 20 млн.$, выдал ему через несколько своих подразделений кредит в несколько раз больший, чем планировал. Ошибка выявилась в связи с банкротством клиента. Избежать подобных случаев можно, применяя смешанный подход, который, с одной стороны, предполагает автономную работу подразделений, а, с другой стороны, позволяет подразделениям координировать свои действия. Причем современные технологии позволяют осуществлять координацию без бюрократического аппарата – за счет возможности пользоваться централизованными данными. Например, вышеописанная ситуация с банком не могла произойти, если бы банк имел централизованную базу данных, доступную всем подразделениям. Таким образом, организация может устранить бюрократические процедуры и повысить качество обслуживания. На рис. 3.9 приведены модели бизнес-процессов (в виде диаграмм деятельности) до реинижиниринга, использующих централизованный и децентрализованный подходы, и модель бизнес-процесса после реинижиниринга, использующего смешанный подход. 3.2. Роль новых информационных технологий в реинжиниринге Информационные технологии (ИТ) – это не только база для автоматизации базнес-процессов, но и способ, с помощью которого товар предлагается клиентам. Информация стала важной составляющей частью товаров и услуг, поставляемых компаниями на рынок. Стратегическая цель ИТ – способствовать менеджменту, реагировать на динамику рынка, создавать и углублять конкурентное преимущество. Современные информационные технологии играют критически важную роль в BPR. В каждом из приведенных в п. 1.4 примеров успешного реинжиниринга новые ИТ сыграли существенную роль в изменении бизнес-процессов. Так, IBM Credit благодаря ИТ смогла объединить работу нескольких специалистов в работу, выполняемую одним человеком, имеющим доступ к экспертной системе с базой данных. Компания Ford смогла благодаря использованию централизованной базы данных отказаться от накладной. Компании Kodak использование технологии CAD/CAM и интегрированной БД, хранящей текущее состояние проекта, позволило применить параллельный подход при разработке новой камеры. Необходимо подчеркнуть, что во всех описываемых случаях информационные технологии применялись не для автоматизации существующей деятельности, а для автоматизации новых перепроектированных процессов. Более того, само перепроектирование процессов стало возможным только благодаря новым информационным технологиям. Основная ошибка большинства компаний состоит в том, что они хотят решить свои проблемы, автоматизируя существующую деятельность. Однако простое накладывание ИТ на существующие деловые процессы не приводит к трансформации бизнеса и даже наоборот может блокировать процесс перестройки, сохранив прежние способы ведения дел. Таким образом, простая автоматизация не позволяет значительно улучшить основные показатели деятельности компании, сделать рывок, опередить конкурентов. Можно выделить три категории изменений, которые обеспечивает использование информационных технологий: • изменения, улучшающие временные характеристики процессов без модификации их содержания. Такие изменения, не являясь революционными, позволяют автоматизировать работу, сократить ручной труд, анализировать данные новыми методами, которые невозможно применять вручную; • изменения, не затрагивающие сами процессы, но позволяющие контролировать каждый конкретный экземпляр процесса и выявлять, где он наталкивается на те или иные проблемы. Такие изменения обеспечивают автоматизированные системы мониторинга и диагностики; • революционные изменения, заключающиеся в реорганизации бизнес-процессов. Именно данная категория изменений является ядром реинжиниринга. Приведем пример того, как новые ИТ позволяют коренным образом поменять ход выполнения бизнес-процессов. Компания Дженерал Моторс построила завод Сатурн (Теннесси, США), в котором производственная база данных доступна в режиме on-line для официальных поставщиков. Теперь поставщики не ждут от Дженерал Моторс официального заказа на комплектующие. Они просматривают график работ и сами определяют, когда и сколько комплектующих должно быть поставлено. Зная, сколько машин компания выпускает в месяц, поставщик может составить собственный график производства и доставки соответствующих деталей. В этом процессе нет места бумажной переписке – заказам и счетам. Когда необходимые детали пребывают в нужное место и в строго определенное время, клерк сканирует нанесенный на них штриховой код, что автоматически подтверждает приемку товара и инициирует оплату. Таким образом, ИТ, а конкретнее, база данных по графику производства и электронный обмен данными позволили разным компаниям действовать как единое целое [2]. В таблице 3.1 ([1, 2]) приведены примеры того, как ИТ меняют старые правила работы компаний на новые. Дадим краткую характеристику перечисленных в табл. 3.1 информационных технологий. Таблица 3.1 Новые ИТ, изменяющие правила работы компаний Технология Прежнее правило Новое правило Телекоммуникационные сети Необходимо выбирать между централизацией и децентрализацией Можно одновременно получать преимущества от централизации и децентрализации Беспроводная связь и переносимые компьютеры Специалистам для получения, хранения, поиска и передачи информации требуется офис Специалисты могут посылать и получать информацию из того места, где они находятся Распределенные базы данных Информация может появляться в одно время в одном месте Информация может появляться одновременно в разных местах тогда, когда она необходима Средства поддержки принятия решений Все решения принимают менеджеры Принятие решений становится частью работы каждого сотрудника Экспертные системы Сложную работу могут выполнять только эксперты Работу эксперта может выполнить специалист по общим вопросам Интерактивный видеодиск Лучший контакт с потенциальным покупателем – личный контакт Лучший контакт с потенциальным покупателем – эффективный контакт Технология автоматического индексирования и отслеживания Для того, чтобы найти некую сущность, необходимо знать, где она находится Сущности говорят вам, где они находятся Высокопроизводительные компьютеры План пересматривается периодически План пересматривается оперативно, по мере необходимости 1. Телекоммуникационные сети. Это сети передачи данных, связывающие компьютеры посредством линий связи или магистралей, средств радиосвязи, спутников и др. Локальные сети связывают ряд компьютерных станций в одной локальной зоне, ограниченной, например, одним зданием, одним предприятием. Глобальные сети отличаются более протяженными коммуникациями, которые могут обеспечиваться с помощью телекоммуникационных компаний. Использование сетей дает возможность работникам из различных подразделений организации (в том числе территориально отдаленных друг от друга) оперативно обмениваться информацией при помощи своих компьютеров. Например, продавцы, работающие в регионе, могут через сеть получать доступ к централизованной базе данных, находящейся в штаб-квартире компании, и использовать при составлении контрактов последние сведения по ценам, спецификациям товаров и др. Таким образом, становится возможным сочетать децентрализованное принятие решений отдельными подразделениями с централизованным хранением и обработкой информации. При этом координация решений, самостоятельно принимаемых на местах, осуществляется без бюрократических процедур. Старое правило ведения бизнеса «Необходимо выбирать между централизацией и децентрализацией» меняется на новое: «Можно одновременно получать преимущества от централизации и децентрализации». 2. Беспроводная связь (связь, осуществляемая без кабельных линий посредством средств радиосвязи) и переносимые компьютеры (ноутбуки). Они позволяют передавать, обрабатывать и получать информацию в любом месте, хоть в чистом поле. Старое правило «Специалистам для получения, хранения, поиска и передачи информации требуется офис» меняется на новое: «Специалисты могут посылать и получать информацию из того места, где они находятся» 3. Распределенные базы данных (Distributed Data Base, DDB). Распределенная БД – это логически единая база данных, физически размещенная на двух или более компьютерах, являющихся узлами компьютерной сети. Сущность DDB заключается в организации доступа пользователей к большим объемам информации. Это позволяет располагать данные так, что последние, с одной стороны, находятся в пунктах наибольшего их спроса, а, с другой стороны, обеспечивается доступ к любым данным, независимо от того, где они расположены. Таким образом, старое правило «Информация может появляться в одно время в одном месте», характерное для локальных баз данных, меняется на новое: «Информация может появляться одновременно в разных местах тогда, когда она необходима». 4. Средства поддержки принятия решений (СППР). Это информационные системы, помогающие менеджерам в принятии решений. Они сочетают традиционные методы доступа и обработки компьютерных данных с возможностями решения задач на основе математических моделей. СППР позволяют в диалоговом режиме выявлять различные подходы к решению задач, генерировать варианты, осуществлять их оценку и выбор оптимальных решений. Для этого в состав СППР наряду с подсистемой данных (системой управления базами данных - СУБД) вводится подсистема моделирования, содержащая программы расчета на различных моделях принятия решений. В качестве моделей могут использоваться: модели математического программирования (линейного, нелинейного, целочисленного); модели прогнозирования (экстраполяционные, статистические); имитационные модели и др. Использование СППР может существенно облегчить процесс принятия решений, сделать его доступным не только для управленцев, но и для рядовых сотрудников. Таким образом, старое правило «Все решения принимают менеджеры» меняется на новое: «Принятие решений становится частью работы каждого сотрудника». 5. Экспертные системы (ЭС). Это информационные системы, которые моделируют с помощью компьютера процесс принятия решения человеком-экспертом (высоко квалифицированным специалистом в некоторой предметной области) и выступают в роли консультанта для рядового специалиста. Экспертные системы называют также системами, основанными на знаниях, т.к. они используют для решения задач знания эксперта, причем не только теоретические знания, но и эвристические – почерпнутые из наблюдений, опыта работы. Знания эксперта хранятся в, так называемой, базе знаний, чаще всего, в виде логических правил. Примеры правил из области оценки финансового состояния предприятия [20]: ЕСЛИ Коэффициент рентабельности > 0.2 ТО Рентабельность = «удовл»; ЕСЛИ Задолженность = «нет» И Рентабельность = «удовл» ТО Финансовое_состояние = «удовл»; ЕСЛИ Финансовое_состояние = «удовл» И Репутация = «удовл» ТО Надежность_предприятия = «удовл». В процессе решения конкретной задачи вводятся исходные факты (запрашиваемые данные), на основании которых выводятся новые факты, которые, в свою очередь, становятся основанием для вывода следующих новых фактов и т.д., пока не будет выведено искомое заключение. Если выданное системой решение непонятно пользователю, то он может запросить у системы объяснения, каким образом было получено решение. Использование ЭС позволяет рядовым специалистом решать сложные, слабо формализуемые задачи, опираясь на знания эксперта. Таким образом, старое правило «Сложную работу могут выполнять только эксперты» меняется на новое: «Работу эксперта может выполнить специалист по общим вопросам». 6. Интерактивный видеодиск Технология интерактивных видеодисков представляет собой слияние видео-технологий с компьютерными технологиями. Ключевым моментом этого слияния является тот факт, что информация, заключенная на видеодиске, может контролироваться микропроцессором таким образом, что система реагирует на поведение пользователя. Движущиеся имиджи, заставки, компьютерная графика и печатная информация могут комбинироваться и структури-роваться в единый материал. Пользователь, например, потенциальный покупатель, желающий ознакомиться с товаром посредством интерактивного видеодиска, может по своему усмотрению выбирать нужные разделы и просматривать видео, заново просматривать отдельные части для извлечения большей информации или для ее уточнения, пропускать ненужные места, просматривать сцены в замедленном режиме и останавливать определенные кадры. Заменяет ли такой способ получения информации живое общение с продавцом товара? Ответ не однозначен. Все зависит, с одной стороны от компетентности продавца, с другой стороны – от качества видеодиска. Таким образом, старое правило «Лучший контакт с потенциальным покупателем – личный контакт» меняется на новое: «Лучший контакт с потенциальным покупателем – эффективный контакт». 7. Технология автоматического индексирования и отслеживания, используемая в системах электронного документооборота (СЭД) предприятия. Термин «электронный документооборот» обозначает автоматизированный процесс управления передачей документов, информации или рабочих заданий между сотрудниками или их группами внутри организации. Типы файлов, которые, как правило, поддерживают СЭД, включают: текстовые документы, изображения, электронные таблицы, аудиоданные, видеоданные и Web-документы. СЭД обеспечивают процесс создания, управления доступом и распространения больших объемов документов в компьютерных сетях, а также обеспечивают контроль над потоками документов в организации как с помощью жесткого определения маршрутов движения, так и путем свободной маршрутизации документов. В СЭД должны автоматически отслеживаться изменения в документах, сроки исполнения документов, движение документов, а также контролироваться все их версии и подверсии. Автоматический контроль движения документов позволяет сменить старое правило ведения бизнеса «Для того, чтобы найти некую сущность4, необходимо знать, где она находится» на новое: «Сущности говорят вам, где они находятся». 8. Высокопроизводительные компьютеры. Современные интегрированные информационные системы планирования деятельности предприятий требуют больших вычислительных мощностей. Такие системы, как ERP (Enterprise Resource Planning) выполняют множество функций: планирование развития бизнеса, планирование продаж, планирование потребностей в сырье и материалах, планирование закупок, планирование производственных мощностей, планирование финансовых ресурсов и т.д. Существенным фактором является время рассмотрения планов. Слишком часто долгое время планирования становится временем упущенной выгоды, за которое рынок успел измениться и план потерял свою актуальность. Планирование должно проходить в сжатые сроки. Использование высокопроизводительных компьютеров предоставляет возможность динамического анализа и динамического изменения плана по всей цепочке планирования. Таким образом, старое правило «План пересматривается периодически» меняется на новое: «План пересматривается оперативно, по мере необходимости». Мы рассмотрели лишь часть технологий, используемых для реконструкции бизнеса. Современные ИТ продолжают развиваться и поэтому те правила бизнеса, которые кажутся незыблемыми сегодня, могут устареть через год или ранее. В процессе реинжиниринга отделы информационных технологий в фирмах и корпорациях вынуждены пересматривать свою роль. Их миссия смещается от обслуживающих функций к формированию основ конкурентоспособности компании. Отделы ИТ необходимо привлекать к стратегическому планированию с целью «наложения» новой бизнес-архитектуры на новую ИТ-архитектуру. Примеры взаимного влияния этих архитектур, взятые из [21] приведены в таблице 3.2. Таблица 3.2 Взаимосвязь бизнес- и ИТ-архитектур Бизнес-архитектура ИТ-архитектура Глобализация бизнеса Глобальные сети, бесперебойная работа в режиме 24 часа × 365 дней Меньшее количество уровней управления Повсеместные телеконференции, электронная почта, заметки Интеграция цепочки поставщиков Приложения клиент/сервер от нескольких поставщиков Возросшая мобильность служащих Беспроводные коммуникации, сети, распределенные БД Фокусировка на обслуживании клиента Быстрое развитие приложений. Бесперебойная 24×365 -работа 3.3. Организационная структура новой компании Новой организации бизнеса, построенного на новых принципах, должна соответствовать и новая организационная структура. Рекомендуется использовать для новой реконструированной компании процессную оргструктуру. Рассмотрим основные характеристики новой структуры. В традиционной иерархической функциональной структуре подразделения выполняют отдельные функции, являющиеся частью процессов. В структуре, ориентированной на процессы, функциональные подразделения рассматриваются как ресурсы (людские, материальные), используемые в экземплярах процессов. Таким образом, процессы – это динамический взгляд на то, как ресурсы используются для производства продукции. В каждом конкретном экземпляре процесса, производящем некоторый продукт для конкретного заказчика (внутреннего или внешнего), участвуют ресурсы различных функциональных подразделений. В процессной структуре вводятся новые организационные подразделения, выполняющие экземпляры процессов. В качестве примера рассмотрим новую структуру компании SAS – Скандинавские Авиалинии [2]. Дж. Карлсон, бывший президент SAS, организовал свой персонал в команды, по одной на каждый авиарейс (см. рис. 3.10). Команда несла ответственность за процесс «проведение полета: от регистрации до выдачи багажа по прибытии». Команда состояла из персонала, работавшего как в самолете, так и на земле. К последним относились, например, техники и сотрудники по приему и выдаче багажа. Это был принципиально новый подход к организации коммерческих рейсов по сравнению с процедурами в традиционных компаниях. Дж. Карлсон довольно ярко описывает, как небольшая неисправность, например, недостаточно закрученная деталь отрабатывается в рамках традиционной и новой компании. Ранее ответственный за техническую часть должен был представлять формальный рапорт о неисправности, в результате чего запускалась длительная и дорогостоящая процедура, в которую вовлекались менеджеры на нескольких уровнях иерархии. В новой компании ответственному достаточно просто попросить техника подкрутить деталь, сняв тем самым все проблемы. В компании, основанной на процессах, можно выделить несколько типовых ролей сотрудников (см. рис. 3.11): • президент компании - первый руководитель; • владельцы ресурсов (менеджеры): по одному для каждой функции; • владельцы процессов (менеджеры): по одному для каждого процесса; • операторы процессов (непосредственные исполнители). Кроме того, могут назначаться лидеры для каждого из конкретных процессов (экземпляров процессов). Каждый конкретный человек может выступать в одной роли или сразу в нескольких. Перечислим обязанности основных категорий сотрудников компании, основанной на процессах [2]. Президент компании определяет стратегии бизнеса, ставит долгосрочные и оперативные цели. Он осуществляет общий контроль за бюджетом и финансовой деятельностью компании, обеспечивает развитие бизнеса и организационной структуры. Президент назначает владельцев ресурсов и владельцев процессов, а также контролирует их деятельность, отвечая за конечный результат выполнения процессов компании. Он также отвечает за координацию различных процессов на уровне интерфейсов между этими процессами. В большой компании между президентом и владельцами ресурсов и процессов могут стоять должностные лица, отвечающие за различные сферы бизнеса. Владелец процесса несет ответственность за выполнение определенного процесса, за его конечный результат. Он определяет цели процесса так, чтобы они соответствовали стратегическим бизнес-планам, разрабатывает процесс и обеспечивает его выполнение. Он определяет также интерфейс (взаимодействие) процесса с другими процессами, обеспечивает развитие процесса и улучшение его качества. Владелец процесса договаривается с высшим руководством о стоимости своего процесса и планирует бюджет процесса. Он распоряжается активами (деньгами), которые предоставляются руководством, для привлечения ресурсов, будь то люди, оборудование или программное обеспечение, как внутри, так и вне компании. Владелец процесса набирает сотрудников из различных подразделений (у владельцев ресурсов), исходя из их опыта и профессиональной подготовки, а также из тех заданий, которые должны выполняться процессом. При этом заключается трехстороннее соглашение между владельцем процесса, владельцем ресурса и оператором процесса. Если все стороны соглашаются с предложениями по такому соглашению, то они подписывают и принимают эти предложения. Таким образом, владелец процесса организует операторов процесса в команду. Он несет оперативную ответственность за привлекаемые им ресурсы, распределяет работы и руководит их выполнением. Кроме того, владелец процесса может назначать лидера для каждого из своих конкретных процессов. Он определяет каждый экземпляр процесса: устанавливает и отслеживает его цели, условия выполнения и т.д., в то время как лидер процесса выполняет конкретные реализации процесса. Владелец ресурса несет долговременную ответственность за ресурсы, относящиеся к его конкретной функции. Он имеет исполнителей, но не имеет денег, в отличие от владельца процесса, который имеет деньги, но не имеет исполнителей. Владелец ресурса распределяет имеющиеся в его распоряжении ресурсы на различные бизнес-процессы, разрешает конфликты, возникающие при распределении ресурсов, заключает соглашения с операторами процессов и владельцами процессов. Получаемые от владельцев процессов деньги он расходует на выплату зарплаты своим сотрудникам, на приобретение оборудования и т.д. Еще одна важная функция владельца ресурсов - обеспечение профессионального роста своего персонала. Он принимает на работу операторов процесса, ведет проверку их компетентности, составляет долгосрочные планы обучения и повышения квалификации. Для каждого из работников составляется личный план профессионального роста, описывающий основные курсы, которые должен закончить оператор процесса, а также его возможные продвижения в компании в ближайшие 1-3 года. Операторы процесса выполняют работы в конкретных процессах. Они могут участвовать одновременно в нескольких процессах. Каждый оператор процесса составляет совместно с владельцами процессов и владельцем ресурса индивидуальный план участия в процессах. В этих планах указывается, какой процент времени оператор затрачивает на участие в различных процессах в течение года. Индивидуальные планы должны обсуждаться и пересматриваться ежегодно. Процессная структура является, по сути, модификацией матричной структуры. Однако имеются и отличия: 1. Матричная структура применяется, когда необходимо выполнить некоторый проект. Руководитель проекта набирает временную команду из специалистов, необходимых для выполнения проекта. В процессной структуре многофункциональные команды создаются не только для проектов, но и для других видов процессов, в том числе рутинных, повторяющихся. Примером циклически повторяющегося процесса является авиарейс: от регистрации до выдачи багажа. Здесь одна летная команда, подкрепленная наземными службами, начинает обслуживание нового рейса сразу же по завершении работы по предыдущему. 2. В матричной структуре часто возникают конфликты между руководителем проекта и линейными менеджерами. Когда менеджер проекта хочет нанять исполнителей у линейных менеджеров, он обычно встречает недружелюбный прием. Последние не хотят терять свои ресурсы. Переговоры тянутся без конца. Ситуация является конфликтной с самого начала. В структуре же, основанной на процессах владельцы ресурсов заинтересованы в том, чтобы предлагать владельцам процессов исполнителей, которые им нужны, т.к. за «продаваемых» специалистов они получают деньги на покрытие своих расходов (на зарплату, обучение сотрудников и т.д.). Основное достоинство процессной структуры состоит в том, что она ориентирована на потребности индивидуального, а не массового клиента. Это позволяет оценивать работу по конечному результату, т.е. по таким характеристикам, как степень удовлетворения клиента, качество, длительность, стоимость. Концентрация на процессах, производящих ценности для клиентов, а не на каких-то других частях бизнеса позволяет наилучшим образом выполнить то, что должно быть сделано фирмой в конечном итоге. При этом оказывается, что значительная часть работы компании не связана с созданием потребительских ценностей и решает внутренние проблемы. 3.4. Последствия реинжиниринга В определении реинжиниринга подчеркивается решающая роль радикального перепроектирования бизнес-процессов. Однако необходимо помнить, что реинжиниринг не исчерпывается только перепроектированием процессов. Дело в том, что фундаментальное изменение бизнес-процессов оказывает воздействие почти на все аспекты компании. На рис. 3.12 показано влияние различных аспектов бизнес-системы друг на друга Так, изменение способа выполнения бизнес-процессов компании влияет на выбор организационной структуры. Изменение структуры влечет за собой изменение содержания работ исполнителей, что, в свою очередь влияет на то, каким образом менеджеры будут управлять исполнителями и оценивать их работу. Система оценок во многом определяет ценности и убеждения сотрудников. И, наконец, система ценностей оказывает влияние на эффективность выполнения процессов компании. Итак, для успешного функционирования компании все аспекты бизнес-системы должны быть согласованы. Рассмотрим более подробно последствия реинжиниринга в контексте описанных выше аспектов [2]. Изменение бизнес-процессов. Реконструкция бизнес-процессов должна происходить в соответствии с эвристическими правилами, описанными выше (п. 3.1). Предлагаемые правила направлены, в первую очередь, на упрощение потоков информации и организационных отношений, устранение лишних работ и связей. Перепроектирование бизнес-процессов должно проводиться одновременно с проектированием информационной системы (ИС), т.к. именно новые ИС во многом определяют новую структуру бизнес-процессов. Изменение организационной структуры. Новым перепроектированным бизнес-процессам наиболее соответствует процессная организационная структура, описанная выше (п. 3.3). Подчеркнем основные отличия новой структуры от традиционной. В традиционно организованной компании люди распределяются по отделениям, отделам, лабораториям, группам и т.п., в которых они выполняют предписанные им функции (части процессов). Эта фракционность создает много проблем, в частности проблему несогласованности и даже противоречивости целей различных групп людей. Реинжиниринг предполагает альтернативный подход, состоящий не в разделении людей по подразделениям, а в объединении людей в команды процессов, т.е. в группы людей, выполняющих совместно законченную часть работы - процесс. В зависимости от сути выполняемых работ используются различные типы команд процессов. Можно выделить три типа команд. Один тип команды объединяет некоторое число людей с различными специальностями, выполняющих рутинный повторяющийся процесс. В данном случае члены команды объединяются на длительное время. Такой тип команды используется компанией SAS (см. п.3.3). Другой тип команды объединяет людей для решения некоторой эпизодической, и, как правило, сложной задачи. В этом случае команда создается на время решения задачи. При завершении проекта команда расформировывается, а ее члены переходят в другие команды. Такой тип команды использовался компанией Kodak при проектировании камеры (см. п.1.4). Третий тип команды подобен первому типу, но состоит из одного человека. Этот тип использовался фирмой IBM Credit (см. п.1.4). Изменение содержания работ. Реинжиниринг изменяет не только организационные отношения, но и содержание работы исполнителей. Во-первых, работа меняется от простой к многоплановой. Член команды несет совместно с другими членами команды ответственность за весь процесс, что требует умения не только выполнять свое задание, но и понимать весь процесс в целом и уметь при необходимости выполнять не одно, а несколько заданий. Работа члена команды становится более содержательной. Во-вторых, вместо контролируемого исполнения предписанных заданий от работника требуется принятие самостоятельных решений. Члены команды фокусируют свои усилия на потребностях пользователей, а не на потребностях начальства. От членов команды требуется высокая оперативность и согласованность в работе. Это невозможно обеспечить без передачи полномочий по принятию решений исполнителям. В связи с многоплановостью и изменяемостью работ, ориентированных на процессы, меняются и требования к подготовке сотрудников. При непрерывно изменяющемся характере работы невозможно нанять людей, которые знают все, что от них может потребоваться. Поэтому компании должны заботиться не только о проведении обучающих курсов, но и о непрерывном образовании своих сотрудников. Изменение функций менеджеров. В традиционной функциональной компании оргструктура определяет иерархию принятия решений. При этом работа менеджеров в значительной степени состоит в контроле за исполнителями и в «склеивании» (координации) работ, выполняемых отдельными подразделениями или работниками, в единый процесс. Повышение самостоятельности и ответственности исполнителей, усложнение выполняемых ими работ приводит к тому, что уменьшается работа менеджеров по управлению и контролю за ходом выполнения процесса. Функции менеджеров изменяются, их задача состоит теперь не в выдаче управляющих и контролирующих воздействий, а в помощи членам команды решать возникающие проблемы. Таким образом, менеджер выполняет функции тренера, который не участвует в работе команды, но помогает команде выполнить ее работу с минимальными затратами. Уменьшается и требуемое количество менеджеров. Действительно, менеджер, осуществляющий контролирующие функции, обычно не может работать более чем с семью подчиненными. Менеджер, осуществляющий тренерские функции, может работать примерно с 30-ю людьми. Таким образом, значительно сокращается количество управляющих уровней, оргструктура становится более «плоской». Уменьшение управляющих уровней приближает руководство компании к непосредственным исполнителям и к клиентам. Функции администрации изменяются от секретарских к лидирующим. Изменение системы оценок. В традиционной компании схема оценки деятельности и оплаты труда довольно прямолинейна: людям платят за отработанное время. Понятно, что это далеко не самый эффективный способ оплаты, однако при разбиении работы на узкие задания довольно трудно оценить ее эффективность по конечному результату. После проведения реинжиниринга команда отвечает за результаты процесса, и в этом случае компания может оценить и оплатить работу команды в соответствии с полученным результатом. Жалованье сотрудника определяется не столько временем, проведенным на работе, важностью выполняемой работы, трудовым стажем, занимаемой должностью и количеством подчиненных, сколько эффективностью его работы, оцениваемой по конечному результату. Например, в компании IBM Credit (см. п.1.4) работа специалиста оценивается не по количеству отчетов, а по выгоде, полученной от заключенных им договоров. При таком подходе эффективность работы сотрудника в текущем году не является гарантией его эффективной работы в следующем году. По этой причине базовая зарплата сотрудника меняется мало, а размер премии целиком зависит от эффективности выполненной работы. Изменение системы оценок эффективности работы сотрудников влияет и на критерии продвижения в должности. Традиционные компании рассматривают продвижение в должности как награду за эффективный труд. При этом происходит недооценка как роли исполнителя (т.к. управленческая деятельность оценивается выше), так и роли менеджера (т.к. утверждается, что любой исполнитель может стать менеджером). Наградой за эффективность работы должна быть премия, а не продвижение по службе. Продвижение по службе должно зависеть исключительно от способностей сотрудника. Хороший программист не всегда сможет стать хорошим руководителем лаборатории программистов, т.к. у менеджера совершенно другая работа. Принцип здесь должен быть следующим: «платим за эффективность, продвигаем за способности». Убеждения и ценности. Реинжиниринг вызывает существенный сдвиг в культуре компании. Сотрудники не ощущают того надзора, который был раньше, они осознают рост своих полномочий и начинают чувствовать себя предпринимателями. Реинжиниринг требует от исполнителей убежденности, что они работают для клиентов, а не для своих начальников. Исполнители будут верить в это в той степени, в которой практика работы компании подтверждает это. Администрация компании должна обеспечивать мотивацию сотрудников, словом и делом укрепляя убеждения и ценности, установленные компанией. Контрольные вопросы и упражнения 1. На что направлены эвристические правила реконструкции бизнеса? В чем основная суть изменений, диктуемых этими правилами? 2. Является ли объединение подразделений компании примером горизонтального сжатия процесса? Если нет, то за счет чего происходит горизонтальное сжатие? 3. Как связано вертикальное сжатие процесса с передачей полномочий? 4. Что такое делинеаризация процесса? Поясните на примере. 5. К каким последствиям приводит введение вариантов исполнения процесса? 6. Использование правила «работа выполняется там, где это целесообразно» укрепляет или разрушает границы между подразделениями компании? 7. Приведите примеры работ, которые в соответствии с принципами реинжиниринга должны быть сокращены. 8. В чем преимущество введения уполномоченного менеджера? 9. За счет чего реализуется смешанный централизованный/ децентрализованный подход? 10. Какова роль новых информационных технологий в проведении реинжиниринга бизнес-процессов? 11. Каким образом использование телекоммуникационных сетей, беспроводной связи и технологии распределенных баз данных меняет правила работы компаний? 12. В чем разница между системами поддержки принятия решений и экспертными системами? Что дает их применение? 13. Объясните суть технологии автоматического индексирования и отслеживания. Как ее использование может помочь в реконструкции бизнеса? 14. В чем состоит преимущество интерактивного видеодиска по сравнению с обычным? 15. Какая новая информационная технология меняет старое правило «План пересматривается периодически» на новое: «План пересматривается оперативно, по мере необходимости»? 16. Приведите примеры новых бизнес-архитектур и соответствующих ИТ-архитектур. 17. Перечислите типовые роли сотрудников в компании, основанной на процессах. 18. В чем заключаются обязанности каждой из основных категорий сотрудников в «процессной» организационной структуре? 19. Приведите примеры команд процессов и ресурсных подразделений 20. Каковы отличия «процессной» организационной структуры от матричной? 21. В чем основные преимущества «процессной» оргструктуры? 22.. Какие виды команд процессов Вы знаете? 23. Как изменяется содержание работ исполнителей в результате проведения реинжиниринга? 24. Каковы основные функции менеджеров до и после проведения реинжиниринга? 25. Как меняется система оплаты труда и продвижения в должности после реинжиниринга? 26. Каким образом реинжиниринг влияет на культуру компании, на систему ценностей, поддерживаемую компанией? 4. Технология реинжиниринга 4.1. Директива на проведение реинжиниринга Типовая технология реинжиниринга бизнеса (регламент) представляет собой руководящие указания относительно последовательности и содержания этапов, используемых методов моделирования и анализа бизнес-процессов, а также инструментальных средств поддержки. На рис. 4.1 приведена укрупненная типовая последовательность проведения реинжиниринга. Основанием для начала работ по реинжинирингу служит директива на проведение реинжиниринга, принимаемая руководством компании. Директива должна быть составлена в терминах высокого уровня и выражать ожидания от реализации проекта. Майк Хаммер называет директиву документом типа «аргументы для действий». Такой документ объясняет ситуацию, в которой находится компания, и почему бизнес должен быть реконструирован. Работники должны быть убеждены, что компания не может продолжать идти прежним курсом, если она хочет выжить и остаться конкурентоспособной. Таким образом, основное назначение директивы – обеспечение мотивации к проведению реинжинирнга как для участников проекта, так и для всех сотрудников компании, затрагиваемых проектом. Роль мотивации для разных групп сотрудников различна. Чрезвычайно важна мотивация высшего руководства, т.к. реинжиниринг всегда проводится «сверху – вниз». Руководство должно верить в необходимость реинжиниринга и быть абсолютно убеждено, что проект по реинжинирингу даст значительный результат. С другой стороны, руководство должно отдавать себе отчет в трудностях, неизбежных при построении новой компании и должно уметь идти на некоторый риск. Как сказал Дж. Карлсон, «нужно отважиться сделать прыжок» [22]. Руководитель, возглавляющий проект по реинжинирингу, должен уметь сопротивляться давлению упрямой старой компании и должен убедить сотрудников в том, что проект не только выполним, но и необходим для выживания компании. Сотрудники компании должны понимать, почему проект приведен в действие, принимать свои новые задачи и быть готовыми к переменам. Относительно просто объяснить необходимость нового способа работы работникам нижнего уровня, но людям, исполняющим должности менеджеров, намного труднее понять, что новая компания может им предложить. Особое внимание рекомендуется уделять управляющим среднего звена, поскольку именно их деятельность в наибольшей степени будет изменена в результате реинжиниринга. Б.Виллох определяет три категории средних менеджеров [23]: 1. «Тигры». Это молодые карьеристы, которые хотя и участвуют с энтузиазмом в проекте по реинжинирингу, имеют тенденцию концентрироваться на своих собственных задачах в ущерб общим целям проекта. 2. «Ослы». Это старейшие сотрудники, достигнувшие целей своей карьеры, которые хотят спокойствия и стабильности в компании. Они могут серьезно навредить проекту. 3. «Акулы». Это сотрудники, которые разработали процедуры и инструкции для управления операциями компании, они часто имеют реальную силу в компании и могут создать огромные проблемы путем саботирования реальных перемен. В задачу руководителя проектом по реинжинирингу должно входить разъяснение задач реинжиниринга всем служащим компании, привлечение их на свою сторону и демонстрация преимуществ обновления бизнеса. Факторы, способствующие созданию положительной мотивации: • понятность целей реинжиниринга. Новые задачи компании должны быть четко сформулированы и понятны каждому сотруднику. Руководство и рядовые сотрудники должны понимать, как достичь стратегических целей. • широкие горизонты. Проекты, сформулированные в терминах роста и расширения, а не сокращения размеров и расходов, имеют больше шансов на успех, поскольку порождают больше энтузиазма и меньше сопротивления. • осязаемые результаты. Результаты работ по реинжинирингу должны быть конкретными. Работа по изменению компании должна фокусироваться на наиболее приоритетных целях, которые могли бы быть достигнуты примерно за год (этого времени обычно достаточно, чтобы создать первую версию реконструированных процессов). «Никогда не следует откусывать больше, чем можете прожевать». • самостоятельный бюджет проекта. Проект должен иметь свой собственный бюджет, особенно если планируется интенсивное использование ИТ. Часто ошибочно считают, что реинжиниринг возможен на условиях самофинансирования. • принцип первого руководителя. Проект должен выполняться под управлением руководства компании. Руководитель, возглавляющий проект по реинжинирнгу, должен иметь большой авторитет в компании и нести за него ответственность. Для успеха проекта очень важно твердое и умелое управление. Все перечисленные аспекты должны быть учтены при составлении директивы на проведение реинжиниринга. Ее основное содержание: 1. Анализ ситуации: изменение окружения компании, ожидания клиентов, увеличение конкуренции, трудности бизнеса компании, риск, вызванный сохранением существующего положения 2. Цели реинжиниринга. Цели должны быть величественны, чтобы мотивировать сотрудников компании на радикальные изменения в работе. С другой стороны, цели и ожидаемые результаты должны быть реалистичны и конкретны. 3. Средства реализации проекта: бюджет, руководство, планируемые сроки проведения реинжиниринга, использование технологической поддержки, приблизительный объем работ. 4.2. Подготовительный этап После издания директивы на проведение реинжиниринга начинается подготовительный этап, основным содержанием которого является создание системы управления проектом и планирование проведения реинжниринга (см. рис. 4.2). Создание системы управления начинается с определения участников проекта по реинжинирингу, их ролей и обязанностей. На рис. 4.3 приведена типовая организационная структура управления проектом. М Хаммер и Дж. Чампи для среднего проекта выделяют следующих участников реинжиниринга компании [1]: лидер проекта, руководящий комитет, исполнительный директор, владельцы процессов и члены команд по реинжинирингу. В приведенную организационную структуру не были включены владельцы ресурсов – руководители подразделений компании и сторонних организаций, сотрудники которых привлекаются к участию в проекте. Дело в том, что владельцы ресурсов непосредственно не участвуют в проекте по ренжинирингу, они лишь заключают соглашения о передаче своих сотрудников под управление владельцев процессов на время проведения проекта. Рассмотрим обязанности основных участников проекта. 1. Лидер проекта – член высшего руководства компании, который возглавляет организацию и проведение реинжиниринга. Он берет на себя основную ответственность и риск, связанные с проектом. Его основная задача – формирование представления о будущей обновленной компании и обеспечение должной мотивации остальных сотрудников. Лидер служит источником энтузиазма для всех участников реинжиниринга, он создает в компании атмосферу, в которой каждый сотрудник сможет проявить готовность отказаться от старых правил работы. Кроме того, лидер проекта назначает исполнительного директора и владельцев процессов. Он участвует в выработке стратегии обновления бизнеса, принимает наиболее важные решения и осуществляет общий контроль. Лидер проекта должен иметь достаточные полномочия для выполнения перечисленных задач. Очень важно, чтобы его личные качества соответствовали взятым на себя обязательствам: без сильного, агрессивного и высокопрофессионального руководства довольно сложно преодолеть сопротивление некоторых сотрудников компании происходящим изменениям. 2. Руководящий комитет (совет) наблюдателей – комитет, образованный из представителей высшего руководства компании. Как правило, в него входят владельцы процессов. Комитет возглавляется лидером проекта. Основная цель руководящего комитета – определение общей стратегии по реинжинирингу и контроль выполнения работ по проекту. В частности, им определяются приоритеты проектов, а также решаются проблемы, требующие совместных усилий владельцев различных процессов, преодолеваются конфликтные ситуации. Руководящий комитет не является обязательным участником работ, в небольших компаниях его функции может выполнять лидер проекта. 3. Исполнительный директор – специалист компании, выполняющий функции оперативного руководителя всех работ по реинжинирингу. Поскольку лидер не имеет возможности осуществлять повседневное оперативное управление проектом, он нуждается в помощнике, берущем на себя руководство штатом по реинжинирингу. Директор подчиняется непосредственно лидеру проекта и выполняет две основные функции. Первая состоит в обеспечении работы по каждому конкретному проекту: исполнительный директор помогает владельцам процессов привлекать специалистов для формирования команды по реинжинирингу; осуществляет помощь в работе команды. При этом в его задачу входит адаптация и развитие методик и инструментариев. Поэтому он должен владеть современными методами проведения реинжиниринга. Вторая функция директора состоит в координации работ по всем одновременно выполняемым проектам. Он организует взаимодействие владельцев процессов – обсуждения, инспекции и т.д. 4. Владельцы процессов – менеджеры высшего звена, отвечающие за обновляемые процессы. Они назначаются лидером проекта. Владелец процесса несет ответственность за обновляемый процесс, однако сам не выполняет реинжиниринг. Его задача состоит в привлечении квалифицированной команды процесса и обеспечении ей нормальных условий для работы над проектом. Владелец процесса участвует в процессе как наблюдатель, тренер и оппонент. Он также отвечает за мотивацию членов команды. 5. Команда по реинжинирингу - группа специалистов (сотрудники компании, а также эксперты и разработчики, привлеченные со стороны) для проведения реинжиниринга определенного процесса. Назначение членов команды сводится к распределению работ по исполнителям. Для выполнения проекта могут привлекаться следующие ресурсы и группы: • Группа моделирования бизнеса - специалисты, которые непосредственно занимаются созданием моделей существующего бизнеса, выработкой решений по реконструкции бизнеса, созданием моделей нового бизнеса, анализом и оценкой моделей и т.д. Они должны хорошо разбираться в деятельности компании, ее положении в соответствующей отрасли, внутренней организации компании, структуре ее продукции. • Эксперт по методу - специалист или группа специалистов, отвечающие за используемую методологию. Они должны быть экспертами по данному методу и оказывать команде помощь, необходимую для его применения в данном конкретном проекте. От этих специалистов требуется также понимание деятельности компании и степени компетентности остальных членов команды по реинжинирингу. • Группа прототипирования - специалисты, создающие компьютерные прототипы для исследования принимаемых решений и моделей. При использовании современных интегрированных инструментальных средств прототипы могут создаваться и группой моделирования бизнеса и отдельная группа прототипирования не нужна. • Группа документирования - специалисты, занимающиеся документированием моделей бизнеса, а также обсуждением и проверкой моделей с клиентами, менеджерами и служащими компании и т.д. Эта группа планирует обучение работников компании, клиентов, партнеров новым способам ведения бизнеса. От специалистов по документированию требуются специальные навыки по составлению ясных, понятных описаний и документов. • Координатор (группа координации) - специалисты, отвечающие за повторное использование смоделированной инфраструктуры в нескольких местах (например, в нескольких филиалах). Координатор должен оценить потенциальные возможности повторного применения разработанных моделей не только в рамках разрабатываемых проектов, но и для будущих проектов. Т.о. координация и управление библиотекой повторного использования должны иметь межпроектный статус. • Администратор проекта – специалист, отвечающий за выполнение текущих планов с учетом стоимости и сроков разработки. В больших проектах такой администратор просто необходим. Создание системы управления реинжинирингом включает в себя: • выявление единомышленников среди руководства и создание рабочей группы из представителей администрации; • подбор участников реинжиниринга; • выбор консультантов или внешних экспертов; • распределение обязанностей, заключение договоров; • создание условий для работы (предоставление помещений, компьютеров, закупка программного обеспечения и т.д.); • обучение участников реинжиниринга; • проведение вводного совещания; • планирование работы. Планирование проведения реинжиниринга. Несмотря на наличие типовой технологии проведения реинжиниринга, определяющей типовую последовательность этапов, типовой набор методик и инструментальных средств, для каждого конкретного проекта приходится проводить адаптацию типовой технологии к особенностям проекта. Каждый проект предъявляет свои особые требования к используемым методам, срокам, ресурсам, объему работ и т.д. Проекты по реинжинирингу могут отличаться по следующим аспектам: • размер реконструируемой компании и масштаб реинжиниринга (отдел, компания в целом, совокупность компаний в рамках отрасли); • сложность инфраструктуры бизнеса (степень диверсификации компании, территориальная разбросанность и др.); • опыт разработчиков как в области реинжиниринга в целом, так и в использовании конкретных методологий; • готовность копании к реинжинирингу (степень поддержки со стороны руководства и сотрудников компании). До начала разработки необходимо принять основополагающие решения по способу организации процесса реинжиниринга, учитывающие особенности проекта. Конкретный способ организации работ по реинжинирингу можно назвать прецедентом разработки. Таким образом, планирование работы над проектом по реинжинирингу представляет собой описание прецедента разработки. Основными аспектами этого описания являются: последовательность этапов реинжиниринга; содержание этапов, включая конкретные виды работ, используемые методики и перечень разрабатываемых документов; способы взаимодействия участников проекта по реинжинирингу. Последовательность этапов. Состав этапов для любого проекта примерно одинаков и включает в себя кроме подготовительного этапа этапы визуализации, прямого, обратного инжиниринга и внедрения. Однако схема применения этапов, порядок их следования и организация работ могут существенно отличаться. Существует несколько типовых схем организации работ, разработанных для процессов создания информационных систем, однако эти схемы могут быть распространены и на проекты по реинжинирингу. Различают три основных схемы [5, 24]: 1. Каскадная (водопадная) схема предполагает строгое линейное следование этапов по единому заранее разработанному плану (рис. 4.4). Такая схема, обладая определенными преимуществами (логичность, детерминированность, простота), имеет существенные недостатки, главный из которых заключается в том, что к моменту завершения работ зачастую обнаруживалось, что цели проекта не были достигнуты, т.к. не были учтены некоторые требования и ограничения. Кроме того, как правило, не выдерживался план-график выполнения работ, превышались сроки и смета. 2. Спиральная схема заключается в том, что разработка проекта ведется как бы по спирали, на каждом витке которой создается законченная версия системы (рис. 4.5). Создание каждой версии при этом предполагает последовательное выполнение всех этапов. Каждый виток спирали представляет собой, таким образом, законченный проектный цикл по типу каскадной схемы. Такой подход обеспечивает на каждом витке уточнение требований и ограничений, что позволяет достигать поставленные цели. Однако сроки разработки по сравнению с каскадной схемой удлиняются, а затраты существенно возрастают. 3. Макетная схема (другие названия: схема быстрого прототипирования, возвратная схема). Последовательность этапов в данной схеме внешне выглядит как каскадная, однако содержание технологических этапов таково, что многие проектные решения в процессе разработки подвергаются многократным уточнениям и корректировкам, как это предусмотрено спиральной моделью (рис. 4.6). Такой компромисс достигается за счет следующих особенностей процесса разработки: • на каждом из этапов создаются макеты (прототипы), представленные хотя бы и на бумаге, и оперативно обсуждаемые со всеми заинтересованными сторонами (будущими пользователями, заказчиками и т.д.); • на любом этапе по результатам обсуждений макетов при необходимости принимается решение о возврате на любой из предыдущих этапов с целью корректировки принятых решений; • выполнение этапов и отдельных работ в рамках каждого этапа осуществляется последовательно-параллельно. В результате общее время разработки при использовании технологии быстрого прототипирования существенно сокращается по сравнению со спиральной моделью, при этом качество конечного результата не теряется, а, возможно, и улучшается. Для проекта по реинжинирингу лучше использовать спиральную или макетную схему, т.к. они предполагают выполнение нескольких итераций, в ходе которых проект постоянно уточняется. Необходимость итеративной разработки обусловлена сложностью реинжиниринга. Существуют следующие причины для изменения и корректировки решений, принимаемых в ходе выполнения реинжиниринга: • цели никогда не удается сформулировать окончательно ясно, поэтому в ходе выполнения конкретной работы происходит их постоянное уточнение; • некоторые цели, запланированные в начале работы над проектом, оказываются нереалистичными и не могут быть достигнуты; • исполнители проекта обнаруживают, что для достижения всех целей им недостаточно времени и имеющихся ресурсов, поэтому они вынуждены отказаться от некоторых целей. Корректировка уже принятых решений и возврат на предыдущие этапы существенно удлиняет сроки разработки. Поэтому рекомендуется параллельно-последовательное выполнение этапов, как это предусмотрено макетной технологией. На рис. 4.7 приведен пример календарного графика проведения реинжиниринга в виде диаграммы Ганта. С некоторым сдвигом относительно начала выполнения подготовительного этапа запускается этап визуализации. После выполнения некоторых начальных процедур по визуализации инициируется параллельное выполнение этапа обратного инжиниринга. Возможно несколько итераций между этими двумя этапами. После того, как сформирована адекватная картина существующего бизнеса, инициируется этап прямого инжиниринга. После нескольких итераций этап визуализации заканчивается, и его результатом оказывается спецификация целей. Прямой инжиниринг исходит из этих спецификаций и моделей существующего бизнеса. Как только закончены разработка и тестирование отдельных процессов (пилотных проектов), может начинаться их внедрение. С учетом возможного параллельного выполнения нескольких версий картина еще более усложняется. Содержание этапов. В целях конкретизации типовых видов работ, выполняемых на различных этапах, необходимо осуществить оценку предполагаемых к использованию методов и моделей. Для оценки могут быть привлечены лидер проекта, эксперт по реинжинирингу, эксперты по методам, ведущие менеджеры компании. Основываясь на полученных оценках, следует принимать решения о том, какие методы и модели, в каком объеме будут использоваться в данном проекте. Следует адаптировать работы, предполагаемые методом, чтобы обеспечить оптимальное достижение конкретного результата. Кроме того, необходимо заранее определить перечень промежуточных и окончательных документов, которые следует разработать. Можно сэкономить много времени и сил, если составить образцы выпускаемых документов. В образце указывается, какого рода информация должна содержаться в каждом разделе и с какой степенью подробности она должна быть изложена. Составление образцов способствует единообразию документации, что особенно важно в тех случаях, когда документы подготавливаются разными исполнителями. Способы взаимодействия участников проекта. Основным средством взаимодействия участников проекта по реинжинирингу, призванным обеспечить должное качество результата работ по реинжинирингу, являются обсуждения. Обсуждения необходимы, во-первых, для взаимоконтроля участниками проекта принятых решений, а во-вторых, для координации принимаемых решений. Контроль включает в себя проверку моделей с точки зрения их полноты, избыточности, структуры, ясности и понятности, отслеживания версий документов, стандартов и т.д. Как именно осуществляется проверка, в значительной степени зависит от цели обсуждения. Рассмотрим три вида обсуждений [2]: 1. Совещание. Совещания нужны для того, чтобы убедиться в полноте и согласованности всех полученных к текущему моменту результатов. Различают формальные и неформальные совещания. Формальное совещание проводится по окончании каждого этапа. На нем рассматривается общий результат и принимается решение о переходе к следующему этапу разработки. При проведении совещания проверяются итоговые документы этапа: оцениваются принятые решения, выявляются ошибки. В таком совещании кроме владельцев процессов и членов команд должно принимать участие высшее руководство, т.к. только им может быть принято решение о переходе к следующему этапу. Кроме того, к совещанию могут быть привлечены клиенты и заказчики. Неформальные совещания могут проводиться в любое время разработки, например, по завершении какой-либо локальной работы для проверки ее результатов. В них, как правило, участвует несколько разработчиков и, возможно, представитель группы поддержки качества. На таких совещаниях членами команды обсуждаются созданные макеты и промежуточные документы. По итогам обсуждения вносятся необходимые коррективы и намечаются пути дальнейшей работы. 2. Инспекция. Это наиболее мощный из всех методов оценки и контроля. Представляет собой формальную методику оценки, результирующих документов этапа. Число участников инспекции невелико, как правило, не более восьми человек Выделяют следующие конкретные роли участников: • Арбитр (председатель) – обеспечивает создание творческой и продуктивной атмосферы и направляет деятельность участников на выявление ошибок; • Секретарь – фиксирует каждую обнаруженную ошибку, ее приоритет и степень серьезности; • Инспектор (оппонент) – несет ответственность за критический разбор; • Автор или проектировщик – докладывает результаты и дает необходимые пояснения. Итогом инспекционного обсуждения должно быть решение, принимается ли обсуждавшийся документ без изменений, принимается с внесенными корректировками или его принятие откладывается до очередной инспекции с тем, чтобы документ был доработан и исправлены все выявленные ошибки. 3. Прогон. Это неформальный способ оценки, при котором проектировщик «проводит» одного или нескольких членов команды, участвующих в проекте, через разработанный сегмент модели. Члены команды делают замечания по стилю, методам, возможным ошибкам, нарушению стандартов и т.д. Все ошибки, обнаруженные во время прогона, должны быть зафиксированы проектировщиком для дальнейшей проработки. Однако никаких формальных записей и протоколов не требуется: цель прогона - дать проектировщику информацию, необходимую для коррекции его работы. Прогон представляет собой хорошее упражнение с широким обменом информацией. 4.3. Этап визуализации Цель этапа – разработать образ будущей компании и сформулировать его в терминах спецификации целей компании. Основное содержание этапа визуализации (рис. 4.8): • анализ положения дел: понимание существующего бизнеса, выявление требований и ожиданий клиентов компании, партнеров и поставщиков; сравнение компании с другими предприятиями из ее окружения и оценка уровня компании; • спецификация целей реинжиниринга на основе анализа возможных стратегий развития компании. Понимание существующего бизнеса. Для разработки образа новой компании необходимо понять, как выглядит существующая компания. В компании, где применялся реинжиниринг, эта модель уже существует. Если нет, то ее следует создать. На этапе визуализации создается обобщенная модель бизнеса. В дальнейшем на этапе обратного инжиниринга будет построена более подробная модель. Как правило, выполняется одна или несколько итераций между этапами визуализации и обратного инжиниринга: сначала на этапе визуализации создается обобщенная модель существующего бизнеса и формируется первая версия спецификации целей, затем на этапе обратного инжиниринга создается подробная модель, описывающая состояние бизнес-процессов в деталях, и на ее основе уточняются первоначальные цели и т.д. Работа по пониманию существующего бизнеса начинается с идентификации, т.е. вычленения основных бизнес-процессов. Нужно помнить, что процессы моделируют завершенные потоки событий и должны иметь измеримую ценность для клиента (заказчика). Как правило, процессы пересекают границы существующих организационных подразделений, пронизывают их. Может оказаться, что определенные процессы не связаны с внешним по отношению к компании клиентом (актором). Это внутренние процессы, поддерживающие инфраструктуру бизнеса. Акторами для таких процессов могут выступать остальные части компании, взаимодействующие с этим процессом. При создании модели существующего бизнеса целесообразно сконцентрировать внимание на наиболее важных процессах. Не следует слишком распылять силы, лучше сосредоточиться на тех процессах, которые являются жизненно важными. Можно предложить следующие критерии выбора процессов для реинжиниринга: • процессы, оказывающие наибольшее влияние на клиентов, улучшение которых позволит полнее удовлетворить ожидания клиентов; • процессы, эффективность которых наиболее низка по сравнению с аналогичными процессами в компаниях-лидерах; • процессы, реинжиниринг которых может дать скорейшие позитивные результаты. Приоритетные, наиболее подходящие для реинжиниринга процессы выявляются путем оценки экспертами – высоко квалифицированными специалистами компании. Выявленные процессы следует распределить в порядке важности. В дальнейшем ренинжиниринг должен происходить в соответствии с присвоенными им рангами: сначала подвергаются перепроектированию наиболее важные процессы, затем менее важные и т.д. Для выделенных приоритетных процессов следует составить описание. Причем на этапе визуализации составляется содержательное описание высокого уровня. Не следует создавать излишне подробные описания, т.к. они предназначены для того, чтобы стимулировать дискуссию о будущей компании. Детали могут быть отложены до этапа обратного инжиниринга. Описание процесса должно включать описание клиентов, поставщиков и других партнеров, описание входов, действий и продукции процесса. Для каждого бизнес-процесса необходимо определить измеримые свойства (метрики), относительно которых можно оценивать существующий процесс, а в дальнейшем - различные варианты реконструкции процесса. Кроме того, когда новые процессы будут созданы, эти метрики можно использовать для контроля эффективности проведенных изменений, чтобы показать, как улучшилось функционирование процессов. Как сказал Дж. Харрингтон: «Измерения - это ключ. Если вы не можете измерить, то не сможете контролировать. Если не сможете контролировать, то не сможете управлять. Если не сможете управлять, то не сможете улучшить» [2]. Выбор метрик зависит от конкретного процесса. Обычно присутствуют метрики времени, цены и качества, например: среднее время обработки заявки, производительность (количество продукции в единицу времени), количество участников бизнес-процесса, себестоимость товара или услуги, процент брака (отказов клиентам), уровень обслуживания. Очень важно включить метрики, отражающие степень удовлетворения клиента (пользователя). В дополнение к описанию бизнес-процессов полезно составить описание организационной структуры компании, а также действующей системы оценок и ценностей. Требования клиентов, поставщиков и партнеров. Очевидно, что наибольший импульс на улучшение бизнеса исходит от клиентов компании. Следовательно, необходимо анализировать и количественно оценивать ожидания (настоящие и будущие) клиентов компании. Анализ лучше всего проводить при помощи опроса клиентов, спонтанных интервью или систематических исследований. Рекомендуется применять маркетинговые и социометрические методы исследований. Анализ клиентов бизнес-процесса включает: - классификацию существующих клиентов по признакам наиболее значимым для данного вида бизнеса; - классификацию потенциальных клиентов; - перечень потребностей, удовлетворяемых бизнес-процессом и не удовлетворяемых бизнес-процессом; - описание идеального (с точки зрения клиента) бизнес-процесса удовлетворения потребностей, идеального результата взаимодействия с бизнес - процессом фирмы; - оценку клиентами существующего процесса по метрикам стоимости, времени и качества (посредством качественных оценок – «плохо», «хорошо», «»отлично» или балльных). Основным результатом анализа должно быть выявление потребности клиентов по расширению и улучшению продуктов и услуг компании. Анализ партнеров и/или поставщиков бизнес-процесса включает: - оценку роли в бизнес-процессе (степени влияния на метрики бизнес-процесса); - требования к идеальным партнерам и/или поставщикам; - требования партнеров и/или поставщиков к бизнес-процессу; Оценка уровня. При оценке уровня осуществляется сравнение компании с лучшими фирмами-конкурентами. Следует сосредоточить свое внимание на компаниях, которые работают в той же отрасли, и на компаниях в других отраслях, использующих подобные процессы. Для сравнения выбираются компании-лидеры, отвечающие следующим требованиям: • имеют большие объемы продаж; • имеют хорошую репутацию; • производят товары хорошего качества. Сравнение существующего бизнес-процесса компании с аналогичными бизнес-процессами конкурентов целесообразно проводить по выделенным для данного процесса метрикам. По каждой метрике экспертами выставляется оценка (либо качественная, либо балльная). Оценка уровня позволяет выявить сильные и слабые стороны компании по сравнению с конкурентами. Кроме того, изучение бизнес-процессов компаний-лидеров может рассматриваться как средство визуализации того, как будет функционировать новая компания. Спецификация целей компании. Работа по спецификации целей начинается с формирования системы целей. Для выбранных наиболее приоритетных бизнес-процессов определяются цели их реконструкции. Цели выявляются на основе результатов анализа требований клиентов, партнеров, поставщиков и оценки уровня компании. Например, если большинство клиентов оценивают сроки изготовления продукта (предоставления услуги), как неудовлетворительные, то в качестве цели выдвигается сокращение среднего срока. Кроме словесных формулировок, по возможности, цели должны содержать значения метрик. Это могут быть не только абсолютные, но и относительные значения (например, в %-ном соотношении) или в виде интервала, например: «сокращение среднего времени обработки заявки на 50%», «увеличение количества обрабатываемых запросов в 10 раз», «сокращение общего количества участников бизнес-процесса со 100 человек до 10-20». Необходимо помнить, что реинжиниринг предполагает выдвижение величественных целей, предусматривающих резкое скачкообразное улучшение характеристик деятельности компании. Выдвинутые цели следует структурировать, т.к. одни цели могут быть подцелями других. Например, цели «сокращение сроков изготовления продукта на 50%» и «повышение качества обслуживания клиента» являются подцелями более обобщенной цели «улучшение степени удовлетворенности клиента». Для структурирования целей могут быть использованы различные методы построения деревьев целей [15, 25]. На рис. 4.9 приведен пример дерева целей реинжиниринга. Нижний уровень дерева составляют сценарии перепроектирования бизнес-процессов, т.е. стратегии изменения процессов, позволяющие достигать поставленные цели. Как правило, предлагается не один, а несколько возможных альтернативных сценариев. Разработка сценариев – наиболее сложная, слабо формализуемая и творческая работа. Часто она начинается с «мозгового штурма», в ходе которого команда по реинжинирингу набрасывает первоначальный набор возможных стратегий. Никакое новое предположение относительно изменения процесса не должно считаться слишком эксцентричным до его опробования. В конце концов, именно странные идеи дали начало фундаментально новаторским решениям. В соответствии с предложенными стратегиями изменения процессов необходимо построить прототипы – высокоуровневые описания будущих процессов. Следует оценить возможные последствия, составить приблизительный прогноз того, как изменятся характеристики процесса, определить факторы успеха и факторы риска. Для оценки эффективности разработанных сценариев могут быть использованы методы экспертных оценок, в частности метод анализа иерархий (МАИ), разработанный Т. Саати [25]. МАИ позволяет учесть при оценке сценариев степени важности целей, на достижение которых они направлены. В качестве основы метод использует дерево целей. Сначала определяются относительные приоритеты подцелей второго уровня. Приоритеты выражаются в виде баллов (чисел в интервале от 0 до 1). Чем выше балл, тем выше приоритет. Сумма приоритетов подцелей одной цели должна быть равна 1. Например, на рис. 4.9 второй уровень дерева целей составляют две подцели, соответствующие двум бизнес-процессам, приоритет одной цели равен 0.7, второй – 0.3. Для выявления приоритетов могут быть использованы матрицы парных сравнений [25]. Затем аналогичным образом расставляются приоритеты подцелей третьего уровня и т.д. На нижнем уровне таким же способом оцениваются сценарии (см. рис. 4.9). Для того, чтобы определить приоритет некоторого сценария относительно глобальной цели (цели верхнего уровня), необходимо перемножить приоритеты данного сценария и всех подцелей, входящих в цепочку от сценария до глобальной цели5. Например, глобальный приоритет сценария «Последовательно- параллельная технология» (рис. 4.9) равен: 0.6 × 0.8 × 0.65 × 0.7 = 0.22 Оценка сценариев позволяет «отсеять» заведомо плохие альтернативы. Результатом работ по визуализации является спецификация целей компании, которая должна содержать: • названия и краткую характеристику бизнес-процессов, подлежащих реинжинирингу; • измеримые цели для каждого процесса, которые должны быть достигнуты в результате реинжиниринга; • высокоуровневое описание будущих процессов, список факторов успеха и риска. 4.4. Этап обратного инжиниринга Основным содержанием этапа обратного инжиниринга является построение и анализ модели существующего бизнеса (рис. 4.10). Результатом этапа является модель текущего состояния бизнеса, которая в дальнейшем используется как для уточнения спецификации целей, так и в качестве основы для выполнения прямого инжиниринга компании. Иногда высказывается мнение, что создавать модель существующего бизнеса необязательно, т.к. реинжиниринг предполагает проектирование «с чистого листа». Однако большинство специалистов полагают, что такая модель необходима, т.к. она позволяет: • понять недостатки существующего бизнеса и определить «узкие места» – те области, в которых стоит проводить изменения; • объяснить сотрудникам, чем плохи прежние процедуры работы и почему они должны быть изменены; • измерить характеристики процессов, которые должны быть изменены, и установить новые измеримые цели. Следует подчеркнуть, что обратный инжиниринг имеет самостоятельную ценность вне зависимости от реинжиниринга компании, т.к. позволяет получить адекватную картину текущего положения дел в компании. В процессе построения модели существующего бизнеса часто бывает полезно опросить основных сотрудников компании и провести «инвентаризацию» их знаний и областей компетенции. Основные люди есть в любой компании. Зачастую они обладают уникальными знаниями о процессах компании. Зависеть от нескольких личностей очень опасно, т.к. если такой человек покинет компанию, это может привести к катастрофе. Поэтому очень важно выявить и зафиксировать знания таких специалистов в описании того, как функционирует бизнес компании. Рассмотри поэтапно процедуру построения и анализа модели существующего бизнеса. Построение внешней модели. Создание модели для приоритетных бизнес-процессов, выявленных на этапе визуализации, начинается с выявления и описания субъектов окружения (акторов), а также взаимодействия процессов с окружением. Для большинства внешних бизнес-процессов можно выделить следующие типы акторов: Клиент (Покупатель), моделирующий людей или компании, проявляющих интерес к покупке продуктов; Пользователь, моделирующий людей, для которых производится продукция; Поставщик, моделирующий компании, поставляющие сырье, материалы, комплектующие; Партнер, моделирующий компании, способствующие разработке и производству продукции. Кроме того, к акторам могут быть отнесены вышестоящие системы, в частности, государственные органы, осуществляющие контрольные, надзорные функции. Для внутренних бизнес-процессов в качестве субъектов окружения могут выступать те части компании, которые являются потребителями конечного продукта процесса или поставщиками. Не следует слишком подробно описывать акторов, необходимо сосредоточиться на описании их обязательств по отношению к бизнес-процессам и на описании конкретных взаимодействий акторов с процессами. Для наглядного представления взаимодействий может быть использована диаграмма вариантов использования языка UML (Use Case Diagram). Описание потока событий бизнес-процессов. Для каждого из приоритетных процессов необходимо подробнейшим образом опиисать всю технологию его выполнения в виде потока событий/состояний. Описав основной ход событий прецедента, следует описать важнейшие альтернативные или дополнительные потоки событий и исключения. В процессе этой работы следует обращать особое внимание на обстоятельства, которые могут привести к прерыванию основного хода событий и переключению на другую последовательность событий. Для наглядного представления потока событий могут быть использованы различные визуальные модели, например, диаграммы функциональной декомпозиции (IDEF0-диаграммы), диаграммы деятельности (Activity Diagrams) языка UML, диаграммы потоков работ (Work Flow Diagrams), диаграммы Ганта, имитационные модели и т.д. Выбор методов моделирования зависит от характера бизнес-процесса, а также от предпочтений участников команды по реиежинирингу. Построение объектной модели. Для каждого из моделируемых бизнес-процессов необходимо составить описания объектов, участвующих в прецедентах. При описании объекта следует указать, к какой организационной единице (отделу, департаменту, лаборатории, группе) он относится. Кроме активных объектов необходимо описать и объекты-сущности. Примеры типовых объектов-сущностей: Продукция, Услуга, Заказ. Можно составить описание в виде списка атрибутов. Для наглядного отражения структуры классов описаний объектов и отношений между классами можно построить диаграмму классов (Class Diagram) языка UML. Затем следует описать взаимодействие объектов при выполнении бизнес-процесса. Это дает представление, каким образом объекты, работая совместно, реализуют ход событий прецедента. Описание может быть представлено в виде диаграммы последовательности (Sequence Diagram) или диаграммы кооперации (Collaboration Diagram) языка UML. После того, как модель существующего бизнеса создана, следует провести обсуждения. Для выявления всех ошибок на раннем этапе необходимо присутствие на совещании представителей команды по реинжинирингу и сотрудников компании, выполняющих данный процесс. Анализ модели существующего бизнеса. После составления моделей для каждого из приоритетных бизнес-процессов необходимо выполнить анализ. При этом команде по реинжинирингу следует выполнить следующие действия [2]: 1. Измерить основные характеристики процессов с помощью метрик, предложенных на этапе визуализации. Как правило, это метрики времени, стоимости и качества. Для измерения стоимостных характеристик процессов можно воспользоваться методом функционально-стоимостного анализа. Он позволяет постатейно (в соответствии с выделенными центрами затрат) определить стоимость каждого шага по всей технологической цепочке и, таким образом определить фактическую себестоимость конечного продукта процесса. Очень важно учесть все затраты – и прямые, и косвенные, и постоянные и переменные. Для измерения времени выполнения процесса в целом и его отдельных шагов, а также анализа распределения ресурсов между работами во времени и степени загрузки ресурсов используют методы календарного планирования (диаграммы Ганта, дополненные диаграммами загрузки, сетевые диаграммы) и методы имитационного моделирования. Для измерения качества наряду с количественными характеристиками, такими как «процент брака», «процент отказов» можно использовать экспертные оценки (качественные, либо балльные). Полученные данные измерений будут впоследствии сравниваться со значениями модифицированных бизнес-процессов. 2. Оценить шаги процессов с точки зрения их необходимости. Для этого необходимо классифицировать каждое действие процесса, как «Увеличивающее потребительскую Ценность продукта» (УЦ-действие) или «Не Увеличивающее Ценность продукта» (НУЦ-действие). НУЦ-действия, такие как проверка платежеспособности клиента, согласование документов, передача документов из отдела в отдел и др. не вносят ничего ценного в конечный продукт (их отсутствие не повлияет на качество продукта). Поэтому следует рассмотреть возможность устранения таких действий. Некоторые НУЦ-действия не могут быть удалены, например, если они предписаны законодательством. Следует также оценить возможность уменьшения стоимости УЦ-действий и тех НУЦ-действий, которые нельзя удалить. 3. Идентифицировать проблемы и ограничения, связанные с существующими бизнес-процессами, основываясь на значениях метрик и результатах оценки шагов процессов. Список проблем («узких мест») нужно проранжировать в порядке убывания важности. В дальнейшем он послужит основой для внесения предложений по реконструкции процессов. Можно также провести опрос персонала для того, чтобы понять проблемы и получить предложения по их усовершенствованию. Следует исследовать краткосрочные рационализаторские предложения по простому улучшению существующих процессов. Важно, чтобы персонал видел, что уже на раннем этапе по обновлению происходит прогресс, что повышает его мотивацию. Важно при выявлении проблем существующего бизнеса проанализировать, как существующие информационные системы оптимизируют работу. Следует обсудить достоинства и недостатки их использования, исследовать, существует ли возможность увеличить эффективность их применения или требуется построение совершенно новой ИС. Выявленные в ходе опроса персонала проблемы следует внести в общий список проблем. 4. Скорректировать цели реинжиниринга, выдвинутые на этапе визуализации. Необходимо уточнить требования к будущим радикальным изменениям процессов, в частности, скорректировать измеримые цели, которые должны быть достигнуты в результате реинжиниринга (цена, качество, время, удовлетворение пользователя). 4.5. Этап прямого инжиниринга 4.5.1. Построение модели нового бизнеса Прямой инжиниринг начинается с построения модели нового бизнеса. В качестве основы используется модель текущего состояния бизнеса, построенная на этапе обратного инжиниринга, проранжированный список проблем и ограничений, а также уточненная спецификация целей. Рассмотрим поэтапно процедуру построения модели нового бизнеса (схема построения модели приведена на рис. 4.11). Выработка новаторских идей. Для каждого из приоритетных бизнес-процессов нужно проанализировать список проблем и ограничений, созданный на этапе обратного инжиниринга, и предложить идеи, каким образом можно устранить данные проблемы. Обычно эта задача решается методом «мозгового штурма» и с помощью изучения чужого опыта. Осуществляется поиск информации в литературе и прессе, исследуется опыт компаний с подобными процессами, проводится опрос служащих и руководителей компании, а также внешних экспертов и консультантов. В ходе генерации идей методом «мозгового штурма» обдумывается возможность применения эвристических правил реконструкции бизнеса (см. п. 3.1). Например, решаются вопросы: • можно ли несколько работ объединить в одну, выполняемую одним человеком или командой? • можно ли передать полномочия по принятию решений исполнителям? • можно ли некоторые шаги процесса выполнять параллельно? • можно ли выделить несколько версий процесса? • можно ли минимизировать согласования, проверки и управляющие воздействия в ходе выполнения процесса? При поиске ответов на поставленные вопросы должна учитываться возможность использования новых информационных технологий, т.к. именно новые ИТ позволяют кардинально изменить правила работы компании. Оцениваются также роли субъектов окружения (акторов) и исследуется, может ли изменение их роли помочь в решении проблем существующего бизнеса. Например, рассматриваются вопросы: • какие из обязанностей, выполняемых бизнесом, целесообразно передать клиентам или поставщикам/партнерам? • какие из обязанностей, выполняемых клиентами или поставщиками партнерами, лучше передать компании? Может быть принято решение, что, некоторые акторы не нужны. Например, компания может отказаться от внешних поставок какого-либо компонента продукции, начав производить его самостоятельно. Могут появиться совершенно новые акторы. После обсуждения всех предложенных идей и отсеивания заведомо плохих или нереализуемых следует составить список перспективных идей. Идеи полезно проранжировать в соответствии с их ценностью. Разработка альтернативных вариантов. На этом шаге конкретизируются обобщенные сценарии, включенные в спецификацию целей, с учетом предложенных новаторских идей. Возможно, при этом прежние сценарии будут кардинально пересмотрены или будут предложены новые сценарии. Однако не следует разрабатывать слишком много сценариев: для каждого из приоритетных бизнес-процессов достаточно от одного до трех вариантов. При разработке сценариев следует учитывать принципы реинжиниринга. Рассмотрим некоторые характеристики «хорошего» бизнес-процесса, соответствующего этим принципам [2]: 1. Процесс должен быть четко определен и прост для понимания. 2. Все шаги процесса должны, по возможности, способствовать увеличению ценности продукта для клиента, т.е. являться УЦ-действиями. Следует сократить ненужные проверки и согласования. 3. В выполнении экземпляра процесса должно участвовать как можно меньше людей. Если процесс достаточно мал, то желательно, чтобы его выполнял один человек. Наличие такого человека уменьшает количество передач дела из рук в руки, при которых возникают задержки, за счет чего временные показатели ухудшаются. 4. Важно, чтобы интерфейс с клиентом был настолько простым, насколько это возможно. Желательно, чтобы один человек обслуживал все контакты с клиентом и, по возможности, выполнял большую часть внутреннего потока событий. 5. Люди, реализующие задачи процесса, должны обладать необходимыми полномочиями. Они не должны ждать решения руководства, если произойдет что-то непредусмотренное, решения должны приниматься ими самостоятельно. 6. Должен существовать простой способ адаптации процесса к любым ограничениям бизнеса. Процесс, точнее его класс, может существовать в нескольких версиях. В зависимости от конкретных условий выполняется та или иная версия. Построение модели для каждого из вариантов. Для каждого из разработанных сценариев следует построить модель, отображающую бизнес-процесс в наглядном и структурированном виде. Процедура формирования модели нового бизнеса ничем не отличается от процедуры моделирования существующего бизнеса, используемой на этапе обратного инжиниринга. Она должна включать: построение внешней модели, показывающей взаимодействие бизнес-процесса с окружением; описание потока событий (как основного, так и вспомогательных и альтернативных); построение объектной модели, отражающей взаимодействие объектов в ходе выполнения бизнес-процесса. Созданные модели следует документировать и обсудить на ряде совещаний. Анализ моделей и выбор наилучших вариантов. Для каждого из рассматриваемых бизнес-процессов необходимо провести оценку вариантов. Оценка осуществляется путем измерения новых процессов с помощью метрик, предложенных на этапе визуализации. Измерение проводится аналогично измерениям на модели существующего бизнеса ­(см. п. 4.4). Для выбора наилучшего варианта (в случае, если предложено несколько альтернативных вариантов) результаты измерений по каждому из вариантов сравниваются друг с другом. Поскольку не всегда один вариант оказывается наилучшим по всем метрикам, для выбора оптимального варианта могут быть использованы методы многокритериального выбора [15]. При использовании подобных методов, прежде всего, необходимо нормировать значения метрик, т.е. перевести их в баллы. Один из способов нормирования: нужно найти разницу между значениями метрики для нового и существующего бизнеса и поделить ее на значение метрики для существующего бизнеса. Кроме того, метрики могут быть оценены по важности. Коэффициент важности (вес) метрики представляется в виде числа в интервале от 0 до 1. При этом сумма всех весов должна быть равна 1. Для подсчета интегральной оценки используются различные формулы. Наиболее распространенная – взвешенная сумма оценок. В соответствии с этой формулой для вычисления интегральной оценки некоторого варианта значение каждой метрики (в баллах) для данного варианта умножается на вес метрики и полученные числа складываются.. В таблице 4.1 приведен пример вычисления интегральной оценки для двух вариантов бизнес-процесса. Таблица 4.1 Оценка вариантов бизнес-процесса Метрика Вес метрики Существующий бизнес Вариант 1 нового бизнеса Вариант 2 нового бизнеса абсолют. значение абсолют. значение нормир. значение взвешенная оценка абсолют. значение нормир. значение взвешенная оценка Стоимость, руб. 0.5 3500 2000 0.43 0.215 1000 0.71 0.355 Время, час. 0.3 120 20 0.83 0.250 50 0.58 0.175 Качество, балл 0.2 - - 0.6 0.12 - 0.8 0.16 Интегральная оценка 0.585 0.69 В заключение нужно проверить, достигаются ли поставленные на этапе визуализации измеримые цели. Если нет – следует проанализировать причину неудачи и, возможно, вернуться к одному из предыдущих этапов. 4.5.2. Разработка новой организационной структуры Создание новой организационной структуры, соответствующей перепроектированным бизнес-процессам, осуществляется на основе объектных моделей бизнес-процессов. Этот процесс может рассматриваться, как адаптация объектной модели к реальным условиям Разработка оргструктуры включает: • определение состава команд процессов – сопоставление интерфейсным и управляющим объектам объектной модели нового бизнеса реальных исполнителей, т.е. сотрудников подразделений компании или внешних производителей; • организацию командной работы – реструктуризацию системы управления, разработку экономических механизмов деятельности команд процессов; • определение прав и обязанностей сотрудников компании в соответствии с новой структурой организационных отношений, создание новых должностных инструкций и/или контрактов; • создание систем мотивации и оценок, отражающих новые убеждения и ценности, установленные компанией. Определение состава команд процессов. Для того, чтобы сопоставить интерфейсным и управляющим объектам объектной модели нового бизнеса реальных исполнителей, полезно сначала выделить для каждого объекта все его обязательства (ответственность) во всех процессах (прецедентах) и всех экземплярах процесса с разными альтернативными потоками событий. Процедура выявления всех обязательств объекта описана в п.2.2.3. При назначении реальных объектов может оказаться, что одному объекту модели сопоставляется несколько реальных исполнителей, т.к. один работник не в состоянии выполнить все обязательства, либо, наоборот, обязательства нескольких объектов модели может выполнить один исполнитель. Кроме того, когда несколько экземпляров процесса могут выполняться одновременно, необходимо решить, может ли один и тот же исполнитель участвовать во всех экземплярах, либо для каждого экземпляра назначается свой исполнитель. Дополнительные ограничения появляются, если бизнес является географически распределенным. Следует определить, к какому из существующих организационных подразделений должен принадлежать каждый из исполнителей, участвующих в новых бизнес-процессах. Возможно, потребуется привлечь специалистов из других компаний. Организация командной работы. Реинжиниринг предполагает отказ от традиционной схемы управления по функциям и переход к управлению по бизнес-процессам. В процессе реструктуризации управления, введения процессной структуры необходимо определить, сколько и каких команд процессов нужно создать. Как правило, для каждого бизнес-процесса (и внешнего, и внутреннего) создается одна команда. Причем команда может состоять и из одного человека. Команды могут быть как временными (для решения единовременной задачи), так и постоянными. Если процесс может иметь несколько одновременно выполняющихся экземпляров, каждому экземпляру может соответствовать своя команда. Возможно, потребуется изменить структуру функциональных подразделений – упразднить или объединить некоторые подсистемы. Например, может быть принято решение, что отдел сбыта не нужен, т.к. команды процессов могут сами находить потенциальных потребителей и обеспечивать наилучшее исполнение их запросов. Альтернативным подходом может являться выделение сбыта в отдельный бизнес-процесс [7]. Введение процессной структуры предполагает переход на бюджетирование как основной метод планирования и контроля деятельности подразделений. Поскольку подразделения компании рассматриваются, с одной стороны, как потребители и, с другой – как производители товаров и услуг, необходимо определить стоимость продуктов внутреннего потребления, поставляемых одним подразделением компании другому. Внутренняя стоимость должна формироваться исходя из рыночной стоимости аналогичных товаров и услуг внешних производителей с учетом их сервиса, качества и гарантий [7]. Необходимо децентрализовать бухучет и анализ хозяйственной деятельности до уровня команд процессов. Виртуальный аналитический учет издержек и доходов подразделений компании существенно изменяет и дополняет традиционный бухучет, позволяя определить реальную эффективность их деятельности. На основании полученных финансовых результатов производится расчет прибылей/убытков и фонда заработной платы членов команд процессов [7]. Определение прав и обязанностей сотрудников. Изменение бизнеса меняет не только структуру организационных отношений, но и сам характер работы исполнителей и менеджеров. Как правило, введение процессной структуры приводит к обогащению и расширению содержания работ работников. Исполнителям делегируются широкие полномочия по принятию решений. С другой стороны, повышается их ответственность – теперь каждый ответственен не только за выполнение своих обязанностей, но и за работу всей команды. Новые правила хозяйствования устанавливают и новые требования к квалификации сотрудников. В связи с этим требуется разработать программу обучения сотрудников компании новым приемам работы. Необходимо также обеспечить доступ к информации, касающейся деятельности компании, регулярно информировать работников о происходящих на предприятии событиях. Все права и обязанности каждого из сотрудников должны быть закреплены в трудовых контрактах, а также временных соглашениях, заключаемых при создании команд процессов между операторами процессов, владельцами ресурсов и владельцами процессов. Создание систем мотивации и оценок. Новые системы мотивации должны обеспечить учет вклада каждого работника, поощрение постоянного повышения квалификации и универсализма в работе. Необходимо внедрить схему премирования, связанную с конечными результатами деятельности. Например, владелец процесса распределяет сумму дохода, полученного в зависимости от реализации продукции, между ленами команды по их трудовому вкладу. При этом в процентном соотношении премия (гибкая часть оплаты) должна быть существенно выше фиксированной части заработной платы. Могут использоваться и иные формы мотивации: участие в прибыли, помощь в обучении, социальные программы и т.п. [7]. 4.5.3. Построение информационной системы поддержки Информационные технологии являются основой реинжиниринга бизнес-процессов, т.к. решающим образом влияют на функционирование процессов и при правильном использовании приводят к многократному повышению результативности [2]. Учитывая важнейшую роль информационных систем поддержки нового бизнеса, необходимо как можно раньше определить основные функции информационной системы. Модели бизнес-процессов и модели информационной системы тесно взаимосвязаны: с одной стороны, модели нового бизнеса позволяют сформулировать требования к программному обеспечению, с другой стороны, модель ИС определяет направления модификации бизнес-процессов. Поэтому необходимо предусмотреть несколько итераций между формированием модели бизнеса и созданием ИС. Подобные итерации должны проводиться на протяжении всей разработки: на этапе визуализации определяются контуры обеих моделей, которые затем детализируются. Чем дальше продвигается разработка, тем более детальными становятся обе модели. Использование одних и тех же подходов для построения как бизнес-системы, так и соответствующей информационной системы значительно упрощает взаимосвязи между этими моделями. В данном параграфе будет рассмотрено, как объектно- ориентированная методология моделирования (в частности, язык UML) может быть использована при создании ИС нового бизнеса. Поскольку информационная система является достаточно сложной системой, для ее создания необходима мощная технология разработки. Сам процесс разработки информационной системы может рассматриваться как своего рода бизнес-процесс. Следовательно, этот процесс может быть представлен в виде модели прецедента «Разработка информационной системы». На рис. 4.12 представлены диаграммы прецедентной и объектной моделей данного прецедента6. Как видно из внешней модели (диаграммы вариантов использования) субъектами окружения прецедента «Разработка ИС» являются конечные пользователи системы и заказчики. Диаграмма деятельности отображает технологическую последовательность этапов разработки. Диаграмма кооперации дает наглядное представление об участниках разработки, их взаимодействии, а также о создаваемых и используемых в процессе разработки объектах-сущностях. Приведем описание каждого из этапов разработки информационной системы. 1. Сбор требований. На этом этапе собираются все предложения, идеи, пожелания и требования к информационной системе. Интерфейсный объект Интервьюер опрашивает потенциальных Пользователей ИС и Заказчиков. Собранная информация обрабатывается и формируется Список требований. Элементы списка упорядочены по приоритетам и содержат приблизительные оценки сроков разработки. Первоначальный список требований рекомендуется сформировать еще на этапе визуализации новой компании, когда определяется роль новых ИТ в модифицированном бизнесе. В дальнейшем список требований к системе прорабатывается и для наиболее важных компонентов информационной системы составляется окончательная спецификация требований. 2. Анализ требований. Цель этого этапа состоит в проверке полноты и непротиворечивости спецификаций требований и определении функциональных требований к системе. Наглядное представление о функциях системы и ее взаимодействии с пользователем дает прецедентная модель (П-модель ИС). Модель формируется Аналитиком требований. Он использует информацию, содержащуюся в Списке требований и объектной модели нового бизнеса (О-модели бизнеса). Сначала должны быть определены акторы системы (пользователи), основные прецеденты ИС и их взаимодействие. Затем должно быть составлено описание потока событий прецедентов, отражающее динамику поведения информационной системы. На основании П-модели ИС создается макет (прототип), который Тестирующим оперативно проверяется и обсуждается с будущими пользователями. 3. Идеальное проектирование (логическое проектирование). Этот этап предназначен для построения логической структуры информационной системы. Результатом является объектная модель (О-модель ИС), формируемая Проектировщик на основании П-модели ИС (при этом он также может использовать Список требований и О-модель нового бизнеса). Для каждого прецедента ИС Проектировщик выделяет объекты, необходимые для реализации потока событий прецедента, описывает их структуру и взаимодействие в ходе выполнения прецедентов. Затем создается уточненный макет системы, который Тестирующий обсуждает с пользователями. После проверки модели Проектировщик создает унифицированное и структурированное описание модели. 4. Реальное проектирование (физическое проектирование). На этом этапе разрабатывается модель, служащая базисом для реализации информационной системы. Разработчик адаптирует О-модель ИС к условиям реального окружения с учетом выбранных средств реализации (языка программирования, СУБД и т.д.) и возможностей стыковки ИС с существующим программным обеспечением. При этом формируется физическая структура баз данных, составляются подробные спецификации компонент, создаются макеты экранных форм и т.д. Важно обеспечить ясность и гибкость модели, что позволит в дальнейшем легко ее модифицировать. 5. Реализация. Цель данного этапа – создание программного кода и баз данных информационной системы. Программист на основании модели реализации разрабатывает программу, создает базы данных, сопроводительную документацию и т.д. 6. Тестирование. На данном этапе проверяется соответствие созданной информационной системы предъявляемым к ней требованиям. Тестирующий, тесно взаимодействуя с Пользователем и Заказчиком, проверяет соответствие готовой системы и документации спецификации требований. Тестирующий обрабатывает все замечания, пожелания и комментарии о продукте. Эта информация передается участникам разработки для исправления ошибок и внесения корректив. Тестирование – длительный и дорогостоящий этап. Раньше тестирование относили на конец процесса разработки и сводили только к проверке программного кода. Сейчас большинство специалистов считают, что о тестировании следует позаботиться с самого начала разработки. При этом специально выбранные пользователи проверяют не только макеты и готовые версии продукта, но и документацию. Результатом окончательного тестирования должны быть корректные результаты прогона системы на тестовых задачах. Наиболее сложными видами работ в технологии разработки ИС являются процедуры формирования прецедентной и объектной моделей информационной системы, выполняемые соответственно на этапах анализа требований и идеального проектирования. Поэтому рассмотрим их подробнее. Построение прецедентной модели информационной системы. Построение П-модели ИС начинается с выделения прецедентов и акторов системы, а также создания высокоуровневого описания прецедентов. Результатом является диаграмма вариантов использования. В [2] описан алгоритм создания такой диаграммы на основе объектной модели бизнеса. Рассмотрим последовательность шагов этого алгоритма: • на основе анализа объектной модели бизнеса выбирается активный объект (или актор), использующий в своей деятельности информационную систему, т.е. взаимодействующий с объектом, который относится к классу информационных систем; • выбранному объекту О-модели бизнеса в П-модели информационной системы сопоставляется актор – пользователь информационной системы; • на О-модели бизнеса проверяются все обязательства выбранного объекта. Если некоторое обязательство осуществляется с помощью информационной системы, то либо в П-модели ИС идентифицируется новый прецедент ИС и в его описание вносится соответствующее обязательство, либо обязательство вносится в уже выделенный ранее прецедент информационной системы; • если рассмотрены еще не все объекты, использующие ИС, то все шаги повторяются для очередного объекта. Поясним алгоритм на конкретном примере – формировании прецедентной модели информационной системы на основании О-модели бизнес-процесса «Продажа заказного продукта». На рис. 4.13 показаны О-модель бизнеса (фрагмент диаграммы кооперации) и П-модель ИС (диаграмма вариантов использования). Как видно из О-модели прецедента «Продажа заказного продукта» объект Продавец в ходе выполнения прецедента взаимодействует с информационной системой. Поэтому в П-модели ИС ему сопоставляется актор Продавец – пользователь ИС. Продавец в прецеденте «Продажа заказного продукта» имеет следующие обязательства, выполняемые с помощью ИС: «Вводит информацию о заказе в базу данных»; «Выбирает заказ, и делает отметку об оплате заказа»; «Выбирает заказ и вводит дату доставки продукта»; «Если продукт доставлен, удаляет заказ из БД». Для выполнения первого обязательства выделяется прецедент «Ввод нового заказа» и обязательство вносится в описание прецедента. Следующие два обязательства выполняются с помощью другого прецедента – «Выбор и редактирование заказа». Четвертое обязательство вносится в еще один прецедент – «Удаление заказа». После выделения акторов и прецедентов модели ИС необходимо составить полные описания выделенных прецедентов в виде потока событий и описания интерфейсов пользователей ИС. При этом используется не только модель бизнеса, но и список требований к информационной системе. Например, в прецедент «Ввод нового заказа» к уже внесенной функции ввода информации о заказе добавляется функция записи заказа в базу данных, функции, связанные с вычислением стоимости заказа, функции обработки ошибок ввода и т.д.; продумывается вид окна ввода заказа. На рис. 4.14 приведен пример описания потока событий данного прецедента в виде диаграммы деятельности (диаграмма описывает только основной поток событий, не учитывая дополнительные и альтернативные потоки). Создание описаний прецедентов ИС – сложная и трудоемкая работа. Рекомендуется разработать несколько различных сценариев (экземпляров прецедентов ИС) и создать несколько соответствующих макетов интерфейсов пользователя. Разработанные сценарии нужно обсудить с будущими пользователями. Построение объектной модели информационной системы. О-модель ИС формируется на основании П-модели ИС, списка требований и О-модели нового бизнеса. Сначала необходимо выделить объекты, участвующие в выполнении прецедентов ИС. Как уже указывалось в п. 2.2.1, объект ИС, создаваемый программой, является экземпляром некоторого класса и объединяет в одну структуру совокупность данных (атрибутов) и процедур (методов, операций). В контексте языка UML все объекты делятся на две категории: пассивные и активные. Пассивный объект (объект-сущность) оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они получают. Примером класса-сущности является таблица в базе данных. Активный объект может инициировать деятельность по управлению другими объектами, т.е. послать сообщение другому объекту, инициирующее выполнение этим объектом определенной операции [16]. Среди активных объектов можно выделить категорию интерфейсных. Интерфейсные объекты поддерживают взаимодействие ИС с окружением – с пользователями, с аппаратурой (принтерами, сканерами и т.д.), с другими системами. В частности, к интерфейсным объектам относятся экранные формы (окна, диалоговые окна), отчеты, протоколы связи. После первоначального определения объектов ИС следует описать их взаимодействие (включая взаимодействие с окружением системы) в виде диаграммы последовательности или диаграммы кооперации. На диаграммах данного типа каждое взаимодействие представляет собой сообщение, посылаемое одним объектом другому. При этом сообщения не только передают некоторую информацию, но и требуют от принимающего объекта выполнения ожидаемых действий. При генерации программного кода сообщения транслируются в вызовы методов (процедур) объекта. Таким образом, каждое сообщение диаграммы последовательности или кооперации должно быть соотнесено с операцией (процедурой). Рассмотрим пример формирования О-модели прецедента ИС «Ввод нового заказа», диаграмма деятельности которого приведена на рис. 4.14. На рис. 4.15 приведена диаграмма последовательности данного прецедента. Для реализации данного прецедента требуется интерфейсный объект «Окно ввода заказа», через взаимодействие с которым пользователь (Продавец) вводит всю информацию о заказе – номер заказа, ФИО клиента, его адрес и т.д. Окно содержит поля ввода и две командных кнопки – «Записать» и «Отмена». «Нажатие» пользователем на первую инициирует создание объекта «Заказ» и вызов процедуры записи заказа в базу данных. Объект «Заказ» содержит поля с информацией о заказе и процедуры, в числе которых – процедура записи в базу данных. После выполнения процедуры записи объект «Заказ» посылает сообщение окну ввода о завершении записи. Это сообщение инициирует закрытие окна. К такому же результату приводит «нажатие» пользователем кнопки «Отмена» в окне ввода заказа. 4.6. Тестирование и внедрение нового бизнеса Тестирование нового бизнеса – очень важная и ответственная часть разработки. Однако ошибочно ее относить лишь на конец выполнения проекта. Проверка нового бизнеса должна осуществляться на протяжении всего этапа прямого инжиниринга несколько раз. Она включает в себя: • проверку модели нового бизнеса; • проверку прототипа информационной системы поддержки; • выполнение пробной инсталляции модели всего бизнеса, но в масштабах изолированной части компании. После каждого тестирования следует анализировать результаты и, при необходимости, вносить дополнения, корректировки. Возможно, даже потребуется вернуться на один из предыдущих этапов. Тестирование лучше проводить на прототипах (макетах). Существует несколько видов прототипирования [11]: • информационное – создание прототипов на бумаге в виде диаграмм и текстовых описаний; • компьютерное – моделирование новых процессов с помощью компьютера; • организационное – моделирование новых процессов с участием сотрудников компании и клиентов в виде деловой игры. Информационное моделирование рекомендуется выполнять на ранних этапах создания модели нового бизнеса. Эта старомодная «проверка на столе» позволяет избежать грубых ошибок в основной концепции проекта. Этот метод прототипирования используется и для проверки модели информационной системы поддержки на ранних этапах ее проектирования. Компьютерные прототипы создаются с помощью инструментальных средств поддержки (см. гл. 5). Они позволяют более детально проанализировать различные шаги новых процессов, измерить параметры рассматриваемого бизнеса и получить оценку его работы. При создании информационной системы компьютерные прототипы не только облегчают проверку моделей ИС, но и упрощают процесс создания компонент системы – генерацию программного кода, определение структур баз данных и т.д. Организационное прототипирование, как правило, используется на заключительном этапе при проведении пробной инсталляции с участием реальных пользователей. Инсталляция процессов на примере отдельной части бизнеса позволяет оценить эффективность новых процессов и новой информационной системы, выявить различные проблемы и ограничения. В процессе тестирования моделируются различные ситуации, исследуется полнота и надежность созданной модели бизнеса. По результатам тестирования в модель могут быть внесены некоторые коррективы и уточнения. В случае, если пробная инсталляция прошла успешно, приступают непосредственно к внедрению новых бизнес-процессов. Это очень ответственный этап, потому что в то время, как внедряются новые процессы, необходимо продолжать работу существующих процессов. Клиенты и партнеры не должны испытывать неудобств от совмещения старых и новых процессов. Существуют различные способы аккуратного внедрения. Как правило, выбирают подразделение, специалисты которого имеют наилучшие шансы на достижение успеха при внедрении новых процессов и внедряют сначала в масштабах данного подразделения [2]. Контрольные вопросы и упражнения 1. Какова роль мотивации к проведению реинжиниринга для различных групп сотрудников компании? 2. Что должна содержать директива на проведение реинжиниринга? 3. Перечислите основных участников проекта по реинжинирингу, их роли и обязанности. 4. Каковы особенности каскадной, спиральной и макетной схемы разработки? Какая схема наиболее пригодна для реинжиниринга и почему? 5. Какие виды обсуждений Вы знаете? В чем состоят их отличительные особенности? 6. Что включает в себя анализ положения дел, проводимый на этапе визуализации? 7. Перечислите критерии выбора бизнес-процессов для проведения реинжинирннга. 8. Приведите примеры метрик бизнес-процессов 9. Каким образом осуществляется выявление и структурирование системы целей реинжиниринга? 10. Приведите пример иерархии целей реинжиниринга для некоторой компании и сделайте оценку целей и сценариев методом анализа иерархий (МАИ) 11. Каково основное содержание этапа обратного инжиниринга? 12. Какие методы измерений бизнес-процессов Вы знаете? 13. Приведите примеры УЦ- и НУЦ-действий. 14. Каково основное содержание этапа прямого инжиниринга? 15. Какие методы выработки новаторских идей Вы знаете? 16. Каковы основные характеристики «хорошего» бизнес-процесса, соответствующего принципам реинжиниринга? 17. Как осуществляется оценка и выбор наилучших вариантов нового бизнеса? 18. Что включает в себя разработка новой организационной структуры? 19. Охарактеризуйте основные этапы разработки информационной системы. Для каждого этапа укажите участников, исходные данные и результаты. 20. Как осуществляется построение прецедентной модели информационной системы на основе модели бизнеса? 21. Перечислите виды объектов информационной системы. 22. Какие виды прототипирования Вы знаете? 5. инструментальные средства поддержки проведения реинжиниринга 5.1. Классификация инструментальных средств Использование компьютерных инструментальных средств во многом определяет успех конкретного проекта по реинжинирингу. В конечном счете реинжиниринг может быть реализован и без использования поддерживающих инструментариев. Однако применение средств поддержки в процессе разработки может существенно сократить сроки разработки, уменьшить трудозатраты, повысить качество разработки, уменьшить количество ошибок. Инструментальные средства предоставляют следующие возможности, повышающие эффективность реинжиниринга: • Систематизация информации о проекте и его компонентах, что позволяет отслеживать процесс принятия решений, упрощает верификацию проекта и сопутствующей ему документации; • Визуальное моделирование, заменяющее разработчику бумагу и карандаш на компьютер и позволяющее формировать графический проект в интерактивном режиме с использованием визуальных средств (диаграмм, блок-схем, графов), дополненный различного рода описаниями, спецификациями, словарями; • Анализ построенных моделей, включая возможность просчитать стоимостные и временные характеристики различных процессов, проверить гипотезы «что, если …», проверить возможные последствия различных ситуаций и т.д.; • Поддержка коллективной работы – возможность параллельной разработки отдельных компонент проекта различными группами разработчиков с возможностью интеграции результатов в один общий проект; • Использование типовых решений – использование ранее накопленного опыта при принятии решений, например, использование готовых фрагментов модели; • Автоматическое создание компонент – например, автоматическая кодогенерация (создание компьютерных программ, баз данных на основе введенных моделей и диаграмм), формирование различного рода отчетов, документации по заданному шаблону и т.д. Все используемые в технологии реинжиниринга инструментальные средства поддержки можно условно разделить на две большие группы – CASE-средства и средства моделирования бизнеса, которые, в свою очередь разделяются на более мелкие группы (рис. 5.1). Границы этих групп размыты, пересекают друг друга. Классификацию усложняет и наличие интегрированных многофункциональных средств, которые поддерживают широкий спектр функций, начиная от построения и анализа моделей бизнеса и заканчивая разработкой приложений (программного обеспечения). CASE-средства. Это программно-технические средства для автоматизации разработки информационных систем. Первоначально они были ориентированы, в основном, на методологии структурного проектирования программного обеспечения и проектирования баз данных. Однако постепенно все больше акцент стал смещаться с проектирования компонент ИС на анализ автоматизируемой предметной области, на моделирование сложных систем широкого назначения. Неслучайно аббревиатура CASE, означающая Computer Aided Software Engineering – компьютерная поддержка проектирования программного обеспечения, все чаще стала расшифровываться как Computer Aided System Engineering – компьютерная поддержка проектирования систем [17]. Большинство современных консалтинговых фирм при проведении реинжиниринга используют CASE-средства. Современный рынок CASE-средств насчитывает сотни систем, различающихся по функциональным возможностям, применяемым методологиям, доступным платформам и цене. Существуют различные классификации CASE-средств [26]. Классификация по уровню проектирования в жизненном цикле создания ИС включает три категории: • средства верхнего уровня (Upper CASE), предназначенные для анализа предметной области, определения места информационной системы в контуре бизнес-системы; • средства среднего уровня (Middle CASE), использующиеся для разработки архитектуры информационной системы, создания проектных спецификаций; • средства нижнего уровня (Lower CASE), поддерживающие разработку программного обеспечения. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла и в основном совпадает с классификацией по уровням. Выделяют следующие типы: средства анализа предметной области (соответствуют Upper CASE); средства анализа и проектирования (соответствуют Middle CASE) и средства разработки приложений (соответствуют Lower CASE). Кроме того, выделяют вспомогательные типы CASE-средств, к которым относятся средства управления проектом, средства тестирования, документирования и т.д. Рассмотрим основные из перечисленных типов CASE-средств, а также их роли в технологии реинжиниринга. Средства анализа предметной области. Средства этого типа позволяют формировать модель предметной области (прежде всего, функциональную модель), например, в виде диаграмм функциональной декомпозиции или диаграмм потоков данных. Наиболее распространенные методологии, используемые ими – IDEF0 (SADT), ABC, DFD, IDEF3, UML. К средствам анализа относятся: Design/IDEF (Meta Software), BPwin (Logic Works), CASE Аналитик (МакроПроджект), Rational Rose (Rational Software Corp.). В технологии реинжиниринга эти CASE-средства используются на этапах обратного и прямого инжиниринга для построения моделей существующего, нового бизнеса. Средства анализа и проектирования. Выходом этих средств являются спецификации компонентов и интерфейсов информационной системы, архитектуры ИС, алгоритмов, структур данных (схем баз данных). Имеется множество методологий, используемых средствами этого типа. Например, для моделирования данных чаще всего используют диаграммы ERD, DSD, IDEF1X. Для моделирования архитектуры ИС используют различные методы структурного проектирования (например, диаграммы архитектуры системы SAD) и объектно-ориентированного проектирования (в частности язык UML). К средствам анализа и проектирования относятся: Silverrun (CSA), Erwin (Logic Works), Designer/2000 (ORACLE), CASE Аналитик (МакроПроджект), Rational Rose (Rational Software Corp.). В технологии реинжиниринга CASE-средства этого типа используются на этапе прямого инжиниринга для построения модели информационной системы поддержки нового бизнеса. Средства разработки приложений. Это RAD-средства и средства инжиниринга (реинжиниринга) программного обеспечения). Их основная функция – генерация программного кода на различных языках верхнего уровня, таких как C++, Object Pascal, Java, Visual Basic. При этом зачастую они используют спецификации, созданные средствами анализа и проектирования. К ним относятся: Power Builder (Sybase), Delphi (Borland), 4GL (Uniface Compuware), а также генераторы кодов, входящие в состав Rational Rose (Rational Software Corp.), Silverrun (CSA) и др. В технологии реинжиниринга CASE-средства этого типа используются на этапе прямого инжиниринга для создания информационной системы на основе модели ИС. Средства управления проектом. Это средства, предназначенные для планирования хода выполнения проекта, а также для сопровождения проекта (контроля и корректировки планов выполнения работ). Поскольку в качестве проекта может выступать не только разработка информационной системы, но и любой бизнес-проект (например, разработка нового изделия, проведение рекламной компании), средства данного типа относят как к CASE-средствам, так и к средствам моделирования бизнеса. Основные функции средств управления проектами • формирование календарных графиков работ в виде диаграмм Ганта (при этом можно задавать различные связи между работами: выполнение работы может допускаться по завершении другой работы, при наступлении определенного момента времени и доступности ресурса и т.д.); • управление ресурсами, включающее возможность задавать распределение ресурсов между работами во времени, строить диаграммы ресурсов, проводить анализ их загруженности, автоматически перераспределять ресурсы; • управление затратами, позволяющие рассчитывать финансовые показатели проекта, например, составление бюджета проекта, учитывающего затраты труда, расход материалов и накладные расходы. Наиболее распространенные средства данного типа: Microsoft Project (Microsoft), Time Line (Symantec), CA-SuperProject (Computer Associates International). В технологии реинжиниринга они используются на подготовительном этапе для планирования выполнения проекта по реинжинирингу. Кроме того, средства этой категории могут быть использованы на этапах обратного и прямого инжиниринга для создания модели бизнес-процесса в виде последовательности работ. Средства моделирования бизнеса. Не смотря на то, что многие CASE-средства, в частности, средства анализа предметной области, предоставляют возможности для моделирования бизнеса, они не всегда удовлетворяют потребности разработчиков моделей бизнеса. CASE-средства рассматривают модели бизнеса лишь как основу для проектирования информационных систем и, в связи с этим, не содержат развитых средств анализа и оптимизации бизнес-процессов. В настоящее время разработано множество средств, ориентированных не столько на проектирование ИС, сколько на анализ и реинжиниринг бизнеса. Впрочем, некоторые из них содержат и подсистемы для создания спецификаций компонент ИС и преобразования спецификаций в программные модули. Поэтому такие инструментарии можно отнести как к CASE-средствам, так и к средствам моделирования Условно средства моделирования бизнеса можно разделить на три группы: средства анализа бизнес-процессов, средства имитационного моделирования, средства интеллектуального моделирования. Дадим краткую характеристику каждой из этих категорий. Средства анализа бизнес-процессов. С их помощью осуществляется построение статических моделей компании (организационных, функциональных, моделей управления) и анализ эффективности организации бизнеса на основе этих моделей. Анализ включает в себя: калькуляцию затрат по методу ABC; оценку стратегических планов на основе сбалансированной системы показателей (Balanced Score Card - BSC); сравнение ключевых показателей эффективности бизнеса (экспортированных в том числе из систем планирования класса ERP) с показателями конкурентов; разработку и использование системы менеджмента качества и др. Средствами данного типа, получившими наибольшее распространение, являются: интегрированная среда анализа и проектирования ARIS (IDS Prof. Sheer), специализированное средство стоимостного анализа EasyABC (ABC Technologies), Business Design Facility (Texas Instruments), Business Improvement Facility (Virtual Software Factory). Использование этих средств в технологии реинжиниринга позволяет не только строить статические модели существующего и нового бизнеса, но и анализировать, сравнивать сценарии организации бизнеса на основе метрик. Средства имитационного моделирования. Средства данного типа позволяют строить динамические модели бизнес-процессов, копирующие реальные процессы. Модели как бы «проигрываются» на компьютере в сжатом времени или пошаговом режиме. При этом иногда используются даже анимационные эффекты для демонстрации состояний процесса. С помощью имитационных моделей можно получить статистику относительно характеристик процессов так, как если бы они происходили в реальности. Изменяя различные условия (например, распределение ресурсов между отдельными функциями) можно проанализировать вероятные сценарии по принципу «что - если». В большинстве инструментариев имитационного моделирования бизнес-процессы описываются с использованием графических символов. Отдельные функции процесса (рабочие процедуры) изображаются в виде последовательности прямоугольников (или других геометрических фигур) и стрелок. Описание процессов и работ включает различные характеристики, например: скорость поступления обрабатываемых данных или объектов, время обработки объектов и т.д. Причем, значения характеристик могут генерироваться в процессе «проигрывания» модели в соответствии с заданной статистической функцией. По результатам работы модели (в течении заданного времени) формируется отчет, содержащий статистику, например, время ожидания объектов в очередях, максимальное и минимальное время нахождения объектов в системе и.т.д.. К средствам имитационного моделирования относятся: Arena (Systems Modelling), ServiceModel (ProModel), ModSym (CASI), модуль ARIS Simulation интегрированной среды ARIS (IDS Prof. Sheer). В технологии реинжиниринга средства этой категории используются для анализа динамики процессов существующего бизнеса, а также для сравнения и оценки альтернативных сценариев организации нового бизнеса. Средства интеллектуального моделирования. Отличительной особенностью этих средств является использование методов инженерии знаний (экспертных систем), позволяющих представлять в моделях плохо формализуемые, эвристические знания экспертов о бизнес-процессах. Знания экспертов, хранящиеся в базе знаний, могут быть представлены в различном виде. Это могут быть знания об объектах, участвующих в бизнес-процессах, представленные в виде описаний классов и отношений между классами. Либо знания о поведении объектов, отражающие зависимости между действиями объекта и определенными событиями, и представленные в виде логических правил формата «если – то» или процедур. Машина вывода выполняет рассуждения (например, проверяет и исполняет правила) на основании знаний, содержащихся в БЗ, и данных, поступающих от внешних источников. Среди специализированных инструментальных средств интеллектуальных систем основной удельный вес занимают экспертные системы реального времени, бесспорным лидером среди которых является инструментальный комплекс G2 (Gensym). На базе G2, в свою очередь созданы различные проблемно- ориентированные расширения, в том числе комплекс ReThink,, разработанный специально для проведения реинжиниринга [2, 20]. Выбор инструментального средства. На выбор наиболее подходящего инструментария для конкретного проекта по реиинжинирнгу влияют следующие факторы. Функциональные возможности. Большинство средств ориентировано на достаточно узкий диапазон функций, однако в последнее время идет активное развитие интегрированных многофункциональных комплексов. Такие комплексы включают множество разнообразных инструментариев, объединенных на базе единого подхода. Например, интегрированная система ARIS содержит средства анализа и моделирования деятельности предприятий (в том числе модуль стоимостного анализа, модуль динамического имитационного моделирования), а также средства разработки информационных систем. Комплекс G2, интегрирующий ключевые достижения имитационного моделирования процессов, объектно-ориентированного программирования и инженерии знаний, позволяет решать широкий спектр задач, например, составление расписаний и планирование, мониторинг в реальном масштабе времени, оптимизация бизнес-процессов и др. При реализации больших проектов по реинжинирингу рекомендуется использовать именно многофункциональные средства. Однако, как правило, они достаточно дороги, сложны для использования и требуют длительного обучения работе с ними. Методология. В современных инструментариях используются практически все известные методологии проектирования. Наиболее распространенные методологии, такие как IDEF0, DFD поддерживаются множеством различных CASE-средств. Заметной тенденцией последнего времени стала разработка средств, поддерживающих сразу несколоько методологий, а также допускающих стыковку с другими инструментариями. Например, популярное CASE-средство BPwin поддерживает три методологии – IDEF0, DFD и IDEF3, а также экспорт и/или импорт с EasyABC, Arena, ERwin, MS Excel, MS Word. Интегрированные средства могут поддерживать десятки методов моделирования, например, ARIS – 83 метода. Для проектов по реинжинирингу разными авторами рекомендуются различные методологии. Значительное число специалистов советуют использовать объектно-ориентированные методы. В любом случае выбор методологии проектирования и выбор инструментального поддерживающего средства должны производиться одновременно на подготовительном этапе реинжиниринга. Ориентация на пользователя. Реинжиниринг осуществляют специалисты двух типов – профессионалы в области бизнеса (менеджеры) и профессионалы в области информационных систем (программисты). Большинство CASE-средств ориентировано на программистов и не предполагает непосредственного участия менеджеров в разработке моделей. Однако опыт ренинжиниринга показывает, что опосредованное участие менеджеров в компьютерном моделировании зачастую приводит к неадекватности моделей и к непоправимым ошибкам в проведении BPR. Ориентация на пользователей, не являющихся специалистами в области ИТ, предъявляет высокие требования к интерфейсу инструментального средства в части простоты использования. Интерфейс должен быть «прозрачным», легко осваиваемым для того, чтобы менеджеры могли самостоятельно, без помощи программистов воплощать свои идеи в виде работающих моделей бизнеса. Как правило, непосредственное использование менеджерами таких категорий инструментариев, как средства управления проектами, CASE-средства верхнего уровня, средства анализа бизнес-процессов, не вызывает трудностей. Определенные проблемы возникают при использовании менеджерами средств имитационного моделирования и интеллектуального моделирования, т.к. для работы с ними требуется специальная подготовка. Поэтому фирмы-поставщики подобных инструментариев, как правило, предоставляют методологическую поддержку своих продуктов и консалтинговые услуги. Технические характеристики и архитектура. При выборе инструментального средства необходимо учитывать, на какие вычислительные платформы и операционные среды оно ориентировано. Немаловажную роль играют также возможности многопользовательского доступа к инструментарию. Реализация крупного проекта требует участия множества специалистов. Поэтому организация совместной работы, реализуемая через такие средства, как архитектура клиент-сервер, хранилище моделей, управление доступом, зачастую является необходимым условием для успешного проведения реинжиниринга. Цена. Этот фактор играет не последнюю роль, т.к. стоимость различных инструментариев может отличаться в сотни раз. Самые дешевые средства, реализующие узкий диапазон функций, имеют стоимость порядка 300 – 1000 дол. Цена интегрированных многофункциональных средств колеблется в интервале 10000 – 50000 дол. Однако, несмотря на дороговизну, использование интегрированных средств для крупных проектов по реинжинирингу вполне оправданно, т.к. они поддерживают практически весь технологический цикл разработки, начиная от планирования и заканчивая разработкой информационной системы, и могут существенным образом повысить качество работ и снизить трудоемкость. Перейдем к рассмотрению наиболее популярных инструментальных средств, используемых в технологии реинжиниринга бизнес-процессов.. 5.2. Инструментальное средство BPwin BPwin является мощным средством моделирования и документирования бизнес-процессов. Этот продукт использует технологию моделирования IDEF0 – наиболее распространенный стандарт, который принят для моделирования бизнес-процессов. Кроме стандарта IDEF0, BPwin поддерживает также методологии моделирования DFD (data flow diagram) и IDEF3 (workflow). Методология DFD используется для описания потоков данных, которые возникают в результате деятельности компании. Методология IDEF3 служит для графического описания потока процессов (работ), взаимодействия процессов и объектов, которые изменяются этими процессами [19]. BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. Общий вид рабочего интерфейса представлен на рис. 5.2. Его основными элементами являются: главное меню, основная панель инструментов (ниже главного меню), навигатор модели (в левой части рабочего интерфейса), окно модели (в правой части рабочего интерфейса) и специальная панель инструментов, вид которой зависит от выбранного типа модели (располагается между навигатором и окном модели). Данное расположение элементов интерфейса принято по умолчанию, однако оно может быть изменено пользователем. Рис. 5.2. Рабочий интерфейс среды моделирования BPwin Навигатор модели показывает в виде раскрывающегося иерархического списка все диаграммы, открытые в BPwin. С его помощью можно перейти на любую диаграмму. Кроме того, на специальной вкладке навигатора в виде списка показаны и все блоки, включенные в диаграммы модели. Создать новую модель можно через меню File/New или соответствующую.кнопку основной панели инструментов. Возникает окно диалога, в котором следует внести имя модели и выбрать методологию, в которой будет построена модель. Рассмотрим для примера создание модели в стандарте IDEF0. При создании модели автоматически создается диаграмма верхнего уровня (контекстная диаграмма) с единственным функциональным блоком, изображающим систему в целом. Для задания имени блока следует щелкнуть по нему правой кнопкой мыши, выбрать в меню Name и в появившемся диалоге внести имя. Для создания граничных стрелок, отражающих взаимодействие системы с окружением, нужно сначала перейти в режим рисования стрелок, щелкнув по кнопке в специальной панели инструментов. Для внесения входящей стрелки (входа, механизма или управления) нужно сначала щелкнуть у границы диаграммы (откуда начинается стрелка), а затем – на нужной стороне функционального блока. Для рисования стрелки выхода наоборот, надо сначала щелкнуть на правой стороне блока, а затем – у правой границы диаграммы. Для задания имени стрелки необходимо вернуться в режим редактирования, щелкнув по кнопке в панели инструментов, затем щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и ввести имя в появившемся диалоге. Имена вновь внесенных стрелок автоматически заносятся в словарь [19]. Для создания диаграммы декомпозиции нужно щелкнуть по кнопке перехода на нижний уровень и в окне диалога указать количество функциональных блоков на диаграмме декомпозиции (в дальнейшем можно будет добавить недостающие блоки или удалить лишние). Появляется диаграмма декомпозиции с расположенными на ней блоками. Блоки располагаются по диагонали, начиная с левого верхнего угла и кончая нижним правым углом. Имена блоков задаются так же, как и имя блока на родительской диаграмме. Стрелки, которые были внесены на контекстной диаграмме, автоматически переносятся на диаграмму декомпозиции (им присваиваются ICOM-коды), но при этом они не касаются блоков. Связывание граничной стрелки с блоком осуществляется аналогично рисованию граничной стрелки на диаграмме верхнего уровня. Для рисования внутренней стрелки, связывающей блоки между собой, необходимо в режиме рисования стрелок, щелкнуть по правой стороне одного блока и затем – по нужной стороне (например, левой) другого блока. Для разветвления стрелки нужно в режиме редактирования щелкнуть по фрагменту стрелки и по соответствующей стороне блока, а для слияния наоборот: сначала – по левой стороне блока, а затем по соответствующему фрагменту стрелки. Функциональность BPwin заключается не только в рисования диаграмм, но и в проверке целостности и согласованности модели. BPwin обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании, таких, как «зависание» связей при переходе от диаграммы к диаграмме, нарушение ассоциации связей в различных диаграммах модели и т.п. Для оценки моделируемых бизнес-процессов BPwin предоставляет разработчику два инструмента – функционально-стоимостной анализ (ABC) и оценка свойств, определяемых пользователем. При проведении стоимостного анализа сначала задаются единицы измерения времени и денег. Их можно задать в диалоговом окне Model Properties (меню Edit/ Model Properties). Затем описываются центры затрат, для чего вызывается диалог Cost Center Dictionary (меню Dictionary/ Cost Center). Задание стоимости функциональных блоков следует начинать с диаграмм нижнего уровня. Для задания стоимости блока нужно щелкнуть правой кнопкой мыши по блоку и во всплывающем меню выбрать Costs. Откроется диалог Activity Properties, вкладка Costs. В нем можно ввести суммы (стоимости соответствующей функции) по каждому центру затрат. Можно указать также продолжительность данной функции (Duration) и частоту ее выполнения в рамках общего процесса (Frequency) [19]. Общие затраты по функции рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) функции сначала вычисляется произведение затрат дочерней функции на ее частоту, затем результаты складываются. Если для всех блоков модели включен режим Compute from Decompositions, подобные вычисления автоматически проводятся по всей иерархии функциональных блоков снизу вверх [19]. Для проведения более тонкого стоимостного анализа можно воспользоваться специализированным средством EasyABC, с которым BPwin имеет двунаправленный интерфейс. 5.3. CASE-средство Rational Rose CASE-средство Rational Rose фирмы Rational Software Corp. является одним из наиболее мощных инструментов объектно-ориентированного анализа и проектирования. Корпорация Rational Software стояла у истоков разработки языка UML и CASE-средств его поддержки.. Rational Rose содержит все диаграммы UML, начиная от диаграмм вариантов использования и заканчивая диаграммами реализации. Одним из наиболее мощных свойств данного инструментария является возможность генерации программного кода (на языках C++, Java, Visual Basic, PowerBuilder и др.) на основе построенных моделей [16]. В Rational Rose реализованы общепринятые стандарты на пользовательский интерфейс программы. На рис. 5.3 представлен общий вид интерфейса. Рис. 5.3. Рабочий интерфейс программы Rational Rose В верхней части окна находится меню и стандартная панель инструментов. В левой части рабочего интерфейса находится окно браузера (Browser), в котором представлены все диаграммы и элементы диаграмм в виде иерархического списка. Любой элемент, который разработчик добавляет в модель, сразу отображается в этом окне. Оно облегчает навигацию, позволяет отыскать любой элемент и «отбуксировать» его при помощи мыши в окно диаграммы. В правой части рабочего интерфейса находится окно диаграммы (Diagram). Одновременно в нем могут присутствовать несколько диаграмм, однако активной может быть только одна из них. Окно диаграммы называют также рабочим столом Rational Rose. Внизу рабочего стола находится свернутое окно протокола (Log). В нем Rational Rose постоянно фиксирует все действия, произведенные над диа­граммами. Между окном браузера и окном диаграммы находится панель инструментов текущей диаграммы (специальная панель), вид которой зависит от типа активной диа­граммы. В нижней левой части интерфейса, под окном браузера находится окно документации (Documentation). В этом окне можно записывать самую различную информацию о вы­деленном в текущий момент элементе диаграммы. Представленное на рис. 5.3 расположение элементов интерфейса принято по умолчанию, однако оно может быть изменено пользователем. Рассмотрим пример создания нового проекта в середе Rational Rose. При запуске программы автоматически будет создан новый проект, содержащий представление вариантов использования (Use case view), логическое представление (Logical View) и представление компонент (Component view). Все эти представления отражены в окне браузера в виде папок (пакетов). Работа над проектом обычно начинается с построения диаграммы вариантов использования (Use case diagram). Для ее активизации необходимо раскрыть пакет Use case view в браузере и дважды щелкнуть на пиктограмме Main (главная). При этом появится специальная панель инструментов, на которой присутствуют все необходимые для построения диаграммы вариантов использования элементы. Назначение кнопок панели можно узнать из всплывающих подсказок [16]. Для того, чтобы поместить на диаграмму некоторый элемент (например, актора или вариант использования), нужно выбрать на панели инструментов нужный инструмент (Actor или Use Case), после чего щелкнуть мышью на свободном месте диаграммы. На диаграмме появится изображение элемента с маркерами изменения его геометрических размеров и предложенным программой именем по умолчанию. Поменять имя можно, щелкнув левой клавишей мыши на выделенном элементе и введя новое имя в поле под элементом. Переименовать можно и в окне спецификации элемента, которое вызывается двойным щелчком мыши на выделенном элементе. В спецификации отображается вся информация об элементе. С помещенными на диаграмму элементами можно производить различные действия при помощи мыши: перемещать, удалять и изменять размеры. Для этого на панели инструментов должен быть активен инструмент выбора (Selection Tool). Для того, чтобы установить связь между элементами типа ассоциаций, обобщений или зависимостей, необходимо выбрать на панели инструментов нужный инструмент, выделить первый элемент связи и затем, не отпуская нажатую левую кнопку мыши, переместить указатель ко второму элементу связи. Для связи можно задать имя и определить различные свойства в окне спецификации, которое вызывается двойным щелчком мыши на связи. Можно также разместить на диаграмме примечание с помощью инструмента Note и привязать его к некоторому элементу с помощью инструмента Anchor Note to Item. Кроме того, с помощью инструмента Text Box можно создать произвольную надпись на диаграмме, не привязанную ни к какому элементу. Последним этапом создания диаграммы является документирование элементов диаграммы. Документация (поясняющий текст) на активный элемент вносится в окне Documentation. Пример диаграммы вариантов использования приведен на рис. 5.3. Для любого из вариантов использования можно создать диаграмму деятельности (Activity diagram), раскрывающую последовательность действий при его выполнении. Для создания диаграммы необходимо щелкнуть правой кнопкой мыши на выбранном варианте использования и во всплывающем меню активизировать Sub Diagrams → New Activity Diagram. На рабочем столе появится пустое окно диаграммы деятельности. При этом поменяется специальная панель инструментов. Процесс добавления и удаления элементов диаграммы (действий, состояний, переходов, ветвлений и др.) аналогичен этим же действиям с элементами других диаграмм. На рис. 5.4 приведен пример диаграммы деятельности. Рис. 5.4. Пример изображения диаграммы деятельности в среде Rational Rose Другой взгляд на реализацию варианта использования дает диаграмма последовательности (Sequence diagram), которая раскрывает последовательность взаимодействия объектов в ходе его выполнения. Создать диаграмму последовательности можно следующим образом: в окне браузера установить курсор на пакет представления вариантов использования (Use case view), вызвать всплывающее меню щелчком правой кнопки мыши и выбрать в меню New → Sequence Diagram. Затем нужно ввести имя диаграммы и активизировать ее двойным щелчком. На рабочем столе появится окно диаграммы последовательности. Панель инструментов диаграммы приобретает вид, представленный на рис. 5.5. Рис. 5.5. Пример изображения диаграммы последовтельности в среде Rational Rose Построение диаграммы последовательности сводится к добавлению или удалению отдельных объектов и сообщений. Если инициатором сообщения является актор, его следует перенести с диаграммы вариантов использования. Для этого в окне браузера нужно раскрыть диаграмму Main, выберать нужный элемент (актора) и «отбуксировать» его с помощью мыши в окно диаграммы. Чтобы создать объект (получателя или инициатора сообщений), на панели инструментов необходимо выбрать инструмент Object и щелкнуть мышью в верхней части окна диаграммы правее уже помещенных объектов. Задать имя объекта можно двумя способами: щелкнув на выделенном объекте, ввести имя внутри прямоугольника, обозначающего объект; или щелкнув двойным щелчком на выделенном объекте, ввести имя в окне спецификации. Для того, чтобы отобразить взаимодействие между объектами, необходимо выполнить следующие действия: - на панели инструментов выбрать инструмент Message (сообщение); - установить курсор на линии жизни объекта – инициатора сообщения в нужном месте, соответствующем последовательности передачи сообщения; - не отпуская кнопки мыши, переместить указатель к линии жизни объекта-получателя сообщений. Имя сообщения можно ввести в окне спецификации, которое открывается двойным щелчком на выделенной линии сообщения. В дальнейшем можно переименовать сообщение: щелкнуть на нем мышью и ввести имя в поле над линией сообщения. Последним этапом создания диаграммы является документирование элементов диаграммы. На основе диаграммы последовательности можно создать диаграмму кооперации (Collaboration diagram), которая является другим способом визуализации взаимодействия объектов. Особенность работы в среде Rational Rose заключается в том, что диаграмма этого вида создается автоматически после построения диаграммы последовательности и нажатия клавиши . С помощью этой же клавиши осуществляется переключение между диаграммами последовательности и кооперации [16]. После того, как диаграмма кооперации будет создана, можно активизировать любой объект, помещенный на диаграмму, и передвинуть его. Можно поместить на диаграмму новые объекты или классы, новые сообщения. При этом изменения, вносимые в диаграмму кооперации, автоматически вносятся и в диаграмму последовательности. По окончании сеанса работы над проектом выполненную работу необходимо сохранить в файле проекта с расширением mdl. Это можно сделать через меню File→Save. В дальнейшем в начале нового сеанса можно открыть этот проект для последующей модификации через меню File→Open. 5.4. Средство имитационного моделирования ARENA Система Arena корпорации Systems Modeling – один из наиболее эффективных инструментов имитационного моделирования. Она позволяет создавать стохастические динамические модели, «проигрывать» их и анализировать результаты такого «проигрывания». Имитационная модель Arena включает следующие основные элементы [19, 27]: • процессы (Process) – работы, операции, действия; • ресурсы (Resource), выполняющие процессы – люди (продавцы, клерки, рабочие) или оборудование (станки, компьютеры); • сущности (Entity), обрабатываемые процессами – заказы, документы, заготовки изделий, клиенты и т.д.; • очереди (Queue) из сущностей, ожидающих обработки – образуются перед процессами, которые в данный момент заняты. Процессы отображаются в виде графических модулей. Для процессов разного типа используются разные графические обозначения. На рис. 5.6 а – 5.6. д приведены обозначения некоторых процессов. а) модуль Create б) модуль Dispose в) модуль Process г) модуль Decide д) модуль Assign Рис. 5.6. Пример изображения графических модулей модели Arena Модуль Create (рис. 5.6 а) или Источник создает сущности, обрабатываемые в системе. Он имитирует, например, прибытие клиентов в банк или в магазин, поступление документов (заказов, чеков), начало изготовления продукции на производственной линии. Скорость поступления сущностей от Источника обычно задается статистической функцией. Модуль Dispose (рис. 5.6 б) или Сток удаляет сущности из системы. Он имитирует, например, уход клиентов из банка или магазина, окончание обработки документа или изготовления изделия. Модуль Process (рис. 5.6 в) является основным модулем процесса обработки в имитационной модели. Он имитирует, например, обслуживание клиентов, обработку документов или деталей, выполнение заказов. Время обработки сущности в процессе (производительность процесса) обычно задается статистической функцией. Модуль Decide (рис. 5.6 г) служит для принятия решений в имитационной модели. Он позволяет проверять условия и в зависимости от результата проверки направлять сущности по той или иной ветке (тому или иному процессу). Обычно условия основаны на значениях атрибутов (характеристик) сущностей. Например, если клиенту банка требуется операция снятия со счета, то он направляется в один отдел, если он хочет оформить кредит, то – в другой отдел. Модуль Assign (рис. 5.6 д) предназначен для задания значения переменной в системе, в частности, значения атрибута сущности. Например, можно задать номер операции, требуемой клиентом, или тип документа. Обычно задается случайное значение по заданной статистической функции. Модули соединяются между собой в соответствии с логикой выполнения имитируемого бизнес-процесса. На рис. 5.7 приведена в качестве примера имитационная модель системы обслуживания клиентов в банке. Модуль Crate 1 имитирует приход клиентов в банк. Распределение времени между приходами клиентов описывается некоторым законом. Модуль Assign 1 присваивает клиентам атрибут oper, характеризующий кассовую операцию (номер операции). Может быть назначен один из трех видов операций, для каждого из которых задана вероятность. Модуль Decide 1 распределяет клиентов по кассам в зависимости от операции, которую им необходимо выполнить. Модули Process 1, Process 2, … Process 5 имитируют работу соответственно первого, второго, … пятого кассира. Время выполнения операций описывается некоторым законом распределения (например, экспоненциальным законом с заданным средним значением). Модуль Decide 2 распределяет клиентов между вторым и третьим кассиром, выполняющими операцию 2. Он направляет клиента тому кассиру, очередь у которого меньше. Модуль Decide 3 распределяет клиентов между четвертым и пятым кассиром аналогично модулю Decide 2. Модуль Dispose 1 имитирует уход клиента из банка. Общий вид пользовательского интерфейса системы Arena представлен на рис. 5.8. В верхней части окна находится меню и панели инструментов. В левой части рабочего интерфейса находится окно проекта, которое включает в себя несколько панелей: Basic Process (панель основных процессов) – содержит модули, которые используются для моделирования; Reports (панель отчетов) – содержит сообщения, которые отображают результаты имитационного моделирования; Navigate (панель навигации) – отображает все модели и подмодели в виде иерархического списка, позволяет перейти на любую модель. Рис. 5.8. Рабочий интерфейс программы Arena В правой части рабочего интерфейса расположено окно блок-схемы модели, которое называют также рабочим полем. В нем отображается графическая модель, а также анимационные и другие элементы. Под рабочим полем находится окно свойств модулей, которое служит для настройки параметров модулей, таких как: время, издержки и др. Для создания имитационной модели необходимо выбрать с помощью мыши на панели основных процессов нужный модуль (как правило, построение модели начинают с модуля Create) и «перетащить» его на рабочее поле. Чтобы задать свойства модуля, следует дважды щелкнуть по нему и в появившемся диалоговом окне задать значения параметров. В частности, для модуля типа Create можно задать имя модуля, тип сущностей, генерируемых модулем, закон распределения, по которому будут генерироваться сущности. Таким же образом на рабочее поле помещается следующий модуль и т.д. Если некоторый модуль является выделенным, то при помещении на рабочую область нового модуля эти модули автоматически соединяются друг с другом. Однако связи между модулями можно и переопределить. После того, как имитационная модель будет создана, ее можно «проиграть». Для этого необходимо выбрать в меню Run/Go. Перед этим следует задать параметры «проигрывания», например, общее время имитации. После «проигрывания» модели автоматически генерируются отчеты. Arena позволяет формировать следующие виды отчетов [19, 27]: • по сущностям, находящимся в системе – общее время нахождения в системе, суммарное время ожидания, количество сущностей, вошедших в систему или вышедших из системы; • по очередям, образующимся в модулях процессов, – время ожидания обработки в очереди, количество сущностей, ожидающих в очереди; • по процессам – статистика для каждого повторения; • по ресурсам – статистика по затраченным ресурсам. Например, для модели, представленной на рис. 5.7 можно получить отчет по времени ожидания клиентов в очередях перед кассирами. Построив несколько моделей для некоторой системы, отражающих различные варианты выполнения бизнес-процессов, «проиграв» их и проанализировав отчеты по результатам «проигрывания» каждой из моделей, можно выбрать оптимальный вариант. Например, для системы обслуживания клиентов в банке, рассмотренной выше, можно построить другие модели, отличающиеся от модели на рис. 5.7 другим распределением операций между кассирами. «Проиграв» каждую из моделей в течение одинакового промежутка времени, можно сравнить среднее время ожидания клиентов в очередях системы. Тот вариант, в котором время ожидания минимально, можно считать наилучшим. 5.5. Интегрированная среда ARIS Интегрированная инструментальная среда ARIS (IDS Prof. Scheer) представляет собой комплекс средств анализа и моделирования деятельности предприятия, а также разработки автоматизированных информационных систем. Данный продукт занимает лидирующее положение на рынке средств моделирования и анализа деловых процессов. Четыре из пяти ведущих мировых консалтинговых фирм используют ARIS в качестве инструментария для оптимизации своей деятельности [28]. В основу системы ARIS положена методология, основанная на разработанной профессором А.-В. Шеером теории «Архитектура интегрированных информационных систем» (Architecture of Integrated Information System — ARIS). В методологии ARIS выделено четыре основных вида моделей, отражающих основные аспекты организации (рис. 5.9) [29, 30]: • организационные модели, представляющие структуру организации — иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений; • функциональные модели, описывающие функции, выполняемые в организации, а также иерархию целей, стоящих перед аппаратом управления; • информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы; • модели управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы. В рамках каждого из перечисленных типов создаются модели разных видов, отражающие соответствующие стороны исследуемой системы. Методология ARIS включает большое количество методов моделирования, в том числе известных как диаграммы Чена ERM, язык UML (Unified Modeling Language), методики ОМТ (Object Modeling Technique), BSC (Balanced Scorecard) и т.п. Последняя версия ARIS поддерживает более 80 методов моделирования. Методология ARIS дает возможность описывать достаточно разнородные подсистемы в виде взаимоувязанной и взаимосогласованной совокупности различных моделей, которые хранятся в едином репозитории. Методология ARIS не накладывает ограничений на последовательность подготовки четырех типов представления. Процесс анализа и проектирования можно начинать с любого из них, в зависимости от конкретных условий и целей, стоящих перед исполнителями. К организационным моделям относится, в частности, организационная схема (Organizational chat), пример которой приведен на рис. 5.10 (рис взят из [28]). Наиболее распространенными функциональными моделями являются: дерево функций (Function Tree) и диаграмма целей (Objective diagram). Пример дерева функций приведен на рис. 5.11 (рис взят из [28]). Среди моделей данных можно назвать модель технических терминов (Technical Term Model), расширенную модель «сущность - отношение» (Extended entity-relationship model – eERM). К моделям процессов/управления относятся: событийная цепочка процесса (Extended event driven process chain — eEPC), диаграмма цепочки процесса (Process Chain Diagram — PCD) и др. Пример модели eEPC приведен на рис. 5.12 (рис взят из [28]). Разработка моделей организации не является самоцелью. Они создаются для того, чтобы получить новую информацию о деятельности организации. Для ее получения методология ARIS предусматривает целый комплекс операций, которые могут быть проведены над моделями. Эти операции делятся на основные и вспомогательные (служебные). К основным операциям относятся [28]: • проверки корректности моделей (семантические проверки); • составление разнообразных отчетов по модели; • оптимизация моделей по различным критериям; • анализ моделей, проводимый по различным методикам, например, функционально-стоимостной анализ, стратегическое планирование; • сравнение моделей; • обмен информацией с другими программными системами; • непрерывное улучшение модели. К служебным операциям относятся: создание вариантов моделей; слияние моделей; экспорт/импорт моделей и др. Интегрированная инструментальная среда ARIS является сложной системой и состоит из комплекса взаимосвязанных и взаимодополняющих модулей, выполняющих различные функции. Основным модулем анализа и проектирования является базовый модуль ARIS Toolset, который может включать все остальные модули системы. Модуль ARIS Easy Design представляет собой упрощенное средство моделирования и анализа, имеющее ограниченные функциональные возможности по сравнению с базовым модулем. Перечислим некоторые из компонент, входящих в ARIS Easy Design: • ARIS Designer — конструктор моделей; • ARIS Explorer — проводник, обеспечивающий работу с серверами, базами данных, моделями и объектами; • ARIS Report — генератор отчетов о элементах ARIS; • ARIS Semantic Check — инструмент для выполнения семантических проверок моделей. Модуль ARIS Toolset наряду с компонентами ARIS Easy Design включает также дополнительные компоненты, среди которых можно отметить: • ARIS Analysis — инструмент для анализа моделей и их анимации; • ARIS Simulation — средство для динамического моделирования процессов; • ARIS Variants — средство для создания вариантов моделей, выполнения операций сравнения вариантов. В ARIS предусмотрены также модули, предназначенные для решения некоторых частных задач. К ним, в частности, относятся: • ARIS ABC (Activity Based Costing) — инструмент для проведения функционально-стоимостного анализа моделей; • ARIS BSC (Balanced Scorecards) — инструмент для стратегического управления. • ARIS Quality Management Scout — проводник менеджмента качества; • ARIS PPM (Process Performance Manager) — менеджер выполнения процессов. Средства ARIS могут применяться как однопользовательская среда, а также поддерживать коллективные разработки в среде «клиент-сервер». Рассмотри подробнее конструктор моделей ARIS Designer, предназначенный для создания и корректировки моделей. На рис. 5.13 ([28]) представлен общий вид рабочего интерфейса. Рис. 5.13. Рабочий интерфейс ARIS Designer Окно ARIS Designer состоит из основного окна, где происходит построение моделей, и вспомогательных окон – окна просмотра модели в уменьшенном масштабе, окна проводника, окна просмотра объекта, окна вывода системной информации для пользователя. Находясь в основном окне, можно создавать объекты и связи между ними, а также редактировать их атрибуты. Для создания нового объекта или связи следует воспользоваться кнопками специальной панели инструментов Modeling (моделирование). Конфигурация этой панели зависит от типа текущей модели. Контрольные вопросы и упражнения 1. Какие основные возможности предоставляют инструментальные средства поддержки реинжиниринга? 2. Приведите классификацию CASE-средств по уровням проектирования, поддерживаемым ими и по типам. 3. Охарактеризуйте основные группы инструментальных средств, используемых в технологии BPR, - назначение, основные функции, используемые методологии и примеры средств. 4. Каковы критерии выбора наиболее подходящего инструментального средства для конкретного проекта по реинжинирнгу? 5. Какие методологии поддерживает инструментальное средство BPwin? 6. Каковы основные функции и возможности BPwin? 7. Какие виды диаграмм, поддерживаемых CASE-средством Rational Rose, Вы знаете? 8. Как связаны между собой диаграмм различных видов, формируемые с помощью Rational Rose? 9. Каковы основные возможности средства имитационного моделирования Arena? 10. Перечислите основные элементы имитационной модели Arena. 11. Охарактеризуйте основные графические модули модели Arena. 12. Постройте имитационную модель процесса продажи продукта. 13. Какие виды отчетов позволяет формировать средство Arena? 14. К какой группе инструментальных средств относится среда ARIS? Каковы ее основные функции? 15. Охарактеризуйте основные виды моделей методологии ARIS. Заключение Реинжиниринг бизнес-процессов используется промышленными компаниями и обслуживающими фирмами, желающими добиться значительных успехов и существенно повысить конкурентоспособность, для реконструкции своих деловых процессов. Добиться впечатляющих результатов позволяют новейшие достижения в области менеджмента и информационных технологий, взятые на вооружение реинжинирингом. Основная суть состоит в том, чтобы сделать процессы более простыми и гибкими, структуры управления – менее жесткими и забюрократизированными, исполнителей и менеджеров – заинтересованными в качестве конечного результата деятельности. Это дает важнейшие преимущества в условиях жесткой конкуренции, постоянного повышения требований клиентов к товарам и услугам, быстрых технических и технологических изменений. Реинжиниринг не исчерпывается описанием принципов, на которых должны строиться реконструированные процессы и организационные структуры, он содержит рекомендации по организации работ в ходе перепроектирования бизнеса, использованию методов моделирования бизнес-процессов и инструментальных средств поддержки. Именно наличие этих рекомендаций в виде типового регламента позволяет назвать реинжиниринг бизнес-процессов технологией. Авторы данного учебного пособия постарались охватить все аспекты такой многоплановой дисциплины, как «Реинжиниринг бизнес-процессов». Желающие углубить свои познания в тех или иных разделах могут обратиться к дополнительной литературе: принципы и технология реинжиниринга описаны в [1, 2, 6, 31, 32], организационные аспекты хорошо освещены в [7, 37], описание наиболее распространенных методологий моделирования и инструментальных средств поддержки содержится в [2, 16-20, 26-30, 33-36], примеры реинжиниринга компаний, в том числе и российских приводятся в [6, 8-10]. Авторы будут признательны заинтересованным читателям за критические замечания и предложения, которые можно высылать в адрес редакции. Литература 1. Hammer M., Champy J. Reengineering the Corporation: A Manifesto for Business Revolution. – N-Y: HarperCollins, 1993. 2. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: Реинжиниринг организаций и информационные технологии, - М.: Финансы и статистика, 1997. - 336 с. 3. Основы менеджмента / под ред. А.А. Радугина. – М.: Центр, 1997. – 432 с. 4. Мильнер Б.З. Теория организаций. – М.: МНФРА-М, 1998. – 336 с. 5. Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг. // СУБД. – 1995. – №4. – С. 37-49. 6. Уткин Э.А. Бизнес-реинжиниринг. - М.: Ассоциация авторов и издателей "ТАНДЕМ". Изд-во ЭКМОС, 1998. – 224 с. 7. Кутелев П.В., Мишурова И.В. Технология реинжиниринга бизнеса: Учеб. пособие. – М.: ИКЦ «МарТ»; Ростов н/Д: издат. центр «МарТ», 2003. – 176 с. 8. Рапопорт Б.М., Скубченко А.И. Инжиниринг и моделирование бизнеса. – М.: .: Ассоциация авторов и издателей "ТАНДЕМ". Изд-во ЭКМОС, 2001. – 240 с. 9. Медынский В.Г., Ильдеменов С.В. Реинжиниринг инновационных предприятий. – М.: ЮНИТИ, 1999. – 346 с. 10. Инжиниринг информационных и деловых процессов: Сб. науч. трудов/ Моск. госуд. ун-т экономики, статистики и информатики. - М., 1997. - 138 с. 11. Davenport T.H. Business Innovation, Reengineering Work through Information Technology. – Boston: Harvard Business School Press, 1993. 12. Martin J. enterprise Engineering – The Key to Corporate Survival. – V.I-V. – UK: Savant Institute, 1994. 13. Силич М.П. Теория организации: Учебное пособие. – Томск: Томск. гос. ун-т систем управления и радиоэлектроники, 2003. – 136 с. 14. Шеннон Р. Имитационное моделирование систем - искусство и наука. – М.: Мир, 1978. 15. Перегудов Ф.И., Тарасенко Ф.П. Основы системного анализа: учеб 3-е изд. – Томск: Изд-во НТЛ, 2001. – 396 с. 16. Леоненков А.В. Самоучитель UML. – СПб.: БХВ-Петербург, 2001. – 304 с. 17. Каменнова М.С. Системный подход к проектированию сложных систем // Журнал д-ра Добба. – 1993. – №1. – С. 9-14. 18. Методология IDEF0. Стандарт. Русская версия. - М.: Метатехнология, 1993. - 107 с. 19. Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process Modeler (BPwin 4.1). – М.: ДИАЛОГ-МИФИ, 2003. – 240 с. 20. Тельнов Ю.Ф. Интеллектуальные информационные системы в экономике: учеб. пособие / Моск. гос. ун-т экономики, статистики и информатики. – М., 1998. – 174 с. 21. Меллинг В.П. Корпоративные информационные архитектуры: и все-таки они меняются // СУБД. – 1995. – №2 22. Carlzon J. Moments of Truth. – MA: Ballinger Publishing Company, 1987. 23. Willoch B.E. Business Process Engineering. Vinnende arbeidsprosesse og organisasjonsstrukturere i forandringens decennium. – Norway: Fagbogförlaget, 1994. 24. Кириллов В.П. SSADM – передовая технология разработки автоматизированных систем // Компьютеры + программы. – 1994. - №2 (10). – С. 8-16. 25. Саати Т., Кернс К. Аналитическое планирование. Организация систем: пер. с англ. – М.: Радио и связь, 1991. – 224 с. 26. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М: Финансы и статистика, 1998. 27. ARENA Users Guide. – Sewickley: System Modeling Co., 1996. 28. Каменова М.С. Моделирование бизнеса. Методология ARIS / М.С. Каменнова, А. И. Громов, М. М. Ферапонтов, А. Е. Шматалюк. — М.: Весть-МетаТехнология, 2001. 29. Шеер А.-В. Бизнес-процессы: основные понятия, теории, методы. — М.: Просветитель, 1999. – 152 с. 30. Шеер А.-В. Моделирование бизнес-процессов. — М.: Весть-МетаТехнология, 2000. 31. М.Хамер, Дж.Чампи. Реинжиниринг корпорации: Манифест революции в бизнесе. — СПб.: Изд.СПб ун-та, 1997. 32. Робсон М., Уллахх Ф. Практическое руководство по реинжинирингу бизнес-процессов. — М.: Аудит, 1997. 33. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. – М., 1993. – 240 с. 34. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение) – М.: ЛОРИ, 1996 – 242 с.. 35. Калянов Г.Н. CASE-технологии: консалтинг в автоматизации бизнес-процессов. – М.: Горячая линия - Телеком, 2000. – 320 с. 36. Язык UML. Руководство пользователя: Пер. с англ. / Г. Буч, Д. Рамбо, А. Джекобсон. – М.: ДМК, 2000. – 432 с. 37. Кутелев П.В. Организационный инжинирнг: Технологии реинжиниринга бизнеса: Учеб. Пособие для вузов. – Ростов н/Д: Феникс, 2003. – 220 с. Краткий СЛОВАРЬ Актор (actor) – субъект окружения моделируемой системы, взаимодействующий с ней. Акторы используются для моделирования элементов окружения бизнес-процессов или информационной системы. Бизнес-процесс (business process) – логическая серия взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как Продукт или Услуга. Визуализация – один из этапов технологии реинжиниринга бизнес-процессов, на котором формируется образ будущего компании и разрабатывается спецификация целей реинжиниринга. Диаграмма вариантов использования (use case diagram) – диаграмма языка UML, на которой отражается взаимодействие между прецедентами (вариантами использования), моделирующими бизнес-процессы, и акторами, моделирующими субъекты окружения бизнес-процессов. Диаграмма деятельности (activity diagram) – диаграмма языка UML, показывающая процесс выполнения операций. С ее помощью моделируется поток событий бизнес-процесса Диаграмма кооперации (collaboration diagram) – диаграмма языка UML, на которой показаны отношения между объектами. Статическая модель взаимосвязей объектов бизнес-процесса. Диаграмма последовательности (sequence diagram) – диаграмма языка UML, на которой показаны взаимодействия объектов, упорядоченные по времени. Динамическая модель взаимодействия объектов бизнес-процесса Инжиниринг (engineering) – проектирование, создание, построение, изобретательство. Информационная технология – система методов и способов сбора, накопления, хранения, поиска, передачи, обработки и выдачи информации с помощью компьютеров и компьютерных линий связи. Модель – отображение (представление) объекта, системы или понятия в некоторой форме, отличной от формы их реального существования Обратный инжиниринг – один из этапов технологии реинжиниринга бизнес-процессов, на котором анализируется состояние существующего бизнеса. Объект (object) – 1) в объектно-ориентированном программировании это тип данных, который объединяет в одну структуру совокупность атрибутов (полей данных) и методов (процедур); 2) в реинжиниринге бизнес-процесов это либо участник выполнения бизнес-процесса (активный объект), либо сущность, обрабатываемая или вырабатываемая бизнес-процессом (пассивный объект, объект-сущность). ООП (Объектно-Ориентированное Программирование) - совокупность принципов, технологии и инструментальных средств для создания программных систем, в основу которых закладывается архитектура взаимодействия объектов. Прецедент или вариант использования (use case) – законченная совокупность действий моделируемой системы, начинающаяся при получении стимула извне и заканчивающаяся предоставлением некоторого продукта или сервиса пользователю (клиенту) системы. С помощью прецедентов моделируются внутренние и внешние бизнес-процессы, а также процессы информационных систем. Процессная структура – организационная структура, ориентированная на процессы; воплощает некоторые черты матричной и сетевой структур. Прямой инжиниринг – один из этапов технологии реинжиниринга бизнес-процессов, на котором осуществляется проектирование нового бизнеса. Реинжиниринг (reengineering) – перепроектирование, перестройка, реконструкция, реорганизация Реинжиниринг бизнес-процессов (business process reengineering) – фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения резких, скачкообразных улучшений в решающих современных показателях деятельности компании, таких как стоимость, качество, сервис и темпы ABC (Activity Based Costing – функционально-стоимостной анализ, ФСА) – метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах. BPR (Business Process Reengineering) – см. реинжиниринг бизнес-процессов CASE-средства (Computer-Aided Software Engineering – компьютерная поддержка проектирования программного обеспечения) – программно-технические средства для автоматизации разработки информационных систем. CPI (Continuous Process Improvement – непрерывное усовершенствование процессов) – методология управления процессами, ставящая своей целью постоянное повышение качества продуктов и услуг за счет динамичного совершенствования организации выполнения процессов. IDEF (Integrated computer-aided manufacturing DEFinition - определение интегрированной компьютерной поддержки производства) – семейство методологий моделирования различных аспектов функционирования производственной среды. Включает методологию функциональной декомпозиции IDEF0, методологию семантического моделирования данных IDEF1X, методологию динамического моделирования IDEF2 и др. OOA/OOD (Object-Oriented Analysis/Design – объектно- ориентированный анализ/проектирование) – технология разработки программных систем, основанных на принципах объектно-ориентированного программирования. RAD-средства (Rapid Application Development – быстрая разработка приложений) – инструментальные средства «визуального» программирования TQM (Total quality management – глобальное управление качеством) – разновидность методологий управления процессами, ориентированная на совершенствование процессов на основе объективного их измерения для повышения удовлетворенности потребителя и соответствия его требованиям. UML (Unified Modeling Language– унифицированный язык моделирования) – объектно-ориентированный язык моделирования. Используется для описания, визуализации и документирования информационных систем в процессе их разработки, а также для моделирования бизнес-процессов. Приложение Методические указания для выполнения курсовой работы по Дисциплине «Реинжиниринг бизнес-процессов» Цель работы Курсовая работа по дисциплине «Реинжиниринг бизнес-процессов» имеет целью: получение навыков самостоятельного анализа и перепроектирования бизнес-процессов в соответствии с принципами реинжинринга, рассмотренными в процессе изучения дисциплины. Этапы выполнения курсовой работы соответствуют основным этапам технологии реинжиниринга. Варианты заданий Для выполнения курсовой работы студент (группа) получает от преподавателя индивидуальное задание – название бизнес-процесса, на примере которого выполняется реинжинринг. Список рекомендуемых объектов реинжинринга: 1. Ремонт квартир. 2. Ремонт автомобилей. 3. Проведение праздничных мероприятий. 4. Организация туристических поездок. 5. Пошив и ремонт верхней одежды. 6. Проведение рекламных компаний. 7. Оказание услуг по операциям с недвижимостью. 8. Гостиничное обслуживание. 9. Организация выставок и ярмарок. 10. Издание печатной продукции. 11. Производство, продажа и сопровождение программной продукции. 12. Проведение рекламных компаний. 13. Производство и продажа мебели на заказ. 14. Трудоустройство. 15. Организация обучения и консультирования. 16. Оказание жилищно-коммунальных услуг. 17. Оказание услуг по автоперевозкам. 18. Организация спортивных мероприятий. 19. Выпуск газеты. 20. Оказание медицинских услуг. 21. Оказание маркетинговых услуг. 22. Организация выборных компаний. 23. Оказание услуг брачного агентства. 24. Строительство садовых домиков. Студент может предложить собственный вариант задания. В случае, если в качестве задания выбран бизнес-процесс реальной компании, реинжиниринг целесообразно проводить группой. Размер группы зависит от сложности процесса. Содержание курсовой работы В процессе выполнения курсовой работы необходимо выполнить следующие этапы: 1. Планирование проведения реинжиниринга. В случае, если курсовая работа выполняется группой, необходимо выбрать лидера, распределить роли между участниками группы, определить способы их взаимодействия. Необходимо составить календарный график работ. График может быть представлен в виде диаграммы Ганта. 2. Понимание существующего бизнеса. Дается характеристика исследуемого бизнес -процесса: • название, цель процесса; • содержательное описание процесса, его входов и выходов; • периодичность проведения процесса (разовый процесс, периодически повторяющийся, выполняемый при определенных условиях и т.д.); • краткая характеристика компании, использующей процесс; • организационная структура компании или той части компании, которая выполняет процесс. Следует ввести метрики, по которым будет измеряться существующий бизнес-процесс, проводиться сравнение с аналогичными процессами, а также с новыми вариантами организации данного бизнес-процесса. Примеры метрик: • время обслуживания клиента; • стоимость товара (услуги); • качество продукта (услуги); • процент отказов; • уровень сервисного обслуживания. Метрики должны быть конкретными, применимыми именно для исследуемого процесса. 3. Анализ требований клиентов. Дается оценка клиентами существующего процесса по введенным метрикам. При этом могут использоваться качественные оценки – «плохо», «хорошо», «отлично» и т.д. или балльные (по 5-ти или 10-ти балльной шкале). Можно привести описание идеального (с точки зрения клиента) бизнес-процесса и идеального результата взаимодействия с бизнес – процессом. Следует сделать вывод, что не устраивает клиентов в существующем бизнесе 4. Оценка уровня компании. Проводится сравнение существующего бизнес-процесса компании с аналогичными бизнес-процессами конкурентов. По каждой метрике для каждого из сравниваемых процессов выставляется оценка (либо качественная, либо балльная). Следует сделать вывод о слабых и сильных сторонах исследуемого бизнес-процесса в сравнении с процессами конкурентов. 5. Спецификация целей. На основе результатов анализа требований клиентов и оценки уровня компании выдвигаются основные цели реинжиниринга. Формулировки целей, по возможности, должны содержать значения метрик, например: «сокращение среднего времени обработки заявки на 50%», «увеличение количества обрабатываемых запросов в 10 раз». Формируется дерево целей: для выделенных целей выявляются подцели и обобщенные сценарии. Необходимо привести краткое описание сценариев. Осуществляется оценка приоритетов целей, подцелей и сценариев. Для каждой группы целей (подцелей, сценариев) выставляются балльные оценки (числа в интервале от 0 до 1) так, чтобы их сумма равнялась единице. Чем выше балл, тем выше приоритет. Затем для каждого сценария определяется приоритет относительно глобальной цели. Для этого необходимо перемножить приоритеты данного сценария и всех подцелей, входящих в цепочку от сценария до глобальной цели. 6. Создание внешней модели существующего бизнеса. Следует выделить акторы исследуемого бизнес-процесса, составляющие его окружение. Для каждого актора перечисляются его обязательства по отношению к исследуемому процессу. Приводится схема взаимодействия бизнес-процесса с окружением в виде диаграммы вариантов использования (Use case) языка UML. Схема может содержать не только прецедент, соответствующий исследуемому бизнес-процессу, но и прецеденты, связанные с ним отношениями обобщения, включения, расширения. Следует описать связи между прецедентами и акторами. 7. Описание потока событий бизнес-процесса Создается описание прецедента в виде потока событий (шагов процесса). Описание может включать кроме основного хода событий альтернативные или дополнительные потоки событий. Поток событий следует представить в виде диаграммы деятельности (Activity Diagrams) языка UML. Необходимо структурировать описание прецедента с помощью отношений обобщения и/или отношения включения. 8. Создание объектной модели существующего бизнеса. Выделяются объекты исследуемого бизнес-процесса. Для каждого объекта необходимо указать: • тип (интерфейсный, управляющий, объект-сущность); • атрибуты (основные свойства, характеристики); • основные обязательства по отношению к прецеденту. Создается динамическая модель взаимодействия объектов в виде диаграммы последовательности (Sequence Diagram) языка UML. Последовательность взаимодействий должна соответствовать шагам процесса. Если процесс существует в нескольких версиях, возможно, потребуется создание нескольких диаграмм для различных версий. На основе динамической модели создается статическая модель в виде диаграммы кооперации (Collaboration Diagram) языка UML. В дополнение к взаимодействиям между активными объектами на ней следует показать связи с объектами-сущностями, используемыми в процессе выполнения процесса. 9. Измерение существующего бизнес-процесса Для измерения стоимостных характеристик необходимо провести функционально-стоимостной анализ. Создается модель функциональной декомпозиции по методологии IDEF0. Выделяются центры стоимости функций. Определяются стоимости функциональных блоков нижнего уровня. Стоимости родительских блоков подсчитываются через стоимости дочерних блоков. Для измерения процесса по метрикам времени можно использовать диаграммы Ганта или имитационные модели. По метрикам качества процессы оцениваются в виде качественных или балльных оценок. 10. Оценка шагов существующего бизнес- процесса. Следует оценить каждый шаг исследуемого бизнес-процесса как УЦ-действие (увеличивающее потребительскую ценность продукта) или НУЦ-действие (не увеличивающее ценность продукта) и определить возможность удаления шага. Кроме того, на основе результатов функционально-стоимостного анализа необходимо дать качественные оценки стоимости (например, высокая, средняя, низкая) для каждого шага процесса. Результат нужно представить в виде таблицы (см. табл.П.1). Таблица П.1 Оценка шагов бизнес-процесса «Продажа продукта» Шаги бизнес-процесса Признак УЦ- или НУЦ-действия Возможность удаления Стоимость 1. Прием заказа УЦ нет Средняя 11. Идентификация проблем. На основе результатов измерения существующего бизнеса, оценки шагов процесса, а также результатов анализа требований клиентов и оценки уровня следует составить список проблем. 12. Выработка новаторских идей, разработка вариантов. Необходимо проанализировать возможность применения эвристических правил реконструкции бизнеса. Для каждого из девяти правил следует указать, можно ли его применить, и если да, то каким образом оно может быть использовано. При этом нужно учитывать возможность использования новых информационных технологий. Например, Вы решаете, что принцип горизонтального сжатия можно применить к исследуемому процессу следующим образом. Определенные шаги процесса можно объединить, поручив их выполнение одному исполнителю, за счет того, что он в своей работе будет использовать централизованную базу данных или экспертную систему. Необходимо проанализировать результаты оценки шагов существующего бизнес-процесса (таблица П1) для того, чтобы решить, можно ли удалить некоторые шаги (НУЦ-действия) или уменьшить стоимость некоторых шагов (например, за счет автоматизации). Оцениваются также роли субъектов окружения (акторов) и исследуется, может ли изменение их роли помочь в решении проблем существующего бизнеса. Можно свести все планируемые изменения в единый список, расположив их в порядке убывания важности Основываясь на выработанных идеях, следует конкретизировать предложенные на этапе спецификации целей (этап 5) обобщенные сценарии. Следует выбрать один или два наиболее перспективных вариантов нового бизнес-процесса и составить для них подробные сценарии. На данном этапе составляется содержательное описание сценариев. 13. Построение внешней модели нового бизнеса Этот этап выполняется аналогично этапу 6, однако в модели должны отразиться планируемые изменения, предложенные на предыдущем этапе. В случае, если имеется несколько вариантов нового бизнеса, для каждого из вариантов создается своя модель. Выделяются акторы нового бизнес-процесса, Для каждого актора перечисляются его обязательства по отношению к процессу (в случае, если они меняются по сравнению с моделью существующего процесса). Приводится схема взаимодействия бизнес-процесса с окружением в виде диаграммы вариантов использования (Use case) языка UML.. 14. Описание потока событий нового бизнес-процесса. Выполнение данного этапа аналогично выполнению этапа 7. Создается описание потока событий нового бизнеса в виде диаграммы деятельности (Activity Diagrams) языка UML. При необходимости описание может быть структурировано с помощью отношений обобщения и/или отношения включения. В случае, если имеется несколько вариантов нового бизнеса, для каждого из вариантов создается свое описание потока событий. 15. Построение объектной модели нового бизнеса. Этап выполняется аналогично этапу 8, однако в модели должны отразиться планируемые изменения (например, некоторые из объектов существующего бизнеса статут лишними, появится новый объект – информационная система, изменится структура взаимодействия между объектами и т.д.). Необходимо выделить объекты нового бизнес-процесса и составить новое описание объектов (в случае, если их роль меняется по сравнению с ролью в существующем процессе). Создается динамическая модель взаимодействия объектов в виде диаграммы последовательности (Sequence Diagram) языка UML. На основе динамической модели создается статическая модель в виде диаграммы кооперации (Collaboration Diagram) языка UML. В случае, если имеется несколько вариантов нового бизнеса, для каждого из вариантов создается своя модель. 16. Измерение нового бизнес-процесса Этот этап выполняется аналогично этапу 9. Для измерения стоимостных характеристик проводится функционально-стоимостной анализ. Измерение по метрикам времени может проводиться с использованием диаграмм Ганта или имитационных моделей. По метрикам качества проводится экспертное оценивание. В случае, если имеется несколько вариантов нового бизнеса, измерение осуществляется для каждого из вариантов. 17. Оценка нового бизнеса. Необходимо сравнить значения метрик для существующего бизнеса, для каждого из вариантов нового бизнеса и для целей реинжиниринга. Значения метрик следует представить в виде таблицы (табл. П.2). Таблица П.2 Значения метрик бизнес-процесса Метрика Существующий бизнес Цель реинжиниринга Вариант 1 нового бизнеса Вариант 2 нового бизнеса Среднее время обработки заявки 140 час. 50-70 час. 56 час. 65 час. В случае, если имеется несколько вариантов нового бизнеса и ни один из вариантов не является наилучшим по всем метрикам, для выбора наилучшего варианта необходимо использовать метод многокритериального выбора. Следует определить коэффициенты важности метрик, пронормировать значения метрик для каждого из вариантов (например, определить относительные доли улучшения значений метрик по отношению к значениям для существующего бизнеса) и найти интегральные оценки вариантов методом взвешенной суммы. Необходимо сделать вывод, достигаются ли цели реинжиниринга. Если нет, то в чем причина. 18. Формирование новой организационной структуры На основе объектной модели нового бизнеса необходимо определить состав команды, выполняющей один экземпляр бизнес-процесса. Активным объектам модели следует сопоставить реальных исполнителей, указав, к каким из существующих организационных подразделений они принадлежат. При этом одному объекту модели может соответствовать несколько реальных исполнителей или, наоборот, один исполнитель может соответствовать нескольким объектам. Команда может состоять и из одного человека. Следует также определить, сколько команд процессов нужно создать. Если процесс может иметь несколько одновременно выполняющихся экземпляров, каждому экземпляру может соответствовать своя команда. Нужно указать, являются ли создаваемые команды временными или постоянными. Затем уточняется состав каждой из команд с учетом того, что один и тот же реальный исполнитель может входить в несколько команд. Необходимо определить, следует ли для каждой команды назначать лидера или один владелец процесса будет руководить всеми командами. Нужно также решить, следует ли вводить новые должности владельца процесса и лидеров процессов или существующие сотрудники компании будут выполнять их обязанности. Формируется новая структура подчиненности. Структуру следует представить в виде схемы, на которой отражаются связи между руководством компании, владельцами ресурсов, владельцами процессов и операторами процесса. Если организационная структура слишком большая, можно представить на схеме только ту часть структуры, которая реализует реконструированный бизнес-процесс. В заключение следует описать обязанности владельцев процессов, владельцев ресурсов и операторов процесса и, возможно, предложить систему мотивации, в частности, критерии оценки труда операторов процесса. 19. Определение функциональных требований к информационной системе Сначала необходимо выделить акторов (пользователей) информационной системы и обязательства акторов, выполняемые с помощью ИС. Для этого осуществляется анализ объектной модели нового бизнеса (соответствующей выбранному варианту бизнес-процесса) и каждому из объектов или акторов бизнеса, использующему информационную систему, сопоставляется актор модели ИС. Проверяются все обязательства выделенных акторов, выполняемые ими в новом бизнес-процессе, и выписываются те из них, которые предполагают взаимодействие с ИС. Проанализировав все выписанные обязательства, следует определить прецеденты информационной системы, с помощью которых они будут реализованы. Взаимодействие выделенных прецедентов ИС с акторами необходимо представить в виде диаграммы вариантов использования языка UML. Затем составляется высокоуровневое описание прецедентов, отражающее функции ИС. Описание должно содержать не только внешние функции по взаимодействию с пользователями, но и внутренние функции системы 20. Описание потока событий прецедентов информационной системы. Создается описание потока событий выделенных прецедентов в виде в виде диаграммы деятельности языка UML. В диаграмме целесообразно использовать две дорожки, соответствующие действиям пользователя и системы. Диаграмма кроме основного потока событий может содержать дополнительные и альтернативные потоки, связанные, например, с обработкой ошибок ввода и др. Необходимо также описать интерфейсы пользователей системы, в частности, вид основных окон. 21. Формирование объектной модели информационной системы Выделяются и описываются объекты, участвующие в выполнении прецедентов ИС. Для каждого объекта необходимо указать: • тип (активный, интерфейсный, объект-сущность); • атрибуты (состав полей); • методы (процедуры). Следует описать взаимодействие объектов (включая взаимодействие с окружением системы, в частности, с пользователями) в виде диаграммы последовательности или диаграммы кооперации. Требования к оформлению отчетов По результатам курсовой работы оформляется отчет. Оформление отчета должно соответствовать требованиям стандарта к оформлению курсовых работ. Рекомендуется следующее содержание отчета: • титульный лист, • содержание, • введение, • основная часть, • заключение, • список использованных источников. Введение должно содержать цель работы, ее значение. Основная часть отчета должна отражать результаты выполнения всех этапов, составляющих содержание курсовой работы и описанных выше. Заключение должно содержать краткие выводы по результатам выполненной работы. Список использованных источников оформляется согласно стандарту.