Разработка рекомендаций по оптимизации бизнес-процессов ООО Specia



Оглавление

ВВЕДЕНИЕ

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

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

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

1) Произвести анализ литературных источников по тематике бизнес-процессов, определить ключевые термины и дать им однозначную коннотацию;

2) Произвести аналитический обзор существующих методик моделирования и оптимизации бизнес-процессов;

3) Привести общее описание и дать характеристику компании «Specia»;

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

5) Проанализировать бизнес-процессы и определить их ключевые проблемные аспекты;

6) Разработать пул рекомендаций, направленных на оптимизацию операционной деятельности в ООО «Specia», его бизнес- процессов;

7) Произвести моделирование и прогноз возможных эффектов от предложенных мероприятий.

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

Предметом исследования является аспекты бизнес-процессов, которым требуется оптимизация, в комплексном бизнес-процессе ООО «SPECIA».

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

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

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

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

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

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

Глава 1. Теоретические основы бизнес-процессов иevent-менеджмента

1.1 Понятие и сущность бизнес – процессов в организации

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

Так, В.В. Кондратьевым и М.Н. Кузнецовым дано определение бизнес-процесса как совокупности связанных шагов, которые направлены на достижение организационной цели в рамках существующей организационной структуры [Кондратьев и Кузнецов, 2].

М. Хаммер и Д. Чампи определяют понятие бизнес-процесс как набор связанных задач, которые заключаются в предоставлении услуги или продукта клиенту. Процесс содержит набор атрибутов и шагов для достижения задачи. В целом, бизнес-процесс помогает в управлении операциями таким образом, чтобы он мог производить ценные результаты [Хаммер и Чампи, 32].

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

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

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

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

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

Происхождение управления бизнес процессов (BPM-BusinessProcessManagement) началось в 1990-х годах. На сегодняшний день, оно эволюционирует во многие концепции, включая управление потоками (WFM), обработку дел (CH), интеграцию корпоративных приложений (EAI), планирование ресурсов предприятия (ERP), управление отношениями с клиентами (CRM) и т. д [Громов, 2016].

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

Деятельность по управлению бизнес-процессами включает в себя проектирование, моделирование, оптимизацию и реинжиниринг [Галямина, 2013].

Моделирование бизнес-процессов - это схематическое/ структурное представление потока деловой активности в организации или функции внутри организации. Его основное использование заключается в том, чтобы документировать и основывать текущий поток деятельности, чтобы определить улучшения для быстрого выполнения задач. Обычно они соответствуют стандарту, к примеру, «Обозначение бизнес-процессов» (BPMN), которое является общепринятым стандартом, с которым легко идентифицировать большинство процессов [Елиферов, Репин, 2005].

Оптимизация и совершенствование бизнес-процессов тесно связаны друг с другом, однако, следует понимать разницу между этими понятиями. Так, совершенствование (оптимизация) бизнес-процессов определяется как концепция стратегического планирования, направленная на частичное изменение бизнес-процессов с целью повышения эффективности и способствования роста бизнеса [Грущенко, 2010]. В отличии от оптимизации, реинжиниринг бизнес-процессов включает в себя полный редизайн бизнес-процессов после тщательного анализа [Абдикеев, 2008]. Основой BPR является переработка процессов, особенно тех, которые помогают в развитии бизнес-ценности организации, а ИТ используется как простой инструмент, который помогает в автоматизации процессов [Ротер, 2015].

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

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

1.2.1 ДиаграммаDFD

Диаграмма потоков данных (DFD) является методологией, которая отображает поток информации для любого процесса или системы. Она использует определенные символы, такие как прямоугольники, круги и стрелки, а также короткие текстовые метки для отображения входов и выходов данных, точек хранения и маршрутов между каждым пунктом назначения. Блок-схемы данных могут варьироваться от простых, даже отрисованных вручную обзоров процессов, до глубоких многоуровневых, которые постепенно углубляются в процесс обработки данных. Они могут использоваться для анализа существующей системы, так и моделирования новой [Цисарь, 2012а].

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

