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

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

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

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

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

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

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

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

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

Ежедневные советы от диджитал-наставника Checkroi прямо в твоем телеграме!

Подписывайся на канал

Зачем нужно моделировать бизнес-процессы

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

Проблемы, которых помогает избежать моделирование бизнес-процессов:

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

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

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

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

Классификация методологий моделирования бизнес-процессов

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

Методология включает в себя:

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

В основе методологии моделирования могут лежать три подхода:

Структурный подход рассматривает систему как набор элементов, подсистем и отношений между ними. Используется для организационного развития предприятий и компаний: ищет способы оптимизации, разрабатывает рабочие регламенты и должностные инструкции. Методологии: SADT, DFD, WFD.
Объектно-ориентированный подход рассматривает систему как набор взаимодействующих объектов. Объекты — предметы, которые преобразуются при выполнении процессов. При объектно-ориентированном подходе сначала выделяются объекты, а затем действия, в которых они участвуют. Подход используется для визуализации, конструирования и документирования. Методология: BAAM.
Интегрированный подход объединяет структурный и объектно-ориентированный подходы. Даёт полное и комплексное представление о моделируемом объекте. Методология: ARIS.

Единого верного способа моделирования нет. Важно правильно ставить цель и исходя из неё выбирать подходящие инструменты реализации.

Разберём особенности популярных методологий моделирования.

SADT

SADT — методология структурного анализа и проектирования, разработанная Дугласом Россом в 1969-1973 годах. Объединяет и организует диаграммы в иерархические древовидные структуры — чем выше уровень диаграммы, тем она менее детализирована.

Диаграммы SADT состоят из:

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

Методология применяется на ранних этапах создания системы для определения требований к ней. В США SADT успешно использовалась в военных и коммерческих организациях для долгосрочного стратегического планирования и управления финансами.

Особенности методологии SADT:

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

Самая распространённая нотация — IDEF0.

Пример бизнес-процесса в нотации IDEF0

DFD

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

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

Особенности методологии DFD:

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

Самые распространённые нотации — Эд Йордана и Тома де Марко.

Пример описания процесса обработки заказа клиента с помощью методологии DFD

WFD

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

Методология применяется для моделирования таких бизнес-процессов компаний как: «Выставление счетов», «Подготовка договора», «Изготовление детали».

Особенности методологии WFD:

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

Самая распространённая нотация — IDEF3.

Пример описания процесса согласования договора с помощью нотации IDEF3

ARIS

ARIS — одновременно и методология, и программный продукт для моделирования бизнес-процессов организации. Методология ARIS разработана профессором Августом Шеером в 1990-х годах. Она представляет собой современный подход к структурированному описанию деятельности компании, представлению её в виде взаимосвязанных графических диаграмм, удобных для понимания и анализа.

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

Особенности методологии ARIS:

основывается на концепции интеграции, предлагает целостный взгляд на процессы;
рассматривает и представляет любую организацию как единую систему;
насчитывает более 80 моделей, поэтому для осмысленного применения требуется время;
использует разные уровни описания: что система должна знать, какие у неё пути реализации, а также программные и технические средства.
её внедрению должна предшествовать «ручная» проектно-аналитическая работа;
главное преимущество — высокая степень визуализации бизнес-моделей.

Самые распространённые нотации — EPC, UML и BPMN.

Пример бизнес-процесса в BPMN-нотации

BAAM

BAAM — методология описания деятельности. Включает в себя шесть бизнес-моделей: ESM, BCM, BPM, BFM, BOM, ERM. С их помощью последовательно описывает функции, бизнес-процессы, организационные и структурные особенности компаний, её подразделения, а также материальные и информационные потоки между ними. Методология представляет собой схему, на которой вместо работ отображаются структурные подразделения и взаимодействия между ними.

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

Особенности методологии BAAM:

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

Самые распространённые нотации — Нотация Питера Чена, нотация Гордона Эвереста Crow’s Foot.

Пример бизнес-процесса в нотации Питера Чена

Сравнение нотаций

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

Критерий сравнения	IDEF0	EPC	BPMN
Принцип построения диаграммы	Принцип доминирования	Временная последовательность выполнения процедур	Временная последовательность выполнения процедур
Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме
Модель отражает	Структуру системы, функции, потоки ресурсов и информации	Структуру системы, функции, потоки ресурсов и информации	Функции системы, внутренние процессы
Графические элементы	Прямоугольники — действия и этапы. Стрелки — ресурсы и исполнители	Фигуры разных цветов. Розовые — события, зелёные — функции, жёлтые — исполнители, серые — ресурсы, оранжевые — ИС. Соединительные элементы — стрелки и разделители «и», «или»	Задача — прямоугольник, событие — круг, поток — стрелка. Также есть сноски и базы данных
Достоинство	Высокая степень детализации. Можно создать модель, которая будет учитывать практически все ресурсы, всех сотрудников	Простота восприятия	Простота восприятия. Подходит для описания внутренних бизнес-процессов компании
Недостаток	Модель занимает много места	Приходится создавать события даже для незначительных этапов	Зациклена на бизнес-процессах, не подходит для описания структуры
Сфера применения	Долгосрочное планирование, управление финансами	Описание технологических процессов предприятия — выставление счетов, отгрузки товаров и т.д.	Управленческий консалтинг, внедрение систем управления качеством, оптимизация бизнес-процессов

Коротко о главном

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

Источник

УДК 004

