Custom software or SaaSСвоё решение или SaaS
Custom development can be justified when a material business rule cannot reasonably be implemented in a packaged product. SaaS can fit when its supported configuration covers the required process and the team accepts its boundaries. Compare life after launch as well: changes, maintenance, data and dependence on the supplier.Разработка оправдана, когда важное правило бизнеса нельзя разумно реализовать готовым продуктом. SaaS подходит, когда поддерживаемая конфигурация закрывает нужный процесс и команда готова принять её границы. Сравнение должно охватывать жизнь решения после запуска: изменения, сопровождение, данные и зависимость от исполнителя.
Identify a genuinely distinctive ruleНайдите действительно особое правило
Separate a difference that affects outcomes from a familiar screen layout. A particular method of allocating scarce stock across orders may be essential. Button colors or status labels can often be negotiated. Every exception should have an owner, a reason and an example demonstrating why it matters.Отделите отличие, влияющее на результат, от привычного вида экрана. Например, сложный порядок распределения дефицитного товара между заказами может быть обязательным. Цвет кнопки или название статуса чаще можно согласовать иначе. Каждое исключение должно иметь владельца, причину и пример, который показывает, зачем оно нужно.
Before commissioning software, examine available configuration and possible process changes. Equally, do not dismiss a necessary control as unnecessary simply because a product lacks it. Describe the cost of compromise: likely errors, remaining manual checks and who will be able to detect them.До заказа разработки проверьте настройку готового решения и возможность изменить сам процесс. Но не называйте необходимый контроль избыточным только потому, что продукт его не поддерживает. Запишите стоимость компромисса: какие ошибки появятся, сколько ручной проверки останется и кто сможет их обнаружить.
Clarify what ownership includesУточните, что означает владение
For commissioned software, examine usage rights, source access, documentation, dependencies and the ability to move support to another developer. Agree these terms in the contract. Paying for development does not by itself establish that the business receives everything necessary to maintain and extend the system independently.В заказной разработке разберите права использования, доступ к исходному коду, документацию, зависимости и возможность передать поддержку другому исполнителю. Эти условия нужно согласовать в договоре. Оплата разработки сама по себе не доказывает, что бизнес получит всё необходимое для самостоятельного сопровождения и дальнейшего развития системы.
For SaaS, establish who controls configuration, what can be exported and which changes do not require the supplier. Access to business data is different from the right to move the entire product. Compare an actual exit task instead of grouping code, data, branding and infrastructure under one vague idea of ownership.В SaaS выясните, кто управляет настройками, что можно выгрузить и какие изменения доступны без участия поставщика. Право получить данные не равно праву перенести весь продукт. Сравните эти различия на конкретной задаче выхода, а не объединяйте код, данные, бренд и инфраструктуру словом «собственность».
Count work after launchПосчитайте работу после запуска
For custom software, include analysis, implementation, testing, releases, failure monitoring and subsequent changes. For SaaS, include configuration, subscription, training, limitations and integration maintenance. Both approaches need someone who understands the process and accepts the result. Having no in-house developers does not remove that responsibility.Для разработки включите анализ, реализацию, проверку, выпуск, наблюдение за сбоями и последующие изменения. Для SaaS включите настройку, подписку, обучение, ограничения и поддержку интеграций. Обеим сторонам нужен человек, который понимает процесс и принимает результат. Отсутствие программистов в штате не устраняет эту ответственность.
Compare an equivalent scope over the same expected period of use. List uncertain expenses and review triggers separately: a new sales channel, changes in an external service or a key specialist leaving. A one-off quote excluding maintenance and a subscription excluding transition costs describe different workloads.Сравнение полезно вести при одинаковом объёме и сроке использования. Отдельно запишите неопределённые расходы и события пересмотра: новый канал продаж, изменение внешнего сервиса или уход ключевого специалиста. Разовая смета без сопровождения и подписка без стоимости перехода описывают разные объёмы работы.
Test a disputed scenarioПроверьте спорный сценарий
Consider an order partly fulfilled: the customer changes the remaining items while the first portion has already been paid. Define allowed actions, the remaining balance and change history in advance. Ask a packaged-product supplier to demonstrate the supported process; include the same example in agreed acceptance criteria for custom development.Представьте заказ с частично выполненными позициями: клиент меняет оставшуюся часть, а первая уже оплачена. Заранее опишите допустимые действия, расчёт остатка и историю изменения. Для готового продукта попросите показать поддерживаемый процесс; для разработки включите тот же пример в согласованный критерий приёмки.
Retain initial data, final records and explanations of limitations. A manual outcome may be acceptable when its workload and owner are known. Include reversal, incorrect input and staff departure in the checks so the resulting system does not depend on its original configurator remembering how it works.Сохраните исходные данные, итоговые записи и объяснение каждого ограничения. Если результат достигается вручную, это допустимый вариант только при известной нагрузке и ответственном. Проверка должна также включать отмену изменения, ошибочный ввод и уход сотрудника, чтобы новая система не зависела от памяти автора настройки.
Bound the development scopeОграничьте объём разработки
A mixed approach may be sensible: retain the standard process in a packaged system and implement a distinctive rule separately. The connection still needs its own specification and maintenance. Choose this approach only after verifying that the external component can appropriately read required data and return a usable result.Смешанный путь может быть разумным: стандартный процесс оставить в готовой системе, а особое правило реализовать отдельно. При этом связь между частями требует собственного описания и поддержки. Такой выбор оправдан только после проверки, что внешняя часть действительно может безопасно читать нужные данные и возвращать результат.
When discussing SABSUS, distinguish verified standard actions, required configuration and unresolved extension requirements. A possible future enhancement is not an available feature. Base the purchase or development decision on agreed scope, maintenance ownership and evidence from the difficult business scenario.При обсуждении SABSUS перечислите подтверждённые стандартные действия, необходимые настройки и открытые требования к расширению. Не считайте будущую доработку доступной функцией. Решение о покупке или разработке должно опираться на согласованный объём, ответственных за сопровождение и доказательство результата по сложному сценарию.
Quick answersКороткие ответы
When does custom development fail to solve the problem?Когда разработка не решает проблему?
When rules, data authority and outcome ownership are undefined. Code can preserve the same uncertainty.Когда не определены правила, источник данных и владелец результата. Код может закрепить ту же неопределённость.
Can a business start with SaaS and extend it later?Можно ли начать с SaaS, а позже расширить решение?
Yes, when the actual product’s data access, integration interfaces and extension terms have been verified.Да, если заранее проверены доступные данные, интерфейсы обмена и условия расширения конкретного продукта.
Should launch speed determine the choice?Нужно ли выбирать только по сроку запуска?
No. Consider future changes, support, limitations and the cost of handing the system to another team.Нет. Учтите будущие изменения, поддержку, ограничения и стоимость передачи решения другой команде.