Моделирование бизнес процессов его назначение и эффективность. Цели и задачи моделирования бизнес-процессов. Побудительные причины моделирования процессов

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

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

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

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

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

Business Studio Разработчик «ГК «Современные технологии управления». Наиболее популярный инструментов бизнес- моделирования в России и странах СНГ. На начало 2012 года продукт использовало более 1000 организаций. Используется в учебном процессе более 100 ВУЗов и бизнес-школ России и стран СНГ.

Business Studio Базируется на методологии SADT (Structured Analysis & Design Technique) Нотация моделирования бизнес-процессов IDEF0. Блок-схемы (Process Flowchart, Cross Functional Flowchart). EPC (Event Driven Process Chain). Сбалансированная система показателей Нортона и Каплана. В продукт интегрированы типовые структуры бизнес-процессов – референтные модели для типичных процессов организаций различных сфер деятельности.

Business Studio Формализация стратегии организации и контроль достижения стратегических целей Проектирование и оптимизация бизнес-процессов Проектирование организационной структуры и штатного расписания Формирование регламентирующей документации (MS Office, HTML) Поддержка внедрения системы менеджмента качества по стандартам ISO Формирование Технического задания на создание/развитие ИС

Business Studio позволяет: Создавать дерево целей компании. Разрабатывать карту стратегических целей согласно Сбалансированной системе показателей (ССП, BSC – Balanced Scorecard). Конкретные перспективы задаются пользователем. Разрабатывать карту стратегических целей с отображение на ней показателей и степени достижения целей.

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

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

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

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

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

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

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

ARIS Модели - диаграммы, элементами которых являются объекты - "функция", "событие", "структурное подразделение", "документ" и т.п. Между объектами устанавливаются связи Объект имеет набор атрибутов с его описанием Атрибуты используются при имитационном моделировании или для проведения стоимостного анализа.

Основная бизнес-модель ARIS eEPC (extended Event Driven Process Chain) - расширенная модель цепочки процессов, управляемых событиями). Расширяет возможности IDEF0, IDEF3 и DFD Недостаток: при большом числе объектов и связей плохо читаема Бизнес-процесс - поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур не отражается. Возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Для получения информации о длительности процессов нужны другие инструменты описания (например, графики Ганта)

Метод Ericsson-Penker Ресурсы - объекты, используемые или участвующие в бизнес-процессах (люди, материалы, информация или продукты). Процессы - виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес- правилами. Цели - назначение бизнес-процессов. Могут быть разбиты на подцели и соотнесены с отдельными процессами. Бизнес-правила - условия или ограничения выполнения процессов (функциональные, поведенческие или структурные).

Метод Ericsson-Penker Представления бизнес-модели концептуальное представление - структура целей и проблем; представление процессов - взаимодействие между процессами и ресурсами (в виде набора диаграмм деятельности); структурное представление - структура организации и ресурсов (в виде диаграмм классов); представление поведения - поведение отдельных ресурсов и детализация процессов (в виде диаграмм деятельности, состояний и взаимодействия).

Rational Unified Process Bиды моделей модели бизнес-процессов (Business Use Case Model); модели бизнес-анализа (Business Analysis Model). Расширение модели вариантов использования UML за счет введения набора стереотипов Business Actor (действующее лицо бизнес-процессов) - роль, внешняя по отношению к бизнес-процессам организации. Business Use Case (вариант использования с точки зрения бизнес-процессов) - описание последовательности действий (потока событий) в рамках бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.

Rational Unified Process Для каждого Business Use Case строится объектная модель, описывающая реализацию бизнес- процесса в терминах взаимодействующих бизнес- объектов, принадлежащих к двум классам - Business Worker и Business Entity. Business Worker (исполнитель) - абстракция исполнителя, выполняющего действия в рамках бизнес-процесса. Исполнители участвуют в сценариев Business Use Case и манипулируют сущностями. Business Entity (сущность) является объектом различных действий со стороны исполнителей.

Rational Unified Process Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. (помогают определить в модели обязанности каждого исполнителя в виде набора его операций) Диаграммы деятельности, описывающие взаимосвязи между сценариями одного или различных Business Use Case. Диаграммы состояний, описывающие поведение отдельных бизнес-объектов

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

