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

Часть текущей работы HR-направления обрабатывалась и формировалась во внутренних системах клиента, однако элементарный прием, согласование заявок и передача результатов работы отдела кадров руководству осуществлялись не самым удобным способом для всех участников процесса…

Что хотел клиент

Разработать гибкую и удобную систему приема и согласования заявок персонала в hr-службу компании со штатом более 20 000 человек.

Этапы решения

Часть 1. Подготовка:

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

В итоге мы сформировали первичный список требований к системе:

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

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

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

В ходе такой углубленной проработки было принято несколько важных решений:

• При работе должен использоваться итерационный подход, по итогам каждой итерации клиент должен получать полнофункциональную часть сервиса для возможности полноценного тестирования;
• Обмен информацией должен происходить на основании SOAP-запросов;
  
• Сотрудники офиса должны были иметь возможность авторизовываться под общекорпоративной учетной записью, а сотрудники магазинов – добавляться в систему автоматически по запросу из внутренних систем заказчика с СМС-уведомлением;
• У проекта должен быть удобный и простой интерфейс для гибкого формирования шаблонов форм и цепочек согласований для каждого конкретного заявления;
• Заявления должны генерироваться автоматически на основе данных, вводимых пользователем;
• Сотрудник должен видеть дополнительные смены для своей должности и иметь возможность откликнуться;
• Сервис должен обладать хорошей адаптацией для мобильных устройств.

По итогу всей подготовительной работы проект был разбит не несколько итераций:

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

Часть 2. Реализация базового функционала:

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

В данном этапе мы запланировали несколько работ:

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

Разработка макета

Первые работы мы начали еще на предыдущем этапе, предоставив клиенту несколько вариантов прототипов.

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

Тогда было решено поменять концепт дизайна, пока ситуация позволяла сделать это с минимальными ресурсозатратами. За основу дизайна заказчик предложил взять стилистику мобильных приложений Яндекс.Лавки и Самоката.

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

Верстка шаблона

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

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

Заготовка функциональных модулей сервиса

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

Это позволило нам создать внутренний скелет будущей системы параллельно с работами по подготовке макетов и верстке базового интерфейса.

Реализация системы доступа

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

Принимая во внимание данную особенность, мы сделали два контура авторизации:

•  Доступ для сотрудников офиса был реализован с помощью интеграции с AD-сервером заказчика;
• Учетные записи для сотрудников магазинов генерировались по входящему SOAP-запросу. После создания на телефон сотрудника автоматически отправлялась SMS со ссылкой на личный кабинет, логином и паролем. Блокировка и удаление пользователей была реализована аналогично:
• Для офисных сотрудников блокировки и удаления строились на основании интеграции с AD-сервером;
• Сотрудники магазина блокировались по соответствующему SOAP-запросу.

Реализация профиля пользователя

После того, как были созданы базовые вещи, мы занялись профилем сотрудника. В рамках данных работ мы подготовили SOAP-запрос для добавления/изменения информации о пользователе.

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

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

Часть 3. Реализация системы заявок:

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

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

Разработка внутренней бизнес-логики сервиса

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

Глобально система согласований состояла из нескольких комплексных компонентов:

•  Система управления типами заявок и справок;
• Система управления шаблонами цепочек согласований;
• Система формирования цепочки согласования по конкретной заявке;
• Система хранения заявок пользователей;
• API для передачи заявки на согласование в Битрикс24;
• API для приема информации по заявке из Битрикс24;
• Система уведомлений согласующих пользователей.

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

Подробная разработка архитектуры и парсера SOAP-запросов

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

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

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

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

Мы согласовали запросы и протестировав их со своей стороны, организовали тестирование запросов с технической группой заказчика: их разработчики насыщали запросы демо-данными и передавали их из своих внутренних систем в сервис личного кабинета сотрудника.

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

Разработка модуля управления формами заявок и цепочками согласований

Личный кабинет проектировался для того, чтобы сотрудник мог заказать любую справку или написать заявление по различным кадровым вопросам (отпуск, отгул, перевод, увольнение, повышение и т.д.).

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

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

Изначально мы планировали, что все управление системой будет происходить из стандартной административной панели 1С-Битрикс. Однако уже на этапе тестирования первых прототипов стало понятно, что для проекта заказчика это было бы неудобно.

В результате мы приняли решение добавить в систему два новых интерфейса, предназначенных для:

• управления содержимым формы заявления;
• управления цепочкой согласования для каждой формы.

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

Интерфейс управления формой заявки

