1.2. Разработка функциональной модели системы средствами bPwin
BPwin – CASE-средство верхнего уровня, помогающее проводить анализ и реорганизацию бизнес-процессов. Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему надо стремиться (модель TO-BE).
Процесс построения информационной модели в BPwin состоит из следующих шагов:
построить контекстную диаграмму;
провести функциональную декомпозицию;
после каждого сеанса декомпозиции провести сеанс экспертизы.
CASE-cредство BPWin предназначено для проведения анализа и реорганизации бизнес-процессов. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. Такая технология построения модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. На основе модели BPwin строится модель данных, в программе поддерживается связь с ERwin.
Функциональность BPwin заключается не только в рисования диаграмм, но и в проверке целостности и согласованности модели. BPwin обеспечивает логическую четкость в определении и описании элементов диаграмм, а также проверку целостности связей между диаграммами. Инструмент обеспечивает коррекцию наиболее часто встречающихся ошибок при моделировании, таких, как "зависание" связей при переходе от диаграммы к диаграмме, нарушение ассоциации связей в различных диаграммах модели и т.п. Кроме того, BPwin поддерживает пользовательские свойства, которые применяются к элементам диаграммы для описания специфических свойств, присущих данному элементу.
BPwin имеет широкие возможности по представлению диаграмм. Графическое представление модели может быть изображено при помощи различных цветов, шрифтов и прочих параметров представления, которые выделяют важные или, наоборот, тушируют незначительные аспекты модели. Эта, незначительная на первый взгляд, возможность является ключевой во время представления и обсуждения модели с заказчиком или экспертами предметной области, т.к. правильно подобранное графическое представление позволяет им быстрее сориентироваться в модели.
BPwin поддерживает три методологии моделирования:
функциональное моделирование (IDEFO);
описание бизнес-процессов (IDEF3);
диаграммы потоков данных (DFD).
Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
Почему этот процесс должен быть смоделирован?
Что должна показывать модель?
Что может получить заказчик?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: "Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций информационной системы" и т. д.
На начальных этапах создания ИС необходимо понять, как работает организация. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но плохо знает, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области, следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации. Наиболее удобным языком моделирования бизнес-процессов является IDEF0.
В методологии IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной т.е. функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Под моделью в методологии IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Описание системы с помощью методологии IDEF0 называется функциональной моделью. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие. Модель может содержать четыре типа диаграмм:
контекстную диаграмму А0 (в каждой модели может быть только одна контекстная диаграмма);
диаграммы декомпозиции;
диаграммы дерева-узлов;
диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой.
Рассмотрим, на примере процесса записи пациента к врачу построение контекстной диаграммы, что позволит нам рассмотреть взаимосвязь системы с окружающей средой.
Рис. 1. Контекстная диаграмма «Регистратура РДЦ»
Как видно на контекстной диаграмме на вход подаются исходные данные о пациенте, они регламентируются пожеланиями пациента и загруженностью врачей, исполнителем является работник регистратуры, а оборудованием – рабочая платформа. В этом процессе происходит обработка входных данных, после чего обработанные данные передаются на выход в виде талона на прием и/или графика приёма врачей.
После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции.
Диаграмма верхнего уровня создается путем декомпозиции основной функции контекстной диаграммы. На диаграмме декомпозиции функции нумеруются автоматически слева направо. Номер функции показывается в правом нижнем углу. В левом верхнем исчезает небольшая диагональная черта, которая показывает, что данная функция была декомпозирована.
В ходе работы была создана диаграмма верхнего уровня, путем проведения декомпозиции контекстной диаграммы, результат которой представлен на рисунке 2.
Рис. 2. Диаграмма декомпозиции «Регистратура РДЦ»
В ходе декомпозиции процесса записи пациента к врачу в регистратуре РДЦ процесс был разбит на 3 процесса:
обработка данных;
выбор врача;
запись на прием.
В первом процессе на вход поступают данные о пациенте, а после обработки этих данных на выход поступают уже обработанные данные. Данный процесс регламентируется пожеланиями пациента и загруженностью врачей, а для выполнения данного процесса необходима рабочая платформа и регистратор, который будет следить за тем, чтобы система работала правильно. Далее обработанные данные поступают на вход второго процесса «Выбор врача». Данный процесс также регламентируется пожеланиями пациента и загруженностью врачей и для выполнения процесса, также необходима рабочая платформа и регистратор. Последний процесс «Запись на приём» на входе принимает обработанные данные, полученные во втором процессе, а на выходе выдает талон на приём и/или график приёма врачей. Для выполнения данного процесса необходима рабочая платформа и регистратор, а регламентируется процесс пожеланиями пациента и загруженностью врачей.
Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:
функции обработки информации (работы);
документы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;
внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
таблицы для хранения документов (хранилище данных,
data store).
Рассмотрим на примере процесса «Составление расписания» диаграмму потоков данных:
Рис. 3. Диаграмма потоков данных процесса «Составление расписания»
Внешние сущности изображают входы в систему и/или выходы из системы. Как видно на рисунке 3, внешней сущностью является Регистратура. Из нее поступают обработанные данные на вход процесса «Составление графика приемов». Данный процесс регламентируется различной документацией, гостами, а также «Нагруженностью врача». «Нагруженность врача» - это хранилище данных. В системах обработки информации хранилища данных являются механизмом, который позволяет сохранить данные для последующих процессов. Результатом процесса является черновой вариант расписания, который поступает на вход процесса «Корректировка чернового варианта расписания». Этот процесс регламентируется документацией и стандартами, а для его выполнения необходимы рабочая платформа и персонал. В результате выполнения данного процесса получаем готовое расписание приемов, которое отправляется во внешнюю сущность «Регистратура», а далее в хранилище «База данных».
Также была построена диаграмма потоков данных для процесса «Запись на прием»:
Рис. 4. Диаграмма потоков данных процесса «Запись на прием»
Процесс «Запись на прием к врачу-специалисту» был разбит на 5 подпроцессов:
заполнение 1-й страницы медицинской карты;
запись к участковому врачу;
прием участковым врачом;
заполнение медицинской карты;
запись к специалисту.
На прием к специалистам узкого профиля (эндокринологу, кардиологу, ревматологу, неврологу, гастроэнтерологу, гематологу, нефрологу) граждане, состоящие на диспансерном учете у профильного специалиста и внесенные в регистр диспансерных больных, могут быть записаны без предварительного посещения участкового врача. Запись должна быть обеспечена в течение 5 дней с момента обращения. Если гражданин не состоит на диспансерном учете у профильного специалиста, запись осуществляется к участковому врачу для решения вопроса о необходимости консультации узкого специалиста и ее организации в срок до 5 дней.
На прием к специалистам узкого профиля (окулисту, хирургу, отоларингологу, травматологу, урологу, онкологу, физиотерапевту, андрологу, инфекционисту и пр.) запись осуществляется в день обращения, на следующий день или на любой другой день по желанию пациента.
На вход первого процесса поступают обработанные данные о пациенте. После выполнения этого процесса получаем медицинскую карту с данными о пациенте. Медицинская карта с данными о пациенте поступает на вход второго процесса «Запись к участковому врачу».На прием к участковому врачу запись осуществляется в день обращения, на следующий день или на любой другой день по желанию пациента. Если прием участкового врача закончен или нет свободного времени для записи, при получении согласия, пациент может быть направлен к другому терапевту. После записи пациенту выдается направление на прием к участковому врачу, который поступает на вход третьего процесса «Прием участковым врачом». В ходе приема участковый врач заполняет лист опроса (жалобы пациента и другие показатели), который поступает на вход четвертого процесса – заполнение медицинской карты. Здесь регистратор переносит всю информацию с листа опроса в медицинскую карту, все медицинские карты хранятся в базе данных. После заполнения карты, регистратор выдает пациенту направление на прием к врачу-специалисту, происходит запись к врачу специалисту и больному выдается талон на прием.