Как выбрать CMS для сайта компании: редактирование, интеграции и расходы

Начните с работы сотрудников, которые будут менять сайт

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

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

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

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

Не смешивайте CMS, CRM и способ размещения

CMS отвечает за содержимое сайта, CRM — за работу с клиентами и продажами. Они могут обмениваться заявками, но это разные задачи. Когда в разговоре звучит «Битрикс», уточните продукт: «1С-Битрикс: Управление сайтом» позиционируется как CMS для сайтов и интернет-магазинов. Битрикс24 используют для корпоративной работы и CRM; наличие интеграции не делает продукты взаимозаменяемыми.

Отдельно обсуждайте размещение. Система может работать на инфраструктуре компании или предоставляться как облачный сервис. В первом случае нужно определить, кто обслуживает сервер и обновления; во втором — какие ограничения задаёт поставщик и как получать свои данные. Уточните возможности облачного варианта: описание размещения не отвечает на вопросы о правах редактора, интеграциях и переносе.

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

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

Составьте матрицу обязательных и желательных возможностей

Не начинайте с длинного каталога функций. Выберите требования, без которых компания не сможет работать: нужные типы материалов, роли, согласование, каталог, обмен данными, языки, управление адресами. Для каждого требования напишите пример и способ проверки. Формулировка «удобный редактор» слишком расплывчата; «сотрудник создаёт страницу услуги по шаблону без правки кода» уже проверяется.

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

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

Разберите интеграции на конкретных данных

Фраза «есть интеграция с 1С» не объясняет, какие именно сведения будут передаваться. Для CMS интернет-магазина уточните товары, характеристики, цены, остатки, заказы, статусы и направление обмена. Для сайта услуг чаще важны формы, CRM, телефония и аналитика. Разные задачи могут требовать разных подключений и отдельной разработки.

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

Отдельный вопрос — ошибка обмена. Кто её увидит, как обнаружится непереданная заявка, возможен ли повтор без создания дубля? Маркетологу не нужно выбирать технический протокол. Ему нужно согласовать последствия для клиента и получить от исполнителя описание контроля. Успешная демонстрация одной отправки не заменяет проверки отказа.

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

Сравните расходы на несколько этапов жизни сайта

В споре «WordPress или Битрикс» часто сравнивают только цену лицензии. Для решения компании нужен более полный расчёт: настройка, разработка шаблонов, подключение модулей, перенос материалов, обучение, размещение и сопровождение. Состав зависит от проекта; бесплатная лицензия не означает отсутствия оплачиваемой работы, а платная не включает автоматически все доработки.

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

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

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

Проведите демонстрацию на реальной задаче компании

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

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

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

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

Проверьте передачу проекта и возможность сменить исполнителя

До выбора узнайте, какие учётные записи, лицензии, исходники и документы получит компания. Список должен соответствовать архитектуре проекта: для облачного сервиса и собственного размещения он будет различаться. Не предполагайте, что всё автоматически передаётся вместе с оплатой разработки; условия нужно закрепить в договорённостях.

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

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

Если выбор связан с заменой действующей CMS, добавьте отдельный проект переноса: страницы, адреса, изображения, формы, аналитику и историю необходимых данных. Смена системы ради более удобной админки не должна автоматически приводить к удалению работающих страниц. Сначала сравните пользу нового процесса с объёмом и рисками перехода.

Зафиксируйте решение вместе с условиями, на которых оно принято

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

• Редакторские действия показаны на ваших материалах и нужных ролях.
• Обязательные требования закрыты без скрытых предположений.
• Интеграции описаны через данные, ошибки и контроль.
• Стоимость включает запуск, поддержку и внешние платежи.
• Компания понимает, что получит при передаче и как сменит подрядчика.

Сохраните матрицу и образцы вместе с заданием. Если нужна помощь с выбором, передайте ШТАБ ИТ список страниц, сценарии редакторов и действующие системы через форму обращения. На такой основе можно обсуждать архитектуру и бюджет предметно, не превращая выбор CMS в спор о любимых продуктах разработчиков.