1a:T77bd,

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

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

Так мы решили включить HConfig в Единый реестр российских программ для электронных вычислительных машин и баз данных, который обычно называют реестром российского ПО или реестром Минцифры.

Первую заявку мы подали 24 октября 2025 года. Дальше последовали 2 отказа, доработка юридической документации, проверка архитектуры и несколько месяцев работы. 17 апреля 2026 года HConfig был включен в реестр российского ПО под номером 32983.

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

Зачем мы решили включить HConfig в реестр российского ПО

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

На практике процесс оказался значительно глубже.

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

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

«Мы заходили в процедуру с ощущением, что основная сложность будет в сборе документов. В результате самым полезным оказался другой эффект: пришлось последовательно разобрать продукт как объект, который должен существовать независимо от конкретного разработчика, сервера или внешнего сервиса. Для зрелого программного продукта такая проверка сама по себе полезна», — Алексей Постригайло, старший партнер Энсайн.

Первая заявка: почему рабочего продукта оказалось недостаточно

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

Заявку отклонили.

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

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

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

Вторая попытка: проблема с правообладателями

После первого отказа мы переоформили домен, расширили документацию и подготовили новую заявку. Она тоже не прошла.

Причиной стала структура прав на HConfig.

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

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

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

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

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

Какие документы пришлось дорабатывать

После второго отказа мы обратились в поддержку реестра за разъяснениями. Этот шаг оказался полезнее попыток самостоятельно интерпретировать каждое требование.

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

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

У HConfig появилась полноценная документальная история: от создания программного обеспечения и оформления прав до постановки на учет и эксплуатации.

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

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

Техническая проверка HConfig

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

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

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

Для нас здесь было важно нативное взаимодействие с РЕД ОС 8. Эксперту требовалось понимать, как продукт устанавливается и функционирует именно в заявленной конфигурации.

Что происходит с программой без доступа в интернет

Еще один практический вопрос касался эксплуатации в изолированной инфраструктуре.

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

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

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

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

Почему README оказалось мало

Еще одна часть работы, которую легко недооценить, — документация.

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

Для внешней проверки такой подход не подходит.

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

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

Если ответ отрицательный, документация еще не закончена.

Сколько работы занимает подготовка к реестру

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

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

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

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

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

Результат: HConfig в реестре российского ПО

После нескольких попыток и доработки заявки HConfig был включен в реестр российского ПО. Номер реестровой записи — 32983.

Для нас результат важен прежде всего с продуктовой точки зрения.

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

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

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

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

Что проверить перед подачей заявления в реестр российского ПО

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

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

Какие ошибки при регистрации ПО мы считаем самыми дорогими

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

Исправить большинство таких проблем можно. Цена вопроса заключается во времени команды и дополнительных циклах подачи заявления.

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

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

Что в итоге дала нам регистрация HConfig

Главный результат для Энсайн оказался шире самой записи в реестре.

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

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

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

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

Частые вопросы о включении ПО в реестр

Что такое реестр российского ПО?

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

Достаточно ли свидетельства Роспатента для включения программы в реестр?

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

Проверяется ли техническая часть программы?

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

Можно ли повторно подать заявление после отказа?

Да. Мы несколько раз дорабатывали комплект документов и повторно подавали заявление. В результате HConfig был включен в реестр под номером 32983.

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

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

Вывод

История HConfig показала нам, что регистрация в реестре российского ПО начинается задолго до заполнения формы на портале.

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

HConfig прошел этот путь после нескольких попыток. 17 апреля 2026 года продукт Энсайн был включен в реестр российского ПО под номером 32983.

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

1b:T1fe4,

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

Роль информационной поддержки в улучшении пользовательского опыта

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

Удобный доступ к информации

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

Разместите важную информацию в очевидных местах:

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

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

Минимизация времени ожидания

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

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

Персонализированный подход

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

Например:

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

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

Автоматизация процессов

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

Чат-боты для стандартных запросов или системы самопомощи.
Автоматические уведомления для клиентов, чтобы они знали, что их запрос принят и находится в обработке.
CRM-системы для персонализированных и быстрых ответов на запросы.

Постоянное улучшение через анализ данных

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

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

Подведем итоги

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

1c:T50f1,

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

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

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

Что такое CMS и как она работает

CMS расшифровывается как Content Management System — система управления контентом.

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

Все это можно жестко прописать в коде. Но тогда при изменении текста или фотографии придется обращаться к разработчику.

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

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

название услуги;
краткое описание;
основной текст;
изображение;
документы;
статус публикации.

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

Упрощенно процесс выглядит так:

Редактор

↓

CMS

↓

Контент

↓

Сайт

↓

Посетитель

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

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

Что происходит, если CMS нет

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

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

Но на корпоративном сайте информация постоянно обновляется.

Появилась новая услуга. Открылась вакансия. Сменился руководитель подразделения. Изменился номер телефона филиала. Нужно разместить пресс-релиз или новый документ.

Без CMS обычное изменение превращается в техническую задачу:

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

Само изменение может занимать несколько минут. Но на сайте оно появится значительно позже.

CMS убирает разработчика из тех операций, где разработка как таковая не требуется.

Что можно делать через CMS

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

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

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

Причем разные материалы могут иметь разную структуру.

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

Загружать изображения и документы

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

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

Управлять пользователями и правами

Корпоративным сайтом редко занимается один человек.

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

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

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

Хранить историю изменений

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

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

Управлять публикацией

Материал не обязательно должен сразу появляться на сайте.

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

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

Зачем CMS бизнесу

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

Сотрудники меньше зависят от разработчиков

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

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

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

Изменения появляются быстрее

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

Не нужно ждать свободного разработчика и ставить отдельную техническую задачу.

Чем чаще меняется сайт, тем заметнее эта разница.

Информация остается структурированной

Допустим, у компании 100 филиалов.

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

Но надежнее создать единый тип данных «Филиал»:

Название
Адрес
Телефон
Режим работы
Координаты
Услуги
Фотографии

Все филиалы будут заполняться одинаково.

Так же можно работать с сотрудниками, услугами, товарами, документами, мероприятиями и другими повторяющимися объектами.

Несколько подразделений могут работать с сайтом одновременно

На большом сайте контент обычно распределен между разными подразделениями.

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

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

CMS, админка и сайт — в чем разница

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

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

CMS — система управления содержимым сайта и связанными с ним процессами.

Админка — интерфейс, через который сотрудники работают с CMS.

Поэтому наличие административной панели еще ничего не говорит о возможностях самой системы.

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

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

Как CMS работает на крупном корпоративном сайте

На небольшом сайте CMS действительно может ограничиваться страницами и новостями.

На больших проектах ситуация другая.

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

Задача была не просто в создании новой административной панели.

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

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

Это важная граница.

На корпоративном уровне CMS постепенно превращается из редактора страниц в систему управления данными сайта.

Может ли CMS работать с CRM, 1С и другими системами

Да.

На корпоративных проектах часть информации часто находится за пределами CMS.

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

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

Но сама по себе она интеграции не создает. Это уже задача архитектуры и разработки конкретного проекта.

Каждому ли сайту нужна CMS

Нет.

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

Но чем чаще сайт меняется, тем больше от нее пользы.

CMS особенно нужна, если после запуска сотрудники должны регулярно:

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

Можно использовать простой критерий:

если завтра на сайте нужно что-то изменить, кто должен это сделать — сотрудник компании или разработчик?

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

Чего CMS сама по себе не решает

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

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

CMS дает инструменты для управления.

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

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

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

Что в итоге

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

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

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

Дальше возникает следующий вопрос: какую CMS выбрать под конкретный проект.

1d:T33f5,

В крупных компаниях разговор о legacy почти всегда начинается одинаково.

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

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

Это не сбой процесса. Это состояние системы.

Что на самом деле называют legacy

Legacy часто путают с возрастом или стеком. Система старая. Технологии не модные. Код писали десять лет назад. На практике это вторично.

Система становится legacy не тогда, когда ей много лет, а тогда, когда она перестает быть управляемой как целое.

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

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

Проблема не в том, что система сломана.

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

Почему изменения перестают быть локальными

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

Часть зависимостей не описана. Они появились со временем, через временные решения и обходные пути. Тестов либо нет, либо они не отражают реальное поведение системы. Границы между модулями размыты. Ручные операции встроены в поток работы. Люди боятся что-то трогать и перестраховываются.

В итоге каждая доработка превращается не в задачу разработки, а в работу с неопределенностью. Команда не ускоряется, а замедляется. Любое изменение проверяют несколько раз. Любой релиз сопровождается тревогой.

Снаружи это выглядит как неэффективность.

Изнутри — как попытка не уронить бизнес.

Именно в этой точке обычно и начинаются управленческие ошибки.

Типовые ошибки управления legacy

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

Первая ошибка — усиление команды без изменения подхода

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

Вторая ошибка — смена подрядчика в надежде на свежий взгляд

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

Третья ошибка — попытка переписать систему целиком

Решение кажется логичным, пока не начинается реализация. Сроки растут. Бюджеты растут. Старая система все это время продолжает жить и требовать внимания. Часто проект так и остается в подвешенном состоянии, но ответственность за него никуда не исчезает.

Четвертая ошибка — игнорирование поддержки ради новых фич

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

Какие стратегии реально существуют

У legacy нет правильной стратегии. Есть допустимые.

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

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

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

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

Важно понимать одну вещь. Эти стратегии выбирают не тогда, когда система окончательно сломалась. Их выбирают заранее, пока еще есть пространство для маневра. Когда система еще «работает».

Legacy как зона ответственности CIO

В какой-то момент работа с legacy перестает быть задачей разработки. Это становится управленческой задачей.

Здесь не работает логика ускорения delivery. Попытки просто увеличить скорость почти всегда заканчиваются ростом рисков. Главная цель смещается. Важно не сделать быстрее, а сохранить контроль.

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

Legacy — это зона, где ответственность не делегируется полностью ни команде, ни подрядчику. Ее все равно приходится нести.

«Когда мы начинаем работать с legacy-системой, важно понимать, что это не просто устранение ошибок, а управление рисками, которые накапливаются годами. Важно вовремя вмешаться, прежде чем система начнёт ломаться под нагрузкой. Каждый пропущенный этап в модернизации увеличивает вероятность катастрофы. Чем раньше начнём, тем меньше рисков для бизнеса в будущем», — Алексей Постригайло, старший партнер, ИТ-интегратор ЭНСАЙН

Что стоит зафиксировать до следующей доработки

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

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

Эти вопросы не ускорят работу.

Зато они уменьшают число неожиданных проблем.

Вместо вывода

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

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

В крупных компаниях это не самый простой путь.

Зато самый честный.

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

1e:T629d,

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

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

Поэтому headless, API-first и развитие ИИ-агентов стоит рассматривать не как 3 независимых тренда. Они складываются в одну последовательность: контент отделяется от конкретного сайта, становится доступен программно, а затем к данным и операциям получают контролируемый доступ ИИ-системы.

Как устроены классическая и headless CMS, зачем нужен API-first подход и чем эти архитектуры отличаются, подробно разобрано в статье «Какие бывают CMS для корпоративного сайта». Здесь важнее следующий этап развития.

Что изменилось в CMS к 2026 году

Headless отделил управление контентом от конкретного интерфейса, а API-first сделал программную работу с данными штатным сценарием.

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

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

ИИ-агент становится новым пользователем CMS

Обычная автоматизация выполняет заранее определенную последовательность.

Например:

после публикации отправить уведомление;

ночью обновить справочник;

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

Агентный сценарий устроен иначе.

Можно поставить задачу:

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

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

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

Для этого административная панель ему не нужна.

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

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

Что уже происходит у Contentful, Drupal и WordPress

Это направление уже видно в развитии крупных CMS и контентных платформ.

Платформа	Что происходит	Статус
Contentful	MCP предоставляет агентам инструменты для работы с контентом и операциями платформы	Доступно
WordPress	Abilities API описывает функции сайта, а MCP Adapter предоставляет их ИИ-агентам как инструменты	Доступно
Drupal	Развиваются агентные сценарии, governance, версии и human-in-the-loop механизмы	Развивается по AI Roadmap 2026

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

В WordPress Abilities API позволяет регистрировать типизированные и доступные для обнаружения функции, а MCP Adapter преобразует такие abilities в инструменты, которые может использовать агент.

Drupal в 2026 году развивает AI-направление вокруг агентной инфраструктуры, версионирования изменений, аудита и подтверждения действий человеком.

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

Что MCP меняет в работе с CMS

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

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

MCP — Model Context Protocol — стандартизирует подключение ИИ-систем к внешним данным и инструментам. В CMS это позволяет предоставить агенту конкретный набор операций, которыми он может пользоваться.

Упрощенный сценарий может выглядеть так:

агент получает задачу;

видит, что ему доступны поиск материалов, чтение карточки и создание черновой версии;

находит нужные записи;

выполняет разрешенные изменения;

возвращает результат.

Ключевое слово здесь — разрешенные.

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

Чем больше может агент, тем важнее контроль

Генерация одного текста и массовое изменение 10 000 записей имеют совершенно разную цену ошибки.

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

Поэтому при подключении ИИ права, версии и журналирование становятся еще важнее.

Для корпоративной CMS необходимо понимать:

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

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

Drupal уже строит подобные сценарии: AI может подготовить макет, черновик или SEO-метаданные, но изменения сохраняются в отдельной revision branch и проверяются человеком до публикации.

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

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

Подготовить черновик — один уровень риска.

Изменить опубликованную цену — другой.

Удалить данные — третий.

CMS должна уметь различать эти сценарии.

Админка перестает быть единственным интерфейсом CMS

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

Меняется способ взаимодействия с системой.

Обычный сценарий:

открыть раздел → найти карточку → изменить поле → сохранить.

Агентный сценарий:

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

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

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

Кто работает с CMS	Как взаимодействует
Сотрудник	Административный интерфейс
Сайт, приложение или внешний сервис	API
ИИ-агент	Разрешенные инструменты через MCP или другой агентный интерфейс

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

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

Почему ИИ повышает ценность структурированного контента

Для человека фраза:

«Офис работает с 9:00 до 18:00, телефон...»

понятна.

Для агента удобнее отдельные поля:

время работы;
телефон;
адрес;
идентификатор офиса.

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

Поэтому развитие ИИ дополнительно повышает ценность структурированных контентных моделей.

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

Что меняется в требованиях к CMS

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

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

Раньше было достаточно	Что становится важнее
Контент в виде страниц	Структурированные сущности и связи
API для отдельных интеграций	Стабильный API как часть архитектуры
Права только для сотрудников	Отдельные права для людей, сервисов и агентов
История изменений	Полноценные версии и сравнение изменений
Публикация после редактирования	Workflow с подтверждением действий
Общая учетная запись интеграции	Ограниченные права конкретного сервиса или агента
Логи технических ошибок	Аудит того, кто и что изменил
Админка как главный интерфейс	Админка, API и агентный интерфейс

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

Что бизнесу не нужно делать прямо сейчас

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

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

Для системы с горизонтом эксплуатации в несколько лет полезнее сначала проверить базу:

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

Если эти механизмы есть, агентный слой можно добавить позже.

Если их нет, ИИ не исправит архитектуру.

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

Что в итоге

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

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

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

1f:T2488,

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

Почему поддержка IT-системы — это не просто обслуживание?

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

Снижение рисков. Поддержка систем — это работа с возможными рисками, которые могут появиться даже в тех случаях, когда система кажется работающей. Избыточные и неучтённые зависимости, старые технологии и уязвимости в безопасности — всё это может стать источником крупных проблем, если вовремя не позаботиться о поддержке системы.
Оптимизация работы бизнеса. IT-поддержка не сводится только к устранению сбоев. Это процесс, включающий постоянное обновление, оптимизацию и настройку системы для обеспечения её максимальной эффективности. CIO, инвестируя в поддержку, фактически покупают возможность избежать простоя бизнеса и повышают свою способность быстро адаптироваться к изменениям в бизнес-среде.

«Старая система может работать, но важно понимать, что она может работать хуже и медленнее с каждым днем. Если не обновить её вовремя, можно упустить важные возможности и потерять конкурентоспособность», — Алексей Постригайло, партнер, ИТ-интегратор ЭНСАЙН.

Как поддержка системы помогает в долгосрочной перспективе?

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

Обновления и улучшения системы. Иногда, чтобы система продолжала функционировать на должном уровне, достаточно регулярных обновлений и доработок. Обновления могут касаться безопасности, а также функциональности. Постоянная поддержка позволяет отслеживать изменения в требованиях рынка и своевременно адаптировать систему.
Безопасность. Ключевым аспектом поддержки является обеспечение безопасности. Без регулярных обновлений системы становятся уязвимыми для атак, что чревато потерей данных и репутации. Поддержка включает в себя постоянный мониторинг угроз и применение актуальных мер защиты, что позволяет снизить риски для бизнеса.
Необходимость адаптации к изменениям в бизнес-среде. Важным элементом IT-поддержки является способность системы адаптироваться к изменениям в бизнес-процессах. Система, которая не поддерживает новые требования или может быстро адаптироваться к изменениям на рынке, становится ограничением для бизнеса. В этом контексте CIO покупает не только обслуживание системы, но и её способность обеспечивать рост и развитие компании.

Преимущества постоянной поддержки

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

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

Заключение

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

Система сегодня — это ваш бизнес завтра. Сделайте правильный шаг в сторону стабильности и безопасности.

20:T78c7,

Интеграция вроде бы работает. Сделка из «Битрикс24» ушла в 1С, там появился заказ. Значит, можно закрывать задачу?

Я бы не торопился.

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

Технически связь между системами есть. Для бизнеса ее почти нет.

Мы регулярно видим одну и ту же ошибку: интеграцию «Битрикс24» и 1С начинают с установки модуля. Хотя начинать нужно с другого вопроса: как именно должен измениться процесс после подключения?

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

Что на самом деле нужно интегрировать

«Битрикс24» и 1С обычно отвечают за разные части работы.

В CRM живет клиентский процесс. Обращение, сделка, переписка, звонки, коммерческое предложение, задачи менеджера.

В 1С находится учет. Контрагенты, номенклатура, цены, остатки, счета, поступление денег, резервирование, отгрузка.

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

Например, менеджер формирует сделку в «Битрикс24». Заказ создается в 1С без повторного ввода. Когда деньги поступают, статус оплаты возвращается в CRM. Менеджер видит результат в карточке сделки и не дергает бухгалтерию.

Вот ради этого и стоит делать интеграцию.

Не ради самого факта обмена данными.

Где должна храниться основная информация

Один из первых споров на проекте обычно звучит так:

— А можно, чтобы клиента редактировали и в 1С, и в «Битрикс24»?

Можно. Вопрос в том, что будет дальше.

Менеджер поменяет номер телефона в CRM. Бухгалтер в это же время обновит карточку контрагента в 1С. При очередном обмене одна система перезапишет другую. Иногда победит более свежее изменение. Иногда — то, которое первым попало в очередь. Для пользователей результат будет выглядеть случайным.

Поэтому у каждого типа данных должен быть основной владелец.

Обычно мы предлагаем начинать с такой модели:

Данные	Где ведем
Лиды, сделки, коммуникации	«Битрикс24»
Номенклатура и цены	1С
Остатки и резервы	1С
Учетные документы	1С
Оплаты и отгрузки	1С
Статусы оплаты и отгрузки в сделке	Передаем из 1С в CRM

Это не универсальная таблица. У конкретного бизнеса могут быть другие правила.

Важно не то, какую систему мы выбрали. Важно, что выбор сделан.

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

Двусторонний обмен не означает, что все данные разрешено свободно редактировать с обеих сторон.

Почему одного коннектора недостаточно

Штатный коннектор умеет многое. Он передает клиентов, товары, заказы и документы. Может работать по расписанию или реагировать на изменения. Через него можно получать печатные формы и запускать операции в 1С из роботов «Битрикс24».

Но коннектор не знает, как устроена конкретная компания.

Он не решит:

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

Это уже не настройка модуля. Это проектирование процесса.

Покажу на простом примере.

Менеджер отправляет заказ из CRM в 1С. Документ успешно создается, но в этот момент пропадает соединение. «Битрикс24» не получает ответ и считает операцию неуспешной.

Через минуту запрос уходит повторно.

Что произойдет?

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

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

Когда интеграция действительно окупается

Не каждой компании нужен сложный обмен между CRM и 1С.

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

Интеграция становится оправданной, когда одни и те же действия повторяются постоянно.

Менеджеры заново вводят реквизиты. Бухгалтерия вручную создает заказы. Оплата передается сообщением. Склад отдельно подтверждает наличие. Руководитель собирает общую картину из нескольких отчетов.

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

Но начинать все равно лучше с одного маршрута.

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

Первый рабочий сценарий может быть таким:

Сделка создается в «Битрикс24». После согласования из нее формируется заказ в 1С. Когда поступает оплата, CRM получает новый статус и переводит сделку на следующий этап.

Если этот маршрут работает стабильно, добавляем резервирование, отгрузку и остатки.

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

С чего начать интеграцию «Битрикс24» и 1С

Сначала описать процесс на бумаге

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

Кто создает сделку? В какой момент она считается согласованной? Какие данные обязательны для 1С? Может ли менеджер изменить состав заказа после передачи? Что должно вернуться в CRM после оплаты?

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

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

Интеграция просто вытащит эти противоречия наружу.

Поэтому сначала договариваемся о процессе. Потом автоматизируем.

Затем проверить, с какой 1С придется работать

Фраза «у нас обычная 1С» почти ничего не означает.

Это может быть «Бухгалтерия», «Управление торговлей», ERP, УНФ или конфигурация, которую дорабатывали много лет. Иногда внутри компании несколько баз, а между ними уже настроен собственный обмен.

До оценки работ нужно знать:

точное название конфигурации;
редакцию и версию;
версию платформы;
какие доработки сделаны;
где размещена база;
есть ли возможность опубликовать HTTP-сервисы;
какая версия «Битрикс24» используется.

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

Тогда потребуется доработка.

После этого разобраться с существующими данными

Интеграция редко запускается на пустых системах.

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

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

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

Название — плохой ключ.

ООО «Ромашка», «Ромашка» и «Ромашка, ООО» для человека выглядят одинаково. Для системы это могут быть три разных контрагента.

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

Штатный коннектор или собственная разработка

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

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

Это быстрее, дешевле и проще в дальнейшем сопровождении.

Собственная разработка нужна, когда появляются реальные ограничения:

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

Иногда лучший вариант — смешанный.

Стандартные объекты передаем через коннектор. Специфические сценарии выносим в отдельный сервис.

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

Как запускать первый контур

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

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

И обязательно пройти несколько сценариев.

Создать новый заказ. Изменить существующий. Отправить один и тот же запрос повторно. Отключить 1С и проверить, что произойдет с очередью. Вернуть систему в работу и убедиться, что данные дошли.

Тест «нажал кнопку — заказ появился» ничего не доказывает.

Надежность проявляется в ошибочных ситуациях.

Что произойдет, если у клиента не заполнен ИНН? Если товар архивирован? Если документ уже существует? Если 1С ответила через минуту вместо нескольких секунд? Если соединение пропало после создания заказа?

Именно эти проверки показывают, можно ли отдавать интеграцию в промышленную эксплуатацию.

Почему появляются дубли

Дубли — самая заметная проблема, но причина у них бывает разной.

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

Поэтому одной проверки по названию недостаточно.

У каждого переданного объекта должен сохраняться внешний идентификатор. «Битрикс24» должна знать, какому документу в 1С соответствует конкретная сделка или заказ. 1С — какой карточке CRM соответствует контрагент.

Тогда повторная передача обновляет существующую запись, а не создает новую.

Особенно важно это для заказов, счетов, оплат и отгрузок. Здесь дубли уже влияют не только на удобство, но и на учет.

Что должно происходить при сбое

Сбой будет. Вопрос только в том, когда.

Недоступна 1С. Истек пароль служебной учетной записи. Изменилась структура поля. После обновления перестал проходить один тип документа.

Нормальная интеграция не должна молча терять данные.

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

При этом запрос можно отправить повторно без риска создать еще один документ.

Вот четыре вещи, которые нужно видеть постоянно:

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

Журнал, который никто не открывает, не является мониторингом.

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

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

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

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

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

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

То же касается вебхуков, ключей и доступов к HTTP-сервисам.

Критичный бизнес-процесс не должен зависеть от конкретного человека.

Что меняется при подключении товаров и склада

Складской учет лучше подключать после базового обмена клиентами и заказами.

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

Сначала определяется основной каталог.

Если товары ведутся в 1С, менять их названия и цены в CRM не нужно. «Битрикс24» получает данные из учетной системы и использует их в сделках.

Отдельно согласовывается логика остатков.

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

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

Кто отвечает за интеграцию после запуска

Интеграция не может оставаться «за разработчиками».

Техническая команда отвечает за передачу данных, ошибки, доступы и восстановление.

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

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

Без него любая проблема превращается в переписку:

Это 1С не передала.
Нет, это CRM неправильно приняла.
Менеджер вообще не должен был менять заказ.
А кто ему это сказал?

Технически такая интеграция может быть исправна. Организационно — нет.

Как понять, что проект завершен

Не по факту установки модуля.

И не по первому успешно переданному заказу.

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

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

После обновления 1С или CRM проводится контрольная проверка, а не ожидание первого инцидента.

Если данные по-прежнему периодически сверяют вручную, проект еще не завершен.

Вместо вывода

Штатно соединить «Битрикс24» и 1С обычно несложно.

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

Сам по себе коннектор не устраняет ручную работу. Он только передает информацию.

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

В «Энсайн» такие проекты мы начинаем с разбора процесса. Смотрим, где сотрудники повторно вводят информацию, как сейчас передаются оплаты и заказы, какие данные расходятся.

И только после этого выбираем способ подключения.

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

21:T2cb6,

У корпоративного сайта почти никогда нет красивой точки отказа. Он не умирает в один день. Сначала чуть медленнее открываются страницы. Потом перестает доходить часть заявок. Затем ломается интеграция, но это замечают не сразу. Через какое-то время на сайте уже лежат старые условия, лишние плагины, неактуальные доступы, а любое изменение требует лишней осторожности. Формально сайт работает. По факту бизнес уже начал терять деньги, данные и скорость изменений.

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

Где сайт начинает ломать экономику проекта

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

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

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

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

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

Поддержка полезна там, где она незаметна

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

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

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

Что должно входить в регулярную поддержку

Контроль критичных сценариев. Не абстрактная проверка сайта, а конкретные вещи: уходит ли форма, создается ли лид, работают ли уведомления, записывается ли событие в аналитику, не развалилась ли интеграция с CRM, корректно ли открываются основные страницы.
Обновления. Платформа, модули, серверное окружение должны обновляться по понятному циклу, с резервной копией и проверкой последствий. Обновлять все сразу в аварийном режиме — плохой сценарий. Не обновлять вообще — еще хуже.
Контроль безопасности. Старый сайт удобен для атаки не потому, что он старый, а потому, что его давно не проверяли. Лишние права, устаревшие модули, забытые учетные записи, слабая парольная политика, отсутствие контроля резервного восстановления — все это делает даже обычный корпоративный сайт точкой риска.
Актуальность контента. Если сайт обещает одно, а бизнес давно работает по-другому, у компании появляется разрыв между реальностью и интерфейсом. Поддержка должна закрывать и этот слой тоже. Иначе сайт становится архивом, а не инструментом продаж и сервиса.
Расчистка накопленного долга. Без этого поддержка быстро сводится к латанию. Дубли, старые шаблоны, неиспользуемые блоки, лишние скрипты, устаревшие плагины и костыли надо убирать, а не бесконечно обходить.

Самая дорогая ошибка

Бизнесу часто кажется, что можно сначала сэкономить на сопровождении, а потом вернуться к этому вопросу. На практике получается обратное.

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

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

Как выглядит рабочая модель поддержки

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

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

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

Подведем итоги

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

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

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

22:T80fa,

Разработка собственной CMS для корпоративного проекта может стоить примерно от 2,5 млн рублей до 10 млн рублей и выше. Разброс большой, потому что под одним названием могут скрываться системы совершенно разного масштаба.

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

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

Класс системы	Ориентировочные трудозатраты	Ориентир по бюджету	Ориентировочный срок
Базовая собственная CMS	400-750 часов	2,5-4,5 млн руб.	3-5 месяцев
Корпоративная CMS	900-1500 часов	5,5-9 млн руб.	5-8 месяцев
CMS как ядро цифровой платформы	1700-3000+ часов	от 10 млн руб.	8-12+ месяцев

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

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

Сколько стоит собственная CMS

Базовая собственная CMS — примерно 2,5-4,5 млн рублей

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

В такой проект могут входить:

несколько основных типов контента;
административный интерфейс;
2-4 роли;
публикация и редактирование материалов;
работа с файлами;
поиск и фильтрация;
базовый API;
журнал основных действий.

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

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

Корпоративная CMS — примерно 5,5-9 млн рублей

Здесь CMS уже становится самостоятельной внутренней системой компании.

В ней могут быть:

10-20 и более типов данных;
несколько групп пользователей;
права на уровне подразделений или объектов;
согласования;
история изменений;
несколько интеграций;
API для других сервисов;
перенос существующего контента;
журналирование действий;
отдельные требования к эксплуатации.

На экране такая CMS необязательно выглядит в 2 раза сложнее предыдущей.

Разница находится в количестве правил за интерфейсом.

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

CMS как ядро цифровой платформы — от 10 млн рублей

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

Например:

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

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

Формально систему по-прежнему можно назвать CMS. По масштабу разработки это уже полноценная корпоративная платформа.

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

Из чего складывается стоимость собственной CMS

Основные статьи бюджета можно увидеть еще до детальной оценки.

Блок	За что платит бизнес
Анаитика и архитектура	Требования, модель данных, процессы, устройство системы
Backend	Данные, бизнес-правила и серверная логика
Административный интерфейс	Работа сотрудников внутри CMS
Права, процессы и версии	Роли, согласования, статусы, история изменений
Интеграции и API	Обмен с другими корпоративными системами
Миграция	Перенос старого контента и данных
Тестирование	Проверка функций, ролей, интеграций и связей
Инфраструктура и безопасность	Развертывание, мониторинг, резервирование и доступ
Документация	Передача системы и дальнейшее сопровождение
Управление проектом	Планирование, координация, приемка и релизы

Соотношение этих работ у каждой CMS будет своим.

Аналитика и архитектура

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

На стоимость здесь влияет прежде всего количество связей и правил.

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

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

Backend и данные

Backend — это логика, которую пользователь административной панели почти не видит.

Здесь находятся:

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

Основной фактор стоимости — не количество полей, а количество условий.

Чем больше правил вида «только для этой роли», «после этого статуса», «если объект относится к подразделению», тем больше разработки и тестирования требуется.

Административный интерфейс

Оценивать CMS количеством экранов неудобно.

Гораздо важнее, что пользователь должен уметь делать внутри каждого из них.

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

Поэтому форма из 5 полей иногда требует больше работы, чем простая форма из 20.

Права, процессы и версии

Базовая модель «администратор — редактор» обычно сравнительно предсказуема.

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

Каждое такое правило затрагивает backend, интерфейс и тестирование.

То же относится к согласованиям и хранению истории изменений.

Интеграции и API

Здесь разброс трудозатрат особенно большой.

Одно дело — раз в сутки получить из внешней системы готовый справочник.

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

На стоимость влияют:

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

Поэтому одна сложная интеграция иногда стоит дороже нескольких простых.

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

Миграция данных

Перенос старого контента редко сводится к кнопке «Импортировать».

Допустим, в старой CMS 10 000 материалов.

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

Чем дольше работала старая система, тем больше обычно находится исключений.

Поэтому миграцию лучше оценивать после просмотра реальных данных.

Тестирование

В собственной CMS проверяются не только интерфейсы.

Нужно тестировать права, статусы, согласования, интеграции, API и обработку ошибок.

Чем больше ролей и состояний, тем больше комбинаций.

Именно поэтому усложнение бизнес-логики автоматически увеличивает не только разработку, но и объем тестирования.

Инфраструктура, безопасность и документация

Часть бюджета вообще не видна в CMS.

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

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

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

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

Представим 2 административные панели.

На каждой есть поле «Статус».

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

Во второй изменение того же статуса:

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

Для пользователя это один выпадающий список.

Для команды разработки — несколько связанных механизмов.

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

Пример расчета корпоративной CMS

Возьмем модельный корпоративный проект.

Исходные данные:

10-15 основных типов данных;
5 ролей;
согласование части публикаций;
история изменений;
3 интеграции;
API для сайта и еще одного сервиса;
перенос примерно 10 000 материалов;
стандартный корпоративный контур эксплуатации.

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

Блок	Ориентировочные трудозатраты	Ориентировочная стоимость
Аналитика и архитектура	120 ч	0,7 млн руб.
Backend и данные	280 ч	1,7 млн руб.
Административный интерфейс	220 ч	1,3 млн руб.
Права и процессы	120 ч	0,7 млн руб.
Интеграции и API	180 ч	1,1 млн руб.
Миграция	80 ч	0,5 млн руб.
Тестирование	120 ч	0,7 млн руб.
Инфраструктура и документация	80 ч	0,5 млн руб.
Управление проектом	100 ч	0,6 млн руб.
Итого	около 1300 ч	около 7,8 млн руб.

Это не типовая цена любой корпоративной CMS.

Расчет показывает другое: около 7,8 млн рублей здесь стоит не административная панель, а весь контур системы — аналитика, backend, права, интеграции, перенос данных, тестирование и ввод в эксплуатацию.

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

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

Какие расходы часто не попадают в первую оценку

Подготовка данных к миграции

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

Переходный период

Иногда старая и новая CMS некоторое время работают одновременно. Тогда нужно поддерживать сразу 2 контура и иногда синхронизировать их.

Обучение сотрудников

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

Первые доработки после запуска

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

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

Что должно быть в оценке подрядчика

Строка:

«Разработка собственной CMS — 6 млн рублей»

сама по себе мало что говорит.

Для нормального сравнения предложений стоит смотреть минимум на 3 вещи.

1. Блоки работ

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

2. Трудозатраты

По каждому крупному блоку нужны часы или человеко-дни.

Так видно, где подрядчик ожидает основную сложность.

3. Допущения

Например:

5 ролей;
3 интеграции;
10 000 материалов;
API для 2 систем;
определенный объем документации.

Без допущений 2 подрядчика могут назвать 5 и 9 млн рублей просто потому, что один посчитал миграцию и интеграции полностью, а другой — нет.

Дешевое предложение в таком случае может оказаться не дешевле. В нем просто другой объем работ.

Какие данные нужны для предварительного расчета

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

Достаточно зафиксировать:

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

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

Нужна предварительная оценка собственной CMS?

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

Получить предварительную оценку проекта →

Что в итоге

Для первичного бюджетирования собственной CMS можно ориентироваться на 3 класса проектов:

2,5-4,5 млн рублей — компактная CMS преимущественно для одного корпоративного сайта.

5,5-9 млн рублей — корпоративная CMS с собственными ролями, процессами, интеграциями и миграцией.

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

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

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

Поэтому при сравнении предложений стоит задавать 3 вопроса:

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

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

23:T1b94,

При работе с legacy-системами вопрос скорости выполнения задач становится проблемой. Задачи должны решаться не только быстро, но и с учётом долгосрочных последствий. Поэтому KPI, ориентированные на скорость, могут вызвать больше вреда, чем пользы.

Почему спешка только усугубляет ситуацию

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

Основные проблемы здесь заключаются в следующем:

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

Почему «быстро закрыть задачу» — плохое решение для legacy

«Когда мы гоняемся за скоростью, часто забываем, что в мире IT даже маленькая ошибка может обернуться большими последствиями. Нужно не просто закрыть задачу, а еще сделать это правильно», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Влияние на внутреннюю культуру

Когда основной фокус в работе с legacy-системами ставится на скорость, это часто приводит к поверхностному решению проблем, которые лишь временно устраняются. Сотрудники, ориентированные на быстрый результат, могут выполнить задачу так, чтобы она выглядела завершённой, но на самом деле она может скрывать за собой недостатки или привести к худшим проблемам в будущем. Руководитель по итогу получает горькую конфету в красивой обертке: вроде бы задача выполнена быстро и с видимым результатом, но реальная эффективность работы системы остаётся под вопросом.

Как определить правильные KPI для работы с legacy-системами

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

Другие удачные KPI могут включать:

Время до восстановления после сбоя
Снижение технического долга
Повышение безопасности системы

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

Подведем итоги

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

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

24:T2ebb,

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

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

Зачем он вообще нужен

Большая часть веб-разработки состоит не из уникальных задач, а из повторяемых. Маршруты, формы, роли, работа с базой, API, обработка ошибок, базовая защита, административные интерфейсы, сборка клиентской части. Писать все это с нуля в коммерческом проекте обычно бессмысленно. Это не дает преимущества. Это просто съедает время и увеличивает число ошибок в базовом слое.

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

Где начинается проблема

Ошибка редко в самом фреймворке. Ошибка в том, что под него не смотрят на задачу.

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

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

Что важно бизнесу, а не только команде

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

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

Отдельно про frontend и backend

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

На backend цена ошибки выше. Здесь уже живут данные, права доступа, интеграции, очереди, журналирование и устойчивость операций. Поэтому серверный фреймворк оценивают не по синтаксису, а по тому, как он работает с ORM, миграциями, middleware, валидацией, OpenAPI-документацией, обработкой ошибок и наблюдаемостью. Условно, Django хорош там, где важны зрелая ORM, админка, роли, контентные и корпоративные сценарии. FastAPI — там, где нужен быстрый и прозрачный API контур.

Фреймворк способен как ускорить разработку, так и погубить проект

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

Нужно ли делать свое

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

Как выбирать зрело

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

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

Подведем итоги

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

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

25:T571f,

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

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

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

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

27 контрактов на 168 млн рублей: почему опыт не засчитали

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

Под этот критерий Энсайн представила 27 исполненных контрактов общей стоимостью около 168 млн рублей.

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

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

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

Комиссия оценила его иначе.

Почему функционального сходства оказалось недостаточно

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

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

Такого прямого подтверждения в наших материалах не было.

В результате все 27 контрактов общей стоимостью около 168 млн рублей не принесли баллов по квалификации. Более низкая предложенная цена уже не могла компенсировать этот разрыв. Итоговая оценка Энсайн составила около 30 баллов против примерно 88 баллов у участника, опыт которого комиссия признала соответствующим критериям.

Участник	Снижение цены	Заявленный опыт	Подтвержден- ный опыт	Стоимость контрактов	Оценка квалификации
Победитель	около 5%	29 контрактов	26 контрактов	более 300 млн руб.	100 баллов
Энсайн	около 30%	27 контрактов	не засчитан	около 168 млн руб.	0 баллов

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

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

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

«В тендере недостаточно понимать внутри компании, что проект соответствует требованию. Нужно посмотреть на него глазами комиссии: сможет ли она подтвердить каждый критерий по тем материалам, которые лежат перед ней, без дополнительных объяснений и предположений. После нескольких таких конкурсов мы именно так и проверяем заявки перед подачей», — Алексей Постригайло, управляющий партнер Энсайн.

Когда работающий WebGL-интерфейс не заменил отдельный макет

Во втором конкурсе структура оценки была другой. Цена имела вес 60%, качественные характеристики предложения — 30%, квалификация участника — 10%.

Качественная часть состояла из двух отдельных характеристик.

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

Во второй характеристике нужно было разработать решение для раздела «Мегаполисы мира» и представить сразу три результата:

макет интерфейса;
HTML-верстку;
фронтенд-приложение с интерактивными 3D-элементами на WebGL.

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

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

Комиссия пришла к другому выводу.

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

Почему готовый интерфейс оказался недостаточным

Ошибка стала очевидна уже после конкурса.

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

Для оценки этого оказалось недостаточно.

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

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

Что объединяет два тендера

На первый взгляд ошибки совершенно разные.

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

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

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

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

Именно поэтому сегодня при подготовке конкурсных заявок мы стараемся разделять два вопроса:

Соответствуем ли мы требованию фактически?

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

Это не одно и то же.

Как мы теперь проверяем конкурсные заявки

После этих историй подход Энсайн к участию в ИТ-тендерах стал гораздо формальнее.

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

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

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

Проблема старых контрактов: нужной формулировки в документах может не быть

У формального подхода есть и обратная сторона.

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

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

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

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

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

Что важно учитывать при участии в ИТ-тендерах

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

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

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

Хорошая конкурсная заявка — это заявка, в которой комиссии не нужно ничего додумывать за участника.

26:T58fa,

Почему выбирают энсайн? опыт, открытость и понятный подход

ЭНСАЙН — компания с 20-летним опытом в сфере IT-разработки. Мы накопили обширные знания благодаря сотрудничеству с госструктурами, крупными компаниями и отраслевыми лидерами. Понимаем, насколько непросто передать проект сторонней команде, поэтому организуем свою работу прозрачно, обеспечивая полное понимание всех процессов.

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

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

Как начинается работа с энсайн?

После получения вашего обращения специалист ЭНСАЙН оперативно свяжется с вами, чтобы детально обсудить запрос и понять объем необходимых работ — будь то консультация, аудит или предварительная оценка. Далее мы назначаем удобную встречу с нашими экспертами, где разъясняем все важные моменты простым языком. На следующем этапе предлагается заполнить короткий опросник, позволяющий выявить ключевые нюансы вашей задачи. Затем проводится рабочая встреча, где совместно формулируется техническое задание и определяются конкретные цели и ожидаемые результаты.

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

Особенности выбора подхода в работе?

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

Процесс анализа включает:

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

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

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

Безопасность? наш абсолютный приоритет

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

Аудит инфраструктуры. При наличии действующей IT-системы мы проводим тщательную проверку на наличие уязвимостей и рисков, учитывая предыдущий опыт работы с подрядчиками (при наличии).
Проектирование безопасности. Если речь идет о новом проекте, мы совместно разрабатываем комплекс мер, направленных на защиту данных и предотвращение угроз, исходя из специфики вашего бизнеса.
Соответствие стандартам. Применяемые нами меры безопасности соответствуют российским нормам и отраслевым стандартам (например, ФЗ-152, приказ ФСТЭК №21), гарантируя надежную защиту вашего бизнеса и готовность к любым проверкам контролирующих органов.

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

Честные условия и прозрачный бюджет?

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

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

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

«Кстати ЭНСАЙН может выступить в роли генерального подрядчика, взяв на себя управление проектом и координацию всех участников процесса. При этом, мы освобождаем наших клиентов от организационных хлопот, беря на себя ответственность за взаимодействие со всеми участниками проекта: поставщиками программного обеспечения, интеграторами, производителями оборудования. Наш проектный менеджер становится единым центром коммуникации, координируя деятельность подрядчиков, отслеживая выполнение сроков и оперативно устраняя возникающие проблемы», - рассказывает старший партнер ИТ-компании «Энсайн» Алексей Постригайло.

Теперь перейдем к процессу разработки в ЭНСАЙН. Наши специалисты делают этот процесс простым и понятным для клиента.

Как создать эффективный цифровой продукт?

Компания «ЭНСАЙН» известна своим щепетильным и предметным подходом к созданию и внедрению IT-решений. Благодаря поэтапному процессу разработки и тесному взаимодействию с клиентами удается достичь высоких результатов и удовлетворенности заказчиков.

Весь цикл разработки в «ЭНСАЙН» состоит из шести основных этапов, каждый из которых направлен на повышение эффективности и удобства создаваемого продукта.

Первый этап: аналитика и аудит

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

Второй этап: прототипирование и исследование пользовательского опыта (UX)

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

Третий этап: дизайн и утверждение интерфейса

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

Четвёртый этап: верстка и разработка

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

Пятый этап: интеграция с внешними системами

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

Шестой этап: тестирование и запуск

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

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

«Мы понимаем, что в процессе работы возможны непредвиденные обстоятельства и изменение планов. Поэтому мы открыто обсуждаем любые возникающие трудности и оперативно принимаем решения. Каждое дополнительное требование фиксируется отдельно, оценивается его влияние на сроки и бюджет, а все подробности согласуются до момента внедрения. Если существует несколько вариантов реализации, мы подробно объясняем преимущества и недостатки каждого из них, давая возможность принять взвешенное решение», - руководитель отдела разработки компании «Энсайн» Вадим Зимин.

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

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

Профессиональная поддержка 24/7?

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

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

Какие виды поддержки мы предлагаем:

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

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

Прозрачная работа и долгосрочное партнерство?

Работая с компанией «ЭНСАЙН», вы получаете не просто исполнителя для разработки, а надежного партнера, способного поддерживать ваш бизнес на протяжении длительного периода. Наша команда высоко ценит прозрачность и открытый диалог, что выражается в постоянном информировании вас о состоянии проекта и дальнейших планах.

Мы используем признанные методологии управления проектами — Scrum и Waterfall, что позволяет выбирать оптимальный подход в зависимости от конкретных целей и характера вашего проекта. За каждым этапом стоят высококвалифицированные специалисты, обладающие глубокими компетенциями в своей области. Команда «ЭНСАЙН» — это не просто группа единомышленников, а коллектив профессионалов, готовых решать самые амбициозные задачи.

Нужно разработать высоконагруженный веб-сервис или современное веб-приложение? Просто пройдите экспресс-аудит или запланируйте предварительную встречу для обсуждения деталей сотрудничества. Мы на связи 24/7.

27:T63e0,

Собственная, или самописная, 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 признаков:

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

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

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

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

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

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

28:T2211,

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

Почему выбор подрядчика критичен

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

Что должен учесть CIO выбирая исполнителя для поддержки legacy-систем

На что обратить внимание

Опыт работы с похожими системами. Чем больше у команды конкретных кейсов с вашим стеком, тем выше вероятность, что они смогут быстро и безопасно решать задачи.
Понимание архитектуры и слабых мест legacy. Подрядчик должен видеть скрытые зависимости и потенциальные точки отказа, а не просто выполнять инструкции.
Проактивная поддержка и модернизация. Важно, чтобы команда не ждала, пока возникнут ошибки, а выявляла и устраняла проблемы заранее.
Прозрачные процессы и отчётность. Регулярные отчёты, контроль задач и возможность проверить качество работы — обязательные условия.

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

Последствия неправильного выбора

Ошибки или задержки в сопровождении legacy проявляются сразу в нескольких областях. Система становится сложнее для управления, исправление ошибок занимает больше времени, чем планировалось. Устаревшие компоненты не получают обновлений и становятся уязвимыми к киберугрозам. Любая ошибка подрядчика может спровоцировать цепочку проблем, приводящих к срывам сроков, замедлению процессов и перерасходу ресурсов. Чрезмерная зависимость от подрядчика создаёт дополнительный риск: при его уходе компания остаётся без специалистов, способных поддерживать критические процессы, и восстановление стабильной работы требует серьёзных инвестиций и времени.

«Каждая задержка или неправильное решение при сопровождении legacy увеличивает долг компании: время, ресурсы, риск простоя. Выбор подрядчика для legacy — это не только цены и отчеты, а способность управлять рисками, которые накапливались годами» — Алексей Постригайло, партнер, ИТ-интегратор ЭНСАЙН

Как проверить подрядчика

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

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

Заключение

Выбор подрядчика для поддержки legacy-систем — это инвестиция в стабильность и управляемость бизнеса. Грамотная команда сокращает риски, сохраняет контроль над системой и минимизирует расходы на исправление проблем. CIO, который проверяет компетенции, процессы и подход к сопровождению, получает уверенность, что система будет работать безопасно, эффективно и позволит бизнесу развиваться без технических тормозов.

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

29:T63e0,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

Будет.

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

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

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

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

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

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

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

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

2a:T55f3,

Во время аудита одной из систем заказчика мы обнаружили рабочую базу в тестовой среде.

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

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

Но рядом существовала еще одна база.

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

В этом и была проблема.

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

Почему рабочие данные вообще попадают в тестовую среду

Разработчикам проще проверять систему на настоящей базе.

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

Поэтому возникает простое решение: сделать копию рабочей базы и развернуть ее на тестовом сервере.

Само по себе тестирование на копии еще не означает, что кто-то намеренно нарушает правила. Чаще это обычный рабочий процесс, который никто отдельно не пересматривал с точки зрения защиты ПДн.

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

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

Если эти вопросы заранее не определить, временное решение быстро становится постоянным.

В чем был реальный риск

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

Главный риск в другом: эта копия фактически выпала из общего контроля.

Основную систему компания знала и защищала. Было понятно, кто имеет доступ, как настроена авторизация, где лежат резервные копии. С тестовым стендом такой ясности уже не было.

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

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

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

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

Почему проблему не нашли раньше

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

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

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

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

Каждое изменение выглядит локальным. Но вместе они меняют путь данных.

В какой-то момент документация продолжает описывать одну систему, а на практике ПДн уже находятся в нескольких сервисах, резервных копиях, выгрузках и тестовых средах.

Поэтому аудит нельзя сводить к вопросу: «Все ли документы подготовлены?»

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

Отдельно требования Роскомнадзора к обработке и хранению ПДн, документам и подготовке к контрольным мероприятиям мы разобрали в статье «Как подготовиться к проверке Роскомнадзора по персональным данным».

Что проверяется во время аудита ПДн

Во время аудита мы смотрим не только документы и не только основную базу.

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

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

Дальше обычно начинают всплывать детали.

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

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

Поэтому аудит должен отвечать на практические вопросы:

Кто имеет доступ?
Где лежат копии?
Можно ли выгрузить базу целиком?
Какие данные видит подрядчик?
Что происходит с информацией после завершения задачи?
Можно ли подтвердить удаление?

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

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

Что делать с рабочими данными на тестовом стенде

Лучший вариант: не переносить реальные ПДн в тестовую среду.

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

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

На словах все просто. На практике обезличивание тоже нужно проверять.

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

Поэтому для тестовых копий нужен отдельный порядок:

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

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

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

Тестовая база редко бывает единственной незаметной копией

После обнаружения тестовой базы важно не останавливаться на одном сервере.

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

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

Похожая ситуация возникает и без участия разработчиков.

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

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

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

Когда аудит уже нельзя откладывать

Обычно это видно без сложной диагностики.

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

ИТ-служба знает про серверы. Отдел продаж про CRM. Маркетинг про рассылки. Разработчики про тестовые стенды. Подрядчики про свои копии и доступы.

Но общей картины нет.

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

Появилась новая CRM. Подключили облачный сервис. Сменили подрядчика. Начали использовать ИИ. Перенесли систему. Запустили мобильное приложение.

Каждое такое изменение меняет путь данных.

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

В такой ситуации вопрос уже не в том, есть ли риск.

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

Что должно остаться после аудита

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

Компания должна получить рабочую картину:

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

Отдельно нужен план действий.

Часть нарушений можно устранить сразу: отключить старую учетную запись, закрыть лишний доступ, удалить ненужную копию.

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

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

Так аудит связывает техническую инфраструктуру, работу сотрудников и требования к обработке ПДн в одну систему.

Основной риск находится за пределами основной базы

В обнаруженном нами случае никто не пытался обойти защиту.

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

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

Именно для этого нужен аудит ПДн.

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

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

Она начинается с ответа на более сложный вопрос: где еще находятся эти данные?

Проведем аудит обработки и защиты ПДн

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

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

2b:T4850,

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

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

До 30 млн рублей на российские цифровые решения

54 проекта уже получили поддержку

ИТ-рынок вырос. Но картина не такая однозначная

Государственные системы собирают в единый контур

Минцифры хотят сделать главным ведомством по ИИ

Зарегистрированных киберпреступлений стало меньше

Что видно по этим новостям

До 30 млн рублей на российские цифровые решения

Фонд содействия инновациям вместе с Минцифры открыл прием заявок на конкурс «Развитие-ЦТ».

Максимальный размер гранта — 30 млн рублей. Деньги можно направить на НИОКР, доработку продукта и подготовку решения к внедрению. При этом компания должна вложить в проект собственные средства — не менее 20% суммы гранта.

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

Заявки принимаются до 24 августа 2026 года.

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

54 проекта уже получили поддержку

Почти одновременно подвели итоги конкурсов «Старт-ИИ» и «Старт-ЦТ».

По данным Минцифры, финансирование получат 54 проекта из 25 регионов. Общая сумма поддержки превысит 260 млн рублей.

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

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

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

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

ИТ-рынок вырос. Но картина не такая однозначная

По итогам первого квартала 2026 года российские ИТ-компании реализовали собственных продуктов и услуг более чем на 1,2 трлн рублей.

Рост к прошлому году составил 37,6%. Примерно 68% этого объема приходится на разработчиков программного обеспечения. Их выручка приблизилась к 860 млрд рублей.

В отрасли работает около 1,2 млн человек. За год сотрудников стало больше примерно на 102 тыс. Средняя зарплата приблизилась к 235 тыс. рублей.

Данные приводят CNews и Хабр.

Цифры хорошие. Но из них не следует, что ИТ-компаниям сейчас легко.

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

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

Государственные системы собирают в единый контур

Правительство обновило стратегию цифровой трансформации государственного управления до 2030 года.

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

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

К единому пространству электронного документооборота собираются подключить около 35 тыс. органов и организаций.

Подробный разбор опубликован на ComNews. Сам документ доступен в правовой базе.

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

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

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

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

Минцифры хотят сделать главным ведомством по ИИ

Еще одна июльская новость — проект постановления о новых полномочиях Минцифры в сфере искусственного интеллекта.

Ведомство может стать основным координатором государственной политики по ИИ. В его зону ответственности войдут нормативные требования, меры поддержки, доступ к государственным данным и развитие ИИ-сервисов на платформе «ГосТех».

О проекте писали Хабр и TelecomDaily.

Пока это именно проект. Готовых правил для бизнеса еще нет.

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

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

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

Зарегистрированных киберпреступлений стало меньше

Минцифры сообщило о снижении количества зарегистрированных киберпреступлений.

В первом полугодии 2025 года их было 371,4 тыс. За тот же период 2026 года — 252,9 тыс. Разница составляет почти 120 тыс. случаев.

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

Подробности опубликованы на сайте Минцифры.

Также обсуждается «красная кнопка» на Госуслугах для сообщений о мошенничестве и самозапрет на международные звонки.

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

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

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

Что видно по этим новостям

Минцифры сейчас работает сразу в двух направлениях.

С одной стороны, государство финансирует новые разработки и ИИ-проекты. С другой — постепенно повышает требования к данным, безопасности и интеграции систем.

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

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

2c:T3323,

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

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

«Я предложил Rust не потому, что хотелось попробовать что-⁠то экзотическое. Для меня это один из языков будущего именно из-⁠за его жесткости: если код нарушает правила, которые компилятор способен проверить, он просто не собирается. Ошибка не уходит дальше по цепочке — в тестирование, поддержку или к заказчику», — Вадим Зимин, техлид Энсайн.

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

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

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

Где Rust стал не идеей, а проектным решением

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

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

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

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

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

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

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

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

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

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

Что мы из этого вынесли

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

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

В коммерческом проекте каждый стек должен отвечать на простой вопрос: какую конкретную проблему он снимает?

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

Но у Rust есть и цена. Команде нужно понимать модель владения, библиотеки, сборку, ревью, работу с unsafe, поддержку и сроки. Если этих ответов нет, язык сам становится риском.

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

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

Почему мы изучаем Rust заранее

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

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

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

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

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

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

2d:T3945,

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

Customer Journey Map нужна как раз для таких маршрутов. Это карта взаимодействия клиента с компанией по шагам: где он впервые столкнулся с продуктом, что сделал дальше, через какие каналы прошел, в какой момент начал сомневаться и что именно не дало ему дойти до результата.

Трафик, конверсия и отчеты из CRM всего не показывают. Они фиксируют факт: человек ушел, не купил, не вернулся. А вот CJM помогает понять причину.

Что именно показывает CJM

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

Для чего нужен Customer Journey Map

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

Где от нее есть польза

1. Маркетинг приводит трафик, но заявок мало

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

2. Заявки есть, но до сделки доходит мало

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

3. Поддержка отвечает на одни и те же вопросы

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

4. Пользователь заходит в сервис, но не доходит до целевого действия

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

5. Каналы работают по отдельности, а вместе дают слабый результат

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

Почему карту часто делают, но редко используют

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

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

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

«Когда путь клиента не собран в одну картину, компания почти всегда лечит не ту проблему», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Как строить CJM

1. Начните с конкретного вопроса

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

2. Выберите один сегмент и один сценарий

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

3. Опирайтесь на реальные данные

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

4. Собирайте карту вместе с разными командами

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

5. На каждом этапе фиксируйте не только действие, но и причину

Полезно смотреть на каждый шаг сразу с нескольких сторон:

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

6. Связывайте карту с метриками

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

7. Завершайте работу списком изменений

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

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

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

Подведем итоги

Customer Journey Map показывает, на каком шаге человек перестает двигаться дальше и что именно в этот момент не сработало.

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

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

2e:T2854,

Сценарий почти всегда один и тот же.

Нужно поправить отчет. Добавить поле. Чуть изменить логику расчета. Задача выглядит небольшой и понятной. Ее так и называют. Простая правка.

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

Если это повторяется, дело не в совпадении. И не в конкретной команде.

Это свойство системы.

Откуда берется ожидание простоты

Ожидание простоты возникает не из наивности. Оно возникает из прошлого опыта.

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

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

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

Что происходит внутри legacy при любой правке

Legacy не появляется внезапно. Оно формируется постепенно.

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

Со временем появляются неявные зависимости. Один отчет тянет за собой несколько расчетов. Поле, добавленное когда-то временно, становится опорным. Ручные операции встраиваются в процесс и перестают восприниматься как часть системы.

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

Снаружи это выглядит как замедление. Изнутри — как работа в условиях повышенного риска.

Почему опыт и усиление команды не ускоряют работу

В этот момент часто ожидают, что опыт или усиление команды решат проблему.

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

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

Это не вопрос квалификации. Это следствие состояния системы.

«Когда мы начинаем работать с legacy-системой, важно понимать, что это не просто устранение ошибок, а управление рисками, которые накапливаются годами. Важно вовремя вмешаться, прежде чем система начнёт ломаться под нагрузкой. Каждый пропущенный этап в модернизации увеличивает вероятность катастрофы. Чем раньше начнём, тем меньше рисков для бизнеса в будущем», — Вадим Зимин, руководитель отдела разработки, Энсайн.

Потеря локальности как ключевая проблема

Главная особенность legacy — утрата локальности изменений.

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

Любое изменение проходит через фильтр осторожности. Это меняет экономику доработок.

Задачи, которые раньше занимали дни, начинают занимать недели. Не из-за сложности кода, а из-за стоимости ошибки. И чем дольше система живет в таком состоянии, тем меньше в ней остается быстрых решений.

Почему смена подрядчика редко меняет картину

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

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

Через несколько месяцев разговор снова возвращается к срокам, рискам и осторожным правкам.

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

Что важно зафиксировать до следующей правки

Если простые задачи регулярно превращаются в долгие и рискованные, это сигнал.

Система живет в режиме legacy. Ожидание простоты в этом режиме становится управленческой ошибкой.

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

Это не сделает работу быстрой. Зато перестанет создавать иллюзию, что она может быть простой.

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

Вместо вывода

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

В крупных компаниях это не самый простой путь.

Зато самый честный.

2f:T2488,

Почему поддержка IT-системы — это не просто обслуживание?

Снижение рисков. Поддержка систем — это работа с возможными рисками, которые могут появиться даже в тех случаях, когда система кажется работающей. Избыточные и неучтённые зависимости, старые технологии и уязвимости в безопасности — всё это может стать источником крупных проблем, если вовремя не позаботиться о поддержке системы.
Оптимизация работы бизнеса. IT-поддержка не сводится только к устранению сбоев. Это процесс, включающий постоянное обновление, оптимизацию и настройку системы для обеспечения её максимальной эффективности. CIO, инвестируя в поддержку, фактически покупают возможность избежать простоя бизнеса и повышают свою способность быстро адаптироваться к изменениям в бизнес-среде.

«Старая система может работать, но важно понимать, что она может работать хуже и медленнее с каждым днем. Если не обновить её вовремя, можно упустить важные возможности и потерять конкурентоспособность», — Алексей Постригайло, партнер, ИТ-интегратор ЭНСАЙН.

Как поддержка системы помогает в долгосрочной перспективе?

Обновления и улучшения системы. Иногда, чтобы система продолжала функционировать на должном уровне, достаточно регулярных обновлений и доработок. Обновления могут касаться безопасности, а также функциональности. Постоянная поддержка позволяет отслеживать изменения в требованиях рынка и своевременно адаптировать систему.
Безопасность. Ключевым аспектом поддержки является обеспечение безопасности. Без регулярных обновлений системы становятся уязвимыми для атак, что чревато потерей данных и репутации. Поддержка включает в себя постоянный мониторинг угроз и применение актуальных мер защиты, что позволяет снизить риски для бизнеса.
Необходимость адаптации к изменениям в бизнес-среде. Важным элементом IT-поддержки является способность системы адаптироваться к изменениям в бизнес-процессах. Система, которая не поддерживает новые требования или может быстро адаптироваться к изменениям на рынке, становится ограничением для бизнеса. В этом контексте CIO покупает не только обслуживание системы, но и её способность обеспечивать рост и развитие компании.

Преимущества постоянной поддержки

Заключение

Система сегодня — это ваш бизнес завтра. Сделайте правильный шаг в сторону стабильности и безопасности.

30:T5637,

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

Собственная CMS требует большего бюджета и времени. Зато система проектируется под конкретные данные и процессы компании.

Поэтому сравнивать эти варианты только по стоимости первого релиза неправильно. Для корпоративного проекта важнее понять, во сколько каждый вариант обойдется за 3–⁠5 лет эксплуатации и развития.

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

Готовая CMS экономит на том, что уже создано

Основное преимущество готовой платформы не обязательно в стоимости лицензии.

Компания получает набор функций, которые были разработаны до начала ее проекта:

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

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

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

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

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

Где появляется скрытая стоимость готовой CMS

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

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

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

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

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

Именно эту часть расходов легко не увидеть при первоначальном выборе платформы.

За что бизнес платит при собственной разработке

У собственной CMS структура затрат другая.

В начале приходится самостоятельно создавать или интегрировать то, что готовая система предоставляет сразу.

Например:

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

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

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

Поэтому аргумент «сделаем свою и перестанем зависеть от коробки» мало что говорит об экономике проекта.

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

Сравниваем стоимость владения

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

Картина шире.

Статья расходов	Готовая CMS	Собственная CMS
Первоначальная разработка	Обычно ниже	Обычно выше
Лицензия	Может быть	Обычно отсутствует
Базовая функциональность	Уже есть	Нужно создать или интегрировать
Нестандартная логика	Доработка платформы	Реализуется внутри собственной архитектуры
Обновления	Производитель выпускает обновления, проект нужно проверять	Организует команда проекта
Совместимость доработок	Может усложняться по мере развития	Контролируется внутри своей системы
Поддержка	CMS и собственные модули	Вся система
Специалисты	Обычно проще найти для популярных CMS	Нужно сохранять знание собственной архитектуры
Изменение архитектуры	Ограничено устройством платформы	Контролирует команда проекта
Стоимость через 3–⁠5 лет	Сильно зависит от объема доработок	Зависит от темпа развития собственной CMS

На старте готовая система чаще выглядит привлекательнее.

Дальше все зависит от того, как развивается проект.

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

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

Когда доработки начинают съедать экономию

Представим 2 задачи.

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

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

Формально оба проекта работают на готовой CMS.

Экономика у них разная.

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

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

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

Когда меняется экономика сравнения

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

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

На одном из наших проектов такая граница проявилась достаточно явно.

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

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

Где чаще ошибаются в расчетах

Считают только стоимость лицензии

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

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

Лицензия — только одна строка расходов.

Не учитывают обновления после доработок

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

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

Эти часы тоже являются частью стоимости владения.

Считают собственную CMS один раз

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

Через год появятся новые функции. Обновятся зависимости. Изменятся требования к безопасности. Потребуется поддержка новых сотрудников и процессов.

Поэтому сравнивать 5 лет эксплуатации готовой CMS со стоимостью только первого релиза собственной системы некорректно.

Как считать стоимость на 3–⁠5 лет

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

Для готовой CMS стоит учитывать:

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

Для собственной CMS:

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

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

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

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

Такое сравнение ничего не покажет.

Что в итоге

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

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

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

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

«Что дешевле — лицензия или собственная разработка?»

А так:

Как изменится стоимость проекта за 3–⁠5 лет и сколько будет стоить каждое следующее изменение?

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

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

Их разберем в следующей статье серии — «Когда требуется создание собственной CMS».

31:T3e0b,

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

Угроза редко приходит с одной стороны

Риски удобно делить на внешние и внутренние. Но на практике этого мало.

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

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

Внешние источники угроз: не только кража данных

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

Обычно бьют по 4 зонам.

Публичные сервисы. Сайты, API, личные кабинеты, мобильные backend-контуры, интеграционные шлюзы. Все, что доступно извне, становится мишенью для перебора, сканирования и эксплуатации старых уязвимостей.
Рабочая среда сотрудников. Почта, браузеры, мессенджеры, удаленный доступ, ноутбуки, телефоны. Здесь проще сыграть не на технологии, а на привычке и невнимательности.
Инфраструктура. Серверы, сетевое оборудование, облачные ресурсы, хранилища, резервные каналы, внешние сервисы аутентификации. Слабое место здесь открывает путь дальше по контуру.
Физический слой. Кража устройства, доступ в офис, подмена оборудования, подключение к внутренней сети без контроля. Это менее заметный, но вполне рабочий сценарий.

Внутренние источники угроз опаснее, чем кажутся

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

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

Природа и источники информационных угроз

У внутренних угроз есть 3 типовых сценария.

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

«Самый дорогой инцидент обычно начинается не с хитрой атаки, а с простого вопроса: у кого был доступ, зачем он был нужен и почему никто давно это не пересматривал,» — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Для бизнеса важнее не тип атаки, а то, что именно он теряет

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

Потеря доступности

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

Потеря целостности

Данные доступны, но им уже нельзя доверять. Записи подменены. Статусы изменены. Логика обработки нарушена. Особенно опасно это в интеграционном контуре, где система не падает, а начинает «тихо врать».

Потеря конфиденциальности

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

Активные и пассивные угрозы: заметные и тихие

Часть атак заметна сразу: что-то перестало работать, файлы зашифрованы, сервер перегружен. Это активный сценарий.

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

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

Самые частые мишени — конкретные активы

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

Обычно в зоне риска находятся:

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

Каждый такой актив нужно смотреть через простой вопрос: что будет, если этот элемент станет недоступен, скомпрометирован или изменен?

Где бизнес чаще всего ошибается при оценке угроз

Есть 5 типовых ошибок.

1. Считать главным риском только внешний взлом

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

2. Смотреть на безопасность отдельно от архитектуры

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

3. Плохо знать свои активы

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

4. Не пересматривать накопленные доступы

Люди меняют роли, подрядчики уходят, проекты закрываются, а права остаются. Через год система обрастает хвостом доступов, который никто по-настоящему не контролирует.

5. Не считать стоимость простоя и искажения данных

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

Подведем итоги

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

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

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

32:T629d,

Что изменилось в CMS к 2026 году

ИИ-агент становится новым пользователем CMS

Обычная автоматизация выполняет заранее определенную последовательность.

Например:

после публикации отправить уведомление;

ночью обновить справочник;

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

Агентный сценарий устроен иначе.

Можно поставить задачу:

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

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

Для этого административная панель ему не нужна.

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

Что уже происходит у Contentful, Drupal и WordPress

Это направление уже видно в развитии крупных CMS и контентных платформ.

Платформа	Что происходит	Статус
Contentful	MCP предоставляет агентам инструменты для работы с контентом и операциями платформы	Доступно
WordPress	Abilities API описывает функции сайта, а MCP Adapter предоставляет их ИИ-агентам как инструменты	Доступно
Drupal	Развиваются агентные сценарии, governance, версии и human-in-the-loop механизмы	Развивается по AI Roadmap 2026

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

Что MCP меняет в работе с CMS

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

Упрощенный сценарий может выглядеть так:

агент получает задачу;

видит, что ему доступны поиск материалов, чтение карточки и создание черновой версии;

находит нужные записи;

выполняет разрешенные изменения;

возвращает результат.

Ключевое слово здесь — разрешенные.

Чем больше может агент, тем важнее контроль

Генерация одного текста и массовое изменение 10 000 записей имеют совершенно разную цену ошибки.

Поэтому при подключении ИИ права, версии и журналирование становятся еще важнее.

Для корпоративной CMS необходимо понимать:

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

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

Подготовить черновик — один уровень риска.

Изменить опубликованную цену — другой.

Удалить данные — третий.

CMS должна уметь различать эти сценарии.

Админка перестает быть единственным интерфейсом CMS

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

Меняется способ взаимодействия с системой.

Обычный сценарий:

открыть раздел → найти карточку → изменить поле → сохранить.

Агентный сценарий:

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

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

Кто работает с CMS	Как взаимодействует
Сотрудник	Административный интерфейс
Сайт, приложение или внешний сервис	API
ИИ-агент	Разрешенные инструменты через MCP или другой агентный интерфейс

Почему ИИ повышает ценность структурированного контента

Для человека фраза:

«Офис работает с 9:00 до 18:00, телефон...»

понятна.

Для агента удобнее отдельные поля:

время работы;
телефон;
адрес;
идентификатор офиса.

Поэтому развитие ИИ дополнительно повышает ценность структурированных контентных моделей.

Что меняется в требованиях к CMS

Раньше было достаточно	Что становится важнее
Контент в виде страниц	Структурированные сущности и связи
API для отдельных интеграций	Стабильный API как часть архитектуры
Права только для сотрудников	Отдельные права для людей, сервисов и агентов
История изменений	Полноценные версии и сравнение изменений
Публикация после редактирования	Workflow с подтверждением действий
Общая учетная запись интеграции	Ограниченные права конкретного сервиса или агента
Логи технических ошибок	Аудит того, кто и что изменил
Админка как главный интерфейс	Админка, API и агентный интерфейс

Что бизнесу не нужно делать прямо сейчас

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

Для системы с горизонтом эксплуатации в несколько лет полезнее сначала проверить базу:

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

Если эти механизмы есть, агентный слой можно добавить позже.

Если их нет, ИИ не исправит архитектуру.

Что в итоге

33:T2211,

Почему выбор подрядчика критичен

Что должен учесть CIO выбирая исполнителя для поддержки legacy-систем

На что обратить внимание

Опыт работы с похожими системами. Чем больше у команды конкретных кейсов с вашим стеком, тем выше вероятность, что они смогут быстро и безопасно решать задачи.
Понимание архитектуры и слабых мест legacy. Подрядчик должен видеть скрытые зависимости и потенциальные точки отказа, а не просто выполнять инструкции.
Проактивная поддержка и модернизация. Важно, чтобы команда не ждала, пока возникнут ошибки, а выявляла и устраняла проблемы заранее.
Прозрачные процессы и отчётность. Регулярные отчёты, контроль задач и возможность проверить качество работы — обязательные условия.

Последствия неправильного выбора

Как проверить подрядчика

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

Заключение

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

34:T7df0,

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

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

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

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

Для выбора конкретного решения мы бы оценивали корпоративный проект по 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 или собственная CMS: что выбрать бизнесу».

35:T63e0,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

Будет.

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

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

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

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

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

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

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

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

36:T80fa,

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

Класс системы	Ориентировочные трудозатраты	Ориентир по бюджету	Ориентировочный срок
Базовая собственная CMS	400-750 часов	2,5-4,5 млн руб.	3-5 месяцев
Корпоративная CMS	900-1500 часов	5,5-9 млн руб.	5-8 месяцев
CMS как ядро цифровой платформы	1700-3000+ часов	от 10 млн руб.	8-12+ месяцев

Сколько стоит собственная CMS

Базовая собственная CMS — примерно 2,5-4,5 млн рублей

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

В такой проект могут входить:

несколько основных типов контента;
административный интерфейс;
2-4 роли;
публикация и редактирование материалов;
работа с файлами;
поиск и фильтрация;
базовый API;
журнал основных действий.

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

Корпоративная CMS — примерно 5,5-9 млн рублей

Здесь CMS уже становится самостоятельной внутренней системой компании.

В ней могут быть:

10-20 и более типов данных;
несколько групп пользователей;
права на уровне подразделений или объектов;
согласования;
история изменений;
несколько интеграций;
API для других сервисов;
перенос существующего контента;
журналирование действий;
отдельные требования к эксплуатации.

На экране такая CMS необязательно выглядит в 2 раза сложнее предыдущей.

Разница находится в количестве правил за интерфейсом.

CMS как ядро цифровой платформы — от 10 млн рублей

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

Например:

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

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

Из чего складывается стоимость собственной CMS

Основные статьи бюджета можно увидеть еще до детальной оценки.

Блок	За что платит бизнес
Анаитика и архитектура	Требования, модель данных, процессы, устройство системы
Backend	Данные, бизнес-правила и серверная логика
Административный интерфейс	Работа сотрудников внутри CMS
Права, процессы и версии	Роли, согласования, статусы, история изменений
Интеграции и API	Обмен с другими корпоративными системами
Миграция	Перенос старого контента и данных
Тестирование	Проверка функций, ролей, интеграций и связей
Инфраструктура и безопасность	Развертывание, мониторинг, резервирование и доступ
Документация	Передача системы и дальнейшее сопровождение
Управление проектом	Планирование, координация, приемка и релизы

Соотношение этих работ у каждой CMS будет своим.

Аналитика и архитектура

На стоимость здесь влияет прежде всего количество связей и правил.

Backend и данные

Backend — это логика, которую пользователь административной панели почти не видит.

Здесь находятся:

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

Основной фактор стоимости — не количество полей, а количество условий.

Административный интерфейс

Оценивать CMS количеством экранов неудобно.

Гораздо важнее, что пользователь должен уметь делать внутри каждого из них.

Поэтому форма из 5 полей иногда требует больше работы, чем простая форма из 20.

Права, процессы и версии

Базовая модель «администратор — редактор» обычно сравнительно предсказуема.

Каждое такое правило затрагивает backend, интерфейс и тестирование.

То же относится к согласованиям и хранению истории изменений.

Интеграции и API

Здесь разброс трудозатрат особенно большой.

Одно дело — раз в сутки получить из внешней системы готовый справочник.

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

На стоимость влияют:

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

Поэтому одна сложная интеграция иногда стоит дороже нескольких простых.

Миграция данных

Перенос старого контента редко сводится к кнопке «Импортировать».

Допустим, в старой CMS 10 000 материалов.

Чем дольше работала старая система, тем больше обычно находится исключений.

Поэтому миграцию лучше оценивать после просмотра реальных данных.

Тестирование

В собственной CMS проверяются не только интерфейсы.

Нужно тестировать права, статусы, согласования, интеграции, API и обработку ошибок.

Чем больше ролей и состояний, тем больше комбинаций.

Инфраструктура, безопасность и документация

Часть бюджета вообще не видна в CMS.

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

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

Представим 2 административные панели.

На каждой есть поле «Статус».

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

Во второй изменение того же статуса:

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

Для пользователя это один выпадающий список.

Для команды разработки — несколько связанных механизмов.

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

Пример расчета корпоративной CMS

Возьмем модельный корпоративный проект.

Исходные данные:

10-15 основных типов данных;
5 ролей;
согласование части публикаций;
история изменений;
3 интеграции;
API для сайта и еще одного сервиса;
перенос примерно 10 000 материалов;
стандартный корпоративный контур эксплуатации.

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

Блок	Ориентировочные трудозатраты	Ориентировочная стоимость
Аналитика и архитектура	120 ч	0,7 млн руб.
Backend и данные	280 ч	1,7 млн руб.
Административный интерфейс	220 ч	1,3 млн руб.
Права и процессы	120 ч	0,7 млн руб.
Интеграции и API	180 ч	1,1 млн руб.
Миграция	80 ч	0,5 млн руб.
Тестирование	120 ч	0,7 млн руб.
Инфраструктура и документация	80 ч	0,5 млн руб.
Управление проектом	100 ч	0,6 млн руб.
Итого	около 1300 ч	около 7,8 млн руб.

Это не типовая цена любой корпоративной CMS.

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

Какие расходы часто не попадают в первую оценку

Подготовка данных к миграции

Переходный период

Обучение сотрудников

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

Первые доработки после запуска

Что должно быть в оценке подрядчика

Строка:

«Разработка собственной CMS — 6 млн рублей»

сама по себе мало что говорит.

Для нормального сравнения предложений стоит смотреть минимум на 3 вещи.

1. Блоки работ

2. Трудозатраты

По каждому крупному блоку нужны часы или человеко-дни.

Так видно, где подрядчик ожидает основную сложность.

3. Допущения

Например:

5 ролей;
3 интеграции;
10 000 материалов;
API для 2 систем;
определенный объем документации.

Дешевое предложение в таком случае может оказаться не дешевле. В нем просто другой объем работ.

Какие данные нужны для предварительного расчета

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

Достаточно зафиксировать:

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

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

Нужна предварительная оценка собственной CMS?

Получить предварительную оценку проекта →

Что в итоге

Для первичного бюджетирования собственной CMS можно ориентироваться на 3 класса проектов:

2,5-4,5 млн рублей — компактная CMS преимущественно для одного корпоративного сайта.

5,5-9 млн рублей — корпоративная CMS с собственными ролями, процессами, интеграциями и миграцией.

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

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

Поэтому при сравнении предложений стоит задавать 3 вопроса:

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

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

37:T6757,

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

Здесь легко запутаться. В один ряд часто ставят WordPress, «1С-Битрикс», headless CMS и собственную разработку. Но это не совсем корректное сравнение.

Готовая или собственная CMS — это вопрос о том, берем мы уже существующий продукт или создаем систему под конкретный проект. Классическая или headless — вопрос о том, как CMS связана с самим сайтом.

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

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

Почему готовая, собственная и headless — не три одинаковых типа CMS

Представим два корпоративных сайта.

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

Это различие по происхождению системы.

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

Это уже различие по архитектуре.

Получается, что готовая CMS вполне может быть headless. Собственная тоже.

Именно поэтому дальше разделим эти вопросы.

Готовая CMS

Готовая CMS — это программный продукт, который существовал еще до начала конкретного проекта.

Например:

WordPress;
Drupal;
«1С-Битрикс: Управление сайтом».

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

Разработчики не создают все это заново. Они настраивают CMS под проект, реализуют дизайн, типы контента, дополнительные функции и интеграции.

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

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

Где начинаются ограничения готовой CMS

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

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

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

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

Каждую такую задачу можно решить.

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

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

Собственная CMS

У собственной CMS другая отправная точка.

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

Это не означает разработку абсолютно всего с нуля.

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

Допустим, компания управляет большой сетью объектов.

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

Готовую CMS тоже можно под это настроить.

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

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

У собственной CMS есть цена

Собственная разработка дает больше контроля, но этот контроль приходится оплачивать.

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

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

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

Поэтому писать свою CMS только ради «гибкости» — слабая причина.

Своя система оправдана тогда, когда эта свобода действительно нужна проекту и используется постоянно.

Готовая или собственная CMS: в чем разница

Критерий	Готовая CMS	Собственная CMS
Базовые функции	Уже есть	Нужно разработать или интегрировать
Скорость старта	Обычно выше	Обычно ниже
Затраты на старте	Обычно ниже	Обычно выше
Нестандартные процессы	Реализуются доработками	Можно заложить сразу
Модель данных	Зависит от устройства платформы	Проектируется под систему
Обновления ядра	Выпускает разработчик CMS	Организует команда проекта
Основной риск	Упереться в ограничения платформы	Получить дорогую систему, которую нужно постоянно поддерживать

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

Просто расходы и ограничения находятся в разных местах.

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

Классическая CMS

Теперь посмотрим на другой признак.

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

Редактор создает материал в административной части, а сама платформа знает, как его вывести на странице сайта.

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

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

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

Headless CMS

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

Сайт получает данные через API и отображает их самостоятельно.

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

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

Редактор при этом меняет услугу в одном месте.

Это и есть главное отличие headless: контент существует независимо от конкретной страницы или интерфейса.

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

Зачем отделять CMS от сайта

Такой подход особенно полезен, когда один и тот же контент нужен сразу нескольким системам.

Например, компания ведет основной сайт, мобильное приложение и несколько региональных проектов.

Если каждая система хранит свою копию данных, со временем информация начинает расходиться. Где-то обновили описание услуги, где-то забыли. В одном приложении старый телефон, на сайте уже новый.

При headless-подходе данные хранятся централизованно, а интерфейсы используют один источник.

Есть и вторая причина — свобода разработки пользовательской части.

CMS не диктует, как должен быть устроен frontend. Команда может развивать его отдельно и выбирать технологии под требования самого продукта.

Почему headless подходит не каждому проекту

Разделение системы добавляет новую сложность.

Теперь отдельно существуют CMS, frontend и API. Нужно продумать авторизацию, кеширование, предварительный просмотр материалов и работу при сбоях между компонентами.

Для большого продукта это может быть оправдано.

Для сайта компании из нескольких десятков информационных страниц — уже не факт.

Если контент используется только в одном месте, классическая CMS иногда оказывается проще и дешевле в эксплуатации без заметных ограничений для бизнеса.

Классическая и headless CMS: в чем разница

Критерий	Классическая CMS	Headless CMS
Связь CMS и сайта	Тесная	Разделены
Получение контента	Обычно внутри одной платформы	Через API
Один корпоративный сайт	Типовой сценарий	Возможен, но не всегда нужен
Несколько сайтов и приложений	Зависит от системы	Один из основных сценариев
Свобода frontend	Зависит от платформы	Выше
Техническая сложность	Обычно ниже	Обычно выше
Повторное использование контента	Возможно	Закладывается в архитектуру

Как эти подходы сочетаются

Здесь как раз становится видно, почему не стоит ставить готовую, собственную и headless CMS в один ряд.

Компания может взять готовую CMS и использовать ее в классическом варианте.

Можно взять готовую CMS только как систему управления контентом, а frontend разработать отдельно. Это уже готовая headless CMS.

То же самое с собственной системой. Она может быть частью одного сайта или отдавать данные сразу нескольким приложениям через API.

То есть у одного проекта могут одновременно быть характеристики «готовая» и «headless» или «собственная» и «headless».

Это не противоречие.

По каким еще признакам различают CMS

Готовая или собственная, классическая или headless — не единственные характеристики.

Есть еще как минимум два различия, которые часто встречаются при обсуждении CMS.

Коммерческие и с открытым исходным кодом

Коммерческая CMS распространяется по лицензии разработчика. Условия использования, обновлений и поддержки определяет поставщик.

У систем с открытым исходным кодом исходники доступны для просмотра и изменения в рамках условий конкретной лицензии.

Например, WordPress и Drupal относятся к open source. «1С-Битрикс: Управление сайтом» — коммерческий продукт.

При этом открытый исходный код сам по себе не означает, что проект получится бесплатным. Все равно остаются расходы на разработку, настройку, инфраструктуру и поддержку.

И наоборот, коммерческая лицензия не говорит о том, подходит система конкретному проекту или нет.

Это всего лишь один из параметров.

Облачные и на собственной инфраструктуре

Еще одно различие — где работает CMS.

Систему можно разместить на инфраструктуре самой компании или подрядчика. В этом случае команда получает больше контроля над окружением, настройками и обновлениями.

Другой вариант — облачная CMS, которую предоставляет производитель как сервис. Компания пользуется системой, а эксплуатацией базовой платформы занимается поставщик.

У обоих подходов есть свои ограничения по контролю, обновлениям, безопасности и способам интеграции.

Для корпоративных проектов этот вопрос часто становится важным уже на этапе требований к инфраструктуре и информационной безопасности.

Что в итоге

У CMS нет одной универсальной классификации.

Готовая и собственная системы отличаются тем, используем мы существующий продукт или создаем систему под конкретный проект. И разобраться в видах CMS — только первый шаг. На практике сложность начинается позже, когда нужно выбрать конкретный подход под проект и не переплатить за возможности, которые не понадобятся, или наоборот — не упереться в ограничения системы через год после запуска.

В следующей статье разберем, как выбрать CMS для корпоративного сайта: какие требования стоит определить заранее, на что смотреть кроме цены и популярности платформы и в каких случаях архитектуру лучше закладывать с запасом на дальнейшее развитие.

38:T29c3,

Интеграция новых технологий в вашу ИТ-систему — это процесс, который может значительно улучшить производительность, повысить безопасность и упростить управление инфраструктурой. Чтобы этот процесс прошел гладко, нужно учитывать несколько ключевых шагов. В этой статье мы расскажем, как правильно внедрить новые решения в сложную ИТ-инфраструктуру и избежать распространенных ошибок.

5 шагов для успешной интеграции новых технологий в сложную ИТ-инфраструктуру

Шаг 1: Оценка текущей ИТ-инфраструктуры

Прежде чем внедрять новые решения, необходимо оценить текущее состояние инфраструктуры. Это первый и важнейший этап, который определит, какие проблемы существуют и какие технологии помогут их решить.

Без этой оценки можно попасть в ловушку, где новые решения не смогут нормально работать из-за несовместимости с устаревшими системами. Важнейшие вопросы на этом этапе:

Какова текущая нагрузка на вашу инфраструктуру?
Какие компоненты системы наиболее уязвимы или устарели?
Что нужно улучшить для повышения производительности?

Полученная информация поможет не только выявить слабые места, но и выбрать оптимальные решения для модернизации системы.

Шаг 2: Определение целей и требований

Следующий шаг — это формулирование чётких целей и требований, которые должны быть достигнуты с помощью новых технологий. Иначе вы рискуете внедрить что-то, что не решит ваши бизнес-задачи.

Цели должны быть:

Измеримыми: например, «снизить время отклика на 20%» или «сократить количество сбоев на 30%».
Конкретными: что конкретно должно измениться в работе системы — улучшение производительности, повышение безопасности, оптимизация процессов.
Совместимыми с долгосрочной стратегией бизнеса: технологии должны соответствовать направлениям развития вашей компании.

Этот шаг поможет избежать ненужных затрат на технологические решения, которые не соответствуют нуждам бизнеса.

Шаг 3: Выбор подходящих технологий и подрядчиков

Когда цели определены, и вы понимаете, какие задачи должны быть решены, наступает следующий важный этап — выбор технологий и подрядчиков. На рынке существует множество решений, но не все они подойдут для вашего бизнеса.

Важно: технологии должны быть гибкими, масштабируемыми и совместимыми с вашими текущими системами. Не стоит увлекаться модными решениями или теми, которые дают краткосрочные результаты. Сосредоточьтесь на том, что будет работать для вашей инфраструктуры в долгосрочной перспективе.

При выборе подрядчика обратите внимание на надежность и репутацию компании, наличие документации, возможность обучения персонала, их предыдущие кейсы.

Шаг 4: Планирование и подготовка к интеграции

Теперь, когда решение выбрано, нужно планировать интеграцию. Без четкого плана внедрения технологии рискуют вызвать сбои в работе системы и привести к неоправданным затратам.

Этап планирования включают:

Тестирование: перед полномасштабным внедрением важно протестировать технологию в условиях близких к реальным.
Резервное копирование и защита данных: обеспечение безопасности всех данных во время внедрения.
Разработка плана на случай неудачи: всегда имеет смысл предусмотреть альтернативные варианты действий, чтобы минимизировать риски при сбоях.

«Каждый этап интеграции новых технологий должен быть тщательно проработан. Без должного планирования и оценки рисков даже самые лучшие решения могут не оправдать ожиданий», — Вадим Зимин, руководитель отдела разработки, Энсайн

Шаг 5: Мониторинг и оптимизация после интеграции

Интеграция технологий — это не конец. Это начало нового этапа, когда важно следить за результатами и оптимизировать системы в процессе работы. Постоянный мониторинг позволяет не только отслеживать производительность, но и выявлять возможные проблемы на ранних стадиях.

После внедрения технологии важно:

Отслеживать производительность: как она влияет на существующие процессы, и есть ли улучшения в ключевых метриках.
Проводить регулярное обновление и улучшение: после внедрения системы важно продолжать её развивать и адаптировать под меняющиеся условия.
Обратная связь от сотрудников: важно, чтобы персонал мог дать обратную связь о новых технологиях и сообщать о проблемах в их работе.

Многие компании забывают о необходимости постоянной оптимизации после интеграции. Поддержание высокого уровня производительности в долгосрочной перспективе — ключевой аспект для успешного использования новых технологий.

Подведем итоги

Интеграция новых технологий — это важный процесс, который помогает улучшить ИТ-систему и делает её более гибкой и безопасной. Чтобы интеграция прошла успешно, важно правильно оценить текущую систему, четко определить цели, выбрать подходящие решения и планомерно внедрять их. Не забывайте об оптимизации после интеграции, чтобы система продолжала работать на полную мощность.

Узнайте больше о наших решениях для корпоративных клиентов.

39:T2610,

В крупной компании legacy-система часто воспринимается как стабильный элемент инфраструктуры. Она работает — значит, проблем нет. Но эта спокойная иллюзия может обернуться большими рисками для бизнеса.

Когда система работает, кажется, что можно просто оставить всё как есть. Но накапливающиеся проблемы могут проявиться позже — когда будет слишком поздно что-то менять. Простой отчет может превратиться в долгую и рискованную задачу, а небольшой апдейт — в настоящую катастрофу.

Отсроченные риски

Когда мы работаем с legacy-системами, мы накапливаем риски. Проблемы не исчезают, а просто откладываются. Вроде бы все работает, но в этом состоянии постоянно растет вероятность ошибок. Если не вовремя заметить слабые места, они могут перерасти в серьезные сбои.

С каждым годом старые компоненты системы теряют свою актуальность. Интеграции с другими системами начинают давать сбои, а устаревшие компоненты становятся уязвимыми для новых угроз. Каждое изменение оказывается сложнее, чем кажется на первый взгляд, потому что система не была построена с учетом долгосрочного роста и изменений.

Эта инертность ведет к накоплению долгосрочных рисков, которые сначала не очевидны, но с каждым годом становятся всё более очевидными и критичными.

Потеря управляемости и безопасности

Старые системы становятся всё менее управляемыми. Это особенно заметно, когда нужно внести изменения. Чаще всего что-то ломается — даже если правка кажется незначительной.

Без регулярных обновлений и доработок система перестает отвечать современным требованиям безопасности. Устаревшие компоненты становятся уязвимыми для кибератак, а отсутствие своевременных обновлений увеличивает вероятность потери данных или других критических рисков.

Каждая неучтенная зависимость, каждый компонент, который не был обновлен вовремя, может привести к серьезным последствиям для бизнеса — от утечек данных до полной остановки ключевых процессов.

Реальные последствия игнорирования legacy

Если постоянно откладывать работу с legacy-системой, последствия могут проявиться в нескольких формах:

Уязвимость для кибератак: Старые системы часто не выдерживают современных угроз. Устаревшие компоненты не поддерживают последние обновления безопасности.
Проблемы с производительностью: Система может не справляться с увеличившейся нагрузкой, особенно при пиковых запросах. Это ведет к замедлению работы и повышенному времени отклика, что критично для бизнеса.
Потеря контроля: Сложность системы растет, и управлять ею становится всё сложнее. В некоторых случаях управление системой превращается в ежедневный баланс между устранением ошибок и решением новых проблем, что забирает ресурсы у команды.

Когда в компании начинают осознавать, что все эти проблемы уже накопились, иногда бывает слишком поздно что-то менять без значительных затрат. Система может перестать поддерживать операции, а переход на новые технологии обернется высокими рисками и дополнительными расходами.

Как минимизировать риски

Чтобы минимизировать эти риски, важно начать работать с legacy-системой до того, как она начнет выходить из строя. Не нужно ждать, пока система перестанет работать должным образом. Лучше начать модернизацию, пока еще есть время.

Проводить регулярные аудиты системы. Это поможет выявить уязвимости и точки, требующие доработки.
Обновлять ключевые компоненты и решать проблемы по мере их появления. Модернизация системы должна быть поэтапной и регулярной.
Внедрить автоматизированное тестирование, чтобы оперативно выявлять проблемы. Это поможет избежать человеческого фактора и ускорить процесс внесения изменений.

Раннее вмешательство поможет избежать множества неприятных сюрпризов и позволит системе работать стабильно и безопасно.

Заключение

Legacy-системы требуют постоянного внимания. Игнорирование их состояния и откладывание изменений приводит к накоплению рисков, которые могут стать критическими для бизнеса. Важно не ждать, пока система сломается. Регулярная модернизация и своевременные правки помогут сохранить её работоспособность и безопасность на долгие годы.

«Когда мы начинаем работать с legacy-системой, важно понимать, что это не просто устранение ошибок, а управление рисками, которые накапливаются годами. Важно вовремя вмешаться, прежде чем система начнёт ломаться под нагрузкой. Каждый пропущенный этап в модернизации увеличивает вероятность катастрофы. Чем раньше начнём, тем меньше рисков для бизнеса в будущем. Важно не только снизить затраты на поддержку, но и ускорить решение задач бизнеса, что способствует росту доходов и прибыли», — Алексей Постригайло, партнер, ИТ-интегратор ЭНСАЙН.

Если ваша система давно не обновлялась, начните с технического анализа, чтобы избежать серьезных последствий в будущем.

3a:T2d5f,

В первой статье мы разобрали основные риски, с которыми сталкиваются компании при выборе подрядчика. Мы понимаем, что для вас важно не просто избежать этих рисков, но и получить гарантии, стабильность и результат, который превзойдет ваши ожидания. Теперь мы расскажем, как наша компания решает эти задачи, обеспечивая вам качественное выполнение проектов и долгосрочную поддержку.

1. Компетенции подрядчика: Как мы обеспечиваем качество и опыт

Риск в первой статье:

Недостаточная компетенция подрядчика приводит к задержкам и перерасходу бюджета.

Как это решает наша компания:

Мы привлекаем только высококвалифицированных специалистов с глубоким опытом в вашей отрасли и уверены, что каждый проект требует глубокой аналитики и технической экспертизы. В нашей команде работают эксперты, которые прошли через множество успешных проектов в разных сферах, что позволяет нам предложить надежные и эффективные решения. Мы используем новейшие технологии и методологии, чтобы обеспечивать высокое качество на каждом этапе.

Почему это важно:

Мы понимаем, что для вашего бизнеса каждый проект — это не просто задача, а инвестиция в будущее. Поэтому вы можете быть уверены, что квалификация нашей команды гарантирует успешное выполнение и достижение поставленных целей без лишних затрат.

2. Вовлеченность в проект: Как мы обеспечиваем вашу уверенность на каждом шаге

Риск в первой статье:

Низкая вовлеченность подрядчика ведет к недопониманию и несоответствиям с бизнес-целями.

Как это решает наша компания:

Мы формируем выделенную команду, которая полностью сосредоточена на вашем проекте. Ваши цели становятся нашими целями, и мы работаем как единая команда. У нас нет стандартных решений — каждое предложение, каждое действие подчинено вашим уникальным требованиям. Мы постоянно поддерживаем связь и информируем вас о ходе проекта, обеспечивая полную прозрачность и вовлеченность.

Почему это важно:

Вовлеченность нашей команды на всех этапах проекта — это залог того, что вы получаете решение, идеально соответствующее вашему бизнесу. Мы снимаем с вас всю нагрузку по управлению проектом, экономя ваши ресурсы и время.

3. Гарантии сроков и качества: Как мы обеспечиваем выполнение в срок и с гарантией результата

Риск в первой статье:

Подрядчик без гарантий может не выполнить проект в срок или не соблюсти заявленное качество.

Как это решает наша компания:

Мы предлагаем четкие гарантии по срокам и качеству выполнения работ. На каждом этапе проекта мы фиксируем контрольные точки, которые согласовываются с вами. Мы гарантируем, что ваш проект будет завершен вовремя, с соблюдением всех согласованных критериев качества. Если возникнут непредвиденные обстоятельства, мы быстро реагируем, чтобы минимизировать последствия и избежать срывов.

Почему это важно:

Гарантии — это не просто формальности. Они подтверждают нашу готовность брать на себя ответственность за результат и доверие, которое вы нам оказываете. Мы понимаем, как важен для вас каждый срок и каждое обязательство.

4. Прозрачность стоимости: Как мы делаем бюджет понятным и без скрытых расходов

Риск в первой статье:

Невозможность точно оценить стоимость проекта может привести к неожиданным расходам.

Как это решает наша компания:

Мы предоставляем детализированное коммерческое предложение на каждом этапе работы. В нём четко прописаны все расходы, что позволяет вам контролировать бюджет и избежать скрытых платежей. Никаких неожиданных доплат и расходов — мы работаем прозрачно и честно. Вы будете точно знать, за что платите, и какие результаты получите.

Почему это важно:

Полная прозрачность и чёткие расчёты — это то, что позволяет вам управлять рисками и гарантировать, что проект будет выполнен в рамках бюджета. Мы уверены, что только такой подход помогает построить доверительные отношения.

5. Поддержка после завершения проекта: Как мы обеспечиваем вашу уверенность и после запуска

Риск в первой статье:

После завершения разработки подрядчик может забыть о проекте, оставив вас без поддержки.

Как это решает наша компания:

Мы не только сдаем проект, но и продолжаем поддерживать его даже после запуска. Мы предлагаем услуги сопровождения, регулярные обновления, техническую поддержку и адаптацию системы под изменяющиеся требования бизнеса. Мы будем рядом с вами долгосрочно, чтобы поддерживать эффективность и актуальность решения.

Почему это важно:

После реализации проекта, ваша система должна быть готова к изменениям и масштабированию. Мы гарантируем, что системы останутся актуальными, а поддержка будет оперативной и высококачественной.

Почему мы — ваш идеальный IT‑партнер

Опыт и компетенции: Мы привлекаем только опытных специалистов, обладающих глубокими знаниями в вашей отрасли.
Выделенная команда: Мы формируем команду, которая работает исключительно на ваш проект, обеспечивая максимальную вовлеченность и минимальные усилия с вашей стороны.
Гарантии и прозрачность: Мы гарантируем соблюдение сроков и бюджета, а также прозрачность всех процессов.
Долгосрочное партнерство: Мы предлагаем постоянную поддержку и развитие системы, чтобы ваше решение было актуальным и эффективным.

Готовы построить успешное партнерство?

Запишитесь на консультацию с нами, и мы поможем вам решить задачи вашего бизнеса с максимальной выгодой.

3b:T50f1,

Что такое CMS и как она работает

CMS расшифровывается как Content Management System — система управления контентом.

CMS позволяет разделить программную часть сайта и его содержание.

Разработчик один раз определяет, какие данные нужны странице и как она должна выглядеть. Например:

название услуги;
краткое описание;
основной текст;
изображение;
документы;
статус публикации.

После этого сотрудник компании заполняет эти поля через административный интерфейс.

Упрощенно процесс выглядит так:

Редактор

↓

CMS

↓

Контент

↓

Сайт

↓

Посетитель

Для этого не нужно редактировать HTML, работать с базой данных или ставить отдельную задачу программисту.

Что происходит, если CMS нет

Сам сайт вполне может работать без системы управления.

Но на корпоративном сайте информация постоянно обновляется.

Без CMS обычное изменение превращается в техническую задачу:

сотрудник готовит информацию;
передает ее разработчику;
задача попадает в очередь;
разработчик вносит изменения;
результат проверяют;
обновление публикуют.

Само изменение может занимать несколько минут. Но на сайте оно появится значительно позже.

CMS убирает разработчика из тех операций, где разработка как таковая не требуется.

Что можно делать через CMS

Конкретные возможности зависят от проекта, но базовые функции у большинства систем похожи.

Создавать и менять материалы

Причем разные материалы могут иметь разную структуру.

Загружать изображения и документы

Редактор может самостоятельно добавлять фотографии, PDF-файлы, презентации, инструкции и другие материалы.

После загрузки их можно использовать в нужных разделах сайта.

Управлять пользователями и правами

Корпоративным сайтом редко занимается один человек.

CMS позволяет определить, кто и с какими разделами может работать.

Хранить историю изменений

Если контент регулярно обновляется, важно понимать, кто и что поменял.

Управлять публикацией

Материал не обязательно должен сразу появляться на сайте.

Зачем CMS бизнесу

Технически CMS нужна для управления контентом. Но для компании ценность обычно находится в четырех вещах.

Сотрудники меньше зависят от разработчиков

Разработчик не должен менять телефон на странице, загружать новый PDF или публиковать очередную новость.

CMS передает ежедневную работу с информацией тем сотрудникам, которые за нее отвечают.

Изменения появляются быстрее

Не нужно ждать свободного разработчика и ставить отдельную техническую задачу.

Чем чаще меняется сайт, тем заметнее эта разница.

Информация остается структурированной

Допустим, у компании 100 филиалов.

Можно создать 100 отдельных страниц и вручную разместить на каждой адрес, телефон и режим работы.

Но надежнее создать единый тип данных «Филиал»:

Название
Адрес
Телефон
Режим работы
Координаты
Услуги
Фотографии

Все филиалы будут заполняться одинаково.

Несколько подразделений могут работать с сайтом одновременно

На большом сайте контент обычно распределен между разными подразделениями.

Нет смысла собирать все изменения у одного администратора и вручную переносить их на сайт.

CMS, админка и сайт — в чем разница

Эти понятия часто используют как синонимы, хотя это не совсем одно и то же.

CMS — система управления содержимым сайта и связанными с ним процессами.

Админка — интерфейс, через который сотрудники работают с CMS.

Поэтому наличие административной панели еще ничего не говорит о возможностях самой системы.

В одном проекте админка позволяет поменять несколько текстов.

Как CMS работает на крупном корпоративном сайте

На небольшом сайте CMS действительно может ограничиваться страницами и новостями.

На больших проектах ситуация другая.

Задача была не просто в создании новой административной панели.

Это важная граница.

На корпоративном уровне CMS постепенно превращается из редактора страниц в систему управления данными сайта.

Может ли CMS работать с CRM, 1С и другими системами

Да.

На корпоративных проектах часть информации часто находится за пределами CMS.

CMS в такой архитектуре становится одним из участников обмена данными.

Но сама по себе она интеграции не создает. Это уже задача архитектуры и разработки конкретного проекта.

Каждому ли сайту нужна CMS

Нет.

Но чем чаще сайт меняется, тем больше от нее пользы.

CMS особенно нужна, если после запуска сотрудники должны регулярно:

публиковать статьи и новости;
менять страницы;
загружать документы;
обновлять каталог;
добавлять вакансии;
поддерживать список сотрудников или филиалов;
работать с сайтом одновременно.

Можно использовать простой критерий:

если завтра на сайте нужно что-то изменить, кто должен это сделать — сотрудник компании или разработчик?

Чего CMS сама по себе не решает

Наличие CMS не гарантирует, что сайт получится удобным, быстрым или хорошо оптимизированным для поиска.

CMS дает инструменты для управления.

Результат зависит от того, насколько правильно спроектированы сам сайт, данные и процессы работы с ними.

Поэтому выбирать систему только по количеству функций в административной панели не стоит.

Сначала нужно понять, какой информацией компания будет управлять после запуска и кто будет с ней работать.

Что в итоге

На небольшом проекте это страницы, новости, тексты и изображения.

Дальше возникает следующий вопрос: какую CMS выбрать под конкретный проект.

3c:T265d,

DevOps — это способ работы, который объединяет разработку и эксплуатацию, чтобы быстрее и безопаснее доставлять обновления. Он помогает не только ускорить процесс, но и повысить безопасность. В этой статье разберем, как DevOps помогает решить два важных вопроса — скорость и безопасность.

Автоматизация процессов разработки и развертывания

Автоматизация — это основной элемент DevOps. Без неё невозможно быстро и безопасно доставлять обновления. Когда всё автоматизировано, ошибки, связанные с ручными действиями, исключаются, а процессы становятся быстрее.

Автоматизация помогает сократить время развертывания обновлений — когда всё настроено автоматически, изменения можно внедрять в несколько кликов, а также уменьшить количество ошибок, ведь всё происходит по проверенному процессу и не нужно вручную вводить данные.

Это важно, потому что в мире ИТ время всегда критично. Чем быстрее и надёжнее происходит внедрение обновлений, тем лучше.

Интеграция безопасности (DevSecOps)

Важный момент, который отличает DevOps от старых подходов — это интеграция безопасности на всех этапах работы. Вместо того чтобы проводить тестирование безопасности в конце, как это бывает в традиционных методах, в DevOps безопасность включена с самого начала.

Что это даёт:

Раннее обнаружение уязвимостей. Вы не ждете, пока проблема возникнет в продуктивной среде. Проверки безопасности происходят на каждом этапе.
Меньше рисков. Автоматические тесты и проверки помогают минимизировать угрозы безопасности до того, как они станут проблемой.

«Если безопасность не встроена в процесс с самого начала, её исправление на финальных этапах разработки может быть слишком поздно», — Вадим Зимин, руководитель отдела разработки, Энсайн.

Мониторинг и обратная связь

DevOps требует постоянного мониторинга. Это помогает оперативно выявлять проблемы, даже до того, как они станут угрозой. Мониторинг позволяет увидеть, что происходит с системой в реальном времени.

Вы мгновенно видите все отклонения от нормальной работы и получаете быструю обратную связь для оперативного реагирования. Так можно гарантировать, что система будет работать без сбоев, а угрозы будут устранены на ранних стадиях.

Сотрудничество команд разработки и эксплуатации

В традиционных подходах разработка и эксплуатация работают раздельно. В DevOps всё иначе — разработчики и операторы работают вместе на всех этапах.

Это даёт:

Быструю реакцию на возникающие проблемы.
Прозрачность процессов, потому что все участники видят, как их работа влияет на остальных.
Скорость принятия решения. Команды совместно устраняют проблемы и ускоряют развертывание обновлений.

Эволюция DevOps: новые тренды и подходы

DevOps продолжает развиваться, и на горизонте уже видны новые тренды, которые еще больше ускоряют процессы и усиливают безопасность.

Роль DevOps в ускорении обновлений и укреплении безопасности систем

Например:

GitOps: Использование Git как единого источника правды для всех конфигураций и процессов развертывания. Это позволяет еще больше автоматизировать процессы и сделать их более прозрачными.
Инфраструктура как код (IaC): Инструменты для управления инфраструктурой через код делают настройку и масштабирование более гибкими и быстрыми. Это особенно важно для динамично развивающихся проектов, где нужно быстро адаптироваться.
Контейнеризация: Эти технологии позволяют масштабировать приложения и управлять ими, улучшая производительность и снижая риски при развертывании.
ML для мониторинга: Использование машинного обучения для предсказания сбоев и угроз. Такие подходы помогают на предсказуемо высокой скорости устранять проблемы, не допуская их перерастания в инциденты.

Постоянное улучшение

Как мы поняли, DevOps — это постоянное совершенствование. Процесс не заканчивается с внедрением первых обновлений, ведь система всегда требует оптимизации.

Проверяйте обновления на каждом этапе, регулярно анализируйте данные, чтобы выявлять слабые места и постоянно оптимизируйте процессы на основе полученных результатов.

Подведем итоги

DevOps — это мощный инструмент, который помогает ускорить доставку обновлений и повысить безопасность ИТ-систем. Интеграция автоматизации, безопасности и постоянного мониторинга позволяет создавать гибкие и безопасные системы, которые быстро реагируют на изменения. Внедрение DevOps помогает компании снизить риски, ускорить работу и поддерживать высокие стандарты безопасности. Это необходимое условие для компаний, которые хотят оставаться конкурентоспособными и защищёнными.

3d:T6039,

Сайт может выглядеть аккуратно и при этом мешать пользователю решить задачу. Нужный раздел спрятан, форма обнуляется после ошибки, заявка не доходит до внутренней системы, а мобильная версия требует лишних действий. Вместе такие сбои создают ручную работу, увеличивают стоимость привлечения и снижают отдачу от продукта.

Юзабилити-аудит сайта помогает пройти ключевые сценарии глазами пользователя и проверить, что происходит за интерфейсом. Проверка охватывает интерфейс, аналитику, интеграции и ограничения системы.

Ниже собран рабочий чек-лист. Он поможет провести первичную проверку, определить критичные проблемы и подготовить задачи для команды разработки.

Содержание

Определите цели и границы юзабилити-аудита сайта

Проверьте первый экран, структуру и навигацию

Пройдите ключевые пользовательские сценарии

Проверьте формы и движение данных

Проверьте мобильную версию и техническую устойчивость

Найдите системные ограничения и оцените стоимость изменений

Подготовьте результаты к внедрению и поддержке

1. Определите цели и границы юзабилити-аудита сайта

Проверять весь сайт без приоритета обычно невыгодно. На крупном ресурсе можно найти десятки спорных деталей, но их исправление не обязательно повлияет на продажи, обслуживание или нагрузку на сотрудников. Начинать стоит со сценариев, которые имеют понятный результат для пользователя и бизнеса.

Чек-лист

Определены основные задачи пользователей.
Для каждой задачи зафиксирована точка входа.
Понятно, какое действие считается успешным завершением.
Выбраны страницы и функции, которые входят в аудит.
Указаны устройства и роли пользователей для проверки.
Проверены настройки веб-аналитики.
Зафиксированы ограничения по срокам, бюджету и платформе.

Признак проблемы: обсуждение начинается с цвета кнопок, хотя команда еще не определила, какие действия пользователей влияют на результат.

Последствие для бизнеса: бюджет уходит на заметные, но второстепенные изменения. Разрыв в заявке, регистрации или поиске услуги остается без внимания.

«До начала аудита мы фиксируем, какой путь проверяем и где он заканчивается внутри компании. Иначе отчет превращается в длинный список наблюдений, из которого невозможно собрать нормальный план работ», — Екатерина Шмелева, руководитель проектов «Энсайн».

2. Проверьте первый экран, структуру и навигацию

Пользователь может прийти из поиска сразу в услугу, статью, карточку продукта или форму. На любой точке входа он должен понять, куда попал, что здесь можно сделать и куда двигаться дальше.

Чек-лист первого экрана

Заголовок соответствует ожиданию от источника перехода.
Назначение страницы понятно без изучения всего сайта.
Основное действие видно и сформулировано конкретно.
Дополнительные кнопки не конкурируют с ним.
На мобильном устройстве баннеры не перекрывают содержание.

Чек-лист структуры и навигации

Информация расположена в порядке, соответствующем задаче пользователя.
Заголовки помогают быстро просмотреть страницу.
Условия и ограничения находятся рядом с действием.
Названия разделов понятны без знания структуры компании.
Внутренние ссылки ведут к следующему шагу.
Нет страниц, из которых можно выйти только назад.
Мобильное меню сохраняет основные разделы и действия.

Чек-лист поиска и фильтров

Поиск доступен там, где ручная навигация неудобна.
Результаты соответствуют запросу.
Пустая выдача предлагает изменить запрос или перейти в раздел.
Фильтры используют понятные характеристики.
Выбранные параметры видны и легко сбрасываются.

Признак проблемы: пользователь возвращается в меню, меняет запросы или открывает несколько похожих страниц подряд.

Что проверять глубже: причина может находиться в структуре каталога или качестве исходных данных. Перерисовка поиска не поможет, если система не знает, какие товары, документы или услуги связаны между собой.

3. Пройдите ключевые пользовательские сценарии

Страницы нельзя оценивать изолированно. Пользователь решает задачу через последовательность действий. Ошибка может появиться между 2 исправными экранами: после выбора услуги, при переходе к форме, во время авторизации или при возврате из внешней системы.

Чек-лист сценария

У пути есть понятные начало и завершение.
Каждый шаг объясняет следующее действие.
В многоэтапном процессе виден прогресс.
Возврат назад не удаляет введенные данные.
Ошибки отображаются рядом с местом возникновения.
Сообщение подсказывает способ исправления.
Повторное действие не создает дубли.
После завершения пользователь получает подтверждение.
Проверено поведение при недоступности внешнего сервиса.

Проверьте содержание

Текст отвечает на вопрос текущего шага.
Условия не спрятаны после подтверждения.
Инструкции совпадают с поведением системы.
Термины понятны целевой аудитории.
Контакты поддержки доступны в точке затруднения.

Признак проблемы: операцию можно завершить, но пользователю приходится звонить сотруднику, искать инструкцию в другом разделе или повторно вводить данные.

Последствие для бизнеса: цифровой сценарий не сокращает нагрузку, а переносит ее на поддержку и операционные подразделения.

Юзабилити-аудит сайта: путь пользователя и путь данных

4. Проверьте формы и движение данных

Успешная отправка формы на сайте еще не означает, что обращение принято в работу. Данные проходят проверку, передаются через интеграцию, записываются во внутреннюю систему и назначаются ответственному. Сбой на любом участке приводит к одному результату: пользователь отправил информацию, но продолжения не получил.

Чек-лист формы

Запрашиваются только необходимые на этом этапе данные.
Формат поля понятен до начала ввода.
Ошибка в одном поле не очищает всю форму.
Проверка данных не срабатывает раньше времени.
Кнопка защищена от повторных нажатий.
После отправки показан понятный статус.
Пользователь получает подтверждение.
Форма проверена на мобильном устройстве.

Чек-лист передачи данных

Все поля доходят до внутренней системы без искажений.
Источник обращения определяется корректно.
Заявка попадает в нужный процесс.
Ответственный назначается по понятному правилу.
Ошибка интеграции фиксируется в журнале.
Команда получает уведомление о сбое.
Действие на сайте можно сопоставить с записью во внутренней системе.

«Интерфейс часто показывает только последний участок проблемы. Если заявка потерялась после отправки, менять текст кнопки бессмысленно. Нужно пройти маршрут данных и понять, на каком шаге система перестала выполнять ожидаемое действие», — Екатерина Шмелева, руководитель проектов «Энсайн».

Признак проблемы: сотрудники ищут обращения в почте, сверяют несколько систем или вручную переносят данные из формы.

Последствие для бизнеса: растет время обработки, появляются дубли, а источник потери заявки трудно восстановить.

5. Проверьте мобильную версию и техническую устойчивость

Мобильная проверка не должна ограничиваться уменьшением окна браузера. Основные сценарии нужно пройти на реальном устройстве, с экранной клавиатурой и нестабильным соединением.

Чек-лист мобильной версии

Контент сохраняет правильный порядок.
Кнопки доступны без точного попадания.
Фиксированные панели не перекрывают форму.
Клавиатура не закрывает активное поле.
Таблицы и схемы можно прочитать без прокрутки всей страницы.
Всплывающие окна закрываются.
После временной потери связи данные не исчезают.

Чек-лист технической устойчивости

Основной контент появляется без ожидания второстепенных элементов.
Ошибка внешнего сервиса не блокирует всю страницу.
Повторное нажатие не создает несколько операций.
Пользователь получает понятное сообщение при недоступности функции.
Критичные сценарии контролируются мониторингом.
Изменения проверяются в тестовом контуре.

Что проверять глубже: задержка может возникать в интерфейсе, серверной обработке, внешней системе или модели данных. До постановки задачи нужно определить источник, иначе ускорение одного экрана не изменит сценарий.

6. Найдите системные ограничения и оцените стоимость изменений

На развивающемся сайте одинаковые элементы часто начинают работать по-разному. Одну форму обновили, вторую скопировали для нового раздела, третья осталась на старом компоненте. Пользователь видит непоследовательный интерфейс, а команда получает несколько мест для поддержки одной функции.

Чек-лист системных ограничений

Одинаковые элементы используют общие компоненты.
Формы применяют единые правила проверки.
Справочники получают данные из одного источника.
Контент не дублируется вручную.
Устаревшие страницы выведены из навигации и поиска.
Ключевые интеграции описаны.
Известны зависимости от внешних сервисов.
Изменение общего компонента можно проверить до выпуска.

Локальная или системная проблема

Локальная проблема возникает в одном элементе и не повторяется в других сценариях. Ее можно устранить без изменения общей логики продукта.

Системная проблема появляется в нескольких местах или возвращается после доработок. Источник может находиться в компоненте, данных, интеграции или процессе публикации. Исправление одного экрана уберет симптом, но не сократит будущие расходы.

«Для бизнеса ценнее найти одну общую причину нескольких ошибок, чем получить сотню замечаний к отдельным экранам. Системное изменение может стоить дороже на старте, но оно снижает стоимость следующих доработок и делает продукт предсказуемее», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

На оценку влияют состояние кода, число зависимых систем, качество документации, наличие тестового контура и возможность проверить изменение без риска для работающего сервиса.

Юзабилити-аудит сайта: локальное исправление или системное решение

7. Подготовьте результаты к внедрению и поддержке

Отчет не должен заканчиваться формулировками «улучшить навигацию» или «сделать форму удобнее». Каждое замечание нужно связать со сценарием, причиной и ожидаемым результатом.

Что должно быть в карточке проблемы

Страница или функция, где обнаружен сбой.
Условие возникновения.
Фактическое и ожидаемое поведение.
Последствие для пользователя и бизнеса.
Предполагаемый источник проблемы.
Зависимости от других систем.
Рекомендуемый вариант исправления.
Критерий приемки.

Как расставить приоритеты

Исправить в первую очередь:

пользователь не может завершить основное действие;
данные теряются или искажаются;
ошибка затрагивает оплату, регистрацию или доступ;
сбой создает постоянную ручную работу;
проблема влияет на безопасность данных.

Включить в план развития:

сценарий требует лишних действий;
одинаковые элементы ведут себя по-разному;
ограничение мешает запуску следующей функции;
временное решение увеличивает стоимость поддержки.

Объединить с плановым обновлением:

визуальная неточность не мешает сценарию;
изменение выгоднее внедрять вместе с общим компонентом.

После выпуска сценарий нужно пройти повторно, проверить передачу данных и соседние функции. Для критичных операций нужны мониторинг и уведомления. Без них команда узнает о сбое из жалоб или пропавших обращений.

Такой формат особенно важен, когда аудит становится основанием для разработки и поддержки цифровых сервисов: команда получает проверяемые задачи с понятными приоритетами и техническими зависимостями.

3e:T77bd,

Зачем мы решили включить HConfig в реестр российского ПО

На практике процесс оказался значительно глубже.

«Мы заходили в процедуру с ощущением, что основная сложность будет в сборе документов. В результате самым полезным оказался другой эффект: пришлось последовательно разобрать продукт как объект, который должен существовать независимо от конкретного разработчика, сервера или внешнего сервиса. Для зрелого программного продукта такая проверка сама по себе полезна», — Алексей Постригайло, старший партнер Энсайн.

Первая заявка: почему рабочего продукта оказалось недостаточно

Заявку отклонили.

Вторая попытка: проблема с правообладателями

Причиной стала структура прав на HConfig.

Какие документы пришлось дорабатывать

Специалист помог разобрать заявку и указал, каких сведений не хватает.

Техническая проверка HConfig

Что происходит с программой без доступа в интернет

Еще один практический вопрос касался эксплуатации в изолированной инфраструктуре.

Почему README оказалось мало

Еще одна часть работы, которую легко недооценить, — документация.

Для внешней проверки такой подход не подходит.

Если ответ отрицательный, документация еще не закончена.

Сколько работы занимает подготовка к реестру

Для подачи заявления эту информацию приходится собирать в единую систему.

В этом смысле подготовка к реестру стала для нас своеобразной инвентаризацией продукта.

Результат: HConfig в реестре российского ПО

Для нас результат важен прежде всего с продуктовой точки зрения.

Что проверить перед подачей заявления в реестр российского ПО

После прохождения этого процесса мы бы начинали подготовку значительно раньше самой подачи заявления.

Проверить правообладателей и права на код. Нужно восстановить всю цепочку возникновения исключительных прав и заранее разобраться со случаями, когда правообладателей несколько.
Проверить домены и публичную документацию. Ресурсы продукта должны быть оформлены корректно и соответствовать сведениям, указанным в заявлении.
Собрать юридическую и бухгалтерскую историю ПО. Документы о создании программы, правах и учете продукта лучше готовить как единую систему.
Описать архитектуру и зависимости. Нужно понимать, какие внешние компоненты используются и насколько от них зависит работа продукта.
Проверить автономность. Если ПО предполагается использовать в изолированных контурах, этот сценарий необходимо протестировать и задокументировать.
Подготовить инструкцию для независимой установки. Эксперт должен иметь возможность развернуть экземпляр продукта без участия разработчиков.
Проверить пакет целиком до отправки. Несогласованность между техническими, юридическими и бухгалтерскими документами может привести к дополнительным итерациям.
Использовать поддержку реестра для уточнения спорных требований. В нашем случае разбор конкретной заявки помог быстрее понять причины отказа и подготовить следующий комплект документов.

Какие ошибки при регистрации ПО мы считаем самыми дорогими

Что в итоге дала нам регистрация HConfig

Главный результат для Энсайн оказался шире самой записи в реестре.

Все это пригодилось бы продукту независимо от регистрации.

Частые вопросы о включении ПО в реестр

Что такое реестр российского ПО?

Достаточно ли свидетельства Роспатента для включения программы в реестр?

Проверяется ли техническая часть программы?

Можно ли повторно подать заявление после отказа?

Нужно ли готовить документацию по установке программного обеспечения?

Вывод

3f:T55f3,

Во время аудита одной из систем заказчика мы обнаружили рабочую базу в тестовой среде.

Но рядом существовала еще одна база.

В этом и была проблема.

Почему рабочие данные вообще попадают в тестовую среду

Разработчикам проще проверять систему на настоящей базе.

Поэтому возникает простое решение: сделать копию рабочей базы и развернуть ее на тестовом сервере.

Если эти вопросы заранее не определить, временное решение быстро становится постоянным.

В чем был реальный риск

Проблема была не только в том, что в тестовой среде лежала копия рабочей базы.

Главный риск в другом: эта копия фактически выпала из общего контроля.

Именно поэтому проверка только основной системы дает ложное ощущение порядка.

Почему проблему не нашли раньше

Потому что каждый участник видел только свой участок работы.

Такое расхождение появляется постепенно.

Каждое изменение выглядит локальным. Но вместе они меняют путь данных.

Поэтому аудит нельзя сводить к вопросу: «Все ли документы подготовлены?»

Нужно проверить, соответствует ли описанная схема тому, как компания действительно работает сегодня.

Что проверяется во время аудита ПДн

Во время аудита мы смотрим не только документы и не только основную базу.

Наша задача понять, что в компании реально происходит с персональными данными.

Дальше обычно начинают всплывать детали.

Поэтому аудит должен отвечать на практические вопросы:

Кто имеет доступ?
Где лежат копии?
Можно ли выгрузить базу целиком?
Какие данные видит подрядчик?
Что происходит с информацией после завершения задачи?
Можно ли подтвердить удаление?

После этого уже сравниваем фактическую схему с документами и требованиями по защите ПДн.

Что делать с рабочими данными на тестовом стенде

Лучший вариант: не переносить реальные ПДн в тестовую среду.

На словах все просто. На практике обезличивание тоже нужно проверять.

Поэтому для тестовых копий нужен отдельный порядок:

Определить, какие данные действительно требуются разработчикам.
Удалить поля, без которых можно провести проверку.
Заменить сведения, по которым можно определить пользователя.
Ограничить доступ конкретной командой.
Установить срок существования копии.
Зафиксировать удаление после завершения работ.

Тестовая база редко бывает единственной незаметной копией

После обнаружения тестовой базы важно не останавливаться на одном сервере.

Если данные уже переносили для разработки, стоит проверить, где они могли оказаться еще.

Похожая ситуация возникает и без участия разработчиков.

Если компания проверяет только основную базу, эти участки остаются за пределами контроля.

Когда аудит уже нельзя откладывать

Обычно это видно без сложной диагностики.

Например, компания не может быстро ответить, где хранятся персональные данные клиентов.

Но общей картины нет.

Еще один сигнал: инфраструктура заметно изменилась, а правила работы с ПДн остались прежними.

Каждое такое изменение меняет путь данных.

В такой ситуации вопрос уже не в том, есть ли риск.

Вопрос в том, где он находится и сколько времени компания его не замечает.

Что должно остаться после аудита

Результат аудита не должен выглядеть как общий перечень замечаний на десятках страниц.

Компания должна получить рабочую картину:

где собираются персональные данные;
какие системы участвуют в обработке;
кому и на каком основании передаются сведения;
где находятся неучтенные копии;
кто имеет избыточный или устаревший доступ;
какие меры существуют только в документах;
какие проблемы нужно закрыть в первую очередь.

Отдельно нужен план действий.

Основной риск находится за пределами основной базы

В обнаруженном нами случае никто не пытался обойти защиту.

Именно для этого нужен аудит ПДн.

Защита персональных данных начинается не с уверенности, что основная база настроена правильно.

Она начинается с ответа на более сложный вопрос: где еще находятся эти данные?

Проведем аудит обработки и защиты ПДн

По итогам компания получает перечень обнаруженных рисков и план их устранения с приоритетами.

40:Ta1c2,

Когда бизнес обсуждает запуск нового цифрового продукта, разговор быстро переходит к функциям.

Нужен личный кабинет. Нужна аналитика. Нужны роли пользователей, уведомления, интеграция с CRM, мобильная версия и удобная административная панель.

Проблема в том, что на этом этапе еще никто не доказал, что пользователю нужен сам продукт.

Команда начинает проектировать полноценную систему, хотя главный вопрос остается без ответа: существует ли задача, ради решения которой клиент готов изменить привычный процесс, потратить время и заплатить деньги?

Для этого и нужен MVP.

Минимально жизнеспособный продукт не должен изображать уменьшенную копию будущей платформы. Его задача намного практичнее: проверить критическую гипотезу и дать бизнесу достаточно данных, чтобы принять решение о дальнейших инвестициях.

Если после запуска первой версии команда не понимает, стоит ли продолжать разработку, значит MVP был спроектирован неправильно.

MVP начинается не с идеи продукта

Обычно инициатор проекта приходит с уже сформированным решением.

Например:

«Нам нужна система автоматического формирования коммерческих предложений».

Из этой формулировки сразу появляется будущий функционал: шаблоны документов, каталог товаров, история версий, согласование, выгрузка в PDF, интеграция с CRM.

Но пока это только идея системы.

Чтобы превратить ее в проверяемую гипотезу, нужно вернуться к проблеме пользователя.

Допустим, менеджеры тратят несколько часов на подготовку каждого коммерческого предложения. Они вручную собирают данные из разных источников, копируют старые документы, проверяют цены и отправляют результат на согласование. Из-за этого клиент долго ждет ответ, а в документах появляются ошибки.

Тогда гипотеза может звучать так:

Если менеджер сможет автоматически собрать первый вариант коммерческого предложения на основе данных из CRM и каталога, время подготовки документа сократится, а сотрудники начнут использовать новый инструмент вместо ручного копирования старых файлов.

Теперь понятно, что именно нужно проверить.

Не всю будущую систему. Не десятки функций. Не красоту интерфейса.

Нужно выяснить, сможет ли менеджер получить пригодный результат быстрее привычного способа и станет ли он пользоваться этим сценарием повторно.

Это и есть отправная точка MVP.

Как найти критическую гипотезу

У любого цифрового продукта есть несколько предположений.

Бизнес предполагает, что проблема достаточно серьезная. Что пользователь готов менять привычки. Что сотрудники согласятся работать в новом интерфейсе. Что заказчик предоставит необходимые данные. Что интеграция технически возможна. Что за решение готовы платить.

Проверять все одновременно слишком дорого.

Поэтому сначала нужно найти гипотезу, ошибка в которой делает бессмысленным весь проект.

Представим сервис для автоматического анализа корпоративных документов. Команда может долго обсуждать качество распознавания, скорость обработки и формат отчета.

Но критической гипотезой может оказаться возможность использовать реальные документы.

Если служба безопасности не разрешает передавать информацию во внешний сервис, продукт не получится внедрить независимо от качества алгоритма.

В другом проекте технология может работать без ограничений, но сама проблема окажется недостаточно дорогой. Система экономит сотруднику 10 минут в неделю, а ее внедрение требует интеграций, обучения и постоянной поддержки. Польза есть, но экономика не сходится.

Критическую гипотезу стоит искать там, где пересекаются четыре фактора:

реальная боль пользователя;
готовность изменить текущее поведение;
возможность технической реализации;
экономический смысл для заказчика.

Это не значит, что под каждую гипотезу нужно проводить отдельный многомесячный проект. Наоборот, хороший MVP сводит проверку к одному сценарию, в котором проявляются основные риски.

Не спрашивайте пользователей, нравится ли им идея

Перед разработкой нужно поговорить с людьми, для которых создается продукт.

Но интервью тоже легко превратить в формальность.

Пользователю показывают презентацию и спрашивают:

«Стали бы вы пользоваться такой системой?»

Чаще всего человек отвечает положительно. Идея выглядит разумной, собеседник не хочет спорить, а будущий продукт пока ничего от него не требует.

Такие ответы почти бесполезны.

Гораздо важнее обсуждать не предполагаемое будущее, а реальное прошлое.

Когда проблема возникала в последний раз? Как человек ее решал? Какие инструменты использовал? Сколько времени занял процесс? Кто участвовал в согласовании? Что произошло из-за ошибки или задержки? Платит ли компания за существующее решение?

Фактическое поведение надежнее заявленного интереса.

Если сотрудник говорит, что проблема критична, но годами решает ее вручную и не пытается ничего изменить, это важный сигнал. Возможно, неудобство существует, но его цена слишком мала для покупки отдельного продукта.

Для корпоративных систем важно разговаривать не только с будущим пользователем.

У проекта почти всегда несколько участников:

сотрудник выполняет операцию;
руководитель отвечает за результат;
ИТ-служба оценивает интеграции;
безопасность определяет ограничения;
финансовый руководитель согласует бюджет;
владелец процесса принимает решение о внедрении.

Продукт может понравиться пользователю, но не пройти требования безопасности. Или технически работать, но не дать эффекта, за который готов платить владелец процесса.

Поэтому на этапе исследования нужно понять не только пользовательскую боль, но и механизм принятия решения внутри компании.

Зафиксируйте критерий успеха до разработки

Один из главных вопросов MVP звучит просто:

Какой результат убедит нас продолжить инвестиции?

Ответ нужно получить до начала разработки.

Иначе после запуска команда будет подстраивать трактовку под фактические цифры.

Сто регистраций можно назвать успехом. Но если никто не завершил основной сценарий, продукт не доказал свою ценность.

Несколько пользователей могут выглядеть слишком маленькой выборкой. Но если три компании согласились провести платный пилот, это сильный результат для сложного корпоративного решения.

Критерий зависит от проверяемой гипотезы.

Если бизнес проверяет наличие спроса, результатом могут быть заявки на пилот.

Если проверяется удобство сценария, нужно измерять долю пользователей, которые дошли до результата без помощи команды.

Если проверяется ценность продукта, важны повторное использование и готовность вернуться.

Если проверяется бизнес-модель, главным сигналом становится оплата или готовность подписать договор.

Хороший критерий должен быть измеримым и заранее ограниченным по времени.

Например:

Мы считаем гипотезу подтвержденной, если за месяц не менее пяти компаний согласятся предоставить данные для пилота, а минимум две будут готовы продолжить работу на коммерческих условиях.

Это гораздо полезнее формулировки «посмотрим, будет ли интерес».

MVP не всегда требует полноценной разработки

Минимально жизнеспособный продукт часто путают с первой версией приложения.

Но проверять гипотезу можно разными способами.

Если нужно понять, существует ли интерес к проблеме, иногда достаточно посадочной страницы и формы заявки.

Если нужно проверить понятность интерфейса, подойдет интерактивный прототип.

Если важно убедиться в ценности результата, услугу на первом этапе можно частично выполнять вручную.

Представим сервис, который должен анализировать техническую документацию и находить ошибки. Вместо разработки сложной платформы компания может запустить простую форму загрузки файлов. Пользователь передает документ, специалист выполняет анализ вручную, а клиент получает отчет в заранее подготовленном формате.

Внешне процесс уже похож на будущий продукт. Внутри пока нет полной автоматизации.

Такой подход позволяет проверить важные вещи:

готовы ли пользователи передавать документы;
какие ошибки они считают критичными;
насколько ценен итоговый отчет;
готовы ли они платить;
как часто возникает потребность.

Если спрос подтвердится, ручные операции можно автоматизировать.

Полноценное приложение нужно тогда, когда без него нельзя проверить основную гипотезу.

Например, если ценность продукта основана на скорости обработки, работе без подключения к интернету, совместной работе большого числа пользователей или глубокой интеграции с оборудованием, ручная имитация даст искаженный результат.

Формат MVP должен определяться не амбициями команды, а вопросом, на который нужно получить ответ.

Соберите один законченный сценарий

Когда проект доходит до функциональности, команда обычно пытается включить в MVP как можно больше.

Логика понятна: раз разработка уже началась, хочется сразу сделать основу будущего продукта.

В результате первая версия быстро обрастает ролями, настройками, уведомлениями, отчетами, фильтрами и дополнительными разделами. Срок увеличивается, а критическая гипотеза остается размытой.

Рабочий MVP строится вокруг одного законченного пользовательского сценария.

У пользователя возникает задача. Он входит в систему, передает необходимые данные, получает результат и понимает, что делать дальше.

Например:

сотрудник загружает договор, система анализирует документ, выделяет рискованные условия и формирует отчет.

Или:

менеджер выбирает клиента, система получает данные из CRM, формирует коммерческое предложение и передает его на согласование.

В первой версии не обязательно создавать гибкий конструктор отчетов, сложную систему ролей и десятки вариантов экспорта.

Но основной путь должен работать от начала до конца.

Пользователь не должен столкнуться с красивым интерфейсом, который заканчивается сообщением «функция появится позже» в момент получения результата.

Минимальность относится к количеству сценариев. Жизнеспособность означает, что выбранный сценарий действительно завершен.

«В проектах мы часто видим одну и ту же ошибку: MVP пытаются сделать как дешевую копию будущей системы. В итоге функций мало, но главный риск так и не проверен. Я бы смотрел иначе: первая версия должна не впечатлять количеством возможностей, а дать бизнесу честный ответ — стоит ли вкладывать следующие миллионы в этот продукт», — Алексей Постригайло, старший партнер ИТ-⁠интегратора «Энсайн».

Где заканчивается минимальный продукт и начинается технический долг

У MVP есть неприятная крайность.

Иногда ради скорости из проекта убирают все, что не видно пользователю: аналитику, журналирование, управление доступом, резервное копирование и контроль ошибок.

Внешне продукт работает. Но команда не понимает, что происходит внутри.

Нельзя увидеть, на каком шаге уходят пользователи. Нельзя восстановить причины сбоя. Нельзя определить, кто получил доступ к данным. Любое изменение выполняется непосредственно в рабочей среде.

Это уже не экономия, а потеря управляемости.

Даже минимальный продукт должен давать команде возможность наблюдать за его работой и безопасно проводить эксперимент.

На первом этапе обычно необходимы:

фиксация ключевых действий пользователя;
журнал ошибок;
разграничение доступа;
безопасное хранение паролей и ключей;
резервное копирование критичных данных;
тестовая среда;
возможность быстро отключить проблемную функцию.

Особенно важно это для корпоративных продуктов.

Если MVP подключается к CRM, ERP, личному кабинету или внутреннему хранилищу документов, он становится частью существующего ИТ-ландшафта. Ошибка в таком продукте может затронуть не только тестовую группу, но и рабочие процессы компании.

Мы часто видим, что бизнес недооценивает именно эту часть проекта. Снаружи MVP может состоять из нескольких экранов. Внутри ему уже нужны интеграции, права доступа, обмен данными, обработка ошибок и контроль состояния внешних систем.

Поэтому объем первой версии нельзя оценивать только по количеству страниц.

Не создавайте архитектуру на десять лет вперед

У другой крайности обратная проблема.

Команда боится будущего роста и сразу проектирует сложную архитектуру: микросервисы, несколько контуров, универсальную систему ролей, масштабирование под миллионы пользователей.

При этом продуктом пока пользуются десять человек.

Такой подход увеличивает стоимость эксперимента и замедляет получение обратной связи.

Архитектура MVP должна выдерживать пилот и ближайший понятный этап развития. Не воображаемый масштаб через пять лет.

Но это не означает, что можно полностью игнорировать будущее.

Есть решения, которые создают технический тупик уже на старте:

данные хранятся в формате, который нельзя перенести;
бизнес-логика жестко связана с конкретным конструктором;
отсутствует разделение между интерфейсом и интеграциями;
изменения невозможно тестировать отдельно;
нет документации по обмену данными;
ключевые процессы зависят от ручных действий одного человека.

Задача интегратора на этапе MVP не построить окончательную архитектуру, а сохранить возможность развивать систему после подтверждения гипотезы.

Для этого нужно заранее понимать, какие части первой версии можно заменить, а какие станут основой будущего продукта.

Как провести пилот

Когда первый сценарий готов, появляется соблазн сразу открыть продукт широкой аудитории.

Для MVP это редко полезно.

На раннем этапе важнее глубина наблюдения, а не объем трафика.

В корпоративном проекте пилот можно провести на одном подразделении, одной группе сотрудников или нескольких компаниях. Главное, чтобы участники действительно сталкивались с проверяемой проблемой.

Пользователю нужно дать реальную задачу, а не попросить «посмотреть интерфейс».

Если продукт автоматизирует согласование документов, участники должны провести через него настоящий документ.

Если система помогает подбирать оборудование, нужно использовать реальные параметры и ограничения.

Если сервис формирует отчет, результат должен быть нужен пользователю в текущей работе.

Иначе команда проверит не продукт, а способность человека пройти демонстрационный сценарий.

Во время пилота нужно наблюдать не только за итоговыми показателями.

Важно видеть, где пользователь остановился, что понял неправильно, какие данные не смог найти и в какой момент попросил помощи.

Хороший пилот почти всегда содержит ручную поддержку. Это нормально.

Проблема возникает, когда команда не учитывает ее объем.

Если каждому пользователю приходится вручную исправлять данные, объяснять половину интерфейса и запускать обработку из административной панели, продукт пока не готов к масштабированию.

Даже если клиент доволен результатом.

Что измерять после запуска MVP

Метрики должны быть связаны с критической гипотезой.

Просмотры, регистрации и время на сайте могут быть полезны, но сами по себе не доказывают ценность продукта.

Если основной сценарий заключается в формировании документа, нужно измерять, сколько пользователей создали документ до конца.

Если продукт должен использоваться регулярно, важно повторное использование.

Если решение обещает экономить время, нужно сравнивать длительность процесса до и после внедрения.

Для корпоративного MVP мы бы смотрели на четыре группы показателей.

Первая группа показывает, смог ли пользователь получить результат:

завершение ключевого сценария;
время до первого полезного результата;
количество ошибок;
необходимость помощи.

Вторая группа отражает реальную ценность:

повторное использование;
готовность передать продукт коллегам;
отказ от старого способа работы;
снижение времени или количества ручных операций.

Третья группа связана с бизнесом:

готовность продолжать пилот;
запрос коммерческого предложения;
согласованный бюджет;
фактическая оплата.

Четвертая показывает стоимость эксплуатации:

объем ручной поддержки;
количество нестандартных ситуаций;
затраты на обработку одного пользователя;
нагрузка на интеграции и инфраструктуру.

Последняя группа особенно важна. Продукт может нравиться пользователям, но оказаться экономически невыгодным из-за большого количества скрытых ручных операций.

Как принять решение после пилота

После MVP команда должна принять одно из четырех решений.

Первое: развивать продукт.

Такое решение оправдано, если критическая гипотеза подтверждена, пользователи получают ценность, а основные технические ограничения понятны.

Второе: изменить направление.

Проблема может существовать, но выбранный сценарий не подходит. Возможно, продукт ориентирован не на ту аудиторию, требует слишком много действий или решает второстепенную часть процесса.

В этом случае не обязательно закрывать проект. Но следующая версия должна проверять новую гипотезу, а не просто содержать больше функций.

Третье: повторить эксперимент.

Иногда данных действительно недостаточно. Например, пилот попал на период низкой активности или в нем участвовали сотрудники, которые редко сталкиваются с задачей.

Повторять эксперимент стоит только тогда, когда понятно, почему первый результат нельзя считать достоверным.

Четвертое: остановить проект.

Это нормальный исход MVP.

Если пользователи не видят достаточной ценности, экономика не сходится или внедрение требует несоразмерных затрат, продолжать разработку только потому, что уже вложены деньги, не имеет смысла.

Успех MVP заключается не в обязательном переходе к полноценному продукту.

Успех заключается в том, что решение принято раньше, чем компания потратила основной бюджет.

Что изменилось с появлением ИИ-инструментов

Современные средства разработки позволяют быстрее собирать интерфейсы, подключать базы данных, создавать серверную логику и развертывать приложения.

Для MVP это полезно.

Команда может провести эксперимент быстрее и дешевле. Можно сравнить несколько интерфейсных решений, собрать работающую демонстрацию и проверить сценарий без длительной разработки базовой инфраструктуры.

Но ИИ не отменяет продуктовую работу.

Он не определит за бизнес, какая проблема действительно важна. Не договорится со службой безопасности. Не убедит сотрудников изменить привычный процесс. Не подтвердит готовность клиента платить.

Более того, высокая скорость разработки создает новый риск.

Команда может за несколько недель собрать продукт, который раньше потребовал бы несколько месяцев. Но если гипотеза выбрана неправильно, компания просто быстрее получит ненужную систему.

Поэтому главный эффект ИИ для MVP заключается не в возможности сделать больше.

Он позволяет дешевле проверять предположения.

И именно так его стоит использовать.

Рабочая схема запуска MVP

Если свести весь процесс к одной последовательности, она будет выглядеть так.

Сначала бизнес формулирует проблему конкретной аудитории и изучает, как она решается сейчас.

Затем команда выбирает предположение, ошибка в котором разрушает весь проект, и заранее определяет критерий успеха.

После этого выбирается минимальный формат проверки. Это может быть прототип, ручная услуга, ограниченный цифровой сервис или полноценный пилотный контур.

Если необходима разработка, команда собирает один законченный сценарий и добавляет минимальную эксплуатационную основу: аналитику, контроль доступа, журналирование и управление ошибками.

Продукт запускается на ограниченной аудитории с реальными задачами и данными.

После пилота команда сравнивает результат с критериями, оценивает объем ручной поддержки и принимает решение: развивать продукт, менять гипотезу, повторять эксперимент или остановить проект.

В этой схеме нет ничего эффектного.

Зато она защищает бизнес от ситуации, когда полноценная система уже разработана, интеграции оплачены, а вопрос о реальной ценности продукта только начинают обсуждать.

Главное

MVP нужен не для того, чтобы показать первую версию продукта.

Он нужен, чтобы принять решение о следующей инвестиции.

Поэтому начинать стоит не с перечня функций и не с выбора технологии.

Сначала нужно определить, какое предположение бизнес хочет проверить, какой результат будет считаться подтверждением и какой минимальный сценарий способен дать достоверный ответ.

Все остальное появляется после.

Если критическая гипотеза подтверждается, у компании есть основания инвестировать в архитектуру, интеграции, безопасность и масштабирование.

Если не подтверждается, проект можно изменить или остановить до того, как он станет дорогим.

Именно в этом заключается ценность правильно спроектированного MVP.

41:T265d,

Автоматизация процессов разработки и развертывания

Интеграция безопасности (DevSecOps)

Что это даёт:

Раннее обнаружение уязвимостей. Вы не ждете, пока проблема возникнет в продуктивной среде. Проверки безопасности происходят на каждом этапе.
Меньше рисков. Автоматические тесты и проверки помогают минимизировать угрозы безопасности до того, как они станут проблемой.

«Если безопасность не встроена в процесс с самого начала, её исправление на финальных этапах разработки может быть слишком поздно», — Вадим Зимин, руководитель отдела разработки, Энсайн.

Мониторинг и обратная связь

Сотрудничество команд разработки и эксплуатации

Это даёт:

Быструю реакцию на возникающие проблемы.
Прозрачность процессов, потому что все участники видят, как их работа влияет на остальных.
Скорость принятия решения. Команды совместно устраняют проблемы и ускоряют развертывание обновлений.

Эволюция DevOps: новые тренды и подходы

Роль DevOps в ускорении обновлений и укреплении безопасности систем

Например:

GitOps: Использование Git как единого источника правды для всех конфигураций и процессов развертывания. Это позволяет еще больше автоматизировать процессы и сделать их более прозрачными.
Инфраструктура как код (IaC): Инструменты для управления инфраструктурой через код делают настройку и масштабирование более гибкими и быстрыми. Это особенно важно для динамично развивающихся проектов, где нужно быстро адаптироваться.
Контейнеризация: Эти технологии позволяют масштабировать приложения и управлять ими, улучшая производительность и снижая риски при развертывании.
ML для мониторинга: Использование машинного обучения для предсказания сбоев и угроз. Такие подходы помогают на предсказуемо высокой скорости устранять проблемы, не допуская их перерастания в инциденты.

Постоянное улучшение

Подведем итоги

42:T3e0b,

Угроза редко приходит с одной стороны

Риски удобно делить на внешние и внутренние. Но на практике этого мало.

Внешние источники угроз: не только кража данных

Обычно бьют по 4 зонам.

Публичные сервисы. Сайты, API, личные кабинеты, мобильные backend-контуры, интеграционные шлюзы. Все, что доступно извне, становится мишенью для перебора, сканирования и эксплуатации старых уязвимостей.
Рабочая среда сотрудников. Почта, браузеры, мессенджеры, удаленный доступ, ноутбуки, телефоны. Здесь проще сыграть не на технологии, а на привычке и невнимательности.
Инфраструктура. Серверы, сетевое оборудование, облачные ресурсы, хранилища, резервные каналы, внешние сервисы аутентификации. Слабое место здесь открывает путь дальше по контуру.
Физический слой. Кража устройства, доступ в офис, подмена оборудования, подключение к внутренней сети без контроля. Это менее заметный, но вполне рабочий сценарий.

Внутренние источники угроз опаснее, чем кажутся

Природа и источники информационных угроз

У внутренних угроз есть 3 типовых сценария.

Злой умысел. Сотрудник копирует базу перед уходом. Подрядчик выносит данные. Пользователь сознательно передает доступ.
Ошибка. Документ уходит не туда. Доступ выдают не той роли. Тестовую выгрузку делают на боевых данных. Конфигурацию меняют без понимания последствий.
Слабая среда. Человек не делает ничего намеренно опасного, но работает в системе, где уже нет нормальных ограничений: общие учетные записи, лишние привилегии, отсутствие журналирования, слабая сегментация, формальные регламенты.

«Самый дорогой инцидент обычно начинается не с хитрой атаки, а с простого вопроса: у кого был доступ, зачем он был нужен и почему никто давно это не пересматривал,» — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Для бизнеса важнее не тип атаки, а то, что именно он теряет

С точки зрения бизнеса все угрозы в итоге бьют по 3 вещам: доступности, целостности и конфиденциальности.

Потеря доступности

Потеря целостности

Потеря конфиденциальности

Активные и пассивные угрозы: заметные и тихие

Самые частые мишени — конкретные активы

Чтобы защищаться, мало знать список угроз. Нужно понимать, что именно является активом в вашем контуре.

Обычно в зоне риска находятся:

клиентские и партнерские базы;
учетные системы;
корпоративная почта;
внутренние порталы и личные кабинеты;
файловые хранилища;
серверы приложений и баз данных;
сетевой контур;
резервные копии;
учетные записи с повышенными правами;
интеграционные каналы между системами;
устройства сотрудников.

Где бизнес чаще всего ошибается при оценке угроз

Есть 5 типовых ошибок.

1. Считать главным риском только внешний взлом

2. Смотреть на безопасность отдельно от архитектуры

3. Плохо знать свои активы

4. Не пересматривать накопленные доступы

5. Не считать стоимость простоя и искажения данных

Подведем итоги

43:Ta95d,

Защиту сайта часто сводят к одному решению. Подключают WAF, устанавливают антивирус, обновляют CMS или настраивают резервное копирование. Каждая из этих мер полезна. Но ни одна из них не закрывает все возможные сценарии атаки.

WAF может заблокировать вредоносный запрос, но не исправит ошибку в правах доступа. Многофакторная аутентификация защитит учетную запись, но не остановит атаку через уязвимую библиотеку. Резервная копия поможет вернуть данные, но не устранит причину взлома.

Поэтому защита сайта должна состоять из семи независимых уровней:

Учетные записи и права доступа.
Код, CMS и API.
Управление обновлениями.
Сервер и внешний периметр.
Зависимости и процесс развертывания.
Мониторинг и обнаружение атак.
Резервное копирование и восстановление.

Главный принцип такой: если один уровень не сработал, остальные должны остановить атаку, ограничить ущерб и позволить быстро восстановить работу.

Именно способность системы выдержать отказ одного из уровней показывает, насколько сайт действительно защищен.

Содержание:

Почему одного средства защиты недостаточно

Как защита сайта «Энсайн» выдержала DDoS-атаку мощностью почти 110 Гбит/с

Семь уровней защиты сайта

Как уровни защиты подстраховывают друг друга

Чек-лист семи уровней защиты

Почему слабые места не всегда видны

Вывод

Почему одного средства защиты недостаточно

Современный сайт редко существует отдельно от других систем компании.

Даже обычный корпоративный ресурс может быть связан с CRM, почтовыми сервисами, системой аналитики, формами обратной связи и административной панелью. Интернет-магазин дополнительно работает с оплатой, доставкой, складом и программой лояльности. Личный кабинет обращается к внутренним базам, документам и сервисам авторизации.

К этому добавляется инфраструктура разработки:

репозитории;
сторонние библиотеки;
системы автоматической сборки;
облачные сервисы;
тестовые серверы;
учетные записи разработчиков;
ключи и токены интеграций.

Злоумышленнику необязательно атаковать главную страницу. Он ищет самое слабое место во всей цепочке.

Такой точкой входа может стать старый плагин, забытый поддомен, украденный пароль, тестовый сервер, ошибка в API или зараженная зависимость.

Если защита построена вокруг одного продукта, обход этого продукта открывает путь дальше. В многоуровневой системе каждая мера решает свою задачу и подстраховывает соседние.

Как защита сайта «Энсайн» выдержала DDoS-атаку мощностью почти 110 Гбит/с

Один из самых показательных случаев в работе нашего системного администратора Вадима Зимина прошел внутри компании почти незаметно.

Именно так и выглядит хорошо подготовленная инфраструктура.

Речь идет о корпоративном сайте «Энсайн». Для ИТ-интегратора устойчивость собственных ресурсов напрямую связана с профессиональной репутацией. Мы предъявляем к своей инфраструктуре те же требования, что и к системам заказчиков.

Вадим заранее подключил сайт к внешней системе фильтрации DDoS-трафика. Задача была конкретной: ресурс должен оставаться доступным даже во время атаки.

Позже это решение прошло проверку в реальных условиях.

Атака продолжалась около 10 минут. В пике ее мощность достигала почти 110 Гбит/с, а интенсивность составляла около 9,5 млн пакетов в секунду.

Без защиты сайт бы просто лег. Атака пришлась как раз на рекламную кампанию, на которую уже потратили серьезный бюджет. И проблема была бы не только в потерянных заявках. Мы запускали рекламу, чтобы проверить конкретную гипотезу, а при недоступном сайте нормальных данных уже не получить. Пришлось бы восстанавливать ресурс, а потом заново оплачивать и запускать кампанию. То есть расходы по сути выросли бы в 2 раза.

В итоге ничего этого не произошло. Сайт продолжал работать, заявки поступали, рекламную кампанию останавливать не пришлось. О самой атаке мы узнали уже после, когда посмотрели технический отчет.

«Сильная работа системного администратора часто остается за кадром. Вадим заранее подготовил защиту, и атака мощностью почти 110 Гбит/с прошла без недоступности сайта», — говорит Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

В этом случае сработали два уровня.

Защита внешнего периметра отфильтровала вредоносный трафик до того, как он перегрузил канал. Мониторинг позволил зафиксировать параметры атаки и убедиться, что инфраструктура отработала штатно.

Остальные уровни не пришлось задействовать. Но при другой точке входа результат зависел бы уже от безопасности приложения, защиты учетных записей или возможности быстро восстановить систему.

Этот случай показывает главный принцип: необходимые меры нужно внедрять до инцидента. Когда сайт уже находится под атакой, времени на выбор решения, изменение DNS и проверку конфигурации обычно нет.

Семь уровней защиты сайта

Уровень 1. Учетные записи и права доступа

Многие атаки начинаются не с технической уязвимости, а с обычного входа под настоящей учетной записью.

Злоумышленник может получить пароль из старой утечки, подобрать его, перехватить через фишинговую страницу или воспользоваться доступом бывшего сотрудника.

Под угрозой находятся не только учетные записи CMS. В единую систему доступа входят:

панель хостинга;
DNS;
CDN;
репозиторий;
система развертывания;
облачная инфраструктура;
база данных;
резервные копии;
административные интерфейсы.

Если одна учетная запись открывает доступ сразу к нескольким системам, ее компрометация становится критической.

Что должно быть настроено

Для всех привилегированных учетных записей нужна многофакторная аутентификация.

У каждого сотрудника должен быть собственный доступ. Общие логины мешают определить, кто выполнил действие, и затрудняют отзыв прав.

Доступы нужно выдавать по принципу минимальной достаточности. Редактору не нужен вход на сервер. Разработчику не всегда требуется постоянный доступ к рабочей среде. Интеграция не должна подключаться к базе данных с правами администратора.

Список пользователей и их полномочий нужно регулярно пересматривать. Доступы бывших сотрудников и подрядчиков следует отзывать сразу после завершения работы.

Что произойдет при отказе уровня

Если пароль все же украден, ограниченные права не позволят атакующему сразу получить контроль над всей инфраструктурой. Мониторинг должен заметить необычный вход или изменение настроек. Резервная копия поможет вернуть поврежденные данные.

Основные ответственные: владелец системы и системный администратор.

Уровень 2. Код, CMS и API

Второй уровень защищает от ошибок самого приложения.

К этой группе относятся:

неправильная проверка прав;
небезопасная работа с базой данных;
ошибки при загрузке файлов;
слабое восстановление пароля;
выдача лишних данных через API;
возможность массового перебора;
выполнение команд на сервере;
раскрытие технической информации.

Одна из наиболее опасных проблем возникает, когда пользователь успешно входит в систему, но может получить доступ к чужим данным.

Предположим, документ открывается по адресу:

/api/documents/1256

Если сервер проверяет только наличие активной сессии, но не проверяет принадлежность документа, достаточно изменить номер в запросе.

Так можно получить доступ к чужим заказам, договорам, счетам или внутренним документам.

Сложный адрес не является защитой. Права необходимо проверять при каждом обращении к объекту.

Что должно быть настроено

Приложение должно контролировать:

входящие данные;
права на каждый объект и действие;
тип и размер загружаемых файлов;
количество запросов;
содержимое ответов API;
создание и завершение сессий;
восстановление доступа;
обработку ошибок.

Готовая CMS не снимает эту задачу. Безопасность зависит от версии платформы, установленных модулей, настроек и качества доработок.

Что произойдет при отказе уровня

Если в приложении появилась уязвимость, часть атак может остановить WAF. Сегментация ограничит доступ к внутренним системам. Мониторинг покажет необычные запросы. Резервная копия поможет вернуть систему, если данные были повреждены.

Основные ответственные: технический руководитель и разработчики.

Уровень 3. Управление обновлениями

Наличие исправления не защищает сайт, пока оно не установлено.

После публикации информации об уязвимости злоумышленники начинают искать системы, в которых продолжает работать старая версия. Чем дольше компания откладывает обновление, тем шире становится окно для атаки.

Для управления этим риском нужно знать точные версии:

CMS;
плагинов;
фреймворков;
библиотек;
серверного ПО;
базы данных;
операционной системы;
контейнеров.

Если единого списка нет, компания не сможет быстро определить, относится ли новая уязвимость к ее инфраструктуре.

Что должно быть настроено

Для обычных обновлений нужен плановый график. Для критических уязвимостей требуется отдельный ускоренный процесс:

Получить информацию об уязвимости.
Проверить, используется ли компонент.
Оценить возможность эксплуатации.
Подготовить резервную копию.
Проверить исправление.
Установить обновление.
Проанализировать журналы.
Убедиться, что уязвимость не использовали раньше.

Если компонент нельзя обновить сразу, часть атак можно временно блокировать через WAF или сетевые правила. Но это только временная компенсация.

Пока уязвимый компонент остается в системе, риск не устранен.

Что произойдет при отказе уровня

Если исправление не было установлено вовремя, внешний периметр может остановить известный способ эксплуатации. Мониторинг поможет обнаружить попытки атаки. Изоляция приложения ограничит возможное распространение.

Основная ответственная сторона: команда сопровождения.

Уровень 4. Сервер и внешний периметр

Этот уровень принимает на себя атаки до того, как они достигнут приложения или внутренней инфраструктуры.

В него входят:

CDN;
защита от сетевых DDoS;
защита от прикладных DDoS;
WAF;
ограничение частоты запросов;
фильтрация автоматического трафика;
защита DNS;
сегментация сети;
ограничения доступа к служебным панелям.

Сетевая DDoS-атака пытается перегрузить канал или оборудование. Прикладная атака действует иначе. Она имитирует действия обычного пользователя и обращается к наиболее тяжелым функциям:

поиску;
фильтрам;
авторизации;
расчету стоимости;
формированию документов;
оформлению заказа;
внешним интеграциям.

Иногда для перегрузки приложения не нужен огромный объем трафика. Достаточно регулярно вызывать одну ресурсоемкую операцию.

Что должно быть настроено

Базы данных, служебные панели и внутренние сервисы не должны быть доступны из интернета без необходимости.

Административные интерфейсы можно ограничить через VPN, доверенные адреса или отдельную систему доступа.

Во внешний периметр также входят тестовые среды, старые поддомены и временные серверы. После завершения проекта о них часто забывают, хотя они продолжают оставаться доступными.

Что произойдет при отказе уровня

Если вредоносный трафик все же достиг приложения, ограничения количества запросов, кеширование и очереди должны снизить нагрузку. Мониторинг покажет развитие атаки. План восстановления позволит действовать без хаоса, если часть инфраструктуры перестала отвечать.

Основные ответственные: системный администратор или DevOps-команда.

Уровень 5. Зависимости и процесс развертывания

Современный сайт состоит не только из кода, который написала команда проекта.

Он использует сторонние библиотеки, пакеты, контейнеры и инструменты сборки. Даже небольшой сервис может включать сотни компонентов.

Если один популярный пакет был скомпрометирован, вредоносный код может попасть сразу во множество проектов.

Отдельный риск создает система автоматической сборки и развертывания. Обычно она имеет доступ:

к исходному коду;
рабочим серверам;
облачной инфраструктуре;
контейнерам;
ключам;
токенам;
внутренним сетям.

Получив контроль над системой сборки, злоумышленник может внедрить изменения в рабочую среду через штатный процесс публикации.

Что должно быть настроено

Необходимо контролировать:

список зависимостей;
точные версии;
происхождение пакетов;
известные уязвимости;
сценарии установки;
права системы сборки;
доступ к секретам;
состав итогового артефакта.

Версии библиотек нужно фиксировать. Новые компоненты должны проходить проверку. Сборки из недоверенных веток не должны иметь доступ к рабочим ключам и серверам.

В рабочую среду следует разворачивать только проверенный артефакт, происхождение которого можно подтвердить.

Что произойдет при отказе уровня

Если зараженный компонент попал в сборку, ограниченные права токенов сократят возможный ущерб. Сегментация не позволит приложению свободно обращаться ко внутренним системам. Мониторинг может обнаружить необычные соединения. Проверенный артефакт даст возможность вернуться к доверенной версии.

Основные ответственные: разработчики, DevOps и технический руководитель.

Уровень 6. Мониторинг и обнаружение атак

Даже хорошо защищенную систему могут атаковать.

Поэтому важно не только предотвращать инциденты, но и быстро замечать подозрительную активность.

Без мониторинга злоумышленник может находиться в инфраструктуре несколько дней или месяцев. Он будет изучать систему, расширять права, собирать данные и готовить следующую стадию атаки.

Что должно отслеживаться

В зоне контроля должны находиться:

создание новых администраторов;
изменение ролей;
массовые неудачные входы;
авторизация из необычных мест;
изменение системных файлов;
установка новых модулей;
изменение DNS;
необычные запросы к API;
массовые выгрузки;
рост ошибок;
аномальная нагрузка;
новые исходящие соединения.

Журналы желательно хранить отдельно от сайта. Иначе атакующий сможет удалить их вместе со следами проникновения.

Важно определить не только список уведомлений, но и человека, который на них реагирует. Сотни непрочитанных сообщений не создают защиту.

Что произойдет при отказе уровня

Если атаку обнаружили поздно, сегментация, ограниченные права и изоляция резервных копий должны сократить масштаб последствий. Но чем дольше злоумышленник остается незамеченным, тем сложнее определить точку входа и восстановить доверенное состояние системы.

Основные ответственные: эксплуатация и информационная безопасность.

Уровень 7. Резервное копирование и восстановление

Последний уровень нужен на случай, если атака прошла через остальные меры.

Резервная копия должна быть:

регулярной;
автоматической;
зашифрованной;
изолированной от основной инфраструктуры;
защищенной отдельной учетной записью;
проверенной на восстановление.

Копия, которую никто не пытался восстановить, не гарантирует возвращение системы в работу.

Что должно быть известно заранее

Компания должна понимать:

сколько времени займет восстановление;
какой объем данных допустимо потерять;
где находится доверенная копия;
кто принимает решение о восстановлении;
как проверить возвращенную систему;
как убедиться, что точка входа закрыта.

Простого возврата старой версии недостаточно. Если причина взлома не устранена, атака повторится.

Поэтому восстановление работает вместе с обновлениями, мониторингом и контролем процесса разработки.

Что произойдет при отказе уровня

Если резервные копии повреждены или недоступны, остальные меры должны не допустить полного разрушения системы. Ограниченные права, сегментация и своевременное обнаружение уменьшают вероятность того, что атакующий доберется до всех данных и копий.

Основные ответственные: системный администратор и владелец системы.

Как уровни защиты подстраховывают друг друга

Семь уровней не работают по очереди. Они действуют одновременно.

Если не сработал	Возможное последствие	Что ограничивает ущерб
Защита учетной записи	Атакующий входит под администратором	Ограниченные права, мониторинг, восстановление
Безопасность приложения	Используется ошибка в коде или API	WAF, сегментация, журналы
Управление обновлениями	Эксплуатируется известная уязвимость	WAF, мониторинг, изоляция
Внешний периметр	Вредоносный трафик достигает приложения	Лимиты, кеширование, очереди
Контроль зависимостей	В сборку попадает вредоносный пакет	Минимальные права, мониторинг, доверенная сборка
Мониторинг	Атака обнаруживается с задержкой	Сегментация и ограниченные права
Восстановление	Систему нельзя быстро вернуть в работу	Остальные уровни должны ограничить разрушение

Защищенным можно считать не сайт, в котором никогда не происходит ошибок, а систему, где одна ошибка не приводит к полной компрометации.

Чек-лист семи уровней защиты

Для каждого пункта выберите один ответ:

да;
нет;
не знаю.

Ответ «не знаю» означает, что состояние защиты не подтверждено.

Уровень 1. Учетные записи

Для CMS, хостинга, DNS и репозитория включена многофакторная аутентификация.
У каждого сотрудника есть собственная учетная запись с ограниченными правами.
Доступы бывших сотрудников и подрядчиков отключены.

Уровень 2. Код, CMS и API

Права проверяются при каждом обращении к документу или объекту.
CMS, модули и API проходят регулярную проверку безопасности.
Загрузка файлов и восстановление доступа защищены от злоупотреблений.

Уровень 3. Обновления

Составлен список используемых платформ и их версий.
Компания получает уведомления о критических уязвимостях.
Для срочных обновлений существует отдельный процесс.

Уровень 4. Внешний периметр

Перед сайтом настроены WAF и защита от DDoS.
Базы данных и служебные панели не открыты в интернет.
Тестовые среды, старые поддомены и сетевые сервисы учтены.

Уровень 5. Зависимости и развертывание

Версии библиотек зафиксированы и проверяются на известные уязвимости.
Недоверенные сборки не имеют доступа к рабочим секретам.
В рабочую среду попадают только проверенные артефакты.

Уровень 6. Мониторинг

Журналы собираются централизованно и хранятся отдельно от сайта.
Настроены уведомления об изменении прав, файлов и конфигурации.
Определен сотрудник, который реагирует на предупреждения.

Уровень 7. Восстановление

Резервные копии создаются автоматически и хранятся отдельно.
Доступ к копиям защищен отдельной учетной записью.
Восстановление проверялось на практике.

Если по трем или более пунктам выбран ответ «не знаю», состояние системы нельзя считать подтвержденным.

Это не означает, что сайт уже взломан. Это означает, что компания пока не располагает данными, которые подтверждают работу всех уровней.

Почему слабые места не всегда видны

Сайт может работать стабильно и внешне не показывать никаких проблем.

При этом в системе могут оставаться:

устаревшие библиотеки;
открытые сетевые сервисы;
забытые поддомены;
небезопасные настройки сервера;
лишние точки входа;
компоненты с известными уязвимостями.

Обычная эксплуатация не отвечает на вопрос, можно ли использовать эти слабые места для атаки.

Чек-лист показывает, какие процессы и меры должны существовать. Но он не подтверждает, что конкретные версии компонентов безопасны, а внешний периметр настроен правильно.

Для технической проверки применяют сканирование систем на наличие уязвимостей.

Оно помогает перейти от предположения «сайт должен быть защищен» к конкретному списку обнаруженных проблем, которые нужно проверить и расставить по приоритету.

Вывод

Защита сайта не строится вокруг одного продукта.

WAF не заменяет безопасный код. Обновление не защищает украденную учетную запись. Мониторинг не исправляет уязвимость. Резервная копия не предотвращает повторный взлом.

Поэтому рабочая система состоит из семи независимых уровней. Если один уровень не сработает, остальные должны остановить атаку, ограничить ущерб и позволить быстро вернуть систему в работу.

Следующий вопрос заключается в том, как проверить, где эта система уже имеет разрывы.

В следующей статье разберем, как проходит сканирование систем на наличие уязвимостей, что именно оно позволяет обнаружить и почему автоматический отчет еще нельзя считать полноценным аудитом безопасности.

44:T1f0e,

Миграция с зарубежных ИТ-решений на отечественные — это важный шаг, который компании предпринимают по разным причинам. Однако, как и любой крупный проект, миграция может быть чревата ошибками. Чтобы избежать распространенных проблем, нужно внимательно подойти к каждому этапу процесса. В этой статье мы расскажем, как избежать ошибок при переходе на отечественные решения и сделать процесс миграции успешным.

Оцените текущие потребности и ограничения

Прежде чем начать миграцию, важно понять, какие именно проблемы решают зарубежные ИТ-решения, и что нужно сохранить при переходе на отечественные технологии. Оцените, насколько эти решения могут эффективно заменить зарубежные аналоги:

Способность отечественных решений масштабироваться вместе с вашим бизнесом.
Сроки внедрения и адаптации новых решений к существующим процессам.
Наличие технической поддержки и возможности обновлений на протяжении нескольких лет.

Выделите преимущества отечественных решений

При выборе отечественных ИТ-решений важно оценить их эффективность с точки зрения бизнеса, а не только безопасности или государственных требований. Чтобы не ошибиться, нужно задаться вопросами:

Как эти решения будут масштабироваться с развитием бизнеса?
Какая поддержка предлагается для новых технологий?
Как быстро и безболезненно можно будет внедрить решения в вашу систему?

Не стоит торопиться с выбором только потому, что решение кажется самым доступным. Лучше проанализировать все плюсы и минусы, чтобы сделать обоснованный выбор.

Составьте план миграции и подготовьте команду

Миграция — это не моментальное внедрение новых технологий. Для успешной миграции важно составить четкий план, в который должны быть включены все этапы — от тестирования до переноса данных и внедрения.

Какие именно этапы миграции потребуют наиболее значительных ресурсов?
Как будет происходить передача данных?
Как избежать простой в работе из-за адаптации команды к новым технологиям?

Также важно провести обучение для персонала, который будет работать с новыми системами, и дать время на ознакомление с решением до его полной интеграции в процессы.

Проведите тестирование и пилотный запуск

Миграция не должна проходить в один момент — разделите процесс на несколько этапов. Тестирование каждого этапа позволит выявить возможные проблемы до того, как они станут критичными для всей системы. Проведите тесты на малых объемах данных, чтобы понять, как новое решение будет взаимодействовать с уже существующими системами. Это позволит вам оценить, как система работает в реальных условиях.

Обеспечьте поддержку и оптимизацию после миграции

Когда миграция завершена, важно не забывать об оптимизации и мониторинге работы системы. В течение первого времени нужно внимательно следить за производительностью и стабильно работать над устранением возникающих проблем. Например, обратная связь от пользователей и сотрудников компании поможет выявить потенциальные улучшения или нестабильности, которые могут возникать в процессе работы.

«Миграция ИТ-решений — это не разовый процесс, а постоянное улучшение. Важно не только провести переход, но и следить за тем, чтобы новая система максимально эффективно выполняла свою роль», — Вадим Зимин, Руководитель отдела разработки, Энсайн.

Подведем итоги

Миграция с зарубежных ИТ-решений на отечественные — это сложный процесс, который требует внимательной подготовки на каждом этапе. Оценка текущих потребностей, выбор подходящих технологий, правильное планирование, тестирование и поддержка после миграции — все эти шаги помогут избежать ошибок и обеспечить успешный переход.

Узнайте больше о наших решениях по миграции ИТ-систем.

45:T4e7e,

Во многих проблемных проектах ошибка начинается не в коде. Она появляется раньше — в момент, когда бизнес говорит про результат, а команда слышит набор общих пожеланий.

Заказчик говорит: «нужен быстрый заказ». Менеджер понимает это как отдельную кнопку. Аналитик — как упрощенный сценарий оформления. Разработчик — как короткий путь в корзину. Все вроде делают одну задачу, но у каждого в голове разный продукт.

Для этого и нужен SRS — Software Requirements Specification. Это документ, который фиксирует, что именно должна делать система, в каких условиях, с какими ограничениями и по каким критериям результат считается правильным. Не набор общих пожеланий. Не список экранов. А рабочая спецификация, по которой можно оценивать, проектировать, разрабатывать, тестировать и принимать результат.

SRS нужен не ради формальности. Он нужен, чтобы не платить дважды — сначала за разработку, потом за переделку.

Что такое SRS на практике

SRS — это опорный документ проекта между бизнесом, аналитикой, разработкой, тестированием и поддержкой.

Он отвечает на 5 вопросов:

что система должна делать;
в каких сценариях это работает;
какие есть ограничения;
как проверить, что требование выполнено;
что не входит в текущий объем.

Последний пункт особенно важен. Хороший SRS фиксирует не только состав работ, но и границы. Иначе проект начинает расползаться: «раз уж делаем это, давайте сразу еще вот это». На словах это мелочь. На практике — новые связи, новые риски, новая нагрузка на тестирование и поддержку.

Что SRS не должен в себя тащить

Частая ошибка — подменять требования техническими решениями.

Требование «система должна хранить историю операций 5 лет и позволять искать по номеру документа, дате, клиенту и статусу» — нормальное.

Требование «использовать PostgreSQL, Redis и микросервисную архитектуру» — уже не про требования, а про реализацию. Такие решения принимают позже, когда понятны нагрузка, контур, интеграции, требования к отказоустойчивости, бюджет и команда сопровождения.

SRS не должен отвечать на вопрос «как написать». Он должен точно отвечать на вопрос «что должно получиться».

Когда без SRS уже опасно

Полноценная спецификация нужна не в каждом проекте. Но без нее почти гарантированы конфликты, срывы и переделки, если:

проект делает внешний подрядчик;
в системе много ролей, сценариев и исключений;
есть интеграции с другими системами;
продукт влияет на деньги, документы, клиентские данные, логистику, платежи или доступы;
решение будет жить долго и развиваться не одной командой;
приемка должна идти по понятным критериям, а не по ощущениям.

В маленьких задачах иногда хватает минимального описания изменений. Но как только появляется сложная логика, несколько систем, нефункциональные ограничения и чувствительные данные, упрощенный формат начинает ломаться.

Особенно это заметно в enterprise-среде и legacy. Там проблема почти никогда не в одной функции. Проблема в зависимостях, совместимости, старых данных, регламентных окнах, доступах и последствиях для соседних процессов.

Что бизнес получает от нормального SRS

Прогнозируемость. Когда требования зафиксированы, можно оценивать не «на глаз», а по составу функций, интеграций, ролей, исключений и ограничений.
Управляемость изменений. Если baseline-версии требований нет, любое изменение выглядит как «маленькое уточнение». Когда спецификация есть, видно, что меняется: логика, данные, интерфейсы, тесты, сроки, бюджет, поддержка.
Нормальная приемка. Без SRS продукт часто принимают по ощущениям. С ним — по согласованным критериям.
База для поддержки. После релиза документ нужен не меньше, чем до него. Новая команда, подрядчик поддержки, тестировщики, интеграторы — всем нужен единый источник понимания, как система должна работать.

«Большая часть дорогих доработок появляется не потому, что команда плохо пишет код. Они появляются потому, что в начале проекта никто не договорился, где заканчивается бизнес-требование и начинается предположение», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Из чего должен состоять SRS

Не нужен культ шаблона. Но логика у хорошего документа почти всегда одна.

SRS нужен до начала разработки, а не после первой дорогостоящей ошибки

Цель и границы проекта. Какую бизнес-проблему решаем, кто пользователи, что входит в первую версию, а что остается за рамками.
Контекст и ограничения. В каком контуре работает система, какие есть внешние зависимости, ограничения по безопасности, доступам, инфраструктуре, релизным окнам и данным.
Функциональные требования. Что делает система, кто запускает сценарий, какие есть предусловия, шаги, проверки, результаты и ошибочные сценарии.
Нефункциональные требования. Производительность, доступность, отказоустойчивость, безопасность, аудит действий, масштабируемость, журналирование, архивирование, время восстановления.
Требования к данным и интеграциям. Какие сущности участвуют, откуда приходят данные, кто источник истины, что происходит при ошибке обмена, дублировании, тайм-ауте или конфликте версий.
Критерии приемки. Каждое важное требование должно быть проверяемым. Иначе это не требование, а пожелание.

Как писать требования, чтобы их не трактовали по-своему

Главное правило: требование должно быть однозначным, проверяемым и отделенным от соседнего.

Плохо: «Система должна быстро загружаться и быть удобной».
Лучше: «Для авторизованного пользователя страница списка заказов должна открываться не более чем за 2 секунды при нагрузке до 300 одновременных сессий».
Плохо: «Система должна отправлять уведомления».
Лучше: «При переходе заказа в статус «Передан в доставку» система должна отправить клиенту email и SMS, если в карточке заказа заполнены подтвержденные email и номер телефона. При ошибке отправки система должна записать событие в журнал и поставить задачу на повторную отправку».

Чем меньше слов вроде «удобно», «быстро», «гибко», «понятно», тем меньше пространства для споров.

Минимальный шаблон хорошего требования

Даже без сложного инструмента полезно держать единый формат:

ID: FR-012
Название: Создание заказа из корзины
Источник: Бизнес-требование BR-03
Приоритет: Must
Описание: Пользователь может оформить заказ из корзины
Предусловия: Пользователь авторизован, корзина не пуста, товары доступны к заказу
Основной сценарий: Пошаговое описание действий
Исключения: Товар недоступен, не прошла оплата, отсутствует адрес
Результат: Заказ создан, клиент получил подтверждение, данные переданы в учетную систему
Критерии приемки: Список проверяемых условий
Связанные требования: Уведомления, логирование, интеграция с оплатой

Кто должен участвовать в создании SRS

Ошибка — считать, что спецификацию пишет только аналитик.

Хороший SRS собирается на стыке ролей. Бизнес формулирует цель. Аналитик переводит ее в структуру и сценарии. Архитектор проверяет реализуемость. Разработка видит скрытый объем и зависимости. Тестирование помогает сделать требования проверяемыми. Поддержка подсказывает, где потом возникнут проблемы в эксплуатации.

Если документ пишет один человек в вакууме, он почти всегда получается или слишком общим, или слишком теоретическим.

Как выглядит рабочий процесс

Сначала собирают контекст: какую задачу решаем, кто пользователи, какой процесс сейчас, где точка сбоя, какие системы уже участвуют, какие ограничения нельзя игнорировать.

Потом разбирают сценарии. Не только основной поток, но и исключения: нет данных, интеграция недоступна, пользователь не завершил действие, событие пришло дважды, статусы в системах разошлись.

После этого фиксируют требования и согласуют baseline — версию документа, от которой идет работа.

Дальше вводят порядок изменений. Изменения в требованиях нормальны. Ненормально вносить их без оценки последствий для логики, интеграций, сроков, тестирования и поддержки.

Где SRS чаще всего ломается

Чаще всего проблемы возникают в 5 местах:

требования пишут слишком общо;
описывают только «счастливый путь»;
не связывают требования с бизнес-целью;
забывают про эксплуатацию — логирование, мониторинг, доступы, архив, восстановление;
документ не обновляют по мере изменения проекта.

Самая опасная ситуация — когда SRS формально есть, но фактически устарел. Команда разрабатывает по одному пониманию, тестирует по другому, а бизнес принимает по третьему.

Когда полноценный SRS не нужен

Избыточная документация тоже вредна.

Если задача маленькая, логика простая, команда компактная, контур понятный, а цена ошибки низкая, можно обойтись более легким форматом: user story, acceptance criteria, макеты и список ограничений.

Но здесь важно не обманывать себя. Часто проект называют «небольшой доработкой», хотя внутри уже есть интеграции, роли, права, данные, уведомления, история изменений и требования к отказоустойчивости. Это уже не маленькая задача. Это плохо описанный проект.

Подведем итоги

SRS — это способ убрать двусмысленность из проекта до того, как она превратится в переделки, конфликт по объему работ и проблемы в эксплуатации.

Чем сложнее система, чем больше в ней интеграций и чем дольше ей жить, тем выше цена плохих требований. В таких проектах спецификация — это инструмент управления риском.

Хороший SRS дает предсказуемость. Для бизнеса — в сроках и бюджете. Для команды — в границах задачи. Для поддержки — в понимании того, как система должна вести себя в реальном контуре.

46:T5af2,

Подготовка к проверке Роскомнадзора по обработке персональных данных на веб-ресурсах, корпоративных системах и информационных порталах включает оформление документов, правильную настройку сервисов аналитики вроде Яндекс.Метрики и устранение распространенных ошибок.

Сегодня контроль за соблюдением требований обработки персональных данных стал строже, ведь число проверок сайтов и информационных ресурсов постоянно увеличивается. Повышенный интерес к вопросам защиты данных вызван ростом цифровых технологий, увеличением числа утечек информации и реакцией общественности на подобные инциденты. Регулятор постоянно обновляет правила и усиливает меры надзора, чтобы обеспечить безопасность пользователей.

В 2025 году акцент смещен на профилактику нарушений. Однако компании, работающие с массивами пользовательской информации (сайты, корпоративные порталы, ретейл, CRM, 1С Битрикс, SaaS-платформы, интернет-магазины), образовательные и медицинские организации, органы власти остаются под особым вниманием проверяющих. Любое обращение гражданина, утечка данных или жалоба способны стать поводом для предупреждения.

Для бизнеса проверки Роскомнадзора нередко становятся источником тревоги. Страхи понятны: штрафы по 152-ФЗ достигают сотен тысяч рублей, возможна блокировка сайта, временное приостановление деятельности и репутационные потери. Но при грамотной подготовке проверка превращается не в стресс, а в оценку зрелости процессов защиты информации.

Кого проверяют чаще всего?

Утечки персональных данных в России, основания для проверки Роскомнадзором

Источники: interfax.ru, tass.ru, tass.ru/ekonomika, rbc.ru

Проверки Роскомнадзора стали строже: теперь контролируются любые сайты и системы, работающие с персональными данными пользователей, будь то простая форма обратной связи или мощный аналитический инструмент. Важно соблюдать закон, иначе возможны штрафы. Особенно внимательны специалисты ведомства к крупным платформам, собирающим много данных, использующим CRM и аналитику, передавая их другим компаниям или сохраняя в облаках. Причинами внезапных проверок часто становятся жалобы пользователей, некорректные настройки форм согласия и ошибки в защите данных.

Как компании узнают о проверке?

Схема работы, выдача акта проверки и предписания Роскомнадзора

Обычно уведомление о проверке приходит официальным письмом или через электронный сервис ведомства, и этот факт отражается в Едином реестре проверок. В уведомлении содержатся: основания проверки, перечень проверяемых требований (например, соблюдение требований по сбору форм, куки, журналам согласий), сроки и формат взаимодействия, а также контактные данные инспектора. Если сайт собирает персональные данные или размещает формы обратной связи, важно, чтобы был назначен ответственный за взаимодействие с РКН и готов к запросам.

Но проверка может начаться без предварительного предупреждения: например, инспектор вправе запросить логи или выписку по формам на почту или в электронном виде. На практике проверки Роскомнадзора сайтов и информационных систем нередко проходят незаметно для владельца ресурса. Инспекторы могут зайти на ресурс под видом обычного пользователя, оценить наличие политики конфиденциальности, корректность баннера Cookies и формы согласия, а затем направить официальный запрос на корпоративную почту. В письме обычно содержится требование пояснить, почему сайт не включен в реестр операторов персональных данных, предоставить перечень применяемых мер защиты информации или копии локальных актов по обработке ПД.

Если сайт устанавливает Cookies или запускает аналитику без согласия пользователя, либо формы обратной связи работают без обязательного чекбокса согласия на обработку ПД, это почти гарантированный повод для внепланового интереса со стороны Роскомнадзора.

Для сайтов часто не требуется отдельного письма-уведомления заранее: проверка может стартовать при анализе публично доступных данных (форма, политика конфиденциальности, куки-баннер) или при получении жалобы. Поэтому сайт должен быть готов: опубликована актуальная политика обработки ПД, формы работают корректно с явным согласием, логи согласий ведутся, настройка аналитики соответствует требованиям. Иначе запрос от РКН может появиться на почте с требованием предоставить логи, журналы, описания процессов.

За несоблюдение требований Роскомнадзора предусмотрены штрафы: физлицам — до 15 тысяч рублей, должностным лицам — до 200 тысяч рублей, юридическим лицам — до полумиллиона рублей.

Какие документы проверяют при работе с информационными системами и сайтами

При проверке фокус смещается на то, как компания реализует обработку ПД пользователей на своих информационных системах и сайтах. Инспекторы оценивают легальность действий, корректность настроек IT-систем.

Политика конфиденциальности и обработки данных:

● должна быть опубликована на сайте и доступна пользователям;

● описание целей сбора данных, правил их хранения, передачи и удаления;

● обновление политики при изменении процессов, новых сервисов или интеграций.

Явное согласие пользователей:

● форма согласия на обработку данных (например, через чекбокс при отправке формы обратной связи с соответствующим текстом: “Я даю ООО "название фирмы" согласие на обработку моих данных в соответствии с Политикой защиты персональных данных"

● отправка данных без нажатого согласия запрещена;

● хранение информации о согласии в логах с указанием времени, даты и идентификатора пользователя (например, телефонного номера).

Настройки IT-систем и защита данных:

● шаблоны и скрипты для корректного сбора согласий;

● отдельные серверы для хранения чувствительных данных (документы, биометрия), изолированные от внешнего интернета;

● шифрование, разграничение прав доступа, резервное копирование и аудит действий пользователей.

Автоматизированная и ручная обработка данных:

● все процессы обработки должны быть задокументированы;

● контроль доступа сотрудников к системам и данным;

● журналы регистрации действий пользователей и сотрудников.

Ответственные лица:

● назначение ответственного за обработку данных в информационной системе;

● фиксирование его полномочий, обязанностей;

● ведение учета действий, решений по информационной защите.

Эти документы создают основу для оценки ответственности оператора и соблюдения технических и организационных мер защиты. Их отсутствие или утрата актуальности — типовая причина штрафов и предписаний Роскомнадзора.

Работа с Яндекс.Метрикой

Во время проверок Роскомнадзор особо следит за правильной настройкой аналитических инструментов, таких как Яндекс.Метрика и Google Analytics. Эти сервисы отслеживают IP-адреса, Cookies-файлы и поведение пользователей, что считается персональными данными. Следовательно, установка счетчиков возможна лишь после получения согласия пользователя на обработку его данных и использование файлов Cookies.

Это технически реализовано следующим образом: до момента нажатия кнопки «Принять» на специальном окне согласия сбор данных не начинается. Необходимо вести журнал фиксации моментов дачи согласия пользователями (включая время, дату и сессионный ID).

ЭНСАЙН оказывает помощь предприятиям в грамотной интеграции и настройке механизмов предоставления согласия: подключаем окна Cookies, адаптируем скрипты аналитики и обеспечиваем соблюдение требований Федерального закона №152-ФЗ («О персональных данных»). Такой подход минимизирует вероятность штрафов и подтверждает ответственный подход к обеспечению безопасности данных клиентов.

Действия компании во время проверки и роль интегратора

Когда сайт проверяют, важно действовать последовательно, чтобы минимизировать риски, показать добросовестность. Рекомендуемые шаги:

Назначение ответственных лиц. Обычно это IT-специалист, ответственный за систему, и сотрудник юридического отдела. Они координируют показ процессов обработки ПД и ответы на вопросы инспектора.
Предоставление актуальной документации. Все формы согласий, журналы логирования действий, политика конфиденциальности и протоколы защиты данных должны быть в актуальном виде.
Фиксация действий. Ведение протокола взаимодействия с инспектором, копирование документов, запись даты и времени предоставления данных.
Проверка соответствия технических мер. Убедитесь, что системы хранения данных разграничены: чувствительные данные (паспортные данные, сканы документов, биометрия) должны храниться на отдельном сервере с ограниченным доступом и межсетевым экраном, а доступ к ним фиксируется в логах.
Обжалование при несогласии. Если инспектор выявляет несоответствия, компания имеет право представить пояснения или исправить нарушения в разумные сроки.

Как поможет подрядчик?

Подрядчик играет важную роль в подготовке компаний к проверкам Роскомнадзора. Компания ЭНСАЙН поможет провести аудит ваших систем на предмет соблюдения правил обработки данных, настроит правильное логирование согласий и действий пользователей, обеспечит разделение серверов для хранения различных типов данных, разработает журналы доступа согласно требованиям информационной безопасности, автоматизирует процессы, связанные со сроками хранения персональных данных, даст рекомендации по грамотной организации их хранения и обработки, доработает информационную систему до полного соответствия требованиям ФЗ-152. Сотрудничество с опытным интегратором позволяет заблаговременно выявить и устранить риски, предотвратить или минимизировать возможные штрафы, продемонстрировав проверяющим ответственное отношение компании к выполнению требований законодательства. Свяжитесь с ЭНСАЙН сегодня и получите бесплатную консультацию, обеспечив надежную защиту персональных данных вашего бизнеса от штрафных санкций.

Частые вопросы (FAQ)

Что делать, если на сайте нет согласий или журналов логирования?

Даже частичное отсутствие согласий повышает риск штрафа за нарушение ПДн. Необходимо внедрить формы согласия для всех точек сбора данных (обратные формы, аналитика, куки), а также настроить логирование действий пользователей: когда и каким способом было получено согласие. Это позволит доказать соблюдение требований законодательства в случае жалобы или проверки.

Можно ли исправить нарушения «по ходу» работы сайта?

Частично да, но исправления должны быть документированы и доступны инспектору. Лучше заранее убедиться, что формы согласий, политика конфиденциальности и логирование корректны, чтобы не подвергать компанию риску штрафов.

Как должен работать чек согласия на форме обратной связи?

Пользователь должен самостоятельно ставить галочку о согласии на обработку ПД. Форма не должна отправляться без этого согласия. При этом информация о дате, времени и идентификаторе пользователя должна фиксироваться в базе или отдельном журнале.

Кто отвечает за соблюдение правил обработки данных на сайте?

Ответственность несет оператор данных, то есть компания-владелец сайта или информационной системы. Конкретные сотрудники отвечают только при умысле или грубой неосторожности.

Что делать, если сайт обрабатывает паспортные данные, сканы документов, биометрию?

Такие данные требуют отдельного хранения на выделенном сервере с ограниченным доступом и межсетевым экраном. Журналы логирования и разграничение прав доступа обязательны. Интегратор, например «ЭНСАЙН», поможет правильно организовать архитектуру, процессы хранения.

Как интегратор может помочь заранее подготовиться к проверке?

Интегратор проводит аудит системы, настраивает логи, обновляет формы согласий, политику конфиденциальности и инструкции для сотрудников, а также обучает команду безопасной обработке ПД. Это снижает риск штрафных санкций, ускоряет прохождение проверки.

47:T78c7,

Я бы не торопился.

Технически связь между системами есть. Для бизнеса ее почти нет.

Что на самом деле нужно интегрировать

«Битрикс24» и 1С обычно отвечают за разные части работы.

Вот ради этого и стоит делать интеграцию.

Не ради самого факта обмена данными.

Где должна храниться основная информация

Один из первых споров на проекте обычно звучит так:

— А можно, чтобы клиента редактировали и в 1С, и в «Битрикс24»?

Можно. Вопрос в том, что будет дальше.

Поэтому у каждого типа данных должен быть основной владелец.

Обычно мы предлагаем начинать с такой модели:

Данные	Где ведем
Лиды, сделки, коммуникации	«Битрикс24»
Номенклатура и цены	1С
Остатки и резервы	1С
Учетные документы	1С
Оплаты и отгрузки	1С
Статусы оплаты и отгрузки в сделке	Передаем из 1С в CRM

Это не универсальная таблица. У конкретного бизнеса могут быть другие правила.

Важно не то, какую систему мы выбрали. Важно, что выбор сделан.

Двусторонний обмен не означает, что все данные разрешено свободно редактировать с обеих сторон.

Почему одного коннектора недостаточно

Но коннектор не знает, как устроена конкретная компания.

Он не решит:

кто имеет право менять реквизиты;
когда сделку уже нельзя редактировать;
что считать одним и тем же клиентом;
как вести себя при повторном запросе;
кому сообщить об ошибке;
что делать, если 1С была недоступна два часа.

Это уже не настройка модуля. Это проектирование процесса.

Покажу на простом примере.

Через минуту запрос уходит повторно.

Что произойдет?

Когда интеграция действительно окупается

Не каждой компании нужен сложный обмен между CRM и 1С.

Интеграция становится оправданной, когда одни и те же действия повторяются постоянно.

Здесь автоматизация дает понятный эффект: информация перестает ходить между отделами через людей.

Но начинать все равно лучше с одного маршрута.

Первый рабочий сценарий может быть таким:

Если этот маршрут работает стабильно, добавляем резервирование, отгрузку и остатки.

Так проще понять, где именно возникла ошибка. И намного проще вернуть процесс в рабочее состояние.

С чего начать интеграцию «Битрикс24» и 1С

Сначала описать процесс на бумаге

До установки модуля нужно пройти весь путь заказа.

Обычно уже на этом этапе выясняется, что у разных подразделений разные представления об одном процессе.

Интеграция просто вытащит эти противоречия наружу.

Поэтому сначала договариваемся о процессе. Потом автоматизируем.

Затем проверить, с какой 1С придется работать

Фраза «у нас обычная 1С» почти ничего не означает.

До оценки работ нужно знать:

точное название конфигурации;
редакцию и версию;
версию платформы;
какие доработки сделаны;
где размещена база;
есть ли возможность опубликовать HTTP-сервисы;
какая версия «Битрикс24» используется.

Тогда потребуется доработка.

После этого разобраться с существующими данными

Интеграция редко запускается на пустых системах.

Если просто включить обмен, старый беспорядок начнет размножаться.

Название — плохой ключ.

Штатный коннектор или собственная разработка

Я бы не начинал с собственной интеграции, пока не проверены возможности штатного решения.

Это быстрее, дешевле и проще в дальнейшем сопровождении.

Собственная разработка нужна, когда появляются реальные ограничения:

конфигурация сильно изменена;
работают несколько баз 1С;
используются нестандартные документы;
между системами нужна сложная маршрутизация;
в процесс включены сайт, личный кабинет или складская система;
требуется централизованная очередь и отдельный мониторинг.

Иногда лучший вариант — смешанный.

Стандартные объекты передаем через коннектор. Специфические сценарии выносим в отдельный сервис.

Как запускать первый контур

Первый запуск лучше ограничить.

Одна база. Одно юридическое лицо. Один тип заказа. Несколько пользователей. Небольшая группа товаров.

И обязательно пройти несколько сценариев.

Тест «нажал кнопку — заказ появился» ничего не доказывает.

Надежность проявляется в ошибочных ситуациях.

Именно эти проверки показывают, можно ли отдавать интеграцию в промышленную эксплуатацию.

Почему появляются дубли

Дубли — самая заметная проблема, но причина у них бывает разной.

Поэтому одной проверки по названию недостаточно.

Тогда повторная передача обновляет существующую запись, а не создает новую.

Что должно происходить при сбое

Сбой будет. Вопрос только в том, когда.

Нормальная интеграция не должна молча терять данные.

При этом запрос можно отправить повторно без риска создать еще один документ.

Вот четыре вещи, которые нужно видеть постоянно:

когда прошел последний успешный обмен;
сколько сообщений находится в очереди;
сколько ошибок появилось;
как давно висит самая старая.

Журнал, который никто не открывает, не является мониторингом.

Если об остановке обмена компания узнает от менеджера, значит контроль не настроен.

Почему интеграцию нельзя привязывать к сотруднику

Иногда обмен настраивают от учетной записи разработчика, администратора или руководителя отдела.

Пока человек работает и его права не меняются, проблем нет.

Потом сотрудник увольняется, учетную запись блокируют, и вместе с ней останавливается интеграция.

То же касается вебхуков, ключей и доступов к HTTP-сервисам.

Критичный бизнес-процесс не должен зависеть от конкретного человека.

Что меняется при подключении товаров и склада

Складской учет лучше подключать после базового обмена клиентами и заказами.

Сначала определяется основной каталог.

Отдельно согласовывается логика остатков.

Без этих ответов цифра в CRM будет выглядеть точной, но может не иметь отношения к реально доступному товару.

Кто отвечает за интеграцию после запуска

Интеграция не может оставаться «за разработчиками».

Техническая команда отвечает за передачу данных, ошибки, доступы и восстановление.

Без него любая проблема превращается в переписку:

Это 1С не передала.
Нет, это CRM неправильно приняла.
Менеджер вообще не должен был менять заказ.
А кто ему это сказал?

Технически такая интеграция может быть исправна. Организационно — нет.

Как понять, что проект завершен

Не по факту установки модуля.

И не по первому успешно переданному заказу.

Интеграция закончена, когда сотрудники перестали выполнять лишнюю работу.

После обновления 1С или CRM проводится контрольная проверка, а не ожидание первого инцидента.

Если данные по-прежнему периодически сверяют вручную, проект еще не завершен.

Вместо вывода

Штатно соединить «Битрикс24» и 1С обычно несложно.

Сам по себе коннектор не устраняет ручную работу. Он только передает информацию.

И только после этого выбираем способ подключения.

48:T2002,

Выбор IT-партнёра — одна из ключевых задач CIO. Это не только вопрос технологий, но и долгосрочного взаимодействия. Чем старше и опытнее становишься в этой роли, тем яснее понимаешь, что зрелый партнёр — это тот, кто помогает решать не только текущие проблемы, но и предсказывает их, чтобы компания могла работать стабильно, не беспокоясь о будущем.

Техническая зрелость и умение работать с текущими решениями

Когда начинается сотрудничество с новым партнёром, стоит обратить внимание на то, как он подходит к существующим системам. Если партнёр сразу предлагает переписать всё с нуля, это настораживает. Зрелый партнёр не рушит всё, что было сделано раньше, а находит способы улучшить и развить систему, без сбоев и потерь данных.

Как CIO оценивает зрелость IT-партнёра

Понимание текущей инфраструктуры. Партнёр должен понимать, как работают уже внедрённые системы и какие риски могут возникнуть при их изменении. Чем больше он знает об этой инфраструктуре, тем меньше рисков будет в процессе работы.
Интеграция с другими системами. Хороший партнёр всегда думает о совместимости с другими приложениями и сервисами. Он предлагает решения, которые легко интегрируются, а не создаёт очередной монолит, который в будущем станет тяжело обновлять и поддерживать.

Проактивность и предупреждение проблем

Партнёр всегда должен быть настроен на поиск рисков и проблем до того, как они становятся инцидентами. Это означает не только наблюдение за текущими процессами, но и использование аналитики для предсказания и предотвращения сбоев. Это не всегда очевидно на первых порах, но через некоторое время становится ясно, кто из партнёров не просто реагирует на ситуацию, а работает на опережение.

Оперативность и способность работать в условиях изменений

Жизнь в IT — это постоянные изменения. Новые технологии, обновления, изменения в бизнес-процессах. Зрелый партнёр должен быть готов быстро адаптировать решения под новые условия. Он должен понимать, что бизнес не может остановиться на несколько месяцев ради глобальных изменений.

Масштабируемость решений. Когда компания растёт, партнёр должен предложить решения, которые масштабируются по мере роста. Он должен обеспечить, чтобы инфраструктура оставалась стабильной, даже если требования к ней будут увеличиваться.
Плавные изменения. Вместо того чтобы всё менять сразу, зрелый партнёр предложит поэтапное внедрение изменений. Он будет работать с командой, чтобы внедрять улучшения, не останавливая работы.

Умение работать с рисками и оправдывать доверие

Риски всегда присутствуют в IT-системах и партнёр должен не только уметь их устранять, но и предотвращать. Он заранее готовит план на случай сбоя и может предложить стратегию восстановления, минимизируя время простоя. Важно, чтобы партнёр был готов взять на себя ответственность за решение возникающих проблем, а не искать оправдания.

«Когда риски становятся управляемыми, их можно превратить в фактор, который не пугает, а помогает двигаться вперёд с уверенностью», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

За годы работы понимаешь, что стабильность и надёжность — это не только вопрос качества услуг, но и человеческих отношений. Хороший партнёр всегда готов объяснить, что происходит на каждом этапе и как это повлияет на работу компании.

Подведем итоги

Зрелый IT-партнёр для CIO — это тот, кто помогает решать текущие задачи и предотвращать проблемы в будущем. Он должен быть экспертом в технологиях, но также понимать бизнес-потребности и быть готовым быстро адаптироваться к изменениям.

Именно с таким партнёром CIO могут быть уверены в том, что их IT-система будет работать бесперебойно, независимо от изменений на рынке.

49:T25b4,

Часто, когда стоит выбор между развитием системы и её поддержкой, решения склоняются в пользу обновлений и нововведений. Однако на практике поддержка может быть дешевле и менее рискованной альтернативой, чем переписывание или создание новой системы.

Почему поддержка иногда дешевле

Разработка новых решений и внедрение инноваций — это всегда затраты. Помимо денег, развитие системы часто влечёт за собой скрытые риски: ошибки при внедрении, сбои в работе, неопределённость в сроках. В отличие от этого, поддержка уже работающей системы требует гораздо меньших вложений и меньше рисков.

Снижение непредвиденных расходов: Поддержка позволяет избежать затрат на радикальные изменения, которые могут не оправдать себя.
Минимизация рисков: Внедрение новых решений всегда сопряжено с рисками — поддержка позволяет избежать неожиданных сбоев и других проблем.
Эффективность и стабильность: Поддержка позволяет сосредоточиться на стабильности системы и её постепенном улучшении, не затрачивая ресурсы на кардинальные изменения.

Когда система стабильно выполняет свои задачи, зачем вкладываться в её переписывание, если достаточно провести минимальные доработки? Поддержка старой системы позволяет сохранить стабильность и избежать неоправданных затрат на неопробованные решения.

Почему поддержка еще и безопаснее

Поддержка старой системы может быть не только дешевле, но и безопаснее, если она уже отвечает на бизнес-потребности. Например, компания использует старую CRM-систему. Внедрение новой — это не только большие расходы, но и риск ошибок, недовольства сотрудников и переходных проблем. Вместо этого компания может поддерживать существующую систему, интегрируя её с новыми инструментами и обновляя лишь необходимые части.

Преимущества стабильности: Разработка новой системы требует значительных вложений в адаптацию, обучение и интеграцию. Поддержка позволяет сохранить стабильность в текущих процессах.
Уверенность в результатах: Поддержка даёт уверенность в том, что система будет продолжать функционировать так, как она должна, без неожиданностей.
Быстрое реагирование на изменения: Внедрение изменений в поддерживаемую систему происходит быстрее и с меньшими затратами, чем в новую, что важно в условиях быстрой динамики.

Более того, разработка новой системы требует времени на обучение сотрудников, изменение бизнес-процессов и адаптацию. Всё это отвлекает от основной работы и снижает общую эффективность. Поддержка позволяет избежать этих сложностей, ведь система уже интегрирована в процессы.

Постепенные улучшения против кардинальных изменений

Поддержка старой системы не исключает возможности для улучшений. Однако изменения можно вносить постепенно, не нарушая существующей структуры и не создавая лишнего стресса для бизнеса.

Пошаговое внедрение: Вместо того чтобы переписывать систему с нуля, можно поэтапно внедрять новые функции, что даёт возможность контролировать изменения.
Контроль над изменениями: Кардинальные изменения могут вызвать неожиданные последствия, тогда как постепенные улучшения минимизируют этот риск.

«Не всегда нужно ломать, чтобы строить. Поддержка позволяет плавно адаптировать систему к новым условиям, не нарушая её основ», — Вадим Зимин, Руководитель отдела разработки, Энсайн.

Как выбрать между поддержкой и развитием

Решение зависит от того, насколько устарела система и как она выполняет свои задачи. Если система справляется со своей ролью, можно сосредоточиться на её поддержке. Важно помнить, что развитие может означать не только большие затраты, но и долгосрочные риски, которые вряд ли оправдаются с точки зрения бизнеса.

Оценка текущего состояния: Когда система выполняет свои задачи, можно продолжать её поддержку, а не тратить ресурсы на развитие.
Риски переписывания: Развитие системы может повлечь за собой больше рисков и затрат, чем предполагаемые преимущества.
Непрерывность бизнеса: Поддержка обеспечивает стабильную работу без крупных сбоев, в отличие от изменения системы, которое может привести к остановке процессов.

Поддержка даёт возможность не менять систему кардинально, а лишь адаптировать её под текущие нужды.

Подведем итоги

Поддержка старой системы часто оказывается более выгодным и менее рисковым выбором, чем её развитие. Это решение позволяет сохранить стабильность работы, минимизировать затраты и избежать проблем, связанных с внедрением новых технологий. Поддержка — это не временная мера, а стратегическое решение, которое приносит долгосрочную пользу бизнесу.

4a:Ta1c2,

Когда бизнес обсуждает запуск нового цифрового продукта, разговор быстро переходит к функциям.

Проблема в том, что на этом этапе еще никто не доказал, что пользователю нужен сам продукт.

Для этого и нужен MVP.

MVP начинается не с идеи продукта

Обычно инициатор проекта приходит с уже сформированным решением.

Например:

«Нам нужна система автоматического формирования коммерческих предложений».

Но пока это только идея системы.

Чтобы превратить ее в проверяемую гипотезу, нужно вернуться к проблеме пользователя.

Тогда гипотеза может звучать так:

Теперь понятно, что именно нужно проверить.

Не всю будущую систему. Не десятки функций. Не красоту интерфейса.

Это и есть отправная точка MVP.

Как найти критическую гипотезу

У любого цифрового продукта есть несколько предположений.

Проверять все одновременно слишком дорого.

Поэтому сначала нужно найти гипотезу, ошибка в которой делает бессмысленным весь проект.

Но критической гипотезой может оказаться возможность использовать реальные документы.

Критическую гипотезу стоит искать там, где пересекаются четыре фактора:

реальная боль пользователя;
готовность изменить текущее поведение;
возможность технической реализации;
экономический смысл для заказчика.

Не спрашивайте пользователей, нравится ли им идея

Перед разработкой нужно поговорить с людьми, для которых создается продукт.

Но интервью тоже легко превратить в формальность.

Пользователю показывают презентацию и спрашивают:

«Стали бы вы пользоваться такой системой?»

Такие ответы почти бесполезны.

Гораздо важнее обсуждать не предполагаемое будущее, а реальное прошлое.

Фактическое поведение надежнее заявленного интереса.

Для корпоративных систем важно разговаривать не только с будущим пользователем.

У проекта почти всегда несколько участников:

сотрудник выполняет операцию;
руководитель отвечает за результат;
ИТ-служба оценивает интеграции;
безопасность определяет ограничения;
финансовый руководитель согласует бюджет;
владелец процесса принимает решение о внедрении.

Зафиксируйте критерий успеха до разработки

Один из главных вопросов MVP звучит просто:

Какой результат убедит нас продолжить инвестиции?

Ответ нужно получить до начала разработки.

Иначе после запуска команда будет подстраивать трактовку под фактические цифры.

Критерий зависит от проверяемой гипотезы.

Если бизнес проверяет наличие спроса, результатом могут быть заявки на пилот.

Если проверяется ценность продукта, важны повторное использование и готовность вернуться.

Если проверяется бизнес-модель, главным сигналом становится оплата или готовность подписать договор.

Хороший критерий должен быть измеримым и заранее ограниченным по времени.

Например:

Это гораздо полезнее формулировки «посмотрим, будет ли интерес».

MVP не всегда требует полноценной разработки

Минимально жизнеспособный продукт часто путают с первой версией приложения.

Но проверять гипотезу можно разными способами.

Если нужно понять, существует ли интерес к проблеме, иногда достаточно посадочной страницы и формы заявки.

Если нужно проверить понятность интерфейса, подойдет интерактивный прототип.

Если важно убедиться в ценности результата, услугу на первом этапе можно частично выполнять вручную.

Внешне процесс уже похож на будущий продукт. Внутри пока нет полной автоматизации.

Такой подход позволяет проверить важные вещи:

готовы ли пользователи передавать документы;
какие ошибки они считают критичными;
насколько ценен итоговый отчет;
готовы ли они платить;
как часто возникает потребность.

Если спрос подтвердится, ручные операции можно автоматизировать.

Полноценное приложение нужно тогда, когда без него нельзя проверить основную гипотезу.

Формат MVP должен определяться не амбициями команды, а вопросом, на который нужно получить ответ.

Соберите один законченный сценарий

Когда проект доходит до функциональности, команда обычно пытается включить в MVP как можно больше.

Логика понятна: раз разработка уже началась, хочется сразу сделать основу будущего продукта.

Рабочий MVP строится вокруг одного законченного пользовательского сценария.

Например:

Или:

Но основной путь должен работать от начала до конца.

«В проектах мы часто видим одну и ту же ошибку: MVP пытаются сделать как дешевую копию будущей системы. В итоге функций мало, но главный риск так и не проверен. Я бы смотрел иначе: первая версия должна не впечатлять количеством возможностей, а дать бизнесу честный ответ — стоит ли вкладывать следующие миллионы в этот продукт», — Алексей Постригайло, старший партнер ИТ-⁠интегратора «Энсайн».

Где заканчивается минимальный продукт и начинается технический долг

У MVP есть неприятная крайность.

Внешне продукт работает. Но команда не понимает, что происходит внутри.

Это уже не экономия, а потеря управляемости.

На первом этапе обычно необходимы:

фиксация ключевых действий пользователя;
журнал ошибок;
разграничение доступа;
безопасное хранение паролей и ключей;
резервное копирование критичных данных;
тестовая среда;
возможность быстро отключить проблемную функцию.

Особенно важно это для корпоративных продуктов.

Поэтому объем первой версии нельзя оценивать только по количеству страниц.

Не создавайте архитектуру на десять лет вперед

У другой крайности обратная проблема.

При этом продуктом пока пользуются десять человек.

Такой подход увеличивает стоимость эксперимента и замедляет получение обратной связи.

Но это не означает, что можно полностью игнорировать будущее.

Есть решения, которые создают технический тупик уже на старте:

данные хранятся в формате, который нельзя перенести;
бизнес-логика жестко связана с конкретным конструктором;
отсутствует разделение между интерфейсом и интеграциями;
изменения невозможно тестировать отдельно;
нет документации по обмену данными;
ключевые процессы зависят от ручных действий одного человека.

Как провести пилот

Когда первый сценарий готов, появляется соблазн сразу открыть продукт широкой аудитории.

Для MVP это редко полезно.

На раннем этапе важнее глубина наблюдения, а не объем трафика.

Пользователю нужно дать реальную задачу, а не попросить «посмотреть интерфейс».

Если система помогает подбирать оборудование, нужно использовать реальные параметры и ограничения.

Если сервис формирует отчет, результат должен быть нужен пользователю в текущей работе.

Иначе команда проверит не продукт, а способность человека пройти демонстрационный сценарий.

Во время пилота нужно наблюдать не только за итоговыми показателями.

Хороший пилот почти всегда содержит ручную поддержку. Это нормально.

Проблема возникает, когда команда не учитывает ее объем.

Даже если клиент доволен результатом.

Что измерять после запуска MVP

Метрики должны быть связаны с критической гипотезой.

Просмотры, регистрации и время на сайте могут быть полезны, но сами по себе не доказывают ценность продукта.

Если продукт должен использоваться регулярно, важно повторное использование.

Если решение обещает экономить время, нужно сравнивать длительность процесса до и после внедрения.

Для корпоративного MVP мы бы смотрели на четыре группы показателей.

Первая группа показывает, смог ли пользователь получить результат:

завершение ключевого сценария;
время до первого полезного результата;
количество ошибок;
необходимость помощи.

Вторая группа отражает реальную ценность:

повторное использование;
готовность передать продукт коллегам;
отказ от старого способа работы;
снижение времени или количества ручных операций.

Третья группа связана с бизнесом:

готовность продолжать пилот;
запрос коммерческого предложения;
согласованный бюджет;
фактическая оплата.

Четвертая показывает стоимость эксплуатации:

объем ручной поддержки;
количество нестандартных ситуаций;
затраты на обработку одного пользователя;
нагрузка на интеграции и инфраструктуру.

Как принять решение после пилота

После MVP команда должна принять одно из четырех решений.

Первое: развивать продукт.

Второе: изменить направление.

Третье: повторить эксперимент.

Четвертое: остановить проект.

Это нормальный исход MVP.

Успех MVP заключается не в обязательном переходе к полноценному продукту.

Успех заключается в том, что решение принято раньше, чем компания потратила основной бюджет.

Что изменилось с появлением ИИ-инструментов

Для MVP это полезно.

Но ИИ не отменяет продуктовую работу.

Более того, высокая скорость разработки создает новый риск.

Поэтому главный эффект ИИ для MVP заключается не в возможности сделать больше.

Он позволяет дешевле проверять предположения.

И именно так его стоит использовать.

Рабочая схема запуска MVP

Если свести весь процесс к одной последовательности, она будет выглядеть так.

Сначала бизнес формулирует проблему конкретной аудитории и изучает, как она решается сейчас.

Продукт запускается на ограниченной аудитории с реальными задачами и данными.

В этой схеме нет ничего эффектного.

Главное

MVP нужен не для того, чтобы показать первую версию продукта.

Он нужен, чтобы принять решение о следующей инвестиции.

Поэтому начинать стоит не с перечня функций и не с выбора технологии.

Все остальное появляется после.

Если не подтверждается, проект можно изменить или остановить до того, как он станет дорогим.

Именно в этом заключается ценность правильно спроектированного MVP.

4b:T26cd,

Многие компании до сих пор воспринимают обновление и поддержание ИТ-инфраструктуры как дополнительные расходы, которые можно отложить или минимизировать. Однако в реальности это инвестиции, которые необходимы для устойчивости и долгосрочного роста бизнеса. Обновление и оптимизация ИТ-систем — это не просто решение текущих проблем, это стратегический шаг, обеспечивающий стабильность, безопасность и эффективность бизнеса.

Что такое оптимизация ИТ-инфраструктуры

Оптимизация ИТ-инфраструктуры включает в себя улучшения в аппаратной и программной части системы, направленные на повышение производительности, безопасности и масштабируемости. Важно понимать, что это не только «перенастройка» существующих систем, но и создание основ для долгосрочной эффективности и стабильности бизнеса.

Инвестиции в обновление ИТ не должны рассматриваться как случайный расход. Это обязательная часть долгосрочной стратегии компании, которая позволит ей быть гибкой и готовой к изменениям на рынке. Модернизация ИТ-инфраструктуры — это основа для успешного расширения бизнеса, повышения его конкурентоспособности и снижения операционных рисков.

Как оптимизация ИТ-инфраструктуры влияет на бизнес

Обновление ИТ-систем помогает бизнесу стать более эффективным и безопасным. Современные технологии сокращают время обработки данных, минимизируют простои и улучшают клиентский опыт. Когда компании игнорируют необходимость обновлений, они рискуют столкнуться с высокой вероятностью сбоев в системе, что ведет к снижению продуктивности и потере доверия со стороны клиентов.

Для примера: компания, которая обновляет своё ПО и систему безопасности вовремя, может избежать потерь от киберугроз и системных сбоев, которые могут привести к огромным финансовым убыткам. Системы, которые обновляются вовремя, не только предотвращают дорогостоящие сбои, но и укрепляют долгосрочную конкурентоспособность компании.

Пример из практики:

Одна из наших клиентов, крупная розничная сеть, долгое время откладывала обновление своей ИТ-системы. Как результат — система начала работать с перебоями, и время обработки данных значительно увеличилось. После модернизации ИТ-инфраструктуры, время отклика на 40% сократилось, а простои снизились на 95%. Это позволило компании повысить производительность и улучшить качество обслуживания клиентов.

Обновление ПО — важнейший шаг к стабильности

Одним из самых критичных элементов оптимизации является обновление ПО. Важно понимать, что старые системы не только медленно работают, но и могут быть уязвимы для киберугроз. Кроме того, обновление ПО позволяет оптимизировать работу всех компонентов инфраструктуры, повышая их скорость и производительность.

Пример 1:

Компания X обновила свою систему безопасности, что позволило снизить количество инцидентов с безопасностью на 50%. Это обновление не только повысило уровень защиты данных, но и улучшило общий пользовательский опыт.

Пример 2:

После перехода на новую версию ПО, компания Y снизила время простоя на 35%, что позволило сэкономить значительную сумму на устранение инцидентов и повысить доверие со стороны клиентов.

Как правильно подойти к инвестициям в ИТ

Чтобы инвестиции в ИТ действительно стали стратегическим инструментом роста, важно понимать, что они должны быть направлены на решение реальных проблем бизнеса. Важно не только выбирать «модные» технологии, но и выбирать те, которые обеспечат долгосрочные результаты.

Прежде чем приступить к модернизации ИТ-инфраструктуры, следует ответить на несколько вопросов:

Какие именно проблемы вы решаете?
Как обновления улучшают бизнес-процессы?
Какие технологии помогут вам достигнуть ваших бизнес-целей?

Компания, которая инвестирует в ИТ, должна быть уверена, что эти вложения принесут конкретные результаты. Это может быть повышение безопасности, снижение операционных расходов или улучшение качества обслуживания клиентов.

Заключение

Инвестиции в ИТ-инфраструктуру — это не расходы, а ключевая составляющая стратегии роста и развития компании. Обновления и оптимизация ИТ-систем — это не только способ устранить текущие проблемы, но и создать прочную основу для успешного масштабирования, повышения безопасности и повышения конкурентоспособности компании.
Не откладывайте обновления и улучшения — инвестируйте в ИТ сегодня, чтобы обеспечить стабильность и рост в будущем.

Хотите узнать, как обновление ИТ-системы поможет вашему бизнесу стать стабильнее и эффективнее? Свяжитесь с нами для консультации по оптимизации ИТ-инфраструктуры.

4c:T23cf,

Для большинства CIO решение о том, стоит ли продолжать поддерживать текущую IT-систему или инвестировать в её развитие — это не только техническое, но и стратегическое решение. Оно влияет на бизнес-процессы, безопасность данных и долгосрочную стабильность компании. Однако этот выбор не всегда очевиден. Некоторые компании считают, что поддержка старой системы дешевле и менее рискованно, чем её замена или обновление, в то время как другие предпочитают инвестировать в модернизацию, чтобы улучшить гибкость и производительность. Но что делать, если устаревшая система всё еще работает, и CIO сталкивается с выбором, как решить этот вопрос?

Почему CIO боятся обновлять старые системы?

Проблема старых IT-систем часто скрыта за «иллюзией стабильности». Когда система работает, кажется, что всё в порядке. Однако, с каждым днем её способность поддерживать новые бизнес-требования и внедрять инновации снижается. Страх CIO в таких ситуациях не случайный. Модернизация системы — это риск, который требует значительных вложений и времени. Более того, каждое вмешательство в такую систему чревато неожиданными последствиями: неучтёнными зависимостями, проблемами с интеграцией и, что важнее, с безопасностью.

Какие риски скрыты за стабильностью старой системы?

Когда система выглядит стабильной, многие CIO ошибочно считают, что обновление — это лишняя трата ресурсов. Но старые системы не просто теряют эффективность — они скрывают риски, которые могут проявиться в самый неподходящий момент. Устаревшие компоненты становятся уязвимыми для кибератак, а отсутствие поддержки актуальных технологий ограничивает гибкость системы. Со временем старое ПО перестает справляться с возросшими требованиями бизнеса, и его модернизация становится необходимостью перед рисками:

Уязвимости безопасности: Старые системы часто не поддерживают последние обновления безопасности.
Неэффективность при увеличении нагрузки: Система может не справляться с пиковыми запросами и не выдерживать нагрузку.
Невозможность интеграции с новыми технологиями: Текущая система может быть несовместимой с новыми решениями.

«Системы, которые давно не обновлялись, имеют высокий уровень скрытых рисков. Они могут продолжать работать, но с каждым днем их способность отвечать на новые вызовы и потребности бизнеса снижается. CIO должны понимать: когда система уже в таком состоянии, то просто ждать, что она будет работать вечно — это не стратегия, а бездействие», — Вадим Зимин, начальник отдела ИТ инфраструктуры ЭНСАЙН.

Как избежать дорогостоящих ошибок в управлении IT-инфраструктурой?

Решение о поддержке или модернизации системы не всегда очевидно. Однако есть несколько принципов, которые могут помочь CIO избежать дорогостоящих ошибок:

Провести аудит текущего состояния системы: Это поможет понять, какие компоненты требуют немедленного обновления, а какие ещё могут оставаться стабильными.
Внедрить поэтапную модернизацию: Вместо того чтобы пытаться переписать всю систему, стоит постепенно обновлять её ключевые компоненты, сохраняя функциональность и минимизируя риски.
Регулярно мониторить систему: Круглосуточный мониторинг поможет оперативно выявлять проблемы и повысит качество работы системы.

Модернизация как залог успешного будущего компании

Модернизация IT-системы — это не просто устранение багов. Это основа для устойчивого развития компании в будущем. Система должна быть гибкой, безопасной и готовой к новым бизнес-вызовам. Когда CIO упускают этот момент, компания рискует попасть в ловушку устаревших технологий, которые создают проблемы, начиная от безопасности и заканчивая высокой стоимостью обслуживания.

Если ваша система не обновлялась давно, начните с технического аудита и оцените риски, связанные с её поддержанием. Принятие решения об обновлении сейчас поможет избежать больших затрат и сбоев в будущем.

Заключение

Когда CIO сталкиваются с выбором между поддержкой старой системы и её модернизацией, важно учитывать не только текущие потребности, но и долгосрочную стратегию бизнеса. Игнорирование рисков, связанных с устаревшими технологиями, может привести к серьезным проблемам в будущем. Поддержка — это не просто обслуживание системы, это основа для безопасной и эффективной работы компании в будущем.

Меры, предпринятые вами сейчас, помогут избежать больших проблем в дальнейшем.

4d:T63e0,

1. Бизнес-сущности приходится собирать из обходных конструкций CMS

Хороший проверочный вопрос:

если убрать ограничения текущей CMS, стала бы модель данных проекта заметно проще?

Если команда регулярно отвечает «да», часть бюджета уже расходуется на адаптацию продукта к платформе.

2. Сопоставимые изменения со временем становятся дороже

Допустим, 2 года назад команда добавила новый тип объекта. Сейчас появилась похожая по масштабу задача.

Сама бизнес-задача не стала сложнее. Стало дороже вмешиваться в существующую архитектуру.

«Я бы смотрел на стоимость следующего изменения. Если команда все чаще оценивает не саму новую функцию, а то, сколько придется потратить на аккуратный обход старых решений, проблема может быть уже не в конкретной задаче. Тогда стоит отдельно посмотреть на архитектуру CMS», — Алексей Постригайло, старший управляющий партнер ИТ-интегратора «Энсайн».

3. Команда не может быстро определить, где находятся актуальные данные

В сложном корпоративном проекте информация редко хранится только в одном месте.

4. Один и тот же контент приходится поддерживать в нескольких копиях

Чем больше таких копий, тем больше времени компания тратит на синхронизацию и исправление расхождений.

5. Реальный процесс работы с контентом происходит вне CMS

Посмотрите не на список функций административной панели, а на то, как сотрудники работают каждый день.

Формально система управления контентом есть. Фактически она участвует только в последнем шаге.

Это тоже затраты, просто они не видны в смете разработки.

6. Инфраструктура держится на постоянных исключениях вокруг платформы

Вопрос в количестве накопленных исключений.

Со временем в проекте могут появиться правила вроде:

этот компонент нельзя обновлять стандартным способом;
здесь нужно сохранять старую версию библиотеки;
этот модуль работает через отдельный механизм авторизации;
после обновления необходимо вручную проверить связанные функции.

Каждое такое решение можно объяснить историей проекта. Вместе они создают постоянную стоимость поддержки.

7. Ограничения CMS начинают менять дорожную карту бизнеса

Это самый серьезный признак.

Ситуация меняется, когда разговор начинает звучать иначе:

эту функцию пока лучше не делать из-за устройства CMS;
придется ждать новую версию;
изменение ядра слишком рискованно;
нужный сценарий потребует слишком большой переделки;
часть требований проще убрать.

Один признак еще не означает, что CMS нужно менять

Сложная доработка — не повод писать собственную систему.

Большая интеграция — тоже.

Даже несколько неудачных архитектурных решений еще можно исправить внутри существующей платформы.

Смотреть нужно на сочетание симптомов.

Как проверить, сколько денег уходит именно на ограничения CMS

Для первого вывода не обязательно начинать с большого технического аудита.

Достаточно взять несколько заметных доработок за последний период и разобрать фактические трудозатраты.

Для каждой задачи их стоит разделить на 2 части.

Работа над самой бизнес-функцией

То, ради чего задача вообще появилась:

новый пользовательский сценарий;
новый тип объекта;
интеграция;
функция для редакторов;
изменение бизнес-процесса.

Работа, появившаяся из-за текущей CMS

Например:

дополнительные адаптеры;
изменение старых модулей;
обход ограничений платформы;
сохранение совместимости;
миграции из-за внутренней структуры CMS;
дополнительное тестирование зависимых участков.

После такого разбора становится видно, за что компания действительно платит.

Конкретная пропорция здесь не является нормативом.

Если да, это уже аргумент для отдельного расчета другой платформы или собственного ядра.

Что не является достаточной причиной для собственной CMS

«Хотим перестать зависеть от готовой платформы»

Собственная CMS уберет зависимость от производителя.

Взамен появится зависимость от собственного кода, документации и команды, которая умеет его поддерживать.

Поэтому сама независимость ничего не говорит о выгоде решения.

«Своя система будет гибче»

Будет.

«Нам не нравится административная панель»

Неудобный интерфейс еще не говорит о проблеме архитектуры.

Если вопрос только в работе редакторов, дешевле может оказаться переработка административной части.

Что делать, если несколько признаков совпали

Не начинать разработку новой CMS на следующий день.

Следующий шаг — сравнить 2 сценария на одной и той же дорожной карте продукта.

Первый — оставить текущую платформу.

Второй — перейти на другое управляющее ядро.

Результат вполне может показать, что еще несколько лет выгоднее развивать существующую CMS.

Это нормальный вывод.

Если несколько признаков совпали

Следующий шаг — не заказывать новую CMS, а посчитать оба сценария на реальных данных проекта.

Оценить архитектуру веб-проекта →

Что в итоге

Собственная CMS нужна не тогда, когда готовую приходится дорабатывать.

Доработки сами по себе нормальны.

На это указывают 7 признаков:

бизнес-сущности приходится собирать из обходных конструкций;
сопоставимые изменения со временем становятся дороже;
сложно определить, где находятся актуальные данные;
один контент приходится поддерживать в нескольких копиях;
реальные процессы работы с контентом происходят вне CMS;
инфраструктура держится на постоянных исключениях вокруг платформы;
ограничения CMS начинают влиять на дорожную карту бизнеса.

Один симптом еще ничего не доказывает.

Если вторая часть системно растет, собственную CMS уже имеет смысл включать в расчет.

Не ради собственного решения как такового.

А потому, что в определенный момент сохранять старую архитектуру может оказаться дороже, чем заменить ее.

4e:T50da,

ИИ в бизнесе проходит важный этап взросления. Еще недавно компании активно запускали чат-ботов, добавляли нейросети в коммуникации и тестировали генерацию текстов, ответов, писем и кратких справок.

Но постепенно стало понятно: одного диалога с ИИ бизнесу недостаточно.

Чат-бот может ответить на вопрос. Иногда быстро, грамотно и вежливо. Но для компании важен не сам ответ, а результат: подготовленный отчет, обработанная заявка, найденная причина отклонения, собранная аналитика, корректно заполненный документ или сокращение ручной работы.

Поэтому фокус смещается. Бизнес начинает смотреть не на ИИ как на отдельное окно для переписки, а на ИИ-помощника, встроенного в конкретный процесс.

Разница принципиальная.

Чат-бот общается. ИИ-помощник получает задачу, обращается к данным, учитывает права пользователя и помогает выполнить часть работы.

Ниже — 3 показательных примера из рынка.

Сбер: ИИ встраивают в маркетинговые процессы

Сбер представил мультиагентную ИИ-систему «Маркус» для маркетинга и коммуникаций. По данным компании, система помогает с аналитикой, мониторингом информационного поля, подготовкой материалов и другими задачами маркетинговой команды.

В этом кейсе важен не только сам запуск ИИ-инструмента. Ключевой момент — предварительная работа с процессами. Перед внедрением Сбер разобрал маркетинговые и коммуникационные функции, укрупнил их и выделил направления для дальнейшей автономизации.

Именно с этого обычно и должна начинаться работа с ИИ.

Не с выбора модели. Не с покупки доступа к нейросети. Не с идеи «давайте сделаем агента для всего отдела».

Сначала нужно понять, какие действия в подразделении повторяются, где сотрудники тратят больше всего времени и какие операции можно безопасно передать системе.

Источник: Сбер о запуске «Маркуса»

Билайн: ценность ИИ появляется при доступе к данным

Билайн Big Data & AI открыл демодоступ к новым ИИ-агентам для бизнеса: «Помощнику аналитика» и «Маркетологу».

«Помощник аналитика» рассчитан на работу с бизнес-показателями. Он помогает искать причины отклонений, анализировать воронку продаж, отток клиентов и другие параметры, которые важны для управленческих решений.

Здесь хорошо видно главное отличие ИИ-помощника от обычного чат-бота.

Если система не подключена к данным компании, она может давать только общие рассуждения. Например, перечислить типовые причины падения продаж или роста оттока. Но она не сможет объяснить, что именно происходит в конкретном бизнесе.

Для реальной пользы помощнику нужны источники данных: CRM, отчеты, база обращений, история сделок, справочники, документы, BI-контур. И вместе с этим — правила доступа, журналирование действий и понятная логика работы с информацией.

Сам интерфейс чата здесь не самая сложная часть. Гораздо сложнее корректно подключить данные и сделать так, чтобы система не создавала новые риски.

Источник: Билайн о демодоступе к ИИ-агентам

2ГИС: ИИ становится интерфейсом к сложному продукту

В «2ГИС Про» появился ИИ-помощник для геоаналитики. Пользователь может описать задачу обычным языком, например попросить оценить потенциал локации для бизнеса. Система формирует интерактивный отчет на карте с данными и выводами.

Этот пример интересен не только для геоаналитики.

Он показывает, как ИИ может стать новым интерфейсом к сложной системе. Раньше пользователю нужно было самому выбирать слои, фильтры, параметры и собирать отчет. Теперь часть этого пути можно начать с обычного вопроса.

Для корпоративных систем это важное направление.

Во многих компаниях внутренние продукты со временем становятся функционально богатыми, но сложными для сотрудников. В них много разделов, ролей, справочников, отчетов и сценариев. ИИ-помощник может сократить путь до нужного действия, если он встроен в систему и понимает ее структуру.

Источник: ComNews о запуске ИИ-помощника в 2ГИС Про

Почему бизнесу уже мало чат-бота

Во всех трех примерах ИИ работает не сам по себе.

У Сбера он связан с маркетинговыми функциями.
У Билайна — с аналитикой и корпоративными данными.
У 2ГИС — с геоаналитическим сервисом и пользовательским сценарием.

Это и есть главный сдвиг.

Бизнесу нужен не еще один чат, а помощник, который встроен туда, где возникает рабочая задача.

Если менеджер готовится к звонку, система должна собрать историю клиента и текущие договоренности. Если аналитик ищет причину отклонения в показателях, помощник должен обращаться к реальным данным. Если сотрудник работает в сложной внутренней системе, ИИ должен помогать быстрее пройти к нужному действию.

Без такой связи ИИ остается отдельным инструментом. Сотруднику приходится открывать еще одно окно, вручную копировать туда информацию и потом переносить результат обратно в рабочую систему.

В таком формате автоматизация получается поверхностной.

Что нужно подготовить перед внедрением ИИ-помощника

Полезный ИИ-помощник начинается не с промптов и не с выбора конкретной модели. Он начинается с разборки процесса.

Компании нужно ответить на несколько вопросов.

Какую задачу должен выполнять помощник

Формулировка «внедрить ИИ в продажи» слишком широкая. С ней сложно работать и почти невозможно оценить результат.

Гораздо лучше выбрать узкий сценарий:

подготовка краткой сводки по клиенту перед звонком;
поиск ответа в базе знаний поддержки;
первичная классификация обращения;
сбор данных для отчета;
подготовка черновика документа;
поиск расхождений в показателях.

Чем конкретнее задача, тем проще проверить, помогает ИИ или просто создает видимость автоматизации.

Какие данные ему нужны

ИИ-помощник не может качественно работать в отрыве от корпоративной информации.

Если данные разрознены, устарели или хранятся в разных версиях, помощник начнет воспроизводить этот хаос. Он может сформулировать ответ уверенно, но это не сделает исходные данные правильными.

Перед внедрением важно понять, где находятся нужные источники, кто за них отвечает, как часто они обновляются и по каким правилам система должна к ним обращаться.

Какие действия можно доверить системе

Не каждый сценарий требует полной автономности.

На первом этапе помощник может только готовить черновик, подсказку или аналитическую сводку. Финальное решение остается за сотрудником.

Такой подход снижает риски и помогает постепенно накапливать доверие к системе. Особенно если речь идет о клиентских коммуникациях, финансовых данных, юридически значимых документах или управленческих решениях.

Как будет измеряться результат

Запуск ИИ-помощника нельзя оценивать только по тому, что он отвечает на вопросы.

Нужны понятные показатели: сколько времени экономится, сколько ручных действий исчезает, насколько быстрее обрабатываются обращения, как меняется нагрузка на сотрудников, уменьшается ли количество ошибок.

Без метрик любой пилот можно объявить успешным. Но для бизнеса важен не сам факт запуска, а изменение процесса.

Где чаще всего возникают сложности

На практике основные проблемы обычно связаны не с нейросетью.

Модель можно выбрать. Интерфейс можно разработать. Прототип можно показать достаточно быстро.

Сложности начинаются глубже:

процессы не описаны;
данные противоречат друг другу;
нет единой логики прав доступа;
документы устарели;
интеграции с внутренними системами требуют доработки;
сотрудники по-разному понимают правильный результат;
компания не определила, что именно хочет улучшить.

Поэтому ИИ-проекты часто хорошо выглядят на демонстрации, но буксуют при переходе в промышленную эксплуатацию.

Пилот работает на ограниченном наборе данных и заранее подготовленных сценариях. Реальная эксплуатация сталкивается с исключениями, ошибками, разными ролями пользователей, неполными данными и высокой ответственностью за результат.

«Сейчас бизнесу нужен не ИИ, который просто отвечает на вопросы, а инструмент, встроенный в рабочую среду и привязанный к конкретному процессу. Но такой помощник не появляется из воздуха. Сначала нужно разобраться с данными, правами доступа, интеграциями и логикой самой работы. Иначе компания получает еще один интерфейс, который создает шум вместо результата», — Алексей Постригайло, старший партнер ИТ-⁠интегратора «Энсайн».

Какой подход выглядит наиболее рабочим

Самый надежный путь — начинать с узкого сценария.

Не пытаться сразу автоматизировать весь отдел. Не строить универсального агента для всех задач. Не подключать систему ко всем данным компании без ограничений.

Лучше выбрать один процесс, где:

задача повторяется регулярно;
данные уже есть в цифровом виде;
результат можно проверить;
цена ошибки понятна;
сотрудник может контролировать итог.

После этого можно описать процесс, подключить нужные источники, настроить права, запустить пилот на ограниченной группе и сравнить показатели до и после внедрения.

Такой подход выглядит менее громко, чем запуск большого универсального ИИ-агента. Но именно он чаще приводит к рабочему результату.

Вывод

Бизнес постепенно уходит от идеи «добавить чат-бота» к более зрелому подходу: встроить ИИ в конкретный процесс.

ИИ-помощник приносит пользу не потому, что умеет красиво отвечать. Его ценность появляется там, где он подключен к данным, понимает задачу, действует в рамках прав пользователя и сокращает ручную работу.

Для компаний это означает простую вещь: перед внедрением ИИ нужно смотреть не только на модель, но и на собственную цифровую среду.

Если процессы не описаны, данные не готовы, а права доступа настроены формально, ИИ быстро начнет производить больше шума, чем пользы.

Если же у компании есть понятный сценарий, качественные данные и готовность встроить помощника в рабочую систему, ИИ может стать не модной надстройкой, а нормальным инструментом повышения эффективности.

В этом и заключается главный переход: от ИИ, который отвечает, к ИИ, который действительно помогает выполнять работу.

4f:T2524,

Когда речь идет о выборе SLA (Service Level Agreement) для ИТ-⁠поддержки, важно понимать, что это основной инструмент для оптимизации ваших ИТ-⁠расходов и повышения стабильности работы системы. Выбор SLA должен зависеть от конкретных нужд вашего бизнеса и бюджета, а также от того, какой уровень обслуживания критичен для вашей компании.

Понимание потребностей бизнеса

Первый шаг — это четкое понимание, какие ИТ-⁠системы требуют большего внимания и ресурсов. Это поможет вам выбрать необходимый уровень обслуживания.

Пример:

Если вы управляете облачной инфраструктурой с высоким трафиком и множеством клиентов, то минимальные SLA с ограничением по времени отклика вам не подойдут. Здесь нужна круглосуточная поддержка с быстрым временем реакции, потому что каждый час простоя может привести к большим убыткам.
Для небольших внутренних систем, где простоят не более нескольких часов, подойдет SLA с ограниченными временными рамками и низким приоритетом.

Если ваша ИТ-⁠инфраструктура критична для ежедневных операций бизнеса, необходимо выбирать высокий уровень обслуживания, что, конечно, будет стоить дороже.

Разделение SLA на уровни обслуживания

Все SLA можно условно разделить на несколько уровней в зависимости от нужд вашего бизнеса:

Базовый: Покрывает стандартные задачи, такие как стандартные запросы и поддержка в рабочие часы. Подходит для несложных систем, где не критична скорость реакции.
Средний: Включает круглосуточную поддержку с конкретными сроками отклика (например, 1–⁠2 часа на решение проблемы). Идеален для компаний с умеренными требованиями, где нужен баланс между ценой и качеством.
Высокий: Круглосуточная поддержка с минимальными сроками отклика, часто с возможностью индивидуальных изменений в зависимости от ситуации. Этот уровень обслуживания подходит для крупных компаний с высокими требованиями к ИТ-⁠инфраструктуре и минимальным временем простоя.

Соответственно — чем выше уровень SLA, тем дороже его обслуживание, но это также означает меньше простоя, меньше рисков и более оперативную помощь.

Оценка уровня обслуживания и соответствия вашему бюджету

При выборе SLA важно понимать, что вы получаете за свои деньги. Например, если вы выбрали круглосуточную поддержку, но вам не нужно, чтобы на каждый запрос отвечали в течение 15 минут, это можно корректировать. Вы можете договориться о растянутых сроках отклика, чтобы снизить цену, но оставить круглосуточную поддержку для срочных случаев. Важно также понимать, что такие услуги, как помощь в обновлениях, тестировании безопасности, добавление новых функциональностей обычно идут за дополнительную плату.

Соглашение должно быть гибким

Любой SLA должен быть гибким. Это важно, так как потребности бизнеса и ИТ-⁠системы могут меняться со временем. Например, ваш бизнес может расшириться, добавиться новые отделы или функции, и поддержка, которую вы изначально выбрали, может оказаться недостаточной. В этом случае вам понадобится возможность перехода на более высокий уровень SLA.

ИТ-поддержка и бюджет: как правильно выбрать уровень SLA

Придерживайтесь гибкости при согласовании SLA, чтобы можно было переходить между уровнями обслуживания без лишних затрат. Убедитесь, что ваши контракты позволяют изменение условий SLA в случае роста или изменений в бизнесе.

«Соглашение должно быть зеркалом вашего бизнеса: его масштабы, потребности и скорости меняются и SLA должен адаптироваться, а не оставаться фиксированным», — Вадим Зимин, начальник отдела ИТ инфраструктуры Энсайн.

Следите за выполнением SLA

Вы не сможете оценить эффективность SLA, если не будете постоянно отслеживать, как он выполняется. Для этого полезно:

Установить метрики производительности (например, время отклика, время на решение проблемы, количество успешных решений).
Внедрить систему для отслеживания и анализа работы службы поддержки. Это поможет определить слабые места и быстро на них реагировать.

И, конечно, важно, чтобы ваша команда могла гибко реагировать на изменения и проводить ревизию SLA при необходимости.

Подведем итоги

Выбор правильного SLA для ИТ-⁠поддержки — это важный шаг, который напрямую влияет на качество обслуживания и производительность вашей компании. Определите ваши потребности, сбалансируйте цену и качество, и выберите уровень обслуживания, который соответствует вашим требованиям. Только так вы сможете гарантировать, что ИТ-⁠система будет работать эффективно, а поддержка не будет вызывать лишних затрат.

50:T230f,

Компания «Энсайн» открыла внешним пользователям доступ к HConfig — консольному инструменту для автоматизированной настройки серверов и управления Linux-инфраструктурой.

Ранее решение применялось внутри компании при запуске, переносе и сопровождении веб-проектов. В апреле 2026 года HConfig был включен в реестр российского и евразийского программного обеспечения.

Номер реестровой записи — 32983 от 17 апреля 2026 года.

Теперь инструмент доступен компаниям, разработчикам и ИТ-командам, работающим с Linux-серверами.

Зачем был создан HConfig

Настройка серверного окружения включает множество повторяющихся операций: создание пользователей, установку необходимых компонентов, развертывание баз данных, подключение сертификатов и настройку резервного копирования.

Если эти действия выполняются вручную, конфигурация постепенно начинает зависеть от опыта и памяти конкретного специалиста. Это усложняет передачу системы другой команде, миграцию между площадками и восстановление инфраструктуры после сбоев.

HConfig создавался как внутренний инструмент стандартизации таких процессов. Его задача — сократить объем ручной работы и привести настройку серверов к единому и воспроизводимому порядку.

«Ручная настройка серверов давно стала слабым местом инфраструктурных проектов. Пока все держится на памяти и аккуратности одного специалиста, запуск и перенос проектов остаются плохо предсказуемыми. HConfig уменьшает количество ручных операций и делает сопровождение инфраструктуры понятнее», — отмечает Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Какие задачи автоматизирует HConfig

Инструмент позволяет:

создавать пользователей веб-сервера;
настраивать окружение под технологический стек проекта;
устанавливать PHP-модули и зависимости;
разворачивать MySQL и PostgreSQL;
подключать SSL-сертификаты и Let’s Encrypt;
автоматизировать резервное копирование;
переносить и публиковать веб-контент.

В состав HConfig входят модули install, webuser, phpmodules, mysql, postgres, sslstore и letsencrypt.

Модульная архитектура позволяет использовать только необходимые функции и адаптировать процесс развертывания под конкретную конфигурацию сервера.

Миграция и масштабирование инфраструктуры

Один из основных сценариев применения HConfig — перенос веб-проектов между серверами или инфраструктурными площадками.

При ручной миграции необходимо заново воспроизвести программное окружение, пользователей, права доступа, зависимости, базы данных и сертификаты. Если часть исходных настроек не была зафиксирована, особенности конфигурации могут обнаружиться уже после запуска проекта.

HConfig помогает подготовить новое окружение по единой модели. Это сокращает количество повторяющихся действий, снижает вероятность пропустить отдельную настройку и ускоряет масштабирование инфраструктуры.

Инструмент не отменяет тестирование и контроль со стороны инженеров. Он автоматизирует типовые операции и делает результат более воспроизводимым.

Поддерживаемые платформы

На текущем этапе HConfig протестирован и поддерживается на RedOS 8.

Использование со смежными Linux-дистрибутивами возможно, однако в отдельных случаях может потребоваться дополнительная адаптация. Дистрибутивы различаются составом репозиториев, версиями пакетов и системными настройками.

Нативно устанавливаются версии PHP, доступные в репозиториях выбранного дистрибутива. PHP версий от 7.1 до 8.5 может устанавливаться с использованием кастомных сборок.

Команда «Энсайн» продолжает расширять перечень поддерживаемых Linux-платформ и серверных конфигураций.

Почему мы открыли доступ к инструменту

HConfig объединяет инженерные практики, накопленные командой «Энсайн» при эксплуатации Linux-систем, настройке веб-площадок и сопровождении распределенной инфраструктуры.

Проблема ручной настройки и зависимости от знаний отдельных специалистов характерна для многих ИТ-команд. Поэтому мы решили сделать внутреннюю разработку доступной другим компаниям, интеграторам и разработчикам.

После включения HConfig в реестр российского и евразийского программного обеспечения доступ к решению был открыт для внешнего использования.

Где найти HConfig

HConfig зарегистрирован в реестре российского и евразийского программного обеспечения под номером 32983 от 17 апреля 2026 года.

Получить информацию об инструменте и доступ к нему можно на странице решения по ссылке.

51:T25dc,

CIO часто оказываются в трудном положении, когда нужно принять решение о модернизации legacy-системы. Эти системы, с одной стороны, играют критическую роль в бизнес-процессах компании, с другой — их модернизация связана с большим количеством рисков. CIO понимают, что риск отказа от обновлений или ошибок в процессе модернизации может быть разрушительным для бизнеса. Поэтому они откладывают изменения, даже когда понимают, что старые системы требуют модернизации. Но правильно ли это?

Основные причины страха CIO перед изменением legacy-системы

Риски безопасности
Старые системы не поддерживают современные протоколы безопасности. Их обновление или замена может привести к уязвимостям, если изменения не будут внедрены правильно. Это ставит под угрозу данные компании и может привести к утечке конфиденциальной информации. CIO, понимая последствия таких рисков, часто откладывают изменения.
Неопределенность интеграции новых решений
Старые системы часто имеют устаревшие компоненты, которые не могут поддерживать новые технологии. Любая попытка интегрировать новое решение может вызвать сбои в работе всей инфраструктуры. Этот процесс может затянуться, вызвать дополнительные затраты и привести к значительным проблемам в работе бизнеса.
Технический долг и сложность изменений
Старые системы — это зачастую сложная, неструктурированная архитектура, в которой изменения в одном месте могут повлиять на другие, неочевидные компоненты. Каждый новый компонент или обновление требует тщательного тестирования и проверки, что замедляет процесс и увеличивает риск ошибок.

«Когда мы начинаем работать с legacy-системой, важно понимать, что это не просто устранение ошибок, а управление рисками, которые накапливаются годами. Важно вовремя вмешаться, прежде чем система начнёт ломаться под нагрузкой. Каждый пропущенный этап в модернизации увеличивает вероятность катастрофы. Чем раньше начнём, тем меньше рисков для бизнеса в будущем. Важно не только снизить затраты на поддержку, но и ускорить решение задач бизнеса, что способствует росту доходов и прибыли», — Алексей Постригайло, партнер, ИТ-интегратор ЭНСАЙН.

Почему эти опасения оправданы?

Потери данных и потери безопасности
Старые системы становятся уязвимыми для кибератак, так как не могут эффективно противостоять современным угрозам. Их поддержка и модернизация, если не будет должным образом спланирована, могут привести к утечке данных или нарушению работы важнейших бизнес-процессов.
Неопределённость с интеграцией новых технологий
Старые системы, которые не поддерживают актуальные компоненты, создают ограничения для внедрения новых решений. Любая интеграция с такими системами требует дополнительных усилий и времени, что приводит к неопределенности и повышенным рискам.
Ресурсы и затраты
Модернизация legacy-системы требует значительных временных и денежных затрат, что делает её довольно сложной задачей для бизнеса. CIO понимают, что процесс может занять много времени и в некоторых случаях привести к сбоям и дополнительным затратам.

Как минимизировать риски при модернизации legacy-системы

Для минимизации рисков и успешной модернизации важно принимать осознанные решения. Вот несколько ключевых шагов:

Пошаговая модернизация: Вместо того чтобы переписывать всю систему, стоит начать с поэтапной модернизации. Это поможет минимизировать риски и обеспечить плавный переход.
Регулярный аудит безопасности: Очень важно включить экспертов по безопасности на ранних этапах, чтобы выявить уязвимости и минимизировать угрозы безопасности.
Тестирование и подготовка: Прежде чем внедрить изменения, важно протестировать компоненты и убедиться, что все изменения будут работать стабильно.

Когда изменения становятся неизбежными?

Если система не справляется с современными требованиями или устарела настолько, что не поддерживает актуальные функции, модернизация становится обязательной. В таких случаях CIO не должны бояться изменений, а должны сосредоточиться на том, как минимизировать риски и правильно подготовиться к процессу.

Если вы хотите узнать больше о рисках работы с legacy-системами и как избежать их в своей компании, ознакомьтесь с другими статьями:

Если ваша система устарела и требует модернизации, не ждите, пока возникнут серьёзные проблемы. Начните с аудита и плана поэтапной модернизации.

52:T721b,

Корпоративный портал редко оказывается бесполезным из-за неудачного дизайна. Обычно проблема проще: в нем нельзя закончить ни один рабочий процесс.

Сотрудник заполняет заявку, а дальше пишет руководителю. Скачивает договор, но согласовывает его по почте. Находит инструкцию по командировкам, после чего идет в мессенджер уточнять, кому отправить данные на билеты.

Портал вроде бы есть. Но работа проходит рядом с ним.

Мы регулярно сталкиваемся с такой ситуацией. Компания приходит с запросом на разработку или обновление корпоративного портала. Начинаем разбирать задачу и довольно быстро понимаем: дело не в главной странице, новостной ленте или профилях сотрудников.

Нужно смотреть глубже. Как внутри компании проходят заявки. Кто их согласовывает. Откуда берутся данные. В какой момент сотрудник вынужден переключиться на почту, таблицу или другую систему.

И только после этого становится понятно, каким должен быть портал.

Один запрос на командировку, а внутри — половина компании

Один из показательных проектов Энсайн был связан с управлением командировками сотрудников.

На старте задача выглядела довольно локально: собрать оформление поездок в одном интерфейсе. Но при разборе выяснилось, что никакой «простой заявки на командировку» там нет.

Сначала нужно проверить график сотрудника. Затем согласовать поездку. Построить маршрут. Подобрать транспорт и проживание. Рассчитать стоимость. Учесть компенсации. Передать данные во внутренние системы заказчика.

И это еще без нестандартных ситуаций: пересадок, сложных маршрутов, изменений дат, разных условий проживания.

Мы разработали корпоративный портал с CRM-контуром, который связывал эти этапы в один процесс. Система работала с сервисами бронирования и внутренними решениями заказчика, учитывала варианты логистики, рассчитывала стоимость поездки, формировала график сотрудника и данные по компенсациям.

Для пользователя все выглядело просто: одна заявка, один понятный маршрут, один статус.

Внутри при этом работали несколько систем и подразделений.

Именно в этом, на мой взгляд, заключается правильная роль корпоративного портала. Он не должен заменять бухгалтерию, кадровую систему, CRM, документооборот и внешние сервисы. Его задача — соединить их так, чтобы сотруднику не приходилось разбираться, где заканчивается одна система и начинается другая.

Пользователю вообще неважно, сколько решений работает внутри. Если он вынужден вручную переносить данные между ними, интеграцию не закончили.

Форма на портале — еще не автоматизация

Это одна из самых частых ошибок.

На портал переносят заявление на отпуск, заявку на доступ или запрос на закупку. Интерфейс становится удобнее. Заявка выглядит аккуратно. Но после отправки сотрудник отдела кадров копирует данные в учетную систему, администратор уточняет детали в чате, а руководитель согласует все по почте.

Для сотрудника изменился первый экран. Для компании почти ничего не поменялось.

Процесс действительно автоматизирован, когда:

данные не приходится вводить повторно;
система сама определяет маршрут;
сотрудник видит статус без звонков;
результат фиксируется там, где он должен храниться;
нестандартные случаи передаются человеку, а не ломают весь процесс.

Это важнее количества модулей и разделов.

Можно сделать портал на двадцать функций, которым никто не пользуется. А можно автоматизировать три болезненных процесса и получить заметный эффект уже на первом этапе.

С чего начинать

Не с самых сложных процессов. И не с тех, которые нравятся руководству больше остальных.

Для первого этапа лучше выбирать то, что регулярно повторяется и заметно раздражает сотрудников.

Хороший кандидат обычно выглядит так:

в процессе участвуют несколько подразделений;
люди постоянно уточняют статус;
данные переносят вручную;
правила в целом понятны;
результат можно измерить;
есть человек, который отвечает за процесс целиком.

Чаще всего первыми оказываются командировки, кадровые запросы, доступы, внутренние заявки и согласования.

Ниже — процессы, которые стоит проверить в первую очередь.

1. Командировки

Я бы начинал именно с них, если поездки занимают заметную часть работы компании.

Командировка быстро показывает все слабые места внутренней автоматизации. Здесь есть согласования, деньги, графики, внешние сервисы и учетные системы.

Если процесс собран правильно, сотрудник не выясняет отдельно:

кто согласует поездку;
где купить билеты;
какие расходы допустимы;
какие документы нужны после возвращения;
когда поступит компенсация.

Все это должно быть частью одного сценария.

Для руководства важен другой результат: видна стоимость поездок, причины отклонений, сроки согласования и общая нагрузка на подразделения.

То есть портал решает не только пользовательскую задачу. Он дает управленческую картину.

2. Прием и увольнение сотрудников

На схеме этот процесс всегда выглядит логично. Кадры оформляют сотрудника, ИТ выдает доступы, руководитель готовит задачи.

В реальности что-то почти всегда забывают.

Сотрудник уже вышел, но рабочее место еще не готово. Пропуск выдан, но доступ к системе не открыт. Уволившийся человек продолжает числиться владельцем документов или рабочих групп.

На портале можно создать единый процесс, в котором каждый участник видит свою часть работы и общий срок.

При увольнении тот же механизм запускается в обратную сторону. Доступы закрываются, оборудование возвращается, проекты передаются.

Ценность здесь не в цифровом чек-листе. Она в том, что процесс перестает держаться на памяти конкретного сотрудника.

3. Доступы и оборудование

С доступами обычно все начинается с сообщения администратору.

«Откройте мне систему».

Дальше выясняется, какую именно роль нужно выдать, кто должен согласовать запрос и имеет ли сотрудник право видеть эти данные.

Если компания растет, ручная схема быстро перестает работать. Доступы выдаются с задержкой, старые права не пересматриваются, а основания остаются в переписке.

В корпоративном портале запрос можно связать с должностью, подразделением и типовой ролевой моделью.

Стандартные права выдаются по понятному маршруту. Нестандартные уходят владельцу системы или службе безопасности.

В итоге руководство может ответить на простые, но важные вопросы: кто имеет доступ к критичной системе, кто его согласовал и почему эти права до сих пор активны.

4. Отпуска и кадровые запросы

Кадровые процессы — хороший вариант для пилота. Они знакомы всем и обычно не требуют долгого объяснения ценности.

Сотрудник оформляет отпуск, получает справку, меняет персональные данные или отправляет запрос на компенсацию.

Слабое место появляется там, где портал заканчивается.

Если кадровик после получения заявки вручную переносит данные в учетную систему, работа не автоматизирована. Просто у нее появился новый вход.

Правильный сценарий должен завершаться обновлением данных в системе-источнике. Без лишнего копирования и повторных проверок.

5. Внутренние заявки

Чем крупнее компания, тем сложнее сотруднику понять, куда обращаться.

Вопрос по оборудованию — в ИТ. По договору — к юристам. По пропуску — в административный отдел. По справке — в кадры.

Сотрудник не обязан знать внутреннюю структуру компании.

На портале он должен выбирать услугу или просто описывать задачу. Дальше система сама определяет, кто отвечает за результат.

Мы считаем процесс рабочим, когда человеку не нужно сопровождать заявку личными сообщениями. Отправил, увидел срок, получил результат.

Для руководства здесь появляется еще один полезный слой: можно увидеть, какие службы перегружены, где постоянно нарушаются сроки и какие вопросы сотрудники задают снова и снова.

6. Договоры и согласования

Договор редко согласует один человек.

Он проходит через инициатора, руководителя, юриста, финансовую службу, безопасность. Иногда подключаются и другие участники.

При работе через почту быстро появляются несколько версий. Один согласующий комментирует старый файл, другой уже работает с новым. Через месяц никто не может уверенно сказать, почему спорное условие осталось в документе.

Портал помогает собрать маршрут и историю решений в одном месте.

Но здесь есть ограничение, которое часто недооценивают.

Нельзя автоматизировать порядок, которого нет.

Если каждый договор согласуется по новым правилам, а полномочия зависят от личной договоренности, сначала придется навести порядок в самом процессе. Разработка начинается после этого, а не до.

7. Закупки и счета

Закупку часто начинают автоматизировать с оплаты. Это слишком поздно.

До счета уже успела появиться потребность, был выбран поставщик, согласован бюджет и подписан договор.

Если эти этапы живут отдельно, руководство видит только финальную сумму, но не понимает, где процесс задержался и почему закупка заняла столько времени.

Через корпоративный портал можно связать весь путь: от заявки до постановки приобретения на учет.

Сотрудник видит один процесс. Финансовая служба, закупки, юристы и бухгалтерия — свои этапы.

Не нужно собирать все данные внутри портала. Достаточно правильно соединить системы, в которых они уже хранятся.

8. Проекты и задачи

Сам по себе список задач пользы не дает.

Через несколько месяцев после запуска в компании нередко появляются два параллельных мира. В одном задачи стоят на портале. В другом команда реально работает — в мессенджере, таблице или профессиональном трекере.

Так случается, когда портал пытаются использовать как замену всем инструментам сразу.

Я бы не ставил такую цель.

Гораздо полезнее связать задачи с контекстом: проектом, решением встречи, документом, сроком и ожидаемым результатом. А если команда уже работает в специализированной системе, получать оттуда данные, а не создавать второй список.

Портал должен упрощать работу. Не заставлять сотрудников обновлять одно и то же в двух местах.

9. База знаний

С базой знаний проблема обычно не в количестве документов.

Их как раз хватает.

Сложно понять, какой из них актуален, кто отвечает за обновление и что сотруднику нужно сделать после прочтения.

Регламент без владельца быстро устаревает. Инструкция без связи с процессом превращается в справочный текст, после которого человек все равно идет искать исполнителя.

Поэтому материал о получении доступа должен вести к заявке на доступ. Правила командировок — к запуску командировки. Инструкция по системе — к форме поддержки.

Тогда база знаний становится частью работы, а не архивом документов.

10. ИТ-инциденты и внутренние изменения

Когда перестает работать важная система, команда теряет время не только на поиск причины.

Нужно собрать специалистов, определить приоритет, уведомить пользователей, зафиксировать ход восстановления.

Если все происходит в нескольких чатах, информация быстро расходится.

Портал может показывать сотрудникам простой статус: что не работает, кого затронула проблема и когда ожидается восстановление. Техническая команда при этом продолжает работать в своей системе.

Похожая логика нужна при внутренних изменениях.

Опубликовать новость о новом регламенте недостаточно. Нужно определить, кого изменение затронуло, обновить инструкции, провести обучение и проверить, что новый порядок действительно используется.

Почему проекты корпоративных порталов буксуют

По тому, что мы видим на проектах, причина редко в технологии.

Чаще компания пытается автоматизировать процесс, который никто не может одинаково описать.

На встрече руководитель говорит одно. Исполнитель — другое. В регламенте написано третье. А в реальности все работает по личным договоренностям.

Разработчики в такой ситуации начинают превращать исключения в системные правила. Появляются десятки условий, ручные обходы и спорные статусы.

Вторая частая ошибка — начинать с дизайна.

Команда обсуждает блоки на главной странице, когда еще не определено, какие задачи сотрудник должен решать через портал.

Третья — дублировать данные. Пытаться хранить в портале кадровую, финансовую и проектную информацию, хотя для этого уже есть отдельные системы.

И четвертая — запускать сразу все.

Большой проект на несколько десятков процессов сложно согласовывать, тестировать и внедрять. Люди устают от изменений еще до запуска.

Лучше выбрать несколько процессов, довести их до результата и только потом расширять контур.

Как быстро проверить действующий портал

Возьмите три самые популярные функции и пройдите их как обычный сотрудник.

Допустим, оформить отпуск, заказать оборудование и согласовать договор.

Посмотрите, что происходит после отправки.

Нужно ли писать кому-то отдельно? Повторно вводить данные? Заходить в другую систему? Можно ли увидеть статус? Понятно ли, когда задача будет завершена?

Если после формы начинается ручная переписка, портал пока работает как витрина.

Возможно, хорошая и современная. Но все еще витрина.

Что должен дать аудит

Начинать разговор о новом корпоративном портале с выбора платформы я считаю ошибкой.

Сначала нужно понять, где компания теряет время.

Для этого достаточно разобрать 3–5 процессов. Не по регламентам, а так, как они проходят на самом деле.

Кто запускает процесс. Кто принимает решение. Где данные копируются вручную. Какие системы участвуют. Где сотрудники обходят официальный маршрут.

После такого разбора становится видно, что действительно нужно автоматизировать, а что можно исправить без разработки.

В Энсайн результатом аудита становится карта процессов, перечень узких мест, схема интеграций и состав первого этапа.

Это уже предметный материал для внутреннего обсуждения. Руководство понимает, какой процесс меняется, сколько подразделений он затрагивает и по каким показателям можно оценивать результат.

Вместо вывода

Корпоративный портал нужен не для того, чтобы собрать в одном месте больше информации.

Его задача — сократить путь от запроса до результата.

Сотрудник не должен знать, в какой системе хранятся данные, кто вручную переносит их между отделами и кому писать, если процесс остановился.

Он должен видеть одну понятную последовательность действий.

Руководство — сроки, стоимость и точки задержки.

Если этого нет, обновление интерфейса мало что изменит.

Поэтому разработку корпоративного портала мы начинаем не с макетов. Сначала разбираем процессы, роли и данные. Смотрим, какие системы уже используются и где между ними рвется маршрут.

И только после этого становится понятно, что именно нужно разрабатывать.

53:T6757,

Поэтому правильнее не пытаться найти один список «видов CMS», а разобраться в этих различиях отдельно.

Почему готовая, собственная и headless — не три одинаковых типа CMS

Представим два корпоративных сайта.

Первый работает на готовой CMS. Второй — на системе, которую разработали специально для компании.

Это различие по происхождению системы.

Это уже различие по архитектуре.

Получается, что готовая CMS вполне может быть headless. Собственная тоже.

Именно поэтому дальше разделим эти вопросы.

Готовая CMS

Готовая CMS — это программный продукт, который существовал еще до начала конкретного проекта.

Например:

WordPress;
Drupal;
«1С-Битрикс: Управление сайтом».

Для обычного корпоративного сайта это часто разумная отправная точка.

Где начинаются ограничения готовой CMS

Сам факт доработки еще не означает, что система выбрана неправильно.

Проблема появляется позже — когда исключений становится слишком много.

Каждую такую задачу можно решить.

Если второй сценарий становится постоянным, преимущество готового продукта начинает уменьшаться.

Собственная CMS

У собственной CMS другая отправная точка.

Это не означает разработку абсолютно всего с нуля.

Допустим, компания управляет большой сетью объектов.

Готовую CMS тоже можно под это настроить.

Для сложных проектов это может заметно упростить дальнейшее развитие.

У собственной CMS есть цена

Собственная разработка дает больше контроля, но этот контроль приходится оплачивать.

После запуска ответственность тоже остается у команды проекта.

Поэтому писать свою CMS только ради «гибкости» — слабая причина.

Своя система оправдана тогда, когда эта свобода действительно нужна проекту и используется постоянно.

Готовая или собственная CMS: в чем разница

Критерий	Готовая CMS	Собственная CMS
Базовые функции	Уже есть	Нужно разработать или интегрировать
Скорость старта	Обычно выше	Обычно ниже
Затраты на старте	Обычно ниже	Обычно выше
Нестандартные процессы	Реализуются доработками	Можно заложить сразу
Модель данных	Зависит от устройства платформы	Проектируется под систему
Обновления ядра	Выпускает разработчик CMS	Организует команда проекта
Основной риск	Упереться в ограничения платформы	Получить дорогую систему, которую нужно постоянно поддерживать

Важный момент здесь не в том, какой столбец выглядит лучше.

Просто расходы и ограничения находятся в разных местах.

Классическая CMS

Теперь посмотрим на другой признак.

В классической CMS система управления и сайт обычно тесно связаны.

Для большого количества корпоративных проектов это нормальная и понятная модель.

Чем меньше отдельных компонентов, тем проще обычно поддержка и эксплуатация.

Headless CMS

В headless-подходе CMS занимается контентом, но не отвечает за то, как он выглядит для конечного пользователя.

Сайт получает данные через API и отображает их самостоятельно.

Представим обычную услугу. В CMS хранятся название, описание, изображение, документы и контакты.

Редактор при этом меняет услугу в одном месте.

Это и есть главное отличие headless: контент существует независимо от конкретной страницы или интерфейса.

Зачем отделять CMS от сайта

Такой подход особенно полезен, когда один и тот же контент нужен сразу нескольким системам.

Например, компания ведет основной сайт, мобильное приложение и несколько региональных проектов.

При headless-подходе данные хранятся централизованно, а интерфейсы используют один источник.

Есть и вторая причина — свобода разработки пользовательской части.

Почему headless подходит не каждому проекту

Разделение системы добавляет новую сложность.

Для большого продукта это может быть оправдано.

Для сайта компании из нескольких десятков информационных страниц — уже не факт.

Классическая и headless CMS: в чем разница

Критерий	Классическая CMS	Headless CMS
Связь CMS и сайта	Тесная	Разделены
Получение контента	Обычно внутри одной платформы	Через API
Один корпоративный сайт	Типовой сценарий	Возможен, но не всегда нужен
Несколько сайтов и приложений	Зависит от системы	Один из основных сценариев
Свобода frontend	Зависит от платформы	Выше
Техническая сложность	Обычно ниже	Обычно выше
Повторное использование контента	Возможно	Закладывается в архитектуру

Как эти подходы сочетаются

Здесь как раз становится видно, почему не стоит ставить готовую, собственную и headless CMS в один ряд.

Компания может взять готовую CMS и использовать ее в классическом варианте.

Это не противоречие.

По каким еще признакам различают CMS

Готовая или собственная, классическая или headless — не единственные характеристики.

Есть еще как минимум два различия, которые часто встречаются при обсуждении CMS.

Коммерческие и с открытым исходным кодом

Например, WordPress и Drupal относятся к open source. «1С-Битрикс: Управление сайтом» — коммерческий продукт.

И наоборот, коммерческая лицензия не говорит о том, подходит система конкретному проекту или нет.

Это всего лишь один из параметров.

Облачные и на собственной инфраструктуре

Еще одно различие — где работает CMS.

У обоих подходов есть свои ограничения по контролю, обновлениям, безопасности и способам интеграции.

Что в итоге

У CMS нет одной универсальной классификации.

54:T2767,

Выбор подрядчика — это не просто вопрос денег, а вопрос долгосрочного успеха вашего бизнеса. Важно понимать, что низкая стоимость может скрывать скрытые риски: задержки, ошибки, дополнительные расходы. И наоборот, инвестиции в качественное партнерство принесут вам уверенность в сроках, стабильности и результате. Чтобы выбрать подрядчика, который принесет реальную ценность, нужно взглянуть за рамки цифр и оценить, что он предлагает.

1. Недостаточная компетенция подрядчика

Риск:

Подрядчик с низкой ценой может не обладать необходимыми компетенциями или опытом для вашего проекта. Это приведет к задержкам и снижению качества работы, а также увеличению общих затрат.

Рекомендация:

Оцените не только стоимость, но и опыт подрядчика в аналогичных проектах. Какие технологические решения он использует? Какие гарантии качества он предоставляет?

Почему это важно:

Инвестируя в компетентного подрядчика, вы инвестируете в результат. Качество работы, компетенции команды и своевременное выполнение — это то, что обеспечивает долгосрочный успех, а не низкая цена.

2. Низкая вовлеченность в проект

Риск:

Когда подрядчик не вовлечен в проект на всех этапах, это часто приводит к непониманию ваших бизнес-целей, низкому качеству и задержкам. Важен не только профессионализм, но и внимание к деталям, готовность слушать и адаптироваться под изменения.

Рекомендация:

Выбирайте подрядчика, который будет работать с вами как партнер, а не как внешний исполнитель. Он должен разделять ваши ценности, понимать цели бизнеса и быть готовым к постоянной коммуникации.

Почему это важно:

Вовлеченность подрядчика гарантирует, что решения будут максимально адаптированы под ваши нужды. Такой подход поможет избежать рисков недовольства и перерасхода бюджета.

3. Отсутствие гарантий качества и сроков

Риск:

Подрядчик без четких гарантий может не успеть выполнить проект в срок или не соблюсти заявленное качество. Это может повлиять на вашу репутацию и привести к дополнительным затратам.

Рекомендация:

Работайте только с теми подрядчиками, которые могут предложить прозрачные и четко прописанные гарантии — как по срокам, так и по качеству работы.

Почему это важно:

Гарантии — это не просто формальность, это показатель профессионализма. Они подтверждают, что подрядчик уверен в своем продукте и готов нести ответственность за результат.

4. Невозможность точно оценить стоимость проекта

Риск:

Если цена кажется слишком низкой, это может скрывать скрытые расходы, дополнительные доработки или плохое качество. В итоге проект выйдет дороже, чем планировалось.

Рекомендация:

Попросите подрядчика предоставить детализированное предложение с учетом всех возможных рисков. Процесс согласования и понимание всех составляющих стоимости поможет избежать неприятных сюрпризов в будущем.

Почему это важно:

Лучше заплатить чуть больше, но иметь уверенность в том, что стоимость включает все этапы работы, качественное выполнение и гарантию на результат.

5. Отсутствие поддержки и развития после завершения проекта

Риск:

После завершения разработки подрядчик может забыть о проекте, оставив вас без необходимой поддержки. Это чревато устареванием системы и возникновением новых проблем.

Рекомендация:

Выбирайте подрядчика, который предлагает услуги сопровождения и развития системы после её запуска. Это может включать регулярные обновления, техническую поддержку и адаптацию под изменяющиеся условия бизнеса.

Почему это важно:

Поддержка после завершения проекта — это залог того, что ваша система будет актуальной и не потеряет своей эффективности со временем.

Как выбрать подрядчика, который принесет ценность, а не просто будет дешевым?

Смотрите на опыт: Цена — это важный фактор, но не главный. Если подрядчик предлагает дешевую цену, всегда задавайте вопрос — почему. Возможно, он не имеет опыта или использует устаревшие технологии, которые сделают проект дороже в долгосрочной перспективе.
Обратите внимание на гарантии: Убедитесь, что подрядчик предлагает реальные гарантии по срокам, качеству и бюджету.
Ищите партнера, а не исполнителя: Выбирайте тех, кто готов работать с вами на всех этапах проекта, понимать ваши бизнес-цели и поддерживать долгосрочные отношения.

Итог

Выбор подрядчика — это не просто поиск самой дешевой услуги. Это партнерство, которое может существенно повлиять на будущее вашего бизнеса. Инвестируя в качественные решения, вы обеспечиваете стабильность, скорость и высокое качество. Выбирайте подрядчиков, которые могут предоставить гарантии, разделяют ваши ценности и готовы не просто выполнить задачу, а стать частью вашего успеха.

Готовы сделать правильный выбор?

Запишитесь на консультацию с нами и получите персональное предложение, которое обеспечит результат.

55:T634a,

В 2026 году заказная разработка стала жестче. Бизнес хочет запускать продукты быстрее, но терпимость к ошибкам стала ниже. Если подрядчик тянет сроки, перегружает проект ручной работой или выпускает сырой код, это быстро бьет по деньгам. Не только на этапе запуска. Еще сильнее — через 3–6 месяцев, когда начинаются доработки, интеграции, рост нагрузки и первые сбои.

Поэтому сегодня важен уже не только стек. И не только размер команды. Важнее другое: как подрядчик вообще производит продукт. Где он ускоряется. Где проверяет себя. Кто отвечает за архитектуру. Кто держит безопасность. Как команда не превращает скорость в будущий техдолг.

В Энсайн такой опорной моделью стала AI + Human.

Это не попытка заменить инженеров генерацией кода. И не маркетинговая надстройка ради модной формулировки. Это рабочий подход, в котором ИИ берет на себя повторяемую и трудоемкую часть, а люди отвечают за то, что реально определяет судьбу продукта: архитектуру, устойчивость, безопасность, сложные интеграции и качество на выходе.

Именно этот подход сегодня дает то, что нужно бизнесу: быстрый старт без хаоса после релиза.

Почему прежняя модель разработки начала проигрывать

Еще несколько лет назад можно было спокойно жить в классической схеме. Сначала аналитика. Потом проектирование. Потом разработка. Потом тестирование. Потом доработка того, что не учли в начале. Сроки были длиннее, и рынок это терпел.

Сейчас так работает все хуже.

Современный веб-портал — это уже не просто сайт с личным кабинетом. Обычно это роли, документы, заявки, контент, поиск, уведомления, история действий, аналитика и несколько внешних систем в одном контуре. Рядом почти всегда стоят CRM, 1С, ERP, SSO, телефония, платежи, почта, SMS, иногда мобильное приложение и отдельная админка.

С веб-сервисами картина похожая. Они отвечают за обмен данными, каталог, расчет тарифов, партнерские сценарии, статусы заказов, очереди событий, внутреннюю логику между системами. Ошибки там быстро выходят наружу.

На таком фоне старая схема начинает буксовать. Если команда руками собирает все подряд — от типовых слоев до черновиков тестов и служебной документации — продукт движется медленнее, чем нужно бизнесу. Если команда пытается ускориться за счет бездумной генерации, проблемы просто приезжают раньше.

Поэтому сейчас плохо работают обе крайности. Полностью ручная модель тормозит. Полуавтоматическая без жесткого контроля создает новые риски.

Что означает AI + Human в Энсайн

У нас ИИ встроен в производственный процесс там, где он реально приносит пользу.

Он помогает ускорять подготовку типовых слоев сервиса, повторяемой логики, вспомогательных обработчиков, черновиков автотестов, части технических артефактов, внутренних заготовок и рутинных операций, на которые у команды раньше уходили часы и дни.

Это дает заметный эффект на старте. То, что раньше спокойно собирали неделями, сейчас можно получить в черновом виде намного быстрее. Команда раньше выходит к рабочему контуру. Значит, раньше начинает проверять реальные сценарии, а не обсуждать их в теории.

Но дальше вступает в силу вторая часть модели — Human.

Senior-инженеры, архитекторы, тимлиды и специалисты по безопасности проверяют, что получилось. Смотрят, как решение поведет себя под нагрузкой, не тянет ли за собой лишние зависимости, не ломает ли правила доступа, не создает ли уязвимости, не усложняет ли обновления и сопровождение.

Если речь идет о деньгах, персональных данных, правах доступа, документообороте, обмене с 1С, ERP или другими чувствительными системами, автоматическая генерация без глубокой проверки для нас просто не вариант.

Поэтому логика у нас простая. ИИ ускоряет выпуск повторяемой части. Люди отвечают за то, что влияет на устойчивость системы.

Где ИИ дает реальную пользу

Наибольший эффект ИИ дает не в громких обещаниях, а в повседневной работе.

Например, в проектах по разработке веб-сервисов он помогает быстрее собрать стартовый каркас сервиса: модели, маршруты, API-слои, типовую бизнес-обвязку, базовые проверки. Это не отменяет проектирование, но заметно сокращает путь от идеи до первого рабочего контура.

То же касается типового кода. Стандартные контроллеры, повторяемые обработчики, часть интеграционных заготовок, простые сервисные слои не должны съедать senior-ресурс неделями, если их можно ускорить без потери контроля.

Отдельно важен контур автотестов. ИИ помогает быстро подготовить черновики unit- и integration-тестов, закрыть типовые ветки, подсветить очевидные дыры. После этого инженер доводит покрытие до рабочего уровня и проверяет, что тесты отражают реальную логику, а не создают иллюзию надежности.

Есть и менее заметная, но полезная часть: внутренние технические описания, матрицы проверок, служебные заготовки, документация по повторяемым участкам. Это не тот слой, ради которого стоит тратить дорогие часы сильной команды.

В результате опытные инженеры тратят больше времени на то, что действительно сложно: на архитектурные границы, схему данных, производительность, безопасность, устойчивость под нагрузкой и интеграции, которые потом не развалят продукт.

Где ИИ не должен принимать решения

Есть зоны, где ошибаться слишком дорого.

Первая зона — архитектура. ИИ может предложить рабочий вариант, но он не отвечает за то, как система будет жить через год. Он не думает о накоплении техдолга так, как думает архитектор. Не держит в голове будущие изменения бизнеса. Не оценивает цену неудачного компромисса на длинной дистанции.

Вторая зона — безопасность. Сгенерированный код может выглядеть аккуратно и даже проходить базовые проверки, но при этом содержать слабые места в доступах, валидации, обработке исключений, токенах, персональных данных или логике ролей. Поэтому любая такая часть у нас проходит ручную проверку.

Третья зона — критичная бизнес-логика. Финансовые расчеты, маршруты согласования, правила документооборота, права доступа, обмен с учетными системами, важные бизнес-правила. Здесь ошибка может стоить не часов на исправление, а прямых потерь для клиента.

Четвертая зона — сложные интеграции. 1С, ERP, SSO, внешние API, очереди, нестабильные контуры. Такие вещи нельзя выпускать по принципу «сгенерировалось и вроде работает». Нужны реальные сценарии ошибок, таймауты, ретраи, журналирование, тестирование деградации и понимание, как система поведет себя при сбоях.

По этой причине AI + Human у нас не снижает роль инженеров. Наоборот, делает ее еще важнее.

Что получает бизнес от такой модели

Снаружи может показаться, что речь только про ускорение разработки. На деле эффект шире.

Первое. Быстрее появляется рабочая версия продукта. Не красивая схема и не набор обещаний, а реальный контур, который можно показать, проверить и начать развивать дальше.

Второе. Снижается объем дорогой ручной рутины. Для заказчика это означает более рациональные затраты. Он платит не за механическую сборку там, где ее можно ускорить, а за инженерные решения там, где они действительно нужны.

Третье. Уменьшается риск, что быстрый старт обернется тяжелой поддержкой. Если генерация идет без контроля, техдолг накапливается очень быстро. Если над скоростью стоит нормальная инженерная проверка, продукт живет спокойнее и меняется предсказуемее.

Четвертое. Проще держать полный цикл. После релиза работа только начинается: поддержка, новые интеграции, доработки, оптимизация, разбор инцидентов, рост нагрузки. AI + Human полезен и здесь, потому что ускоряет повторяемые операции, но не ломает качество сопровождения.

Как этот подход работает в веб-порталах

С порталами почти всегда повторяется одна и та же история. На старте проект кажется понятным. Роли, контент, личные кабинеты, каталог, поиск, документы, уведомления. Потом выясняется, что за этим стоят десятки скрытых связей: кто что видит, кто что меняет, какие сущности зависят друг от друга, как ведется история действий, как работает поиск по разным типам данных, как все это связано с CRM, 1С или внутренними справочниками.

В такой среде AI + Human дает хороший результат.

ИИ помогает быстрее собрать повторяемые блоки. Команда не тонет в типовой работе. А инженеры в это время разбирают то, что потом определит цену сопровождения: ролевую модель, связи между сущностями, правила доступа, поведение под нагрузкой, устойчивость поиска, работу интеграций и логику обновлений.

В итоге портал быстрее выходит в рабочую фазу и меньше мстит бизнесу за изменения после запуска.

Как этот подход работает в веб-сервисах

С веб-сервисами требования еще жестче. Если сервис медленный или нестабильный, это быстро замечают другие системы и пользователи.

Здесь AI + Human особенно полезен в проектах, где нужно быстро собрать рабочий слой, но нельзя упрощать критичные вещи. Например, когда сервис отвечает за обмен с 1С, статусы заказов, каталог, кабинеты партнеров, события, документы или внутренние правила между несколькими контурами.

ИИ ускоряет базовую реализацию. Люди не дают системе упроститься там, где потом будет больно.

Для бизнеса это обычно выглядит просто: продукт запускается быстрее, а проблем после релиза меньше.

Что еще обязательно, даже если у команды сильная AI + Human-модель

Сама по себе эта модель не решает все.

Если у проекта нет CI/CD, тестовых контуров, логирования и мониторинга, команда просто начнет быстрее производить ошибки. Если нет нормальной архитектурной дисциплины, ускорение быстро превратится в беспорядок. Если нет трезвого отношения к безопасности, инцидент станет только вопросом времени.

Поэтому AI + Human работает только вместе с нормальной инженерной базой. С понятной поставкой. С проверками. С наблюдаемостью. С внятной схемой поддержки. С умением выбрать меру, а не усложнять систему без причины.

Не каждому проекту нужен Kubernetes. Не каждый продукт надо дробить на микросервисы. Не каждую legacy-систему стоит переписывать с нуля. Зрелость обычно видна именно здесь — по умению принимать трезвые решения, а не собирать красивую схему из модных слов.

Почему для Энсайн это стало стандартом?

Потому что эта модель совпадает с тем, как мы в целом смотрим на разработку.

Нам важен не только запуск. Нам важно, как система будет жить дальше. Сколько будет стоить доработка через полгода. Насколько спокойно пройдут новые интеграции. Не станет ли заказчик заложником подрядчика, редкого стека или одного сильного разработчика. Будет ли продукт развиваться без постоянного страха что-то сломать.

AI + Human помогает решать эти задачи практично.

ИИ убирает тяжелую повторяемую часть. Инженеры удерживают архитектуру, безопасность и качество. Заказчик получает результат быстрее, но не расплачивается за это будущими проблемами.

«ИИ ускоряет разработку, но это не компромисс между скоростью и качеством, а способ получить и то, и другое. Инженеры отвечают за архитектуру, безопасность и то, как система будет жить после релиза. Только в такой связке AI + Human действительно работает в проде, а не на презентации», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Как отличить рабочую модель от красивой презентации

Если подрядчик просто говорит «мы используем ИИ», этого мало.

Нужно смотреть на конкретику. Где именно ИИ встроен в процесс. Что именно он ускоряет. Кто проверяет результат. Как устроен контур безопасности. Как генерация встроена в тестирование, релизы и поддержку. Как команда не дает скорости превратиться в новый техдолг.

Если на эти вопросы нет понятных ответов, скорее всего ИИ там пока существует на уровне слайдов.

В Энсайн этот разговор предметный. Потому что для нас AI + Human — не эксперимент и не внешний эффект. Это рабочий способ делать веб-порталы и веб-сервисы быстрее и качественнее.

Итог

В 2026 году сильная разработка уже не сводится к спору между полностью ручной работой и полной автоматизацией.

Полностью ручная модель слишком медленная. Полностью машинная слишком рискованная.

Работает гибридный подход.

AI + Human дает бизнесу то, что ему сейчас действительно нужно: скорость там, где ее можно безопасно получить, и инженерный контроль там, где ошибка потом стоит дорого.

Именно поэтому в Энсайн эта модель стала новым стандартом. Мы используем ИИ внутри производственного цикла, ускоряем повторяемые части и сохраняем ключевые решения за людьми. За счет этого быстрее выводим продукт в работу и спокойнее сопровождаем его после запуска.

56:T4850,

До 30 млн рублей на российские цифровые решения

54 проекта уже получили поддержку

ИТ-рынок вырос. Но картина не такая однозначная

Государственные системы собирают в единый контур

Минцифры хотят сделать главным ведомством по ИИ

Зарегистрированных киберпреступлений стало меньше

Что видно по этим новостям

До 30 млн рублей на российские цифровые решения

Фонд содействия инновациям вместе с Минцифры открыл прием заявок на конкурс «Развитие-ЦТ».

Заявки принимаются до 24 августа 2026 года.

54 проекта уже получили поддержку

Почти одновременно подвели итоги конкурсов «Старт-ИИ» и «Старт-ЦТ».

«На демонстрации можно показать удачный сценарий и убедительный интерфейс. В промышленной эксплуатации все сложнее. Возникают интеграции, права доступа, требования безопасности, нагрузка, документация и поддержка. Поэтому ценность продукта определяется не только качеством идеи, но и тем, способна ли команда довести ее до стабильной работы в реальной инфраструктуре», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

ИТ-рынок вырос. Но картина не такая однозначная

Данные приводят CNews и Хабр.

Цифры хорошие. Но из них не следует, что ИТ-компаниям сейчас легко.

Государственные системы собирают в единый контур

Правительство обновило стратегию цифровой трансформации государственного управления до 2030 года.

Подробный разбор опубликован на ComNews. Сам документ доступен в правовой базе.

Для подрядчиков в этой новости важны не столько 42 сервиса или 35 тыс. организаций, сколько общий подход.

Минцифры хотят сделать главным ведомством по ИИ

О проекте писали Хабр и TelecomDaily.

Пока это именно проект. Готовых правил для бизнеса еще нет.

Зарегистрированных киберпреступлений стало меньше

Минцифры сообщило о снижении количества зарегистрированных киберпреступлений.

Подробности опубликованы на сайте Минцифры.

Что видно по этим новостям

Минцифры сейчас работает сразу в двух направлениях.

Именно на этом, а не на красивой презентации или удачном пилоте, чаще всего решается судьба проекта.

57:Tb602,

Один подрядчик оценивает сайт в 500 тысяч рублей, другой — в 8 миллионов. Обычно такое расхождение возникает потому, что команды считают разные продукты.

В первом предложении может быть набор информационных страниц на готовой платформе. Во втором — система, которая работает с клиентами, документами, данными и внутренними процессами компании.

В коммерческом запросе оба решения называются сайтом. По трудоемкости между ними может быть разница в десятки раз.

Разберем, сколько стоит разработка сайта или корпоративного портала в 2026 году, какие работы формируют бюджет и как сравнивать предложения подрядчиков.

Содержание

Сколько стоит сайт или портал

Что означают ценовые диапазоны

Чем сайт отличается от портала

Как рассчитывается объем работ

Из чего складывается бюджет

Что входит в ставку подрядчика

Какие расходы могут остаться за пределами сметы

Почему стоимость меняется после старта

Как сравнивать предложения

Какой бюджет закладывать на проект

Сколько стоит разработка сайта или портала

Для первого расчета можно использовать следующие ориентиры.

Тип проекта	Примерная стоимость	Что обычно входит
Лендинг или небольшой промосайт	150-500 тыс. рублей	Несколько экранов, формы, адаптивная версия, базовая аналитика
Корпоративный сайт на готовой платформе	500 тыс. - 1,5 млн рублей	Типовая CMS, информационные разделы, формы, стандартный каталог
Индивидуальный корпоративный сайт	1,5-3 млн рублей	Аналитика, уникальный дизайн, система управления, базовые интеграции
Корпоративный сайт с каталогом и сложной логикой	3-6 млн рублей	Фильтры, поиск, обмен данными, нестандартная административная часть
Личный кабинет или веб-сервис	3-8 млн рублей	Авторизация, роли, документы, операции с данными, интеграции
MVP корпоративного портала	4-8 млн рублей	Основные пользовательские сценарии и ограниченный набор интеграций
Полноценный корпоративный портал	8-20 млн рублей	Несколько ролей, процессы, документы, интеграции, отчетность
Высоконагруженная система или цифровая экосистема	От 15-20 млн рублей	Несколько сервисов, отказоустойчивость, сложная архитектура, повышенные требования к безопасности

Это практические ориентиры для заказной разработки, а не универсальный прайс.

Лицензии, серверная инфраструктура, массовое наполнение, сложная миграция данных, техническая поддержка и последующее развитие обычно рассчитываются отдельно.

Что означают эти диапазоны

В нижнюю часть диапазона обычно попадают решения на готовой платформе, с ограниченным количеством ролей и стандартными интеграциями.

Верхняя граница предполагает индивидуальную архитектуру, сложную административную часть, перенос данных, несколько внешних систем и повышенные требования к надежности.

Например, корпоративный сайт за 1,5 млн рублей может состоять из информационных разделов, форм и стандартной CMS. Проект за 5-6 млн рублей уже способен включать каталог, несколько источников данных, сложный поиск, персонализированные результаты и отдельные инструменты для администраторов.

Визуально оба решения могут выглядеть похожими. Разница находится внутри.

То же относится к MVP портала. MVP не означает «сделать максимально дешево, а ошибки исправить потом». Это минимальный набор законченных сценариев, который можно безопасно запустить, проверить на пользователях и развивать без полной переделки системы.

Чем сайт отличается от портала

Корпоративный сайт в первую очередь публикует информацию. Он рассказывает о компании, продуктах, услугах, проектах и экспертизе.

Портал становится рабочим инструментом. Пользователь выполняет операции, а система управляет данными, правами и внутренними процессами.

Чтобы не сравнивать несопоставимые предложения, разделим проекты на четыре группы.

Лендинг или промосайт

Такой ресурс создают для отдельного продукта, услуги, рекламной кампании или мероприятия.

Основной бюджет приходится на дизайн, верстку, контент и формы. Цена растет, если нужны сложная анимация, интерактивные элементы, калькуляторы, 3D или несколько внешних сервисов.

Небольшое количество страниц еще не означает низкую стоимость. Один технически сложный промосайт может потребовать больше работы, чем стандартный корпоративный ресурс.

Корпоративный сайт

Корпоративный сайт представляет компанию, продукты и экспертизу.

В базовой версии это информационные разделы, формы и система управления контентом. Смету увеличивают каталог, несколько языков, нестандартная структура, поиск, интеграции с CRM и особая логика административной панели.

Здесь особенно важно понимать степень индивидуальности. Сайт на готовом шаблоне и заказная платформа могут иметь одинаковое количество страниц, но совершенно разный состав работ.

Каталог или интернет-магазин

В каталоге появляется товарная логика: характеристики, фильтры, цены, остатки, заказы, оплата и доставка.

Основная сложность часто скрывается в обмене с 1С, ERP, складскими и логистическими системами.

Чем больше типов цен, складов, регионов и правил подбора, тем выше трудоемкость. Пользователь видит товарную карточку и кнопку заказа. За ними могут работать десятки правил и несколько корпоративных систем.

Личный кабинет или корпоративный портал

С этого уровня речь идет уже о полноценном веб-приложении.

В него могут входить:

личные кабинеты;
документы;
заявки;
согласования;
внутренние сервисы;
отчетность;
CRM, ERP и 1С;
единая авторизация;
сложная модель ролей;
журналы действий.

Количество страниц здесь отходит на второй план. Бюджет определяют процессы, данные, интеграции и требования к надежности.

Как рассчитывается объем работ

Оценка начинается не с подсчета страниц и кнопок.

Иногда самый скромный элемент интерфейса оказывается самостоятельным цифровым сервисом.

«Пользователь видит в подборщике смазочных материалов всего несколько полей. Но за ними стоят интеграции минимум с двумя API-сервисами, отдельные модули в административной панели и логика сопоставления и вывода результатов. Внешне это небольшой блок сайта. По объему работ — самостоятельный цифровой сервис», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Сравнивать стоимость такого подборщика с обычной формой обратной связи бессмысленно, хотя на странице оба элемента занимают примерно одинаковое место.

Чтобы оценить функцию, подрядчик последовательно разбирает пользователей, сценарии, данные и внешние зависимости.

Пользователи и права

Сначала нужно понять, кто будет работать в системе.

Это могут быть посетители, клиенты, партнеры, редакторы, операторы, руководители и администраторы.

Для каждой роли определяются доступные данные и действия. Один пользователь видит только собственные заявки. Другой работает со всем подразделением. Третий утверждает документы. Четвертый меняет настройки системы.

На макете эта сложность почти незаметна. В программном коде она затрагивает практически каждый раздел.

Пользовательские сценарии

Затем команда разбирает, что именно сможет сделать пользователь.

Он нажимает кнопку «Отправить заявку». Система проверяет данные, сохраняет запись, передает информацию в CRM, рассылает уведомления, запускает согласование и обновляет статус в личном кабинете.

Одна кнопка превращается в работу для аналитика, дизайнера, frontend-разработчика, backend-разработчика и тестировщика.

Интеграции

Для каждой внешней системы нужно определить:

какие данные передаются;
в каком направлении идет обмен;
как часто он запускается;
есть ли документированный API;
что происходит при ошибке;
кто отвечает за вторую сторону интеграции.

Подключение к современной системе с готовым API может занять несколько дней. Работа с устаревшим решением без документации иногда растягивается на месяцы.

Именно здесь часто возникает разница между двумя сметами. Один подрядчик учитывает только отправку данных. Другой сразу закладывает проверку, повторные попытки, журналирование ошибок и восстановление обмена после сбоя.

Данные и миграция

Старые данные редко готовы к автоматическому переносу.

В них обнаруживаются дубли, пропущенные значения, разные форматы и несовпадающие справочники. Иногда невозможно понять, какая версия записи является актуальной.

Поэтому миграция включает анализ, очистку, преобразование, перенос и проверку результата.

Если подрядчик оценил только техническое копирование, дополнительный объем обнаружится уже после старта.

Надежность и безопасность

На архитектуру влияют количество пользователей, нагрузка, допустимый простой и требования к данным.

Информационный сайт может работать на сравнительно простой инфраструктуре. Для портала, от которого зависят продажи, обслуживание клиентов или внутренние операции, потребуются резервирование, мониторинг, журналирование и отдельные среды.

Чем дороже остановка системы для бизнеса, тем выше требования к разработке, тестированию и поддержке.

Из чего складывается бюджет проекта

Упрощенно бюджет запуска можно представить так:

Трудозатраты команды + лицензии и инфраструктура + внешние сервисы + резерв на известные риски.

Техническая поддержка и дальнейшее развитие обычно рассчитываются отдельно.

Сайт или портал создают аналитики, дизайнеры, frontend- и backend-разработчики, тестировщики, DevOps-инженеры и менеджеры.

Этап	Что делает команда	Почему это влияет на цену
Аналитика	Описывает цели, процессы, роли, данные и интеграции	Ошибка в требованиях приводит к переделкам на следующих этапах
UX/UI-дизайн	Проектирует сценарии, экраны и состояния интерфейса	Один экран портала может иметь десятки состояний
Frontend	Реализует пользовательский интерфейс	Трудоемкость растет вместе с интерактивностью и числом ролей
Backend	Создает бизнес-логику, базы данных и интеграции	Обычно это крупнейший технический блок портала
Тестирование	Проверяет сценарии, права, данные и обмены	Чем больше связей, тем больше комбинаций нужно проверить
Запуск	Настраивает инфраструктуру, мониторинг и перенос данных	Критичным системам нужны отдельные среды и резервирование
Менеджмент	Управляет сроками, рисками и изменениями	Без координации бюджет расходуется на ожидания и переделки

Аналитика: определить систему до разработки

До аналитики заказчик часто видит проект как набор разделов и функций. После разбора процессов становится понятно, сколько ролей, данных и внешних систем скрывается за этой формулировкой.

Команда проводит интервью, изучает существующие процессы, описывает пользователей, собирает требования и формирует структуру будущего решения.

По итогам аналитики заказчик получает:

карту пользовательских сценариев;
прототипы;
функциональные требования;
описание данных;
интеграционную схему;
бэклог или техническое задание;
план реализации;
уточненную смету.

Без аналитики проект выглядит дешевле только на старте. Затем требования приходится уточнять на самом дорогом этапе, когда дизайн и код уже созданы.

Дешевле всего исправлять процесс до начала разработки.

Интерфейс: спроектировать все состояния

Дизайн определяет внешний вид и порядок работы пользователя с системой.

Для обычного сайта дизайнер создает страницы и компоненты. В портале приходится учитывать загрузку, ошибки, отсутствие данных, ограничения доступа, предупреждения и разные состояния для каждой роли.

Затем frontend-разработчик превращает макеты в работающий интерфейс, подключает API, реализует формы, фильтры, поиск и обработку ошибок.

На экране пользователь видит один результат. Команда должна предусмотреть все пути, которыми он может к нему прийти.

Серверная часть: реализовать процессы и данные

Backend скрыт от пользователя. Именно там портал принимает решения, проверяет права, выполняет расчеты и связывается с внутренними системами.

Серверная часть:

хранит данные;
управляет авторизацией;
проверяет права;
выполняет бизнес-правила;
формирует документы;
отправляет уведомления;
взаимодействует с API;
фиксирует действия пользователей;
управляет административными модулями.

Для информационного сайта backend может ограничиваться CMS и несколькими формами.

В портале это обычно крупнейший технический блок. Основную нагрузку создают интеграции, миграция, нестандартные процессы и сложная ролевая модель.

Тестирование и запуск: проверить всю цепочку

Готовый код еще не означает готовую систему.

Проверять нужно не отдельные экраны, а полные сценарии: от авторизации пользователя до передачи данных во внешнюю систему и возврата результата.

Команда тестирует:

функции;
роли и права;
API;
интеграции;
мобильные устройства;
браузеры;
производительность;
безопасность;
работу системы после обновлений.

Ошибка в информационном блоке портит впечатление. Ошибка в правах доступа может открыть пользователю чужие документы. Сбой интеграции способен остановить бизнес-процесс.

Перед запуском также нужно подготовить серверы, базы данных, тестовую и промышленную среды, резервное копирование, мониторинг и план переноса данных.

Если речь идет о критичной системе, запуск становится отдельным проектным этапом.

Управление проектом

Аналитик описывает процесс. Дизайнер переводит его в интерфейс. Разработчики реализуют логику. Тестировщик проверяет всю цепочку.

Если эти специалисты работают с разными версиями требований, бюджет уходит на ожидание, повторные согласования и переделки.

Руководитель проекта:

планирует работы;
координирует команду;
фиксирует решения;
контролирует сроки и бюджет;
управляет рисками;
организует демонстрации;
ведет приемку;
обрабатывает изменения.

В сложных проектах управление нередко составляет около 10-15% трудозатрат. Конкретная доля зависит от размера команды, количества участников со стороны заказчика и сложности согласований.

Менеджмент здесь не является административной надбавкой. Это механизм, который удерживает проект в согласованных границах.

Из чего складывается ставка компании

Ставку подрядчика нельзя напрямую сравнивать с зарплатой штатного разработчика.

В нее входят:

оплата специалистов;
налоги;
оборудование;
лицензии;
контроль качества;
техническое управление;
найм и обучение;
предпродажная оценка;
юридическое сопровождение;
периоды между проектами;
гарантийные работы;
проектные риски;
прибыль компании.

Заказчик платит за способность команды довести систему до запуска, заменить специалиста при необходимости, проверить результат и устранить гарантийные ошибки.

Ставка отражает не только квалификацию разработчика, но и устойчивость всего производственного процесса.

В 2026 году ставки профессиональных команд веб-разработки обычно находятся в диапазоне от 2 500 до 5 000 рублей в час. Работа архитектора, ведущего аналитика или senior-разработчика может стоить дороже.

Но выбирать подрядчика только по ставке неправильно.

Команда со ставкой 2 500 рублей может потратить на задачу 400 часов. Команда со ставкой 4 000 рублей решит ее за 200 часов. Во втором случае итоговая стоимость окажется ниже.

Сравнивать нужно состав команды, количество часов, результат и ответственность подрядчика.

Что может не входить в первоначальную оценку

Даже подробное коммерческое предложение не всегда покрывает все расходы.

Перед заключением договора стоит проверить, учтены ли:

подготовка и перенос контента;
очистка исторических данных;
лицензии CMS;
серверная инфраструктура;
карты, SMS и рассылки;
доработка API внешних систем;
нагрузочное тестирование;
аудит безопасности;
техническая документация;
обучение сотрудников;
круглосуточная поддержка;
дальнейшее развитие.

Например, в смете есть строка «интеграция с CRM», но доработка самой CRM туда не входит. Разница обнаруживается уже после старта.

Формально интеграция учтена. Фактически часть работ остается на стороне заказчика или оплачивается дополнительно.

Поэтому сравнивать нужно не только общую сумму. Сначала следует проверить границы ответственности каждой команды.

Почему стоимость может измениться после старта

Цена остается стабильной, пока не меняются требования и исходные условия.

Появились новые функции

Новая функция требует не только программирования. Ее нужно описать, спроектировать, реализовать и проверить.

Даже небольшое изменение интерфейса может затронуть базу данных, административную панель и внешние системы.

Уточнился бизнес-процесс

После создания прототипа может выясниться, что заявка проходит несколько согласований, возвращается на доработку и обрабатывается по разным правилам для подразделений.

Формально речь все еще идет об одной заявке. По факту объем логики увеличивается.

Обнаружились ограничения интеграции

В документации заявлен нужный API, но часть методов отсутствует или работает иначе.

Команде приходится искать обходной путь, разрабатывать промежуточный модуль или дорабатывать вторую систему.

Данные оказались неготовыми

При миграции обнаруживаются дубли, неполные записи и несовпадающие справочники.

Появляется отдельный блок очистки и преобразования данных, которого не было в первоначальной оценке.

Изменились требования к безопасности

После согласования архитектуры заказчик может добавить закрытый контур, двухфакторную авторизацию, дополнительное журналирование или более строгие правила работы с персональными данными.

Это влияет на архитектуру, разработку и тестирование.

Сократились сроки

Ускорение проекта требует расширения команды и параллельного выполнения работ.

Такой режим увеличивает нагрузку на управление и повышает риск повторных согласований.

Любое изменение цены должно быть связано с конкретным изменением объема или исходных условий.

Если требования остались прежними, подрядчик должен объяснить рост бюджета конкретной ошибкой в оценке, а не общей фразой о неожиданной сложности.

Техническая поддержка после запуска

Запуск завершает создание первой версии. После него начинается эксплуатация.

Даже информационный сайт нужно обновлять, контролировать и защищать.

В поддержку могут входить:

мониторинг;
устранение ошибок;
обновление компонентов;
резервное копирование;
контроль безопасности;
сопровождение интеграций;
консультации пользователей;
выпуск новых версий;
работа с инцидентами.

Небольшой сайт можно поддерживать за 30-100 тыс. рублей в месяц.

Для сложного корпоративного ресурса с регулярным развитием бюджет обычно начинается от 150-400 тыс. рублей в месяц.

Для бизнес-критичного портала с круглосуточным SLA, мониторингом и несколькими линиями поддержки годовая стоимость может начинаться от 3,5 млн рублей.

Чем быстрее подрядчик должен реагировать и чем дороже простой, тем выше бюджет поддержки.

Как сравнивать предложения подрядчиков

Предложения на 3 и 6 млн рублей нельзя сравнить, пока неизвестно, что находится внутри каждой суммы.

Проверьте:

Включена ли аналитика.
Кто готовит требования и техническое задание.
Какие пользовательские сценарии учтены.
Сколько ролей будет в системе.
Какие интеграции входят в оценку.
Кто отвечает за качество и миграцию данных.
Какие виды тестирования проводятся.
Входит ли настройка серверов.
Какая документация передается.
Что включено в гарантию.
Сколько итераций согласования предусмотрено.
Как рассчитываются изменения.

Низкая цена часто означает, что часть работ вынесена за границы предложения.

Заказчик оплачивает их позже через дополнительные соглашения, задержки или переделку системы.

Какой бюджет закладывать на проект

Бюджет до 1,5 млн рублей обычно предполагает типовое решение с ограниченной индивидуальной логикой.

Диапазон 1,5-3 млн рублей позволяет говорить о заказном корпоративном сайте с аналитикой, индивидуальным дизайном и базовыми интеграциями.

При бюджете 3-6 млн рублей можно планировать сложный корпоративный ресурс, каталог или систему с нестандартной административной частью.

С диапазона 4-8 млн рублей начинается территория личных кабинетов и первых версий корпоративных порталов.

Полноценный портал с несколькими ролями, документами, внутренними процессами и интеграциями обычно требует от 8 млн рублей. Верхняя граница определяется масштабом системы, требованиями к надежности и количеством внешних связей.

Поэтому корректный запрос подрядчику звучит не так:

«Сколько стоит сайт на 30 страниц?»

Точнее спросить:

«Сколько стоит система с такими пользователями, процессами, интеграциями и требованиями к надежности?»

Пока эти параметры не определены, любая цена остается предварительной. Подробная оценка начинается с процессов, данных и границ ответственности, а не с количества страниц.

Команда «Энсайн» может провести предпроектный анализ, определить границы системы и подготовить обоснованную оценку разработки.

58:T1d4c,

В бизнесе часто приходится выбирать между развитием устаревших IT-систем и их полной заменой. Несмотря на заманчивость обновлений, такой выбор связан с рисками и затратами. Эволюционное развитие legacy-системы позволяет избежать этих проблем, поддерживая стабильность и эффективность без остановки бизнеса.

Почему эволюционное развитие legacy-системы — это оптимальный путь

Переписывание системы с нуля всегда сопряжено с рисками: потенциальные простои, сбои, проблемы с интеграцией и обучением персонала. В отличие от этого, эволюционное развитие минимизирует эти риски, позволяя внедрять изменения поэтапно. Это помогает сохранить бизнес-процессы, избежать значительных затрат и обеспечить долгосрочную стабильность.

«Когда меняешь систему по частям, можешь увидеть, что работает, а что нужно доработать, прежде чем двигаться дальше», — Вадим Зимин, Руководитель отдела разработки, Энсайн.

Как подойти к эволюционному развитию?

Эволюционное развитие системы происходит поэтапно, что позволяет контролировать изменения и минимизировать риски. Постепенные улучшения вносятся в систему без необходимости её полной переработки, сохраняя её работоспособность на всех этапах.

Как проводить эволюционное развитие legacy-систем без остановки бизнеса

Этапность изменений. Изменения вносятся поэтапно, что позволяет тестировать каждое улучшение до его внедрения.
Минимизация простоя. Важно, чтобы бизнес продолжал работать без остановок, а новые компоненты подключались постепенно.
Постепенная адаптация. Вместо переписывания всей системы внедряются новые функциональные элементы, которые постепенно подсоединяются к старой системе.

Инструменты и методы для эволюционного подхода

Для успешного эволюционного развития можно использовать современные технологии: микросервисы, контейнеризацию и облачные решения. Эти инструменты позволяют вводить изменения без значительных рисков, сохраняя систему в рабочем состоянии.

Микросервисы позволяют создавать независимые модули, которые могут быть интегрированы с существующими решениями.
Контейнеризация и облачные решения дают возможность гибко масштабировать систему и интегрировать новые технологии без кардинальных изменений в архитектуре.

Когда эволюционное развитие подходит, а когда необходимо полное переписывание?

Эволюционное развитие подходит, когда система выполняет свои функции и не требует глобальных изменений. Если же система не справляется с текущими задачами или требует значительных изменений в архитектуре, может быть разумным перейти к полному переписыванию. Важно тщательно оценить затраты и риски перед принятием такого решения.

Использование гибридных подходов

Гибридный подход сочетает преимущества эволюционного развития и новых технологий. Вместо того чтобы полностью отказываться от старой системы, можно интегрировать новые решения в её существующую структуру. Это позволяет сохранить текущую инфраструктуру, при этом внедряя инновации, что минимизирует риски и затраты.

Подведем итоги

Эволюционное развитие legacy-системы — это эффективный способ модернизации без рисков для бизнеса. Постепенные улучшения позволяют избежать долгосрочных затрат и простоев, а использование гибридных подходов даёт возможность интегрировать новые технологии, не разрушая стабильность.

Готовы узнать, как эволюционное развитие вашей системы может повысить её эффективность и минимизировать риски?

59:T3e0b,

Угроза редко приходит с одной стороны

Риски удобно делить на внешние и внутренние. Но на практике этого мало.

Внешние источники угроз: не только кража данных

Обычно бьют по 4 зонам.

Публичные сервисы. Сайты, API, личные кабинеты, мобильные backend-контуры, интеграционные шлюзы. Все, что доступно извне, становится мишенью для перебора, сканирования и эксплуатации старых уязвимостей.
Рабочая среда сотрудников. Почта, браузеры, мессенджеры, удаленный доступ, ноутбуки, телефоны. Здесь проще сыграть не на технологии, а на привычке и невнимательности.
Инфраструктура. Серверы, сетевое оборудование, облачные ресурсы, хранилища, резервные каналы, внешние сервисы аутентификации. Слабое место здесь открывает путь дальше по контуру.
Физический слой. Кража устройства, доступ в офис, подмена оборудования, подключение к внутренней сети без контроля. Это менее заметный, но вполне рабочий сценарий.

Внутренние источники угроз опаснее, чем кажутся

Природа и источники информационных угроз

У внутренних угроз есть 3 типовых сценария.

Злой умысел. Сотрудник копирует базу перед уходом. Подрядчик выносит данные. Пользователь сознательно передает доступ.
Ошибка. Документ уходит не туда. Доступ выдают не той роли. Тестовую выгрузку делают на боевых данных. Конфигурацию меняют без понимания последствий.
Слабая среда. Человек не делает ничего намеренно опасного, но работает в системе, где уже нет нормальных ограничений: общие учетные записи, лишние привилегии, отсутствие журналирования, слабая сегментация, формальные регламенты.

«Самый дорогой инцидент обычно начинается не с хитрой атаки, а с простого вопроса: у кого был доступ, зачем он был нужен и почему никто давно это не пересматривал,» — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Для бизнеса важнее не тип атаки, а то, что именно он теряет

С точки зрения бизнеса все угрозы в итоге бьют по 3 вещам: доступности, целостности и конфиденциальности.

Потеря доступности

Потеря целостности

Потеря конфиденциальности

Активные и пассивные угрозы: заметные и тихие

Самые частые мишени — конкретные активы

Чтобы защищаться, мало знать список угроз. Нужно понимать, что именно является активом в вашем контуре.

Обычно в зоне риска находятся:

клиентские и партнерские базы;
учетные системы;
корпоративная почта;
внутренние порталы и личные кабинеты;
файловые хранилища;
серверы приложений и баз данных;
сетевой контур;
резервные копии;
учетные записи с повышенными правами;
интеграционные каналы между системами;
устройства сотрудников.

Где бизнес чаще всего ошибается при оценке угроз

Есть 5 типовых ошибок.

1. Считать главным риском только внешний взлом

2. Смотреть на безопасность отдельно от архитектуры

3. Плохо знать свои активы

4. Не пересматривать накопленные доступы

5. Не считать стоимость простоя и искажения данных

Подведем итоги

5a:T4d85,

Open source обычно не приходит в проект как большое стратегическое решение. Чаще все проще. Есть задача, есть срок, есть готовая библиотека. Разработчик смотрит документацию, проверяет пример, подключает решение и идет дальше.

И чаще всего он прав.

Странно писать с нуля то, что давно существует и нормально работает. В любом серьезном продукте уже есть чужой код: фреймворк, база данных, сборка фронтенда, кеш, логирование, очередь задач, админка, модули для форм, авторизации или интеграций. Без этого разработка стала бы медленнее и дороже.

Для бизнеса open source тоже выглядит понятно. Быстрее стартуем. Меньше платим на первом этапе. Не покупаем лишние лицензии. Не тратим команду на базовую механику. Сразу идем к тому, ради чего проект вообще начался: личному кабинету, порталу, заявкам, обмену с 1С или CRM, отчетам, админке, работе с данными.

На этом месте обычно и появляется ошибка. Open source начинают воспринимать как «взяли готовое и забыли». Но в продукте так не бывает.

Если библиотека участвует в работе сервиса, ее придется поддерживать. Следить за версиями. Проверять обновления. Понимать, где она используется. Держать в голове, что она может повлиять на соседние функции. И желательно не только в голове, а в документации.

Иначе через несколько месяцев быстрый старт начинает стоить дороже, чем казалось.

Хороший open source экономит время

Сам по себе open source — не проблема. Наоборот, во многих проектах он сильно помогает.

Когда мы делаем корпоративный сайт, портал или личный кабинет, заказчик не ждет от команды собственного фреймворка. Ему нужен рабочий инструмент. Чтобы заявки не терялись. Чтобы контент можно было править без разработчика. Чтобы данные уходили в нужные системы. Чтобы сотрудники видели свои роли и права. Чтобы после запуска сервис можно было поддерживать, а не разбирать заново перед каждой доработкой.

Готовые решения помогают быстрее собрать основу. Команда не пишет с нуля то, что уже много раз написано и проверено. Она быстрее переходит к бизнес-логике, интеграциям, интерфейсам и данным.

В этом смысле open source действительно снижает стоимость старта. Особенно если нужно быстро проверить идею, сделать первую версию продукта или собрать внутренний сервис для компании.

Но экономия работает только тогда, когда решение выбрали под задачу, а не просто потому, что оно первым нашлось в поиске.

Одна библиотека может быть нормальным рабочим инструментом. Другая может потянуть за собой тяжелую платформу, сложные настройки и ограничения, которые потом будут мешать. На старте разница может быть не видна. На поддержке она становится очевидной.

Проблемы обычно начинаются не сразу

С open source редко бывает так, что все ломается в первый день. Обычно наоборот. Все нормально подключилось, функция заработала, релиз прошел.

Потом продукт начинает расти.

Например, в личном кабинете сначала нужны простые роли. Администратор, менеджер, пользователь. Берем готовый модуль прав доступа. Он быстро закрывает задачу.

Через какое-то время появляются филиалы. Потом внешние подрядчики. Потом доступ по регионам. Потом ограничения по договорам. Потом разные права для поддержки, руководителей, бухгалтерии или партнеров.

И модуль, который сначала решал одну небольшую задачу, начинает влиять на работу половины сервиса. От него зависят данные, админка, интерфейс, API и новые доработки.

Это не значит, что модуль плохой. Возможно, он отлично подходил для первой версии. Просто первая версия уже закончилась, а продукт пошел дальше.

Вот здесь и появляется разница между «подключили библиотеку» и «нормально внедрили решение». В первом случае команда просто закрыла задачу. Во втором — заранее подумала, что будет, когда продукт начнет меняться.

Если этого не сделать, начинаются мелкие обходы. Где-то добавили исключение. Где-то проверили права вручную. Где-то временно продублировали логику. Потом временное остается в рабочей системе, потому что на него уже успели опереться другие функции.

Так появляются проблемы, которые никто специально не планировал. Они просто накапливаются.

Бесплатная лицензия не отменяет стоимость поддержки

У многих open source-решений нет платы за лицензию. Это удобно. Но это не значит, что решение ничего не стоит.

Стоимость просто появляется в другом месте.

Нужно настроить библиотеку. Проверить, что она подходит к стеку. Обновлять версии. Следить за уязвимостями. Понимать, какие зависимости она добавила в проект. Описать настройки. Объяснить новой команде, почему выбрали именно это решение.

Если библиотека отвечает за мелочь, все это почти не чувствуется. Если она стоит в авторизации, обмене данными, обработке персональных данных, платежах, загрузке файлов или деплое, цена ошибки становится другой.

На поддержке это выглядит очень приземленно. Заказчик просит небольшую доработку. Например, добавить поле, изменить форму или поправить правило доступа. Команда открывает проект и видит старую библиотеку.

Новая версия не подходит к текущему стеку. Старая давно не обновлялась. Внутри есть ручная правка. Документации нет. Разработчик, который это делал, уже не работает с проектом.

И задача перестает быть маленькой. Перед доработкой сначала нужно понять, как устроено старое решение и что может сломаться рядом.

Для бизнеса это выглядит странно. Просили поправить одну вещь, а получили длинную оценку. Но причина часто не в самой доработке. Причина появилась раньше, когда готовое решение быстро подключили и не оставили после себя понятных следов.

Самый неприятный случай — правки внутри библиотеки

Такое бывает чаще, чем хотелось бы.

Библиотека почти подходит. Не хватает одной детали. Сроки сжаты. Настроек мало. Делать нормальное расширение дольше. Разработчик открывает код библиотеки и правит его напрямую.

На ближайшем релизе это может помочь. Функция заработала, задача закрыта, все пошли дальше.

Проблема приходит позже. Нужно обновить библиотеку, а ручная правка может пропасть. Не обновлять тоже плохо, потому что старая версия устаревает. Переносить изменение вручную можно, но сначала надо понять, что именно меняли и почему.

В итоге чужой код становится почти своим, только без нормальной истории. Он лежит внутри зависимости, но уже влияет на работу продукта.

Если библиотеку нужно менять, лучше делать это открыто. Через отдельный слой, расширение, плагин, форк или хотя бы описанный патч. Это дольше на первом шаге, зато потом не нужно бояться каждого обновления.

Быстрые правки в чужом коде редко остаются бесплатными. Они просто предъявляют счет позже.

Лицензии и безопасность лучше смотреть до релиза

Open source не означает «можно использовать как угодно». У каждого решения есть лицензия.

Для внутреннего сервиса это может быть простым вопросом. Для продукта, который передают заказчику, продают, тиражируют или развивают как SaaS, условия уже важнее.

Плохой момент для проверки лицензии — перед запуском. Код уже написан, библиотека встроена, сроки согласованы. Если в этот момент выясняется, что условия не подходят, проблема быстро становится технической. Нужно менять библиотеку или переписывать часть логики.

С безопасностью похожая история. Команда может подключить одну библиотеку, а вместе с ней получить еще несколько зависимостей. Часть работает только при сборке. Часть попадает в продакшен. Часть давно не обновлялась.

Когда появляется информация об уязвимости, важно быстро понять, есть ли эта библиотека в проекте и где она используется. Если учета нет, начинается ручной поиск по репозиториям, серверам, контейнерам и старым веткам.

Для систем с персональными данными, заявками, договорами, платежами или внутренними учетными системами это плохой сценарий. Там нужно заранее понимать, что стоит в проекте и кто за это отвечает.

Когда open source лучше не брать

Иногда готовое решение только кажется удобным.

Например, ради одной функции в проект добавляют большую платформу. Сначала это ускоряет работу. Потом приходится поддерживать лишние настройки, зависимости и обновления, которые бизнесу не нужны.

Бывает и другая ситуация. Библиотека почти подходит, но ее постоянно приходится подгонять под процесс компании. Сначала это выглядит как настройка. Потом появляются исключения. Потом обходы. Потом продукт начинает работать не так, как нужно бизнесу, а так, как позволяет инструмент.

В таких случаях иногда проще написать свой небольшой модуль. Не потому, что open source плохой. А потому, что конкретное решение не подходит под конкретную задачу.

Коммерческий продукт тоже иногда спокойнее. Например, когда нужна поддержка поставщика, SLA, сертификация или понятная ответственность за работу решения. Это не делает коммерческое ПО лучше во всех случаях. Просто у него другой набор плюсов и минусов.

В реальных проектах чаще всего получается смешанная история. Где-то используется open source, где-то пишется собственная логика, где-то берется коммерческий продукт. Главное — понимать, почему выбрано именно так.

Что стоит решить до подключения библиотеки

Перед тем как добавить open source в проект, не нужно устраивать долгие обсуждения. Но несколько вещей лучше понять сразу.

Зачем берем эту библиотеку. Где она будет использоваться. Насколько она важна для продукта. Кто будет ее обновлять. Подходит ли лицензия. Есть ли нормальная документация. Что будет, если через год ее придется заменить.

Если ответы есть, решение можно спокойно брать в работу.

Если ответов нет, библиотеку просто быстро подключили. Это еще не значит, что ее правильно внедрили.

Open source дает бизнесу скорость на старте. Это его сильная сторона. Он помогает не писать с нуля то, что уже давно решено.

Но после запуска готовое решение становится частью проекта. Его нужно обновлять, проверять, описывать и учитывать при доработках.

Если этого не делать, быстрый старт легко превращается в дорогую поддержку.

Поэтому вопрос не в том, использовать open source или нет. Использовать. Без него нормальная разработка почти невозможна.

Вопрос в другом: кто потом будет за это отвечать.

Если ответ есть, open source помогает продукту.

Если ответа нет, это не экономия. Это проблема, которую просто отложили на потом.

5b:T2854,

Сценарий почти всегда один и тот же.

Если это повторяется, дело не в совпадении. И не в конкретной команде.

Это свойство системы.

Откуда берется ожидание простоты

Ожидание простоты возникает не из наивности. Оно возникает из прошлого опыта.

Именно здесь ожидание начинает конфликтовать с реальным устройством системы.

Что происходит внутри legacy при любой правке

Legacy не появляется внезапно. Оно формируется постепенно.

Снаружи это выглядит как замедление. Изнутри — как работа в условиях повышенного риска.

Почему опыт и усиление команды не ускоряют работу

В этот момент часто ожидают, что опыт или усиление команды решат проблему.

Это не вопрос квалификации. Это следствие состояния системы.

«Когда мы начинаем работать с legacy-системой, важно понимать, что это не просто устранение ошибок, а управление рисками, которые накапливаются годами. Важно вовремя вмешаться, прежде чем система начнёт ломаться под нагрузкой. Каждый пропущенный этап в модернизации увеличивает вероятность катастрофы. Чем раньше начнём, тем меньше рисков для бизнеса в будущем», — Вадим Зимин, руководитель отдела разработки, Энсайн.

Потеря локальности как ключевая проблема

Главная особенность legacy — утрата локальности изменений.

Любое изменение проходит через фильтр осторожности. Это меняет экономику доработок.

Почему смена подрядчика редко меняет картину

Когда ожидание простоты не оправдывается, логичным кажется сменить исполнителя.

Через несколько месяцев разговор снова возвращается к срокам, рискам и осторожным правкам.

Что важно зафиксировать до следующей правки

Если простые задачи регулярно превращаются в долгие и рискованные, это сигнал.

Система живет в режиме legacy. Ожидание простоты в этом режиме становится управленческой ошибкой.

Это не сделает работу быстрой. Зато перестанет создавать иллюзию, что она может быть простой.

Вместо вывода

Legacy не исчезает само. Его нельзя решить одной инициативой. С ним невозможно работать как с обычным проектом.

В крупных компаниях это не самый простой путь.

Зато самый честный.

5c:T2606,

Вопрос производительности ИТ-инфраструктуры стоит на повестке дня у каждого бизнеса. Чем быстрее работают системы, тем быстрее растет сам бизнес. В этой статье мы разберем, что конкретно влияет на производительность ИТ-инфраструктуры и как можно улучшить её работу, чтобы всё функционировало без сбоев.

Как добиться максимальной производительности вашей ИТ-инфраструктуры

Оцените текущее состояние своей инфраструктуры

Прежде чем улучшать производительность, необходимо понять, где именно система буксует. Это первый и самый важный шаг. Проведите аудит своей инфраструктуры: сколько ресурсов тратится на каждый процесс, что работает эффективно, а что требует внимания. Часто проблема в производительности кроется не в самом оборудовании, а в его неэффективном использовании.

Проверьте:

Загруженность серверов: какие из них работают на максимальной мощности? Где можно освободить ресурсы?
Сетевые узкие места: скорость передачи данных, проблемы с пропускной способностью — всё это влияет на общую производительность.
Хранилища данных: работают ли они с оптимальной скоростью? Есть ли возможность перейти на более быстрые SSD-диски?

Оптимизируйте использование ресурсов

Когда слабые места выявлены, можно начинать оптимизацию. Для этого не обязательно сразу покупать новое оборудование — многие проблемы можно решить путём корректировки настроек. Разгрузите серверы, перераспределив нагрузку, отключите ненужные приложения и процессы, освободив ресурсы для критичных задач, используйте виртуализацию, создавая несколько виртуальных машин на одном физическом сервере. Элементарные изменения в настройках могут значительно повысить производительность.

«В большинстве случаев можно добиться значительного улучшения производительности без дорогостоящих модернизаций, достаточно правильно настроить ресурсы и устранить неэффективное их использование», — Вадим Зимин, руководитель отдела разработки, Энсайн.

Модернизируйте оборудование и ПО

Если оптимизация существующих компонентов не даёт нужного эффекта, пора задуматься о модернизации оборудования и обновлении ПО. Это важный шаг для повышения производительности, особенно если система устарела.

Память и процессоры. Увеличение объема оперативной памяти или замена процессоров на более мощные модели позволит повысить общую производительность серверов.
Диски. Переход на SSD вместо традиционных HDD может дать серьезный прирост скорости. Диски SSD значительно быстрее читают и записывают данные, что влияет на скорость обработки.
Обновление ПО. Обновление операционных систем и программного обеспечения не только улучшает производительность, но и закрывает уязвимости, что также важно для стабильности системы.

Когда вы обновляете оборудование, стоит оценить и текущие возможности вашего ПО. Возможно, стоит внедрить более современные решения, которые позволят эффективно использовать ресурсы.

Внедрение автоматизации

Автоматизация — это ключ к повышению производительности. Если повторяющиеся задачи выполняются вручную, они отнимают слишком много времени у сотрудников и влияют на скорость работы всей системы.

Автоматизация процессов обновлений. Настройте автоматическую установку обновлений для всех систем и приложений. Это не только улучшит производительность, но и снизит риски безопасности.
Автоматизация резервного копирования. Настройте систему так, чтобы резервные копии создавались автоматически в нужное время.
Модульная автоматизация позволяет быстро масштабировать систему при необходимости, что тоже положительно влияет на производительность.

Постоянный мониторинг и анализ

Не забывайте, что производительность ИТ-системы — это не одноразовая задача. Чтобы система работала эффективно в долгосрочной перспективе, необходимо регулярно мониторить её состояние и проверять, где могут возникнуть проблемы. Используйте системы мониторинга для отслеживания работы серверов, приложений и сети в реальном времени, настройте оповещения о перегрузках или сбоях в работе, сравнивайте результаты с предыдущими показателями.

Подведем итоги

Максимальная производительность ИТ-инфраструктуры достигается не только за счет мощного оборудования, но и благодаря грамотной оптимизации, регулярной модернизации и внедрению автоматизации. Важно помнить, что это постоянный процесс, и вам нужно быть готовым к изменениям, которые будут улучшать работу вашей системы.

Уверены, что ваша ИТ-инфраструктура работает на полную мощность?

5d:T4203,

Мы сталкиваемся с этим из проекта в проект.

Компания начинает подключать ИИ к рабочему процессу, но сама еще не всегда понимает, какой результат хочет получить. Есть ожидание, что ИИ «натолкнет в нужную сторону»: предложит структуру, найдет слабые места, подскажет, как лучше организовать задачу.

В этом нет ошибки.

Часто именно так и начинается работа с новым процессом. Команда пробует, смотрит на варианты, собирает первые гипотезы. Остановиться в этот момент тоже риск. Можно остаться без развития, пока другие уже проверяют сценарии, тестируют инструменты и учатся быстрее работать с ИИ.

Но важно не путать два разных режима.

Когда процесс еще не описан, ИИ помогает думать.
Когда процесс уже понятен, ИИ помогает делать.

Во втором случае промты работают совсем иначе. Если есть данные, понятная задача, критерии результата и человек, который проверяет ответ, ИИ может давать очень сильный эффект.

Именно это видно по свежим материалам за май—июль 2026 года. Компании и эксперты всё реже говорят о промтах как о «секретных фразах» для ChatGPT. Фокус сместился к рабочим сценариям.

HR: промт работает, если есть управленческий контекст

Culture Amp в материале AI prompt guide for HR: 4 prompts for managers and leaders показывает, как HR-специалисты и руководители могут использовать ИИ для подготовки обратной связи, коммуникации изменений, анализа опросов и работы со сложными управленческими ситуациями.

Это хороший пример, где обычный запрос «напиши письмо сотрудникам» почти ничего не дает. ИИ напишет аккуратный текст, но не поймет, что происходит внутри команды.

Финансы: важен не отчет, а проверяемый вывод

В финансовой теме похожий подход показывают сразу несколько источников.

Journal of Accountancy в статье 9 tips to write more effective AI prompts пишет о базовых, но критичных правилах: конкретизировать задачу, давать контекст, проверять результат.

Unit4 в подборке 25 Practical AI Prompts Every CFO Should Use in 2026 рассматривает промты для CFO: cash flow, прогнозирование, сценарный анализ, управленческую отчетность, workforce planning.

Limelight в материале 10 AI Prompts for Finance Teams разбирает задачи вроде variance commentary, rolling forecast, anomaly detection, board report narrative и data validation.

Во всех этих примерах ИИ нужен не для красивого пересказа таблицы. Финансовой команде нужен вывод: что изменилось, почему это произошло, где отклонение, какие данные требуют проверки, что можно показать руководству.

Маркетинг: промт не заменяет нормальные данные

Маркетинг быстро показывает ограничение любого промта.

Improvado в гайде AI Marketing Prompts Guide: Best Practices 2026 разбирает промты для анализа кампаний, CRM, сегментов, атрибуции, рекламных каналов и метрик.

Маркетинговая команда может попросить ИИ проанализировать эффективность кампаний. Если расходы лежат в одном месте, заявки — в другом, продажи — в третьем, а качество лидов оценивается вручную, модель даст только общие рекомендации.

Промт здесь не решает проблему. Он просто аккуратно оформляет неполный контекст.

Другое дело, когда данные собраны: видны каналы, воронка, стоимость лида, конверсия в продажу, качество заявок, правила атрибуции и ограничения по бюджету. Тогда ИИ можно просить не «дать советы», а найти конкретное слабое место: где остановить кампанию, где перераспределить бюджет, где проблема в посадочной странице, а где — в обработке заявок.

В этом и разница между экспериментом и рабочим сценарием.

Юридические задачи: промт должен быть встроен в процесс

By Lawyers в новости Practical AI prompts added across By Lawyers publications сообщила, что добавила AI-промты прямо в юридические matter plans.

Это важная деталь. Промты не лежат отдельной подборкой. Они встроены в профессиональные сценарии: подготовить письмо клиенту, сравнить инструкции с документом, сделать summary, собрать материалы по делу.

Такой подход выглядит надежнее, чем общая папка «полезные промты». У промта появляется место в процессе, понятные входные данные и зона проверки.

Для бизнеса это хороший ориентир. Промт не должен быть случайной заготовкой из интернета. Он должен быть связан с конкретной задачей, ролью, документом и ответственностью.

Производство: ИИ ускоряет черновик, но не принимает решение

MAIN собрала подборку Manufacturing AI Prompts: 100 ChatGPT Examples для производственных специалистов: SOP, safety messages, quality checks, maintenance, training, сменные отчеты и коммуникации на производстве.

В таких задачах ИИ может быть полезен: подготовить черновик инструкции, чек-лист, обучающий материал, сообщение для смены.

Но есть граница. Если речь о безопасности, качестве, инженерных изменениях или регуляторных требованиях, результат должен проверять специалист.

Это правило применимо не только к производству. В ИТ такая же логика работает с персональными данными, доступами, архитектурными решениями, инцидентами безопасности, договорами и публичными заявлениями.

ИИ может ускорить подготовку. Но не должен становиться единственным источником решения там, где цена ошибки высокая.

Предпринимательство: сначала задача, потом автоматизация

Ben Angel в статье Entrepreneur 4 AI Prompts to Build a Profitable One-Person Business in 2026 пишет о промтах для one-person business.

Материал полезен не только для предпринимателей. В нем есть правильная логика: сначала нужно понять, какие задачи вообще можно отдавать ИИ.

Компании часто идут наоборот: выбирают инструмент, запускают пилот, собирают первые промты, а потом выясняют, что процесс не описан, данные не готовы, ответственность не закреплена.

В таком режиме ИИ может помочь найти направление. Но это еще не автоматизация.

Контент: ИИ работает лучше, когда получает фактуру

В выпуске Don Giannatti AI for Creatives — Week of June 12, 2026 разбирается подход к NotebookLM: использовать его не только для пересказа, но и для работы с книгами, статьями и собственными заметками.

В другом выпуске, AI for Creatives — Week of June 19, 2026, рассматривается workflow для маркетингового письма: прошлый текст, актуальное предложение, боль аудитории и эмоциональная линия.

Здесь снова видна та же закономерность.

Пустой запрос дает общий текст.
Запрос с фактурой, контекстом и ограничениями дает рабочий черновик.

Для контентных задач это особенно заметно. ИИ может хорошо ускорять работу, если ему дали материал, стиль, задачу и рамки. Если этого нет, он начинает писать слишком ровно и обобщенно.

Что говорят AI-платформы

Рекомендации самих платформ идут в ту же сторону.

Microsoft в материале Get started writing prompts in Microsoft 365 Copilot описывает хороший промт через цель, контекст, ожидания и источник.

Google в материале Writing effective AI prompts for business делает акцент на конкретике, контексте и итерациях. В статье 5 tips for writing great prompts for Gemini in the Workspace side panel используется структура persona, task, context, format.

Anthropic в статье Effective context engineering for AI agents говорит уже не только о prompt engineering, а о context engineering: какие данные, инструкции и сведения получает модель во время выполнения задачи.

Вывод

Промты работают по-разному в зависимости от зрелости процесса.

Когда компания еще не понимает, какой результат хочет получить, ИИ полезен как инструмент исследования. Он помогает разложить задачу, увидеть варианты, сформулировать первые гипотезы и нащупать направление. Это важный этап, и пропускать его не стоит. Но это еще не автоматизация.

Когда процесс уже описан, данные доступны, роли понятны, критерии результата согласованы и есть человек, который проверяет ответ, промты дают максимальный эффект. В таких сценариях ИИ действительно ускоряет работу, снимает рутину и может давать результат на 10 из 10.

Поэтому главный вопрос не в том, есть ли у компании библиотека промтов. Главный вопрос — понимает ли компания, где она сейчас находится: только изучает процесс или уже готова его автоматизировать.

5e:T2854,

Сценарий почти всегда один и тот же.

Если это повторяется, дело не в совпадении. И не в конкретной команде.

Это свойство системы.

Откуда берется ожидание простоты

Ожидание простоты возникает не из наивности. Оно возникает из прошлого опыта.

Именно здесь ожидание начинает конфликтовать с реальным устройством системы.

Что происходит внутри legacy при любой правке

Legacy не появляется внезапно. Оно формируется постепенно.

Снаружи это выглядит как замедление. Изнутри — как работа в условиях повышенного риска.

Почему опыт и усиление команды не ускоряют работу

В этот момент часто ожидают, что опыт или усиление команды решат проблему.

Это не вопрос квалификации. Это следствие состояния системы.

«Когда мы начинаем работать с legacy-системой, важно понимать, что это не просто устранение ошибок, а управление рисками, которые накапливаются годами. Важно вовремя вмешаться, прежде чем система начнёт ломаться под нагрузкой. Каждый пропущенный этап в модернизации увеличивает вероятность катастрофы. Чем раньше начнём, тем меньше рисков для бизнеса в будущем», — Вадим Зимин, руководитель отдела разработки, Энсайн.

Потеря локальности как ключевая проблема

Главная особенность legacy — утрата локальности изменений.

Любое изменение проходит через фильтр осторожности. Это меняет экономику доработок.

Почему смена подрядчика редко меняет картину

Когда ожидание простоты не оправдывается, логичным кажется сменить исполнителя.

Через несколько месяцев разговор снова возвращается к срокам, рискам и осторожным правкам.

Что важно зафиксировать до следующей правки

Если простые задачи регулярно превращаются в долгие и рискованные, это сигнал.

Система живет в режиме legacy. Ожидание простоты в этом режиме становится управленческой ошибкой.

Это не сделает работу быстрой. Зато перестанет создавать иллюзию, что она может быть простой.

Вместо вывода

Legacy не исчезает само. Его нельзя решить одной инициативой. С ним невозможно работать как с обычным проектом.

В крупных компаниях это не самый простой путь.

Зато самый честный.

5f:T230f,

Номер реестровой записи — 32983 от 17 апреля 2026 года.

Теперь инструмент доступен компаниям, разработчикам и ИТ-командам, работающим с Linux-серверами.

Зачем был создан HConfig

Какие задачи автоматизирует HConfig

Инструмент позволяет:

создавать пользователей веб-сервера;
настраивать окружение под технологический стек проекта;
устанавливать PHP-модули и зависимости;
разворачивать MySQL и PostgreSQL;
подключать SSL-сертификаты и Let’s Encrypt;
автоматизировать резервное копирование;
переносить и публиковать веб-контент.

В состав HConfig входят модули install, webuser, phpmodules, mysql, postgres, sslstore и letsencrypt.

Миграция и масштабирование инфраструктуры

Поддерживаемые платформы

На текущем этапе HConfig протестирован и поддерживается на RedOS 8.

Команда «Энсайн» продолжает расширять перечень поддерживаемых Linux-платформ и серверных конфигураций.

Почему мы открыли доступ к инструменту

Где найти HConfig

Получить информацию об инструменте и доступ к нему можно на странице решения по ссылке.

60:T3efa,

Компании активно тестируют искусственный интеллект. ИИ помогает искать информацию, анализировать документы, готовить отчеты, обрабатывать обращения и подсказывать сотрудникам решения.

На пилоте такие проекты часто выглядят убедительно. Система быстро отвечает, пользователи видят пользу, руководство получает понятную демонстрацию. Но после теста многие решения не переходят в постоянную работу.

Причина обычно не в самой модели. Проблемы начинаются в момент, когда ИИ нужно подключить к реальным данным компании, встроить в действующие процессы и передать на регулярную поддержку.

Пилот и промышленная эксплуатация работают в разных условиях

Пилот обычно запускают в контролируемой среде. Команда заранее отбирает данные, ограничивает число пользователей и вручную проверяет спорные ответы. В таких условиях проще показать хороший результат.

После масштабирования ситуация меняется. Система начинает работать с реальными документами, разными подразделениями и большим количеством запросов. Появляются устаревшие версии файлов, дубли, противоречия в данных и ограничения по доступу.

То, что не мешало на тесте, становится критичным при постоянной работе.

Именно поэтому успешный пилот еще не означает готовность решения к промышленной эксплуатации. Пилот проверяет идею. Промышленный запуск проверяет всю среду, в которую эта идея должна встроиться.

Данные становятся главным ограничением

Одна из частых причин остановки ИИ-проектов — состояние корпоративных данных.

Во многих компаниях информация распределена между разными системами. Часть данных хранится в учетных программах, часть — в порталах, таблицах и документах на сетевых дисках. Эти данные могут обновляться с разной скоростью и иметь разное качество.

На пилоте это можно обойти. Команда вручную готовит небольшую выборку и подключает ее к модели. Но при переходе к реальной эксплуатации ИИ должен работать со всей информационной средой компании.

Если данные не приведены в порядок, система начинает выдавать ненадежные ответы. Пользователи перепроверяют результат вручную. В итоге ИИ не ускоряет работу, а добавляет еще один слой контроля.

«ИИ хорошо показывает слабые места в данных, но не исправляет их сам. Если в компании есть дубли, устаревшие сведения и разные версии одной и той же информации, модель быстро начнет воспроизводить эти проблемы в ответах. Поэтому перед промышленным запуском нужно смотреть не только на качество модели, но и на состояние всей информационной среды», — отмечает Вадим Зимин, главный технический специалист «Энсайн».

Хороший ответ еще не меняет процесс

Многие пилоты строятся вокруг качества ответа. Модель должна найти нужный документ, подготовить краткое содержание, предложить решение или обнаружить ошибку.

Для демонстрации этого достаточно.

В реальной работе одного ответа мало. Результат должен попасть в понятный процесс. Если система нашла ошибку, ее должен кто-то исправить. Если подготовила документ, он должен пройти согласование. Если выявила риск, уведомление должно уйти ответственному сотруднику.

Без такой связки ИИ остается отдельным инструментом. Сотрудник получает рекомендацию, а дальше вручную переносит ее в другую систему или просто закрывает окно.

Полезный ИИ-сценарий должен быть встроен в рабочий контур компании. Обычно это требует интеграции с внутренними системами, настройки прав, журналирования действий и изменения привычного порядка работы.

Интеграция часто сложнее самой модели

На пилоте решение может работать отдельно. Пользователь загружает файл, задает вопрос и получает ответ.

После запуска появляются требования, которых не было в тестовой версии. Системе нужно получать данные из внутренних источников, учитывать права пользователей, передавать результат в корпоративные сервисы, хранить историю действий и работать стабильно при росте нагрузки.

В этот момент ИИ-проект становится не просто экспериментом с моделью, а полноценной интеграционной задачей.

Сложность часто находится не в настройке ИИ, а в связях с существующей инфраструктурой. У старых систем может не быть удобных API. Документация бывает неполной. Изменения приходится согласовывать с несколькими командами. Требования безопасности могут ограничивать способы подключения.

Поэтому стоимость промышленного внедрения почти всегда отличается от стоимости пилота. В пилоте проверяют идею. В промышленной версии нужно построить систему, которая будет работать каждый день.

ИТ-служба должна взять решение на поддержку

После завершения пилота решение должно перейти в эксплуатацию. Это значит, что за ним нужно следить, обновлять его, разбирать ошибки и контролировать расходы.

Для ИТ-службы важно понимать, как система устроена. Где хранятся данные. Какие действия выполняет модель. Кто имеет доступ к результатам. Что произойдет при сбое. Как восстановить историю действий. Как понять, что качество ответов ухудшилось.

Если этих механизмов нет, ИТ-служба не готова принимать решение на поддержку. Это нормальная позиция. Ответственность за работу системы остается на компании, даже если отдельные действия выполняет ИИ.

Промышленная эксплуатация требует не только запуска модели, но и понятного управления всей системой.

Стоимость меняется после масштабирования

На пилоте расходы обычно выглядят умеренно. Системой пользуется небольшая группа сотрудников, количество запросов ограничено, нагрузка понятна.

После запуска число обращений растет. ИИ начинает использоваться каждый день. Появляются автоматические сценарии, которые могут обращаться к модели без участия человека. Вместе с этим растут расходы на использование модели, инфраструктуру, хранение данных, интеграции и поддержку.

Поэтому экономику проекта нужно считать не по пилоту, а по предполагаемому промышленному объему.

Иначе компания может получить полезный сценарий, который окажется слишком дорогим для постоянного применения.

У пилота должен быть владелец внутри бизнеса

Еще одна причина остановки проектов связана не с технологией, а с управлением.

Компания запускает ИИ-пилот, потому что тема кажется перспективной. Команда делает прототип, пользователи видят пользу, руководители соглашаются, что направление интересное. После этого возникает вопрос: кто отвечает за дальнейшее развитие и какой результат должен получить бизнес?

Если ответа нет, проект зависает.

ИИ-пилот должен начинаться с понимания процесса, который нужно изменить. У него должен быть владелец внутри бизнеса. Не только ИТ-команда, которая отвечает за реализацию, а подразделение, которому нужен результат.

Когда бизнес-задача определена заранее, проще принять решение после пилота. Проект либо масштабируется, либо дорабатывается, либо закрывается. Без этого успешная демонстрация может так и остаться демонстрацией.

Как повысить шансы на промышленный запуск

Перед стартом ИИ-проекта важно смотреть не только на модель, но и на среду, в которой она будет работать.

Нужно заранее понять, какие данные понадобятся решению, где они находятся и насколько им можно доверять. Важно оценить, с какими системами придется интегрироваться и какие ограничения есть по безопасности. Отдельно стоит определить, кто будет отвечать за результат после запуска.

Также нужно заранее продумать эксплуатацию. Если решение нельзя наблюдать, контролировать и поддерживать, его сложно будет вывести за пределы пилота.

Такой подход может казаться более медленным на старте. Но он снижает риск ситуации, когда пилот прошел успешно, а масштабировать его невозможно.

Вывод

ИИ-пилоты часто останавливаются не потому, что модель не справилась с задачей.

Основные сложности появляются после демонстрации. Решение нужно подключить к реальным данным, встроить в рабочий процесс, защитить, проконтролировать и передать на постоянную поддержку.

ИИ дает эффект там, где он становится частью системы, а не отдельным экспериментом.

Поэтому промышленное внедрение начинается не с выбора самой сильной модели. Оно начинается с оценки данных, процессов, интеграций и готовности компании управлять новым решением каждый день.

61:T7686,

За личным кабинетом обычно приходят в тот момент, когда ручной работы стало слишком много.

Клиенты спрашивают, где заявка. Менеджеры ищут документы в почте. Пользователь каждый раз заново подбирает товар. Партнеры хотят видеть статусы, материалы, бонусы или поставки. Администраторы сайта просят разработчиков поменять то, что вроде бы должно редактироваться без программиста.

И где-то здесь появляется простая идея: давайте сделаем личный кабинет.

Идея правильная. Но есть нюанс. Личный кабинет сам по себе ничего не автоматизирует. Можно сделать вход, профиль, красивые вкладки, историю действий и уведомления. А потом обнаружить, что пользователь все равно пишет менеджеру, менеджер все равно переносит данные в CRM, а администратор все равно идет к разработчику за каждой нестандартной правкой.

Так происходит, когда личный кабинет начинают с интерфейса. Хотя начинать нужно с понимания какую ручную работу он должен убрать.

Содержание

Личный кабинет нужен не всегда

Первый релиз лучше делать скучным

Иногда личный кабинет нужен не одному человеку, а всему процессу

Партнерский кабинет нельзя делать одним для всех

Маленький сайт не всегда означает простую систему

Админка — это тоже личный кабинет

Что стоит подготовить до разработки

Где обычно появляются переделки

Личный кабинет нужен не всегда

Это первое, что стоит честно сказать.

Если сайт нужен только для того, чтобы пользователь прочитал информацию и оставил простую заявку, личный кабинет может быть лишним. Регистрация, восстановление пароля, хранение данных, права доступа, поддержка учетных записей — все это добавляет сложность. Не каждый процесс этого требует.

Личный кабинет имеет смысл, когда пользователь возвращается. Не один раз, а регулярно. Он хочет видеть статус, историю, документы, рекомендации, сохраненные товары, записи, бонусы, заявки или персональные условия.

То есть кабинет появляется не потому, что так принято. Он появляется там, где есть повторяющееся взаимодействие.

Хороший тест простой. Нужно открыть переписку менеджеров, поддержку, CRM, таблицы и посмотреть, какие вопросы люди задают снова и снова. Где моя заявка? Когда запись? Что с документами? Какие товары я сохранял? Сколько бонусов накоплено? Что было с машиной в прошлый раз? Где поставка?

Если личный кабинет закрывает такие вопросы, он помогает бизнесу. Если нет, он просто становится еще одним разделом сайта.

Первый релиз лучше делать скучным

У бизнеса часто есть понятное желание: если уж делать личный кабинет, то сразу нормальный. С профилем, документами, уведомлениями, статусами, бонусами, аналитикой, избранным, платежами, настройками и админкой.

На старте это выглядит разумно. Потом проект начинает разрастаться.

Мы видели это в разных задачах: чем больше функций закладывают до проверки основного сценария, тем сложнее становится договориться, что вообще считать готовым результатом. Каждая роль хочет свой раздел. Каждый отдел приносит свои поля. В кабинете появляются функции, которыми еще никто не пользовался, но их уже нужно проектировать, разрабатывать и поддерживать.

Поэтому первый релиз лучше делать скучным. В хорошем смысле.

Он должен закрывать одну главную проблему. Если клиент постоянно спрашивает статус заявки, сделайте нормальный статус и понятную историю. Если пользователь каждый раз заново подбирает продукт, дайте ему сохранить результат. Если сотрудник вручную пересылает документы, сделайте загрузку, проверку и понятный ответ: принято, нужно исправить, находится на рассмотрении.

На сайте смазочных материалов Газпромнефть-СМ личный кабинет как раз можно рассматривать как продолжение подбора. Пользователь сохраняет продукты, сравнивает их, сохраняет результаты подбора смазочных материалов, добавляет свой автомобиль и получает более релевантные рекомендации.

Это не кабинет ради кабинета. Человек уже пришел с задачей — подобрать продукт. Личный кабинет помогает ему не начинать заново, а продолжить с того места, где он остановился.

Вот это хороший принцип для первого релиза: не пытаться заменить весь сервис, а убрать самое раздражающее повторение.

Иногда личный кабинет нужен не одному человеку, а всему процессу

Когда говорят «личный кабинет», чаще всего представляют клиента. Он вошел на сайт, увидел свои данные, заявку, историю, документы. Но в реальности у одного процесса часто несколько участников. И каждому нужен свой экран.

Возьмем станцию технического обслуживания.

Для владельца автомобиля личный кабинет на сайте — это история обслуживания. Какие работы делали, когда была запись, какие рекомендации дал сервис, что стоит проверить в следующий раз. Это удобно. Человеку не нужно звонить на станцию и вспоминать, что происходило полгода назад.

Но этим процесс не заканчивается.

Мастер СТО работает уже не на сайте, а внутри CRM. Ему важно видеть свою запись на день, клиентов, время приемки, задачи, комментарии, загрузку. Для него кабинет — это рабочий день, разложенный по понятным действиям.

Руководителю станции нужен другой уровень. Загруженность сотрудников и боксов. Распределение расходных материалов. Оповещения. Контроль качества. Автоматическое формирование документов. Он не просто смотрит, кто приехал на обслуживание. Он управляет тем, чтобы станция работала без провалов.

Формально все это можно назвать личными кабинетами. Но по смыслу это разные рабочие пространства.

И если на старте описать только клиента, половина процесса останется за кадром. Клиентский интерфейс будет выглядеть хорошо, а внутри сотрудники продолжат жить в таблицах, ручных сообщениях и устных договоренностях.

Поэтому перед разработкой полезно нарисовать не экраны, а участников процесса. Кто приходит снаружи. Кто принимает заявку внутри. Кто меняет статус. Кто контролирует качество. Кто отвечает за документы. Кто смотрит загрузку. Это часто быстрее показывает будущий личный кабинет, чем обсуждение меню и кнопок.

Партнерский кабинет нельзя делать одним для всех

С партнерскими кабинетами есть похожая ловушка. Компания делает один закрытый раздел для всех партнеров. Туда складывают новости, материалы, документы, мероприятия, бонусы, статусы, поставки. Формально все на месте. По факту каждому пользователю приходится продираться через лишнее.

Если у компании разные типы партнеров, им редко нужен одинаковый кабинет.

Врачам может быть нужен обучающий контент: материалы, вебинары, регистрация на мероприятия, записи выступлений, профессиональные рекомендации.

Покупателям важнее бонусная программа, персональные предложения, история активности, доступные привилегии.

Дистрибьюторам нужна совсем другая информация: новости по отгрузкам и поставкам товаров, статусы заказов, отслеживание логистики, документы, уведомления о задержках или изменениях.

Если показать всем все, получится шум. Врач увидит логистику. Покупатель — служебные новости для дистрибьюторов. Дистрибьютор — обучающие материалы, которые не помогают ему решать рабочие задачи.

Поэтому партнерский кабинет лучше собирать от ролей. Не «какие разделы мы можем туда положить», а «зачем этот человек вообще заходит». Что он должен увидеть первым. Какое действие совершить. О чем его нужно уведомить. Что, наоборот, лучше скрыть, чтобы не мешало.

Часто это не усложняет кабинет, а наоборот упрощает. Просто у каждой роли появляется свой маршрут.

Маленький сайт не всегда означает простую систему

Есть еще одна ситуация, где легко ошибиться. Снаружи сайт выглядит небольшим. Например, лендинг. Одна страница, форма, несколько блоков, кнопка отправки.

Кажется, что сложной системы там быть не может.

Но после формы может начинаться длинный внутренний процесс. Пользователь подал заявку, загрузил данные, получил уведомление, потом ждет проверки, отвечает на вопросы, получает статус, общается с представителями организации. За этим могут стоять 1С, CRM, внутренние согласования, документы и уведомления.

На сайте Московского венчурного фонда внешний слой может выглядеть как лендинг или одностраничный сайт. Но основной функционал находится внутри: личный кабинет, связанный с 1С и другими системами. Пользователь отслеживает статус заявки, получает уведомления, загружает данные и ведет коммуникацию с представителями фонда.

Для пользователя разница огромная. Он не отправляет форму «в никуда». Он видит, что происходит дальше.

Для команды фонда разница тоже ощутимая. Заявка не теряется в почте. Данные не собираются по разным каналам. Коммуникация привязана к процессу.

Поэтому размер сайта вообще не главный показатель. Главный вопрос другой: что происходит после первого действия пользователя? Если дальше начинается длинная обработка, личный кабинет может быть нужен даже там, где снаружи всего одна посадочная страница.

Админка — это тоже личный кабинет

Про административную часть часто вспоминают поздно. Сначала обсуждают клиента, партнера, заявителя, покупателя. А потом оказывается, что кто-то внутри компании должен всем этим управлять.

И вот здесь может начаться самое дорогое.

Если администратор не может сам создать раздел, обновить страницу, добавить материал, поменять блок или настроить подсайт, он идет к разработчикам. Один раз — нормально. Второй — терпимо. Через несколько месяцев сайт начинает жить через постоянные мелкие доработки.

В проекте ВДНХ административный кабинет решает как раз эту задачу. Это не просто панель для правки текста, а конструктор контента и инструмент управления подсайтами. Администратор может создавать и наполнять разделы, управлять контентом, работать с подсайтами и настраивать страницы через понятный интерфейс.

Для большого сайта это критично. Контент меняется часто. Появляются события, разделы, спецпроекты, страницы, новые материалы. Если каждый раз нужен разработчик, поддержка становится дорогой и медленной.

Нормальная админка экономит не на разработке первого релиза, а на жизни продукта после запуска. Именно поэтому ее нельзя считать второстепенной частью проекта.

Что стоит подготовить до разработки

Перед обращением к подрядчику не нужно приносить готовые макеты. Иногда они даже мешают, если за ними нет описанного процесса.

Лучше подготовить более простые вещи.

Кто будет пользоваться кабинетом. Не общими словами «пользователи», а конкретно: клиент, врач, покупатель, дистрибьютор, мастер, руководитель, администратор, заявитель.

Что каждый из них должен сделать без участия сотрудника. Подать заявку, сохранить продукт, загрузить документ, посмотреть статус, записаться, сравнить товары, отследить поставку, зарегистрироваться на мероприятие.

Какие данные ему нужны для этого действия. История, документы, бонусы, рекомендации, статусы, записи, уведомления, результаты подбора, логистика.

Где эти данные сейчас находятся. На сайте, в CRM, в 1С, в ERP, в почте, в таблице, в файловом хранилище, у внешнего сервиса.

И кто внутри компании будет управлять процессом. Менеджер, оператор, мастер, руководитель, контент-администратор, сотрудник поддержки.

«Часто на старте нам приносят не процесс, а набор будущих экранов. Профиль, заявки, документы, уведомления — вроде все понятно. Но потом начинаются вопросы: кто меняет статус, где лежат данные, что видит менеджер, что делать, если пользователь загрузил не тот файл. Если это не разобрать заранее, личный кабинет быстро превращается в серию доработок», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

На этом этапе обычно всплывают самые полезные вопросы. Например, кто меняет статус заявки. Нужно ли пользователю видеть комментарий менеджера. Какие документы можно загрузить. Что делать, если интеграция с 1С временно недоступна. Кто получает уведомление об ошибке. Можно ли администратору создать новую страницу без разработчика.

Это не бюрократия перед проектом. Это способ заранее увидеть места, где личный кабинет может сломаться.

Где обычно появляются переделки

Переделки чаще всего появляются не потому, что кто-то плохо нарисовал экран. Проблема глубже.

Начали с дизайна, а потом поняли, что непонятно, кто меняет статусы.

Сделали общий кабинет для всех партнеров, а потом выяснилось, что врачам, покупателям и дистрибьюторам нужны разные материалы.

Запустили форму заявки, но не продумали, где пользователь увидит следующий шаг.

Сделали красивую клиентскую часть, а менеджеры внутри компании все равно работают через таблицы.

Подключили данные из нескольких систем, но не решили, какая из них главная. В итоге в кабинете один статус, в CRM другой, в 1С третий.

Не заложили историю действий. Потом невозможно быстро понять, кто изменил данные, когда загрузили документ и почему уведомление не ушло.

Не продумали админку. После запуска за каждой правкой снова идут к разработчикам.

Все эти проблемы выглядят мелкими по отдельности. Но именно из них складывается ощущение: кабинет вроде есть, а пользоваться им неудобно, поддерживать дорого, развивать сложно.

Почему похожие кабинеты стоят по-разному

На макете два личных кабинета могут выглядеть почти одинаково. Вход, профиль, несколько вкладок, уведомления, история.

В разработке это могут быть два разных мира.

Один кабинет просто сохраняет продукты и результаты подбора. Другой тянет данные из 1С, показывает статусы, разделяет роли, хранит документы, отправляет уведомления, фиксирует историю, дает разные права администраторам и пользователям.

Самые сложные части обычно не видны на первом экране. Интеграции. Права доступа. Логика статусов. История изменений. Административная часть. Исключения. Ошибки. Резервные сценарии.

Поэтому стоимость нельзя оценивать только по количеству страниц в интерфейсе. Важнее понять, сколько процессов скрыто за этими страницами.

Кабинет для сохранения подборов и сравнения продуктов — один уровень. Система для СТО с клиентом, мастером, руководителем, документами, загрузкой боксов и контролем качества — другой. Лендинг с личным кабинетом, связанным с 1С и внутренней обработкой заявок, тоже может оказаться сложнее, чем кажется. Партнерский кабинет с разными ролями для врачей, покупателей и дистрибьюторов добавляет еще один слой логики.

Поэтому нормальная оценка начинается не с фразы «нам нужен личный кабинет». Она начинается с разговора о сценариях.

Итог

Личный кабинет — это не регистрация, профиль и несколько вкладок.

Это способ убрать часть ручной работы из повторяющегося процесса. Где-то он помогает клиенту видеть историю обслуживания автомобиля. Где-то — сохранять результаты подбора смазочных материалов. Где-то — отслеживать заявку после отправки формы на лендинге. Где-то — разделять контент для врачей, покупателей и дистрибьюторов. Где-то — управлять большим сайтом без постоянных обращений к разработчикам.

Начинать стоит не с экранов. Сначала нужно понять, кто будет пользоваться кабинетом, что этот человек должен сделать сам и какие данные для этого нужны.

Тогда личный кабинет становится рабочим инструментом. Не просто закрытым разделом сайта, а частью процесса, которая действительно снижает ручную работу и помогает продукту развиваться без постоянных переделок.

62:T2075,

Работа с legacy-системами всегда сопряжена с рядом уникальных проблем, которые не очевидны на первый взгляд. Несмотря на это, многие подрядчики допускают типичные ошибки при поддержке таких систем. Эти ошибки не только замедляют работу, но и создают долгосрочные риски, которые могут дорого обойтись бизнесу. Разберем наиболее распространенные проблемы, с которыми сталкиваются подрядчики, и какие последствия это может повлечь.

Ключевые ошибки

1. Недооценка сложности системы

Многие подрядчики неправильно оценивают сложности legacy-систем. Под их стабильной работой скрываются многочисленные проблемы, такие как устаревшие компоненты и скрытые зависимости. Когда подрядчик не учитывает все тонкости системы, даже небольшие изменения могут вызвать крупные сбои и задержки.

2. Игнорирование технического долга

Технический долг — неизбежный элемент работы с устаревшими системами. Подрядчики часто недооценивают его важность, что приводит к накоплению проблем, которые в дальнейшем могут осложнить модернизацию и поддержку системы.

3. Проблемы с интеграцией

Интеграция legacy-систем с новыми решениями часто вызывает сложности. Неправильная настройка интеграций может привести к несовместимости компонентов, что влияет на стабильность работы и производительность системы.

4. Отсутствие понимания архитектуры системы

Каждая legacy-система имеет уникальную архитектуру, которую необходимо учитывать при внесении изменений. Без должного понимания этих особенностей подрядчик может внести изменения, которые нарушат работу системы или создадут новые проблемы.

«Подрядчики, не понимающие архитектурных особенностей старых систем, рискуют создать больше проблем, чем решить. Каждая неучтённая зависимость может привести к системным сбоям и потере данных, что ставит под угрозу всю инфраструктуру бизнеса», — Вадим Зимин, начальник отдела ИТ инфраструктуры ЭНСАЙН.

5. Неэффективное тестирование

Нередко подрядчики недостаточно тщательно тестируют систему после внесения изменений. Это особенно важно для legacy-систем, где каждое обновление может привести к неожиданным сбоям, если не провести должную проверку.

Последствия этих ошибок

Ошибки подрядчиков могут привести к различным последствиям для бизнеса. Во-первых, это дополнительные финансовые затраты, которые могут возникнуть при исправлении ошибок, модернизации системы или устранении сбойных ситуаций. Во-вторых, потеря времени и ресурсов на исправление проблем, которые могли быть предотвращены на этапе анализа. В-третьих, риски для безопасности данных и бизнес-процессов, которые могут возникнуть из-за недооценки уязвимостей в системе.

В некоторых случаях последствия возникают совсем неочевидные, к примеру:

Влияние на внутреннюю команду и рабочие процессы. Ошибки подрядчиков в работе с legacy-системами могут сильно перегрузить внутреннюю команду, так как они вынуждены тратить дополнительное время и ресурсы на исправление проблем.
Недооценка адаптации системы к изменениям в бизнесе. Многие подрядчики не учитывают, что legacy-системы должны быть гибкими и адаптируемыми к изменяющимся бизнес-потребностям. Неспособность системы адаптироваться к изменяющимся условиям может привести к ее быстрой устаревшей, а бизнес будет вынужден искать решения на стороне.

В этой статье мы подробно разобрали типичные ошибки подрядчиков при работе с legacy-системами и их последствия. Если их не учесть на раннем этапе, они могут стать дорогостоящими как в плане времени, так и финансов. Чтобы избежать таких проблем, необходимо выбирать подрядчиков с опытом работы с устаревшими системами, которые могут предсказать потенциальные проблемы и устранить их до того, как они станут угрозой для бизнеса.

Доверие к системе начинается с её понимания. Убедитесь, что ваша система готова к будущему.

63:T5063,

Сегодня хотим поделиться историей одного проекта, который начался с, казалось бы, рутинной задачи — рассылки. Но, как это часто бывает, дьявол оказался в деталях, а именно — в персональных данных.

Рис. 1. Защищенный контур CRM: централизованное управление контактами, журналирование действий и модуль управления согласиями.

1) Постановка задачи: цена зависимости от внешних платформ

К нам пришел клиент с задачей: нужна CRM-система для email-рассылок, которая будет жить внутри нашего защищенного контура. Причем система должна была полноценно работать с персональными данными (ПДн): хранить их, управлять согласиями, персонализировать контент и скрупулезно фиксировать каждое действие пользователя (рис. 1). Существующие на тот момент популярные онлайн-сервисы для этой задачи уже не годились. Наши сценарии работы вышли далеко за рамки их стандартного функционала, где рассылка — это только верхушка айсберга.

2) Выбор решения: свое или готовое?

Первый вопрос, который встал перед командой: адаптировать готовый облачный сервис или пилить свое решение с нуля? На первый взгляд, оба варианта рабочие. Отправить письма — не проблема, это умеет любой приличный сервис. Однако в подобных проектах требования регуляторов (152-ФЗ, Приказ №21 ФСТЭК и др.) диктуют архитектуру. Поэтому, чтобы не наломать дров, мы сразу задали себе несколько ключевых вопросов:

Где будут храниться данные? Принципиально — они не должны покидать контур заказчика. Никаких «облачных» историй у третьих лиц.
Кто будет контролировать этот контур? Внешние сервисы не дают нужной гибкости. Ты зависишь от их техподдержки, обновлений и политик безопасности.
Как будет вестись журнал действий и согласий? Нам требовалось полное, доказуемое журналирование (логирование) каждого действия: от загрузки данных до отзыва согласия.
Насколько глубоко можно настроить логику? Нужна была кастомная логика управления согласиями, а не просто галочка «согласен».

Готовый сервис — это удобно, спору нет. Подключил, настроил и поехал. Но как только речь заходит о полном контроле над данными, это удобство превращается в тыкву. Оно упирается в жесткие рамки платформы. Простой пример: популярные сервисы рассылок предлагают 4-й уровень защищенности персональных данных (УЗ-4), а требования законодательства в нашем кейсе диктовали минимум второй (УЗ-2). Доверить такой объем ПДн стороннему API, даже самому защищенному, — примерно то же самое, что и оставить ключ от квартиры под ковриком. Всегда есть риск. Поэтому взвесив плюсы и минусы,мы двинулись в сторону разработки собственной CRM на Django.

3) Задачи и наши решения

Расскажем по задачам, которые мы решали, и инструментам, которые для этого использовали.

Задача: обеспечить хранение данных и доказуемость действий

Самым чувствительным местом оказалась работа с данными. Чтобы обеспечить их хранение и доказуемость действий, мы, во-первых, контактные данные, статусы согласий и служебные метки положили в одну модель. Для нашего случая это было оптимально: такой подход упростил запросы и обработку, ведь система работала с небольшим числом сущностей и невысокой нагрузкой.

Во-вторых, для отслеживания всех манипуляций с персональными данными мы задействовали встроенные в Django механизмы журналирования. Любое действие, будь то импорт контакта или подтверждение согласия, с отметкой времени падало в журнал (см. рис. 2). Это дало нам возможность отследить полный жизненный цикл обработки персональных данных.

Для каждого пользователя мы генерировали уникальный идентификатор (UID). Для этого использовали криптографически стойкий алгоритм binascii.hexlify(os.urandom(64)).decode(). На выходе получалась 128-символьная строка. Можете представить, каковы шансы подобрать или случайно угадать такой ключ для базы в 70 тысяч пользователей? Правильно, практически нулевые.

Рис. 2. Жизненный цикл обработки персональных данных: от импорта контакта до фиксации актуального статуса с полным журналированием каждого шага.

Задача: создавать персонализированные и визуально-привлекательные письма

Отдельная задача — дать в руки заказчику инструмент для создания красивых и личных писем. Для этого мы встроили в CRM редактор шаблонов, чтобы верстать макеты можно было прямо в системе, без прыжков по сторонним сервисам. Для персонализации использовали плейсхолдеры (например, _FIO_). При отправке они автоматически заменялись на реальные данные пользователя. Также добавили гибкую систему фильтров, чтобы можно было легко формировать рассылки на конкретные сегменты аудитории. Эти простые, в общем-то, инструменты убрали из процесса рутину, снизили риск ошибки из-за человеческого фактора и ощутимо ускорили подготовку кампаний.

Задача: собирать статистику, не используя внешние сервисы

Поскольку сервис мы писали с нуля, у нас не было навороченных инструментов аналитики, как в готовых платформах. Да мы и не могли их использовать из соображений безопасности. Задачу сбора статистики по открытиям писем решили старым дедовским способом — с помощью трекинг-пикселя. В каждое письмо мы добавляли невидимое изображение размером 1x1 пиксель. Когда человек открывал письмо, его почтовый клиент обращался к нашему серверу за этой картинкой. Мы фиксировали этот запрос и таким образом анонимно, без сбора лишних данных, получали нужную статистику (см. рис. 3).

Рис. 3. Схема работы трекинг-пикселя: письмо отправляется из CRM, при открытии происходит безопасный запрос к серверу для загрузки невидимого изображения, что позволяет собрать анонимную статистику без передачи данных внешним сервисам.

Задача: обеспечить высокую доставляемость писем

Следующая важная задача — обеспечить высокую доставляемость писем. Чтобы наши сообщения летели во «Входящие», а не в спам, мы «прогревали» почтовые серверы. Это обязательная процедура для новых доменов. Перед основным запуском система автоматически рассылала нейтральные письма небольшими порциями по всей базе подписчиков. Благодаря этому «прогреву» почтовый сервер заказчика «познакомился» с другими серверами и «заработал» репутацию надежного отправителя. После такого «прогрева» все 70 000 писем уходили со скоростью, близкой к целевой — 60 000 писем в час.

Кстати, грамотный расчет времени на «прогрев» и правильная настройка почтовой инфраструктуры (SPF, DKIM, DMARC) — это не какие-то «серые схемы», а основа основ и прямая экономия ресурсов в будущем. Кому интересны технические детали этого процесса, можете почитать, например, вот тут. А мы в одной из следующих статей расскажем, как такой подход помогает экономить на масштабе.

Задача: автоматизировать управление согласиями

Мы свели к минимуму ручную работу с согласиями. Для этого разработали алгоритм, который обрабатывал ответы со страницы подтверждения согласия. Его результаты мы вывели через отдельный модуль в административную панель CRM, чтобы доступ к базе данных с актуальными статусами был максимально оперативным. Система управляла согласиями автоматически: пользователь нажал «Согласен» — в базе данных обновился статус, в журнале появилась запись. Нажал «Отказаться» — получил соответствующий статус, и его данные тут же исключились из активных рассылок. Никаких ручных правок, все строго по букве 152-ФЗ.

4) Инфраструктура и разумная достаточность

Одним приложением такую задачу не закрыть. Логика работы с данными была только частью решения. Не меньшее значение имело то, в каком контуре живет система и как организован к ней доступ.

Для создания защищенной инфраструктуры мы использовали стек российских технологий: РЕД ОС, хостинг в сертифицированном сегменте Selectel, антивирус Dr.Web и Secret Net Studio для Linux для контроля доступа.

При этом мы сознательно не стали внедрять некоторые избыточные, на наш взгляд, меры защиты. Например, шифрование всей базы данных или разворачивание отдельных VPN-серверов для доступа. Такие решения серьезно усложнили бы архитектуру и кратно увеличили бы стоимость владения системой.

Мы оценили риски, нагрузку и сценарии использования и сознательно выбрали достаточный уровень защиты вместо избыточного. Нашей целью была реальная, адекватная процессу безопасность, а не «бумажная» безопасность для галочки.

5) Результаты

ИТОГО, что мы получили на выходе:

Сроки: Бэкенд написали за 2 недели. Весь проект под ключ, не считая согласования дизайна, занял 3 недели.
Масштаб: система уверенно обслуживала базу в 70 000 пользователей.
Автоматизация: сбор согласий и управление ими были автоматизированы на 100%. Перед ключевым мероприятием заказчик одной кнопкой получил полностью готовую к рассылке, актуальную базу.
Независимость: клиент получил 100% независимость от внешних сервисов рассылок и их политик.

Какие выводы мы для себя сделали?

Этот кейс — отличное напоминание: система может казаться простой по набору функций, но как только дело доходит до ПДн, безопасности и аудита, ее реальная сложность резко возрастает. Нельзя обеспечить соответствие закону, просто написав хороший код. Это всегда работа на трех уровнях, как три кита, на которых все держится: логика самого приложения, грамотно выстроенная инфраструктура и отлаженные процессы у самого заказчика. Уберите одного кита — и вся конструкция рухнет.

P.S. Эта CRM, пройдя боевое крещение, в итоге стала одним из наших коробочных продуктов. Так что если перед вами стоят похожие задачи по работе с персональными данными — вы знаете, к кому обратиться. Будем рады помочь.

64:T206a,

Если вы когда-либо сталкивались с рисками информационной безопасности, вы знаете, что это не просто проблема с компьютерами. Это вопрос, который может в мгновение ока вывести ваш бизнес из строя. Когда мы говорим о защите данных и инфраструктуры, недостаточно просто поставить антивирус. Речь идет о стратегии, о том, как мы строим защиту на долгие годы, как минимизируем риски и как не даем атакам шанс разрушить нашу работу. И для этого нужны эксперты.

Как это было в начале

В начале мы сами недооценивали значимость информационной безопасности, полагая, что всё под контролем с базовыми средствами защиты. Однако с каждым годом угрозы становятся всё более сложными. Простые решения становятся недостаточными, а кибератаки — всё более изощренными. Это часто приводит к непредсказуемым последствиям, таким как утечка данных, потеря клиентов или серьезные финансовые убытки. Игнорировать эти риски нельзя.

Почему с экспертами безопаснее

Эксперты по информационной безопасности — это те профессионалы, которые понимают глубину угроз и могут построить систему защиты, которая работает профилактически, а не только реактивно. Эксперт не просто ставит ПО или настраивает фаервол. Он понимает глубину угроз и всегда предвосхищает потенциальные риски. У него есть знания и опыт, чтобы оценить и минимизировать эти риски на каждом уровне.

Уязвимости могут скрываться не только в старом ПО. Очень часто это слабые места, которые никто не видит — человеческий фактор, неправильная настройка системы или политика доступа.

Преимущества работы с экспертами

Роль экспертов по информационной безопасности в защите бизнеса

1. Профилактика вместо борьбы с последствиями

Эксперты не ждут инцидента, чтобы начать действовать. Они предотвращают угрозы на стадии их возникновения. У них есть опыт и инструменты, чтобы заранее выявить слабые места и устранить их.

2. Гибкость и адаптивность

Эксперт всегда в курсе последних тенденций в области безопасности. Он следит за новыми угрозами, обучается новым методам защиты и адаптирует стратегию защиты под реальные угрозы.

3. Оперативное реагирование на инциденты

Даже если что-то пошло не так, профессионал будет готов быстро и эффективно устранить проблему. Это не значит, что можно расслабляться, но это дает уверенность, что в случае беды последствия будут минимальными.

4. Репутация и доверие клиентов

Никакие деньги не могут вернуть репутацию, потерянную из-за утечки данных или атаки. Защита данных — это ответственность компании. Работа с экспертами помогает показать, что безопасность для компании на первом месте.

Не пытайтесь делать всё сами

Многие компании пытаются сэкономить на безопасности, полагаясь на внутренние силы. Это может показаться разумным, пока не происходит инцидент. Когда угроза становится реальностью, стоимость восстановления бизнеса уже многократно превосходит затраты на квалифицированную помощь.

«Каждая уязвимость, оставленная без внимания, становится потенциальной угрозой для бизнеса. Эксперты способны превратить этот риск в надежную защиту», — Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн».

Без экспертов можно столкнуться с рядом проблем, включая недостаточную защиту от новых видов атак, плохую настройку доступа, неспособность к быстрому реагированию. Эти мелочи приводят к огромным проблемам, которые трудно решить без должных знаний и опыта.

Подведем итоги

Информационная безопасность — это не область для экспериментов. Защита данных и инфраструктуры требует профессионализма и глубоких знаний. Работая с экспертами, компания не только защищает данные, но и защищает будущее бизнеса. Эксперты помогают избежать катастроф и делают компанию устойчивой к любым угрозам, что в долгосрочной перспективе приводит к укреплению бизнеса и повышению доверия со стороны клиентов.

6:{"items":[{"id":124,"type":"internal","newsTypeId":1,"serviceId":null,"url":"hconfig-reestr-rossiyskogo-po","name":"Как мы включили HConfig в реестр российского ПО: опыт Энсайн","annotation":"","blog":"$1a","backgroundType":null,"sizeType":1,"datePublication":"2026-10-01 00:00:00","position":null,"meta_title":"Как включить ПО в реестр российского ПО: опыт HConfig | Энсайн","meta_description":"Опыт Энсайн по включению HConfig в реестр российского ПО: причины отказов, требования, техническая проверка и выводы для разработчиков.","meta_keywords":null,"meta_og_title":"Как мы включили HConfig в реестр российского ПО","meta_og_description":"Практический опыт Энсайн: две неудачные заявки, доработка документов, техническая проверка HConfig и итоговое включение продукта в реестр.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/hconfig-reestr-rossiyskogo-po","seo_canonical":"https://nsign.ru/blog/hconfig-reestr-rossiyskogo-po","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как мы включили HConfig в реестр российского ПО: опыт Энсайн\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/hconfig-reestr-rossiyskogo-po\"\r\n }\r\n}","hidden":0,"createdAt":"2026-10-01 18:59:47","updatedAt":"2026-10-01 19:20:17","relatedService":null,"image":"https://n-dl.nsign.ru/repository/42/1d/8e10548f1153f6b55f641201d834708bec1c61b1.jpg","services":[],"randomBlogs":[{"id":78,"type":"internal","newsTypeId":1,"serviceId":null,"url":"informatsionnaya-podderzhka-i-uluchshenie-polzovatelskogo-opyta","name":"Как информационная поддержка помогает улучшить пользовательский опыт","annotation":"","blog":"$1b","backgroundType":null,"sizeType":1,"datePublication":"2026-05-13 00:00:00","position":41,"meta_title":"Как информационная поддержка помогает улучшить пользовательский опыт","meta_description":"Узнайте, как информационная поддержка помогает улучшить пользовательский опыт, повысить удовлетворенность клиентов и укрепить доверие.","meta_keywords":"информационная поддержка, улучшение пользовательского опыта, поддержка клиентов, эффективность сервиса, удовлетворенность клиентов","meta_og_title":"Как информационная поддержка помогает улучшить пользовательский опыт","meta_og_description":"Узнайте, как информационная поддержка помогает улучшить пользовательский опыт, повысить удовлетворенность клиентов и укрепить доверие.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/informatsionnaya-podderzhka-i-uluchshenie-polzovatelskogo-opyta","seo_canonical":"https://nsign.ru/blog/informatsionnaya-podderzhka-i-uluchshenie-polzovatelskogo-opyta","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как информационная поддержка помогает улучшить пользовательский опыт\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/informatsionnaya-podderzhka-i-uluchshenie-polzovatelskogo-opyta\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-17 05:43:04","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/6b/c9/fcc44934d78bfdc82255269bd115201bd122a234.jpg","services":[]},{"id":111,"type":"internal","newsTypeId":1,"serviceId":null,"url":"chto-takoe-cms","name":"Что такое CMS и зачем она нужна сайту","annotation":"","blog":"$1c","backgroundType":null,"sizeType":1,"datePublication":"2026-08-18 00:00:00","position":11,"meta_title":"Что такое CMS и зачем она нужна сайту | Энсайн","meta_description":"Что такое CMS, как работает система управления сайтом, какие задачи решает и зачем нужна бизнесу. Возможности CMS на корпоративных проектах.","meta_keywords":null,"meta_og_title":"Что такое CMS и зачем она нужна сайту","meta_og_description":"Разбираем, как работает CMS, какие задачи она решает и какую роль система управления контентом играет на корпоративном сайте.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/chto-takoe-cms","seo_canonical":"https://nsign.ru/blog/chto-takoe-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Что такое CMS и зачем она нужна сайту\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/chto-takoe-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-18 10:58:34","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/45/b5/861e1aa985b87942bfd91b546d5adeedcb406e23.jpg","services":[]},{"id":37,"type":"internal","newsTypeId":1,"serviceId":null,"url":"legacy-managing-risks-strategies-errors","name":"Как управлять legacy-системами в крупной компании: риски, стратегии, ошибки","annotation":"","blog":"$1d","backgroundType":null,"sizeType":1,"datePublication":"2026-02-11 00:00:00","position":83,"meta_title":"Как управлять legacy-системами в крупной компании: риски, стратегии, ошибки","meta_description":"Как эффективно управлять legacy-системами в крупной компании, какие риски и ошибки нужно учитывать, чтобы не допустить критических сбоев.","meta_keywords":"legacy системы, риски legacy, управление legacy, поддержка legacy, IT управление, стратегии legacy, ошибки legacy","meta_og_title":"Как управлять legacy-системами в крупной компании: риски, стратегии, ошибки","meta_og_description":"В статье рассматриваются риски, стратегии и ошибки, связанные с legacy-системами, а также пути минимизации проблем для бизнеса.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/legacy-managing-risks-strategies-errors","seo_canonical":"https://nsign.ru/blog/legacy-managing-risks-strategies-errors","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как управлять legacy-системами в крупной компании: риски, стратегии, ошибки\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/legacy-managing-risks-strategies-errors\"\r\n }\r\n}","hidden":0,"createdAt":"2026-02-11 12:28:24","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/e2/74/c402700f97c10df5e36ca312ecaec40353350d1e.png","services":[]}]},{"id":123,"type":"internal","newsTypeId":1,"serviceId":null,"url":"cms-2026-headless-api-first-ai-agenty","name":"Как меняются CMS в 2026 году: headless, API-⁠first и AI-⁠агенты","annotation":"","blog":"$1e","backgroundType":null,"sizeType":1,"datePublication":"2026-09-29 00:00:00","position":1,"meta_title":"Как меняются CMS в 2026: headless, API-first и AI-агенты | Энсайн","meta_description":"Как развиваются CMS в 2026 году: headless, API-first, MCP и AI-агенты. Что меняется в архитектуре, правах доступа и управлении контентом.","meta_keywords":null,"meta_og_title":"Как меняются CMS в 2026 году: headless, API-first и AI-агенты","meta_og_description":"Headless, API-first, MCP и AI-агенты меняют архитектуру CMS. Разбираем, как это влияет на данные, права, версии и управление контентом.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/cms-2026-headless-api-first-ai-agenty","seo_canonical":"https://nsign.ru/blog/cms-2026-headless-api-first-ai-agenty","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как меняются CMS в 2026 году: headless, API-first и AI-агенты\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/cms-2026-headless-api-first-ai-agenty\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-29 15:56:56","updatedAt":"2026-09-30 06:07:13","relatedService":null,"image":"https://n-dl.nsign.ru/repository/67/d1/ce4fdbfa1a3bd6853206b2012f0755133ca45791.jpg","services":[],"randomBlogs":[{"id":49,"type":"internal","newsTypeId":1,"serviceId":null,"url":"what-cio-really-buys-when-ordering-it-support","name":"Что на самом деле покупает CIO, заказывая поддержку IT-⁠систем?","annotation":"","blog":"$1f","backgroundType":null,"sizeType":1,"datePublication":"2026-03-12 00:00:00","position":71,"meta_title":"Что на самом деле покупает CIO, заказывая поддержку IT-систем?","meta_description":"CIO покупают не просто техническое обслуживание, но и долгосрочную стабильность бизнеса, риски и оптимизацию. Узнайте, что именно они получают, заказывая поддержку IT-систем.","meta_keywords":"CIO, поддержка IT-систем, риски, оптимизация, безопасность, обновление системы","meta_og_title":"Что на самом деле покупает CIO, заказывая поддержку IT-систем?","meta_og_description":"CIO покупают не просто техническое обслуживание, но и долгосрочную стабильность бизнеса, риски и оптимизацию. Узнайте, что именно они получают, заказывая поддержку IT-систем.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/what-cio-really-buys-when-ordering-it-support","seo_canonical":"https://nsign.ru/blog/what-cio-really-buys-when-ordering-it-support","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Что на самом деле покупает CIO, заказывая поддержку IT-систем?\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/what-cio-really-buys-when-ordering-it-support\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-12 20:02:32","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/54/6f/5d9a6ab71b17f671b8e94a2b9041a65804e794f6.jpg","services":[]},{"id":108,"type":"internal","newsTypeId":1,"serviceId":null,"url":"integraciya-bitrix24-1c","name":"Как интегрировать «Битрикс24» и 1С, чтобы сотрудники не сверяли данные вручную","annotation":"","blog":"$20","backgroundType":null,"sizeType":1,"datePublication":"2026-08-06 00:00:00","position":14,"meta_title":"Интеграция Битрикс24 и 1С без дублей и ручной сверки","meta_description":"Как настроить интеграцию Битрикс24 и 1С, распределить ответственность за данные, исключить дубли и контролировать обмен после запуска.","meta_keywords":null,"meta_og_title":"Интеграция Битрикс24 и 1С без дублей и ручной сверки","meta_og_description":"Разбираем, как превратить штатное подключение Битрикс24 к 1С в надежный и контролируемый бизнес-процесс.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/integraciya-bitrix24-1c","seo_canonical":"https://nsign.ru/blog/integraciya-bitrix24-1c","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как интегрировать Битрикс24 и 1С, чтобы сотрудники не сверяли данные вручную\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/integraciya-bitrix24-1c\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-06 14:36:53","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/98/b6/0cc61e1dba0e90f13bdc48927e94430cadd5971e.jpg","services":[]},{"id":92,"type":"internal","newsTypeId":1,"serviceId":null,"url":"chto-prodlevaet-zhizn-saytu","name":"Что продлевает жизнь сайту","annotation":"","blog":"$21","backgroundType":null,"sizeType":1,"datePublication":"2026-06-16 00:00:00","position":29,"meta_title":"Что продлевает жизнь сайту и помогает не терять контроль","meta_description":"Что помогает продлить жизнь сайту: регулярная поддержка, обновления, контроль интеграций, безопасность, актуальный контент и снижение техдолга.","meta_keywords":"поддержка сайта, жизненный цикл сайта, что продлевает жизнь сайту, техническая поддержка сайта, обновление сайта, безопасность сайта, сопровождение сайта","meta_og_title":"Что продлевает жизнь сайту и помогает не терять контроль","meta_og_description":"Что помогает продлить жизнь сайту: регулярная поддержка, обновления, контроль интеграций, безопасность, актуальный контент и снижение техдолга.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/chto-prodlevaet-zhizn-saytu","seo_canonical":"https://nsign.ru/blog/chto-prodlevaet-zhizn-saytu","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Что продлевает жизнь сайту\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/chto-prodlevaet-zhizn-saytu\"\r\n }\r\n}","hidden":0,"createdAt":"2026-06-12 09:41:07","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/47/23/c14e07951b29b9b6d69dc6b04f0c756b28ca2501.jpg","services":[]}]},{"id":122,"type":"internal","newsTypeId":1,"serviceId":null,"url":"stoimost-razrabotki-sobstvennoy-cms","name":"Сколько стоит разработка собственной CMS для бизнеса","annotation":"","blog":"$22","backgroundType":null,"sizeType":1,"datePublication":"2026-09-24 00:00:00","position":2,"meta_title":"Сколько стоит разработка собственной CMS | Энсайн","meta_description":"Сколько стоит собственная CMS для бизнеса: ориентиры по бюджету, трудозатратам и срокам, состав работ и пример расчета корпоративной системы.","meta_keywords":null,"meta_og_title":"Сколько стоит разработка собственной CMS для бизнеса","meta_og_description":"Ориентиры по стоимости собственной CMS, состав бюджета, трудозатраты и пример расчета корпоративной системы.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/stoimost-razrabotki-sobstvennoy-cms","seo_canonical":"https://nsign.ru/blog/stoimost-razrabotki-sobstvennoy-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Сколько стоит разработка собственной CMS для бизнеса\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/stoimost-razrabotki-sobstvennoy-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-24 17:49:34","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/09/cc/31030731cdd1206d36671548420351f89ccb047e.jpg","services":[],"randomBlogs":[{"id":65,"type":"internal","newsTypeId":1,"serviceId":null,"url":"pochemu-bystro-zakryt-zadachu-plohoi-kpi-dlya-legacy","name":"Почему «быстро закрыть задачу» — плохой KPI для legacy","annotation":"","blog":"$23","backgroundType":null,"sizeType":1,"datePublication":"2026-04-08 00:00:00","position":56,"meta_title":"Почему «быстро закрыть задачу» — плохой KPI для legacy","meta_description":"Узнайте, почему использование скорости как основного показателя эффективности при работе с legacy-системами приводит к скрытым проблемам и повышенным затратам.","meta_keywords":"kpi для legacy, ошибки в kpi, legacy системы, управление legacy системами, работа с legacy, эффективность в IT","meta_og_title":"Почему «быстро закрыть задачу» — плохой KPI для legacy","meta_og_description":"Узнайте, почему использование скорости как основного показателя эффективности при работе с legacy-системами приводит к скрытым проблемам и повышенным затратам.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/pochemu-bystro-zakryt-zadachu-plohoi-kpi-dlya-legacy","seo_canonical":"https://nsign.ru/blog/pochemu-bystro-zakryt-zadachu-plohoi-kpi-dlya-legacy","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему «быстро закрыть задачу» — плохой KPI для legacy\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/pochemu-bystro-zakryt-zadachu-plohoi-kpi-dlya-legacy\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-05 18:38:03","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/23/2e/66678a90c95804652d2ebd9935fdf7b8adaef141.jpg","services":[]},{"id":93,"type":"internal","newsTypeId":1,"serviceId":null,"url":"freymvork-mozhet-uskorit-razrabotku-ili-pokhoronit-proekt","name":"Фреймворк может ускорить разработку или похоронить проект","annotation":"","blog":"$24","backgroundType":null,"sizeType":1,"datePublication":"2026-06-18 00:00:00","position":28,"meta_title":"Фреймворк может ускорить разработку или похоронить проект","meta_description":"Как выбор фреймворка влияет на скорость разработки, поддержку, интеграции, безопасность, найм команды и стоимость изменений в проекте.","meta_keywords":"фреймворк для веб разработки, выбор фреймворка, frontend framework, backend framework, поддержка веб проекта, архитектура веб проекта, разработка веб приложений","meta_og_title":"Фреймворк может ускорить разработку или похоронить проект","meta_og_description":"Как выбор фреймворка влияет на скорость разработки, поддержку, интеграции, безопасность, найм команды и стоимость изменений в проекте.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/freymvork-mozhet-uskorit-razrabotku-ili-pokhoronit-proekt","seo_canonical":"https://nsign.ru/blog/freymvork-mozhet-uskorit-razrabotku-ili-pokhoronit-proekt","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Фреймворк может ускорить разработку или похоронить проект\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/freymvork-mozhet-uskorit-razrabotku-ili-pokhoronit-proekt\"\r\n }\r\n}","hidden":0,"createdAt":"2026-06-12 09:50:49","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/a9/b9/5873d6818d0097844a982887c054f4cb710b96fb.jpg","services":[]},{"id":31,"type":"external","newsTypeId":2,"serviceId":null,"url":"https://itrussia.media/ru/article/v-rossii-sobrali-pazl-obrazovatelnykh-servisov","name":"В России собрали ПАЗЛ образовательных сервисов","annotation":"","blog":"","backgroundType":null,"sizeType":1,"datePublication":"2025-12-26 00:00:00","position":90,"meta_title":null,"meta_description":null,"meta_keywords":null,"meta_og_title":null,"meta_og_description":null,"meta_og_type":"article","meta_og_url":null,"seo_canonical":null,"seo_schemaorg":null,"hidden":0,"createdAt":"2025-12-26 07:27:11","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4c/de/339ab5d36cd52f297b754b2dab56e16afeb54906.png","services":[]}]},{"id":118,"type":"internal","newsTypeId":1,"serviceId":null,"url":"it-tendery-podtverzhdenie-opyta-webgl","name":"Работающий WebGL и 27 контрактов на 168 млн рублей: как мы дважды получили 0 баллов в ИТ-тендерах","annotation":"","blog":"$25","backgroundType":null,"sizeType":1,"datePublication":"2026-09-22 00:00:00","position":5,"meta_title":"IT-тендеры: как 27 контрактов и WebGL получили 0 баллов","meta_description":"Два реальных ИТ-тендера Энсайн: почему 27 контрактов на 168 млн рублей и работающий WebGL-интерфейс не принесли баллов при оценке заявок.","meta_keywords":null,"meta_og_title":"Работающий WebGL и 27 контрактов: как мы получили 0 баллов в ИТ-тендерах","meta_og_description":"Разбираем два тендера Энсайн и показываем, почему фактического опыта и работающего технического решения может быть недостаточно для высокой оценки заявки.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/it-tendery-podtverzhdenie-opyta-webgl","seo_canonical":"https://nsign.ru/blog/it-tendery-podtverzhdenie-opyta-webgl","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Работающий WebGL и 27 контрактов на 168 млн рублей: как мы дважды получили 0 баллов в ИТ-тендерах\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/it-tendery-podtverzhdenie-opyta-webgl\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-22 17:50:33","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/78/71/4a8cc7f26d64859d8de08ffcd028342f66fa497e.jpg","services":[],"randomBlogs":[{"id":23,"type":"internal","newsTypeId":1,"serviceId":null,"url":"audit-dev-modern","name":"Аудит, разработка, модернизация и поддержка ПО. Прозрачный бюджет и гарантия","annotation":"

Разработка и модернизация IT-систем любой сложности. Проводим аудит, обеспечиваем миграцию данных и техподдержку 24/7. Надежная защита ИТ-инфраструктуры.

","blog":"$26","backgroundType":null,"sizeType":1,"datePublication":"2025-11-20 00:00:00","position":98,"meta_title":"Аудит, разработка, модернизация и поддержка ПО. Прозрачный бюджет и гарантия","meta_description":"Разработка и модернизация IT-систем любой сложности. Проводим аудит, обеспечиваем миграцию данных и техподдержку 24/7. Надежная защита ИТ-инфраструктуры.","meta_keywords":"разработка IT-продуктов, создание веб-сервисов под ключ, IT-компания полного цикла, заказная разработка ПО, IT-аудит и консалтинг, интеграция с CRM и ERP системами, безопасная разработка ПО ФЗ-152, разработка высоконагруженных систем","meta_og_title":"Аудит, разработка, модернизация и поддержка ПО. Прозрачный бюджет и гарантия","meta_og_description":"Разработка и модернизация IT-систем любой сложности. Проводим аудит, обеспечиваем миграцию данных и техподдержку 24/7. Надежная защита ИТ-инфраструктуры.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/audit-dev-modern","seo_canonical":"https://nsign.ru/blog/audit-dev-modern","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Аудит, разработка, модернизация и поддержка ПО. Прозрачный бюджет и гарантия\",\r\n \"description\": \"Разработка и модернизация IT-систем любой сложности. Проводим аудит, обеспечиваем миграцию данных и техподдержку 24/7. Надежная защита ИТ-инфраструктуры.\",\r\n \"inLanguage\": \"ru-RU\",\r\n \"url\": \"https://nsign.ru/blog/audit-dev-modern\",\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/audit-dev-modern\"\r\n }\r\n}\r\n","hidden":0,"createdAt":"2025-11-21 08:28:52","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/31/a0/1d4cd5b6cdf2c41f073c60131f7663196475d0b8.png","services":[]},{"id":117,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kogda-nuzhna-sobstvennaya-cms","name":"Когда бизнесу нужна собственная CMS: 7 признаков","annotation":"","blog":"$27","backgroundType":null,"sizeType":1,"datePublication":"2026-09-17 00:00:00","position":6,"meta_title":"Когда бизнесу нужна собственная CMS: 7 признаков | Энсайн","meta_description":"7 признаков, что готовая CMS стала ограничивать развитие проекта: растут затраты на доработки, дублируются данные и усложняется архитектура.","meta_keywords":null,"meta_og_title":"Когда бизнесу нужна собственная CMS: 7 признаков","meta_og_description":"Как понять, что ресурсы уходят уже не на развитие продукта, а на преодоление ограничений CMS. 7 признаков для диагностики проекта.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_canonical":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Когда бизнесу нужна собственная CMS: 7 признаков\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-17 20:45:51","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/fb/9c/74c150675357fd2bef1cd1e92303281842622335.jpg","services":[]},{"id":50,"type":"internal","newsTypeId":1,"serviceId":null,"url":"cio-podryadchik-podderzhka-legacy-sistem","name":"Как CIO выбрать подрядчика для поддержки legacy-систем","annotation":"","blog":"$28","backgroundType":null,"sizeType":1,"datePublication":"2026-03-17 00:00:00","position":70,"meta_title":"Как CIO выбрать подрядчика для поддержки legacy-систем","meta_description":"Критерии выбора подрядчика для поддержки legacy-систем: как снизить риски простоев, уязвимостей и зависимости от внешней команды.","meta_keywords":"поддержка legacy, подрядчик для legacy, сопровождение устаревших систем, CIO, аудит legacy, управление рисками IT","meta_og_title":"Как CIO выбрать подрядчика для поддержки legacy-систем","meta_og_description":"Критерии выбора подрядчика для поддержки legacy-систем: как снизить риски простоев, уязвимостей и зависимости от внешней команды.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/cio-podryadchik-podderzhka-legacy-sistem","seo_canonical":"https://nsign.ru/blog/cio-podryadchik-podderzhka-legacy-sistem","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как CIO выбрать подрядчика для поддержки legacy-систем\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/cio-podryadchik-podderzhka-legacy-sistem\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-17 19:18:10","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/31/8b/af6585363615adb4c50fe992cd16da3e8017eab2.jpg","services":[]}]},{"id":117,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kogda-nuzhna-sobstvennaya-cms","name":"Когда бизнесу нужна собственная CMS: 7 признаков","annotation":"","blog":"$29","backgroundType":null,"sizeType":1,"datePublication":"2026-09-17 00:00:00","position":6,"meta_title":"Когда бизнесу нужна собственная CMS: 7 признаков | Энсайн","meta_description":"7 признаков, что готовая CMS стала ограничивать развитие проекта: растут затраты на доработки, дублируются данные и усложняется архитектура.","meta_keywords":null,"meta_og_title":"Когда бизнесу нужна собственная CMS: 7 признаков","meta_og_description":"Как понять, что ресурсы уходят уже не на развитие продукта, а на преодоление ограничений CMS. 7 признаков для диагностики проекта.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_canonical":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Когда бизнесу нужна собственная CMS: 7 признаков\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-17 20:45:51","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/fb/9c/74c150675357fd2bef1cd1e92303281842622335.jpg","services":[],"randomBlogs":[{"id":28,"type":"external","newsTypeId":2,"serviceId":null,"url":"https://itrussia.media/ru/article/rossiyskiy-bank-usilil-zaschitu-dannykh-s-pomoschyu-novogo-s","name":"Российский банк усилил защиту данных с помощью нового сервиса рассылок","annotation":"","blog":"","backgroundType":null,"sizeType":1,"datePublication":"2025-12-26 00:00:00","position":93,"meta_title":null,"meta_description":null,"meta_keywords":null,"meta_og_title":null,"meta_og_description":null,"meta_og_type":"article","meta_og_url":null,"seo_canonical":null,"seo_schemaorg":null,"hidden":0,"createdAt":"2025-12-26 07:20:20","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4c/de/b087bc9e4cac31ca3180583a0a05260c165703c9.png","services":[]},{"id":110,"type":"internal","newsTypeId":1,"serviceId":null,"url":"audit-pdn-testovaya-baza","name":"Рабочая база в тестовой среде: что может обнаружить аудит ПДн","annotation":"","blog":"$2a","backgroundType":null,"sizeType":1,"datePublication":"2026-08-13 00:00:00","position":12,"meta_title":"Аудит ПДн: рабочая база в тестовой среде | Энсайн","meta_description":"Аудит ПДн выявил рабочую базу в тестовой среде. Разбираем риски, порядок проверки, обезличивание данных и признаки, когда аудит нельзя откладывать.","meta_keywords":null,"meta_og_title":"Рабочая база в тестовой среде: что обнаруживает аудит ПДн","meta_og_description":"Разбираем случай, когда во время аудита ПДн обнаружилась копия рабочей базы с реальными данными пользователей в тестовой среде.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/audit-pdn-testovaya-baza","seo_canonical":"https://nsign.ru/blog/audit-pdn-testovaya-baza","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Рабочая база в тестовой среде: что обнаруживает аудит ПДн\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/audit-pdn-testovaya-baza\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-13 15:53:00","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/03/23/01b9407c67d83be740868f995d270af79c419af1.jpg","services":[]},{"id":103,"type":"internal","newsTypeId":1,"serviceId":null,"url":"novosti-mincifry-iyul-2026","name":"Новости Минцифры за июль: гранты, ИИ и новые планы по цифровизации государства","annotation":"","blog":"$2b","backgroundType":null,"sizeType":1,"datePublication":"2026-07-23 00:00:00","position":18,"meta_title":"Новости Минцифры за июль 2026: гранты, ИИ и цифровизация","meta_description":"Главные новости Минцифры за июль 2026 года: гранты для ИТ-компаний, регулирование ИИ, цифровизация государства и данные по рынку.","meta_keywords":null,"meta_og_title":"Новости Минцифры за июль 2026: гранты, ИИ и цифровизация","meta_og_description":"Гранты для российских разработчиков, регулирование ИИ, цифровизация госуправления и свежие данные по ИТ-рынку.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/novosti-mincifry-iyul-2026","seo_canonical":"https://nsign.ru/blog/novosti-mincifry-iyul-2026","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Новости Минцифры за июль: гранты, ИИ и новые планы по цифровизации государства\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/novosti-mincifry-iyul-2026\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-23 13:13:35","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/71/c2/7df69c5443ceb6ff63aa3253e70465833795ce88.jpg","services":[]}]},{"id":116,"type":"internal","newsTypeId":1,"serviceId":null,"url":"rust-v-b2b-it-proektah","name":"Почему мы заранее изучаем Rust, хотя не предлагаем его в каждый проект","annotation":"","blog":"$2c","backgroundType":null,"sizeType":1,"datePublication":"2026-09-15 00:00:00","position":7,"meta_title":"Почему мы изучаем Rust, но не используем его в каждом проекте","meta_description":"Когда Rust оправдан в коммерческой разработке, какие проектные риски он снижает и почему интегратору важно изучать новый стек заранее.","meta_keywords":null,"meta_og_title":"Почему мы изучаем Rust, но не используем его в каждом проекте","meta_og_description":"Практический опыт Энсайн: где Rust снижает риски разработки и поставки, а где привычный технологический стек остается рациональнее.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/rust-v-b2b-it-proektah","seo_canonical":"https://nsign.ru/blog/rust-v-b2b-it-proektah","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Готовая CMS или собственная CMS: что выбрать бизнесу\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/gotovaya-ili-sobstvennaya-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-15 06:48:28","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/fd/22/73616ebeb354b7f35416e9ca7d88069699d4d9ff.jpg","services":[],"randomBlogs":[{"id":94,"type":"internal","newsTypeId":1,"serviceId":null,"url":"chto-takoe-customer-journey-map","name":"Что такое Customer Journey Map","annotation":"","blog":"$2d","backgroundType":null,"sizeType":1,"datePublication":"2026-06-23 00:00:00","position":27,"meta_title":"Что такое Customer Journey Map и как она помогает бизнесу","meta_description":"Что показывает Customer Journey Map, где она помогает бизнесу, почему карты часто не работают и как строить CJM на данных, а не на догадках.","meta_keywords":"Customer Journey Map, CJM, карта пути клиента, клиентский путь, путь клиента, customer journey, CX, UX, аналитика клиентского опыта","meta_og_title":"Что такое Customer Journey Map и как она помогает бизнесу","meta_og_description":"Что показывает Customer Journey Map, где она помогает бизнесу, почему карты часто не работают и как строить CJM на данных, а не на догадках.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/chto-takoe-customer-journey-map","seo_canonical":"https://nsign.ru/blog/chto-takoe-customer-journey-map","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Что такое Customer Journey Map\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/chto-takoe-customer-journey-map\"\r\n }\r\n}","hidden":0,"createdAt":"2026-06-12 09:59:10","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/8d/49/371756a7f034c8df9630a4a07eb2a0251197c1af.jpg","services":[]},{"id":38,"type":"internal","newsTypeId":1,"serviceId":null,"url":"legacy-system-management-risks-strategies-errors","name":"Почему простые правки в legacy почти никогда не бывают простыми","annotation":"","blog":"$2e","backgroundType":null,"sizeType":1,"datePublication":"2026-02-13 00:00:00","position":82,"meta_title":"Почему простые правки в legacy почти никогда не бывают простыми","meta_description":"Почему простые правки в legacy-системах часто приводят к неожиданным сложностям. Управление рисками и реализация эффективных стратегий для старых систем.","meta_keywords":"legacy системы, управление legacy, риски legacy, ошибки legacy, поддержка legacy систем, обновление legacy, стратегии legacy","meta_og_title":"Почему простые правки в legacy почти никогда не бывают простыми","meta_og_description":"Почему простые правки в legacy-системах приводят к накоплению рисков и как управлять сложными системами без сбоев.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors","seo_canonical":"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему простые правки в legacy почти никогда не бывают простыми\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors\"\r\n }\r\n}","hidden":0,"createdAt":"2026-02-13 08:07:22","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/cc/52/584689bcd9334c752e789581b2601d7de44b7d25.png","services":[]},{"id":49,"type":"internal","newsTypeId":1,"serviceId":null,"url":"what-cio-really-buys-when-ordering-it-support","name":"Что на самом деле покупает CIO, заказывая поддержку IT-⁠систем?","annotation":"","blog":"$2f","backgroundType":null,"sizeType":1,"datePublication":"2026-03-12 00:00:00","position":71,"meta_title":"Что на самом деле покупает CIO, заказывая поддержку IT-систем?","meta_description":"CIO покупают не просто техническое обслуживание, но и долгосрочную стабильность бизнеса, риски и оптимизацию. Узнайте, что именно они получают, заказывая поддержку IT-систем.","meta_keywords":"CIO, поддержка IT-систем, риски, оптимизация, безопасность, обновление системы","meta_og_title":"Что на самом деле покупает CIO, заказывая поддержку IT-систем?","meta_og_description":"CIO покупают не просто техническое обслуживание, но и долгосрочную стабильность бизнеса, риски и оптимизацию. Узнайте, что именно они получают, заказывая поддержку IT-систем.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/what-cio-really-buys-when-ordering-it-support","seo_canonical":"https://nsign.ru/blog/what-cio-really-buys-when-ordering-it-support","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Что на самом деле покупает CIO, заказывая поддержку IT-систем?\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/what-cio-really-buys-when-ordering-it-support\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-12 20:02:32","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/54/6f/5d9a6ab71b17f671b8e94a2b9041a65804e794f6.jpg","services":[]}]},{"id":115,"type":"internal","newsTypeId":1,"serviceId":null,"url":"gotovaya-ili-sobstvennaya-cms","name":"Готовая CMS или собственная CMS: что выбрать бизнесу","annotation":"","blog":"$30","backgroundType":null,"sizeType":1,"datePublication":"2026-09-08 00:00:00","position":8,"meta_title":"Готовая или собственная CMS: что выбрать бизнесу | Энсайн","meta_description":"Сравниваем готовую и собственную CMS по стоимости запуска, поддержке, доработкам и владению системой на горизонте 3-5 лет.","meta_keywords":null,"meta_og_title":"Готовая или собственная CMS: что выбрать бизнесу","meta_og_description":"Сравнение готовой и собственной CMS: стартовые затраты, доработки, поддержка и стоимость владения системой на несколько лет.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/gotovaya-ili-sobstvennaya-cms","seo_canonical":"https://nsign.ru/blog/gotovaya-ili-sobstvennaya-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Готовая CMS или собственная CMS: что выбрать бизнесу\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/gotovaya-ili-sobstvennaya-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-08 15:48:00","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/c6/63/2e23725916a699cf30d8af24a67ba4b1acaf8fdb.jpg","services":[],"randomBlogs":[{"id":87,"type":"internal","newsTypeId":1,"serviceId":null,"url":"istochniki-ugroz-informatsionnoy-bezopasnosti","name":"Источники угроз информационной безопасности","annotation":"","blog":"$31","backgroundType":null,"sizeType":1,"datePublication":"2026-06-09 00:00:00","position":32,"meta_title":"Источники угроз информационной безопасности","meta_description":"Где в компании возникают реальные угрозы ИБ: внешние атаки, внутренние ошибки, слабые доступы, уязвимости инфраструктуры и риск потери данных.","meta_keywords":"источники угроз информационной безопасности, угрозы ИБ, информационная безопасность бизнеса, уязвимости инфраструктуры, контроль доступов, защита данных, киберугрозы","meta_og_title":"Источники угроз информационной безопасности","meta_og_description":"Где в компании возникают реальные угрозы ИБ: внешние атаки, внутренние ошибки, слабые доступы, уязвимости инфраструктуры и риск потери данных.\r\n","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti","seo_canonical":"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Источники угроз информационной безопасности\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti\"\r\n }\r\n}","hidden":0,"createdAt":"2026-05-10 17:44:52","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4e/f3/54d5ed96ed3184064e2ff5647809c5dc55bf0d30.jpg","services":[]},{"id":123,"type":"internal","newsTypeId":1,"serviceId":null,"url":"cms-2026-headless-api-first-ai-agenty","name":"Как меняются CMS в 2026 году: headless, API-⁠first и AI-⁠агенты","annotation":"","blog":"$32","backgroundType":null,"sizeType":1,"datePublication":"2026-09-29 00:00:00","position":1,"meta_title":"Как меняются CMS в 2026: headless, API-first и AI-агенты | Энсайн","meta_description":"Как развиваются CMS в 2026 году: headless, API-first, MCP и AI-агенты. Что меняется в архитектуре, правах доступа и управлении контентом.","meta_keywords":null,"meta_og_title":"Как меняются CMS в 2026 году: headless, API-first и AI-агенты","meta_og_description":"Headless, API-first, MCP и AI-агенты меняют архитектуру CMS. Разбираем, как это влияет на данные, права, версии и управление контентом.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/cms-2026-headless-api-first-ai-agenty","seo_canonical":"https://nsign.ru/blog/cms-2026-headless-api-first-ai-agenty","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как меняются CMS в 2026 году: headless, API-first и AI-агенты\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/cms-2026-headless-api-first-ai-agenty\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-29 15:56:56","updatedAt":"2026-09-30 06:07:13","relatedService":null,"image":"https://n-dl.nsign.ru/repository/67/d1/ce4fdbfa1a3bd6853206b2012f0755133ca45791.jpg","services":[]},{"id":50,"type":"internal","newsTypeId":1,"serviceId":null,"url":"cio-podryadchik-podderzhka-legacy-sistem","name":"Как CIO выбрать подрядчика для поддержки legacy-систем","annotation":"","blog":"$33","backgroundType":null,"sizeType":1,"datePublication":"2026-03-17 00:00:00","position":70,"meta_title":"Как CIO выбрать подрядчика для поддержки legacy-систем","meta_description":"Критерии выбора подрядчика для поддержки legacy-систем: как снизить риски простоев, уязвимостей и зависимости от внешней команды.","meta_keywords":"поддержка legacy, подрядчик для legacy, сопровождение устаревших систем, CIO, аудит legacy, управление рисками IT","meta_og_title":"Как CIO выбрать подрядчика для поддержки legacy-систем","meta_og_description":"Критерии выбора подрядчика для поддержки legacy-систем: как снизить риски простоев, уязвимостей и зависимости от внешней команды.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/cio-podryadchik-podderzhka-legacy-sistem","seo_canonical":"https://nsign.ru/blog/cio-podryadchik-podderzhka-legacy-sistem","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как CIO выбрать подрядчика для поддержки legacy-систем\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/cio-podryadchik-podderzhka-legacy-sistem\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-17 19:18:10","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/31/8b/af6585363615adb4c50fe992cd16da3e8017eab2.jpg","services":[]}]},{"id":114,"type":"internal","newsTypeId":1,"serviceId":null,"url":"vybor-cms-korporativnogo-saita","name":"Как выбрать CMS для корпоративного сайта","annotation":"","blog":"$34","backgroundType":null,"sizeType":1,"datePublication":"2026-09-01 00:00:00","position":9,"meta_title":"Как выбрать CMS для корпоративного сайта | Энсайн","meta_description":"Как выбрать CMS для корпоративного сайта: данные, интеграции, права, нагрузка, безопасность, инфраструктура и стоимость владения системой.","meta_keywords":null,"meta_og_title":"Как выбрать CMS для корпоративного сайта","meta_og_description":"6 критериев выбора CMS: модель данных, редакторы, интеграции, цифровые каналы, инфраструктура и стоимость владения.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/vybor-cms-korporativnogo-saita","seo_canonical":"https://nsign.ru/blog/vybor-cms-korporativnogo-saita","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как выбрать CMS для корпоративного сайта\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/vybor-cms-korporativnogo-saita\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-02 08:27:14","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/05/67/dd7ced5fb8c6d4a893bb025ea7e7d5691b6f2149.jpg","services":[],"randomBlogs":[{"id":35,"type":"external","newsTypeId":2,"serviceId":null,"url":"https://www.tadviser.ru/index.php/%d0%9f%d1%80%d0%be%d0%b5%d0%ba%d1%82:%d0%a2%d0%b5%d1%85%d0%bd%d0%be%d0%bb%d0%be%d0%b3%d0%b8%d0%b8_%d0%b2%d0%be%d0%b7%d0%bc%d0%be%d0%b6%d0%bd%d0%be%d1%81%d1%82%d0%b5%d0%b9_(%d0%9f%d1%80%d0%be%d0%b5%d0%ba%d1%82%d1%8b_%d0%98%d0%a2-%d0%b0%d1%83%d1%82%d1%81%d0%be%d1%80%d1%81%d0%b8%d0%bd%d0%b3%d0%b0)","name":"«Технологии возможностей» с помощью «Энсайн» запустили цифровую платформу для улучшения качества жизни людей с ограниченными возможностями","annotation":"","blog":"","backgroundType":null,"sizeType":1,"datePublication":"2025-12-26 00:00:00","position":86,"meta_title":null,"meta_description":null,"meta_keywords":null,"meta_og_title":null,"meta_og_description":null,"meta_og_type":"article","meta_og_url":null,"seo_canonical":null,"seo_schemaorg":null,"hidden":0,"createdAt":"2025-12-26 12:21:29","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/b2/85/56d9d06e5caa8fa6b9b05b441985327c73956c09.png","services":[]},{"id":117,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kogda-nuzhna-sobstvennaya-cms","name":"Когда бизнесу нужна собственная CMS: 7 признаков","annotation":"","blog":"$35","backgroundType":null,"sizeType":1,"datePublication":"2026-09-17 00:00:00","position":6,"meta_title":"Когда бизнесу нужна собственная CMS: 7 признаков | Энсайн","meta_description":"7 признаков, что готовая CMS стала ограничивать развитие проекта: растут затраты на доработки, дублируются данные и усложняется архитектура.","meta_keywords":null,"meta_og_title":"Когда бизнесу нужна собственная CMS: 7 признаков","meta_og_description":"Как понять, что ресурсы уходят уже не на развитие продукта, а на преодоление ограничений CMS. 7 признаков для диагностики проекта.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_canonical":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Когда бизнесу нужна собственная CMS: 7 признаков\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-17 20:45:51","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/fb/9c/74c150675357fd2bef1cd1e92303281842622335.jpg","services":[]},{"id":122,"type":"internal","newsTypeId":1,"serviceId":null,"url":"stoimost-razrabotki-sobstvennoy-cms","name":"Сколько стоит разработка собственной CMS для бизнеса","annotation":"","blog":"$36","backgroundType":null,"sizeType":1,"datePublication":"2026-09-24 00:00:00","position":2,"meta_title":"Сколько стоит разработка собственной CMS | Энсайн","meta_description":"Сколько стоит собственная CMS для бизнеса: ориентиры по бюджету, трудозатратам и срокам, состав работ и пример расчета корпоративной системы.","meta_keywords":null,"meta_og_title":"Сколько стоит разработка собственной CMS для бизнеса","meta_og_description":"Ориентиры по стоимости собственной CMS, состав бюджета, трудозатраты и пример расчета корпоративной системы.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/stoimost-razrabotki-sobstvennoy-cms","seo_canonical":"https://nsign.ru/blog/stoimost-razrabotki-sobstvennoy-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Сколько стоит разработка собственной CMS для бизнеса\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/stoimost-razrabotki-sobstvennoy-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-24 17:49:34","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/09/cc/31030731cdd1206d36671548420351f89ccb047e.jpg","services":[]}]},{"id":113,"type":"internal","newsTypeId":1,"serviceId":null,"url":"vidy-cms-dlya-korporativnogo-saita","name":"Какие бывают CMS для корпоративного сайта","annotation":"","blog":"$37","backgroundType":null,"sizeType":1,"datePublication":"2026-08-25 00:00:00","position":10,"meta_title":"Какие бывают CMS для корпоративного сайта | Энсайн","meta_description":"Разбираем виды CMS для корпоративных сайтов: готовые и собственные, классические и headless. Отличия, ограничения и особенности архитектуры.","meta_keywords":null,"meta_og_title":"Какие бывают CMS для корпоративного сайта","meta_og_description":"Готовая или собственная, классическая или headless: разбираем основные виды CMS и принципиальные различия между ними.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/vidy-cms-dlya-korporativnogo-saita","seo_canonical":"https://nsign.ru/blog/vidy-cms-dlya-korporativnogo-saita","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Какие бывают CMS для корпоративного сайта\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/vidy-cms-dlya-korporativnogo-saita\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-25 18:03:15","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/bd/fa/c215eaf7b3e353d640ca67e4a338eb99af2d7234.jpg","services":[],"randomBlogs":[{"id":64,"type":"internal","newsTypeId":1,"serviceId":null,"url":"5-shagov-k-uspehnoj-integratsii-novyh-tehnologij-v-slojnuju-it-infrastrukturu","name":"5 шагов к успешной интеграции новых технологий в сложную ИТ-⁠инфраструктуру","annotation":"","blog":"$38","backgroundType":null,"sizeType":1,"datePublication":"2026-04-07 00:00:00","position":57,"meta_title":"5 шагов к успешной интеграции новых технологий в сложную ИТ-инфраструктуру","meta_description":"Узнайте, как правильно интегрировать новые технологии в сложную ИТ-инфраструктуру, минимизируя риски и увеличивая эффективность.","meta_keywords":"интеграция новых технологий, ИТ-инфраструктура, модернизация, бизнес-процессы, обновление ИТ-систем","meta_og_title":"5 шагов к успешной интеграции новых технологий в сложную ИТ-инфраструктуру","meta_og_description":"Узнайте, как правильно интегрировать новые технологии в сложную ИТ-инфраструктуру, минимизируя риски и увеличивая эффективность.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/5-shagov-k-uspehnoj-integratsii-novyh-tehnologij-v-slojnuju-it-infrastrukturu","seo_canonical":"https://nsign.ru/blog/5-shagov-k-uspehnoj-integratsii-novyh-tehnologij-v-slojnuju-it-infrastrukturu","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"5 шагов к успешной интеграции новых технологий в сложную ИТ-инфраструктуру\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/5-shagov-k-uspehnoj-integratsii-novyh-tehnologij-v-slojnuju-it-infrastrukturu\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-05 18:30:11","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/ec/92/4c1601420b7dbe6a4829fc9a1f5d59f888e01043.jpg","services":[]},{"id":39,"type":"internal","newsTypeId":1,"serviceId":null,"url":"legacy-system-risks-consequences","name":"Почему legacy опасно не трогать: отложенные риски и реальные последствия","annotation":"","blog":"$39","backgroundType":null,"sizeType":1,"datePublication":"2026-02-16 00:00:00","position":81,"meta_title":"Почему legacy опасно не трогать: отложенные риски и реальные последствия","meta_description":"Legacy-системы накапливают риски с каждым годом. Узнайте, как их минимизировать и какие стратегии помогут сохранить стабильность и безопасность.","meta_keywords":"legacy системы, риски legacy, управление legacy, поддержка legacy, модернизация legacy, проблемы legacy","meta_og_title":"Почему legacy опасно не трогать: отложенные риски и реальные последствия","meta_og_description":"Как игнорирование legacy-систем и откладывание изменений ведет к накоплению рисков и серьезным последствиям для бизнеса.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/legacy-system-risks-consequences","seo_canonical":"https://nsign.ru/blog/legacy-system-risks-consequences","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему legacy опасно не трогать: отложенные риски и реальные последствия\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/legacy-system-risks-consequences\"\r\n }\r\n}","hidden":0,"createdAt":"2026-02-13 08:08:31","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/9b/4c/a5ce92007ad674805657b5a27b9bf42a0dc1b1cf.png","services":[]},{"id":56,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-nasha-kompaniya-reshayet-osnovnye-riski-pri-vybori-it-podryadchika","name":"Как Энсайн решает основные риски при выборе IT-⁠подрядчика: Пять решений для вашего успеха","annotation":"","blog":"$3a","backgroundType":null,"sizeType":1,"datePublication":"2026-03-27 00:00:00","position":65,"meta_title":"Как Энсайн решает основные риски при выборе IT‑подрядчика","meta_description":"Узнайте, как наша компания минимизирует риски при выборе IT‑подрядчика и обеспечит вам успешный результат.","meta_keywords":"риски при выборе подрядчика, IT подрядчик, решение рисков, IT решение, гарантии сроков и качества","meta_og_title":"Как Энсайн решает основные риски при выборе IT‑подрядчика","meta_og_description":"Узнайте, как наша компания минимизирует риски при выборе IT‑подрядчика и обеспечит вам успешный результат.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-nasha-kompaniya-reshayet-osnovnye-riski-pri-vybori-it-podryadchika","seo_canonical":"https://nsign.ru/blog/kak-nasha-kompaniya-reshayet-osnovnye-riski-pri-vybori-it-podryadchika","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как Энсайн решает основные риски при выборе IT‑подрядчика\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-nasha-kompaniya-reshayet-osnovnye-riski-pri-vybori-it-podryadchika\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-26 19:46:33","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/5a/23/8d9505cd9aa2a2a833ec35b09ab8beaa3e4f86a3.jpg","services":[]}]},{"id":111,"type":"internal","newsTypeId":1,"serviceId":null,"url":"chto-takoe-cms","name":"Что такое CMS и зачем она нужна сайту","annotation":"","blog":"$3b","backgroundType":null,"sizeType":1,"datePublication":"2026-08-18 00:00:00","position":11,"meta_title":"Что такое CMS и зачем она нужна сайту | Энсайн","meta_description":"Что такое CMS, как работает система управления сайтом, какие задачи решает и зачем нужна бизнесу. Возможности CMS на корпоративных проектах.","meta_keywords":null,"meta_og_title":"Что такое CMS и зачем она нужна сайту","meta_og_description":"Разбираем, как работает CMS, какие задачи она решает и какую роль система управления контентом играет на корпоративном сайте.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/chto-takoe-cms","seo_canonical":"https://nsign.ru/blog/chto-takoe-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Что такое CMS и зачем она нужна сайту\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/chto-takoe-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-18 10:58:34","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/45/b5/861e1aa985b87942bfd91b546d5adeedcb406e23.jpg","services":[],"randomBlogs":[{"id":79,"type":"internal","newsTypeId":1,"serviceId":null,"url":"devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem","name":"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-⁠систем","annotation":"","blog":"$3c","backgroundType":null,"sizeType":1,"datePublication":"2026-05-14 00:00:00","position":40,"meta_title":"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-систем","meta_description":"Узнайте, как DevOps помогает ускорить доставку обновлений и повысить безопасность ИТ-систем, улучшая процессы разработки и эксплуатации.","meta_keywords":"DevOps, безопасность, доставка обновлений, ускорение разработки, IТ-системы","meta_og_title":"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-систем","meta_og_description":"Узнайте, как DevOps помогает ускорить доставку обновлений и повысить безопасность ИТ-систем, улучшая процессы разработки и эксплуатации.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem","seo_canonical":"https://nsign.ru/blog/devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-систем\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-17 16:22:27","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/de/c4/0c949724b31af9f728748debc4a59fa9f481028d.jpg","services":[]},{"id":96,"type":"internal","newsTypeId":1,"serviceId":null,"url":"yuzabiliti-audit-sayta","name":"Юзабилити-аудит сайта: чек-лист для поиска потерь и точек роста","annotation":"","blog":"$3d","backgroundType":null,"sizeType":1,"datePublication":"2026-06-30 00:00:00","position":25,"meta_title":"Юзабилити-аудит сайта: чек-лист для поиска потерь","meta_description":"Чек-лист юзабилити-аудита сайта: проверка сценариев, форм, мобильной версии, интеграций и подготовка задач для разработки и поддержки.","meta_keywords":null,"meta_og_title":"Юзабилити-аудит сайта: чек-лист для поиска потерь","meta_og_description":"Как проверить пользовательские сценарии, формы, мобильную версию, интеграции и подготовить результаты аудита к внедрению.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/yuzabiliti-audit-sayta","seo_canonical":"https://nsign.ru/blog/yuzabiliti-audit-sayta","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Юзабилити-аудит сайта: чек-лист для поиска потерь и точек роста\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/yuzabiliti-audit-sayta\"\r\n }\r\n}","hidden":0,"createdAt":"2026-06-28 20:53:32","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/1f/fa/9830a560531f92726b9e5c5d2fb61fb4ba97e3a9.jpg","services":[]},{"id":124,"type":"internal","newsTypeId":1,"serviceId":null,"url":"hconfig-reestr-rossiyskogo-po","name":"Как мы включили HConfig в реестр российского ПО: опыт Энсайн","annotation":"","blog":"$3e","backgroundType":null,"sizeType":1,"datePublication":"2026-10-01 00:00:00","position":null,"meta_title":"Как включить ПО в реестр российского ПО: опыт HConfig | Энсайн","meta_description":"Опыт Энсайн по включению HConfig в реестр российского ПО: причины отказов, требования, техническая проверка и выводы для разработчиков.","meta_keywords":null,"meta_og_title":"Как мы включили HConfig в реестр российского ПО","meta_og_description":"Практический опыт Энсайн: две неудачные заявки, доработка документов, техническая проверка HConfig и итоговое включение продукта в реестр.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/hconfig-reestr-rossiyskogo-po","seo_canonical":"https://nsign.ru/blog/hconfig-reestr-rossiyskogo-po","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как мы включили HConfig в реестр российского ПО: опыт Энсайн\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/hconfig-reestr-rossiyskogo-po\"\r\n }\r\n}","hidden":0,"createdAt":"2026-10-01 18:59:47","updatedAt":"2026-10-01 19:20:17","relatedService":null,"image":"https://n-dl.nsign.ru/repository/42/1d/8e10548f1153f6b55f641201d834708bec1c61b1.jpg","services":[]}]},{"id":110,"type":"internal","newsTypeId":1,"serviceId":null,"url":"audit-pdn-testovaya-baza","name":"Рабочая база в тестовой среде: что может обнаружить аудит ПДн","annotation":"","blog":"$3f","backgroundType":null,"sizeType":1,"datePublication":"2026-08-13 00:00:00","position":12,"meta_title":"Аудит ПДн: рабочая база в тестовой среде | Энсайн","meta_description":"Аудит ПДн выявил рабочую базу в тестовой среде. Разбираем риски, порядок проверки, обезличивание данных и признаки, когда аудит нельзя откладывать.","meta_keywords":null,"meta_og_title":"Рабочая база в тестовой среде: что обнаруживает аудит ПДн","meta_og_description":"Разбираем случай, когда во время аудита ПДн обнаружилась копия рабочей базы с реальными данными пользователей в тестовой среде.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/audit-pdn-testovaya-baza","seo_canonical":"https://nsign.ru/blog/audit-pdn-testovaya-baza","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Рабочая база в тестовой среде: что обнаруживает аудит ПДн\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/audit-pdn-testovaya-baza\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-13 15:53:00","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/03/23/01b9407c67d83be740868f995d270af79c419af1.jpg","services":[],"randomBlogs":[{"id":107,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-zapustit-mvp","name":"Как запустить MVP: от критической гипотезы до решения об инвестициях","annotation":"","blog":"$40","backgroundType":null,"sizeType":1,"datePublication":"2026-08-04 00:00:00","position":15,"meta_title":"Как запустить MVP: от гипотезы до решения об инвестициях","meta_description":"Практическое руководство для бизнеса: как выбрать гипотезу, собрать MVP, провести пилот и решить, стоит ли развивать полноценный продукт.","meta_keywords":null,"meta_og_title":"Как запустить MVP: от гипотезы до решения об инвестициях","meta_og_description":"Как определить критическую гипотезу, собрать законченный сценарий, провести пилот и оценить целесообразность дальнейшей разработки.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-zapustit-mvp","seo_canonical":"https://nsign.ru/blog/kak-zapustit-mvp","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как запустить MVP: от критической гипотезы до решения об инвестициях\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-zapustit-mvp\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-04 17:05:25","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/8b/6f/a6b320eb2360ca2fc811950ffbcb6898ff4c1051.jpg","services":[]},{"id":79,"type":"internal","newsTypeId":1,"serviceId":null,"url":"devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem","name":"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-⁠систем","annotation":"","blog":"$41","backgroundType":null,"sizeType":1,"datePublication":"2026-05-14 00:00:00","position":40,"meta_title":"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-систем","meta_description":"Узнайте, как DevOps помогает ускорить доставку обновлений и повысить безопасность ИТ-систем, улучшая процессы разработки и эксплуатации.","meta_keywords":"DevOps, безопасность, доставка обновлений, ускорение разработки, IТ-системы","meta_og_title":"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-систем","meta_og_description":"Узнайте, как DevOps помогает ускорить доставку обновлений и повысить безопасность ИТ-систем, улучшая процессы разработки и эксплуатации.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem","seo_canonical":"https://nsign.ru/blog/devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как DevOps ускоряет доставку обновлений и повышает безопасность ИТ-систем\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/devops-uskoryaet-dostavku-obnovleniy-i-povyshaet-bezopasnost-it-sistem\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-17 16:22:27","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/de/c4/0c949724b31af9f728748debc4a59fa9f481028d.jpg","services":[]},{"id":87,"type":"internal","newsTypeId":1,"serviceId":null,"url":"istochniki-ugroz-informatsionnoy-bezopasnosti","name":"Источники угроз информационной безопасности","annotation":"","blog":"$42","backgroundType":null,"sizeType":1,"datePublication":"2026-06-09 00:00:00","position":32,"meta_title":"Источники угроз информационной безопасности","meta_description":"Где в компании возникают реальные угрозы ИБ: внешние атаки, внутренние ошибки, слабые доступы, уязвимости инфраструктуры и риск потери данных.","meta_keywords":"источники угроз информационной безопасности, угрозы ИБ, информационная безопасность бизнеса, уязвимости инфраструктуры, контроль доступов, защита данных, киберугрозы","meta_og_title":"Источники угроз информационной безопасности","meta_og_description":"Где в компании возникают реальные угрозы ИБ: внешние атаки, внутренние ошибки, слабые доступы, уязвимости инфраструктуры и риск потери данных.\r\n","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti","seo_canonical":"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Источники угроз информационной безопасности\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti\"\r\n }\r\n}","hidden":0,"createdAt":"2026-05-10 17:44:52","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4e/f3/54d5ed96ed3184064e2ff5647809c5dc55bf0d30.jpg","services":[]}]},{"id":109,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-zashchitit-sayt-ot-vzloma","name":"Как защитить сайт от взлома: 7 независимых уровней защиты","annotation":"","blog":"$43","backgroundType":null,"sizeType":1,"datePublication":"2026-08-11 00:00:00","position":13,"meta_title":"Как защитить сайт от взлома: 7 уровней защиты","meta_description":"Семь независимых уровней защиты сайта: доступы, код, обновления, периметр, CI/CD, мониторинг и восстановление. Кейс DDoS-атаки.","meta_keywords":null,"meta_og_title":"Как защитить сайт от взлома: 7 независимых уровней защиты","meta_og_description":"Как построить защиту сайта, при которой отказ одного уровня не приводит к полной компрометации системы. Кейс DDoS-атаки и чек-лист.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-zashchitit-sayt-ot-vzloma","seo_canonical":"https://nsign.ru/blog/kak-zashchitit-sayt-ot-vzloma","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как защитить сайт от взлома: 7 независимых уровней защиты\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-zashchitit-sayt-ot-vzloma\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-11 10:45:37","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/e3/ea/fa085b7867d7e4c31aa7fe924608840b2eaa9390.jpg","services":[],"randomBlogs":[{"id":67,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-izbezhat-oshibok-pri-migracii-s-zarubezhnyh-it-reshenij-na-otechestvennye","name":"Как избежать ошибок при миграции с зарубежных ИТ-⁠решений на отечественные","annotation":"","blog":"$44","backgroundType":null,"sizeType":1,"datePublication":"2026-04-09 00:00:00","position":55,"meta_title":"Как избежать ошибок при миграции с зарубежных ИТ-решений на отечественные","meta_description":"Узнайте, как избежать основных ошибок при миграции с зарубежных ИТ-решений на отечественные, минимизируя риски и затраты.","meta_keywords":"миграция ИТ, зарубежные ИТ-решения, отечественные ИТ-решения, переход на отечественные технологии, миграция данных","meta_og_title":"Как избежать ошибок при миграции с зарубежных ИТ-решений на отечественные","meta_og_description":"Узнайте, как избежать основных ошибок при миграции с зарубежных ИТ-решений на отечественные, минимизируя риски и затраты.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-izbezhat-oshibok-pri-migracii-s-zarubezhnyh-it-reshenij-na-otechestvennye","seo_canonical":"https://nsign.ru/blog/kak-izbezhat-oshibok-pri-migracii-s-zarubezhnyh-it-reshenij-na-otechestvennye","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как избежать ошибок при миграции с зарубежных ИТ-решений на отечественные\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-izbezhat-oshibok-pri-migracii-s-zarubezhnyh-it-reshenij-na-otechestvennye\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-05 18:58:53","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/01/ce/db215b9f62e84c01f4ce6d910635e0cd118f674b.jpg","services":[]},{"id":83,"type":"internal","newsTypeId":1,"serviceId":null,"url":"srs-zachem-on-nuzhen-do-starta-razrabotki","name":"SRS: зачем он нужен до старта разработки, а не после первой дорогой переделки","annotation":"","blog":"$45","backgroundType":null,"sizeType":1,"datePublication":"2026-05-21 00:00:00","position":37,"meta_title":"SRS: зачем он нужен до старта разработки, а не после первой дорогой переделки","meta_description":"Что дает SRS, когда без него уже опасно, из каких блоков он состоит и как требования снижают риск переделок, конфликтов и срывов сроков.","meta_keywords":"SRS, спецификация требований, software requirements specification, требования к ПО, документ требований, B2B IT, разработка ПО, системный анализ","meta_og_title":"SRS: зачем он нужен до старта разработки, а не после первой дорогой переделки","meta_og_description":"Что дает SRS, когда без него уже опасно, из каких блоков он состоит и как требования снижают риск переделок, конфликтов и срывов сроков.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/srs-zachem-on-nuzhen-do-starta-razrabotki","seo_canonical":"https://nsign.ru/blog/srs-zachem-on-nuzhen-do-starta-razrabotki","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"SRS: зачем он нужен до старта разработки, а не после первой дорогой переделки\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/srs-zachem-on-nuzhen-do-starta-razrabotki\"\r\n }\r\n}","hidden":0,"createdAt":"2026-05-10 17:19:46","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/a4/dd/1dfc24e803def7fbe7d084b00e0339d42fd46444.jpg","services":[]},{"id":20,"type":"internal","newsTypeId":1,"serviceId":null,"url":"check-of-roskomnadzor","name":"Как подготовиться к проверке Роскомнадзора по персональным данным — чек-лист и документы","annotation":"

Подробное руководство по подготовке к проверке Роскомнадзора: порядок, виды проверок, список документов, частые ошибки и советы экспертов «ЭНСАЙН» по работе с персональными данными.

","blog":"$46","backgroundType":null,"sizeType":1,"datePublication":"2025-11-11 00:00:00","position":105,"meta_title":"Как подготовиться к проверке Роскомнадзора по персональным данным — чек-лист и документы","meta_description":"Подробное руководство по подготовке к проверке Роскомнадзора: порядок, виды проверок, список документов, частые ошибки и советы экспертов «ЭНСАЙН» по работе с персональными данными.","meta_keywords":"подготовка к проверке Роскомнадзора, проверке Роскомнадзор, проверка персональных данных, чек-лист Роскомнадзор, документы для Роскомнадзора, обработка персональных данных, политика обработки персональных данных","meta_og_title":"Как подготовиться к проверке Роскомнадзора по персональным данным — чек-лист и документы","meta_og_description":"Подробное руководство по подготовке к проверке Роскомнадзора: порядок, виды проверок, список документов, частые ошибки и советы экспертов «ЭНСАЙН» по работе с персональными данными.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/check-of-roskomnadzor","seo_canonical":"https://nsign.ru/blog/check-of-roskomnadzor","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как подготовиться к проверке Роскомнадзора по персональным данным — чек-лист и документы\",\r\n \"description\": \"Подробное руководство по подготовке к проверке Роскомнадзора: порядок, виды проверок, список документов, частые ошибки и советы экспертов «ЭНСАЙН» по работе с персональными данными.\",\r\n \"inLanguage\": \"ru-RU\",\r\n \"url\": \"https://nsign.ru/blog/check-of-roskomnadzor\",\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/check-of-roskomnadzor\"\r\n }\r\n}\r\n","hidden":0,"createdAt":"2025-11-11 09:00:30","updatedAt":"2026-09-30 05:38:08","relatedService":null,"image":"https://n-dl.nsign.ru/repository/6c/93/a3194d28fa2c0c0d89a23672844cf61000c9e73d.png","services":[]}]},{"id":108,"type":"internal","newsTypeId":1,"serviceId":null,"url":"integraciya-bitrix24-1c","name":"Как интегрировать «Битрикс24» и 1С, чтобы сотрудники не сверяли данные вручную","annotation":"","blog":"$47","backgroundType":null,"sizeType":1,"datePublication":"2026-08-06 00:00:00","position":14,"meta_title":"Интеграция Битрикс24 и 1С без дублей и ручной сверки","meta_description":"Как настроить интеграцию Битрикс24 и 1С, распределить ответственность за данные, исключить дубли и контролировать обмен после запуска.","meta_keywords":null,"meta_og_title":"Интеграция Битрикс24 и 1С без дублей и ручной сверки","meta_og_description":"Разбираем, как превратить штатное подключение Битрикс24 к 1С в надежный и контролируемый бизнес-процесс.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/integraciya-bitrix24-1c","seo_canonical":"https://nsign.ru/blog/integraciya-bitrix24-1c","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как интегрировать Битрикс24 и 1С, чтобы сотрудники не сверяли данные вручную\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/integraciya-bitrix24-1c\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-06 14:36:53","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/98/b6/0cc61e1dba0e90f13bdc48927e94430cadd5971e.jpg","services":[],"randomBlogs":[{"id":34,"type":"external","newsTypeId":2,"serviceId":null,"url":"https://www.itweek.ru/management/news-company/detail.php?id=233898","name":"Обновлённая экосистема ВДНХ: улучшенный UX и ускорение LCP на 40%","annotation":"","blog":"","backgroundType":null,"sizeType":1,"datePublication":"2025-12-26 00:00:00","position":87,"meta_title":null,"meta_description":null,"meta_keywords":null,"meta_og_title":null,"meta_og_description":null,"meta_og_type":"article","meta_og_url":null,"seo_canonical":null,"seo_schemaorg":null,"hidden":0,"createdAt":"2025-12-26 12:20:51","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/d8/e3/2c236b86ca489656f1427e6bb6e52094f820452f.png","services":[]},{"id":75,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-vyglyadit-zhelyryy-it-partner-glazami-cio","name":"Как выглядит зрелый IT-⁠партнёр глазами CIO","annotation":"","blog":"$48","backgroundType":null,"sizeType":1,"datePublication":"2026-04-28 00:00:00","position":45,"meta_title":"Как выглядит зрелый IT-партнёр глазами CIO","meta_description":"Узнайте, каким должен быть зрелый IT-партнёр с точки зрения CIO и почему зрелость партнёрства важна для бизнеса.","meta_keywords":"зрелый IT-партнёр, CIO, выбор партнёра, долгосрочное сотрудничество, стабильность бизнеса, IT-услуги","meta_og_title":"Как выглядит зрелый IT-партнёр глазами CIO","meta_og_description":"Узнайте, каким должен быть зрелый IT-партнёр с точки зрения CIO и почему зрелость партнёрства важна для бизнеса.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-vyglyadit-zhelyryy-it-partner-glazami-cio","seo_canonical":"https://nsign.ru/blog/kak-vyglyadit-zhelyryy-it-partner-glazami-cio","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как выглядит зрелый IT-партнёр глазами CIO\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-vyglyadit-zhelyryy-it-partner-glazami-cio\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-13 21:10:48","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/51/01/312438f87c23e080ce57052a2e45affc9fad983a.jpg","services":[]},{"id":66,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kogda-podderzhka-deshevle-chem-razvitie","name":"Когда поддержка дешевле, чем развитие","annotation":"","blog":"$49","backgroundType":null,"sizeType":1,"datePublication":"2026-04-10 00:00:00","position":54,"meta_title":"Когда поддержка дешевле, чем развитие — стратегические решения для бизнеса","meta_description":"Узнайте, почему поддержка устаревших систем может быть более выгодной и безопасной альтернативой развитию для вашего бизнеса.","meta_keywords":"поддержка систем, развитие vs поддержка, IT решения, стабильность системы, экономия ресурсов, оптимизация рисков","meta_og_title":"Когда поддержка дешевле, чем развитие — стратегические решения для бизнеса","meta_og_description":"Узнайте, почему поддержка устаревших систем может быть более выгодной и безопасной альтернативой развитию для вашего бизнеса.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kogda-podderzhka-deshevle-chem-razvitie","seo_canonical":"https://nsign.ru/blog/kogda-podderzhka-deshevle-chem-razvitie","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Когда поддержка дешевле, чем развитие — стратегические решения для бизнеса\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kogda-podderzhka-deshevle-chem-razvitie\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-05 18:41:58","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4c/a9/e09c61db05abf98478a30389139d52eec91976ae.jpg","services":[]}]},{"id":107,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-zapustit-mvp","name":"Как запустить MVP: от критической гипотезы до решения об инвестициях","annotation":"","blog":"$4a","backgroundType":null,"sizeType":1,"datePublication":"2026-08-04 00:00:00","position":15,"meta_title":"Как запустить MVP: от гипотезы до решения об инвестициях","meta_description":"Практическое руководство для бизнеса: как выбрать гипотезу, собрать MVP, провести пилот и решить, стоит ли развивать полноценный продукт.","meta_keywords":null,"meta_og_title":"Как запустить MVP: от гипотезы до решения об инвестициях","meta_og_description":"Как определить критическую гипотезу, собрать законченный сценарий, провести пилот и оценить целесообразность дальнейшей разработки.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-zapustit-mvp","seo_canonical":"https://nsign.ru/blog/kak-zapustit-mvp","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как запустить MVP: от критической гипотезы до решения об инвестициях\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-zapustit-mvp\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-04 17:05:25","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/8b/6f/a6b320eb2360ca2fc811950ffbcb6898ff4c1051.jpg","services":[],"randomBlogs":[{"id":63,"type":"internal","newsTypeId":1,"serviceId":null,"url":"pochemu-optimizatsiya-it-infrastruktury-eto-ne-rashod-a-investitsiya","name":"Почему оптимизация ИТ-⁠инфраструктуры — это не расход, а инвестиция","annotation":"","blog":"$4b","backgroundType":null,"sizeType":1,"datePublication":"2026-04-06 00:00:00","position":58,"meta_title":"Почему оптимизация ИТ-инфраструктуры — это не расход, а инвестиция","meta_description":"Оптимизация ИТ-инфраструктуры — ключ к росту бизнеса. Узнайте, как инвестиции в ИТ-системы обеспечат стабильность и снижение рисков.","meta_keywords":"оптимизация ИТ, инвестиции в ИТ, модернизация инфраструктуры, обновление ПО, долгосрочные инвестиции","meta_og_title":"Почему оптимизация ИТ-инфраструктуры — это не расход, а инвестиция","meta_og_description":"Оптимизация ИТ-инфраструктуры — ключ к росту бизнеса. Узнайте, как инвестиции в ИТ-системы обеспечат стабильность и снижение рисков.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/pochemu-optimizatsiya-it-infrastruktury-eto-ne-rashod-a-investitsiya","seo_canonical":"https://nsign.ru/blog/pochemu-optimizatsiya-it-infrastruktury-eto-ne-rashod-a-investitsiya","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему оптимизация ИТ-инфраструктуры — это не расход, а инвестиция\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/pochemu-optimizatsiya-it-infrastruktury-eto-ne-rashod-a-investitsiya\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-05 17:01:44","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/e6/6c/52893418d3b9acdad8b7b8c0f4aa621c6de6fa5b.jpg","services":[]},{"id":48,"type":"internal","newsTypeId":1,"serviceId":null,"url":"why-cio-rarely-tell-the-truth-about-the-condition-of-it-systems","name":"Почему CIO редко говорят правду о состоянии IT-⁠систем","annotation":"","blog":"$4c","backgroundType":null,"sizeType":1,"datePublication":"2026-03-10 00:00:00","position":72,"meta_title":"Почему CIO редко говорят правду о состоянии IT-систем","meta_description":"Почему CIO часто скрывают реальные проблемы с IT-системами, и как это влияет на долгосрочную стабильность бизнеса?","meta_keywords":"CIO, IT-системы, модернизация, поддержка, риски","meta_og_title":"Почему CIO редко говорят правду о состоянии IT-систем","meta_og_description":"Почему CIO часто скрывают реальные проблемы с IT-системами, и как это влияет на долгосрочную стабильность бизнеса?","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/why-cio-rarely-tell-the-truth-about-the-condition-of-it-systems","seo_canonical":"https://nsign.ru/blog/why-cio-rarely-tell-the-truth-about-the-condition-of-it-systems","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему CIO редко говорят правду о состоянии IT-систем\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/why-cio-rarely-tell-the-truth-about-the-condition-of-it-systems\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-10 15:04:19","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/47/fe/f6d82740bd5de945df6d116af1d49a7e3a239eb2.jpg","services":[]},{"id":117,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kogda-nuzhna-sobstvennaya-cms","name":"Когда бизнесу нужна собственная CMS: 7 признаков","annotation":"","blog":"$4d","backgroundType":null,"sizeType":1,"datePublication":"2026-09-17 00:00:00","position":6,"meta_title":"Когда бизнесу нужна собственная CMS: 7 признаков | Энсайн","meta_description":"7 признаков, что готовая CMS стала ограничивать развитие проекта: растут затраты на доработки, дублируются данные и усложняется архитектура.","meta_keywords":null,"meta_og_title":"Когда бизнесу нужна собственная CMS: 7 признаков","meta_og_description":"Как понять, что ресурсы уходят уже не на развитие продукта, а на преодоление ограничений CMS. 7 признаков для диагностики проекта.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_canonical":"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Когда бизнесу нужна собственная CMS: 7 признаков\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kogda-nuzhna-sobstvennaya-cms\"\r\n }\r\n}","hidden":0,"createdAt":"2026-09-17 20:45:51","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/fb/9c/74c150675357fd2bef1cd1e92303281842622335.jpg","services":[]}]},{"id":106,"type":"internal","newsTypeId":1,"serviceId":null,"url":"ai-assistants-business-processes","name":"Бизнес устал от чат-⁠ботов. Почему ИИ-⁠помощник должен не отвечать, а работать","annotation":"","blog":"$4e","backgroundType":null,"sizeType":1,"datePublication":"2026-07-30 00:00:00","position":16,"meta_title":"ИИ-помощники в бизнесе: от чат-ботов к рабочим процессам","meta_description":"Как бизнес переходит от чат-ботов к ИИ-помощникам, встроенным в процессы, данные и корпоративные системы.","meta_keywords":null,"meta_og_title":"ИИ-помощники в бизнесе: от чат-ботов к рабочим процессам","meta_og_description":"Почему бизнесу уже недостаточно чат-ботов и как ИИ-помощники начинают выполнять рабочие задачи внутри компаний.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/ai-assistants-business-processes","seo_canonical":"https://nsign.ru/blog/ai-assistants-business-processes","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Бизнес устал от чат-ботов. Почему ИИ-помощник должен не отвечать, а работать\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/ai-assistants-business-processes\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-30 14:53:42","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/f0/12/c79192b9a49f69ad5d0da24296a5972ed8e9ff2f.jpg","services":[],"randomBlogs":[{"id":80,"type":"internal","newsTypeId":1,"serviceId":null,"url":"it-podderzhka-i-slugi-sla-pod-bjudzhet","name":"Как адаптировать ИТ-⁠поддержку под ваш бюджет: выбираем подходящий SLA","annotation":"","blog":"$4f","backgroundType":null,"sizeType":1,"datePublication":"2026-05-19 00:00:00","position":39,"meta_title":"Как адаптировать ИТ-поддержку под ваш бюджет: выбираем подходящий SLA","meta_description":"Узнайте, как выбрать подходящий SLA для ИТ-поддержки в зависимости от бюджета и потребностей вашего бизнеса.","meta_keywords":"ИТ-поддержка, SLA, выбор SLA, бюджет, настройка SLA, поддержка бизнеса","meta_og_title":"Как адаптировать ИТ-поддержку под ваш бюджет: выбираем подходящий SLA","meta_og_description":"Узнайте, как выбрать подходящий SLA для ИТ-поддержки в зависимости от бюджета и потребностей вашего бизнеса.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/it-podderzhka-i-slugi-sla-pod-bjudzhet","seo_canonical":"https://nsign.ru/blog/it-podderzhka-i-slugi-sla-pod-bjudzhet","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как адаптировать ИТ-поддержку под ваш бюджет: выбираем подходящий SLA\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/it-podderzhka-i-slugi-sla-pod-bjudzhet\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-21 05:51:09","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/b5/ba/f296544ccbe9afcadb51f75299287b04f47d7479.jpg","services":[]},{"id":97,"type":"internal","newsTypeId":1,"serviceId":null,"url":"hconfig-linux-infrastructure-automation","name":"«Энсайн» открыла доступ к HConfig для автоматизации Linux-инфраструктуры","annotation":"","blog":"$50","backgroundType":null,"sizeType":1,"datePublication":"2026-07-02 00:00:00","position":24,"meta_title":"HConfig: автоматизация настройки Linux-серверов","meta_description":"«Энсайн» открыла доступ к HConfig — инструменту автоматизации настройки, миграции и сопровождения серверов на базе Linux.","meta_keywords":null,"meta_og_title":"HConfig: автоматизация настройки Linux-серверов","meta_og_description":"Инструмент «Энсайн» для стандартизации настройки Linux-серверов, миграции веб-проектов и сокращения ручных операций.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/hconfig-linux-infrastructure-automation","seo_canonical":"https://nsign.ru/blog/hconfig-linux-infrastructure-automation","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"«Энсайн» открыла доступ к HConfig для автоматизации Linux-инфраструктуры\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/hconfig-linux-infrastructure-automation\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-02 14:36:54","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/54/24/3b9340ba298caa022ec29ce6cdcf396c1d296244.jpg","services":[]},{"id":47,"type":"internal","newsTypeId":1,"serviceId":null,"url":"cio-fear-of-changing-legacy","name":"Почему CIO боятся менять legacy — и они правы","annotation":"","blog":"$51","backgroundType":null,"sizeType":1,"datePublication":"2026-03-05 00:00:00","position":73,"meta_title":"Почему CIO боятся менять legacy — и они правы","meta_description":"Узнайте, почему CIO избегают изменений в legacy-системах и как это влияет на безопасность, эффективность и риски бизнеса.","meta_keywords":"legacy системы, модернизация IT, CIO, риски в IT, безопасность IT систем, IT поддержка","meta_og_title":"Почему CIO боятся менять legacy — и они правы","meta_og_description":"Узнайте, почему CIO избегают изменений в legacy-системах и как это влияет на безопасность, эффективность и риски бизнеса.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/cio-fear-of-changing-legacy","seo_canonical":"https://nsign.ru/blog/cio-fear-of-changing-legacy","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему CIO боятся менять legacy — и они правы\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/cio-fear-of-changing-legacy\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-05 18:46:31","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/34/42/3c3ec4e4682b3f05fcd89f12b333f417718284da.jpg","services":[]}]},{"id":105,"type":"internal","newsTypeId":1,"serviceId":null,"url":"korporativnyy-portal-avtomatizaciya-processov","name":"Разработка корпоративного портала: какие процессы автоматизировать первыми","annotation":"","blog":"$52","backgroundType":null,"sizeType":1,"datePublication":"2026-07-28 00:00:00","position":17,"meta_title":"Разработка корпоративного портала: что автоматизировать первым","meta_description":null,"meta_keywords":"Какие процессы автоматизировать в корпоративном портале первыми: командировки, согласования, доступы, заявки, закупки и интеграции систем.","meta_og_title":"Разработка корпоративного портала: какие процессы автоматизировать первыми","meta_og_description":"Разбираем, какие внутренние процессы стоит переносить в корпоративный портал и как связать сотрудников, подразделения и информационные системы.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/korporativnyy-portal-avtomatizaciya-processov","seo_canonical":"https://nsign.ru/blog/korporativnyy-portal-avtomatizaciya-processov","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Разработка корпоративного портала: какие процессы автоматизировать первыми\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/korporativnyy-portal-avtomatizaciya-processov\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-28 11:31:38","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/dd/a6/1d60a64304fd7412e0a65587108027914c832969.jpg","services":[],"randomBlogs":[{"id":113,"type":"internal","newsTypeId":1,"serviceId":null,"url":"vidy-cms-dlya-korporativnogo-saita","name":"Какие бывают CMS для корпоративного сайта","annotation":"","blog":"$53","backgroundType":null,"sizeType":1,"datePublication":"2026-08-25 00:00:00","position":10,"meta_title":"Какие бывают CMS для корпоративного сайта | Энсайн","meta_description":"Разбираем виды CMS для корпоративных сайтов: готовые и собственные, классические и headless. Отличия, ограничения и особенности архитектуры.","meta_keywords":null,"meta_og_title":"Какие бывают CMS для корпоративного сайта","meta_og_description":"Готовая или собственная, классическая или headless: разбираем основные виды CMS и принципиальные различия между ними.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/vidy-cms-dlya-korporativnogo-saita","seo_canonical":"https://nsign.ru/blog/vidy-cms-dlya-korporativnogo-saita","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Какие бывают CMS для корпоративного сайта\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/vidy-cms-dlya-korporativnogo-saita\"\r\n }\r\n}","hidden":0,"createdAt":"2026-08-25 18:03:15","updatedAt":"2026-09-30 05:38:03","relatedService":null,"image":"https://n-dl.nsign.ru/repository/bd/fa/c215eaf7b3e353d640ca67e4a338eb99af2d7234.jpg","services":[]},{"id":55,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-vybrat-pravilnogo-it-podryadchika-5-riskov-i-pochemu-tsena-ne-glavnoe","name":"Как выбрать правильного IT-⁠подрядчика: 5 рисков и почему цена не главное","annotation":"","blog":"$54","backgroundType":null,"sizeType":1,"datePublication":"2026-03-25 00:00:00","position":67,"meta_title":"Как выбрать правильного IT‑подрядчика: 5 рисков и почему цена не главное","meta_description":"Узнайте, как избежать рисков при выборе IT‑подрядчика, что важно при оценке качества и стоимости. Инвестируйте в надежность, а не только цену.","meta_keywords":"IT подрядчик, выбор подрядчика, риски выбора подрядчика, качество IT решений, как выбрать IT подрядчика, гарантии сроков и качества","meta_og_title":"Как выбрать правильного IT‑подрядчика: 5 рисков и почему цена не главное","meta_og_description":"Узнайте, как избежать рисков при выборе IT‑подрядчика, что важно при оценке качества и стоимости. Инвестируйте в надежность, а не только цену.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-vybrat-pravilnogo-it-podryadchika-5-riskov-i-pochemu-tsena-ne-glavnoe","seo_canonical":"https://nsign.ru/blog/kak-vybrat-pravilnogo-it-podryadchika-5-riskov-i-pochemu-tsena-ne-glavnoe","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как выбрать правильного IT‑подрядчика: 5 рисков и почему цена не главное\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-vybrat-pravilnogo-it-podryadchika-5-riskov-i-pochemu-tsena-ne-glavnoe\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-23 20:42:41","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/b0/d8/b7a8a70901734eaabeef5405e770765b1298f0b5.jpg","services":[]},{"id":61,"type":"internal","newsTypeId":1,"serviceId":null,"url":"ai-human-razrabotka-veb-portalov-veb-servisov-2026-nsign","name":"Разработка веб-порталов и веб-сервисов в 2026 году: почему модель AI + Human стала новым стандартом в Энсайн","annotation":"","blog":"$55","backgroundType":null,"sizeType":1,"datePublication":"2026-04-01 00:00:00","position":61,"meta_title":"AI + Human в разработке веб-порталов и сервисов в 2026","meta_description":"Как модель AI + Human в Энсайн ускоряет разработку веб-порталов и веб-сервисов без потери качества, безопасности и инженерного контроля.","meta_keywords":"разработка веб-порталов, разработка веб-сервисов, AI + Human, заказная разработка, Энсайн, B2B IT, архитектура, DevOps, интеграции, 1С","meta_og_title":"AI + Human в разработке веб-порталов и сервисов в 2026","meta_og_description":"Как модель AI + Human в Энсайн ускоряет разработку веб-порталов и веб-сервисов без потери качества, безопасности и инженерного контроля.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/ai-human-razrabotka-veb-portalov-veb-servisov-2026-nsign","seo_canonical":"https://nsign.ru/blog/ai-human-razrabotka-veb-portalov-veb-servisov-2026-nsign","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"AI + Human в разработке веб-порталов и сервисов в 2026\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/ai-human-razrabotka-veb-portalov-veb-servisov-2026-nsign\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-30 18:49:42","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/b2/77/f5d6578caf73114d048b5b92b6f3c9f3663431d4.jpg","services":[]}]},{"id":103,"type":"internal","newsTypeId":1,"serviceId":null,"url":"novosti-mincifry-iyul-2026","name":"Новости Минцифры за июль: гранты, ИИ и новые планы по цифровизации государства","annotation":"","blog":"$56","backgroundType":null,"sizeType":1,"datePublication":"2026-07-23 00:00:00","position":18,"meta_title":"Новости Минцифры за июль 2026: гранты, ИИ и цифровизация","meta_description":"Главные новости Минцифры за июль 2026 года: гранты для ИТ-компаний, регулирование ИИ, цифровизация государства и данные по рынку.","meta_keywords":null,"meta_og_title":"Новости Минцифры за июль 2026: гранты, ИИ и цифровизация","meta_og_description":"Гранты для российских разработчиков, регулирование ИИ, цифровизация госуправления и свежие данные по ИТ-рынку.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/novosti-mincifry-iyul-2026","seo_canonical":"https://nsign.ru/blog/novosti-mincifry-iyul-2026","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Новости Минцифры за июль: гранты, ИИ и новые планы по цифровизации государства\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/novosti-mincifry-iyul-2026\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-23 13:13:35","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/71/c2/7df69c5443ceb6ff63aa3253e70465833795ce88.jpg","services":[],"randomBlogs":[{"id":99,"type":"internal","newsTypeId":1,"serviceId":null,"url":"stoimost-razrabotki-sayta-portala","name":"Сколько стоит разработка сайта или корпоративного портала в 2026 году","annotation":"","blog":"$57","backgroundType":null,"sizeType":1,"datePublication":"2026-07-09 00:00:00","position":22,"meta_title":"Сколько стоит разработка сайта или портала в 2026 году","meta_description":"Цены на разработку корпоративных сайтов и порталов в 2026 году: этапы, ставки подрядчиков, скрытые расходы и правила сравнения смет.","meta_keywords":null,"meta_og_title":"Сколько стоит сайт или корпоративный портал в 2026 году","meta_og_description":"Разбираем цены на корпоративные сайты и порталы, состав проектной сметы, скрытые расходы и причины расхождений между предложениями подрядчиков.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/stoimost-razrabotki-sayta-portala","seo_canonical":"https://nsign.ru/blog/stoimost-razrabotki-sayta-portala","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Сколько стоит разработка сайта или корпоративного портала в 2026 году\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/stoimost-razrabotki-sayta-portala\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-09 14:42:41","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/40/58/b17a10d7f9868acb8819becce7510a507b946477.jpg","services":[]},{"id":69,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-evolyutsionno-razvivat-legacy-sistemu-bez-ostanovki-biznesa","name":"Как эволюционно развивать legacy-систему без остановки бизнеса","annotation":"","blog":"$58","backgroundType":null,"sizeType":1,"datePublication":"2026-04-14 00:00:00","position":52,"meta_title":"Как эволюционно развивать legacy-систему без остановки бизнеса","meta_description":"Узнайте, как модернизировать legacy-системы поэтапно, не нарушая стабильность работы бизнеса и минимизируя риски.","meta_keywords":"эволюционное развитие, модернизация legacy-систем, поддержка IT, без остановки бизнеса, постепенные улучшения","meta_og_title":"Как эволюционно развивать legacy-систему без остановки бизнеса","meta_og_description":"Узнайте, как модернизировать legacy-системы поэтапно, не нарушая стабильность работы бизнеса и минимизируя риски.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-evolyutsionno-razvivat-legacy-sistemu-bez-ostanovki-biznesa","seo_canonical":"https://nsign.ru/blog/kak-evolyutsionno-razvivat-legacy-sistemu-bez-ostanovki-biznesa","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как эволюционно развивать legacy-систему без остановки бизнеса\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-evolyutsionno-razvivat-legacy-sistemu-bez-ostanovki-biznesa\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-12 17:52:34","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/6a/d1/6ea751a325dee04701923730da550b59ad132dcd.jpg","services":[]},{"id":87,"type":"internal","newsTypeId":1,"serviceId":null,"url":"istochniki-ugroz-informatsionnoy-bezopasnosti","name":"Источники угроз информационной безопасности","annotation":"","blog":"$59","backgroundType":null,"sizeType":1,"datePublication":"2026-06-09 00:00:00","position":32,"meta_title":"Источники угроз информационной безопасности","meta_description":"Где в компании возникают реальные угрозы ИБ: внешние атаки, внутренние ошибки, слабые доступы, уязвимости инфраструктуры и риск потери данных.","meta_keywords":"источники угроз информационной безопасности, угрозы ИБ, информационная безопасность бизнеса, уязвимости инфраструктуры, контроль доступов, защита данных, киберугрозы","meta_og_title":"Источники угроз информационной безопасности","meta_og_description":"Где в компании возникают реальные угрозы ИБ: внешние атаки, внутренние ошибки, слабые доступы, уязвимости инфраструктуры и риск потери данных.\r\n","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti","seo_canonical":"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Источники угроз информационной безопасности\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/istochniki-ugroz-informatsionnoy-bezopasnosti\"\r\n }\r\n}","hidden":0,"createdAt":"2026-05-10 17:44:52","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4e/f3/54d5ed96ed3184064e2ff5647809c5dc55bf0d30.jpg","services":[]}]},{"id":102,"type":"internal","newsTypeId":1,"serviceId":null,"url":"open-source-v-korporativnoy-razrabotke","name":"Open source в проекте: сэкономили на старте, но поддерживать все равно придется","annotation":"","blog":"$5a","backgroundType":null,"sizeType":1,"datePublication":"2026-07-21 00:00:00","position":19,"meta_title":"Open source в проекте: выгода и поддержка после запуска","meta_description":"Как использовать open source в корпоративной разработке без лишнего техдолга, проблем с обновлениями, лицензиями и поддержкой.","meta_keywords":null,"meta_og_title":"Open source в проекте: выгода и поддержка после запуска","meta_og_description":"Разбираем, когда open source помогает быстрее запустить продукт, а когда требует дополнительных затрат на поддержку, обновления и безопасность.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/open-source-v-korporativnoy-razrabotke","seo_canonical":"https://nsign.ru/blog/open-source-v-korporativnoy-razrabotke","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Open source в проекте: быстро взять — не значит забыть после запуска\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/open-source-v-korporativnoy-razrabotke\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-21 05:19:38","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/e3/94/ca1a8208a220e8a947f7eaf15c37b4276dc1af68.jpg","services":[],"randomBlogs":[{"id":38,"type":"internal","newsTypeId":1,"serviceId":null,"url":"legacy-system-management-risks-strategies-errors","name":"Почему простые правки в legacy почти никогда не бывают простыми","annotation":"","blog":"$5b","backgroundType":null,"sizeType":1,"datePublication":"2026-02-13 00:00:00","position":82,"meta_title":"Почему простые правки в legacy почти никогда не бывают простыми","meta_description":"Почему простые правки в legacy-системах часто приводят к неожиданным сложностям. Управление рисками и реализация эффективных стратегий для старых систем.","meta_keywords":"legacy системы, управление legacy, риски legacy, ошибки legacy, поддержка legacy систем, обновление legacy, стратегии legacy","meta_og_title":"Почему простые правки в legacy почти никогда не бывают простыми","meta_og_description":"Почему простые правки в legacy-системах приводят к накоплению рисков и как управлять сложными системами без сбоев.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors","seo_canonical":"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему простые правки в legacy почти никогда не бывают простыми\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors\"\r\n }\r\n}","hidden":0,"createdAt":"2026-02-13 08:07:22","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/cc/52/584689bcd9334c752e789581b2601d7de44b7d25.png","services":[]},{"id":76,"type":"internal","newsTypeId":1,"serviceId":null,"url":"kak-obespechit-maksimalnuyu-proizvoditelnost-vashej-it-infrastruktury","name":"Как обеспечить максимальную производительность вашей ИТ-⁠инфраструктуры","annotation":"","blog":"$5c","backgroundType":null,"sizeType":1,"datePublication":"2026-05-05 00:00:00","position":43,"meta_title":"Как обеспечить максимальную производительность вашей ИТ-инфраструктуры","meta_description":"Узнайте, как повысить производительность вашей ИТ-инфраструктуры с помощью оптимизации ресурсов, модернизации оборудования и внедрения новых технологий.","meta_keywords":"производительность ИТ-инфраструктуры, оптимизация ресурсов, модернизация оборудования, повышение производительности","meta_og_title":"Как обеспечить максимальную производительность вашей ИТ-инфраструктуры","meta_og_description":"Узнайте, как повысить производительность вашей ИТ-инфраструктуры с помощью оптимизации ресурсов, модернизации оборудования и внедрения новых технологий.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/kak-obespechit-maksimalnuyu-proizvoditelnost-vashej-it-infrastruktury","seo_canonical":"https://nsign.ru/blog/kak-obespechit-maksimalnuyu-proizvoditelnost-vashej-it-infrastruktury","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Как обеспечить максимальную производительность вашей ИТ-инфраструктуры\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/kak-obespechit-maksimalnuyu-proizvoditelnost-vashej-it-infrastruktury\"\r\n }\r\n}","hidden":0,"createdAt":"2026-04-16 21:14:35","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/05/91/f1789ad164870cd030b5be99e94f3ec6109ddd1a.jpg","services":[]},{"id":28,"type":"external","newsTypeId":2,"serviceId":null,"url":"https://itrussia.media/ru/article/rossiyskiy-bank-usilil-zaschitu-dannykh-s-pomoschyu-novogo-s","name":"Российский банк усилил защиту данных с помощью нового сервиса рассылок","annotation":"","blog":"","backgroundType":null,"sizeType":1,"datePublication":"2025-12-26 00:00:00","position":93,"meta_title":null,"meta_description":null,"meta_keywords":null,"meta_og_title":null,"meta_og_description":null,"meta_og_type":"article","meta_og_url":null,"seo_canonical":null,"seo_schemaorg":null,"hidden":0,"createdAt":"2025-12-26 07:20:20","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/4c/de/b087bc9e4cac31ca3180583a0a05260c165703c9.png","services":[]}]},{"id":101,"type":"internal","newsTypeId":1,"serviceId":null,"url":"prompty-dlya-ii-v-biznes-processah","name":"Промты для ИИ: почему в одних задачах они дают сильный результат, а в других только создают иллюзию работы","annotation":"","blog":"$5d","backgroundType":null,"sizeType":1,"datePublication":"2026-07-16 00:00:00","position":20,"meta_title":"Промты для ИИ в бизнес-процессах: где они работают","meta_description":null,"meta_keywords":"Как промты помогают бизнесу работать с ИИ: когда они ускоряют процессы, а когда создают только иллюзию результата.","meta_og_title":"Промты для ИИ: где они дают результат, а где мешают","meta_og_description":"Разбираем, почему промты работают только при понятных данных, процессе, критериях результата и проверке человеком.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/prompty-dlya-ii-v-biznes-processah","seo_canonical":"https://nsign.ru/blog/prompty-dlya-ii-v-biznes-processah","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Промты для ИИ: почему в одних задачах они дают сильный результат, а в других только создают иллюзию работы\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/prompty-dlya-ii-v-biznes-processah\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-16 19:47:38","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/c9/1a/595ab935122359a88a2fa8f1696d577d47f09718.jpg","services":[],"randomBlogs":[{"id":38,"type":"internal","newsTypeId":1,"serviceId":null,"url":"legacy-system-management-risks-strategies-errors","name":"Почему простые правки в legacy почти никогда не бывают простыми","annotation":"","blog":"$5e","backgroundType":null,"sizeType":1,"datePublication":"2026-02-13 00:00:00","position":82,"meta_title":"Почему простые правки в legacy почти никогда не бывают простыми","meta_description":"Почему простые правки в legacy-системах часто приводят к неожиданным сложностям. Управление рисками и реализация эффективных стратегий для старых систем.","meta_keywords":"legacy системы, управление legacy, риски legacy, ошибки legacy, поддержка legacy систем, обновление legacy, стратегии legacy","meta_og_title":"Почему простые правки в legacy почти никогда не бывают простыми","meta_og_description":"Почему простые правки в legacy-системах приводят к накоплению рисков и как управлять сложными системами без сбоев.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors","seo_canonical":"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему простые правки в legacy почти никогда не бывают простыми\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/legacy-system-management-risks-strategies-errors\"\r\n }\r\n}","hidden":0,"createdAt":"2026-02-13 08:07:22","updatedAt":"2026-09-30 05:38:07","relatedService":null,"image":"https://n-dl.nsign.ru/repository/cc/52/584689bcd9334c752e789581b2601d7de44b7d25.png","services":[]},{"id":97,"type":"internal","newsTypeId":1,"serviceId":null,"url":"hconfig-linux-infrastructure-automation","name":"«Энсайн» открыла доступ к HConfig для автоматизации Linux-инфраструктуры","annotation":"","blog":"$5f","backgroundType":null,"sizeType":1,"datePublication":"2026-07-02 00:00:00","position":24,"meta_title":"HConfig: автоматизация настройки Linux-серверов","meta_description":"«Энсайн» открыла доступ к HConfig — инструменту автоматизации настройки, миграции и сопровождения серверов на базе Linux.","meta_keywords":null,"meta_og_title":"HConfig: автоматизация настройки Linux-серверов","meta_og_description":"Инструмент «Энсайн» для стандартизации настройки Linux-серверов, миграции веб-проектов и сокращения ручных операций.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/hconfig-linux-infrastructure-automation","seo_canonical":"https://nsign.ru/blog/hconfig-linux-infrastructure-automation","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"«Энсайн» открыла доступ к HConfig для автоматизации Linux-инфраструктуры\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/hconfig-linux-infrastructure-automation\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-02 14:36:54","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/54/24/3b9340ba298caa022ec29ce6cdcf396c1d296244.jpg","services":[]},{"id":98,"type":"internal","newsTypeId":1,"serviceId":null,"url":"ai-piloty-promyshlennoe-vnedrenie","name":"Почему ИИ-⁠пилоты не доходят до промышленной эксплуатации","annotation":"","blog":"$60","backgroundType":null,"sizeType":1,"datePublication":"2026-07-07 00:00:00","position":23,"meta_title":"Почему ИИ-пилоты не доходят до внедрения","meta_description":"Почему ИИ-проекты останавливаются после пилота: данные, интеграции, процессы, поддержка и экономика промышленного внедрения.","meta_keywords":null,"meta_og_title":"Почему ИИ-пилоты не доходят до промышленной эксплуатации","meta_og_description":"Разбираем, почему ИИ-проекты часто останавливаются после пилота и что мешает вывести их в постоянную работу.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/ai-piloty-promyshlennoe-vnedrenie","seo_canonical":"https://nsign.ru/blog/ai-piloty-promyshlennoe-vnedrenie","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему ИИ-пилоты не доходят до промышленной эксплуатации\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/ai-piloty-promyshlennoe-vnedrenie\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-07 08:52:50","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/84/dc/87dcf8b6fe3ad5c65f088e9fd6ddac76952163a1.jpg","services":[]}]},{"id":100,"type":"internal","newsTypeId":1,"serviceId":null,"url":"razrabotka-lichnogo-kabineta","name":"Личный кабинет для сайта или сервиса: что продумать перед разработкой","annotation":"","blog":"$61","backgroundType":null,"sizeType":1,"datePublication":"2026-07-14 00:00:00","position":21,"meta_title":"Разработка личного кабинета для сайта или сервиса","meta_description":"Что продумать перед разработкой личного кабинета: роли, сценарии, данные, интеграции, админку и поддержку после запуска.","meta_keywords":null,"meta_og_title":"Разработка личного кабинета для сайта или сервиса","meta_og_description":"Практические рекомендации: когда бизнесу нужен личный кабинет, что включить в первый релиз и какие ошибки приводят к переделкам.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/razrabotka-lichnogo-kabineta","seo_canonical":"https://nsign.ru/blog/razrabotka-lichnogo-kabineta","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Личный кабинет для сайта или сервиса: что продумать перед разработкой\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/razrabotka-lichnogo-kabineta\"\r\n }\r\n}","hidden":0,"createdAt":"2026-07-14 08:03:13","updatedAt":"2026-09-30 05:38:04","relatedService":null,"image":"https://n-dl.nsign.ru/repository/fe/3e/72c80b9178324596a9ed0d27ec563bd18d880e11.jpg","services":[],"randomBlogs":[{"id":51,"type":"internal","newsTypeId":1,"serviceId":null,"url":"typovye-oshibki-podryadchikov-pri-rabotye-s-legacy","name":"Почему подрядчики не справляются с legacy — типовые ошибки рынка","annotation":"","blog":"$62","backgroundType":null,"sizeType":1,"datePublication":"2026-03-19 00:00:00","position":69,"meta_title":"Почему подрядчики не справляются с legacy — типовые ошибки рынка","meta_description":"Основные ошибки подрядчиков при работе с legacy-системами: причины и последствия для бизнеса. Как избежать проблем при модернизации и поддержке старых решений.","meta_keywords":"legacy системы, ошибки подрядчиков, поддержка legacy, технический долг, интеграция legacy, модернизация legacy, риски бизнес-систем","meta_og_title":"Почему подрядчики не справляются с legacy — типовые ошибки рынка","meta_og_description":"Основные ошибки подрядчиков при работе с legacy-системами: причины и последствия для бизнеса. Как избежать проблем при модернизации и поддержке старых решений.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/typovye-oshibki-podryadchikov-pri-rabotye-s-legacy","seo_canonical":"https://nsign.ru/blog/typovye-oshibki-podryadchikov-pri-rabotye-s-legacy","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему подрядчики не справляются с legacy — типовые ошибки рынка\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/typovye-oshibki-podryadchikov-pri-rabotye-s-legacy\"\r\n }\r\n}","hidden":0,"createdAt":"2026-03-18 20:52:13","updatedAt":"2026-09-30 05:38:06","relatedService":null,"image":"https://n-dl.nsign.ru/repository/6b/a8/90556dd40308ac07aced118f9ca63e919d3185d7.jpg","services":[]},{"id":88,"type":"internal","newsTypeId":3,"serviceId":null,"url":"kak-my-postroili-crm-dlya-rassylok-s-nulya-chtoby-vernut-kontrol-nad-personalnymi-dannymi","name":"Как мы построили CRM для рассылок с нуля, чтобы вернуть контроль над персональными данными","annotation":"

","blog":"$63","backgroundType":null,"sizeType":1,"datePublication":"2026-05-20 00:00:00","position":38,"meta_title":"CRM для рассылок и контроль персональных данных: наш кейс","meta_description":"Как мы построили CRM для рассылок с нуля внутри защищенного контура, автоматизировали согласия, журналирование и сохранили контроль над ПДн.","meta_keywords":"CRM для рассылок, персональные данные, контроль ПДн, защищенный контур, журналирование действий, управление согласиями, заказная разработка CRM","meta_og_title":"CRM для рассылок и контроль персональных данных: наш кейс","meta_og_description":"Как мы построили CRM для рассылок с нуля внутри защищенного контура, автоматизировали согласия, журналирование и сохранили контроль над ПДн.","meta_og_type":"article","meta_og_url":"https://nsign.ru/crm-dlya-rassylok-i-kontrol-personalnyh-dannyh/","seo_canonical":"https://nsign.ru/crm-dlya-rassylok-i-kontrol-personalnyh-dannyh/","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"BlogPosting\",\r\n \"headline\": \"Как мы построили CRM для рассылок с нуля, чтобы вернуть контроль над персональными данными\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"Энсайн\"\r\n },\r\n \"mainEntityOfPage\": \"https://nsign.ru/crm-dlya-rassylok-i-kontrol-personalnyh-dannyh/\"\r\n}","hidden":0,"createdAt":"2026-05-20 08:43:11","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/93/e3/6045e27c518089c9e6d60718f657fdabe81139c7.png","services":[]},{"id":84,"type":"internal","newsTypeId":1,"serviceId":null,"url":"pochemu-vazhno-rabotat-s-ekspertami-v-oblasti-informatsionnoj-bezopasnosti","name":"Почему важно работать с экспертами в области информационной безопасности","annotation":"","blog":"$64","backgroundType":null,"sizeType":1,"datePublication":"2026-05-28 00:00:00","position":35,"meta_title":"Почему важно работать с экспертами в области информационной безопасности","meta_description":"Работать с экспертами по информационной безопасности — это стратегическое решение, которое помогает минимизировать риски и защищает бизнес от угроз.","meta_keywords":"информационная безопасность, эксперты по безопасности, защита данных, безопасность компании","meta_og_title":"Почему важно работать с экспертами в области информационной безопасности","meta_og_description":"Работать с экспертами по информационной безопасности — это стратегическое решение, которое помогает минимизировать риски и защищает бизнес от угроз.","meta_og_type":"article","meta_og_url":"https://nsign.ru/blog/pochemu-vazhno-rabotat-s-ekspertami-v-oblasti-informatsionnoj-bezopasnosti","seo_canonical":"https://nsign.ru/blog/pochemu-vazhno-rabotat-s-ekspertami-v-oblasti-informatsionnoj-bezopasnosti","seo_schemaorg":"{\r\n \"@context\": \"https://schema.org\",\r\n \"@type\": \"Article\",\r\n \"headline\": \"Почему важно работать с экспертами в области информационной безопасности\",\r\n \"author\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\"\r\n },\r\n \"publisher\": {\r\n \"@type\": \"Organization\",\r\n \"name\": \"NSIGN\",\r\n \"url\": \"https://nsign.ru\"\r\n },\r\n \"mainEntityOfPage\": {\r\n \"@type\": \"WebPage\",\r\n \"@id\": \"https://nsign.ru/blog/pochemu-vazhno-rabotat-s-ekspertami-v-oblasti-informatsionnoj-bezopasnosti\"\r\n }\r\n}","hidden":0,"createdAt":"2026-05-10 17:24:04","updatedAt":"2026-09-30 05:38:05","relatedService":null,"image":"https://n-dl.nsign.ru/repository/02/7d/33b8c3247aa0eec15362dc65ec150f0a46ce0057.jpg","services":[]}]}],"_links":{"self":{"href":"https://cp.nsign.ru/api/v1/bitrix24/blog/index/1?expand=image%2Cservices%2CrandomBlogs.services%2CrandomBlogs.image"},"first":{"href":"https://cp.nsign.ru/api/v1/bitrix24/blog/index/1?expand=image%2Cservices%2CrandomBlogs.services%2CrandomBlogs.image"},"last":{"href":"https://cp.nsign.ru/api/v1/bitrix24/blog/index/6?expand=image%2Cservices%2CrandomBlogs.services%2CrandomBlogs.image"},"next":{"href":"https://cp.nsign.ru/api/v1/bitrix24/blog/index/2?expand=image%2Cservices%2CrandomBlogs.services%2CrandomBlogs.image"}},"_meta":{"totalCount":104,"pageCount":6,"currentPage":1,"perPage":20}}

Блог

Блог

Расскажите о своем проекте

Блог

Блог

Расскажите о своем проекте

Блог

Блог

Расскажите о своем проекте