ЧАСТЬ 1. МОДЕЛЬ BPWIN
Итак, на контекстной диаграмме С-0 отразим основные входные потоки, выходные данные, ресурсы и управление. Думаю, что особых пояснений здесь не требуется. Управляющими воздействиями здесь будут Законодательство и Инструкции. Ресурсами являются сотрудники центра и материальные ресурсы. Но дальше мы не будем их особенно раскрывать: уж очень муторно, а смысловая нагрузка низкая.
Далее, определим основные процессы страхования. Это будут:
- консультации;
- заключение договора;
- страховые выплаты.
Отразим эти блоки на диаграмме первого уровня С0 (рис.2). Входными данными модели будут:
- вопросы клиентов;
- документы клиентов;
- заявления на выплаты и другие документы.
Кроме этого, страховщик обязан регулярно вносить обусловленную договором страхования плату (страховую премию).
Выходными данными модели будут:
- отказ в страховании;
- страховой полис и договор;
- страховое возмещение.
Теперь создадим диаграмму «Консультации» (рис.3). Здесь все просто: сотрудник, являющийся консультантом, используя законодательные документы и внутренние инструкции, находит ответ на вопрос и сообщает его клиенту по телефону.
«Заключение договора» (рис.4) состоит из двух частей: Предварительная беседа и Оформление договора.
В ходе предварительной беседы (рис.5) инспектор рассматривает документы клиента, выслушивает его пожелания, дает разъяснения. Результатом является «решение клиента», которое может быть положительным или отрицательным. Поэтому эту стрелку мы сделаем разветвляющейся. Положительное решение будет служить управляющим сигналом для подготовки документов, а отрицательное, - пойдет в качестве выходного.
В ходе «оформления договора» (рис.6) проводится: проверка транспорта, заполнение страхового полиса, прием оплаты, подпись и выдача страхового полиса, помещение копии страхового полиса в архив. При проверке транспорта, если обнаружены повреждения, несоответствие документам, может быть принято решение об отказе в страховании. Дальше шаги вроде бы ясны и комментариев не требуют.
«Страховые выплаты» (рис.7) проводятся в случае наступления страхового события. Инспектор рассматривает заявление клиента, страховой полис и документы, подтверждающие факт страхового события. Проводится осмотр автотранспорта. На основании этого принимается решение о выплате или отказе.
Несомненным удобством при работе с BPWin является то, что по каждому блоку и стрелке можно записать комментарий. Есть также функция проверки грамматики, но только английской. Русского языка (как обычно) в перечне нет. А как присоединить русский словарь, непонятно, хотя опция присоединения словаря есть. Но откуда его брать? Самому писать что ли?
Удобно также менять названия стрелок. Можно сразу изменить название определенной стрелки во всех диаграммах. Удобно двигаются надписи по отношению к стрелкам.
Стрелки можно объединять и создавать иерархию данных. Например: город, дом, улица, - объединить в Адрес. Тогда, на верхний уровень будет выходить только адрес. Для этого надо сделать ответвление со стрелки и назвать его по-другому.
Большим преимуществом BPWin по сравнению с другими изобразительными средствами является то, что при построении иерархических диаграмм потоки родительской диаграммы, входящие в дочернюю, автоматически переносятся туда. И, наоборот, выходящие из дочерней, сразу отображаются в родительской. Если в родительской диаграмме мы удаляем стрелку, то в дочерней ее вход заключается в скобки. Это очень удобно, так как позволяет отслеживать потоки между уровнями. Попробуйте нарисуйте такие схемы в Wordе, замучаетесь.
Главной ценностью, на мой взгляд, в методологии IDEF0 и DFD является иерархический подход, позволяющий описывать процессы любой сложности. В результате весь процесс отображается набором диаграмм различной степени обобщения, что мы и сделали. Верхние можно показывать начальству, нижние – исполнителям, программистам. Хотя, конечно, мы любим потрясать воображение начальства схемами на полстены. Но теория (SADT) утверждает, что обычный человек не может воспринять смысл схемы более чем из 5-6 блоков. Во как!
С помощью BPWin мы можем изобразить дерево функций. Это делается автоматически и не требует усилий. Оно отображено на рисунке 8.
Дополнительно можно построить диаграммы потоков данных (DFD-диаграммы). Они отображены ниже. На мой взгляд, именно DFD-диаграммы играют основную роль для описания системы на верхнем уровне. Их очень удобно демонстрировать руководству. Хотя теория утверждает, что основой являются IDEF0-диаграммы, поскольку они отражают еще управление и ресурсы. Но вот этого, как раз, на верхнем уровне понимания и не требуется.
Диаграммы потоков данных можно рисовать с различных точек зрения. Например, с точки зрения функций, или с точки зрения объектов. Построим сначала «объектную» диаграмму потоков данных. Основным объектом у нас будет Центр страхования (рис.9).
Войдем в него. В его состав включим: договорный отдел, отдел страховых выплат, ну и еще начальника (рис.10). Видите, как это полезно: мы уже начали думать над структурой центра. В реальном процессе, конечно, существует гораздо больше организационных единиц, но так как наша модель учебная, мы ее упростим. Теперь вернемся на верхний уровень и подумаем о том, с какими внешними объектами мы будем взаимодействовать. Во-первых, - это страхователь, который будет заключать договор. Во-вторых, - это опять страхователь J, который будет получать страховое возмещение. А больше никого. Ну очень простая модель! Не будем мы рассматривать взаимодействие с банками, органами внутренних дел, судебные споры, материально - техническое обеспечение, рекламу и т.д. Потому, что цель у нас другая: показать BPWin во всей его красе!
Итак, посмотрим, что у нас будет делать страхователь. Для этого обратимся к модели IDEF0. Он будет:
- задавать вопросы;
- подавать документы;
- подавать заявление о выплате страхового возмещения.
Что будет на выходе? То есть, что он может получить:
- ответ на вопрос;
- страховой полис;
- страховое возмещение;
- отказ в страховании;
- отказ в выплате страхового возмещения (вот так-то).
Кроме того, он сам может отказаться от… (вы подумали – от страхового возмещения J), нет, - от заключения договора.
Вопросы клиентов могут поступать как в договорный отдел, так и в отдел страховых выплат. Также и документы клиента.
При заключении договора сотрудник договорного отдела оформляет полис. Клиент вносит деньги и получает полис. Теперь, если посмотреть первую модель, мы увидим, что забыли такой объект, как касса. На этом этапе, после рассмотрения документов, возможен и отказ в страховании.
Теперь, создадим хранилище данных: архив, куда будут помещаться копии документов.
Заявление на выплату рассматривается в отделе страховых выплат. Туда же подаются акты, протоколы и другие документы, подтверждающие факт наступления страхового случая. Заявление утверждает начальник центра. После рассмотрения документов возможен отказ в страховом возмещении.
Можно, конечно, дальше развертывать организационную структуру, но мы ограничимся первым уровнем.
При желании можно построить организационные диаграммы, но большой необходимости в этом для такой простой модели нет. Пример организационной диаграммы можно посмотреть в статье: «Модернизация системы пропускного режима предприятия».
Можно выдавать отчеты по проекту. В версии 4.1 есть мастер отчетов, который позволяет сформировать по своему желанию отчет в формате HTML или Word. Можно использовать готовые шаблоны. Пример отчета HTML Вы можете посмотреть здесь. Пример отчета Word можно загрузить здесь.
Ну, посмотрели? Что можно сказать.
Во-первых, везде присутствует англоязычное обрамление. И заменить английские слова на русские в шаблоне (то есть создать русскоязычный шаблон) невозможно (во всяком случае, мне найти не удалось). Можно только править текст HTML- или Word-документа. Но ведь не будешь же это делать каждый раз! Может быть в лицензионной или какой-нибудь расширенной версии это возможно?? HTML-отчет создается несколько по-уродски и мне пришлось потрудиться, чтобы поместить его в Интернет. Конечно, отчет можно было сделать более полноценным, записав комментарии к объектам. Но мне это лень было делать. Кстати, и всем остальным тоже, - редкий автор добирается в своей модели до полноценных комментариев. Ну, а если доберется, то тут же и упадет замертво.
Кроме этого можно выдавать стандартные текстовые отчеты. Но это вообще убожество. Пример отчета по диаграмме:
Report for Diagram: С0, Страхование автогражданской ответственности
Activity Name: Консультации
Activity Number: С1
Activity Name: Заключение договора
Activity Number: С2
Activity Name: Страховые выплаты
Activity Number: С3
В версии 4.0 имеется такой недостаток, как искажение русских шрифтов при генерации отчета в Word. Я объясняю это тем, что там все еще используются старые 16-битные шрифты. Не следят за прогрессом, понимаешь! В MS Word 2000/ХР это исправляется очень просто: из меню "Сервис" выбираем пункт "Восстановить поврежденный текст", ставим "Язык" - русский и галочку "Ко всему документу". Вуаля!
Имеется возможность создавать Определенные Пользователем Свойства (User Defined Property, UDP). Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report. Через UDP могут быть запущены другие документы и приложения.
Конечно, не надо забывать, что BPWin предназначен, кроме рисования, и для других функций, например, для расчета стоимости и продолжительности работ.
Для это потребуется создать Центры затрат (Cost centers), которые можно трактовать как статьи расхода. При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег, затем описываются центры затрат и, наконец для каждой работы на диаграмме декомпозиции назначаются продолжительность (duration), частота проведения данной работы в рамках общего процесса (frequency) и суммы по каждому центру затрат, то есть задается стоимость каждой работы по каждой статье расхода. Этот очень упрощенный принцип подсчета справедлив, если работы выполняются последовательно.
Возьмем, например, диаграмму С22: «Оформление договора» и проведем расчет стоимости. Основные исходные данные возьмем из модели: «Из опыта использования средства Arena для моделирования работы центра страхования автогражданской ответственности». Будем считать, что в этом процессе участвуют: руководитель, который утверждает документы; четыре инспектора, которые заключают договоры страхования; один кассир, который принимает деньги. Ежедневно поступает 40 заявлений на страхование. Будем считать, что зарплата инспектора – 300 р/день, руководителя 500 р/день, а кассира – 200 р/день. Создадим следующие центры затрат:
- зарплата;
- оборудование;
- расходные материалы.
В блок «Проверка транспорта» запишем всю дневную зарплату инспекторов (чтобы не делить ее на несколько частей) – 300рх4=1200р. Продолжительность проверки примем равной 0,2 час.
В блоке «Заполнение страхового полиса» определим, что на все полисы в день потребуется: 200р на расходные материалы и 50р на амортизацию оборудования. Продолжительность операции примем равной 0,3 час.
В блоке «Прием оплаты» запишем всю дневную зарплату кассира – 200р. Продолжительность операции примем равной 0,1 час. Затраты на расходные материалы – 50р, на оборудование – 50р.
В блоке «Подпись и выдача страхового полиса» запишем всю дневную зарплату руководителя – 500р, на расходные материалы – 50р, на оборудование – 0р. Продолжительность примем равной 0,1 час.
В блоке «Помещение копии страхового полиса в архив» запишем на расходные материалы – 30р, на оборудование – 20р. Продолжительность примем равной 0,1 час.
В результате на диаграмме будут отражены результаты расчета стоимости. А на диаграмме верхнего уровня будет выведена стоимость 2350р.
Если в свойствах модели мы укажем «отображать продолжительность» процессов, то получим, что общая продолжительность оформления договора составит 0,8 часа.
В общем, какой-то никому не нужный примитив получается. Может, только для очень большого проекта он имеет смысл? Но это мое скромное мнение. Если кто имеет опыт расчета стоимостных показателей в BPWin, прошу отозваться и рассказать.
Какие недостатки можно отметить в BPWin, касающиеся интерфейса и удобства работы:
- Нельзя менять мышью размеры текстового поля. Приходится при наборе текста делать перевод строки так, чтобы размеры были такие, какие требуется на диаграмме.
- Отсутствует возможность самому редактировать текст Header/footer. Английские слова в заголовках формы заменить на русские невозможно.
- Несколько дубоватый, не совсем Windows-ный интерфейс: при сохранении, при закрытии проекта. Одно «Close without saving» чего стоит.
- Устаревшие кириллические шрифты, которые, если диаграммы копировать, не видны в MS Office 2000, XP.
- Невозможность выделения и копирования одного или группы объектов, - только диаграмма полностью.
Неудобством является и то, что по каждому объекту (блоку, стрелке) свойства (цвет, толщину линий) надо устанавливать отдельно. Обобщение или, например, выделение группы объектов отсутствует.
А если мы ошиблись и хотим перенести блок (например, «Прием оплаты») на другую диаграмму? Путем копирования или перемещения это сделать невозможно. Придется удалить его на одной и заново нарисовать на другой. И, кроме того, придется удалять и заново рисовать все стрелки. А если их много! То этот процесс становится очень неприятным. Правда, он облегчается тем, что можно удалить блок и стрелки из диаграммы не удаляя их из модели. Тогда, при создании блока на другой диаграмме, все удаленные блоки и стрелки можно выбрать из списка неиспользуемых.
Ну, а если мы хотим вставить дополнительный уровень, то есть создать диаграмму между двумя существующими, то это превращается в настоящее мучение. Я всегда холодным потом покрываюсь, когда надо такое сделать J. Иногда даже легче удалить весь нижний уровень и начать все сначала. В качестве примера привожу «простенький» алгоритм вставки нового уровня.
Пример: Дана модель с диаграммами A1, A2 и A3 (все они уже подвергнуты декомпозиции). Мы хотим, чтобы текущая диаграмма A2 стала диаграммой A21, и заменить текущую диаграмму А2 новой диаграммой.
В диаграмме A0, нажать правую кнопку мыши над A2 и выбрать пункт Разбиение Модели (Split Model). Ввести имя модели (например, "park"). Вновь созданная модель будет иметь диаграмму A2 , как контекстную операцию, а предыдущая операция A2 будет иметь стрелку вызова с названием "park". Предыдущая операция A2 теперь является висячей (или конечной) операцией и может быть подвергнута декомпозиции, для создания новой диаграммы A2 в оригинальной модели. Вы должны переименовать или контекстную операцию новой модели (park) или предыдущую операцию A2. Затем надо удалить стрелку вызова "park" из предыдущей операции и поместить новую стрелку вызова "park" в операцию в новой декомпозиции, где должна быть расположена предыдущая диаграмма A2 (в данном случае A21). Контекстной операции новой модели "park" следует дать такое же название, как и операции А21 (Activity A21) в новой декомпозиции. Воспользуйтесь меню правой кнопки мыши над операцией A21 или над стрелкой вызова "park", выберите пункт Слияние Модели (Merge Model) и вновь объедините модель "park" с оригинальной моделью. Необходимо отметить, что новая диаграмма будет иметь обрамляющие стрелки (border arrows), которые соответствуют традиционным туннельным (square tunneled) стрелкам, соединяющим помещенную нами операцию А21 (Activity A21). Эти стрелки можно соединять так, как вы сочтете нужным.
Ну вот! Вроде с BPWin в основном разобрались.
