HubEx FSM

HubEx FSM – это специализированная ERP система класса FSM (Field Service Management) предназначенная для организации работы сервисных подразделений с мобильным персоналом, от ремонтов и технического обслуживания, до обходов и клинига.

Для удобства получения информации о возможностях HubEx мы разработали HubEx AI бота в Телеграм, который ответит на большинство вопросов по возможностям и функциям системы: @HubexWikiBot

Чем HubEx отличается от Help Desk, Service Desk, ESM, ITSM, CRM, ТОиР и SCADA/IoT систем

Ключевое отличие HubEx от систем работы с заявками, ТОиР, ITSM, отраслевых CRM и других систем, позволяющих работать с клиентскими обращениями и заявкам - это мощное развитое мобильное приложение с конфигуратором позволяющем без разработки и выпуска новых версий гибко организовать процесс работы мобильного персонала “в полях” из смартфона. Другие отличия, от систем различных классов перечислены ниже.

Отличие HubEx от Help Desk / Service Desk, ESM, ITSM систем 

HubEx FSM имеет следующий базовый функционал присущий системам данного класса: работа с заявками, база данных активов и обслуживаемых объектов, база знаний, шаблоны ответов, расчет SLA, омниканальность получения заявок, автоматизация обработки обращений, конструктор бизнес-процесса прохождения заявки, уведомления и триггеры, чек-листы, API для интеграций и ряд другого функционала, с полным перечнем которого лучше всего ознакомиться на сайте: HubEx.ru, либо спросить информацию у HubEx WIKI бота @HubexWikiBot

В отличии от классических Help Desk/ITSM систем, работа в HubEx не выстроена в соответствии ITIL процессами. В частности в HubEx нет классической ITIL CMDB, не реализовано процессов управления релизами, Change management процесса, Problem management процесс настраивается вручную с рядом ограничений, нет ITIL управления конфигурациями.

Но зато за счет отсутствия ограничений накладываемых ITIL практикой, в HubEx реализована удобная и гибкая работа с заявками и клиентскими обращениями от омниканального приема заявок до выстраивания автоматизированных процессов их выполнения не только офисными, но и мобильными сотрудниками, и не только в режиме получено/выполнено, как это обычно реализуется в мобильных приложениях ITIL или CRM систем, но и с детальным проработанным процессом контроля работы для мобильного персонала, от получения информации по объекту обслуживания / заказчике работ, до контроля работы персонала через чек-листы, ГЕО-позиционирование, электронное заполнение актов, доступ к складам и материалам, получения электронной подписи заказчика работ и отчетности перед офисом. Таким образом HubEx FSM функционально ближе к системам ESM класса  с тем отличием, что работа не выстроена в соответствии с ITIL практиками, зато более приспособлена к работе сервисных не-IT подразделений.

Отличие HubEx от CRM

Основное отличие HubEx от CRM-системы заключается в том, что CRM система организует процесс заключения сделки с клиентом ОТ  момента появления лида ДО момента закрытия сделки (заключения контракта). В свою очередь HubEx организует уже процесс выполнения работ С момента формирования заявки на работу ДО ее выполнения, контроля качества и отчетности сотрудника перед “офисом”. Из этого следуют и отличия систем: в HubExе нет классической воронки продажи с лидами и сделаками, а в CRM-системе нет полноценной работы с заявками. При этом обе системы хранят данные о клиентах и контактных лицах. Упрощенную воронку можно организовать созданием отдельного типа заявки с необходимыми стадиями в HubEx, а в свою очередь в CRM можно создать упрощенную задачу со стадиями новая/выполнена. CRM не позволит выстроить эффективный автоматизированный процесс работы персонала по заявкам и контролировать процесс работы мобильного персонала. Кроме отсутствия в CRM-системах классического функционала работы с заявками, в ней нет базы обслуживаемого оборудования, урезан или вовсе отсутствует функционал базы знаний, нет механик расчетов уровня сервиса / SLA, не настраивается древовидная логика прохождения заявки по стадиям, нет графиков работы объектов обслуживания и расписаний работы сотрудников, планировщика работ, функционала GPS-контроля местонахождения персонала, мобильное приложение не имеет функций организации работы мобильных сотрудников, нет электронных актов в мобильном приложении с возможностью привязки затраченных на выполнение работ материалов и запчастей, нет чек-листов, мобильное приложение не работает offline и гибко не настраивается из конфигуратора без разработки.

Отличие HubEx от системы класса ТОиР

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

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

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

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

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

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

Отличие HubEx от система класса SCADA и IoT 

Чаще всего HubEx FSM является инструментом работы с заявками, которые формируются из SCADA и IoT систем на сервисный персонал. SCADA и IoT системы формируют сигналы / данные с контроллеров оборудования и датчиков, агрегирует сигналы в события 2го уровня требующие реакции персонала и уже такие события поступают на вход HubEx, как заявки требующие реакции персонала. Так что HubEx FSM это оперативный слой работы с задачами поступающими на сервисный персонал от систем класса IoT и SCADA. 

Платформа HubEx

Краткая справка о платформе HubEx

HubEx – Отечественное решение класса FSM (Field Service Management) включенное в реестре российского ПО от 15.07.2020. Рег. номер ПО №6816 и предназначенное для организации работы сервисных подразделений с мобильным персоналом, от ремонтов и технического обслуживания, до обходов и клинига. HubEx FSM может использоваться, как отдельно-стоящая IT-система, так и как компонент группы интегрированных IT-решений. Одним из основных компонентов HubEx является мощное мобильное приложение для полевого персонала для iOS и Android, а так же приложения для Заказчиков работ. Данные приложения можно использовать как отдельно от системы, так и как компонент HubEx решения развернутого в компании. Если приложение используется отдельно, то оно подключается к внутренней IT-системе компании классов HelpDesk/ServiceDesk/ТОиР и др. через API, откуда в приложение передаются заявки на исполнение и другая информация. Если HubEx внедряется целиком, то приложение используется как внутренняя подсистема платформы HubEx.

Компоненты платформы HubEx

МОБИЛЬНОЕ ПРИЛОЖЕНИЕ

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

Мобильное приложение поставляется совместно с интерфейсом административной настройки, back-end сервисами и системой логирования позволяющими без разработки настроить систему на указанный в функциональных требованиях процесс и эффективно поддерживать ее работу. Система разворачивается на серверах клиента, а приложение устанавливается на устройства Android через APK-файлы, систему управления мобильными устройствами Заказчика класса Mobile Device Management или из публичных магазинов приложений приложений.

Приложение интегрируется через открытый API с информационными системами Заказчика в том числе системами класса ТОиР, что позволит выстроить бесшовный сервисный процесс обходов и ремонтов автоматизировав работу мобильного персонала. Приложение можно установить на Android и Apple смартфоны, а так же специализированные Андроид терминалы совместимые с версией ОС Android 6.0 и выше.

Для простоты интеграции с 1C-совместимыми IT-системами, вместе с приложением может поставляться 1С-конфигурация, которая поможет 1С-специалистам проще освоить работу с API HubEx и настраивать обмены с HubEx частично или полностью (зависит от выбранной архитектуры) через промежуточную 1С конфигурацию.

Состав поставки мобильного приложения:

1. Android / Apple мобильное приложение для исполнителя работ, обходчика и ITР, техника, сервисного специалиста, руководителя или мастера смены и приложение заказчика работ
2. Панель администрирования для настройки и конфигурация системы и в том числе приложения согласно ролевой модели
3. Открытый API для интеграций
4. База данных – хранит данные приложения и обеспечивает обмен информацией между приложением и системами заказчика через Application сервер
5. Сервер приложений – обрабатывает запросы мобильного приложении
6. Сервер логирования – сохраняет информацию по событиям и помогает расследовать инциденты, решать возникающие проблемы
7. Документация по API в Swagger
8. Документация по возможностям мобильного приложения

WEB ПРИЛОЖЕНИЕ

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

ПАНЕЛЬ АДМИНИСТРИРОВАНИЯ 

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

ЭЛЕКТРОННЫЙ ПАСПОРТ

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

• Параметры и характеристики
• История обслуживания
• Сопутствующая документация: регламенты обслуживания, инструкции по эксплуатации и ремонту и т. д.
• Гарантийный срок, контакты ответственных лиц и т. д.

В паспорт можно добавлять дополнительные поля данных. Электронный паспорт может быть дополнен QR-кода или NFC-меткой, которыми можно маркировать оборудование. Расположенные на оборудовании шильды с метками позволяют пользователю удобно подать заявку через сканирование метки (без писем, звонков и мессенджеров). При этом Исполнитель работ, при сканировании метки, получает доступ к электронному паспорту объекта со всей документацией и историей обслуживания.

 

Возможности по настройке и доработкам HubEx</h2>

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

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

КОНФИГУРАТОР

HubEx имеет функциональный административный интерфейс (конфигуратор) позволяющий достаточно гибко настраивать работу системы, в том числе и работу мобильных приложений. Через конфигуратор можно управлять ролевой моделью, настраивать справочники, создавать поля данных, управлять процессом прохождения заявки, настраивать видимость и доступ к данным по ролям, создавать пользователей, объекты и гибко настраивать систему под процессы компании. Работа в конфигураторе не требует знаний программирования и доступна для изучения любому IT-специалисту. Wiki HubEx находится в публичном доступе и содержит всю необходимую информацию как для администратора системы, так и для пользователей. Для лучшего изучения продукта рекомендуем пройти курсы HubEx Академии. Как дополнение к конфигуратору в HubEx предусмотрено несколько дополнительных инструментов позволяющие дорабатывать систему под задачи компании: технология HubEx Automat, система плагинов и различного вида доработки.

HUBEX AUTOMATE

Следующий по частоте использования технологией настройки/расширения возможностей HubEx, после Конфигуратора, является технология HubEx Automate. HubEx Automate это low-code компонент HubEx с визуальным конструктором и графическим интерфейсом позволяющий делать доработки системы без необходимости писать код. Примеры использования возможностей технологии описаны на сайте в разделе: HubEx Automate. С помощью HubEx Automate можно относительно быстро и просто разработать:

1. Интеграцию / обмен данными с практически любыми IT-системами, поддерживающими технологии обмена по REST API или SOAP.

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

3. Пользовательские интерфейсы/приложения для взаимодействия с интеграциями, автоматизациями и кастомным функционалом, которые можно встроить как в HubEx, так и в сторонние IT-системы

4. Формирование печатных форм по шаблонам, принятых в вашей организации, на основе данных  из HubEx

5. Интерактивные BI-отчеты и сводные аналитические панели любой сложности

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

ПЛАГИНЫ

Плагины – еще один уровень гибкости платформы HubEx. Технология плагинов, встроенная в систему, позволяет либо создавать новый функционал/интерфейсы в системе, либо встраивать сторонние приложения в HubEx. Плагины могут встраиваться как в WEB, так и в мобильное приложение. Плагины могут быть написаны на любых языках программирования, а встройка происходит через iFrame. Например, с помощью плагина в HubEx встроен функционал базы знаний. На сегодняшний момент плагины могут добавляться в систему отдельными окнами и встраиваться в меню как WEB, так и мобильных приложений. Плагины HubEx могут обмениваться данными с системой через REST API / SOAP и технологию HubEx Automate, но на сегодняшний момент имеют следующие ограничения: плагин не умеет взаимодействовать с данными системы еще не сохранённые пользователем на сервер. Функциональны возможности платформы для плагинов постоянно расширяется.

КОНСТРУКТОР ОТЧЕТОВ И АНАЛИТИЧЕСКИХ ПАНЕЛЕЙ

Создавать новые отчеты, печатные формы и аналитических панели в HubEx можно с помощью интегрированных в продукт инструментов: Power BI или Apache SuperSet. ИТ-специалист со знанием данных инструментов сможет взаимодействовать с источниками данных в HubEx и строить отчеты, печатные формы и интерактивные дашборды. Любой отчет можно добавить в меню навигации HubEx WEB или в мобильные приложения HubEx. Для самостоятельно использования данных инструментов необходимо локальное развертывание HubEx или размещение системы на выделенных серверах облачной инфраструктуры HubEx.

ПРОЕКТНЫЕ ДОРАБОТКИ

В рамках проектов функционал HubEx может быть значительно расширен. Кроме технологий доработок перечисленных выше (HubEx Automate, Плагины, Конструктора отчетов и Конфигуратора) в крупных проектах допускается создание отдельной ветки разработки для Клиента. Плюсами данного подхода является максимальная гибкость в доработках и относительно высокая скорость разработки, в сравнении с продуктовой разработкой*. Минусами проектной разработки** (фича под проект конкретного Заказчика, а не в продукт) является то, что отдельная ветка разработки начинает отличаться по коду от основного продукта, а значит замедляется процесс обновления конфигураций системы до новых версий обновлений базового продукта, что повышает стоимость поддержки.  Чем больше таких изменений и доработок, тем ниже скорость применения обновлений и выше трудозатраты. Если не выполнять обновления платформы до новых версий, то через некоторое время возможность обновлений может быть вовсе утрачена, багфиксинг и доработки придется отдельно выпускать под каждую ветку разработки учитывая все выполненные под проект доработки. Проектные доработки НЕ делаются в публичном облаке HubEx Cloud и требуют локального развертывания HubEx или размещения системы на выделенных серверах облачной инфраструктуры HubEx. Под отдельную ветку разработки следует планировать отдельную команду разработки состоящую из нескольких сотрудников: back-end разработчик .NET+SQL, front-end разработчик React, мобильный разработчик React Native, Тестировщик, Аналитик, РП.

*Чем проектная разработка отличается от продуктовой: в продукт делаются только те доработки (фичи), которые требуются большинству клиентов. Уникальные фичи (нужные только одному клиенту), делаются в определенный проект (под конкретного заказчика). Продуктовые доработки имею гораздо более высокий уровень сложности, чем проектные, так как при использовании функционала разными клиентами к каждой фиче (доработке) добавляется функционал настройки в конфигуратор,  ролевая модель, проводится тестирование под множество сценариев работы различных клиентов и выстраивается универсальная архитектура поддерживающая все возможные конфигурации системы у всех клиентов. Так что стоимость продуктовых доработок обычно в 5-10 раз выше, чем проектных. При этом проектные доработки выполняются значительно быстрее и проще. Минусом проектных доработок является то, что все последующие обновления системы до новых версий и хотфиксы требуют больше времени для установки и тестирования на измененной / доработанной под клиента конфигурации. Обязательным условием выполнения Проектных доработок является наличие у Клиента пакета расширенной технической поддержки**

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

ПРОДУКТОВЫЕ ДОРАБОТКИ

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

НОВЫЕ ИНТЕРФЕЙСЫ

Новые интерфейсы в Хабекс могут разрабатываться любым из перечисленных выше способов. Самый простой и наиболее бюджетный вариант – разработка  на базе технологий HubEx Automate. Разработка небольшой фичи на базе данной технологии занимает 20-40 часов.  Следующей по сложности являются плагины – это полноценные мини-программы встроенные в хабекс. По совей сути HubEx Automate  конструктор встраивается в систему через плагин, так что трудоёмкость создания плагина можно также оценить от 20 часов.  Далее по сложности идет проектная разработка. Тут уже объем трудозатрат исчисляется сотнями часов. Продуктовая разработка – самый ресурсоемкий процесс. Минимальная продуктовая фича занимает от 500 часов и в ней участвуют несколько специалистов: Продут-менеджер, Аналитик, Дизайнер, Back-End и Front-End разработчик, часто Мобильный разработчик и тестировщики.

Технологический стек HubEx

ОБЩЕЕ ОПИСАНИЕ

Основной дата-центр (ЦОД) HubEx Cloud находится в IAAS облаке провайдера класса TIER3 в г.С-Петербург. Резервный ЦОД находится в г. Москва. HubEx Cloud работает в кластере высокой доступности, а резервная площадка находится в режиме холодного резервирования с возможностью переключения на резервный ЦОД при выходе из строя основной площадки.

Сервися HubEx работают на серверах под управлением Linux Ubuntu (ВЕБ-севера) с Nginx, Windows серверах с Service Fabric и приложениями Node.js, .NET. Сервисные приложения работают на ОС Linux ubuntu и размещаются в Docker контейнерах. База данных – MS SQL Server и  PostgreSQL. Для сборки приложений используется vsts-agent-win-x64 и vsts-agent-linux-x64.

ТЕХНОЛОГИИ РАЗРАБОТКИ

Платформа программирования: .Net, Язык: C#,

Сервисы: ASP.Net Core, SignalR,

Брокер сообщений: RabbitMQ + Rebus,

Кластеризация: Azure Service Fabric,

Авторизация: Keycloak, Работа с базой данных: ADO.Net. 

Мобильные приложения: 

Уведомления и deeplinks: Firebase
Фреймворк: React Native
База данных: SQLite
Язык программирования: JavaScript

Web приложение:

Уведомления и deeplinks: Firebase

Фреймворк: ReactJS

Язык программирования: JavaScript

Сборщик модулей: Webpack

Управление состоянием: Redux