Введение
1. Моделирование бизнес-процессов
2. Классификация бизнес-процессов
3. Стандарты моделирования бизнес-процессов
Заключение
Список используемых источников
ВВЕДЕНИЕ
Понятие «моделирование бизнес-процессов» пришло в быт большинства аналитиков одновременно с появлением на рынке сложных программных продуктов, предназначенных для комплексной автоматизации управления предприятием.
Подобные системы всегда подразумевают проведение глубокого предпроектного обследования деятельности компании. Результатом этого обследование является экспертное заключение, в котором отдельными пунктами выносятся рекомендации по устранению «узких мест» в управлении деятельностью.
На основании этого заключения, непосредственно перед проектом внедрения системы автоматизации, проводится так называемая реорганизация бизнес-процессов, иногда достаточно серьезная и болезненная для компании. Это и естественно, сложившийся годами коллектив всегда сложно заставить «думать по-новому». Подобные комплексные обследования предприятий всегда являются сложными и существенно отличающимися от случая к случаю задачами.
Для решения подобных задач моделирования сложных систем существуют хорошо обкатанные методологии и стандарты. К таким стандартам относятся методологии семейства IDEF. С их помощью можно эффективно отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.
Моделирование бизнес-процессов позволяет проанализировать не только, как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте.
Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:
- это описание бизнес-процессов предприятия позволяющее руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам - как работают их коллеги и на какой конечный результат направлена вся их деятельность;
моделирование бизнес-процессов - это эффективное средство поиска возможностей улучшения деятельности предприятия;
моделирование бизнес-процессов - это средство позволяющее предвидеть и минимизировать риски, возникающие на различных этапах реорганизации деятельности предприятия;
моделирование бизнес-процессов - это метод, позволяющий дать стоимостную оценку каждому процессу, взятому в отдельности, и всем бизнес-процессам на предприятии, взятым в совокупности .
Современные предприятия вынуждены постоянно заниматься улучшением своей деятельности. Это требует разработки новых технологий и приемов ведения бизнеса, повышения качества конечных результатов деятельности и, конечно, внедрения новых, более эффективных методов управления и организации деятельности предприятий.
Бизнес-процесс – это логичный, последовательный, взаимосвязанный набор мероприятий, который потребляет ресурсы производителя, создает ценность и выдает результат потребителю. Среди основных причин, побуждающих организацию оптимизировать бизнес-процессы, можно выделить необходимость снижения затрат или длительности производственного цикла, требования, предъявляемые потребителями и государством, внедрение программ управления качеством, слияние компаний, внутриорганизационные противоречия и др.
Моделирование бизнес-процессов – это эффективное средство поиска путей оптимизации деятельности компании, средство прогнозирования и минимизации рисков, возникающих на различных этапах реорганизации предприятия. Этот метод позволяет дать стоимостную оценку каждому отдельному процессу и всем бизнес-процессам организации в совокупности.
Решения по моделированию бизнес-процессов обычно принимается по причинам, представленным на рисунке 1.
Рисунок 1 - Причины, по которым принимается решение по моделированию бизнес-процессов
Моделирование бизнес-процессов затрагивает многие аспекты деятельности компании:
изменение организационной структуры;
оптимизацию функций подразделений и сотрудников;
перераспределение прав и обязанностей руководителей;
изменение внутренних нормативных документов и технологии проведения операций.
Целью моделирования является систематизация знаний о компании и ее бизнес-процессах в наглядной графической форме более удобной для аналитической обработки полученной информации. Модель должна отражать структуру бизнес-процессов организации, детали их выполнения и последовательность документооборота .
Моделирование бизнес-процессов организации включает два этапа структурное и детальное.
Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose. Детальное моделирование выполняется на языке UML.
На этапе структурного моделирования в модели должны быть отражены:
существующая организационная структура;
документы и иные сущности, используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;
структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;
диаграммы взаимодействия для конечных бизнес-процессов, отражающие последовательность создания и перемещения документов (данных, материалов, ресурсов и т.п.) между действующими лицами.
Детальное моделирование бизнес-процессов выполняется в той же модели и должно отражать требуемую детализацию и должна обеспечить однозначное представление о деятельности организации.
Детальная модель бизнес-процесса должна включать:
набор прецедентов отражающих возможные варианты выполнения бизнес-процессов «как есть»;
диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;
диаграммы взаимодействия, отражающие схемы документооборота.
Бизнес-операция - совокупность действий, процедур, составляющих содержание одного акта бизнес-деятельности.
Бизнес-операция обычно начинается с производства или закупки партии товара по заранее намеченному плану действий и завершается продажей товара и получением прибыли. Бизнес-операции называют также сделками .
Бизнес-функция – это задача, которую решает компания для собственного выживания и для достижения поставленных целей. Функция отвечает на вопрос что делать . Разумеется, в рамках компании можно выделить множество функций. Так любая бизнес-система должна обладать такими функциями, как управление финансами, производство, продажи.
Бизнес-Модель - это то, что делает компания и благодаря чему она зарабатывает деньги (Том Мэлоун)
Бизнес-стратегия есть теория, бизнес-модель - гипотеза (Николас Карр)
Бизнес-модель - это представление набора связанных модельных элементов, определяющих внутреннюю и внешнюю среду компании в рамках единой системы .
2. КЛАССИФИКАЦИЯ БИЗНЕС-ПРОЦЕССОВ
Выделяют следующую классификацию :
В зависимости от места бизнес-процессов в организационной структуре компании выделяют следующие бизнес-процессы:
горизонтальные процессы – процессы, отражающие взаимодействие по горизонтали;
индивидуальные горизонтальные процессы – процессы, выполняемые отдельными работниками (организационными единицами);
межфункциональные горизонтальные процессы – процессы, выполняемые многими работниками (организационными единицами);
вертикальные процессы – процессы, отражающие взаимодействие работников (организационных единиц) по вертикали;
интегрированные процессы – процессы, отображающие взаимодействие участников процессов по вертикали и по горизонтали.
В зависимости от степени их сложности выделяют:
монопроцессы – односложные процессы;
вложенные процессы - монопроцессы, входящие в состав более сложного процесса (макропроцесса);
связанные процессы – выделенные и последовательно реализуемые по определенному алгоритму монопроцессы.
В зависимости от их предназначения:
основные бизнес-процессы – горизонтальные бизнес-процессы, обеспечивающие выполнение реальных операционных задач, связанных с созданием продукта и реализацию его клиенту; - это процессы, операции которых имеют прямое отношение к продукту предприятия и тем самым влияют на создание добавленной стоимости;
поддерживающие бизнес–процессы – горизонтальные бизнес-процессы, обеспечивающие исполнение основных процессов, они не имеют непосредственного отношения к производимым товарам и услугам, однако, без них невозможно выполнение операций по созданию добавленной стоимости;
бизнес-процессы управления – вертикальные бизнес-процессы, обеспечивающие управление деятельностью компании, основными и поддерживающими бизнес-процессами. Это процессы формирования стратегии, планирования бизнеса и контроля.
В зависимости от их места в иерархии целей организации:
бизнес-процессы верхнего уровня – процессы, направленные на реализацию стратегических целей компании, наиболее значимые для компании;
бизнес-процессы среднего уровня – бизнес-процессы, направленные на реализацию тактических целей;
бизнес-процессы нижнего уровня бизнес-процессы, направленные на реализацию оперативных целей.
В зависимости от степени их детализации :
макропроцессы – укрупненные бизнес-процессы имеющие степень детализации необходимую чтобы описать бизнес-процессы верхнего уровня;
субпроцессы – бизнес-процессы имеющие степень детализации необходимую для описания бизнес-процессов среднего уровня;
микропроцессы – бизнес-процессы, имеющие предельно максимальную степень детализации, используются для описания бизнес-процессов нижнего уровня.
В рамках основных составляющих сбалансированной системы показателей:
финансовые бизнес-процессы;
клиентские бизнес-процессы;
бизнес – процессы производства;
бизнес-процессы развития, обучения и роста.
Стандарт функционального моделирования IDEF0
Стандарт IDEF0 считается классическим методом процессного подхода к управлению. Основной принцип процессного подхода заключается в структурировании деятельности организации в соответствии с ее бизнес-процессами, а не организационно-штатной структурой. Именно бизнес-процессы, формирующие значимый для потребителя результат, представляют ценность, и именно их улучшением предстоит в дальнейшем заниматься.
Стандарт IDEF 0 представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.
Модель IDEF 0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы. Общее число уровней в модели (включая контекстный) не должно превышать 5-6. Практика показывает, что этого вполне достаточно для построения полной функциональной модели современного предприятия любой отрасли .
Стандарт информационного моделирования IDEF1
Стандарт IDEF1 был разработан как инструмент для анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия. Применение методологии IDEF1 как инструмента построения наглядной модели информационной структуры предприятия по принципу «как должно быть». Пример построения модели показан на рисунке 2.
Рисунок 2 – Пример построения модели IDEF1
Основными составляющими компонентами информационной модели являются:
диаграммы – структурные изображения информационной модели, представляющие, в соответствии с набором правил, состав и логические связи используемых данных;
словарь – значение каждого элемента модели описывается текстовым фрагментом.
Базовым понятием в методологии IDEF1 является понятие сущности. Сущность определяется как реальный или абстрактный объект, набор отличительных свойств которого, называемых атрибутами, известен. Каждая сущность имеет имя и атрибуты .
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д.
Процесс на диаграмме потоков данных изображается, как показано на рисунке 4.
Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: "Ввести сведения о налогоплательщиках", "Выдать информацию о текущих расходах", "Проверить поступление денег".
Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс.
Накопитель данных - это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д.
Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать модели данных.
Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее его содержание.
Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними .
ЗАКЛЮЧЕНИЕ
В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3–5 является теоретическим, а к IDEF0 вполне практически обоснованным.
Тем не менее, большинство руководителей до сих пор расценивают практическое применение моделирования в стандартах IDEF скорее как дань моде, нежели чем эффективный путь оптимизации существующей системы управления бизнесом. Вероятнее всего это связано с ярко выраженным недостатком информации по практическому применению этих методологий и с непременным софтверным уклоном абсолютного большинства публикаций.
Не секрет, что практически все проекты обследования и анализа финансовой и хозяйственной деятельности предприятий сейчас в России, так или иначе, связаны с построением автоматизированных систем управления. Благодаря этому, стандарты IDEF в понимании большинства стали условно неотделимы от внедрения информационных технологий, хотя с их помощью порой можно эффективно решать даже небольшие локальные задачи, буквально при помощи карандаша и бумаги.
В заключении хочется подчеркнуть, что главное достоинство идеи анализа бизнес-процессов предприятия посредством создания его модели – ее универсальность. Во-первых, моделирование бизнес-процессов это ответ практически на все вопросы, касающиеся совершенствования деятельности предприятия и повышения его конкурентоспособности. Во-вторых, руководитель или руководство предприятия, внедрившие у себя эту методологию, будут иметь информацию, которая позволит самостоятельно совершенствовать свое предприятие и прогнозировать его будущее.
1. Войнов И.В. Моделирование экономических систем и процессов. Опыт построения ARIS-моделей [Текст]: монография / И.В. Войнов – М.: ЮУрГУ, 2002. – 392 с.
2. Волков О.Н. Стандарты и методологии моделирования бизнес-процессов [Текст]: учеб. пособие для вузов / О.Н. Волков. – М.: АСВ, 2000. – 145 с.
3. Григорьев Д.И. Моделирование бизнес-процессов предприятия [Текст]: учеб. пособие / Д.И. Григорьев. – М.: ИРЦ, 2006. – 214 с.
4. Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов [Текст]: учеб. пособие / Г.Н. Калянов. – М.: Финансы и статистика, 2006. – 319 с.
5. Пинаев Д.К. Моделирование бизнес-процессов: доступно о сложном [Текст]: справ. пособие / Д.К. Пинаев. – М.: РГАС, 2003. – 247 с.
Нужна помощь по изучению какой-либы темы?
Наши специалисты проконсультируют или окажут репетиторские услуги по интересующей вас тематике.
Отправь заявку
с указанием темы прямо сейчас, чтобы узнать о возможности получения консультации.
Моделирование бизнес процессов является одним из методов улучшения качества и эффективности работы организации. В основе этого метода лежит описание процесса через различные элементы, такие как действия, данные, события, материалы, присущие процессу. Как правило, моделирование бизнес процессов описывает логическую взаимосвязь всех элементов процесса от его начала до завершения в рамках организации. В более сложных ситуациях моделирование может включать в себя внешние по отношению к организации процессы или системы.
Моделирование бизнес процессов позволяет понять работу и провести анализ организации. Это достигается за счет того, что модели могут быть составлены по различным аспектам и уровням управления. В больших организациях моделирование бизнес процессов выполняется более подробно и многограннее, чем в малых, что связано с большим количеством кросс-функциональных связей.
Моделирование бизнес-процессов позволяет проанализировать не только, как работает предприятие в целом, как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом отдельно взятом рабочем месте.
Существует несколько подходов к определению понятия «моделирование бизнес-процессов»:
Современные предприятия вынуждены постоянно заниматься улучшением своей деятельности. Это требует разработки новых технологий и приемов ведения бизнеса, повышения качества конечных результатов деятельности и, конечно, внедрения новых, более эффективных методов управления и организации деятельности предприятий.
Обычно для моделирования бизнес-процессов применяются различные компьютерные средства и программное обеспечение. Это облегчает управление моделями, отслеживание в них изменений и позволяет сократить время анализа.
Моделирование бизнес-процессов включает следующие цели:
Модель бизнес-процесса должна определять:
Моделирование бизнес процессов, как правило, включает в себя выполнение нескольких последовательных стадий. Т.к. конечной целью моделирования является улучшение процессов, то оно охватывает и «проектную» часть работы, и работы по внедрению моделей процессов.
Состав стадий, которые включает в себя моделирование бизнес процессов следующий:
В зависимости от желаемой цели моделирования бизнес-процессов, для унификации собранной информации о процессе или получения новой, применяют следующие виды моделирования:
Одна и та же информационная характеристика бизнес-процесса может быть отражена на разных моделях. Так же на одной модели могут располагаться объекты бизнес-процесса разной природы происхождения.
На сегодняшний день существует достаточно большое количество методов моделирования бизнес-процессов. Эти методы относятся к разным видам моделирования и позволяют сфокусировать внимание на различных аспектах. Они содержат как графические, так и текстовые средства, за счет которых можно наглядно представить основные компоненты процесса и дать точные определения параметров и связей элементов.
Наиболее часто моделирование бизнес-процессов выполняют с помощью следующих методов:
Большинство из указанных методов реализованы в виде программного обеспечения. Оно позволяет осуществлять поддержку бизнес-процессов или проводить их анализ.
Выбор инструментальных средств моделирования и методов
Одним из первых и основных этапов проекта по описанию бизнес-процессов компании является выбор методов и инструментальных средств моделирования.
В настоящее время на рынке программного обеспечения есть большое количество продуктов, предназначенных для моделирования деятельности предприятия, в основу каждого из них заложена определенная методология.
В целом выделяют два подхода к моделированию.
Структурно-алгоритмический – основными строительными блоками модели при использовании данного подхода являются функции (процедуры). Модель представляет собой выстроенную последовательность функций, при этом имеется возможность их декомпозиции на составные части; на вход каждой функции поступают некоторые данные, на выходе имеются определенные результаты ее выполнения, показывается ресурсное окружение функции – люди, информационные системы, регламенты.
К этому блоку относится методология IDEF; инструментом, реализующим данную методологию, является BPWin.
Объектно-ориентированный подход предполагает использование объектов – сущностей, обладающих идентичностью, состоянием и поведением. Модель в данном случае представляет собой всестороннее описание объекта исследования – кроме описания собственно бизнес-процесса, в ней содержится описание: организационной структуры предприятия, структуры информационных систем, операционных и регламентирующих документов. При моделировании в соответствии с объектно-ориентированным подходом создается единая база данных объектов модели, благодаря этому появляется возможность отслеживания взаимосвязей между объектами и безызбыточности построенной модели.
Методологии, поддерживающие объектно-ориентированный принцип: методология Aris (группа продуктов IDS Sheer «Aris») и методология UML (продукт Rational Rose). Методология UML в основном ориентирована на разработку программного обеспечения, Aris используется для описания бизнес-процессов предприятия.
Aris в том числе предоставляет возможность оценки процессов по заданным параметрам, например с точки зрения времени и стоимости их выполнения.
При моделировании деятельности организации в случае обоснования необходимости возможна интеграция нескольких систем, в этом случае в их состав должны входить соответствующие механизмы экспорта/импорта.
В России для моделирования и анализа бизнес-процессов достаточно широко используются следующие средства моделирования: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer. За рубежом, помимо упомянутых, активно используются такие средства, как System Architect, Ithink Analyst, ReThink и др. В табл. 5 представлен перечень инструментальных средств, участвующих в рассмотрении. Приведенная информация включает:
? наименование инструментального средства;
? данные о поставщике и представителе в России;
? краткую характеристику инструментального средства.
Выделим основные критерии, позволяющие из представленных средств моделирования выбрать те, применение которых в России могло бы с большей вероятностью себя оправдать. Такими критериями являются:
? устойчивое положение продукта на рынке (срок его существования, программа развития продукта, система отчетов о проблемах, совокупность применений и др.);
? распространенность продукта (количество проданных лицензий, наличие, размер и уровень деятельности пользовательской группы);
? доступность поддержки поставщика. Такие услуги могут включать телефонную «горячую линию», техническую и консультационную поддержку через представителя поставщика в России;
? доступность обучения. Обучение может проводиться на территории представителя поставщика в России, пользователя или где-либо в другом месте;
? доступность материалов по продукту. Они могут включать компьютерные учебные материалы, учебные пособия, книги, статьи, информацию в Интернете, демоверсии.
Из приведенного в таблице списка инструментальных средств для более подробного анализа выделим те программные продукты, которые удовлетворяют указанным критериям. В этом случае в рамки нашего дальнейшего рассмотрения попадают BPWIn/ERWin, Oracle Designer, Rational Rose, Power Designer, ARIS, по которым ниже представлено более подробное описание.
BPWin и ERWin компании СотрШвгAssociates. Computer Associates International, Inc. (CA) входит в пятерку ведущих производителей программного обеспечения, предлагая средства моделирования, резервного копирования, управления инфраструктурой предприятия (сетями, серверами и т. д.), информационной безопасности, business intelligence и т. д. Пакет BPWin основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Методология IDEF, являющаяся официальным федеральным стандартом США, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями.
Возможности BPwin:
? поддерживает сразу три стандартные нотации – IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;
? позволяет оптимизировать процедуры в компании;
? полностью поддерживает методы расчета себестоимости по объему хозяйственной деятельности (функционально-стоимостной анализ, ABC);
? позволяет облегчить сертификацию на соответствие стандартам качества ISO9000;
? интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.;
? интегрирован со средством имитационного моделирования Arena;
? содержит собственный генератор отчетов;
? позволяет эффективно манипулировать моделями – сливать и расщеплять их;
? имеет широкий набор средств документирования моделей, проектов.
Пакет ERWin – это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность – связь». В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов. Возможности ERWin:
? поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEFlx для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных – Dimensional;
? поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;
? интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;
? позволяет повторно использовать компоненты созданных ранее моделей, а также использовать наработки других разработчиков;
? возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager);
? позволяет переносить структуру БД (не сами данные!) из СУБД одного типа в СУБД другого;
? позволяет документировать структуру БД.
Oracle Designer компании Oracle. Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web– и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения – от моделирования бизнес-процессов до внедрения. Применение единого репозитория делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений. Задачей Oracle Designer являются сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы. Графические модели определений проекта, интегрированные с многопользовательским репозиторием, существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки и позволяющих пользователям осуществлять построение моделей привычным для их организации способом. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода и др. Пользуясь этими принципами, можно добиться успешного баланса организационных потребностей и технологических возможностей и даже эффективно управлять риском, связанным с частыми неизбежными и важными изменениями как в одной, так и в другой области. Средства концептуального моделирования Oracle Designer включают в себя:
? ER-диаграммы (диаграммы информационной структуры предметной области, представляемой в виде объектов и их взаимосвязей);
? диаграммы функциональной иерархии, описывающие функции, которые выполняет система;
? диаграммы потоков данных, циркулирующих на предприятии.
Такие модели представляют информационные потребности в удобном и наглядном для восприятия виде, что делает их хорошим средством коммуникации между проектировщиками и пользователями в процессе уточнения постановки задач. Любой разработчик заинтересован, чтобы описание концептуальной модели было использовано для создания спецификаций, описывающих структуру и основные компоненты будущей системы. В Oracle Designer все спецификации проекта системы разрабатываются на основе моделей концептуального уровня и обеспечивают выполнение всех содержащихся в них требований и ограничений. Полученные компоненты системы могут быть преобразованы в реальные объекты базы данных, экранные формы и отчеты. Финальная часть разработки проекта – автоматическая генерация серверных компонентов – возможна не только для сервера БД Oracle, но и для СУБД Microsoft SQL Server, DB/2, Sybase и ряда других. Любые изменения бизнес-процессов могут быть внесены в модели, и тут же будет сгенерировано модифицированное приложение, основывающееся уже на новых схемах ведения бизнеса. При этом все разработанное ранее будет сохранено и войдет в новый проект. Огаск Designer автоматически создает отчеты, которые содержат всю информацию о проекте и могут быть использованы как набор документов, отражающих текущее состояние проекта.
Rational Rose компании IBM. IBM Rational Rose входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Rational Rose является одним из ведущих инструментов визуального моделирования в программной индустрии благодаря полноценной поддержке языка UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС. Любые участники проекта – аналитики, специалисты по моделированию, разработчики и др. – могут использовать модели, построенные в Rational Rose, для большей эффективности создания конечного продукта. Для бизнес-аналитиков средство Rational Rose дает возможность детально описать и проанализировать бизнес-процессы данной предметной области. Системные аналитики, используя указанные описания, смогут разработать необходимый функционал ИС, который максимально удовлетворит запросы заказчика. Для архитекторов средство Rational Rose будет полезно при создании мощной и гибкой архитектуры системы. Для аналитиков, специализирующихся в области разработки баз данных, Rational Rose даст возможность визуально проектировать и генерировать базы данных любого размера. Таким образом, можно создавать базы данных Microsoft SQL Server, Oracle, Sybase, SQL Anywhere, IBM DB2 и любые другие, которые поддерживают возможность запуска скриптов стандарта ANSI SQL. Любые модели, создаваемые с помощью данного средства, являются взаимосвязанными: бизнес-модель, функциональная модель, модель анализа, модель проектирования, модель базы данных, модель компонентов и модель физического развертывания системы. Есть возможность по созданию шаблонов архитектурных решений, позволяющих использовать опыт, накопленный в предыдущих проектах. Существуют расширения Rational Rose, которые позволяют выполнять скелетную (round-trip) разработку ИС, создаваемых на базе языков C/C+ +, Java, Smalltalk, Ada, Object Pascal (Borland Delphi) и др. Таким образом, можно сгенерировать каркас программного кода на любом из указанных языков или выполнить процедуру обратного проектирования, что позволяет сформировать модель на базе существующего кода. Есть возможность публикации модели в Интернете, которая служит основой для объединения работы удаленных команд разработчиков. Интеграция Rational Rose с Rational RequisitePro позволяет на базе визуальной модели разработать полный набор требований, которые необходимо реализовать при создании конечного продукта. Интеграция Rational Rose с Rational TestManager дает возможность создавать сценарии тестирования на базе визуальной модели. Интеграция Rational Rose с Rational ClearCase позволяет поставить на версионный контроль модель целиком или по частям. Интеграция Rational Rose с Rational SoDA позволяет автоматизировать процесс создания документов и отчетов по визуальной модели.
PowerDesigner компании Sybase. Компания Sybase со дня своего основания традиционно является ведущим поставщиком информационных технологий на мировой рынок финансовых институтов: технологии Sybase используют 90 % компаний мирового рынка ценных бумаг, 60 % мировых банков и 68 % компаний Wall Street. С 1996 года, когда открылся офис в Москве, Sybase активно работает в России и других странах СНГ. В апреле 2002 года открылись офисы компании в Санкт-Петербурге и Киеве. Офисы Sybase в Москве, Санкт-Петербурге и Киеве обеспечивают всестороннюю работу с клиентами, включая поставки технологий, оборудования, разработку законченных решений, обучение пользователей, полнофункциональную техническую поддержку и услуги консалтинга. PowerDesigner является комплексным решением для моделирования и разработки приложений и бизнес-процессов для организаций, которые нуждаются в быстром, последовательном и эффективном с точки зрения затрат создании или реинжиниринге бизнес-приложений. PowerDesigner позволяет устранить следующие препятствия, мешающие эффективной разработке проектов: различия в профессиональной подготовке участников проекта, разнородные платформы и изобилие языков разработки – то, что характерно для большинства современных компаний. Это позволяет фокусироваться на бизнес-потребностях создания приложений на протяжении всего процесса разработки – от системного анализа и дизайна вплоть до непосредственной генерации кода для приложения. Последняя версия продукта, PowerDesigner, обладает новыми возможностями по моделированию бизнес-процессов, объектному моделированию, базирующемуся на UML, и поддерживает как традиционные, так и вновь появляющиеся технологии моделирования в рамках одной развитой графической среды. Это позволяет значительно сократить затраты и время реализации проекта, который должен функционировать на различных платформах и инструментальных средах. Одним из основных преимуществ PowerDesigner является также использование репозитория масштаба предприятия для хранения и управления всей информацией, касающейся моделирования и дизайна приложений на всех уровнях ведения бизнеса в компании. Это дает возможность правильно организовать рабочий процесс и кардинальным образом повысить эффективность работы разработчика. Ключевые характеристики PowerDesigner:
? моделирование бизнес-процессов: PowerDesigner позволяет нетехническим специалистам компании разрабатывать и моделировать бизнес-процессы, ориентируясь на бизнес-задачи и опираясь на известные им термины, используя простую и интуитивно понятную графическую нетехническую модель;
? моделирование данных: PowerDesigner позволяет разрабатывать и генерировать схему БД посредством двухуровневого (концептуального и физического) моделирования реляционной БД, поддерживающего классические методики проектирования баз данных. Имеет также встроенные средства моделирования хранилища данных;
? объектное моделирование: PowerDesigner предлагает законченную технологию анализа и проектирования систем с использованием стандарта UML (диаграммы бизнес-процессов, последовательности выполнения, классов и компонентов). На основе диаграммы классов PowerDesigner автоматически осуществляет генерацию и реинжиниринг кода для популярных инструментальных сред, таких как JavaTM (включая EJB 2.0), XML, Web Servicies, C+ +, PowerBuilder, Visual Basic и др., посредством настраиваемого генератора;
? репозиторий масштаба предприятия: Enterprise-версия PowerDesigner содержит функциональность репозитория класса предприятия. Репозиторий позволяет всем членам вашей команды легко просматривать модели и другую информацию, а также осуществлять обмен ими. Репозиторий обладает высокой масштабируемостью и поддерживает систему безопасности, основанную на роли пользователя, контроль версий, поиск и возможности составления отчетов.
ARIS компании IDS Scheer AG. В настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS, разработанный германской фирмой IDS Scheer. Компания IDS Sheer AG основана в 1984 г. Основное направление – программное обеспечение и консалтинг. В настоящее время компания обслуживает 4000 клиентов в 50 странах мира через сеть своих представительств и партнеров. Качество решений IDS Scheer было подтверждено в июне 2005 года золотой медалью Международной познаньской ярмарки, на которой награждаются только лучшие продукты. А также в июле 2005 года, когда на мировом рынке была представлены программные продукты ARIS 7 с абсолютно новыми Web-продуктами; все они имеют общую черту – интуитивно понятный и выразительный интерфейс. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что дает возможность использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику. Методика моделирования ARIS основывается на разработанной профессором Августом Шером теории построения интегрированных ИС, определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
? организационные модели, представляющие структуру системы – иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений;
? функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей;
? информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
? модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.
Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования, в частности ER и UML. В процессе моделирования каждый аспект деятельности предприятия сначала рассматривается отдельно, а после детальной проработки всех аспектов строится интегрированная модель, отражающая все связи между различными аспектами. ARIS не накладывает ограничений на последовательность построения указанных выше типов моделей. Процесс моделирования можно начинать с любого из них, в зависимости от конкретных условий и целей, преследуемых разработчиками. Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты – «функция», «событие», «структурное подразделение», «документ» и т. п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа. Таким образом, по результатам выполнения этого этапа возникает набор взаимосвязанных моделей, представляющих собой исходный материал для дальнейшего анализа. Стоит отметить несколько особенностей системы ARIS. Первая – семейство программных продуктов ARIS ориентировано на процессное описание. Основная бизнес-модель ARIS – eEPC (extended Event-driven Process Chain – расширенная модель цепочки процессов, управляемых событиями). По существу, модель eEPC расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Вторая особенность – в системе ARIS есть внутренняя база данных, которая позволяет проверять модель на непротиворечивость, целостность, проводить верификацию модели. В других продуктах это отсутствует. Третья особенность: ARIS – единственная система, ориентированная на описание бизнеса, где присутствуют различные взгляды на бизнес-систему, которую мы можем оценить и рассмотреть с разных сторон, чего нет в других программных продуктах. В течение последних пяти лет ARIS уверенно лидирует среди средств моделирования.
Укажем основное предназначение каждого рассматриваемого продукта из множества его применений:
? для моделирования баз данных больше подходят инструменты Erwin, Power Designer и Rational Rose;
? для моделирования компонентов разрабатываемых приложений больше подходят Oracle Designer, Power Designer и Rational Rose;
? для моделирования бизнес-процессов больше подходят BPwin, ARIS и Rational Rose.
В табл. 6 приводится сравнение функциональных возможностей и свойств инструментальных сред, предназначенных для моделирования бизнес-процессов.
Общие требования, выдвигаемые к среде моделирования, следующие. Необходимо исходить, что разработанные модели будут часто подвержены изменениям. Это обусловлено рядом объективных обстоятельств:
1) появлением новых внутренних регламентов взаимодействия, изменений внешней среды – требований клиентов к предоставляемым продуктам и услугам, активности конкурентов и др.;
2) модернизацией и появлением новых автоматизированных процедур вследствие развития ИС;
3) поэтапной детализацией отдельных подпроцессов в силу изначальной недостаточной алгоритмизации отдельных процедур деятельности организации;
4) оптимизацией моделей, в том числе в рамках состава рассчитываемых показателей и критериев их оценки.
По этой причине спроектированная на инструменте моделирования архитектура базовых компонент модели должна быть таковой, чтобы безболезненно (или с минимальными потерями) обеспечить дополнение новых подпроцессов, расширение состава атрибутов, возможность построения метамоделей и комплексных моделей в условиях существенного различия в уровнях детализации описания моделей, входящих в общую совокупность.
К числу ключевых характеристик, которые могут быть использованы при сопоставлении возможностей инструментальных средств моделирования, относятся:
? наличие и удобство реализации иерархического подхода;
? поддержка различных уровней абстракции;
? формальный язык и система обозначений;
? интеграционные возможности;
? средства анализа;
? методологическая база;
? наличие прототипов формализованных бизнес-процессов применительно к различным предметным областям.
При осуществлении выбора инструментальной среды можно использовать достаточно известные магические квадранты Gartner. И хотя основным предназначением этого представления является сравнение не технологий или продуктов, а главным образом их поставщиков, тем не менее они дают полезную информацию для последующего решения по платформе.
Вид магического квадранта Gartner для средств моделирования показан на рис. 6. В рамках данного представления положение каждого вендора отображается в координатах «функциональные возможности» – «полнота представления». Функциональные возможности оцениваются по уоловной шкале с учетом таких факторов, как наличие стратегического плана развития продукта, соответствие общим тенденциям развития данной технологии, адекватность анализу и соответствие спросу рынка. Полнота представления оценивается исходя из финансового потенциала компании-производителя в целом, организации исследований и разработок, наличия стратегии и системы маркетинга и продаж, а также возможностей по поддержке и участию в альянсах.
В рамках используемого представления выделяются четыре квадранта, которые определяют следующее категорирование поставщиков решений: нишевые игроки, мечтатели, претенденты, лидеры.
К категории «нишевые игроки» относятся компании, продуктовые решения которых реализуются в специализированных областях, или имеющие существенные отставания от конкурентов в части наличия инноваций и способности их реализации.
К категории «претенденты» относятся компании, имеющие высокий потенциал реализации своих продуктовых решений, но недостаточно четкое видение перспектив развития технологий и продуктов.
К категории «лидеры» относятся компании, оказывающие наибольшее влияние на развитие рынка в анализируемой области с точки зрения как понимания перспектив, так и возможностей по их реализации. Лидеры не только обладают преимуществами перед конкурентами на текущий момент, но и имеют высокие шансы на сохранение своих позиций в будущем в рассматриваемой технологической области.
Принципиальным моментом является комплексность оценок, реализуемых в квадранте. Позиционирование компании осуществляется не характеристиками отдельных продуктов или их версий, а общим потенциалом компании с учетом реализуемой бизнес-модели в конкретной области, организации поддержки, функциональности продукта или услуги, а также применяемой технологии. По этой причине сравнение квадрантов для одной и той же области, построенных в разное время (обычно Gartner выпускает версии каждые полгода), может иметь существенные различия.
Необходимо отметить, что выбор инструментальных средств моделирования должен сопровождаться либо происходить в контексте выбора методик моделирования бизнес-архитектуры предприятия.
Исходя из этого, выбор инструментальной среды предусматривает в общем следующие работы (включая соответствующее документирование результатов):
1) обоснование состава методов моделирования с учетом состава и особенностей системообразующих элементов бизнес-процессов;
2) определение общих требований к средствам разработки моделей процессов;
3) проведение сравнительного анализа современного рынка инструментальных средств моделирования и выбор оптимального варианта.
Из книги Инвестиционные проекты: от моделирования до реализации автора Волков Алексей Сергеевич2.1. Общая логика экономического и финансового моделирования Любое сознательное действие имеет первопричину, в голове человека зреет план действий. А действия, связанные с длительными и серьезными последствиями, тем более должны быть обдуманными. Поэтому люди строят в
Из книги Учет и налогообложение расходов на страхование работников автора Никаноров П ССтатья 11. Выбор инвестиционного портфеля (управляющей компании), перевод средств пенсионных накоплений в негосударственный пенсионный фонд 1. Застрахованные лица вправе выбрать инвестиционный портфель (управляющую компанию) либо перевести средства пенсионных
Из книги Финансы и кредит автора Шевчук Денис Александрович76. Роль чистого оборотного капитала (собственных оборотных средств), кредитов и займов, кредиторской задолженности, привлеченных источников. Выбор стратегии Чистый оборотный капитал (Чистый рабочий капитал, Net Working Capital, NWC) - разность между величиной текущих активов и
Из книги Практика и проблематика моделирования бизнес-процессов автора Всяких Е ИОпределение моделирования Объектом моделирования может выступать любая сущность, описанные в книге подходы универсальны и могут быть применимы как к архитектуре корпоративной информационной системы или компании в целом, так и при проектировании отдельных
Из книги Обеспечение информационной безопасности бизнеса автора Андрианов В. В.Общие принципы моделирования Перед тем как дать описание основных используемых на сегодняшний день методов моделирования, укажем общие принципы и особенности, которые должны быть учтены при построении модели.1. Принцип осуществимости. Создаваемая модель прежде всего
Из книги Механизмы и методы регулирования в условиях преодоления кризиса автора Автор неизвестенОсновные методики моделирования Необходимо отметить, что постановка задачи по построению модели объекта определяется фиксированием ряда таких составляющих, как:? используемые методики проектирования моделей;? формализация (нотация);? лингвистическое обеспечение
Из книги Экономический анализ. Шпаргалки автора Ольшевская НатальяГлава 4 Современные инструментальные средства моделирования бизнес-процессов. Как выбирать инструментальную среду для
Из книги Как работать где хочешь, сколько хочешь и получать стабильный доход автора Фокс Скотт4.2.1. Цели моделирования угроз Моделирование угроз ИБ от персонала является элементом деятельности организации по анализу и оценке соответствующих рисков. С помощью собственной модели угроз ИБ от персонала организация может формализовать имеющиеся у нее знания о таких
Из книги Финансовый менеджмент – это просто [Базовый курс для руководителей и начинающих специалистов] автора Герасименко Алексей2.7. Выбор методов регулирования в условиях преодоления кризиса: кейнсианство или монетаризм? Вопросы, связанные с местом, ролью и функциями государства в экономике, занимали ученых с самого возникновения экономической науки. В мировой экономической литературе
Из книги Практика управления человеческими ресурсами автора Армстронг Майкл52. Выбор методов Проведение аналитических расчетов связано с целенаправленным выбором совокупности методов и приемов, подходящих для анализа и особенностей анализируемой ситуации. При выборе методов необходимо обеспечить функциональную полноту анализа при
Из книги Управление качеством. Практикум автора Ржевская СветланаДобро пожаловать в мир моделирования стиля жизни Вуаля! Вы создали для себя стиль жизни, благодаря которому зарабатываете, общаясь с французами – все как вы мечтали. Вы больше не связываете успех со своей основной работой. Вы вложили свое время в изучение французского
Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон ДжонВаш Список покупок для моделирования стиля жизни Вы обдумали, что вам нравится и не нравится в жизни, изучили, что важнее всего изменить. Теперь пришло время подводить итоги. Вернемся к вашему Журналу идей, чтобы создать итоговый список ответов на приведенные ниже
Из книги автораВыбор между вариантами заемных средств Обычно у финансового директора есть выбор между несколькими возможными источниками и способами финансирования. Как в этом случае нужно сделать выбор? Обычно в этом случае вы будете руководствоваться сначала стратегическими
Из книги автораВЫБОР МЕТОДОВ ОТБОРА Можно выбирать среди основных методов отбора. Анкеты, интервью и рекомендации – это то, что М. Кук (1993) называет классическим трио. Их можно дополнить или заменить биографиями, оценочными центрами и психологическими тестами, которые описаны в данной
Из книги автора3.1 Выбор статистического метода (методов) дая решения пробаемы Анализ процессов – это упорядоченное исследование осуществляемое с помощью количественных инструментов и методов с целью оценки характеристики процессов, выявления любой неадекватности и вызывающих ее
Из книги автораЭлементы условных соглашений моделирования 1. Контроль версий.2. Содержание.3. ЧАСТЬ I – ВВЕДЕНИЕa. Введение в документ об условных соглашениях:i. Цель введения условных соглашений.ii. Кому предназначен документ.iii. Как пользоваться документом (отдельно по каждой целевой
В этой статье я хочу поговорить об основных принципах моделирования бизнеса, о тех подходах, которые применяются в этой сфере, и на основе которых создаются языки моделирования и нотации.
Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.
С одной стороны, применение схем для наглядности при описании моделей бизнеса в ни у кого не вызывает вопросов. Это действительно очень удобно. С другой стороны, многие бизнесмены и даже мои коллеги недоумевают, зачем нужны специальные нотации и правила для разработки бизнес-процессов, ведь можно в любом графическом редакторе (visio) или при помощи других удобных инструментов просто нарисовать интуитивно понятную схему.
О том, почему так важна стандартизация, а также о том, в каком случае применяется тот или иной подход, я и хочу поговорить.
Функциональное моделирование рассматривает бизнес как функцию (лат. functio - совершение, исполнение) или иными словами «черный ящик». В функциональной модели функция не имеет временной последовательности, а только точку входа и точку выхода. Функциональное моделирование помогает рассматривать бизнес-модель с с точки зрения результативности, т.е. при моделировании мы исходим из того, что имеем на входе, и того, что желаем получить на выходе.
Например, компания разрабатывает какую-то CRM-систему для своего бизнеса. В случае применения функционального подхода к моделированию уже сама выбранная среда для работы подсказывает, с чего начинать. Точка входа – «входящий интерес клиента или лид», точка выхода – желаемый результат: «покупка и получение лояльного клиента», «получение постоянного клиента», «получение максимум информации о потенциальном клиенте» и т.д.
Таким образом, в функциональной модели изначально известны точка входа и желаемый результат, а последовательность действий и является объектом разработки. При этом использование функциональных моделей как «черных ящиков» позволяет детализировать каждый этап по мере необходимости. А вся работа при моделировании направлена на поиск оптимального решения для достижения цели.
Функциональные модели вы можете также использовать для демонстрации своих идей и вариантов решений. Это также очень удобно, ведь в процессе демонстрации вы можете двигаться от общего к деталя, по мере необходимости разделять и декомпозировать функции. Но декомпозировать вы будете при этом именно функции, и, разделяя одну функцию на несколько, вы не получите описание процесса.
Некоторые путают описание процесса и функциональную модель. Например, в системе Business Studio функцию называют процессом, хоть это и не совсем верно. Все же описание функций и процессный подход – несколько разные вещи. И я лично считаю, что функциональное моделирование оптимально реализовано в нотации IDEFO. Сам я для такого варианта работы использую именно ее, и всем также рекомендую.
Правила работы с IDEFO вы можете подробнее изучить, прочитав мою статью накомство с нотацией IDEF0 и пример использования.
О процессном моделировании я буду рассказывать с точки зрения нотации BPMN, как одного из наиболее распространенных стандартов процессного моделирования. При этом я полностью согласен, что существует множество языков моделирования и различных систем. И каждый может пользоваться тем, что ему удобнее. Но все же BPMN - это уже сложившийся стандарт процессного моделирования, а потому его я и беру за основу в описании.Процесс с точки зрения бизнес-модели - это последовательность каких-то событий и действий, которые имеют начало и конец.
В этом кроется основное отличие процессного моделирования от функционального. Функциональное моделирование рассматривает бизнес-модель с точки зрения входа и выхода (имеющихся ресурсов и желаемого результата). А процессное основано на последовательности действий в определенных границах, в случае BPMN это будут начало и конец события.
Все процессы могут разбиваться (детализироваться) на подпроцессы вплоть до детализации на уровне задач, т.е. действий, дальнейшая детализация которых невозможна. Процесс – это некая последовательность действий, которую необходимо выполнить, чтобы получить определенный результат. Необходимо отметить что в модели бизнеса как процесса результат может и не быть явным в отличии от функциональной модели.
Принципиальное отличие процессного моделирования от функционального заключается в том, что при процессном моделировании основное внимание уделяется не тому, что мы хотим получить, а тому, что нужно сделать для получения результата, т.е. не итогам той или иной деятельности, а самой последовательности действий.
Например, в BPWIN или Business Studio в процессе детализации каждой функции происходит переход от функционального подхода к процессному. Т.е. в общем, мы рассматриваем модель с точки зрения – возможностей и желаемого результата, а когда переходим к решениям для каждой функции, здесь уже практикуется явно процессный подход, т.е. пошаговый алгоритм действий для достижения результата.
Представьте себе что в функциональной модели есть «черный ящик» - функция «Принять заказ». А при декомпозировании мы уже рассматриваем ее не как функцию, а как процесс, и последовательность действий при приеме заказа – это уже процессный подход.
Есть и еще одно очень важное отличие. Функциональную модель невозможно использовать при реализации какой-то либо системы, только для проектирования. А процессный подход позволяет создавать исполняемые модели, т.е. описания последовательности действий, которые мы можем в дальнейшем перевести в какую-то среду для создания системы совместной работы предприятия, основанной на процессном подходе.
При создании ментальных моделей специалист подходит к моделированию не как к процессу или набору функций, а как к некому набору связанных между собой понятий. Для наглядности я приведу пример - ментальная карта понятия “Процедура снабжения” (см. рисунок).
Такой вариант подхода применяется, прежде всего, для себя. Рисование схемы в свободной форме помогает структурировать свои знания, так сказать, “разложить по полочкам” в свободной форме полученную информацию. Также подобные ментальные карты помогают найти решение, которое уже позже, по мере необходимости, будет воплощаться в рамках строгих правил процессного или функционального подхода.
Можно применять ментальные карты и для демонстрации клиентам: и существующей ситуации, и вариантов решения поставленной задачи. Ментальные карты помогут наглядно продемонстрировать, какие методы могут быть использованы, показать в наглядной форме различные идеи.
Плюсы применения таких ментальных карт очевидны:
В результате для понимания модели и заложенных в ней идей требуется присутствие и комментарии ее разработчика (аналитика).
Конечно, существуют очень простые карты, которые интуитивно читаются и без дополнительных комментариев. Но при отсутствии стандартов всегда есть вероятность, что даже в этом случае автор что-то другое имел в виду или где-то недостаточно детализировал свою схему. Т.е. существует вероятность разного прочтения. А бизнес - это не философия. При всей умозрительности и разнообразии подходов к описанию бизнес-процессов, здесь очень важны однозначные решения.
Методология - это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.
Здесь напрашивается сравнение с программированием вообще и применением конкретного языка программирования. Программирование включает в себя и построение алгоритма, и выбор подходящего языка программирования, и реализацию алгоритма программы в рамках того или иного языка. А, например, программирование на языке Си++ – это уже заведомо ограничение определенными рамками, так как средствами определенного языка можно решить только четко ограниченный круг задач, и, одновременно, даже если задачу можно решить средствами Си++ совсем не обязательно, что именно этот язык будет в конкретном случае оптимальным. В общем, разницу между понятием «программирование» и «программированием в рамках определенного языка», я думаю, большинство понимают даже без таких пояснений.
Основное различие этих языков от языков разработки бизнес-процессов лежит в их предназначении. Если языки проектирования IT-систем рассматривают бизнес-процессы с точки зрения возможности их автоматизации, воплощении в IT-системах, то языки бизнес-моделирования рассматривают последовательность действий именно с точки зрения бизнеса, включая работу как IT-систем, так и сотрудников, движения товаров и т.д.
Соответственно, в языках проектирования систем нет элементов, которые помогут полноценно описать действия подразделений, сотрудников, взаимодействие между ними, работу с поставщиками, общение с клиентами и так далее. Инструменты этой группы языков помогут именно автоматизировать процессы бизнеса, которые поддаются автоматизации. А все остальное будет оставлено «за кадром», например, как некие «функции» без расшифровки.
В то же время языки разработки бизнес-процессов охватывают максимально именно работу бизнеса как такового, а вот те или иные нюансы автоматизации и алгоритмизации систем в них описать далеко не всегда возможно с достаточной степенью детализации.
На самом деле, стандарты и правила – это огромный плюс:
Кроме того, наглядные схемы бизнес-моделей помогают мне в процессе взаимодействия с клиентами. Проекты у меня часто бывают сложными, и обычного текста или устной речи бывает недостаточно для понимания, в то время как использование наглядных бизнес-моделей снижает затраты времени клиента на чтение и понимание моих предложений, и практически исключает проблемы взаимопонимания в этом вопросе. И если несколько лет назад я еще сталкивался с недоумением со стороны клиентов, то сейчас вариант описания «на словах» без наглядных и удобных схем практикуется крайне редко.
А в случае автоматизации какого-либо этапа работы или создания автоматизированной системы управления бизнесом на основе проектно-ориентированного подхода качественная бизнес-модель, выполненная в том или ином языке моделирования, станет готовым руководством для технических специалистов.
Удобство, универсальность, простота восприятия – это те причины, по которым от словесных описаний в бизнес-сфере все больше переходят к бизнес-моделированию. А применение готовых языков позволяет работать с моделями быстро, избегать ошибок, и также без проблем вносить любые изменения.
Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости
Цифровые технологии стремительно врываются во все сферы жизни общества, заставляя нас быть более гибкими и быстро адаптироваться к изменениям. Цифровая трансформация не обошла стороной и бизнес: его выживание в современных условиях зависит, прежде всего, от готовности быстро и кардинально менять методы управления предприятием, объекты которого стали частью единого информационного пространства. Дополнительный импульс в виде обязательной автоматизации получило и управление бизнес-процессами, связывающих в единую модель информационные и человеческие ресурсы.
Каждому руководителю успешной организации сегодня очевиден тот факт, что любые управленческие инновации и меры для повышения эффективности бизнеса основаны на грамотной и умелой трансформации бизнес-процессов. А бумажные регламенты, как и автоматизация несовершенных и неструктурированных процессов — давно в прошлом.
Управление компанией, вне зависимости от размера и отрасли, подобно управлению автомобилем, где все решает скорость поступления информации и оперативная реакция на нее. Как и в машине, где помимо руля и коробки передач, должны быть различные приборы, в реальном времени отражающие как показатели самого транспортного средства, так и окружающей среды, в системе управления должны присутствовать инструменты для непосредственного воздействия и средства для обработки информации. Бумажные регламенты могут дать общую картину устройства бизнеса, но они не являются инструментом управления. Такие процессы не интерактивны и не предоставляют точных измерений выполняемых операций.
Инструмент для моделирования и управления бизнес-процессами — системы BPM, позволяющие быстро создавать, запускать, мониторить и изменять процессы благодаря тесной интеграции сред проектирования, разработки и выполнения. В основе ВРМ-систем, как правило, лежит один из наиболее прогрессивных мировых стандартов моделирования — нотация BPMN 2.0.
BPMN — самая гибкая и простая методология моделирования, анализа и реорганизации бизнес-процессов. Гибкость обеспечивает набор элементов и правил нотации, а наглядность достигается за счет визуальных диаграмм процессов и блок-схем. Основная цель BPMN — обеспечить доступной нотацией описания бизнес-процессов всех пользователей: аналитиков, которые создают модели процессов, разработчиков, внедряющих технологии их выполнения, простых бизнес-пользователей и руководителей, управляющих процессами и отслеживающих их выполнение.
BPMN призвана служить связующим звеном между стадией дизайна бизнес-процесса и стадией его реализации. С этой целью нотация BPMN использует базовый набор интуитивно понятных элементов, позволяющих определять сложные семантические конструкции. Стандарт BPMN появился в результате необходимости в простом механизме для проектирования и чтения как простых, так и сложных моделей бизнес-процессов. Моделирование в нотации BPMN осуществляется с помощью диаграмм с небольшим количеством графических элементов. Это позволяет пользователям быстро разобраться и понять логику процессов.
bpm"online — платформа для управления бизнес-процессами от компании Terrasoft. В основе системы — самый прогрессивный стандарт моделирования бизнес-процессов BPMN. Система позволяет не только осуществить моделирование и схемы бизнес-процесса и изменить ее с помощью удобного дизайнера, но и запустить только что созданный процесс без привлечения разработчика.
Для моделирования бизнес-процессов в нотации BPMN в bpm’online доступны два инструмента:
Мастер бизнес-процессов — для создания простых бизнес-процессов с использованием стандартных элегментов, запускаемых пользователем вручную.
Дизайнер бизнес-процессов — для моделирования сложных разветвленных процессов, содержащих множество различных элементов, включая выполняемые системой автоматически.
Выбор инструмента для моделирования в bpm’online зависит от сложности, назначения и способа запуска процесса.
Бесплатный (до 20 сотрудников) инструмент для графического описания процессов в нотации BPMN. Система поддерживает совместную работу, имитационное моделирование, экспорт созданных моделей в текстовые редакторы и другие форматы. Система состоит из двух модулей: BizAgi Modeler, который используется для описания и моделирования бизнес-процессов и BizAgi Studio, позволяющий превратить созданные модели в исполняемые приложения. Система также позволяет отслеживать выполнение процессов в реальном времени.
Система поддерживает несколько нотаций моделирования: IDEF, eEPC, BPMN и еще несколько других. В Business Studio есть возможность имитационного моделирования, проведения функционально-стоимостного анализа и автоматической генерации документов. Недостатком системы является то, что выполнение и мониторинг моделей процессов производится через интеграцию с другими системами. Программа также позволяет осуществлять постановку целей компании по системе сбалансированных показателей.
Для моделирования бизнес-процессов в системе используется нотация BPMN. Система позволяет также в реальном времени выполнять и отслеживать смоделированные процессы. Кроме построения моделей, система также позволяет назначать роли бизнес-процессов ответственным сотрудникам, организовать работу с документооборотом, интегрировать систему с 1С.
Система поддерживает большое количество нотаций и блок-схем моделей, среди них и BPMN. Созданные в системе модели могут быть связаны между собой, что легко позволит создать модель всего бизнеса. Кроме этого, есть возможность провести имитационное моделирование и проверку диаграмм процессов.
Visual Paradigm обеспечивает возможность управлять атрибутами элементов и автоматически генерировать описания процессов. Система изначально была ориентирована на разработчиков, поэтому каждому элементу можно задать условия поведения в системе, бизнес-правила.
