Что означает интегрированность ит
ТЗ на интеграцию информационных систем: 5 главных вопросов аналитика
Системные и бизнес-аналитики довольно часто участвуют в проектах интеграции информационных систем. Сегодня рассмотрим, с чего начать предпроектное исследование, чтобы успешно разработать требования к интеграции и оформить их в виде технического задания (ТЗ) по шаблонам российских ГОСТ’ов (34.602-89 и 19.201-78) или международных стандартов спецификации. Также разберем, чем пакетный парсинг отличается от потоковой передачи событий и каковы сложности интеграции нескольких информационных систем с разными моделями данных.
Что такое интеграция информационных систем: краткий ликбез для бизнес-аналитика
Когда речь идет об интеграции информационных систем (ИС), под этим подразумевается односторонняя передача или взаимный обмен данными, которые в них хранятся. Выполнять такую передачу или обмен данными будет программное обеспечение (ПО), внешнее по отношению к связываемым информационным системам, или внутренние компоненты их самих. Как именно это будет происходить, решает ИТ-архитектор или ведущий разработчик, который отвечает за техническое решение. Чтобы корректно разработать требования к реализации такого ПО, аналитик должен понимать ключевые аспекты интеграции, которые мы и рассмотрим далее. С учетом современной тенденции российского (и не только) рынке к слиянию ролей системного и бизнес-аналитика, такой краткий ликбез по интеграции информационных систем пригодится начинающим специалистам обеих профессий. Итак, разработать требования к интеграции помогут точные ответы на следующие 5 вопросов.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
Ближайшая дата курса
Длительность обучения
12 ак.часов
Стоимость обучения
20 000 руб.
Зачем?
Поскольку любое исследование в бизнес-анализе начинается с определения потребности, неудивительно, что «Зачем?» — это первый вопрос при интеграции ИС. Зная ответ, аналитик сможет определить полезность и нужность, т.е. ценность интеграции для бизнеса: решает ли она реальную проблему и действительно ли эту проблему стоит решать. Например, сотрудники компании тратят 2 часа рабочего времени на внесение данных из одной информационной системы в другую. Зная количество этих сотрудников и их почасовую ставку, нетрудно рассчитать экономию от автоматической передачи данных между разными системами. Это и будет ценность интеграции в денежном выражении. Сопоставив потенциальную выгоду интеграции с затратами на ее реализацию, можно сделать выводы о периоде окупаемости интеграционного решения и его целесообразности. Подробнее о бизнес-проблемах, их причинах и следствиях мы говорили в прошлой статье.
Кроме того, понятные ответ на вопрос «Зачем нужна интеграция ИС» поможет определить сценарии обмена данными между ними, причем как в плане бизнес-процессов, так и с технической точки зрения. Иначе говоря, «Зачем?» является главным и первым вопросом аналитика в любом проекте, позволяя определить дальнейший путь выявления требований к решению и ключевые аспекты его реализации. В техническом задании на разработку ПО для интеграции информационных систем или спецификации требований ответ на вопрос «Зачем?» располагается во введении или разделах, которые описывают назначение и цели создания программного продукта.
Сколько?
Хотя главным вопросом для бизнеса являются деньги и то, что с ними связано, здесь речь идет не о стоимости интеграционного решения, а о том, какое количество ИС необходимо связать между собой. Если нужен обмен данными между всего 2-мя «коробочными решениями», а бизнес не планирует строить полноценную инфраструктуру данных, добавляя десятки специфических ИС для поддержки различных процессов и направлений деятельности, то границы проектируемого интеграционного ПО могут располагаться внутри 2-х связываемых систем. Когда речь идет о создании корпоративной дата-магистрали, к которой подключено много ИС, при разработке ТЗ аналитику нужно тщательно проработать требования к внешним интерфейсам, которые будут обеспечивать многосторонний обмен данными.
На основании этих требований и особенностей самих связываемых систем ИТ-архитектор принимает решение о модели интеграции. Например, это может быть общая шина предприятия (ESB, Enterprise Service Bus) с очередью сообщений, набором коннекторов к источникам и приемникам данных, а также объединяющей программной платформы. Или реализация CDC-подхода, когда с помощью триггеров отслеживаются и обрабатываются изменения в базах данных прикладных систем (Change Data Capture), сливаясь в единое корпоративное хранилище (DWH, Data WareHouse). Или же обмен данными по запросу через удаленный вызов процедур из одной системы и обращение к конечной точке другой методами RESTful-API. Подробнее о способах интеграции ИС с технической точки зрения мы поговорим в следующий раз. А пока отметим, что при разработке ТЗ или спецификации требований информация о количестве связываемых ИС и их архитектурных особенностях будет отражена в разделе «Ограничения дизайна и реализации».
Какие данные?
Этот вопрос касается структуры данных, которыми будут обмениваться связываемые системы. Каждая ИС имеет свою модель данных – чаще всего она является реляционной, где информация структурирована в связанные таблицы. В реляционной модели каждая таблица имеет заранее определенное количество столбцов для хранения данных конкретного типа: целочисленных, символьных и пр. Некоторые СУБД поддерживают не только реляционную парадигму – они называются NoSQL и хранимые в них данные могут иметь различную структуру, например, как JSON-файл со множеством ключей. Поскольку каждая ИС имеет свою уникальную модель данных, интеграция – это не просто передача записей (или значений отдельных полей) из одной таблицы в другую. Поэтому в функциональных требованиях к интеграционному решению аналитик указывает, какие данные будут передаваться, в каком виде они изначально хранятся в источнике и как будут ложиться в приемник. При этом в функциональные требования также включается преобразование значений, например, приведение к единообразной форме отображения адресов, личных данных клиентов или названий предприятий.
Например, в одной системе адрес хранится в одном поле таблицы строкового типа, а в другой – разбит на несколько отдельных полей с разными типами данных: индекс, область, город, улица, номер дома, корпус, квартира. В этом случае интеграционное решение будет выполнять синтаксический анализ (парсинг) исходных данных, чтобы выделить разные значения из единой строки и записать их в различные поля модели данных системы-приемника. Аналогичный парсинг будет выполняться и для сложных типов данных в случае интеграции нескольких систем, например, при разборе сообщений, хранящихся в очереди корпоративной ESB-шины. Описать данные, которыми будут обмениваться интегрируемые системы, а также сопоставить компоненты одной модели данных и другой поможет техника под названием «Словарь данных», которую мы недавно разбирали здесь. В дополнение к этому будет полезно показать источники и приемники данных с процессами их преобразования. Сделать это можно с помощью диаграмм потоков данных (DFD, Data Flow Diagram), которые мы разбирали в этой статье.
Чем опасна интеграция IT-решений, и как минимизировать связанные с ней риски
Интеграция часто становится своеобразным фетишем для руководства компаний при наведении порядка в IT. Евгений Любимов предостерегает – такой подход может привести к необходимости дорогостоящих изменений бизнес-процессов.
Обычный путь российской компании средних размеров – начать автоматизацию управления с бухгалтерии, отдела кадров и документооборота, затем перейти к производственным и коммерческим бизнес-процессам. Наконец, возникает большой соблазн получить абсолютно интегрированную систему, которая объединит все в «единое информационное пространство».
Конечно, не существует общих рекомендаций по выбору уровня интеграции. Руководство каждой компании самостоятельно решает этот вопрос, исходя из своих потребностей и ресурсов. Статья о том, что риск вынужденной реорганизации бизнеса в связи с внедрением интеграционных решений не «сопутствующий», а достаточно высокий. Настолько высокий, что его нужно учитывать в качестве основного.
Что дает интеграция
Традиционные методики расчета эффекта от автоматизации известны многим руководителям и являются основными аргументами при выделении бюджетов. Сложность заключается в том, что рост эффективности автоматизации «глохнет» на стыках, при обмене информацией между подразделениями.
При отсутствии интегрирующего программного обеспечения используются «древние технологии» вроде распечаток на бумаге с повторным вносом данных, экспортом/импортом через электронные таблицы или «лоскутные» решения. Обмен данными становится самым узким участком и определяет общую производительность IT в рамках предприятия. Поэтому, с точки зрения экономики, подход к обоснованию актуальности интеграции между подразделениями почти идентичен обоснованию автоматизации подразделений. Цель – повышение эффективности.
Однако, стоимость интеграции зачастую выше стоимости автоматизации. Поэтому может оказаться, что интегрированные IT-решения невыгодны экономически. Для малых предприятий интеграция почти всегда убыточна, средний бизнес балансирует на пределе окупаемости интеграционных проектов, и только в крупном бизнесе интеграция дает существенные технологические преимущества.
На практике построение единой, высоко интегрированной КИС (корпоративной информационной системы) часто становится самоцелью для IT-специалистов, вне зависимости от масштаба компании, ее бизнес-целей и экономической целесообразности. В IT-сообществе польза высокоинтегрированных КИС редко подвергается сомнению. И зря, потому что их эффективность сильно зависит от контекста.
Интеграционные технологии
По сути, в IT есть два основных подхода к интегрированию:
1) Монолитные информационные системы.
2) Интеграционная шина предприятия.
Термин «монолитные ИС» применяется для систем с широким перечнем функций (почти ERP), но все же ограниченных сферой применения среднего бизнеса. Технически проблем с интеграцией в них не существует, благодаря использованию единой базы данных, в которой хранится абсолютно вся информация. Примерами таких систем являются решения на платформах 1С, «Галактика».
Монолитные системы обладают рядом недостатков, связанных с обновлением и скоростью работы. Кроме того, не все компании, выросшие из малого бизнеса, готовы отказаться от годами развиваемых собственных ИС и внедрить «чужое» монолитное ПО.
Интеграционная шина позволяет наладить обмен данными между различными ИС и создать централизованное хранение для всех справочников. Технология интеграционной шины может быть внедрена самостоятельно или приобретена в составе готовых IT-решений SAP, Microsoft и других разработчиков, предлагающих автоматизацию для крупного бизнеса. Наличие интеграционной шины решает техническую IT-задачу интеграции, но не обеспечивает интеграции бизнес-процессов. Если в случае с монолитными системами такой задачи не существует, то при связывании различных ИС с помощью интеграционной шины нужно самостоятельно проектировать систему справочной информации (проще говоря, единую базу данных), разрабатывать процедуры записи и обновления информации и т.д. Все это весьма трудоемко и как следствие дорого – что наверняка не подходит ни малому, ни среднему бизнесу.
Уровни интеграции
Интеграция может рассматриваться как механизм передачи информации в сквозном бизнес-процессе с участием нескольких подразделений. Технически возможны следующие варианты:
1) Подразделения используют единую КИС, единые справочники и документы. Это означает, что интеграция полностью выполнена.
2) Автоматическая интеграция – когда ИС без участия человека синхронизируют справочники и документы с использованием сервисной шины предприятия и подсистемы НСИ (нормативно-справочной информации).
3) Автоматизированная интеграция – когда автоматически синхронизируется справочники, а документы переносятся с участием сотрудников.
4) Полуавтоматизированная интеграция – справочники и документы переносятся с участием сотрудников.
5) Ручная интеграция – информация распечатывается и заново вносится в другую ИС.
Трудозатраты, связанные с переносом данных, растут от пункта 1 к пункту 5. Соответственно, замедляются сквозные бизнес-процессы между подразделениями. То есть первые варианты – лучшие с точки зрения IT и de facto являются стандартом построения интегрированной КИС. С другой стороны, они же являются самыми дорогими. Причем не только по внедрению. В худшем случае автоматическая интеграция может привести к структурным противоречиям.
Интеграция против организационной структуры
При формировании организационной структуры сильно связанные функции группируются в рамках подразделений. Понятие связности, взятое из теории структурного программирования, показывает, насколько задачи зависят друг от друга. Это может быть функциональная или информационная связь, временная или логическая и т.д. Связность задач внутри подразделения всегда выше связности задач между подразделениями.
При построении структуры бизнес-процессов связность также является основополагающим фактором. Бизнес-процесс может начинаться с поступления сырья и заканчиваться за воротами предприятия, но в таком длинном (сквозном) виде он будет неудобочитаем. Поэтому его разбивают на подпроцессы, руководствуясь связностью. Таким образом, именно связность между задачами определяет, как происходит разбиение сложной системы на подсистемы и формирование структур.
Интеграция высокого уровня меняет связность между задачами, что приводит к необходимости реорганизации структур.
При отсутствии интеграции передача информации между подразделениями происходит через руководителя подразделения в ручном или автоматизированном режиме. На практике руководитель делегирует задачу передачи информации, но сути это не меняет. Подразделение владеет информацией, полностью отвечает за релевантность и целостность, контролирует ее передачу наружу.
Благодаря интеграции обмен данными между подразделениями существенно ускоряется, поэтому можно классифицировать такое взаимодействие как сильно связное. Подобная связность больше, чем внутри подразделения, так как отсутствует какой-либо контроль со стороны подразделений. Сложно однозначно определить, кто владеет общей интегрированной ИС двух подразделений, необходимо дополнительно проговаривать и контролировать данный вопрос.
Итак, интеграция перекраивает организационную структуру и перестраивает бизнес-процессы – что вызывает недовольство у руководителей подразделений. Вынужденная перестройка организационной структуры плохо управляема, сложна, и непонятно будет ли вообще полезной для организации. Поэтому иногда лучше специально понижать уровень интеграции, переводя ее в ручной режим управления.
Владение справочниками
Если в ситуации до интеграции у каждого подразделения свои данные в ИС, то в ситуации после картина кардинально меняется. Как правило, документы, хранящиеся в ИС подразделений и передаваемые в рамках интеграционного обмена, описывают факты хозяйственной деятельности и привязаны к бизнес-процессам. Не возникает проблем с тем, кто изменил документ, системы четко фиксируют все изменения, в рамках бизнес-процесса всегда ограничены возможности сотрудника изменять документ.
В ситуации со справочниками ситуация более сложная. Функция контроля за ведением справочников, корректностью ввода, отсутствием дублей должна быть закреплена за кем-то особо. То есть владение справочником является еще одним атрибутом «власти». Полномочия по справочникам не должны идти вразрез с организационной структурой.
Например, IT в малом российском бизнесе, как правило, начинается с автоматизации бухгалтерии и кадрового учета. Финансовое руководство логично становится владельцем всех информационных баз компании. Затем, когда компания растет до уровня среднего бизнеса (что может происходить довольно быстро, за считанные годы), появляется полноценная IT-служба. Ее руководитель, избегая лишних согласований и конфликтов с «финансистами», обычно создает параллельную структуру пользователей, номенклатур, контрагентов.
Стратегия интеграции
Фактически, существует всего три стратегии построения единой КИС:
1) Внедрение готовой интегрированной КИС. Путь технологически наиболее правильный, сулящий максимальный эффект – и самый затратный. Подходит для крупного бизнеса, когда наведение порядка производится «любой ценой» (можно и без кавычек).
2) Поэтапное построение КИС с единой базой справочников. Это ловушка, в которую попадает большинство компаний из самых лучших и, на первый взгляд, здравых предпосылок. Опасность заключается в катастрофической недооценке рисков централизации справочников. По сути, проект изначально не «айтишный», поэтому выполнить его в рамках IT невозможно.
3) Поэтапное построение КИС с децентрализованной базой данных. Наиболее безболезненный и перспективный подход, так как он позволяет компании с помощью «лоскутной интеграции» постепенно созреть до уровня полноценного комплексного решения.
Можно смело сказать, что у растущего бизнеса выбора стратегии не существует. Начинать интеграцию следует только с третьего, самого «скромного» варианта. После достижения достаточно высокой степени заинтересованности и взаимопонимания руководителей на всех ключевых уровнях управления компанией можно сделать серьезный шаг и переходить ко второй стратегии; либо, при наличии достаточных ресурсов и резервов – к третьей.
Выводы
Руководство компании должно осознавать, что интеграция не относится к категории типичных IT-задач. Это дорогое удовольствие и зона ответственности топ-менеджмента. IT-сообщество часто манипулирует понятием интеграции, суля баснословный рост эффективности. В то же время IT-директора не способны брать на себя всю полноту ответственности за растущие издержки (вместо их оптимизации), особенно за необходимость изменения бизнес-процессов.
При решении задач интеграции нужно учитывать существующее распределение сфер влияния на бизнес-процессы, справочники и данные, которое отражается в организационной структуре. Нужно внимательно следить, чтобы слишком хорошая интеграция не перекраивала бизнес-процессы и в некоторых случая интеграцию намеренно «ухудшать», переходя на ручной режим управления.
Я не призываю отказаться от интеграции как таковой, всего лишь предлагаю внимательнее относиться к этому инструменту. Потребности в интеграции должны быть продиктованы руководством компании. Не стоит бежать впереди паровоза и внедрять чрезмерно перспективные решения.
Редактор рубрики «IT для бизнеса» – Сергей Соловьев
ИТ-интеграция – миссия выполнима
Время просмотра: 6.5 мин.
Прошло несколько лет, у нашего владельца уже 10 магазинов, 2 склада, недавно стартовали интернет-продажи. Конечно, с расширением бизнеса пришлось отказаться от Excel как средства учёта, однако отчётность всё равно готовится в нём… Почему же? Потому что для учета товара на складах так и используется уже значительно переделанная программа однокурсника, интернет-магазин был внедрён усилиями сторонней компании, бухгалтерия использует 1С, кадры выбрали решение известного производителя. И ни одно из этих решений «не знает» о существовании других. В итоге ИТ-отделу приходится каждый месяц осуществлять выгрузки из баз данных для бухгалтерии, которая затем неделю пытается свести эту информацию в хоть какую-то отчётность. А в это время владельцу интересно уже не только итоговое сальдо, ему хочется понимать, какие из его магазинов приносят прибыль, а какие – нет, какие товары лучше продаются, какие – хуже, и, в конце концов, кто его клиенты и как сделать так, чтобы они стали больше у него покупать?
Другие статьи автора
Статьи по теме
Поделиться
При всей «игрушечности» примера подобные проблемы рано или поздно встают перед практически любой организацией, будь то небольшая компания, средний бизнес или крупная корпорация. И чем крупнее компания, тем более комплексные задачи приходится решать ее ИТ-отделу. Отметим, что если задача интеграции информационных систем (ИС) в организации еще не стоит остро, но взаимодействие между ними уже должно быть автоматизировано, чаще всего на выходе будет ИТ-решение, во многом внедренное «спонтанно». К сожалению, для него не характерна системность подхода и в каждом конкретном случае задача интеграции решается, как сейчас модно говорить, ad hoc, что фактически каждый раз является «изобретением велосипеда».
Кроме того, на решение задачи интеграции оказывают влияние следующие факторы:
Как же в итоге решать задачу интеграции? Существует целый ряд средств и методов, которые позволяют реализовать задуманное. Их можно разделить на три основные группы, каждая из которых, в свою очередь, включает в себя разнообразные подходы и системы.
Первая группа – это решения для интеграции данных. Фактически подход к интеграции со стороны данных является одновременно и наиболее простым с точки зрения реализации, и наиболее многообразным относительно решаемых при этом задач. Это могут быть импорт данных в разнообразных форматах, их преобразование, очистка от ошибок, исключение дублирующих записей, обогащение, хранение, отображение и др. Ниже будут рассмотрены основные классы систем, непосредственно участвующих и обеспечивающих качественную интеграцию на уровне данных.
Вторая группа – это интеграция приложений. Если интеграция данных чаще применяется для построения хранилищ и аналитических систем, то этот подход главным образом позволяет строить распределенные корпоративные ИС, направленные на обработку оперативных данных. Интеграция приложений чаще всего реализуется с помощью обмена сообщениями и событиями между системами. За счет этого снимается необходимость ручного ввода данных в каждую из интегрируемых систем.
Третья группа – интеграция бизнес-процессов. Когда в организации уже налажены интеграционные взаимодействия между ИС и автоматизированы практически все информационные потоки, следующим этапом становится своеобразная «интеграция» людей-исполнителей и ИС. Выстраивается единая автоматизированная цепочка, в которой человек и «машина» выполняют свою часть работы, образуя эффективный бизнес-процесс.
Фактически рассмотренные нами группы представляют собой три последовательные ступени в процессе построения полноценной и эффективной интеграции. Мы начинаем с нормализации данных, затем налаживаем автоматизированное взаимодействие между приложениями и, наконец, организуем сквозные бизнес-процессы. Рассмотрим указанные группы и применимые в их рамках решения более подробно.
Интеграция данных
Практически в любой компании, независимо от рода ее деятельности, ведется учет информации о контрагентах, с которыми она взаимодействует, о товарах или услугах, которые она реализует, о контрактах, в рамках которых эти товары или услуги поставляются или закупаются. Представим, что это большая и территориально распределенная организация. Как правило, это означает наличие «зоопарка» ИТ-систем, различающихся в головном офисе и территориальных отделениях. В эти различные ИС сотрудники добросовестно заносят данные о клиентах компании. Однако одного и того же клиента могут внести в CRM, ERP и прочие учетные системы столько раз, сколько этих бизнес-приложений, собственно, насчитывается в организации. При этом оператор, вносящий информацию о новом клиенте, например, об «ООО Розмарин», в свою систему, зачастую может даже не знать о том, что его сосед по кабинету сделал то же самое, но в своем приложении. С одной оговоркой – у него новый клиент называется «Торговый дом Розмарин» или даже «Rozmarin Trade». Введенная таким образом информация будет успешно храниться в системах, обрабатываться и дополняться до тех пор, пока руководство не захочет получить консолидированную отчетность по клиенту «Розмарин». Похожая ситуация возникает, когда в разных филиалах торговой организации, имеющих один и тот же ассортимент продукции, номенклатура ведется в локальных системах и, разумеется, по-разному. Представьте себе, сколько возможных вариантов названий может быть, к примеру, у товара «кашпо декоративное керамическое “Весна”». А теперь представьте, как будет выглядеть ответ на запрос от коммерческого отдела: «Каков объем поставки кашпо “Весна” клиенту «Розмарин»?».
Разумеется, до некоторых пор вопрос можно решать организационно, как выдавая четкие инструкции операторам отдельных систем, так и создавая огромное многообразие матриц соответствий и таблиц перекодировок (этот вариант чуть более технологичен). Другой способ – ручное сведение данных в консолидированной отчетности, когда специально выделенный, к примеру, аналитик, метким взором оглядывая огромный отчет, ловко вылавливает из него всевозможные «Розмарины» и решает, один и тот же ли это клиент. Эти решения лишь на первый взгляд кажутся быстрыми, простыми и недорогими, но, к сожалению, они совершенно не приемлемы для крупных и быстрорастущих компаний.
Описанная задача является всего лишь одним из частных случаев применения систем класса MDM (Master Data Management) (подробнее – в статье «Мастерское управление данными», стр. 24). В действительности такие решения отвечают за огромный спектр задач, связанных с управлением основными данными, которые также часто называют эталонными данными или нормативно-справочной информацией (НСИ). Внедрение таких систем позволяет не только эффективно организовать процессы управления ими, обеспечив их актуальность и непротиворечивость, но и повысить качество данных, например, используя технологии их очистки (так называемое Data Quality). Используя определенные модели данных и алгоритмы их обработки, такие решения позволяют автоматически устранять определенные некорректности в данных, образовавшиеся, например, вследствие ошибок оператора. Вернемся к примеру с «Розмарином» и кашпо: возможным решением здесь могла бы стать так называемая дедупликация, которая также относится к классу задач Data Quality.
На сегодняшний день практически в любой организации возникает задача получения различного рода консолидированной отчетности, на основе которой умудренные опытом бизнес-аналитики делают выводы о текущих тенденциях бизнеса и принимают те или иные стратегические решения. Как правило, для получения подобного рода отчетности строятся громадные хранилища, в которые собираются данные из всех основных корпоративных ИС, будь то ERP, CRM или автоматизированная банковская система. Основой же для построения хранилищ практически всегда является система, которая, получая на вход данные в самых разных форматах, преобразовывает их в нужную форму и загружает в хранилище. И когда необходимо серьезное преобразование данных на их пути из одной системы в другую, на помощь приходит технология ETL (Extract, Transform, Load).
Однако сфера ее применения не ограничивается одними лишь хранилищами и BI. В качестве примера можно привести задачу расчета бонусных баллов. На данный момент в России достаточно популярны так называемые программы лояльности, участники которых являются обладателями специальных пластиковых карт. После того как владелец карты совершил покупки в определенных розничных и ресторанных сетях, на автозаправочных станциях и т.п., ему по различным схемам начисляются бонусные баллы.
Пример: абонентам одного из телеком-операторов, являющимся обладателями карт лояльности, полагаются бонусные баллы за оплату тех или иных услуг, например, минут разговора, отправленных SMS и MMS, интернет-трафика и т.п. Количество типов таких услуг и соответствующих алгоритмов начисления баллов – несколько десятков. Количество абонентов, имеющих карты лояльности, – десятки, а то и сотни тысяч. Совершенно очевидна необходимость системы, которая в автоматическом режиме выгружала бы данные об абонентах и предоставленных им услугах, рассчитывала бы баллы, полагающиеся каждому, и передавала бы их в учетную систему программы лояльности.
Нужно отметить, что исходные данные для расчетов находятся в нескольких БД, включая абонентскую базу и базу платежей. Алгоритмы расчета бонусов представляют собой наборы операций, сложность которых может быть совершенно разной – от простейших запросов к единственному источнику до сложной последовательности различных преобразований данных, полученных одновременно из нескольких систем, включая неограниченное количество условных переходов.
Эта задача может быть решена с помощью использования технологии ETL. Построенное решение по определенному расписанию будет запускать сложнейшие расчетные процедуры, в результате формируя данные по начисленным баллам. Более подробно о других решениях, построенных на базе этой технологии, вы можете прочитать во второй части – в № 1, 2013.
Как уже говорилось ранее, интеграционные задачи возникают практически при любом внедрении бизнес-приложений, но есть классы систем, в основе которых изначально лежит интеграционное решение. Примером здесь могут быть платформы класса ECM (Enterprise Content Management), ориентированные на обработку большого количества документов и любой неструктурированной информации, вплоть до аудио- и видеофайлов, а также данных из интернет-источников (более подробно – во второй части, в 1 1, 2013). В основе такого решения лежит хранилище, в которое посредством интеграции помещается информация любого требуемого типа. Перечислим некоторые виды такой интеграции. Во-первых, это сбор электронных документов из бизнес-приложений – контрактов, приказов и распоряжений, ордеров и т.п. К этому же типу задач можно отнести сбор в единое корпоративное хранилище электронных писем, отправляемых или получаемых сотрудниками. Во-вторых, это помещение в хранилище оцифрованных бумажных документов. В этом случае необходима интеграция со средствами сканирования и распознавания. И третий пример – это сбор информации из открытых источников, например, интернета. Представим себе сотрудника отдела маркетинга, ответственного за процесс формирования имиджа компании в СМИ. Одной из его задач является сбор данных об упоминаемости компании в различных источниках, в первую очередь в интернете. Ее решение может быть построено на основе автоматического сбора, структурирования информации по различным признакам (темам, авторам, источникам и т.п.) и ее помещения в единое хранилище. Совершенно очевидно, что такое решение требует интеграции с интернет-источниками.
Интеграция приложений
По вполне понятным причинам автоматизация исторически развивалась по пути наименьшего сопротивления – где болит, там и внедряем программное обеспечение, потому что результат нужен вчера, генеральный в гневе, клиенты уходят… Как ни банально это звучит, решение одной проблемы всегда вызывает к жизни две другие, не менее сложные. Внедрили «по-быстрому» системы в двух отделах – обнаружили, что в обеих реализован справочник клиентов. Прошло пару лет, и вот уже в компании создан отдел НСИ, а отчеты, сформированные из разных систем, противоречат друг другу. И с каждым годом получить достоверные цифры почему-то становится не проще, а сложнее.
Таким же путем шли и при интеграции – системы разрознены, так давайте научим их обмениваться информацией. И снова знакомая картина: чтобы получить данные о клиенте из двух разных систем, специалисты компании написали две процедуры на стороне «получателей». В результате при малейшем изменении сразу возникают проблемы. Нужно, во-первых, не забыть, кто является получателем, во-вторых, внести изменение во все зависимые системы. Здесь уместно вспомнить любимый анекдот ИТ-директора: «Работает? – Ничего не трогай!».
Итак, жизнь подтолкнула к появлению интеграционных шин, или ESB – Enterprise Service Bus. Теперь приложения получили возможность интегрироваться только с шиной и «не знать» о других системах. Как образно выразился один из наших заказчиков, «у нас появится шина, ощетинившаяся интерфейсами». Подробнее об интеграционных шинах и технических деталях их реализации читайте в статье «Дирижер в оркестре сервисов».
Интеграция бизнес-процессов
Менеджменту необходимо получать адекватные и достоверные данные для принятия управленческих решений, сотрудники хотят избежать рутины, да и просто гордиться тем, что работают в современной технологичной компании, где работа организована эффективно и позволяет сосредоточиться на своих задачах, а не продираться сквозь лес ИТ- и «не ИТ-» систем с их разрозненностью и другими несовершенствами. Речь идет о том, что, какой бы автоматизированной система ни была, для обеспечения эффективной работы бизнес-процессов необходимо, чтобы и она, и ее пользователи работали буквально в гармонии друг с другом. То есть нужно сделать так, чтобы, например, длинная цепочка «товар куплен у поставщика, оказался на складе, приобретен клиентом через интернет-магазин и, наконец, учтён в бухгалтерии» в разрезе информационных систем выглядела также единым процессом, а не разрозненным набором операций, выполняемых операторами в самых разных системах. Это под силу BPM.
Технологии BPM (Business Process Management) позволяют сократить время выполнения бизнес-процессов за счёт регламентации и автоматизации шагов, введения временных ограничений и действий «по умолчанию». Соблюдение всех предусмотренных правил и повышение эффективности бизнес-процессов обеспечиваются за счет увеличения прозрачности этих процессов для всех их участников, регламентации и средств мониторинга.
При этом применение BPM позволяет «визуализировать» процессы, причем в динамике. И самое главное – внедрение новых процессов и изменение старых осуществляются гораздо быстрее и практически прозрачно для их участников. Сотрудникам не нужно заучивать новые регламенты, запоминать новый порядок действий или согласований – все это ложится на плечи BPM-системы (подробнее о решениях этого класса – во второй части, № 1, 2013).
Разумеется, мы не претендуем на полное и детальное описание всех существующих технологий интеграции, есть еще, как минимум, интеграция сервисов и пользовательских интерфейсов. Цель этой статьи – дать общее представление о задачах и проблемах интеграции. Далее в этом номере поднятые нами вопросы будут освещены более подробно, а также описаны существующие решения вендоров и опыт реализации подобных проектов.