Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено 75%. То есть, в трех случаях из четырех — придется че-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…
…Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Самая красивая интеграция, естественно, у 1C Битрикс (сходите по ссылке и почитайте! у всех остальных — дела намного хуже!). Нужно сделать пару настроек, и товары полетят в Битрикс, а заявки — обратно, в 1С-ку.
Когда она так работает — я ее люблю.
Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Иначе корову не продашь.
В реальности сценарий продажи и внедрения интеграции может превратиться в АДъ!:
Анализ диалога:
Менеджер — уже тертый калач и задает правильные вопросы. Но на фазе пресейла такие детали, как правило, неизвестны заказчику, а выяснять их долго и муторно. Проще выбрать того подрядчика, который не станет задавать таких вопросов. Попытка менеджера проекта перенести интеграцию на дальнейшие этапы способствует тому, что фаза пресейла пройдет более гладко.
Но на практике это может привести к большим проблемам уже после запуска системы, когда выяснится, что структура каталога товаров в 1С и его структура на сайте — принципиально разные. Информация о том, что 1С кто-то дописывает — очень тревожный сигнал, равно как и то, что клиент планирует менять версию 1С. Зачастую, одновременно с этим может потребоваться доработка сайта на Bitrix или другой CMS, так как интеграция может начать идти по другому.
Как правило, это гарантирует, что штатной интеграции не хватит.
Анализ диалога:
Непредоставление выгрузки или доступа к 1С, к сожалению, — частая проблема. На этом же этапе работ я бы порекомендовал начинать взаимодействие с программистом заказчика (вполне возможны разного рода неожиданности). Порой — это самый дешевый и реальный вариант. Договоритесь с заказчиком, чтобы он организовал вам колл с программистом, добейтесь того, чтобы программист либо дал вам доступ к выгрузке, либо 100% согласился обеспечить выгрузку и настройки под ваши требования.
Зафиксируйте договоренности письменно.
Анализ диалога:
Практически гарантированный фэйл. Программистам нужно спроектировать структуру каталога, но, если выгрузка из базы будет принципиально другой, — это нужно учесть заранее. Пожалуй, тут еще все можно было бы и спасти, но…
Анализ ситуации:
Ну все, фэйл случился. Теперь проджект-менежер будет пытаться «рулить» удаленным программистом, который не стоит у него в подчинении, и которого он не нанимал. Все зависит от того, какое чувство собственной важности у программиста на стороне клиента… И не дай бох оно будет >9000 :).
Далее – события развиваются по любопытному сценарию.
Анализ ситуации:
Если давить на программиста заказчика — можно выяснить, что он либо не разобрался в спецификации, либо пробовал, но у него не получилось, либо уже нагородил какого-то своего говнокода или какой-то свой «универсальный» формат, от которого теперь не хочет отступать. Особенная жесть начинается, если ваш клиент платит своему 1С-нику — почасовую ставку, и 1С-ник утверждает, что работа с его стороны займет неделю, из-за ваших «необоснованных» требований (или уникальности «нашей базы»).
Анализ ситуации:
Для краткости показаны только самые сильные ходы ПМ-а. На самом деле можно протрахаться значительно дольше. Вырулить можно, но о попадании в бюджет и срок — уже речи не идет. Виноват — клиент, (в договоре формально закреплено, что выгрузка будет предоставлена в требуемом формате), но это неважно, поскольку цель ПМ-а — запустить проект, а не доказать «виноватость». Главное не вестись на разговоры вроде «вы же профессионалы, должны были предусмотреть». Вы предусмотрели и решили продолжить работы, имея открытый риск. А риск, увы, — сработал.
Лечится, как правило, увеличением цены на 2-3-4 человеко-дня со стороны программистов студии, и еще часов 8-16 нервных переговоров со стороны менеджера проектов и клиента. Собственно, отсюда и разница в цене — $N за штатную интеграцию, $MMM — за нештатную. Нервные клетки не восстанавливаются.
Риск/ситуация | Последствия | Противодействие |
---|---|---|
Выгрузка запрошена на этапе пресейла. |
|
|
Выгрузка не предоставлена на этапе составления ТЗ. |
|
|
Интеграция вынесена в отдельный этап. |
|
|
1С был модифицирован сторонним разработчиком, имеет устаревшую версию или плохо структурированный каталог. |
|
|
Выполнение настроек 1С на стороне клиента своими силами. |
|
|
Студия настаивает на соблюдении протокола. |
|
|
Студия прогнулась и согласилась изменить требования протокола под любой формат. |
|
|
Программист на стороне заказчика — неуправляем. |
|
|
Сколько же копий уже сломалось в дискуссиях на тему интеграции с 1С… Когда речь заходит о функционале, творческие личности уходят на второй план, а на первый – выходят технари.
Рейтинг разработчиков интернет-магазинов – удобный инструмент для выбора веб-студии, где есть хорошие специалисты и из первой, и из второй категории.
Помимо прочих нюансов, при разработке интернет-магазина важно, обладает ли веб-студия необходимым опытом работы в конкретной тематике. Например, интернет-магазины, предназначенные для оптовых b2b-продаж, существенно отличаются от магазинов одежды, ориентированных на розничные покупки. Согласны? Тогда обязательно используйте инструмент «Топ разработчиков по отраслям проектов», расположенный справа от рейтинга.
Владимир написал отличную статью о проблемах интеграции с 1С. Для нашей компании этот вопрос очень актуален: мы разрабатываем десятки интернет-магазинов ежегодно, и большая часть требует интеграции с 1С.
В своей работе мы сталкиваемся со всеми проблемами, перечисленными в статье. Также как и у Владимира, не менее 75% проектов с интеграцией с 1С превышают выделенный бюджет по этому этапу. Более того, даже при наличии типовой конфигурации и возможности использовать обмен с сайтом «одной кнопкой» требуется значительное время менеджера, чтобы объяснить, куда нажимать, что делать и где смотреть.
Проблемы с интеграцией с 1С очень часто являются причиной неудовлетворенности проектом с обоих сторон — как со стороны Заказчика, так и со стороны Исполнителя.
При этом способы решения проблемы с интеграцией также очень хорошо описаны в статье Владимира и сводятся, по сути, к трем методам:
Сейчас мы применяем первый и второй способы, но проблема настолько актуальна, что мы уже близки к обучению собственных сотрудников программированию в 1С.
Статья написана безусловно правильно и большинство сценариев подтверждены лично к сожалению.
Самый правильный способ ведения любого в принципе общения с клиентом — это разделение проекта на подзадачи. Для этого создается общий договор «На оказание услуг». В рамках договора создается «Спецификация» на этап разработки. Таким образом проект будет сдаваться частями, клиент будет реально ощущать, что работа идет, а студия будет получать постоянные денежные транши.
Что касается самого момента интеграции, лучшим вариантом в нашем опыте является знакомство программистов студии с программистом клиента на стадии составления ТЗ для уточнения всех возможных ситуаций. Этот момент поможет решить ряд вопросов еще на стадии согласования, заодно можно сразу посмотреть адекватный он или ЧСВ9000+, может и не имеет смысла браться за проект.
Автор статьи описывает типичные проблемы, которые часто возникают у разработчиков интернет-проектов.
В наших проектах для 30% случаев хватает стандартной интеграции, в 70% — требуется индивидуальная интеграция.
Избежать рисков описанных в статье можно за счет четких требований на каждом из этапов работы с клиентом и четкого документирования всех обсуждаемых вопросов. Мы для этого документируем все переговоры во внутренних системах — «Ареал CRM» и «1С-Битрикс: Корпоративный портал». В последнем клиент подключается в «экстранет», где фиксируются все «телодвижения» сторон.
Если требуется синхронизация между 1С и интернет-проектом, то нужно четко указывать какие работы будут сделаны, стандартная эта синхронизация или нет, указывать версию и конфигурацию 1С, с которой стандартная синхронизация будет работать.
Постараюсь показать, как мы решаем данный вопрос. Проект считается, успешным, если он соответствует четырем критериям: соблюдены заявленные сроки, проект укладывается в бюджет, по завершению работы клиент доволен сотрудничеством и, как следствие, остался в компании на дальнейшее сопровождение. Совершив ошибку во взаимодействии с клиентом в вопросах интеграции, вы получаете гипотетические сложности на пути соблюдения этих требований.
Мы сформировали три пакета услуг по интеграции с 1С:
Все три пакета имеют фиксированную стоимость для клиента. По первым двум пакетам понятны трудозатраты, поэтому стоимость их для всех клиентов одинаковая. Стоимость третьей оценивается в зависимости от сложности интеграции аналитиком на этапе подготовки коммерческого предложения (если клиент готов к этому) или на этапе проектирования при составлении технического задания. В случае если на этапе проектирования клиент не определился с пакетом интеграции, то данный вопрос переносится на техническую поддержку после завершения этапа разработки проекта.
Если на этапе пресейла клиент настаивает на включение в смету пакета интеграции с 1С, но определить его формат невозможно, то менеджер добавляет в смету стандартный пакет, в котором зафиксированы все особенности включённого варианта.
Хочется также отметить, что в статье правильно отмечено, что если менеджер проектов начинает взаимодействовать напрямую с техническим специалистом от клиента, то неминуемо возникнут сложности. Я считаю, что в данном вопросе все переговоры должны идти при присутствии всех заинтересованных сторон: менеджер проекта, технический специалист, клиент, технический специалист клиента и с обязательным фиксированием всех договоренностей, с обозначением сроков.
Статья хорошая и очень актуальная. Немногие из клиентов и разработчиков сайтов смотрят на интеграцию интернет-магазина с 1С как на сложную организационную задачу в первую очередь, а не техническую. Интеграционный проект, на стыке систем с разными ответственными, требуется начинать прорабатывать именно с организационных вопросов и планирования сценариев работы, а потом уже браться за функционал и код. В статье отмечено множество подводных камней интеграции, и я очень рекомендую ее для всех, кто с такими задачами сталкивается.
В тоже время, стоит отметить, что и 1С и 1С-Битрикс, разрабатывая интеграцию, пытались многие трудности предугадать и облегчить. Очень много удалось сделать в типовой интеграции: готовность к ограничениям хостинга, разные требования к бизнес-процессу обработки заказов, независимость 1С от работы сайта и другие. И работа над созданием дополнительной гибкости ведется постоянно. По нашему мнению в этой задаче она вряд ли когда-то будет излишней.
Тема интеграции с 1С действительно очень актуальна и набила оскомину многим участникам и клиентам рынка веб-разработки.
Из своего опыта я вынес следующее.
Номер ноль — это вначале делаем интеграцию, потом программируем сайт :)
1. Пресейл.
Согласен с автором, что начинать стоит с разъяснительных работ с клиентом, чтобы убрать шоры с его глаз. Затем необходимо собрать максимально полную информацию:
— есть ли у клиента программист 1С в штате и если нет, то готов ли он к нашему специалисту или он работает с франчайзи (с кем?);
— версию и конфигурацию 1С;
— была ли она переписана и насколько сильно;
— какие данные будут выгружаться из 1С;
— какие данные не будут выгружаться из 1С :)
— какие данные должны загружаться с сайта в 1С;
— совпадает ли каталог 1С с будущим каталогом на сайте;
— есть ли у товаров множественные характеристики и если есть — используются ли они в 1С;
— как будут загружаться картинки (очень частый камень преткновения);
— какие данные и как часто должны ходить в обе стороны (тут, кстати, можно неожиданно для себя узнать, что клиент хочет чуть ли не обмен данными через веб-сервис);
Мой совет — составить анкету и отправлять ее на этапе пресейла.
На этапе пресейла действительно важно правильно оценить стоимость интеграции для разработчика. Опыт показывает, что трудозатраты на консультации клиента и управление проектом менеджером обычно в несколько раз превышают затраты на саму интеграцию. Поэтому эти трудозатраты должны быть примерно оценены. Я советую использовать метод PERT (он кстати есть в MS Project) и прогнозировать необходимое количество времени.
Математика простая: делаем оптимистичный прогноз t(0), пессимистичный прогноз t(П) и реалистичный t(Р).
Ожидаемый срок будет следующим: ( t(O) + 4 t (П) + t (P) )/ 6
Приведем пример. Допустим, мы пообщались с нашим программистом и оценили его сроки так:
— оптимистичный срок — 20 часов
— реалистичный — 35 часов
— пессимистичный — 60 часов (но потом вспомнили, что у программиста скоро ДР, и он может пару дней не прийти и поставили 70 :)
Итак, посчитаем реальный ожидаемый срок: (20+35*4+70) = 38,33.
Вы можете также вводить свои поправочные веса.
Применение метода PERT в жизни будет оправдано при одном условии: наши оценки исходят из статистики прошлых проектов, а не из придуманных данных.
2. Документация
Лучше всего по возможности делать отдельное ТЗ на интеграцию описывающее все: от адреса, по которому должна 1С обращаться к сайту, заканчивая структурой файлов с указанием типов полей.
Следующий важный момент — это учет в Договоре специфики работ по интеграции, чтобы потом можно было к нему апеллировать. Желательно описывать ход работ по интеграции в отдельном подпункте.
И, наконец, обязательно вести протоколирование встреч. Если начинаются проблемы, то пишем клиенту на бланке компании официальное письмо с требованиями о предоставлении данных или просьбу о пробной загрузке данных с их стороны. При этом в письме должны обязательно содержаться ссылки на пункты Договора, Сметы и ТЗ на интеграцию.
3. Сдача работ:
В особо сложных случаях можно поступить хитрым способом. Заключить Договор так, что при создании ТЗ мы обязаны создать тестовые эталонные файлы. При этом, критерием работы механизма интеграции будет приемка именно этих файлов.
Такой способ помогает решить две задачи:
— понять, на чьей стороне ошибка после сдачи проекта (если тестовый файл проходит, значит проблема появилась на стороне клиента и будет решаться платно :)
— сдать проект до того, как клиент доведет 1С до нужных кондиций. Когда есть утвержденные ТЗ и эталонные файлы, мы можем легко сдать проект, не дожидаясь программиста клиента. И это отличный способ сократить время разработки (жаль, что такой договор получается заключить нечасто).
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Генеральный директор в Интаро
Согласен с автором статьи, тема актуальная. Мы давно рассматриваем каталог товара с его структурой, характеристиками и остатками как стержневой элемент проекта по разработке интернет-магазина. Ведь дальнейшая реализация нетиповых сервисов товарного каталога завязано на спроектированный каталог. Поэтому требуем выгрузку из 1С на самых ранних этапах проекта. На этапе пресейла делаем пессимистичные оценки и предупреждаем о проблемах клиента.