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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 1. Диагностика системы управления организации.

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

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

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

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

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

Этап 2. Моделирование существующих бизнес-процессов.

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

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

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

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

• 3. Моделирование в SADT означает создание диаграмм А0 и А-0. Эти две диаграммы полностью рассказывают все об изучаемой системе с минимальной степенью детализации. Прежде чем начать моделирование необходимо подготовиться к нему, собрать информацию, декомпозировать объект исследования (декомпозиция - диаграмма А0 освещает наиболее важные функции и объекты системы), затем обобщить эту декомпозицию (диаграмма А-0 трактует систему как черный ящик, дает ей название и определяет наиболее важные входы, управления, выходы и механизмы):
• 3.1. Выбор цели и точки зрения.
• 3.2. Составление списка данных. При этом лучше, если данных больше, чем меньше. Данные можно сразу группировать по типам.
• 3.3. Составление списка функций. Функции системы тоже лучше объединить по типу используемых данных. Затем функции объединяются в группы (от трех до шести). Желательно, чтобы эти группы имели один и тот же уровень сложности, содержали примерно одинаковый объем действий и функции в каждой из них имели сходные операции и цели.
• 3.4. Построение и обобщение диаграммы А0 (А0 - А-0). Для любой SADT-диаграммы есть родительская диаграмма, содержащая ее контекст. Контекстом для А0 служит А-0, представляющая обобщение всей модели. Эта диаграмма имеет несколько назначений: она объявляет общую функцию всей системы, дает множество основных типов или наборов данных, которые использует или производит система, указывает взаимоотношения между основными типами данных, производя их разграничение.
• 3.5. Декомпозиция ограниченного объекта. Начало процесса декомпозиции заключается в выборе блока рассматриваемой диаграммы и рассмотрении объекта, определяемого этим блоком и его дугами. При этом надо учесть, что рассматривать следует в первую очередь такой блок, декомпозиция которого выявит многие аспекты диаграммы А0 и будет оказывать большее влияние на будущие декомпозиции других блоков этой системы. При выборе самого содержательного блока нужно учесть и доминирование, и функциональную сложность и понятность. Лучшим блоком для первой декомпозиции будет тот, который позволит наиболее глубоко проникнуть в суть рассматриваемой системы.
• 3.6. Итерационный процесс рецензирования.
• 3.7. Завершение моделирования. Декомпозиция модели или ее части прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями для прекращения декомпозиции.
• 3.8. Документирование См.: Калянов, Г. Н. CASE-технологии. Структурный системный анализ (автоматизация и применение) / Г.Н. Калянов. - М:, Лори, 2002. - С.76-80..

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

Этап 3. Оценка оптимальности и оптимизация бизнес-процессов.

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

Проведение оценки оптимальности по перечисленным параметрам приводит к достижению следующих результатов:

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

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

Этап 4. Организация внедрения изменений.

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

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

• - проведение инструктажа сотрудников, ответственных за проведение изменений с целью разъяснения целей и мероприятий, порядка и форм внедрения новых моделей.
• - мониторинг проведения опытной эксплуатации новых стандартов функционирования Компании с целью выявления отклонений разработанных моделей бизнес-процессов от реальной возможности выполнения работ.
• - корректировка моделей бизнес-процессов на основании результатов опытной эксплуатации См.: Техническое задание проекта реорганизации бизнес-процессов предприятия. Режим доступа: http://www.finexpert.ru/content.asp?mID=60&ID=128&mode=w .

Этап 5. Разработка регламентирующих документов

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

Этап 6. Внедрение регламентирующих документов.

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

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

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

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

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

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

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

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

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

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

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

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

Цели моделирования бизнес-процессов обычно формулируются следующим образом:

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

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

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

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

• - Описание бизнес-процессов в стандарте «как есть»;
• - Является эффективным средством выявления и устранения «узких» мест предприятия;
• - Средство для предвидения и минимизации рисков;
• - Описание деятельности предприятия для последующей автоматизации.

Задачи бизнес-моделирования:

• - Реорганизация бизнеса
• - Сертификация бизнеса
• - Применение информационных систем для управления бизнесом

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

• 1. Какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата?
• 2. В какой последовательности выполняются эти процедуры?
• 3. Какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса?
• 4. Кто выполняет процедуры процесса?
• 5. Какие входящие документы/информацию использует каждая процедура процесса?
• 6. Какие исходящие документы/информацию генерирует процедура процесса?
• 7. Какие ресурсы необходимы для выполнения каждой процедуры процесса?
• 8. Какая документация/условия регламентирует выполнение процедуры?
• 9. Какие параметры характеризуют выполнение процедур и процесса в целом?

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

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

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

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

Модели бизнес-процесса:

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

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

Введение

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

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

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

Заключение

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Книги

• Бизнес-моделирование , Осипова Татьяна. Эта книга будет изготовлена в соответствии с Вашим заказом по технологии Print-on-Demand. Рассматривается моделирование бизнес-процессов, или бизнес-моделирование, основанное на…
• Бизнес-моделирование и анализ данных. Решение актуальных задач с помощью Microsoft Excel , Винстон Уэйн Л.. Уэйн Винстон использует реальные задачи, чтобы научить вас быстро анализировать данные, принимать решения, подводить итоги, составлять отчеты, обрабатывать данныеи строить аналитические…