Planificación de la implementación de Power BI: Planificación de la solución BI

Nota:

Este artículo forma parte de la serie de artículos sobre el planeamiento de la implementación de Power BI. Esta serie se centra principalmente en la carga de trabajo de Power BI dentro de Microsoft Fabric. Para obtener una introducción a la serie, consulte el planeamiento de la implementación de Power BI.

Este artículo le ayuda a planificar soluciones que respalden su estrategia de inteligencia empresarial (BI). Se dirige principalmente a:

• Directores o administradores de BI y análisis: responsables de la toma de decisiones encargados de supervisar el programa de BI y las soluciones de BI estratégicamente importantes.
• Centro de excelencia (COE), TI y equipos de BI: los equipos que diseñan e implementan soluciones empresariales de BI para su organización.
• Expertos en la materia (PYME) y propietarios y creadores de contenidos: los equipos y personas que lideran el análisis en un departamento y diseñan e implementan soluciones para escenarios de uso de autoservicio, departamentos de BI o equipos de BI.

Una estrategia de BI es un plan para implementar, usar y administrar datos y análisis. La estrategia de BI se define empezando por la planificación estratégica de BI. La planificación estratégica le ayuda a identificar sus áreas y objetivos de enfoque de BI. Para determinar el camino a seguir para alcanzar sus objetivos de BI, se describen resultados clave mediante la planificación táctica. A continuación, logre el progreso hacia sus resultados clave mediante la planificación e implementación de soluciones de BI.

Nota:

En el marco de los objetivos y resultados clave (OKR), los objetivos son descripciones claras y de alto nivel de lo que se quiere conseguir. Por el contrario, los resultados clave son resultados específicos y alcanzables para medir el progreso hacia uno de sus objetivos.

Además, las iniciativas o las soluciones son procesos o herramientas desarrollados para ayudarle a conseguir uno o varios resultados clave. Las soluciones abordan necesidades de datos específicas para los usuarios. Una solución puede adoptar muchas formas, como una canalización de datos, un almacén de lago de datos o un informe o modelo semántico de Power BI.

Para más información sobre los OKR, consulte Descripción de los OKR (Microsoft Viva Goals).

Existen muchos enfoques para planificar y aplicar soluciones de BI. En este artículo se describe un enfoque que puede adoptar para planificar e implementar soluciones de BI que admitan su estrategia de BI.

El siguiente diagrama de alto nivel muestra cómo llevar a cabo la planificación de soluciones de BI.

Para llevar a cabo la planificación de la solución BI, siga los siguientes pasos.

Step	Descripción
1	Formar un equipo de proyecto que reúna los requisitos y defina el diseño de la solución.
2	Planificar la implementación de la solución mediante la configuración inicial de herramientas y procesos.
3	Realice una prueba de concepto (POC) de la solución para validar las hipótesis sobre el diseño.
4	Cree y valide contenidos utilizando ciclos iterativos de desarrollo y validación.
5	Implemente, preste asistencia y supervise la solución una vez que se haya lanzado en el entorno de producción.

Nota:

La planificación de soluciones de BI se aplica tanto a los proyectos de BI de autoservicio como a los de BI empresarial.

Para obtener más información, consulte la serie de migración de Power BI. Aunque la serie se ocupa de la migración, las acciones y consideraciones clave son pertinentes para la planificación de soluciones.

Paso 1: Recopilar requisitos

La planificación de la solución comienza con la recopilación de requisitos y la definición del diseño de la solución.

Nota: la planificación estratégica y táctica está dirigida por un equipo de trabajo, que lidera la iniciativa. En cambio, la planificación de soluciones está dirigida por un equipo de proyecto, formado por propietarios y creadores de contenidos.

La recopilación de los requisitos adecuados es fundamental para lograr una implementación y adopción correctas de la solución. Una forma eficaz de recopilar requisitos es identificar e implicar a las partes interesadas adecuadas, definir en colaboración el problema que hay que resolver y utilizar esa comprensión compartida del problema para crear un diseño de solución.

Estas son algunas ventajas del uso de un enfoque colaborativo para recopilar requisitos.

• La entrada del usuario genera diseños más útiles: al atraer a los usuarios en discusiones centradas para recopilar requisitos, puede capturar de forma más eficaz las necesidades de datos empresariales. Por ejemplo, los usuarios pueden demostrar a los creadores de contenido cómo usan las soluciones existentes y proporcionar comentarios sobre la eficacia percibida de estas soluciones.
• Evite suposiciones y mitigue las solicitudes de cambio: las conversaciones con los usuarios suelen revelar matices, excepciones y complejidades ocultas. Estas conclusiones reducen la probabilidad de solicitudes de fase tardía, lo que puede resultar costoso de abordar.
• La incorporación de usuarios aumenta la adopción de soluciones: al implicar a los usuarios en el diseño y el desarrollo temprano, se les proporciona la oportunidad de influir en el resultado final. La participación también puede dar a los usuarios una idea de la propiedad intelectual y la responsabilidad de la solución. Los usuarios muy implicados tendrán más probabilidades de respaldar la solución y liderar su comunidad de práctica para utilizarla con eficacia.
• Los diseños crean expectativas para las partes interesadas y los usuarios: la elaboración de bocetos o ilustraciones del diseño de la solución permite mostrar claramente a las partes interesadas lo que ofrecerá la solución. También ayuda a crear una comprensión mutua del resultado esperado del proyecto. Este proceso también se conoce como pensamiento de diseño, y puede ser una forma eficaz de abordar y comprender problemas complejos.

