Процесс описания и анализа бизнес-процессов
Для начала нам нужно понять, чего мы хотим получить в результате выполняемого процесса — мы ставим цель, причем наверняка цель будет одной из списка задач, которые наше предприятие выполняет наиболее часто.
Затем необходимо структуризировать цели — делаем мы это в несколько шагов: детализируем поставленные цели, выбираем приоритеты для целей, если мы поставили их несколько, дорабатываем цели и разрабатываем ТЗ, а затем ждем утверждения руководством нашего ТЗ.
Третьим шагом для каждой из наших поставленных целей формулируем KPI (Ключевой Показатель Эффективности), который позволяет установить необходимую планку по нашему процессу, а затем позволит отслеживать фактические значения, которые получаются в результате бизнес-процесса.
Четвертый шаг — пожалуй, самый трудоемкий и нудный шаг: нужно выполнить полное описание бизнес процесса и вот основные шаги для этого:
1. Определяем внешних клиентов нашей организации
2. Составляем перечень основных бизнес-процессов, которые формируют внешние выходы — именно этот перечень будет показывать добавленную ценность
3. Параллельно с предыдущим пунктом нужно составить перечень бизнес-процессов верхнего уровня. Именно на этом этапе можно начать готовить нормативные документы.
4. Проводим ранжирование получившихся процессов с целью выбора наиболее приоритетных для достижения поставленных целей
5. Описываем каждый из приоритетных бизнес-процессов на нижнем уровне
6. Строим организационную структуру организации и распределяем ответственных за каждый из бизнес-процессов. В результате можно будет построить матрицу распределения ответственности, благодаря которой можно определить наличие дублирования или отсутствия ответственности.
7. В зависимости от нашей конечной цели описания нужно привести детальное описание каждого из процессов в различных интерпретациях (IDEF, EPC, CMK, BPMN)
Пятый шаг — непосредственный анализ бизнес-процесса. Выделяют качественный и количественный анализ бизнес-процесса.
Качественный анализ бывает на основе субъективных оценок (такой анализ имеет 3 оценки — SWOT-анализ процесса, который выявляет сильные и слабые стороны процесса, возможности для его улучшения и возможные угрозы ухудшения, анализ проблем процесса, который заключается в выявлении проблемных мест процесса при помощи графической схемы (ветви, протяженность, зоны ответственности), а так же ранжирование процессов, которое распределяет процессы по уровням важности, наличии проблемных зон и наличию барьеров для изменений), так же бывает визуальный качественный анализ графических схем процесса, который выполняется в 3 шага: производят анализ входов и выходов процесса, анализируют функции и анализируют различные ресурсы, ну и анализ состояния процесса по отношению к некоторым требованиям: анализируем состояние процесса по отношению к стандартам CMK ISO, PDCA и по отношению к нормативным актам.
Количественный анализ характеризуется по 6 пунктам:
1. Выполняется анализ эффективности процесса
2. Анализируются показатели процесса
3. Анализируется удовлетворенность клиентов процесса
4. Производится сравнительный анализ процессов
5. Производится имитационное моделирование процесса, а так же функционально-стоимостной анализ
6. В качестве заключения производится ABC-анализ процесса.
Таким образом получается, что анализ бизнес процесса может выполняться с разных сторон, и следует помнить, что каждая сторона имеет собственный набор характеристик, которые и являются планом для анализа процесса.
Методы разработки функциональных моделей бизнес-процессов
В основе различных методов моделирования процессов предприятия могут быть, как структурные, так и объектно-ориентированные подходы к моделированию. В своей работе я хотел бы осветить наиболее известные и часто используемые методы, такие как: SADT, IDEF, DFD, UML и ARIS.
Метод моделирования: SADT
Метод структурного анализа и проектирования (Structured Anal- ysis and Design Technique, SADT) был создан еще в конце 1960-х годов. SADT очень полезен в описании большого массива процессов сложных систем и имеет достаточно широкую область применения. В виде оконченного пакета SADT появился только к 1975 году и на тот момент использовался уже в 50 различных компаниях. На тот момент SADT имел крайний успех: рынок впервые увидел полностью рабочую среду, предназначенную для описания процессов и системы в целом, причем среда SADT имела исключительное преимущество, ведь она была основана на концепции моделирования систем.
Метод моделирования: IDEF
Метод IDEF является продолжением SADT и позволяет анализировать деятельность уже в разных разрезах. Семейство IDEF подразделяется на несколько частей:
1. IDEF0 — система представляется в виде некоторых, связанных между собой блоков
2. IDEF1 — методология, предназначенная для построения моделей информационных потоков, находящихся внутри системы
3. IDEF1X — используется для создания моделей различных реляционных баз данных
4. IDEF2 — используется чтобы создавать динамические модели
5. IDEF3 — комплект для ведения документации процессов
6. IDEF4 — продвинутая методология, позволяющая строить наглядно структуру и связи в системе
7. IDEF5 —исследует систему при помощи набора правил и словарей, а затем выдает тезисы о состоянии системы на основе этих правил
8. IDEF6 — позволяет предотвратить ошибки во взаимосвязях системы при изменении её структуры
9. IDEF7 — выполняет с системой аудиторские операции
10. IDEF8 — пакет для разработки графических интерфейсов
11. IDEF9 —анализирует поставленные правила и исследует их влияние на окончательные решения
12. IDEF10 — позволяет моделировать архитектуру текущих выполняемых процессов и отслуживать выполнение этих процессов
13. IDEF11 — используется для создания моделей артефактов
14. IDEF12 — позволяет создавать организационные модели
15. IDEF14 — используется для моделирования сетей
Метод моделирования: DFD
DFD представляет собой, что следует из названия (Data Flow Diagramming) диаграмму потоков данных — это некоторый иерархически упорядоченный набор процессов, который связаны между собой различными потоками данных. Такие диаграммы, в интерпретации этого метода показывают, каким образом происходит обработка информации каждым иха процессов, каким образом процессы связаны друг с другом и каким образом их связь позволяет работать системе, как одно целое и как эта система обрабатывает данные, которые в нее вносятся. Поток данных, это в первую очередь механизм, который используется для создания моделей передачи информации от одного участника процесса к другому. Потоки данных применяются в качестве дополнения к модели IDEF0 для того, чтобы наглядно показать документооборот в системе, при помощи DFD можно смоделировать процесс движения информации от одного блока к другому, провести определение инжиниринга системы. На схемах DFD отображаются различные функции процесса, информация, как входящая, так и исходящая, внешние бизнес-процессы, а так же точки разрыва в случае, если процесс переходит на другие страницы.
Диаграммы DFD могут быть построены в несколько этапов, используя структурный анализ: строим физическую модель, преобразуем её в логическую модель, которая показывает текущие требования к системе, строим модель, которая будет отображать требования к системе, которую мы будем строить, ну и наконец строим физическую модель, на основе которой собственно и строим новую систему.
Основные объекты, используемые в методике DFD: блоки (работы), которые отображают все процессы изменения и обработки информации, стрелки, показывающие информационные потоки, хранилища данных, именно те данные, к которым осуществляется доступ и различные внешние ссылки, которые отображают различные объекты с которыми взаимодействует система. Стоит отметить, что именно работы DFD — ключевое звено во всей цепочке этой методики, ведь именно работы являются графическим отображением различных операций по преобразованию или обработке данных.
DFD-диаграммы создают модели функций, которые нужно выполнить системы, но при этом практически не показывают отношения между данными и поведение системы в разное время, поэтому для этого используют другие типы диаграмм, такие как сущность-связь и диаграммы переходов состояний.
По синтаксису DFD каждому элементу данных должно быть присвоено имя, формат и тип данных, потому что именно эту информацию будет использовать методика построения модели сущность-связь.
Метод моделирования UML
UML — Унифицированный язык моделирования (Unified Modeling Language), является общецелевым языком для визуального моделирования, разработанный для проектирования, визуализации, документирования и спецификации компонентов бизнес-процессов и программного обеспечения.
UML принципиально отличается от от таких средств моделирования, как IDEF0, IDEF1X, IDEF3, DFD, которые сильно типизированы. UML же содержит в себе специальные механизмы, которые позволяют расширять определенный язык моделирования к каким-либо определенным требованиям разработчика и благодаря этому освобождают его от изменения метамодели.
Описание языка UML состоит из двух частей, которые взаимодействуют между собой — семантики и нотации языка UML. Под семантикой в данном случае стоит понимать некоторые метамодели, которые позволяют определить синтаксис и понятия для создания моделей на UML. Нотации же играют роль графического «сопровождающего», который семантику визуально представляет пользователю.
Определяют семантику для двух видов моделей: статических (описывают структуру компонентов системы) и динамических (описывают функционирование объектов системы).
Диаграммы UML бывают 10 видов:
1. Диаграммы вариантов использования
2. Диаграммы классов
3. Диаграммы поведения
4. Диаграммы состояния
5. Диаграммы деятельности
6. Диаграммы взаимодействия
7. Диаграммы реализации
8. Диаграммы компонентов
9. Диаграммы кооперации
10. Диаграммы развертывания
Для построения этих диаграмм используется концепция RUP (Rational Unified Process). Суть концепции построения всех этих диаграмм заключается в последовательном разбиении процесса проектирования и анализа на отдельные части, в каждой из которых происходит разработка соответствующих типов диаграмм.
Порядок построения модели UML: выполняем логическое представление структуры системы, логически представляем модель поведения и физически представляем модели системы. В результате процесса RUP должны получится последовательные диаграммы на языке UML.
Основные элементы UML — связи (линии на плоскости), графические символы (находятся рядом с визуальными элементами диаграммы) и текст, который содержится внутри различных геометрических фигур.
Метод моделированияARIS
Методология построения интегрированных информационных систем (Ar- chitecture of Integrated Information Systems) реализует различные принципы структурного анализа и позволяет определить и показать в моделях все компоненты организации, процессы, продукцию, информацию и найти взаимосвязи между всеми этими компонентами. Благодаря тому, что в методологии ARIS организация рассматривается с 5 точек зрения (функциональной,организационной, продуктов и услуг, обрабатываемых данных, структуры бизнес-процессов) при помощи ARIS можно без особого труда собрать и отразить всю деятельность, которая происходит на фирме в виде наглядных графических моделей, которые могут быть использованы для анализа и последующей выработки некоторых решений по изменениям в организации.
Источники информации
1. Основные подходы к управлению организацией
Самуйлов К.Е., Серебренникова Н.В., Чукарин А.В., Яркина Н.В. Основы формальных методов описания бизнес-процессов: Учеб. пособие. – М.: РУДН, 2008. – 130 с.: ил. (дата обращения: 11.07.2016)
2. Понятие бизнес-процесса и бизнес-модели, процесс описания и анализа бизнес-процессов
Тельнов Ю.В. Реинжиниринг бизнес-процессов (Учебное пособие). / Московский международный институт эконометрики, информатики, финансов и права. - М., 2002. – 99с.(дата обращения: 11.07.2016)
3. Методы разработки функциональных моделей бизнес-процессов
Кулябов, Д.С. Введение в формальные методы описания процессов / Д.С. Кулябов, А.В. Королькова –М.: РУДН, 2008. –202 с. (дата обращения: 12.07.2016)
Дата добавления: 2018-08-06; просмотров: 221; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!