Автоматизация обработки заявок в системе учета

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

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

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

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

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

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

Вся работа строится вокруг движения заявки по статусам.

Например, имеем заявку на КП (запрос КП) от внешнего контрагента. Она создается в статусе Новая. Далее менеджер принимает ее в обработку (в статусе На обработке). После этого формирует КП (статус КП сформирован) и передает клиенту (передано клиенту). Если клиент согласился с КП, то можно дальше продолжить развитие статуса Заявки в обработку заказа и т.д.

На каждом из этапов задействованные лица имеют различные возможности. Например, при статусе Передан клиенту клиент может скачать КП (или просмотреть страницу КП).

Интерфейс системы подстраивается под текущее состояние заявки для каждой роли.

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

В нашем понимании есть 2 самых удобных способа:

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

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

Именно сюда заходит пользователь для выполнения любых действий по заявке.

Что может быть размещено на карточке:

Система упрощается в плане понимания при таком подходе. Ищем карточки через таблицы и поиск, а вся работа выполняется в рамках карточки.

При создании подобной системы необходимо учитывать следующие моменты:

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

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

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

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

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

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

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

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

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

Уведомления могут приходить в виде СМС, email, в мессенджер, пуш уведомление и на сайт.

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

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

Пример создания подобного аналитического отчета.

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

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

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

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

Карточка заявки у клиента

Карточка заявки у менеджера

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

Это крайне важное свойство для любой живой системы. Если бы природа не позволяла животным изменяться, дальше амеб дело бы не пошло.

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

Подробная статья о планировании изменений в it проектах.

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

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

Платформа Falcon Space - это на 90% формы и таблицы. Все основное делается на базе этих компонентов. Остальные элементы гораздо реже используются. У этих 2 компонентов реализована максимальная гибкость по функционалу.

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

Любое отхождение от базовых правил - будущая проблема понимания как и что устроено в системе. А это время на сопровождение и возможные ошибки из-за неверных представлений о системе.

Начните с выделения основных ролей - кто будет в вашей системе иметь свой личный кабинет.

Определите центральный объект, вокруг которого будет работать система, например, Заказы.

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

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

На основе этого определите состав кабинета для каждой роли, а также их функции в системе.

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

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

Источник: