Содержание к диссертации
Введение
1. Повышение эффективности автоматизированного проектирования информационных систем управления предприятием 9
1.1. Задачи интеграции информационных систем управления на предприятии 9
1.2. Особенности информационной системы управления как объекта проектирования 26
1.3. Применение новых информационных технологий при создании информационных систем управления 28
1.3.1. Тенденции развития новых информационных технологий 28
1.4. Цель и задачи исследования 60
Основные выводы первой главы 62
2. Моделирование бизнес-процессов предприятия на этапе проектирования ее информационной системы управления , 63
2.1. Задача количественного описания бизнес-модели и методы ее решения 63
2.2. Методология проектирования организационных подсистем на базе оптимальных модульных структур 72
2.3. Разработка бизнес-модели предприятия с применением CASE-средства BPwin 94
2.3.1. Организационная структура предприятия 94
2.3.2. Построение функциональной IDEFO-модели 98
2.5.1. Разработка диаграммы потоков данных (DFD) 101
Основные выводы второй главы 104
3. Информационное моделирование и алгоритмизация проектируемой системы управления 106
3.1. Структура построения информационной модели данных 106
3.2. Модель проектирования систем отчетности и технология разработки структур данных 109
3.3. Информационная модель проектируемой системы управления и алгоритмы реализации ее подсистем 112
3.4. Моделирование структур баз данных с применением инструментального CASE-средства AllFusion ERwin Data Modeler г7.117
3.4.1. Алгоритм проектирования модели данных 118
3.4.2. Разработка логической модели данных 119
3.4.3. Разработка физической модели данных 120
3.5. Функциональный аспект описания систем управления предприятия 121
Основные выводы третьей главы 124
4. Разработка программного обеспечения информационной системы управления 125
4.1. Организация программного обеспечения 125
4.2. Описание программного комплекса 132
4.3. Использование разработанного программного обеспечения и анализ его эффективности по результатам внедрения 150
Основные выводы четвертой главы 151
Заключение 152
Литература
- Особенности информационной системы управления как объекта проектирования
- Методология проектирования организационных подсистем на базе оптимальных модульных структур
- Модель проектирования систем отчетности и технология разработки структур данных
- Использование разработанного программного обеспечения и анализ его эффективности по результатам внедрения
Введение к работе
Актуальность темы. В настоящее время на любом предприятии имеется своя система управления на уровне административно-управленческой и финансово-экономической деятельности, однако не все бизнес-процессы автоматизированы, так как это требует значительных материальных, трудовых и временных затрат. Повышение уровня автоматизации информационных систем управления (ИСУ) приводит к увеличению производительности предприятия в целом и получению экономического эффекта.
Основой процесса проектирования ИСУ предприятия является описание методов ведения бизнеса, построение структуры системы и структуры баз данных, определение системы математических моделей и алгоритмов, разработка пользовательского интерфейса и выбор технических средств.
Такой процесс проектирования позволяет эффективно решать эти задачи за счет оптимизации модульных структур и использования CASE-технологий. Это позволит решать перечисленные проблемы с достаточным уровнем информатизации и автоматизации, высокой структурой и функциональной организацией и позволит как использовать комплексные технологические средства для разработки программных систем, так и появиться инструменту для решения исследовательских и проектных задач, связанных с начальными этапами разработки. Использование оптимизации модульных структур и CASE-технологий позволит ускорить технологию разработки ИСУ за счет улучшения взаимодействия между различными специалистами, этапами проектирования и отдельными его компонентами, создания документации, единства тезауруса и библиотеки моделей.
Таким образом, актуальность темы диссертационной работы обусловлена необходимостью разработки моделей и алгоритмов автоматизированного проектирования информационных процессов предприятия на основе оптимизации модульных структур и CASE-технологий и повышения за счет этого производительности и качества организации деятельности предприятия и получения экономического эффекта.
Диссертационная работа выполнялась в соответствии с НИР Воронежского института МВД России на 2005 год «Нормы планирования и учета затрат времени профессорско-преподавательского состава образовательных учреждений и сотрудников ОВД на подготовку обучающих, информационных и программных продуктов, разрабатываемых для оптимизации служебной деятельности» (регистрационный номер 01055890).
Цель и задачи исследования. Целью диссертационной работы является исследование и разработка моделей и методов автоматизированного проектирования информационной системы управления предприятия, включая оптимизацию модульных структур информационных процессов, средства CASE-технологий, направленных на повышение эффективности проектирования.
Для достижения поставленной цели необходимо решить следующие задачи:
1) провести анализ методов и алгоритмов проектирования ИСУ
предприятия на предпроектном этапе на основе оптимизации модульных
структур и CASE-технологий;
2) разработать алгоритм моделирования бизнес-процессов
предприятия на основе CASE-технологий, обеспечивающий их
формализованное представление, как основу проектирования ИСУ;
3) синтез алгоритма проектирования информационной модели ИСУ
на основе полученных моделей бизнес-процессов предприятия;
4) разработать модель процесса проектирования ИСУ предприятия с
у использованием оптимизации модульных структур процессов
информационной модели;
5) практическая реализация исследования в виде ИСУ для
предприятия и их апробация, подтверждающая эффективность
разработанных принципов, моделей, алгоритмов и программ.
Методы исследования. В работе использованы методы структурного анализа, CASE-технологий, математического моделирования и оптимизации, объектно-ориентированных баз данных.
Научная новизна. В диссертации получены следующие основные результаты, характеризующиеся научной новизной:
1) модель предметной области и архитектура ИСУ предприятия,
^ отличающиеся возможностью интеграции с комплексами средств
автоматизированной разработки на основе оптимизации модульных структур и CASE-технологий, что обеспечивает высокую эффективность и качество принимаемых решений на предпроектном этапе;
2) алгоритм проектирования бизнес-процесса предприятия,
отличающийся использованием CASE-технологий на основе стандартов
IDEF0 и IDEF1X, учитывающий функционально-стоимостный анализ
бизнес-процесса;
3) алгоритм проектирования информационных моделей ИСУ
предприятия, отличающийся представлением информации на
концептуальном, логическом и физическом уровнях;
4) модель процесса проектирования ИСУ предприятия,
отличающаяся использованием оптимизации модульных структур,
учитывающей минимальный интерфейс между модулями.
Практическая ценность и реализация результатов работы.
Использование программных средств автоматизированного
проектирования ИСУ предприятием на основе оптимизации модульных структур и CASE-технологий позволит повысить эффективность функционирования ИСУ за счет более адекватного описания предметной области и ее информационных потоков, возможности корректировки системы даже на физическом уровне, улучшения качества разрабатываемой ИСУ за счет оптимизации модульных структур и структуры интегрированной базы данных, уменьшения временных и финансовых затрат на ранних этапах проектирования, а также позволит предварительно моделировать новые потоки данных в связи с возникновением новых направлений деятельности предприятия.
Результаты диссертации внедрены в практику работы компании ООО «PET», учебный процесс Воронежского государственного педагогического университета и Воронежского института МВД России.
Апробация работы. Основные положения и результаты диссертационной работы докладывались и обсуждались на следующих конференциях: Всероссийской научно-практической конференции «Охрана, безопасность и связь - 2005» (Воронеж, 2005 г.), Международной научной конференции «Современные проблемы прикладной математики и математического моделирования» (Воронеж, 2005 г.), VIII Всероссийской научно-практической конференции «Повышение эффективности средств обработки информации на базе математического моделирования» (Тамбов, 2006г.), Международной научно-практической конференции «Современные проблемы борьбы с преступностью» (Воронеж, 2006 г.), IV Всероссийской научно-практической конференции «Теория конфликта и ее приложения» (Воронеж, 2006 г.).
Публикации. По результатам исследования опубликовано 15 печатных работ (5 статей и 10 материалов научных конференций). В
работах, опубликованных в соавторстве, лично соискателю принадлежит: алгоритм моделирования бизнес-процессов предприятия на основе CASE-технологий, обеспечивающий их формализованное представление как основу проектирования информационных систем управления [11,69,70,72, 73,75,76]; алгоритм проектирования информационной модели ИСУ на основе полученных моделей бизнес-процессов предприятия [65,66,68,71]; модель процесса проектирования ИСУ предприятия с использованием оптимизации модульных структур процессов информационной модели [64,109,112].
Структура и объем работы. Диссертационная работа состоит из введения, четырех глав, заключения, списка литературы из 136 наименований и 9 приложений. Работа изложена на 271 странице машинописного текста, содержит 62 рисунка и 44 таблицы. Основной текст занимает 168 страниц.
Особенности информационной системы управления как объекта проектирования
Указанные задачи и принципы, описанные в предыдущем пункте, положены в основу создания автоматизированной ИСУ, рассматриваемой в данной работе, которая предназначена для использования в ООО «PET» для производства и реализации техники, полностью удовлетворяющей требования и ожидания потребителей при оптимальном соотношении цены и качества, а также обеспечение удовлетворенности клиентов качеством услуг и сервиса.
Структура рассматриваемой компании состоит из отделов (и входящих в них подразделений) и филиалов, связанных между собой как функционально, выполняя отдельные виды работ в рамках единого бизнес-процесса, так и информационно, обеспечивая постоянный поток документов.
Для достижения эффективности проектируемой ИСУ необходимо решать важные задачи перевода компании на электронный документооборот путем построения бизнес-модели, выявления структуры документооборота, построения модели структуры баз данных и разработки соответствующих приложений управления данными.
В связи с переводом предприятия на электронный документооборот возникают немаловажные проблемы: во-первых, обеспечение безопасности как технического, так и юридического характера, во-вторых, архивирования и хранения документов, что влечет за собой большие объемы данных. В итоге, подобная автоматизация приведет к автоматизации большей части предприятия, а это требует построения мощной и достаточно сложной технической базы.
Общий взгляд на предприятие как на объект проектирования позволяет сформировать общую архитектуру проектируемой ИСУ в масштабе всего предприятия, представляющую собой финансово-административную систему управления бизнес-процессами.
Проектируемая информационная система в масштабе предприятия -это комбинация, тесное переплетение различных информационных технологий, успешная реализация которых зависит от степени их интеграции и применения соответствующих программных и аппаратных средств. В частности, проектируемую систему составляют следующие элементы: коммуникационные приложения, организующие передачу структурированной информации между структурными единицами рассматриваемого предприятия по глобальной сети Internet; подсистема управления полномочиями, обеспечивающая безопасность работы пользователей в системе, работу специализированных приложений и идентификацию системы общения, позволяющая управлять настройками с точки зрения администрирования; подсистема электронной почты, которая позволяет обмениваться пользователям различных удаленных структурных подразделений компании текстовыми сообщениями; специализированные функциональные приложения, необходимые для реализации передачи файловой информации, шифрования, архивирования, временного хранения, преобразования типов документов и т.п.; подсистема управления документооборотом, которая должна обеспечивать автоматизированную функцию распределения и сортировки информации (документов) между подразделениями и конечными пользователями, включая удаленное распределение между филиалами компании, а также преобразование документов для удобного их хранения по шаблонам в структуры данных (по возможности, в зависимости от типа и состава документа); подсистема формирования отчетов, ориентированная для работы в филиалах, необходимая для автоматизированного составления электронных документов и отчетов, поддерживающая совместимость с офисными приложениями и включающая в себя элементы экспорта/импорта; подсистема синхронизации данных, ориентированная на встроенную систему репликаций СУБД Oracle; подсистема управления хранением документов, организующая работу файловой архитектуры (поиск, переименование, удаление и т.д.), а также организацию структурированной информации, основанной на СУБД Oracle с возможностью печати документов.
Таким образом, создание административно-финансовой системы управления предприятия необходимо проводить с использованием современных информационных технологий, учитывая методики развития и ведения бизнес-функций.
Методология проектирования организационных подсистем на базе оптимальных модульных структур
Внедрение информационной системы всегда приводит к реорганизации бизнеса. В значительной степени предмет деятельности остается без изменений, в то время как меняются способы и участники этой деятельности. Модели, используемые для определения потребностей бизнеса, должны позволять делать обоснованные изменения в организационной структуре. Эти модели должны как можно меньше зависеть от известных информационных технологий. Система должна быть открыта в сторону введения новых процедур, например, производства, продаж, управления или учета.
Требования должны моделироваться и определяться настолько общим способом, насколько это возможно; функциональные потребности должны определять что делается, а не как или кем. Структура данных должна быть рассчитана на изменения в организационной структуре и на текущие и ожидаемые исключения и ограничения. На этом основан подход Р. Баркера к проектированию информационных систем, которая соответствует методикам моделирования бизнеса [85, 102]. Приведенная на рис. 2.5 диаграмма иллюстрирует приведенные выше технологии моделирования подхода Р. Баркера, а также места их пересечения.
Каждая из этих моделей реального мира должна соответствовать контексту общего направления бизнеса, которое определяется его задачами, приоритетами и критическими для успеха факторами.
В общем случае, автоматизированная ИСУ предприятия - это не только программы, данные и коммуникации, но и организационные структуры, планы-графики работы, а также цели и стимулы предприятия и отдельных людей. И все эти «вещи» должны быть понятным и непротиворечивым образом соединены в одну систему. Все возрастающая сложность и многоаспектность предприятия определяют растущую сложность согласования его частей и аспектов работы. Следовательно, необходимо использовать современные методы проектирования ИСУ, которые используют стандартные системы документации на различных этапах разработки; разработку и использование формальных методов синтеза проектных решений для различных этапов и уровней создания этих систем; разработку модульных систем, а также разработку и использование типовых проектных решений и пакетов прикладных программ; автоматизацию получения проектных решений. Наиболее важной задачей при проектировании ИСУ является декомпозиция системы на подсистемы (модули), т.е. на элементы.
Проблемы разбиения (декомпозиции) системы на подсистемы, задачи на подзадачи, программного обеспечения на отдельные программы и подпрограммы возникают на различных этапах анализа и синтеза ИСУ, причем каждый последующий уровень разбиения представляет собой абстрактный компонент (модуль) системы предыдущего уровня. В качестве модулей различных уровней в организационной структуре рассматриваются функциональные подразделения предприятия. При рассмотрении программного обеспечения модули интерпретируются как машинная команда, инструкция языка высокого уровня, блок команд или инструкций, подпрограмма, программа, отдельные задачи и подзадачи ИСУ и т.п.
Такой подход при проектировании информационного и программного обеспечения ИСУ на базе принципа типизации позволяет свести проектирование к оптимальному синтезу функционально независимых отдельных частей (модулей), совместно выполняющих заданные функции системы с требуемой эффективностью, и значительно сокращает затраты на разработку, внедрение и модификацию систем.
На основе декомпозиции системы выделяются задачи, подлежащие автоматизации; определяется необходимое множество процедур реализации заданного множества функциональных задач и необходимой для этого информации; осуществляется предварительная оценка уровня типизации используемых алгоритмов.
Разделение информационного и программного обеспечения на отдельные модули и их последующее сопряжение является одной из наиболее трудных и слабо формализованных проблем.
Данная задача возникает на этапе составления технического задания и проектирования, когда формулируются общие требования к системе информационного и программного обеспечения ИСУ, определяются выполняемые системой функции или процедуры по обработке данных.
В основу этой задачи положен анализ входных, промежуточных и выходных данных и множество необходимых процедур их преобразования. Информационные связи между процедурами обработки данных можно формализовать с использованием мультиграфа, вершинами которого являются процедуры, а связывающие их дуги помечены номерами общих для данных процедур информационных элементов или различными цветами.
В графовой интерпретации задача состоит в определении разбиения мультиграфа с раскрашенными или помеченными дугами на подграфы, обеспечивающего минимум суммарного числа дуг различного цвета, связывающего подграфы при ограничениях на общее число выделяемых подграфов, число дуг и вершин каждого подграфа, число связей между отдельными подграфами.
Эта задача подразумевает анализ информационных потоков по каждой подсистеме и системе в целом в виде блок-схем, стрелочных диаграмм, графов, таблиц, матриц специального вида [82,87,100].
Формальный анализ и определение характеристик ИСУ необходимо проводить на базе совокупности взаимосвязанных матричных и графовых моделей, а также с использованием формализованных методов представления результатов изучения и анализа [3,55,63].
Модель проектирования систем отчетности и технология разработки структур данных
На сегодняшний день многие компании обнаружили, что накопить большой объем данных еще не означает обладать полезной информацией. Учетные системы могут генерировать для компании самые ценные ресурсы - данные, но не способны преобразовать их в информацию, необходимую для принятия решений. Однако с подобной задачей удается справиться, применяя инфраструктуру хранилища данных.
Предназначение хранилища данных - предоставление специально подобранной информации, необходимой для принятия решений. , Известно несколько различных архитектур корпоративной отчетности, начиная с создания отчетов напрямую из учетных систем и заканчивая комплексной средой хранилища, описание которых рассматривается в работах [25,55], однако архитектура отчетности с использованием хранилищ данных представляет в нашем случае наибольший интерес и, следовательно, остановимся на рассмотрении данной проблемы более подробно.
С ростом информативности выясняется тот факт, что накопить большой объем данных еще не означает обладать полезной информацией.
Хранилище данных предприятия (Enterprise Data Warehouse - EDW) предназначено для объединения данных из различных учетных систем (рис. 3.2). Ключевым моментом этой технологии является применение бизнес-правил к исходным данным. Бизнес-правила определяют методы консолидации, стандартизацию кодов, очистку данных и отслеживание транзакций за прошедшие периоды. t Иитрины данных
Данные из различных источников помещаются в хранилище, а их описания - в репозиторий метаданных. Конечный пользователь, используя различные инструменты (средства визуализации, построения отчетов, статистической обработки и т.д.) и содержимое репозитория, анализирует данные в хранилище. Результатом является информация в виде готовых отчетов, найденных скрытых закономерностей, каких-либо прогнозов. Так как средства работы конечного пользователя с хранилищем данных могут быть самыми разнообразными, то теоретически их выбор не должен влиять на структуру хранилища и функции его поддержания в актуальном состоянии. Физическая реализация данной концептуальной схемы может быть самой разнообразной.
После консолидации к данным применяются правила стандартизации и очистки. Таким образом, у пользователей появляется согласованный доступ к данным, не зависящий от источника. Записи, которые не отвечают требованиям, предъявляемым к качеству данных, получают статус «ожидания», пока не будет выполнено действие по устранению создавшейся неопределенности. В соответствии с бизнес-правилами, таким данным можно присвоить также значение «по умолчанию».
После очистки и консолидации данные хранятся в реляционной СУБД (например, продукты фирмы Oracle, IBM, SQL Server и т.п.). Данные хранятся в реляционном формате, позволяя эффективно использовать историю транзакций и время от времени менять дизайн.
Помимо истории транзакций хранилище данных также содержит изменения, вносимые в структуру бизнес подразделений. Таким образом, в хранилище поддерживаются так называемые «медленно изменяющиеся измерения» (slowly changing dimensions) и оно служит единым источником регулярно обновляемой информации для витрин. Поскольку изменения происходят как в учетной системе, так и в витринах данных, хранилище служит своего рода буфером, минимизирующим исправления в данных и инфраструктуре отчетности [25].
Единственным очевидным аргументом, говорящим не в пользу хранилищ данных, является стоимость их реализации. Однако расходы на дизайн и разработку можно отсрочить, создавая EDW постепенно, расширяя его по мере добавления новых предметных областей. При таком подходе выгода от использования высококачественных данных превышает издержки на разработку сложной архитектуры отчетности.
Использование разработанного программного обеспечения и анализ его эффективности по результатам внедрения
а) В нижней таблице отображаются те задания, у которых время доставки попадает в тот промежуток времени, на котором стоит курсор в средней таблице. Например: курсор стоит в столбце с общим заголовком «Завтра» на строке со временем «13.5». Это значит, что в нижней таблице будут видны все задания, у которых «Назначено» попадает в промежуток времени с «завтра 13:30» до «завтра 14:00».
б) Если кликнуть на заголовке столбца с надписью «Сегодня», «Завтра» или «Послезавтра», то в нижней таблице отобразятся все доставки за выбранный день, не зависимо от времени.
При снятии флага «Отображать завтра и послезавтра» в форме «Доставка» отображается список водителей, который имеет структуру типа «дерево» со следующими вариантами ветвей: выходной; название филиала компании; перерыв/отсутствуют; выполняют доставку: доставка не начата; доставка идет; доставка просрочена; свободны; доставки без клиента.
При навигации по дереву происходит перемещение курсора в средней и нижней таблицах на соответствующую запись. Обозначения: жирным красным шрифтом выделяются водители, у которых доставка просрочена; жирным желтым - доставка не начата; жирным зеленым - водитель свободен; тонким черным - все остальные. В колонке «auto» содержится условное обозначение типа автомобиля, на котором водитель работает: - водитель легкового автомобиля; ІН &П» - водитель автомобиля типа «универсал»; - водитель микроавтобуса; - водитель грузового автомобиля. Обновление дерева происходит автоматически при изменении и обновлении данных по доставкам.
Обновление структуры дерева (удаление пустых веток и создание новых при появлении новых доставок) происходит при нажатии выпадающей кнопки «Обновить все» к кнопке «Обновить».
Вызвать форму «Доставка» можно одним из следующих способов.
Первый способ. В форме «Заказы» есть кнопка «Задания»/«Доставка» (рис. 4.6). При нажатии на эту кнопку откроется форма для установки времени доставки выбранного заказа. С помощью I этой формы можно формировать любые доставки.
Второй способ. Из главной формы ИСУ «Менеджер-Р» щелкнув на соответствующей форме «Доставка» в списке форм (рис. 4.5). Так можно формировать заявки только на служебные доставки.
Третий способ. С помощью комбинации горячих клавиш Alt+D . Такой вызов аналогичен вызову из главной формы и, соответственно, так можно формировать заявки только на служебные доставки.
Рассмотрим создание задания на доставку товара через вызов формы «Задания». Кликнув на нужный пункт главного меню, откроется форма «Задания». Для того, чтобы назначить доставку/доставку с установкой на какое-то время, необходимо выбрать курсором нужный день (столбец) и I время (строку) и нажать правой кнопкой мыши на выбранной ячейке. Из выпадающего меню выбрать необходимый пункт: доставка или доставка с установкой. Внизу формы будут заполнены поля для создания нового задания на доставку/доставку с установкой. На этот момент задание еще не создано и можно изменить данные. В поле «Комментарий» необходимо заполнить адрес доставки. В поле «Назначено» - дата и время доставки. В поле часов - количество часов доставки. После того, как заполнены все необходимые данные, следует нажать кнопку «Новое». Новое задание на доставку создано.
Некоторые поля в форме «Задания» можно изменять непосредственно в таблице: «комментарий», «заказ», «время доставки» и «назначено». При этом изменения применятся сразу после того, как пользователь сойдет с изменяемой строки. Все поля задания можно поменять внизу формы. Изменения применятся только после нажатия на кнопку «Изменить».
В программе предусмотрена возможность копирования задания. Для этого необходимо переместить курсор на то задание, которое надо скопировать, изменить в нем необходимые поля и нажать кнопку «Новое».
При этом в старом задании ничего не изменится. Если заполнить поля внизу формы и несколько раз нажать на кнопку «Новое», то создадутся несколько одинаковых заданий, отличающихся только временем создания.
После выполнения задания водитель отчитывается о доставке в отделе доставок, о чем делается соответствующая запись в форме «Доставка» и задание считается исполненным. Если водитель задерживается с доставкой товара, то об этом предупреждается клиент и время выполнения задания в форме «Доставка» увеличивается. Если клиент по какой-либо причине не может принять товар в указанные сроки, то время на выполнение задания также увеличивается и вносятся соответствующие изменения в поля формы «Доставка».
