Дипломная работа внедрение erp системы на предприятии

метки: Система, Предприятие, Внедрение, Приложение, Данные, Управление, Обмен, Интеграция

Проблема автоматизации работы предприятия появилась более 30 лет назад. С момента появления первых работ по разработке информационных систем, охватывающих все бизнес-процессы целевой организации, достаточно многое изменилось. Что в итоге привело к появлению стандарта планирования ресурсов предприятия (Enterprise Resource Planning, сокр. ERP), широко распространенного в настоящее время.

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

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

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

Перед автором настоящей дипломной работы были поставлены следующие задачи:

1. изучить теорию интеграции корпоративных приложений;

2. изучить особенности интеграции западной ERP-системы и системы

российского бухгалтерского учета;

3. разработать метод интеграции зарубежной ERP-системы (Microsoft Dynamics

NAV) и системы российского бухгалтерского учета (1C: Предприятие) с

использованием пакета XML-DEM;

4. проверить работоспособность предложенного метода.

1 Технология ERP-систем

1.1 Что такое ERP-система

К концу 80-х годов идея разработки единой модели данных в пределах организации стала привлекать внимание промышленных компаний, которые искали способ упростить управление производственными процессами. Первым шагом в данном направлении стала концепция планирования материальных ресурсов (Materials Resource Planning, сокр. MRP), рассматривающая приобретение материалов и управление производственным процессом с управлением реализацией. В системе такого рода осуществляется расчет потребностей в материалах в зависимости от конкретных сроков выполнения тех или иных технологических операций. Но методологии MRP присущ серьезный недостаток. При расчете потребности в материалах не учитываются загрузка и амортизация производственных мощностей, стоимость потребляемой энергии и рабочей силы, и т.д. Поэтому как логическое развитие технологии MRP была разработана концепция Manufacturing Resource Planning (планирование производственных ресурсов), сокращенно называемая MRP II. В рамках системы класса MRP II можно планировать все производственные ресурсы предприятия: материалы, сырье, оборудование, все виды потребляемой энергии, людские ресурсы и пр.

Внедрение системы «1С:Предприятие 8» в компании ЗАО «Генсер»

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

Далее концепция MRP II развивалась в соответствии с тенденциями изменения рынка и порождаемыми ими новыми потребностями в управлении предприятиями. К MRP II постепенно добавлялись возможности по учету и управлению другими затратами предприятия. Дальнейшее наращивание функционала в отношении управления деятельностью всего предприятия в целом, привело к появлению концепции ERP (Enterprise Resource Planning).

В основе ERP лежит принцип создания единого хранилища данных, в котором содержится вся деловая информация, накопленная организацией в процессе своей деятельности, включая финансовую информацию, данные, связанные с производством, управлением персоналом и любые другие сведения. Такой подход устраняет необходимость в передаче данных между разными системами. Кроме того, любая часть информации, которой располагает данная организация, может быть одновременно доступной для всех работников, которые обладают соответствующими полномочиями.[1]

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

В разрезе информационных технологий, ЕRP-система — набор интегрированных приложений, которые комплексно, в едином информационном пространстве поддерживают все основные аспекты управленческой деятельности предприятий планирование ресурсов (финансовых, человеческих, материальных) для производства товаров (услуг), оперативное управление, выполнением планов (включая снабжение, сбыт, ведение договоров), все виды учета, анализ результатов хозяйственной деятельности. [2]

Системы класса ERP представляют собой набор интегрированных приложений, в совокупности проецирующих действия по основным направлениям управленческой деятельности предприятия на единое информационное пространство. Знания, заложенные в ERP-системы, позволяют решить основную задачу корпоративной автоматизации представить работу всех функциональных подразделений компании как работу единой сложной системы. Перечислим основные преимущества внедрения и использования ERP-системы: [3]

• ERP-системы интегрируют виды деятельности фирмы. Процессы

планирования ресурсов предприятий являются межфункциональными,

заставляющими фирму выходить за традиционные, локальные и

функциональные рамки. Кроме того, различные бизнес-процессы часто

связаны между собой. Более того, данные интегрированы в единую систему.

Управление деятельностью аэропорта

... пассажиров. Ожидается, что к 2015 году аэропорт будет обслуживать 35 млн пассажиров в год. Система менеджмента качества аэропорта сертифицирована по стандарту ISO 9001:2008. Технические ... курсовой работе я выбрала международный аэропорт Шереметьево. Вид деятельности: внутренние и международные пассажирские и грузовые перевозки ОАО «Международный аэропорт Шереметьево» Аэропорт Шереметьево -- один из ...

— ERP-системы используют «передовые технологии» (best practices).

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

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

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

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

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

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

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

способствует взаимодействию, обеспечивая каждое географически разделенное и

функциональное подразделение нужной им информацией.

• ERP-системы способствуют взаимодействию и сотрудничеству между

организациями. ERP-система обеспечивает информационную магистраль для

организации взаимодействия и сотрудничества с другими организациями. Фирмы

все больше и больше открывают партнерам свои БД для облегчения снабжения и

Планирование индивидуальной работы менеджера

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

других видов деятельности. Чтобы данная система работала, необходим единый

архив, которым могут пользоваться партнеры; и ERP-системы могут быть

использованы для содействия таким обменам.

1.2 Функции ERP систем

Современная модель MRP/ERP включает в себя следующие подсистемы:

• управление запасами;
• управление снабжением;
• управление сбытом;
• управление производством;
• планирование;
• управление сервисным обслуживанием;
• управление цепочками поставок;
• управление финансами.

Укрупнено структура управления в ERP показана на рисунке 1. [4]

Остановимся кратко на базовой функциональности, поддерживаемой каждой из подсистем.

1. Управление запасами

Эта подсистема обеспечивает реализацию следующих функций:

• мониторинг запасов (Inventory Control);
• регулирование и инвентаризация складских остатков (Physical

Inventory).

При решении задач управления запасами производится обработка и

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

материалов, промежуточной продукции и готовых изделий; учет запасов по

складам, выбор стратегий контроля, пополнения и списания запасов по

каждой позиции. Также учитывается нормативная и текущая фактическая

стоимость запасов, отслеживается прохождение отдельных партий запасов и

серий изготавливаемой продукции.

2. Управления снабжением

Подсистема реализует следующие функции:

• заказы на закупку (Purchase Orders);
• график поставок (Supplier Schedules);
• планирование потребности в материалах (MRP), понимаемое как

управление заявками на закупку. 3. Управление сбытом Базовыми функциями этой подсистемы являются:

• квотирование продаж (Sales Quotations);
• заказы на продажу / счета фактуры (Sales Orders / Invoices);
• график продаж потребителям (Customer Schedules);
• конфигурирование продуктов (Configured Products);
• анализ продаж (Sales Analysis);
• управления ресурсами распределения (Distributed Resource Planning).

Прогнозирование

Бизнес-планирование

Прогнозирование Прогнозирование

Планирование продаж и Планирование

выпуска продукции проектов и программ

Прогнозирование

Управление Объёмное и

спросом объёмно-календарное

планирование мощностей

Ведение Составление графика информации выпуска продукции

о составе продукции

Детальное планирование материальных

ресурсов/мощностей

Ведение График производства информации о и снабжение технологических маршрутах

Производство

Управление

затратами

Прогнозирование

Управление Управление

финансами кадрами

Рисунок 1 4. Управления производством В этой подсистеме реализуются следующие функции, соответствующие различными типам производственных процессов:

• спецификация изделий, определяющая, какие материалы и

комплектующие используются в производимом изделии (Product

Structures);

• операции/центры переработки (Routings / Work Centers), включает в

себя описание цехов, участков, рабочих мест;

Управление качеством строительной продукции

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

• технологические процессы производства продукции (Formula / Process)

с маршрутизацией по рабочим центрам для объемного (процессного)

производства.

• наряд-задание (Work Orders) на производство работ для позаказного и

мелкосерийного производства;

• управление трудозатратами (Shop Floor Control);
• поточное производство (Repetitive), как для серийного, так и массового

производства.

• управление качеством (Quality Management), описание различных

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

• Product Line Planning (PLP) – финансовое планирование товарно номенклатурных групп (ТНГ);
• Master Scheduling Planning (MSP) – главный календарный график или

объемно календарное планирование;

• Distribution Resource Planning (DRP) – планирование распределения

ресурсов (RCP);

• Materials Requirements Planning (MRP) – планирование потребности

материалов;

• Capacity Requirements Planning (CRP) – планирование потребления

мощностей. Эту функциональность можно условно отнеси к трем

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

7. Управление цепочками поставок

Эта подсистема предназначена для обеспечения эффективного управления

материальными и соответствующими им информационными потоками: от

поставщика через производство к потребителю. Реализованная в подсистеме

идеология «управления глобальными цепочками поставок» дает

промышленным предприятиям возможность представлять свою деятельность

в виде так называемых эффективных цепочек логистики: от поставщиков

сырья и комплектующих до продажи готовых изделий конечному

потребителю. При этом обеспечиваются широкие возможности управления

транснациональными компаниями, координации распределенного между

многими дочерними компаниями производства.

8. Управление финансами

Эта подсистема полностью интегрирована со всеми остальными и позволяет

оперативно получать информацию о финансовых потоках, связанных с

потоками материальными, о текущем финансовом состоянии компании, и

помогает находить оптимальные финансово — экономические решения.

Сквозное управление материальными потоками находит свое отражение в

управлении финансовыми потоками (движении денежных средств).

