Когда бизнесу нужна собственная CMS: 7 признаков

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

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

В этот момент вопрос меняется. Нужно понять не «можно ли сделать следующую задачу на текущей CMS», а сколько еще будет стоить сохранение этой CMS как основы проекта.

Если система только выбирается и таких проблем еще нет, критерии нового проекта мы собрали в статье «Как выбрать CMS для корпоративного сайта».

А здесь разберем 7 признаков, по которым можно понять, что действующая CMS сама начинает становиться ограничением.

 

1. Бизнес-сущности приходится собирать из обходных конструкций CMS

На корпоративном сайте появляются собственные типы данных: услуги, филиалы, объекты, мероприятия, документы, сотрудники.

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

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

Для редактора все это еще может выглядеть как одна карточка. Для разработчика любое изменение уже означает работу с несколькими слоями системы.

Хороший проверочный вопрос:

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

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

 

2. Сопоставимые изменения со временем становятся дороже

Допустим, 2 года назад команда добавила новый тип объекта. Сейчас появилась похожая по масштабу задача.

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

Сама бизнес-задача не стала сложнее. Стало дороже вмешиваться в существующую архитектуру.

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

Почему это влияет на экономику проекта, мы отдельно разбирали в статье «Готовая CMS или собственная CMS: что выбрать бизнесу».

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

 

3. Команда не может быстро определить, где находятся актуальные данные

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

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

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

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

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

 

4. Один и тот же контент приходится поддерживать в нескольких копиях

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

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

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

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

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

 

5. Реальный процесс работы с контентом происходит вне CMS

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

Автор готовит материал в документе. Согласование идет по почте. Юрист присылает правки в мессенджере. Статус публикации ведется в таблице. После всех согласований редактор вручную переносит итоговую версию в CMS.

Формально система управления контентом есть. Фактически она участвует только в последнем шаге.

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

Это тоже затраты, просто они не видны в смете разработки.

 

6. Инфраструктура держится на постоянных исключениях вокруг платформы

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

Вопрос в количестве накопленных исключений.

Со временем в проекте могут появиться правила вроде:

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

Каждое такое решение можно объяснить историей проекта. Вместе они создают постоянную стоимость поддержки.

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

 

7. Ограничения CMS начинают менять дорожную карту бизнеса

Это самый серьезный признак.

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

Ситуация меняется, когда разговор начинает звучать иначе:

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

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

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

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

 

Один признак еще не означает, что CMS нужно менять

Сложная доработка — не повод писать собственную систему.

Большая интеграция — тоже.

Даже несколько неудачных архитектурных решений еще можно исправить внутри существующей платформы.

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

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

Возможно, компания регулярно платит за одну и ту же причину — несоответствие архитектуры CMS задачам продукта.

 

Как проверить, сколько денег уходит именно на ограничения CMS

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

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

Для каждой задачи их стоит разделить на 2 части.

Работа над самой бизнес-функцией

То, ради чего задача вообще появилась:

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

Работа, появившаяся из-за текущей CMS

Например:

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

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

Условно, если новая функция потребовала 80 часов разработки и еще 10 часов ушли на особенности платформы, CMS вряд ли является основной проблемой.

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

Конкретная пропорция здесь не является нормативом.

Важна динамика: растет ли доля работ, которые не создают новую ценность для бизнеса, а нужны только для сохранения существующей архитектуры.

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

 

Что не является достаточной причиной для собственной CMS

«Хотим перестать зависеть от готовой платформы»

Собственная CMS уберет зависимость от производителя.

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

Поэтому сама независимость ничего не говорит о выгоде решения.

«Своя система будет гибче»

Будет.

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

«Нам не нравится административная панель»

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

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

 

Что делать, если несколько признаков совпали

Не начинать разработку новой CMS на следующий день.

Следующий шаг — сравнить 2 сценария на одной и той же дорожной карте продукта.

Первый — оставить текущую платформу.

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

Второй — перейти на другое управляющее ядро.

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

Результат вполне может показать, что еще несколько лет выгоднее развивать существующую CMS.

Это нормальный вывод.

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

Если несколько признаков совпали

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

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

 

Оценить архитектуру веб-проекта →

 

Что в итоге

Собственная CMS нужна не тогда, когда готовую приходится дорабатывать.

Доработки сами по себе нормальны.

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

На это указывают 7 признаков:

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

Один симптом еще ничего не доказывает.

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

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

Не ради собственного решения как такового.

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