Считается, есть две вечные темы для обсуждения — любовь и смерть. А мы нашли третью — интеграция с ERP клиента. Мы уже писали о ней, и не раз. И всегда остаётся, что добавить.

Интеграция — космически важная штука, потому что она делает возможным:

1. Автоматически выгружать существующие товары из системы на сайт. Номенклатуру, остатки, цены.

2. Забирать оформленные пользователями заказы с сайта в систему.

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

Интеграция из коробки: коробка в яйце, яйцо в утке, утка улетела на юг

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

Мы, конечно, можем устроить интеграцию любым способом из таблицы выше, но, так как наш гипотетический заказчик уже по уши зарылся в сайт Битрикса, рассмотрим вариант с 1С. Он, к тому же, самый распространённый.

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

На самом деле, разработчики сильнее остальных мечтают, чтобы интеграция проходила легко и просто. Но так бывает не всегда. По нашему опыту — только в 25% случаев, когда интеграция штатная.

Штатная интеграция подходит только в случае, если конфигурация системы стандартна, 1С-специалист ничего не менял.

Если вашу базу ковыряли и перекраивали, то ситуация нештатная. Такая база будет активно сопротивляться интеграции из коробки. Чтобы заставить её работать с сайтом, придётся потанцевать с бубном. И чем активнее, тем интеграция будет дольше и дороже.

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

Как строится процесс

Если заказчику нужна интеграция c 1C, то о масштабе задачи нам нужно знать как можно раньше. Поэтому уже на этапе продажи возникают неудобные вопросы вроде «Какая у вас версия 1С?» и «Занимается ли базой какой-нибудь специалист? А что он с ней делает?»

Не всякий топ-менеджер или маркетолог в курсе, что творится с его системой. Но без этих данных дать информацию по стоимости и срокам интеграции невозможно — вилка получается такая, что никакой конкретики: от 8 до 80 часов на описание протокола и от 40 до 200 часов на реализацию интеграции. Поэтому знать, с чем мы имеем дело, нужно уже на этапе прототипа.

Мы просим заказчика вместе с его специалистом заполнить чек-лист. Это помогает понять, чем должны обмениваться сайт и 1C клиента, и в каком состоянии последняя. Так понимаем, насколько всё запущено, сужаем сроки и вилочную стоимость.

Когда чек-лист заполнен, и масштаб работ примерно понятен, нужна выгрузка. Получить её — отдельный квест. Ждать выгрузку можно дольше, чем делать сайт, интеграцию и праздновать сдачу проекта. Всё потому, что:

• Базу переделывают. Старую показывать смысла нет, а новая пока не готова. Сидим, ждём.

• Специалист со стороны заказчика не умеет/не хочет/просто забыл дать выгрузку. Если проблему не получается решить через заказчика, берём дело в свои руки. Коллами и переписками объясняем специалисту 1C, чего мы хотим и как это сделать. Если результатов нет — просим доступы и решаем все вопросы самостоятельно. Не обходится без фэйлов.

Это весело и забавно, но если хочется всё делать чётко, у нас есть парочка проверенных спецов по интеграции c 1C в Москве. Если у заказчика всё очень плохо — приедут и настроят.

Выгрузка получена, готовы прототип и ТЗ. Теперь нужно:

• понять, как сделать из нештатного штатное, чтобы по максимуму полетело из коробки;

• разобраться, что из пожеланий заказчика и предложений студии можно сделать в 1C, а что — нельзя;

• выявить, какие есть риски, и дать заказчику точную оценку по интеграции.

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

Чтобы всё это сделать, мы пишем протокол на интеграцию. Привлекаем для этого разработчика, который на 1C съел не одну собаку. Нет, хвостом не подавился, даже во вкус вошёл.

Протокол пишется итеративно: поговорили, описали часть работ, выполнили, снова поговорили. Для этого два-три раза в неделю созваниваемся с заказчиком и специалистом. И обсуждаем, что было сделано, над чем будем работать в ближайшее время, какие есть вопросы и проблемы.

Сначала разработчик анализирует выгрузку, соотносит её с прототипами. Выясняет, где нужно будет поработать напильником: на сайте или в 1C. И делает костяк протокола. Все пункты помечаются соответствующими пиктограммами:

Кроме флажков и галочек, в протоколе есть вещи серьёзные. Ради чего проводится интеграция: экспорт товаров на сайт, импорт заказов, если необходим. И папки с файлами выгрузки. К ним и к протоколу доступ есть у всех участников процесса.

Вот так масштабно получается. Руки боятся, да? Успокойте их — не нужно делать всё и сразу. То, без чего сайт не будет сайтом, допиливается в первую очередь. А приятные, но не критические фишки типа тех же скидок за лояльность, можно отложить на второй этап работ над интеграцией.

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

Ирина
Руководитель проектов

Из коробки в моих проектах получилось только один раз — на «Эко». Мегасложного технического задания не потребовалось: на стороне сайта мы допилили две функции. Плюс немного понервничали, когда числовые характеристики пришли строками — все-таки по ним фильтр, все дела.

Но это скорее исключение — 1С никто не менял, товары выводились как есть, заказы на сайт не возвращались. Техническое задание на интеграцию — порой единственный способ навести порядок в сложном проекте с множеством задействованных лиц.

Во-первых, это возможность четко сказать спецу 1С, что мы от него ждем. И заказчику — чего мы ждем от 1Сника. По пунктам, без возможности слиться. С контролем каждого пункта (красный флажок / зеленый флажок).

Во-вторых, это известность и прозрачность. Не какие-то абстрактные «ну на неделе сделаю», а четкие сроки и зафиксированные договоренности. Созваниваемся часто, контрольных точек много, молчунов на мороз :)

В-третьих, это описанный протокол, к которому можно обращаться в случае спорных вопросов. Нюансы по ходу сборки так или иначе все равно всплывут. Но а) это контролируемо, б) это не адовая катастрофа, ставящая под угрозу весь проект («мы не можем предоставить вам выгрузку в таком формате, переделывайте каталог»).

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

Это повод менеджеру проекта снова перечитать общее ТЗ и светофором покрасить, что всё-таки будет на сайте, а что реализовать не получится. То же самое сделать с прототипом, и лучше — вместе с заказчиком. Это хороший способ отловить все взаимодействия. Правда, возится с прототипом — процесс долгий и немного занудный, поэтому пользуемся им только на самых хардкорных проектах.

Когда интеграционный протокол, ТЗ и прототип готовы и покрашены флажками / текстовыделителями, можно наконец ответить на самый важный вопрос заказчика — сколько это стоит. Составляется точная смета, утверждается протокол работ.

Цена зависит от того, насколько интеграция была далека от штатной. Чем дальше — тем дороже.

Битрикс и правда может в интеграцию, и мы его любим за это. Но часто ему нужна помощь. Иногда — реанимация. И без специалистов уже не обойтись.

Оригинал: http://blog.sibirix.ru/2016/05/05/make1Cnotwar/