Модель MRP/ERP реализована в ряде информационных систем (ERP –систем) корпоративного уровня. Согласно статистическим данным, полученным при анализе использования ERP-систем в США, результатом внедрения таких систем на предприятиях является сокращение объемов запасов в среднем на 17 %, уменьшение затрат за закупку сырья и материалов на 7 %, повышение рентабельность производства в среднем на 30% и качества выпускаемой продукции на 60%.

Автоматизированная система управления технологическими процессами ...

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

1.3 Реализация стандартов управления в корпоративных системах

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

Западные аналитики различают два вида корпоративных информационных систем: Business Management Systems (BMS) – системы управления бизнесом и Enterprise Recourse Planning (ERP) – системы планирования ресурсов предприятия.

В свою очередь, BMS – системы подразделяются на три группы. В первую группу входят простые системы, предназначенные для автоматизации малых предприятий. Системы этой группы рассчитаны на выполнение весьма ограниченного числа стандартных бизнес-процессов и представляют собой «коробочный продукт». Как правило, они работают на одном рабочем месте или в небольших сетях из 4 – 8 компьютеров. Такие системы называют «Low End PC». Примером отечественной системы такого уровня является «1С: Бухгалтерия».

Ко второй группе, называемой «Middle PC», относят системы, отличающейся большей глубиной и широтой охвата функций. Они нуждаются в настройке, которую в большинстве случаев осуществляют специалисты фирмы-разработчика. В такой системе могут быть описаны десятки бизнес — процессов. В основном данные системы автоматизируют бухгалтерский и/или складской учет, как например «1C: Предприятие».

Последняя группа систем под названием «High End PC» рассчитана на работу большого числа пользователей. Такие системы могут применяться на средних предприятиях, не предъявляющих высоких требований к функциональности и гибкости системы управления. В системах этой группы можно встретить описание уже сотен бизнес — процессов. В большинстве случаев они могут работать в среде Windows NT или UNIX. Среди российских программных продуктов к данному классу относятся “Галактика”, “NS2000”.

Высший уровень иерархии занимают системы, которые обеспечивают планирование и управление всеми ресурсами предприятия и строятся на основании MRP/ERP модели, то есть ERP-системы. В них содержится описание тысяч бизнес процессов. Такие системы могут иметь до 100 тысяч настраиваемых параметров, позволяющих реализовать огромное многообразие требований различных предприятий. ERP-системы удовлетворяют большинству запросов как средних, так и очень крупных предприятий. Они могут работать на различных платформах (Windows NT, UNIX, Solaris, AIX и т.д.) и с различными мощными профессиональными СУБД.

Разработка системы контроля и управления доступом к охраняемым объектам

... брелоки и др. 1.1 Общие принципы работы систем контроля и управления доступом Существуют различные конфигурации систем контроля управления доступом: самые простые из них рассчитаны ... работы с самой системой. Данная компьютерная система должна иметь простой и наглядный интерфейс, который будет понятен любому пользователю. 1. Анализ существующих компьютерных систем контроля и управления доступом (СКУД) ...

На мировом рынке представлено около трех десятков полноценных ERP-систем. В России систем подобного уровня пока еще не создано. Хотя данное утверждение можно сделать только с оговоркой, из-за отсутствия четкого определения отношения системы класса ERP. Поэтому с определенными ограничениями к этому классу можно отнести конфигурацию «Управление производственным предприятием» на базе платформы 1С Предприятие и систему «Галактика ERP». Затраты на создание ERP-системы оцениваются экспертами в несколько тысяч человеко-лет с вытекающими отсюда финансовыми и организационными затратами. Кроме того, очень важным для столь сложных информационных систем является процесс апробации на множестве предприятий. Только после нескольких десятков успешных внедрений ERP-система может претендовать на рыночный успех, поскольку только тогда она аккумулирует в себе достаточный опыт предметных специалистов и необходимые управленческие технологии. Чтобы вернуть инвестиции и получить прибыль, компания-разработчик ERP-системы должна обеспечить ей высокий уровень продаж. Но рынок России и стран СНГ, даже по самым оптимистическим оценкам, не способен пока обеспечить спрос в миллиарды долларов за системы подобного класса. Это значит, что система должна хорошо продаваться на западных рынках, прежде всего в США. Все без исключения лидеры рынка ERP-систем смогли занять свои позиции только после успеха на самом богатом американском рынке. Так как у нас только начинается развитие экономики предприятий на базе MRP/ERP – моделей, то пройдет немало времени, прежде чем в России появятся специалисты, которые научатся не только разбираться в современных методах управления предприятиями, но и создавать программные продукты, реализующие эти методы. Однако ничто не препятствует уже сейчас использовать мировой опыт применения информационных технологий для управления предприятиями, поскольку многие из ERPсистем представлены в России, переведены на русский язык и адаптированы к требованиям российского законодательства.

Сейчас практически все современные западные производственные системы и основные системы управления производством базируются на концепции ERP и отвечают её рекомендациям, которые вырабатываются американской общественной организацией APICS, объединяющей производителей, консультантов в области управления производством, разработчиков программного обеспечения. К сожалению, большинство из российских систем управления производством не удовлетворяет пока даже требованиям MRP, не говоря уже обо всех остальных более развитых концепциях.

Последний по времени стандарт CSRP (Customer Synchronized Resource Planning) охватывает кроме управления непосредственно предприятием также и взаимодействие с клиентами: оформление технического задания, наряд – заказа, поддержку заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в том, чтобы интегрировать заказчика в систему управления предприятием. То есть не отдел сбыта, а сам покупатель непосредственно размещает заказ на изготовление продукции соответственно сам несет ответственность за его правильность, сам может отслеживать сроки поставки, производства и пр. При этом предприятие может очень четко отслеживать тенденции спроса и т.д.

Проектирование базы данных для информационной системы «Грузоперевозки»

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

На мировом рынке сейчас предлагается свыше 500 систем класса BMS (в том числе и системы класса MRP II-ERP).

Рынок бурно растет — на 35% — 40% каждый год. В настоящее время в России присутствуют около десятка западных систем и три-четыре отечественные информационные системы, которые можно отнести к корпоративным. [5] 1.4 Структура и крупнейшие поставщики российского рынка ERP систем в торговле.

По данным Центра выбора технологий и поставщиков TAdviser [6], лидером на рынке ERP-систем в российской торговле по установленным продуктам является Microsoft Business Solutions. На её решения приходится 44,3% всех проектов внедрения ERP-систем в торговле (Microsoft Dynamics NAV — 25,9%, Microsoft Dynamics AX — 18,4%).

Второе место уверенно занимает российская компания «1С». Продукты на базе платформы «1С:Предприятие 8.0» занимают свыше трети рассматриваемого сегмента 33,2%.

На третье место с большим отставанием от первых двух лидеров вышла компания SAP, её решения занимают 6,7% рынка (mySAP ERP — 4%, SAP Business One — 2,7%).

В совокупности на решения трех лидирующих вендоров приходится почти 85% всех ERP-проектов в российской торговле. На рисунке 2 представлена общая диаграмма распределения рынка между основными поставщиками ERP-систем.

Рисунок 2

Исследование проводилось на основе анализа свыше 1650 ERP-проектов по 100 ERP-интеграторам, общее количество ERP-проектов в торговле – 386.

Кроме этого исследования, в приложении А приведены сравнительные характеристики ERP-систем.

2 Проблема интеграции корпоративных систем.

2.1 Причины возникновения проблемы интеграции

Корпоративные приложения на заре своего появления — начиная с 60-х и до конца 70-х годов — были исключительно просты в исполнении, располагали простыми функциями и были разработаны в основном для выполнения повторяющихся задач. Как отмечает Билл Инмон (Bill Inmon), признанный авторитет в области Хранилищ данных, «тогда никто не задумывался об интеграции корпоративных данных. Основная задача состояла в том, чтобы автоматизировать некоторые процессы». [1]

К 80-м годам некоторые компании начали понимать значение и необходимость интеграции приложений. Ситуация осложнялась тем, что многие сотрудники IT-отделов стали предпринимать попытки перепроектировать используемые приложения, надеясь, что таким образом они смогут их интегрировать. В качестве примера Билл Инмон приводит проекты, целью которых было выполнение оперативной обработки транзакций с помощью систем, предназначенных для обработки информационных данных (функциональность Хранилищ данных).

90-е годы ознаменовались рассветом ERP-систем — в результате, корпорации столкнулись с необходимостью использовать существующие приложения и данные в рамках одной ERP-системы. Попытки решить эту интеграционную проблему исходили от самих поставщиков программных продуктов — от SAP, Oracle, PeopleSoft. Поставщики утверждали, что использование их продуктов «автоматически» снимает задачу интеграции. В качестве подтверждения своей теории они приводили следующие аргументы:

Реферат форматы баз данных в автоматизированных библиографических системах

... разведки. Директорат информационных служб и систем. Отвечает за составление информационных баз данных, автоматизированную пересылку информации потребителям, ведает разведывательными архивами. На сегодняшний день в РУМО работают свыше 7000 ... не только как набор инструментов для управления базами данных (далее БД), но и как среду для разработки приложений. В состав MS Access входят конструкторы форм, ...

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

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

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

