Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

Нижегородский государственный технический университет имени Р.Е. Алексеева

Институт Экономики и управления

Кафедра "Экономика, управление и финансы"

Курсовая работа

по дисциплине: "Моделирование бизнес-процессов и экономических систем"

на тему: «Моделирование бизнес-процессов. Основные этапы проекта по внедрению процессного подхода в компании»

Выполнил:

студент гр. 10ИНМк

Резвова А.В.

Проверил:

Ковылкин Д.Ю.

Нижний Новгород 2014 г.

Введение

1.2 Основные терминологии

2. Практическая часть

2.1 Исходные данные

2.2 Проектная часть

Заключение

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

Введение проектирование управление процессный

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

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

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

1. Основные этапы проекта по внедрению процессного подхода в компании

1.1 Возможности процессной системы управления

В настоящее время многие российские предприятия занимаются внедрением процессного подхода к управлению, проводят подготовку и сертификацию по стандартам ISO серии 9000:2000, автоматизируют деятельность при помощи корпоративных информационных систем (SAP R/3, BAAN и др.), внедряют системы стратегического управления. На практике часто складывается ситуация, когда в организации одновременно ведутся несколько проектов, которые частично дублируют задачи друг друга, непроизводительно расходуя ресурсы предприятия. Одновременно на предприятии могут проводиться следующие работы:

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

· служба по качеству описывает и регламентирует бизнес-процессы в своем формате для целей внедрения системы качества (СК) или системы менеджмента качества (СМК);

· служба информатизации (IT-подразделение) собирает информацию по бизнес-процессам для подготовки и внедрения ERP-системы.

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

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

Внедрение процессного подхода к управлению дает предприятию следующие возможности.

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

· порядок планирования целей и деятельности;

· взаимодействие между процессами и подразделениями предприятия;

· ответственность и полномочия должностных лиц, в т.ч. владельцев процессов;

· порядок работы и действий в нештатных ситуациях;

· порядок и формы отчетности перед высшим руководством;

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

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

Внедрение на предприятии СУБП в первую очередь подразумевает работу по описанию и регламентации бизнес-процессов, в рамках которой:

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

· определяется система взаимодействия процессов между собой и с внешними поставщиками и потребителями;

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

· составляется график разработки и внедрения этой документации;

· устанавливаются показатели деятельности процессов, способы и формы сбора информации и порядок отчетности перед руководителями;

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

· устанавливаются критерии, по которым начинается работы по устранению причин отклонения.

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

· показатели результата деятельности отдельных процессов и предприятия в целом (достижение запланированных результатов - по объему, качеству, номенклатуре и срокам);

· показатели эффективности деятельности отдельных процессов и предприятия в целом (отношение полученных результатов к затратам времени, финансовых и других ресурсов);

· показатели продуктов, производимых процессами предприятия;

· показатели удовлетворенности клиентов результатами работы.

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

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

· система основана на измерении показателей деятельности предприятия, планировании и достижении непрерывного улучшения результатов деятельности;

· система направлена на удовлетворение потребностей 5 групп лиц, заинтересованных в деятельности организации:

A. 1) соучредители (инвесторы);

2)потребители на рынке;

3) персонал организации;

4) поставщики.

5) общество.

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

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

Внедрение процессной системы управления на предприятии рассматривается как проект. Основным заказчиком результатов этого проекта является высшее руководство предприятия и владельцы процессов.

1.2 Основные терминологии

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

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

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

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

Документооборот - система документального обеспечения деятельности предприятия.

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

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

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

Показатели продукта (услуги)(ПП) - параметры продукта бизнес-процесса.

Показатели (данные) удовлетворенности клиента (потребителя) (ДУК) - параметры удовлетворенности клиента.

Поставщик - субъект, предоставляющий ресурсы.

Потребитель (клиент) - субъект, получающий результат бизнес-процесса. Потребитель может быть:

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

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

