Когда компания обращается к EDI-проекту, вне зависимости от того, развертывание ли это нового решения или обновление уже имеющегося, затраченные усилия могут быть сопряжены со сложными в исправлении и дорогостоящими ошибками.
К наиболее типичным ошибкам при выборе EDI-решения для e-commerce относятся следующие:
1.Выбор набора функций и доработок, вместо коробочного решения. Писать или Покупать – этот выбор часто встает перед компаниями, когда речь заходит о внедрении технологических решений. Большинство, выбравшее разработку собственных бизнес-приложений, часто, осуществив значительные инвестиции, в дальнейшем мигрировали на коммерческие решения, столкнувшись с технологическими и бизнес трудностями, поскольку их собственные системы морально устарели.
Мир EDI насчитывает большое число самодельных платформ, которые имеют общие проблемы: долгое подключение партнеров, недостаточный уровень автоматизации, сложный и недокументированный код, который все более усложняется по мере возникновения необходимости решать новые задачи. Все эти проблемы ведут к затратам на устранение несоответствия требованиям партнеров, законодательства и могут стать причиной крупных штрафов, вплоть до потери бизнеса. Многие компании не осознают, что покупка транслятора или интеграционного модуля – это только первый шаг на потенциально долгий и дорогой путь достижения максимальной интеграции.
Очень немногие ERP-платформы обладают возможностью получать структурированные данные произвольных форматов и проводить корректные транзакции без довольно серьезных доработок. ERP-платформы, предлагающие EDI, обычно имеют ограниченный недостаточно гибкий функционал по обработке транзакций. Таким образом, ситуации, отличающиеся от “нормальных”, нуждаются в кастомизации или предварительной/последующей обработке, чтобы добиться требуемого результата.
2. Отсутствие компетентного EDI и ERP специалиста. Некоторые «продвинутые» ИТ-специалисты считают, что интеграция с EDI – это всего лишь загрузка файла в целевую систему и генерация исходящего файла. Скоро, однако, они узнают, что существует множество бизнес и технологических процессов, которые значительно усложняют EDI-проект. Простая, на первый взгляд, задача создания и передачи файла превращается в сложный и дорогой проект, который трудно сопровождать, обеспечивать поддержку новых версий ERP платформы.
Мало кто из EDI-провайдеров имеет интеграционные решения, способные контролировать изменение версий ERP-систем у клиента и заблаговременно информировать обе стороны о возможных проблемах.
Многие компании, уделяющие существенное внимание EDI-системе, не инвестируют достаточно средств в поддержку ERP. Те, кто следит за развитием и изменениями в ERP-платформе, участвуют в бета-тестировании новых версий, к моменту выхода официального обновления подходят во всеоружии, уверенные в полной совместимости EDI и ERP. Менее организованные компании ищут возможность финансирования работ по обеспечению совместимости вышедшей версии ЕRP-системы с EDI за счет клиентов.
3. Игнорирование критериев производительности и масштабируемости. EDI решение, которое не справляется с объемом транзакций компании, должно быть заменено.
Многие разработанные и интегрированные в ERP модули EDI работают в однопотоковом режиме и одновременно способны обрабатывать единственный поток данных.
Еще более тяжелым случаем являются решения, которые во время выполнения транзакций блокируют других пользователей, что создает дополнительные узкие места в системе. Слышали ли вы призыв: «Никто не редактирует заказы, пожалуйста, я обмениваюсь документами»? Платформы, которые поддерживают общедоступные облака, имеют значение, когда требуется обслуживать огромное количество транзакций. Большинство же облачных решений рассчитаны на относительно небольшое число одновременных транзакций и спроектированы в соответствии с этим расчётом. В результате мы имеем установку и закрытие соединения с ERP системой для каждой транзакции. EDI решения, поддерживающие облака, частные облака больше подходят для компаний со средним и большим числом обрабатываемых транзакций.
4. Не учитывается текущий уровень автоматизации. Некоторые компании бывают просто шокированы, когда сталкиваются с интеграцией впервые, увидев, как счета на поставку формируются из заказа на поставку всего за несколько кликов. Однако, они не принимают во внимание текущий уровень автоматизации: кто будет совершать эти клики, сколько раз в день нужно это делать, нужно ли проверять документы, как будут отслеживаться и исправляться ошибки? Amazon, к примеру, требует от большинства поставщиков обновлять информацию о запасах каждый час в режиме 24/7/365. Многие другие компании требуют уведомление об отгрузке в течении 15 минут после того, как товар покинул распределительный центр. Очевидно, что иметь специального сотрудника для нажатия клавиш, не является оптимальным решением.
Настоящая автоматизация, исключающая вмешательство человека, трудно достижима и требует организации рабочих процессов, которые могут выполняться по расписанию или по факту наступления события. Кроме того, необходимы встроенные системы обнаружения ошибок, ведения журналов событий, оповещения о событиях ответственных сотрудников, к примеру по электронной почте, текстовыми сообщениями, посредством мессенджеров.
Но как быть, если событие зарегистрировано, сотрудник оповещен, но проблему решить не может? Способна ли платформа отследить журналы событий и оповещений и предотвратить ввод в систему документов с ошибками? В идеальном случае, эта ситуация должна быть решена автоматически, без вмешательства человека.
5. Выбор модели, для поддержки которой требуется несколько разработчиков. Многие решения предполагают использование сторонних разработок для передачи, трансляции данных, интеграции и т.д. Эти «разделенные» технологические и бизнес-модели могут стать причиной дополнительных множественных точек возникновения ошибок и ведут к проблемам определения ответственного за поддержку на каждом производственном этапе. В каком-то смысле это и есть современный российский роуминг в EDI и внешнем ЭДО. Подход, при котором сторона A получает данные, конвертирует файл, передает его стороне В, для доставки по «последней миле» до ERP-системы, является неэффективным и создает трудности для своевременной идентификации и устранения ошибок.
6. Выбор негибкой бизнес-модели. Бизнес-среда большинства компании очень изменчива, постоянно что-то происходит, включая изменения в количестве персонала, бизнес-возможностей. К примеру, компания может решить, что сама будет поддерживать таблицы соответствия и обеспечивать совместимость, однако неожиданные обстоятельства могут сделать аутсорсинг этих процессов более привлекательным. Эти изменения могут потребовать новое решение, которое окажется дорогим и сложным в развертывании. С другой стороны, компания, для которой вопросы мэппинга и комплайенса не являются критичными, может развернуть эти сервисы на собственных мощностях. В любом случае, наличие широкого набора опций, позволит сделать наиболее подходящий для Вашего бизнеса и стратегии выбор.
7. Выбор решения с неопределенной стоимостью владения. В мире решений для EDI встречаются компании, предлагающие низкие цены, зачастую бесплатное развертывание продукта, и рассчитывающие на дальнейшую оплату за проведенные транзакции. По мере роста Вашей компании, бизнес-модель претерпевает изменения и нагрузка на интегрированное EDI-решение увеличивается. Затраты, первоначально казавшиеся приемлимыми, начинают влиять на показатели бизнеса и эффективности инвестиций. Поскольку многие вложения в технологии оцениваются с точки зрения возврата на инвестиции, то в случае с оплатой за каждую транзакцию, правильно рассчитать этот показатель становится очень сложно.
8. Выбор решения, не способного удовлетворить все требования бизнеса и интеграционных процессов. К сожалению, некоторые покупатели EDI-технологий рассматривают решения очень примитивно.
Например, способно ли решение создавать счет на основе заказа на поставку – «да» или «нет». Однако, вопрос может быть более тонким и содержать подуровни, благодаря которым «да» может превратиться в «не совсем». К примеру, может ли решение интегрировать и отслеживать или создавать множественные счета для заказа, требующего доставку в несколько пунктов или, напротив, создать один счет с указанием адресов доставки? Способна ли система правильно работать по сценариям прямых поставок (дроп-шиппинг)?
Один из лучших способов определить отвечает ли решение Вашим бизнес-требованиям – это количество документов по интеграции: чем их больше, тем выше вероятность того, что решение Вам подходит сейчас и сможет решать задачи в будущем. Еще одним способом убедиться в том, что решение Вам подходит – проверить, используют ли похожие компании из Вашей отрасли этот продукт и насколько успешно.
9. Выбор решения, неспособного работать с международными стандартами или продвинутыми форматами данных. Более старые решения, не основанные на стандартах, несут большие затраты на управление и обработку данных в новых форматах. Европейские и азиатские стандарты значительно отличаются от североамериканских стандартов. Кроме того, некоторые отрасли промышленности, такие как электроника и автомобилестроение, используют форматы и протоколы, отличные от других отраслей. Важно знать ограничения решения заранее. Тогда Вы не будете удивлены, если новый покупатель не сможет обмениваться документами с Вашей системой.
10. Выбор провайдера, не имеющего методологии развертывания и долгосрочной поддержки своего решения.
Индустрия EDI развивается вместе с некоторыми компаниями, которые получают преимущества от этих изменений, и другими, которые снижают уровень поддержки клиентов. Важно оценить способность сервис-провайдера обеспечить полноценную техническую поддержку, чтобы быть уверенным, что Вам не придется несколько дней ждать ответ на срочный вопрос.
Новые компании, которые не нацелены на 100% удовлетворение технических запросов всех своих клиентов и развитие своих решений в соответствии с современной изменяющейся бизнес-средой, будут отставать от потребностей бизнеса своих клиентов, а также их партнеров и покупателей.
Часто бывает и так, что если у компании есть один ярко выраженный якорный клиент, на удовлетворение потребностей которого брошены все ресурсы, то остальным клиентам придется не сладко и перспективы будут не радужные.
Таким образом, подходить к развертыванию EDI-системы нужно подготовленным, проведя предварительное исследование рынка. Обратившись к авторитетным консультантам и экспертам отрасли, можно предотвратить крупные затраты и избавиться от головной боли в будущем.