Планирование реализации Power BI: планирование решения бизнес-аналитики

Примечание.

Эта статья входит в серию статей по планированию реализации Power BI. В этой серии основное внимание уделяется рабочей нагрузке Power BI в Microsoft Fabric. Общие сведения о серии см. в статье о планировании реализации Power BI.

Эта статья поможет вам спланировать решения, поддерживающие стратегию бизнес-аналитики (BI). Это в первую очередь предназначено для:

• Бизнес-аналитика или руководители: лица, принимающие решения, которые отвечают за надзор за программой БИЗНЕС и стратегически важными решениями бизнес-аналитики.
• Центр превосходства (COE), ИТ-отделы и группы бизнес-аналитики: команды, которые разрабатывают и развертывают корпоративные решения бизнес-аналитики для своей организации.
• Эксперты по темам (SMEs) и владельцы контента и создатели: команды и лица, которые чемпионы аналитики в отделе и разработке и развертывании решений для самообслуживания, отдела бизнес-аналитики или сценариев использования бизнес-аналитики команды.

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

Примечание.

В рамках целей и ключевых результатов (ОКR) цели являются четкими, высокоуровневые описания того, что вы хотите достичь. В отличие от этого, ключевые результаты являются конкретными, достижимыми результатами для оценки прогресса в достижении одной из ваших целей.

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

Дополнительные сведения о OKRs см. в статье "Знакомство с OKRs" (Microsoft Viva Goals).

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

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

Чтобы провести планирование решений бизнес-аналитики, выполните следующие действия.

Step	Description
1	Соберите группу проектов, которая собирает требования и определяет проект решения.
2	Планирование развертывания решения путем начальной настройки средств и процессов.
3	Провести подтверждение концепции (POC) для проверки предположений о проектировании.
4	Создание и проверка содержимого с помощью итеративных циклов разработки и проверки.
5	Развертывание, поддержка и мониторинг решения после его выпуска в рабочей среде.

Примечание.

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

Дополнительные сведения см. в серии миграций Power BI. Хотя серия связана с миграцией, ключевые действия и рекомендации относятся к планированию решений.

Шаг 1. Сбор требований

Вы начинаете планирование решений, сначала собирая требования и определяя проект решения.

Примечание. Стратегическое и тактическое планирование возглавляет рабочая группа, которая ведет инициативу. В отличие от этого, планирование решений ведется командой проектов, которая состоит из владельцев контента и создателей.

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

Ниже приведены некоторые преимущества совместного подхода для сбора требований.

• Входные данные пользователей создают более полезные проекты: путем привлечения пользователей в ориентированные обсуждения для сбора требований, вы можете более эффективно записывать потребности бизнес-данных. Например, пользователи могут продемонстрировать создателям содержимого, как они используют существующие решения и предоставлять отзывы о предполагаемой эффективности этих решений.
• Избегайте предположений и устраняйте запросы на изменение: обсуждения с пользователями часто показывают нюансы, исключения и скрытые сложности. Эти аналитические сведения снижают вероятность поздних запросов, которые могут быть дорогостоящими для решения.
• Подключение пользователей увеличивает внедрение решений: путем участия пользователей в разработке и начале разработки вы предоставляете им возможность влиять на окончательный результат. Участие также может дать пользователям чувство интеллектуальной собственности и ответственности за решение. Очень заинтересованные пользователи, скорее всего, будут поддерживать решение и вести свое сообщество практики эффективно использовать его.
• Проекты устанавливают ожидания для заинтересованных лиц и бизнес-пользователей: создавая макеты или иллюстрации дизайна решения, вы можете четко показать заинтересованным лицам, что решение будет доставлять. Это также помогает создать взаимное понимание ожидаемого результата проекта. Этот процесс также известен как проектирование мышления, и он может быть эффективным способом подхода и понимания сложных проблем.

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

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

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

Важно!

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

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

Примечание.

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

Подготовка к планированию решений

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