Операция (работа) - часть бизнес-процесса.

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

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

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

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

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

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

1.3 Процессный подход: концепция внедрения в организации

Для определения зрелой с процессной точки зрения организации можно использовать следующие критерии:

* Наличие и поддержание в актуальном состоянии архитектуры (системы) бизнес-процессов компании;

* Действующая система стандартизации (регламентации) деятельности (в первую очередь процессов);

* Наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам;

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

* Наличие центра компетенции (департамента отдела) по организационному развитию с представителями в каждом департаменте (функциональное подчинение);

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

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

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

С точки зрения состояния ресурсы могут: A. Храниться; B. Перемещаться; C. Находиться в состоянии обработки.

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

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

Ресурс по управлению - необходимый для управлен-я процессом.

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

Выход процесса - преобразованный при выпо-нении процесса ресурс.

Обеспечивающие ресурсы могут:

* Периодически по мере необходимости поставляться в процесс другими процессами;

* Выделяться процессу на постоянной основе.

В реальной жизни обеспечивающие ресурсы меняются:

A. Сотрудники приобретают опыт, стареют и так далее;

B. Оборудование изнашивается;

C. ПО морально устаревает.

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

В целом владелец процесса - это руководитель, способ-ый как минимум:

1. Проводить мониторинг хода процесса;

2. Анализировать факторы, влияющие на процесс и приводящие к вариациям;

3. Разрабатывать предложения по улучшению процесса и организовывать их обсуждения и согласования;

4. Координировать или управлять внутренние совершенствования процесса.

2. Практическая часть

2.1 Исходные данные

В данном разделе осуществляется моделирование описанного ранее бизнес-процесса с использованием нотации моделирования IDEF0 семейства стандартов IDEF.

Создание контекстной диаграммы

Рассматриваются некие продажи через интернет магазин.

Основные процедуры в продаже через интернет магазин таковы:

· Обработка заявки клиента

· Сборка товара на складе

· Подготовка документации

· Доставка

Рис.1 Контекстная диаграмма - 1-й уровень декомпозиции

2.2 Проектная часть

Создание диаграммы декомпозиции

В диалоге «Activity Box Count» устанавливаем число работ на диаграмме нижнего уровня - 4 - и нажимаем ОК.

Рис.2 Диалог «Activity Box Count»

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

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

2.3 Создание диаграммы декомпозиции A1

Декомпозируем работу «Поверка и внесение заказа».

Рис.4 Результаты декомпозиции подпроцесса «Обработка заявки клиента» 3-й уровень декомпозиции

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

2.4 Создание диаграммы декомпозиции A2

Декомпозируем работу «товар»

Рис 5. Результаты декомпозиции подпроцесса «Сборка товара на складе» 3-й уровень декомпозиции.

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

2.5 Создание диаграммы декомпозиции A3

Декомпозируем работу «Подготовка накладной»

Рис. 6 Результаты декомпозиции подпроцесса «Подготовка документации» 3-й уровень декомпозиции.

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

2.6 Создание диаграммы декомпозиции А4

Декомпозируем работу «Наличие накладной»

Рис.7. Результаты декомпозиции подпроцесса «Доставка» 3-й уровень декомпозиции.

Завершающий процесс. На входе сразу 3 стрелки: сформированные заявки клиентов, чеки, маршрутый лист. Пройдя через все блоки получаем на выходе товар и чек доставленные клиенту.

2.3 Выводы и комментарии по результатам проектирования

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

Была произведена декомпозиция бизнес-процесса «Продажи через интернет магазин» которая включила в себя 4 уровня декомпозиции: «Обработка заявки на складе», «Сборка товара на сладе», Подготовка документации», «Доставка». На 3 уровне декомпозиции включает в себя диаграммы декомпозиции всех подпроцессов составляющих бизнес-процесс контекстной диаграммы.

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

Заключение

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

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

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

