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

I:

S:
Семейство стандартов IDEF предназначено
для

+:
описания бизнес — модели предприятий

-:
планирования производственного цикла

-:
описания структуры бухгалтерского
учёта

I:

S:
Методология моделирования информационных
потоков определяется стандартом

-:
IDEF0

+:
IDEF1

-:
IDEF2

-:
IDEF3

-:
IDEF4

-:
IDEF5

I:

S:
Методология функционального моделирования
определяется стандартом

+:
IDEF0

-:
IDEF1

-:
IDEF2

-:
IDEF3

-:
IDEF4

-:
IDEF5

I:

S:
Методология динамического моделирования
развития систем определяется стандартом

-:
IDEF0

-:
IDEF1

+:
IDEF2

-:
IDEF3

-:
IDEF4

-:
IDEF5

I:

S:
Методология документирования процессов,
происходящих в системе определяется
стандартом

-:
IDEF0

-:
IDEF1

-:
IDEF2

+:
IDEF3

-:
IDEF4

-:
IDEF5

I:

S:
Методология построения объектно-ориентированных
систем определяется стандартом

-:
IDEF0

-:
IDEF1

-:
IDEF2

-:
IDEF3

+:
IDEF4

-:
IDEF5

I:

S:
Методология онтологического исследования
сложных систем определяется стандартом

-:
IDEF0

-:
IDEF1

-:
IDEF2

-:
IDEF3

-:
IDEF4

+:
IDEF5

I:

S:
Совокупность понятий «функциональный
блок», «интерфейсная дуга», «декомпозиция»
и «глоссарий» лежит в основе стандарта

+: IDEF0

-: IDEF1

-: IDEF2

I:

S:
Функциональный блок графически
изображается в виде

-: круга

-:
эллипса

+:
прямоугольника

I:

S:
Верхняя сторона функционального блока
имеет значение

-: Вход

+:
Управление

-: Выход

I:

S:
Правая сторона функционального блока
имеет значение

-: Вход

-:
Управление

+: Выход

I:

S: Левая
сторона функционального блока имеет
значение

+: Вход

-:
Управление

-: Выход

I:

S:
Нижняя сторона функционального блока
имеет значение

+:
Механизм

-:
Управление

-: Выход

I:

S: По
требованиям стандарта IDEF0 любой
функциональный блок должен иметь по
крайней мере

+: одну
интерфейсную дугу

-: две
интерфейсных дуги

-: три
интерфейсных дуги

I:

S:
Источником интерфейсной дуги может
быть только сторона интерфейсного
блока, имеющая значение

-: Выход

-: Вход

+:
Управление

I:

S:
Приёмником интерфейсной дуги НЕ может
быть сторона интерфейсного блока,
имеющая значение

-: Выход

+: Вход

-:
Управление

I:

S:
Согласно стандарта IDEF0 декомпозиция
диаграмм применяется для

-:
характеристики объекта, отображенного
каким-либо элементом

+:
разбиения сложного процесса на
составляющие его функции

-:
обеспечение возможности получения
отчетов о состоянии бизнес-процесса

I:

S:
Обозначение “туннеля” в виде двух
круглых скобок вокруг начала интерфейсной
дуги обозначает, что

-: в
дочерней по отношению к данному блоку
диаграмме эта дуга отображаться и
рассматриваться не будет

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

-:
данная интерфейсная дуга является
управляющей

I:

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

-:
четырьмя

-: пятью

+:
шестью

I:

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

+: тремя

-:
четырьмя

-: двумя

I:

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

-: тремя

+:
четырьмя

-: двумя

I:

S:
Стандарт IDEF3 предоставляет средства
для моделирования

+:
сценариев технологических процессов

-:
содержания интерфейсных дуг

-:
декомпозиции функциональных блоков

I:

S: В
стандарте IDEF3 имеется

-: один
тип диаграмм

+: два
типа диаграмм

-: три
типа диаграмм

I:

S: С помощью PFDD
диаграмм стандарта IDEF3 документируются

+: последовательность
и описание стадий обработки детали в
рамках исследуемого технологического
процесса

-: трансформации
детали, которые происходят на каждой
стадии обработки

-: процессы контроля
качества детали

I:

S: С
помощью OSTN диаграмм стандарта IDEF3
документируются

-:
последовательность и описание стадий
обработки детали в рамках исследуемого
технологического процесса