Casewise Corporate Modeler Suite инструмент для моделирования и анализа бизнес- процессов, документирования и оптимизации бизнеса поддерживает широкий спектр нотации, подходов и методологий моделирования и бизнес-процессов предоставляет набор разнородных типов объектов, соединение которых позволяет представить любые бизнес-ситуации в легком для понимания виде предлагает большое количество готовых моделей и расширений, которые можно использовать как основу для моделирования. позволяет переносить модели в различные форматы, включая HTML и MS Word, а также редактировать модели через браузер в реальном режиме времени

Столбцы – основные аспекты моделирования: Мотивация («Почему?»); Процессы («Как?»); Люди («Кто?»); Местоположения («Где?»); Данные («Что?»); Время («Когда?»). Строки – уровни моделирования: Бизнеса, Организации, Систем, Технологий, Деталей К каждой ячейке прилагаются стандартные шаблоны и примеры диаграмм, которые можно использовать как основа модели с последующим изменением с учетом специфики деятельности организации Матрица Захмана

Строки матрицы Захмана Уровень бизнеса - описывает объекты, с которыми имеют дело руководители компании: стратегия, миссия компании, ключевые направления деятельности компании, подразделения, ключевые данные, события; Уровень организации – описывает объекты, детализирующие уровень бизнеса. Здесь не уделяется особого внимания системным или физическим ограничениям; Уровень систем – описывает работу организации с учетом ограничений, накладываемых бизнесом и ИТ. Этот уровень показывает, как в дальнейшем модели уровня организации будут воплощены в действующие системы; Уровень технологий - детально описывает применяемые в организации технологии; Уровень деталей – описывает такие объекты, как сети, люди, компьютерные программы, базы данных.

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

Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области и внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика - он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке требований, анализе пропущенных требований и пр.

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

Что бы решить этот вопрос надо определить цели и задачи самого бизнес-анализа, как этапа построения КИС.

С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) - принципиально разные процессы.

АПО преследует классические цели создания модели: налицо объект (автоматизируемое предприятие или организационная система Организационная система - ОС, ОС) и задача аналитика - отразить этот объект в создаваемой модели с требуемой степенью точности схема процесса разработки представлена на рисунке 3.

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

ОС->М(ОС)->М(АИС)->М" (АИС)->М"" (АИС)->М""" (АИС)->АИС

Проведя анализ организационной системы можно создать модель М(ОС). Это - модель бизнес-анализа (проблемной области).

Анализ проблемной области позволяет вычленить:

• - с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,
• - с другой - устройство предметной области (в начале - на уровне концептуальной модели),
• - с третьей - требования к информации и ее обработке.

Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для выявления функциональных требований к системе. Остальная, собранная на этапе АПО, информация служит для поиска нефункциональных требований. В результате получаем модель АТ, как первое приближение модели АИС, М(АИС).

Углубленный анализ и проектирование, формируют, соответственно, аналитическую модель М" (АИС), проектную модель М"" (АИС) и модель реализации М""" (АИС).

Модель уровня реализации позволяет объединить собственно АИС, как совокупность программных, информационных, организационных факторов.

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

Процесс разработки АИС можно отобразить в виде диаграмм в программе BPwin. На рисунке 4 отображены этапы разработки АИС. Диаграммы верхнего уровня - Создание программы (рис. 4) состоит из двух диаграмм второго уровня Разработка и Тестирование.

Разработка состоит из Построения каркаса программы и Создания тела программы.

Третий уровень Построение каркаса программы

Четвертый уровень Создание тела программы.

Пятый уровень Тестирование

Рассмотрев бизнес-моделирование, перейдем к бизнес-процессам. Изучение методологии бизнес-процессов приводит к возможности их деления на три категории:

• - модели, преследующие цель анализа и улучшения организационной системы (например, SWOT, VCM, BPR, CPI/TQM/ISO9000, BSC),
• - модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
• - модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

Наиболее развитая модель описания проблемной области предлагается в методологии ARIS. Архитектура ARIS выделяет в организации следующие подсистемы:

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

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

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

Для решения задач функционального моделирования, то есть описания существующих процессов или процессов, которые мы стремимся получить в идеале, широко используется методология структурного анализа и проектирования технология SADT Structured Analysis and Design Technigue.

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