Список используемой литературы

1. Моделирование бизнес-процессов и экономических систем: методические указания для выполнения курсовой работы студентам, обучающимся по профилю «Информационный менеджмент» направления 080200 «Менеджмент»/НГТУ; сост.: Д.Ю. Ковылкин. Н.Новгород, 2014. - 30 c.

2. Лекции по дисциплине «Инструментальные средства моделирования сложных систем», Д.Ю.Ковылкин. 2014.

Размещено на Allbest.ru

Подобные документы

    Определение процессного подхода к управлению организацией. Моделирование бизнес-процессов; объекты и связи в IDEF0, преимущества и недостатки их использования. Процессно-организационная бизнес-модель компании ОАО "Урал"; паспорт процесса "Продажа".

    курсовая работа , добавлен 03.05.2014

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

    дипломная работа , добавлен 21.03.2013

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

    курсовая работа , добавлен 25.05.2009

    Эффективное внедрение процессного подхода. Основные виды бизнес-процессов. Вопросы управления бизнес-процессами. Проект реинжиниринга бизнес процессов организации. Общая характеристика организации ООО "Мир стекла". Разработка бизнес-процесса организации.

    курсовая работа , добавлен 17.11.2014

    Целесообразность внедрения процессного управления на ООО "Мир Алюминия". Разработка рекомендаций и механизма оптимизации основных бизнес-процессов как пути совершенствования системы управления на исследуемом предприятии. Моделирование бизнес-процессов.

    дипломная работа , добавлен 08.01.2012

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

    дипломная работа , добавлен 28.04.2011

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

    реферат , добавлен 16.07.2016

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

    контрольная работа , добавлен 22.02.2017

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

    курсовая работа , добавлен 25.01.2016

    Анализ финансово-хозяйственной деятельности ООО "ВТК". Применение процессного подхода в деятельности организации. Разработка мер по совершенствованию внешнеэкономической деятельности, целевая схема бизнес-процессов. Оценка экономической эффективности.

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

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

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

Книга:

Введение

Введение

В настоящее время государственные и негосударственные организации Российской Федерации начинают активно реализовывать проекты по созданию бизнес-моделей. Данная активность не является данью некой новой «технологической» моде – для нее существуют вполне объяснимые причины, связанные с действием совокупности объективных экономических и организационно-правовых факторов. Во-первых, наличие документированной бизнес-архитектуры предприятия является обязательным условием его сертификации как по международным стандартам ISO 9001:2000, так и по российским ГОСТ Р ИСО 9001–2001. Более того, в настоящее время в ряде развитых зарубежных стран приняты стандарты, определяющие требования к структуре и порядку построения бизнес-архитектуры. Во-вторых, в условиях все возрастающих инвестиций в информационно-технологическую инфраструктуру организации предварительное моделирование ожидаемых изменений в бизнес-процессах и оценки эффектов является одним из основных инструментов обоснования и оптимизации расходов на модернизацию.

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

? увеличение доли федеральных органов государственной власти, выполнивших описание и оптимизацию административно-управленческих процессов, с 7 % до 60 %;

? увеличение доли органов государственной власти субъектов Российской Федерации, выполнивших описание и оптимизацию административно-управленческих процессов, с 5 % до 50 %.

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

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

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

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

Архитектура предприятий по своей сути является некоторым механизмом, который обеспечивает прозрачность представления, «трансформацию» «стандарных» услуг (деятельности) правительства в электронные регламенты, основанные на использовании современных ИТ. В каждой из стран существует своя специфика в организации, наименовании и стандартизации проектов по созданию электронного правительства. Например, в США реализуется проект «Федеральная архитектура», в Германии – «Стандарты и архитектура прикладных систем электронного правительства» (SAGA – Standards and Architecture for e-Government Applications). Однако при всем многообразии специфик реализации основной лейтмотив заключается в процессном подходе организации деятельности государства по предоставлению на современной технологической основе услуг гражданам и бизнесу. Соответственно, проектирование национальной инфраструктуры государственных информационных систем осуществляется в контексте обеспечения эффективной реализации государственных функций.

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

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

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