Тем не менее, несмотря на привлекательность выдвинутой теории, практика показала ее несостоятельность. Действительно, ни одна ERP-система не в состоянии решить все задачи, стоящие перед предприятием. Следовательно, потребуется приобретение дополнительного модуля или разработка собственного приложения, реализующего необходимую функциональность, и, как результат, проведение интеграции. Помимо этого, утверждение, что ERP-система уже интегрирована, достаточно условно, поскольку при установке новой версии одного из приложений, входящих в ERP-систему, требуется обновление и других модулей. Поэтому поставщики должны обеспечить возможность внедрения различных версий своих приложений — что также требует интеграции. Кроме того, в компаниях всегда остается несколько «устаревших» приложений. Дело в том, что на внедрение всех модулей ERP-системы нужны годы, и пока они устанавливаются, используется существующие приложения, т.е. снова необходима интеграция. Наконец, слияния и поглощения компаний являются источником возникновения интеграционных проблем: часто в компаниях используются ERP-системы от различных поставщиков — в этом случае опять требуется интеграция…[1]

Сама концепция систем управления ресурсами предприятия подразумевает, что должно существовать единое информационное пространство для всех бизнес процессов предприятия. При внедрении и эксплуатации подобных систем возникает ряд задач, для которых обмен информацией наиболее востребован, например: [7]

• перенос данных из старых приложений в новую систему в процессе

внедрения системы;

• параллельная эксплуатация старых используемых на предприятии

приложений и новой системы;

• использование программных продуктов обеспечивающих специфику

учета, которая не реализована в корпоративной системе, или реализована

менее удобно. Например: специфические производственные системы,

привычные для пользователя приложения из пакета Microsoft Office;

• обмен информацией между различными инсталляциями систем. Например,

различные инсталляции для получения отчетности в российском

и международном стандарте; удаленные подразделения, филиалы

компании;

• публикация данных в Интернете;
• сбор информации из различных источников. Например: торговые

представители, удаленные торговые точки.

2.2 Три составляющих интеграции.

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

В настоящее время есть три технологии, которые могут помочь в этом. В [7] они именуются как «три ‘И'» (или «three Е» в английском варианте).

Это интеграция корпоративных приложений (Enterprise Application Integration, сокр. EAI), интеграция корпоративной информации (Enterprise Information Integration, сокр. EII) и программное обеспечение для извлечения, преобразования и загрузки данных (Extract, Transform and Load, сокр. ETL).

Эти технологии могут быть использованы для широкого круга задач: от интеграции в режиме реального времени до пакетной интеграции и от интеграции данных до интеграции приложений. Для интеграции данных в режиме реального времени лучше всего подходит технология EII. Для пакетной интеграции данных — ETL. А для интеграции приложений, в режиме реального времени или пакетном, наиболее подходящим инструментом является технология EAI.

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

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

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

— EII — это технология для интеграции в режиме реального времени несопоставимых типов данных из многочисленных источников как внутри, так и за пределами корпорации. Инструменты EII обеспечивают универсальный уровень доступа к данным и используют технологию поиска информации (pull technology) или возможности работы по запросам. Технология EII ориентирована на конкретных сотрудников, которые получают информацию через инструментальную панель или отчет.

Далее необходимо рассмотреть место этих технологий в уже существующей архитектуре. На рисунке 3 показано, как каждая из них может быть использована наилучшим образом. Технология EAI интегрирует транзакции двух или более приложений, технология ETL интегрирует данные операционных систем и компонентов поддержки принятия решений, а технология EII осуществляет виртуальную интеграцию данных из различных источников.

Отчеты

Отчеты

EII

ETL

Витрины

данных

EAI Товарные

продажи

запасы

Рисунок 3

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

Технология ETL оказывается наиболее полезной в тех случаях, когда необходимо создать Хранилище данных, содержащее хорошо документированные и надежные данные для исторического анализа, например, для анализа временных рядов или многомерных запросов. Эта технология также используется для интеграции ключевых справочных данных. Технология ETL незаменима для таких задач, как удаление дублирующихся данных, осуществление процессов проверки качества данных и т.п. Эти инструменты также используются для создания отдельных витрин данных, обслуживающих конкретный отдел или бизнес-процесс или предназначенных для каких-либо долгосрочных целей. Инструменты ETL дают пользователю возможность запустить повторяющиеся процессы для большей слаженности действий и возможности их многократного использования. Такие процессы включают создание точных технических метаданных, поддерживающих общую целостность среды business intelligence (BI).

Технология EII лучше всего подходит в тех случаях, когда необходимо создать общий шлюз (gateway) с едиными языком и точкой доступа к несогласованным источникам данных. Такие инструменты предоставляют приложениям и конечным пользователям возможности более гибкого, а также незапланированного доступа к данным, при этом не требуя постоянного использования данных или долговременных целей для получения этого доступа. Помимо традиционных реляционных баз данных, инструменты EII могут работать с XML- и LDAP-файлами (Lightweght Directory Access Protocol — облегченный протокол доступа к каталогам), плоскими файлами и другими нереляционными данными. Эти инструменты также способны представлять реляционные данные в формате XML или формате web-сервисов. Особенно полезны инструменты EII, если есть необходимость добавить к справочным данным Хранилища дополнительные детали, в частности, детальную информацию в реальном времени (например, сопоставление исторических данных с текущей ситуацией).

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

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

И наконец, очень важен постоянный мониторинг производительности и эффективности этих технологий в условиях конкретной инфраструктуры. Их производительность в значительной степени будет зависеть от скорости архивирования данных, размеров и детальности данных, а также от эффективности функционирования системы в условиях полной нагрузки. При определении производительности также следует оценить влияние, которые эти инструменты могут оказывать на операционные приложения и системы. Поэтому необходим постоянный мониторинг и этого влияния. [7]

2.3 Цели интеграции

Интеграция корпоративных приложений (Enterprise Application Integration) – подход, предусматривающий связывание приложений, приобретенных или разработанных внутри самой компании, с тем чтобы они наилучшим образом поддерживали бизнеспроцессы. EAI предоставляет пользователям инструментальные средства для моделирования бизнес-процессов и связи этих приложений с промежуточным ПО, которое может обеспечить взаимодействие с другими приложениями за счет обмена сообщениями. [8]

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

В разрезе информационных технологий, EAI — это процесс объединения различных приложений, разработанных независимо друг от друга, таким образом, чтобы они работали как единое целое, прозрачно для пользователя. Эти приложения могут использовать различные технологии и оставаться независимо управляемыми. [2]

Зачастую корпоративные приложения распределяются между несколькими компьютерами за счет использования n-уровневой архитектуры (усовершенствованный вариант архитектуры клиент/сервер).

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

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

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

Можно сформулировать 3 общие цели интеграции приложений:

• уменьшить стоимость эксплуатации совокупности приложений

предприятия;

• увеличить скорость выполнения типичных задач или гарантировать сроки

их выполнения;

• поднять качество выполнения задач за счет формализации процессов и

минимизации человеческого фактора, как основного источника ошибок.

В качестве целей конкретных интеграционных проектов обычно фигурируют более четкие формулировки. Например: «обеспечить формирование финансовой отчетности предприятия в срок не более одной недели после завершения финансового периода»; «уменьшить время оформления продажи с одного часа до 15 минут»; «уменьшить количество персонала, задействованного для поддержания в актуальном состоянии справочников и классификаторов, с 20 до пяти человек». Но обычно все, в конце концов, сводится к общим целям, которые можно сформулировать в еще более общем виде — уменьшить операционные расходы предприятия или организации. Поэтому интеграционные проекты часто оказываются в выигрышном положении с точки зрения обоснования перед людьми, принимающими решение о финансировании проектов: расчет показателей возврата инвестиций для таких проектов может выглядеть достаточно привлекательным.

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

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

EAI — это сложная и многогранная технология, которая охватывает все уровни корпоративной системы — ее архитектуру, аппаратное и программное обеспечение и процессы. EAI означает проведение интеграции на следующих уровнях: [1]

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

— Интеграция приложений (Application Integration) На этом уровне интеграции целью является объединение данных или функции одного приложения с другим, благодаря чему обеспечивается интеграция, близкая к реальному времени. Интеграция приложений используется — и это далеко не полный список — для интеграции B2B, внедрения CRM-систем, которые интегрированы с корпоративными серверными приложениями, web-интеграции и построения web-сайтов, которые поддерживают многочисленные бизнес системы. Кроме того, может потребоваться проведение специальной интеграции, особенно когда требуется интегрировать существующее приложение с вновь устанавливаемым ERP-приложением.

— Интеграция данных (Data Integration) Один из самых распространенных в настоящее время подходов — создание хранилищ данных (datawarehouses).

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

— Стандарты интеграции (Standards of Integration) Для обеспечения интеграции данных необходимо выбрать стандартные форматы для данных. Стандартами интеграции являются те форматы, которые поддерживают использование и распространение информации и бизнес данных, т.е. стандарты являются основой для проведения интеграции корпоративных приложений. К ним относятся COM+/DCOM, CORBA, EDI, JavaRMI и XML.

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

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

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

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

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

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

Для преодоления описанных выше трудностей можно воспользоваться четырьмя основными подходами.

1. Передача файла (File Transfer).

Одно приложение создает файл, а другое приложение считывает его. Приложения должны согласовать имя файла, его расположение, формат, время записи/считывания, а также процедуру удаления.

2. Общая база данных (Shared Database).

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

3. Удаленный вызов процедуры (Remote Procedure Invocation).

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

4. Обмен сообщениями (Messaging).

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

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

2.4 Издержки и проблемы интеграции

Идея интегрировать развернутые в компании системы обычно не возникает беспричинно. Однако прежде чем решаться на интеграционный проект, нужно взвесить все «за» и «против». Ниже приведены основные проблемы, с которыми сталкиваются компании при ведении подобных проектов. [11]

Недооценка эффекта от интеграции может серьезно подорвать энтузиазм компании при рассмотрении соответствующего проекта. Однако анализ интеграционных проектов показывает, что 100% прямой выгоды достигается лишь в редких случаях. В большинстве же внедрений прямая прибыль от проекта составляет всего 10-15%, а косвенная – до 85-90%.

