Статья

Каким быть мобильному ПО для топ-менеджера?

Телеком Документооборот Мобильная связь Контент
мобильная версия

В условиях тотального вторжения мобильных устройств в деловую сферу при создании бизнес-приложений, ориентированных на такие гаджеты, необходимо соблюдать некоторые обязательные требования. Это возможность работы в офлайн-режиме, определенные условия к сети и пр. Каким же должно быть идеальное мобильное приложение для топ-менеджера?

Вопрос функциональности

Как уже было отмечено, существование смартфонов и планшетов накладывает определенные требования на программное обеспечение.

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

Требование офлайн-режима, конечно же, будет относиться ко всем типам устройств, так как несмотря на широкое беспроводное покрытие, связь не везде стабильна. Иногда доступа к сети может не быть вовсе. По этой причине веб-интерфейсы в качестве мобильного рабочего места не подходят. Кроме этого есть причина разработки именно нативных приложений — мобильные клиенты должны взаимодействовать с низкоуровневыми объектами системы и с аппаратной частью — это адресная книга, календарь, камера и т.д.

Следующий вопрос, с которым столкнется разработчик: какой объем функциональности бизнес-приложения должен обеспечивать мобильный клиент. Конечно же, хотелось бы реализовать доступ ко всем функциям. Но это желание невыполнимо по ряду объективных причин. Возможности бизнес-приложений и тот объем операций, которые они позволяют выполнить, существенно шире, чем у приложений для обычного потребительского рынка. К примеру, попробуйте сравнить функциональность Facebook и CRM-системы или СЭД. Если функциональность Facebook измеряется десятками операций, то возможности CRM-системы и СЭД — сотнями операций даже при стандартных настройках, без учета кастомизации решения. Кроме того, разным типам пользователей СЭД нужен разный функционал. Из этого следует простой вывод. Мобильные клиенты для бизнес-приложений должны поддерживать только сценарии работы определенных ролей пользователей. Это сделать гораздо проще.

Схема сетевой организации работы мобильного клиента

Источник: Docsvision, 2013

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

С акцентом на топ-задачи

В соответствии с этой концепцией был спроектирован продукт "Docsvision Топ-менеджер". С учетом всех заданных требований он поддерживает сценарии работы менеджеров высшего звена: руководителей предприятий или их филиалов. В нем есть все, что необходимо топ-менеджеру: создание поручений, согласование, работа с документами. Продукт разработан для наиболее популярного устройства Apple iPad. Это приложение для операционной системы iOS, которое имеет удобный, настраиваемый интерфейс.

Кроме концепции построения мобильных клиентов рассмотрим архитектуру мобильных решений в целом. Какая базовая функциональность должна присутствовать здесь и почему?

Основной вопрос — это безопасность. Мобильный клиент имеет подключение к основному бизнес-приложению. Но выставлять в открытый доступ сервер бизнес-приложения небезопасно. Широкое распространение имеет практика организации так называемых "демилитаризованных зон" (DMZ), когда часть инфраструктуры выделяется в отдельный сегмент сети, доступ из которого во внутреннюю сеть организации невозможен. Соответственно и мобильный клиент, и бизнес-приложение во внутренней сети должны сами инициировать соединение с серверной частью в DMZ. Именно такая архитектура соответствует требованиям безопасности.

В "Docsvision Топ-менеджер" это требование также выполняется. Архитектура приложения позволяет работать как при наличии доступа в интернет, так и без него. Функциональность в обоих случаях абсолютно одинакова. Серверная часть позволяет выносить некоторые сервисы в DMZ, поддерживая высокий уровень безопасности всей системы документооборота.

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

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

Михаил Захаров