В качестве примера можно привести один из результатов такой разобщенности, озвученный бывшим министром обороны США Дональдом Рамсфельдом: «Наличие 673 различных и нескоординированных систем финансового учета сделало невозможным найти следы транзакций на общую сумму в 2,3 млрд долларов» .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке.

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

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

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

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

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

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

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

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

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

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

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

  1. Нужно регламентировать деятельность. Содержание графической модели бизнес-процесса полностью совпадает с текстовой. Если компания располагает графиком, то в кратчайшие сроки и без труда переведет его в формат текста, чтобы подготовить нормо-регулирующую документацию. Благодаря некоторым ВРМ-системам на основе модели возможна автоматическая генерация регламентов исполнения и должностных инструкций.
  2. Необходимо управлять рисками.С операционными рисками компания сталкивается в ходе выполнения бизнес-процессов. Модели бизнес-процессов могут стать основой для составления карты рисков всей организации при управлении ими.
  3. Компания нуждается в организационных изменениях. Чтобы рассчитать оптимальную численность специалистов в штате, следует точно определить, сколько сотрудников должно участвовать во всех бизнес-процессах компании. Получить необходимую информацию помогает визуальное моделирование бизнес-процессов. Данное действие позволяет грамотно распределить человеческие ресурсы, которые требуются для выполнения того или иного процесса и связанных с ним задач, а также выявить, сколько специалистов должно состоять в каждом отделе, с рациональной точки зрения.
  4. Проведение функционально-стоимостного анализа. Моделирование бизнес-процессов предприятия позволяет понять, сколько человеческих и материальных ресурсов нужно, чтобы выполнить одно действие в рамках бизнес-процесса. Данная информация может стать основой для автоматического распределения всех доходов и расходов на центры затрат и получения прибыли, в зависимости от подразделения.
  5. Потребность в автоматизации. При моделировании бизнес-процесса однозначно описывается порядок действий и место специалистов, отвечающих за них. Это позволяет правильно разработать бизнес-требования. Благодаря автоматизированным информационным системам класса workflow-managemet можно моментально вносить корректировки в информационную систему.

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

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

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

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

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

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

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

Часто модели бизнес-процессов используют, оптимизируя схему управления и создавая систему мотивации персонала предприятия.

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

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

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

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

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

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

Большой лист бумаги и блок стикеров – вот и всё, что понадобится вам для применения метода создания бизнес-моделей по известной книге Александра Остервальдера и Ива Пинье. Добавьте еще креативность, острый ум и упорство членов команды, и вы получите отличный результат.

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

Основные подходы к моделированию бизнес-процессов

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

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

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

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

Функциональное моделирование бизнес-процессов имеет весомое достоинство – наглядность и понятность отображения на разных уровнях абстракции. Это особенно важно на этапе введения в отделы компании созданных бизнес-процессов.

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

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

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

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

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

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

Сейчас можно отметить тенденцию интеграции разных способов моделирования и анализа систем. Проявляется она в том, что создаются интегрированные средства моделирования бизнес-процессов. Одно из них – продукт немецкой компании IDS Scheer под названием ARIS – Architecture of Integrated Information System.

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

Система АRIS оказывает поддержку 4 видам моделей, отражающим различные объекты изучаемой системы:

Чтобы создать модели описанных выше типов, пользуются как собственными способами моделирования ARIS, так и разными известными методами и языками – ERM, UML, OMT и т.д.

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

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

Ключевой бизнес-моделью АRIS является eEPC (extended Event Driven Process Chain – расширенная модель цепи бизнес-процессов, которыми управляют события). По сути, она расширяет возможности IDEF0, IDEF3 и DFD, обладает своими плюсами и минусами. Использование достаточного количества объектов, соединенных друг с другом различными видами связей, позволяет существенно увеличить размер модели и превратить ее в плохо читаемую.