Недооценка затрат на персонал. Анализ проектов на Microsoft BizTalk показывает, что до 70-80% затрат может приходиться на человеческий фактор (оплату собственных специалистов и внешних консультантов) и лишь 10-15% затрат приходится на ПО и оборудование.

Использование других технологий приводит к увеличению затрат на оборудование и ПО, но при этом обычно возрастает и сложность проекта (он ведется в гетерогенной среде), и себестоимость специалистов. Интеграционный проект может длиться от года до трех лет. На первом этапе имеет смысл привлекать консультантов, затем выгоднее действовать силами своего персонала, обученного на первом этапе. В этом контексте стоит обратить внимание на интегрированность подсистем продукта -свойства, наличие которого позволяет значительно снизить данную статью расходов (позитивный пример в этом смысле дает ИВК «Юпитер»).

Недооценка затрат на ПО. Аналитическая компания Giga указывает, что в больших компаниях на первое место (более 60%) по затратам может выйти стоимость коннекторов к системам.

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

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

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

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

Недооценка гетерогенности или незрелости коммуникационной среды. Иногда интегрируются в основном приложения Windows в пределах одного здания, но это бывает далеко не всегда.

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

Недооценка важности обеспечения безопасности. Интеграция ставит много вопросов в области обеспечения безопасности. Появление промежуточного звена в КИС, куда данные передаются и где они могут долго храниться, и вообще увеличение числа связей может (если не приняты контрмеры на уровне разработчика и администратора) ослабить защищенность системы от несанкционированного доступа.

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

Стоит также подумать, как передаются пароли из межплатформного ПО в интегрируемые приложения, ведь многие готовые коннекторы работают в системе с собственными логинами и паролями.

2.5 Предположительная ценность принципа интеграции данных

Прозрачность базовой неоднородности информации для пользователя

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

Преимущество: от начала разработки до выхода на рынок

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

Сокращение затрат на разработку и обслуживание

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

Преимущество по производительности

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

Преимущество многократности использования

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

Улучшенное управление

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

2.6 Критерии интеграции

Для оценки качества, полноты, целесообразности интеграции необходимы определенные критерии. В [9] выделяются основные критерии, влияющие на выбор способа интеграции приложений.

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

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

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

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

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

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

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

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

Таким образом, различных критериев, влияющих на выбор способа интеграции приложений, относительно немного. Универсального способа интеграции приложений, в одинаковой степени удовлетворяющего всем рассмотренным выше критериям, не существует, однако существует способ, оптимальный в рамках конкретного интеграционного сценария. Каждый стиль интеграции имеет свои преимущества и недостатки. Интеграционное решение может основываться на использовании нескольких различных стилей. Подобные «гибридные» решения поддерживаются многими пакетами для интеграции и связующим ПО.

Рассмотрим существующие подходы к интеграции и связанные с ними преимущества и недостатки.

Передача файла (File Transfer)

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

Стратегическим решением является выбор общего формата файлов. Еще совсем недавно (лет 5-10 назад) наиболее распространенным стандартным форматом файлов считался простой текстовый файл. Но сейчас современные интеграционные решения основываются на использовании формата XML.

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

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

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

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

Общая база данных (Shared Database)

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

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

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

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

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

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

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

Удаленный вызов процедуры (Remote Procedure Invocation)

Несмотря на то, что передача файла (File Transfer) и общая база данных (Shared Database) позволяют наладить обмен информацией между приложениями, зачастую этого оказывается недостаточно. Например, изменение адреса проживания клиента может потребовать выполнения некоторых действий, таких как проверка допустимости нового адреса.

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

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

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

Такой механизм называется удаленный вызов процедуры (Remote Procedure Invocation).

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

Удаленный вызов процедуры поддерживается множеством технологий, таких как CORBA, COM, .NET Remoting и Java RMI. Зачастую реализация удаленного вызова процедуры предусматривает наличие дополнительных возможностей, например, поддержки транзакций.

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

Обмен сообщениями (Messaging)

Передача файла (File Transfer) и общая база данных (Shared Database) позволяют объединенным приложениям получить доступ только к общим данным, но не к общей функциональности. Этот недостаток можно устранить, если использовать Удаленный вызов процедуры (Remote Procedure Invocation), но ценой будет сильное связывание интегрируемых приложений. Часто же одной из задач интеграции является оперативный обмен данными между слабо связанными приложениями.

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

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

Асинхронный обмен сообщениями способен устранить большинство недостатков распределенных систем. Одновременная доступность получателя и отправителя не является обязательной для передачи сообщения.

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

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

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

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

Взаимное отношение описанных выше подходов можно представить в графическом виде (представлено на рисунке 4).

Стрелками указаны преимущества одного подхода над другим.

сильное связывание слабое связывание сильное связывание

увеличение Обмен интеграция

частоты обмена файлами функциональности

Удаленный вызов

частый обмен процедуры

малыми объемами

данных частоты обмена

Обмен

сообщениями увеличение

Общая база интеграция

данных функциональности

Рисунок 4 – Взаимное отношение подход интеграции 3 Задача интеграции западной ERP-системы и системы российского

бухгалтерского учета

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

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

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

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

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

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

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

В качестве системы российского бухгалтерского учета (РБУ) может быть выбрана любая из использующихся в настоящее время систем, успешно зарекомендовавших себя в этой области. Следующие характеристики [12] следует учитывать при выборе такой системы:

• открытость системы: доступность информации о форматах хранения

данных и возможность создания пользовательских приложений;

• уровень соответствия выходных форм фискальной отчетности

требованиям нормативов;

• регулярность обновления форм отчетности фирмой-производителем;
• наличие у пользователя опыта работы с какой-либо определенной

системой и, соответственно, наличие обученного персонала;

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

При использовании системы обмена данными работа по вводу всех первичных документов выполняется в ERP-системе, а российская система бухгалтерского учета используется для расчета зарплаты и формирования фискальной отчетности.

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

Перечисленные выше задачи, которые должна решать система обмена данными, и предположения о характере ее использования позволяют сформулировать следующие основные требования к разрабатываемой системе передачи данных из ERP-системы в систему РБУ:

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

Обеспечение передачи информации из тех разделов учета, которые по каким-либо причинам, ведутся в системе РБУ, а данные из них требуются для работы разделов, обслуживаемых в ERP-системе.

Гарантированность полноты передаваемой информации с учетом возможного внесения изменений и дополнений в информационную базу.

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

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

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

4 Возможные подходы интеграции

Для интеграции были разработаны свои шаблоны, еще их называют паттерны интеграции.

Шаблоны (паттерны) проектирования — это проверенный способ представления накопленного опыта и знаний в таких областях, как архитектура программных приложений, объектно-ориентированное проектирование и создание интеграционных решений.

Каждый шаблон состоит из описания некоторой проблемы проектирования, обсуждения исходных условий и представления сбалансированного решения. В большинстве случаев предлагаемое решение является результатом длительного процесса поиска. Каждый шаблон «вбирает» в себя опыт, накопленный старшими разработчиками и архитекторами в попытке дать оптимальный ответ на конкретную задачу интеграции. Шаблон нельзя «придумать»; к нему можно прийти в результате длительных «полевых» испытаний, извлекая уроки из собственных ошибок.[9]

Паттерны проектирования можно разделить на три группы: [1]

• паттерны проектирования распределения обязанностей и взаимодействия

отдельных классов или объектов информационных систем;

• архитектурные паттерны;
• паттерны интегрирования информационных систем.

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

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

Перечисленные шаблоны указаны в порядке возрастания «масштаба» решаемых задач.

1 Структурные паттерны интеграции

1.1 Взаимодействие «точка — точка»

У одной из систем есть интерфейс для доступа к ней активной системы. При таком взаимодействии одна система является активной, другая пассивной, т.е. активная система управляет второй. Под активной системой подразумевается система, использующая интерфейс другой системы, а под пассивной — система, предоставляющая интерфейсы для пользования другим системам и не использующая напрямую интерфейсы других систем.

Схема такого взаимодействия представлена на рисунке 5. Данный паттерн применяется, в основном, при стихийной интеграции систем.

Рисунок 5 – Схема взаимодействия «точка-точка»

Данный метод взаимодействия соответствует требованиям активной системы, но непригоден для использования другой системой в качестве активной.

1.2 Взаимодействие «звезда» (интегрирующая среда)

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

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

Рисунок 6 – Схема взаимодействия «звезда»

Интегрирующая среда имеет универсальный интерфейс для доступа активных систем. Кроме того интегрирующая среда может использовать интерфейсы пассивных систем. Интегрирующая система включает в себя реализацию основных уровней интегрирующей среды (наглядно схема представлена на рисунке 7):

• базовый уровень интегрирующей среды: представляет собой ядро

интегрирующей среды. Этот уровень содержит платформу для исполнения

сценариев транзакции, базовый функционал по взаимодействию

приложений, службы протоколирования и мониторинга состояния

интегрирующей среды;

• уровень сценариев интеграции: предполагает наличия графической схемы

обмена сообщениями между системами, алгоритмы преобразования и

маршрутизации этих сообщений;

• транспортный уровень интегрирующей среды: отвечает за физическую

доставка сообщений между компонентами;

• уровень адаптеров компонентов: взаимодействие с системой посредством

ее API, генерация сообщений, передача сообщений базовому уровню

посредством транспортного уровня.

Рисунок 7 – Основные уровни интегрирующей среды

1.3 Смешанный способ взаимодействия

