Мобильное приложение для бизнеса: как проверить безопасность, поддержку и условия оплаты

Критерии выбора

1. Какие данные будет обрабатывать приложение

Первый шаг — определить, какие данные попадут в мобильное приложение. От этого зависит уровень проверки.

Типовые данные в бизнес-приложениях:

• клиентская база;

• имена, телефоны, email, адреса доставки;

• история заказов и покупок;

• платежные статусы;

• заявки и обращения;

• персональные данные сотрудников;

• графики смен и маршруты;

• складские остатки;

• документы, фото, акты, накладные;

• переписка с клиентами;

• геолокация курьеров или выездных специалистов;

• внутренние задачи и комментарии.

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

Подробнее на эту тему — Как проверить, не сломает ли обновление SaaS-сервиса текущи….

Минимальный вопрос перед выбором: что произойдет, если приложение будет недоступно 2 часа, 1 день или 3 дня? Если бизнес потеряет заказы, не сможет обслуживать клиентов или остановит сотрудников, приложение считается критичным.

2. Безопасность доступа

Для бизнес-приложения недостаточно обычного логина и пароля. Нужно проверить, как управляются пользователи и права.

Обязательные функции для большинства рабочих сценариев:

• двухфакторная аутентификация;

• роли пользователей: владелец, администратор, менеджер, курьер, оператор, бухгалтер;

• ограничение доступа по филиалам, проектам, складам или подразделениям;

• быстрый запрет доступа для уволенного сотрудника;

• журнал действий пользователей;

• история входов;

• возможность сменить пароль и завершить активные сессии;

• ограничение доступа к финансовым данным;

• отдельные права на экспорт, удаление и изменение данных.

Рискованный признак — когда все сотрудники имеют одинаковые права. Например, курьер видит всю клиентскую базу, менеджер может удалить заказы, а временный сотрудник имеет доступ к финансовым отчетам. В малой команде это может казаться удобным, но при росте до 10–20 пользователей превращается в серьезный риск.

3. Персональные данные и документы

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

Минимальный пакет:

• договор или публичная оферта;

• политика конфиденциальности;

• соглашение или раздел об обработке персональных данных;

• описание категорий данных, которые собираются;

• условия хранения и удаления данных;

• порядок передачи данных третьим лицам;

• условия использования аналитики, пуш-уведомлений, SMS и внешних интеграций;

• регламент расторжения договора;

• порядок выгрузки и удаления рабочей базы.

Смотрите не только на сам факт наличия документов, но и на конкретность формулировок. Фраза “мы принимаем все необходимые меры безопасности” не отвечает на вопросы бизнеса. Должно быть понятно:

• какие данные собираются;

• зачем они собираются;

• где они хранятся;

• кто имеет доступ;

• сколько времени данные хранятся после отключения;

• как удалить аккаунт;

• как получить выгрузку перед уходом.

Если поставщик предлагает перенести клиентскую базу, но не готов заранее показать договор и условия обработки данных, перенос лучше отложить.

4. SLA и поддержка

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

Перед выбором проверьте:

• каналы поддержки: чат, email, телефон, тикет-система, мессенджер, личный менеджер;

• часы работы: 5/2, 7/7, 24/7;

• срок первой реакции;

• срок решения критичных инцидентов;

• приоритеты заявок;

• что считается критичным сбоем;

• есть ли поддержка в выходные и праздники;

• входит ли поддержка в тариф;

• есть ли платная приоритетная поддержка;

• предусмотрены ли уведомления об авариях;

• есть ли статусная страница сервиса.

Ориентиры по срокам:

• для некритичного внутреннего приложения допустима реакция в течение 1 рабочего дня;

• для приложения, связанного с заказами, доставкой, оплатой или клиентским сервисом, желательна первая реакция в течение 1–2 часов по критичным сбоям;

• для высоконагруженных процессов стоит обсуждать отдельный SLA с доступностью 99,5–99,9% и понятной процедурой эскалации.

Стоп-фактор: поддержка существует только через форму обратной связи, сроки реакции не указаны, а менеджер отвечает “обычно быстро” без письменного регламента.

5. Условия оплаты и скрытые лимиты

Цена мобильного приложения редко равна одной строке “в месяц”. Стоимость может зависеть от десятков параметров.

Частые элементы тарификации:

• количество пользователей;

• количество устройств;

• количество филиалов;

• количество клиентов в базе;

• количество заказов, заявок или транзакций;

• объем хранилища;

• количество фото и документов;

• количество push-уведомлений;

• SMS-уведомления;

• email-рассылки;

• интеграции с CRM, ERP, складом, кассой, платежами;

• доступ к API;

• вебхуки;

• брендирование;

• публикация в App Store и Google Play;

• обучение сотрудников;

• техническая поддержка;

• перенос данных;

• доработки;

