Презентация "Сущности и принципы реинжиниринга бизнес-процессов" по экономике – проект, доклад

Сущность и принципы реинжиниринга бизнес-процессов

Установочная лекция Профессор Кафедры Математики и информатики Васильев В.П.

Цель преподавания дисциплины

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

Литература

Тельнов Ю. Реинжиниринг бизнес-процессов. М: Финансы и статистика, 2005. Абдикеев, Н.М. Реинжиниринг бизнес-процессов: учебник/ Н.М.Абдикеев, Т.П.Данько, С.В.Ильдеменов, А.Д.Киселев.-М.: Эксмо, 2007 Железко, Б.А. Реинжиниринг бизнес-процессов: учеб.пос./ Б.А.Железко, Т.А.Ермакова, Л.П.Володько; под ред. Б.А.Железко.-Мн.: Книжный дом, Мисанта, 2006. Ильин, В.В. Моделирование бизнес-процессов. Практический опыт разработчика: / В.В.Ильин.-М.: ООО"И.Д.Вильямс, 2006. Васильев В.П. Реинжиниринг бизнес процессов (цикл лекций) МФ МЭСИ ,2010. Васильев В.П. Моделирование бизнес процессов (практикум на ПК) МФ МЭСИ ,2010.

Определения

Бизнес-процесс -система последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью определенных ресурсов за определенное время входы процесса преобразуются в выходы - в результаты, представляющие ценность для потребителя и приносящие прибыль изготовителю. Бизнес-процесс – связанные между собой процедуры (операции, функции). В бизнес-процесс их объединяют: бизнес-задача (цель) предприятия, которая объединяет процедуры «изнутри», являясь стержнем, на который «нанизываются» процедуры. организационная структура, которая задает ограничения (рамки), также объединяющие процедуры в бизнес-процесс«извне», ограничивая единое пространство, на котором они существуют . Поток работ – множество рабочих заданий. В понятие потока работ задачи объединяются: упорядочением во времени, рамках правил, определенных для данного бизнес-процесса.

бизнес-процесс характеризуется:

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

Примеры бизнес процессов предприятия

Корни РБП

Реинжиниринг бизнес-процессов берет свое начало, как это общепризнанно, в двух статьях, написанных в 1990 году Хаммером (Hammer) и Давенпортом и Шортом (Davenport and Short) реинжиниринг определяется как : «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов организации для достижения коренных улучшений в актуальных основных показателях их деятельности: стоимость, качество, услуги и темпы». Имеется в виду не небольшое усовершенствование бизнес-процессов организаций, а кардинальное повышение их эффективности – в десятки и даже сотни раз. В исследованиях настоящего времени требование радикальности стало смягчаться. Действительно, во многих случаях трудно четко определить, какие преобразования являются радикальными, а какие – нет. В связи с этим в литературе и на практике начали употребляться термины «революционный реинжиниринг» и «эволюционный реинжиниринг».

Цель реинжиниринга бизнес-процессов

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

Сравнительная характеристика совершенствования и реинжиниринга бизнеса

Реинжиниринг применяется в трех основных ситуациях.

1.В условиях, когда фирма находится в глубоком кризисе, который может выражаться в явно неконкурентном уровне издержек, массовом отказе потребителей от продукта фирмы и т.п. 2. Когда текущее положение фирмы может быть признано удовлетворительным, однако прогнозы ее деятельности являются неблагоприятными. Фирма сталкивается с нежелательными для себя тенденциями в части конкурентоспособности, доходности, уровня спроса. 3. Реализацией возможностей реинжиниринга занимаются благополучные, быстрорастущие и агрессивные организации. Их задача состоит в ускоренном наращивании отрыва от ближайших конкурентов и создании уникальных конкурентных преимуществ. Применение реинжиниринга в этой ситуации является лучшим вариантом ведения бизнеса.

базовые правила реинжиниринга

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

реинжиниринг бизнес-процессов обеспечивает решение следующих задач

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

Операции реинжиниринга бизнес-процессов и их следствия

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

Особенности реинжиниринга

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

Типовая схема

Обратный инжиниринг — исследование существующих бизнес-процессов

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

Постановка проблемы

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

Работы на стадии идентификации

Формулирование (уточнение) миссии предприятия. Определение ключевых факторов успеха (7-8 факторов): длительность, издержки, качество, сервисное обслуживание и т.д. Выявление основных видов бизнес-процессов, как существующих, так и перспективных (10 — 15 процессов). Оценка бизнес-процессов по степени реализации ключевых факторов успеха. Ранжирование бизнес-процессов с указанием приоритетов реинжиниринга. Неформальное описание отличительных особенностей бизнес-процессов. Спецификация существующих обеспечивающих производственных и информационных технологий. Описание возможных сценариев развития предприятия: появление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов. Определение ограничений, связанных с уровнем квалификации персонала фирмы, технической оснащенности производства и т.д. Определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров.