Puede adoptar diferentes enfoques para atraer a los usuarios y recopilar requisitos. Por ejemplo, puede recopilar los requisitos con el diseño empresarial y el diseño técnico (descritos en detalle en secciones posteriores de este artículo).

El diseño empresarial es un enfoque para recopilar requisitos empresariales. Se centra en la participación de los usuarios empresariales en sesiones de diseño empresarial para diseñar la solución de forma colaborativa. La salida de un diseño empresarial consta de bocetos de soluciones y documentación de diseño descriptivo.

El diseño técnico es un enfoque para traducir los requisitos empresariales a los requisitos técnicos y abordar las suposiciones de diseño. Un diseño técnico se centra en validar el diseño empresarial y definir un enfoque técnico para su uso. Para validar el diseño, los creadores de contenidos suelen colaborar con expertos técnicos en debates específicos denominados sesiones de diseño técnico, cuando es necesario.

Importante

Recopilar los requisitos incorrectos es una razón común por la que se produce un error en las implementaciones. A menudo, los equipos recopilan requisitos incorrectos porque se ponen en contacto con las partes interesadas equivocadas, como los responsables de la toma de decisiones, que solicitan de forma vertical que se construyan soluciones.

La participación de los usuarios empresariales mediante enfoques de colaboración como un diseño empresarial puede ayudarle a recopilar mejores requisitos. Unos mejores requisitos suelen conducir a un desarrollo más eficaz y a soluciones más sólidas.

Nota:

Para algunos equipos, la adopción de un proceso de recopilación de requisitos estructurados es un gran cambio. Asegúrese de gestionar este cambio y de que no interrumpa la planificación de la solución. Le recomendamos que encuentre formas de adaptar estos enfoques para que se ajusten a la forma en que trabaja su equipo.

Preparar la planificación de soluciones

En primer lugar, debe prepararse para la planificación de la solución teniendo en cuenta los factores descritos en las siguientes secciones.

• Identificar quién llevará a cabo la planificación de soluciones: Como parte de la planificación táctica de BI, el equipo de trabajo creó una lista de soluciones prioritarias. En la planificación de soluciones, un equipo de proyecto se encarga de diseñar, desarrollar e implementar una o varias soluciones del trabajo pendiente. Para cada solución del trabajo pendiente, debe formar un equipo de proyecto que será responsable de la solución. Además de ejecutar la planificación de soluciones de BI, el equipo del proyecto debe:
  • Defina escalas de tiempo e hitos para la planificación de soluciones.
  • Identifique e implique a las partes interesadas adecuadas para la recopilación de requisitos.
  • Configure una ubicación centralizada para la comunicación, la documentación y la planificación.
  • Interactúe con las partes interesadas para recopilar los requisitos.
  • Comunicarse y coordinarse con las partes interesadas y los usuarios empresariales.
  • Organice ciclos iterativos de desarrollo y pruebas con usuarios empresariales.
  • Documentación de la solución.
  • Incorpore usuarios a la solución definiendo y aplicando un plan de aprendizaje.
  • Proporcionar compatibilidad con soluciones posteriores a la implementación.
  • Solucione las solicitudes de usuario razonables para cambiar o actualizar la solución después de la implementación.
  • Realice la entrega de la solución después de la implementación, si es necesario.
• Centralizar la comunicación y la documentación: es importante que el equipo del proyecto centralice la comunicación y la documentación para la planificación de soluciones de BI. Por ejemplo, el equipo del proyecto debe centralizar los requisitos, la comunicación de las partes interesadas, las escalas de tiempo y las entregas. Considere la posibilidad de almacenar toda la documentación en un portal centralizado.
• Recopilación de requisitos del plan: el equipo del proyecto debe empezar por planificar las sesiones de diseño empresarial para recopilar los requisitos empresariales. Estas sesiones adoptan la forma de reuniones interactivas y pueden seguir un formato similar a los talleres de planificación estratégica.

Sugerencia

Considere la posibilidad de identificar e implicar a los equipos de asistencia responsables de la solución en una fase temprana del proceso de recopilación de requisitos. Para admitir eficazmente la solución, los equipos de soporte técnico necesitarán una comprensión completa de la solución, su propósito y los usuarios. Esto es especialmente importante cuando el equipo del proyecto está compuesto únicamente por consultores externos.

Recopilación de requisitos empresariales

Recopilar los requisitos empresariales correctos es fundamental para diseñar la solución adecuada. Para reunir los requisitos adecuados y definir un diseño de solución eficaz, el equipo del proyecto puede llevar a cabo sesiones de diseño empresarial junto con los usuarios de la empresa.

El propósito de las sesiones de diseño empresarial es:

• Confirme el ámbito de la solución inicial.
• Definir y comprender el problema que debe abordar la solución.
• Identificar a las partes interesadas clave en la solución.
• Recopilar los requisitos empresariales adecuados.
• Preparar un diseño de solución que cumpla los requisitos empresariales.
• Preparar la documentación auxiliar de diseño.

El siguiente diagrama muestra cómo recopilar los requisitos empresariales y definir el diseño de la solución utilizando un enfoque de diseño empresarial.

El diagrama muestra los siguientes pasos.