• Определите, кто будет проводить планирование решений: в рамках тактического планирования бизнес-аналитики рабочая группа создала приоритетную невыполненную работу решений. В планировании решений группа проектов отвечает за проектирование, разработку и развертывание одного или нескольких решений из невыполненной работы. Для каждого решения в невыполненной работы необходимо собрать группу проектов, которая будет отвечать за решение. Помимо планирования решений бизнес-аналитики, группа проектов должна:
  • Определите временная шкала и вехи для планирования решений.
  • Определите и включайте нужных заинтересованных лиц для сбора требований.
  • Настройте централизованное расположение для обмена данными, документации и планирования.
  • Привлечение заинтересованных лиц к сбору требований.
  • Обмен данными и координация с заинтересованными лицами и бизнес-пользователями.
  • Оркестрируйте итеративные циклы разработки и тестирования с бизнес-пользователями.
  • Задокументируйте решение.
  • Подключение пользователей к решению путем определения и принятия плана обучения.
  • Предоставление поддержки решения после развертывания.
  • Указать разумные запросы пользователей на изменение или обновление решения после развертывания.
  • При необходимости выполните передачу решения после развертывания.
• Централизация коммуникации и документации. Важно, чтобы группа проектов централизованно общения и документации для планирования решений бизнес-аналитики. Например, команда проектов должна централизировать требования, взаимодействие заинтересованных лиц, временная шкала и доставить их. Рассмотрите возможность хранения всей документации на централизованном портале.
• Сбор требований к плану: группа проектов должна начинаться с планирования сеансов проектирования бизнеса для сбора бизнес-требований. Эти сессии принимают форму интерактивных собраний, и они могут следовать аналогичному формату стратегических семинаров по планированию.

Совет

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

Сбор бизнес-требований

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

Цель бизнес-проектных сессий состоит в том, чтобы:

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

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

На схеме показаны следующие шаги.

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

Бизнес-дизайн завершается следующими доставить.

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

Техническая конструкция используется и проверяется техническим проектом.

Совет

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

Сбор технических требований

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

Примечание.

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

Цель технического проектирования состоит в том, чтобы:

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

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

Примерами заинтересованных лиц в техническом проектировании могут быть:

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

Группа проектов участвует заинтересованным лицам в технических сеансах проектирования для решения технических аспектов. Технические аспекты могут включать:

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

Совет

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

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

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

На схеме показаны следующие шаги.

Элемент	Description
	Команда проектов начинает технический дизайн, определяя источник данных область на основе результатов бизнес-проектирования. Источник данных область объявляет, какие данные необходимы для создания решения. Чтобы определить правильные источники данных, группа проектов обращается к бизнес-и функциональным ПРЕДПРИЯТИЯм.
	Группа проектов определяет технических или функциональных заинтересованных лиц, которые будут участвовать в последующих сеансах технического проектирования.
	Группа проектов планирует ограниченные, ориентированные сессии с функциональными заинтересованными лицами для решения технических аспектов. Планирование включает информирование заинтересованных лиц, организацию собраний и подготовку конечных результатов.
	Группа проектов изучает технические требования. Исследования включают определение вычислений полей и сопоставлений источников данных, а также устранение допущений бизнес-проектирования с техническим анализом и документацией.
	При необходимости группа проектов включает заинтересованных лиц в технические сессии проектирования. Сеансы сосредоточены на конкретных технических аспектах решения, таких как безопасность или подключения к источнику данных. В этих сессиях группа проектов собирает качественные отзывы заинтересованных лиц и субъектов МАЛОГО ИБ.
	Команда проекта готовит свои выводы с помощью плана решения, который они представляют заинтересованным лицам и лицам, принимающим решения. План — это итерация и расширение результатов бизнес-проектирования, которые включают окончательный дизайн, оценки и другие результаты.
	Технический дизайн должен завершиться окончательным собранием с заинтересованными лицами и лицами, принимающими решения, чтобы решить, следует ли продолжить. Это собрание предоставляет окончательную возможность оценить планирование решения до того, как ресурсы будут привержены разработке решения.

