Автоматизация жизненного цикла заказа службы и управления соглашением об уровне обслуживания с помощью Power Platform

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

Диаграмма архитектуры

Диаграмма архитектуры Power Platform с пользователями, безопасностью, Dataverse, пользовательским интерфейсом приложения на основе модели, Power Automate и интеграциями Microsoft 365.

Рабочий процесс

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

Рабочий процесс заказа на обслуживание

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

Рабочий процесс выглядит следующим образом:

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

   • Доступ к существующему заказу службы, соглашению об уровне обслуживания (SLA) или запросам на завершение
   • Создание нового запроса на заказ службы, соглашение об уровне обслуживания или завершение работы
   • Просмотр назначенных задач
   • Кнопка "Администратор", видимая членам группы администраторов

2. Пользователь выбирает новый заказ службы на домашней странице. Появится новая форма заказа на обслуживание с вкладками, чтобы ввести сведения о заказе на обслуживание. Пользователь может присоединить документы к созданному сервисному заказу, используя встроенный параметр вложенной сетки SharePoint.

3. Чтобы создать запрос заказа на обслуживание, пользователь нажимает настраиваемую кнопку "Отправить запрос " в верхней части страницы. Выполняются следующие действия:

   1. Новый сервисный заказ создается с новым идентификатором сервисного заказа.

   2. Состояние запроса обновляется на Сервисный заказ запрошен.

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

   4. Пользователь больше не может изменить запрос.

   5. Поток бизнес-процесса обновляется на следующем этапе.

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

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

1. Коммерческий ответственный пользователь входит и выбирает назначенную задачу в разделе "Моя задача".

2. Коммерческий ответственный пользователь проверяет запрос и утверждает или отклоняет запрос, нажав соответствующую пользовательскую кнопку:

   • Назначение основного ответственного
   • Отклонение запроса

3. При отклонении запрос отклоняется, а уведомление отправляется запросившему заказ на обслуживание.

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

   1. Состояние запроса обновляется на Ожидание утверждения PR.

   2. Этап потока бизнес-процессов обновляется.

   3. Для основного ответственного пользователя создается новая задача. Предыдущая задача, назначенная коммерческому ответственному пользователю, завершена.

   4. Уведомление отправляется основному ответственному пользователю.

Основной ответственный пользователь утверждает, отклоняет или запрашивает изменения следующим образом:

1. Основной ответственный пользователь входит и выбирает назначенную задачу в разделе "Моя задача".

2. Основной ответственный пользователь выбирает утверждение, отклонение или отправку изменений. Эти пользовательские кнопки видны только пользователю, которому назначен PR для запроса, когда запрос находится в статусе Ожидание утверждения PR.

   • Утвердить:

     1. Состояние запроса помечается как утвержденное. Это изменение состояния реализуется с помощью пользовательского скрипта, написанного на пользовательской кнопке.

     2. Уведомление отправляется коммерческой ответственной группе и инициатору заявки на обслуживание.

     3. Состояние запроса обновляется на Ожидание окончательного процесса подписывания.

     4. Задача назначается коммерческой ответственной группе.

     5. Поток бизнес-процесса обновляется на следующем этапе.

     6. Задача основного ответственного пользователя завершена.

   • Отклонить:

     1. Запрос помечается как отклоненный.

     2. Бизнес-процесс обновляется до этапа "Отклонено".

     3. Уведомление отправляется запрашивающему заказ на обслуживание и коммерческой ответственной группе.

   • Отправить поправку:

     1. Запрос возвращается инициатору сервисного заказа на доработку.

     2. Статус запроса обновляется до этапа обработка запроса на выполнение заказа.

     3. Поток бизнес-процессов возвращается к начальной стадии.

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

   Когда основной ответственный пользователь отклоняет или утверждает запрос, PDF-документ экспортируется и сохраняется в библиотеку SharePoint заказов на обслуживание. PDF-файл создается с помощью функции шаблона документа Dataverse, где пользователь создает шаблон в Word с помощью атрибутов сущности XML. Поток Power Automate вызывает API шаблона PDF-документа, чтобы создать версию PDF и экспортировать все данные запроса на обслуживание. Идентификатор шаблона документа и глобальный уникальный идентификатор (GUID) сервисного заказа передаются в поток Power Automate.