Elemento	Descripción
	El equipo del proyecto comienza el diseño empresarial confirmando el ámbito de la solución que se documentó por primera vez en la planificación táctica. Deben aclarar las áreas de negocio, los sistemas y los datos que abarcará la solución.
	El equipo del proyecto identifica a las partes interesadas clave de la comunidad de usuarios que participarán en las sesiones de diseño empresarial. Las partes interesadas clave son usuarios con conocimientos y credibilidad suficientes para representar las áreas temáticas de la solución.
	El equipo del proyecto planea sesiones de diseño empresarial. La planificación implica informar a las partes interesadas, organizar reuniones, preparar entregas e interactuar con los usuarios empresariales.
	El equipo del proyecto recopila e investiga las soluciones existentes que los usuarios empresariales usan actualmente para satisfacer las necesidades de datos empresariales existentes. Para acelerar este proceso, el equipo del proyecto puede utilizar la investigación pertinente de la planificación estratégica de BI, que se ha documentado en el centro de comunicación.
	El equipo del proyecto ejecuta sesiones de diseño empresarial con las partes interesadas. Estas sesiones son reuniones pequeñas e interactivas, donde el equipo del proyecto guía a las partes interesadas para comprender las necesidades y los requisitos de los datos empresariales.
	El equipo del proyecto concluye el diseño empresarial presentando un borrador del diseño de la solución a las partes interesadas y otros usuarios para obtener su opinión y aprobación. El diseño empresarial tiene éxito cuando las partes interesadas están de acuerdo en que el diseño les ayudará a alcanzar sus objetivos empresariales.

El diseño empresarial concluye con los siguientes entregables.

• Borradores de diseños de soluciones: los bocetos, prototipos o diagramas de contorno reticular ilustran el diseño de la solución. Estos documentos traducen los requisitos en un proyecto de diseño concreto.
• Lista de métricas empresariales: campos cuantitativos previstos en la solución, incluidas las definiciones empresariales, y agregaciones previstas. Si es posible, clasifíquelos por importancia para los usuarios.
• Lista de atributos empresariales: atributos relevantes y estructuras de datos esperados en la solución, incluidas las definiciones de negocio y los nombres de los atributos. Si es posible, incluya jerarquías y clasifique los atributos por importancia para los usuarios.
• Documentación complementaria: descripciones de los requisitos funcionales o de cumplimiento clave. Esta documentación debe ser tan precisa como sea necesario, pero tan concisa como sea posible.

Los resultados del diseño empresarial se utilizan y validan en el diseño técnico.

Sugerencia

Los bocetos de soluciones, prototipos o diagramas alámbricos pueden crear una clara comprensión del resultado esperado, tanto para los desarrolladores como para los usuarios finales. La creación de maquetas eficaces no requiere habilidades o talento artístico. Puede utilizar herramientas sencillas como Microsoft Whiteboard, PowerPoint, o incluso simplemente un lápiz y un papel para ilustrar el diseño.

Recopilación de requisitos técnicos

Tras completar el diseño empresarial, el equipo del proyecto valida sus resultados mediante un diseño técnico. El diseño técnico es un enfoque similar al diseño empresarial. Aunque el diseño empresarial se centra en las necesidades de datos empresariales, el diseño técnico se centra en los aspectos técnicos de una solución. Un resultado clave del diseño técnico es el plan de soluciones, que describe el diseño final de la solución y estimaciones fundamentadas del esfuerzo necesario para implementarla.

Nota:

A diferencia del diseño empresarial, el diseño técnico es en gran medida una investigación independiente sobre los datos de origen y los sistemas llevados a cabo por creadores y propietarios de contenido.

El propósito de un diseño técnico es:

• Valide los resultados del diseño empresarial.
• Abordar suposiciones técnicas en el diseño actual.
• Identifique los orígenes de datos pertinentes en el ámbito de aplicación y defina los cálculos de campo y las asignaciones campo-fuente para cada origen de datos.
• Convierta los requisitos empresariales en requisitos técnicos.
• Genere estimaciones del esfuerzo necesario para la implementación.

El equipo del proyecto involucra a las partes interesadas técnicas o funcionales en sesiones de diseño técnico limitadas y centradas. Estas sesiones son reuniones interactivas con las partes interesadas funcionales para recopilar requisitos técnicos. Las partes interesadas son responsables de las áreas funcionales específicas necesarias para que la solución funcione de forma eficaz.

Ejemplos de partes interesadas en un diseño técnico podrían ser:

• Equipos de seguridad y redes: responsables de garantizar la seguridad y el cumplimiento de los datos.
• Equipos funcionales y administradores de datos: responsables de la conservación de los datos de origen.
• Arquitectos: propietarios de plataformas, herramientas o tecnología específicas.

El equipo del proyecto reúne a las partes interesadas en sesiones de diseño técnico para abordar los aspectos técnicos de la solución. Los aspectos técnicos pueden incluir:

• Conexiones de origen de datos: detalles sobre cómo conectarse a orígenes de datos e integrarlos.
• Redes y puertas de enlace de datos: detalles sobre redes privadas u orígenes de datos locales.
• Asignación de origen de campo: asignaciones de datos de métricas empresariales y atributos a campos de origen de datos.
• Lógica de cálculo: conversión de definiciones empresariales en cálculos técnicos.
• Características técnicas: características o funcionalidades necesarias para admitir los requisitos empresariales.

Sugerencia

El equipo del proyecto que realizó el diseño empresarial también debe realizar el diseño técnico. Sin embargo, por motivos prácticos, diferentes individuos podrían dirigir el diseño técnico. En este caso, comience el diseño técnico revisando los resultados del diseño empresarial.

Lo ideal es que las personas que dirigen el diseño técnico conozcan a fondo los resultados y los usuarios empresariales.

En el diagrama siguiente se muestra cómo convertir los requisitos empresariales en requisitos técnicos mediante un diseño técnico.

El diagrama muestra los siguientes pasos.

