Веб-сервисы и интеграции
Личные кабинеты, SaaS, интеграции CRM и учётных систем, импортозамещение, работа с legacy.
70 ответов
Зачем вообще нужен личный кабинет клиенту, если есть менеджер и почта?#
Личный кабинет забирает у менеджера повторяющиеся вопросы: статус заказа, остатки, счета, акты сверки, история отгрузок. По опыту внедрений портал снимает заметную часть рутины: один человек ведёт не 30 клиентов, а 60–150 — но только там, где данные актуальны. Почта и мессенджеры этого не дают: там нет остатков и нет самообслуживания в три часа ночи. Кабинет начинает окупаться, когда у вас больше 50 постоянных клиентов и заказы повторяются.
Сколько стоит разработать личный кабинет клиента в 2026 году?#
От 400–700 тысяч рублей за кабинет с авторизацией, историей заказов и документами до 3–8 млн за портал с ролями, согласованиями, оплатой и обменом с ERP. Разброс не от жадности: до 70% бюджета уходит не на экраны, а на интеграции и на логику скидок, лимитов и отгрузок. Просите смету в разрезе интерфейс / интеграции / роли — сразу видно, за что платите и что можно отложить.
Сколько времени займёт сделать личный кабинет с нуля?#
Рабочая первая версия — 2–4 месяца, полноценный B2B-портал — 6–12. Разбивка типична: 2–4 недели на аналитику и прототип, 6–10 недель на ядро, 3–6 недель на интеграцию с учётной системой, 2–3 недели опытной эксплуатации с живыми клиентами. Дольше всего тянется не код, а согласование того, откуда брать цены, скидки и остатки. Если обещают кабинет с обменом с 1С за месяц — обмена там не будет, будет ручная выгрузка.
Чем личный кабинет отличается от B2B-портала?#
Личный кабинет — окно одного пользователя в его данные: заказы, счета, обращения. B2B-портал — рабочее место компании-контрагента: несколько сотрудников с разными правами, свои цены и скидочные матрицы, лимит дебиторки, согласование заказа внутри клиента, несколько юрлиц и точек доставки. Разница в модели прав и в глубине обмена с учётной системой, а не в дизайне. Поэтому портал обычно стоит в 2–3 раза дороже кабинета.
Личный кабинет делать на Битриксе или писать на фреймворке?#
На Битриксе — если кабинет тонкий: вход, история заказов, документы, повтор заказа из каталога. Как только появляются сложные роли, свои расчёты, десятки форм и внешние API, разработчики всё равно тащат внутрь Laravel или Symfony, и вы платите дважды. Практичный компромисс: контент и каталог остаются в CMS, кабинет живёт отдельным приложением и ходит к ней по API. Тогда обновление CMS не роняет бизнес-логику.
Можно запустить кабинет по частям или надо сразу делать всё?#
По частям — и это почти всегда правильнее. Первый релиз: вход, список заказов, статусы, документы на скачивание. Второй: оформление заказа и оплата. Третий: рекламации, сверки, аналитика. Через 8–10 недель вы увидите реальную посещаемость и поймёте, какие разделы никому не нужны — обычно это 30–40% того, что просили на старте. Обратная сторона: модель ролей и схему обмена данными надо продумать сразу, их потом не переклеишь.
Как понять, что нам нужен кабинет, а не просто форма на сайте?#
Считайте повторяющиеся обращения. Если менеджеры больше 20 раз в неделю отвечают на «где мой заказ», «пришлите счёт», «есть ли на складе» — кабинет окупится. Если клиент покупает раз в год и не помнит пароль, кабинет будет пустой: тут выигрывает страница отслеживания по номеру заказа без регистрации. Второй признак в пользу кабинета — у клиента несколько сотрудников и им нужны разные права. Форма этого не решает никогда.
Что положить в кабинет дилера в первую очередь?#
Остатки с ценой именно для этого дилера, статусы заказов, дебиторку и лимит, документы (счёт, УПД, акт сверки) и повтор прошлого заказа в один клик. Это закрывает большую часть звонков. Маркетинговые материалы, бонусные программы и обучение — во вторую очередь. Критично одно: цена и остаток берутся из учётной системы, а не из ручной выгрузки. Дилер один раз получит неверный остаток — и вернётся к менеджеру навсегда.
Правда ли, что кабинет разгружает отдел продаж, или это маркетинг подрядчиков?#
Разгружает, но не сам по себе. Цифры вроде «менеджер вёл 30 клиентов, стал вести 100» встречаются там, где есть актуальные остатки, персональные цены и документы — то есть где клиенту действительно незачем звонить. Если кабинет показывает вчерашние данные или без менеджера всё равно не оформить заказ, нагрузка не падает, а растёт: добавляются вопросы про сам кабинет. Меряйте не «сэкономленные часы», а долю заказов, оформленных без участия человека.
Как посчитать окупаемость личного кабинета до того, как закажем разработку?#
Возьмите три числа: обращений в месяц, стоимость часа менеджера, доля обращений, которые закроет самообслуживание — реалистично 40–60%. 500 обращений по 15 минут при 40% дают около 50 часов в месяц. Добавьте второй эффект: рост частоты повторных заказов на 5–15% за счёт круглосуточного оформления. При бюджете 1,5 млн окупаемость обычно выходит 12–20 месяцев. Обещания «окупится за полгода» под такой моделью не сходятся.
Сделали кабинет, а клиенты им не пользуются и всё равно звонят. Что делать?#
Сначала выясните, где они отваливаются: разложите воронку по шагам — вход, поиск товара, корзина, подтверждение. Типичные причины по частоте: неудобный вход без восстановления пароля по телефону, данные не совпадают с тем, что говорит менеджер, нет нужного документа, и просто никто не сказал клиенту, что кабинет есть. Работает жёсткая мера: часть операций перевести только в кабинет и дать менеджерам скрипт. Иначе самообслуживание застревает на 10–15%.
Кабинету нужно мобильное приложение или хватит адаптивной версии?#
Хватит адаптива в восьми случаях из десяти. Приложение оправдано, когда нужны офлайн-режим, сканер штрихкодов, push о доставке или работа на складе и в поле. Это ещё 1,5–3 млн, два стора плюс RuStore, обновления SDK и отдельный релизный цикл. Начните с адаптивного кабинета и PWA: установка на экран есть, push на Android работают, а бюджет отличается в разы. К приложению вернётесь, когда увидите долю мобильного трафика.
Хотим превратить свою внутреннюю систему в SaaS для рынка. С чего начать?#
С разделения данных и настроек по арендаторам — это единственное, что потом нельзя переделать дёшево. Дальше по порядку: тарифы и биллинг, самостоятельная регистрация, права внутри арендатора, журнал действий, выгрузка данных клиента по запросу. Внутренняя система живёт на допущении «одна компания, все свои», и снимать это допущение приходится в каждом запросе к базе. Реально это 4–9 месяцев и переписывание слоя доступа к данным, а не косметика. В ARIS такой распил внутренней системы на арендаторов занимал 5–7 месяцев.
Multi-tenant или отдельная база на каждого клиента — что выбрать?#
Общая база с колонкой tenant_id — до сотен клиентов, дешевле в обслуживании, но одна забытая проверка в запросе показывает чужие данные. Отдельная база на клиента — когда клиентов десятки, они крупные, требуют своих сроков обновления, своих копий или размещения в своём контуре. Компромисс — общее приложение и отдельная схема БД на арендатора. Помните: миграции на 300 отдельных баз становятся самостоятельной инженерной задачей с оркестрацией и откатом.
Сколько стоит запустить MVP SaaS-сервиса в России?#
1,5–5 млн рублей и 3–6 месяцев до первой платной подписки, если считать честно: продукт, регистрация, тарифы, приём платежей, поддержка. Отдельно закладывайте инфраструктуру — 30–150 тысяч в месяц на старте, эквайринг 2,5–3,5% с платежа — и юридическую часть: оферта, политика обработки персональных данных, уведомление в Роскомнадзор. Самая недооценённая статья не разработка, а первый год доработок под первых клиентов: ещё 30–50% бюджета.
Как считать себестоимость SaaS — сколько съедает инфраструктура?#
Ориентир для российского B2B SaaS — 10–25% выручки на инфраструктуру и 15–30% на поддержку и доработки. Считайте на одного арендатора: сколько он занимает в базе, сколько фоновых задач запускает, сколько трафика тянет. Тяжёлые арендаторы часто съедают маржу целиком, поэтому в тарифы закладывают лимиты: число пользователей, объём хранилища, количество вызовов API. Без счётчика ресурсов по клиенту вы знаете не свою маржу, а среднюю температуру.
Биллинг и тарифы делать сразу или можно прикрутить потом?#
Модель тарификации закладывайте сразу, сам биллинг можно позже. Разница принципиальная: если вы потом решите брать деньги за активных пользователей или за объём операций, а система эти события не считала, исторических данных не будет и перевод клиентов на новый тариф превратится в спор. Минимум на старте: счётчик событий, признак тарифа у арендатора и мягкие лимиты. Приём платежей первые месяцы можно вести счетами вручную — это нормально и экономит месяц работы.
Какие вообще есть способы связать сайт с 1С?#
Четыре рабочих. Штатный обмен CommerceML — быстро на старте, тяжело на больших каталогах. HTTP-сервисы 1С — когда нужен ответ в реальном времени: остаток, цена, статус заказа. Обмен через очередь или брокер — когда нельзя терять сообщения при недоступности 1С. Промежуточная витрина или коннектор — когда учётную систему вообще нельзя нагружать. Выбор диктуют две вещи: допустимая задержка данных и то, кто держит паузу — сайт или 1С.
Почему обмен с 1С постоянно тормозит и вешает сайт?#
Почти всегда причина одна: гоняется полная выгрузка каталога вместо изменений. На 30–50 тысячах позиций полный обмен блокирует ресурсы на десятки минут и днём мешает и сайту, и учётке. Лечение: дифференциальный обмен только по изменённым элементам, полная выгрузка раз в сутки ночью, картинки — оптимизированным обменом, отдельный пул под обмен. И жёсткий предел по времени: пакет, идущий дольше 15 минут, режется на части, а не добивает сервер. В ARIS такие обмены разводят на два контура: онлайн-запрос за остатком и ночная полная выгрузка.
Интеграция с Битрикс24 упирается в лимиты API. Что делать?#
Лимиты жёсткие и обойти их нельзя: интенсивность считается по схеме leaky bucket — на большинстве тарифов 2 запроса в секунду с накопителем на 50, на Энтерпрайзе — 5 и 250. При превышении прилетает 503 QUERY_LIMIT_EXCEEDED, на ресурсоёмких вызовах — 429 OPERATION_TIME_LIMIT: суммарное время одного метода свыше 480 секунд за 10 минут блокирует его. Лечится архитектурой: batch до 50 вызовов в одном запросе, своя очередь с ограничением скорости, повтор со случайным разбросом, кэш справочников, массовые обновления ночью порциями.
После интеграции CRM с сайтом полезли дубли клиентов. Почему так вышло?#
Потому что у систем нет общего ключа. Сайт создаёт лид по email, CRM ищет по телефону, 1С — по наименованию, и «ООО Ромашка» с «ООО «Ромашка»» становятся двумя записями. Лечится не чисткой, а правилом сопоставления: один устойчивый идентификатор (для B2B — ИНН+КПП, для B2C — телефон в формате E.164), таблица соответствия внешних ID и обновление по ключу вместо создания новой записи. Старые дубли придётся слить руками один раз.
Сколько стоит интеграция сайта с CRM и 1С?#
Типовой обмен на готовом модуле — 80–250 тысяч рублей и 2–4 недели. Нетиповая интеграция с вашими правилами цен, скидок и резервов — 400 тысяч–1,5 млн и 1,5–3 месяца. Разница в числе сущностей и направлений: односторонняя выгрузка товаров вчетверо дешевле двустороннего обмена заказами, оплатами и статусами. Плюс закладывайте 10–20% годовой стоимости на поддержку: чужие API меняются, и это не гарантийный случай, а нормальная эксплуатация.
Обмен файлами или обмен по API — правда есть разница?#
Разница в том, что происходит при сбое. Файловый обмен по расписанию молча теряет пакет: файл не выгрузился, никто не заметил, расхождение всплывает через неделю на сверке. API даёт код ответа, повтор и подтверждение. Файлы допустимы, когда данных много, а свежесть не важна — ночная выгрузка справочников. Всё, что влияет на деньги и обещания клиенту — остатки, статусы, оплаты — идёт запросами с подтверждением и алертом после трёх неудач подряд.
А если у поставщика нет API — как тогда с ним интегрироваться?#
По убыванию надёжности: выгрузка по расписанию в CSV/XML на FTP или почтой, доступ к копии базы или витрине только на чтение, роботизация интерфейса и парсинг личного кабинета. Парсинг работает, но это самый хрупкий вариант: ломается при любом редизайне, поэтому его пишут с отдельным мониторингом и ручным резервным сценарием. И сначала всегда спрашивайте прямо — у части «закрытых» систем API есть, просто про него знает только их интегратор. В ARIS на парсинговых интеграциях всегда ставят отдельный контроль свежести данных.
Законно ли парсить чужой сайт, если API нам не дают?#
Сбор общедоступных данных сам по себе не запрещён, но границы жёстче, чем кажется. Нельзя обходить техническую защиту и авторизацию, нельзя нарушать пользовательское соглашение, под которым вы подписались, нельзя выкачивать базу целиком — существенная часть базы защищена правом изготовителя (ст. 1334 ГК). Персональные данные без законного основания собирать нельзя по 152-ФЗ. Практика такая: чтение публичных страниц с разумной частотой терпимо, автоматизация чужого личного кабинета — предмет письменной договорённости.
Кто должен быть источником истины по остаткам — 1С или сайт?#
Учётная система. Для каждой сущности назначается ровно одна система-владелец, и это записывается на бумаге: остатки и цены — 1С, карточка клиента и коммуникации — CRM, корзина и поведение — сайт. Двусторонняя правка одного поля в двух системах — одна из самых частых причин инцидентов интеграции. Если сайту нужен быстрый ответ, он держит кэш остатка с меткой времени и честно показывает «данные на 10:42», а резерв подтверждает запросом в 1С.
Как разруливать конфликт, если одну запись поменяли сразу в двух системах?#
Три рабочих стратегии. Лучшая — не допускать: у поля один владелец, остальные читают. Вторая — «последняя запись побеждает» по метке времени источника; годится для комментариев, но незаметно затирает данные. Третья — журнал конфликтов и ручное разрешение: расхождение попадает в очередь ответственному, а не исчезает молча. Для денег и остатков подходит только первая. Версия записи с проверкой при обновлении спасает от гонок чаще, чем сложные алгоритмы слияния.
Что такое идемпотентность и зачем она в интеграциях?#
Идемпотентность — это когда повторный запрос не создаёт вторую сущность, а возвращает результат первого. Нужна потому, что повторы неизбежны: таймаут сети, ретрай клиента, повторная доставка из очереди, рестарт воркера между записью в базу и подтверждением. Делается просто: клиент передаёт идентификатор операции, сервер хранит его сутки-двое и на повтор отдаёт прежний ответ. Без этого один клик превращается в два заказа, а сбой сети — в двойное списание.
Вебхуки или опрос по расписанию — что надёжнее?#
Надёжнее связка: вебхук для скорости, периодическая сверка для полноты. Вебхуки теряются — сервер лежал, подпись не сошлась, обработчик упал; поэтому им нужны очередь, повторы с нарастающей паузой и случайным разбросом, предел попыток и очередь недоставленных сообщений. Опрос ничего не теряет, но даёт задержку и лишнюю нагрузку. Рабочая схема: вебхук обновляет статус за секунды, фоновая сверка раз в час-сутки догоняет расхождения. Только вебхуки — это гарантированные дыры в данных.
Что делать, когда чужой API отвечает 500 и данные теряются?#
Не терять их на своей стороне. Правильная схема: вы принимаете событие, кладёте в очередь и только потом пытаетесь отправить. Повторы — с нарастающей паузой (1, 5, 30 секунд, 5 минут), случайным разбросом и пределом попыток, дальше очередь недоставленных сообщений и уведомление человеку. Отдельно нужен предохранитель: если чужой сервис ответил ошибкой 20 раз подряд, перестаньте стучаться на 5–10 минут, иначе добьёте и его, и собственную очередь.
Как тестировать интеграцию, если у поставщика нет тестового контура?#
Поднимите заглушку у себя: запишите реальные ответы боевого API и проигрывайте их локально — это закрывает большую часть случаев. Дальше тесты на границах: пустой ответ, обрезанный JSON, HTTP 500, таймаут, дубль сообщения, другой порядок событий. На бою заведите технического контрагента — «тестового» клиента, чьи операции помечены и не попадают в отчётность. И обязательно режим сухого прогона: обмен пишет в лог, что сделал бы, ничего не меняя.
Когда пора делать шину данных вместо точечных интеграций?#
Ориентир — 5–7 систем и больше десятка связей между ними. Причина арифметическая: точечных связей растёт как n×(n−1)/2, при восьми системах это до 28 интеграций, и каждую надо мониторить и обновлять. Шина превращает их в восемь подключений к одной точке. Но до пяти систем шина чаще вредит: добавляет слой, который надо содержать, и общую точку отказа. Три системы и четыре обмена — стройте прямые связи с очередью, не выдумывайте. Считать надо не системы, а связи: в ARIS порогом для шины считают двенадцать регулярных обменов.
Шина данных — это дорого? Что реально придётся содержать?#
Дорого не лицензия, а эксплуатация. Считайте: кластер брокера, человек или роль, кто ведёт реестр сервисов и форматы сообщений, мониторинг, тестовый контур, регламент изменений. Для среднего предприятия это 150–500 тысяч в месяц сверх внедрения, а внедрение — от 3 млн и от полугода. Экономия появляется, когда подключение новой системы занимает недели вместо месяцев, то есть при постоянно растущем ландшафте. Разовая интеграция двух систем шиной не окупается никогда.
Можно обойтись без ESB — например, очередями и одним сервисом-интегратором?#
Можно, и для большинства среднего бизнеса нужно именно так. RabbitMQ или Kafka плюс свой сервис-интегратор закрывают то же самое: гарантированную доставку, повторы, порядок сообщений, единый формат. Вы теряете готовые адаптеры и визуальный конструктор маршрутов, но не платите за платформу и не нанимаете под неё людей. Переходить на полноценную шину стоит, когда интеграциями занимаются несколько команд сразу и нужен общий реестр контрактов.
Мы на SAP. Сколько реально займёт переход на 1С:ERP?#
От 6 месяцев для одного юрлица с типовыми процессами до 18–24 месяцев для холдинга. Деньги: от 5 млн на небольшом контуре и 80–120 млн на промышленном предприятии с 2000 сотрудников. Основное время съедает не установка, а перенос исторических данных, доработка отчётности и переобучение людей. Идти надо волнами по юрлицам и модулям, а не одним рубильником: параллельный период в 2–3 месяца дороже, но дешевле остановки учёта.
Меняем ядро ERP — что будет со всеми интеграциями?#
Ломается всё, что было прибито к структурам старой системы, и это до 30% бюджета миграции. Спасает промежуточный слой: сайт, кабинет и внешние сервисы обращаются не к SAP или 1С напрямую, а к вашему собственному API с устойчивыми названиями полей. Тогда при смене ядра переписывается один адаптер, а не двенадцать интеграций. Такой слой имеет смысл сделать до миграции — это дешевле, чем чинить ядро и обмены одновременно.
Обязательно ли уходить с зарубежного ПО, если мы не госкомпания?#
Юридически нет: запрет адресован госорганам и заказчикам, владеющим значимыми объектами КИИ — Указ Президента № 166 от 30.03.2022, с 1 января 2025 им запрещено использовать на таких объектах иностранное ПО. Практически решают три вещи: продлят ли лицензию, кто чинит систему при сбое и приходят ли обновления безопасности. SAP и Salesforce свернули работу с российскими клиентами ещё в 2022–2024, но внедрения продолжают работать. Опасен другой сценарий: поддержки нет, конфигурацию внутри никто не понимает, а данные вынуть можно только через ушедшего подрядчика.
Что нужно, чтобы наш сервис попал в реестр российского ПО?#
Права на софт у российского юрлица или гражданина, суммарная доля российских участников более 50%, отсутствие критичной зависимости от зарубежных компонентов, свободная реализация в РФ, документация и доступ проверяющим. Требование совместимости не менее чем с двумя доверенными ОС вводится поэтапно: с 01.09.2026 для офисного ПО и до 01.01.2028 для промышленного (ПП № 1937 от 28.11.2025). Взамен — освобождение от НДС по статье 149 НК и допуск к госзакупкам. Регламентный срок рассмотрения заявления — около 30 рабочих дней.
Уходим с Salesforce — как забрать данные и не потерять историю?#
Выгружайте не только объекты, но и связи, вложения и историю изменений: именно её теряют чаще всего. Порядок такой: полный экспорт всех объектов через API, отдельно файлы и заметки, отдельно журналы активности. Затем сопоставление полей — кастомные поля и формулы, которым в новой системе нет аналога, надо заранее разделить на «переносим» и «в архив». Старую систему держите в режиме чтения ещё 6–12 месяцев: это дешевле, чем восстанавливать историю по памяти.
Переезжаем с Битрикс24 на своё решение — что сломается?#
Сломается всё, что жило внутри портала неявно: роботы и бизнес-процессы, телефония с записями звонков, приложения из Маркета, права доступа, отчёты. Сделки, контакты и дела выгружаются через REST нормально, но упрутся в те же лимиты — 2 запроса в секунду и batch по 50, поэтому выгрузка крупного портала занимает дни, а не часы. Реалистичный план — 3–6 месяцев с параллельной работой, и заранее решите, кто будет содержать то, что раньше приходило по подписке.
Переписать старую систему с нуля или чинить существующую?#
В восьми случаях из десяти — чинить по частям. Полное переписывание означает год-полтора, когда старое не развивается, а новое ещё не работает, и вы заново реализуете логику десятилетней выдержки вместе с новыми ошибками. Переписывать разумно, когда технология не поддерживается, разработчиков не найти, а логику знает один человек. Средний рабочий путь: обвязать старую систему API, выносить по модулю и постепенно душить ядро — бизнес при этом не останавливается.
У нас всё на PHP 5.6. Насколько это страшно?#
Страшно не «старо», а «без обновлений безопасности с 2018 года». Практические последствия: хостинг рано или поздно выключит эту версию, современные библиотеки и SDK платёжных систем не поставить, разработчиков искать дольше и дороже. Порядок действий: тесты хотя бы на критичные сценарии, автоматический анализ несовместимостей (Rector, PHPCompatibility), затем переход версиями 5.6 → 7.4 → 8.x. Больнее всего даётся замена mysql_* и старых конструкций, а не новый синтаксис.
Сколько стоит поднять проект с PHP 5 до PHP 8?#
Для среднего сайта на 50–150 тысяч строк — 150–600 тысяч рублей и 3–8 недель. Там, где SQL перемешан с вёрсткой, нет ни ORM, ни тестов, счёт идёт на месяцы и может дойти до половины стоимости переписывания. Оценку даёт не глазомер, а прогон анализатора совместимости: он покажет количество проблемных мест до начала работ. Приятный побочный эффект — на реальных приложениях PHP 7 и выше работает примерно вдвое быстрее PHP 5.6.
Почему переписывания с нуля так часто проваливаются?#
Потому что в старом коде живёт бизнес-логика, которую никто не описал: три десятка частных случаев, накопленных за годы. При переписывании их находят по одному — в проде, от разъярённых пользователей. Второй фактор: пока команда пишет новое, старое всё равно надо чинить, и ресурс делится пополам. Третий: срок растягивается вдвое, терпение заканчивается, проект замораживают с двумя недоделанными системами. Отсюда правило — заменять кусками и каждый кусок довозить до прода.
Как модернизировать систему по частям и не остановить бизнес?#
Схема называется «удушение»: перед старой системой ставится маршрутизатор, часть запросов уходит в новый сервис, остальные — в старый. Начинают с изолированного куска: отчёты, уведомления, кабинет клиента, — где мало общих данных. База остаётся одна как можно дольше, иначе придётся синхронизировать две. Каждый вынесенный модуль сразу идёт в прод. Через 6–18 месяцев старое ядро становится тонким и выключается. Дороже разового переписывания на 10–20%, но без периода, когда всё лежит. В ARIS так выносили кабинеты клиентов из монолитов на PHP: сначала маршрутизатор, потом по модулю.
А когда систему лучше вообще не трогать?#
Когда она делает свою работу, редко меняется и не мешает зарабатывать. Стабильный складской модуль на старой технологии, куда правки вносят раз в год, — не техдолг, а актив. Трогать надо при других признаках: нет обновлений безопасности, невозможно поднять копию окружения, простая доработка занимает недели, знание системы держится на одном человеке. Если ничего этого нет — потратьте деньги на резервные копии и описание системы, а не на рефакторинг.
Как объяснить финдиректору, что такое техдолг, в деньгах?#
Переведите его в две метрики. Первая — стоимость изменения: сколько человеко-дней уходит на типовую доработку сейчас и сколько уходило два года назад; рост с 3 до 10 дней и есть счёт, который вы платите ежемесячно. Вторая — стоимость простоя: инцидентов в квартал, среднее время восстановления, потери за час. Дальше разговор идёт про конкретную сумму, а не про «плохой код». Обычно скрытая переплата оказывается 20–40% бюджета разработки.
Единственный разработчик, который знает нашу систему, увольняется. Что делать?#
Первым делом сделайте так, чтобы систему можно было развернуть без него: репозиторий у вас, инструкция по развёртыванию проверена на чистом сервере, резервные копии восстанавливаются, доступы к домену, хостингу и платёжкам переоформлены на компанию. Затем оплаченные две-три недели передачи дел с записью экрана и разбором прошлых инцидентов, а не с сочинением документации. Параллельно посадите рядом стороннюю команду на приёмку. Дороже удержания, но дешевле остановки.
Как не попасть в зависимость от подрядчика?#
Четыре пункта, и они работают только вместе. Код лежит в вашем репозитории с первого дня, а не выкладывается «по завершении». Домены, серверы, платёжные и почтовые аккаунты оформлены на ваше юрлицо. Стек распространённый: своя самописная CMS означает, что заменить команду будет некому. Развёртывание описано и хотя бы раз проверено силами другой команды. И пропишите переход прав прямо: по ст. 1296 ГК при заказной разработке они по умолчанию у заказчика, но если создание ПО не было предметом договора — у исполнителя (ст. 1297).
Подрядчик пропал, доступов нет. Что делать?#
Восстанавливайте контроль по порядку. Домен возвращается через регистратора по документам юрлица, если оформлен на компанию; если на физлицо подрядчика — только переговорами или через суд. Хостинг и серверы — через владельца договора и платежей. Дальше снимите полную копию сайта и базы и зафиксируйте состояние, даже если войти в админку пока не можете. Если код существует только на сервере — забирайте оттуда. Параллельно письменная претензия. Обычно на всё уходит 2–6 недель.
Что должно быть в договоре, чтобы код был действительно наш?#
Прямое условие о переходе исключительных прав с указанием момента — подписание акта этапа, а не финальная оплата. Правило «оплатили — значит наше» само по себе не работает: по ст. 1296 ГК при договоре, предметом которого была разработка, права по умолчанию у заказчика, а по ст. 1297, когда создание ПО предметом не было, — у исполнителя. Дальше: перечень передаваемых материалов (исходники, схема БД, инструкция по развёртыванию, конфигурации), список сторонних библиотек с лицензиями, срок передачи доступов и запрет встраивать закрытые компоненты исполнителя.
Фикс-прайс или почасовая оплата — что честнее для сложного проекта?#
Фикс-прайс честен там, где есть подробное ТЗ и требования не меняются, — это небольшие типовые работы. На системах с интеграциями фикс превращается в наценку за риск 30–50% и в спор о том, что входило в объём. Рабочая середина: фиксированная цена на исследование и прототип, дальше почасовая работа спринтами с потолком бюджета на квартал и правом остановиться. Демонстрация каждые две недели защищает вас лучше любой формы договора.
Как проверить подрядчика до подписания договора?#
Просите не портфолио, а доступ к двум работающим системам их производства и контакты этих заказчиков — и позвоните. Спросите, что там ломалось и как чинили: команда, которая не помнит инцидентов, скорее всего, проект не сопровождала. Смотрите, как они оценивают: честная оценка приходит с вопросами и диапазоном, а не цифрой в тот же день. Проверьте юрлицо: возраст, штат, суды. И начните с платного этапа на 2–4 недели.
Почему оценки на интеграции всегда оказываются заниженными?#
Потому что оценивают свою часть, а время съедает чужая. Реальные пожиратели: получить доступ к тестовому контуру (недели), обнаружить, что документация к API устарела, разобраться в справочниках и единицах измерения, договориться, кто владеет полем, дождаться разработчика на стороне контрагента. Здоровая практика — считать интеграцию двумя числами: работа по коду и ожидание внешних сторон, а второе закладывать в календарный срок с коэффициентом 1,5–2.
Сколько стоит поддержка системы после запуска?#
15–20% стоимости разработки в год для системы без активного развития и 30–50%, если продукт живёт и растёт. Сюда входит не только исправление ошибок: обновления библиотек и ОС, реакция на изменения чужих API, мониторинг, резервные копии и проверка их восстановления, мелкие доработки. Отдельно зафиксируйте время реакции: 4 рабочих часа на критичный сбой и 2 рабочих дня на остальное — нормальный ориентир для бизнес-систем без круглосуточной смены. В ARIS в поддержку отдельной строкой закладывают часы на изменения чужих API — они меняются ежегодно.
Обязательно ли хранить персональные данные клиентов в России?#
Да, если вы собираете данные граждан России: по части 5 статьи 18 152-ФЗ запись, систематизация, накопление, хранение, уточнение и извлечение таких данных при сборе должны идти в базах на территории РФ. Зарубежные серверы допустимы как вторичная обработка и при соблюдении правил трансграничной передачи с уведомлением Роскомнадзора до её начала. И помните: если на сайте есть хотя бы поля «имя» и «телефон», вы уже оператор персональных данных и обязаны подать уведомление по статье 22.
Какие штрафы за утечку персональных данных в 2026 году?#
За утечку юрлицу — от 3 до 15 млн рублей в зависимости от числа пострадавших субъектов, при повторной — оборотный штраф 1–3% годовой выручки в пределах 20–500 млн (ст. 13.11 КоАП в редакции 420-ФЗ). Процедурные нарушения дешевле: нет опубликованной политики обработки — 30–60 тысяч, неподанное уведомление в Роскомнадзор — 100–300 тысяч, обработка без согласия — 300–700 тысяч. Дешевле всего закрывается именно процедурная часть — уведомление, политика, формы согласия, журнал доступа: это недели работы, а не месяцы.
Нужна ли аттестация, если в кабинете только ФИО и телефон?#
Аттестация не обязательна для большинства коммерческих систем — она нужна государственным информационным системам и в отдельных регулируемых случаях. Вам нужно другое: определить уровень защищённости (для ФИО, телефона и заказов это обычно УЗ-3 или УЗ-4), выполнить меры под этот уровень, подать уведомление в Роскомнадзор, вести модель угроз и приказы. Если добавляются паспортные данные, сведения о здоровье или биометрия — требования резко ужесточаются, и это уже отдельный проект.
Облако или свой сервер для корпоративной системы?#
Облако — когда нагрузка неровная, команда маленькая и важна скорость запуска. Своё железо — когда нагрузка постоянная, требования регулятора жёсткие или объёмы такие, что аренда дороже владения. Порог обычно проходит около 300–500 тысяч рублей в месяц за облако: дальше свой кластер окупается за 1,5–2 года, но требует людей. Гибрид тоже нормален: база с персональными данными в своём контуре, вычисления и файлы — в облаке российского провайдера.
Что такое отказоустойчивость на практике и сколько она стоит?#
Начните с двух чисел: сколько система может лежать (RTO) и сколько данных допустимо потерять (RPO). Один сервер с ночной копией — простой до суток, потеря до суток, почти бесплатно. Реплика базы и второй сервер — простой 5–30 минут, потеря около минуты, плюс 60–100% к стоимости инфраструктуры. Кластер в двух зонах — минуты и почти без потерь, но это удвоение бюджета и постоянная работа. Большинству кабинетов хватает среднего варианта.
Кабинет тормозит в час пик. С чего начинать разбираться?#
С измерений, а не с покупки сервера. В большинстве случаев виноваты запросы к базе: отсутствующие индексы и проблема N+1, когда список из 100 строк порождает 100 запросов. Второй по частоте виновник — синхронные обращения к внешним API прямо при отрисовке страницы: 1С задумалась на 5 секунд, и кабинет встал вместе с ней. Порядок: профилировщик, медленные запросы, вынос внешних вызовов в фон, кэш справочников. Железо помогает последним и ненадолго.
Сколько пользователей выдержит обычный личный кабинет и когда нужен кластер?#
Один нормально настроенный сервер на 8 ядер и 16–32 ГБ спокойно держит 200–500 одновременно активных пользователей кабинета и десятки тысяч визитов в сутки. Упирается всё не в число людей, а в тяжёлые операции: выгрузка прайса, отчёт за год, обмен с учётной системой. Кластер чаще нужен не ради нагрузки, а ради обновлений без простоя. Порядок действий: кэш и фоновые задачи в отдельный процесс, потом вторая машина, и лишь потом масштабирование.
Нужны ли свои резервные копии, если хостер делает снапшоты?#
Нужны. Снапшот хостера спасает от отказа железа, но не от удаления аккаунта, ошибки в миграции, шифровальщика и не от ситуации, когда сам провайдер недоступен. Рабочий минимум: ежедневная копия базы и файлов в другое место у другого провайдера, хранение 30 дней и плановая проверка восстановления раз в квартал. Копия, из которой ни разу не разворачивали систему, копией не является — обычно выясняется, что там нет одной нужной базы.
Что такое API простыми словами и зачем он бизнесу?#
API — это оговорённый способ одной программы спросить у другой данные или попросить что-то сделать: дай остаток по артикулу, создай заказ. Бизнесу он нужен ровно для одного: чтобы данные не переносили руками. Практический признак зрелости системы — если у неё есть документированный API, её можно связать с чем угодно за недели; если нет, любое расширение упирается в выгрузки в Excel. Поэтому при выборе софта вопрос про API задают раньше вопроса про цену.
Как понять, что интеграция сломалась, раньше клиентов?#
Нужны три вещи, и они делаются за пару дней. Счётчик успешных и неуспешных обменов с оповещением в мессенджер при трёх ошибках подряд или при нуле обменов за час. Контроль свежести: если последняя успешная синхронизация старше допустимого интервала, это авария, даже когда ошибок нет. И ежедневная сверка контрольных сумм — количество заказов и сумма за вчера должны совпадать в обеих системах. Расхождение в 0,5% — уже сигнал разбираться.
Интеграция ломается примерно раз в месяц. Это нормально?#
Ненормально, если ломается молча и узнают об этом менеджеры. Само падение обмена — обычное дело: у чужой системы обновление, сменился формат, истёк токен, кончилось место. Разница между зрелой и сырой интеграцией не в числе сбоев, а в том, что происходит дальше: сообщение уходит в очередь недоставленных, приходит оповещение, после восстановления всё догоняется само. Если после каждого сбоя кто-то руками перезаливает данные — вот это и есть поломка.
Стоит ли писать свою CRM вместо Битрикс24 или amoCRM?#
Почти никогда — если вам нужна классическая CRM со сделками, задачами и телефонией: готовое решение стоит от 2 490 рублей в месяц за команду до пяти человек (Битрикс24 Базовый) или от 599 рублей за пользователя (amoCRM), а своя обойдётся в 3–10 млн и потребует постоянной команды. Своя система оправдана в другом случае: когда основной процесс не укладывается в сделки и воронки — производство под заказ, логистика, лицензирование, расчёты по договорам. Рабочий вариант: типовая CRM плюс своё приложение для вашего процесса, связанные по API.
Чем отличается доработка коробочного продукта от разработки своей системы?#
Скоростью старта и потолком. Доработка коробки даёт результат за недели, но каждая правка живёт внутри чужих правил, а обновление вендора может её сломать — поэтому серьёзные изменения выносят в отдельные модули и API. Своя система стартует за месяцы, зато потолка у неё нет и обновления вы ставите сами. Практический критерий: если ваши требования расходятся с логикой коробки больше чем на 30%, доработка выйдет дороже собственной разработки.
Нужен ли вход через Госуслуги или SSO в личный кабинет?#
Вход через Госуслуги нужен, когда требуется подтверждённая личность: финансовые сервисы, медицина, образование, услуги для граждан. Для B2B-кабинета он избыточен — там важнее корпоративный SSO, чтобы сотрудники клиента заходили под учёткой своей компании. Для остальных достаточно входа по телефону с кодом: он снимает главную причину отвала — забытый пароль. Двухфакторная авторизация обязательна там, где в кабинете видны деньги, договоры и персональные данные третьих лиц.
С чего начать, если систем много, а порядка в данных нет?#
С карты потоков данных, а не с покупки платформы. Выпишите на один лист: какие системы есть, какие сущности в каждой, кто владелец каждой сущности, как данные попадают из одной в другую и что происходит при сбое. Обычно на этом этапе обнаруживаются 3–5 обменов, про которые никто не помнит, и два владельца у одного справочника. Работа занимает 2–4 недели и экономит месяцы: половина «нужных интеграций» после неё отпадает.
Опишите задачу — ответим по существу, без презентаций и созвонов «на познакомиться». Или прикиньте бюджет сами в калькуляторе.
Задать вопросКалькулятор стоимостиЧитайте в блоге
Планируете свой маркетплейс? Рассчитайте стоимость разработки за 2 минуты — бесплатно и без регистрации.
Рассчитать стоимость маркетплейса →