Примечание.

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

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

• Средства и технологии: список соответствующих технических инструментов, необходимых для реализации решения. Список обычно включает соответствующие новые параметры лицензии (например, емкость Fabric или Premium на пользователя), функции и инструменты.
• Определенный список бизнес-метрик: вычисления и сопоставления источников полей бизнес-метрик для всех область источников данных. Чтобы создать этот доставить, команда проектов использует список бизнес-метрик, созданных в бизнес-дизайне.
• Определенный список бизнес-атрибутов: сопоставления бизнес-атрибутов с исходным полем для всех область источников данных. Для создания этого результата команда проектов использует список бизнес-атрибутов, созданных в бизнес-дизайне.
• Измененные проекты: редакции проектирования решения на основе изменений или недопустимых предположений о бизнес-дизайне. Измененные макеты обновлены версии макетов, прототипов или проволочной диаграммы, созданные в бизнес-дизайне. Если никаких изменений не требуется, сообщите, что технический дизайн проверяет бизнес-дизайн.
• Оценка усилий: оценка ресурсов, необходимых для разработки, поддержки и обслуживания решения. Оценка сообщает окончательное решение о том, следует ли продолжать реализацию решения, или нет.

Важно!

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

Совет

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

Контрольный список . При сборе требований к ключевым решениям и действиям относятся:

• Уточняйте, кто владеет планированием решений: для каждого решения убедитесь, что роли и обязанности понятны для группы проектов.
• Уточняйте решение область: решение область уже должно быть задокументировано в рамках тактического планирования бизнес-аналитики. Перед началом планирования решения может потребоваться провести дополнительное время и усилия, чтобы уточнить область.
• Выявление и информирование заинтересованных лиц: выявление заинтересованных лиц для бизнес-проектов и технических проектов. Заранее сообщите им о проекте и объясните область, цели, необходимые затраты времени и доставить их из бизнес-дизайна.
• Планирование и проведение бизнес-проектных сессий: модерируйте сеансы проектирования бизнеса, чтобы получить информацию от заинтересованных лиц и бизнес-пользователей. Попросите пользователей продемонстрировать, как они используют существующие решения.
• Документируйте бизнес-метрики и атрибуты: используя существующие решения и входные данные от заинтересованных лиц, создайте список бизнес-метрик и атрибутов. В технических проектах сопоставьте поля с источником данных и опишите логику вычисления для количественных полей.
• Проект решения: создание итеративных макетов на основе входных данных заинтересованных лиц, которые визуально отражают ожидаемый результат решения. Убедитесь, что макеты точно представляют и решают бизнес-требования. Сообщите бизнес-пользователям, что макеты по-прежнему должны быть проверены (и, возможно, изменены) во время технического проектирования.
• Создайте план решения: исследовательские исходные данные и соответствующие технические рекомендации, чтобы обеспечить достижимый бизнес-дизайн. Где это необходимо, описать ключевые риски и угрозы для проектирования, а также любые альтернативные подходы. При необходимости подготовьте проект решения и обсудите его с заинтересованными лицами.
• Создание оценки усилий. В рамках окончательного плана решения оцените усилия по созданию и поддержке решения. Оправдывать эти оценки с информацией, собранной во время бизнес-проектных и технических проектных сессий.
• Решите, следует ли продолжать работу с планом: чтобы завершить процесс сбора требований, представить окончательный план заинтересованным лицам и лицам, принимающим решения. Цель этого собрания — определить, следует ли продолжать разработку решений.

Шаг 2. Планирование развертывания

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

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

Планирование решения ключевых областей

Группа проектов должна планировать основные области развертывания решения. Как правило, планирование должно решать следующие области.

