Анализ деятельности предприятия и моделирование основных бизнес-процессов. Моделирование бизнес-процессов при помощи CASE-средства Rational Rose. Получение прибыли путем расширения рынка товаров и услуг. Бизнес-процесс "Заказ и закупка товара".

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

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

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

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

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


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

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


Создание модели бизнес-процессов "Распродажа" в ВPwin. Цели и правила распродажи. Прогнозирование бизнес-процессов ППП "Statistica". Методы анализа, моделирования, прогноза деятельности в предметной области "Распродажа", изучение ППП VIP Enterprise.

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


Разработка языка для моделирования реальных бизнес-процессов в рамках "Студии компетентностных деловых игр". Использование DSM-платформа MetaEdit+. Составление требований к разрабатываемому языку программирования. Правила разработки метамодели языка.

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


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

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


Моделирование регламента Центра сертификации ключей ЗАО "Инфраструктура открытых ключей" с учётом требований безопасности. Основные определения и понятия моделирования процессов. Функции программно-технического комплекса центра. Атрибуты безопасности.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

процессов составила методология SADT. В настоящее время наиболее широко используемая методология описания бизнес-процессов – стандарт США IDEF.

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

моделирование бизнес-процессов это ответ практически на все вопросы,

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

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

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

Существует несколько подходов к определению понятия

«моделирование бизнес-процессов»:

1) моделирование бизнес-процессов - это описание бизнес-

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

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

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

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

предъявляемым к его функционированию, управлению, эффективности,

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

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

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

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

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

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

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

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

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

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

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

деятельности компании:

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

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

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

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

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

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

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

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

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

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

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

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

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

отражающие последовательность создания и перемещения документов

(данных, материалов, ресурсов и т.п.) между действующими лицами.

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

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

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

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

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

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

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

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

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

Под методологией (нотацией) создания модели (описания) бизнес-

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

– теоретическая база;

–описание шагов, необходимых для получения заданного результата;

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

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

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

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

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

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

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

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

повышение конкурентоспособности компании. Недостатки, в свою очередь:

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

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

Основу многих современных методологий моделирования бизнес-

процессов составила методология SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) и

алгоритмические языки, применяемые для разработки программного обеспечения.

В сжатом виде история развития методологий моделирования бизнес-

процессов представлена на рисунке 2. Для наглядности параллельно приведена история развития подходов к управлению качеством .

Рисунок 2 - История развития методологий моделирования бизнес-

процессов

В настоящее время для описания, моделирования и анализа бизнес-

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

 моделирования бизнес-процессов (Business Process Modeling);

 описания потоков работ (Work Flow Modeling);

 описания потоков данных (Data Flow Modeling).

Методологии моделирования бизнес-процессов (Business Process Modeling). Наиболее широко используемая методология описания бизнес-

процессов – стандарт США IDEF0. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с совершенствованием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-

процессов (например, BPWin 4.0, ProCap, IDEF0/EM Tool и др.).

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

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

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

настоящий момент к семейству IDEF можно отнести следующие стандарты:

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

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

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий ―Сущность-взаимосвязь‖

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

IDEF2 – методология динамического моделирования развития систем.

В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе;

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

описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая

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

IDEF4 – методология построения объектно-ориентированных систем.

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

IDEF5 – методология исследования сложных систем .

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

иерархию организационных подразделений, должностей и конкретных лиц,

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

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

необходимых для достижения поставленных целей;

информационные модели, отражающие структуру информации,

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

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

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

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

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

РЕГЛАМЕНТ КАК ДОКУМЕНТ

Наш словарик

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

Регламенты строго индивидуальны и могут действовать только в той организации, которая утвердила их для себя. Так, при составлении инструкции по делопроизводству обычно используют ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» и Методические рекомендации по внедрению ГОСТ Р 6.30-2003 . На основе этих документов создаются внутренние инструкции и в небольшом магазине, и в ОАО федерального уровня. А вот, например, порядок прохождения внутренних документов, установленный в одной организации, может совершенно не подходить для другой.

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

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

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

