Método Data Vault 2.0-Planificación de proyectos
Las capacidades de planificación de proyectos del método Data Vault 2.0 provienen de PMP. A diferencia del método ágil Scrum, enfatiza la planificación formal de proyectos en sprints. Cada proyecto tiene un plan de proyecto: incluye las tareas a realizar, los resultados esperados como resultados de las tareas y los roles que realizarán las tareas. Dependiendo del tipo de proyecto, existen diferentes tipos de roles para ejecutar el proyecto:
Patrocinador de Negocio: Debe crear alineación entre el proyecto, el negocio y la visión.
Analista técnico de negocios: un usuario avanzado que reporta al departamento comercial pero que tiene algunas habilidades técnicas, incluida la comprensión de los modelos de datos y la capacidad de usar o escribir SQL directamente.
Gerente de Proyecto: Responsable de garantizar que el equipo del proyecto complete el proyecto.
Responsable de TI: Garantizar la continuidad del negocio y el éxito empresarial.
Desarrollador ETL: Desarrollador responsable del proceso de extracción, transformación y carga (ETL).
Desarrolladores de informes: implementen informes impulsados por el negocio basados en centros de información, tablas de almacén de negocios o (en casos excepcionales) directamente en el almacén de datos original.
Arquitecto de Datos/Arquitecto de Información: Responsable de la arquitectura de la información y la integración de datos.
Administrador de metadatos: Responsable de la construcción de metadatos.
Administrador de cambios: garantiza que las nuevas funciones no interfieran con otros servicios comerciales o de TI cuando se lanzan. También es responsable de garantizar que las nuevas versiones puedan continuar en el entorno y no sean bloqueadas por otros proyectos.
Muchas organizaciones cometen el error de asignar responsabilidades a las personas en lugar de definir roles. El beneficio de definir un rol dentro de un equipo es que la persona que desempeña este rol puede ser reemplazada por otra persona más capacitada, por ejemplo, si la persona actual deja la organización o cambia de proyecto. Las definiciones de funciones ayudan a las organizaciones de muchas maneras: estas definiciones de funciones ayudan a RR.HH. a encontrar las personas adecuadas para los puestos de trabajo en el mercado libre. Los nuevos empleados tienen la posibilidad de identificar rápidamente sus responsabilidades y completar el trabajo que se supone que deben realizar y, finalmente, tener responsabilidades claras; Puede ayudar a los equipos a decidir quién hará qué cuando se traten problemas que surgen naturalmente en un proyecto de desarrollo.
En un almacén de datos, la mayoría de los roles presentados ya son conocidos por el equipo del proyecto. Los analistas técnicos de negocios son la excepción. Este rol sirve como intermediario entre el negocio y la TI. La Figura 3.2 brinda más información sobre las características y responsabilidades de este rol.
Dado que esta función es entre la empresa y TI, el trabajo del analista técnico de negocios es facilitar la relación entre las dos partes y evitar la mentalidad de "escalar el muro" entre las dos partes. Esta mentalidad de que ambas partes no se entienden, no se apoyan mutuamente y no trabajan juntas es a menudo la causa fundamental del fracaso del proyecto. Este tipo de proyecto se caracteriza por requisitos comerciales poco claros, artefactos técnicos que no satisfacen las necesidades y requisitos comerciales tal como los entiende TI y software poco confiable debido a pruebas no probadas o incompletas (desde una perspectiva comercial). A menudo ambas partes se culpan mutuamente, estando cada una bastante convencida de que la otra ha cometido un error.
Esta es la razón por la que el equipo de Data Vault 2.0 no recomienda separar los roles comerciales de los roles de TI. En cambio, los dos grupos deberían trabajar juntos y cada rol debería ser consciente de sus propias responsabilidades. Si es posible, los equipos deberían trabajar en el mismo lugar para aumentar la eficiencia. Es importante establecer un nivel de colaboración y entendimiento mutuo entre el negocio y TI, y entre cada rol, para evitar la situación descrita en el párrafo anterior. Esta es la responsabilidad del director del proyecto. Si el equipo comienza a separarse durante el proyecto, necesitarán acciones continuas.
Parte del entendimiento que debía desarrollarse desde el lado empresarial era que necesitaba una forma de trabajar que estuviera relativamente libre de problemas cotidianos durante los sprints de dos semanas. Los problemas en las operaciones deben programarse para el próximo sprint. Para lograr esto, los departamentos de TI también deben cambiar su forma de pensar: su trabajo debería ser permitir que las unidades de negocios resuelvan algunos (si no la mayoría) de los problemas por sí mismas sin la participación de TI.
Aquí es donde entra en juego la inteligencia empresarial (BI) de autoservicio "administrada". El estándar Data Vault 2.0 proporciona a los departamentos de TI orientación sobre cómo poner los datos a disposición de los usuarios empresariales de forma que puedan utilizarlos ellos mismos. Esto requiere trasladar la responsabilidad a la empresa. Por ejemplo, no debería ser responsable de corregir datos en un almacén de datos empresarial para compensar errores en los sistemas comerciales. Es responsabilidad de la empresa corregir estos errores para que TI pueda enviar los datos de regreso a la empresa a través del almacén de datos, donde pueden aplicar reglas comerciales para transformar los datos en información. Utilizará este conocimiento para estandarizar los mercados de información de uso común.
Para evitar cualquier interrupción, los cambios en los requisitos del sistema requieren un proceso establecido. La Figura 3.3 muestra el proceso de comunicación de este cambio de requisito de DataVault2.0.
Figura 3.3 Proceso de comunicación 3.3 Cambio de requisitos de DataVault2.0
Las nuevas solicitudes de cambio generalmente provienen del lado comercial del proyecto. Requiere una evaluación del riesgo y el impacto en los sistemas de producción actuales. Es por eso que las solicitudes de cambio pasan de los usuarios comerciales a través de los patrocinadores (que deciden la prioridad de los cambios a los requisitos) y los analistas técnicos de negocios (que ayudan a traducir los requisitos comerciales en proyectos técnicos) hasta los gerentes de TI y los gerentes de proyectos responsables de la programación. Cuando completa la evaluación de riesgos, devuelve esta información a la empresa para que pueda tomar una decisión final sobre si implementar el cambio de requisitos en función de la evaluación de riesgos e impacto. Si la unidad de negocios decide continuar trabajando en el cambio de requisitos, TI programará el cambio de requisitos en el siguiente sprint según la prioridad anterior de la unidad de negocios. Luego son responsables del desarrollo y posterior entrega de nuevos artefactos. Después de que los empresarios hayan probado el cambio (excepto las pruebas de desarrollo) y lo hayan aceptado, una aprobación formal liberará a TI de una mayor responsabilidad por ese cambio de requisitos.
Al desarrollar nuevas versiones de sistemas de almacenamiento de datos, los equipos de desarrollo utilizan los mismos métodos que los equipos de desarrollo de software tradicionales. Utilizan versiones Alpha (Beta) en las primeras etapas del proceso de desarrollo para probar nuevas versiones, que son fáciles de probar con una audiencia empresarial limitada, y crean versiones Gamma (Candidatas). Las versiones alfa (beta) solo deberían afectar a los miembros del equipo técnico hasta los analistas técnicos de negocios.
Además del equipo técnico de TI, suele haber de 3 a 5 analistas técnicos de negocio en las versiones Alpha. Cuando TI publica nuevos informes para los analistas, debe quedar claro que estos informes no están destinados a distribuirse a las unidades de negocio, ya que la información en el informe o cubo (conjunto de datos) puede ser incorrecta o incluso mala. Sin embargo, los analistas técnicos de negocios recibirán estos informes para ayudarlos a encontrar estos errores o identificar errores de cálculo. Después de los primeros dos o tres sprints de un proyecto de almacén de datos, normalmente se distribuye una versión alfa a los analistas técnicos de negocios.
Una vez que una nueva versión alcance el estado beta, estará expuesta a analistas comerciales más técnicos, patrocinadores comerciales, gerentes comerciales seleccionados y otros usuarios con un interés personal en la funcionalidad de la nueva versión.
La versión beta ha sido probada completamente por representantes comerciales y de TI y ya no contiene errores obvios o conocidos. Sin embargo, debido a la naturaleza del estado de publicación, el informe resultante aún no es apto para su circulación. En cambio, equipos limitados utilizan estos informes para identificar problemas que los analistas técnicos y de desarrollo de negocios no han identificado hasta ahora. Si el equipo limitado está de acuerdo con los preparativos para el lanzamiento del producto, el sistema de almacenamiento de datos entrará en el estado Gamma (candidato).
La versión gamma o de producción está implementada y disponible para todos los usuarios empresariales. Este enfoque sigue estrictamente CMMI y es parte del enfoque Data Vault 2.0. El artículo siguiente presenta el método CMMI de Data Vault 2.0.