Elemento	Descripción
	El equipo del proyecto comienza el diseño técnico definiendo el ámbito del origen de datos basándose en los resultados del diseño empresarial. El ámbito del origen de datos declara qué datos son necesarios para compilar la solución. Para identificar los orígenes de datos correctos, el equipo del proyecto consulta con las SME empresariales y funcionales.
	El equipo del proyecto identifica a las partes interesadas técnicas o funcionales para que participen más adelante en las sesiones de diseño técnico.
	El equipo del proyecto planifica sesiones limitadas y centradas con las partes interesadas funcionales para abordar los aspectos técnicos de la solución. La planificación implica informar a las partes interesadas, organizar reuniones y preparar entregas.
	El equipo del proyecto investiga los requisitos técnicos. La investigación incluye la definición de cálculos de campo y asignaciones de orígenes de datos, así como el tratamiento de los supuestos de diseño empresarial con análisis y documentación técnica.
	Si es necesario, el equipo del proyecto implica a las partes interesadas en sesiones de diseño técnico. Las sesiones se centran en un aspecto técnico específico de la solución, como la seguridad o las conexiones de orígenes de datos. En estas sesiones, el equipo del proyecto recopila comentarios cualitativos de las partes interesadas y las SME.
	El equipo del proyecto prepara sus conclusiones mediante un plan de soluciones, que presenta a las partes interesadas y a los responsables de la toma de decisiones. El plan es una iteración y extensión de los resultados del diseño empresarial que incluye el diseño final, las estimaciones y otros entregables.
	El diseño técnico debe concluir con una reunión final con las partes interesadas y los responsables de la toma de decisiones para decidir si continuar o no. Esta reunión proporciona una oportunidad final para evaluar la planificación de la solución antes de que los recursos se comprometan a desarrollar la solución.

Nota:

El diseño técnico podría revelar una complejidad inesperada que podría hacer inviable la planificación de la solución dada la disponibilidad actual de recursos o la preparación organizativa. En este caso, la solución deberá reevaluarse en el siguiente periodo de planificación táctica. Dependiendo de la urgencia de las necesidades de los datos empresariales, un responsable de toma de decisiones, como el patrocinador ejecutivo, podría querer continuar con una prueba de concepto o solo una parte de la solución planeada.

El diseño técnico concluye con un plan de solución, que consta de los siguientes entregables.

• Herramientas y tecnologías: lista de los instrumentos técnicos pertinentes necesarios para implementar la solución. Normalmente, la lista incluye nuevas opciones de licencia relevantes (como capacidad de Fabric o Premium por usuario), características y herramientas.
• Lista definida de métricas empresariales: cálculos y asignaciones de origen de campo de las métricas empresariales para todos los orígenes de datos incluidos. Para generar esta entrega, el equipo del proyecto usa la lista de métricas empresariales creadas en el diseño empresarial.
• Lista definida de atributos empresariales: asignaciones de origen de campo de los atributos empresariales para todos los orígenes de datos dentro del ámbito. Para generar este entregable, el equipo del proyecto utiliza la lista de atributos empresariales creada en el diseño empresarial.
• Diseños revisados: revisiones del diseño de la solución basadas en cambios o suposiciones no válidas sobre el diseño empresarial. Los diseños revisados son versiones actualizadas de los bocetos, prototipos o diagramas de contorno reticular producidos en el diseño empresarial. Si no es necesario realizar ninguna revisión, comunique que el diseño técnico valida el diseño empresarial.
• Estimación del esfuerzo: estimación de los recursos necesarios para desarrollar, respaldar y mantener la solución. La estimación informa de la decisión final sobre si se procede o no a implementar la solución.

Importante

Asegúrese de que el equipo del proyecto notifica a las partes interesadas los cambios o descubrimientos inesperados del diseño técnico. Estas sesiones de diseño técnico deben seguir implicando a los usuarios empresariales pertinentes. Sin embargo, asegúrese de que las partes interesadas no se exponen innecesariamente a información técnica compleja.

Sugerencia

Dado que los objetivos empresariales evolucionan invariablemente, se espera que los requisitos cambien. No asuma que los requisitos de los proyectos de BI son fijos. Si tiene dificultades para cambiar los requisitos, podría ser una señal de que su proceso de recopilación de requisitos no es eficaz o de que sus flujos de trabajo de desarrollo no incorporan suficientemente los comentarios periódicos.

Lista de comprobación: al recopilar requisitos, las decisiones y acciones clave incluyen:

