3. Интеграция информационных систем
Реинжиниринг бизнес-процессов на основе интегрированных информационных систем
Эффективная координация хозяйственной деятельности отдельных структурных единиц сложной организационно- экономической системы предусматривает использование концепции процессного подхода в управлении. Эта концепция предполагает установление нескольких деловых процессов (бизнес-процессов), проходящих через все взаимодействующие структурные единицы организационно-экономической системы (предприятия, корпорации, и т.д.).
Схематически сквозные процессы в управлении представлены на рис. 3.1.
Бизнес-процесс представляет собой взаимосвязанную упорядоченную последовательность операций, объединенных общей целью и характеризующуюся определенным входом и выходом.
Рассмотрим классификацию бизнес-процессов.
Можно выделить четыре класса бизнес-процессов.
!!!!!!!!!!!!!!!!!!!!!!
Рис. 3.1 Процессный подход в управлении
Основные бизнес-процессы предназначены для производства товаров или услуг (работ) на основе затрат ресурсов. Эти процессы состоят из операций, предусмотренных технологией и организацией производства.
Обеспечивающие бизнес-процессы призваны обеспечить основные бизнес-процессы производственными ресурсами (материальными, финансовыми, трудовыми, информационными).
Как основные, так и обеспечивающие бизнес-процессы относятся к исполнительской деятельности объекта управления.
Бизнес-процессы управления и информационных технологий относятся к деятельности субъекта управления. Они призваны управлять прочими бизнес-процессами на основе информационных технологий. В их состав входят такие операции (функции управления), как организация, планирование, учет, контроль и анализ деятельности всех взаимодействующих структурных единиц, а также необходимые при этом операции сбора, хранения, обработки и выдачи информации. Бизнес-процессы управления и информационных технологий связаны с остальными бизнес-процессами в рамках каждой структурной единицы.
В качестве инструментальных средств управления бизнес-процессами используются информационные системы класса work-flow, то есть информационные системы управления потоками работ.
Если основные и обеспечивающие бизнес-процессы относятся к текущей деятельности хозяйствующего субъекта, то бизнес-процессы направлены на перспективу: совершенствования продукции, инновационную и инвестиционную деятельность, конструкторскую и технологическую подготовку нового производства. Бизнес-процессы управления информационных технологий оказывают воздействие на бизнес-процессы развития в рамках стратегического управления.
Процессный подход в управлении возможен только на основе интегрированной (корпоративной) информационной системы, охватвывающей все взаимосвязанные структурные единицы корпорации.
Внедрению такой интегрированной информационной системы должен предшествовать тщательный анализ и перепроектирование (реинжиниринг) бизнес-процессов с целью существенного повышения эффективности производственно-хозяйственной деятельности корпорации.
Классическое определение реинжиниринга, которое сформулировали М. Хаммер и Дж. Чампи, - это фундаментальное переосмысление и радикальное перепроектирование деловых процессов для достижения резких скачкообразных улучшений в решающих, современных показателях деятельности компании, таких, как стоимость, качество, сервис и темпы.
Основными принципами реинжиниринга бизнес-процессов являются следующие:
1). «горизонтальное» сжатие процесса, при котором несколько операций объединяются в одну и достигается универсализация исполнителей;
2). «вертикальное» сжатие процесса, при котором исполнители получают больше самостоятельности в принятии решений и контролируют ход процесса, а не только результат;
3). организация рабочих групп для выполнения процесса под руководством менеджера («хозяина») процесса;
4). организация взаимодействия территориально-распределенных структур (виртуальных корпораций) на основе Internet-технологий;
6). обеспечение единой точки контакта процесса с заказчиком;
7). распараллеливание процессов для экономии времени при сохранении необходимых взаимосвязей между ними;
8). многовариантный подход к организации процессов.
Для проектирования бизнес-процессов используется инженерный подход с привлечением количественных оценок.
Основными показателями эффективной организации бизнес-процесса являются стоимостные и временные затраты на его осуществление, а также качество полученной в результате продукции.
В качестве инструментальных средств моделирования бизнес-процессов используются CASE-средства, обеспечивающие графическое представление процессов и функционально-стоимостной анализ, инструментальные средства имитационного моделирования, а также математические методы оптимизации.
Принципы и особенности проектирования интегрированных информационных систем
Интегрированная (корпоративная) информационная система (КИС) представляет собой объединение информационных систем в различных сферах деятельности одного или нескольких хозяйствующих субъектов.
Применительно к промышленному предприятию состав систем, составляющих интегрированную систему, во взаимосвязи с пользователями на различных уровнях управления, может быть представлен в виде следующей пирамиды (рис. 3.2). На этом рисунке приняты следующие обозначения:
!!!!!!!!!!!!!!!!!!
Рис. 3.2. Связь классов информационных систем с уровнями функциональных задач
АС – административные системы (Executive Support Systems – ESS);
СППР – системы поддержки принятия решений (Decision Support Systems – DSS) для решения возникающих проблем;
УИС – управленческие информационные системы (Management Information Systems – MIS) для решения повторяющихся задач;
СОЗ – системы обработки знаний (Knowledge Work Systems – KWS);
ОАС – офисные автоматизированные системы (Office Automation Systems – OAS);
СОО – системы обработки операций (Transaction Processing Systems – TPS );
МВУ – менеджеры верхнего уровня;
МСУ – менеджеры среднего уровня;
ИТР – инженерно-технические работники, служащие;
МНУ – менеджеры нижнего уровня, рабочие, операторы.
Следует заметить, что интеграции подлежат информационные системы как в сфере управления, так и в сфере исполнения определенной работы.
Интеграция функциональной части системы предполагает решение сквозных задач, охватывающих несколько информационных систем (подсистем интегрированной системы). Эти сквозные задачи должны отвечать общим критериям эффективности деятельности предприятия и соответствовать процессному подходу в управлении.
В качестве интегратора могут выступать ресурсы, например, материальные потоки. В настоящее время за рубежом и в нашей стране развивается наука об управлении материальными потоками и связанными с ними информационными и финансовыми потоками – логистика.
Интегрированные логистические системы охватывают управление и обеспечивают синхронизацию в движении материальных потоков от поставщиков предприятия, внутри подразделений предприятия (склады-цеха-склады) и до потребителей через дистрибутивную сеть. За счет синхронизации снижаются запасы на складах, объем незавершенного производства в цехах и повышается гибкость в ответ на требования рынка.
Рассмотрим требования к интеграции обеспечивающих подсистем.
Интеграция информационного обеспечения требует создания общей базы данных.
Наиболее очевидные задачи – это объединение баз данных конструкторской и технологической подготовки производства, а также интеграция использования прочих баз данных КИС.
Совместное использование разнородных баз данных обеспечивается на основе соответствующих драйверов.
Интеграция программного обеспечения проявляется в следующих направлениях:
- программное обеспечение сквозных задач;
- программное обеспечение обмена информацией между отдельными базами данных в процессе их объединения;
- организация взаимодействия прикладных программ;
- разработка стандартов программного обеспечения.
Организация взаимодействия прикладных программ требует использования соответствующих интерфейсов.
Интеграция технического обеспечения предполагает проведение единой технической политики и использование компьютерных сетей как основного технического интеграционного фактора.
Интегрированная информационная система в рамках одного предприятия обычно поддерживается локальной вычислительной сетью. Однако интеграционные процессы в современной экономике выходят за рамки отдельных предприятий. Создаются финансово-промышленно-торговые группы (корпорации), единое информационное пространство которых обеспечивается корпоративной сетью во взаимосвязи с другими сетями (рис. 3.3).
Для защиты от несанкционированного доступа связь корпоративной сети с Internet осуществляется через, так называемые, импортный и экспортный брандмауэры.
Для снижения загрузки зарубежных каналов могут использоваться зеркальные серверы, содержащие копии Web-страниц и находящиеся на территории нашей страны. На Proxy-серверах сохраняется информация, к которой было обращение, для облегчения повторного обращения и снижения загрузки Internet.
Международная банковская сеть SWIFT объединяет банки 150 стран мира и представляет собой наиболее защищенную систему передачи финансовой информации.
Интеграция организационного обеспечения предусматривает общее руководство системой (без дисбаланса в ту или иную сторону автоматизации) и корректировку организационной структуры системы и должностных инструкций пользователей с учетом новых сквозных задач.
Организация процесса проектирования не должна сводиться к разработке проектировщиком информационной интегрированной системы всех участков автоматизации.
Проектировщик интегрированной системы должен заниматься лишь «стыковочными» вопросами, оставляя возможность решения технологических вопросов технологу, конструкторских – конструктору и так далее.
Особенности определения экономического эффекта интеграции системы в следующем. Надо суметь оценить тот дополнительный эффект за счет интеграции, который превышает сумму эффектов от применения автоматизированной системы в различных сферах деятельности предприятия. Этот дополнительный эффект принято называть системным или синергетическим эффектом.
Требования к корпоративным информационным системам
Требования к корпоративным информационным системам, предъявляемые при их выборе или разработке, сгруппированы на рис. 3.4 по функциональной части и обеспечивающим подсистемам.
Рассмотрим вкратце основные требования к КИС.
Функциональная часть системы должна удовлетворять требованиям интеграции и полноты и соответствовать требованиям международных стандартов (MRP-II, ERP и др.).
Алгоритмы функциональных задач системы должны учитывать особенности российского законодательства.
Рис. 3.4. Требования к корпоративным информационным системам
В составе вспомогательных функциональных задач системы должен быть предусмотрен автоматизированный мониторинг процесса эксплуатации системы. Этот мониторинг должен охватывать как анализ функционирования программно-технического комплекса КИС, так и анализ фактической экономической эффективности ее использования.
Требования к информационному обеспечению КИС сводятся к следующему. Система должна быть локализована, то есть пользовательский интерфейс должен быть представлен на русском языке и форматы представления дат, чисел, денежных единиц и т.д. должны соответствовать российским стандартам.
Проектирование системы АРМ на основе локальной вычислительной сети
Автоматизированное рабочее место (АРМ) является основным организационным элементом экономической информационной системы.
АРМ представляет собой программно-технический комплекс для решения задач пользователя (клиента) информационной системы непосредственно на рабочем месте в режиме человеко-машинного диалога.
Иногда АРМ называется клиентским рабочим местом, рабочим местом пользователя информационной системы, рабочей станцией.
Диалоговый режим позволяет избежать необходимости моделировать с помощью математических методов трудно формализуемые этапы решения задачи. Участие человека в процессе решения, как известно, отличает автоматизированный процесс от автоматического.
В экономической информационной системе АРМ классифицируются следующим образом:
- АРМ руководителя;
- АРМ секретаря;
- АРМ специалиста.
Назначение АРМ руководителя:
- информационная поддержка принятия управленческих решений;
- оперативное получение справок по основным показателям производственно-хозяйственной деятельности
- организация личной работы и др.
Назначение АРМ секретаря:
- ведение информационной базы АРМ руководителя;
- контроль исполнения сроков выполнения поручений руководителя;
- составление писем;
- работа с электронной почтой и др.
Назначение АРМ специалиста:
- выполнение функций управления производственно-хозяйственной деятельностью предприятия (планирование, учет, анализ и т.д.)
- повышение квалификации с помощью автоматизированной обучающей системы (АОС) и др.
АРМ управленческого персонала предприятия функционально связаны между собой в соответствии с принятой организационной структурой управления, то есть образуют систему АРМ.
В системе взаимосвязи АРМ прослеживается двухуровневый кибернетический принцип управления, согласно которому несколько подчиненных АРМ специалистов (исполнителей) замыкаются на один вышестоящий АРМ руководителя, которому придается в помощь для информационного обслуживания АРМ секретаря.
Использование системы АРМ управленческого персонала в организационной структуре управления предприятием показаны на рис. 3.5.
АРМ директора предприятия непосредственно связан в функциональной части с АРМ главных специалистов (главного экономиста, главного бухгалтера, главного инженера, начальника производства, зам. директора по информатизации и т.д.).
В соответствии с линейно-функциональной структурой управления АРМ директора также непосредственно связан с АРМ начальников цехов, а АРМ главных специалистов – с АРМ начальников подчиненных им отделов.
В свою очередь АРМ руководителей цехов и отделов непосредственно связаны в процессе работы с АРМ своих подчиненных – линейных руководителей нижнего уровня или специалистов.
Функциональная взаимосвязь АРМ обеспечивается технологической взаимосвязью, основанной на использовании локальной вычислительной сети предприятия и серверов баз данных приложений информационно-вычислительного центра.
Если при локальной архитектуре информационной системы приложения и базы данных находятся на одном компьютере клиента (рис. 3.6, а), то в распределенных системах организуются интегрированные базы данных общего пользования.
Файл-серверная архитектура предполагает, что вся обработка данных выполняется клиентом, а сервер базы данных выполняет функции накопления данных и передачу файлов по запросу клиента (рис. 3.6, b).
Синхронизация совместного использования базы данных возлагается на сетевую СУБД, которая должна обеспечивать блокирование записей во время корректировки.
Двухуровневая клиент-серверная архитектура дает возможность, в отличие от файл-серверной архитектуры, отказаться от пересылки по сети файлов базы данных целиком, а передавать только ту выборку из базы данных (записи), которая удовлетворяет запросу пользователя. Это достигается благодаря наличию на сервере базы данных локальных СУБД клиентов (рис. 3.6, c). Двухуровневая клиент-серверная архитектура является предпочтительной для небольшого количества пользователей.
Трехуровневая клиент-серверная архитектура предусматривает размещение прикладных программ на специальных серверах приложений, которые взаимодействуют с серверами баз данных (рис. 3.6, d). Такая архитектура повышает масштабируемость информационных систем.
Возможно использование общего компьютера в качестве сервера базы данных и сервера приложений.
Рис. 3.6 Архитектура информационных систем
Многоуровневая клиент-серверная архитектура предполагает возможность связи каждого клиента с несколькими серверами приложений, которые, в свою очередь, могут обращаться к нескольким серверам баз данных. Многоуровневая архитектура может быть целесообразна для территориально распределенных корпораций.
При переходе от локального АРМ к двухуровневой, трехуровневой и многоуровневой архитектуре клиент постепенно превращается из «толстого» в «тонкого», компьютер которого обеспечивает лишь пользовательский интерфейс.
Особенности и преимущества проектирования информационной системы на базе АРМ заключаются в том, что можно создавать систему по очереди (сначала спроектировать подсистему АРМ для работников одного цеха или отдела, затем другого и т.д.). Так постепенно развивается вся система, но с самого начала нужно предусмотреть решение общесистемных вопросов (мощность серверов и сетей, кодирование и т.д.)
Использование при разработке системы концепции АРМ соответствует применению целевого подхода в управлении. Определив основные цели пользователей АРМ, можно обосновать состав функциональных задач кА
Синхронизация совместного использования базы данных возлагается на сетевую СУБД, которая должна обеспечивать блокирование записей во время корректировки.
Двухуровневая клиент-серверная архитектура дает возможность, в отличие от файл-серверной архитектуры, отказаться от пересылки по сети файлов базы данных целиком, а передавать только ту выборку из базы данных (записи), которая удовлетворяет запросу пользователя. Это достигается благодаря наличию на сервере базы данных локальных СУБД клиентов (рис. 3.6, c). Двухуровневая клиент-серверная архитектура является предпочтительной для небольшого количества пользователей.
Трехуровневая клиент-серверная архитектура предусматривает размещение прикладных программ на специальных серверах приложений, которые взаимодействуют с серверами баз данных (рис. 3.6, d). Такая архитектура повышает масштабируемость информационных систем.
Возможно использование общего компьютера в качестве сервера базы данных и сервера приложений.
Многоуровневая клиент-серверная архитектура предполагает возможность связи каждого клиента с несколькими серверами приложений, которые, в свою очередь, могут обращаться к нескольким серверам баз данных. Многоуровневая архитектура может быть целесообразна для территориально распределенных корпораций.
При переходе от локального АРМ к двухуровневой, трехуровневой и многоуровневой архитектуре клиент постепенно превращается из «толстого» в «тонкого», компьютер которого обеспечивает лишь пользовательский интерфейс.
Особенности и преимущества проектирования информационной системы на базе АРМ заключаются в том, что можно создавать систему по очереди (сначала спроектировать подсистему АРМ для работников одного цеха или отдела, затем другого и т.д.). Так постепенно развивается вся система, но с самого начала нужно предусмотреть решение общесистемных вопросов (мощность серверов и сетей, кодирование и т.д.)
Использование при разработке системы концепции АРМ соответствует применению целевого подхода в управлении. Определив основные цели пользователей АРМ, можно обосновать состав функциональных задач каждого АРМ и общесистемные решения.
Обоснование состава задач, возлагаемых на АРМ, целесообразно осуществлять на основе принципов реинжиниринга бизнес-процессов, предусматривающего критический анализ существующей системы управления и поддерживающих ее информационных процессов. Анализ существующих процессов обработки информации должен сопровождаться поиском ответов на вопросы: почему принят существующий состав задач, чем вызваны существующие варианты их решения, что следовало бы изменить и почему, и т.д.
Открытые информационные системы: основные свойства и межсистемные интерфейсы
Открытая информационная система – это система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы.
Основные свойства открытых систем следующие:
1). Интероперабельность (interoperability) – способность к взаимодействию с другими системами). Это свойство присуще открытым системам по определению.
2). Расширяемость/масштабируемость (extensibility/scalability).
3). Мобильность (portability).
4). Дружественность (driveability) – легкая управляемость со стороны пользователя. Это требование можно считать общим к каждой современной информационной системе.
Интеграция компонентов (элементов) в открытой системе должна следовать стандартам интерфейсов этих компонент. Эти интерфейсы охватывают следующие стороны взаимодействия компонентов:
- управление (Management) – системное и сетевое администрирование, управление информационной безопасностью, ресурсами системы, конфигурирование системы.
- пользовательский интерфейс (User Interface) – интерфейс пользователя с прикладными программами и средствами разработки приложений;
- интерфейсы прикладных программ (Application Programs Interface – API) – интерфейсы между прикладными программами и между прикладными программами и операционной системой;
- форматы данных;
- интерфейсы сетевых коммуникаций.
В качестве пути создания открытой системы рассмотрим использование стандартов OLE.
OLE (Object Linking and Embedding – связывание и внедрение объектов) – это набор стандартов для связи и внедрения объектов при создании компонентов программного обеспечения. Одним из стандартов OLE является спецификация модели составного объекта (или COM), основа для бинарных соединений между компонентами.
OLE позволяет увеличивать степень интеграции между программными модулями и служит для создания множества взаимозаменяемых компонентов программного обеспечения. Набор услуг, которые предлагает OLE, непостоянен. Корпорация Microsoft постоянно модернизирует и расширяет как операционную систему Windows, так и набор стандартов OLE в соответствии с широким набором требований по интеграции приложений.
Стандартные методы совместного доступа к базам и программам в сложных информационных системах
Организация взаимодействия прикладных программ на основе интерфейсов CORBA и COM
Стандартные интерфейсы CORBA и COM в настоящее время являются основными для организации взаимосвязи объектно-ориентированных прикладных программ в распределенных информационных системах.
Использование одного только объектно-ориентированного языка недостаточно для разработки распределенных информационных систем.
Очень часто различные компоненты программного обеспечения требуют реализации на разных языках и используют разную программно-техническую платформу (операционные системы и аппаратные средства).
При создании распределенной ИС требуется преодолевать границы:
- унаследованного программного обеспечения;
- операционных систем;
- языков программирования;
- сетевых коммуникаций;
- объектных моделей (например, модели объектно-ориентированного программирования на языках Java и C++ имеют некоторые отличия, что препятствует интеграции приложений);
- различия в продукции многих продавцов на рынке ИС;
- различия с точки зрения фирм-проектировщиков ИС в действующих информационных системах ряда фирм-заказчиков.
Программный интерфейс CORBA (Common Object Request Broker Architecture – общая архитектура брокеров объектных запросов) курируется консорциумом OMG.
Программный интерфейс COM (Component Object Model – компонентная объектная модель) является разработкой корпорации Microsoft.
Язык описания интерфейсов IDL (Interface Definition Language) обеспечивает стандартизацию описания взаимосвязи объектов в объектно-ориентированных прикладных программах. Однако IDL недостаточно для обеспечения возможности взаимодействия объектов. Требуется программное средство, которое доставляет запросы на вызов методов реагирования объектов на внешние воздействия. Таким средством является брокер объектных запросов ORB (Object Request Broker), промежуточный программный слой, отвечающий за обработку запросов и доставку результатов клиенту.
Организация связи с разнородными базами данных на основе драйверов ODBC
ODBC (Open Database Connectivity) – широко распространенный комплекс драйверов фирмы Microsoft для связи с разнородными (гетерогенными) базами данных, удовлетворяющий стандартам ISO.
С помощью ODBC можно манипулировать данными любой реляционной и нереляционной СУБД, а также данными файлов электронных таблиц и текстовых файлов.
Связь клиентской и серверной частей информационных систем осуществляется с помощью локальной или глобальной сети. Доступ к соответствующей базе данных со стороны клиента (из прикладных программ) обеспечивается трехслойным программным интерфейсом.
Управляющий модуль ODBC (ODBC Administration) позволяет определить необходимые источники данных для прикладной программы.
Драйвер ODBC представляет собой динамически загружаемую библиотеку, которую клиентское приложение загружает в свое адресное пространство для доступа к источнику данных.
Для каждой используемой СУБД нужен собственный ODBC-драйвер. ODBC-драйверы осуществляют функции клиентских интерфейсов API (Application Programs Interface).
ODBC-драйвер для конкретной СУБД переформирует формат запроса прикладной программы во внутренний формат, распознаваемый СУБД, к которой обращен запрос.
Эффективность ODBC-драйверов состоит в том, что позволяет изолировать приложение от внутренней специфики баз данных. По сути, ODBC-драйверы являются типичными шлюзами от приложений к СУБД.
Традиционная технология использования ODBC создает много работы сетевому администратору при появлении новых СУБД. Проблема состоит в необходимости инсталляции дополнительных драйверов для этой СУБД на каждом клиентском месте. Выход найден в технологии связи с разнородными базами данных с использованием сервера ODBC .
Системы управления информационными потоками как средство интеграции приложений
Большинство аналитиков рассматривают системы класса Workflow как важнейшую составляющую современных корпоративных информационных систем, наиболее перспективную технологию управления бизнес-процессами.
Буквальный перевод термина «workflow» как «поток работ» почти никак не раскрывает его содержание. Более информативно определение программных продуктов класса Workflow как систем, обеспечивающих полную или частичную координацию выполнения производственных операций (заданий, работ, функций), составляющих структурированные бизнес-процессы предприятия.
В основе технологии Workflow лежат следующие понятия:
1). объект – информационный, материальный или финансовый объект, используемый в бизнес-процессе (например, письмо, оборудование, счет);
2). событие – внешнее (не контролируемое в рамках процесса) действие, произошедшее с объектом (скажем, получение письма, поломка оборудования, получение счета);
3). операция – элементарное действие, выполняемое в рамках рассматриваемого бизнес-процесса (допустим, подготовка письма, ремонт оборудования, оплата счета);
4). исполнитель – должностное лицо, ответственное за выполнение одной или нескольких операций бизнес-процесса (к примеру, менеджер, механик, бухгалтер).
Взаимосвязь между базовыми понятиями технологии Workflow отражены на концептуальной информационной модели, представленной на рис. 3.10.
В рамках этой модели ПРОЦЕСС состоит из ОПЕРАЦИЙ. Каждая ОПЕРАЦИЯ адресуется своему ИСПОЛНИТЕЛЮ, который, в свою очередь, отвечает за выполнение одной или нескольких ОПЕРАЦИЙ. ОБЪЕКТЫ участвуют в выполнении ОПЕРАЦИИ. СОБЫТИЯ могут влиять на выполнение ОПЕРАЦИЙ, например, изменяя результат операций или последовательность их выполнения.
Каждая система класса Workflow обеспечивает решение трех задач:
1). разработка описания бизнес-процесса;
2). управление выполнением бизнес-процесса;
3). интеграция используемых в процессе приложений.
Соответственно этим задачам в составе технологии Workflow можно выделить типовые компоненты и проанализировать связи между ними.
Инструментальные средства описания процесса предназначены для формирования формального описания процесса в виде упорядоченного множества операций, правил их выполнения, связанных с ними объектов, исполнителей и событий. Полученное описание (спецификация) процесса используется для контроля и управления выполнением процесса на основе поступающих в систему данных. В качестве этих данных выступают информация, введенная пользователями, результаты выполнения отдельных операций, информация от прикладных систем и баз данных.
В свою очередь, средства управления выполнением процесса предоставляют пользователям и/или прикладным программам информацию, необходимую для выполнения каждой операции в условиях интеграции приложений, а выявленные на этапе выполнения операций несоответствия служат основанием для пересмотра спецификаций бизнес-процессов.