В дальнейшем общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Затем каждая подфункция декомпозируется на более мелкие - и так далее до достижения необходимой детализации описания. На рис. 2 показано дерево функций, называемое деревом узлов функциональной модели.

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

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

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

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

Внешняя сущность (рис. 10а) - объект (например, поставщик, клиент и т.д.), с которым взаимодействует данный работник;

Накопитель (рис. 10б) - любое хранилище данных;

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

Поток данных (рис. 10г) - характеризует связь (над стрелкой рекомендуется указать наименование конкретного документа).

Анализ данных заключается в следующем:

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

b. Определяется структура данных: название(имя), тип, свойства;

c. Формирование информационных объектов (ИО);

d. Установление связей между информационными объектами.

Каждый информационный объект образует совокупность логически связанных реквизитов. В таблице 1 приведен пример ИО:

Таблица 1. ИО «Журнал учета организаций-клиентов»

Состав реквизитов определяет структуру ИО. Каждый ИО имеет уникальное имя.

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

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

На рисунке 12 приведен пример ИЛМ

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

Анализ программ бизнес моделирования позволяет сделать вывод, что для ведения бизнес процессов моделирования, BPwin является уникальной программой, которая позволяет создавать модели процессов и поддерживает в одной модели в дополнение к IDEF0 еще два стандарта (нотации) моделирования - DFD и IDEF3. Каждая из этих трех нотаций позволяет рассмотреть различные стороны деятельности предприятия:

• 1) диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии, они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты производят работы, что является управляющими факторами и какие ресурсы для этого необходимы;
• 2) нотация IDEF0 позволяет выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия;
• 3) диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации.

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

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

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

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

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

Программа BPwin предоставляет аналитику два инструмента для оценки модели - стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями для идентификации движителей затрат в организации.

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

Обычно ABC применяется для того, чтобы понять происхождение затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), и др. в каждой из моделей AS-IS и ТО-ВЕ.

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

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

В рамках данной дипломной работы будут рассматриваться элементы линейки AllFusion компании Computer Associates.

Изучив первоисточники и проанализировав их, а также само средство - программу BPwin сделаем выводы: любую деятельность или структуру предприятия можно спроектировать и представить в виде, что позволит оптимизировать работу организации, проверить её на соответствие стандартам ISO9000, спроектировать структуру, снизить издержки, исключить ненужные операции, повысить гибкость и эффективность. BPwin поддерживает сразу три нотации моделирования: IDEF0 федеральный стандарт США, IDEF3 и DFD и является уникальным программным средством в области проектирования автоматизированных информационных систем. Проанализировав все процессы, в завершение параграфа представлен рисунок 14, демонстрирующий все процессы такие как анализ требований и другие рабочие потоки программной инженерии.

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

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

Поток работ «анализ и проектирование» осуществляется на основе исходных данных, предоставленных АТ. В определенной мере эти потоки работ проводятся параллельно. При обнаружении проблем, связанных с требованиями, возникает обратная связь от этого потока работ к потоку работ АТ.

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

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

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

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

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

Коротко о процессном подходе

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

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

Практическое применение моделирования бизнес-процессов

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

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

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

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

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

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

Перечисленными задачами далеко не исчерпывается область применения моделирования бизнес-процессов - здесь приведены лишь некоторые примеры использования этого вида моделирования.

Процессный подход и CASE-технологии

Модели, объекты и связи

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

Существует довольно много методологий моделирования, используемых сегодня при описании бизнес-процессов. К наиболее популярным из них можно отнести методологию DFD (Data Flow Diagrams), описывающую диаграммы потоков данных, которые используются при анализе требований и функциональном проектировании информационных систем; STD (State Transition Diagram), рассматривающую диаграммы перехода состояний для проектирования систем реального времени; ERD (Entity-Relationship Diagrams), раcсматривающую диаграммы «сущность - связь», которые применяются при логическом проектировании информационных систем; FDD (Functional Decomposition Diagrams), описывающую диаграммы функциональной декомпозиции; SADT (Structured Analysis and Design Technique), представляющую собой довольно популярную в 90-х годах технологию структурного анализа и проектирования. В последнее время популярна также методология ARIS, рассматривающая совокупность различных типов моделей (включая и поддерживаемые некоторыми другими методологиями), которые используются для описания всех подсистем компании. Не менее популярно и семейство методологий IDEF, применяемых для проектирования бизнес-процессов и данных (разработчики баз данных, как правило, неплохо знакомы с методологией IDEF1X, описывающей логические и физические модели данных, а методология IDEF0 весьма популярна у аналитиков, описывающих бизнес-процессы). У разработчиков приложений очень популярна методология UML (Unified Modelling Language), используемая при проектировании информационных систем и приложений с целью описания требований к информационной системе, сценариев работы пользователей, изменения состояний системы и данных в процессе работы и классов будущего приложения.

