Интерфейс BPwin простой и интуитивно понятный. Ниже представлено описание интерфейса версии BPwin 4.0.
При запуске BPwin по умолчанию появляется: (1) стандартная панель инструментов, (2) палитра инструментов и, в левой части, (3) навигатор модели - Model Explorer.
Model Explorer
Инструмент Model Explorer имееттривкладки - Activities, Diagrams, Objects.
Вкладка Activities показывает в виде раскрывающегося иерархического списка все блоки модели. Одновременно могут быть показаны все модели, открытые в BPwin. Блоки диаграмм IDEF0 показываются зеленым цветом, IDEF3 - желтым, DFD - голубым.
Для редактирования свойств блока следует щелкнуть по нему правой кнопкой мыши (МП). Появляется контекстное меню. В таблице 1 приведены значения пунктов меню.
Если с помощью вкладки Activities можно перейти на стандартные диаграммы (контекстную и декомпозиции), то вторая вкладка - Diagrams - служит для перехода на любую диаграмму модели.
При переходе на вкладку Objects на ней показываются все объекты, соответствующие выбранной на вкладке Diagrams диаграмме, в том числе хранилища данных, внешние ссылки, перекрестки.
| Таблица 1 Контекстное меню редактирования свойств блока | |
| Пункт меню | Описание |
| Insert Before | Создать новый блок перед текущим |
| Insert After | Создать новый блок после текущего |
| Decompоse | Декомпозировать блок. В результате будет создана диаграмма декомпозиции |
| Name | Вызов редактора имени |
| Definition/Note | Вызов редактора определения и примечания |
| Font | Изменение шрифта |
| Color | Изменение цвета |
| Costs | Задание стоимости |
| Data Usage | Ассоциация блока с данными |
| UDP | Задание свойств, определяемых пользователем |
| UOW | Задание свойств для блока IDEF3 |
Стандартная панель инструментов
Стандартная панель инструментов обеспечивает быстрый доступ к часто выполняемым задачам. Вы можете показывать или скрывать панель, используя команду меню View | Standard Toolbar. В таблице 2 показаны элементы стандартной панели.
Палитра инструментов
Палитра инструментов содержит инструменты для работы с объектами в диаграмме BPwin. Вы можете показывать или скрывать ее, используя команду меню View | BPwin Toolbox. Вид палитры зависит от выбранной нотации (IDEF0, IDEF3, DFD). В таблице 3 показаны основные элементы палитры инструментов.
| Таблица 2 Описание элементов управления стандартной панели инструментов BPwin 4.0 | ||
| Элемент управления | Описание | |
|
| Создать новую модель | |
|
| Открыть модель | |
|
| Сохранить модель | |
|
| Печать модели | |
|
| Вызвать генератор отчетов | |
|
| Выбор масштаба | |
|
| Масштабирование | |
|
| Проверка правописания | |
|
| Включение и выключение навигатора модели Model Explorer | |
|
| Включение и выключение дополнительной панели инструментов работы с ModelMart | |
| Таблица 3 Описание элементов управления палитры инструментов BPwin 4.0 | ||
| Элемент управления | Описание | |
|
| Указатель (Pointer) - редактирование, перемещение объектов | |
|
| Блок (Activity Box) - создание блока на диаграмме IDEF0 | |
|
| Стрелка (Precedence Arrow) - создание стрелки | |
|
| Тильда (Squiggle) - создание тильды | |
|
| Текст (Text) - создание текстовых комментариев | |
|
| Родительская диаграмма (Go to Parent Diagram) - открытие родительской диаграммы | |
|
| Дочерняя диаграмма (Go to Child Diagram) - создание диаграммы декомпозиции | |
|
| Единица работы (UOW) - создание единицы работы на диаграмме IDEF3 | |
|
| Перекресток (Junction) - создание перекрестка на диаграмме IDEF3 | |
|
| Ссылка (Referent) - создание ссылки на диаграмме IDEF3 | |
|
| Процесс (Activity Box) - создание процесса на диаграмме DFD | |
|
| Внешняя сущность (External Reference) - создание внешней сущности на диаграмме DFD | |
|
| Хранилище данных (Data Store) - создание хранилища данных на диаграмме DFD | |
Построение моделей IDEF0
Рекомендуется следующая последовательность при построении функциональной модели [6]:
(1) формирование цели моделирования;
(2) выбор точки зрения;
(3) определение области моделирования;
(4) создание блока контекстной диаграммы;
(5) создание стрелок на контекстной диаграмме;
(6) создание диаграмм декомпозиции;
(7) создание диаграмм узлов и иллюстраций.
Цель моделирования. Модель не должна создаваться без ясного осознания цели моделирования. При выборе цели следует ответить на такие вопросы: почему моделируется данный процесс? что выявит данная модель? как ее смогут применять? Вот пример цели моделирования: выявить задачи каждого сотрудника компании для разработки руководства по обучению новых сотрудников.
Точка зрения. С методической точки зрения при моделировании полезно использовать мнение специалистов, имеющих разные взгляды на предметную область. Но модель должна разрабатываться исходя из единой точки зрения. Другие точки зрения отражаются в виде диаграмм иллюстраций.
Основой для выбора точки зрения должна служит поставленная цель моделирования. Наименованием точки зрения может являться название должности или подразделения (например, менеджер по продажам). Как и в случае с определением цели моделирования, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры.
Область моделирования. При определении области моделирования необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной.
После определения области предполагается, что новые объекты не должны вносится в систему, так как все объекты модели взаимосвязаны и внесение нового объекта может изменить существующие взаимосвязи.
Стрелки проще проектировать в таком порядке: (1) выход, (2) вход, (3) механизм, (4) управление.
Определение выходов. Каждый блок обозначает отдельную функцию, и она часто имеет четко описываемые результаты работы. Наличие неясностей при анализе выходов блока - возможный сигнал необходимости проведения реинжиниринга рассматриваемого бизнес-процесса.
После идентификации возможных выходов полезно провести анализ модели на предмет предвидения всех возможных сценариев поведения процесса. Это означает, что если существует вероятность возникновения той или иной ситуации в ходе процесса, модель должна ее отражать. Важно не забыть отразить негативные результаты работы блоков. Негативные результаты часто используются в качестве обратных связей; их анализ должен проводиться для каждого блока.
Определение входов. Входы можно рассматривать как особым образом преобразуемые блоками сырье или информацию для получения выходов.
Определение механизмов. После создания входов и выходов можно приступать к рассмотрению механизмов исполнения или ресурсов, относящихся к блоку.
Определение управления. Наконец, должно быть определено управление, контролирующее ход работы блока. Все блоки должны иметь хотя бы одну стрелку управления.
После завершения работы над контекстной диаграммой следует задать следующие вопросы. Обобщает ли диаграмма моделируемый бизнес-процесс? Согласуется ли диаграмма с областью, точкой зрения и целью моделирования? Подходит ли выбранный уровень детализации стрелок для контекстного блока?
Диаграммы декомпозиции. Блок декомпозируется, если необходимо детально описать его работу. При декомпозиции блока полезно рассмотреть его жизненный цикл - это поможет определить блоки дочерней диаграммы. Например, жизненный цикл блока «Поджарить картофель» может быть таким: подготовить продукты, почистить картофель, подогреть масло и т.д.
Важно помнить, что граница дочерней диаграммы есть граница родительского блока. Это означает, что вся работа выполняется блоками самого нижнего уровня. В отличии от иерархии, применяемой в структурном программировании, блоки верхнего уровня не являются субъектами управления для блоков нижнего уровня. Это значит, что дочерние объекты - это те же объекты, что и их родители, только показанные с большей детализацией. Действия генерального директора компании могут отражаться на IDEF-диаграммах рядом с действиями простых рабочих.
Модели могут проектироваться как с использованием подхода в ширину, когда каждая диаграмма максимально детализируется перед своей декомпозицией, так и с подходом в глубину, когда сначала определяется иерархия блоков, а потом создаются соединяющие их стрелки.
Когда остановиться? Сформулированная цель моделирования содержит вопросы, на которые должна отвечать модель. Когда становится возможным получение ответов на них с помощью модели, последняя считается удовлетворяющей поставленным требованиям и рассматривается как завершенная. При построении декомпозиции нужно следить, чтобы все блоки на диаграмме лежали внутри определенных ранее границ моделирования. Еще одно правило состоит в том, что моделирование следует продолжаться до тех пор, пока стрелки входа и выхода преобладают на диаграммах.
9.3. Модели «как есть» и «как будет»
Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности компании, анализе преимуществ новых бизнес-процессов и степени изменения существующей структуры организации бизнеса [5].
Анализ начинают с построения модели как есть (AS-IS), то есть модели существующей организации работы. Модель «как есть» может создаваться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов), анкетирования и опроса служащих предприятия и других источников.
С помощью синтаксического анализа модели можно легко обнаружить «бесполезные» (не имеющие выхода), «неуправляемые» (не имеющие управления) и «простаивающие» функции. Более тонкий анализ позволяет выявить дублирующие, избыточные или неэффективные функции. Модель дает целостное представление о работе системы в целом и возможность понять взаимосвязи всех составляющих системы. При этом выясняется, что обработка информации и использование ресурсов неэффективны, важная информация не доходит до соответствующего рабочего места. Признаком неэффективности организации работ является, например, отсутствие обратных связей по входу и управлению для важных функций.
Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели как будет (TO-BE).
Только на основе модели «как будет» проектируется модель данных и затем информационная система. Построение модели на основе модели «как есть» приводит к тому, что информационная система автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот.
