С внешними объектами

Рис. 3.4. Диаграмма «Регистрация и размещение»

Рис. 3.5. Диаграмма «Расчет с клиентами»

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

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

Каждый бизнес-процесс характеризуется:

· четко определенным во времени началом и концом;

· внешними интерфейсами, которые либо связывают его с другими бизнес-процессами внутри организации, либо описывают выход во внешнюю среду;

· последовательностью выполнения функций и правилами выполнения (бизнес-правилами);

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

· Диаграммы Swim Lane идеально подходят для графического отображения в нотации IDEF3 бизнес-процессов:

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

· с помощью пяти перекрестков легко реализуются любые логические условия;

· на ней удобно размещать все документы (внешние и внутренние);

· возможно отображение внешних объектов или объектов предметной области, которые находятся за границами проекта;

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

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

После построения модели «AS IS» на основе этих трех типов диаграмм (рис. 3.2-3.5) разработчик (системный аналитик) должен получить четкое представление о существующей системе управления предприятиям, выя-вить существующие недостатки, определить пути их устранения и сформу-лировать ожидаемый технико-экономический эффект от внедрения инфор-мационной системы. На основании этой информации формируется результирующий для этапа «Формирование требований к ИС» документ «Технико-экономическое обоснование» (ГОСТ 24.202-80, РД 50-34.698-90), который рекомендуется разместить в Приложении к дипломному проекту.

Документ ТЭО ИС должен состоять из введения и следующих разделов (сокращенный вариант):

Раздел «Характеристика объекта и существующей системы управления» должен содержать:

· характеристику производственно-хозяйственной деятельности, организационной и производственной структуры объекта;

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

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

Раздел «Цели, критерии и ограничения создания ИС» содержит:

· формулировку производственно-хозяйственных, научно-техниче-ских и экономических целей и критериев создания ИС;

· характеристику ограничений по созданию ИС;

· перечень основных источников экономической эффективности получаемых в результате создания ИС.

Документ ТЭО разрабатывается в основном для Заказчика, чтобы убедить его в необходимости использования ИС в управлении предприятием.

Затем осуществляется переход к одному из самых важных этапов проектирования «Разработка концепции ИС», результатом выполнения которого является построение модели «ТО ВЕ» в составе функциональной модели, базы данных логического уровня (ER-диаграммы) и дерева меню (прототипа пользовательского интерфейса).

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

Основой для построения функциональной диаграммы является модель «AS IS», но подвергнутая существенной модернизации.

Во-первых, в ней необходимо устранить недостатки, указанные в ТЭО

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

батывается совместно с представителями Заказчика.

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

Рис. 3.6. Модель управления городом «AS IS»

 

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

Модель управления «ТО ВЕ» финансовыми и материальными потоками муниципального образования построена по принципу корпорации, в ко-торой централизован ряд финансово-хозяйственных процедур и создана служба муниципальных закупок (рис. 3.7).

Рис. 3.7. Модель управления городом «TO BE»

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

Данный пример является типичной задачей бизнес-анализа, для которой широко применяются методологии IDEF0, IDEF3 и DFD.

В-четвертых, необходимо использовать принципы Business process reengineering (BPR), основного инструмента при построении модели «TO BE», который предполагает радикальное переосмысление и модификацию бизнес-процессов для достижения резких, скачкообразных улучшений главных показателей деятельности предприятия, таких, как стоимость, качество, сервис и темпы.

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

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

Каждый из девяти принципов BPR необходимо «сфокусировать» на ди-аграммы модели «AS IS» и попытаться применить их для оптимизации бизнес-процессов при построении функциональной модели «ТО ВЕ» [5].

Построение функциональной модели «ТО ВЕ» начинается с создания контекстной диаграммы (рис. 3.8) с учетом всех перечисленных выше приемов по оптимизации модели «AS IS». Контекстная диаграмма содержит полную информацию о входной и выходной информации, пользователях системы и нормативной документации, в соответствии с которой выполняются бизнес-процессы.

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

Первые 2-3 уровня декомпозиции рекомендуется выполнять в IDEF0-методологии, поскольку имеющиеся в ней ICOM-коды обеспечивают связанность диаграмм различных уровней. По мере приближения к моделированию процессов на рабочих местах следует использовать методологи IDEF3 и DFD, так как они более удобны для описания логики процессов и документооборота [5,6].

Рис. 3.8. Контекстная диаграмма функциональной модели «ТО ВЕ»

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

Результат построения функциональной модели может быть представлен одной диаграммой – «деревом узлов» (рис. 3.9). Все блоки нижнего уровня иерархии определяют функциональный состав проектируемой ИС и затем на этапе «Рабочее проектирование» они будут реализованы в виде программных модулей.

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