В еЕРС бизнес-процесс является потоком последовательно проводимых работ (функций, процедур, мероприятий), расположенных в хронологическом порядке. Точная продолжительность процедур в еЕРС не отображается наглядно, вследствие чего не исключено появление в ходе разработки моделей ситуаций, в которых одному исполнителю придется решать две задачи в одно время. Символы логики, применяемые при моделировании, помогают отобразить ветвление и соединение процесса. Чтобы узнать, сколько на самом деле длятся процессы, следует пользоваться иными инструментами описания, к примеру, графиками Ганта в системе MS Project.

Ericsson-Penker

Способ Ericsson-Penker интересен, главным образом, тем, что в его рамках была предпринята попытка использовать UML, когда проводилось процессное моделирование бизнес-процессов. Разработчики метода создали собственный профиль UML, чтобы выполнять моделирование бизнес-процессов. Для этого вводили набор стереотипов, описывавших ресурсы, процессы, цели и правила работы компании.

В рамках метода применяют 4 главных категории бизнес-модели:

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

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

3. Цели – назначение бизнес-процессов. Их можно делить на составляющие и соотносить эти подцели с конкретными процессами.

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

5. Основная диаграмма UML-метода – диаграмма деятельности. Ericsson-Penker демонстрирует процесс в виде деятельности со стереотипом «process» (основу представления составляет расширение метода IDEF0). В полную бизнес-модель входит много представлений, схожих с представлениями архитектуры ПО. Все представления в отдельном порядке выражены в одной диаграмме UML и более. Диаграммы могут включать в себя разные виды и изображать цели, правила, процессы и ресурсы при взаимодействии. Метод пользуется 4 разными представлениями бизнес-модели:

Rational Unified Process

Существует также моделирование бизнес-процессов по методике Rational Unified Process (RUP), в рамках которого строят две модели:

Модель бизнес-процессов является расширением модели вариантов применения UML за счет введения набора стереотипов – Business Actor (стереотипа действующего лица) и Business Use Case (стереотипа варианта использования). Business Actor – это некая роль, внешняя по отношению к бизнес-процессам компании. Business Use Case выступает как описание порядка мероприятий в отдельно взятом процессе, приносящее видимые результаты определенному лицу. Данное определение схоже с общим определением бизнес-процесса, но суть его точнее. В терминах объектной модели Business Use Case это класс. Его объекты – определенные потоки событий в описываемом бизнес-процессе.

При описании Business Use Case также можно обозначать цель. Ее, как и в случае с методом Eriksson-Penker, моделируют с помощью класса со стереотипом «goal», а дерево целей изображают как диаграмму классов.

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

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

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

  • организационным, которые представляют системную структуру – подразделения компании, должности, конкретные лица в иерархии, взаимосвязь между ними, территориальную принадлежность структурных отделов;
  • функциональным, в которых отражена иерархия цепей, стоящих перед управленческим аппаратом, с совокупностью деревьев функций, необходимых для реализации имеющихся задач;
  • информационным, где отражена структура информации, которая требуется для выполнения всех функций в системе в целом;
  • моделям управления, которые представляют собой комплексный взгляд на выполнение бизнес-процессов.
  • концептуальным, показывающим структуру проблем и целей;
  • представлением процессов, что является взаимодействием между ресурсами и процессом (как набор диаграмм деятельности);
  • структурным представлением, показывающим структуру компании и ресурсов (отображаются диаграммы классов);
  • представлением поведения (тем, как ведут себя отдельные ресурсы, а также детализацией ресурсов в виде диаграмм работ, состояний и взаимодействия).
  • бизнес-процессов (Business Use Case Model);
  • бизнес-анализа (Business Analysis Model).
  1. Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case как последовательность обмена сообщениями между объектами – действующими лицами и объектами, являющимися исполнителями. Благодаря таким диаграммам можно определять, какими обязанностями должен быть наделен тот или иной исполнитель, и отображать в модели набор его операций.
  2. Диаграммы деятельности, описывающие взаимосвязь между сценариями одного или нескольких Business Use Case.
  3. Диаграммы состояний, описывающие, как себя ведут отдельные бизнес-процессы.