• Determine quién es el responsable de planificar la solución: para cada solución, asegúrese de que los roles y responsabilidades están claros para el equipo del proyecto.
• Determinar el ámbito de la solución: el ámbito de la solución ya debería estar documentado como parte de la planificación táctica de BI. Es posible que tenga que dedicar más tiempo y esfuerzo para aclarar el ámbito antes de iniciar el planeamiento de la solución.
• Identificar e informar a las partes interesadas: identifique a las partes interesadas para diseños empresariales y diseños técnicos. Informe de antemano sobre el proyecto y explique el ámbito, los objetivos, la inversión de tiempo necesaria y las entregas del diseño empresarial.
• Planificar y llevar a cabo sesiones de diseño empresarial: moderar las sesiones de diseño empresarial para obtener información de las partes interesadas y los usuarios de la empresa. Solicite a los usuarios que muestren cómo usan las soluciones existentes.
• Documente las métricas y los atributos empresariales: mediante el uso de las soluciones existentes y la entrada de las partes interesadas, cree una lista de métricas y atributos empresariales. En los diseños técnicos, asigne los campos al origen de datos y describa la lógica de cálculo para los campos cuantitativos.
• Borrador del diseño de la solución: cree bocetos iterativos basados en la entrada de las partes interesadas que reflejen visualmente el resultado esperado de la solución. Asegúrese de que los bocetos representan y abordan con precisión los requisitos empresariales. Comunique a los usuarios empresariales que los bocetos deben validarse (y posiblemente revisarse) durante el diseño técnico.
• Cree el plan de solución: investigue los datos de origen y las consideraciones técnicas pertinentes para garantizar que el diseño empresarial sea factible. Cuando sea pertinente, describa los riesgos y amenazas clave para el diseño y cualquier enfoque alternativo. Si es necesario, prepare una revisión del diseño de la solución y hable con las partes interesadas.
• Crear estimaciones del esfuerzo: como parte del plan de solución final, calcule el esfuerzo para crear y mantener la solución. Justifique estas estimaciones con la información recopilada durante las sesiones de diseño empresarial y diseño técnico.
• Decida si desea continuar con el plan: para concluir el proceso de recopilación de requisitos, presente el plan final a las partes interesadas y a los responsables de la toma de decisiones. El propósito de esta reunión es determinar si se debe continuar con el desarrollo de soluciones.

Paso 2: planificar la implementación

Cuando el equipo del proyecto termina de recopilar los requisitos, crear el plan de solución y recibir la aprobación para continuar, está listo para planificar la implementación de la solución.

Las tareas de planificación de la implementación varían en función de la solución, el flujo de trabajo de desarrollo y el proceso de implementación. Un plan de implementación suele pertenecer a muchas actividades relacionadas con la planificación y la configuración de herramientas y procesos para la solución.

Plan para abordar las áreas clave

El equipo del proyecto debe planificar las áreas clave de la implementación de la solución. Normalmente, la planificación debe abordar las siguientes áreas.

• Cumplimiento: asegúrese de que todos los criterios de cumplimiento identificados en la recopilación de requisitos se abordarán mediante acciones específicas. Asigne cada una de estas acciones a personas específicas y defina claramente el período de tiempo de entrega.
• Seguridad: decida cómo se administrarán las distintas capas de acceso a la solución y los requisitos de las reglas de seguridad de datos. Revise si la seguridad de la solución será más o menos estricta que el contenido estándar del inquilino.
• Puertas de enlace de datos: evalúe si la solución necesita una puerta de enlace de datos para conectarse a orígenes de datos. Determine si es necesario especificar la configuración de puerta de enlace o los clústeres de alta disponibilidad. Planee quién podrá administrar las conexiones de puerta de enlace a través de los roles de seguridad de puerta de enlace y cómo supervisar las puertas de enlace. Para obtener más información, consulte Aprovisionamiento del acceso a la puerta de enlace.
• Áreas de trabajo: decida cómo configurar y usar áreas de trabajo. Determine si la solución requiere herramientas de administración del ciclo de vida, como la integración de Git y las canalizaciones de implementación, y si requiere un registro avanzado con Azure Log Analytics.
• Soporte técnico: establezca quién es responsable de dar soporte y mantener la solución después de la implementación de producción. Si las personas responsables del soporte técnico son diferentes de las del equipo del proyecto, implique a estas personas en el desarrollo. Asegúrese de que quien admita la solución comprenda el diseño de la solución, el problema que debe abordar, quién debe usarla y cómo.
• Aprendizaje del usuario: anticipe los esfuerzos necesarios para entrenar a la comunidad de usuarios para que puedan usar la solución de forma eficaz. Tenga en cuenta si es necesario realizar acciones específicas de administración de cambios.
• Gobernanza: identifique los posibles riesgos de gobernanza para la solución. Anticipe el esfuerzo necesario para permitir que los usuarios usen eficazmente la solución, a la vez que mitiga cualquier riesgo de gobernanza (por ejemplo, mediante el uso de etiquetas y directivas de confidencialidad).

Realización de la configuración inicial

El equipo del proyecto debe realizar la configuración inicial para comenzar el desarrollo. Las actividades de configuración iniciales pueden incluir:

• Herramientas y procesos iniciales: realice la configuración inicial de las nuevas herramientas y procesos necesarios para el desarrollo, las pruebas y la implementación.
• Identidades y credenciales: cree grupos de seguridad y entidades de servicio que se usarán para acceder a herramientas y sistemas. Almacene las credenciales de forma eficaz y segura.
• Puertas de enlace de datos:implemente puertas de enlace de datos para orígenes de datos locales (puertas de enlace de modo de empresa) u orígenes de datos en una red privada (redes virtuales o VNet, puertas de enlace).
• Áreas de trabajo y repositorios: cree y configure áreas de trabajo y repositorios remotos para publicar y almacenar contenido.

Nota:

La planificación de la implementación varía en función de la solución y el flujo de trabajo que prefiera. En este artículo solo se describe la planificación de alto nivel y los elementos que requieren acción.

Para obtener más información sobre la planificación de la implementación, consulte |Planificar la implementación para migrar a Power BI.

Lista de comprobación: al planificar la implementación de soluciones, las decisiones y acciones clave incluyen:

• Planificar las áreas clave: planifique los procesos y herramientas que necesita para desarrollar e implementar con éxito su solución. Aborde ambas áreas técnicas (como puertas de enlace de datos o áreas de trabajo) y también la adopción (como el aprendizaje y la gobernanza de usuarios).
• Realice la configuración inicial: establezca las herramientas, los procesos y las características que necesita para desarrollar e implementar la solución. Documente la configuración para ayudar a otras personas que tendrán que realizar una configuración por primera vez en el futuro.
• Probar conexiones de origen de datos: valide que los componentes y procesos adecuados están en su lugar para conectarse a los datos correctos para iniciar la prueba de concepto.