• резервное копирование;

• расширенная аналитика.

Перед оплатой нужно посчитать не только текущий месяц, но и сценарий роста на 6–12 месяцев. Например, тариф может выглядеть выгодно для 5 сотрудников, но стать дорогим при 20 пользователях, двух филиалах, API и интеграции со складом.

Что запросить у поставщика:

• расчет для текущего объема;

• расчет при росте пользователей на 2–3 раза;

• стоимость дополнительных филиалов;

• стоимость превышения хранилища;

• цену интеграций;

• стоимость API;

• условия оплаты уведомлений;

• стоимость поддержки;

• условия продления;

• условия возврата при отказе;

• минимальный срок договора.

Особенно внимательно смотрите на годовую оплату. Если поставщик требует оплатить 12 месяцев до проверки экспорта, интеграций и ролей, риск выше обычного.

6. Экспорт данных и план выхода

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

До внедрения нужно проверить:

• можно ли выгрузить все данные самостоятельно;

• какие форматы доступны: CSV, XLSX, JSON, XML;

• есть ли выгрузка через API;

• выгружаются ли вложения, фото, документы, комментарии и история;

• можно ли выгрузить данные по филиалам или периодам;

• есть ли ограничения на экспорт в тестовом тарифе;

• сколько времени хранятся данные после отключения;

• как удалить аккаунт;

• можно ли получить резервную копию перед расторжением;

• кто помогает при миграции.

Если экспорт “возможен по запросу”, уточните срок, стоимость и формат. Нормальный ответ: “выгрузка предоставляется в течение 3 рабочих дней в CSV и архиве вложений”. Рискованный ответ: “обычно решаем индивидуально”.

Для бизнеса важно не только войти в сервис, но и выйти из него без потерь.

7. Интеграции и API

Мобильное приложение редко работает изолированно. Обычно оно связано с другими системами.

Частые интеграции:

• CRM;

• интернет-магазин;

• сайт;

• складская система;

• ERP;

• бухгалтерия;

• касса;

• платежный сервис;

• телефония;

• служба доставки;

• BI-аналитика;

• корпоративный мессенджер;

• система лояльности.

Проверять нужно не наличие логотипа нужной системы на сайте, а реальные условия:

• какие данные синхронизируются;

• есть ли двусторонняя синхронизация;

• как часто обновляются данные;

• что происходит при ошибке;

• кто отвечает за сбой интеграции;

• входит ли интеграция в тариф;

• есть ли лимиты API;

• доступна ли техническая документация;

• можно ли протестировать интеграцию на демо-данных;

• есть ли журнал обмена данными.

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

8. Пилот и тестовый период

Демо-презентация не заменяет пилот. На презентации показывают лучший сценарий, а бизнесу нужно проверить реальный процесс.

Оптимальный пилот обычно занимает 7–30 дней. Для сложных решений — до 45–60 дней, если требуется интеграция и обучение сотрудников.

На пилоте стоит проверить:

• регистрацию пользователей;

• настройку ролей;

• загрузку тестовых данных;

• выполнение типовой заявки или заказа;

• работу на iOS и Android;

• работу на разных устройствах сотрудников;

• отправку push-уведомлений;

• интеграцию с CRM или складом;

• отчетность;

• экспорт;

• обращение в поддержку;

• восстановление доступа;

• отключение пользователя;

• сценарий ошибки.

Лучше заранее выбрать 3–5 ключевых сценариев. Например: “создать заказ”, “передать заказ курьеру”, “обновить статус”, “синхронизировать с CRM”, “выгрузить отчет”. Если эти сценарии не работают на пилоте, перенос рабочей базы преждевременен.

9. Права на результат при индивидуальной разработке

Если речь идет не о готовом SaaS, а о разработке мобильного приложения под бизнес, дополнительно проверяйте права.

В договоре должны быть указаны:

• кому принадлежит исходный код;

• кому принадлежит дизайн;

• кто владеет аккаунтами разработчика в App Store и Google Play;

• кто управляет сервером и облачной инфраструктурой;

• кто имеет доступ к ключам, сертификатам и репозиторию;

• передается ли техническая документация;

• как проходит приемка;

• какой гарантийный период действует после релиза;

• что считается ошибкой, а что доработкой;

• сколько стоят изменения после запуска;

• как передаются материалы при смене подрядчика.

Рискованный сценарий: приложение формально “ваше”, но код, сервер, аккаунты публикации и ключи доступа остаются у подрядчика без ясного порядка передачи. В этом случае бизнес зависит не только от продукта, но и от конкретного исполнителя.

Таблица проверки мобильного приложения

Сравнение вариантов

Готовое SaaS-приложение

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

Плюсы:

• быстрый старт;

• ниже первоначальная стоимость;

• регулярные обновления;

• готовая поддержка;

• часто есть версии для iOS и Android;