Диаграммы потоков данных были популяризированы в конце 1970-х годов, возникшие из книги «Структурированный дизайн», путем вычисления пионеров Эдом Тьюдоном и Ларри Константином. Они основывали его на моделях вычисления графика потока данных Дэвидом Мартином и Джеральдом Эстрином[Цисарь, 2012б].

Существует две разных моделей обозначений для диаграмм потоков данных: Йордон и Коад (Yourdon&Coad) или Гейн и Сарсон (Gane&Sarson), определяющих различные визуальные представления для процессов, хранилищ данных, потока данных и внешних объектов.

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

Еще тремя экспертами, способствовавшими созданию методологии DFD, были Том ДеМарко, Крис Гане и ТришСарсон. Они объединились в разных комбинациях, чтобы быть основными определителями символов и обозначений, используемых для диаграммы потока данных.

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

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

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

1.2.2 eEPC

EEPC India является ведущей организацией по поощрению торговли и инвестиций в Индии. Она спонсируется Министерством торговли и промышленности, правительством Индии и обслуживает индийский машиностроительный сектор. В качестве консультативного органа она активно содействует политике правительства Индии и выступает в качестве интерфейса между машиностроительной промышленностью и правительством [Назарова, 2012].

Созданная в 1955 году, EEPC India теперь имеет членскую базу, насчитывающую более 13 000 человек, из которых 60% являются SMEs.EEPC Индия организует большое количество рекламных акций, таких как встреча покупателей и продавцов (BSM) - как в Индии, так и за рубежом, за рубежом ярмарок / выставок и павильонов / информационных стендов в Индии на отдельных зарубежных выставках, чтобы продемонстрировать возможности индийской машиностроительной промышленности и предоставить зарубежным покупателям истинную ценность, распространяемую Brand India. India Engineering Exhibition (INDEE) является собственным брендом EEPC в Индии и является одна из крупнейших экспозиций техники в мире[Новикова, 2016а].

Чтобы стимулировать создание глобальных партнерских отношений с Индией, EEPC India организует International Engineering Sourcing Show (IESS), крупнейший показ инженерных продуктов и услуг каждый год. Это признано единственным событием в Индии - демонстрацией новейших технологий и предпочтительного места встречи для глобальных покупателей и продавцов. Это шоу также важно для поощрения иностранных инвестиций в соответствии с недавно начатой ​​кампанией «Сделай в Индии» правительством Индии. Расширяя свою регулярную повестку дня, EEPC India публикует несколько докладов / исследований, чтобы информировать участников о международных тенденциях и возможностях с тем чтобы укрепить их глобальные следы. Сохраняя «Инженерное будущее» в качестве девиза, EEPC India служит ориентиром для индийской машиностроительной промышленности и международного делового сообщества в его усилиях по созданию Индии в качестве крупного инженерного центра в будущем.

Основными целями методики EEPC India являются:

  1. Поддержка, защита, увеличение и продвиение экспорта инженерных товаров;
  2. Поддержка постоянную связь с торговыми палатами и другими торговыми и государственными органами во всем мире с целью принятия надлежащих и необходимых мер для поддержания или увеличения экспорта инженерных товаров
  3. Консультирование и представление правительству, местным органам власти и государственным органам политики и другие меры;
  4. Модернизация технологий для развития индийского экспорта и установления синергии между промышленностью и научными кругами;
  5. Подготовка, редактирование, выпуск, приобретение и распространение изданий и продуктов печатного полиграфического производства, таких как:  книги, газеты, периодические издания, журналы, циркуляры и другие литературные материалы- относящихся к промышленности, торговле или торговле, а также к инженерным товарам[Новикова, 2016б].

1.2.3 Пакет инструментовAris

