Последнее время все чаще приходится сталкиваться с вопросом «Можно ли сделать обмен данными между конкретной платформой интернет-магазина и другой системой или сервисом и сколько это будет стоить?». С одной стороны это радует, потому что все больше людей начинают понимать, что интернет магазин это не просто сайт, и что нужно автоматизировать не только взаимодействия с покупателем в процессе его ознакомления с товаром и оформления заказа, но и внутренние процессы связанные с товарными запасами и исполнением заказов (комплектованием и доставкой). Но с другой - удручает крайне низкая грамотность CEO интернет-магазинов в данной области. А ведь только за счет интеграции нескольких средств в единую систему можно добиться глубокой и комплексной автоматизации торгового процесса, а, значит, повышения эффективности бизнеса и в конечном итоге роста прибыли. Для многих растущих интернет-магазинов интеграция с внешними системами в буквальном смысле становится единственным способом выживания потому, что только так они могут расти дальше, становиться сильнее и побеждать в конкурентной борьбе. А раз так, то давайте разберемся в этом вопросе детальнее.
Прежде всего нужно понять, откуда берется потребность в межсистемных обменах данными потому, что это поможет систематизировать требования к нему. А возникает эта потребность потому, что в бизнес-процессе при выполнении одних действий создается информация, которая является предметом или условием для выполнения других действий, а информационные системы-это средства автоматизации выполнения этих действий. Таким образом особенности бизнес-процесса задают структуру информационных потоков (состав передаваемых данных, отправителей и получателей, форматы передачи) и определяют основные параметры информационного взаимодействия, которые нужно обеспечить при интеграции систем. На первый взгляд все просто, но дьявол как известно кроется в деталях, и эти детали как правило и упускают.
Во-первых, любая единичная передача данных это довольно сложный процесс, в котором:
одна сторона подготавливает передаваемую информацию так, чтобы принимающая сторона могла ее правильно и однозначно интерпретировать (то есть распознать и воспринять смысловое содержание послания), а вторая - интерпретирует ее, то есть преобразует из формы передачи в форму, пригодную для дальнейшего использования;
стороны обмениваются дополнительными сообщениями, по которым они согласуют порядок передачи сообщения и осуществляют контроль качества передачи (отсутствие искажений основной информации в процессе передачи).
В совокупности функции подготовки, интерпретации и передачи данных каждой из сторон обмена составляют их интерфейсы.
Во-вторых, передача данных имеет направление. Обмен информацией может быть как однонаправленный, при котором один субъект передает информацию а другой получает, так и двунаправленным, когда оба субъекта информационного обмена и передают и получают информацию.
В-третьих, важным требованием является динамика движения информации потому, что одним из важнейших ее качественных характеристик является актуальность. Обеспечение актуальности информации в каждой операции бизнес-процесса достигается подачей информации в нужное место в нужное время, а скорость передачи информации определяется периодом времени, в течение которого информация сохраняет свою актуальность. Для пояснения - в быстрых процессах период актуальности информации короче, чем в медленных.
По временным характеристикам обмен данными может быть:
периодическим;
непрерывным.
Первый тип применим в медленных процессах, где не требуется сиюминутная обработка новых данных (в торговле к таким процессам можно отнести, например, синхронизацию остатков и цен между складами и магазином, а период актуальности информации могут составлять например одни сутки), второй —для процессов с обработкой информации в режиме «реального времени», где вновь поступившая информация должны поступить на обработку немедленно (к таким процессам в торговле могут относится например процессы исполнения заказов, особенно если речь идет о скоропортящемся товаре, или при большом потоке заказов, когда счет в исполнении каждого идет буквально на минуты).
Параметры скорости и направления обмена данными задают дополнительные требования к интерфейсам субъектов обмена (в данном случае под субъектами понимаются информационные системы). Чтобы обмен между системами проходил в требуемом направлении, нужно, по меньшей мере, чтобы свойства их интерфейсов обладали соответствующими возможностями, а именно способностями подготавливать или интерпретировать основной контент. Чтобы реализовать постоянный обмен, процесс передачи информации должен быть полностью автоматизирован, а значит интерфейсы систем должны иметь функционал поддержки канала передачи данных.
Главной проблемой, которую приходится решать при интеграции систем, является устранение несоответствия их интерфейсов тем требованиями, которые задаются бизнес-процессом и вариантов таких несоответствий может быть много.
Так, несоответствия требованиям направления передачи данных могут выражаться в том, что системы, предполагаемые к интеграции, могут только отдавать или только принимать информацию, или система, которая должна отдавать информацию, умеет только принимать, а другая только отправлять, или одна система не может подготовить передаваемую информацию так, чтобы вторая система смогла ее интерпретировать. Но в конечном итоге, интерфейсные свойства систем, подлежащих интеграции, позволяют, в своем исходном виде, реализовать такую структуру информационных взаимодействий, которая в конкретном бизнес-процессе нужна «как рыбе зонтик».
Несоответствия требованиям скорости передачи данных проявляются тогда, когда функционал интерфейса интегрируемых систем не позволяет им поддерживать автоматизированный канал передачи данных, несмотря на то, что условия бизнес-процесса требуют постоянного режима обмена данными. То есть, интерфейсы систем в их первозданном виде позволяют обеспечить только периодический режим обмена, например когда одна система имеет функционал для организации автоматизированного обмена данными (например SOAP, REST, XML-RPC), а вторая нет или его не имеют обе системы, или функции обеспечивают поддержку разных типов каналов (у одной - REST, у другой — SOAP).
Что касается возможности и стоимости интеграции информационных систем, то под этим следует понимать возможность доработки интерфейсов систем с целью устранения приведенных выше несоответствий. А раз так, попробуем прикинуть, какие могут возникнуть сложности и как сильно они могут повлиять на трудоемкость решения задачи межсистемной интеграции. И вот тут-то и начинается самое интересное.
Что касается сложностей, то:
во-первых, чтобы доработать системы для интеграции нужно иметь возможность их дорабатывать, а это не всегда возможно (например, часто возникает необходимость интегрировать интернет-магазин с онлайн-сервисами, которые дорабатывать практически нет возможности, потому что этого не позволит владелец сервиса);
во-вторых, если доработки требуют обе интегрируемые системы, то очень часто возникает необходимость привлекать не одного разработчика, а двух, каждый из которых специализируется в доработках одной системы, потому что если интегрируемые системы достаточно сложны, то найти одного универсального спеца, который сможет переделать обе системы, практически невозможно, то есть помимо технических сложностей возникают еще и организационные.
Теперь то, что касается стоимости:
в первом случае ограничения возможности доработки одной из интегрируемых систем придется компенсировать либо увеличением объемов переделки другой, либо созданием третьей промежуточной системы, которая будет фактически представителем немодифицируемой системы, но уже с расширенными функциями или так называемый интерфейс-обертка, расширяющий возможности того интерфейса, который невозможно модифицировать, а все это усложняет и увеличивает объем работ иногда в разы, а иногда и на порядки;
во втором — участие большего количества исполнителей усложняет организацию работ за счет увеличения объема непроизводительных, вспомогательных действий согласования и обсуждения, а также роста числа переделок в случае нестыковок, что неизбежно приводит к росту скрытых трудозатрат подрядчиков, стоимость которых они все равно включат в общую стоимость работ (при этом нужно отчетливо понимать, что их действия придется координировать заказчику потому, что сами разработчики вряд ли договорятся между собой. Они либо будут пытаться валить работу друг на друга, либо тянуть каждый на себя в зависимости от размеров бюджета. И это естественно, ведь каждый заинтересован меньше работать и больше получать.).
Рассмотрим несколько типичных примеров.
Интеграция платформы интернет-магазина (Opencart, Prestashop, Magento) с ERP-системой (чаще всего в конфигурации 1С «Управление торговлей»). В силу особенностей реализации 1С, связанных с основным направлением ее использования (управление производством или оптовой торговлей), очень часто получить данные в необходимом для интернет-магазина виде без специальных доработок невозможно. То есть те данные, которые могут быть получены типовыми настройками 1С непригодны для использования в интернет-магазине (в 1С все строится на документообороте), а чтобы привести их к требуемому виду (получить сводные данные о количестве товара), нужны серьезные трудозатраты специалистов с весьма высокой квалификацией в работе с 1С (разработка отчета для обобщения данных приходных и расходных документов). В результате, не смотря на то, что последние версии 1С имеют мощный функционал для организации передачи данных (обеспечения канала транспортировки), необходимость настройки средств подготовки данных к передаче существенно усложнит интеграцию в целом. И это при том, что о доработках другой системы ( а именно платформы интернет-магазина) речь в примере даже и не шла, и решаемая задача- синхронизация данных о товарах в системе управления и магазине-лишь одна из задач. К тому же, в примере подразумевается, что интеграция должна осуществляться благодаря опросу системы управления магазином, а, значит, обмен периодический. Для постоянной актуализации нужно реализовывать схему интеграции, когда из 1С идет обращение к интерфейсам платформы магазина при любом изменении данных в системе управления, а для этого нужен соответствующий интерфейс, который не везде есть. Например из перечисленных систем необходимый интерфейс в этой части, не требующий доработок, имеет только Magento (на момент написания статьи - февраль 2013 года. прим. автора).
Интеграция интернет-магазина с управленческими сервисами, такими как Мегаплан, Мойсклад, сервисами логистических компаний, таких как Ritm-Z или Axiomus и т. п. Доработать такие сервисы конечно-же практически не представляется возможным (их приходится использовать «as is», то есть «как есть»). А они представляют собой некоторые наборы функций, не все из которых будут использоваться в автоматизации того или иного бизнес-процесса, да и те, которые есть реализуются исходя из представлений владельцев сервиса о способах их использования, которые не всегда совпадают с потребностями их пользователей. К тому же, их интеграционные интерфейсы построены исходя из того, что в процессах обмена они играют пассивную роль и являются в основном получателями данных, то есть в них больше возможностей управлять обработкой полученных данных, нежели подготовкой данных с передаче (принцип работы их интерфейсов похож на односторонний клапан, все впускает и ничего не выпускает). А значит, прежде чем задавать вопросы об интеграции, нужно сначала понять какие функции вообще можно передать на обработку и исходя из этого спрогнозировать структуру информационных потоков.
Итог.
Во-первых, прежде чем задаваться вопросом, упомянутым в первом абзаце, и задавать его другим надо:
описать предполагаемую схему организации бизнес-процесса с использованием интегрируемых систем (какие функции на какие системы предполагается передать);
описать структуру и временные характеристики информационного обмена, между функциями, распределенными между системами, предполагаемыми к интеграции.
В противном случае вопрос не имеет ни малейшего смысла, и ожидать на такой вопрос осмысленного ответа неразумно.
Во-вторых, лучше сразу привыкнуть к мысли, что стоимость более или менее осознанной эффективной интеграции платформы интернет-магазина с большинством систем и сервисов будет существенно, скорее всего в разы, дороже разработки дизайна и верстки, потому что готовых решений, способных удовлетворить очень разнообразные требования, предъявляемые различными бизнес-процессами, просто не существует.
Продолжение следует ...
Комментарии (0)