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

Первые разработки АСУ в 50-70-х годах проводились по принципу концентрации вычислительных мощностей на центральных ЭВМ и звездообразной топологии подключения терминалов, системы были монолитными, и модули взаимодействовали друг с другом средствами ОС и языка программирования. ПК и «офисные» программы стали базой для создания АРМ благодаря понятиям «рабочего стола» и «персонализации». С распространением локальных сетей они стали способны решать также задачи малого бизнеса и уровня подразделения. Успешной попыткой совмещения достоинств централизованных систем и ПК стало появление архитектуры клиент-сервер. Двухзвенные системы клиент-сервер целиком полагались на интеграцию вокруг данных — распределение функций между подсистемами строилось по принципу разделения ответственности за данные путем ограничения доступа к ним. Интеграция решалась технически — за счет механизмов репликации данных, однако зависимость от относительно статический структуры данных сдерживала развитие. Переход систем класса ERP/MRP на трехзвенную архитектуру был обусловлен как масштабируемостью среднего звена, так и предоставляемым на уровне сервера приложения механизмом взаимодействия программных компонентов. Производители корпоративных решений стали ориентироваться на поддержку программных интерфейсов для интеграции со сторонними системами, к примеру, SAP предоставляет доступ внешним программам через BAPI-интерфейс и поддерживает обмен данными в форматах EDI, iDocs и XML.

Несмотря на появившиеся возможности масштабирования, острой осталась проблема совместимости — даже внутри решения от одного производителя нет единой платформы интеграции, и в большинстве своем идет простой обмен данными в пакетном режиме либо разделение доступа к общим таблицам и представлениям БД, а требуется взаимодействие на оперативном уровне, фактически, в режиме реального времени, к примеру, ERP/MRP с АСУТП.

Аналогичная ситуация сложилась и в сфере аналитических систем, где приходится разрабатывать низкоуровневые модули импорта «сырых» данных непосредственно из БД или путем разбора форм отчетности на агрегированном уровне. Применение специализированных OLAP-средств и аналитического инструментария типа Oracle Discoverer, Cognos, Business Objects, Hyperion, Ascential, Brio возможно только при ручной настройке алгоритмов извлечения данных. В итоге либо приходится пользоваться просто универсальными генераторами отчетов типа Crystal Reports и Actuate, либо делать сложные стыковочные модули, как предусмотрено в CRM-решениях Siebel, Pivotal и Onyx для стыковки с аналитическим блоком E.Piphany.

Эффективное использование систем управления документами или электронного документооборота связано с их полноценным внедрением в информационные системы учетного и фактографического характера. Индексирование документов, классификация, определение списка контроля доступа и разграничение прав авторства в таком случае должно производиться в контексте предметной области, что требует интеграции с прикладными подсистемами: ERP, CRM и др. К примеру, Documentum 4i включает коннекторы eConnectors к SAP и Siebel. С другой стороны, поддержка совместной работы над документом требует встраивания или подключения системы управления процессами, что позволяет выполнять предопределенную и динамическую маршрутизацию документов, назначение исполнителей, отслеживание статуса документа и т.д.

Проблемы развития информационных систем

Перед создателями современных информационных систем стоят следующие задачи:

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

Если первые два типа задач решаемы с технической точки зрения благодаря стандартам, то последний пункт требует концептуальных изменений в модели информационной системы масштаба предприятия, а именно обеспечения: сквозных бизнес-процессов; единого пользовательского интерфейса (портала); общего информационного пространства. Если даже центральный сервер баз данных способен поддержать работу интегрированной системы, то невозможно обеспечить единую структуру общей базы данных, если компоненты системы разрабатываются разными командами разработчиков. Остается проблема логической целостности данных, гарантии правильной работы с разделяемыми данными.