Paso 3: Realizar una prueba de concepto

El equipo del proyecto lleva a cabo una prueba de concepto (POC) de la solución para validar suposiciones pendientes y demostrar las primeras ventajas para los usuarios empresariales. Una POC es una implementación de diseño inicial que está limitada en el ámbito y la madurez. Una POC bien ejecutada es especialmente importante para las soluciones grandes o complejas, ya que puede identificar y abordar las complejidades (o excepciones) que no se detectaron en el diseño técnico.

Se recomienda tener en cuenta las siguientes consideraciones al preparar una POC.

• Objetivos y ámbito: describa el propósito de la POC de la solución y las áreas funcionales que abordará. Por ejemplo, el equipo del proyecto podría decidir limitar el POC a un único área funcional o a un conjunto específico de requisitos o características.
• Origen de datos: identifique qué datos se usarán en la POC. En función de la solución, el equipo del proyecto podría decidir usar diferentes tipos de datos, como:
  • Datos de producción (reales)
  • Datos de ejemplo
  • Datos sintéticos generados similares a los volúmenes de datos reales y la complejidad observada en entornos de producción
• Demostración: describa cómo y cuándo el equipo del proyecto mostrará la POC a las partes interesadas y los usuarios. Se podrían dar demostraciones durante las actualizaciones periódicas o cuando la POC cumple criterios funcionales específicos.
• Entorno: describa dónde creará el equipo del proyecto la POC. Un buen enfoque consiste en usar un entorno de espacio aislado distinto para la POC e implementarlo en un entorno de desarrollo cuando esté listo. Un entorno de espacio aislado tiene directivas más flexibles y contenido fluido, y se centra en generar resultados rápidos. En cambio, un entorno de desarrollo sigue procesos más estructurados que permiten la colaboración y se centra en completar tareas específicas.
• Criterios de éxito: defina el umbral para cuando la POC sea correcta y debe pasar a la siguiente iteración y entrar en el desarrollo formal. Antes de iniciar el POC, el equipo del proyecto debe establecer criterios claros para determinar si el POC tiene éxito. Al establecer estos criterios de antemano, el equipo del proyecto define cuándo finaliza el desarrollo de la POC y cuándo comienzan los ciclos iterativos de desarrollo y validación. En función de los objetivos de la POC, el equipo del proyecto podría establecer distintos criterios de éxito, como:
  • Aprobación de la POC por parte de las partes interesadas
  • Validación de características o funcionalidad
  • Revisión favorable de la POC por parte de elementos del mismo nivel después de un tiempo de desarrollo fijo
• Error: asegúrese de que el equipo del proyecto pueda identificar el error de la POC. La identificación temprana del error ayudará a investigar las causas principales. También puede ayudar a evitar una mayor inversión en una solución que no funcionará según lo previsto cuando se implemente en producción.

Precaución

Cuando el equipo del proyecto lleva a cabo la POC, debe permanecer alerta para suposiciones y limitaciones. Por ejemplo, el equipo del proyecto no puede probar fácilmente el rendimiento de la solución y la calidad de los datos mediante un pequeño conjunto de datos. Además, asegúrese de que el ámbito y el propósito de la POC sean claros para los usuarios empresariales. Asegúrese de comunicar que el POC es una primera iteración y haga hincapié en que no es una solución de producción.

Nota:

Para obtener más información, vea Realizar una prueba de concepto para migrar a Power BI.

Lista de comprobación: al crear una POC, las decisiones y acciones clave incluyen:

• Definir los objetivos: asegúrese de que los objetivos de la POC estén claros para todas las personas implicadas.
• Definir el ámbito de la POC: asegúrese de que la creación del POC no requiera demasiado esfuerzo de desarrollo, al tiempo que proporciona valor y demuestra el diseño de la solución.
• Decida qué datos se usarán: identifique qué datos de origen utilizará para realizar la POC, justificando su decisión y exponiendo los posibles riesgos y limitaciones.
• Decida cuándo y cómo demostrar la POC: planee mostrar el progreso presentando la POC a los responsables de la toma de decisiones y a los usuarios empresariales.
• Aclare cuándo finaliza la POC: asegúrese de que el equipo del proyecto decida una conclusión clara para la POC y describa cómo se promoverá a ciclos de desarrollo formales.

Paso 4: Crear y validar contenido

Cuando la POC se realiza correctamente, el equipo del proyecto pasa de la POC a crear y validar contenido. El equipo del proyecto puede desarrollar la solución de BI con ciclos iterativos de desarrollo y validación. Estos ciclos constan de versiones iterativas, donde el equipo del proyecto crea contenido en un entorno de desarrollo y lo publica en un entorno de prueba. Durante el desarrollo, el equipo del proyecto incorpora gradualmente la comunidad de usuarios en un proceso piloto a las primeras versiones (beta) de la solución en el entorno de prueba.

Sugerencia

La entrega iterativa fomenta la validación y la retroalimentación tempranas que pueden mitigar las solicitudes de cambio, promover la adopción de soluciones y obtener beneficios antes del lanzamiento de producción.

Los ciclos iterativos de desarrollo y validación continúan hasta que el equipo del proyecto llega a una conclusión predefinida. Normalmente, el desarrollo concluye cuando ya no hay más funciones que implementar o comentarios de los usuarios que abordar. Cuando finalizan los ciclos de desarrollo y validación, el equipo del proyecto implementa el contenido en un entorno de producción con el lanzamiento de producción final.