На последнем этапе подписания коммерческий ответственный пользователь подписывает документ и завершает запрос. Пользователь может видеть только вкладки, связанные с процессом подписывания документа. Все остальные вкладки скрыты. Эта функция реализуется с помощью API XRM и JavaScript в форме.

1. На первой вкладке коммерческий ответственный пользователь увидит кнопку "Отправить подписанный документ ".

2. Когда пользователь нажимает кнопку, приложение выделяет следующую вкладку, которая содержит подрешетку документа SharePoint и PDF-документ, созданный на предыдущем шаге.

3. Коммерческий ответственный пользователь скачивает PDF-документ, подписывает его вручную и отправляет его на вкладку библиотеки документов.

4. Пользовательская кнопка "Полный процесс подписывания" в верхней части становится доступной.

5. Когда коммерческий ответственный пользователь выбирает кнопку, запрос становится доступным только для чтения.

6. По завершении запроса пользователю отправляется уведомление, коммерческой ответственной группе и основному ответственному пользователю. Поток Power Automate помечает поток бизнес-процесса и назначенную задачу как завершенные.

Рабочий процесс по соглашению об уровне обслуживания

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

Соглашение об уровне обслуживания по умолчанию действует в течение 18 месяцев, и процесс Power Automate выполняется ежедневно для проверки истечения срока действия SLA. Когда дата истечения SLA совпадает с текущей датой, задание помечает SLA и связанный сервисный заказ как завершенные, а также обновляет соответствующие уведомления по электронной почте и этапы потока бизнес-процесса для обеих сущностей.

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

Рабочий процесс прекращения

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

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

Когда наступает дата прекращения для любого утвержденного запроса на прекращение, внутренний поток Power Automate ежедневно выполняет проверку и:

• Если запрос связан с соглашением об уровне обслуживания, завершите то соглашение, которое связано с запросом на завершение.

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

Сведения о варианте использования

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

Бизнес-контекст

Эта инициатива началась, когда организация намерена переместить процесс управления заказами на обслуживание с платформы Angular-Camunda в Microsoft Power Platform.

Устаревшее решение, основанное на Angular, Camunda Workflow Engine и PostgreSQL, столкнулось с высокими расходами на лицензирование, требовало выделенной технической команды для запросов на изменение и имело длительное время выполнения даже для незначительных улучшений. Сложность решения и ее затрат на обслуживание побудила организацию проводить современную, экономически эффективную и простую альтернативу.

Цели и драйверы

Ключевые драйверы для нового решения:

• Использование существующих лицензий и инфраструктуры Power Platform для устранения дополнительных затрат на лицензирование.

• Сокращение зависимости от специализированной технической поддержки, снижение операционных расходов.

• Упрощение управления изменениями с помощью функций с низким кодом и минимизации пользовательской разработки.

• Предоставьте оптимизированное, легкое в обслуживании решение Power Platform в течение одного месяца, учитывающее строгие сроки клиента.

• Обеспечение простой миграции существующих процессов и базовых данных.

• Улучшение взаимодействия с пользователем с помощью интерактивного интуитивно понятного интерфейса.

Components

Команда разработала и реализовала приложение Power Apps на основе модели, поддерживаемое ключевыми встроенными функциями (OOTB), чтобы минимизировать настройки и при этом выполнить все функциональные требования.

Пользовательский интерфейс

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

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

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

Потоки бизнес-процессов (BPF) помогают пользователям визуализировать существующий этап.

Создание PDF-файлов

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

Новое решение использует:

• Шаблоны документов сущностей OOTB для создания Word/PDF.

• Изменения шаблона, контролируемые администратором, устраняют зависимость от технических команд.

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

Рабочие процессы и утверждения

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

потоки Power Automate выполняют различные действия при завершении каждого этапа утверждения, такие как отправка уведомлений в Outlook и Teams, назначение задач и создание автоматического PDF-файла на последнем этапе.