В данном способе совмещены первые два подхода к взаимодействию систем (рисунке 8.).

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

Рисунок 8 – Смешанный способ взаимодействия

2 Паттерны по методу интеграции

2.1 Интеграция систем по данным (data-centric).

Данный поход был исторически первым в решении проблемы интеграции приложений. Этот подход характерен для традиционных систем «клиент-сервер». При интеграции приложений по данным считается, что основным фактором при построении информационной системы является общая база данных, предназначенная для коллективного доступа. Основная идея этого подхода состоит в том, что приложения объединяются в систему вокруг объединенных данных под управлением СУБД. Интегрирующей средой является промышленная СУБД (как правило, реляционная) со стандартным интерфейсом доступа к данным (обычно это SQL).

Все функции прикладной обработки размещаются в клиентских программах.

Существенным недостатком такого подхода является необходимость передачи больших объемов данных.

2.2 Функционально-центрический (function-centric) подход.

При функционально-центрическом подходе основным фактором являются сервисы — общеупотребительные прикладные и системные функции коллективного доступа, реализованные в виде серверных программ со стандартным API. В виде сервисов реализуются такие функции, как различного вида прикладная обработка, контроль информационной безопасности, служба единого времени, централизованный файловый доступ и т.п. Все сервисы являются интегрированными в том же смысле, что и интегрированные данные в базе данных коллективного доступа, т.е. реализуемые сервисами функции достоверны, непротиворечивы и общедоступны. Концепция интеграции в данном подходе состоит в том, что приложения объединяются в систему вокруг интегрированных сервисов со стандартизованным интерфейсом. Интегрирующей средой является сервер приложений или монитор транзакций со стандартным API. При использовании функционально-центрического подхода приложение декомпозируется на три уровня (взаимодействие с пользователем, прикладная обработка, доступ к данным).

Общая архитектура системы является трехзвенной: клиентское приложение функциональные сервисы — сервер базы данных.

2.3 Объектно-центрический (object-centric).

Объектно-центрический подход, основанный на стандартах объектного взаимодействия CORBA, COM/DCOM, .NET и пр. и является композицией типов объединения систем по данным и обьектно-центрического. Концепция интеграции в состоит в том, что системы объединяются вокруг общедоступных распределенных объектов со стандартными интерфейсами. Характерными особенностями данного подхода являются:

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

Интегрирующей средой является брокер объектных запросов с интерфейсом в стандарте CORBA или DCOM. Общая архитектура системы формируется на основе распределенных объектов и является n-звенной.

2.4 Интеграция на основе единой понятийной модели предметной области (concept-centric).

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

Средством решения такой проблемы интеграции является разработка компонентов ОЯВ (общесистемный язык взаимодействия), основанных на единой понятийной модели, описывающей объекты предметной области, их взаимосвязи и поведение. Как правило, ОЯВ является языком сообщений высокого уровня и имеет достаточно простой синтаксис и естественно-языковую лексику на основе бизнесобъектов. Единая понятийная модель представляет собой базу метаданных, хранящую описания интерфейсных бизнес-объектов каждого из компонентов и отношения (связи) между этими объектами. Между интегрируемыми компонентами и их описаниями в базе метаданных должно поддерживаться постоянное соответствие. Хранящиеся в базе метаданных описания и сам язык взаимодействия строятся как независимые от конкретного интегрирующего программного обеспечения. Преобразование сообщений на ОЯВ в вызовы функций той или иной интегрирующей среды обеспечивается дополнительной интегрирующей оболочкой с единым интерфейсом, который предназначен только для обмена сообщениями на ОЯВ. Единицей информационного обмена в рассматриваемом подходе являются сообщения, поэтому целесообразно строить такое программное обеспечение на основе программных продуктов класса MOM (Message Oriented Middleware – это системное программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями).

3 Паттерны интеграции по типу обмена данными

3.1 Файловый обмен

Данный тип интеграции основывается на концепции «точка-точка» (подход 1.1), системы экспортируют общие данные в формате пригодном для импорта в другие системы. В последнее время в качестве единого формата файлов обмена все чаще выбирают XML, как наиболее распространенный и поддерживаемый в мире.

XML (eXtensile Markup Language) — расширяемый язык гипертекстовой разметки, используемый в интернете. Язык XML использует структуру тегов и определяет содержание гипертекстового документа. XML позволяет автоматизировать обмен данными, при этом объем программирования будет незначительным.

Большинство систем позволяют производить экспорт-импорт данных в формате XML, на рынке программного обеспечения существует большое количество программ, позволяющих в удобной форме создавать так называемые «преобразователи» XML данных на основе технологии XSLT.

XSLT (eXtensible Stylesheet Language for Transformations) – технология, предназначенная для преобразования XML документов. С ее помощью можно описать правила преобразования, которые позволят преобразовать документ в другую форму (структуру) или формат, например, в текстовый или HTML.

Схема такого взаимодействия представлена на рисунке 9.

Э

И

К Общие М

С

Система 1 П данные П Система 2

О

О

Р

Р

Т

Т

Рисунок 9 – Схема файлового обмена

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

3.2 Общая база данных

Является реализацией подхода 2.1. Данный тип интеграции позволяет получить полностью интегрированную систему приложений, работающую с едиными данными в любой момент времени. Изменения, произведенные в одном из приложений, автоматически отражаются в другом. За корректность данных отвечает многопользовательская СУБД. Схема такого взаимодействия представлена на рисунке 10.

Система 1 Система 2 Система 3

Совместно

используемые

данные

Рисунок 10 – Схема общей базы данных

Этот подход удобно использовать для вновь создаваемых систем, но затруднительно интегрировать уже существующие системы.

3.3 Удаленный вызов процедур

Данный тип интеграции является реализацией объектно-центрического подхода 2.3. При таком подходе приложения интегрированы на уровне функций. Изменение данных в другой системе происходит также посредством вызова функций. Схема такого взаимодействия представлена на рисунке 11.

Вызов функции

интерфейс

прокси

Система 1 Система 2

результат

Рисунок 11 – Схема удаленный вызов процедуры

Каждая из систем самостоятельно заботится о поддержке данных в корректном состоянии, что является довольно сложно задачей.

3.4 Обмен сообщениями

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

Схема такого взаимодействия представлена на рисунке 12.

Система 1 Система 2 Система 3

Шина обмена сообщениями

рис. 12 – Схема обмена сообщениями

5 Обмен данными Microsoft Dynamics Nav – 1С: Предприятие

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

В качества зарубежной ERP-системы выбрана система «Microsoft Dynamics Nav», поставляемая корпорацией Microsoft. Для такого выбора есть ряд причин:

• система, включает функциональные возможности для управления

финансами, складом, производством, отношениями (CRM), дистрибуцией

(SCM) и электронной коммерцией;

• одно из самых выгодных предложений в мире по критерию:

Состав Продукта (Функциональные + Технические Возможности) /

Стоимость Продукта;

• первая западная система, сертифицированная Министерством Финансов

РФ.

На данный момент, разработчиком поддерживаются 4-ая и 5-ая версии продукта.

В роли системы РБУ выступает «1С: Бухгалтерия», основанная на платформе «1С: Предприятие 8.1». На такой выбор повлияли следующие факторы:

• фирма-разработчик ежеквартально обновляет все формы

регламентированной отчетности в соответствии с изменениями

российского законодательства;

• открытость и хорошая документированность платформы «1С:

Предприятие», позволяющая конечному пользователю при необходимости

вносить в нее необходимые изменения самостоятельно или с привлечением

сторонних организаций, не связанных непосредственно с компанией 1С;

• достаточно широкая распространенность и известность системы.

На момент написания работы, актуальной версией конфигурации 1С: Бухгалтерия была 1.6.14.9, актуальная версия платформы 1С: Предприятие — 8.1.13.

В графическом виде разделение обязанностей между названными выше системами представлено на рисунке 13.

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

• требуется обеспечить только интеграцию данных, интеграция

функциональности как задача не рассматривается;

• минимизация совокупной стоимости интеграционного решения;
• относительная простота поддержки интеграционного решения;
• нежелательность использования дополнительного промежуточного ПО.

Интегрируемые системы были разработаны в разное время, и, что вполне закономерно, основаны на разных принципах. Оба приложения могут использовать СУБД MSSQL в качестве сервера баз данных, но подход «общая база данных» не может быть использован по причине разительного различия в способах хранения информации в каждой системе.

ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ

ПЕРВИЧНЫЕ ДОКУМЕНТЫ

Оперативный Оперативное Оперативный Оперативный

управлен- плани- бухгалтер- налоговый

ческий рование ский учет

учет учет

(в том числе финансовое)

ПЛАНИРОВАНИЕ

БУХГАЛТЕРСКИЙ

УПРАВЛЕНЧЕСКИЙ

НАЛОГОВЫЙ

УЧЕТ

УЧЕТ

УЧЕТ

Управленческий учет и планирование Регламентированный учет

(в целом по предприятию) (в отдельным организациям)

Microsoft Dynamics NAV 1С: Бухгалтерия

Рисунок 13

Дополнительное ограничение, которое ограничивает использование дополнительного ПО, делает невозможным использование подхода «обмен сообщениями». Другое дополнительное ограничение, убирающее из задач интеграцию функциональности, по сути, ограничивает использование «удаленного вызова процедуры».

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

В качестве формата файлов обмена был выбран XML. XML обладает рядом преимуществ перед другими форматами описания данных при обмене данными между приложениями: [10]

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

Поддержка производителями. Библиотеки для работы с XML созданы для всех ведущих языков программирования и популярных СУБД. Использование этих библиотек позволяет существенно уменьшить объем кодирования при разработке «шлюзов» между приложениями.

