Менеджерам очень крупной производственной компании нужно было мобильное приложение, чтобы делать заказы. Раньше менеджер по продажам, находясь у клиента, звонил в офис, там выбежавший из цеха сотрудник что-то записывал ручкой и только к вечеру забивал заказ в ERP. Только после этого можно было выяснить, успеет заказ выполниться к сроку или нет. Плюс клиенты не могли обращаться круглосуточно и были привязаны к рабочим часам офиса – не очень удобно, если надо было просто проверить состояние склада. Решили всё это упростить и автоматизировать.

Смотрите примерно, как получилось:

Тут всё не просто сложно работает, а очень сложно. Есть промежуточный сервис, который, фактически, тянет данные из основных баз и собирает свою базу под мобильное приложение, и ещё и автоматически создаёт библиотеки под все ОС.

Сейчас расскажу, почему всё в итоге так хитро закручено и зачем каждый кусок нужен.

Веб-морда: отказ от первой версии

Есть ERP и CRM. Нужен доступ к данным по истории клиента и возможность оформлять заказ с планшета где-нибудь, где люди ходят вверх ногами. Первое логичное решение – не городить огород, а просто сделать веб-морду.

На смартфонах доступ к CRM есть. Но – куча браузеров, постоянные апдейты ОС, масса проблем с совместимостью. Когда более-менее только научились открывать нужный контент, встала в рост ещё куча проблем. Например, отсутствие уверенности в безопасности или проблема с тем, что данные не сохраняются, и связь есть далеко не всегда. Некий контент всегда должен быть на конечном устройстве.

А потом ИБ просто запретила ходить из веб-сервисов напрямую к основной базе данных.

Отсюда — решили делать мобильное приложение.

Дистрибуция приложения

Конкретно для этой производственной компании мы сделали приложение, которое со временем появится в общих маркетах и будет доступно для скачивания клиентами. А сейчас около 70 менеджеров и сотрудников технической поддержки компании уже работают с ERP и CRM прямо с мобильных устройств, причем некоторые со своих личных.

Это на практике автоматически означает введение MDM-политик (централизованного управления мобильными устройствами). Поначалу речь идёт только о корпоративном источнике приложений, возможности удалённо уничтожать корпоративные данные или отзывать сертификаты шифрования, чтобы уволенный сотрудник не унёс корпоративную информацию. Либо чтобы украденный планшет можно было быстро заблокировать.

Примерно на этой стадии приходит понимание, что нужно ограничивать работу и со штатными функциями ОС – от снятия скриншотов приложения и до работы с буфером обмена. Так, безопасники и IT-отделы постепенно «распробуют» MDM, и в итоге внедряют его полноценно. В результате все корпоративные устройства (несколько тысяч, обычно) управляются половиной админа из одного общего интерфейса. Он накатывает профили, он меняет групповые конфиги и он же прописывает политики безопасности – вплоть до вайпа на попытку джейлбрейка.

Удобно. Руководитель подразделения покупает планшет, получает ссылку, переходит по ней, подтверждает сертификат – и дальше всё ставится автоматически. Начиная от конфигурирования корпоративного VPN и заканчивая как раз нашими приложениями.

Доступ оффлайн

Для заказчика было важно хранить кэш по клиенту, его заказам и последний слепок склада по своему подразделению прямо на устройстве. Обычный сценарий такой: планшет лежит на столе в отделе и спокойно синхронизируется. В какой-то момент менеджер забирает его в Сингапур к клиенту. В Сингапуре в офисе сразу же обсуждается заказ и забивается прямо при клиенте с учётом всех деталей по его профилю и известных остатков. Никаких звонков с уточнениями, никакого ожидания подключения, всё быстро и удобно.

Ранее это делалось чуть ли не на бумаге с последующим забиванием руками в SAP вечером. Сейчас планшет ловит Wi-Fi прямо на территории заказчика (если такого вдруг нет, то где-то в районе аэропорта), открывает VPN-туннель до интранета и отправляет заказ.

Работа с заказом в SAP:

И в мобильном приложении:

Получение данных

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

Логичным шагом кажется сделать прямую связку API ERP и API CRM с приложением, чтобы оно само «выдёргивало» данные. Встаёт вопрос с кэшем, но это, в целом, тоже может решаться на стороне SAP ERP.

Проблема в том, что когда система в бэкенде одна, это легко. А когда таких систем много, то точек интеграции тоже много – и начинается рост сложности процессов. Поэтому все подобные решения, начиная с определённого масштаба, начинают использовать промежуточный сервер интеграции. Это кэш, API и другие сервисы – грубо говоря, аппаратный коннектор.

Получается так:

• Одна бэкенд-подсистема и одно приложение – прямое соединение через API.
• Несколько приложений (например, для разных ОС) – нужен некий простой промежуточный сервис с нормализованными данными, чтобы не писать коннекторы к каждому.
• Несколько бэкенд-подсистем – к каждой сервер интеграции.
• Много бэккенд-подсистем и разные приложения – проще и дешевле не ставить отдельный ПАК на каждый маршрут данных, а собрать один крупный сервис, который будет сам забирать нужные данные и готовить их под запросы.

Вот как это может выглядеть по слоям:

Общие библиотеки

Фраза про «генерация универсальных библиотек для различных платформ» — это не просто красивые слова. Это жизненная необходимость. Есть некие элементарные методы, которые нужны каждому разработчику. Например – получить зашифрованные данные. На уровне разработки приложения это решается одной функцией, которая отвечает за технический обмен. То есть разработчик не прописывает логику, а просто использует библиотечную функцию, сгенерированную специально для него. Такая же механика авторизации – вызывается всего одна функция, куда передаётся логин и пароль. Никаких сложностей с реализацией под систему, никакого копания в деталях. Ну и защита от дурака, что немаловажно.

Релеи

Ещё раз схема:

SMP — MEAP. Relay — реверсивный прокси-фильтр, который пропускает трафик внутрь и наружу, есть в любой организации. Load balancer — балансировщик нагрузки. Веб сайт – сайт компании, с которого на мобильное устройство подтягивается новостная лента.

SAP SMP в данном случае ещё выступает в роли кэша. Схема такая:

1. При обновлении данных с АРМ (например, новый заказ от менеджера) эти данные кладутся в основную базу через API ERP.
2. При обновлении данных в базе вызывает метод, обновляющий данные для MP.
3. Данные уходят в MP, где они разбираются по уже готовым таблицам в кэше так, чтобы в ответ на запрос с АРМ не собирать информацию и не бегать куда-то, а ответить готовым куском информации.

Таких таблиц на MP может быть очень много по очевидным причинам. Но при этом не все данные можно гонять через кэш. Есть особо чувствительная информация, которая не может храниться в системе. Поэтому появляется ещё один класс задач – быстро сделать выгрузку по запросу на конкретное устройство. Начинают летать 500-Мегабайтные файлы для приложения, которые должны правильно закачиваться и докачиваться. Понятное дело, логика всего этого и реализация под весь зоопарк ОС не должна лежать на разработчиках приложения. Тоже всё складывается в стандартные функции обмена информацией.

Что на что меняем

Внедрять промежуточную мобильную платформу такого плана, как описано выше, недешево. Даже не так – очень дорого. Но всё же дешевле того хаоса, который может случиться при наличии 20 серверов интеграций и попыток исполнить все требования ИБ.

Очевидных плюсов много, из которых главные, помимо перечисленных, – очень простая и быстрая разработка приложений под любые ОС. Берём перегенеренные библиотеки, подготовленные данные – и просто рисуем интерфейсы, по сути. Вторая радость в том, что при изменении ERP, для приложения ничего не меняется. Данные ходят в том же виде, потому что их готовит MP. И эта MP отвечает за работу со всеми API.

Дорогая, очевидно, поддержка этой MP – при изменении архитектуры данных нужно менять уже не одну систему, а две. Но, повторюсь, когда в бэкенде 20 систем, это всё равно дешевле, чем делать заново вообще всё.

В России под такую архитектуру, пожалуй, имеет смысл разрабатывать двум, может, трём десяткам компаний. Соответственно, куда чаще всё решается не такими сложными MP.

По вендорам — разработка идёт с использованием MEAP-платформ, например, от SAP, Oracle. Есть OpenSource, и есть одна хорошая полностью отечественная разработка. Чаще всего — SAP Mobile Platform, Oracle OMAF, IBM Worklight, Open MEAP, CDC Optimum. В связке — SAP Afaria, Mobile Iron, Citrix XenMobile.

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

Ещё опыт разработки

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

Обычный заказ может выглядеть так. Приходит страховщик, говорит, что ему нужно приложение, позволяющее контролировать работу агента. Например, если он едет снимать машину – чтобы само приложение не давало сохранить фото, если автомобиль там не целиком, не видно номер и т.п. Чтобы вместе с фото принудительно определялись координаты и прочие метаданные. Чтобы можно было при этом не беспокоиться за сохранность ПД, потерянные планшеты, уволенных сотрудников с доступами и попытки своих же сделать джейлбрейк, чтобы выдернуть через приложение всю базу.

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

Иногда всё это накатывается на специальные планшеты или устройства-кирпичи. Например, Samsung сейчас делает защищённый планшет, который можно будет ронять в сугроб с арматурой с третьего этажа, а потом съезжать на таком планшете с горки — и он при этом не согнётся. Я уверен, он будет пользоваться популярностью в нашей стране.

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

Понимаю, что такие схемы нужны только реально крупному бизнесу, и нюансов по ним много, поэтому если что, отвечу на вопросы в комментариях или по почте EvSmirnov@croc.ru.

Автор:

Источник