40. Синтаксис idef0 моделей.

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

– контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

– диаграммы декомпозиции;

– диаграммы дерева узлов;

– диаграммы только для экспозиции (FEO).

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

достижения нужного уровня подробности описания. Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграммы только для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения либо для специальных целей и могут не подчиняться правилам синтаксиса IFEF0. IDEF0-модели развиваются в процессе структурной декомпозиции сверху вниз. Название диаграммы совпадает с названием декомпозируемого блока. Результатом этого процесса является модель, диаграмма верхнего уровня которой описывает систему в общих терминах «черного ящика», а диаграммы нижнего уровня описывают детализированные аспекты и операции системы. Каждая диаграмма модели идентифицируется посредством номера узла. Номер узла (Node) для контекстной диаграммы имеет следующий вид: любая заглавная буква (чаще всего буква A), дефис и ноль. Номером узла диаграммы, декомпозирующей контекстную диаграмму, является тот же номер узла, но без дефиса, например, А0 . Номера всех остальных диаграмм образуются посредством добавления к номеру узла родительской диаграммы номера декомпозируемого блока, например, А1, А2, А12 и т. д. При построении диаграммы следующего уровня стрелки, касающиеся декомпозируемого блока, используются в качестве источников и приемников для стрелок, которые создаются на новой диаграмме. После завершения диаграммы ее внешние стрелки стыкуются с родительской диаграммой для обеспечения согласованности.

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

Стрелка «входит в тоннель», если она:

– является внешней стрелкой, которая отсутствует на родительской диаграмме (имеет скрытый источник);

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

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

41. Программный пакет BPWin. Характеристика поддерживаемых нотаций в пакете BPWin. Возможности BPwin:

• поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область наиболее комплексно;

• позволяет оптимизировать процедуры в компании;

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

• интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.;

• интегрирован со средством имитационного моделирования Arena;

• содержит собственный генератор отчетов;

• позволяет эффективно манипулировать моделями - сливать и расщеплять их;

• имеет широкий набор средств документирования моделей, проектов.

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

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

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

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

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

Помимо стоимости могут быть другие свойства, которые необходимо учесть при оценке общей эффективности системы. Для этого имеется возможность внесения свойств, определенных пользователем (User Defined Properties, UDP).