Самодокументированность. XML-документ «читабелен» для человека. Кроме того, наличие внутри него описания данных позволяет создавать автоматические программы их обработки, например универсальные модули загрузки данных, поступающих из разных систем в единое хранилище.

Иерархичность. Это ключевое свойство языка. В отличие от формата CSV (текстового файла с разделителем «»), XML позволяет легко описывать сложные структуры данных с неограниченной вложенностью объектов.

Объектность. Структура данных XML сочетается с объектно-ориентированной моделью программирования. Каждый тег XML-документа может быть поставлен в соответствие классу или свойству класса обрабатывающей программы. С другой стороны, есть возможность описать в XML-формате каждый прикладной объект предметной области как отдельный тег.

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

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

Для обмена данными используются следующие средства:

— на стороне MS Dynamics NAV — инструмент PBiz XML-Data Exchange Manager (XML-DEM), распространяемый в виде дополнения к системе Microsoft Dynamics NAV. XML-DEM позволяет легко и удобно настраивать различные схемы для обмена данными, в автоматическом и интерактивном режиме производить выгрузку и загрузку данных, обеспечивая тем самым интеграцию между различными приложениями, поддерживающими стандарт XML. Инструмент легок в освоении и не требует глубоких знаний в области XML. С помощью этого средства можно сформировать файл формата xml с произвольной структурой.

— на стороне 1С: Бухгалтерия – стандартная внешняя обработка «Универсальный обмен данными в формате XML». Эта обработка входит в состав поставки конфигурации «Конвертация данных 2.0». Названная обработка позволяет производить выгрузку и загрузку данных в/из базы 1С. Правила, по которым данные будут выгружаться или загружаться, определяются с помощью конфигурации «Конвертация данных 2.0». Но, несмотря на всю мощность этого инструмента, он предназначен для обмена данными между приложениями на базе платформы 1С: Предприятие, и как следствие этого ограничения, формат xml файлов обмена определен разработчиками этой конфигурации.

— из-за сложностей, которые могут возникнуть при формировании в системе MS Dynamics Nav xml файла со структурой, подходящей для загрузки в базу данных 1С: Бухгалтерии с помощью названной выше обработки, используется промежуточное XSL преобразование структуры xml файла. Описание используемых форматов xml-файлов и структура XSL-преобразования представлены в Приложении Б.

Процедура передачи данных между системами состоит из четырех основных этапов.

1. Создание файла обмена. Отправитель создает XML-файл, содержащий

полезную информацию.

2. XSL-преобразование XML-файла.

3. Отправка файла. Файл обмена передается от отправителя к получателю.

4. Загрузка. Получатель считывает полезную информацию из XML-файла.

Схема процедуры передачи данных между системами представлена на рисунке 14.

В рамках описываемого решения, в качестве получателя и отправителя может выступать любая из систем. Но существует одна техническая особенность: xslпреобразование xml-файла выполняется только на стороне MS Dynamics NAV (т.е. после выгрузки данных из этой системы, либо непосредственно перед загрузкой данных в нее); это ограничение обусловлено отсутствием возможности выполнения такой операции на стороне системы 1С: Бухгалтерия с помощью обработки «Универсальный обмен данными в формате XML».

Microsoft Dynamics NAV

чтение/ создание/ XSL

запись чтение преобра данных PBiz XML файла зование

База Data Exchange

Данных Manager XML XML

передача

файла

запись/ чтение/

чтение создание

данных Универсальный файла

База обмен данными

Данных в формате XML XML

1С: Бухгалтерия

Рисунок 14 – Схема загрузки/выгрузки XML-документов

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

Определение списка документов и справочников, подлежащих переносу между системами. Также надо определить в каком направлении, какие данные переносятся (т.е. какой справочник в какой системе будет заполняться, а в какую систему данные будут переноситься).

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

Для документов и справочников, которые ведутся на стороне системы 1С: Бухгалтерия и подлежат переносу в MS Dynamics NAV, необходимо создать план обмена в конфигурации в «Конвертации данных 2.0» на базе платформы 1С: Предприятие. В этом плане обмена определяются правила выгрузки данных из любой конфигурации, основанной на платформе 1С: Предприятие (причем как типовой, так и любой произвольной)

Для документов и справочников, которые загружаются или выгружаются из системы MS Dynamics NAV необходимо создать объекты обмена XML-DEM в соответствии с результатами шагов 1 и 2.

Объекты обмена XML-DEM разрабатываются на основание определенного метода, подробно описанного в приложении В.

Положительные стороны:

• Решение слабо связывает интегрируемые системы, т.е. внутренние

изменения одной из систем слабо влияют на интерфейс взаимодействия;

• количество изменений в системах, которые необходимо произвести для

достижения цели, напрямую зависит от разнородности внутренней

структуры приложений. В случае решаемой задачи интеграции систем

Incadea и 1С: Предприятие, в системе Incadea были внесены

незначительные изменения (более подробно об изменениях этой системы

описано в п.)

Отрицательные стороны:

• заказчику необходимо приобрести Add-on для системы Microsoft Dynamics

Nav под названием PBiz XML Data Exchange Manager (XML-DEM).

Это

дополнение к системе значительно упрощает процесс интеграции, но, за

его использование необходимо заплатить сумму денег (хотя и небольшую);

• из-за невозможности использования единого формата данных, в решении

использован внешний java-скрипт, выполняющий xsl-преобразование, но

его выполнение прозрачно для пользователя.

Хотя в данном конкретном решении проблемы своевременности доставки данных ложится на плечи ответственных пользователей системы

6 Практическое применение

Практическое применение метода разработки, подробно описанного в приложении В, будет показано на примере реализации шлюза между системой Incadea на базе Microsoft Dynamics NAV и конфигурацией 1С: Бухгалтерия на базе платформы 1С: Предприятие. Приводимые примеры являются частью проекта по интеграции выше названных систем, который выполнялся ООО «Интант-Сервис» в рамках договорных работ для компании «Крок».

На первом этапе реализации шлюза необходимо определить список документов, которые необходимо передавать из одной системы в другую. В таблице 1 представлено соответствие документов, переносимых из Incadea в 1С: Бухгалтерию, а в таблице 2 – из 1С: Бухгалтерии в Incadea. Таблица 1 – Соответствие документов (экспорт из Incadea в 1С: Бухгалтерию) № п/п Документ Incadea Документ 1С 1. Покупка Учт. Счет Поступление товаров и услуг 2. Запчасти — Перемещение ТМЦ Перемещение товаров 3. Продажа Учт. Счет Реализация товаров и услуг 4. Покупка Запчастей – Кредит нота Возврат Товаров Поставщику 5. Продажа Запчастей – Кредит нота Возврат Товаров От Покупателя 6. Учт. Заказы инвентаризации Оприходование товара 7. Учт. Заказы инвентаризации Требование накладная 8. Товар Учт. Акт Списания Требования накладная 9. Сервис – Учт. Счет продажи Реализация товаров и услуг

Требование Накладная 10. Сервис – Учт. Счет продажи Реализация товаров и услуг

Требование Накладная 11. Автомобиль — Учт. Счет Покупки Поступление товаров и услуг 12. Автомобиль — Учт. Счет Продажи Реализация товаров и услуг 13. Клиент – Учт. Кассовые операции Приходный Кассовый Ордер 14. Клиент – Учт. Кассовые операции Платежное поручение Входящее 15. Клиент – Учт. Кассовые операции Расходный Кассовый Ордер Таблица 2 – Соответствие документов (Импорт в Incadea из 1С: Бухгалтерии) № п/п Документ 1С Документ Incadea 1. Входящее Платежное Поручение Журнал Оплат 2. Исходящее Платежное Поручение Журнал Оплат

На втором этапе для каждого объекта, передаваемого между системами, необходимо определить в каком случае и по какому алгоритму формируется этот объект. В таблице 3 представлен пример такого описания для документа в системе 1С Приходный Кассовый Ордер. Таблица 3 – Пример описания соответствия объектов Таблица Incadea Документ 1С Комментарий Учт. Кассовые Приходный Таблица Учт. Кассовые операции строки операции Кассовый фильтруется по полю Тип = Клиент, Payment (In/Out)

Ордер = Payment-In или Correction Payment-In

Для каждой строки таблицы Учт. Кассовые

операции, удовлетворяющей условиям фильтров, в

1С создается отдельный документ.

Далее следует выделить набор реквизитов передаваемого объекта, значение которых следует заполнить в загружаемом объекте. Кроме этого необходимо определить соответствие полей объектов в разных системах с указанием алгоритма заполнения значений. В таблице 4 показан пример соответствия полей для документа Приходный Кассовый Ордер (в системе 1С).

Таблица 4 – Пример соответствия полей объектов документа 1С «Приходный кассовый ордер» и таблицы Incadea «Учт. Кассовые операции»

Поле 1С Поле Incadea Алгоритм Шапка документа Номер Автоматически следующий номер

документа в 1С Дата Системная дата и время экспорта данных Организация Код Организации Счет Касса Константа «50.01» Вид Операции Константа «Оплата от покупателя» Контрагент Код Источника Валюта Документа Код валюты Сумма Документа Сумма (РУБ) Отражать в Налоговом Константа «Да» Учете Табличная часть Расшифровка платежа Договор контрагента Код Договора Курс Взаиморасчетов Рассчитывается по формуле:

Сумма / Сумма (РУБ) Сумма Платежа Сумма (РУБ) Сумма Взаиморасчетов Сумма Ставка НДС Если для данного Кода договора в