• можно протестировать до покупки;

• не нужно самостоятельно содержать инфраструктуру.

Минусы:

• ограниченная кастомизация;

• зависимость от тарифа;

• лимиты на пользователей, данные и интеграции;

• не всегда подходит для нестандартной логики;

• возможен vendor lock-in;

• важен экспорт при смене сервиса.

SaaS стоит выбирать, если бизнес-процесс можно адаптировать под готовое решение, а поставщик дает прозрачные условия по данным, поддержке и оплате.

Индивидуальная разработка

Индивидуальная разработка подходит, если приложение является частью продукта компании или должно точно соответствовать бизнес-модели.

Типовые сценарии:

• маркетплейс;

• сервис для выездных сотрудников;

• приложение для дилеров;

• B2B-портал;

• программа лояльности с нестандартной логикой;

• сложная логистика;

• клиентская экосистема;

• приложение с глубокой интеграцией в ERP или внутренние системы.

Плюсы:

• гибкая логика;

• контроль над функциями;

• индивидуальный интерфейс;

• глубокая интеграция;

• возможность владеть кодом и инфраструктурой;

• меньше зависимости от типового тарифа.

Минусы:

• выше стартовая стоимость;

• дольше сроки запуска;

• нужны техническое задание и приемка;

• требуется бюджет на поддержку;

• нужны обновления под iOS и Android;

• важно заранее закрепить права и доступы.

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

Гибридный вариант

Гибридный подход — это готовая платформа плюс настройка, интеграции, брендирование и отдельные доработки.

Плюсы:

• быстрее, чем разработка с нуля;

• дешевле, чем полностью индивидуальный продукт;

• можно закрыть часть специфических требований;

• поставщик берет на себя инфраструктуру;

• запуск возможен поэтапно.

Минусы:

• сохраняется зависимость от платформы;

• не все функции можно изменить;

• кастомные доработки могут быть дорогими;

• экспорт и права нужно проверять особенно внимательно;

• обновления платформы могут влиять на доработанную логику.

Гибридный вариант подходит, если стандартного приложения недостаточно, но разработка с нуля пока избыточна по срокам и бюджету.

Основные риски

Потеря или блокировка данных

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

Как снизить риск:

• проверить экспорт на пилоте;

• запросить форматы выгрузки;

• сохранить договор и регламент;

• сделать тестовую выгрузку до оплаты;

• уточнить срок хранения после отключения.

Простой бизнеса

Если приложение связано с заказами, доставкой, оплатой или работой сотрудников, простой даже на несколько часов может привести к потерям.

Как снизить риск:

• запросить SLA;

• проверить поддержку;

• уточнить аварийные каналы связи;

• узнать порядок восстановления;

• иметь резервный процесс на 1–2 дня.

Неожиданный рост стоимости

Низкий стартовый тариф может быть рассчитан на минимальный объем. Когда бизнес вырастет, появятся доплаты за пользователей, API, хранилище, уведомления и поддержку.

Как снизить риск:

• считать стоимость на 6–12 месяцев;

• моделировать рост в 2–3 раза;

• фиксировать тарифы письменно;

• уточнять условия продления;

• проверять платные лимиты до подписания.

Зависимость от подрядчика

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

Как снизить риск:

• прописать передачу исходного кода;

• закрепить права на дизайн;

• оформить доступы к аккаунтам публикации;

• получить техническую документацию;

• определить порядок смены подрядчика.

Слабая защита сотрудников и клиентов

Если нет ролей, 2FA и журнала действий, сложно контролировать доступ и расследовать ошибки.

Как снизить риск:

• включить 2FA;

• настроить роли;

• ограничить экспорт;

• регулярно проверять список пользователей;

• отключать неактивные аккаунты;

• использовать журнал действий.

Когда мобильное приложение не подходит

Иногда от внедрения лучше отказаться или отложить решение.

Приложение не подходит, если:

• бизнес-процесс еще не описан и постоянно меняется;

• нет ответственного за внедрение;

• сотрудники не готовы пользоваться мобильным инструментом;

• поставщик не дает тестовый доступ;

• невозможно проверить экспорт;

• нет документов по данным;

• тариф нельзя посчитать заранее;

• ключевые интеграции только “планируются”;

• требуется годовая оплата до проверки;

• нет понимания, кто будет сопровождать систему после запуска.

Также мобильное приложение может быть избыточным, если задачу закрывает адаптивный веб-сервис, личный кабинет или существующая CRM. Разработка отдельного приложения оправдана не всегда. Если пользователи заходят в систему редко, а push-уведомления, офлайн-режим и доступ к функциям смартфона не нужны, веб-решение может быть дешевле и проще.

Безопасность

• Есть двухфакторная аутентификация.

• Можно настроить роли и права пользователей.

• Есть журнал действий.