В ходе проработки системы управления формами заявок было выделено несколько важных моментов:

• Многие кадровые заявления подразумевали специфические поля для ввода, нужные только для них;
• Для облегчения процесса оформления заявки необходимо максимальное предварительное заполнение поля известной информацией;
• После заполнения заявки должна генерироваться печатная форма документов, содержащая всю необходимую информацию из заявки;
• Сотрудник должен подписать и приложить к заявке подписанный скан или фото заявления, а это может занять определенное время. Значит, система должна запомнить все данные неоконченной заявки в черновик и открыть его при подгрузке скана/фотографии.

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

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

В результате прототипирования и обкатки нескольких MVP мы пришли к следующей схеме работы контент-менеджера:

• В стандартной административной панели создается заявка нового типа (например, заявка на отгул);
• docx-шаблон заявления от сотрудника размечается плейсхолдерами в тех местах, где требуется подстановка динамического контента (например, ФИО, дата и т.д.);
• В интерфейсе управления полями загружается подготовленный ранее .docx-шаблон. После этого система автоматически формирует поля будущей формы;
• Сгенерированным полям задаются подходящие названия, выбирается соответствующий им тип данных (текст, число, дата и т.д.);
• Для тех полей, информация по которым уже есть в системе, срабатывает автоподстановка;
• Настраиваются тексты для пояснения процедуры заполнения и благодарственного сообщения;
• Форма сохраняется.

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

Интерфейс управления цепочками согласований

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

При выборе конкретной заявки в правой, основной части отображались все настроенные цепочки согласований.

Редактирование и добавление новых цепочек осуществлялось здесь же. Механика была максимально простая:

• Выбирается должность, для которой будет происходить процесс согласования;
• Нажимается кнопка «+»;
• Выбирается должность первого согласующего пользователя;
• Нажимается кнопка «+»;
• Выбирается второй согласующий пользователь;
• И т.д.

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

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

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

Разработка модуля для автоматического формирования цепочек согласований

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

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

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

Мы смогли ограничиться всего двумя параметрами:

• Номером подразделения;
• Названием должности.

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

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

Нам оставалось только передать эту информацию в Битрикс24 и настроить соответствующие бизнес-процессы согласования.

Разработка бизнес-процессов согласования заявлений

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

Для упрощения системы и оптимизации стоимости работ, за основу системы согласования мы решили взять Битрикс24.

Разработка бизнес-процессов согласования была разбита на 3 логические части:

• Подготовка API для передачи информации по заявке, подписанного заявления и цепочки согласователей в Битрикс24;
• Настройка бизнес-процесса согласования в Битрикс24;
• 
  
• Подготовка API для возврата информации из Битрикс24 в личный кабинет.

Сам процесс работы с согласованием получился максимально простым и понятным:

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

В итоге, вся механика согласования была сведена к окну с информацией о заявке и двум простым кнопкам: «Согласовать» и «Отклонить».

Разработка модуля истории заявок

Сотрудник должен понимать статус по каждой своей заявке. При этом сотрудник одновременно может оставить несколько заявок по различным кадровым запросам.

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

Данный модуль давал возможность:

•  Увидеть все свои заявки;
• Фильтровать заявки по определенному признаку;
• Отозвать или повторить заявку;
• Увидеть статус согласования и комментарий согласующего пользователя.

Таким образом, сотрудник получал всю информацию по каждой из своих заявок.

Часть 4. Реализация календаря смен:

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

Для этого было решено добавить в сервис информацию о рабочем графике конкретного сотрудника.

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

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

Информация о сменах, как и все данные в этом проекте, загружалась из внутренних систем заказчика с помощью SOAP-запросов.

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

Часть 5. Реализация блока уведомлений об отпуске:

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

В целом, для решения этой задачи мы ввели несколько дополнительных блоков в интерфейсе:

• Вывели под календарем даты начала плановых отпусков;
• Там же отобразили общее количество накопленных сотрудником дней отпуска;
• Показать блок с информацией о размере отпускных на ближайший отпуск;
• Отобразить уведомление об отпуске и получить подпись сотрудника на данном документе.

Информация о сменах, как и все данные в этом проекте, загружалась из внутренних систем заказчика с помощью SOAP-запросов.

Часть 6. Пилотирование:

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

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

Для теста было выбрано порядка 40 магазинов и 400 сотрудников.

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

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

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

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

После тестовой обкатки было принято решение о переносе системы на продуктивный контур и плавное внедрение в компанию заказчика.