Определение узких мест

Анализируются разработанные модели бизнес процессов , по заданным критериям. В качестве основных критериев анализа используются: Стоимость (ABC); Время реализации; Риски . Определяются факторы отклонений процессов от необходимых параметров. Расставляются приоритеты реализации процессов.

Прямой инжиниринг — построение новых бизнес-процессов

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

Разработка проекта бизнес-процессов.

После определения основных направлений реорганизации бизнес-процессов осуществляется разработка обеспечивающих подсистем, поддерживающих функционирование новой системы организации бизнеса. В части изменения структуры организационно-экономической системы осуществляется: разработка должностных инструкций, обучение персонала, подготовка рабочей документации. В части создания новой информационной системы осуществляется: разработка и наполнение базы данных, установка системы телекоммуникации, программирование, настройка и отладка программных модулей. Обычно в реинжиниринге бизнес-процессов используются современные средства автоматизации проектирования Computer Aided Software/Sistem Engineering ( аббревиатура CASE-технологии), например простые общедоступные BP Win , Rasional Rose или более совершенные Oracle Designer2000, SilverRun, Natural Engineering Workbench и др

Внедрение проекта бизнес-процессов

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

организационная структура проекта

Регламентирующий комитет выделяет ресурсы на предприятии для проведения реинжиниринга и контролирует выполнение всех этапов в соответствии с разработанным планом-графиком сдачи работ. Методологический центр координирует работу команд реинжиниринга и обеспечивает их методологией, инструментарием, типовыми решениями и обычно формируется из представителей консалтинговой фирмы. Лидер проекта — это менеджер верхнего звена управления, который возглавляет работы по реинжинирингу бизнес процессов на всех его этапах Команды РБП выполняют реинжиниринг бизнес-процессов, число которых определяется числом реорганизуемых процессов. Команды реинжиниринга бизнес-процессов создаются из работников предприятия, являющихся высококлассными экспертами на смежных участках бизнес-процесса, и сторонних консультантов — инженеров в области структурирования и моделирования бизнес-процессов. Обычно соотношение собственных работников и консультантов — 3 к одному, а общая численность команды — в среднем 10 человек Владельцы бизнес-процессов — это будущие администраторы процессов.

Команды реинжиниринга

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

Примерная структура команды

Моделирование бизнес процессов

Понятие моделирование БП

Важнейшим инструментом для проведения Реинжиниринга БП является моделирование. Модель— некоторый материальный или мысленно представляемый объект или явление, являющийся упрощённой версией моделируемого объекта или явления (прототипа) и в достаточной степени повторяющий свойства, существенные для целей конкретного моделирования (опуская несущественные свойства, в которых он может отличаться от прототипа).. Для проведения анализа состояния предприятия необходимо иметь модель двух видов: Модель «как есть (as is)», представляющая собой описание реальное положение дел на предприятии (структура, протекающие бизнес- процессы, используемые технологии и т.д.). Такая модель позволяет понять как функционирует предприятие и какие процессы в нем протекают, а также выявить ошибки и узкие местабизнс – процессов и сформулировать предложения по их реинжинирингу Модель «как должно быть (as to be)» интегрирующая предложения руководства, сотрудников предприятия, экспертов и системных аналитиков и позволяющая сформулировать видение новых бизнес- процессов, оценить их эффективность и целесообразность реализации.

Два направления моделирования Бизнес Процессов

Функциональное моделирование , использование методик IDEF , инструментарии : AllFusion Process Modeler (BPWin) компании Computer Associates или ORACLE BUSINESS PROCESS MANAGEMENT SUITE компании ORACLE Объектное моделирование использование методик UML, инструментарий Rational Rose , ARIS , Natural Engineering Workbench

Объектно-ориентированный подход

Бизнес процесс рассматривается как взаимодействие объектов (субъектов) направленное на реализацию целей организации. При объектно-ориентированном подходе различают объектно-ориентированный анализ БП (ООА), объектно - ориентированное проектирование БП (OOD) . OOA – (Object Oriented Analysis) методология, при которой требования к процессу воспринимаются с точки зрения классов и объектов, выявленных в предметной области. OOD – (Object Oriented Design) – методология проектирования, соединяющая в себе процесс объектной декомпозиции и приёмы представления логической, физической, а также статической и динамической моделей проектируемого процесса. Основной инструмент унифицированный язык моделирования UML (Unified Modeling Language).

Унифицированный язык визуального моделирования (UML)