El siguiente diagrama muestra cómo el equipo del proyecto puede ofrecer de forma iterativa soluciones de BI con ciclos de desarrollo y validación.

El diagrama muestra los siguientes pasos.

Elemento	Descripción
	El equipo del proyecto comunica cada lanzamiento a la comunidad de usuarios, describiendo los cambios y las nuevas características. Idealmente, la comunicación incluye una demostración de la solución y Q&A, para que los usuarios comprendan las novedades del lanzamiento y puedan proporcionar comentarios verbales.
	Durante la validación, los usuarios proporcionan comentarios a través de un formulario o herramienta central. El equipo del proyecto debe revisar periódicamente los comentarios para resolver problemas, aceptar o rechazar solicitudes e informar sobre las próximas fases de desarrollo.
	El equipo del proyecto supervisa el uso de la solución para confirmar que los usuarios la están probando. Si no hay ningún uso, el equipo del proyecto debe comprometerse con la comunidad de usuarios para entender las razones. Un uso bajo puede indicar que el equipo del proyecto debe realizar más acciones de habilitación y administración de cambios.
	El equipo del proyecto responde rápidamente a los comentarios de los usuarios. Si el equipo del proyecto tarda demasiado en abordar los comentarios, los usuarios podrían perder rápidamente la motivación para proporcionarlos.
	El equipo del proyecto incorpora los comentarios aceptados en la planificación de la solución. Si es necesario, revisan las prioridades de planificación para aclarar y delegar tareas antes de que comience la siguiente fase de desarrollo
	El equipo del proyecto continúa desarrollando la solución para el próximo lanzamiento.
	El equipo del proyecto recorre en iteración todos los pasos hasta llegar a una conclusión predefinida y la solución está lista para la implementación de producción.

Las siguientes secciones describen las consideraciones clave para utilizar ciclos iterativos de desarrollo y validación para ofrecer soluciones de BI.

Crear contenido

El equipo del proyecto desarrolla la solución siguiendo su flujo de trabajo de desarrollo habitual. Sin embargo, deben tener en cuenta los siguientes puntos al crear contenido.

• Durante cada ciclo de desarrollo, actualice la documentación para describir la solución.
• Concluye cada ciclo de desarrollo con un anuncio para la comunidad de usuarios. Los anuncios deben publicarse en el portal centralizado e incluir breves descripciones de los cambios y novedades de cada lanzamiento.
• Con cada lanzamiento, considere la posibilidad de organizar sesiones para demostrar los cambios y las nuevas características a la comunidad de usuarios, y para responder a cualquier pregunta verbal.
• Defina cuándo concluirán los ciclos iterativos de desarrollo y validación. Asegúrese de que existe un proceso claro para implementar la solución en el entorno de producción, incluida una transición a las actividades de asistencia y adopción.

Validar contenido

Cada ciclo de desarrollo iterativo debe concluir con la validación de contenido. En el caso de las soluciones de BI, normalmente hay dos tipos de validación.

• Validación del desarrollador: Las pruebas de soluciones las realizan los creadores de contenidos y sus compañeros. El propósito de la validación del desarrollador es identificar y resolver todos los problemas críticos y visibles antes de que la solución esté disponible para los usuarios empresariales. Los problemas pueden estar relacionados con la corrección de datos, la funcionalidad o la experiencia del usuario. Idealmente, el contenido lo valida un creador de contenido que no lo desarrolló.
• Validación de usuario: la comunidad de usuarios se encarga de probar las soluciones. El propósito de la validación del usuario es proporcionar comentarios para iteraciones posteriores e identificar los problemas que no encontraron los desarrolladores. Los períodos de validación de usuarios formales se conocen normalmente como pruebas de aceptación de usuario (UAT).

Importante

Asegúrese de que se solucione cualquier problema de calidad de los datos durante la validación del desarrollador (antes de UAT). Estos problemas pueden afectar rápidamente a la confianza en la solución y pueden dañar la adopción a largo plazo.

Sugerencia

Al realizar la validación de usuarios, considere la posibilidad de realizar llamadas breves ocasionales con usuarios clave. Observe cuándo usan la solución. Toma nota de lo que les resulta difícil de usar o de qué partes de la solución no funcionan como esperaban. Este enfoque puede ser una manera eficaz de recopilar comentarios.

Tenga en cuenta las siguientes consideraciones cuando el equipo del proyecto valide el contenido.

• Anime a los usuarios a enviar comentarios: con cada lanzamiento, solicite a los usuarios que proporcionen comentarios y demuestren cómo pueden hacerlo de forma eficaz. Considere la posibilidad de compartir periódicamente ejemplos de comentarios y solicitudes que han provocado cambios recientes y nuevas características. Al compartir ejemplos, está demostrando que los comentarios se reconocen y se valoren.
• Aislar solicitudes más grandes: algunos elementos de comentarios requieren más esfuerzo para abordar. Asegúrese de que el equipo del proyecto puede identificar estos elementos y analizar si se implementarán o no. Considere la posibilidad de documentar solicitudes más grandes para analizar en sesiones de planificación tácticas posteriores.
• Iniciar actividades de administración de cambios: entrenar a los usuarios cómo usar la solución. Asegúrese de dedicar un esfuerzo adicional a nuevos procesos, nuevos datos y diferentes formas de trabajar. Invertir en la administración de cambios tiene un retorno positivo en la adopción de soluciones a largo plazo.