СОВРЕМЕННЫЕ МЕТОДОЛОГИИ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

Македонский Павел Дмитриевич¹, Уламасова Евгения Петровна²
¹Магнитогорский государственный технический университет имени Г.И. Носова, студент 3 курса Института энергетики и автоматизированных систем
²Магнитогорский государственный технический университет имени Г.И. Носова, студентка 4 курса Института экономики и управления

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

Ключевые слова: бизнес-моделирование, бизнес-процесс, информационная система, методология ARIS

MODERN METHODOLOGY DESCRIPTION OF BUSINESS PROCESSES

Makedonskiy Pavel Dmitrievich¹, Ulamasova Evgeniya Petrovna²
¹Nosov Magnitogosk State Technical University, 3rd year student of the Institute of Energy and automated systems
²Nosov Magnitogosk State Technical University, 4th year student of the Institute of Economics and Management

Abstract
Today there is a real opportunity with the help of simulations on modern multi-functional, the processing and display of information, such as Microsoft Visio, specify the type and characteristics of data models, to identify the main features of the future work of the operators, to formulate requirements to the parameters of the hardware-software interface, interaction, etc. Particular emphasis in the implementation of these objectives, the design and AIS development should, of course, give a modern CASE-tools programming, because they optimally allow you to design solutions that are based on, first of all, to a consistent user interface requirements, what is the interface Windows.

Библиографическая ссылка на статью:
Македонский П.Д., Уламасова Е.П. Современные методологии описания бизнес-процессов // Современная техника и технологии. 2016. № 11. Ч. 2 [Электронный ресурс]. URL: https://technology.snauka.ru/2016/11/11458 (дата обращения: 24.02.2023).

Одной из современных методологий бизнес-моделирования, получившей широкое распространение в России является методология ARIS, которая расшифровывается как Architecture of Integrated Information Systems – проектирование интегрированных информационных систем. Основные проблемы как практического, так и теоретического характера связанных со всесторонним изучением масштаба и темпа внедрения средств автоматизации управления ставит необходимость комплексных исследований.
Одним из преимуществ методологии ARIS является высокая степень визуализации бизнес-моделей, что делает данную методологию удобной и доступной в использовании всеми сотрудниками компании. В методологии ARIS смысловое значение имеет цвет, что повышает восприимчивость и читабельность схем бизнес-моделей. Помимо большего количества моделей по сравнению с другими методологиями, методология ARIS имеет наибольшее количество различных объектов, используемых при построении бизнес-моделей, что увеличивает их аналитичность. Например, материальные и информационные потоки на процессных схемах обозначаются разными по форме и цвету объектами, что позволяет быстро определить тип потока [1, 2, 3]. Несмотря на большее количество моделей в методологии ARIS в проектах по описанию и оптимизации деятельности в общем случае их используется не более десяти. Методология ARIS позиционирует себя как конструктор, из которого под конкретный проект в зависимости от его целей и задач разрабатывается локальная методология, состоящая из небольшого количества требуемых бизнес-моделей и объектов.
Таким образом, на сегодняшний день можно констатировать тот факт, что моделирование бизнес-процессов, бизнес-моделирование стало неотъемлемой составляющей реализации любого проекта, связанного с модернизацией и развитием деятельности компании. А результаты бизнес-моделирования представлены в виде моделей: eEPC, OC, OG, BSC, VAD и другие [1, с. 4].
Рассмотрим информационную систему учета заявок МАОУ «СОШ №67» с использованием методологии ARIS. Для достижения цели необходимо решить следующие задачи:

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

Школа № 67 открыта 30 августа 1994 года. До 1997 года она носила статус школы – новостройки. На момент открытия школы (в 1994 году) в ней обучалось 1800 учащихся, что превышало объемные показатели в 3,5 раза. Только в начальной школе было укомплектовано 30 классов.
В настоящий момент присвоен статус муниципального автономного общеобразовательного учреждения: МАОУ «СОШ № 67» города Магнитогорска. Имеет опыт работы в сфере образования: Всероссийская научно-практическая конференция работников вузов кафедр педагогики и методики начального образования «Современные подходы к преподаванию в начальной школе», на которой был одобрен опыт по внедрению информационных и здоровье сберегающих технологий в учебный процесс [4, 5, 6]. Наиболее успешным примером с ИТ стало, использование проектного метода в обучении технологии и защиты проекта, как формы итоговой аттестации учащихся по технологии; метод круговой тренировки как способ организации самостоятельной деятельности учащихся; проведение организационно-деятельностных игр. Является участником в федеральном эксперименте по обновлению содержания образования. Приступила к реализации Программы «Организация самостоятельной деятельности учащихся как условие качественного образования». В рамках Приоритетного национального проекта «Образование» школа получила грант Президента. Благодаря Российской Академией образования и науки, Ведущим институтом развивающих технологий, образовательным центром «Школьный университет» за участие в международной исследовательской программе «Будущее за ИКТ» МАОУ «СОШ № 67» присвоен статус «Базовая школа по формированию ИКТ-компетентности школьников [7, 8, 9]. Выступает в качестве Центра образовательной робототехники.
Функциональные обязанности Диспетчера определены на основе должностных инструкций, указанных в уставе Школы.
Диспетчер:

