Всем привет! Мой коллега написал статью по опыту использования различных инструментов О365 для автоматизации небольших бизнес-процессов. Мы взяли за основу кейс по автоматизации HelpDesk на технологиях PowerApps, MS Flow и MS Teams.
Подробности под катом. Надеюсь, статья будет полезна.
Меня зовут Андрей Браун, я ведущий специалист по внедрению программного обеспечения. Сегодня я снова хочу поделиться опытом реализации одного интересного кейса.
Суть задачи следующая – необходимо реализовать небольшую HelpDesk систему, которая позволит регистрировать обращения от заявителей. Общий концепт логики выглядит следующим образом:
- На почтовый ящик приходит письмо, которое необходимо зарегистрировать как тикет в системе HelpDesk.
- По важности письма определяется приоритет тикета. По почтовому адресу определяется заказчик, а по заказчику SLA, отведенный для решения данного запроса. После чего создается тикет.
- Тикет можно переводить в работу, закрывать, откладывать выполнение.
- Должен быть небольшой дашборд, для отслеживания изменений в работе по тикетам.
- Подача тикета также может осуществляться через чат-бота.
Получается такая классическая HelpDesk система, но с некоторыми интересными решениями, о которых я сейчас расскажу, но всё по порядку.
В первую очередь создаем структуру списков на сайте SharePoint Online. Нам потребуются списки:
- Support Issues – обращения от заявителей.
- Products – справочник продуктов, по которым приходят обращения от заявителей.
- Customers – справочник компаний-заявителей, от которых могут приходить письма.
- SLA – справочник с данными по SLA для каждой компании-заявителя. Если заявитель не относится ни к одной из имеющихся в справочнике Customers компаний, то используется стандартный срок ответа на обращение – 3 дня.
Предусматриваем возможность создания обращения вручную сотрудником технической поддержки. Для этого делаем максимально простую форму, с использованием инструмента Microsoft PowerApps и выводим на нее несколько реквизитов, как показано на скриншоте ниже:
Созданный тикет можно брать в работу, с помощью нажатия на кнопку, закрепленную в нижней части формы, как показано на скриншоте ниже:
Далее, в ходе работы над обращением, специалист технической поддержки ведет переписку с заявителем через почту и, после решения вопроса по обращению, закрывает тикет в системе.
Но основным способом подачи обращения для заведения тикета, всё-таки будет являться почта. Для приема почты будет использоваться почтовый ящик Office 365, а для обработки входящей почты, процесс, сделанный с помощью инструмента Microsoft Flow.
Microsoft Flow – это облачный сервис, который позволяет создавать рабочие процессы для обмена данными между приложениями, службами и online-сервисами. Эти процессы можно использовать для сбора данных, синхронизации файлов, получения уведомлений и других целей.
Преимуществом инструмента Microsoft Flow, является большой набор коннекторов к различным системам и сервисам. Например, в нашем случае, мы можем использовать триггер, который будет анализировать новые письма в почтовом ящике и, по каждому из них, выполнять определенную логику.
Сам триггер будет выглядеть максимально просто:
Дальнейшая логика, определённая в процессе, отвечает за формирование уникального регистрационного номера, создания тикета в системе HelpDesk на сайте SharePoint Online, а также за отправку почтового уведомления заявителю:
По опыту работы с Microsoft Flow, могу отметить, что это удобный и надежный инструмент для создания автоматизированных рабочих процессов с целью обмена данными между приложениями и службами. На текущий момент поддерживается большое количество популярных сервисов и служб, таких как Google, Dropbox, Slack, WordPress, а также различных социальных сервисов: Blogger, Instagram, Twitter, Youtube, Facebook, Vimeo и так далее. Конечно же, помимо этого доступна простая интеграция с приложениями Office 365.
Без минусов конечно, тоже не обошлось:
- При добавлении блоков условий или циклов читаемость процесса снижается в несколько раз. После добавления даже трёх условий разобраться в логике процесса становится затруднительно из-за того, что дизайнер процесса отображает эти блоки не совсем очевидным образом.
- Триггеры, которые стартуют выполнение процесса, отрабатывают не сразу, по наступлению события, а раз в некоторый промежуток времени. То есть нужно быть готовым к тому, что процесс по триггеру запустится не мгновенно, а через несколько минут.
- Имена блоков-действий являются своеобразными идентификаторами этих блоков. Поэтому, если данные из блока, который вы хотите переименовать, используются в следующих блоках, то переименовать исходный блок не получится. Нужно сначала убрать все связи.
Но данные проблемы не являются критичными, скорее это уже мои личные придирки. Так что двигаемся дальше.
Теперь у нас есть два способа подачи обращения: вручную, сотрудником технической поддержки и через почту, путем отправки сообщения на определенный адрес. И самое время добавить третий способ. Третьим способом является подача обращения с помощью чат бота. С помощью привлечения разработчиков, удалось реализовать простую схему нашего бота, которая позволяет заявителю подавать свои обращения напрямую через Teams или Skype.
Схема подачи обращения выглядит следующим образом:
В ходе данного диалога, чат-бот определяет основную информацию обращения, формирует письмо на почтовый адрес службы поддержки, а дальше обработка идёт по, уже известной нам, схеме, с помощью процесса Microsoft Flow. Чат-бот ожидает окончания регистрации обращения и пишет сообщение в чат об успешной регистрации тикета. Данный способ взаимодействия с техподдержкой является одним из самых удобных, так как для подачи обращения достаточно открыть соседний чат с ботом, в Teams или Skype и всего за пару секунд отправить своё обращение. Также, данный бот может оказывать некоторые консультации и искать нужную для вас информацию в базе знаний:
Интересными особенностями реализации чат бота являются:
- Использование сервиса Dialog Flow от Google, который позволяет более точно классифицировать запросы от пользователей и выдавать нужную информацию.
- Возможность интеграции со всеми популярными мессенджерами, такими как Skype, Teams, Telegram, Slack и другими.
- База знаний для бота регулярно индексируется с помощью Elastic Search, что позволяет поддерживать актуальность данных для поиска.
- Бот может и просто поддержать непринужденную беседу.
Финальным штрихом всей системы является реализация небольшого дашборда на Power BI со статистикой по заведенным тикетам. Источником данных для данного дашборда будут являться списки SharePoint Online:
На основании этих списков будут строиться модели данных, используемые в графиках.
Источник данных, по которому строится дашборд регулярно обновляется, что позволяет практически всегда быть в курсе реальной обстановки дел по обращениям заявителей:
Итоговый дашборд располагаем на главной странице нашей системы HelpDesk:
В заключение хочется сказать, что использование совокупности вышеперечисленных продуктов и технологий, позволяет достаточно просто создавать функциональные и удобные системы для различных целей.
Автор: JuliyaErina