Назначение Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством для структурного и функционального моделирования. UML пригоден для моделирования любых процессов: от информационных масштаба предприятия до локальных в масштабах исполнителя. Является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика процесса, лидера проекта и различных групп разработчиков; UML содержит механизмы расширения и специализации базовых концепций языка. Средства UML позволяют рассмотреть процессы со всех точек зрения, имеющих отношение к разработке и последующему развертыванию любого процесса . Несмотря на обилие выразительных возможностей, язык прост для понимания и использования. Изучение UML удобнее всего начать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка .

Методики моделирования бизнес процессов IDEF

Методики проектирования IDEF

Развитие методов и моделей реинжиниринга привело к необходимости создания взаимосвязанной совокупности методик моделирования и концептуального проектирования, которая обеспечивала бы возможность эффективного обмена информацией между всеми специалистами – участниками процесса реинжиниринга В 90х гг. в США разработана совокупность методик, по программе компьютеризации промышленности ICAM (Integrated Computer-Aided Manufacturing), получила название IDEF (аббревиатура от Icam DEFinition или Integrated Definition). Некоторые из этих методик получили статус государственного стандарта США. IDEF-технологии находят успешное применение в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Основными являются: методология функционального моделирования бизнес-процессов IDEF0, методология документирования процессов предприятия IDEF3, дополненная технологией анализа потоков данных DFD.

Методика IDEF0

Методология функционального моделирования IDEFO — это технология описания системы в целом как множества взаимозависимых действий, или функций. Важно отметить функциональную направленность IDEFO — функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. "Функциональная" точка зрения позволяет четко отделить аспекты назначения системы от аспектов ее физической реализации Методология предназначена для функционального моделирования, т. е. моделирования выполнения функций объекта, путём создания описательной графической модели, показывающей что, как и кем делается в рамках функционирования предприятия. Наиболее часто IDEFO применяется как технология исследования и проектирования систем на логическом уровне. По этой причине он, как правило, используется на ранних этапах разработки проекта моделирования для сбора данных и моделирования процесса "как есть". (AS IS) а в совокупности с IDEF3 и для реинжиниринга БП (AS to BE)

Применение IDEF0

для построения двух видов моделей: При обследовании предприятия строится функциональная модель КАК ЕСТЬ, которая позволяет чётко зафиксировать, какие деловые процессы осуществляются на предприятии, какие информационные объекты используются при выполнении деловых процессов и отдельных операций. Функциональная модель КАК ЕСТЬ является отправной точкой для анализа потребностей предприятия, выявления проблем и "узких" мест и разработки проекта совершенствования деловых процессов. Функциональная модель КАК БУДЕТ позволяет уже на стадии проектирования будущей информационной системы определить эти изменения. Применение функциональной модели КАК БУДЕТ позволяет не только сократить сроки внедрения информационной системы, но также снизить риски, связанные с невосприимчивостью персонала к информационным технологиям.

Методика IDEF3

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

Применение IDEF3

Документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса. Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. Содействовать принятию оптимальных решений при реорганизации технологических процессов. Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."

Диаграммы потоков данных (DFD)

Диаграммы DFD используются для анализа документооборота в рамках моделируемого IDEF0 процесса, основное назначение -анализ управляемости основного процесса. DFD – использующий понятия "поток данных" и "хранилище данных" для описания системы в виде набора диаграмм, отражающих и структурирующих требования к проектируемой системе. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей "AS-IS" и "AS-TO-BE", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации.

Методология IDEF0

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

Синтаксис языка

Набор структурных компонентов языка, их характеристики и правила, определяющие связи между компонентами, представляют собой синтаксис языка. Компоненты синтаксиса IDEF0 – блоки, стрелки, диаграммы и правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование ; Стрелки представляют данные или материальные объекты, связанные с функциями; Правила определяют, как следует применять компоненты; Диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели.

Блоки (Действия)

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

Нумерация блоков и диаграмм

Все функциональные блоки IDEFO нумеруются. В номерах допускается использование префиксов произвольной длины, но в подавляющем большинстве моделей используется префикс А. Номер блока проставляется за префиксом. Контекстный блок всегда имеет номер АО. Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А1, А2, A3 и т.д. А1 декомпозируется в А11, А12, А13 и т.д. А11 декомпозируется в А111, А112, А113 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.

Стрелка.

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

Использование стрелок

В IDEFO также моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения — объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе. Для отображения категорий информации, присутствующих на диаграммах IDEFO, существует аббревиатура ICOM, отображающая четыре возможных типа стрелок: I (Input) — вход — нечто, что потребляется в ходе выполнения процесса; С (Control) — управление — ограничения и инструкции, влияющие на ход выполнения процесса; О (Output) — выход — нечто, являющееся результатом выполнения процесса; М (Mechanism) — исполняющий механизм — нечто, что используется для выполнения процесса, но не потребляется само по себе.