Cuando la solución alcanza un nivel predefinido de integridad y madurez, el equipo del proyecto está listo para implementarla en producción. Después de la implementación, el equipo del proyecto pasa de la entrega iterativa a admitir y supervisar la solución de producción.

Nota:

El desarrollo y las pruebas varían en función de la solución y del flujo de trabajo que prefiera.

En este artículo solo se describen la planificación de alto nivel y los elementos que requieren acción. Para obtener más información sobre los ciclos iterativos de desarrollo y pruebas, consulteCrear contenido para migrar a Power BI.

Lista de comprobación: al crear y validar contenido, las decisiones y acciones clave incluyen:

• Use un proceso iterativo para planificar y asignar tareas: planifique y asigne tareas para cada lanzamiento de la solución. Asegúrese de que el proceso para planificar y asignar tareas sea flexible e incorpore comentarios de los usuarios.
• Configurar la administración del ciclo de vida del contenido: use herramientas y procesos para simplificar y automatizar la implementación de soluciones y la administración de cambios.
• Cree una herramienta para centralizar los comentarios: automatice la recopilación de comentarios mediante una solución que sea sencilla para usted y sus usuarios. Cree un formulario sencillo para asegurarse de que los comentarios sean concisos pero accionables.
• Programar una reunión para revisar los comentarios: reúnase para revisar brevemente cada elemento de comentarios nuevo o pendiente. Decida si va a implementar los comentarios o no, quién será responsable de la implementación y qué acciones realizar para cerrar el elemento de comentarios.
• Decida cuándo concluye la entrega iterativa: describa las condiciones para cuándo terminarán los ciclos de entrega iterativos y cuándo publicará contenido en el entorno de producción.

Paso 5: implementación, soporte técnico y supervisión

Cuando está listo, el equipo del proyecto implementa la solución validada en el entorno de producción. El equipo del proyecto debe tomar medidas clave de adopción y soporte técnico para asegurarse de que la implementación se realiza correctamente.

Para garantizar una implementación correcta, realice las siguientes tareas de soporte técnico y adopción.

• Comunique el lanzamiento final: el patrocinador ejecutivo, un administrador u otra persona con autoridad y autorización suficientes deben anunciar el lanzamiento a la comunidad de usuarios. La comunicación debe ser clara, concisa e incluir vínculos a las soluciones y los canales de soporte técnico pertinentes.
• Realizar cursos para consumidores de contenido: el aprendizaje debe estar disponible para los consumidores de contenido durante las primeras semanas después del lanzamiento a producción. El aprendizaje debe centrarse en aclarar el ámbito de la solución, responder a las preguntas de los usuarios y explicar cómo usar la solución.
• Abordar comentarios y solicitudes: considere la posibilidad de proporcionar a los usuarios un canal para enviar comentarios y solicitudes al equipo del proyecto. Asegúrese de que se describen los comentarios y las solicitudes razonables y, cuando corresponda, se implementan durante el período de soporte técnico posterior a la implementación. Actuar sobre los comentarios y las solicitudes después del lanzamiento de producción es importante. Indica una solución ágil que responde a las cambiantes necesidades empresariales.
• Planifique la conexión con la comunidad de usuarios: incluso después de que finalice el periodo de asistencia posterior a la implementación, asegúrese de que los propietarios de la solución se reúnen periódicamente con la comunidad de usuarios. Estas reuniones son valiosas fuentes de comentarios para revisar la estrategia de BI. Además, ayudan a admitir la adopción de soluciones habilitando a los usuarios.
• Acciones de entrega: es posible que los miembros del equipo del proyecto no sean responsables de mantener la solución. En este caso, el equipo debe identificar al responsable y realizar una entrega. La entrega debe producirse poco después del lanzamiento a producción y debe abordar tanto la solución como la comunidad de usuarios.

Precaución

Si no se lleva a cabo una entrega eficaz, es posible que se produzcan problemas evitables con el soporte y la adopción de soluciones durante su ciclo de vida.

Después de la implementación, el equipo del proyecto debe planificar pasar a la siguiente solución en el trabajo pendiente de la solución prioritaria. Asegúrese de recopilar los nuevos comentarios y solicitudes y, si es necesario, revise la planificación táctica, incluida la lista de soluciones pendientes.

Lista de comprobación: al considerar la implementación de soluciones, las decisiones y acciones clave incluyen:

• Crear un plan de comunicación: planifique cómo comunicar el lanzamiento, el entrenamiento y otras acciones de adopción o soporte técnico de soluciones. Asegúrese de que cualquier interrupción o problema se comunique y se solucione rápidamente en el período de soporte técnico posterior a la implementación.
• Siga con un plan de entrenamiento: entrenar a los usuarios para que usen la solución. Asegúrese de que el entrenamiento incluye sesiones de entrenamiento en directo y grabadas durante varias semanas después del lanzamiento.
• Realizar actividades de entrega: si es necesario, prepare una entrega del equipo de desarrollo al equipo de soporte técnico.
• Organice horas de oficina para la solución: tras el periodo de asistencia posterior a la implementación, considere la posibilidad de organizar sesiones periódicas de atención al público para responder a las preguntas de los usuarios y recopilar sus comentarios.
• Configurar un proceso de mejora continua: programe una auditoría mensual de la solución para revisar posibles cambios o mejoras a lo largo del tiempo. Centralice los comentarios de los usuarios y revise los comentarios periódicamente entre auditorías.

Contenido relacionado

Para obtener más consideraciones, acciones, criterios de toma de decisiones y recomendaciones para ayudarle con las decisiones de implementación de Power BI, vea Planificación de la implementación de Power BI.