таблице Договоры значение поля Тип

Договора = Сервис, то передается

значение «Без НДС», иначе «НДС 18%» Сумма НДС Рассчитывается автоматически Счет Учета Расчетов С 1С выбрать регистр сведений Счета Контрагентом Учета Расчетов С Контрагентами.

Отфильтровать по измерениям

Организация, Контрагент и Договор

(поля документа соответственно

Организация, Контрагент, Договор

Контрагента).

Выбрать значение ресурса

Счет Учета Расчетов С Покупателем

Если это значение пусто, то брать

константу = «62.01» Счет Учета Расчетов 1С выбрать регистр сведений Счета По Авансам Учета Расчетов С Контрагентами.

Отфильтровать по измерениям

Организация, Контрагент и Договор

(поля документа 1С соответственно

Организация, Контрагент, Договор

Контрагента).

Выбрать значение ресурса

Счет Учета Авансов Полученных

Если это значение пусто, то брать

константу = «62.02»

Третий этап – реализация правил обмена с помощью XML-DEM (на стороне MS Dynamics NAV), по которым данные будут выгружаться или загружаться.

В качестве простого примера будет рассмотрено создание объектов обмена для экспорта из Incadea, источником является таблица Учт. Кассовые операции, приемником – документ Приходный кассовый ордер.

На рисунке 15 представлена форма объекта обмена. В представленном объекте настроена выгрузка реквизитов документа согласно соответствию, описанному в таблице 4. В этом примере используются префиксы в названии полей, например d, s02, tab01; они определены в файле xsl-преобразования и используются для подстановки типа реквизита.

Рисунок 15

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

Настройка объекта обмена для импорта данных происходит аналогичным образом, с той разницей, что заполняется колонка не ExportValue (как в случае экспорта), а ImportValue. На рисунке 16 показан пример объекта обмена для импорта в Incadea документа по наличным оплатам; источником является документ Исходящее Платежное Поручение, приемником – таблица Журнал оплат.

Рисунок 16

После создания всех необходимых объектов обмена, они объединяются в пакет обмена. Объединение происходит на основании какой-то логической связанности между объектами, например, объекты, предназначенные для выгрузки кассовых документов, могут быть объединены вместе. На рисунке 17 представлен пакет обмена под названием «Перемещение товаров и услуг», в котором объединены объекты, отвечающие за выгрузку документов: Приходный кассовый ордер, Расходный кассовый ордер, Платежное поручение входящее. Для всех этих объектов указан общий файл выгрузки (поля Export path и Export file) и путь запуска java-скрипта, выполняющего xslпреобразование (поле Script File After).

Эти поля заполняются администратором системы и не должны впоследствии меняться пользователями.

Рисунок 17

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

Для организации работы шлюза, на стороне платформы 1С: предприятие используется обработка «Универсальный обмен данными в формате XML», которая входит в состав всех типовых конфигураций, поставляемых фирмой 1С.

При загрузке данных в конфигурацию 1С: Бухгалтерия с помощью названной выше обработки необходимо указать на закладке «загрузка данных» полный путь к xml-файлу, после чего нажать кнопку «Загрузить данные». На рисунке 19 показан пример экранной формы этой обработки.

Рисунок 18

Для выгрузки данных из конфигурации 1С: Бухгалтерия используется та же обработка, что и при загрузке, только необходимо выбрать закладку «выгрузка данных». на рисунке 20 показан пример экранной формы этой закладки. Внешний вид такой формы похож на форму пользовательского интерфейса обмена данными, созданного на стороне Incadea. Рисунок 19

Рисунок 20

Как видно на рисунке 20, необходимо заполнить 2 обязательных поля: «путь к файлу шаблона» и «путь к файлу выгрузки», отметить список выгружаемых объектов на закладке «Выгружаемые данные». Также, если это необходимо, можно задать дополнительные фильтры на выгружаемые объекты на той же закладке. Затем нажать кнопку «выгрузить данные», после этого произойдет экспорт информации в указанный файл.

Для создания файла-шаблона достаточно однажды проделать следующую достаточно простую процедуру.

• В конфигурации 1С: Бухгалтерия, из которой будет происходить выгрузка,

необходимо получить файл описания метаданных объектов, для этого

используется обработка «Выгрузка описания структуры метаданных»

(названная обработка входит в состав конфигурации «Конвертация данных

2.0» и распространяется бесплатно).

Внешний вид формы обработки

показан на рисунке 21.

Рисунок 21

• В конфигурации «Конвертация данных 2.0» на базе платформы

1С: Предприятие необходимо создать новый объект в справочнике

Конфигурации, используя файл описания метаданных, полученный на

предыдущем шаге.

• В новой конвертации необходимо создать правила конвертации объектов,

которые соответствуют выгружаемым объектам, и правила конвертации

свойств, которые соответствуют реквизитам выгружаемых объектов. На

рисунке 22 показан пример созданного правила конвертации объектов под

названием «ПлатежноеПоручениеВходящееОплатаКлиента». На вкладке

«Конвертация свойств» указаны реквизиты документа, которые будут

выгружаться в файл.

Рисунок 22

— После создания все необходимых правил, необходимо сохранить в файл сделанные настройки с помощью кнопки «Сохранить правила» (она находится в левом верхнем углу на рисунке 22).

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

Заключение

В результате данной работы были достигнуты следующие цели:

1. предложен метод разработки объектов обмена для XML-DEM;

2. разработан план обмена в конфигурации «Конвертация данных 2.0» на

платформе 1С: Предприятие 8.1;

3. разработаны объекты обмена XML-DEM в системе Microsoft Dynamics

NAV;

4. реализовано XSLT-преобразование XML-файлов.

Результаты работы апробированы в ходе коммерческой деятельности ООО «Интант-Сервис» в рамках следующих проектов по интеграции систем MS Dynamics NAV и 1С: Предприятие:

• интеграция автоматизированной системы управления Московской печатной

фабрики ФГУП «Гознак» и комплексной автоматизированной

информационной системы (КАИС) бухгалтерского и налогового учета

ФГУП «Гознак»;

• интеграция системы Icadea (на базе Microsoft Dynamics NAV) и

конфигурации 1С: Бухгалтерия на базе платформы 1С: Предприятие (по

заказу компании Крок);

• интеграция системы автоматизированного управления предприятием

Microsoft Dynamics NAV и конфигурации 1С: Бухгалтерия на базе

платформы 1С: Предприятие для компании ЗАО «Правдинское Свино

Производство»;

— По результатам проведенного исследования и разработки были опубликованы двое тезисов на студенческих конференциях.

Литература

[Электронный ресурс]//URL: https://inzhpro.ru/diplomnaya/vnedrenie-erp-sistemyi-na-predpriyatii/

1. Техническая библиотека CITForum.ru [Электронный ресурс] – Электрон. дан. – М.: Центр Информационных Технологий («ЦИТ»), 2005 — Режим доступа: http://citforum.ru, свободный. 2. Интернет-словарь компьютерных терминов [Электронный ресурс] – Электрон. дан. – М. компания «Incom»: 2005 – Режим доступа: http://incom.ua, свободный. 3. Электронная библиотека socrates.by.ru [Электронный ресурс] – Электрон. дан. – М. 2003. — Режим доступа: http://www.socrates.by.ru, свободный. 4. Автоматизация управления предприятием / В. В. Баронов [и др.]. – М. : Инфра-М, 2000 – 239 с. 5. Интернет-сайт компании «Computer finance» [Электронный ресурс] – Электрон. дан. – М.: компания «Computer finance»: 2002. – Режим доступа: http:// cfin.ru, свободный. 6. Портал для выбора технологий и ИТ-поставщиков TAdviser [Электронный ресурс] – Электрон. дан. – М.: компания TAdviser, 2005. – Режим доступа: http://www.tadviser.ru/, свободный. 7. Интернет-сайт компании «Intersoft Lab» [Электронный ресурс] – Электрон. дан. – М.: компания «Intersoft Lab», 2000. – Режим доступа: http://iso.ru, свободный. 8. Электронный журнал «Computerworld» [Электронный ресурс] – Электрон. дан. – М.: издательство «Открытые системы», 1992. – Режим доступа: http://osp.ru, свободный. 9. Шаблоны интеграции корпоративных приложений / Хоп Г., Вульф. Б. – М:, Вильямс, 2007 – 672 стр. 10. Интернет-сайт компании «Интерфейс Ltd.» [Электронный ресурс] – Электрон. дан. – М.: компания «Интерфейс Ltd.», 2006. – Режим доступа: http://www.interface.ru, свободный. 11. Интернет-сайт журнала «PCweek live» [Электронный ресурс] – Электрон. дан. – М.: ЗАО «СК Пресс», 2007. – Режим доступа: http://www.pcweek.ru, свободный. 12. Интернет-сайт корпорации Microsoft [Электронный ресурс] – Электрон. дан. – корпорация Microsoft, 2005. – Режим доступа: http://www.microsoft.com/Rus/Dynamics, свободный. 13. Интернет-сайт компании Сеть-ЕВЛ [Электронный ресурс] – Электрон. дан. – компания Сеть-ЕВЛ, 2000. – Режим доступа: http://www. evlnet.com/, свободный.

Приложение А.

По данным компании EVLNET сравнительные характеристики ERP-систем представлены в таблице А.1 [13].

Подробно сравнивались системы как отечественного, так и зарубежного производства.

Список сравниваемых систем:

— HansaWorld Enterprise

— Microsoft Dynamics AX

— Microsoft Dynamics NAV

— SAP Business One

— Галактика ERP