Инструменты моделирования

Хотя рисовать модели на бумаге не возбраняется, современное моделирование бизнес-процессов обычно осуществляется с использованием CASE-средств - Computer Aided System Engineering - проектирование систем с помощью компьютера. На современном рынке программного обеспечения CASE-средств не одна сотня. В такой ситуации имеет смысл обсудить их классификацию и задачи, которые можно решить с их помощью (применительно к процессному подходу).

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

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

CASE-средства можно классифицировать по типам:

• средства анализа и моделирования, предназначенные для создания описаний процессов и иных предметных областей как таковых;
• средства анализа и проектирования, используемые для управления требованиями и документирования ИТ-проектов;
• средства моделирования приложений (сегодня наиболее распространенной категорией таких средств является семейство средств UML-моделирования);
• средства проектирования данных, обеспечивающие моделирование данных и генерацию схем баз данных для наиболее распространенных СУБД.

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

Рис. 1. Borland Together

К наиболее популярным в нашей стране средствам описания бизнес-процессов можно отнести средства UML-моделирования Rational Rose (IBM) и Together (Borland) - рис. 1, семейство AllFusion Business Process Modeler (BPwin) для описания бизнес-процессов с помощью методологии IDEF0 (Computer Associates) и организации коллективной работы над единым репозитарием моделей (рис. 2), ARIS (IDS Scheer) - инструмент коллективной работы над совокупностью взаимосвязанных моделей различных типов (рис. 3), предназначенных для описания бизнес-процессов, данных и информационных систем, деятельности компаний, Visio (Microsoft) - средство создания различных типов моделей бизнес-процессов и данных, позволяющее создавать диаграммы и модели с применением различных методологий (рис. 4).

Рис. 2. CA AllFusion Business Process Modeler (BPwin)

Рис. 3. ARIS Business Architect

Рис. 4. Microsoft Visio

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

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

Среди рядовых сотрудников бытует мнение, что работа HR-отдела, это «прием на работу - работа - увольнение». Однако функции этого отдела и количество бизнес-процессов в сфере управления персоналом гораздо разнообразнее, чем кажется.

Возьмем для примера кадровый бизнес-процесс - «выход на работу нового сотрудника»:

Схема 1. Бизнес-процесс «Выход на работу нового сотрудника»

Из схемы видно, что даже такой рядовое событие в жизни компании состоит из десятка этапов.

Бизнес-процессы в сфере HR

• поиск и подбор кандидатов на вакансию;
• адаптация персонала;
• оценка способностей сотрудника;
• кадровый учет;
• материальная мотивация;
• управление карьерой.

12 типажей HR-специалистов

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

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

Чтобы развеять эти сомнения, рассмотрим преимущества автоматизированных бизнес-процессов в HR. Эксперты «Системы Кадры» подробно расскажут, как автоматизировать процессы управления персоналом, какую из современных систем выбрать

4 преимущества автоматизации бизнес-процессов в HR

Преимущество 1. Автоматизация значительно снижает расход времени на выполнение рутинных кадровых процедур. Заявки разных типов можно подавать и обрабатывать в автоматическом режиме. Например, заявка на отпуск. В автоматическом режиме последовательность процедур такая: «учет заявки сотрудника → визирование заявки руководителем → подготовка приказа → фиксация данных об отпуске в расписании сотрудника ».

Схема 2. Бизнес-процесс «Заявка на отпуск»

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

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

Преимущество 3. Обеспечивает сохранность кадровых данных и предотвращает несанкционированный доступ к ним.

Преимущество 4. Повышает дисциплину сотрудников. Автоматизированные комплексы снабжены системой напоминаний. Процессы можно легко отслеживать на всех этапах. Сохраняется история операций. Всегда можно определить ответственного за нарушение порядка работы.

Какие программные продукты используют HR-ы в своей работе