Стрелки входа.

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

Стрелки управления.

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

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

Стрелки выхода.

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

механизм исполнения

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

Комбинированные стрелки

В IDEFO существует пять основных видов комбинированных стрелок: выход — вход; выход — управление; выход — механизм исполнения; выход — обратная связь на управление; выход — обратная связь на вход.

Разбиение и соединение стрелок.

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

Туннели

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

Диаграммы IDEF0.

IDEF0-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг н друга. Графическая диаграмма – главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.

Диаграммы

Типовая диаграмма IDEFO содержит на полях служебную информацию. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и "подвала"). Элементы заголовка используются для отслеживания процесса создания модели. Элементы "подвала" отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.

Элементы заголовка диаграммы IDEFO

элементы "подвала" диаграммы

Контекстная диаграмма верхнего уровня.

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя –общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A-0 устанавливает область моделирования и ее границу.

Пример

Иерархия диаграмм

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

Родительская диаграмма –

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

Дочерняя диаграмма .

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

Контекстная диаграмма A-0

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

Нумерации блоков на диаграммах

То, что блок является дочерним и раскрывает содержание родительского блока на диаграмме предшествующего уровня, указывается специальным ссылочным кодом, написанным ниже правого нижнего угла блока. Этот ссылочный код может формироваться несколькими способами, из которых самый простой заключается в том, что код , начинающийся с буквы А(по имени диаграммы А-0), содержит цифры, определяемые номерами родительских блоков. код формируется так: А 6 1 * * * * | | | | |__________ и т.д. | | | |___________ Номер блока на диаграмме А61 | | |_____________Номер блока на диаграмме А6 | |______________ Номер блока на диаграмме А0 |________________ Имя блока А0

Текст и глоссарий

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

Стрелки как ограничения .

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

Параллельное функционирование.

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

Отношения между блоками диаграммы и другими диаграммами (окружающей средой).

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

Граничные стрелки.

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

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

использованием методики IDEF0

Начальные этапы моделирования

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

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

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

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

Пример нумерации и расположения

Разветвления на диаграмме

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

Классификация объектов

уточняет тип обрабатываемого в дальнейшем объекта. Например, класс объектов «Заказ» делится на подклассы «Заказ нового клиента», «Заказ старого клиента. Разветвление в этом случае обеспечивает альтернативность путей выполнения процесса реализации заказа клиента. При этом каждый путь должен быть помечен именем подтипа объекта

Разбиение объекта на компоненты

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

Одновременный доступ к объекту

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

Объединение на диаграмме

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

Обратные связи

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

Пример организации связей

Правила построения диаграмм

1. В составе модели должна присутствовать контекстная диаграмма A-0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме A-0 должен быть 0. 2. Блоки на диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные.

3. Не контекстные диаграммы должны содержать не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков менее трех вызывают серьезные сомнения в необходимости декомпозиции родительской функции. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток. 4. Каждый блок не контекстной диаграммы получает номер, помещаемый в правом нижнем углу; порядок нумерации - от верхнего левого к нижнему правому блоку (номера от 1 до 6).

5.Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на дочернюю диаграмму; ссылка (например, узловой номер, C-номер или номер страницы) помещается под правым нижним углом блока. 6. Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные данные. 7. При наличии стрелок со сложной топологией целесообразно повторить метку для удобства ее идентификации. 8. Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки.

9. Блоки всегда должны иметь хотя бы одну управляющую и одну выходную стрелку, но могут не иметь входных стрелок. 10. Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы. 11. Максимально увеличенное расстояние между параллельными стрелками облегчает размещения меток, их чтение и позволяет проследить пути стрелок.

12. Стрелки связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме 13. Обратные связи по управлению должны быть показаны как «вверх и над» 14. Обратные связи по входу должны быть показаны как "вниз и под" Так же показываются обратные связи посредством механизма. Таким образом обеспечивается показ обратной связи при минимальном числе линий и пересечений

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

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

16. Если возможно, стрелки присоединяются к блокам в одной и той же позиции. Тогда соединение стрелок конкретного типа с блоками будет со-гласованным и чтение диаграммы упростится.

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

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

Инструментальная среда BPwin

CASE-средство BPWIN

Интерфейс

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer

Задание методики

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель . BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Построение модели IDEF0

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

Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы — наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования.

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

Цель моделирования

Цель моделирования определяется из ответов на следующие вопросы: Почему этот процесс должен быть смоделирован? Что должна показывать модель? Что может получить клиент? Точка зрения (Viewpoint). Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом

Настройка отчета

Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет

Заключение

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.