Выбор CMS лучше начинать не с названий платформ. Вопрос «Битрикс, WordPress, Drupal или что-то свое?» появляется слишком рано.

Сначала нужно понять, как будет устроен проект.

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

Если пока не до конца понятно, какую роль CMS играет в проекте, начните со статьи «Что такое CMS и зачем она нужна сайту».

Для выбора конкретного решения мы бы оценивали корпоративный проект по 6 параметрам:

1. какие данные нужно хранить и как они связаны;
2. кто будет работать с контентом;
3. с какими системами должен обмениваться сайт;
4. где еще будут использоваться данные;
5. какая ожидается нагрузка и какие есть требования к безопасности и инфраструктуре;
6. сколько система будет стоить не только при запуске, но и через несколько лет.

Если большая часть требований стандартная, первым кандидатом обычно становится готовая CMS. Если один контент используют несколько независимых интерфейсов, появляется основание рассматривать headless. Если значительная часть логики проекта плохо укладывается в существующие платформы, имеет смысл отдельно считать собственную систему управления.

Здесь важно не смешивать разные характеристики системы. Готовая и собственная CMS отличаются способом создания, а классическая и headless — архитектурой. Подробнее эту разницу мы разбирали в статье «Какие бывают CMS для корпоративного сайта».

 

Почему не стоит начинать с конкретной CMS

Представим обычное обсуждение нового сайта.

Один участник предлагает «1С-Битрикс», потому что компания уже с ним работает. Другой — WordPress, потому что он дешевле. Техническая команда предлагает headless, потому что frontend планируется разрабатывать отдельно.

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

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

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

«Мы несколько раз видели проекты, где CMS выбирали в самом начале — просто потому, что команда привыкла с ней работать. А уже в процессе выяснялось, что половину требований приходится реализовывать в обход стандартной логики платформы. Поэтому для меня выбор CMS начинается не с названия продукта, а с вопроса: какие данные и процессы она должна обслуживать через 3-5 лет. Если на это есть ответ, список подходящих систем обычно сокращается довольно быстро», — Алексей Постригайло, старший управляющий партнер ИТ-интегратора «Энсайн».

Поэтому к сравнению конкретных платформ имеет смысл переходить после того, как понятны требования.

 

1. Контент и модель данных

Для небольшого сайта структура обычно простая:

• страницы;
• новости;
• статьи;
• вакансии;
• документы.
  
  

Большинство CMS умеют работать с этим без серьезных доработок.

На корпоративных проектах данные могут быть устроены сложнее.

Допустим, у компании есть сеть филиалов. У каждого свои адреса, сотрудники, услуги, режим работы, документы и фотографии.

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

Или сайт работает с мероприятиями, у которых есть площадки, расписание, участники и категории.

Здесь важнее не количество страниц, а то, насколько естественно такая структура укладывается в модель выбранной CMS.

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

 

2. Редакторы, права и согласования

Следующий вопрос — кто будет пользоваться CMS после запуска.

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

Например:

• маркетинг ведет статьи и услуги;
• HR обновляет вакансии;
• пресс-служба публикует новости;
• региональные сотрудники отвечают только за свои филиалы;
• юрист согласовывает отдельные материалы;
• руководитель утверждает публикацию.
  
  

Здесь стандартных ролей «администратор» и «редактор» уже может не хватить.

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

Может ли сотрудник сразу опубликовать материал? Нужна проверка? Кто согласовывает изменения? Нужно ли сохранять предыдущие версии и возможность отката?

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

Права и редакционный процесс лучше определить до начала разработки. Переделывать их после запуска значительно дороже.

 

3. Интеграции и источники данных

Корпоративный сайт редко существует отдельно от других систем.

CMS может быть связана с:

• CRM;
• 1С;
• ERP;
• кадровой системой;
• личным кабинетом;
• корпоративной авторизацией;
• поиском;
• картами;
• аналитикой;
• внутренними справочниками.
  
  

При этом само количество интеграций не главный показатель.

Важнее определить, какая система является источником конкретных данных.

Например, описание услуги меняется в CMS, а стоимость приходит из учетной системы. Карточка сотрудника отображается на сайте, но ФИО и должность загружаются из кадровой системы. Заявка создается на сайте, а дальше должна попасть в CRM.

В такой архитектуре CMS управляет только частью информации.

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

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

 

4. Один сайт или несколько цифровых каналов

Этот вопрос может заметно изменить архитектуру.

Если контент используется только на одном корпоративном сайте, классическая CMS часто закрывает задачу без дополнительной сложности.

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

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

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

Главный вопрос здесь простой:

контент принадлежит одному сайту или им должны пользоваться несколько независимых систем?

Если нескольким, способ взаимодействия CMS с frontend и другими сервисами становится одним из критериев выбора.

 

5. Производительность, безопасность и инфраструктура

Этот блок лучше разбирать до выбора платформы, а не после.

Сначала — нагрузка.

Нужно хотя бы приблизительно понимать:

• сколько пользователей ожидается;
• бывают ли резкие пики посещаемости;
• насколько большой будет каталог;
• много ли динамических фильтров и поиска;
• есть ли требования к скорости загрузки;
• где находятся основные пользователи.
  
  

При этом сама CMS — только одна часть производительности сайта.

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

Второй вопрос — безопасность и размещение.

Нужно определить:

