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

Автор: Владимир Завертайлов, Сибирикс (Генеральный директор)

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

…Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Самая красивая интеграция, естественно, у 1C Битрикс (сходите по ссылке и почитайте! у всех остальных — дела намного хуже!). Нужно сделать пару настроек, и товары полетят в Битрикс, а заявки — обратно, в 1С-ку.

Когда она так работает — я ее люблю.

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

В реальности сценарий продажи и внедрения интеграции может превратиться в АДъ!:

Фаза пресейла:

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

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

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

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

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

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

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

Зафиксируйте договоренности письменно.

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

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

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

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

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

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

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

Далее – события развиваются по любопытному сценарию.]

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

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

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

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

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

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

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

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

Источник: http://www.cmsmagazine.ru/library/items/cms/integrating-the-site-with-1c-risks-and-a-little-reality/

Читать комменты и комментировать

Добавить комментарий / отзыв



Защитный код
Обновить

Интеграция сайта с 1С — риски и немного реальности | | 2012-03-20 20:56:44 | | Статьи Web-мастеру | | Автор: Владимир Завертайлов, Сибирикс (Генеральный директор) Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено | РэдЛайн, создание сайта, заказать сайт, разработка сайтов, реклама в Интернете, продвижение, маркетинговые исследования, дизайн студия, веб дизайн, раскрутка сайта, создать сайт компании, сделать сайт, создание сайтов, изготовление сайта, обслуживание сайтов, изготовление сайтов, заказать интернет сайт, создать сайт, изготовить сайт, разработка сайта, web студия, создание веб сайта, поддержка сайта, сайт на заказ, сопровождение сайта, дизайн сайта, сайт под ключ, заказ сайта, реклама сайта, хостинг, регистрация доменов, хабаровск, краснодар, москва, комсомольск |
 
Поделиться с друзьями: