Разработка системы автоматизации обработки заявок

Введение

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

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

Из чего состоит система 

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

Вся система состоит из личных кабинетов.

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

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

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

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

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

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

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

Поиск объектов и списки

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

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

1. Глобальный поиск по сайту по одному полю. Обычно он находится вверху каждой страницы.  Просто набираем текст, и поиск осуществляется по всем объектам базы данных в соответствии с доступами данного пользователя. К примеру, если я модератор, то мне нужно искать только по модерируемым объектам. Если я клиент, то я буду искать по своим заявкам. 
2. Таблица заявок с гибкими фильтрами и сортировками. Этот инструмент более тонкого поиска по объектам определенного типа (например, заявки на перевозку). Подобная таблица позволяет получить сокращенный список нужных объектов. В идеале фильтры должны позволить получить нам список из 10-20 объектов максимум и с ними дальше работать. 

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

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

Карточка заявки 

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

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

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

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

1. Статус заявки - ключевое поле, определяющее состояние заявки и влияющее на интерфейс. В зависимости от статуса можно показывать различные блоки на карточке. 
2. Поля данных по карточке - это некая информация (набор полей), которую заполняют пользователи по заявке. 
3. Вывод статистики - мы можем формировать некие статистические данные по объекту и выводить их сразу на карточке. Причем для каждой отдельной роли это могут быть свои данные.  Например, это может быть количество дней в текущем статусе, маркеры проблем (например, когда описание неполное). 
4. Комментарии - удобный инструмент для фиксации истории по заявке. В комментарии можно писать как вручную, так и автоматически записывать в них важные изменения по заявке (например, смену статуса). Комментарии позволяют понять как развивался ход событий по заявке. 
5. Файлы - файлы, связанные с заявкой. 
6. Подобъекты. Например, в CRM к контрагенту может быть привязана таблица Контактов (лиц).  Это может быть и объект посложнее, например, вывод всех заказов клиента в карточке клиента. 
7. Связанные заявки - это заявки, которые по какому-то критерию связаны с текущей заявкой. Это может служить как способом навигации, так и для реализации определенной бизнес-логики (например, заявка на перевозку идет в рамках более крупной сущности, и можно выводить все такие заявки, связанные через эту сущность с нашей заявкой).
8. Управляющие действия. Это различные формы для выполнения операций с заявкой. Действия зависят от статуса и ролей пользователя. 

Разработка системы автоматизации. Что важно учесть?

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

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

Расширяемость

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

Делать лыжню для пользователей

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

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

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

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

Логирование действий

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

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

Уведомления о событиях в системе 

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

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

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

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

Аналитика во времени

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

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

Разные карточки одной заявки для ролей 

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

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

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

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

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

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

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

Что дает подобная структура системы автоматизации

Возможность расширять

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

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

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

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

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

Это легко укладывается в возможности платформы

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

Простота поддержки 

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

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

Как проработать свой вариант автоматизации обработки заявки

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

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

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

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

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

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

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

Источник: https://falconspace.ru/blog/avtomatizaciya-obrabotki-zayavok-v-sisteme-ucheta