На базе функциональной модели выполняется расчет стоимости эксп-луатации ИС в среде пакета BPwin помощью инструмента стоимостного анализа, основанного на работах – Activity Based Costing (ABC) [5,6]. Ито-говая стоимость эксплуатации заносится в функциональный блок контекстной диаграммы. Напр., стоимость ежемесячной эксплуатации ИС пред-

приятия транспорта - 21230 руб., АРМ врача - 24101 рублей (рис. 3.8, 3.9).

Функциональная модель является основой для построения базы данных, поскольку она однозначно определяет состав входных и выходных документов. Поэтому БД должна быть построена исходя из следующих двух соображений: все входные документы необходимо разместить в БД, а данные, необходимые для формирования выходных документов, также должны находиться в БД. Построение БД рекомендуется начать с базы данных логического уровня в среде пакета All Fusion Erwin Data Modeler (или Oracle Designer 10g) с помощью методологии IDEF1X [5].

БД логического уровня (ER-диаграмма) должна иметь 3-ю нормальную форму Кодда и не иметь отношений типа M:M (рис. 3.10). При этом в БД необходимо максимально использовать справочники («Номерной фонд», «Услуги» на рис. 3.10), чтобы заменить ввод с клавиатуры справочные данные вызовом их в виде всплывающих меню.

Рис. 3.9. Диаграмма «Дерево узлов» АРМ врача-офтальмолога

Рис. 3.10. БД логического уровня для ИС санатория

 

Пакет ALL Fusion Modeling Suite обеспечивает интеграцию IDEF- и IDEF1X-моделей в среде пакета BPwin для связывания объектов БД (сущностей и атрибутов) с дугами и работами функциональной модели [5]. Связывание моделей гарантирует завершенность анализа и полную информационную поддержку для всех функциональных модулей системы. Другими словами, при выполнении программных модулей не возникнет ситуация, когда не удастся занести информацию в БД или не будет найдены необходимые данные в БД.

Результаты связывания функциональной и информационной моделей могут быть отражены в пяти видах отчетов, настройка которых производится в окне Data Usage Report (Tools/Report/ Data Usage Report). Анализ отчетов позволяет выявить атрибуты, которые не используются при работе программных модулей и являются лишними, если только в них не планируется хранение вычисляемых в процессе работы данных. Также определятся отсутствие необходимых сущностей или атрибутов для информационной поддержки функциональных модулей. В обоих случаях коррекция БД выполняется непосредственно в среде BPwin, а затем экспортируется в пакет ERwin [5,6]. Затем средствами пакета ERwin может быть выполнена генерация схемы базы данных в среде практически любого современного СУБД. В дипломном проекте рекомендуется сгенерировать схему БД в СУБД Access (рис. 3.11) [5,6].

Рис. 3.11. Физическая структура БД для ИС санатория

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

· запустить в работу все программные модули, полученные на нижнем уровне иерархии диаграммы «Дерево узлов» (рис. 3.9);

· обеспечить доступ к каждому полю таблиц БД, чтобы выполнить с ним операции ввода, изменения или удаления данных (рис. 3.11).

В самом простом случае «Дерево меню» может повторить диаграмму «Дерево узлов» (рис. 3.12). Такой вид меню удобен, например, для систем типа АРМ.

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

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

Рис. 3.12. Дерево меню АРМ врача-офтальмолога

 

Рис. 3.13. Дерево меню ИС

3.2.1.2. Стадия «Разработка «ТЗ»»

Полученные на предыдущем этапе функциональная модель, база данных логического уровня и пользовательский интерфейс разрабатываемой системы позволяют разработчику и заказчику определить сложность и тру-доемкость разработки ИС, ее функциональный состав, структуру информа-ции, условия эксплуатации. Этой информации достаточно для разработки технического задания (ТЗ) на ИС (ГОСТ 34.602-89). ТЗ является основным юридическим документом во взаимоотношениях между разработчиком и заказчиком и определяет цели создания ИС, требования к системе и основные исходные данные, необходимые для ее разработки, а также план-гра-фик создания ИС. Обычно ТЗ разрабатывает разработчик, а выдает его раз-работчику заказчик.

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

При разработке «ТЗ» необходимо решить следующие задачи:

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

· разработать и обосновать предъявляемые к подсистемам требования;

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

· установить общие требования к проектируемой системе;

· определить перечень задач создания системы и исполнителей;

· определить этапы создания системы и сроки их выполнения;

· провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

ТЗ на ИС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.