ARIS представляет собой набор инструментов, охватывающих архитектуру бизнес- процессов, архитектуру ИТ и другие. Он позиционируетсяGartner в квадранте лидеровMagicQuadrant дляEnterpriseArchitecture и поставщиков инструментовBPM. Различные аспекты данного инструмента представляют собой тару функциональности инструмента для привлечения определенных категорий пользователей (аналитики бизнес-процессов, бизнес-архитекторов, ИТ-архитекторов и т. Д.) [Ильин, 2006а].

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

Еще один интересный аспектARIS заключается в том, что помимо того, что он является инструментом, он также является методологией для моделирования процессов. Эта методология основана на концептуальной модели (или метамодели), которая сочетает в себе перспективы разных точек зрения и абстракции для создания интегрированной структуры, называемойARISHouse [Каменнова, 2000а].

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

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

Комбинация представлений и уровней определяет тип моделей, поддерживаемых ARIS, и здесь гибкость модели способствует полезности инструмента. ARIS определяет свои собственные обозначения, которые будут использоваться для моделей в соответствующих комбинациях представлений и уровней. Таким образом, ARIS действительно представляет собой набор модельных обозначений, организованных в соответствии со структурой ARIS [Репин, 2003]. Поэтому с ARIS можно поддерживать различные структуры, методологии и обозначения (например, TOGAF, а также BPMN, UML, IT-планирование города и т. д.). Посредством сопоставления их частей с различными частями дома ARIS и добавления соответствующих обозначений сам поставщик инструментов предоставляет несколько плагинов, которые обогащают методологию, структуру и обозначения [Ильин, 2006б].

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

Рис. 1. МетодологияAris

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

Одним из недостатков ARIS являются большая величина переменных затрат, вызванных внедрением данного ПО. Стоимость одной лицензированной копии составляет более 1000 евро за лицензию [Каменнова, 2000б]. Во всяком случае, это необходимо учитывать при выборе инструмента, а также при согласовании с другими инструментами технологического инструментария предприятия, но, что более важно, с концепцией его технологического развития.

1.2.4 МетодологияBPMN

Business Process Modeland Notation (BPMN) – это методология, которая моделирует шаги запланированного бизнес-процесса. Это ключ к управлению бизнес-процессами, он визуально отображает подробную последовательность бизнес-операций и информационных потоков, необходимых для завершения процесса [Федоров, 2013а].

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

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

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

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

Группа управления объектами (OMG) предоставляет пять сертификатов в BPMN 2.0 под названием OCEB 2, что означает OMG-CertifiedExpert в BPM 2.0. OMG намерена для BPMN 2.0 стандартизировать моделирование бизнес-процессов так же, как стандартизованное программное обеспечение унифицированного моделирования (UML)[Белайчук,2017б].

BPMN требует времени и энергии, но выигрыш в понимании и улучшении может быть огромным. Версия 2.0 основывается на предыдущих версиях, предоставляя более богатый стандартный набор символов и обозначений, позволяя более подробно для тех, кто в ней нуждается. Идея управления бизнес-процессами - создать жизненный цикл непрерывного совершенствования. Этапы - это моделирование, внедрение, выполнение, мониторинг и оптимизация. Диаграммы BPMN играют ключевую роль в этом[Калянов,2006б].

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

  1. Частные бизнес-процессы являются внутренними для конкретной организации и не пересекают пулы или организационные границы.
  2. Абстрактные бизнес-процессы. Это происходит между частным / внутренним процессом и другим участником или процессом. Абстрактный процесс показывает внешнему миру последовательность сообщений, необходимых для взаимодействия с частным процессом. Он не показывает сам частный / внутренний процесс.
  3. Совместные бизнес-процессы. Они показывают взаимодействие между двумя или несколькими бизнес-объектами [Калянов,2006б].

1.2.5 Методология UML