Осуществляет с использованием средств вычислительной техники, коммуникаций и связи оперативное регулирование хода производства и других видов основной деятельности предприятия или его подразделений в соответствии с производственными программами, календарными планами и сменно-суточными заданиями.
Контролирует обеспеченность подразделений необходимыми материалами, комплектующими изделиями, оборудованием.
Осуществляет оперативный контроль за ходом выполнения операций, обеспечивая максимальное использование производственных мощностей, бесперебойную работу Аппаратного обеспечения, выполнение работ (услуг.
Обеспечивает соблюдение установленных норм по Технике безопасности.
Принимает меры по предупреждению и устранению нарушений хода работы отделов, привлекая, при необходимости, соответствующие службы предприятия.
Выявляет резервы производства по установлению наиболее рациональных режимов работы технологического оборудования, более полной и равномерной загрузке оборудования и производственных площадей, сокращению длительности цикла.
Осуществляет внедрение и обеспечивает рациональное использование технических средств оперативного управления.
Ведет диспетчерский журнал, составляет отчетные рапорты и другую техническую документацию о ходе работы Технического отдела.
Участвует в работе по анализу и оценке деятельности подразделений, выявлению резервов [10, 11, 12].

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


Рисунок 1 – Сущность процесса учета заявок

Модель “Диаграмм бизнес-процессов верхнего уровня” – VAD является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Дополнительным отличием данной и других процессных моделей является то, что информационные и материальные потоки на схеме VAD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. На модели VAD методологии ARIS в отличие от классического подхода также используется логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ [1, с. 180].
Существующий способ учета приема заявок связан с большой трудоемкостью, разрозненностью сведений, что с большей вероятностью ведет к их утере или неправильной интерпретации. На сегодняшний день невозможно получить сведения об общем количестве заявок, провести анализ основных причин возникновения проблемных вопросов у клиентов и проанализировать причины обращения [13, 14, 15]. Кроме того, в отчетный период необходимо составление аналитических отчетов, включающих в себя анализ работы за определенный период, что очень затруднительно. Основной причиной возникновения проблем по работе с выполнением заявок выступает затяжной характер выполнения заявки, представленный на рисунке 2.


Рисунок 2. Диаграмма причины и следствия связей

Таким образом, сотрудник занят получения доступа к рабочему месту одного из клиентов системы, а также, при необходимости занесением необходимых сведений в книги учета. Учитывая, что продолжительность рабочего дня составляет 8 часов, делаем вывод, что на выполнение остальных обязанностей (то есть непосредственную работу по решению проблем клиента и выработке необходимых мероприятии) остается менее 40 % рабочего времени, что крайне неэффективно. Для данного способа также характерны следующие недостатки, представленные на рисунке 3.


Рисунок 3. Причинно-следственная диаграмма – «Рыбий скелет»

Для оценки значимости факторов создана экспертная группа из двух человек – системные администраторы двух школ. Произведем экспертную оценку используя метод ранжирования для этого составим матрицы обратных рангов (ai,j/(nmax+1)-ai,j) для таблиц 1-11 и найдем весовой показатель (W), где (a) экспертная оценка по (i-ому) критерию (j-го) эксперта [3].

Эксперт	Среда	Технический персонал	ИТ-Инфраструктура	Журнал учета заявок
1	14	32	41	23
2	14	41	23	32
W	8	3	4	5
	0,4	0,15	0,2	0,25
Эксперт	Формулировка Заявки некорректна	Отсутствие отчетности	Неполная Информации о проблеме
1	13	31	22
2	22	31	13
W	5	2	5
	0,42	0,16	0,42
Эксперт	Отсутствие ПО	Проблемы С ПО	Недостаточно Прав доступа
1	22	31	13
2	31	22	13
W	3	3	6
	0,25	0,25	0,5
Эксперт	Активация	Компьютерные характеристики
1	21	12
2	21	12
W	2	4
	0,33	0,67
Эксперт	Не предусмотрено Учебным планом	Лицензия
1	21	12
2	12	21
W	3	3
	0,5	0,5
Эксперт	Сервисный ремонт сторонней организации	Уровень знаний
1	21	12
2	12	21
W	3	3
	0,5	0,5
Эксперт	Дефекты и поломки оборудования	Неисправность оборудования
1	12	21
2	12	21
W	4	2
	0,67	0,33
Эксперт	Сложность заявки	Отсутствие опыта
1	21	12
2	21	12
W	2	4
	0,33	0,67
Эксперт	Отсутствие доступа к кабинету	Искажение оперативной информации в журнале
1	22	31
2	31	22
W	3	3
	0,25	0,25
Эксперт	Ключа на Вахте нет	Ключи у технички	Ключи у учителя
1	13	22	31
2	13	31	22
W	6	3	3
	0,5	0,25	0,25
Эксперт	Учитель вне школы	Учитель в школе
1	12	21
2	12	21
W	4	2
	0,67	0,33

Таким образом, выполненная нами экспертная оценка показала, что наиболее значимая группа факторов является Среда (рис. 4), оцениваемая в 40% и в качестве решения возможно поддержание постоянной связи между сотрудником и исполнителем процесса, а также обеспечение доступа в помещение.


Рисунок 4. Эффективный учет выполнения заявки

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


Рисунок 5. Диаграмма событийно-управляемого процесса – eEPC


Рисунок 6. Диаграмма взаимодействия основных подразделений компании – CD

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

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

Библиографический список

Новикова Т. Б., Назарова О. Б., Петеляк В. Е. Aris: теория и практика бизнес-моделирования: учеб. Пособие. – Магнитогорск: Изд-во Магнитогорск. гос. техн. ун-та им. Г. И. Носова, 2016. 289 с.
Комиссарова О.Р., Конькова Д.С., Матвеев В.А., Новикова Т.Б. Исследование деятельности аэропорта на примере диаграмм методологии ARIS «EEPC», «MFD» // Современные научные исследования и инновации. 2015. № 11 (55). С. 117-120.
Конькова Д.С., Новикова Т.Б., Комиссарова О.Р., Матвеев В.А. Разработка диаграмм eEPC, VAD, FTA на примере описания предметной области «Ведение обращений в прокуратуру» // Современные научные исследования и инновации. 2015. № 11 (55). С. 112-116.
Конькова Д.С., Новикова Т.Б., Комиссарова О.Р., Матвеев В.А., Мусин Р.Ф. Бизнес – моделирование деятельности завода по производству автомобилей с использованием диаграмм IFD, CD, MFD // Современные научные исследования и инновации. 2015. № 11 (55). С. 98-101.
Курзаева Л.В. Введение в теорию систем и системный анализ : учеб.пособие / Л.В. Курзаева. – Магнитогорск : МаГУ, 2015. – 211 с.
Македонский П.Д., Курзаева Л.В. Анализ проблем обслуживания ИТ-инфраструктуры современной школы на основе экспертной оценки // Современные научные исследования и инновации. 2016. № 7 [Электронный ресурс]. URL: http://web.snauka.ru/issues/2016/07/70042 (дата обращения: 04.12.2016).
Матвеев В.А., Конькова Д.С., Комиссарова О.Р., Новикова Т.Б., Мусин Р.Ф. Документооборот при оказании услуг перевозки груза и его графическое отображение на примере нотации eEPS // Современные научные исследования и инновации. 2015. № 11 (55). С. 89-94.
Мусин Р.Ф., Пролозова Т., Конькова Д.С., Матвеев В.А., Новикова Т.Б., Курзаева Л.В. Разработка диаграммы VAD для описания бизенс-процесса приема сырья на склад // Современные научные исследования и инновации. 2015. № 11 (55). С. 95-97.
Новикова Т.Б., Гусева Т.Ф., Вахрушев В.И., Седнева Д.А., Климов П.А., Иванченко А.Е., Игнатова Т.А. Опыт моделирования диаграмм OD, FTA, VAD, EEPC для постановки задач управления в социальных и экономических системах // Современные научные исследования и инновации. 2016. № 1 (57). С. 67-72.
Новикова Т.Б., Махмутова М.В., Гусева Т.Ф., Вахрушев В.И., Седнева Д.А., Климов П.А., Иванченко А.Е., Игнатова Т.А., Яковлева М.Ф. Моделирование бизнес-процесса «Учет ремонтов» с целью повышения эффективности и функционирования компании по предоставлению ремонтных услуг // Современные научные исследования и инновации. 2015. № 12 (56). С. 268-274.
Новикова Т.Б., Махмутова М.В., Гусева Т.Ф., Вахрушев В.И., Седнева Д.А., Климов П.А., Иванченко А.Е., Игнатова Т.А., Микутская К.А. Разработка моделей для описания бизнес-процесса «Учет готовой продукции на складе» // Современные научные исследования и инновации. 2015. № 12 (56). С. 275-280.
Новикова Т.Б., Янин А.А., Агалакова В.И., Юрлова О.А., Курзаева Л.В. Реорганизация бизнеса для поддержки операционной деятельности с применением модели EPC // Современные научные исследования и инновации. 2015. № 11 (55). С. 241-248.
Седнева Д.А., Климов П.А., Гусева Т.Ф., Вахрушев В.И., Румянцев Е.П., Новикова Т.Б. Описание моделей по созданию собственного бизнеса // Современные научные исследования и инновации. 2015. № 11 (55). С. 131-138.
Шарипова У.В., Федоренко И.А., Новикова Т.Б., Курзаева Л.В., Енютина А.В., Арзамасцева Е.А. Актуальность модели EEPC в описании деятельности компании // Современные научные исследования и инновации. 2016. № 1 (57). С. 141-145.
Ягудина Р.Р., Новикова Т.Б. Бизнес-моделирование процесса «Описание деятельности кафетерия» с использованием методологии ARIS // Современные научные исследования и инновации. 2015. № 11 (55). С. 154-161.

Все статьи автора «Македонский Павел Дмитриевич»

Источник

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

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

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

На
самом деле, несмотря на свое различие,
в основном связанное с названием
диаграмм и видов используемых объектов,
современные методологии описания
бизнес-процессов практически идентичны
и представляют из себя незначительные
видоизменения двух классических схем
– DFD и WFD, которые были рассмотрены.

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

IDEF0.
DFD
в нотациях Гейна-Сарсона и Йордана-Де
Марко.
IDEF3.
ORACLE.
BAAN.
ARIS.

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

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

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

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

Методология dfd в нотациях Гейна-Сарсона и Йордана-Де Марко

Следующий
стандарт описания бизнес-процессов,
который получил распространение, был
разработан на основе развития классической
методологии DFD. Данный стандарт
представлен двумя немного различающимися
вариантами, которые называют нотациями.
Первая из них называется нотацией Гейна
Сарсона, вторая – нотацией Йордона-Де
Марко.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

Источник

Ковалев Сергей Михайлович

Ковалев Валерий Михайлович

№	Название модели	Описание и предназначение модели
Английский вариант	Русский вариант
1.	ESM – Enterprise Structure Model.	Модель метаструктуры предприятия.	Модель позволяет описать географически распределенную структуру компании.
2.	BCM — Business Control Model.	Модель управления.	Процессная модель описывает бизнес-процессы компании в стандарте DFD. Применяется для описания бизнес-процессов верхнего уровня.
3.	BPM — Business Process Model.	Процессная модель.	Модель описывает бизнес-процессы компании в стандарте WFD. Применяется для описания бизнес-процессов нижнего уровня.
4.	BFM — Business Function Model	Функциональная модель	Модель описывает функции, выполняемые в компании и их иерархию.
5.	BOM — Business Organization Model.	Организационная модель.	Модель описывает организационную структуру компании.
6.	ERM – Entity-Relationship Model.	Информационная модель	Информационная модель типа «Сущность-Связь» описывает структуру информации, используемой при реализации бизнес-процессов. Позволяет описать структуру базы данных.

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

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

Рис. 9. Модель метаструктуры предприятия – ESM / BAAN.

Структурные подразделения компании, изображенные на модели метаструктуры предприятия – ESM декомпозируется на модель управления – BCM , на которой показываются бизнес-процессы данного структурного подразделения, а также материальные и информационные потоки протекающие между ними. Модель управления – BCМ полностью соответствуют классической DFD-схеме и она применяется для описания бизнес-процессов верхнего уровня (рис. 10).

Рис. 10. Модель управления – BCM / BAAN.

Процессы с модели управления – BCM декомпозируются на модель управления – BCM более низкого уровня в случае, если они глобальны и могут быть представлены в виде временной последовательности работ. В противном случае они декомпозируются на модели бизнес-процессов – BPM, которые применяются для описания бизнес-процессов нижнего уровня и практически соответствуют классической WFD-схеме, за исключением двух особенностей. Первая – блоки принятия решений на модели бизнес-процессов BPM называются управляющими работами и вторая особенность связана с наличием на модели элементов, называемых состоянием, с помощью которых описываются состояния, характеризующие начало и окончания каждой работы. Данный подход, связанный с описанием состояний заимствован из подхода к описанию бизнес-процессов, который называется «Сети Петри» (рис. 11).

Рис. 11. Модель бизнес-процессов – BPM / BAAN.

При описании деятельности компании методология BAAN также использует модель функций – BFM, при помощи которых строится дерево функций компании (рис. 12).

Рис. 12. Модель функций – BFM / BAAN.

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

Рис. 13. Модель организационной структуры – BOM / BAAN.

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

Источник

№	Название модели	Описание и предназначение модели
Английский вариант	Русский вариант
1.	ESM – Enterprise Structure Model.	Модель метаструктуры предприятия.	Модель позволяет описать географически распределенную структуру компании.
2.	BCM — Business Control Model.	Модель управления.	Процессная модель описывает бизнес-процессы компании в стандарте DFD. Применяется для описания бизнес-процессов верхнего уровня.
3.	BPM — Business Process Model.	Процессная модель.	Модель описывает бизнес-процессы компании в стандарте WFD. Применяется для описания бизнес-процессов нижнего уровня.
4.	BFM — Business Function Model	Функциональная модель	Модель описывает функции, выполняемые в компании и их иерархию.
5.	BOM — Business Organization Model.	Организационная модель.	Модель описывает организационную структуру компании.
6.	ERM – Entity-Relationship Model.	Информационная модель	Информационная модель типа «Сущность-Связь» описывает структуру информации, используемой при реализации бизнес-процессов. Позволяет описать структуру базы данных.

Ковалев Сергей Михайлович,
Ковалев Валерий Михайлович,
(Журнал «Консультант директора», № 12, Июнь, 2004 г.)

Проектирование оптимальных бизнес-процессов начинается со структуризации и описания организации. Затем следует собственно описание бизнес процессов. Эти вопросы рассмотрены в статьях: Ковалев С.М., Ковалев В.М. «Технология структуризации и описание организации – шаг за шагом» (Консультант директора №8, Апрель, 2004) и Ковалев С.М., Ковалев В.М «Описание бизнес-процессов – к вершинам мастерства» (Консультант директора №10, Май, 2004)

При описании и оптимизации бизнес-процессов возникает вопрос о выборе наиболее соответствующей интересам организации методологии. Этому вопросу посвящена данная статья. Как всегда: просто о сложном. Шаг за шагом — к вершинам мастерства.

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

Сущность и значение моделирования бизнес-процессов

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

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

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

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

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

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

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

моделирование бизнес-процессов — это всегда верный способ выявления текущих проблем на предприятии и предвидения будущих.

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

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

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

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

Читать полностью: https://www.km.ru/referats/80a6343015b8443393cbe203c7df7c3b

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

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

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

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

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

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

новые требования к автоматизации выполняемых процессов и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле, несмотря на свое различие, в основном связанное с названием диаграмм и видов используемых объектов современные методологии описания бизнес-процессов практически идентичны и представляют из себя незначительные видоизменения двух классических схем — DFD и WFD – Work Flow Diagram, которые были рассмотрены.

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

• IDEF0;
• DFD в нотациях Гейна-Сарсона и Йордана-Де Марко;
• IDEF3;
• Oracle;
• BAAN;
• Swimmer lanes;
• ARIS.

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

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

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

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

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

Таблица 1. Название и размещение входов и выходов в стандарте IDEF0 относительно функционального блока.

Название объектов	Размещение
Русский вариант	Английский вариант
Вход	I nput	Подходит к работе слева
Управление	C ontrol	Подходит к работе сверху
Выход	O utput	Исходит от работы справа
Механизм	M echanism	Подходит к работе снизу

Давайте рассмотрим пример бизнес-процесса «Выточить деталь», который выполняет токарь. Входом процесса является заготовка из которой вытачивается деталь – она физически преобразуется в процессе. Для того, что бы токарь начал точить деталь ему нужно дать задание или план. Также ему понадобится чертеж с размерами детали. Так вот, чертеж, задание или план нужны для реализации бизнес-процесса и процесс без них не начнется, но по ходу выполнения процесса они не преобразуются. Согласно стандарту IDEF0 их относят к управлению. Для того, что бы выточить деталь нужен токарь, нужен станок – их относят к механизмам. Выходами или результатами бизнес-процесса является деталь (рис. 1).

Рис. 1. Стандарт описания бизнес-процесса IDEF0.

Стандарт IDEF0 получил большое распространение в США и активно используется в России. Ввиду того, что в стандарте IDEF0 появилась дополнительная аналитика по сравнению с классическим стандартом DFD, схемы бизнес-процессов получаемые при описании в стандарте IDEF0 выглядят более сложными с точки зрения менеджеров компании, в виду ограниченного наличия у них свободного времени. Данная сложность часто приводит к тому, что менеджеры, особенно высшего уровня, которые должны принимать активное участие в проекте по описанию и оптимизации деятельности компании, «отказываются» от работы с IDEF0. В данном случае IDEF0 — является излишне информационно насыщенным и сложным стандартом.

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

Тем не менее, стандарт IDEF0 имеет большое распространение в России, так как по нему существует много книг и различных информационно-методических материалов.

Также существуют программные продукты, поддерживающие данный стандарт, овладеть которым несложно.

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

Рис. 2. Диаграмма IDEF0 верхнего уровня бизнес-процесса «Увольнение сотрудника».

Часть 2.

Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Марко

Следующий стандарт описания бизнес-процессов, который получил распространение, был разработан на основе развития классической методологии DFD. Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна Сарсона, вторая нотацией Йордона-Де Марко.

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

Рис. 3. DFD-схема бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении» в нотации Гейна-Сарсона.

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

Вторая нотация Йордона-Де Марко методологии DFD была названа в честь разработавшего ее специалиста Йордона-Де Марко. В первом приближении эта нотация аналогична нотации Гейна Саросна, за исключение форм объектов: для описаний операций бизнес-процесса вместо закругленных прямоугольников стали использоваться круги, немного видоизменились и другие объекты – хранилище данных и внешние сущности (рис. 4).

Рис. 4. DFD-схема бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении» в нотации Йордона-Де Марко.

В таблице 2 приведены названия, обозначения и смыл элементов, используемых при построении DFD-схемы бизнес-процесса в нотациях Гейна-Сарсано и Йордона-Де Марко.

Таблица 2. Элементы методологии DFD в нотациях Гейна-Сарсано и Йордона-Де Марко.

Часть 3.

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

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

Для описания временной последовательности и алгоритмов выполнения работ стандарт IDEF0 не подходит. Для решения этой задачи стандарт IDEF0 получил дальнейшее развитие в результате чего был разработан стандарт IDEF3, который входит в семейство стандартов IDEF.

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

Рис. 5. Схема бизнес-процесса в стандарте IDEF3.

В отличие от классической методологии WFD в стандарте IDEF3 связи между работами делятся на три типа, обозначения, названия и смыл которых, приведены в таблице 3.

Таблица 3. Типы связей между работами в стандарте IDEF3.

Помимо наличия нескольких типов связей между работами в стандарте IDEF3 логические операторы, которые в данном случае называются перекрестками также делятся на несколько типов: «Исключающий ИЛИ», «И» и «ИЛИ».

Перекресток «Исключающий ИЛИ» обозначает, что после завершения работы «A» (рис. 6), начинает выполняться только одна из трех расположенных параллельно работ B, С или D в зависимости от условий 1, 2 и 3. Перекресток «И» обозначает, что после завершения работы «A», начинают выполняться одновременно три параллельно расположенные работы B, С и D. Перекресток «ИЛИ» обозначает, что после завершения работы «A», может запуститься любая комбинация трех параллельно расположенных работ B, С и D. Например может запуститься только одна из них, могут запуститься три работы, а также могут запуститься двойные комбинации В и С, либо C и D, либо B и D. Перекресток «Исключающий ИЛИ» является самым неопределенным, так как предполагает несколько возможных сценариев реализации бизнес-процесса и применяется для описания слабо формализованных ситуаций.

Рис. 6. Применение перекрестков «Исключающий ИЛИ», «И» и «ИЛИ» — схемы расхождения.

Перекрестки «И» и «ИЛИ» подразделяются еще на два подтипа – синхронные и асинхронные. Перекрестки синхронного типа обозначают, что работы В, С и D запускаются одновременно после завершения работы A. Перекрестки асинхронного типа требований к одновременности не предъявляют.

Приведенные на рис. 5 схемы взаимосвязи работ и перекрестков называются схемами расхождения, так как от перекрестков расходятся несколько работ. Существует и другие схемы взаимосвязи перекрестков и работ – это так называемые схемы схождения, когда к перекрестку подходит несколько работ (рис. 7).

Рис. 7. Применение перекрестков «Исключающий ИЛИ», «И» и «ИЛИ» — схемы схождения.

В таблице 4 приведены обозначения, названия и смысл всех типов перекрестков как в схемах схождения, так и в схемах расхождения.

Таблица 4. Обозначения, названия и смысл типов перекрестков в схемах схождения и расхождения.

Название перекрестков	Обозначение перекрестков	Смысл перекрестков
Схема расхождения	Схема схождения
«Исключающий ИЛИ»		Только одна последующая работа запускается	Только одна предшествующая работа должна быть завершена
«И»	Асинхронный		Все последующие работы запускаются	Все предшествующие работы должны быть завершены
Синхронный		Все последующие работы запускаются одновременно	Все предшествующие работы должны быть завершены одновременно
«ИЛИ»	Асинхронный		Одна или несколько последующих работ запускаются	Одна или несколько предшествующих работ должны быть завершены
Синхронный		Одна или несколько последующих работ запускаются одновременно	Одна или несколько предшествующих работ должны быть завершены одновременно

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

Часть 4.

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

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

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

Три наиболее крупных разработчика информационных систем: SAP/R3, BAAN и ORACLE для повышения эффективности внедрения своих информационных систем разработали свои стандарты и программные продукты, с помощью которых описывается бизнес-деятельность компании. Каждый из этих стандартов содержит несколько бизнес-моделей, с помощью которых описываются бизнес-процессы, организационная структура, а также строятся прочие бизнес-модели.

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

Таблица 5.Модели методологии ORACLE.

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

Рис. 8. Пример описания бизнес-процесса «Торговля чаем» для функциональной организационной структуры компании «Эврика».

Одним из недостатков формата «Swimmer lanes» является то, что в данном случае более трудно отследить временную последовательность работ, а так же критический путь бизнес-процесса, что актуально при проведении временной оптимизации.

Модель IDEF1X

IDEF1X — методология описания данных. Применяется для построения баз данных.

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

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

Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Ниже, на рисунке, приведен ряд примеров связи между сущностями:

Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. На рисунке 2 приведен пример IDEF1X диаграммы.

Преимущества IDEF1X

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

Модель IDEF4

IDEF4 — объектно-ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектно-ориентированных языках (например С++). Пока, на мой взгляд, широкого распространения не нашла. Более широко сейчас используется UML.

Модель SADT

SADT — методология структурного анализа и проектирования (Structured Analysis and Design Technique). Основана на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители. Возникла в конце 60-х годов.

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

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

Часть 5.

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

Методология описания деятельности, разработанная компанией разработчиком информационных систем BAAN

содержит бизнес-модели, описание которых приведено в таблице 6.

Таблица 6. Модели методологии BAAN.

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

Структурные подразделения компании, изображенные на модели метаструктуры предприятия – ESM декомпозируется на модель управления – BCM, на которой показываются бизнес-процессы данного структурного подразделения, а также материальные и информационные потоки протекающие между ними. Модель управления – BCМ полностью соответствуют классической DFD-схеме и она применяется для описания бизнес-процессов верхнего уровня (рис. 10).

Рис. 10. Модель управления – BCM / BAAN.

Процессы с модели управления – BCM декомпозируются на модель управления – BCM более низкого уровня в случае, если они глобальны и могут быть представлены в виде временной последовательности работ. В противном случае они декомпозируются на модели бизнес-процессов – BPM, которые применяются для описания бизнес-процессов нижнего уровня и практически соответствуют классической WFD-схеме, за исключением двух особенностей. Первая – блоки принятия решений на модели бизнес-процессов BPM называются управляющими работами и вторая особенность связана с наличием на модели элементов, называемых состоянием, с помощью которых описываются состояния, характеризующие начало и окончания каждой работы. Данный подход, связанный с описанием состояний заимствован из подхода к описанию бизнес-процессов, который называется «Сети Петри» (рис. 11).

Рис. 11. Модель бизнес-процессов – BPM / BAAN.

Рис. 12. Модель функций – BFM / BAAN.

Рис. 13. Модель организационной структуры – BOM / BAAN.

Рис. 14. Информационная модель – ERM / BAAN.

Часть 6.

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

Методология ARIS на данный момент времени является наиболее объемной и содержит около 100 различных бизнес-моделей, используемых для описания, анализа и оптимизации различных аспектов деятельности организации. Часть моделей методологии ARIS используются в настроечном модуле интегрированной информационной системы SAP/R3, который применяется при внедрении системе и ее настройке на деятельности компании. В виду большого количества бизнес-моделей методология ARIS делит их на четыре группы (рис. 15):

Группа «Оргструктура».

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

Группа «Функции».

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

Группа. «Информация».

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

Группа «Процессы».

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

Рис. 15. Группы моделей методологии ARIS.

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

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

Таблица 7. Наиболее часто используемые на практике модели методологии ARIS.

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

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

Рис. 17. Модель «Дерево продуктов и услуг — PST/ARIS».

Модель «Дерево функций» — FT описывает функции, выполняемые в компании и их иерархию. Данная модель часто применяется для для построения дерева бизнес-процессов компании (рис. 18).

Рис. 18. Модель «Дерево функций» — PST/ARIS.

Модель «Диаграмма окружения процесса» — FAT позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов (рис. 19).

Рис. 19. Модель «Диаграмма окружения процесса» — PST/ARIS.

Модель «Диаграмм цепочки добавленной стоимости» — VACD является прототипом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня. Дополнительным отличием данной и других процессных моделей является то, что информационные и материальные потоки на схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. На модели VACD методологии ARIS в отличие от классического подхода также используется логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характерно для классического подхода WFD. (рис. 20).

Рис. 20. Модель «Расширенная цепочка процессов, управляемая событиями» — eEPC/ARIS.

Модель «Матрица выбора процесса» — PSM является прототипом классического DFD-стандарта и используется как альтернатива для модели VACD. Матрица выбора процессов по отношению к диаграмме цепочки добавленной стоимости является с одной стороны более упрощенным вариантом описания процесса, с другой стороны данная модель содержит дополнительные объекты, позволяющие показать другие аспекты бизнес-процесса. Простота матрицы выбора бизнес-процессов связана с тем, что на данной модели не показываются информационные и материальные потоки. Что касается других аспектов, то данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения бизнес-процесса, который описывается. Соответственно матрицу выбора процессов целесообразно применять вместо диаграммы цепочки добавленной стоимости в случаях, когда описываемый бизнес-процесс имеет несколько вариантов исполнения, каждый из которых ложится базовую схему. Пример применения матрицы выбора процессов для описания деятельности компании «Эврика», имеющий функциональную организационную структуру показан на рис. 21.

Модель «Extended event driven Process Chain» — eEPC является прототипом классического WFD-стандарта и используется для описания бизнес-процессов нижнего уровня. Дополнительным отличием eEPC-модели от классической WFD-схемы является наличие на модели объекта, который называется событием. С помощью событий изображается факт, время или событие инициирующие начало выполнения работ процесса, а также факт или время их завершения (рис. 22).

Рис. 22. Модель «Расширенная цепочка процессов, управляемая событиями» — VACD/ARIS.

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

Рис. 23. Модель «Организационная структура» — ORG/ARIS.

Модель «Диаграмма типов информационных систем» — ASTD используется для описания структуры информационных систем, используемых в компании. На данной модели показываются типы и модули информационных систем, программные продукты, взаимосвязь между ними и бизнес-процессами организации, которые они автоматизируют (рис. 24).

Рис. 24. Модель «Диаграмма типов информационных систем» — VACD/ASTD.

Часть 7.

Методология, применяемая консалтинговыми компаниями

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

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

Модель верхнего уровня и принципы ее построения представлена на рис. 25.

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

Модель бизнес-процессов нижнего уровня, использующая подход «Swimmer lanes» представлена на рис. 26.

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

Методология Betec (©)

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

Стратегия;

Бизнес-процессы;

Оргструктура;

Финансы;

Персонал;

Маркетинг.

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

Читать полностью: https://www.km.ru/referats/80a6343015b8443393cbe203c7df7c3b

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

Модель «Дерево бизнес-процессов» описывает бизнес-процессы, выполняемые в компании и их иерархию (рис. 24). На верхнем уровне дерева бизнес-процессы делятся на три группы: основные, обеспечивающие и управленческие.

Модель «Диаграмм окружения процесса» позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов (рис. 25).

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

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

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

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

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

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

В случае если в проекте была описана внутренняя структура информационных потоков, то на схеме процесса показывается соответствие между элементами информационных потоков и документами в формате MS Word, описывающих внутреннюю структуру информации (рис. 30).

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

Часть 8.

Семь «золотых» правил описания бизнес-процессов

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

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

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

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

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

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

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

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

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

Правило 4. Создавайте схемы деятельности, а не организационных структур.

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

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

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

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

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

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

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

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

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

Правило 7. Не смешивайте понятия «как есть», » как должно быть», «как будет».

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

Часть 9.

Методы сбора информации при описании бизнес-процессов

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

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

Рабочие семинары;
Интервью;
Вопросники и анкеты;
Документы, существующие в организации.

Рабочие семинары

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

Интервью

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

Правильно сделайте выбор собеседника;

Войдите в доверие к собеседнику, создайте дружелюбную располагающую к общению атмосферу;

Поддерживайте и развивайте контакт с собеседником, стимулируйте собеседника говорить на нужную Вам тему;

Задавайте открытые вопросы — Когда? Как? Кто? Что? Почему? Где? и активно слушайте;

Не перебивайте собеседника лишними вопросами;

Удерживайте нужный логический уровень общения;

Делайте записи;

Подведите итоги, уточните сведения;

Поблагодарите собеседника.

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

Вопросники и анкеты

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

Документы, существующие в организации

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

Источник

Моделирование бизнеса. Основные подходы

Время на прочтение
9 мин

Количество просмотров 77K

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Основные подходы

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

Функциональный;
Процессный;
Ментальный (с применением ментальных карт).

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

Функциональное моделирование

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

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

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

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

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

Правила работы с IDEFO вы можете подробнее изучить, прочитав мою статью накомство с нотацией IDEF0 и пример использования.

Процессное моделирование (моделирование бизнес процессов)

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

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

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

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

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

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

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

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

Ментальный подход (ментальные карты)

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

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

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

Плюсы применения таких ментальных карт очевидны:

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

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

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

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

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

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

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

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

Отличие языков разработки бизнес-моделей в от языков проектирования систем

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

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

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

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

Преимущества разработки моделей бизнеса

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

На самом деле, стандарты и правила – это огромный плюс:

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

Применение моделей бизнеса на практике

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

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

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

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

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

Источник