Противоположный подход — поддержка большого числа разнородных баз данных, расположенных на разных компьютерах требует регламентации и реализации процессов синхронизации данных, унификации справочников и правил кодирования, оставляя нерешенной проблему автоматического продолжения процесса. Построение децентрализованных систем, когда связи обеспечиваются доступом модулей к базам данных других модулей, либо программными вызовами одних модулей другими, приводит к проблеме большого числа взаимосвязей. Разработки одних модулей попадают в зависимость от процесса разработки других, изменения любого из модулей чревато несовместимостью при работе с зависимыми компонентами. Очень сложно отследить вызовы функций, передачу данных и т. д. Правда, при таком построении появляется гибкость организации взаимодействия модулей, возможность автоматического продолжения процесса между модулями, на стыке подсистем. Понятно, что модули должны быть разработаны по единой спецификации или поддерживать определенные стандарты, например, декларированные интерфейсы, чтобы обращаться к внешним приложениям. В таблице 1 приведены все существующие на данный момент модели архитектур интегрированных систем.

Таблица 1. Существующие модели архитектуры информационных систем

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

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

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

Для работы в распределенной гетерогенной среде активно разрабатываются спецификации Web-служб, каждая из которых может реализовать одну или несколько бизнес-процедур или функций. Ассоциация OASIS, BPMI и компании IBM, Microsoft и BEA опубликовали спецификации регулирования потоков работ в рамках бизнес-процессов BPEL4WS (Business Process Execution Language for Web Services), языки XLANG и WSFL (Web Services Flow Language), а коалиция WfML предложила XPDL (XML Process Definition Language).

Примером успешного объединения протокола и формата является SOAP — протокол взаимодействия программных компонентов поверх сетевого протокола HTTP при помощи XML независимо от платформы, среды, средства разработки и пр. Применяя технологии порталов можно объединять в комплексную Web-страницу формы пользовательского интерфейса нескольких Web-служб, обеспечив необходимую взаимосвязь между ними, обновляя данные в одном фрагменте в зависимости от навигации в другом, например: Oracle9i AS Portal Server, IBM WebSphere Portal Server, Plumtree Corporate Portal, Microsoft Digital Dashboard. Специализированные порталы поставляются разработчиками ERP (Sap Portal Server с iView), CRM (BroadVision и Vignette), DMS (Hummingbird Enterprise Portal, Documentum Portal) и др.

Модель архитектуры информационной системы

В теории управления предприятием обычно рассматриваются способы организации системы управления вокруг:

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

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

Архитектура информационной системы управления предприятием

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

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

Ядром должна быть система управления процессами, совмещающая несколько функций: Workflow, Docflow, Groupware и Dataflow. Таким образом, технологические данные, генерируемые техническими устройствами, фактографические данные, вводимые в ИС пользователями на рабочих местах, а также данные, формируемые программными приложениями, будут вноситься в систему управления предприятием и доступны потребителям информации в оперативном режиме.

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

Процесс может оперировать данными различных типов: элементарные типы (число, строка, дата), сложные форматы и структуры данных, а также прикрепленные объекты и файлы Word, Excel, AutoCAD, JPEG и т.д. Весь комплект данных, которые маршрутизируются в процессе, должен быть описан посредством XML с внедренными файлами, OLE-объектами и бинарными приложениями. Таким образом, документы получат конкретную реализацию — XML-документа со структурой, описанной при помощи DTD/XDR для одной карты процесса или нескольких карт.

Вызовы внешних компонентов должны быть реализованы традиционными средствами ОС и языков программирования, что позволит интегрировать унаследованное программное обеспечение и эксплуатирующиеся приложения, а также при помощи компонентных технологий COM/DCOM, .Net, CORBA, Java RMI, EJB/J2EE. Чтобы обеспечить поддержку разных платформ и распределенную среду Internet, рекомендуется применять протокол SOAP. Для того чтобы позволить сопровождающему программисту легко построить карту процесса, документооборот должен быть снабжен графическим редактором. Язык и визуальные примитивы можно выбирать любые, однако лучше использовать прошедшие практическое применение нотации типа SDL.