Какие процессы подлежат регламентации?

Иметь отдельные регламенты на все рабочие процессы, несомненно, очень удобно. Однако у этой медали есть и оборотная сторона, а именно:

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

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

СТРУКТУРА И СОДЕРЖАНИЕ РЕГЛАМЕНТА

Как правило, регламент состоит из следующих основных разделов:

1. Общие положения.
2. Термины, определения, сокращения.
3. Описание процесса.
4. Ответственность.
5. Контроль.

Раздел
Общие положения	Назначение регламента (Настоящий регламент определяет порядок… ); область применения: объекты или работники организации, которых касается регламент; нормативные документы, на основании которых разработан регламент (если они есть); порядок утверждения, внесения изменений и отмены регламента
Термины, определения, сокращения	Определение терминов и разъяснение сокращений, используемых в тексте регламента. Термины приводятся в алфавитном порядке. Каждый из них пишется с новой строки в единственном числе, а его определение указывается через тире без слова «это». В качестве источника определений желательно использовать законодательные акты, государственные стандарты и другие нормативные документы
Описание процесса	Пошаговое описание процесса. Для удобства этот раздел делится на подпункты, каждый из которых соответствует очередному этапу процесса. В разделе указываются работники, задействованные в выполнении, описываются действие и результат
Ответственность	Ответственность участников процесса за неисполнение регламента (дисциплинарная, административная, уголовная). Последняя касается обычно сложных производственных процессов, связанных с риском для здоровья и жизни работников
Контроль	Указание Ф.И.О. должностного лица, ответственного за контроль исполнения регламента, а также, при необходимости, средства контроля

ОСНОВНЫЕ РЕКВИЗИТЫ РЕГЛАМЕНТА

К числу основных реквизитов документа относят:

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

Кстати

Требования к оформлению перечисленных реквизитов установлены ГОСТ Р 6.30-2003. Методические рекомендации по внедрению ГОСТ Р 6.30-2003 разъясняют и конкретизируют порядок внедрения и применения данного стандарта.

МОДЕЛЬ БИЗНЕС-ПРОЦЕССА

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

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

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

ПОРЯДОК РАБОТЫ НАД РЕГЛАМЕНТОМ

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

Утверждение регламента может производиться несколькими способами:

1. напрямую (руководитель собственноручно расписывается на документе);
2. косвенно (путем издания приказа) (см. Пример 1). В данном случае в гриф утверждения будут внесены регистрационные данные приказа.

Пример 1

Приказ об утверждении и введении в действие
регламентов бизнес-процессов

(ООО «Перспектива»)

ПРИКАЗ

23.07.2014 № 456-Пр

г. Москва

Об утверждении и введении в действие регламентов бизнес-процессов

В целях совершенствования процедур делопроизводства ООО «Перспектива»

ПРИКАЗЫВАЮ:

1. Утвердить и ввести в действие с 01.08.2014 регламенты следующих бизнес-процессов:

1.1. Регистрация и учет документов.

1.2. Контроль исполнения документов.

1.3. Хранение и поиск документов.

2. Назначить ответственным за выполнение требований, указанных в п. 1 данного приказа, административного директора Легостаева А.В.

3. Начальнику канцелярии Паршиной В.К. обеспечить ознакомление работников ООО «Перспектива» с настоящим приказом под роспись и передать копии утвержденных регламентов в структурные подразделения ООО «Перспектива» до 30.07.2014.

4. Контроль исполнения настоящего приказа оставляю за собой.

Генеральный директор Максимов Д.А. Максимов

С приказом ознакомлены:

Легостаев А.В. Легостаев 24.07.2014

Паршина В.К. Паршина 24.07.2014

П.А. Карпенко

23-78

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

Пример 2

Регламент бизнес-процесса «Контроль исполнения документов»

Общество с ограниченной ответственностью «Перспектива»
(ООО «Перспектива»)

РЕГЛАМЕНТ №7
бизнес-процесса «Контроль исполнения документов»

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