UML (Unified Modeling Language) представляет собой стандартизованный язык моделирования, состоящий из интегрированного набора диаграмм, разработанных для помощи разработчикам систем и программного обеспечения для определения, визуализации, построения и документирования артефактов программных систем, а также для моделирования бизнеса и других непрограммных систем. UML включает в себя набор лучших инженерных практик, которые оказались успешными при моделировании больших и сложных систем[Окулецкий, 2005].

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

Целью UML является предоставление стандартной нотации, которая может использоваться всеми объектно-ориентированными методами, а также выбор лучших элементов нотификаций предшественников. UML был разработан для широкого спектра приложений, следовательно, он предоставляет конструкции для широкого спектра систем и видов деятельности (например, распределенные системы, анализ, проектирование и развертывание системы) [Голоктеев, 2008].

Поскольку стратегическая ценность программного обеспечения возрастает для многих компаний, отрасль ищет методы автоматизации производства программного обеспечения и повышения качества и сокращения затрат и времени выхода на рынок. Эти методы включают компонентную технологию, визуальное программирование, шаблоны и рамки. Предприятия также ищут методы для управления сложностью систем по мере их увеличения масштабов и масштаба. В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость. Кроме того, разработка World Wide Web, упрощая некоторые вещи, усугубила эти архитектурные проблемы. Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей. Основные цели в разработке UML в фундаментальном объектно-ориентированном дизайне являютcя[Гличев, 2005]:

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

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

1.2.6IDEF

IDEF (Integrated Definition) - это графическая методология моделирования процессов, используемая для внедрения систем и инженерного программного обеспечения. Эти методы используются в функциональном моделировании данных, имитации, объектно-ориентированном анализе и приобретении знаний [Дворников, 2005а].

IDEF был разработан ВВС США в середине 1970-х годов, как стандартный метод документирования и анализа бизнес-процессов. Теперь эта методология используется как регламентированный подход к анализу предприятия, захват моделей процессов «как есть» и для моделирования действий в рамках бизнес-группы. Несмотря на то, что IDEF был первоначально разработан для производственной среды, теперь эта методология моделирования процессов применяется для более широкого использования и для разработки программного обеспечения в целом [Дворников, 2005б].

IDEF относится к семейству языков моделирования, который включает 16 различных методов. Эти методы моделирования процессов охватывают широкий спектр применений, и каждый метод захватывает определенный тип данных [Окулецкий, 2005a].

Наиболее часто используемые методами являются DEF0 – IDEF4. Рассмотрим, каким образом работает стандартIdef0.

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

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

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

Четыре типа стрелок, входы, элементы управления, выходы и механизмы совместно называютсяICOM, аIDEF - сокращениемICOMDEFinition. НаIDEF0 есть нуль, поскольку существует ряд дополнительных стандартовIDEF [Абдикеев, 2005].

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

Рис.2. Функциональный блокIDEF0

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

Каждая диаграмма IDEF0 состоит из трех-шести полей операций с стрелками ICOM, соединяющими ящики. Каждый блок действий может быть разбит, чтобы показать подпроцесс, который он представляет. Когда это произойдет, стрелки ICOM, которые вводят и оставляют окно, обычно появляются в разложенном процессе. Это не принудительно, и когда стрелки не появятся на разложенной диаграмме, стрелка содержит круглые скобки вокруг нее. Аналогично, когда новая диаграмма ICOM используется на диаграмме, которая не была показана на родительской диаграмме, скобки используются в начале стрелки [Черемных, 2001a].

Нумерация используется для связывания диаграмм вместе. Каждая диаграмма имеет A-номер. Диаграмма верхнего уровня, содержащая один поле активности, называется диаграммой A-0 (минус нуль). Диаграммы нижнего уровня нумеруются в соответствии с полем, из которого они были начаты процессы, поэтому первый квадрат на диаграмме A0 становится A1, причем первое поле на этой диаграмме становится A11 и т. д.

Каждая диаграмма также имеет «C-число», в ко