• Соответствие. Убедитесь, что все критерии соответствия, определенные в сборе требований, будут решаться определенными действиями. Назначьте каждое из этих действий определенным людям и четко определите срок доставки.
• Безопасность. Определите, как будут управляться различные уровни доступа к решению и какие-либо требования к правилу безопасности данных. Проверьте, будет ли безопасность решения более или менее строгой, чем стандартное содержимое в клиенте.
• Шлюзы данных. Оцените, требуется ли решению шлюз данных для подключения к источникам данных. Определите, необходимы ли определенные параметры шлюза или кластеры с высоким уровнем доступности. Запланируйте, кто сможет управлять подключениями шлюза с помощью ролей безопасности шлюза и как отслеживать шлюзы. Дополнительные сведения см. в разделе "Подготовка доступа к шлюзу".
• Рабочие области. Определите, как настроить и использовать рабочие области. Определите, требуется ли решение средств управления жизненным циклом, таких как интеграция и конвейеры развертывания Git, а также необходимость расширенного ведения журнала с помощью Azure Log Analytics.
• Поддержка. Определите, кто отвечает за поддержку и обслуживание решения после развертывания в рабочей среде. Если лица, ответственные за поддержку, отличаются от группы проектов, обратитесь к этим лицам в разработке. Убедитесь, что любой из тех, кто будет поддерживать решение, понимает разработку решения, проблему, которую он должен решить, кто должен его использовать и как.
• Обучение пользователей. Предвидеть усилия, необходимые для обучения сообщества пользователей, чтобы они могли эффективно использовать решение. Рассмотрите необходимость каких-либо конкретных действий по управлению изменениями .
• Управление. Определение потенциальных рисков управления для решения. Предвидите усилия, необходимые для эффективного использования решения пользователями, а также для устранения рисков управления (например, с помощью меток конфиденциальности и политик).

Начальная настройка поведения

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

• Начальные средства и процессы: сначала настройте новые средства и процессы, необходимые для разработки, тестирования и развертывания.
• Удостоверения и учетные данные: создание групп безопасности и субъектов-служб, которые будут использоваться для доступа к средствам и системам. Эффективное и безопасное хранение учетных данных.
• Шлюзы данных:развертывание шлюзов данных для локальных источников данных (шлюзы корпоративного режима) или источников данных в частной сети (виртуальная сеть или виртуальная сеть, шлюзы).
• Рабочие области и репозитории: создание и настройка рабочих областей и удаленных репозиториев для публикации и хранения содержимого.

Примечание.

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

Дополнительные сведения о планировании развертывания см. в статье "Планирование развертывания для миграции в Power BI".

Контрольный список . При планировании развертывания решения ключевые решения и действия включают:

• Планирование ключевых областей. План для решения процессов и средств, которые необходимо успешно разрабатывать и развертывать решение. Решение как технических областей (таких как шлюзы данных или рабочие области), так и внедрение (например, обучение пользователей и управление).
• Провести начальную настройку: создайте средства, процессы и компоненты, которые необходимо разработать и развернуть решение. Задокументируйте настройку, чтобы помочь другим пользователям, которым потребуется выполнить первую настройку в будущем.
• Проверка подключений к источнику данных: убедитесь, что необходимые компоненты и процессы установлены для подключения к правильным данным, чтобы начать подтверждение концепции.

Шаг 3. Проведение доказательства концепции

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

При подготовке POC рекомендуется учитывать следующие факторы.

• Цели и область. Описание цели POC решения и функциональных областей, которые будут решаться. Например, команда проектов может решить ограничить POC одной функциональной областью или определенным набором требований или функций.
• Исходные данные: определите, какие данные будут использоваться в POC. В зависимости от решения команда проектов может решить использовать различные типы данных, например:
  • Рабочие (реальные) данные
  • Демонстрационные данные
  • Созданные искусственные данные, похожие на фактические объемы данных и сложности, наблюдаемые в рабочих средах
