- •Методы проведения обследования.
- •Понятие информационного процесса.
- •Понятие и классификация case-средств. Особенности case-средств.
- •Методы сбора данных при обследовании.
- •Измерение количества информации.
- •Особенности case-средства Erwin. Области применения, среда.
- •Основные характеристики
- •Стандарты графического описания бп.
- •Критерии ценности информации и минимума эвристик.
- •Современные методы моделирования ис. Особенности, области применения.
- •Анализ модели бизнес-процесса.
- •Аксиома теории управления.
- •Основные принципы структурной методологии проектирования.
- •Сущность структурного подхода
- •Методы проектирования нового бизнес-процесса.
- •Быстрый анализ
- •Бенчмаркинг
- •Перепроектирование
- •Реинжиниринг
- •Принцип необходимого разнообразия Эшби.
- •Понятие методологии, методов и технологии моделирования ис. Требования, предъявляемые к современным технологиям моделирования ис. Визуальное моделирование
- •Методы структурного анализа и проектирования по
- •Методы объектно-ориентированного анализа и проектирования по. Язык uml
- •Внедрение нового бизнес-процесса.
- •Документарное оформление нового бизнес-процесса.
- •1 1 Имеет
- •Проблемы при внедрении новых бизнес-процессов.
- •Понятие функционально-стоимостного анализа.
- •Понятие сложной системы. Неоднородные связи в системе.
- •Понятие связи и типы связей. Степень связи. Типы связей и отражение связей в среде Erwin. Окно «Свойство связи».
- •Практический подход к проведению фса.
- •Система сбалансированных показателей.
- •Реинжиниринг и реструктуризация предприятия.
- •Существо модели
- •Обратный инжиниринг.
- •Сферы применения обратной разработки Электроника
- •Программное обеспечение
- •Базы данных
- •Промышленность
- •Военная промышленность
- •Для анализа исходного кода
- •Нежелательные элементы при проведении анализа на этапе логического проектирования.
- •Условия успешного проведения инжиниринга.
- •Принцип Парето. Множество Парето.
- •Понятие ограничения целостности. Типы требований по ограничению целостности. Стратегии при ограничении ссылочной целостности. Назначение стратегии в среде Erwin.
- •Типичные ошибки при проведении реинжиниринга.
- •Этапы проектирования базы данных. Цель и виды работ на этапе концептуального проектирования базы данных.
- •Концепция врм.
- •Критерии оценки решений Аналитики Gartner выделяют как основные следующие критерии оценки bpm-решений:
- •Цели внедрения bpm Концепция предполагает внедрение bpm-решения для достижения следующих целей:
- •Основные участники управления бизнес-процессами
- •Оценивание сложный систем в условиях определенности.
- •Этапы проектирования базы данных. Цель и виды работ на этапе логического проектирования базы данных.
- •Цели внедрения концепции врм.
- •Критерии оценки решений
- •Цели внедрения bpm
- •Этапы проектирования базы данных. Цель и виды работ на этапе физического проектирования базы данных. Этапы проектирования данных
Стандарты графического описания бп.
Стандарты графического описания БП
В настоящее время широко используются и пользуются большой популярностью несколько стандартов моделирования бизнес-процессов:
· Семейство стандартов IDEF (в частности, IDEF0, DFD, IDEF3);
· Семейство стандартов ARIS (в частности, нотация eEPC);
· Семейство стандартов UML (Usecase diagram, activity diagram).
Каждое из этих семейств стандартов представляет собой определенную методологию, и реализовано рядом программных продуктов (CASE-средств). Наиболее популярное ПО, реализующее ту или иную методологию, представлено в таблице ниже.
Таблица 1
|
|
|
Методология |
Программное обеспечение |
|
IDEF |
AllFussion Business Modeler (BPwin), MS Visio |
|
ARIS |
ARIS Toolset |
|
UML |
Rational Rose, MS Visio, ARIS Toolset |
|
|
|
|
Разумеется, в таблице представлены далеко не все программные продукты, которые реализуют ту или иную нотацию описания. На самом деле их значительно больше.
Кроме этого, на практике часто встречаются модели БП, подготовленные с использованием шаблона Audit diagram в программе MS Visio.
Семейство стандартов IDEF
Стандарт моделирования бизнес-процессов IDEF0 был принят в качестве такового в 1981 году. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 60-х годов, в частности, Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM - Integrated Computer Aided Manufacturing.
Семейство стандартов IDEF включает в себя ряд графических нотаций, которые могут быть использованы для моделирования бизнес-процессов:
· IDEF0 - стандарт описания бизнес-процессов;
· DFD - диаграмма потока данных (DataFlow Diagram);
· IDEF3 - стандарт моделирования потока работ (workflow).
Семейство стандартов ARIS
ARIS расшифровывается как Arhitecture of Integrated Information Systems (архитектура интегрированных информационных систем). В методологию ARIS входит пять типов представлений моделей:
· Организационные модели, описывающие иерархическую структуру системы: иерархию организационных подразделений, должностей, полномочий конкретных лиц и т.д.;
· Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;
· Информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
· Модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;
· Модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.
В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML (Unified Modeling Language).
Число поддерживаемых ARIS нотаций довольно велико, и описывать каждую из них не целесообразно. Имеет смысл дать основы нотации eEPC, как наиболее, на наш взгляд, применимой для моделирования бизнес-процессов.
Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице ниже приводятся основные используемые в рамках нотации графические объекты.
Таблица 2
|
|
|
|
Наименование |
Описание |
Графическое представление |
|
Функция |
Объект «Функция» служит для описания функций (процедур, работ), выполняемых подразделениями/сотрудниками предприятия. |
|
|
Событие |
Объект «Событие» служит для описания реальных состояний системы, влияющих и управляющих выполнением функций |
|
|
Организационная единица |
Объект, отражающий различные организационные звенья предприятия (например, управление или отдел) |
|
|
Документ |
Объект, отражающий реальные носители информации, например бумажный документ |
|
|
Прикладная система |
Объект отражает реальную прикладную систему, используемую в рамках технологии выполнения функции |
|
|
Кластер информации |
Объект характеризует данные, как набор сущностей и связей между ними. Используется для создания моделей данных |
|
|
Стрелка связи между объектами |
Объект описывает тип отношений между другими объектами, например - активацию выполнения функции некоторым событием |
|
|
Логическое «И» |
Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
|
|
Логическое «ИЛИ» |
Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
|
|
Логическое исключающее «ИЛИ» |
Логический оператор, определяющий связи между событиями и функциями в рамках процесса. Позволяет описать ветвление процесса |
|
|
|
|
|
|
В таблице указаны только основные виды пиктограмм, применяемые в данной нотации. Использование большего числа элементов допустимо, но делает модель плохо читаемой.
На рисунке представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
На рисунке видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
· Каждая функция должна быть инициирована событием и должна завершаться событием;
· В каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции.
Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.
На рисунке ниже показано применение различных объектов ARIS при создании модели бизнес-процесса.
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количество т.н. пользовательских атрибутов.
Из рисунка видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).
Семейство стандартов UML
Аббревиатура UML расшифровывается как Unified Modeling Language (унифицированный язык моделирования).
UML предназначен в первую очередь для быстрого проектирования и разработки программных продуктов, и описание бизнес-процессов с его использованием целесообразно делать, если в конечном итоге требуется разработать корпоративную информационную систему, которая бы отражала особенности протекания бизнес-процессов на предприятии заказчика.
Язык UML был создан в компании Rational одним из ведущих идеологов объектно - ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson) в 1994 году.
UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).
Диаграмма прецедентов служит для моделирования типичных сценариев работы с системой.
Диаграмма прецедентов состоит из прецедентов (use-case) - типичных взаимодействий между пользователем и компьютерной системой - и субъектов (actor) - ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).
Диаграмма действий имеет много общего с блок-схемой, но на ней можно также показывать параллельные процессы. Диаграмма состоит из действий, - некоторых задач, которые должны быть выполнены человеком или компьютером - условных и безусловных переходов, и распараллеливания.
К вопросу о выборе нотации моделирования
Среди специалистов в области моделирования бизнес-процессов часто возникают споры - какую методологию лучше использовать для создания моделей? Каждая из этих методологий имеет свои достоинства и недостатки, какие-то моменты удобнее и эффективнее отражать в той или иной нотации. Однако на наш взгляд однозначного ответа на этот вопрос нет. Выбор той или иной методологии зависит в первую очередь от целей и задач проекта реинжиниринга БП. При этом надо учитывать также степень владения командой аналитиков той или иной методологией, наличие соответствующего ПО, да и просто личные предпочтения руководства проекта.
В любом случае важно, чтобы каждый специалист понимал основные принципы каждой из методологий и умел читать диаграммы, подготовленные с ее использованием.