Системы автоматизации бизнес-процессов используются HR-ами в следующих областях:

• подбор персонала;
• обучение и развитие персонала;
• кадровый учет;
• мотивация и оплата труда.

Топ-5 самых популярных программных продуктов для HR

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

• собирает заявки на подбор персонала со всех отделов фирмы;
• автоматически публикует объявление о вакансии на основных российских job-сайтах;
• собирает отклики на вакансию;
• автоматически обновляет объявления о вакансии;
• ведет поиск резюме по заданным параметрам;
• автоматизирует рутинные операции по массовой «заливке» резюме в базу данных и рассылки писем кандидатам.

В «Системе кадры» вы найдете пример правил использования автоматизированной системы при подборе персонала

Система предназначена для HR-службы компании, отдела кадров и бухгалтерии.

Программный комплекс позволит HR-ам:

• планировать потребность в сотрудниках;
• управлять компетенциями и аттестацией персонала;
• планировать обучение персонала;
• планировать отпуска;
• управлять системой материальной мотивации сотрудников .

Пожалуй, самый мощный и многофункциональный комплекс.

Система состоит из 8 модулей:

• Управление персоналом - здесь собираются все сведения о сотрудниках и на основе этих данных формируется организационно-штатная структура компании.
• Табельный учет - значительно облегчает учет отработанного времени;
• Зарплата - расчет всех видов заработной платы (почасовая, сдельная и т.д);
• Компенсационный пакет - в этом модуле формируются программы компенсаций (например, оплата проезда или мобильной связи), которые затем назначаются разным категориям сотрудников;
• Управление обучением - планирование и контроль затрат на обучение персонала;
• Интернет-подбор персонала - необычный модуль, которого нет в других системах. Суть его в следующем. Модуль создает веб-интерфейс, который можно разместить на сайте компании. Посетители сайта смогут посмотреть вакансии компании и выложить свое резюме.
• Система информирования руководства - еще один необычный модуль. Здесь руководитель может получить любую кадровую информацию в удобной форме. Например, сведения обо всех уволившихся за последний месяц из-за низкой зарплаты или данные о незакрытых вакансиях.
• Управление персоналом, самообслуживание - здесь сотрудники получают доступ только к своей кадровой информации, могут посмотреть расчетные листки, информацию о вакансиях, оставить заявление на отпуск и внести предложения по работе компании.

Одна из старейших на российском рынке систем автомазиции.

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

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

Как выбрать систему автоматизации бизнес-процессов

Существует два варианта выбора системы автоматизации:

• использовать стандартный (коробочный) продукт;
• разработать или заказать индивидуальное программное обеспечение.

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

Прежде чем сделать выбор конкретного программного продукта, дайте ответы на следующие вопросы:

1. Какие бизнес-процессы вы планируете автоматизировать?
2. Соответствует ли функционал программы поставленным задачам?
3. Необходима ли донастройка программы под конкретную задачу?
4. Предусмотрено ли в программе быстрое изменение системы без прекращения ее эксплуатации? Это необходимо на случай смены вида деятельности или условий ведения бизнеса.
5. Удобна ли программа в использовании?
6. Используются ли в вашей компании другие программы автоматизации? Возможна ли интеграция новой системы с существующей?
7. Кто будет осуществлять техническую поддержку?

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

Введение

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

2. Классификация бизнес-процессов

3. Стандарты моделирования бизнес-процессов

Заключение

Список используемых источников

ВВЕДЕНИЕ

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

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

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

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

Моделирование бизнес-процессов позволяет проанализировать не только, как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте.

Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:

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

моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия;

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

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

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

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

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

Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.

Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов

Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:

изменение организационной структуры;

оптимизацию функций подразделений и сотрудников;

перераспределение прав и обязанностей руководителей;

изменение внутренних нормативных документов и технологии проведения операций.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.

На этапе структурного моделирования в модели должны быть отражены:

существующая организационная структура;

документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;

структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;

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

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

Детальная модель бизнес-процесса должна включать:

набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;

диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;

диаграммы взаимодействия, отражающие схемы документооборота.

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

Бизнес-операция обычно начинается с производства или закупки партии товара по заранее намеченному плану действий и завершается продажей товара и получением прибыли. Бизнес-операции называют также сделками .

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