• можно ли использовать облачную CMS;
• требуется ли размещение внутри инфраструктуры компании;
• должна ли административная часть работать только из внутренней сети;
• нужна ли корпоративная авторизация;
• какие действия пользователей необходимо журналировать;
• как устанавливаются обновления;
• как организованы резервное копирование и восстановление.
  
  

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

Поэтому производительность, безопасность и инфраструктуру стоит использовать как фильтр еще до детального сравнения CMS.

 

6. Стоимость владения и развитие системы

Стоимость лицензии хорошо видна в смете, поэтому на нее часто смотрят в первую очередь.

Но для корпоративной CMS это только часть расходов.

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

На старте второй вариант выглядит дешевле. Через несколько лет ситуация может поменяться.

При сравнении стоит учитывать:

• лицензию;
• первоначальную разработку;
• инфраструктуру;
• поддержку;
• обновления;
• доработки;
• работу с уязвимостями;
• стоимость специалистов;
• сложность будущей миграции.
  
  

Стоит учитывать и срок жизни проекта.

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

Поэтому сравнивать лучше не цену CMS, а стоимость владения всей системой на несколько лет вперед.

 

Как принять первое решение

После сбора требований уже можно понять, какие варианты имеет смысл проверять в первую очередь.

Если проект выглядит так	Сначала стоит рассмотреть
Стандартный корпоративный контент, один основной сайт	Готовую классическую CMS
Большая часть необходимых функций уже есть в платформе	Готовую CMS
Один контент используется на сайте, в приложении и других интерфейсах	Headless-архитектуру
Frontend должен развиваться независимо от CMS	Headless-архитектуру
Значительная часть модели данных и процессов нестандартна	Собственную CMS
Есть жесткие требования к размещению и контролю инфраструктуры	CMS с подходящей моделью развертывания
Готовую платформу приходится постоянно глубоко переделывать	Отдельно оценить собственную CMS

 

Это не автоматический выбор технологии.

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

Самый сложный выбор обычно начинается там, где готовая платформа в целом подходит, но под конкретный проект уже требуется заметный объем доработок. Тогда недостаточно сравнить стоимость старта. Нужно отдельно считать поддержку, развитие и цену ограничений платформы. Этому вопросу посвящен отдельный материал — «Готовая CMS или собственная разработка: что выбрать бизнесу».

 

Что зафиксировать перед сравнением конкретных CMS

До обсуждения конкретных платформ стоит собрать хотя бы такой набор вводных.

Блок	Что нужно определить
Контент	Какие сущности будут в системе и как они связаны
Редакторы	Кто работает с CMS и какие права нужны
Публикация	Нужны ли версии, согласования и разные статусы
Интеграции	Откуда приходят данные и куда они передаются
Каналы	Где еще кроме сайта используется контент
Нагрузка	Ожидаемая посещаемость, пики, объем данных и поиск
Безопасность	Требования к доступу, журналированию и размещению
Инфраструктура	Облако или собственный контур
Развитие	Что может появиться в проекте через несколько лет
Поддержка	Кто будет сопровождать и обновлять систему
Экономика	Стоимость владения, а не только запуска

 

После этого сравнение становится предметным.

Можно проверять не абстрактное количество функций платформы, а ее соответствие реальному проекту.

 

Что должно насторожить при выборе CMS

Есть несколько аргументов, при которых с решением лучше не торопиться.

«Мы всегда делаем на этой CMS»

Опыт команды с платформой — плюс. Но он не заменяет анализ требований.

Иначе легко выбрать архитектуру исходя из привычки подрядчика, а не задачи проекта.

«У этой CMS дешевле лицензия»

Без стоимости разработки и поддержки эта цифра мало что значит.

Платная CMS может сэкономить сотни часов доработок. Бесплатная — потребовать серьезного бюджета на настройку и сопровождение.

Считать нужно весь жизненный цикл.

«Почти все можно закрыть плагинами»

Несколько сторонних модулей — нормальная ситуация.

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

«Сразу сделаем headless или свою CMS, чтобы потом не было ограничений»

Более сложная архитектура имеет смысл, когда решает конкретную проблему.

Если такой проблемы пока нет, запас гибкости просто увеличивает стоимость разработки и поддержки.

 

Какой результат должен дать подрядчик

От подрядчика в такой задаче нужен не просто ответ:

«Мы рекомендуем CMS X».

Сначала должны быть зафиксированы требования.

После этого команда показывает:

• что закрывается стандартными возможностями платформы;
• какие функции потребуют разработки;
• где есть архитектурные ограничения;
• сколько будет стоить запуск;
• что потребуется для дальнейшего сопровождения.
  
  

Если выбранная CMS требует компромисса, он должен быть понятен до начала разработки.

Иначе последствия решения проявятся уже после запуска, когда смена платформы будет стоить значительно дороже.

 

Что в итоге

Для корпоративного сайта CMS стоит выбирать по требованиям проекта, а не по популярности продукта или привычному стеку подрядчика.

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

После этого можно сравнивать конкретные платформы и считать стоимость владения.

Для проекта со стандартным контентом и одним основным сайтом разумной отправной точкой обычно будет готовая CMS.

Если один контент нужен нескольким независимым системам, стоит проверить headless-подход.

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

Когда готовую систему еще разумно дорабатывать, а когда затраты на адаптацию уже говорят о необходимости другой архитектуры? Об этом — в следующей статье серии: «Когда требуется создание собственной CMS».