Внедрение Битрикс24: Ловушки, о которых никто не говорит

Привет! Меня зовут Ольга Френкель, и я уже пять лет работаю в команде подрядчика, специализирующегося на настройке и автоматизации коробочной версии Битрикс24.

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

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

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

Дьявол кроется в деталях

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

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

1. Почему важны понятные ID для кастомных полей и объектов

Проектирование объектной модели и создание понятных и корректных ID для кастомных (не встроенных) полей и объектов имеет большое значение. Важно, чтобы создаваемые объекты и поля имели читаемые и понятные идентификаторы. Коробочная версия Битрикс24 позволяет задавать их по своему усмотрению, что облегчает передачу разработки между средами без необходимости внесения изменений в код. Это значительно сокращает трудозатраты и упрощает работу с уже созданными разработками. Например, поле с ID «UF_CRM_CONTRACT» сразу указывает на его связь с договорами, что упрощает работу с данными. Наоборот, некорректные и нечитаемые ID, такие как «UF_CRM_65 637E9 725 337», могут увеличить трудозатраты, так как требуют дополнительного времени на поиск информации «А что же это?».

Если вам уже приходилось сталкиваться с некачественной работой подрядчика, существуют два способа решения проблемы: использовать стандартный функционал и назначить каждому полю XML_ID или выполнить массовую корректировку данных. Однако, массовая корректировка это процесс не быстрый и требует значительных усилий, так как необходимо не только переделать идентификаторы, но и сохранить все рабочие процессы и данные в системе. На одном из проектов, где мы переделывали объектную модель и меняли идентификаторы, потребовалось 9 месяцев активной работы команды из 4 аналитиков и 3 разработчиков.

2. Эффективное оформление процессов в редакторе Бизнес‑процессов

Важно уделять внимание оформлению процессов автоматизации в редакторе Бизнес‑процессов, будь то коробочная версия или облачное решение. Хотя оценить корректность автоматизации или её сложность может быть непросто, общее оформление имеет большое значение. Большинство блоков автоматизации следует переименовать так, чтобы их назначение было легко понятно при беглом просмотре. Это поможет быстрее разобраться, что делает каждый блок, даже без глубокого анализа.

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

3. Почему важно правильно оформлять доработки в коробочном портале

Доработка коробочного портала силами программиста требует особого подхода. Во-первых, крайне важно избегать кастомизации ядра портала. Изменения в ядре могут привести к проблемам с обновлениями системы, что может осложнить её поддержку и развитие. Чаще всего доработки выполняются в отдельной папке, такой как «local», чтобы минимизировать воздействие на ядро и сохранить обновляемость системы. Для упрощения процесса доработок необходимо следовать правилам: использовать систему контроля версий, тестировать код на тестовой среде перед переносом на продакшн, создавать отдельные ветки для каждой доработки с внутренней нумерацией задач и давать подробные описания изменений в задачах и коммитах.

На одном из проектов был случай, когда программист внёс изменения в ядро портала без документирования и комментариев. Это вызвало конфликты при обновлении системы, и команда не могла понять, что было изменено. Мы сравнивали чистую и кастомизированную системы, потратив много времени и ресурсов на восстановление работоспособности.

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

Скупой платит дважды

В своей практике я часто сталкивалась с ситуациями, когда попытки заказчика сэкономить на проекте в конечном итоге приводили к значительным дополнительным затратам. Ситуации, когда экономия на начальных этапах казалась разумным решением, но в результате оборачивалась большими проблемами, встречаются очень часто. Вот несколько популярных примеров такой "экономии", которые я наблюдала:

1.      Встречи по сбору и аналитике требований

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

Чтобы минимизировать такие риски, крайне важно заранее проработать требования и ожидания внутри команды заказчика. Это позволит эффективно использовать время на встречах с исполнителями, снизит вероятность недоразумений и поможет избежать дополнительных затрат на исправления и консультации.

2.      Как наличие нескольких сред может снизить риски и затраты на проект

Работа с несколькими средами (stage, test/premaster и prod) значительно повышает надежность внедрения и помогает избежать конфликтов. На стадии разработки и интеграции используются среда stage для создания и первичного тестирования, среда test или premaster предназначена для проверки работы со стороны бизнеса, а подрядчики на этой же среде проверяют наличие конфликтов перед переносом на продакшн (prod). Это позволяет обеспечить, что доработка на этапе продакшн будет корректной и с минимальным риском возникновения ошибок. Отсутствие таких сред может привести к серьезным сбоям и неполадкам в работе системы, что в свою очередь вызовет дополнительные расходы на устранение проблем и может быть критичным в условиях, когда каждый час простоя на счету.

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

3.      Почему качественная документация экономит ваши деньги

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

Неоднократно в моей практике клиенты приходили с уже настроенной системой и доработками, но без документации. В таких случаях приходилось проводить полный аудит системы, чтобы разобраться, что именно было сделано, как это реализовано и что необходимо исправить. Этот процесс занимал много времени и ресурсов, а отсутствие документации приводило к дополнительным затратам и задержкам.

4.      Как отказ от обучения может привести к скрытым расходам

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

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

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

Надеюсь, что мой опыт и советы помогут вам избежать распространенных ошибок и обеспечить успешное внедрение автоматизации в вашей компании. Удачи в ваших проектах!