В методике моделирования Rational Unified Process есть определенные достоинства:

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

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

IBM WebSphere Business Modeler

IBM WebSphere Business Modeler позволяет моделировать и имитировать бизнес-процессы, анализировать и создавать отчеты для их усовершенствования. У системы есть ряд преимуществ, среди которых:

  1. Обширные и лучшие в своем классе возможности для анализа, имитации и моделирования.
  2. Непрерывное улучшение процессов.
  3. Усовершенствованные возможности интеграции.
  4. Улучшенные сроки возврата инвестиций.
  5. Усовершенствованные функции разработки.

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

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

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

  • Простая формула, чтобы понять, что предприятию нужна автоматизация бизнес-процессов

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

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

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

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

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

Информационное моделирование бизнес-процессов включает несколько составляющих. Главные элементы – это:

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

Основное понятие в IDEF1 – сущность, которую определяют как абстрактный или реальный объект, наделенный совокупностью известных отличительных свойств. У каждой сущности есть атрибуты и имя.

Поскольку анализировать динамические системы достаточно сложно, в данный момент стандарт почти не используют, и он, едва появившись, перестал развиваться. Сегодня есть алгоритмы и их компьютерные реализации, при помощи которых становится возможным превращение набора статистических программ IDEF0 в динамические модели, базой для построения которых выступают «раскрашенные сети Петри» (CPN – Color Petri Nets).

IDEF3 – IDEF14

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

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

IDEF5 является методологией изучения сложных систем.

IDEF6 – Design Rationale Capture – обоснование проектных действий. IDEF6 позволяет значительно упрощать процесс получения информации о моделировании, ее представление и применение при создании фирмами управленческих систем. «Знания о способе» – это определенные обстоятельства, причины, скрытые мотивы, обосновывающие выбранные методы создания моделей. То есть «знания о способе» можно интерпретировать как ответ на вопрос: «Почему получилась именно эта модель, с этими, а не иными характеристиками?». Большая часть способов моделирования концентрируется на создаваемых моделях, не углубляясь в их разработку. Вариант IDEF6 нацелен именно на разработку.

IDEF 7 – Information System Auditing – аудит информационных систем. Метод востребован, но его так и не доработали до конца.

IDEF8 – User Interface Modeling. Метод создания интерфейсов взаимодействия системы с оператором (пользовательских интерфейсов). В данный момент при разработке интерфейсов основное внимание уделяют их внешнему виду. IDFE8 сосредоточен на программировании оптимальной взаимной коммуникации пользователя и интерфейса на 3 уровнях: операции (какая она); вариантах взаимодействия, которые зависят от специфической роли пользователя (как именно тот или иной пользователь должен выполнять ее); и, наконец, на составляющих интерфейса (элементах управления, предлагаемых им для операции).

IDEF9 – Scenario-Driven IS Design (Business Constraint Discovery method) – метод исследования бизнес-ограничений. Призван облегчить обнаружение и анализ ограничений в условиях работы компании. Как правило, при создании моделей не в полном объеме описывают ограничения, способные изменить ход процессов в организации. Информация об основных ограничениях, характере их влияния в лучшем варианте остается не до конца согласованной, нераспределенной рационально, однако нередко она в принципе отсутствует. Это не всегда означает нежизнеспособность построенных моделей. Просто их воплощение будет сопровождаться определенными сложностями, что приведет к нереализованному потенциалу. Вместе с тем, когда имеет место именно совершенствование структур или адаптация к вероятным изменениям, информация об ограничениях становится очень важной.

