Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.
В процессе работы бизнес консультантом, для увеличения эффективности работы систем предприятия, я почти всегда предлагаю провести интеграцию между различным ПО заказчика. Потому что интегрировав различные системы возможно добиться эффекта синергии.
Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем.
Введение в автоматизированное тестирование | Теория
Интеграция – это очень важная часть работы по автоматизации бизнес-процессов, так как требуется она постоянно. В разных ситуациях возникает потребность оперативно обмениваться данными между различными конфигурациями 1С, между программными продуктами 1С и сайтом, между 1С и CAD системами, а также системами биллинга и т.д. Также достаточно часто требуется интегрировать между собой различные веб сервисы, например, интернет-магазин и CRM-систему. В общем, объединить работу различных подразделений компании и автоматизировать рабочий процесс без использования интеграции в большинстве случаев невозможно.
Что такое интеграция?
Википедия дает нам такое определение:
- Веб-интеграция — объединение разнородных веб-приложений и систем в единую среду на базе веб.
- Интеграция данных — объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде
Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением:
Интеграция программных систем и продуктов — это обмен данными между системами с возможной последующей их обработкой.
Смысл интеграции заключается в том, чтобы данные, которые пользователь вводит в одну систему, автоматически переносились в другую. Продукт, в который пользователь вводит данные, называется источник. А получатель данных, соответственно, приемник.
Достаточно часто данные переносят в обе стороны, например, после преобразования в системе-приемнике результаты отправляются обратно в источник. А потому интеграция бывает как односторонней, так и двухсторонней.
Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам.
- Определяем, какой продукт является источником, какой – приемником.
- Сопоставляем объекты между источником и приемником.
- Выбираем протокол для интеграции
- Проводим постобработку данных (после переноса в одну из сторон)
Важно: при интеграции различных программных решений нужно хорошо понимать их функционал.
Когда-то я и сам совершал такую ошибку, и брался за интеграцию программных продуктов, которые я недостаточно хорошо знал. А потому могу сказать точно: изучать программный продукт в процессе интеграции – это не совсем корректно. При таком подходе чаще всего возникает множество ошибок и проблем, например, перенос не тех данных или сбои в работе. Рекомендую сначала хорошо изучить программный продукт, понять, что он может, каким образом в нем реализованы те или иные функции, и только потом заниматься интеграцией.
В принципе, в процессе интеграции вам может потребоваться и более сложный обмен, и придется вводить, например, трех- или четырехстороннюю интеграцию. Но, по сути, эти процессы ничем не отличаются от обычного одно- или двухстороннего процесса. А потому я буду говорить об интеграции односторонней. А в конце скажу пару слов об особенностях двухсторонней. Все остальные направления вы всегда сможете выстроить по аналогии.
Выбираем источник и приемник
Для каждого случая интеграции данных важно четко определить, какая система будет источником, а какая – приемником.
Например, у вас есть система CRM и программа 1С: Торговля. В обеих системах существует такое понятие, как контактное лицо. В принципе, вводить его вы можете и с одной, и с другой стороны. В данном случае, очевидно, что источником стоит назначить CRM, так как этого требует логика работы с любой CRM-системой.
Аналогично и в других случаях. Нужно понимать, в какой системе пользователь будет вводить данные, а какая станет получателем этих данных через интеграцию. Это обязательно согласовывается с клиентом (пользователем), кроме случаев, когда источник очевиден. при этом обязательно нужно поставить в известность клиента, что данные определенного типа следует вводить именно через систему-источник.
Сопоставление объектов (данных)
Каждый раз при работе с данными нужно очень хорошо понимать, что именно вы выгружаете, в каком виде, а также, куда вы будете выгружать эти данные. В некоторых случаях в источнике у вас будет строковая переменная, а в приемнике – два или более объектов. В других важно просто правильно выбрать объект-приемник.
Например, практически в любой CRM контактное лицо и клиент – это одно и то же. С другой стороны в 1С контактное лицо может быть клиентом, партнером, поставщиком. И очень важно понимать, куда именно записывать данные этого контактного лица. Также важно сопоставлять все данные до того, как начнется работа непосредственно с кодом. Для этого прекрасно подойдут таблицы или блок-схемы.
Когда-то я так же, как и многие, пренебрегал этим этапом работы. Сейчас я знаю, что эти действия позволят избежать огромного количества ошибок. На какой бы стороне ни работал программист – на стороне программы-источника или приемника, такая табличка очень помогает в работе. Программист должен четко понимать, какие данные будут брать из источника, куда их нужно переносить, и как они будут обрабатываться.
Например, при выгрузке контактного лица из CRM нужно четко сопоставить этот контакт партнеру или покупателю.
Также очень важно понимать, какие преобразования потребуются для выгружаемых данных. Например, нужные для интеграции данные в источнике хранятся в качестве перечисления в виде текста. А в приемнике (пусть это будет 1С) аналогичное перечисление имеет ссылочный тип. Следовательно, вам потребуется преобразовать текст в ссылку, и уже ссылку передать в документ.
И здесь возникает проблема: требуются правила сопоставления.
Вы должны четко продумать и прописать правила сопоставления. Более того, об этих правилах необходимо оповестить ваших клиентов. Важно понимать, что клиент не видит логику работы обмена данными, он не понимает особенностей интеграции.
Также стоит лог-файл ошибок вести максимально подробно и как можно дольше хранить историю. Не забывайте, что вы имеете дело с данными, которые имеются в одной базе данных, но отсутствуют в другой. И без подробного отчета вам будет очень сложно понять, что именно произошло в процессе передачи данных.
Обмен данными: писать самому или применять типовое решение?
Лично я предпочитаю всегда разрабатывать решение под заказчика. Здесь можно спорить, можно обсуждать различные варианты, но есть факт: типовые обмены данными всегда сильно перегружены возможностями, которые вашему клиенту не нужны. В результате процесс обмена значительно замедляется, а число возможных ошибок вырастает в разы.
Кроме того, при выборе типового программного решения вы очень сильно зависите от поставщика программного обеспечения. Для любого исправления бага вам придется ждать выпуск очередной версии программы. Также придется подстраиваться при обновлениях под все изменения в работе, который внес разработчик.
А потому при выборе между самостоятельным написанием обмена данными и типовым решением, которое не на 100% подходит для данной ситуации, лучше писать обмен самому.
В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.
Метод подключения: REST API, SOAP или прямое подключение к базе приемника
Выбор протокола обмена данными в большинстве случаев напрямую зависит от системы, которую вы интегрируете. В большинстве случаев программисту приходится учитывать требования обеих систем, а потому выбора как такового не существует. В тех случаях, когда система может работать с несколькими протоколами, выбирайте тот, который вам удобнее. По моему опыту, для малых и средних предприятий этот вопрос не принципиален.
Вопросы клиентского доступа: почему не работает обмен?
Я считаю, что обо всех возможных ограничениях в доступе нужно узнать на начальном этапе интеграции. Таким образом, вы гарантированно избежите очень распространенной проблемы:
Вы внедрили интеграцию, все проверили, протестировали, убедились, что система работает. После чего пользователь обнаруживает, что обмен данными не происходит.
- Ограничение доступа по IP.
- Ограничение прав пользователя.
- Ограничение по количеству обращений к источнику или приемнику
В случае работы с CRM-системой ограничения обычно обусловлены оплаченным пакетом услуг. Здесь достаточно оповестить клиента о наличии такого ограничения, и, при необходимости, помочь оплатить и настроить расширенный пакет.
1С идентификаторы и ошибки, связанные с ними
При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных.
Если вы будете проводить поиск по всему справочнику с использованием идентификатора, который предназначен для работы внутри определенного типа данных, возникнет ошибка. Объект может быть вообще не найдет, либо система найдет сразу несколько разных объектов. К этой особенности 1С нужно относиться очень внимательно.
Еще одна проблема: нет возможности привязаться к уникальному идентификатору.
Например, системой-источником является сайт, и на нем не предусмотрено отдельное поле для информации о клиенте, она идет в общем тексте заказа. В этом случае придется выбрать какой-то другой вариант идентификации, например, по email.
При интеграции очень важно выбрать в источнике одно из полей, которое и станет уникальным идентификатором.
Я считаю хорошим тоном дублирование этого идентификатора в двух системах. Например, если я делаю выгрузку информации из CRM в 1С, то поле-идентификатор из CRM я копирую в систему 1С. В дальнейшем весь поиск и интеграция производится по этому полю быстро и просто.
В принципе, это не обязательное действие. Более того, вы будете хранить даже избыточные данные, так как у вас есть нужная информация в одной из систем, но такое дублирование повышает надежность работы обеих программ и является удобным решением для интеграции и последующей обработки данных.
Например, по идентификатору, который идентичен источнику, поиск будет производиться проще и быстрее, так как он не будет требовать дополнительной обработки. Кроме того, если что-то случится с базой данных одной из систем, благодаря дублирующимся идентификаторам сопоставить данные будет намного проще.
Формат выгрузки
Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.
Постобработка
Итак, обмен данными прошел успешно. Что дальше? Я считаю, что это еще не финал интеграции, так как пользователю мало того, что данные появились в системе. Обычно ему требуется, чтобы с этими данными выполнялись какие-то действия. Что именно нужно клиенту, следует уточнить у него.
Но всегда надо помнить о том, что вы работаете для пользователя, для того, чтобы ему было удобно.
- Оповещение менеджера о поступлении заказа, например, при помощи sms
- Уведомление пользователей о поступлении новых заказов или другой актуальной информации по email
- Звуковой сигнал и/или всплывающее окно в 1С с напоминанием о том, что появились новые запросы или заявки
Кроме действий, которые нужно выполнить в приемнике, также часто требуется после завершения успешной передачи данных выполнить определенные действия в источнике. Что именно потребуется, вам также расскажет пользователь.
Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.
Тестирование интеграции
С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье Внедрение программного продукта.
Особенности работы бизнес-консультанта. Часть III. Финальная.
Отличие односторонней и двусторонней интеграции
На самом деле, принципиальных отличий у односторонней, двусторонней или многосторонней интеграции не существует. Суть процесса остается прежней, просто в разные моменты времени приемник и источник меняются ролями. Единственное важное правило, которое я ввел для себя и вам также советую: при двухстороннем обмене необходимо хранить уникальный идентификатор для всех систем, которые участвуют в интеграции. И я считаю, что его также стоит дублировать в обеих системах.
Сегодня я постарался кратко рассказать об особенностях процесса интеграции, с которыми я лично сталкиваюсь на практике. Я надеюсь, что статья оказалась для вас полезной, а если возникнут какие-то вопросы, я, как и всегда, готов на них ответить.
- интеграция
- интеграция приложений
- интеграция с 1с
- обмен данными
- Блог компании Тринион
- Программирование
- .NET
Источник: habr.com
Интеграция программных модулей
Предприятие любого уровня нуждается в программном обеспечении, отдельные компоненты которого будут синхронно работать из любой точки. Для этих целей и проводится интеграция программных модулей. Далее рассмотрим более подробно виды, цели и уровни интеграции программных модулей.
Цели и задачи
Интеграция – процесс разработки и внедрения программного обеспечения, с помощью которого отдельные компоненты могут быть связаны в единую систему. Такое объединение позволяет поддерживать бизнес-процессы и оперативно обмениваться информацией.
Главная задача процесса – обеспечение безопасного и бесперебойного обмена информацией между программными продуктами, которые изначально не предназначены для совместной работы. Например, программное обеспечение для электронного документооборота между предприятием и его клиентами, организация цепей поставок, ERP-системы, облачные технологии, аналитические модули, системы самообслуживания и т. д.
С помощью интеграции программных модулей обеспечивается не только оперативность и автоматизация работы с данными. Решается ряд более широких задач:
- оперативное внедрение новых программных продуктов в работу предприятия;
- улучшения качества работы с клиентами;
- прозрачность процессов;
- сокращения количества ошибок при обработке данных и т. д.
Принципы работы
Прежде, чем настраивать интеграцию модулей, нужно определиться с принимающей и передающей стороной – источником данных. Если изначально источник информации не определен, сделать это нужно до начала загрузки данных в систему, так как в ней могут присутствовать приложения с идентичным функционалом. Например, ПО 1С: Торговля и любая стандартная CRM позволяют вносить данные контрагентов. Разрозненный ввод повлечет за собой проблемы задвоенных данных, их несвоевременную синхронизацию, потерю и т. д.
Возможна и двусторонняя интеграция. В этом случае источник и принимающая сторона могут меняться.
Одно из главных преимуществ интеграции программных модулей – постоянный доступ к обновляющимся данным. Именно за счет этого удается создавать инструменты и сервисы, которые оперативно адаптируются под конкретные задачи.
Основной принцип работы процессов – взаимодействие модулей друг с другом, каждый из которых выполняет конкретную задачу. При завершении работы одного из компонентов все обработанные данные должны быть оперативно синхронизированы с другими модулями и доступны для дальнейших действий.
Чтобы гармонично объединить все элементы системы, важно придерживаться следующих принципов.
Настройка API
API – комплекс правил, на основании которых взаимодействуют отдельные части ПО. Именно за счет API программистам удается оперативно настроить компоненты, предупредить и устранить возможные ошибки в работе модулей.
Настройка событийных действий
Настраивается специальный комплекс действий, которые запускаются после произведения другого, заранее определенного действия. Например, при завершении оформления заказа клиентом система автоматически генерирует ему счет на оплату, то есть одно действие является триггером для последующего.
Сопоставление данных
Правильная настройка обмена данными между разными модулями системы позволяет ускорить обмен и синхронизацию данных.
Виды интеграции
В зависимости от цели внедрения интеграцию, в первую очередь, подразделяют на внутреннюю и внешнюю. Внутренняя подразумевает добавление конкретных программных модулей без привлечения внешних ресурсов. Внешняя интеграция позволяет внутренние процессы синхронизировать с более глобальными, например, подключение к Google Maps для логистических компаний.
Доступны 3 вида интеграции:
- облачная;
- локальная;
- гибридная.
Каждый из видов, в свою очередь, различается по следующим методам:
- На уровне брокеров. Данный вид интеграции считается универсальным. При необходимости задействуется дополнительный модуль – брокер. Он подключается к другим необходимым модулям. Такой вид интеграции считается сложным в реализации, требует определенных знаний.
- На уровне интерфейсов. Целью данного вида интеграции изначально было объединение разноплановых приложений. Сложность такого типа в последовательном подключении элементов. Это вызывает ряд ошибок в процессе взаимодействия. К тому же часто встречаются Legacy софт.
- На уровне сервисов. Здесь при помощи программного обеспечения осуществляется фиксация данных и интерфейсов с двух сторон. Это один из немногих видов неавтоматизированной интеграции, то есть участие человека здесь остро необходимо.
- Функционально-прикладная и организационная интеграция. Ключевым моментом здесь является объединение нескольких схожих или однотипных приложений. Этот вид наиболее удобен для крупных предприятий, корпораций. Именно за счет интеграции этого вида удается снизить затраты на обслуживающий персонал, так как практически все процессы максимально доступны.
- Корпоративные программные приложения. Здесь используются не только приложения внутри системы, но и сам исполняемый код. Специализированное ПО и API позволяют использовать отдельные компоненты приложений в единое ядро. Такую систему легче администрировать и масштабировать при необходимости. Доступ к ядру осуществляется при помощи стандартных протоколов доступа, например, SOAP.
Взаимодействие интегрированных модулей
Интеграция программных модулей включает в себя задачу обеспечения оперативного взаимодействия всех входящих в систему компонентов. Не всегда удается достичь нужного взаимодействия полностью автоматизированным способом.
Обмен данными
Обмен актуальной информацией внутри одной системы – одна из главных задач интеграции программных модулей. Чем проще будет настроена форма обмена, тем быстрее будет происходить обмен. Следует учитывать, что для разных задач может использоваться разный формат данных: pdf, xls, CSV и др. Дополнительным преимуществом будет возможность интегрировать модуль для автоматической загрузки и выгрузки данных.
База данных
Все интегрируемые приложения в системе должны иметь доступ к единой базе данных. Это может вызвать некоторые сложности. Не всегда есть возможность оперативно определить какой-либо конкретный модуль. Все компоненты системы тесно переплетены и образуют один общий привязанный к единой базе элемент внутри системы. Помочь в такой ситуации может дополнительная интеграция модулей для работы с базами данных.
Удаленный вызов
В каждом из модулей интегрированной системы прописываются специальные протоколы. Благодаря им удается задать команды для сообщения между несколькими модулями, то есть для того, чтобы два или несколько компонентов оперативно выполнили одну задачу, первый должен отправить удаленный вызов второго и последующих.
В таком взаимодействии есть очень существенный недостаток. Чтобы не нарушать единовременную синхронизацию всех данных, важно следить за тем, чтобы все системы внутри предприятия в одно и то же время были включены в работу. Если отследить одновременный запуск всех систем не представляется возможным, подобную интеграцию следует рассматривать внутри небольших организаций. Здесь за результативность процесса отвечает человек. Автоматизировать удаленный вызов в системах большего масштаба пока не удалось.
Асинхронный обмен сообщениями
Принцип асинхронного обмена сообщениями внутри одной системы – наиболее оптимальный вариант автоматического взаимодействия модулей. При таком принципе одно из интегрированных приложений просто отправляет запрос другому. При этом не нужно ждать ответа от принимающего приложения. Все запросы доставляются и обрабатываются им в порядке очереди.
Организация маршрутов взаимодействия
Кроме способов взаимодействия особое внимание следует уделить непосредственной организации маршрутов. Различают 2 подхода:
- прямое взаимодействие – точка-точка;
- звездообразная архитектура – хаб-спицы.
От выбранного маршрута напрямую зависит скорость и легкость обмена данными внутри системы.
Точка-точка
Этот подход характеризуется прямым взаимодействием. «Точка-точка» считается самым простым подходом и чаще всего используется для передачи большого объема данных. Важно следить за тем, чтобы приложения использовали одинаковые методы сообщения друг с другом. Изменение интерфейса взаимодействия одного элемента неизбежно повлечет за собой перенастройку всей системы. Кроме этого возможны замедления в работе системы, так как есть риск попасть в момент репликации данных.
Хаб-спицы
Ключевым моментом взаимодействия приложений при подходе «хаб-спицы» является наличие единого центрального узла. Он сам организует взаимодействие между интегрированными компонентами при помощи различных протоколов и методов, контролирует базу данных системы. Приложения связаны с хабом и не взаимодействуют друг с другом. Преимущество такого подхода заключается в отсутствии необходимости модифицировать всю систему, если приходится изменять работу одного из приложений.
Интеграция программных модулей – сложный процесс, требующий определенных знаний на каждом этапе его разработки, внедрения, запуска, дальнейшего использования и обслуживания. Поэтому важно уделить внимание не только задачам, которые стоят перед внедрением. Любая работа по внедрению программного обеспечения включает в себя обязательное тестирование и дальнейшее обучение пользователей.
Источник: dynamicsun.ru
Презентация на тему Подходы к интеграции программных модулей
Интеграция — это не просто механическое объединение модулей информационной системы. При разработке плана интеграции исходят прежде всего из стратегических целей развития предприятия, возможного изменения бизнес-логики, в соответствии с которой выстраиваются бизнес-процессы
- Главная
- Информатика
- Подходы к интеграции программных модулей
Слайды и текст этой презентации
Слайд 1Подходы к интеграции программных модулей
Слайд 2Интеграция — это не просто механическое объединение
модулей информационной системы. При разработке плана интеграции
исходят прежде всего из стратегических целей развития предприятия, возможного изменения бизнес-логики, в соответствии с которой выстраиваются бизнес-процессы и осуществляется их информационное сопровождение. Интеграция может производиться на уровне форматов и баз данных, программно-аппаратных и сетевых устройств, пользовательских интерфейсов, форм и шаблонов документооборота, программных приложений и т.д.
Слайд 3Интеграция на уровне данных
Одной из главных проблем
интеграции данных является обилие форматов и типов
(неструктурированные, частично-структурированные, жёстко-структурированные) данных, а также лавинообразное нарастание их объёмов. Циркулирование разнородных массивов данных и информации в сетях различных служб предприятия создает множество проблем с их сбором, структурированием, обработкой, анализом, хранением, архивированием и передачей пользователю для принятия делового решения.
Слайд 4
Рисунок 1 — Традиционная схема интеграции данных
Слайд 5Интеграция на уровне физических, программных и пользовательских
интерфейсов
Этот вид интеграции начинался как один из
видов «лоскутной интеграции», когда предпринимались попытки объединить разрозненные программные приложения, написанные в разное время разными разработчиками, в подобие единого целого. Приложения объединялись по принципу «каждый с каждым», что, в конечном счёте, усложняло их взаимодействие и создавало массу проблем. Кроме того, всё сложнее становилось использовать унаследованные (Legacy Software) и встроенные (Embedded System) системы.
Такой подход хорош для небольшого количества приложений. При большом их числе он практически не работает и не позволяет строить качественно новые запросы к агрегированным данным, т.е. существенного выигрыша от объединения данных нет. В настоящее время проблема интеграции на уровне интерфейсов решается на базе использования информационных подсистем, реализованных стандартными программными приложениями с открытыми интерфейсами (Open Application Programming Interface).
Слайд 6Подобные унифицированные интерфейсы разрабатываются, например, на базе
семейства международных стандартов POSIX. В этом случае
степень интегрируемости можно характеризовать некоторым числовым показателем (метрикой) который можно, условно говоря, вычислить, перемножив показатель «качества» и «показатель открытости» программного интерфейса. Показателем качества могут выступать такие характеристики, как «совместимость», «надёжность», «переносимость», «понятность», «удобство использования» и пр. В результате мы получим индекс, который (в известной степени) характеризует способность приложения быть частью какого-то другого, глобального композитного приложения.
В настоящее время всё чаще применяется следующий алгоритм: отделяют слой обработки данных от привязанных к ним форм визуализации и реализуют прикладную бизнес-логику на одном из языков третьего поколения (3GL), оформив программный доступ к прикладным функциям в виде хорошо документированного программного интерфейса
Слайд 7
Рисунок 2 — Организация доступа к интегрированным
данным через открытые интерфейсы
Слайд 8Интеграция на функционально-прикладном и организационном уровнях
Этот вид
интеграции предполагает объединение ряда однотипных или схожих
функций в макрофункции с перераспределением потоков данных и управления, а также ресурсов и механизмов для исполнения. Это часто влечёт за собой перестройку организационных структур, бизнес-процессов и, соответственно, схему их информационного и документационного обеспечения.
Выгоды от такой интеграции очевидны — процессы становятся более прозрачными, управляемыми, менее затратными, уменьшается количество обслуживающего персонала, число ошибок при формировании документов и т.д. Однако интеграция такого вида влечёт за собой существенную перестройку или полный реинжиниринг сети процессов, что связано с крупными рисками. Чаще всего такая интеграция проводится в том случае, когда предприятие готовится к внедрению КИС на базе известного решения, которое требует привести бизнес-процессы к требуемому стандарту, или перестраивает свою деятельность в связи со сменой устремлений, открытием филиалов в других странах, освоением новых сегментов рынка и т.д.
Слайд 9Интеграция на уровне корпоративных программных приложений
Интеграция на
уровне приложений (Enterprise Application Integration — EAI,)
подразумевает совместное использование исполняемого кода, а не только внутренних данных интегрируемых приложений. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО.
При таком подходе из этих компонентов создается универсальное программное ядро или платформа, с помощью которых используют все приложения. Для каждого приложения создается только один интерфейс для связи с этим ядром, что существенно облегчает задачу интеграции. Полученную в результате систему легче поддерживать и расширять.
Повторное использование функций в рамках имеющейся среды позволяет значительно снизить время и стоимость разработки приложений. В этом случае анализ внутренней конструкции приложений — обязательный этап в оценке степени интегрируемости тех приложений, которые предполагается связывать в рамках того или иного проекта. Этот анализ усложняется тем, что обычно разработчики приложений, являющихся законченными программными продуктами, как правило, не показывают деталей внутренней конструкции приложений.
Слайд 10В связи с этим технология интеграции в
настоящее время рассматривает не просто интеграцию приложений,
но их интеграцию на базе интеграции бизнес-процессов – в этом случае следует говорить об интеграции на уровне всего предприятия (Enterprise Integration Metodology — EIM).
Рисунок 3 — Схема применения методологии EIM
Слайд 11Интеграция при помощи Web-сервисов
Самый современный и быстро
развивающийся подход к интеграции приложений. Он основан
на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным
Рисунок 4 — Схема доступа с использованием Web-служб
Слайд 12возможность осуществлять оперативное управление распределенной компанией и
ведение консолидированного управленческого учета по нескольким филиалам;
возможность
осуществлять планомерное развитие общекорпоративной информационной системы, интегрируя в нее функциональные компоненты, исходя из приоритетов развития бизнеса компании и потребностей функциональных подразделений, т.е. возможность синхронизировать развитие системы с развитием бизнеса;
возможность при необходимости заменить любой функциональный компонент другим, более соответствующим текущим бизнес-потребностям;
возможность инвестировать в развитие информационных технологий не сразу, а поэтапно, на каждом этапе соотнося вложенные средства с полученным бизнес-эффектом, а также снижать общую стоимость автоматизированного рабочего места, включая затраты на создание системы, поддержку рабочих мест и обучение пользователей;
резкое снижение времени сбора информации, необходимой для принятия управленческих и деловых решений, сокращение времени и трудозатрат на ведение учетных операций, на формирование промежуточных отчетов, на сверку информации между подразделениями и ликвидация противоречивости и несовместимости данных от различных служб;
cохранение инвестиций в имеющиеся системы и оборудование, в обучение персонала.
Источник: thepresentation.ru