Свой портал или платформа вендора: как посчитать обе колонки на пять лет

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

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

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

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

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

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

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

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

Разработка — самая заметная величина, и она приходится на старт. За несколько лет её догоняет владение, и разложить его стоит не перечислением, а по смыслу. Сначала то, что работает без вас: серверы и администрирование, резервные копии и проверка, что из них действительно разворачивается. Затем то, что стареет само: библиотеки и зависимости обновлять придётся, даже если в продукте не изменилось ни строки, иначе через пару лет это отдельный проект. Третье — дежурство: кто и за какое время отвечает, когда кабинет не открывается в понедельник утром. И только четвёртым идёт развитие.

Развитие считают объёмом: сколько часов работы команды в месяц вы готовы оплачивать постоянно. В подписках на команду объём измеряется так — 36, 60, 120 или 220 часов в месяц. Это не цена, а мера: 36 часов закрывают мелкие правки и присмотр, 220 — поток изменений уровня выделенной группы. Портал, который никто не развивает, перестают открывать: это общее наблюдение по рынку, срока в месяцах мы не замеряли.

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

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

Интеграции считайте не системами, а потоками обмена: учётная система, из которой вы забираете данные, и она же, в которую отдаёте статусы, — два потока, и тестируются они отдельно. Масштаб виден по нашим проектам: в кейсе GrandeBoutique.ru — более 30 интеграций при каталоге свыше 35 000 позиций. Для портала потоков меньше, но каждый — отдельная работа и отдельная строка в обеих колонках.

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

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

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

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

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

Сервис собрали из двух модулей. Агент заполняет стандартизированную форму, прикрепляет документы и видит статус заявки в реальном времени. Сотрудник клиники получает её через автоматическое распределение, которое учитывает загруженность специалиста и область его экспертизы. Между ними — встроенный чат и разграничение прав. Результат в кейсе зафиксирован один, и он про скорость: срок от обращения агента до готового медицинского заключения стал короче на 60%.

Что здесь важно для расчёта. Кейс фиксирует само замещение: индивидуальное решение встало на место шаблонного сервиса зарубежного вендора, работа заняла девять месяцев. Разбора двух колонок по годам в кейсе нет, поэтому 60% мы не выдаём за доказательство экономии на лицензиях. Это доказательство другого: процесс, собранный под конкретный способ работы, даёт измеримый эффект. Вывод в кейсе сформулирован прямо: ради стабильного и масштабируемого решения необязательно идти к крупному вендору.

«Центр Сопровождения Бизнеса» ведёт бухгалтерский учёт для компаний разных форм собственности. Собственник задумался о масштабировании и начал с клиентского сервиса. Исследование показало знакомую картину: готовые инструменты либо разрознены, либо избыточно сложны — и тогда внедрение затягивается, а эффективность падает.

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

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

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

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

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

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

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

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

Собственной статистики владения по клиентам мы не приводим: таких замеров в опубликованных кейсах нет. И последнее: расчёт, где разница меньше погрешности ваших же оценок, решения не даёт. Тогда выбирайте по строке «изменения» — по тому, какой вариант позволит поменять процесс через год, когда вы поймёте, как он должен работать.

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