Как корпоративное приложение помогло ускорить работу 50 тысяч сотрудников

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

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

С какой проблемой обратился клиент

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

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

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

Какое решение предложили клиенту

Решение в пользу разработки мобильного приложения было обусловлено распространенностью и доступностью мобильных устройств, а также подкреплено результатами различных научных исследований. Так, по данным Digital Strategy Consulting, 60% сотрудников используют приложения для различных задач, связанных с работой.

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

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

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

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

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

Как решали задачу

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

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

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

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

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

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

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

Если с большей частью перечисленных проблем можно смириться, поскольку они сказываются лишь на времени разработки, то нестабильная работа сторонних сервисов существенно влияет на UX (User Experience — пользовательский опыт) и может вызвать недовольство будущих пользователей. Мы сообщили клиенту о сложившейся ситуации и предложили добавить фичу обратной связи, чтобы моментально реагировать на проблемы пользователей и постараться оперативно их решить. Клиент одобрил нашу идею.

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

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

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

К каким результатам пришли

Через год после выпуска корпоративного приложения уже более 70% сотрудников компании установили его на свои устройства, а 86% пользователей активно пользуется сервисами компании исключительно через него. Сотрудники отмечают скорость и простоту работы с документами, красивый интерфейс и доступ к сервисам в режиме 24/7.

После добавления возможности ведения электронного документооборота и заказа справок эффективность работы кадровых сотрудников повысилась 1,5 раза. 

Вместо вывода

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

Компаниям без сложной структуры подразделений с небольшим штатом сотрудников разработка нативного корпоративного приложения может не пригодиться. В этом случае можно обратиться к low code-платформам. Но стоит учесть, что полученное решение будет менее гибким к изменениям, так как его функциональность будет жестко ограничена возможностями платформы.

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