Всем привет! Мой коллега написал статью по опыту использования различных инструментов О365 для автоматизации небольших бизнес-процессов. Мы взяли за основу кейс по автоматизации HelpDesk на технологиях PowerApps, MS Flow и MS Teams.



Подробности под катом. Надеюсь, статья будет полезна.



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


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


  1. На почтовый ящик приходит письмо, которое необходимо зарегистрировать как тикет в системе HelpDesk.
  2. По важности письма определяется приоритет тикета. По почтовому адресу определяется заказчик, а по заказчику SLA, отведенный для решения данного запроса. После чего создается тикет.
  3. Тикет можно переводить в работу, закрывать, откладывать выполнение.
  4. Должен быть небольшой дашборд, для отслеживания изменений в работе по тикетам.
  5. Подача тикета также может осуществляться через чат-бота.

Получается такая классическая HelpDesk система, но с некоторыми интересными решениями, о которых я сейчас расскажу, но всё по порядку.


В первую очередь создаем структуру списков на сайте SharePoint Online. Нам потребуются списки:


  1. Support Issues – обращения от заявителей.
  2. Products – справочник продуктов, по которым приходят обращения от заявителей.
  3. Customers – справочник компаний-заявителей, от которых могут приходить письма.
  4. 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.


Без минусов конечно, тоже не обошлось:


  1. При добавлении блоков условий или циклов читаемость процесса снижается в несколько раз. После добавления даже трёх условий разобраться в логике процесса становится затруднительно из-за того, что дизайнер процесса отображает эти блоки не совсем очевидным образом.
  2. Триггеры, которые стартуют выполнение процесса, отрабатывают не сразу, по наступлению события, а раз в некоторый промежуток времени. То есть нужно быть готовым к тому, что процесс по триггеру запустится не мгновенно, а через несколько минут.
  3. Имена блоков-действий являются своеобразными идентификаторами этих блоков. Поэтому, если данные из блока, который вы хотите переименовать, используются в следующих блоках, то переименовать исходный блок не получится. Нужно сначала убрать все связи.

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


Теперь у нас есть два способа подачи обращения: вручную, сотрудником технической поддержки и через почту, путем отправки сообщения на определенный адрес. И самое время добавить третий способ. Третьим способом является подача обращения с помощью чат бота. С помощью привлечения разработчиков, удалось реализовать простую схему нашего бота, которая позволяет заявителю подавать свои обращения напрямую через Teams или Skype.


Схема подачи обращения выглядит следующим образом:




В ходе данного диалога, чат-бот определяет основную информацию обращения, формирует письмо на почтовый адрес службы поддержки, а дальше обработка идёт по, уже известной нам, схеме, с помощью процесса Microsoft Flow. Чат-бот ожидает окончания регистрации обращения и пишет сообщение в чат об успешной регистрации тикета. Данный способ взаимодействия с техподдержкой является одним из самых удобных, так как для подачи обращения достаточно открыть соседний чат с ботом, в Teams или Skype и всего за пару секунд отправить своё обращение. Также, данный бот может оказывать некоторые консультации и искать нужную для вас информацию в базе знаний:



Интересными особенностями реализации чат бота являются:


  1. Использование сервиса Dialog Flow от Google, который позволяет более точно классифицировать запросы от пользователей и выдавать нужную информацию.
  2. Возможность интеграции со всеми популярными мессенджерами, такими как Skype, Teams, Telegram, Slack и другими.
  3. База знаний для бота регулярно индексируется с помощью Elastic Search, что позволяет поддерживать актуальность данных для поиска.
  4. Бот может и просто поддержать непринужденную беседу.

Финальным штрихом всей системы является реализация небольшого дашборда на Power BI со статистикой по заведенным тикетам. Источником данных для данного дашборда будут являться списки SharePoint Online:



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


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



Итоговый дашборд располагаем на главной странице нашей системы HelpDesk:



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