С точки зрения конечных пользователей, информационная система формирует им список заданий и обеспечивает работу с документами. Конкретные АРМ должны быть организованы в виде папок документов, к примеру. «Входящие», «Исходящие», «Взятые на исполнение», «На подпись», «В банк» и т.д. Список наименования и содержания папок, доступных каждому сотруднику, должен настраиваться и формироваться в соответствии с его должностью, отделом, ролью и функциями. Документы, или задания, могут быть отсортированы, отфильтрованы, сгруппированы и классифицированы иными способами по приоритетам, срокам исполнения, типам задач, связям с функциональными модулями и т.д.

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

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

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

Доступ к макетам отчетов и OLAP-настройкам должен быть вынесен за рамки функциональных подсистем, реализован в виде портала со своей логикой навигации и правами доступа. Отчеты будут запускаться на формирование либо пользователями на АРМ, либо автоматически системой документооборота на сервере.

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

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

Передача данных между прикладными приложениями и функциональными подсистемами осуществляется следующими способами:

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

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

Портал предоставляет доступ всем потребителям к информационным ресурсам предприятия через Сеть. Портал формирует АРМ для сотрудника в соответствии с его позицией в подразделении и ролью в бизнес-процессах.

Рис. 2. Взаимосвязи подсистем

Фундаментом интегрированной системы (рис. 2) является корпоративная сеть, объединяющая локальные сети подразделений и обеспечивающая доступ к информационной системе через Internet сотрудникам и партнерам. Следующий уровень — системное ПО (серверы приложений, Web-серверы, СУБД, хранилища документов, OLAP-средства, хранилища и витрины данных, и другие составляющие программной платформы. Далее следует ядро (система управления процессами, документооборотом), интегрирующее функциональные подсистемы, которые, в свою очередь, расположены уровнем выше. Документооборот и прикладные подсистемы базируются на системных уровнях и образуют слой оперативного управления и тактического планирования. Уровень отчетности и аналитического инструментария, оперируя данными всех подсистем, помогает руководству решать стратегические и тактические задачи. Замыкает пирамиду Web-портал, обеспечивающий взаимодействие с пользователями, составляющий АРМ на базе всех компонентов системы.

Если рассматривать рис. 2 слева направо, то можно проследить взаимодействие компонентов. В отличие от трехзвенных систем, где Web-сервер и сервер приложений совмещены, здесь необходимо выделить Web-сервер, который формирует АРМ, принимая запросы клиентских машин, формируя в ответ Web-страницы в соответствии с правилами системы (единый пользовательский интерфейс) и пользовательскими настройками (персонализация). Навигация по списку заданий и документов осуществляется обращением к компонентам документоборота и хранилища. Формы заданий, содержимое документов и их визуальное представление определяется настраиваемыми таблицами XSL/CSS. Сами данные передаются в формате XML.

Все программные компоненты должны поддерживать декларированный набор интерфейсов (системных и относящихся к предметной области), чтобы обеспечить совместимость независимо от производителя, версий, средства разработки, реализации и других факторов. Спецификации интерфейсов на языке IDL должны быть разработаны и опубликованы авторитетными объединениями производителей, организациями, занимающимися стандартизацией или, к примеру, экспертными группами по отраслям. Для передачи самих данных из одной подсистемы в другую необходимо стандартизировать форматы передачи, используя язык разметки XML, а для преобразования — XSL/XSLT.

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

Рис. 3. Взаимодействие подсистем

Компоненты могут вызываться не только из «локальной» информационной системы, но и из информационных систем других предприятий, из систем B2B и т.д. Обращения могут идти как непосредственно к интерфейсам компонентов, так и к Web-серверам с последующей переадресацией вызовов к серверам приложений. В этом контексте важно вернуться к этапу проектирования системы, первым шагом которого должна быть декомпозиция системы на подсистемы, и далее на модули вплоть до программных компонентов таким образом, чтобы максимально снизить взаимную зависимость.

Заключение

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

Артак Оганесян (ArtakO@moscow.vdiweb.com) - руководитель проекта компании Vested Development.

Системы управления рабочими процессами

  • Ориентированные на задачи (workflow) - автоматизация работы всех исполнителей по разным задачам (Staffware).
  • Ориентированные на рабочую группу (groupware) - автоматизация работы коллектива исполнителей с разделением доступа и совместным использованием общей информации без структуризации и правил, обмен сообщениями, свободная маршрутизация (ad hoc routing), ведение разделяемого графика работ и календаря, (Lotus Notes и Microsoft Exchange).
  • Ориентированные на документ (docflow) - автоматизация работы исполнителей по маршрутам обработки документов в соответствии с их видом и настройками, зависящими от состояния документа и статуса исполнителя (встроенные в СУД и автономные системы типа 4i/Workflow от Documentum, CyberRouting от Hummingbird и WorkDoc от iManage).
  • Ориентированные на обмен данными и доставку сообщений (message queue) - это cистемы очередей сообщений и их гарантированной доставки между предприятиями и программными системами, к примеру, MQSeries (IBM) и MSMQ (Microsoft).
  • Ориентированные на интеграцию приложений (EAI - Enterprise Applications Integration) - системы, предназначенные для обеспечения обмена данными между системами в масштабах предприятия (TIB/InConcert от TIBCO и WebSphere MQSeries Integrator от IBM, а также специализированные пакеты SeeBeyond, WebMethods, Vitria).
  • Ориентированные на типовые процедуры - регламент определенных действий и обязанностей (подобные системы встраиваются в решения ERP и CRM, например, Oracle Workflow или Siebel Workflow).

По мере внедрения ИТ в управление экономическими структурами системы управления процессами стали применяться в более широком смысле и превратились в инструменты описания «политики» предприятия, формального определения правил ведения хозяйственных, административных, технологических процессов в производственной и коммерческой деятельности. Активно ведутся разработки стандартов описания и выполнения бизнес-процессов, среди них BPEL4WS, WSCI, BPML, XMDL от организаций W3C, WfMC и BPMI.

С начала 90-х годов системы управления рабочими процессами стали рассматриваться также как системы управления бизнес-процессами, что отразили в «Манифесте революции в бизнесе» Майкл Хаммер и Джеймс Чаплин в 1993 году, представив теорию реорганизации деловых процессов (BPR — Business Processes Reengineering) посредством обследования организационной структуры, функций подразделений и отдельных сотрудников, взаимодействие которых представляется в виде деловых процессов и далее оптимизируются при помощи возможностей ИТ. Речь идет не только об оптимизации внутренних для предприятия процессов (традиционные ERP), но и внешних, связанных с заказчиками, партнерами, потребителями, а также потенциальными клиентами. Внедрение CRM-решений выдвигает высокие требования по интеграции приложений перед предприятием, поскольку необходимо предоставить CRM-системе оперативный доступ к данным различных функциональных подсистем. Например, ключевым расширением версии Siebel 7.5 является UAN (Universal Application Network) для взаимодействия с внешними приложениями, а также интерфейсов ASI (Application Service Interface) для предоставления Web-служб электронной коммерции.

Фактически, процессы выходят за рамки предприятия. Системы B2C и B2B, электронные торговые площадки (eMarketplace), электронная коммерция и SCM (Supply Chain Management) позволяют продавцам и покупателям, поставщикам и потребителям, партнерам встречаться и совершать сделки в Сети, при этом требуется интеграция приложений не только внутри организаций, но и между ними. На первое место вышли форматы обмена данных на основе XML (SOAP, xCBL, cXML, UDDI), разработанные независимыми группами OASIS, CommerceNet, W3C и др. На XML переводится даже EDI и его клоны типа EDIFACT и X12.

Платформа Microsoft BizTalk отражает тенденцию и включает Orchestrator — модуль управления процессами и Map Editor — редактор карт преобразования типов данных, и оба они оперируют XML/SOAP. Идея состоит в том, чтобы визуальными средствами спроектировать технологический процесс движения данных от одного приложения к другому со всеми необходимыми преобразованиями. Другие решения: WebMethods, Vitria, TIBCO, SeeBeyond пошли еще дальше и поддерживают уже не только XML/SOAP, но и EJB/J2EE, UDDI, WSDL и другие открытые стандарты. Способность IBM MQSeries работать в различных аппаратных и операционных средах позволяет простроить кросс-платформное решение на базе WebSphere Business Integrator.

Разработка CRM-системы Pivotal eRelationship

С февраля 2000 года автор статьи руководит проектом разработки CRM-системы eRelationship по заказу корпорации Pivotal Software (Канада). В ходе проекта было предложено разработать модули управления процессами (Workflow Engine) и интеграции с внешними приложениями (Integration Engine).

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

Модуль управления процессами применяется для настройки логики обработки и преобразования данных. Сам модуль интеграции построен на базе SOAP/XML и может выступать адаптером к BizTalk Server.

Экономический эффект реализации этих проектных решений выражается в снижении стоимости работ по интеграции eRelationship в существующую инфраструктуру компаний, в частности, интеграции с ERP-системами SAP, Oracle и J.D. Edwards, что раньше было основным препятствием внедрения системы на крупных предприятиях.

Интеграция информационных систем «Совинтел» и «Телеросс»

В 2001 году руководством международного телекоммуникационного холдинга Golden Telecom после приобретения контрольного пакета акций «Совинтел» было принято решение о слиянии «Совинтел» и «Телеросс». На российском рынке образовался самый крупный коммерческий оператор цифровой и аналоговой связи.

Различия в аппаратных и программных платформах, средствах разработки и принципах построения информационных систем, эксплуатирующихся в «Совинтел» и «Телеросс», стали препятствием к осуществлению корпоративных целей. Требовалось, например, интегрировать пять разных систем, отвечающих за биллинг в региональных сетях, охватывающих десятки регионов. Объединенной компании пришлось отвлечь значительные средства на интеграцию информационных инфраструктур.

В ходе обследования инфраструктур объединяющихся компаний, проведенного проектной группой в 2001-2002 годах, были изучены десятки приложений, автоматизирующих различные аспекты деятельности телекоммуникационной компании: собственные разработки и заказные программы. По итогам обследования были составлены карты ИТ-инфраструктур, на базе которых, а также имевшихся на предприятии описаний бизнес-процессов, были разработаны требования к информационной системе объединенной компании, концепция и стратегия развития, архитектура информационной системы и план перехода к ней. В ходе обследования были выявлены также типичные проблемы, обусловленные исторически сложившимися причинами: прямые обращения программ к базам данных друг друга, обмен данными через внешние файлы, централизация новых трехзвенных разработок вокруг сервера приложений и общей базы данных; различия в платформе «ТелеРосс» и «Совинтел» (Windows и Sun Solaris, SQL Server и Oracle, Oracle Developer/Java и Visual Studio).

В ходе разработки концепции были предложены следующие решения:

  • выделенная интеграционная шина для обмена данными;
  • внедрение CRM-системы для обеспечения единого подхода в работе с клиентами и представлением сводной информации о клиенте, собранной через шину;
  • расширение эксплуатирующейся в "Совинтел" workflow-системы для управления процессами в объединенной компании;
  • создание Web-портала для технических служб объединенной компании с целью унификации АРМ и пользовательского интерфейса всех приложений.

Предложенная архитектура информационной системы объединенной компании разделена на несколько уровней (рис. 4), самый низкий из которых составляют системы сбора первичных данных о звонках и трафике от оборудования (так называемые mediation-системы). На следующем уровне расположены системы внутренней автоматизации: биллинг и управление ресурсами предприятия. Автоматизация рабочих процессов, документооборот и CRM-система формируют АРМ сотрудников предприятия. Данные между подсистемами передаются через шину с преобразованием в XML для универсальности и однозначной структуризации.

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