Когда бизнесу нужен кастомный софт, а не коробочное решение

# Когда бизнесу нужен кастомный софт, а не коробочное решение Я встречал компании, которые потратили 2 млн на SAP, потом потратили ещё 3 млн на кастомизацию. В итоге переписали то, что могли написать с нуля за 1.5 млн. В этой статье разберу 5 признаков, когда off-the-shelf ПО проигрывает кастому. И посчитаю реальные цифры TCO (total cost of ownership). ## Признак 1: Ваша бизнес-логика уникальна Off-the-shelf ПО построено на "типовой логике". Например, CRM предполагает стандартный воронку продаж: Лид → Контакт → Сделка → Заказ. Но у вас может быть: - Несколько параллельных воронок - Нестандартные этапы процесса - Условная логика (если это B2B, то другой процесс; если B2C, то третий) - Интеграция с десятком других систем **Пример:** Финтех-стартап разрабатывает кредитный процесс. Стандартный CRM имеет воронку "Лид → Заявка → Договор". Но нужна логика: - Проверка скоринга (AI) - Интеграция с банком (получить лимит) - Если лимит <50k, то одобрить автоматом - Если >50k, то повести через комитет - Интеграция с e-signature - Интеграция с биллингом (списания по графику) Готовый CRM этого не покрывает. Нужна кастомная разработка. **Когда типовое ПО работает:** Если ваш процесс совпадает с типовым в 90%+. Тогда можно использовать решение с минимальной кастомизацией. ## Признак 2: Частые изменения требований Бизнес меняется быстро. Сегодня вам нужна одна функция, завтра вам нужна вторая, через неделю третья. **Со стандартным ПО:** Каждое изменение требует подачи заявки в техподдержку, ожидание 2–4 недели, платёж за кастомизацию (10–50k за маленький чейндж). И есть риск, что система ломается после обновления. **С кастомным софтом:** Изменение добавляется в backlog, разработчик делает за несколько дней, deployит в production через CI/CD. Без координации с вендором, без ожидания. **Пример:** E-commerce платформа. Маркетинг хочет новый способ рассчитать скидку (вместо старого). На стандартной платформе это 2 недели + 30k. На кастомной — 3 дня + бесплатно. ## Признак 3: Интеграция с несколькими системами Готовое ПО интегрируется с популярными сервисами (Salesforce, 1C, Stripe). Но если ваш стек нестандартный, начинаются проблемы. **Примеры нестандартных интеграций:** - Внутренняя система расчёта (1С, Галактика, собственная разработка) - Специализированные API (например, уникальный лич сервис по логистике) - Десяток микросервисов у вас в компании - Legacy системы, которые никак не интегрируются **Со стандартным ПО:** Вы тратите огромные деньги на интеграционные решения (middleware, ETL, API gateway). И результат нестабилен. **С кастомным софтом:** Вы пишете интеграцию под вашу специфику. Нет лишних слоёв, нет переплат. **Пример:** Производственная компания. Есть MRP система (Галактика), биллинг (своя разработка), CRM (Bitrix24), складская система (своя). Нужно всё соединить в единую систему управления. Со стандартным решением: Покупаете ERP (2M за лицензию), потом платите за интеграции (3M за разработку). = 5M. С кастомным решением: Разрабатываете систему интеграции с нуля (1.5M). Получаете ровно то, что нужно. ## Признак 4: Масштабирование требует архитектурных изменений Готовое ПО проектируется для "среднего" клиента. Если вы растёте быстро (например, ваша нагрузка выросла с 100 пользователей на 10 000), система может не потянуть. **Примеры:** - Готовое решение хранит всё в одной БД (работает до 100k записей) - Вам нужна собственная система кэширования, шардирование БД, микросервисная архитектура - Стандартное ПО не может переделать архитектуру без переписки (это месяцы работы) **С кастомным софтом:** Вы с самого начала проектируете под масштабирование. Это требует больше разработки в начале, но потом масштабируется без переделок. **Пример:** Маркетплейс. Начал с 10 продавцов, каждый день растёт. Стандартная e-commerce платформа может потянуть до 1000 товаров, потом начинает лагать. Кастомное решение: Вы проектируете с самого начала под 1M товаров. Потом просто добавляете больше серверов. ## Признак 5: ROI кастомной разработки лучше чем готового решения Это ключевой знак. Если при подсчёте TCO кастомная разработка дешевле — выбирайте её. **Пример расчёта TCO:** ### Вариант 1: Готовое ПО (например, CRM) Год 1: - Лицензия: 500k - Реализация: 1M - Поддержка: 200k - Непредвиденные интеграции: 500k - Штраф за задержку из-за medislow: 0 (потеряем клиентов) **Итого год 1: 2.2M** Год 2–5 (каждый год): - Лицензия: 500k - Обновления и доп. модули: 300k - Поддержка: 200k **Итого год 2–5: 1M/год** **TCO за 5 лет: 2.2M + 4M = 6.2M** ### Вариант 2: Кастомная разработка Год 1: - Разработка: 2M - Тестирование и deployment: 300k - Первичная поддержка: 200k **Итого год 1: 2.5M** Год 2–5 (каждый год): - Поддержка и минор изменения: 300k **Итого год 2–5: 300k/год** **TCO за 5 лет: 2.5M + 1.2M = 3.7M** **Разница: 6.2M - 3.7M = 2.5M экономии за 5 лет.** ## Матрица выбора | Параметр | Типовое ПО | Кастомное | |----------|-----------|----------| | Стоимость разработки | 500k–2M | 1.5M–5M | | Скорость запуска | 2–3 месяца | 3–6 месяцев | | Стоимость лицензии/год | 200k–1M | 0 | | Гибкость в изменениях | Низко | Высоко | | Интеграции | Ограничены | Без ограничений | | Масштабирование | До определённого предела | Без ограничений | | TCO за 5 лет | 5M–10M | 2M–6M | | Сложность внедрения | Средняя | Высокая | ## Стратегия миграции: Как перейти с готового ПО на кастомное Если вы уже используете типовое решение и решили переходить на кастомное: ### Фаза 1: Подготовка (1–2 месяца) 1. Документируйте все процессы в текущей системе 2. Выведите все данные в CSV (не потеряйте историю) 3. Определите "must have" функции для новой системы 4. Спланируйте миграцию в выходной день (минимум простоя) ### Фаза 2: Разработка в параллель (2–4 месяца) 1. Разрабатываете новую систему "за спиной" 2. Параллельно тестируете на реальных сценариях 3. Обучаете пользователей на новой системе (пока используют старую) ### Фаза 3: Миграция данных (1 день) 1. Экспортируете данные из старой системы 2. Трансформируете в нужный формат (скрипт) 3. Загружаете в новую систему 4. Проверяете целостность (выборочно) ### Фаза 4: Переход (1 день) 1. Последний день работы со старой системой (в пятницу) 2. Ночью миграция данных и проверка 3. В понедельник пользователи работают в новой системе 4. В течение недели исправляются мелкие проблемы ### Фаза 5: Поддержка старой системы (1 месяц) 1. Старая система остаётся в read-only режиме 2. Если что-то потеряли в миграции — можно получить из старой 3. После 1 месяца можно выключить старую ## Выводы 5 признаков когда нужен кастомный софт: 1. Ваша бизнес-логика уникальна (не типовая) 2. Требования часто меняются (нужна гибкость) 3. Много интеграций с нестандартными системами 4. Планируете масштабироваться быстро 5. TCO кастомного решения дешевле чем готового Начните с расчёта TCO для вашего сценария. Если кастомное решение экономит 30%+ → выбирайте его. Остальное покроет гибкость и скорость развития.