Всем привет! Мой коллега написал статью по опыту использования различных инструментов О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:

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