Поддержка пользователей: текущая поддержка производственных решений

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

На этой диаграмме показана общая схема поддержки и градации, которую организации успешно используют:

Тип	Описание
	Самообслуживание (внутреннее) происходит, когда создатель поддерживает собственное решение. Пользователи решения знают, что нужно обращаться к создателю за поддержкой, и часто ИТ-отдел или команда не видят уровень или тип поддержки, предоставляемой создателем.
	Групповая поддержка (внутренняя) возникает, когда члены команды учатся друг у друга по мере развития решения Power Platform. Члены команды становятся совладельцами приложений, потоков и чат-ботов своей команды. Совладельцы могут поддерживать запросы пользователей и могут вносить небольшие исправления ошибок и изменения. Хотя групповая поддержка иногда осуществляется неофициально, рекомендуется формализовать этот процесс по мере того, как ваше внедрение и рост становятся более зрелыми.
	Служба поддержки (внутренняя) обрабатывает формальные вопросы поддержки и запросы. Служба поддержки может помочь с такими вопросами, как доступ к приложению на мобильном устройстве или запрос доступа к внутреннему источнику данных. Они будут перенаправлять вопросы, связанные с решением, на канал, поддерживающий решение.
	Специальная поддержка Power Platform (внутренняя) включает в себя решение сложных вопросов, поднятых службой поддержки. Критические приложения передаются этой команде, и они могут развертывать исправления ошибок.
	Поддержка партнеров (внешняя) может дополнить ваше предложение внутренней поддержки и либо поддерживать критически важные приложения, либо работать с конкретными отделами над поддержкой их приложений. Подробнее: Получение квалифицированной помощи от партнеров Power Apps
	Поддержка Майкрософт (внешняя) может использоваться для поднятия технических вопросов, связанных с платформой. В зависимости от вашего плана поддержки вам доступны различные услуги технической поддержки и консультации. Подробнее: Поддержка для Microsoft Power Platform

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

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

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

Определение уровней приложений

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

Характеристики и процессы	Продуктивность	Важность	Критически
Вариант использования	Индивидуальная производительность и варианты использования небольшой команды, которые могут использовать существующие данные.	Простые бизнес-приложения или командные инициативы. Небольшие автономные совместные процессы.	Сложные бизнес-приложения, корпоративные инициативы или критически важные рабочие нагрузки, которые могут оказать существенное влияние на бизнес во время простоя.
Сложность	Простые процессы.	Средняя сложность.	Высокая сложность.
База пользователей	Небольшая пользовательская база — отдельные пользователи, непосредственные коллеги или небольшая команда.	Охватывается бизнес-подразделение.	Большая пользовательская база или использование в масштабах предприятия.
Жизненный цикл разработки	Высокий уровень итерации.	Обычно на разработку уходит не более трех месяцев.	Более длительный цикл разработки.
Воздействие	Малое влияние на бизнес.	Важно, но е критично для бизнеса (среднее влияние).	Высокий уровень влияния.
ALM	ALM не требуется.	Требуется ALM, и его можно реализовать с помощью ручного импорта/экспорта решения.	Требуется надежный процесс ALM — ALM достигается с помощью Azure DevOps или конвейеров GitHub.
Стратегия среды	Решение построено в среде по умолчанию или в общей рабочей среде.	Выделенная среда разработки, а также общие тестовые и рабочие среды (общие с другими решениями, например для конкретных бизнес-подразделений). Среды управляются бизнес-подразделением (децентрализовано) или центральным ИТ-отделом (централизовано).	Выделенные среды разработки, тестирования, производства. Среды управляются центральной ИТ-службой.
Разрешения для создателей	У создателя есть роль безопасности "создатель среды" в средах.	У создателя есть роль безопасности "создатель среды" или "настройщик системы" в среде разработки, но только роль безопасности "конечный пользователь" в тестовой и производственной средах. Решения могут принадлежать служебной учетной записи или администратору среды в тестовой и рабочей средах.	У создателя есть роль безопасности "создатель среды" или "настройщик системы" в среде разработки, но только роль безопасности "пользователь" в тестовой и рабочей средах. Развертывание решения происходит автоматически, и решения принадлежат субъекту-службе в тестовой и рабочей средах.
Участие ИТ	Реактивное управление — ИТ-отдел имеет представление о создаваемых решениях и отслеживает их использование.	ИТ-кураторство на уровне решения или пользователя. Создатель предоставляет подробные сведения о решении, такие как возможные обходные пути и используемые источники данных.	Рабочая среда управляется ИТ-отделом.
Модель поддержки	Самостоятельная.	Групповая поддержка.	Официальная поддержка.

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

