Cloud or your own serverОблако или свой сервер

Separate operational responsibilitiesРазделите обязанности

List application updates, server maintenance, backups, accounts, event records and employee support. Assign both a performer and someone who verifies the result. Cloud hosting commonly puts some of this work with a provider, but the exact boundary depends on the service and its agreement.Составьте список работ: обновления приложения, обслуживание сервера, резервные копии, учётные записи, журнал событий и помощь сотрудникам. Для каждой назовите исполнителя и того, кто проверяет результат. При облачном размещении часть работ обычно выполняет поставщик, но точная граница определяется услугой и соглашением.

An organization-controlled environment can be justified by a specific requirement and a team able to maintain it. Owning equipment does not replace operational coverage, spare components or recovery instructions. If everything depends on one specialist, define what happens during their absence before comparing costs.Собственная площадка оправдана, когда есть конкретное ограничение и команда способна её обслуживать. Владение оборудованием не заменяет дежурство, запасные компоненты и инструкции восстановления. Если всё зависит от одного специалиста, зафиксируйте порядок работы при его отсутствии до сравнения стоимости вариантов.

Work through a connection failureРазберите потерю связи

Distinguish an unavailable application, lost connectivity at a location and a failed employee device. These are different events with different consequences. Locally hosted software may still depend on external payment or delivery services. Cloud software may offer limited offline functions, but each action needs explicit verification.Рассмотрите отдельно недоступность приложения, пропавший интернет в точке и отказ рабочего устройства. Это разные события с разными последствиями. Система на местном сервере тоже может зависеть от внешних платежей или доставки. Облачная система может иметь ограниченные автономные функции, но их нужно подтверждать для каждого действия.

In an illustrative scenario, connectivity disappears after an employee confirms an order but before a response arrives. The employee needs to establish whether the order exists, whether retrying is appropriate and how payment can be checked. Once connected again, reconcile the outcome against the request without a hidden duplicate or an unsupported customer promise.Иллюстративный сценарий: связь исчезла после нажатия «Подтвердить заказ», а ответ не пришёл. Сотрудник должен понять, создан ли заказ, можно ли повторить действие и как проверить оплату. При восстановлении связи итог сверяется с исходным запросом, без незаметного дубля и неподтверждённого обещания клиенту.

Ask for recovery evidenceЗапросите проверку восстановления

A backup existing and a successful restoration are different facts. Clarify what is included, its coverage period, acceptable loss of recent changes and access to the restored environment. Ask how order, payment and reference-data relationships are checked after restoration, rather than merely showing that a login page loads.Наличие резервной копии и успешное восстановление — разные факты. Уточните состав копии, период охвата, допустимую потерю изменений и порядок доступа к восстановленной системе. Попросите показать, как проверяются связи между заказами, оплатами и справочниками после восстановления, а не только запуск страницы входа.

The acceptance criterion depends on the business: which unfinished operations must be located and who resolves disputed cases. Agree how normal work resumes after a temporary process. If employees kept manual records, define reconciliation, entry and closure procedures, including the reason for every correction.Критерий зависит от бизнеса: какие незавершённые операции необходимо найти и кто решает спорные случаи. Отдельно согласуйте возвращение к обычной работе после временного процесса. Если сотрудники вели записи вручную, нужен порядок их сверки, ввода и закрытия, а также сохранения причины каждой корректировки.

Verification before launchПроверка перед запуском

Examine access and exitПроверьте доступ и выход

Record required roles, access removal procedures and limits on viewing data from different locations. Have contract and security owners assess storage and processing requirements. Do not infer compliance from a server’s geography or a service’s marketing label without examining the actual terms and configuration.Запишите нужные роли, способ прекращения доступа и ограничения на просмотр данных из разных точек. Требования к месту хранения и обработке данных передайте ответственным за договор и безопасность. Не выводите соответствие требованиям из географии сервера или рекламного названия услуги без проверки конкретных условий.

For exit, ask what can be exported, when it can be obtained, how relationships are represented and what each party must do after service termination. A useful example is reconstructing a completed order from exported data. Totals alone may be insufficient for later customer inquiries and reconciliation.Для выхода запросите состав доступной выгрузки, сроки получения, формат связей и обязанности сторон после прекращения услуги. Полезный пример — восстановить историю завершённого заказа из экспортированных данных. Если выгружаются только итоговые суммы, этого может быть недостаточно для будущих обращений и сверки.

Choose a supported arrangementРешайте по подтверждённому варианту

Bring the comparison into one responsibility matrix and a set of verified scenarios. Include equipment, maintenance, connectivity, updates, recovery and training. Mark untested assumptions for both options. A requirement the provider has not confirmed remains unresolved even if similar products commonly support it.Сведите сравнение к одной таблице ответственности и набору проверенных сценариев. Учитывайте оборудование, обслуживание, связь, обновления, восстановление и обучение. Для обоих вариантов укажите непроверенные допущения. Требование, которое поставщик не подтвердил, остаётся открытым вопросом, даже если оно привычно для других продуктов.

This framework does not establish that SABSUS can run on your own server or in any cloud you choose. Confirm supported hosting, offline actions and support responsibilities for the specific offer. Begin with tolerable interruption and recovery needs rather than assuming an infrastructure arrangement is available.Этот подход не утверждает, что SABSUS предлагается на собственном сервере или в любом выбранном облаке. Допустимые варианты размещения, автономные действия и обязанности поддержки нужно согласовать для конкретного предложения. Начинайте обсуждение с допустимого простоя и процесса восстановления, а не с заранее выбранной инфраструктуры.

External dependenciesВнешние зависимости

Quick answersКороткие ответы