Бизнес-Модель - это то, что делает компания и благодаря чему она зарабатывает деньги (Том Мэлоун)

Бизнес-стратегия есть теория, бизнес-модель - гипотеза (Николас Карр)

Бизнес-модель - это представление набора связанных модельных элементов, определяющих внутреннюю и внешнюю среду компании в рамках единой системы .

2. КЛАССИФИКАЦИЯ БИЗНЕС-ПРОЦЕССОВ

Выделяют следующую классификацию :

В зависимости от места бизнес-процессов в организационной структуре компании выделяют следующие бизнес-процессы:

горизонтальные процессы – процессы, отражающие взаимодействие по горизонтали;

индивидуальные горизонтальные процессы – процессы, выполняемые отдельными работниками (организационными единицами);

межфункциональные горизонтальные процессы – процессы, выполняемые многими работниками (организационными единицами);

вертикальные процессы – процессы, отражающие взаимодействие работников (организационных единиц) по вертикали;

интегрированные процессы – процессы, отображающие взаимодействие участников процессов по вертикали и по горизонтали.

В зависимости от степени их сложности выделяют:

монопроцессы – односложные процессы;

вложенные процессы - монопроцессы, входящие в состав более сложного процесса (макропроцесса);

связанные процессы – выделенные и последовательно реализуемые по определенному алгоритму монопроцессы.

В зависимости от их предназначения:

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

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

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

В зависимости от их места в иерархии целей организации:

бизнес-процессы верхнего уровня – процессы, направленные на реализацию стратегических целей компании, наиболее значимые для компании;

бизнес-процессы среднего уровня – бизнес-процессы, направленные на реализацию тактических целей;

бизнес-процессы нижнего уровня бизнес-процессы, направленные на реализацию оперативных целей.

В зависимости от степени их детализации :

макропроцессы – укрупненные бизнес-процессы имеющие степень детализации необходимую чтобы описать бизнес-процессы верхнего уровня;

субпроцессы – бизнес-процессы имеющие степень детализации необходимую для описания бизнес-процессов среднего уровня;

микропроцессы – бизнес-процессы, имеющие предельно максимальную степень детализации, используются для описания бизнес-процессов нижнего уровня.

В рамках основных составляющих сбалансированной системы показателей:

финансовые бизнес-процессы;

клиентские бизнес-процессы;

бизнес – процессы производства;

бизнес-процессы развития, обучения и роста.

Стандарт функционального моделирования IDEF0

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

Стандарт IDEF 0 представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

Стандарт информационного моделирования IDEF1

Стандарт IDEF1 был разработан как инструмент для анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия. Применение методологии IDEF1 как инструмента построения наглядной модели информационной структуры предприятия по принципу «как должно быть». Пример построения модели показан на рисунке 2.

Рисунок 2 – Пример построения модели IDEF1

Основными составляющими компонентами информационной модели являются:

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

словарь – значение каждого элемента модели описывается текстовым фрагментом.

Базовым понятием в методологии IDEF1 является понятие сущности. Сущность определяется как реальный или абстрактный объект, набор отличительных свойств которого, называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты .

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

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

Процесс на диаграмме потоков данных изображается, как показано на рисунке 4.

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

Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.

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

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

Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.

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

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

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

ЗАКЛЮЧЕНИЕ

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3–5 является теоретическим, а к IDEF0 вполне практически обоснованным.

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

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

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

1. Войнов И.В. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей [Текст]: монография / И.В. Войнов – М.: ЮУрГУ, 2002. – 392 с.

2. Волков О.Н. Стандарты и методологии моделирования бизнес-процессов [Текст]: учеб. пособие для вузов / О.Н. Волков. – М.: АСВ, 2000. – 145 с.

3. Григорьев Д.И. Моделирование бизнес-процессов предприятия [Текст]: учеб. пособие / Д.И. Григорьев. – М.: ИРЦ, 2006. – 214 с.

4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов [Текст]: учеб. пособие / Г.Н. Калянов. – М.: Финансы и статистика, 2006. – 319 с.

5. Пинаев Д.К. Моделирование бизнес-процессов: доступно о сложном [Текст]: справ. пособие / Д.К. Пинаев. – М.: РГАС, 2003. – 247 с.

Репетиторство

Нужна помощь по изучению какой-либы темы?

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