+:
трансформации детали, которые происходят
на каждой стадии обработки

-:
процессы контроля качества детали

I:

S:
Согласно стандарта IDEF5 для обеспечения
логической систематизации знаний,
накопленных при изучении системы
применяются

+:
диаграммы классификации

-:
композиционные схемы

-:
диаграммы состояний объекта

I:

S:
Согласно стандарта IDEF5 для графического
представления состава классов онтологии
системы применяются

-:
диаграммы классификации

+:
композиционные схемы

-:
диаграммы состояний объекта

I:

S:
Согласно стандарта IDEF5 для документирования
того или иного процесса с точки зрения
изменения состояний объекта применяются

-:
диаграммы классификации

-:
композиционные схемы

+:
диаграммы состояний объекта

I:

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

-:
итеративным

-:
однонаправленным

+:
двунаправленным

I:

S: Семейство
стандартов MRP предназначено для

+: управления
производственным предприятием

-:
управления персоналом

-:
управления финансами

I:

S:
Главной задачей технологии MRP является
обеспечение

-:
качества продукции

+:
гарантии наличия необходимого количества
материалов-комплектующих

-:
минимума производственных затрат

I:

S:
Основным входным элементом MRP системы
является

-: План
заказов

+:
Описание состояния материалов

-:
Прогноз спроса

I:

S:
Основным выходным элементом MRP системы
является

+: План
заказов

-:
Описание состояния материалов

-:
Прогноз спроса

I:

S: MRP
система является системой

: с
обратной связью

+: без
обратной связи

-:
имеющей и прямую и обратную связь

I:

S:
Главным отличием методология MRPII от MRP
состоит в том, что

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

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

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

I:

S:
Согласно стандарта MRPII модуль планирования
развития бизнеса

-:
оценивает, какими должны быть объем и
динамика продаж

-:
формирует план производства всех видов
готовых изделий и их характеристики

+:
формирует бизнес-план компании

I:

S:
Согласно стандарта MRPII модуль планирования
продаж

+:
оценивает, какими должны быть объем и
динамика продаж

-:
формирует план производства всех видов
готовых изделий и их характеристики

-:
формирует бизнес-план компании

I:

S:
Согласно стандарта MRPII модуль планирования
производства

-:
оценивает, какими должны быть объем и
динамика продаж

+:
формирует план производства всех видов
готовых изделий и их характеристики

-:
формирует бизнес-план компании

I:

S:
Согласно стандарта MRPII модуль планирования
потребности в материалах

-:
оценивает, какими должны быть объем и
динамика продаж

-:
формирует план производства всех видов
готовых изделий и их характеристики

+:
определяет требуемое расписание закупки
или внутреннего производства всех
материалов

I:

S:
Согласно стандарта MRPII модуль планирования
производственных мощностей

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

-:
формирует план производства всех видов
готовых изделий и их характеристики

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

I:

S:
Концепция SCRP состоит в

+:
планировании ресурсов предприятия,
синхронизированное с продажами продукции

-:
планировании производства с учётом
работы с сетью филиалов

-:
планировании производства с учётом
логистических схем

I:

S: В
контексте задач планирования ERP системы
представляют собой

-: MRP
системы, дополненные функцией управления
персоналом

+: MRPII
системы, дополненные функциями работы
с сетью филиалов и зависимых компаний

-: MRP
системы, дополненный функциями управления
финансами

I:

S: Для
MRPII-системы лишним является модуль

-:
Планирование развития бизнеса (составление
и корректировка бизнес-плана)

+:
Кадровый учет и кадровая политика

-:
Планирование продаж

I:

S: В семействе
стандартов MRP под статусом материала
понимается

-:
покупательский спрос

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

-:
уровень качества материала

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

•  Путеводитель хороший не посоветуете? Пожалуй вот… возьмите Данте. 

Определение и история

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

Можно отметить 3 самые популярные нотации: семейство IDEF, eEPC и BPMN 2.0. Про BPMN 2.0 я уже писал, теперь давайте немного поговорим о нотации IDEF.

Для начала давайте дадим определение данной нотации и возьмем его из Википедии.

IDEF (I-CAM DEFinition или Integrated DEFinition — «объединённое определение») — это «методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяют отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными» 

