ЭДО: Программные средства. Часть 4

7

ЭДО: Программные средства

Часть 1. В чем проблемы?
Часть 2. Виды документов.
Часть 3. Выбор оператора. 

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

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

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

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

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

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

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

  • разработка решений, комплиментарных к существующим стандартным решениям;

  • разработка комплексных промышленных решений.

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

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

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

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

Из существующих на рынке комплексных промышленных решений для SAP ERP следует отметить два: TerraLink Extended Document Exchange for SAP и DFS B2B Solution компании Docflow Best Practice. Оба решения имеют по нескольку промышленных внедрений и поддерживают работу с более чем одним оператором ЭДО. При всей своей, что неизбежно, функциональной схожести на верхнем уровне, упомянутые решения, тем не менее, существенно различаются по архитектуре, функциональному наполнению, предлагаемой разработчиками стратегии внедрения, и, что самое главное, цене. Такие различия выгодны, в первую очередь, для пользователей, поскольку они смогут выбрать то решение, которое в максимальной степени отвечает их функциональным требованиям, корпоративным политикам, практике проектного управления, и бюджету.

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

  • Производительность

    • Обработка в пиковые периоды не менее 500 000 электронных док/день

  • Универсальность

    • Отсутствие привязки к поставщику тех или иных технологий, например, управления архивами

    • Отсутствие препятствий к развитию учетной системы

  • Гибкость

    • Возможность работы с ERP разных производителей

    • Интеграция в действующие приложения SAP ERP и других ERP заказчика

    • Поддержка изменений: форматов структурированных документов, учетной политики, практики применения электронной подписи,....

    • Поддержка изменений версий SAP ER

    • Полная поддержка стандартной конфигурации SAP ERP, актуальных локализаций

    • Ориентация только на промышленные и перспективные технологии разработки приложений

  • Гарантии

    • Обеспечение поставщиком всего жизненного цикла решения от внедрения до эксплуатации, в т.ч., техническая поддержка в режиме 24 * 7 * 365

    • Возможность развития решения заказчиком

    • Доступность специалистов по используемой технологии разработки

  • Информационная безопасность

    • Отсутствие закладок, скрытых функций и т.д.

    • Соответствие законодательству в области ЭП

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

