В 2023 году одна из крупных российских логистических компаний решила написать собственную PM-систему. Через 14 месяцев проект заморозили: бюджет вырос втрое, ключевой архитектор уволился, а команда вернулась на SaaS-платформу — только уже с потерянным годом и накопленным техническим долгом. Эта история типична.
По данным исследования «Базальт СПО» и CNews Analytics (2024), 35% российских компаний уже заменили вендорские SaaS-инструменты собственной разработкой. Ещё 78% планируют нарастить объём in-house разработки в 2026 году. Тренд реален — вопрос в том, сколько из этих проектов переживут второй год без кратного роста бюджета.
Решение «писать своё» почти всегда принимается на эмоциях. Зарубежный вендор ушёл с рынка. Не хватает одной критичной фичи. Команда разработки уверяет, что «сделаем за три месяца». Финансовой модели при этом нет — есть ощущение, что «своё» будет дешевле и надёжнее.
Перед нами финансово-управленческая задача с конкретными вводными: размер команды, регуляторные ограничения, уникальность процессов, горизонт планирования. Разберём её по частям — с цифрами, кейсами и чек-листом на выходе.
Почему «написать своё» стало казаться проще, чем пять лет назад
Объём российского рынка ПО достиг 808 млрд руб. в 2025 году с прогнозом до 1,71 трлн руб. к 2030 году. Рынок растёт, инфраструктура зреет, а AI-инструменты, low-code-платформы и готовые UI-компоненты действительно снизили стоимость запуска MVP по сравнению с ситуацией трёх-пятилетней давности.
Добавьте контекст импортозамещения. Доля отечественных систем управления проектами выросла с 25% в 2020 году до 73% в 2024-м, но около 28% крупных компаний до сих пор работают на иностранном ПО. Эти компании ищут замену — и часть из них приходит к выводу «сделаем сами», не потому что это рационально, а потому что не нашли подходящего российского решения с первого взгляда.
Проблема в том, что снижение стоимости MVP и снижение стоимости зрелой системы — вещи, которые не имеют между собой почти ничего общего. AI-инструменты помогут написать прототип доски с карточками за несколько дней. Они не помогут построить систему с историей задач, аналитикой загрузки, настраиваемыми ролями, интеграцией с 1С и мобильным приложением. Прототип стоит сотни тысяч рублей. Зрелая система — десятки миллионов.
Ещё одна иллюзия — что внутренняя разработка избавляет от зависимости. На практике она переносит зависимость с вендора на конкретных разработчиков внутри компании. Если ключевой инженер увольняется — система зависает. Если команда занята основным продуктом — PM-система не получает обновлений месяцами.
Из чего на самом деле складывается TCO собственной PM-системы
Большинство внутренних оценок считают только разработку. Это CAPEX — деньги, которые нужно потратить один раз, чтобы система появилась. Реальная стоимость владения на 60–70% состоит из того, что идёт после.
Команда поддержки и развития. Минимальная конфигурация для поддержки работающей системы — два-три разработчика, DevOps и тестировщик. Зарплатный фонд такой команды стартует от 500 тыс. руб. в месяц. Это 6 млн руб. в год только на людей — без инфраструктуры, без инструментов, без премий.
Безопасность и интеграции — две статьи расходов, которые чаще всего забывают при планировании. Регулярные аудиты, пентесты, реагирование на уязвимости, соответствие 152-ФЗ, а для компаний с госучастием — сертификация ФСТЭК. Каждое обновление системы потенциально открывает новые векторы атаки. Параллельно живут интеграции: типичный запрос — «нужна связка с 1С, CRM и корпоративным мессенджером». Каждая интеграция работает до тех пор, пока внешняя система не обновится. 1С выпускает обновления регулярно. После каждого — интеграция может сломаться, и проектная работа встаёт до починки.
Обучение пользователей тоже ложится на внутреннюю команду целиком. У вендорского SaaS есть база знаний, видеоуроки, служба поддержки, комьюнити. У собственной системы — нет ничего из этого. Каждый новый сотрудник требует ручного онбординга. При текучке кадров в 20–30% в год это заметная нагрузка.
Через 18–24 месяца система без регулярного рефакторинга начинает тормозить развитие — накапливается технический долг. Бизнес-процессы меняются быстрее, чем разработчики успевают адаптировать архитектуру. Кто будет переписывать? Обычно — никто. А разработчики, занятые PM-системой, не работают над основным продуктом. Если час разработчика стоит 3 000–5 000 руб., а команда тратит на внутреннюю систему 30% времени — это прямые потери выручки.
Шесть статей расходов, о которых не думают на старте.
Как отмечает команда Surf в своём анализе рынка, собственную систему имеет смысл строить только для сложных уникальных кейсов — когда готового аналога на рынке нет или когда публичное облако запрещено на уровне политики безопасности. В остальных случаях SaaS выигрывает за счёт снижения CAPEX и предсказуемого масштабирования.
Ориентировочные цифры по рынку: MVP собственной PM-системы обходится в 3–5 млн руб. Через два года, с учётом поддержки, инфраструктуры и доработок, совокупные затраты достигают 15–25 млн руб. Конкретная сумма зависит от состава команды и объёма функциональности, но порядок цифр устойчиво подтверждается практикой.
А сколько стоит SaaS — и где подвох в подписке
SaaS переводит CAPEX в OPEX. Вместо единовременных вложений — предсказуемая строка в бюджете. Рынок SaaS в России вырос на 24% до 91,1 млрд руб. в 2025 году, но темпы замедлились вдвое относительно 2023–2024 годов. Рынок зреет — и это хорошая новость для покупателя: конкуренция между вендорами растёт, качество систем повышается, а цены стабилизируются.
Реальные статьи расходов при использовании SaaS: подписка, первичное обучение команды, возможная настройка интеграций через API, миграция данных при смене вендора. Серверов нет. DevOps нет. Команды поддержки продукта нет.
Риски SaaS тоже реальны, и их стоит называть прямо. Vendor lock-in: если вендор закроется или изменит условия, смена платформы займёт время. Зависимость от roadmap: если вам нужна функция, которую вендор не планирует, — либо ждёте, либо решаете через интеграции. Ограничения кастомизации: стандартный SaaS не перепишет логику под уникальный процесс. Наконец, при масштабировании подписка дорожает линейно — компания с 200 пользователями платит в 4 раза больше, чем с 50. На определённом пороге это становится аргументом для собственной разработки, но этот порог выше, чем кажется.
Для команды 50–200 человек на горизонте трёх лет SaaS обходится в 5–15 раз дешевле собственной разработки. Разрыв объясняется просто: подписка масштабируется с бизнесом, а затраты на поддержку in-house системы растут независимо от того, используете ли вы её на 10% или на 100% мощности.
Кейс Workday: как отказ от локальных систем сократил расходы вдвое
До перехода на облачный Workday ряд крупных корпоративных клиентов платформы (финансовый сектор и ритейл, по данным кейсов Workday за 2019–2022 годы) работали на разрозненных локальных системах. Каждый отдел — своя инфраструктура, свои лицензии, свои серверы. Закрытие отчётного периода занимало неделю: данные собирались вручную, сверялись между системами, исправлялись. Менеджмент тратил значительную часть времени не на анализ, а на то, чтобы просто получить актуальную картину.
После перехода на SaaS совокупные расходы снизились примерно на 50%, а закрытие периода сократилось с недели до нескольких дней — экономия времени в отчётных процессах составила до 40%. Вопрос лицензий исчез: платформа обновляется автоматически, без участия IT-отдела. Аналитические инструменты появились из коробки, без дополнительных затрат на разработку.
Для управления проектами эффект ещё заметнее, чем в HR. Цикл обратной связи в PM короче: задача создана, выполнена, закрыта — и это происходит десятки раз в день. Каждый час задержки из-за неработающей интеграции или упавшего сервера — прямые потери скорости команды.
Менеджер проектов в компании, перешедшей на облачную платформу, перестаёт думать об инфраструктуре. Он думает о проектах.
Кейс Workday — не про HR. Он про то, что происходит, когда компания честно считает совокупную стоимость «своего» и сравнивает её с подпиской.
Когда собственная разработка действительно оправдана
Есть ситуации, когда in-house PM-система экономически и стратегически обоснована. Их меньше, чем принято думать.
Регуляторные ограничения. Госкомпании и организации с требованиями ФСТЭК или ФСБ, где данные не могут покидать собственный контур. Публичное облако запрещено на уровне политики безопасности — не как предпочтение, а как жёсткое требование. В этом случае выбор сужается: остаётся либо on-premise развёртывание российского вендора, либо собственная система. Сценарий актуален для части госкомпаний и организаций с государственным участием, но не для большинства частного бизнеса.
Уникальные бизнес-процессы, которых нет ни в одном SaaS. Речь не о «нам не хватает одной кнопки». Речь о ситуациях, когда PM-система является частью производственного цикла, а не надстройкой над ним. Оборонная промышленность с особыми требованиями к документообороту. Фармацевтика с GxP-валидацией, где система управления задачами должна соответствовать регуляторным стандартам качества. Если ни одна рыночная система не закрывает процесс даже через кастомизацию и интеграции — это аргумент для собственной разработки.
Масштаб, при котором подписка дороже разработки. При стоимости SaaS около 500 руб. на пользователя в месяц, 5 000 пользователей на горизонте пяти лет — это 150 млн руб. Сопоставимо с разработкой и поддержкой собственной системы. На таком масштабе расчёт TCO становится аргументом, а не эмоцией.
Система как конкурентное преимущество. Иногда PM-система настолько глубоко вплетена в бизнес-модель, что её архитектура сама по себе является know-how. Если способ управления проектами — это то, что отличает вас от конкурентов, а не просто внутренний инструмент, собственная разработка может быть стратегическим решением. Таких случаев единицы, но они существуют.
Во всех остальных случаях ROI не сходится на реалистичном горизонте планирования.
78% компаний хотят «своё», но большинству это не нужно
Планировать и довести до продакшена — разные вещи. Большинство in-house PM-проектов не переживают фазу MVP: бизнес-заказчик теряет интерес после первых шести месяцев без видимого результата, команда разработки переключается на другие приоритеты, и система замирает в полурабочем состоянии.
Среди разработчиков эта проблема известна как «babysitting» — внутренняя система требует постоянного внимания: следить за обновлениями зависимостей, чинить сломавшиеся интеграции, онбордить новых пользователей вручную. Команда не получает готовую систему — она получает ещё один продукт, который нужно поддерживать. При этом этот продукт не приносит выручки.
Есть и проблема стратегической десинхронизации: внутренняя PM-система часто перестаёт соответствовать реальным процессам компании уже через год после запуска, потому что бизнес изменился, а система — нет. Переписывать её некому и некогда.
Тренд на in-house — это тренд крупного бизнеса с ресурсами. Компании с выделенными командами разработки, продакт-менеджерами для внутренних инструментов и бюджетами на поддержку. Для компаний до 500 человек SaaS остаётся рациональным выбором в большинстве случаев.
Отдельная тема, которую редко обсуждают до начала разработки: что делать с данными, если собственная система не взлетела. Миграция истории задач, файлов и комментариев между PM-системами — отдельная операционная боль. Форматы экспорта у разных систем несовместимы: одни отдают JSON, другие — CSV без вложений, третьи — вообще только через API. Чем дольше команда работала в системе, тем болезненнее переезд: теряются связи между задачами, история комментариев, прикреплённые файлы. Выбирая любую систему — собственную или SaaS — стоит сразу проверить, как экспортируются данные и в каком формате.
Чек-лист для директора: 10 вопросов перед стартом внутренней разработки
Прежде чем выделять бюджет на собственную PM-систему, ответьте на эти вопросы. Если «нет» больше шести раз — разработка не оправдана.
- Есть ли у вас выделенная команда разработки (минимум три человека), которая не занята основным продуктом? Разработчики, совмещающие поддержку внутренней системы с основной работой, делают и то и другое плохо.
- Можете ли вы назвать три или более бизнес-процессов, которые не закрывает ни один SaaS на рынке? Не «нам не нравится интерфейс», а конкретные процессы с конкретными ограничениями.
- Запрещает ли политика безопасности хранение данных в публичном облаке? Не «мы предпочитаем», а документально зафиксированный запрет.
- Число пользователей PM-системы превышает 5 000 человек? Ниже этой отметки математика собственной разработки почти никогда не сходится. В зоне 1 000–5 000 пользователей нужен индивидуальный расчёт TCO — универсального ответа нет.
- Готовы ли вы закладывать в бюджет поддержки 40–60% от стоимости первоначальной разработки ежегодно? Это не пессимистичный сценарий — это норма для зрелых внутренних продуктов.
- Есть ли у вас внутренний продакт-менеджер, который будет вести roadmap PM-системы? Без выделенного владельца продукта система деградирует в течение года.
- Сколько интеграций вам нужно — и кто будет их поддерживать при обновлениях внешних систем? Каждая интеграция — это постоянная статья расходов, а не разовая задача.
- Горизонт планирования — пять лет или один год? In-house система окупается только на длинной дистанции. На горизонте одного-двух лет SaaS всегда дешевле.
- Вы протестировали хотя бы два-три российских SaaS-решения и зафиксировали конкретные ограничения? Отказ от SaaS без реального тестирования — это решение на основе предположений, а не данных.
- Что произойдёт с системой, если ключевой разработчик уволится? Если ответ «встанет» — это операционный риск, который нужно оценить до старта.
Шесть и более «нет» — SaaS закроет потребности быстрее, дешевле и с меньшим риском.
Как SaaS-платформа закрывает 90% потребностей без миллионных бюджетов
Если чек-лист показал, что собственная разработка не оправдана, следующий шаг — проверить, что именно умеют зрелые российские платформы. Конкретные функции, а не маркетинговые описания.
Два самых частых аргумента в пользу собственной разработки: «нам нужны гибкие права доступа» и «нам нужен финансовый контроль внутри PM-системы». Оба аргумента стоит проверить на практике, прежде чем открывать IDE.
В Shtab настраиваемые роли позволяют разграничить доступ до уровня отдельных пространств и проектов — кто видит пространство, кто создаёт задачи, кто редактирует шаблоны. Раздел «Финансы» позволяет контролировать бюджеты проектов прямо внутри PM-системы, без отдельного инструмента. SLA на уровне карточек закрывает контроль сроков. Всё это — функции, ради которых часть компаний начинает собственную разработку, хотя они уже доступны в готовых системах.
Отдельно стоит вопрос безопасности данных. Shtab AI поддерживает подключение к локальной модели — данные не покидают инфраструктуру компании. Это снимает основное возражение «SaaS небезопасен» для большинства сценариев, не связанных с жёсткими регуляторными требованиями.
Перед тем как принять решение о разработке, имеет смысл изучить, что уже есть на рынке. В блоге Shtab есть подробный обзор аналогов Jira — там можно сопоставить функциональность конкретных платформ с вашими требованиями.
Что выбрать — дерево решений вместо универсального ответа
(Пометка для дизайнера: визуализировать как дерево решений)
Алгоритм выглядит так.
Шаг первый: есть ли регуляторный запрет на хранение данных в публичном облаке? Если да — on-premise развёртывание российского вендора или собственная разработка.
Шаг второй: есть ли уникальные бизнес-процессы, которые не закрывает ни один SaaS даже через кастомизацию и интеграции? Если да — оцените TCO собственной разработки на три года и сравните с подпиской.
Шаг третий: число пользователей превышает 5 000 человек, и совокупная стоимость подписок на горизонте пяти лет превышает TCO разработки? Если да — собственная разработка может быть оправдана.
Все остальные случаи — SaaS.
Если дерево решений привело вас к SaaS — протестируйте два-три российских решения в реальной работе. Shtab предлагает бесплатный период, чтобы проверить, закрывает ли платформа ваши сценарии до подписания договора. Подробнее о тарифах — в документации Shtab.
Если вы путаетесь, где заканчивается CRM и начинается PM-система — это отдельная история: статья «CRM vs система управления проектами» разбирает её подробно.
Резюме: цифры, которые стоит запомнить
35% российских компаний уже перешли на собственную разработку. 78% только планируют. Разрыв между намерением и результатом огромен — и большинство из тех, кто «планирует», столкнутся с той же экономикой, которую разобрали выше.
Компании до 500 человек, которые начинают собственную разработку без прохождения чек-листа, как правило, возвращаются на SaaS через полтора-два года. Только уже с потерянным бюджетом, накопленным техническим долгом и необходимостью мигрировать данные из полурабочей системы.
Одна конкретная цифра для финального решения: если ваша команда меньше 5 000 пользователей и у вас нет регуляторного запрета на облако — каждый рубль, вложенный в собственную PM-систему, приносит в 5–15 раз меньше отдачи, чем тот же рубль в подписке. Пройдите чек-лист. Если шесть «нет» — ваш бюджет работает эффективнее в SaaS. Если вы уже выбрали платформу и хотите быстро получить отдачу — статья «12 недель до ROI: пошаговый фреймворк внедрения AI-агента» даёт конкретный план.
FAQ
Сколько времени занимает разработка собственной PM-системы до продакшен-уровня?
При выделенной команде из трёх-пяти разработчиков и чётко сформулированных требованиях — 12–18 месяцев до MVP, пригодного для ежедневной работы. Полноценная система с интеграциями, мобильным приложением и аналитикой — 2–3 года. Но есть нюанс, который часто упускают: MVP, в котором можно работать, и система, которую не стыдно показать новому сотруднику — между ними ещё год доработок. Именно на этом отрезке большинство проектов замораживают.
Можно ли начать с SaaS, а потом мигрировать на собственное решение?
Да, и это самый разумный путь — причём не только из экономии. SaaS даёт то, чего нет у ТЗ, написанного «из головы»: реальные данные о том, как команда работает. Какие поля заполняют, какие игнорируют, какие отчёты смотрят каждый день, а какие — никогда. Через полгода использования SaaS у вас будет не гипотетическое ТЗ, а спецификация, основанная на фактическом поведении пользователей. Критично: выбирайте SaaS с открытым API и возможностью экспорта данных в читаемом формате. Иначе миграция истории задач превратится в отдельный проект на несколько месяцев.
Какие российские SaaS-системы управления проектами поддерживают on-premise развёртывание?
Часть российских вендоров, включая Shtab, предлагают варианты on-premise или подключение AI к локальной модели. Это снимает вопрос безопасности данных для компаний с жёсткими требованиями — без необходимости строить систему с нуля. Перед выбором уточните у вендора два момента: частоту обновлений on-premise версии (некоторые обновляют её с задержкой в месяцы) и объём поддержки при развёртывании на вашей инфраструктуре.
Как оценить, хватит ли функциональности SaaS для нашей компании?
Составьте карту процессов и сопоставьте с функциональностью двух-трёх платформ в реальном тестировании, а не по демо-стенду. Демо всегда выглядит идеально — проблемы начинаются, когда 30 человек начинают работать одновременно. Если SaaS закрывает 80% и более процессов — оставшиеся 20% дешевле решить интеграциями или настройками через API, чем строить систему с нуля. Разрыв в 20% функциональности редко оправдывает разрыв в бюджете в 10–15 раз.