История семейства нотаций IDEF начинается в 70-х годах XX века, когда была разработана методология SADT (Structured Analysis and Design Technique), которая применялась Министерством обороны США для моделирования процессов в рамках программы ICAM (Integrated Computer Aided Manufacturing). В те времена нотаций для бизнес- и системного моделирования в явном виде не было, и крупные организации самостоятельно приходили к потребности унифицировать и создать некоторый внутренний стандарт изображения моделей. Большинство современных нотаций выросло именно из таких решений, так как они были проверены на практике. Именно так и появилось семейство IDEF.

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

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

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

IDEF0  (Function Modeling)

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

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

Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации.

К ее особенностям можно отнести:

• использование контекстной диаграммы;

• поддержка декомпозиции;

• доминирование;

• выделение 4 типов стрелок.

Пример диаграммы процесса «Приготовление борща» первого уровня в IDEF0:

Пример диаграммы декомпозированного процесса «Приготовление борща» в IDEF0:

IDEF1 (Integration Definition for Information Modeling)

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

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

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

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

Основные характеристики:

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

Для чего используется:

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

Преимущества:

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

Недостатки:

• Диаграммы может визуально показаться непривлекательной.
• Диаграммы с множеством прямоугольников и стрелок может плохо читаться.

Пример модели IDEF1 «Работа в ресторане»:

IDEF1X (IDEF1 Extended)

IDEF1X — “это язык моделирования данных для разработки семантических моделей данных.
Используется для создания графической модели информации, которая представляет собой структуру и семантику из информации в среде или системе” («Википедия»).

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

Основными элементами модели IDEF1X являются сущности, атрибуты и отношения.

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

• диаграмма «Сущность — связь» (Entity Relationship Diagram — ERD);

• модель данных, основанная на ключах (Key Based Model — КВМ);

• полная атрибутивная модель (Fully Attributed Model — FAM).

Пример описания сущности в нотации IDEF1X

Основные характеристики:

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

Для чего используется:

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

Преимущества:

• Простота изучения и возможность автоматизации.
• Используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).
• Жесткая и строгая стандартизация моделирования, что позволяет избежать различной трактовки построенной модели, которая, является значительным недостатком ER-диаграмм.

Недостатки:

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

Пример графической диаграммы:

Пример модели данных о коллекционерах марок в нотации IDEF1X:

IDEF2 (Simulation Model Design) 

IDEF2 — это методология динамического моделирования развития систем, то есть отображающая
изменение систем в динамике.

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

Пример модели на базе сети Петри «Использование вычислительных ресурсов ЭВМ»:

IDEF3 (Process Description Capture)

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

Нотация IDEF3 может быть использована:

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

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

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

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

В стандарте IDEF3 есть два типа диаграмм, которые представляют описание одного и того же сценария технологического процесса в разных ракурсах. Первый тип — диаграммы описания последовательности этапов процесса (Process Flow Description Diagrams, PFDD), а второй — диаграммы состояния объекта в процессе его трансформаций (Object State Transition Network, OSTN).

Основные характеристики:

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

Для чего используется:

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

Преимущества:

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

Недостатки:

• При некоторых вариантах описания схемы процессов невозможно прочитать однозначно.
• Нотация изначально предназначалась для технических специалистов, поэтому содержит специальные перекрестки, такие как, «XOR», «Synchronous OR», «Asynchronous OR», «Synchronous AND» и «Asynchronous AND», знакомые программистам, но не знакомые для обыкновенных пользователей.

Пример диаграммы PFDD для процесса «Подбор структуры технологического материала в
соответствии с требуемыми характеристиками изготовляемой из него детали»:

Диаграмма описания последовательности этапов PFDD

Пример диаграммы OSTN для процесса «Выработка изделия»:

IDEF4 (Object-Oriented Design)

Методология IDEF4 вводит объектно-ориентированный подход в набор стандартов IDEF. Является основой для построения методики UML, и сейчас практически не применяется.

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

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

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

1. Уровень проектирования. Уровень верхний — система, уровень её блоков или модулей и наиболее детализированный уровень дизайна.
2. Описание статусов объекта дизайна.
3. Определение типа моделей взаимодействия: статические, динамические и модели смешанного поведения.
4. Расчётное обоснование моделей и уточнение её конструктивных особенностей от общего к частному.

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

Для чего используется:

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

Преимущества:

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

Недостатки:

• Получила более широкое развитие в других нотациях и сейчас практически не используется.

