Мобильные приложения для клиентов: от идеи — к продвижению

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

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

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

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

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

Поиск идеи

Что лучше — искать оригинальную идею, которая легла бы в основу приложения, внутри своей компании, или нанять «креативщиков», которые занялись бы ее изобретением, или воспроизвести нечто подобное тому, что уже кто-то сделал?

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

«Компетенция в области высокоуровневой архитектуры приложений должна быть наработана внутри организации», Максим Патрин, вице-президент Банка Москвы, возглавляющий электронный бизнес

«Все варианты хороши, лишь бы был результат: пользователь устанавливает приложение, получает ожидаемый результат и пользуется услугами организации снова и снова, — считает Иван Левченко, менеджер проекта «Мобильное приложение Superjob». — В нашем случае мобильное приложение — это продолжение функционала портала Superjob.ru в мобильном формате».

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

Павел Деверилин, директор департамента мобильных решений «SAP СНГ», также считает, что все три подхода имеют право на жизнь и что все зависит от задач и типа бизнеса: «Есть множество общих процессов, перенос которых в мобильное приложение не может существенно различаться от компании к компании. Пример — покупка билетов, здесь все уже придумано, и процесс выбора и оплаты билета существенно не изменить. В подобных случаях имеет смысл изучить все лучшее, что уже есть на рынке. Когда же речь идет о бизнесе, для которого наличие собственного мобильного приложения является в достаточной степени необычным (например, торговля обувью), конечно, стоит проявить фантазию и создать нечто уникальное силами собственного маркетинга или привлеченных экспертов».

По мнению Анны Кравцовой, ведущего специалиста по продажам мобильной платформы Worklight компании IBM в России и СНГ, выбор между поиском оригинальной идеи мобильного приложения и выявлением наиболее подходящей из тех, что уже появились на рынке, тесно связан с корпоративной культурой организации и ее стратегией в области инноваций: «Есть компании, в которых генерация новых идей — непрекращающийся процесс, но есть более консервативные компании, которым создание чего-то принципиально нового не свойственно». Кравцова считает, что следует выбирать тот подход, который будет ближе конкретной компании.

Нередко, отмечает она, хорошие идеи рождаются у рядовых сотрудников, активно пользующихся смарт­фонами и планшетами в личных целях. И в этом есть потенциал для поиска идей внутри компании. С другой стороны, многие ведущие российские интеграторы сейчас активно развивают компетенции в области создания мобильных систем. Также есть немало компаний, специализирующихся на разработке мобильных приложений. Услуги таких компаний способны помочь сэкономить время и избежать распространенных ошибок, связанных с недостатком соответствующего опыта в самой организации. Опытом и конкретными примерами реализации мобильных проектов в компаниях по всему миру могут поделиться и поставщики мобильных платформ. Таким образом, имеет смысл искать идеи по всем направлениям.

Набор функций

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

Как отмечает Максим Патрин, вице-президент Банка Москвы, возглавляющий направление «Электронный бизнес», наборы базовых бизнес-функций мобильного приложения для клиентов банков давно известны и придумать что-то принципиально новое здесь очень сложно. Среди базовых функций — просмотр счетов, управление ими (переводы между счетами, на другие счета, платежи), открытие депозитов и ряд других. «Что касается «фишечек», то их нередко заимствуют из приложений западных банков», — добавляет Патрин. По его мнению, клиентское приложение должно быть максимально «легким» и не перегружать трафиком мобильный канал связи. Также в системах дистанционного банковского обслуживания должны быть реализованы функции безопасности, причем в мобильном приложении — лишь необходимый минимум.

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

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

Деверилин рекомендует непосредственно в мобильное приложение выносить те функции, к которым пользователь будет обращаться ежедневно. Остальные сервисы могут быть представлены в серверном компоненте. Это позволит не перегружать интерфейс мобильного приложения (он должен оставаться простым, гибким и удобным), а также сохранить высокую скорость работы приложения.

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

«Мобильный клиент находится в другом ритме, быстрее принимает решения, он не готов долго ждать. Это, если хотите, немного другой человек», Иван Левченко, менеджер проекта «Мобильное приложение Superjob»

Архитектура системы

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

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

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

Ключевой вопрос при работе с внешними командами — коммуникации. «Внешние команды работают очень хорошо, профессионально, но приходится тратить очень много времени на коммуникации с ними: надо объяснить им, что мы хотим, донести до них свои идеи, помочь им разобраться в нашей специфике и пр. Внешняя команда может создать мобильное приложение качественно и быстро, но весьма высока вероятность того, что это будет не совсем то, что нам нужно», — поясняет Акулов.

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

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

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

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

Собственная разработка или индустриальный продукт?

Что лучше — разрабатывать мобильное приложение своими силами или у внешнего разработчика либо воспользоваться тиражируемым мобильным продуктом или платформой для создания мобильных приложений? Заказчики бухгалтерско-экономических программ давно ответили на этот вопрос, отдав предпочтение тиражируемым продуктам и прикладным платформам SAP, «1С», Microsoft и других вендоров. Мобильные приложения сегодня чаще создаются на заказ, тиражируемые решения и прикладные платформы используются гораздо реже.

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

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

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

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

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

«Точка принятия решений о переходе на платформу разработки мобильных решений зависит от видения компании, — поясняет Кравцова. — Компания Gartner предлагает использовать критерий «трех троек»: организации стоит переходить на использование платформы для разработки мобильных приложений, если количество приложений, число интегрируемых с ними сервисов и количество мобильных операционных систем, которые предполагается поддерживать, больше или равно трем».

Доставка приложений

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

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

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

О том, что приложение появилось, можно оповестить с помощью, например, рассылки или при обращении клиентов в отделения банка, отмечает Акулов, но, как правило, клиенты обращаются в банк не для того, чтобы установить приложение, а чтобы получить финансовые услуги (получить кредит, ипотеку, открыть депозит и пр.). PR-кампании по продвижению мобильных приложений для клиентов обеспечивают узнаваемость и быстрый охват аудитории, стимулируя массовую установку приложений, но этот канал продвижения быстро исчерпывается — по мере того как представители целевой аудитории установят у себя приложения. Преимущества прямых рассылок в том, что они дают возможность охватывать аудиторию постепенно, равномерно распределяя число скачиваний мобильного приложения.

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

Для приложений, адресованных широкому кругу клиентов, лучшим каналом доставки будут, конечно, магазины мобильных приложений Google Play, App Store и Windows App Store, уверена Кравцова: «Эти каналы привычны для пользователей, и им легче найти приложение в таких магазинах. Кроме того, к этим магазинам приложений имеется достаточно высокое доверие — это важно, если участь, что многие пользователи по умолчанию запрещают установку приложений на свои устройства откуда-либо еще». Приложение для относительно узкого круга пользователей (например, представителей корпоративных клиентов) распространять через общедоступные магазины особого смысла нет, разумнее обеспечить его скачивание с сайта организации.

«Если приложение предназначено для узкой, определенной категории клиентов (например, только для VIP-клиентов), то лучшим вариантом может оказаться прямая установка на их устройства, — считает Деверилин. — В большинстве же случаев наиболее часто рекомендуемым способом распространения является публикация в магазинах приложений — таким образом можно охватить максимально широкий круг клиентов, не тратить собственные ресурсы на установку и заодно обеспечить удобный и безопасный способ доставки приложений на клиентские устройства».

Безопасность — начиная с идеи

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

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

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

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