Реинжениринг бизнес-процессов Схема лекции 1.1. Функциональное управление Большинство организаций сегодня построены по функциям и уровням иерархии, и большинство людей воспитывались с убеждением , что это не только самый естественный и эффективный способ организации, но и вообще единственный способ организации. Так было еще до того, как структуру организации стали изучать с помощью научных методов в конце 19 века. Научный подход к управлению (Scientific Management), разработанный Фредериком Тейлором, является, возможно, самым лучшим выражением этих идей. Он утверждал, что работа может быть выполнена наиболее производительно, если разбить ее на простые элементы и если люди, особенно рабочие, распределяются управляющими и специализируются на конкретной простой части работы. Он также верил в важную роль управления.”Только через более полную стандартизацию методов, ускоренное внедрение лучших достижений и условий труда, а также усиление кооперации можно обеспечить более быстрое выполнение работы. И обязанность по соблюдению стандартов и увеличению кооперации лежит только на руководителях». Естественным следствием этих взглядов стало распространение функционально-ориентированных организаций. 1.2. Организация Организация - группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений (ИСО 9000:2000) Организация - систематизированное, сознательное объединение действий людей, преследующих достижение определенных целей посредством выполнения определенных действий. Организация - социальная технико-экономическая система 1.3. Функционально-ориентированная организация Особенности: 1. Строгая вертикальная иерархия управления 2. Жесткое разделение труда, сгруппированное в соответствии со спецификой выполняемых действий 3. Управление, ориентированное на выполнение однородных действий Функционально-ориентированная организация - это организация, структура которой неизменна, имеет вертикальную топологию, построенную в соответствии с выполняемыми функциями, и строгую иерархическую подчиненность «сверху-вниз» Чем характерна функциональная структура? 1. Невозможность быстрой реакции на изменения в силу самой природы вертикальной иерархии. 2. Буфер на пути инноваций - защита от изменений, которые могут привести к неоправданному риску. 3. Нет ориентации на клиента, главный потребитель - вышестоящий начальник. Это означает, что каждый сознательно или подсознательно старается удовлетворить начальника, а не коллегу из соседнего подразделения, а тем более клиента. 4. Непроизвольная разрушительная конкуренция между подразделениями, принадлежащими к различным функциональным структурам. 5. Нет заинтересованности работающих в конечном результате - системы их оценки оторваны от результативности работы. Поскольку системы оценки их деятельности оторваны от результативности работы предприятия в целом. Их видение происходящего часто не выходит за рамки подразделения. 6. Рост накладных расходов - сначала процесс разбивается на множество операций, а затем «склеивается» через управленческий аппарат («отрицательная экономия на масштабе» -предприятия больше платят за «клей» чем за работу). 7. Каждое подразделение - обособленный островок методов управления и автоматизации. Отсюда: время взаимодействия между подразделениями делится так: 20% время работы, 80% передача результатов следующему исполнителю. 8. Иерархическая функциональная структура имеет еще один порок - это фундаментальный закон искажения информации при ее передаче. Управляющая информация передается с помощью естественного языка, а он обладает информационной избыточностью. Русский имеет 32% информационной избыточностью. А информационная избыточность является источником искажения сути сообщения. То есть при передаче информации через 4 уровня управления мы имеет почти около 100% искажения исходного сообщения. 1.4. Эволюция рынка В 50-е-60-е годы ХХ века основой бизнеса являлось соотношение Затраты производства + Желаемая прибыль = Цена Т .е существовал РЫНОК ПРОИЗВОДИТЕЛЯ. С 70-х годов ХХ века условия начали изменяться, и к 90-м годам формула успешного бизнеса трансформировалась в другую: Цена -Затраты на производство =Прибыль Рынок производителя превратился в РЫНОК ПОТРЕБИТЕЛЯ. В этих условиях успех производителя зависит от скорости его реакции на запросы потребителя, явные и предполагаемые. В ответ на изменение рынка стали появляться различные системы менеджмента. 1.5. Начало 80-х годов ХХ века .Что изменилось ? Рынки наполнились. Принцип «3С» - customers, competition, changes Изменился статус «продавец-покупатель» решение принимает клиент. Не работает принцип «они купят все, что мы произведем» Компания должна быть клиентно-ориентированной Использование методологии CRM - Customer Relationship Management, управление взаимоотношениями с клиентами Жесткая и многообразная конкуренция. Для выживания на рынке необходимо иметь: наименьшую цену, наивысшее качество, лучшее обслуживание. Нормальное состояние современной компании - постоянные изменения Глобализация экономики, повышение мобильности бизнеса технологический прогресс , сокращение жизненного цикла продукта /услуги и как следствие время разработки нового и выхода с ним на рынок 1.6. Процессный подход Реальная деятельность не осуществляется вдоль линейно-функциональной иерархии, так как здесь имеют место только разрешения и приказы. Она пронизывает предприятие в виде набора бизнес-процессов, которыми в большинстве никем не управляются и никто за них не отвечает, потому что они не описаны и не документированы. В производстве люди мыслили в терминах «производственный процесс» в течение многих десятилетий. Теория бизнес-процессов появилась менее 20 лет назад и сначала была встречена в основном с равнодушием. Основная часть руководителей предприятий часто не ориентирована на процесс - они сосредоточены на задачах, на отдельных операциях, людях, структурах и т.д. Интерес к бизнес-процессам был существенно активизирован массовым внедрением идей менеджмента качества. Процесс - это совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы (ИСО 9000). Процессно-ориентированная организация - это организация, в которой деятельностью и ресурсами управляют как процессом. Процессный подход позволяет: Перейти от «точечного» текстового описания деятельности (Положения о подразделениях и Должностные инструкции) к полному формализованному графическому описанию деятельности, интегрирующим стрежнем которого является модельное представление бизнес -процессов. Выделить и использовать процессы в качестве объектов управления (раньше управляли функциями ,выполняемыми тем или иным подразделением) Сменить ориентацию вектора управления компании от «вертикальной» («на начальника») к «горизонтальной» («на Заказчика»). Заказчик может быть как внешним, так и внутренним. Независимо от этого, именно он оценивает результаты выполнения процессов, А не начальник, стоящий выше по иерархии. Описание деятельности организации (в том числе и процессов), сделанное с достаточной степенью полноты, исключительно трудоемко. Поэтому описание следует вести поочередно, начиная с критически важных для компании предметных областей, к которым относятся организационная структура, процессы и т .д. При моделировании за «деревьями» процессов важно видеть «лес» всей деятельности реализуемой на данном предприятии (систему процессов). Идея представления организации в виде набора бизнес-процессов, а управление ее деятельностью - как управление бизнес-процессами стала распространяться в конце 80-х годов. Лучшие компании на практике доказали надежность, эффективность, экономичность перехода на клиентно-ориентированное производство и процессноориентированную структуру управления производством. Выделение бизнес-процессов, их анализ и последующее совершенствование колоссальный резерв для повышения конкурентноспособности компании и эффективности ее работы. 1.7. Функциональный и процессный подходы Противопоставление процессного и функционального подхода принципиально неверно. Функции, так же, как и процессы, являются равнозначными понятиями управленческой деятельности, и не могут существовать в отрыве друг от друга. При этом результатом и функционального, и процессного подходов является проектирование одновременно организационной структуры (т .е .функциональных областей ) и порядка взаимодействия в ее рамках (т .е .процессов). Разница только в исходных точках проектирования: распределять ли функциональные обязанности на основе процессов или проектировать процессы взаимодействия между функциональными областями. У этих двух подходов есть существенное сходство в базовых посылках :и то и другой подход постулируют изначальный набор типовых процессов /функций, который в дальнейшем детализируется и привязывается к конкретному предприятию Функциональный подход отвечает на вопрос «Что делать ?», процессный «Как делать?». Противоречий между двумя подходами не существует - они не только дополняют друг друга, но и в известной степени должны применяться параллельно. 2.1. Цикл PDCA Цикл Шухарта-Деминга (Цикл PDCA) – известная модель непрерывного улучшения процессов, получившая название цикла Шухарта-Деминга или цикла PDCA - планируй (Plan), делай (Do), проверяй (Check), воздействуй (Act), при ее применении в самых различных областях деятельности позволяет эффективно управлять этой деятельностью на системной основе. Планирование - идентификация и анализ проблемы; оценка возможностей и планирование необходимых изменений. Выполнение - поиск решения проблемы и осуществление запланированных мероприятий. Проверка - оценка результатов и выводы в соответствии с поставленной задачей. Действия - принятие решения на основе полученных выводов; если изменение не решает поставленную задачу следует повторить цикл, внеся коррективы в план. У. Шухарт впервые описал концепцию PDCA в 1939 г. в своей книге "Статистические методы с точки зрения управления качеством". Э. Деминг пропагандировал использование цикла PDCA в качестве основного способа достижения непрерывного улучшения процессов. Он также ввел модификацию цикла PDCA - цикл PDSA ("study" - изучать). В 1950 г. Э. Деминг вдохновил японцев на использование цикла PDCA. 2.3. Бизнес-процесс Бизнес-процесс – это: цепь логически связанных, повторяющихся действий, в результате которых используются ресурсы предприятия для переработки объекта (физически или виртуально) с целью достижения определенных измеримых результатов или продукции для удовлетворения внутренних или внешних потребителей. “Ericsson Quality Institute. Business Process Management. Ericsson, Gothenburg, Sweden, 1993” Любой бизнес-процесс имеет потребителя, внутреннего или внешнего. Опираясь на определение бизнес-процесса, можно все действия внутри организации (компании) рассматривать либо как бизнес-процесс, либо как его часть. 2.4. Концепция BPM (Business Process Management) Предпосылки (1990 гг.): 1. Большое внимание вопросам реинжиниринга бизнес-процессов и совершенствованию деятельности организации за счет улучшения бизнеспроцессов. 2. Широкое распространение инструментов для моделирования бизнес-процессов. 3. Распространение технологий workflow, ориентированных на автоматизацию обработки документов или выполнения заданий. Недостатки прежних подходов к управлению бизнес-процессами: 1. Методологические и технологические разрывы между моделированием и автоматизацией бизнес-процессов не позволяли оперативно реагировать на изменяющиеся потребности бизнеса, особенно при использовании в организациях различных автоматизированных информационных систем. Новый подход к управлению бизнес-процессами (BPM), сформулированный международной организацией BPMI (Business Process Management Initiative): 1. Соединение двух направлений — моделирования процессов с их автоматизацией, целостный подход к повышению эффективности деятельности организации, называемыйBusiness Process Management (BPM). Русскоязычный перевод этого понятия — Управление Бизнес-Процессами (УБП) или Процессное управление . Подход BPM предусматривает: 1. Изучение, проектирование, внедрение, выполнение, поддержка, оптимизация и анализ распределенных процессов, выходящих за границы отдельных подразделений и организаций, и охватывающих приложения, работающие на различных технологических платформах. 2. Использование нескольких компонентных технологий для автоматизированной поддержки распределенных процессов, а также комбинации различных методов интеграции приложений. 2.5. ЖЦ управления процессами в BPM 1) Стратегия Миссия. Стратегия. KPIs разработанные с помощью Balansed Scorecard 2) Проектирование / Описание Документирование и анализ процессов и его окружения. Проектирование недостающих процессов Назначение владельца процесса Определение метрик процесса Регламенты и роли в рамках процесса 3) Внедрение Внедрение методики управления процессами Изменения в системе управления Выбор ИТ-решений и подготовка к внедрению ИТ-систем Внедрение ИТ-систем Управление изменениями, рисками, знаниями в рамках процесса 4) Контроллинг Измерение параметров процесса (время, стоимость, качество) Идентификация слабых мест Контроль основных метрик (KPI) Контроль его адекватности после внедрения 2.6. Процессное управление организацией Процесс – фундаментальное свойство организации. Процессный подход – это систематическая идентификация и менеджмент применяемых организацией процессов, и особенно взаимодействия таких процессов (ИСО 9000) Процессное управление – планомерная деятельность по формированию целенаправленного поведения организации посредством выделения, описания и менеджмента системы взаимосвязанных и взаимодополняющих процессов организации и их ресурсного окружения. Управлять организацией можно, только управляя её процессами. Процессное управление – инструмент корпоративного управления, обеспечивающий реализацию стратегии. Управление может быть эффективно лишь тогда, когда оно сознательно нацелено на управление процессами, являющихся сутью деятельности системы при наличии цели. 2.7. Понятие системы 1. Формальное определение (ИСО 9000): Система – это совокупность взаимосвязанных и взаимодействующих элементов . 2. Определение, данное Расселом Л . Акоффом : Система – это состоящее из двух элементов или более множество, которое удовлетворяет следующим трем условиям: 1. Поведение каждого элемента воздействует на поведение целого. Пример : организм человека. Каждая его часть – сердце, легкие, желудок и т.д. воздействует на функционирование организма в целом. 2. Поведение элементов и их воздействия на целое взаимозависимы. Данное условие означает, 3. что поведение каждого элемента и его воздействие на целое зависит от того, как ведет себя по крайней мере еще один другой элемент. Ни один элемент не имеет самостоятельного воздействия на систему в целом . 4. Какие бы подгруппы элементов ни образовались, каждый элемент воздействует на оведение целого ,и ни один из них не воздействует на них самостоятельно. Иными словами, элементы системы соединены таким образом, что образование ими независимых подгрупп невозможно. 2.8. Свойства системы 1. Каждая часть системы обладает свойствами которые она теряет в случае отделения от системы 2. Каждая система обладает определенными (существенными ) свойствами ,которыми не обладает ни одна из ее частей Существенные свойства системы в целом проистекают из взаимодействия ее частей, а не от их действий самих по себе. Поэтому, если систему разобрать на части, она утратит свои существенные свойства. Следовательно : 3. Система – это целое , которое невозможно понять с помощью анализа ее частей. 2.9. Понятие системного подхода 1.Механистический подход к изучению систем: 1. Разложение на части того, что необходимо объяснить 2. Объяснение поведения или свойств отдельных частей 3. Составление из полученных объяснений целостной трактовки Первые два этапа – анализ системы, третий этап – синтез системы. При механистическом подходе анализ предшествует синтезу 2. Системный подход 1. Идентификация целого (системы), частью которого является предмет, который необходимо объяснить 2. Объяснение поведения или свойств целого 3. Объяснение поведения или свойств предмета по его роли (ролям ) или функции (функциям) в содержащем его целом Первые два этапа – синтез системы, третий этап – анализ системы. Системный подход переворачивает «с ног на голову» трехэтапный порядок механистического подхода: синтез предшествует анализу. 3. Анализ фокусируется на структуре системы, он дает знание (описание) системы 4. Синтез фокусируется на функционировании системы, он дает понимание (объяснение) системы Оригинальное предложение Богданова заключается в обьединении всех человеческих, биологических и физических наук, рассматривая их как системы взаимоотношений, и поиска организационных принципов, лежащих в основе всех типов систем . 1. Организационная система (или комплекс) есть процесс или поток процессов производства составляющих, связанных циклами развития и деградации 2. Четкое различие между организацией и структурой: организация – сеть процессов производства ее составляющих структура – особый пространственно-временной образ (паттерн) произведенных составляющих 3. Организационная система рассматривается не как конечное состояние, нечто застывшее, а как процесс постоянных преобразований, связанных с непрерывной сменой состояний равновесия 4. Сохранность организационной системы обеспечивается только активным использованием внешней среды 2.11. Свойства организации как системы 1. Целенаправленность – определяет поведение системы 2. Сложность – зависит от множества входящих в нее компонентов 3. Делимость – система состоит из ряда подсистем , выделенных по определенному признаку 4. Целостность – функционирование множества элементов системы подчинено единой цели 5. Многообразие элементов и различие их природы 6. Структурированность – определяется наличием установленных связей и отношений между элементами внутри системы, распределении элементов системы по уровням иерархии 2.12. Системный подход к организации 1. Системный подход к организации – выявление, понимание и административное управление системой взаимосвязанных процессов с целью достижения заданной стратегической цели 2. Системный подход реализует представление организации в виде иерархической системы взаимосвязанных моделей, позволяющих изучать его целостные свойства, структуру . 3. Системный подход к организации позволяет : 1. Определить систему путем выявления или разработки процессов, влияющих на достижение заданной стратегической цели 2. Структурировать систему так, чтобы достичь заданную стратегическую цель наиболее эффективным способом 3. Обеспечить понимание взаимосвязей между процессами системы 4. Проводить непрерывное совершенствование системы посредством измерения и оценки 5. Обеспечить лучшее понимание распределения ролей и ответственности при достижении общих стратегических целей, уменьшая тем самым межфункциональные барьеры и улучшая коллективную работу 2.14. Системный анализ 1. Системный анализ - методология описания сложных систем 2. Основные этапы системного анализа 1. Формулировка основных целей и задач исследования 2. Определение границ системы, отделение ее от внешней среды 3. Составление списка элементов системы (подсистем, факторов, переменных и т .д .) 4. Выявление сути целостности системы 5. Анализ взаимосвязей элементов системы 6. Построение структуры системы 7. Установление функций системы и ее подсистем 8. Согласование целей системы и ее подсистем 9. Уточнение границ системы и каждой подсистемы 10.Анализ явлений эмерджентности * (*Качество , свойства системы ,которые не присущи ее элементам в отдельности , авозникают благодаря объединению этих элементов в единую , целостную систему) 11.Создание системной модели 3. Ключевую роль в системном анализе играет понятие "структура ", которое связано с упорядоченностью отношений, связывающих элементы системы 2.15. Идеи, лежащие в основе структурных методов анализа систем 1. Структурные методы (структурный анализ) являются строгой дисциплиной системного анализа 2. Основные идеи структурного анализа: 1. Разбиение сложной системы на части 2. Каждая часть должна реализовывать единственную функцию системы 3. Функция каждой части должна быть легко понимаема 4. Связи между частями должны вводится только при наличии соответствующих связей между функциями 5. Связи должны быть простыми, насколько это возможно, для обеспечения независимости между отдельными частями 6. Иерархическое представление сложной системы 7. Для понимания сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур 8. Графическое представление сложных систем 9. Графическое представление существенно упрощает понимание сложных систем 2.16. Структура системы-организации Структурный анализ – метод исследования систем, который начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Структурный анализ позволяет описать иерархию подсистем, описывающих различные стороны деятельности организации. Он работает как набор географических карт, отличающихся своим масштабом Организация Подсистемы организации организационная производственная функциональная информационная Структура организации – устойчивая картина взаимных отношений подсистем организации Подсистема организации – ее часть, выделенная по определенному признаку, обладающая некоторой самостоятельностью и допускающая разложение на элементы в рамках данного рассмотрения Задачи структурного анализа организации 1. выявление структуры как относительно устойчивой совокупности отношений 2. частичное отвлечение от развития объектов 3. графическое модельное представление объектов которое начинается с общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней 2.17. Структурные элементы и связи Модель – это совокупность графических объектов , их свойств , атрибутов и отношений между ними , которая адекватно описывает моделируемую предметную область Структурный объект – объект , выполняющий одну из элементарных функций , связанных с моделируемым предметом, процессом или явлением Структурный объект – неделимая наименьшая функциональная часть системы (на данном уровне рассмотрения) Связь – вид отношений между объектами, который проявляется как некоторое взаимодействие 3.1. Различные определения бизнес-процесса В настоящее время существует множество определений или интерпретаций понятия бизнес-процесс (БП). В зависимости от задач внимание авторов акцентируется лишь на одном или нескольких его ключевых свойствах. Например : Бизнес-процесс как целевая организационная деятельность (действия ) Поставка продукта (услуги /товара) внешнему потребителю Формирование прибавочной и /или потребительной стоимости и т .д . «Ключевые» свойства, используемые для определения отличий понятия «бизнеспроцесс» от понятия «процесс» зависят от решаемых задач и после их детального изучения оказываются необоснованными. Примеры определений бизнес-процесса Бизнес-процесс как деятельность: работа «от начала до конца» поток работы, проходящий от одного специалиста к другому или от одного отдела к другому (в зависимости от уровня рассмотрения ) взаимонезависимый компонент производственной системы, преобразующие вход в один или несколько выходов в соответствии с предварительно установленными правилами одна или более связанных между собой процедур или операций (функций), которые совместно реализуют некую бизнес-задачу или политическую цель предприятия, как правило в рамках организационной структуры, описывающей функциональные роли и отношения Бизнес-процесс как создание продукта /услуги: множество внутренних шагов деятельности, начинающихся с одного и более входов и заканчивающихся созданием продукции, необходимой клиенту связанный набор повторяемых действий (функций), которые преобразуют исходный материал и /или информацию в конечный продукт (услугу) в соответствии с определенными критериями Бизнес-процесс как формирование прибавочной и /или потребительной стоимости: совокупность различных видов деятельности, в рамках которой “на входе” используется один или более видов ресурсов, и в результате этой деятельности “на выходе” реализуется товар, представляющий ценность для потребителя 3.2. Задание процесса Название (определение) процесса Реализуемая функция или их последовательность Участники процесса Ответственное лицо - владелец процесса Входные и выходные потоки, а также их поставщики (или потребители) Требуемые ресурсы (производственные, технические, материальные, информационные) Определяющая цель (цели) процесса Метрики процесса, точки и процедуры мониторинга процесса Возможные риски и влияния процесса на субъектов процесса Документ - описание процесса Понятие «бизнес-процесс» относим ко всем процессам организации. Использование понятия «бизнес-процесс» вызвано сложившимися традициями и является разумным с учетом того, что понятие процесс используется в других областях знания (математика , физика и т . д .) совсем в другом контексте. Об использовании этих понятий при выполнении конкретных проектов приходится договариваться Иерархическая структура бизнес-процесса: (1) Бизнес-процесс, подпроцесс (субпроцесс ), процедура, функция, транзакция (действие) (Чеботарев В.Г) (2) Бизнес-процесс, операция, действие, функция (Миндалёв И.В) 3.4. Цели процесса Каждый процесс должен иметь цель или систему целей, на достижение которых он направлен. Цели определяются исходя из требований потребителей результатов (выходных потоков) процесса. Цели могут меняться с течением времени. Например, на начальном этапе жизненного цикла процесса для потребителей важно качество выходной продукции. По прошествии времени, когда процесс выстроен и оптимизирован так, что качество продукции гарантируется, целью процесса может стать получение выходной продукции за заданный интервал времени. Желательно формулировать одну, наиболее важную цель процесса, поскольку на ее основе формируется метрика процесса. Использование нескольких целей потребует определения ее интегральной оценки путем введения весовых коэффициентов, определение которых в большинстве случаев весьма затруднительно. Единая интегральная оценка необходима для определения одной метрики процесса. 3.5. Организация как совокупность процессов Миссия Стратегическая цель 1 /выпуск продукта А - Бизнес -процесс 1 Стратегическая цель 2 /предоставление услуги В - Бизнес -процесс 2 Стратегическая цель 3 /внедрение системы качества - Бизнес -процесс 3 3.6. Документирование и описание процессов Документирование - первый шаг к совершенствованию процессов Цель документирования процессов - описание их текущего состояния . При документировании процессов необходимо стремиться к описанию реального, а не идеального состояния Описание процессов необходимо при документировании, инжиниринге, реинжиниринге и совершенствовании процессов Цели описания процессов Разработка системы управления бизнес-процессами Внедрение стандартных методов представления и описания бизнес-процессов Снижение стоимости и повышение качества выполнения бизнес-процессов Стимулирование обсуждения регламентов взаимодействия между подразделениями Создание упорядоченной структуры взаимосвязанных бизнес-процессов системы менеджмента качества, однозначно понимаемой всеми сотрудниками организации Получение возможности повторного использования отдельных процессов в других процессах (использование модульного принципа) Поддержка управления работающими бизнес-процессами Создание сети рабочих групп, призванных заниматься организацией бизнеспроцессов в этих подразделениях 3.7. Идентификация процессов организации Два подхода: 1. Составление списка всех процессов, имеющих ключевое значение для организации 2. Систематический подход - последовательное выделение следующих элементов : стратегии организации, которая определяется и формируется : заинтересованными сторонами, которые : имеют определенные ожидания в отношении продукции организации, благодаря: бизнес-процессам, с помощью которых производят эту продукцию или услуги, а также обеспечивают поддержку и возможность их производства 3.8. Варианты описания процессов текстовый табличный графический 3.9. Классификация процессов Основные процессы: Добавляют качество Кросс-функциональны в рамках предприятия Взаимодействуют как с клиентами, так и с партнерами Через них проходит основной продукт , добавляют продукту ценность , результат получает потребитель В организации выделяются не более 20 основных бизнес-процессов Процессы управления Управление организацией как единой системой: Целеполагание, планирование, контроль достижения целей Анализ и выработка корректирующих воздействий Координация действий отдельных элементов Процессы развития: Определяют тенденции и направления развития основных процессов в зависимости от анализа и прогнозируемых направлений развития организации Вспомогательные процессы Создают инфраструктуру организации не касаются основного продукта, добавляют продукту стоимость, результат получает основной процесс. 3.10. Владелец процесса Владелец процесса - лицо (бизнес-роль), несущее полную ответственность за процесс и наделенное полномочиями в отношении этого процесса. Владелец не касается функций, выполняемых в рамках процесса отдельными исполнителями, ему важна успешная реализация всего процесса. Владелец процесса обеспечивает взаимодействие с поставщиками входных потоков процесса и с потребителями его результатов Критерии выбора владельца процесса: Детальное знание бизнес-процесса, компетентность и профессиональные знания Возможность влиять на людей и способствовать изменениям. Надо помнить, что любые изменения будут внедряться извне функциональнолинейной иерархии, поэтому существует большая вероятность конфликтов Коммуникативные способности Понимание важности порученного дела и надлежащая мотивация 3.11. Входы и выходы процесса Первичный выход, на котором формируется результата процесса (ради которого он существует), передаваемый первичным клиентам, например, заказанное оборудование. Первичный вход, на который поступают входные потоки от первичных поставщиков, например, заявка на поставку оборудования. Вторичные выходы, через которые вторичные продукты (потоки), не являющиеся основной целью процесса, передаются в другие процессы, например, счет на оплату заказанного оборудования передается в процесс «Оплата счетов» Вторичные входы, на которые поступают ресурсы, необходимые для выполнения процесса, например, прайс-листы от потенциальных поставщиков требуемого оборудования 3.12. Поставщики и потребители потоков процесса Косвенный потребитель - не получающий непосредственно первичные выходные потоки, но являющиеся следующими в цепочке Внешний потребитель - находящийся вне организации, но использующий выходные потоки процесса, например, розничные продавцы Потребитель - конечный потребитель выходных потоков процесса Не всегда отдельные категории потребителей присутствуют все вместе 3.13. Ресурсное окружение процесса Персонал документы продукция данные технические ресурсы материальные ресурсы знания и полномочия 3.14. Свойства процесса Результативность - характеризует соответствие результатов процесса нуждам и ожиданиям потребителей Определенность - отражает степень, с которой реальный процесс соответствует описанию Управляемость - характеризует степень, в которой производится управление выполнением процесса производства требуемых продуктов /услуг , отвечающих определенным целевым показателям Эффективность - отражает, насколько оптимально используются ресурсы при достижении необходимого результата процесса Повторяемость - характеризует способность процесса создавать выходные потоки с одинаковыми характеристиками при повторных его реализациях Гибкость (адаптируемость ) - способность процесса приспосабливаться к изменениям внешних условий, перестраиваться так, чтобы не снижались ни результативность, ни эффективность Стоимость - определяет совокупную стоимость выполнения функций процесса и передачи результатов от одной функции к другой 3.15. Мониторинг и измерение процессов Организация должна применять подходящие методы мониторинга и, где это целесообразно, измерения процессов системы менеджмента качества. Эти методы должны демонстрировать способность процессов достигать запланированных результатов. ИСО 9001-2000.Пункт 8.2.3 Показатели, характеризующие параметры процесса : Результативность Определенность Управляемость Эффективность Повторяемость Гибкость Для каждого процесса должны быть определены количественные или качественные величины - метрики, измерение которых позволить определить требуемые параметры. Метрика процесса - количественная мера степени достижения процессом своей цели . 3.16. Определение метрики процесса Цель процесса по возможности должна быть определена таким образом, чтобы о степени ее достижения можно было судить по единственной метрике процесса Метрика процесса - количественная мера степени достижения процессом своей цели. Она должна включать как меры эффективности процесса, так рейтинги уровней зрелости Целевая точка - желаемое значение метрики процесса Текущее измерение процесса - значение метрики процесса до реализации мероприятия по усовершенствованию Результат усовершенствования процесса - значение метрики процесса после осуществления мероприятий по усовершенствованию 3.17. Метрики характеристик процессов 1. Отношение фактического времени выполнения процесса к плановому времени выполнения 2. Степень автоматизации по количеству функций (количество функций с возможностью автоматизации /общее количество функций процесса) 3. Степень автоматизации по времени (суммарное время автоматизированных работ / суммарное время выполнения всех работ ) 4. Отношение суммарного времени выполнения функций процесса к суммарному времени ожидания 5. Отношение суммарного времени выполнения функций - интерфейсов взаимодействия с другими процессами к суммарному времени ожидания Часть II. Модели бизнес-процессов 6.1. Моделирование деятельности организации Модель - это совокупность графических символов, их свойств, атрибутов и связей между ними, которая адекватно описывает некоторые свойства моделируемой предметной области. Модель деятельности организации - совокупность взаимосвязанных и взаимодополняющих графических моделей различных типов, каждая из которых описывает существующую ситуацию в конкретной предметной области деятельности. Моделирование деятельности организации - документирование, анализ и оптимизация работы предприятия или отдельных направлений его деятельности, его целей и задач, механизмов и ресурсов, используемых для их достижения, правовых ограничений и взаимоотношений со средой, в которой предприятие ведет свою деятельность. Изменения способов ведения бизнеса не предполагают очевидной необходимости использования моделей. Для чего нужны модели? Модели бизнеса: 1. вводят точность и методологичность 2. обеспечивают единственное, последовательное представление 3. интегрируют процессы, ИТ-системы, оргструктуру, информацию и данные 4. позволяют увидеть и проанализировать взаимосвязи 5. помогают проводить проверку правильности, просмотр и тестирование процессов 6. обеспечивают информативную среду для оценки сценариев типа «а что, если ...» 7. являются основой для быстрого внедрения изменений процессов 6.2. Общие принципы моделирования 1.Принцип корректности Корректность моделей зависит от полноты и согласованности синтаксиса конкретной метамодели. Метамодель - «модель моделей», т.е. модель, обобщающая модели конкретной методологии моделирования. Мета - общность (греч.) 2. Принцип релевантности Модель не должна содержать информации больше, чем необходимо. 3. Принцип соизмеримости затрат и выгод Соотношение объема усилий для создания моделей и полезности моделирования конкретного сценария, продолжительности использования моделей. 4. Принцип прозрачности Разбиение моделей на различные типы представлений (подмодели) облегчает понимание моделей. 5. Принцип сравнимости Единая согласованная инфраструктура и язык моделирования, сопоставимость метамоделей для разных языков моделирования. 6. Принцип систематизированной структуры Возможность интеграции моделей различных типов на основании единой метамодели, объединяющей различные типы представлений. 6.3. Принципы моделирования деятельности организации Учет целей моделирования Использование эталонных и референтных моделей Моделирование «сверху-вниз» Принцип разумной достаточности. Решение не должно быть слишком сложным по сравнению с самой решаемой задачей. Обеспечение целостности описания Учет эргономических критериев (ограничение числа объектов и геометрического размера модели) Соизмеримость моделей одного уровня детализации по степени обобщения информации Концентрация ресурсов на ключевых аспектах деятельности и на «болевых точках» 6.4. Методологии моделирования Методология моделирования - учение о структуре, логической организации, методах и средствах деятельности в области структурного анализа Методологии структурного подхода DFD, STD, ERD, FDD, SADT, IDEF Методологии объектно-ориентированного подхода UML, RUP Методологии, ориентированные на бизнес-процессы Бизнес + Информационные системы = ARIS ARchitecture of Integrated Information Systems Архитектура интегрированных информационных систем 6.5. Методологии структурного подхода DFD (Data Flow Diagrams) - диаграммы потоков данных, обеспечивающих анализ требований и функциональное проектирование информационных систем. STD (State Transition Diagram) - диаграммы перехода состояний для проектирования систем реального времени. Структурные карты Джексона и /или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов. FDD (Functional Decomposition Diagrams) - диаграммы функциональной декомпозиции. SADT (Structured Analysis and Design Technique) - технология структурного анализа и проектирования семейство. Методология IDEF0 основана на подходе, разработанном Дугласом Россом в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, метод структурного анализа и проектирования). Является также основой IDEF1X. Семейство IDEF (ICAM - Integrated Computer Aided Manufacturing Definition): IDEF0 (Integration Definition method for Function Modeling) - методологияфункциональногомоделирования,позволяющаяописатьпроцессввидеиер архическойсистемывзаимосвязанныхфункций IDEF1 (Integration Definition method for Information Modeling) - применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. IDEF1X (Integration Definition method for Semantic Data Modeling) - методология моделирования структуры информации, основанная на концепции «сущность-связь». ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь». IDEF2 (Integration Definition method for Simulation Modeling) - позволяет построить динамическую модель меняющегося во времени поведения функций, информации и ресурсов производственной системы или среды. IDEF3 (Integration Definition method for Process Description Capture) - методологиядокументированиятехнологическихпроцессов. Методика потокового моделирования, а не структурного как IDEF0. WFD (Work Flow Diagram) - диаграмма потоков событий, инструмент графического представления функций системы, моделируемой в нотации IDEF3. IDEF4 (Integration Definition method for Object-Oriented Design) - методология объектно-ориентированного проектирования сложных систем, описывающая структуру, поведение и реализацию систем в терминах класса объектов. IDEF5 - методология, обеспечивающая наглядное представление данных обработки онтологических запросов. IDEF5 - методология онтологического анализа систем, т.е. анализа основных терминов и понятий (словаря), используемых для характеристики объектов и процессов, границ использования, взаимосвязей между ними. CASE-системы (Computer-Aided Software/System Engineering): BPwin, Erwin Инструментальные системы : MS Visio. 6.7. Методология SADT SADT (Structured Analysis and Disign Tecchnique) - технология структурного анализа и проектирования), основанная на концепции «сущность-связь» (entity-relationship). Представляет собой дальнейшее развитие методологии структурного анализа и проектирования. Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях: 1. графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются; 2. строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: 3. ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков); 4. связность диаграмм (номера блоков); 5. уникальность меток и наименований (отсутствие повторяющихся имен); 6. синтаксические правила для графики (блоков и дуг); 7. разделение входов и управлений (правило определения роли данных). 8. отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. 6.9. Методы бизнес-анализа ABB (Activity Based Budgeting) - планирование бюджета на основе выполняемых функций (операционное планирование бюджета): планирование бюджета компании или инвестиционного проекта с использованием принципов, средств и методов ABC. Фактически представляет собой обратное проектирование ABC-системы ABC (Activity Based Costing) - функционально-стоимостной анализ: метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах. АВМ (Activity Based Management) - управление на основе ABC-информации (операционное управление): методология, описывающая средства и способы управления организацией для совершенствования бизнес-процессов и повышения прибыльности на основе информации, предоставляемой в результате ABC-анализа. ARP (Activity Resource Planning) - функциональное планирование ресурсов: метод планирования ресурсов компании на основе анализа функций, задействованных в бизнес-процессах и данных ЛВС-анализа. Benchmarking: методология определения эффективности производственной системы посредством выбора системы показателей, проведения измерений и сравнения с эталоном. ВРI (Business Process Improvement) - непрерывное совершенствование (улучшение) бизнес-процессов: концепция плавного (пошагового) изменения организации бизнеспроцессов в направлении достижения требуемых показателей эффективности и качества. BPR (Business Process Redesign) - перепроектирование бизнес-процессов: концепция изменения организации деятельности компании на основе пересмотра отдельных бизнес-процессов. BPR (Business Process Reengenering) - реорганизация бизнес-процессов: направление деятельности, включающее «фундаментальное переосмысление и радикальное перепланирование бизнес-процессов для достижения скачкообразных улучшений в решающих показателях деятельности компании, таких как затраты, качество выполнения и скорость». СРI (Continuous Process Improvement) - непрерывное совершенствование процессов: один из подходов к совершенствованию качества бизнес-процессов. CPN (Color Petri Nets) - раскрашенные сети Петри: методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов, для входящих потоков различной структуры. 6.10. Функциональное моделирование в методике IDEF0 6.10.1. Концепция IDEF0 Методология IDEF0 (Integrated Definition Function Modeling) основана на подходе, разработанном Россом (Douglas T. Ross) в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, - метод структурного анализа и проектирования) [10]. На рисунке 2 представлен пример IDEF0-модели. Основу подхода и, как следствие, методологии IDEF0 составляет графический язык моделирования систем, обладающий следующими свойствами: 1. графический язык - полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации; 2. язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания. 3. язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (предприятия); 4. язык может генерироваться рядом CASE-средств, например, BPwin (компания Computer Associates, http://www.ca.com). Эти свойства предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в принятии методологии в 1993 г. федеральным стандартом Национальным институтом по стандартам и технологиям США (NIST) [11]. В 2000 г. методология IDEF0 была использована в нормативном документе Российской Федерации по функциональному моделированию в статусе «Рекомендации по стандартизации» [12]. Методология IDEF0 основана на следующих концептуальных положениях: Модель - искусственный объект, представляющий собой отображение системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих элементов, выполняющих некоторую полезную работу. Элементами системы могут быть любые комбинации разнообразных сущностей, включающих людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергоносители. Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит. Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF - представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Связи, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых систем. Итеративное моделирование. Разработка модели в IDEF0 представляет собой итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению и последующему редактированию, после чего цикл повторяется. Отделение «организации» от «функций». При разработке моделей следует избегать изначальной привязки функций исследуемой системы к существующей организационной структуре моделируемого объекта. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет: оценить адекватность модели, предложить решения, направленные на совершенствование этой структуры. 6.10.2. Синтаксис IDEF0 Компоненты синтаксиса языка IDEF0 - это блоки, стрелки, диаграммы, правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование. Стрелки - данные или материальные объекты, связанные с функциями. Правила определяют как следует применять компоненты. Диаграммы обеспечивают формат графического и словесного описания модели. 6.10.3. Семантика IDEF0 IDEF0 - это методология функционального моделирования и поэтому имя блока описывающее функцию, должно быть глаголом или глагольным оборотом. Примеры имен функций: производить детали, наблюдать за выполнением. Стрелки и их сегменты помечаются существительными или оборотами существительных. Примеры меток стрелок: менеджер, бюджет. Каждая сторона блока имеет своё определенное значение с точки зрения связи блокстрелка. Верхняя сторона имеет значение «управление», левая - «вход», правая «выход», а нижняя - «механизм». В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Пример блока представлен на рисунке 3. В IDEF0 различают пять классов стрелок - стрелка входа, стрелка выхода, стрелка управления, стрелка механизма, стрелка вызова. Стрелка входа - это материал или данные, которые преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелка входа рисуется как входящая в левую грань блока. Допускается, что функция может не иметь ни одной стрелки входа. Часто бывает сложно определить, являются ли данные входом, или управлением. В том случае, когда данные изменяются или перерабатываются, это вход, если нет - управление. Стрелка управления - это правила, стратегии, процедуры, стандарты, которые определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелка управления рисуется как входящая в верхнюю грань блока. Каждая функция должна иметь хотя бы одну стрелку управления. Управление влияет на функцию, но не преобразуется функцией. Если цель функции - изменить процедуру, то такая процедура будет для функции входом. В случае возникновения неопределенности в классифицировании стрелки (вход или управление) рекомендуется создавать стрелку управления. Стрелка выхода - это данные или материальные объекты, произведенные функцией. Стрелка выхода рисуется как выходящая из правой грани блока. Каждая функция должна иметь хотя бы одну стрелку выхода. Функция без выхода не имеет смысла и не должна моделироваться. Стрелка механизма - это ресурсы (персонал, техника, оборудование), поддерживающие выполнение функции. Стрелка механизма рисуется как входящая в нижнюю грань блока. Стрелка механизма может не изображаться на модели. Стрелка вызова - это стрелка, указывающая на другую модель. Стрелка вызова рисуется как исходящая из нижней грани блока. Такая стрелка используется как указание на то, что некоторая функция выполняется за пределами моделируемой системы. IDEF0-модели состоят из трех типов документов: графических диаграмм, текста, глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма - главный компонент модели, содержащий блоки, стрелки, соединения блоков и стрелок. Диаграмма является единицей описания системы и располагается на отдельном листе. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть декомпозированы на составные части и представлены в виде более подробных диаграмм. Процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте. Модель может содержать следующие типы графических диаграмм: контекстная, декомпозиции, дерева узлов, иллюстрации. Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма А-0 устанавливает область моделирования и ее границу. Необходимо установить, что входит в систему, а что лежит за ее пределами, то есть определить, что будет рассматриваться как компоненты системы, а что - как внешнее воздействие. В пояснительном тексте к контекстной диаграмме должна быть указана цель построения диаграммы и зафиксирована точка зрения. Цель - это краткая формулировка причины создания модели. Цель должна отвечать на вопросы: почему этот процесс должен быть смоделирован? что должна показать модель? что может получить читатель? Точка зрения - это указание на должностное лицо или подразделение организации, с позиции которого разрабатывается модель. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться. Это связано с тем, что в конечном итоге финансового директора не интересуют аспекты обработки сырья на производственном оборудовании, а главному технологу ни к чему прорисованные схемы финансовых потоков. Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополнительную детализацию родительского блока. Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Таким образом, дочерняя диаграмма как бы вложена в свой родительский блок. Диаграмме может быть поставлен в соответствие текст, представляющий собой краткий комментарий к содержанию диаграммы. Текст не должен использоваться для описания и без того понятных блоков и стрелок на диаграмме. Глоссарий - это список определений для ключевых слов, фраз, аббревиатур, связанных с блоками, стрелками или с моделью в целом. Глоссарий определяет термины, которые должны одинаково понимать все участники разработки. Диаграммы иллюстрации используются в качестве дополнений, поясняющих специфику содержания основных диаграмм, для иллюстрации альтернативной точки зрения. Такие диаграммы могут не подчиняться правилам IDEF0. Диаграммы дерева узлов показывают иерархию функций в модели и позволяют рассмотреть всю её целиком. На диаграммах узлов нет стрелок. Диаграмм узлов может быть в модели сколько угодно, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня. 6.10.4. Свойства диаграмм IDEF0 имеет шесть типов связей между блоками в пределах одной диаграммы: доминирование, управление, выход-вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Доминирование определяется взаимным расположением блоков на диаграмме. Предполагается, что блоки, расположенные на диаграмме выше и левее, влияют на блоки, распложенные ниже и правее. Блоки на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования. Поэтому в левом верхнем углу располагается самая важная функция или функция, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже функции. Остальные пять типов описывают связи между блоками и изображаются стрелками. Для связи блоков между собой используются внутренние стрелки, то есть стрелки, не касающиеся границы диаграммы, которые начинаются у одного и кончаются у другого блока. Такая стрелка отличается от граничной стрелки. Связь по управлению и связь по входу являются простейшими, поскольку отражают прямые взаимодействия. Связь по управлению (рисунок 4) возникает тогда, когда выход одного блока служит управляющим воздействием на блок с меньшим доминированием. Объекты выхода вышестоящей функции не меняются в нижестоящей. Связь выход-вход (рисунок 5) возникает при соединении выхода одного блока с входом другого блока с меньшим доминированием. Обратная связь по входу и обратная связь по управлению являются более сложными типами связей, поскольку они представляют итерацию (выход функции влияет на будущее выполнение других функций с большим доминированием, что впоследствии скажется на исходной функции). Обратная связь по входу (рисунок 6) имеет место тогда, когда выход блока становится входом другого блока с большим доминированием. Такая связь, как правило, используется для описания циклов. Обратная связь по управлению возникает в том случае, когда выход одного блока создает управляющее воздействие на блок с большим доминированием (рисунок 7). Такая связь часто свидетельствует об эффективности бизнес-процесса. Связь выход-механизм (рисунок 8) отражает ситуацию, при которой выход одной функции становится средством достижения цели для другой, т.е. выход одного блока направляется на механизм другого. Такая связь показывает, что одна функция подготавливает ресурсы, необходимые для другой функции. Связи выход-механизм возникают при отображении в модели процедур выполнения и распределения ресурсов, подготовки средств для выполнения функций системы (например, приобретение оборудования, финансирование, закупка материалов). 6.10.5. Преимущества IDEF0 Идея IDEF0 состоит в том, что бизнес-процессы (функции реального объекта бизнеса) представляются как некие преобразования входного потока в выходной под контролем (управлением) управляющего потока с использованием для преобразования механизма. Основные преимущества IDEF0 состоят в следующем: 1. полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи); 2. комплексность при декомпозиции (мигрирование и туннелирование стрелок); 3. возможность агрегирования и детализации потоков данных и информации (разделение и слияние стрелок); 4. наличие жестких требований методологии, обеспечивающих получение моделей процессов стандартного вида; 5. простота документирования процессов; соответствие подхода к описанию процессов в IDEF0 стандартам ISO 9000:2000. Отсюда и общее назначение IDEF0 - это перестройка структуры функций, которая позволит повысить производительность и эффективность системы. 6.11. Функциональное моделирование в методике IDEF3 6.11.1. Концепция IDEF3 Методология IDEF3 (Integrated Definition Process Description Capture Method) была разработана с целью более удобного описания рабочих процессов (Work Flow), для которых важно отразить логическую последовательность выполнения процедур. Эта методика, в отличии от IDEF0, не стандартизирована. С ее описанием можно познакомиться на сайтеhttp://www.idef.com [13]. На рисунке представлен пример IDEF3-модели. IDEF3 - это структурный метод, показывающий причинно-следственные связи и события. Он также показывает, как организована работа, и какие пользователи работают с моделируемой системой. IDEF3 состоит из двух методов. Process Flow Description (PFD) - описание процессов, с описанием того, как организована работа между различными элементами моделируемой системы. Object State Transition Description (OSTD) - описание переходов состояний объектов, с описанием того, какие существуют промежуточные состояния у объектов в моделируемой системе. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. Сценарием называется описание последовательности изменения свойств объекта в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение ее свойств после прохождения каждого этапа). Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух потоков: (1) документы, определяющие структуру и последовательность процесса (технологические указания, описания стандартов) и (2) документы, отображающие ход его выполнения (результаты экспертиз, отчеты о браке). Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи: 1. документировать имеющиеся данные о технологии процесса; 2. определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов; 3. определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса (например, изменение технологических свойств конечного продукта); 4. содействовать принятию оптимальных решений при реорганизации технологических процессов; 5. разрабатывать имитационные модели технологических процессов по принципу «как будет, если...» [14]. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция может быть представлена в виде отдельного процесса средствами IDEF3. Но функциональное моделирование в IDEF3 отличается от моделирования в IDEF0 и DFD, тем что она отражает функции системы во временной последовательности их осуществления. 6.11.2. Синтаксис IDEF3 Компоненты синтаксиса языка IDEF3 (рисунок 10) - это единицы работы, стрелки, перекрестки, объекты ссылок, диаграммы, правила. Единица работы описывает процесс, действие, решение. Стрелки показывают последовательность выполнения работ. Перекрестки используются в диаграммах, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса, которые могут возникнуть во время его выполнения. Правила определяют как следует применять компоненты. Диаграммы обеспечивают формат графического и словесного описания модели. 6.11.3. Семантика IDEF3 Единица работы - это основной компонент диаграммы IDEF3, близкий по смыслу к блоку IDEF0, изображается прямоугольником с прямыми углами, с именем и номером. Работа именуются отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы. Другое имя существительное в составе той же фразы обычно изображает основной результат работы (например, приготовление фарша). Номер единицы работы присваивается при ее создании и не меняется никогда. Даже если работа будет удалена, ее номер не будет вновь использоваться. Обычно номер состоит из номера родительской работы и порядкового номера на текущей диаграмме. Работа требует более подробного описания, чем блок в IDEF0. Каждая единица должна иметь документ, который включает текстовое описание компонентов работы: объектов и фактов, связанных с ней, ограничений, накладываемых на работу и дополнительное описание работы. Стрелки на диаграмме IDEF0 означают потоки информации или объектов, передаваемые от одной функции к другой. На диаграмме IDEF3 стрелки могут показывать только последовательность выполнения работ, то есть имеют иной смысл, нежели стрелки IDEF0. В IDEF3 различают три типа связей изображаемых стрелками: связь предшествования, связь отношения, поток объектов. Связь предшествования показывает, что прежде, чем начнется работа-приемник, должна полностью завершиться работа-источник. Такая связь обозначается сплошной линией. Связь должна быть именована таким образом, чтобы при чтении модели была понятна причина ее появления. Поток объектов показывает участие некоторого объекта в двух или более единицах работы: например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Связь отношения - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией. Связи этого типа используются для отражения отношений между работами, которые невозможно описать с использованием связей предшествования или потока объектов. Одно из применений такой связи - отображение взаимоотношений между параллельно выполняющимися работами. Отношение является альтернативой связи предшествования и потока объектов в смысле задания последовательности выполнения работ: работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса, могущие возникнуть во время его выполнения. В отличии от IDEF0 в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Различают перекрестки для слияния и разветвления стрелок. Перекресток слияния узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса. Перекресток ветвления - узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно. Объекты ссылок служат для выражения идей и концепций без использования таких методов, как стрелки, перекрестки или работы. Они используются при построении диаграмм для привлечения внимания пользователей к каким-либо важным аспектам модели. Глава 8. Основные понятия IDEF0 8.1. Назначение Постоянное усложнение производственно-технических и организационноэкономических систем - фирм, предприятий и других субъектов производственнохозяйств енной деятельности, а также необходимость их анализа с целью совершенствования функционирования и повышения эффективности обусловливает необходимость наличия специальных средств описания и анализа таких систем. Эта проблема приобретает особую актуальность с связи с появлением интегрированных компьютеризированных производств и автоматизированных предприятий [1]. Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF, позволяющие исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Общая методология IDEF включает частные методологии, основанные на графическом представлении систем: IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3 и др. Подробные спецификации на эти стандарты можно найти на сайте http://www.idef.com. Методология IDEF0 основана на подходе, разработанном Дугласом Россом в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, метод структурного анализа и проектирования) [3]. Основу подхода и, как следствие, методологии IDEF0 составляет графический язык моделирования систем, обладающий следующими свойствами: (1) Графический язык - полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации. (2) Язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания. (3) Язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (предприятия). (4) Язык может генерироваться рядом CASE-средств, например, BPwin (компания Computer Associates, http://www.ca.com), AI0 WIN (компания KBSI, http://www.idef.com). Эти свойства предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в принятии методологии в качестве федерального стандарта США [2]. В 2000 г. методология IDEF0 была принята в качестве стандарта в Российской Федерации [1]. 8.2. Концепция Методология IDEF0 основана на следующих концептуальных положениях [1]. Модель - искусственный объект, представляющий собой отображение системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А (М модель, А - моделируемый объект). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих элементов, выполняющих некоторую полезную работу. Элементами системы могут быть любые комбинации разнообразных сущностей, включающих людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергоносители. Модель описывает: (1) что происходит в системе, (2) как ею управляют, (3) какие сущности она преобразует, (4) какие средства использует для выполнения своих функций и (5) что производит. Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF - представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Связи, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых систем. Итеративное моделирование. Разработка модели в IDEF0 представляет собой итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению и последующему редактированию, после чего цикл повторяется. Отделение «организации» от «функций». При разработке моделей следует избегать изначальной привязки функций исследуемой системы к существующей организационной структуре моделируемого объекта. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет: (1) оценить адекватность модели, (2) предложить решения, направленные на совершенствование этой структуры. 8.3. Компоненты языка Компоненты синтаксиса языка IDEF0 - блоки, стрелки, диаграммы, правила [1]. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование. Стрелки представляют данные или материальные объекты, связанные с функциями. Правила определяют как следует применять компоненты. Диаграммы обеспечивают формат графического и словесного описания модели. Пример блока показан на рисунке 1. Внутри блока помещается его имя Почистить картофель и номер 1. Стрелка формируется из одного или более отрезков прямых и наконечника на одном конце. Стрелки могут ветвиться или сливаться (рис. 2). 8.4. Имена и метки Так как IDEF0 - методология функционального моделирования, то имя блока, описывающее функцию, должно быть глаголом или глагольным оборотом. Примеры имен функций: производить детали, наблюдать за выполнением, планировать ресурсы. Стрелки и их сегменты помечаются существительными или оборотами существительных. Примеры меток стрелок: менеджер, бюджет, конструкция детали. 8.5. Блоки и стрелки Каждая сторона блока имеет своё определенное значение с точки зрения связи блокстрелка. Верхняя сторона имеет значение «управление», левая - «вход», правая «выход», а нижняя - «механизм». В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. В IDEF0 различают пять классов стрелок - (1) стрелка входа, (2) стрелка выхода, (3) стрелка управления, (4) стрелка механизма, (5) стрелка вызова. Стрелка входа - это материал или данные, которые преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелка входа рисуется как входящая в левую грань блока. Допускается, что функция может не иметь ни одной стрелки входа. Часто бывает сложно определить, являются ли данные входом, или управлением. В том случае, когда данные изменяются или перерабатываются, это вход, если нет - управление. Стрелка управления - это правила, стратегии, процедуры, стандарты, которые определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелка управления рисуется как входящая в верхнюю грань блока. Каждая функция должна иметь хотя бы одну стрелку управления. Управление влияет на функцию, но не преобразуется функцией. Если цель функции - изменить процедуру, то такая процедура будет для функции входом. В случае возникновения неопределенности в классифицировании стрелки (вход или управление) рекомендуется создавать стрелку управления. Стрелка выхода - это данные или материальные объекты, произведенные функцией. Стрелка выхода рисуется как выходящая из правой грани блока. Каждая функция должна иметь хотя бы одну стрелку выхода. Функция без выхода не имеет смысла и не должна моделироваться. Стрелка механизма - это ресурсы (персонал, техника, оборудование), поддерживающие выполнение функции. Стрелка механизма рисуется как входящая в нижнюю грань блока. Стрелка механизма может не изображаться на модели. Стрелка вызова - это стрелка, указывающая на другую модель. Стрелка вызова рисуется как исходящая из нижней грани блока. Такая стрелка используется как указание на то, что некоторая функция выполняется за пределами моделируемой системы. Стандартное расположение стрелок показано на рис. 3.