5315
Коментарии: 7

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    30.10.2013 08:43

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

    • Александр Бейдер Михаил
      Рейтинг: 10
      TerraLink
      Директор по цифровым технологиям
      06.11.2013 15:31

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

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

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

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

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

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

      И наконец, но не в последнюю очередь, необходимо учитывать политику компании. Если компании строго ориентируется на стандарты SAP и не приветствует кастомизированные решения, то в результате получится совершенно иное решение по сравнению с решением, предусматривающим определенные доработки на стороне SAPERP, например, встраивание в действующие решения и приложения заказчика. На этих весах мы находимся чуть ближе ко второй опции, сем к первой.
      "..... предлагаемой разработчиками стратегии внедрения, и, что самое главное, цене" - можете подробнее пояснить?
      В стратегии внедрения любого продукта есть два подхода: а) на основании полного проектного цикла, включая анализ существующей системы и сопровождение, б) поставка ПО и поддержка внедрения с позиции вендора.
      Понятно, что второй подход стоит заказчику дешевле, однако он и более рискованный.

      Мы придерживаемся первого подхода.

      • Михаил Петров Александр
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        09.11.2013 00:22

        спасибо!

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    30.10.2013 10:27

    Как видно из обсуждения, наличие WEB-интерфейса у сервиса оператора ЭДО еще далеко не достаточно для реализации промышленного обмена электронными документами. Это связано с тем, что вся информация хранится в ERP-системе и ручной перенос данных из нее в WEB-интерфейс нереалистичен из-за их объема.
    Не соглашусь. Объемы в наше время уже не преставляют проблемы, т.к.:
    1. Пропускная способность каналов достаточна (люди миллиарды фотографий и видео загружают в сеть, а не просто документы).
    2. Выгрузку и загрузку можно автоматизировать (протоколы для передачи данных имеются на любой вкус).
    3. Далеко не все, что есть в ERP надо загружать для внешнего ЭДО, т.е. объемы радикально уменьшаются.
    Имеются жалобы по поводу сложности установки и обновления интеграционного решения, кроме того, отсутствует возможность массовой отправки документов.
    А можно ли поподробнее про "жалобы"?

    • Александр Бейдер Марк
      Рейтинг: 10
      TerraLink
      Директор по цифровым технологиям
      06.11.2013 16:03

      Не соглашусь. Объемы в наше время уже не приставляют проблемы, т.к.:
      1.Пропускная способность каналов достаточна (люди миллиарды фотографий и видео загружают в сеть, а не просто документы).
      Радикальное отличие работы ЭДО от почтовых сообщений состоит в том, что канал ЭДО не просто осуществляет передачу файлов, он еще анализирует структуру передаваемых документов, организовывает протоколы передачи и накапливает у себя архивы пересылаемых документов. Т.е. это не просто канал, но активно работающая облачная среда обработки. Но дело даже не в этом, а в том, что когда мы говорим о пересылке документа, мы включаем в него не просто передачу в канал, но еще и время извлечение информации из CАП-системы, преобразование в нужный формат, применение электронной подписи и контроль кода успеха, т.е это сильно отличается от укладки фотографии в Instagramm. А укладка видео на Youtube или FaceBook это вовсе не мгновенный процесс.
      2.Выгрузку и загрузку можно автоматизировать (протоколы для передачи данных имеются на любой вкус).
      Все верно. Но тут вкус может быть только один - именного того оператора (тех операторов) ЭДО, которых Вы выбрали для передачи Ваших документов. Собственно, в этом на базовом уровне и состоит смысл интеграции сервиса ЭДО с ERP - автоматизация выгрузки и загрузки.
      3.Далеко не все, что есть в ERP надо загружать для внешнего ЭДО, т.е. объемы радикально уменьшаются.
      Собственно, вопрос ставится с точностью наоборот. Все, что надо загружать для внешнего ЭДО, должно находиться в SAP ERP. Следовательно, это никак не уменьшает объемы. Более того, в архив приходится загружать и не только то, что пришло по каналм ЭДО - нужны сканы, почта, файлы Word/Excel и т.д.
      А можно ли поподробнее про "жалобы"?
      В данном вопросе я выступаю в роли коллективного бессознательного. Жаловались мне друзья, что сложно и долго ставить. Один певец подготовляет рапорт, другой рождает приглушенный ропот, а третий знает, что он сам - лишь рупор. Однако мы с Вами взрослые люди, и не первый год в ИТ. Мы хорошо знаем, что сложный продукт редко удается сделать таким образом, чтобы было можно его поставить легко, и что многое еще зависит от квалификации, опыта и настроения того, кто его ставит. Однако надо принять во внимание: сигналы имеются.

      • Марк Шварцблат Александр
        Рейтинг: 30
        КТ "Акведук"
        ИТ-директор
        07.11.2013 13:49

        Это связано с тем, что вся информация хранится в ERP-системе и ручной перенос данных из нее в WEB-интерфейс нереалистичен из-за их объема.
        Прошу прощения, но ответ "Радикальное отличие работы ЭДО от почтовых сообщений..." как-то совсем, в моем представлении плохо связан с исходной посылкой и моим возражением на нее. :)

        Все верно. Но тут вкус может быть только один - именного того оператора (тех операторов) ЭДО, которых Вы выбрали для передачи Ваших документов. Собственно, в этом на базовом уровне и состоит смысл интеграции сервиса ЭДО с ERP - автоматизация выгрузки и загрузки.

        Я писал про то, что выгрузку-загрузку МОЖНО автоматизировать без глубокой интеграции ЭДО в ERP.

        Собственно, вопрос ставится с точностью наоборот. Все, что надо загружать для внешнего ЭДО, должно находиться в SAP ERP. Следовательно, это никак не уменьшает объемы. Более того, в архив приходится загружать и не только то, что пришло по каналм ЭДО - нужны сканы, почта, файлы Word/Excel и т.д.
        С тем, что выгружать лучше из одного места - я не спорю. Еще раз уточню - про что я писал. НЕ ВСЁ из ERP надо выгружать. Внешнее ЭДО не требует всех документов. И еще. ЭДО снижает требования к объемам обмена. Можно послать текст, заверенный ЭЦП, вместо отсканированных в цвете страниц договора.

        В данном вопросе я выступаю в роли коллективного бессознательного.
        С этим я не спорю. Со сложностью тоже. А еще что-то конкретное по содержанию "жалоб"? Предупрежден - значит вооружен.

  • Марк Шварцблат
    Рейтинг: 30
    КТ "Акведук"
    ИТ-директор
    05.12.2013 11:34

    «X5 Retail Group отказалась от бумажного документооборота»

    X5 Retail Group одной из первых в российской рознице отказалась от бумажного документооборота, в том числе с юридически значимыми документами (ЮЗДО). В скором будущем все поставщики компании будут обмениваться документами исключительно при помощи сервиса электронного обмена данными.

    Сократить время и затраты

    Учитывая масштабы X5 Group, несложно представить себе, с каким огромным потоком документов товарооборота ежедневно сталкивается компания. Если обмен данными через электронную почту все еще остается приемлемым для небольших фирм, то для X5 такой формат работы означал бы колоссальные временные и трудовые затраты на обработку, корректировку и отправку документов. Так, по словам, Вячеслава Поликарпова, старшего руководителя проектов X5 RetailGroup, внедрение электронного документооборота (EDI) являлось важным элементом оптимизации бизнес-процессов компании. Поэтому в начале 2012 г. было принято решение перейти на безбумажный обмен документами с поставщиками. Приступая к реализации данного проекта, X5 Retail Group изначально ставила перед собой высокие цели: сократить время обработки одного документа с 30 до 5 минут, значительно снизить затраты на бумагу, оргтехнику и пересылку документов, ввести единый каталог продукции для работы с разными поставщиками и, наконец, свести к минимуму число ошибок, обусловленных ручным вводом информации.

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.