IDEF10 – Implementation Architecture Modeling – моделирование архитектуры выполнения. Система моделирования бизнес-процессов достаточно востребована, несмотря на то, что не разработана до конца.

IDEF11 – Information Artifact Modeling. Также востребованный, но не доработанный полностью метод.

IDEF12 – Organization Modeling – организационное моделирование бизнес-процессов. Метод востребован, но не выработан полностью.

IDEF13 – Three Schema Mapping Design – трехсхемное проектирование преобразования информации. Востребованный, но не окончательно созданный метод.

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

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

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

В диаграммах потоков информации есть ряд составляющих, ключевые из которых:

  • внешние сущности;
  • системы и подсистемы;
  • процессы;
  • накопители информации;
  • информационные потоки.

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

Подсистему идентифицируют по номеру – для этого он и предназначен. В поле имени вводят ее название в виде предложения, где есть подлежащее, соответствующие дополнения и определения.

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

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

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

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

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

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

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

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

  • Как навести порядок в бизнес-процессах, если вам досталась «нехорошая» компания

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

Этап 1. Идентификация.

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

Этап 2. Сбор информации.

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

Этап 3. Анализ информации.

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

Этап 4. Внесение улучшений.

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

Этап 5. Контроль над внедрением.

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

Бизнес-процессы. Моделирование, внедрение, управление Репин Владимир Владимирович

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

Для крупной компании внедрение среды моделирования – серьезный проект, который может состоять из трех этапов:

1. Выбор и тестирование среды моделирования.

2. Опытная эксплуатация среды моделирования.

3. Внедрение среды моделирования в масштабах компании.

Этап 1. Выбор и тестирование среды моделирования:

Определение потребностей внутренних пользователей;

Определение и согласование целей и задач проекта;

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

Установка пробной версии среды моделирования (два-три рабочих места);

Создание пилотной модели организации:

– описание двух-трех процессов на двух уровнях;

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

– описание некоторых документов, терминов, ТМЦ;

– формирование пилотных отчетов (регламентов выполнения бизнес-процессов);

Тестирование среды моделирования на основе пилотной модели:

– тестирование функциональных возможностей системы;

– тестирование выгрузки отчетов (регламентирующих документов);

– тестирование управления изменениями;

Анализ результатов тестирования среды моделирования на пилотной модели, принятие решения о выборе системы;

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

Принятие решения и закупка среды моделирования;

Установка системы (три-пять конкурентных лицензий);

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

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

Этап 2. Опытная эксплуатация среды моделирования:

Администрирование системы:

– создание групп пользователей и определение прав доступа;

– настройка функционала контроля внесения изменений в систему;

Анализ и внесение необходимых изменений в метамодель:

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

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

– определение и внесение необходимых дополнений в метамодель (структуру данных);

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

Ввод в систему необходимых справочников:

– иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS Excel);

– иерархический справочник подразделений и должностей;

– справочник бумажных и электронных документов (уровня компании);

– справочник терминов;

– прочее.

Разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;

Разработка решений по интеграции с другими системами («экспорт – импорт»);

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

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

Анализ эффективности функционирования среды моделирования; внесение необходимых изменений в регламенты работы с системой.

Этап 3. Внедрение среды моделирования в масштабах компании:

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

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

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

Разработка плана описания процессов организации;

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

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

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

1. Общие положения

1.1. Назначение и область действия

1.2. Используемые сокращения

1.3. Термины и определения

2. Ведение справочников в Business Studio

2.1. Справочник «Процессы»

2.2. Справочник «Субъекты»

2.3. Справочник «Объекты деятельности»

2.4. Справочник «Управление»

3. Описание процессов в Business Studio

3.1. Элементы нотации «Процедура» Business Studio

3.2. Описание операций процесса

