Электронный обмен данными ( EDI ) — это концепция электронного обмена информацией, которая традиционно передавалась на бумаге, например, заказы на закупку, предварительные уведомления о поставке и счета-фактуры. Технические стандарты для EDI существуют для того, чтобы облегчить сторонам транзакции таких инструментов без необходимости принятия специальных мер.
EDI существует по крайней мере с начала 1970-х годов, и существует множество стандартов EDI (включая X12 , EDIFACT , ODETTE и т. д.), некоторые из которых отвечают потребностям конкретных отраслей или регионов. Он также относится конкретно к семейству стандартов. В 1996 году Национальный институт стандартов и технологий определил электронный обмен данными как «взаимообмен стандартизированного формата данных между компьютерами. EDI подразумевает последовательность сообщений между двумя сторонами, каждая из которых может выступать как отправитель или получатель. Форматированные данные, представляющие документы, могут передаваться от отправителя к получателю с помощью телекоммуникаций или физически переноситься на электронных носителях». Он различает простое электронное общение или обмен данными, указывая, что «в EDI обычная обработка полученных сообщений осуществляется только компьютером. Вмешательство человека в обработку полученного сообщения обычно предназначено только для условий возникновения ошибок, для проверки качества и в особых ситуациях. Например, передача двоичных или текстовых данных не является EDI, как определено здесь, если данные не рассматриваются как один или несколько элементов данных сообщения EDI и обычно не предназначены для интерпретации человеком в рамках онлайн-обработки данных». [1] Короче говоря, EDI можно определить как передачу структурированных данных по согласованным стандартам сообщений из одной компьютерной системы в другую без вмешательства человека.
Как и многие другие ранние информационные технологии, EDI был вдохновлен разработками в военной логистике . Сложность Берлинского воздушного моста 1948 года потребовала разработки концепций и методов для обмена, иногда более чем через 300-бодовый телетайпный модем , огромными объемами данных и информации о перевозимых товарах. Эти первоначальные концепции позже сформировали первые стандарты TDCC (Комитет по координации транспортных данных) в США. [2] Среди первых интегрированных систем, использующих EDI, были системы управления грузоперевозками. Одной из таких систем реального времени была схема EDP грузовых перевозок в аэропорту Лондона (LACES) в аэропорту Хитроу, Лондон, Великобритания, в 1971 году. Внедрение метода прямого ввода трейдером (DTI) позволило экспедиторам вводить информацию непосредственно в систему таможенной обработки, сокращая время оформления. Увеличение морского трафика и проблемы на таможне, аналогичные тем, которые возникли в аэропорту Хитроу, привели к внедрению систем DTI в отдельных портах или группах портов в 1980-х годах. [3]
EDI обеспечивает техническую основу для автоматизированных коммерческих «разговоров» между двумя субъектами, как внутренними, так и внешними. Термин EDI охватывает весь процесс электронного обмена данными, включая передачу, поток сообщений, формат документа и программное обеспечение, используемое для интерпретации документов. Однако стандарты EDI описывают строгий формат электронных документов , и стандарты EDI были разработаны, изначально в автомобильной промышленности , чтобы быть независимыми от коммуникационных и программных технологий.
Документы EDI обычно содержат ту же информацию, которая обычно содержится в бумажном документе, используемом для той же организационной функции. Например, заказ на доставку со склада EDI 940 используется производителем, чтобы сообщить складу об отправке продукта розничному продавцу. Обычно он имеет адрес «доставки», адрес «получения счета» и список номеров продуктов (обычно UPC ) и количеств. Другим примером является набор сообщений между продавцами и покупателями, таких как запрос котировок (RFQ), предложение в ответ на RFQ, заказ на покупку, подтверждение заказа на покупку, уведомление об отправке, получение уведомления, счет-фактура и уведомление об оплате. Однако EDI не ограничивается только бизнес-данными, связанными с торговлей, но охватывает все области, такие как медицина (например, истории болезни пациентов и результаты лабораторных исследований), транспорт (например, информация о контейнерах и модальных способах), проектирование и строительство и т. д. В некоторых случаях EDI будет использоваться для создания нового потока деловой информации (который раньше не был бумажным потоком). Это касается предварительного уведомления о доставке (ASN), которое было разработано для информирования получателя о доставке, товарах, которые должны быть получены, и способе упаковки товара. Это также дополняется использованием доставкой этикеток для отправки, содержащих штрих-код GS1-128, ссылающийся на номер отслеживания доставки. [4]
Некоторые основные наборы стандартов EDI: [5]
Многие из этих стандартов впервые появились в начале-середине 1980-х годов. Стандарты предписывают форматы, наборы символов и элементы данных, используемые при обмене деловыми документами и формами. Полный список документов X12 включает все основные деловые документы, включая заказы на закупку и счета-фактуры.
Стандарт EDI предписывает обязательную и необязательную информацию для конкретного документа и устанавливает правила для структуры документа. Стандарты подобны строительным нормам. Так же, как две кухни могут быть построены « по нормам », но выглядеть совершенно по-разному, два документа EDI могут соответствовать одному и тому же стандарту и содержать разные наборы информации. Например, продовольственная компания может указать срок годности продукта, в то время как производитель одежды решит отправить информацию о цвете и размере.
Передача EDI может осуществляться с использованием любой методологии, согласованной отправителем и получателем, но по мере того, как все больше торговых партнеров начали использовать Интернет для передачи данных, появились стандартизированные протоколы.
Сюда входят различные технологии, такие как:
Когда некоторые люди сравнивали синхронный протокол модемов 2400 бит/с, устройства CLEO и сети с добавленной стоимостью , используемые для передачи документов EDI, с передачей через Интернет, они приравнивали неинтернет-технологии к EDI и ошибочно предсказывали, что сам EDI будет заменен вместе с неинтернет-технологиями. В большинстве случаев эти неинтернет-методы передачи просто заменяются интернет- протоколами, такими как FTP, HTTP, telnet и электронная почта, но сами документы EDI все еще остаются.
В 2002 году IETF опубликовала RFC 3335, предлагающий стандартизированный, безопасный метод передачи данных EDI по электронной почте. 12 июля 2005 года рабочая группа IETF ратифицировала RFC4130 для передач HTTP EDIINT на основе MIME (также известных как AS2 ), и IETF подготовила аналогичный RFC для передач FTP (также известных как AS3 ). EDI через веб-сервисы (также известные как AS4 ) также был стандартизирован органом по стандартизации OASIS. Хотя часть передачи EDI перешла на эти новые протоколы, поставщики сетей с добавленной стоимостью остаются активными.
По мере того, как все больше организаций подключались к Интернету, в конечном итоге большая часть или весь EDI был перемещен в него. Первоначально это было сделано с помощью специальных соглашений, таких как незашифрованный FTP текстовых файлов ASCII в определенную папку на определенном хосте, разрешенный только с определенных IP-адресов. Однако IETF опубликовал несколько информационных документов («Заявление о применимости»; см. ниже в разделе «Протоколы »), описывающих способы использования стандартных интернет-протоколов для EDI.
С 2002 года Walmart продвигает AS2 для EDI. [6] Благодаря своему значительному присутствию в глобальной цепочке поставок, AS2 стал общепринятым подходом для EDI.
Организации, которые отправляют или получают документы друг от друга, называются «торговыми партнерами» в терминологии EDI. Торговые партнеры договариваются о конкретной информации, которая должна быть передана, и о том, как она должна использоваться. Это делается в человекочитаемых спецификациях (также называемых Руководством по реализации сообщений). В то время как стандарты аналогичны строительным нормам, спецификации аналогичны чертежам. (Спецификация также может называться «сопоставлением», но термин «сопоставление» обычно зарезервирован для определенных машиночитаемых инструкций, предоставляемых программному обеспечению для перевода. [7] ) Более крупные торговые «хабы» имеют существующие Руководства по реализации сообщений, которые отражают их бизнес-процессы для обработки EDI, и они обычно не желают изменять свою деловую практику EDI для удовлетворения потребностей своих торговых партнеров. Часто в крупной компании эти руководства EDI будут написаны так, чтобы быть достаточно общими для использования различными филиалами или подразделениями, и, следовательно, будут содержать информацию, не необходимую для обмена конкретными деловыми документами. Для других крупных компаний они могут создавать отдельные руководства EDI для каждого филиала/подразделения.
Торговые партнеры могут свободно использовать любой способ передачи документов (как описано выше в разделе Протоколы передачи). При этом они могут взаимодействовать как напрямую, так и через посредника.
Торговые партнеры могут подключаться друг к другу напрямую. Например, производитель автомобилей может поддерживать модемный пул, к которому все его сотни поставщиков должны подключаться для выполнения EDI. Однако, если поставщик ведет бизнес с несколькими производителями, ему может потребоваться приобрести другой модем (или устройство VPN и т. д.) и различное программное обеспечение для каждого из них.
По мере развития EDI и веб-технологий появились новые программные технологии EDI, облегчающие прямой (также известный как «точка-точка») EDI между торговыми партнерами. Современное программное обеспечение EDI может облегчать обмены с использованием любого количества различных протоколов передачи файлов и стандартов документов EDI, снижая затраты и барьеры для входа.
Чтобы устранить ограничения в пиринговом принятии EDI, несколько десятилетий назад были созданы VAN (сети с добавленной стоимостью) . VAN действует как региональное почтовое отделение. Он получает транзакции, проверяет информацию «от» и «куда» и направляет транзакцию конечному получателю. VAN могут предоставлять ряд дополнительных услуг, например, ретрансляцию документов, предоставление информации аудита третьей стороны, выступать в качестве шлюза для различных методов передачи и обработку поддержки телекоммуникаций. Из-за этих и других услуг, предоставляемых VAN, предприятия часто используют VAN, даже когда оба торговых партнера используют интернет-протоколы. Клиринговые дома здравоохранения выполняют многие из тех же функций, что и VAN, но имеют дополнительные правовые ограничения.
Эксплуатировать микроавтобусы могут различные организации:
Важно отметить, что существуют ключевые компромиссы между VAN и Direct EDI, [8] и во многих случаях организации, обменивающиеся документами EDI, могут фактически использовать оба варианта совместно для различных аспектов своих реализаций EDI. Например, в США большинство обменов документами EDI используют AS2, поэтому настройка прямого EDI для AS2 может иметь смысл для организации, базирующейся в США. Но добавление возможностей OFTP2 для связи с европейским партнером может быть сложным, поэтому VAN может иметь смысл для обработки этих конкретных транзакций, в то время как прямой EDI используется для транзакций AS2.
Во многих отношениях VAN выступает в качестве поставщика услуг, упрощая большую часть настройки для организаций, желающих инициировать EDI. В связи с тем, что многие организации, впервые начинающие работу с EDI, часто делают это для удовлетворения требований клиентов или партнеров и, следовательно, не имеют внутреннего опыта в области EDI, VAN может стать ценным активом.
Однако VAN могут быть сопряжены с высокими расходами. VAN обычно взимают плату за транзакцию за документ или даже за позицию для обработки транзакций EDI как услуги от имени своих клиентов. Это основная причина, по которой многие организации также внедряют программное решение EDI или в конечном итоге переходят на него для некоторых или всех своих EDI.
С другой стороны, внедрение программного обеспечения EDI может быть сложным процессом в зависимости от сложности варианта использования, задействованных технологий и доступности экспертизы EDI. Кроме того, необходимо учитывать текущие требования к обслуживанию и обновления. Например, отображение EDI является одной из самых сложных задач управления EDI. Компании должны разрабатывать и поддерживать карты EDI для каждого из своих торговых партнеров (а иногда и несколько карт EDI для каждого торгового партнера в зависимости от требований к выполнению заказов).
Программное обеспечение для перевода EDI обеспечивает интерфейс между внутренними системами и форматом EDI, который отправляется/принимается. Для «входящего» документа решение EDI получит файл (либо через сеть с добавленной стоимостью, либо напрямую с использованием таких протоколов, как FTP или AS2), возьмет полученный файл EDI (обычно называемый «конвертом») и проверит, что торговый партнер, отправляющий файл, является действительным торговым партнером, что структура файла соответствует стандартам EDI и что отдельные поля информации соответствуют согласованным стандартам. Обычно переводчик либо создает файл фиксированной длины, переменной длины или в формате с тегами XML, либо «печатает» полученный документ EDI (для неинтегрированных сред EDI). Следующий шаг — конвертировать/преобразовать файл, созданный переводчиком, в формат, который можно импортировать в внутренние бизнес-системы компании, приложения или ERP. Это можно сделать с помощью пользовательской программы, интегрированного фирменного "картографа" или интегрированного стандартного графического "картографа", использующего стандартный язык преобразования данных, такой как XSLT . Последний шаг — импорт преобразованного файла (или базы данных) в внутреннюю систему компании.
Для «исходящего» документа процесс интегрированного EDI заключается в экспорте файла (или чтении базы данных) из информационных систем компании и преобразовании файла в подходящий для переводчика формат. Затем программное обеспечение для перевода «проверит» отправленный файл EDI, чтобы убедиться, что он соответствует стандарту, согласованному торговыми партнерами, преобразует файл в формат «EDI» (добавляя соответствующие идентификаторы и структуры управления) и отправляет файл торговому партнеру (используя соответствующий протокол связи).
Другим важным компонентом любого программного обеспечения для перевода EDI является полный «аудит» всех шагов по перемещению деловых документов между торговыми партнерами. Аудит гарантирует, что любая транзакция (которая на самом деле является деловым документом) может быть отслежена, чтобы гарантировать, что они не будут утеряны. В случае, если розничный торговец отправляет заказ на закупку поставщику, если заказ на закупку «теряется» где-либо в бизнес-процессе, эффект оказывается разрушительным для обоих предприятий. Для поставщика он не выполняет заказ, поскольку не получил его, тем самым теряя бизнес и нанося ущерб деловым отношениям со своим розничным клиентом. Для розничного торговца он имеет перебои на складе, и результатом являются потерянные продажи, снижение обслуживания клиентов и, в конечном итоге, снижение прибыли.
В терминологии EDI «входящий» и «исходящий» относятся к направлению передачи документа EDI по отношению к конкретной системе, а не к направлению товара, денег или других вещей, представленных документом. Например, документ EDI, который сообщает складу о необходимости выполнить исходящую отгрузку, является входящим документом по отношению к компьютерной системе склада. Это исходящий документ по отношению к производителю или дилеру, который передал документ.
EDI и другие подобные технологии экономят деньги компании, предоставляя альтернативу или замену информационным потокам, которые требуют большого человеческого взаимодействия и бумажных документов. Даже когда бумажные документы ведутся параллельно с обменом EDI, например, печатные грузовые манифесты, электронный обмен и использование данных из этого обмена снижают затраты на обработку сортировки, распределения, организации и поиска бумажных документов. EDI и подобные технологии позволяют компании воспользоваться преимуществами хранения и обработки данных в электронном виде без затрат на ручной ввод. Еще одним преимуществом EDI является возможность сократить или устранить ошибки ручного ввода данных, такие как ошибки доставки и выставления счетов, поскольку EDI устраняет необходимость повторного ввода документов на стороне назначения. Одним из очень важных преимуществ EDI по сравнению с бумажными документами является скорость, с которой торговый партнер получает и включает информацию в свою систему, что значительно сокращает время цикла. По этой причине EDI может быть важным компонентом систем производства «точно вовремя». [9]
Согласно отчету Aberdeen 2008 года «Сравнение возможностей поставщиков по всему миру», только 34% заказов на закупку передаются в электронном виде в Северной Америке. В регионе EMEA 36% заказов передаются в электронном виде, а в APAC 41% заказов передаются в электронном виде. Они также сообщают, что средняя стоимость бумажной заявки на заказ для компании составляет $37,45 в Северной Америке, $42,90 в EMEA и $23,90 в APAC. При использовании заявки на заказ в EDI расходы снижаются до $23,83 в Северной Америке, $34,05 в EMEA и $14,78 в APAC. [10]
Существует несколько препятствий для внедрения электронного обмена данными. Одним из самых существенных препятствий является сопутствующее изменение бизнес-процессов. Существующие бизнес-процессы, построенные на обработке бумажных документов, могут не подходить для EDI и потребуют изменений для обеспечения автоматизированной обработки деловых документов. Например, компания может получать большую часть своих товаров с доставкой в течение 1 или 2 дней, а все свои счета-фактуры — по почте. Таким образом, существующий процесс может предполагать, что товары обычно поступают до счета-фактуры. При использовании EDI счет-фактура обычно отправляется при отправке товаров и, следовательно, требует процесса, который обрабатывает большое количество счетов-фактур, соответствующие товары которых еще не были получены.
Другим существенным препятствием являются затраты времени и денег на первоначальную настройку. Предварительные расходы и время, возникающие при внедрении, настройке и обучении, могут быть дорогостоящими. Важно выбрать правильный уровень интеграции, соответствующий требованиям бизнеса. Для бизнеса с относительно небольшим количеством транзакций с партнерами на основе EDI может иметь смысл внедрение недорогих решений «rip and read», где формат EDI распечатывается в удобной для восприятия форме, и люди, а не компьютеры, отвечают на транзакцию. Другой альтернативой являются аутсорсинговые решения EDI, предоставляемые «сервисными бюро» EDI. Для других предприятий внедрение интегрированного решения EDI может быть необходимым, поскольку увеличение объемов торговли, вызванное EDI, заставляет их повторно внедрять свои бизнес-процессы обработки заказов.
Основным препятствием для успешного внедрения EDI является восприятие многими предприятиями природы EDI. Многие рассматривают EDI с технической точки зрения, что EDI — это формат данных; было бы точнее принять точку зрения бизнеса, что EDI — это система обмена деловыми документами с внешними субъектами и интеграции данных из этих документов во внутренние системы компании. Успешные внедрения EDI учитывают влияние внешней информации на их внутренние системы и проверяют полученную деловую информацию. Например, разрешение поставщику обновлять систему кредиторской задолженности розничного продавца без соответствующих сдержек и противовесов подвергнет компанию значительному риску. Предприятия, впервые внедряющие EDI, должны понимать базовый бизнес-процесс и применять надлежащие суждения.
В EDI существует несколько механизмов, используемых для подтверждения , т. е. уведомления отправителя о том, что входящая транзакция была получена и обработана получателем: [11]