Каждый из представленных выше типов поддержки пользователей более подробно описан в этой статье.

Поддержка создателей (самообслуживание)

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

Внимание

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

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

Групповая поддержка

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

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

Служба поддержки

Служба поддержки работает как общая служба, управляемая ИТ-отделом.

Служба поддержки может:

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

Специальная команда поддержки Power Platform

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

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

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

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

Некоторые клиенты могут передать этот уровень поддержки партнеру.

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

Поддержка партнеров

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

Служба поддержки Майкрософт

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

Совет

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

Соображения и ключевые действия

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

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

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

• Определить первоначальный объем тем Power Platform, которыми будет заниматься служба поддержки.
• Оцените уровень готовности вашей службы поддержки к оказанию поддержки.
• Организуйте дополнительные тренинги для сотрудников службы поддержки, исходя из пробелов в готовности.
• Определите путь эскалации для запросов, которые служба поддержки не может обработать напрямую.
• Обновите базу знаний службы поддержки для известных тем Power Platform. Убедитесь, что кто-то отвечает за регулярные обновления базы знаний, чтобы со временем отражать новые и улучшенные функции. Будьте в курсе, подписавшись на RSS-каналы блога Power Apps, блога Power Automate и блога Power Virtual Agents.
• Обеспечьте наличие хорошей системы отслеживания проблем. Часто это система запросов в службу поддержки, которая может управлять уровнями приоритета.
• Решите, будет ли кто-либо заниматься поддержкой по любым вопросам, связанным с Power Platform. При необходимости убедитесь, что ожидания круглосуточной поддержки понятны.
• Определите, какие SLA будут существовать, и что ожидания ответа и разрешения должны быть четко сообщены.
• Будьте готовы быстро решать конкретные распространенные проблемы. Например, запрос на использование нового соединителя должен быть обработан быстро. Медленный ответ службы поддержки может привести к тому, что пользователи найдут обходные пути.
• Убедитесь, что в вашей службе поддержки есть роль безопасности, которая позволяет им направлять запросы в службу поддержки с Microsoft. Решите, будет ли служба поддержки или специальная группа поддержки рассматривать эти проблемы.

Соображения и основные действия, которые вы можете предпринять, чтобы внутреннюю специальную поддержку Power Platform:

• Четко определите, где заканчиваются обязанности службы поддержки и начинаются обязанности специальной поддержки.
• Убедитесь, что у специальной группы поддержки Power Platform есть прямой путь эскалации, чтобы связаться с глобальными администраторами для Microsoft 365 и Azure. Это критически важно, когда возникает широко распространенная проблема, которая выходит за рамки Power Platform. Такие проблемы могут быть связаны с учетными записями пользователей и разрешениями, конфигурациями сети или источниками данных, используемыми в решениях Power Platform.
• Создайте цикл обратной связи от специальной группы поддержки до службы поддержки, чтобы можно было обновлять базу знаний в области ИТ. Цель состоит в том, чтобы основная служба поддержки постоянно совершенствовалась для решения большего количества проблем в будущем.
• Создайте цикл обратной связи от службы поддержки до специальной группы поддержки. Когда персонал поддержки замечает избыточность или неэффективность, он может передать эту информацию специальной группе поддержки, которая может принять решение об изменении и улучшении внутренних процессов. Пример: если служба поддержки перегружена созданием и настройкой новых сред Power Platform для создателей, специальная команда может рассмотреть возможность автоматизации этого процесса с помощью компонентов управления запросами среды в начальном наборе CoE.
• Создайте путь эскалации от отдельных лиц и групп, поддерживающих их решения, до специальной группы поддержки, чтобы они могли быть разблокированы, если столкнутся с проблемами, которые не могут решить самостоятельно.
• Создайте путь передачи от отдельных лиц и групп, поддерживающих свои решения, к специальной группе поддержки, чтобы обеспечить возможность перехода критически важных приложений.
• Определитесь с общей стратегией передачи решений специальной группе — по мере увеличения количества важных и критических решений, будете ли вы увеличивать штат специальной группы поддержки или будете полагаться на бизнес-подразделения, чтобы укомплектовать группы поддержки в своих областях?