Пример диаграммы описания статической модели взаимодействия объектов системы «Оркестр» с
высокой детализацией в IDEF4: 

IDEF4/C++

IDEF4/C++ (C++ Object-Oriented Design) — методология построения объектно-ориентированных систем.

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

Данная нотация является частным случаем IDEF4.

IDEF5 (Ontology Description Capture)

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

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

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

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

• Схематический язык (Schematic Language — SL) – это наглядный графический язык, специально предназначенный для изложения компетентными специалистами в рассматриваемой области системы основных данных в форме онтологической информации.
• Язык доработок и уточнений (Elaboration Language — EL) представляет собой структурированный текстовой язык, который позволяет детально характеризовать элементы онтологии.

Преимущества:

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

Недостатки:

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

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

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

Пример диаграммы классификации геометрических фигур в IDEF5:

2. Композиционные схемы (Composition Schematics) — это механизм графического представления состава классов онтологии. Фактически представляют собой инструменты онтологического исследования по принципу «что из чего состоит».

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

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

Пример схемы взаимосвязей типов отношений объектов в системе в IDEF5:
4. Диаграмма состояния объекта (Object State Schematic) — вид диаграмм, который позволяет задокументировать тот или иной процесс как последовательность действий над объектом системы с точки зрения изменения состояний этого объекта.

Пример диаграммы состояний воды в IDEF5:

IDEF6 (Design Rational Capture Method)

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

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

Основные характеристики:

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

Для чего используется:

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

Преимущества:

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

Пример диаграммы проведения анализа объектов системы в IDEF6:

IDEF7

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

IDEF8 (User Interface Modeling)

IDEF8 — это стандарт для описания для описания взаимодействия системы и её пользователей —
пользовательских интерфейсов.

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

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

Основные характеристики:

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

Преимущества:

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

Пример графической диаграммы:

Пример диаграммы «Поведение системы “Принтер” в случае, когда закончилась бумага для печати» в IDEF8:

IDEF9 (Business Constraint Discovery) 

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

Подход IDEF9 основан на методе Business Constraint Discovery method (метод исследования бизнес-ограничений), который помогает руководителям и аналитикам предусмотреть все возможные риски, возникающие в связи с влиянием каждого из условий и ограничений, а значит, и подготовить необходимые меры их митигации или устранения. К сожалению, далеко не всегда этот стандарт или любые его аналоги используются при проектировании систем, что, конечно, не означает, что все остальные действия по анализу и разработке проекта бесполезны. Однако это часто позволяет команде упустить важные факторы, которые приводят к непредвиденным трудностям уже в процессе
внедрения и эксплуатации системы. Это сказывается на её потенциале и удовлетворении
пользователей.

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

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

IDEF10 – IDEF13

IDEF10 — методология моделирования архитектуры выполнения (Implementation Architecture
Modeling).
IDEF11 — методология моделирования информационных артефактов (Information Artifact Modeling).
IDEF12 — методология организационного моделирования (Organization Modeling).
IDEF13 — методология трёхсхемного проектирования преобразования данных (Three Schema Mapping
Design).
Данные методологии так и не были полностью разработаны, несмотря на высокую востребованность
стандартизации анализа в упомянутых сферах проектирования систем.

IDEF14 (Network Design)

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

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

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

Основные характеристики:

• Нотация может быть использована для моделирования существующих («Как есть» / AS-IS) компьютерных сетей или тех, которые должны быть («Как будет» / ТО-BE). Это позволяет разработчику рассмотреть конфигурацию сети с точки зрения «Что если» и оформить разумное объяснение.
• Нотация позволяет устанавливать требования, определять сетевые компоненты, анализировать существующие сетевые конфигурации и формулировать желаемые характеристики сети.

Для чего используется:

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

Содержание:

Введение

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

В США это обстоятельство было осознано еще в конце 70-ых годов, когда ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM – Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.

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

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

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

1. Теоретические основы методологии IDEF

1.1 История возникновения стандарта IDEF

IDEF0, как стандарт, был разработан в 1981 году департаментом Военно-Воздушных Сил США в рамкахпрограммы автоматизации промышленных предприятий, которая носила обозначение ICAM (IntegratedComputer Aided Manufacturing).

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

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

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года НациональнымИнститутом По Стандартам и Технологиям США (NIST). [1, с. 62]

