Российский проект TAdviser.ru провел исследование "ERP в торговле 2007".

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

• Реализация недостающих "торговых" функций в универсальных ERP-системах
• Реализация учётных и оптимизационных в специализированных решениях для автоматизации торговли
• Интеграция универсальных ERP-систем со специализированными решениями.

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

Поскольку при этом используется встроенный в саму систему инструментарий, отраслевое решение получается монолитным в смысле используемых данных и метаданных, СУБД, пользовательского интерфейса, протоколов передачи данных, форматов файлов и т.п. Аналогичный эффект достигается, если вендор распространяет собственную платформу, основанную на ПО промежуточного уровня (SAP NetWeaver, Oracle Fusion Middleware, Microsoft .NET), или использует "чужую" (IBM WebSphere, Progress OpenEdge и др.).

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

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

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

В техническом плане развитие решений для торговли характеризуется необходимостью максимально полной поддержки современных организационных форм торговой деятельности, а также новейшего специализированного оборудования. На сегодняшний день сюда входит: переход на сервисно-ориентированную архитектуру, использование открытых стандартов и проколов, использование отраслевых стандартов для унификации интерфейсов с POS-системами, а также обмена данными в рамках цепочки поставок, поддержка радиочастотной идентификации товаров (RFID) на складах и в торговых залах, усиление функционала по поддержке мобильной и онлайн-торговли, таких новаций, как "магазин без продавца/self checkout", "умная тележка", "умная витрина/информационный киоск" и др., движение в направлении систем управления качеством и предотвращения краж и мошенничества. Значительная часть этих изменений необходима просто для поддержки соответствия предлагаемых решений объективно сложившимся требованиям со стороны заказчиков и обеспечивает торговым компаниям не столько конкурентное преимущество, сколько стандартную инфраструктуру для управления бизнесом.

Сергей ДМИТРИЕВ