3.3. Использование стрелок типа «Связь предшествования»

3.4. Использование стрелок типа «Поток документов»

3.5. Использование событий

3.6. Использование блока «Решение»

3.7. Использование междиаграммных ссылок

3.8. Использование сносок

4. Схемы организационной структуры в Business Studio

4.1. Используемые графические элементы

5. Заполнение атрибутов объектов модели

5.1. Заполнение атрибутов процесса

5.2. Заполнение атрибутов операции процесса

5.3. Заполнение атрибутов стрелок

5.4. Заполнение атрибутов субъекта деятельности

5.5. Заполнение атрибутов объекта деятельности

5.6. Заполнение атрибутов целей и показателей

6. Приложения

6.1. Пример схемы процесса в нотации «Процедура» Business Studio

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

1. Общие положения

1.1. Назначение

1.2. Термины, определения и сокращения

2. Общее описание процесса управления изменениями

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

4. Изменения справочников

4.1. Организационная структура

4.2. Процессы

4.3. Объекты деятельности (документы, ТМЦ, программные продукты)

4.4. Цели и показатели

4.5. Прочее

5. Изменение схем процессов

6. Изменение шаблонов отчетов

7. Изменение метамодели

8. Архивирование и восстановление объектной модели

9. Изменение прав доступа

10. Изменение версии системы (переход на новые версии)

11. Изменение решений по интеграции с другими системами

В заключение приведу пример графика проекта по созданию репозитория бизнес-процессов организации на платформе среды моделирования Business Studio (рис. 4.10.1).

Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio

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

Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в MS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Business Studio – создается иерархический справочник процессов. Этот справочник – основа для накопления знаний о процессах в рамках электронного репозитория.

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

Чтобы выгрузить из репозитория информацию о процессах в необходимой форме (регламенты, инструкции, положения и т. п.), нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документам и возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Enterprise).

Когда станет понятно, как моделировать процессы и какая информация должна заноситься в атрибуты объектов модели, разрабатывается стандарт моделирования (соглашение по моделированию).

Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.

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

Из книги Человеческий фактор в программировании автора Константин Ларри Л

Из книги Инструменты McKinsey. Лучшая практика решения бизнес-проблем автора Фрига Пол

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

Из книги Виртуальные организации. Новая форма ведения бизнеса в XXI веке автора Уорнер Малкольм

Указания по внедрению Пора вернуться к нашей команде из Acme Widgets. Лукас, недавно назначенный менеджером по закупкам в подразделение малярных кистей (как помните, вы искали этого сотрудника в главе 6), только что прошел вводный курс обучения и готов приступать к работе. К

Из книги Бизнес-процессы. Моделирование, внедрение, управление автора Репин Владимир Владимирович

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

Из книги Проектируем корпоративную архитектуру автора Кондратьев Вячеслав Владимирович

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

Из книги Прорыв в бизнесе! 14 лучших мастер-классов для руководителей автора Парабеллум Андрей Алексеевич

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

Из книги Хватит платить за все! Снижение издержек в компании автора Гагарский Владислав

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

Из книги Руководство по улучшению бизнес-процессов автора Коллектив авторов

4.4. Архитектура типовой среды моделирования процессов Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или Enterprise Architecture, то есть программным

Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон Джон

4.6.5. Нотация «Процедура» среды моделирования Business Studio Сейчас одним из распространенных инструментов бизнес-моделирования стала среда Business Studio. В этой системе реализованы четыре нотации: IDEF0, «Процесс», «Процедура», eEPC.Нотация IDEF0 используется для построения моделей

Из книги автора

5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития В ряде компаний регламентация процессов производства достигает 90–100 %, то есть регламентирована почти вся деятельность. Внешние требования (ограничения)

Из книги автора

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

Из книги автора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1. Borland Together

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

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

Рис. 3. ARIS Business Architect

Рис. 4. Microsoft Visio

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

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