В этой статье мы рассказываем, как создаем общее понимание и последовательность процессов с клиентом при сложных, многосторонних интеграциях. Показываем на реальных файлах, как это может выглядеть.
Что такое сложная интеграция?
Под сложной интеграцией мы подразумеваем настройку синхронизированного обмена данными между внутренней учетной системой заказчика и сайтом — чтобы в обоих источниках данные были одинаковы. Соответственно, простая интеграция, когда мы передаем данные из одного носителя в другой.
Предмет обмена при сложной интеграции зависит от офлайн-процессов заказчика. Но обычно это обмен:
- — товарами (каталог: название, характеристики, цены и пр.);
- — заказами;
- — контрагентами;
- — данными по системе лояльности (бонусы);
- — др.
Чаще всего заказчики пользуются 1С. Это родственный продукт с Битриксом, но почти всегда «стыковка» проходит не без особенностей. И нужна работа и с нашей стороны, и со стороны заказчика.
Какую проблему это решает?
Такая схема позволяет снизить коммуникативные риски и издержки времени на разработку. Помогает заранее договориться, кто и что делает, какие данные, когда, кто и куда отправляет.
А договориться не всегда просто и причины для этого разные. Например, 1С-программист на стороне заказчика имеет недостаточно опыта или вообще ни разу в жизни не делал выгрузку. Или заказчик нанимает аутсорс для этой настройки, который не в курсе внутренних процессов компании. Также команда на стороне бизнеса может быть комплексной: в нашем опыте есть, когда принимают участие и 3 сотрудника из отдела маркетинга, и сотрудники колл-центра, а IT-отдел отвечает только за техническую часть.
При этом важно, что обычно каждая из сторон плохо представляет внутренние сроки других участников процесса, и чтобы не происходили простои у какого-то подразделения нужно прийти к тестированию уже реализованного продукта примерно в один момент.
Если интеграция простая, например, отправить каталог из 1С на сайт, то здесь легко «спроектировать» процесс в голове, обсудить в чате, поэкспериментировать. Но когда выгрузок несколько и они переплетены (например, после регистрации происходит начисление бонусов), начинается сложный и часто хаотичный процесс обсуждения. Это влияет на количество затраченных часов, как следствие — на сроки, себестоимость разработки и нервы обеих сторон.
Как пришли к этой схеме работы и что стало триггером?
Какое-то время опытные программисты отбивали вопросы на своем уровне, хотя им это было очень нелегко. PM не вмешивался в эту, вроде как, техническую часть. Но в итоге выходило так, что рано или поздно появлялись вопросы на уровне менеджеров агентства и заказчика — и возвращаться в такую коммуникацию было еще сложнее.
Все это послужило триггером к проектированию обменов и выстраиванию процессов на этом отрезке. Сперва сесть и договориться на бумаге, далее — визуализировать, согласовать тайминг, и только уже потом писать код. Всё ради того, чтобы сэкономить часы команды и сделать процесс прозрачнее для всех сторон.
Этап первый — «стратегический блок»1
Здесь участвуют все стороны, и менеджмент, и технические специалисты. Обсуждают последовательность обмена данными и интеграцию офлайн-процессов схематически.
Этап второй — детализация схемы.2
Формируем таблицу с максимально детализированным указанием данных, которые необходимо передавать.
Как правило, детализацию уже делаем мы, так как у нас больше опыта, чем у заказчика. Но делает это PM, чтобы могли понять менеджеры на стороне заказчика.
На этом этапе всегда уже возникают вопросы от технических специалистов, и есть возможность их обсудить и скорректировать план.
Детализация схемы для раздела Товары
Этап третий — обмен файлами с кодом.3
Они нужны для технических специалистов, чтобы унифицировать и синхронизировать работу с двух сторон. Особенно это актуально при написании обменов с нуля (не типовых обменов Битрикса, а например по API).
Если есть такой файл, то мост строится с двух берегов одновременно, снижаются риски и сроки.
Файл Users
Файл Zones
Вывод
Чтобы сократить риски несогласованности с клиентом и дальнейших потерь при сложных интеграциях, обсуждайте схему интеграции заранее и прописывайте «на бумаге». Мы это делаем в три этапа от общего к частному: «стратегический блок», детализация схемы и обмен файлами с кодом на самом нижнем уровне. И если у вас еще не выстроен этот процесс — рекомендуем это сделать: в ситуациях многосторонних коммуникаций и при нескольких лицах, принимающих решение, это сильно ускорит работу и даст плюс к лояльности. Для старта можете взять наши примеры документов из статьи, а если что-то не понятно — задать вопрос.