• Можно быстро отключить сотрудника.

• Доступ ограничивается по филиалам, проектам или функциям.

• Описано резервное копирование.

• Понятен порядок восстановления после сбоя.

• Поставщик объясняет, кто имеет доступ к данным.

• Данные передаются по защищенному соединению.

• Есть политика хранения и удаления данных.

Документы

• Получен договор или оферта.

• Есть политика конфиденциальности.

• Описана обработка персональных данных.

• Указаны условия хранения данных.

• Указаны условия удаления данных.

• Зафиксированы тарифы и лимиты.

• Понятны условия продления.

• Понятны условия расторжения.

• Для разработки описаны права на код, дизайн, аккаунты и документацию.

Поддержка

• Известны каналы связи.

• Понятны часы работы поддержки.

• Указан срок первой реакции.

• Есть регламент для критичных сбоев.

• Понятно, входит ли поддержка в тариф.

• Проверено тестовое обращение.

• Известно, кто отвечает за сбои интеграций.

• Есть порядок эскалации.

• Уточнена поддержка в выходные и праздники.

Оплата

• Посчитана стоимость на текущий объем.

• Посчитана стоимость при росте на 6–12 месяцев.

• Известны доплаты за пользователей.

• Известны доплаты за филиалы и устройства.

• Понятна стоимость хранилища.

• Понятна цена push и SMS-уведомлений.

• Уточнена стоимость API.

• Уточнена цена интеграций.

• Нет обязательной годовой оплаты до проверки ключевых функций.

• Сохранены тариф, счет, оферта или коммерческое предложение.

Экспорт и отказ

• Проверен экспорт на тестовом аккаунте.

• Понятны форматы выгрузки.

• Выгружаются основные таблицы.

• Выгружаются важные вложения и документы.

• Уточнена выгрузка истории и комментариев.

• Известно, сколько данные хранятся после отключения.

• Описано удаление аккаунта.

• Есть сценарий миграции к другому решению.

• Есть резервный план на случай прекращения работы сервиса.

Пилот

• Определены 3–5 ключевых сценариев.

• Пилот длится достаточно для проверки процесса: обычно 7–30 дней.

• Используются данные, похожие на реальные.

• Проверена работа на устройствах сотрудников.

• Проверены роли и права.

• Проверены уведомления.

• Проверены отчеты.

• Проверены интеграции.

• Проверено обращение в поддержку.

• Ошибки и ответы поставщика зафиксированы письменно.

Что проверить первым: безопасность, поддержку или цену?

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

Нужен ли SLA малому бизнесу?

Да, если приложение влияет на заказы, доставку, оплату, запись клиентов, склад или работу сотрудников. SLA может быть простым, но срок реакции и канал поддержки должны быть понятны до оплаты. Для критичных процессов желательно иметь реакцию по аварийным заявкам в течение 1–2 часов.

Достаточно ли бесплатной версии для проверки?

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

Какие документы запросить у поставщика?

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

Что считается стоп-фактором?

Серьезные стоп-факторы:

• нет понятного экспорта;

• нет документов по данным;

• поддержка не дает сроков реакции;

• тариф невозможно посчитать заранее;

• ключевые функции доступны только после полной или годовой оплаты;

• поставщик отказывается фиксировать условия письменно;

• нет ответа на вопрос, что происходит при отказе от сервиса;

• роли пользователей отсутствуют или слишком грубые;

• интеграции обещают, но не показывают на тесте.

Как понять, что тариф станет дорогим?

Попросите расчет для будущего сценария: больше сотрудников, больше заказов, несколько филиалов, дополнительное хранилище, API, уведомления, CRM, склад и приоритетная поддержка. Если при обычном росте цена увеличивается в 2–4 раза, это нужно учитывать до внедрения.

Когда лучше выбрать SaaS, а когда индивидуальную разработку?

SaaS подходит, если процесс типовой и важен быстрый запуск. Индивидуальная разработка нужна, если приложение является частью продукта компании, требует нестандартной логики, глубоких интеграций или особого пользовательского опыта. Гибридный вариант уместен, когда нужна скорость SaaS, но стандартных функций недостаточно.

Нужно ли проверять публикацию в App Store и Google Play?

Да, если приложение будет публиковаться как отдельный продукт. Уточните, кто владеет аккаунтами разработчика, кто готовит сборки, кто отвечает за прохождение проверки, кто выпускает обновления и кто имеет доступ к сертификатам. Это особенно важно при смене подрядчика.

Что делать, если приложение понравилось, но нет экспорта?

Не переносите рабочую базу, пока экспорт не проверен. Можно продолжить тест на демо-данных, но запуск с реальными клиентами без понятной выгрузки создает зависимость от поставщика. Минимум — получить письменное подтверждение формата, сроков и стоимости выгрузки.

Как принять окончательное решение?

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