— 1C 8.0 УПП

— БУХта Таблица А.1 – Характеристики ERP – платформ

Система HansaWorld Microsoft Microsoft SAP

Галактика ERP 1C 8.0 УПП БУХта Критерий Enterprise Dynamics AX Dynamics NAV Business One

HansaWorld, Microsoft, Microsoft, SAP AG, Галактика, 1С, ООО БУХта, Разработчик

Швеция США США Германия Россия Россия Россия

3-х звенная 2-х или 3-х звенная 3-х звенная

Возможность

Сервер БД и Возможность Сервер БД и

комбинирования

сервер запуска Клиент-сервер и сервер Архитектура 3-х звенная 2-х звенная 2-х и 3-х

приложений нескольких файл-сервер приложений

уровневой

на одном серверов на одном

архитектуры

сервере приложений сервере Количество

до 500 До 1000 До 250 – До 330 До 140 до 300 пользователей Стоимость лицензий за

1000 — 2000 3500 1500-2650 – 250-850 100-400 550 рабочее место,

Евро Стоимость внедрения (от

25-100% 100-300% 100-300% – 50-100% 100-150% 25-100% стоимости лицензий) Скорость внедрения 1-3 6-15 3-6 1-4 4-18 3-9 – (месяцев)

Нативный Возможность клиент, Терминальный Терминальный Терминальный

Дополнительный WEB удаленного включая – доступ, обмен доступ, обмен доступ,

WEB-интерфейс интерфейс использования мобильные данными данными синхронизация

устройства Продолжение таблицы А.1

Система HansaWorld Microsoft Microsoft SAP

Галактика ERP 1C 8.0 УПП БУХта Критерий Enterprise Dynamics AX Dynamics NAV Business One

Платформы:

Windows, Mac,

Платформы: Платформы:

Linux, Symbian, Платформы: Платформы: Платформы: Платформы:

Windows Windows, Linux

IBM. Windows Windows Windows, Unix Windows, Unix Требования СУБД: MS SQL, СУБД:

СУБД: СУБД: MS SQL, СУБД: MS SQL, СУБД: MS SQL, СУБД: MS

SyBase, IBM Собственная, MS

собственная, Oracle Oracle Oracle SQL

DB2 SQL, PostgreSQL

MS SQL, IBM

DB2, Oracle

Функционал Финансы + + + + + + + Основные

+ – – – + + + средства Бюджетирование + + + + + + + Подотчетные

+ + + – + + +

лица Управление

– + + – + + + персоналом

– (отдельный Консолидация + + – – – +

продукт) Закупки + + + + + + + Продажи + + + + + + + Склад + + + + + + + Производство + + + — / + (сборка) + + + Управление

+ + + – – – + проектами CRM + + + + + + Окончание таблицы А.1

Система HansaWorld Microsoft Microsoft SAP

Галактика ERP 1C 8.0 УПП БУХта Критерий Enterprise Dynamics AX Dynamics NAV Business One Послепродажная поддержка + – – + – – + (Сервис) Электронная + (интеграция с + (интеграция с

+ – – – + почта (e-mail) Outlook) Outlook) Электронная Отдельный

+ – – – – + коммерция продукт Генератор

+ – – + + + +

отчетов

Кол-во

70 000 6 000 55 000 – 6 000 – 2 000 внедрений

Сложное

Простое и Простое и

обновление с

безопасное до безопасное до Обновление Простое Простое – использованием –

больших больших

конверторов

продуктов продуктов

данных

Для каждой Для каждой Русский, Локализация 28 языков страны отдельная страны отдельная – 1 (Русский язык) английский, для

(Русский язык)

локализация локализация стран СНГ

Среда

Собственный Собственный язык Собственный язык Собственный Доработка – Собственный язык разработки.

язык HAL X++ С/SIDE язык

Delphi % модификации типового

менее 1% 20% – – – до 60% до 40% решения при внедрении

Программи Гибкость Параметризация ПрограммированиеПрограммированиеПараметризация Параметризация Программирование

рование

Приложение Б.

XML-формат выгрузки данных из Microsoft Dynamics NAV

При выгрузке данных из системы Microsoft Dynamics NAV с помощью Add-On PBiz XML-DEM, формируется XML-файл следующего формата:

Хотя инструмент XML-DEM позволяет сформировать xml-файл произвольной структуры, но именно представленная выше структура удобнее и быстрее может быть разработана. При формировании достаточно сложной произвольной структуры, сложность реализации объектов обмена для создания xml-файла нужного вида возрастет нелинейно. Поэтому удобнее и менее накладно формировать файлы именно такого вида

XML- формат загрузки данных в 1C

При загрузке данных в систему 1С (на базе платформы 1С: Предприятие 8.1), с помощью обработки «Универсальный обмен данными в формате XML», загружаемый xml-файл должен быть представлен в следующем формате:

Основные части XML-файла, загружаемого в 1С:

— Служебная часть файла – узел ПравилаОбмена;

— В узле ПравилаКонвертацииОбъектов содержится набор правил импорта объектов, они используются обработкой.

В узлах Обработки, ПравилаОчисткиДанных, Алгоритмы, Запросы указываются дополнительные параметры для загрузки пакета данных.

Содержательная часть с данными – набор узлов Объект, Ссылка, Свойство.

Формат узла Объект :

— <�Объект ИмяПравила=»<�Правило>» Нпп=»<�Номер>» Тип=»<�Тип>»/>

— В атрибуте <�Правило> указывается название правила загрузки данных определенного типа, которое должно быть описано в служебной части в узле Правила обмена.

Узел Объект состоит из двух частей:

узел Ссылка и набор узлов Свойство.

В узле Ссылка содержится набор узлов Свойство, по которым будет производиться поиск объекта при загрузке.

Возможные форматы элементов-свойств:

Элементы простого типа.

Простые типы: Строка, Число, Булево, Дата.

Вид xml-узла:

— <�Свойство Имя=»Код» Тип=»Строка»>

— <�Значение>62.01</Значение>

— </Свойство>

— Элементы «сложного» типа. Узлы такого типа содержат в себе узел Ссылка, который идентичен одноименному узлу, описанному выше и набор узлов Свойство, которые могут содержать внутри себя набор элементов простого и сложного типов.

XSLT- преобразование исходного XML- файла

Для обеспечения загрузки данных в формате XML с помощью обработки «Универсальный обмен данными в формате XML», входящей в комплект поставки конфигурации 1С: Бухгалтерия на базе платформы 1С: Предприятие 8.1, необходимо провести преобразование XML-файла к формату, совместимому с данной обработкой. Для этого используется механизм XSLT (eXtensible Stylesheet Language Transformations).

Для облегчения разработки объектов обмена XML-DEM, используются префиксы, используемые при именовании узлов. Тип объекта, соответствующего элементу конфигурации 1С, или свойства указывается в имени узла в качестве префикса. Например: d_Дата означает, что в результате трансформации будет создано свойство с названием Дата, у которого будет атрибут Тип=Дата.

В префиксе может указываться не только тип узла, но и принадлежность узла. Т.е. в какую часть объекта следует отнести это свойство, например, _tab_n_КурсВзаиморасчетов означает, что поле КурсВзаиморасчетов с Типом = Число будет отнесено в узел ТабличнаяЧасть/Запись.

В общем виде префикс состоит из следующих частей: [Место][Тип][Необх.Фигур.Скобки], где:

[Место] ::= ref_| tabXX_

ref_ означает, что свойство будет находиться в узле Ссылка, т.е. по нему будет выполняться идентификация объекта.

tabXX_ означает, что свойство будет находиться в специальном вложенном узле ТабличнаяЧасть/Запись.

XX – числовой код, обозначающий Имя табличной части.

Если эта часть префикса не заполнена, то узел не будет перемещаться в другое место.

[Тип] ::= Код типа.

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

s – используется для типа строка.

d — используется для типа дата.

n — используется для типа число.

b — используется для типа булево.

Для сложных типов коды определяются в файле XSL преобразования. Если код типа не указан, то предполагается, что передан код s.

[Необх.Фигур.Скобки] ::= «__» (два символа подчеркивания).

Если перед названием свойства указано два символа подчеркивания «__», то после трансформации название этого свойства будет заключено в фигурные скобки, например «s___ИмяПредопределенногоЭлемента» – свойство с типом строка будет преобразовано в следующий XML-узел:

— <�Свойство Имя=»{ИмяПредопределенногоЭлемента}» Тип=»Строка»>

Описание реализации запуска механизма XSLT — преобразования

Для реализации автоматического преобразования исходного XML-файла (выгруженного из Microsoft Dynamics NAV) в формат, совместимый с 1С, используется функция запуска скрипта после выгрузки данных.

Скрипт представляет собой программный код, написанный на языке JavaScript (файл с расширением *.js), который исполняется в среде Windows-совместимой ОС.

Скрипт принимает на вход 1 параметр: полный путь к файлу, который необходимо преобразовать. Файл xsl-преобразования, с помощью которого будет производиться преобразование, должен находиться в той же папке, в которой находится исполняемый .js файл. Имя файла *.xsl указывается в коде js-скрипта. Пример заполнения команды выполнения скрипта в интерфейсе XML-DEM показан на рисунке Б.1:

Рисунок Б.1

Результат выполнения скрипта записывается в файл <�имя_скрипта>.log (в случае, показанном на рисунке 14 — 1C_to_NAV.js.log).

Журнальный файл с результатами выполнения скрипта будет создан в той же папке, в которой расположен *.js файл, поэтому у пользователя должны быть права на чтение, запись и выполнение в этой папку.

Приложение В.