В какие мобильные приложения стоит инвестировать вендорам ECM-систем

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

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

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

От реализации самого простого функционала к нужному

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

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

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

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

От копирования десктоп-клиента до написания по гайдлайнам для конкретных устройств

Ещё одна проблема — дизайн мобильного приложения. С одной стороны, естественно желание сохранить преемственность по отношению к основному клиенту. Даже если пренебречь визуальной связью с «большим братом», то оперировать всё равно придётся теми же самыми объектами, что и на десктопе, и это неизбежно повлияет на внешний вид приложения.

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

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

От жесткой привязки к сети до обеспечения работы в оффлайне

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

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

Человеку, собирающемуся в дорогу, нужна возможность что-то отметить как «обязательно взять с собой», а что-то как «нет, это мне точно не понадобится». Для случая с нестабильной связью интерфейс следует строить так, чтобы пользователь осознавал, насколько актуальны загруженные с сервера данные и в каком состоянии сейчас объекты, с которыми он работал, например, отправился документ на сервер или всё ещё ждёт в очереди сеанса связи.

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

Не жалейте заварку: от малозатратной разработки к ориентации на потребителя

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

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

Источник: DIRECTUM