Управление жизненным циклом и завершением

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

Напоминания о задачах

Потоки Power Automate отправляют напоминания пользователям, которым назначены задачи, после наступления срока выполнения.

Источник данных

Dataverse для управления и хранения данных приложения, а также ведения журнала аудита.

SharePoint в качестве репозитория документов и управления версиями документов.

Отчётность

Встроенная отчетность приложения на основе модели Power Apps отображает диаграммы и предоставляет аналитические сведения по данным приложения.

Рекомендации

Эти соображения реализуют основы Power Platform Well-Architected — набора руководящих принципов, повышающих качество рабочей нагрузки. Дополнительные сведения см. в разделе Microsoft Power Platform Well-Architected.

Reliability

• Определите четкие ожидания для:

  • Время отклика
  • Временная шкала утверждения
  • Ежедневные окна выполнения заданий (истечение SLA, задание завершения)

• Реализуйте устойчивость на основе задач. Например, если шаг Power Automate завершится сбоем:

  • Сохраните задачу в Dataverse до тех пор, пока связанное действие не завершится.

  • Пусть пользователи повторяют отправку или утверждение на любом этапе.

  • Обновите состояние запроса только после выполнения всех шагов в рабочем процессе.

  • Показывать ошибку в бизнес-процессе, если обновление этапа завершится сбоем.

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

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

• Используйте ведение журнала для обеспечения надежности данных запроса и поддержки трассировки.

Security

• Управляйте доступом к приложению на основе модели с помощью групп безопасности Microsoft Entra ID, сопоставленных с командами владельцев Dataverse.

• Четко определите роли безопасности для ответственного за коммерческую деятельность, основного ответственного, запрашивающего и администратора для защиты доступа к данным.

• Пригласите гостевых пользователей в Microsoft Entra ID в соответствии с политиками организации и добавьте их в группу безопасности только после утверждения. Используйте ту же группу безопасности для утвержденных внешних пользователей.

• Используйте безопасность уровня полей Dataverse и уровня строк.

• Предоставьте разрешения SharePoint с помощью встроенной интеграции с Dataverse и модельно-управляемыми приложениями.

• Разверните приложение в управляемой среде и определите для него определенную политику данных.

• Используйте ведение журнала аудита Dataverse для обнаружения аномалий данных.

• Сделайте данные только для чтения после того, как запрос достигнет определенного этапа.

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

Операционная эффективность

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

• Реализуйте стратегию решения:

  • Используйте неуправляемое решение в среде разработки и управляемое решение в других средах.

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

• Реализуйте проверки кода перед переходом из среды разработки.

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

Эффективность работы

• Определите паттерны объёма транзакций из старых приложений и согласуйте с бизнесом собранные данные по объёму.

• Делегируйте длительные действия, такие как срок действия соглашения об уровне обслуживания и завершение выполнения, в запланированные потоки, которые не зависят от взаимодействия с пользователем.

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

Оптимизация взаимодействия

• Создайте кастомную страницу для улучшения целевой страницы.

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

• Включите глубокие ссылки в сообщения электронной почты, чтобы пользователи могли напрямую обращаться к запросам.

• Отправлять своевременные напоминания, чтобы помочь пользователям выполнять задачи вовремя.

• Добавьте краткие ссылки на мои задачи и разделы администратора.

• Добавьте пользовательские кнопки, которые пользователи могут выбрать для определения действий.

• Уведомлять пользователей об успешном выполнении или сбое после выбора каждой кнопки.

• Скрытие ненужных данных, когда запросы достигают определенного этапа.

• Архивировать данные, чтобы пользователи видели только активные элементы.

Связанные ресурсы

• Что такое модельно-управляемые приложения в Power Apps?
• Добавьте пользовательскую страницу в свое модельное приложение
• Обзор потоков бизнес-процессов
• Документация по Power Automate
• Документация Dataverse
• Управление группами
• Используйте шаблоны Excel и Word
• Общие сведения об управляемых средах

Соавторы

Microsoft поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Ракхи Джайн, технический архитектор