1.2 Описание методологий семейства IDEF (ICAM Defenition)

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия: первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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

— Верхняя сторона имеет значение «Управление» (Control);

— Левая сторона имеет значение «Вход» (Input);

— Правая сторона имеет значение «Выход» (Output);

— Нижняя сторона имеет значение «Механизм» (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного. [2, с. 124]

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). [2, с. 226]

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

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

Рисунок 2. Пример процесса декомпозиции

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А0».

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

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок – предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). [4, с. 162]

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

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

Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме.

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

Рисунок 3. Процесс туннелирования

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией. [3, с. 241]

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

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

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

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

1.3 Модели AS-IS и ТО-ВЕ

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

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

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

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

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т.е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т.е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого. [4, с. 163]

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

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

1.4 Семейство стандартов IDEF

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

IDEF0 — Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique);

IDEF1 — Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X (IDEF1 Extended) — Data Modeling — методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» (ER — Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

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

IDEF3 — Process Description Capture — Документирование технологических процессов, IDEF3 — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

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

IDEF5 — Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 — Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF7 — Information System Auditing — Аудит информационных систем. Этот метод определён как востребованный, однако так и не был полностью разработан; IDEF8 — User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDFE8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 — Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие;

IDEF10 — Implementation Architecture Modeling — Моделирование архитектуры выполнения. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF11 — Information Artifact Modeling. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF12 — Organization Modeling — Организационное моделирование. Этот метод определён как востребованный, однако так и не был полностью разработан;

IDEF13 — Three Schema Mapping Design — Трёхсхемное проектирование преобразования данных. Этот метод определён как востребованный, однако так и не был полностью разработан;

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

2. функционально-стоимостной анализ реинжиниринга бизнес-процесса в компании ООО «Промтехнологии»

2.1 Характеристика предприятия ООО «Промтехнологии»

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

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

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

Наряду с этим данное предприятие поставляет высококачественные промышленные шланги, воздуховоды, рукава высокого давления, трубки ПВХ для предприятий Урала и близлежащий городов. ООО «Промтехнологии» располагают собственными производственными линиями электрооборудования в Екатеринбурге, а также конвейеров и подъёмников в Кургане.

Рисунок 4.Структура ООО «Промтехнологии»

2.2 Описание бизнес-процессов в компании ООО «Промтехнологии»

Основные бизнес-процессы в организации представляют главные центры сосредоточения прибыли и затрат. На рисунке 5 схематично представлен производственный процесс в компании ООО «Промтехнологии».

Производство продукции

Оптовая закупка сырья и полуфабрикатов

Техническая проверка, и оснастка, грузовых автомобилей

Хранение материалов и изготовленных изделий

Погрузка и отправка продукции заказчику

Рисунок 5.Производственный процесс ООО «Промтехнологии»

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

Продолжение рисунка 6

Рисунок 6. Схема бизнес-процесса «торговля готовой продукцией» ООО «Промтехнологии»

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

Для большей наглядности необходимо представить процесс в разрезе отделов компании ООО «Промтехнологии». На рисунке 7 представлена функциональная схема описываемого выше процесса.

ЗАКАЗЧИК	ОТДЕЛ ПРОДАЖ	БУХГАЛТЕРИЯ	ОТДЕЛ ЗАКУПОК	ТРАНСПОРТНЫЙ ОТДЕЛ
Поступил заказ
	Оформление заявки, составление договора
		Выставление счета на оплату
			Формирование заказа по заявке
				Техосмотр транспортного средства
	Согласование даты и времени доставки с заказчиком
	Передача водителю документов
				Выезд автомобиля на склад для погрузки заказа
				Доставка заказа в пункт назначения
				Возврат ТС обратно

Рисунок 7. Функциональная схема бизнес-процесса до реинжиниринга

2.3 Штатное расписание ООО «Промтехнологии»

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

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

В Таблице 2 предоставлен анализ штатного расписания ООО «Промтехнологии».

Таблица 2. Штатное расписание компании ООО «Промтехнологии»

№ п/п	Структурная единица	Кол-во (чел)	Оклад (руб.)	ФОТ	ЧТС (год)	ФРВ (час)
(год)
1	директор	1	30000	360000	202,70	1776
2	заместитель директора	1	25000	300000	168,92	1776
3	помощник специалиста	1	13000	156000	87,84	1776
4	главный бухгалтер	1	18000	216000	121,62	1776
5	бухгалтер	1	13000	156000	87,84	1776
6	экономист	1	18000	216000	121,62	1776
7	юрист	1	13000	156000	87,84	1776
8	помощник менеджера по закупкам	1	13000	156000	87,84	1776
9	менеджер по закупкам	2	14000	336000	189,19	1776
10	менеджер по продажам	3	14000	504000	283,78	1776
11	водитель-экспедитор	3	18000	648000	364,86	1776
12	автоинженер	2	20000	480000	270,27	1776
13	охранник	2	12000	288000	162,16	1776
14	подсобный рабочий	1	9000	108000	60,81	1776
15	уборщик	2	8000	192000	108,11	1776
	Итого:	23	238000	4272000

На сегодняшний день, компания ООО «Промтехнологии» содержит в штате 23 сотрудников и ведет активную кадровую политику на протяжении последних 12 месяцев.

Месячный фонд оплаты труда составляет 238 000 рублей.

Годовой фонд оплаты труда равен 4 272 000 рублей.

Фонд рабочего времени за 2018 год составил 1776 часов.

2.4 Анализ структурно-элементной модели. Классификация функций

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

Таблица 3. Анализ структурно-элементной модели и классификация функций ООО «Промтехнологии»

№	Наименование функции	Вид функции	Затраты час/год	Затраты на операцию руб./час	Затраты руб./год
1	Оформление заявки	Основная	260	72	18826,6
2	Выставление счета на оплату доставки	Основная	260	68	17752,8
3	Формировка заказа	Вспомогательная	530	68	36188,4
4	Техосмотр автомобиля	Основная	530	103	54828,5
5	Согласование даты и времени доставки	Вспомогательная	480	72	34560
6	Передача водителю документов	Вспомогательная	250	72	18750
7	Выезд автомобиля на склад	Основная	150	207	31050
8	Доставка заказа покупателю	Основная	895	207	185265
9	Возврат автомобиля	Вспомогательная	270	207	55890
	Итого:				453 111,3

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

— согласно проведенной классификации, процесс «оптовая торговля топливом» состоит из 6 основных и 4 вспомогательных функций;

— стоимость реализации данного процесса составляет 453 111,3 руб.

2.5 Анализ целесообразности затрат на функции

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

— 0,5 (относительно меньшая значимость);

— 1 (равнозначность функции);

— 1,5 (относительно большая значимость).

Таблица 4. Анализ целесообразности затрат на функции

Функции	1	2	3	4	5	6	7	8	9	P (0)	Pн (0)	Р (1)	Рн (1)
1	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
2	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
3	0,5	0,5	1	0,5	1	0,5	0,5	0,5	0,5	5,5	0,06	5,5	0,33
4	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
5	0,5	0,5	1	0,5	1	0,5	0,5	0,5	0,5	5,5	0,06	5,5	0,33
6	0,5	1	1,5	1	1,5	1	0,5	1	1	9	0,12	9	1,08
7	1	1	1,5	1	1,5	1,5	1	1	1	10	0,12	10	1,2
8	1	1	1,5	1	1,5	1	1	1	1	10	0,12	10	1,2
9	0,5	1	1,5	1	1,5	1	0,5	1	0,5	9,5	0,12	9,5	1,14
										79,5		79,5

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

Функции 3 и 5 равнозначны и имеют коэффициент 0,33, доказывает их наименьшую значимость в анализируемом бизнес-процессе: «продажа готового оборудования» в компании ООО «Промтехнологии».

2.6 Функционально-стоимостная диаграмма

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

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

Значимость ь

Зна

Функции

Рисунок 8. Диаграмма значимости функций

Рисунок 9. Диаграмма стоимости функций

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

2.7 Анализ качества выполняемых функций

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

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

Таблица 5. Анализ показателей качества выполняемых функций

Условное обозначение	Наименование коэффициента	Формула расчета	Расшифровка составляющих формулы
К1	Коэф. использования технических средств управления при выполнении функций	Тф/Tр	Тф — фактическое время использования технических средств Tр — расчетное техническое время использования технических средств
К2	Коэф. организации рабочих мест при исполнении функций	Кот/Ко	Кот — кол-во рабочих мест, отвечающих требованиям Ко — общее кол-во рабочих мест
К3	Коэф. нормирования труда исполнителей функций	Вн/Во	Вн — время затраченное на выполнение нормируемых работ Во — общее время
К4	Коэф. дублирования функций	Кд/Ко	Кд — кол-во дублируемых функций Ко — общее кол-во функций
К5	Коэф. использования рабочего времени	1- (∑tn/∑T)	∑tn — сумма потерь рабочего времени ∑T — ФРВ (год)

= = 0,98; = = 1;

= = 0,87; = = 0,11;

= 1 – ( ) = 0,85.

Согласно рассчитанным, коэффициентам, можно сделать выводы о том, что на предприятии ООО «Промтехнологии»:

— использование технических средств управления при выполнении функций, составляет 98%;

— в данной компании, все рабочие места, отвечают всем установленным требованиям;

— время, затраченное на выполнение нормируемых функций, составляет 87 % от общего количества времени, затрачиваемого на процесс;

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

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

3. Реинжиниринг бизнес-процесса в ООО «Промтехнологии»

3.1 Изменение существующего бизнес-процесса

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

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

Основной бизнес-процесс ООО «Промтехнологии» – «продажа готовой продукции» был оптимизирован, благодаря функционально – стоимостному анализу. На рисунке 10 изображен данный бизнес-процесс, после проведения реинжиниринга, описанный с помощью «Microsoft Visio».

Рисунок 10. Бизнес-процесс после проведения реинжиниринга

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

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

Для большей наглядности необходимо представить новый процесс в разрезе отделов компании ООО «Формула Доставки». На рисунке 11 представлена функциональная схема описываемого выше процесса.

ЗАКАЗЧИК	ОТДЕЛ ПРОДАЖ	БУХГАЛТЕРИЯ	ОТДЕЛ ЗАКУПОК	ТРАНСПОРТНЫЙ ОТДЕЛ
Поступил заказ
	Оформление заявки, составление договора, согласование даты и времени доставки
		Выставление счета на оплату
				Технический осмотр и загрузка автомобиля
	Передача водителю необходимых документов
				Начало движения по маршруту
				Доставка заказа покупателю
				Возврат автомобиля на территорию складского комплекса

Рисунок 11. Функциональная схема бизнес-процесса после реинжиниринга

3.2 Оценка экономической эффективности проведения реинжиниринга в компании ООО «Промтехнологии»

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

Анализ обновлённого процесса компании ООО «Промтехнологии» представлен в таблице 7.

Таблица 7. Анализ структурно-элементной модели после реинжиниринга основного бизнес-процесса

№	Наименование функции	Вид функции	Затраты час/год	Затраты на операцию руб./час	Затраты руб./год
1	Оформление заказа (согласование даты и времени)	Основная	260	72	18826,6
2	Выставление счета на оплату доставки	Основная	260	68	17752,8
3	Формировка заказа	Вспомогательная	530	68	36188,4
4	Передача водителю документов	Вспомогательная	250	72	18750,0
5	Доставка заказа покупателю	Основная	895	207	185265,0
6	Возврат автомобиля	Вспомогательная	270	207	55890,0
	Итого:				Σ 332 602,8

Итогом реинжиниринга процесса «продажа готовой продукции» в компании ООО «Промтехнологии» является:

— сокращение времени, необходимого для доставки сформированного заказа;

— сокращение части транспортных затрат, за счёт уменьшения порожнего пробега грузового автомобиля;

— уменьшение степени износа транспортных средства

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

— сокращение стоимости данного процесса на 120 508,5 рублей (с 453 111,3 рублей до 332 602,8 рублей). Этот эффект благотворительно отразиться на ООО «Промтехнологии».

Заключение

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

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

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

Итогом реинжиниринга процесса «продажа готовой продукции» в компании ООО «Промтехнологии» является:

— сокращение времени, необходимого для доставки сформированного заказа;

— сокращение части транспортных затрат, за счёт уменьшения порожнего пробега грузового автомобиля;

— уменьшение степени износа транспортных средства;

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

— сокращение стоимости данного процесса на 120 508,5 рублей (с 453 111,3 рублей до 332 602,8 рублей). Этот эффект благотворительно отразиться на ООО «Промтехнологии».

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

1. Абдикеев, Н.М.; Данько, Т.П. и др. Реинжиниринг бизнес-процессов; Эксмо; Издание 2-е, испр. — Москва, 2015. — 590 c.

2. Аллин Олег , Зайцев Вениамин Бизнес по правилам и против них. 225 бизнес-идей, 455 практических примеров; Феникс — Москва, 2015. — 416 c.

3. Блинов А. О., Рудакова О. С., Захаров В. Я., Захаров И. В. Реинжиниринг бизнес-процессов; Юнити-Дана — Москва, 2016. — 344 c.

4. Брэнсон Ричард Бизнес в стиле Virgin. Чему вас не научат в бизнес-школе; Манн, Иванов и Фербер — Москва, 2016. — 336 c.

5. Горемыкин В. А. Бизнес-план. Методика разработки. 25 реальных образцов бизнес-плана; Ось-89 — Москва, 2016. — 592 c.

6. Горемыкин В. А. Бизнес-план. Методика разработки. 45 реальных образцов бизнес-планов; Ось-89 — Москва, 2015. — 864 c.

7. Деарлав, Дез Бизнес-путь: Билл Гейтс. 10 секретов самого богатого в мире бизнес-лидера; СПб: Крылов — Москва, 2015. — 208 c.

8. Каргина Е. Н. Учет бизнес-процессов в системе «1С:Бухгалтерия 8.1»; Феникс — Москва, 2016. — 192 c.

9. Крылов Тимофей ИКЕА изнутри. Пример эффективной организации бизнес-процессов (CD + брошюра); Тимофей Крылов — Москва, 2017. — 314 c.

10. Любанова, Т.П.; Мясоедова, Л.В.; Грамотенко, Т.А. и др. Бизнес-план: опыт, проблемы. Содержание бизнес-плана, пример разработки; М.: Приор — Москва, 2016 — 370 c.

11. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler; Диалог-МИФИ — , 2015. — 240 c.

12. Медынский В. Г., Ильдеменов С. В. Реинжиниринг инновационного предпринимательства; Юнити — Москва, 2016. — 416 c.

13. Меркулов Андрей , Мрочковский Николай Бизнес на автопилоте. Как собственнику отойти от дел и не потерять свой бизнес; Альпина Паблишер — Москва, 2015. — 252 c.

14. Мрочковский Николай , Парабеллум Андрей Бизнес. Перезагрузка. Как вывести из крутого пике бизнес, который казалось бы спасти уже невозможно; Манн, Иванов и Фербер — Москва, 2015. — 535 c.

15. Мрочковский Николай , Парабеллум Андрей Бизнес. Перезагрузка. Как вывести из крутого пике бизнес, который казалось бы спасти уже невозможно; Манн, Иванов и Фербер, Эксмо — Москва, 2016. — 248 c.

16. Оголева Л. Н., Чернецова Е. В., Радиковский В. М. Реинжиниринг производства; КноРус — Москва, 2017. — 304 c.

17. Пелих А. С. Бизнес-план, или Как организовать собственный бизнес; Ось-89 — Москва, 2018. — 112 c.

18. Пелих, А.С. Бизнес-план, или Как организовать собственный бизнес. Анализ. Методика. Практикум; М.: Ось-89 — Москва, 2016. — 962 c.

19. Петухова С. В. Бизнес-планирование. Как обосновать и реализовать бизнес-проект; Омега-Л — Москва, 2016. — 176 c.

20. Репин Владимир , Елиферов Виталий Процессный подход к управлению. Моделирование бизнес-процессов; Манн, Иванов и Фербер — Москва, 2015. — 373 c.

21. Репин, В.В.; Елиферов, В.Г. Процессный подход к управлению. Моделирование бизнес-процессов; М.: Стандарты и качество; Издание 3-е, испр. — Москва, 2015. — 408 c.

22. Рис Эрик Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели; Альпина Паблишер — Москва, 2016 — 256 c.

23. Роберт С. Кэмп Легальный промышленный шпионаж. Бенчмаркинг бизнес-процессов: технологии поиска и внедрение лучших методов работы ваших конкурентов; Баланс-Клуб — Москва, 2016. — 416 c.

24. Теличенко В. И., Лапидус А. А., Морозенко А. А. Информационное моделирование технологий и бизнес-процессов в строительстве; Издательство Ассоциации строительных вузов — Москва, 2015. — 144 c.

25. Уткин, Э.А. Бизнес — реинжиниринг; М.: Экмос — Москва, 2016. — 224 c.