1.1. Регламент бизнес-процесса «Контроль исполнения документов» (далее - Регламент) определяет порядок контроля исполнения заданий по документам в ООО «Перспектива» (далее - Организация).

1.2. Требования и правила Регламента распространяются на все структурные подразделения Организации.

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

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

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

2.1. В Регламенте используются следующие термины и определения:

Документ - зафиксированная на носителе информация с реквизитами, позволяющими ее идентифицировать.

Задание - поручение руководителя.

Задача - см. задание.

Исполнитель - работник Организации, которому поручено исполнение задачи.

Контроль - совокупность действий, обеспечивающих своевременное исполнение документа.

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

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

Руководитель - должностное лицо, выносящее резолюцию.

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

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

Без указания конкретной даты исполнения и специальных пометок - в течение 30 дней;

Без указания конкретной даты, с пометкой «Срочно» или «Немедленно» - в течение трех дней;

Без указания конкретной даты, с пометкой «Оперативно» - в течение 10 дней.

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

3.1. Постановка документа на контроль.

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

3.1.2. Основанием для постановки документа на контроль является резолюция генерального директора Организации или его заместителя.

В резолюции указываются:

Исполнитель документа;

Срок исполнения задачи;

При необходимости - содержание задачи.

3.1.3. Получив документ с резолюцией, секретарь генерального директора или секретарь заместителя генерального директора (далее - Секретари) готовят скан-копию документа с резолюцией. Отсканированный документ помещается в папку «На контроле».

3.1.4. Файл копии документа вкладывается в электронное сообщение, направляемое исполнителю.

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

3.1.6. После получения электронного сообщения с задачей исполнитель направляет автору задачи уведомление о ее получении.

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

3.2. Выполнение задания.

3.2.1. Исполнитель выполняет поставленную перед ним задачу в установленный в резолюции срок.

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

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

3.2.4. В случае если срок выполнения задачи был продлен руководителем, автор задачи изменяет срок ее выполнения в электронной карточке документа.

3.3. Отчет о выполнении задания.

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

3.3.2. Получив отчет о выполнении задачи, автор задачи ставит статус «Выполнено» в электронной карточке документа. Документ изымается из папки «На контроле» и помещается в дело.

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

3.3.4. В случае если срок выполнения задачи был продлен руководителем, автор задачи изменяет срок выполнения в электронной карточке документа.

3.4. Формирование отчета о выполнении задач.

3.4.1. Секретари ежемесячно формируют отчет о выполнении задач по документам, который представляют руководителю.

В отчете указывается:

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

Количество выполненных задач;

Количество задач с продленным сроком исполнения;

Количество задач, не выполненных в срок.

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

4. Ответственность

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

5. Контроль

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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ РФ

НОУ ВПО «СИБИРСКАЯ АКАДЕМИЯ ПРАВА, ЭКОНОМИКИ И УПРАВЛЕНИЯ»

Факультет: Компьютерных Технологий и Информационных Систем

Кафедра Информационных Систем

ДИПЛОМНАЯ РАБОТА

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

Иркутск 2009

Введение. 3

1. Теоретическая часть. 9

1.1 Формирование требований как основной этап в разработке АИС.. 9

1.2 Функциональное моделирование бизнес-процессов. 17

1.3 Среда бизнес моделирования BPwin. 35

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

2.1 Анализ деятельности ОАО «АНХК» и структуры предприятия. 41

2.1 Анализ проблемы автоматизированных информационных систем ОАО «АНХК» 46

2.2 Изучение задач управления. 52

2.3 Описание входной информации. 53

2.5 Описание выходной информации. 54

3. Алгоритм функционирования системы моделирования и его описание. 56

3.1 Информационный анализ процессов и создание контекстной

диаграммы.. 56

3.2 Создание диаграмм декомпозиций. 60

3.3 Создание диаграммы дерева узлов и диаграммы FEO.. 67

Список литературы.. 74

Введение

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1. Схема вертикально-интегрированных нефтяных компаний

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

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

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

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

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

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