МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ
Реинжениринг бизнес-процессов Для успешного построения бизнес-процессов, так и для реинжениринга, необходимо тесное взаимодействие между специалистами в сфере информационных технологий и экспертами в предметной области бизнеса. Языком взаимодействия является язык контекстных диаграмм, который позволяет описать текущую структуру бизнеспроцессов, а также желаемые изменения. • Как можно быстро пытаться документировать структуру бизнес-процессов? • Как быстро получить четкое представление о том, что происходит на предприятии? • Как определить характер предполагаемых изменений и дивиденды, которые эти изменения принесут? Для успешного решения данных и многих других вопросов, современный рынок программного обеспечения предлагает различные CASE-средства. Одним из таких средств является продукт компании Computer Associates – BPWin.
Бизнес-модель предприятия — это совокупность графических и текстовых описаний, позволяющих понимать, а в случае использования электронных средств динамического моделирования, имитировать процесс управления предприятием. Обычно бизнес-модель формируется в целях усовершенствования процесса управления, когда руководство понимает, что предприятие должно перейти на новую ступень развития, например повысить качество производимой продукции или оказываемых услуг, выйти на внешний рынок и т. п. Система БМ обычно содержит в себе встроенные средства динамического моделирования деятельности предприятия, позволяющие: • визуализировать деятельность предприятия, обеспечив руководству возможность правильно оценить имеющиеся недостатки и отыскать источники потенциала и направления усовершенствования; • сократить время настройки ИСУ под специфические особенности предприятия; • отобразить и зафиксировать в готовом для последующего развертывания виде варианты реализации ИСУ, каждый из которых может быть выбран при переходе на очередную ступень развития предприятия.
Бизнес-модель является отображением предприятия и его информационно-управляющей системы. Без бизнес-модели вы не сможете построить действительно интегрированную и «всеобъемлющую» ИСУ. Именно при создании бизнес-модели формируется «язык общения» консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятия ( «корпоративная система управления» ) Очень важно с самого начала определиться, на кого будете ориентироваться при построении модели, то есть кто будет ее конечным потребителем. В большинстве случаев ответ на этот вопрос один: руководство компании. Все попытки использования только точек зрения главного бухгалтера или коммерческого директора превращают модель промышленного предприятия в модель финансового института или торгового дома.
В основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели: • бизнес-функции, описывающие, ЧТО делает бизнес; • бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции; • организационная структура, определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы; • фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции; • роли, определяющие, КТО исполняет бизнес-процессы; • правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.
Построение функциональной модели системы Методология IDEF 0 Для построения функциональных моделей обычно используется методология IDEF 0. Методология IDEF 0, более известная как методология SADT (Structure Analysis and Design Technique) предназначена для представления функций системы и анализа требований к системам. В IDEF 0 реализованы идеи системного анализа, под которыми понимают исследования, начинающиеся с общего обзора системы, а затем детализируют ее в виде иерархической структуры с определенным числом уровней, на каждом из которых не более 8 элементов. В результате система разбивается на функциональные части, дается их описание, исследуются информационные потоки и формализуется структура данных. В основе структурного анализа используются два базовых принципа: принцип «разделяй и властвуй» и принцип иерархического упорядочения.
Первый принцип системного анализа позволяет решение трудных проблем выполнять путем разбиения их на множество более мелких независимых задач, легких для понимания и решения. При этом свою работу системный аналитик начинает методом «сверху-вниз» , реализуя первый принцип системного подхода: движение от общего к частному в различных аспектах. Это, прежде всего, движение мысли по иерархической структуре организации (как системы) сверху вниз, рассмотрение отдельных подсистем. Процессы функционирования подразделений делятся на подпроцессы, а те - на отдельные действия. Сложные свойства организации в целом, ее подразделений и отдельных сотрудников декомпозируются на менее сложные и далее - на квазипростые (если декомпозировать далее нет необходимости) и простые (если декомпозировать далее уже невозможно) свойства.
Второй принцип в дополнение к первому декларирует, что эти независимые задачи должны быть организованы в виде древовидных иерархических структур. Реализация второго принципа предусматривает единство анализа и синтеза, то есть предполагается, что каждый шаг по анализу организации выполняется с постоянным прицелом на ее последующую реструктуризацию, на синтез более эффективной структуры и разработку более эффективного алгоритма функционирования организации. Выявление в объекте функционально самостоятельных составных частей (третий принцип) предполагает выяснение того, кто и что делает в организации.
Методология IDEF 0 используется для создания функциональной модели, которая является структурированным изображением функции производственной системы, а также содержит информацию об объектах, связывающих эти функции. Результатом применения IDEF 0 -методологии является функциональная модель, которая состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга. Диаграммы являются главными компонентами модели. Основными элементами диаграмм являются функциональные блоки и дуги, которые представляются соответственно прямоугольниками и стрелками. Блоки на диаграмме представляют функции, которые показывают, что должно выполняться, и поэтому имена функций содержат глагольный оборот. Каждый блок имеет свой номер, который размещается обычно в нижнем правом углу. Дуги представляют собой материальные объекты или информацию, в которых блоки нуждаются или их производят. Каждая дуга имеет метку - имя, которое записывается над дугой в виде оборота существительного. Дуги могут разветвляться и соединяться, образовывать обратные связи, итерации.
В IDEF 0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной – функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в IDEF 0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна быть отвечать на следующие вопросы: Почему этот процесс должен быть замоделирован? Что должна показывать модель? Что может получить читатель? Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений» «Описать функциональность предприятия с целью написания спецификаций информационной системы » «Идентифицировать роли и ответственность служащих для написания должностных инструкций» Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. IDEFO-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.
В IDEF 0 используется четыре типа дуг: входные (INPUT), управления (CONTROL), выходные (OUTPUT) и механизма (MECHANIZM), представляющие собой ICOM-объекты. Входы (INPUT) - это материалы или информация, которые используются или преобразуются функциональным блоком для получения результата. Они входят в функциональный блок слева. Допускается отсутствие входных дуг. Управление (CONTROL) - это правила, стратегии, процедуры или стандарты, которыми руководствуется функциональный блок. Дуги управления входят в функциональный блок сверху. Должна быть обязательно хотя бы одна дуга.
Механизмы (MECHANIZM) - это ресурсы, которые выполняют работу в функциональном блоке (персонал, станки, транспорт и т. д. ). Эти дуги входят в функциональный блок снизу. По усмотрению системного аналитика дуги механизма могут не отображаться на диаграмме. Дуги механизмов или управления могут быть входами других блоков. Выходы (OUTPUT) - это данные, которые получаются в результате выполнения функции или могут быть материалом или информацией, которая производится функциональным блоком. Выходные дуги выходят справа от функционального блока. Обязательно должна быть хотя бы одна дуга, иначе функциональный блок не имеет смысла. Контекстная диаграмма является верхним уровнем иерархии функциональной модели и представляет собой наиболее обобщенную схему функционирования предметной области.
Контекстная диаграмма методологии IDEF 0 функциональной модели управления городом
Для успешного решения данных и многих других вопросов, современный рынок программного обеспечения предлагает различ-ные CASE-средства. Одним из таких средств является продукт компании Computer Associates – BPWin. BPwin - система моделирования бизнес-процессов, мощное средство системного анализа деловой и производственной активности, позволяющее отслеживать соответствие структуры бизнеса, документооборота, финансовых потоков жестким и динамичным требованиям современной экономики. Система BPwin поможет повысить конкурентоспособность, оптимизировать процессы управления. BPwin - это незаменимый инструмент менеджеров и бизнес-аналитиков становится в руках системных аналитиков и разработчиков и мощным средством моделирования процессов при создании корпоративных информационных систем. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок.
Основные характеристики BPwin • Развитая методология функционального моделирования на основе IDEF 0 • Мощные редакторы для описания операций, связей и вычисления затрат на выполнение работ • Иерархическая структура диаграмм, облегчающая последовательное уточнение элементов модели • Контекстные диаграммы для описания границ системы, области действия, назначения объектов • Декомпозиционные диаграммы для описания особенностей взаимодействия различных процессов • Расширенные возможности по поддержанию ссылочной целостности • Поддержка методологии IDEF 3 • Экспорт моделей в средства имитационного моделирования • Интеграция и связь со средством проектирования баз данных ERwin (методология IDEF 1 X) • Поддержка свойств, определяемых пользователем. Описание моделей может быть расширено за счет свойств, определяемых пользователем, включая мультимедийные документы. • Удобный интерфейс пользователя, позволяющий легко переходить с одной диаграммы на другую простым перемещением по "дереву" проводника. • Автоматическая поддержка изменения размеров. BPwin поддерживает автоматическую настройку размеров диаграмм и возможность изменения масштабов изображения моделей.
Интерфейс BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели, который по организации очень похож на привычный всем проводник Windows. Работы IDEF 0 показываются зеленым цветом, DFD — желтым и IDEF 3 — синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer. Функциональность панели инструментов доступна из основного меню Bpwin. При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория Model. Mart, внести имя модели и выбрать методологию, в которой будет построена модель.
Описание основных нотаций BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. BPwin поддерживает три таких методологии: IDEF 0, DFD и IDEF 3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения: • С точки зрения функциональности системы. В рамках методологии IDEF 0 (Integration Definition for Function Modeling) бизнеспроцесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой. • С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF 0, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.
• С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF 3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF 3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса. Диаграммы IDEF 0 предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющими факторами и какие ресурсы для этого необходимы. Нотация IDEF 0 позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия. Диаграммы потока данных DFD используются для описания документооборота и обработки информации. Для описания логики взаимодействия информационных потоков более подходит IDEF 3, называемая нотацией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.
Основной из трех методологий, поддерживаемых BPwin, является IDEF 0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF 0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF 0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF 0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Резуль-татом применения IDEF 0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм.
Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF 0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов: Стрелки входа (входят в левую грань работы) — изображают данные или объекты, изменяемые в ходе выполнения работы. Стрелки управления (входят в верхнюю грань работы) — изображают правила и ограничения, согласно которым выполняется работа. Стрелки выхода (выходят из правой грани работы) — изображают данные или объекты, появляющиеся в результате выполнения работы. Стрелки механизма (входят в нижнюю грань работы) — изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…) Стрелки вызова (выходят из нижней грани работы) — изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.
Все работы и стрелки должны быть именованы. Первая диаграмма в иерархии диаграмм IDEF 0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными. В контекст входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом. проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).
Применение универсальных графических языков бизнес-моделирования IDEF 0, IDEF 3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.
Для декомпозиции функционального блока необходимо после его выделения щелкнуть по ярлыку в панели инструментов. В появившемся диалоговом окне следует выбрать методологию, в нотации которой будет выполняться его декомпозиция и количество блоков декомпозиции.
IDEF 0 -диаграмма второго уровня иерархии
Дерево узлов
Стоимостный анализ (Activity Based Costing, ABC) BPwin предоставляет аналитику инструмент для оценки модели – стоимостный анализ, основанный на работах (Activity Based Costing, ABC), с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений и др.
При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Затем описываются центры затрат (cost centers). Каждому центру затрат следует дать подробное описание в окне Definition. Для отдельной модели задается один набор функциональных центров. Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх. При построении модели «TO BE» следует также максимально удовлетворять требованиям процессного подхода к управлению: правильно определять состав функций каждого бизнес-процесса на нижних уровнях иерархии. Выходом каждого бизнес-процесса должен воспользоваться хотя бы один клиент, необходимо максимально сократить количество подразделений, поскольку большинство проблем возникает на границах между подразделениями организации. Для этого надо либо заранее описать действия на всех этапах бизнес-процесса, либо изменить структуру подразделений, либо изменить поток работ.
Основным инструментом при построении модели «TO BE» является Business process reengineering (BPR) - это радикальный способ ре -конструкции управления деятельностью предприятия. Цель BPR - добиться более гибкой реакции предприятия на изменения требований потребителей или на прогноз таких изменений при снижении затрат всех видов. Реинжиниринг изменяет реконструируемые бизнес-процессы следующим образом. 1. Несколько рабочих процедур объединяются в одну. Для перепроектированных процессов характерно отсутствие технологии «конвейер» , в рамках которой на каждом рабочем месте выполняются простые задания или рабочие процедуры. Теперь они интегрируются в одну – происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс. Горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз. 2. Исполнители принимают самостоятельные решения. В ходе реинжиниринга осуществляется не только горизонтальное, но и вертикальное сжатие процессов. Это происходит за счет самостоятельного принятия решения исполнителем в тех случаях, когда при традиционной организации работ он должен был обращаться к управленческой иерархии. Наделение сотрудников большими полномочиями и увеличение роли каждого из них в работе приводит к значительному повышению их отдачи.
3. Шаги процесса выполняются в естественном порядке. Реинжиниринг процессов освобождает от линейного упорядочивания рабочих процедур, позволяя распараллеливать процессы там, где это возможно. 4. Процессы имеют различные варианты исполнения. Новые процессы, в отличие от традиционных, ясны и просты – каждый вариант ориентирован только на одну соответствующую ему ситуацию. 5. Работа выполняется в том месте, где это целесообразно. В традиционных компаниях она организуется по функциональным подразделениям: отдел заказов, транспортный отдел и т. п. Реинжиниринг распределяет работу между границами подразделений, устраняя излишнюю интеграцию, что приводит к повышению эффективности процесса в целом. 6. Уменьшается количество проверок и управляющих воздействий. Задача реинжиниринга – сократить их до экономически целесообразного уровня. Вместо проверки каждого из выполняемых заданий перепроектированный процесс часто агрегирует эти задания и осуществляет проверки и управляющие воздействия в отложенном режиме, что заметно сокращает время и стоимость процессов. 7. Минимизируется количество согласований. Задача реинжиниринга состоит в минимизации согласований путем сокращения внешних точек контакта. Речь идет о стирании граней между функциональными подразделениями.
8. «Уполномоченный» менеджер обеспечивает единую точку кон-такта. Механизм «уполномоченного» менеджера применяется в тех случаях, когда шаги процесса либо сложны, либо распределены таким образом, что их не удается объединить силами небольшой команды. «Уполномоченный» менеджер играет роль буфера между сложным процессом и заказчиком. 9. Преобладает смешанный централизованно-децентрализованный подход. Современные технологии позволяют действовать полностью автономно на уровне подразделений, сохраняя при этом возможность, пользоваться централизованными данными Задачи, которые приходится решать в ходе реинжиниринга, обычно характеризуются высокой степенью сложности и большой ответственностью.
Модели AS-IS и TO-BE. Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализе преимуществ новых бизнес-процессов и степени изменения существующей организации бизнеса. Анализ недостатков и «узких мест» начинают с построения модели AS-IS, т. е. модели существующей организации работ. Модель AS-IS может строиться на основе изучения документации, (должностных инструкций, положений о предприятии, приказов, отчетов и т. п. ), анкетирования и опроса служащих предприятия и т. п. Полученная модель AS-IS служит для выявления неуправляемых работ, работ необеспеченных ресурсами, ненужных и неэффективных работ и других недостатков в организации деятельности предприятия. Исправление недостатков приводит к созданию модели TO-BE – модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей TO-BE, среди которых определяют наилучший вариант.
Скачать презентацию МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ Реинжениринг бизнес-процессов Для успешного построения
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ.ppt