3.2 Разработка (адаптация) ис класса mrp, mrp II, erp, crm или olap
3.2.1 Выполнение работ на стадиях разработки заказной ис
3.2.1.1 Стадия «Разработка аванпроекта»
Стадия «Разработка аванпроекта» содержит два этапа: «Формирование требований к ИС» и «Разработка концепций ИС».
Основным содержанием этапа «Формирование требований к ИС» является разработка модели «AS IS» и документа «Технико-экономическое обоснование». Модель «AS IS» рекомендуется разработать в составе трех типов диаграмм: организационная структура предприятия, схема внешнего документооборота и диаграммы Swim Lane (плавательные дорожки).
Рисунок 3.2 - Организационная диаграмма поликлиники
Эти диаграммы строятся в среде пакета All Fusion Process Modeler (BPwin) соответственно в методологиях Organization Charts, Data Flow Diagram (DFD) и Swim Lane Diagram [Коваленко]. Возможно применение для этих целей и другие программные инструментарии, например, Oracle Designer 10g, Rational Rose, MS Visio, Business Studio и т.п.
Организационная структура предприятия (рис. 3.2) строится в первую очередь, так как исследование предметной область удобнее всего начинать с изучения структуры предприятия: названия подразделений, их соподчиненности, руководящего состава всех уровней. После построения иерархической структуры предприятия следует перейти к изучению схемы внешнего документооборота предприятия (рис. 3.3).
Рисунок 3.3 - Схема документооборота АРМ врача-офтальмолога с внешними объектами
Разработка подобной схемы позволит в интегрированном виде понять информационные процессы, происходящие на предприятии и перейти к реализации наиболее сложной части построения модели «AS IS»: выявлению бизнес-процессов и построению для каждого из них диаграммы плавательных дорожек (рис. 3.4-3.5).
Рисунок 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» и попытаться применить их для оптимизации бизнес-процессов при построении функциональной модели «ТО ВЕ» [Коваленко].
Построение функциональной модели «ТО ВЕ» начинается с создания контекстной диаграммы (рис. 3.8) с учетом всех перечисленных выше приемов по оптимизации модели «AS IS». Контекстная диаграмма содержит полную информацию о входной и выходной информации, пользователях системы и нормативной документации, в соответствии с которой выполняются бизнес-процессы.
Состав функциональных блоков 1-го уровня декомпозиции обычно определяется количеством заместителей руководителя. В том случае, когда разработчик использует процессный подход к управлению, возможно использование модифицированных диаграмм модели «AS IS» в качестве функциональных блоков первого уровня декомпозиции.
Первые 2-3 уровня декомпозиции рекомендуется выполнять в IDEF0-методологии, поскольку имеющиеся в ней ICOM-коды обеспечивают связанность диаграмм различных уровней. По мере приближения к моделированию процессов на рабочих местах следует использовать методологи IDEF3 и DFD, так как они более удобны для описания логики процессов и документооборота [Коваленко, Маклаков].
Процесс декомпозиции функциональных блоков продолжается до тех пор, пока разработчик не убедится в том, что каждый функциональный блок нижнего уровня декомпозиции может быть реализован одним программным модулем.
Результат построения функциональной модели может быть представлен одной диаграммой – «деревом узлов» (рис. 3.9). Все блоки нижнего уровня иерархии определяют функциональный состав проектируемой ИС и затем на этапе «Рабочее проектирование» они будут реализованы в виде программных модулей.
Полностью функциональную модель рекомендуется разместить в Приложении к дипломному проекту, а в тексте пояснительной записки к дипломному проекту полезно оставить только контекстную диаграмму, первый уровень декомпозиции и диаграмму «Дерево узлов».
На базе функциональной модели можно выполнить расчет стоимости эксплуатации ИС в среде пакета BPwin помощью инструмента стоимостного анализа, основанного на работах – Activity Based Costing (ABC) [Коваленко, Маклаков]. Итоговая стоимость эксплуатации заносится в функциональный блок контекстной диаграммы. Например, стоимость ежемесячной эксплуатации ИС транспортного предприятия составит 21230 руб., АРМ врача - 24101 рублей (рис. 3.8, 3.9).
Рисунок 3.8 - Контекстная диаграмма функциональной модели «ТО ВЕ» ИС транспортного предприятия
Рисунок 3.9 - Диаграмма «Дерево узлов» АРМ врача-офтальмолога
Функциональная модель является основой для построения базы данных, поскольку она однозначно определяет состав входных и выходных документов. Поэтому БД должна быть построена исходя из следующих двух соображений: все входные документы необходимо разместить в БД, а данные, необходимые для формирования выходных документов, также должны находиться в БД. Построение БД рекомендуется начать с базы данных логического уровня в среде пакета All Fusion Erwin Data Modeler (или Oracle Designer 10g) с помощью методологии IDEF1X [Коваленко]. БД логического уровня (ER-диаграмма) должна иметь 3-ю нормальную форму Кодда и не иметь отношений типа M:M (рис. 3.10). При этом в БД необходимо максимально использовать справочники («Номерной фонд», «Услуги» на рис. 3.10), чтобы заменить ввод с клавиатуры справочные данные вызовом их в виде всплывающих меню.
Пакет ALL Fusion Modeling Suite обеспечивает интеграцию IDEF- и IDEF1X-моделей в среде пакета BPwin для связывания объектов БД (сущностей и атрибутов) с дугами и работами функциональной модели [Коваленко]. Связывание моделей гарантирует завершенность анализа и полную информационную поддержку для всех функциональных модулей системы. Другими словами, при выполнении программных модулей не возникнет ситуация, когда не удастся занести информацию в БД или не будет найдены необходимые данные в БД.
Результаты связывания функциональной и информационной моделей могут быть отражены в пяти видах отчетов, настройка которых производится в окне Data Usage Report (Tools/Report/ Data Usage Report). Анализ отчетов позволяет выявить атрибуты, которые не используются при работе программных модулей и являются лишними, если только в них не планируется хранение вычисляемых в процессе работы данных. Также определятся отсутствие необходимых сущностей или атрибутов для информационной поддержки функциональных модулей. В обоих случаях коррекция БД выполняется непосредственно в среде BPwin, а затем экспортируется в пакет ERwin [Коваленко, Маклаков]. Затем средствами пакета ERwin может быть выполнена генерация схемы базы данных в среде практически любого современного СУБД. В дипломном проекте рекомендуется сгенерировать схему БД в СУБД Access (рис. 3.11) [Коваленко, Маклаков].
Рисунок 3.10 - БД логического уровня для ИС санатория
Рисунок 3.11 - Физическая структура БД для ИС санатория
Рисунок 3.12 - Дерево меню АРМ врача-офтальмолога
Рисунок 3.13 - Дерево меню ИС транспортного мероприятия
Дерево меню, являющееся прообразом пользовательского интерфейса, разрабатывается только после построения функциональной модели и БД логического уровня. Дело в том, что оно должно обеспечить как минимум две основных функции:
запустить в работу все программные модули, полученные на нижнем уровне иерархии диаграммы «Дерево узлов» (рис. 3.9);
обеспечить доступ к каждому полю таблиц БД, чтобы выполнить с ним операции ввода, изменения или удаления данных (рис. 3.11).
В самом простом случае «Дерево меню» может повторить диаграмму «Дерево узлов» (рис. 3.12). Такой вид меню удобен, например, для систем типа АРМ. В информационных системах с большим количеством пользователей можно в главном меню выделить вкладки (кнопки) для конкретных групп пользователей: руководитель, бухгалтерия, отдел кадров и т.п. (рис. 3.13). Выбор структуры «Дерева меню» определяется функциональностью системы, требованиями к правам доступа пользователей, желаниями Заказчика и т.п.
При разработке интерфейса пользователя необходимо использовать соответствующие стандарты, чтобы обеспечить требования к эргономике (шрифты, цветовая палитра и пр.), расположению окон и элементов управления, правила оформления текстов, перечню сообщений пользователю и правилам обработки реакций пользователя. Современные ИС также обеспечиваются системой подсказок пользователю, так называемая система «Help».