• Демонстрация. Описание того, как и когда команда проектов продемонстрирует POC заинтересованным лицам и пользователям. Демонстрации могут быть предоставлены во время регулярных обновлений или когда POC выполняет определенные функциональные критерии.
• Среда. Описание того, где команда проектов создаст POC. Хороший подход — использовать отдельную среду песочницы для POC и развернуть ее в среде разработки, когда она будет готова. Среда песочницы имеет более гибкие политики и содержимое жидкости, и оно сосредоточено на создании быстрых результатов. В отличие от этого, среда разработки следует более структурированным процессам, которые обеспечивают совместную работу, и он фокусируется на выполнении конкретных задач.
• Критерии успешности. Определите пороговое значение, когда POC успешно выполнен и должен перейти к следующей итерации и ввести официальную разработку. Перед запуском POC группа проектов должна определить четкие критерии, когда POC успешно выполнен. Задав эти критерии заранее, команда проектов определяет, когда разработка POC заканчивается, а также когда начинаются итеративные циклы разработки и проверки. В зависимости от целей POC команда проекта может задать различные критерии успеха, такие как:
  • Утверждение POC заинтересованными лицами
  • Проверка функций или функций
  • Благоприятный обзор POC по одноранговым узлам после фиксированного времени разработки
• Сбой. Убедитесь, что команда проекта может определить сбой POC. Выявление сбоя на ранней стадии поможет изучить первопричины. Это также может помочь избежать дальнейших инвестиций в решение, которое не будет работать должным образом при развертывании в рабочей среде.

Внимание

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

Примечание.

Дополнительные сведения см. в статье "Подтверждение поведения" для миграции в Power BI.

Контрольный список . При создании POC ключевые решения и действия включают:

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

Шаг 4. Создание и проверка содержимого

При успешном выполнении POC команда проекта переходит от POC к созданию и проверке содержимого. Команда проектов может разработать решение бизнес-аналитики с помощью итеративных циклов разработки и проверки. Эти циклы состоят из итеративных выпусков, в которых команда проектов создает содержимое в среде разработки и освобождает его в тестовой среде. Во время разработки команда проектов постепенно внедряет сообщество пользователей в пилотный процесс до ранних (бета-версий) решения в тестовой среде.

Совет

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

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

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

На схеме показаны следующие шаги.

Элемент	Description
	Команда проектов сообщает каждому выпуску сообществу пользователей, описывая изменения и новые функции. В идеале взаимодействие включает демонстрацию решения и Q&A, поэтому пользователи понимают, что нового в выпуске, и они могут предоставлять словесные отзывы.
	Во время проверки пользователи предоставляют отзывы через центральное средство или форму. Группа проектов должна регулярно просматривать отзывы о проблемах, принимать или отклонять запросы и информировать предстоящие этапы разработки.
	Команда проектов отслеживает использование решения, чтобы убедиться, что пользователи тестируют его. Если нет использования, команда проектов должна взаимодействовать с сообществом пользователей, чтобы понять причины, почему. Низкое использование может указывать на то, что команде проектов необходимо принять дальнейшие действия по включению и управлению изменениями.
	Команда проектов оперативно реагирует на отзывы пользователей. Если команда проекта занимает слишком много времени для решения отзывов, пользователи могут быстро потерять мотивацию для предоставления.
	Группа проектов включает принятые отзывы в планирование решения. При необходимости они рассматривают приоритеты планирования, чтобы уточнить и делегировать задачи до начала следующего этапа разработки.
	Команда проектов продолжает разработку решения для следующего выпуска.
	Команда проекта выполняет итерацию по всем шагам, пока не достигнет предопределенного заключения, и решение готово к рабочему развертыванию.

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

Создание содержимого

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

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

Проверка содержимого

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

• Проверка разработчика: тестирование решений выполняется создателями содержимого и одноранговыми узлами. Цель проверки разработчика — определить и устранить все критически важные и видимые проблемы, прежде чем решение будет доступно для бизнес-пользователей. Проблемы могут относиться к правильности данных, функциональности или пользовательскому интерфейсу. В идеале содержимое проверяется создателем контента, который не разработал его.
• Проверка пользователей: тестирование решений выполняется сообществом пользователей. Целью проверки пользователей является предоставление отзывов о последующих итерациях и выявление проблем, которые не найдены разработчиками. Формальные периоды проверки пользователей обычно называются проверками принятия пользователей (UAT).

Важно!

Убедитесь, что все проблемы с качеством данных устраняются во время проверки разработчика (перед UAT). Эти проблемы могут быстро утерять доверие к решению, и они могут нанести ущерб долгосрочному внедрению.

Совет

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

Фактор в следующих соображениях, когда команда проекта проверяет содержимое.

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

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

Примечание.

Разработка и тестирование различаются в зависимости от решения и предпочтительного рабочего процесса.

В этой статье описываются только высокоуровневые элементы планирования и действия. Дополнительные сведения о итеративных циклах разработки и тестирования см. в статье "Создание содержимого для миграции в Power BI".

Контрольный список . При создании и проверке содержимого ключевые решения и действия включают:

• Итеративный процесс для планирования и назначения задач: планирование и назначение задач для каждого выпуска решения. Убедитесь, что процесс планирования и назначения задач является гибким и включает отзывы пользователей.
• Настройка управления жизненным циклом контента. Используйте средства и процессы для упрощения развертывания и автоматизации развертывания решений и управления изменениями.
• Создайте средство для централизации отзывов: автоматизация сбора отзывов с помощью решения, простого для вас и пользователей. Создайте простую форму, чтобы убедиться, что обратная связь является краткой, но доступной для действий.
• Запланируйте собрание для просмотра отзывов. Чтобы кратко просмотреть каждый новый или невыполненные элементы обратной связи. Определите, будет ли вы реализовывать отзыв или нет, кто будет отвечать за реализацию, и какие действия следует предпринять для закрытия элемента обратной связи.
• Решите, когда завершается итеративная доставка: опишите условия, когда циклы итеративной доставки завершятся, а также при выпуске содержимого в рабочую среду.

Шаг 5. Развертывание, поддержка и мониторинг

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

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

• Сообщите окончательный выпуск: исполнительный спонсор, менеджер или другой человек с достаточным авторитетом и доверием должен объявить о выпуске в сообществе пользователей. Обмен данными должен быть четким, кратким и включать ссылки на соответствующие решения и каналы поддержки.
• Обучение потребителей контента: обучение должно быть доступно для потребителей контента в течение первых недель после выпуска в рабочую среду. Обучение должно сосредоточиться на уточнении решения область, ответе на вопросы пользователей и объяснении способа использования решения.
• Адрес обратной связи и запросов. Рассмотрите возможность предоставления пользователям канала для отправки отзывов и запросов группе проектов. Убедитесь, что обсуждаются разумные отзывы и запросы, и при необходимости реализуются в течение периода поддержки после развертывания. Важно действовать с отзывом и запросами после выпуска рабочей среды. Это означает гибкое решение, которое отвечает на изменение бизнес-потребностей.
• План подключения к сообществу пользователей: даже после окончания периода поддержки после развертывания убедитесь, что владельцы решений регулярно встречаются с сообществом пользователей. Эти собрания являются ценными источниками отзывов о пересмотре стратегии бизнес-аналитики. Кроме того, они помогают поддерживать внедрение решений, включив пользователей.
• Действия передачи: члены группы проектов могут не отвечать за обслуживание решения. В этом случае команда должна определить, кто несет ответственность и выполнить передачу. Переход должен происходить вскоре после выпуска в рабочую среду, и он должен решать как решение, так и сообщество пользователей.

Внимание

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

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

Контрольный список . При рассмотрении развертывания решения ключевые решения и действия включают:

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

Связанный контент

Дополнительные рекомендации, действия, критерии принятия решений и рекомендации по внедрению Power BI см. в статье о планировании реализации Power BI.