Интеграция сайта с 1С — риски и немного реальности

Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено 75%. То есть, в трех случаях из четырех — придется что-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…

… Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Слоган, который, наверное, никогда не умрет.

Рассмотрим процесс интеграции с точки зрения клиент-исполнитель. Сценарий продажи может превратиться в сущий адъ из-за пары неловких движений менеджера.



Так что знакомимся с горьким опытом и делимся своим:

Фаза предпродажи:

Анализ диалога:

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

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

Как правило, это гарантирует, что штатной интеграции не хватит.

Фаза утверждения технического задания:

Анализ диалога:

Непредоставление выгрузки или доступа к 1С, к сожалению, — частая проблема. На этом же этапе работ я бы порекомендовал начинать взаимодействие с программистом заказчика (вполне возможны разного рода неожиданности). Порой — это самый дешевый и реальный вариант.

Договоритесь с заказчиком, чтобы он организовал вам переговоры с программистом, добейтесь того, чтобы программист либо дал вам доступ к выгрузке, либо 100% согласился обеспечить выгрузку и настройки под ваши требования. Зафиксируйте договоренности письменно.

Фаза разработки:

Анализ диалога:

Практически гарантированный фэйл. Программистам нужно спроектировать структуру каталога, но если выгрузка из базы будет принципиально другой, — это нужно учесть заранее. Пожалуй, тут еще все можно было бы и спасти, но…

Фаза сдачи проекта:

Анализ ситуации:

Ну все, фэйл случился. Теперь проджект-менежер будет пытаться «рулить» удаленным программистом, который не стоит у него в подчинении, и которого он не нанимал. Все зависит от того, какое чувство собственной важности у программиста на стороне клиента… И не дай бох оно будет >9000 :-)

Фаза приемки проекта:

И — дальнейшее развитие событий:



Анализ диалога:

Если давить на программиста заказчика — можно выяснить, что он либо не разобрался в спецификации, либо пробовал, но у него не получилось, либо уже нагородил какого-то своего говнокода или какой-то свой «универсальный» формат, от которого теперь не хочет отступать. Особенная жесть начинается, если ваш клиент платит своему 1С-нику — почасовую ставку, и 1С-ник утверждает, что работа с его стороны займет неделю, из-за ваших «необоснованных» требований (или уникальности «нашей базы»).

Через неделю:

Анализ диалога:

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

Главное, не вестись на разговоры вроде «вы же профессионалы, должны были предусмотреть». Вы предусмотрели и решили продолжить интеграцию, имея открытый риск. А риск, увы, — сработал.

Лечится, как правило, увеличением цены на 2-3-4 человеко-дня со стороны программистов студии, и еще часов 8-16 нервных переговоров со стороны менеджера проектов и клиента. Собственно, отсюда и разница в цене — $N за штатную интеграцию, $MMM — за нештатную.

Нервные клетки не восстанавливаются.

Итого, примерно такой расклад, по основным рискам:

Риск/ситуация	Последствия	Противодействие
Выгрузка запрошена на этапе пресейла.	Клиент поищет кого-то попроще. Слишком много времени уйдет на пресейл, а проект — сорвется.	Вынести интеграцию на отдельный этап. Дать «вилку» на лучший и худший случаи. Сообщить заказчику о возможных рисках.
Выгрузка не предоставлена на этапе составления ТЗ.	Неправильно спроектирована структура каталога. Срыв сроков и бюджета.	Настаивать на предоставлении выгрузки. Вынести интеграцию в отдельный этап. Письменно сообщить заказчику о возможных рисках.
Интеграция вынесена в отдельный этап.	Придется переделывать всю структуру каталога.	Получить выгрузку до начала проектирования.
1С был модифицирован сторонним разработчиком, имеет устаревшую версию или плохо структурированный каталог.	Невозможность выполнить штатную интеграцию. Длительные переговоры с программистом заказчика, потеря времени.	Настаивать на соблюдении подписанных требований. Выполнить настройку выгрузки на стороне клиента своими силами.
Выполнение настроек 1С на стороне клиента своими силами.	Непрогнозируемая трудоемкость и возможные сложности с нетиповой конфигурацией. Риск «закопаться» в проект. Риск получить в нагрузку к сопровождению сайта — бесплатные консультации по 1С или попасть на исправление каких-то глюков в 1С, которых «не было до вас».	Настаивать на соблюдении подписанных требований к выгрузке. Поручить настройку 1С надежному третьему лицу (к которому в случае чего будут все претензии). Кандидатуру согласовать с заказчиком.
Студия настаивает на соблюдении протокола.	Риск разрыва отношений по причине отсутствия возможности у клиента — реализовать требования самостоятельно. Затягивание сроков сдачи проекта.	Вынести интеграцию с 1С на отдельную фазу. Выполнить настройки 1С самостоятельно. Принять данные в том формате, в котором их способен предоставить клиент.
Программист на стороне заказчика — неуправляем.	Длительные, тяжелые переговоры. Срыв сроков.	Организовать ежедневные трехсторонние call-ы с заказчиком, его программистом и студией. Решить проблему на более высоком уровне (эскалировать).
Студия прогнулась и согласилась изменить требования протокола под любой формат.	Переделка структуры каталога, трудоемкое программирование по интеграции «за бесплатно», сорванные сроки.	Закладывать на интеграцию — очень много денег. Запомнить полученный опыт и более не попадаться.