\n| Cierre de centros de mensajes<\/td>\n | Decisi\u00f3n de cerrar los centros de mensajes y pasar a la mensajer\u00eda instant\u00e1nea como canal principal de comunicaci\u00f3n<\/td>\n | \n\n- Evaluar el impacto del cierre en el personal y los procesos<\/li>\n
- Desarrollar planes para capacitar al personal en el uso eficaz de la mensajer\u00eda instant\u00e1nea<\/li>\n
- Considerar los ahorros potenciales derivados del cierre y priorizar en consecuencia<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n| Personal<\/td>\n | Las personas involucradas en la implementaci\u00f3n del plan y\/o afectadas por los cambios<\/td>\n | \n\n- Identificar los roles y responsabilidades del personal involucrado en la implementaci\u00f3n<\/li>\n
- Evaluar el impacto de los cambios en el personal<\/li>\n
- Desarrollar planes para capacitar o reasignar al personal seg\u00fan sea necesario<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n| Mensajer\u00eda instant\u00e1nea<\/td>\n | La nueva tecnolog\u00eda que se introduce como parte del plan de implementaci\u00f3n<\/td>\n | \n\n- Evaluar las ventajas y desventajas de utilizar la mensajer\u00eda instant\u00e1nea como canal principal de comunicaci\u00f3n<\/li>\n
- Elaborar planes para capacitar al personal en el uso eficaz de los mensajes instant\u00e1neos<\/li>\n
- Priorizar los mensajes instant\u00e1neos como una medida de ahorro de costos<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
\n| Costo<\/td>\n | Las implicaciones financieras del plan de implementaci\u00f3n<\/td>\n | \n\n- Evaluar los costos asociados con la implementaci\u00f3n del plan<\/li>\n
- Considerar medidas de ahorro de costos, como el uso de mensajes instant\u00e1neos<\/li>\n
- Elaborar planes para monitorear y gestionar los costos durante toda la implementaci\u00f3n<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Nuevamente, esta es solo una posible forma de regenerar la matriz basada en la tecnolog\u00eda actualizada, y los factores, descripciones y deducciones reales utilizados en la matriz depender\u00e1n del escenario empresarial espec\u00edfico que se est\u00e9 abordando.<\/p>\n \u00a0<\/p>\n Matriz consolidada de brechas, soluciones y dependencias<\/h2>\nLa matriz consolidada de brechas, soluciones y dependencias es una t\u00e9cnica utilizada en el proceso de desarrollo de arquitectura TOGAF para identificar y agrupar brechas en el dominio de arquitectura, evaluar soluciones potenciales y dependencias respecto a esas brechas.<\/p>\n Esta t\u00e9cnica ayuda a los arquitectos a priorizar su trabajo e identificar \u00e1reas donde las soluciones pueden tener el mayor impacto. Al agrupar las brechas, los arquitectos pueden comprender mejor las relaciones entre ellas e identificar soluciones que aborden m\u00faltiples brechas al mismo tiempo.<\/p>\n La matriz tambi\u00e9n es \u00fatil para planificar y crear paquetes de trabajo. Las dependencias identificadas pueden ayudar a impulsar la creaci\u00f3n de proyectos e informar la planificaci\u00f3n de migraci\u00f3n en las Fases E y F del proceso de desarrollo de arquitectura. Esto garantiza que los proyectos se prioricen adecuadamente y se alineen con los objetivos empresariales.<\/p>\n En general, la matriz consolidada de brechas, soluciones y dependencias es una herramienta valiosa para que los arquitectos la utilicen durante todo el proceso de desarrollo de arquitectura, permiti\u00e9ndoles identificar brechas, soluciones y dependencias, priorizar su trabajo y impulsar una planificaci\u00f3n y ejecuci\u00f3n eficaz de proyectos.<\/p>\n Ejemplo<\/h3>\nAqu\u00ed hay un ejemplo de c\u00f3mo se podr\u00eda utilizar la matriz consolidada de brechas, soluciones y dependencias:<\/p>\n Supongamos que durante la fase de an\u00e1lisis de brechas del proceso de desarrollo de arquitectura, el equipo de arquitectura ha identificado varias brechas en la arquitectura del estado actual. Estas brechas incluyen:<\/p>\n \n- Falta de un repositorio centralizado de datos de clientes<\/li>\n
- Definiciones de datos inconsistentes entre las unidades de negocio<\/li>\n
- Integraci\u00f3n limitada entre los sistemas de CRM y de cumplimiento de pedidos<\/li>\n<\/ol>\n
Para crear una matriz consolidada de brechas, soluciones y dependencias, el equipo de arquitectura agrupar\u00eda estas brechas y evaluar\u00eda soluciones y dependencias potenciales. Por ejemplo:<\/p>\n aqu\u00ed est\u00e1 el ejemplo nuevamente con numeraci\u00f3n agregada en la primera columna:<\/p>\n \n\n\n| #<\/th>\n | Brecha<\/th>\n | Soluciones potenciales<\/th>\n | Dependencias<\/th>\n<\/tr>\n<\/thead>\n | \n\n| 1<\/td>\n | Falta de un repositorio centralizado de datos de clientes<\/td>\n | Implementar un data lake para datos de clientes<\/td>\n | Dependiente de la resoluci\u00f3n de las definiciones de datos inconsistentes<\/td>\n<\/tr>\n | \n| 2<\/td>\n | Definiciones de datos inconsistentes entre unidades de negocio<\/td>\n | Establecer un marco de gobernanza de datos y un modelo de datos com\u00fan<\/td>\n | Dependiente de la implementaci\u00f3n de un data lake<\/td>\n<\/tr>\n | \n| 3<\/td>\n | Integraci\u00f3n limitada entre los sistemas de CRM y de cumplimiento de pedidos<\/td>\n | Implementar un bus de servicios empresariales (ESB) para habilitar el intercambio de datos en tiempo real<\/td>\n | Dependiente de la implementaci\u00f3n de un marco de gobernanza de datos y un modelo de datos com\u00fan<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n En este ejemplo, la matriz muestra que abordar las brechas en los datos del cliente requiere un enfoque de m\u00faltiples pasos que implica resolver las inconsistencias de datos, implementar un data lake, establecer un marco de gobernanza de datos y un modelo de datos com\u00fan, y finalmente implementar un ESB para habilitar el intercambio de datos en tiempo real.<\/p>\n Esta matriz se puede utilizar para planificar paquetes de trabajo, identificar dependencias y priorizar proyectos en las Fases E y F. Por ejemplo, el equipo de arquitectura podr\u00eda priorizar la implementaci\u00f3n del marco de gobernanza de datos y el modelo de datos com\u00fan como el primer paso para abordar las brechas identificadas, ya que es una dependencia tanto para la implementaci\u00f3n del data lake como para la del ESB.<\/p>\n Tabla de Incrementos de Definici\u00f3n de Arquitectura<\/h2>\nLa Tabla de Incrementos de Definici\u00f3n de Arquitectura es una t\u00e9cnica utilizada en el Marco de Arquitectura de The Open Group (TOGAF) que permite a los arquitectos planificar y rastrear el desarrollo de una arquitectura empresarial con el tiempo. La tabla enumera los diferentes proyectos que contribuir\u00e1n al desarrollo de la arquitectura, y asigna entregables espec\u00edficos a cada proyecto que se completar\u00e1n en incrementos con el tiempo.<\/p>\n El prop\u00f3sito de esta tabla es crear una hoja de ruta que describa la secuencia planificada de las Arquitecturas de Transici\u00f3n, que son estados intermedios de la arquitectura que se alcanzar\u00e1n en momentos espec\u00edficos durante el proceso de desarrollo. Cada Arquitectura de Transici\u00f3n representa una etapa de la arquitectura que es m\u00e1s completa y m\u00e1s cercana al estado final que la etapa anterior.<\/p>\n Al dividir el proceso de desarrollo en entregables incrementales y asignarlos a proyectos y plazos espec\u00edficos, la Tabla de Incrementos de Definici\u00f3n de Arquitectura ayuda a los arquitectos a:<\/p>\n \n- Planificar el desarrollo de la arquitectura empresarial de manera estructurada y manejable<\/li>\n
- Garantizar que cada proyecto se ordene adecuadamente y que cada incremento se complete a tiempo<\/li>\n
- Identificar posibles dependencias y conflictos entre diferentes proyectos<\/li>\n
- Proporcionar una visi\u00f3n clara del proceso de desarrollo, que puede compartirse con los interesados para asegurar que todos est\u00e9n alineados con los objetivos y la cronolog\u00eda del proyecto.<\/li>\n<\/ol>\n
En general, la Tabla de Incrementos de Definici\u00f3n de Arquitectura es una herramienta poderosa que puede ayudar a los arquitectos a gestionar proyectos complejos de arquitectura empresarial y garantizar que se completen con \u00e9xito y a tiempo.<\/p>\n Aqu\u00ed tiene una tabla actualizada de Incrementos de Definici\u00f3n de Arquitectura que combina la informaci\u00f3n tanto del incremento como de la fecha de inicio:<\/p>\n \n\n\n| Nombre del proyecto<\/th>\n | Incremento 1 \u2013 Fecha de inicio<\/th>\n | Incremento 1<\/th>\n | Incremento 2 \u2013 Fecha de inicio<\/th>\n | Incremento 2<\/th>\n | Incremento 3 \u2013 Fecha de inicio<\/th>\n | Incremento 3<\/th>\n | Incremento 4 \u2013 Fecha de inicio<\/th>\n | Incremento 4<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Sistema CRM<\/td>\n | Trimestre 1 de 2023<\/td>\n | Arquitectura conceptual<\/td>\n | Q2 2023<\/td>\n | Arquitectura l\u00f3gica<\/td>\n | Q3 2023<\/td>\n | Arquitectura f\u00edsica<\/td>\n | Q4 2023<\/td>\n | Sistema completamente operativo<\/td>\n<\/tr>\n | \n| Almac\u00e9n de datos<\/td>\n | Q1 2023<\/td>\n | Arquitectura conceptual<\/td>\n | Q2 2023<\/td>\n | Arquitectura l\u00f3gica<\/td>\n | Q3 2023<\/td>\n | Arquitectura f\u00edsica<\/td>\n | Q4 2023<\/td>\n | Sistema completamente operativo<\/td>\n<\/tr>\n | \n| Plataforma de comercio electr\u00f3nico<\/td>\n | Q2 2023<\/td>\n | Arquitectura conceptual<\/td>\n | Q3 2023<\/td>\n | Arquitectura l\u00f3gica<\/td>\n | Q4 2023<\/td>\n | Arquitectura f\u00edsica<\/td>\n | Q1 2024<\/td>\n | Sistema completamente operativo<\/td>\n<\/tr>\n | \n| Aplicaci\u00f3n m\u00f3vil<\/td>\n | Q2 2023<\/td>\n | Arquitectura conceptual<\/td>\n | Q3 2023<\/td>\n | Arquitectura l\u00f3gica<\/td>\n | Cuarto trimestre de 2023<\/td>\n | Arquitectura f\u00edsica<\/td>\n | Primer trimestre de 2024<\/td>\n | Sistema completamente operativo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n En esta tabla actualizada, cada proyecto tiene cuatro incrementos, y cada incremento tiene una hora de inicio representada como un trimestre y un a\u00f1o. Esto permite al arquitecto planificar una serie de arquitecturas de transici\u00f3n y rastrear el progreso hacia la consecuci\u00f3n del sistema completamente operativo para cada proyecto.<\/p>\n Por ejemplo, el proyecto del sistema CRM comienza en el primer trimestre de 2023, y cada incremento posterior comienza en el trimestre siguiente. La tabla muestra que el incremento del sistema completamente operativo est\u00e1 programado para el cuarto trimestre de 2023. Esto permite al arquitecto planificar y rastrear el progreso hacia la consecuci\u00f3n del sistema completamente operativo para el proyecto del sistema CRM.<\/p>\n De manera similar, la tabla muestra las fechas de inicio para cada incremento de los otros tres proyectos. Esto ayuda al arquitecto a planificar y rastrear el progreso hacia la consecuci\u00f3n del sistema completamente operativo para cada proyecto, y a identificar posibles conflictos o dependencias entre diferentes proyectos.<\/p>\n Tabla de evoluci\u00f3n del estado de la arquitectura de transici\u00f3n<\/h2>\nLa tabla de evoluci\u00f3n del estado de la arquitectura de transici\u00f3n es una t\u00e9cnica utilizada en el Marco de Arquitectura de The Open Group (TOGAF) para demostrar el estado propuesto de las arquitecturas de una organizaci\u00f3n en varios niveles utilizando una taxonom\u00eda definida, como el Modelo de Referencia T\u00e9cnica (TRM) de TOGAF. Esta tabla es una herramienta visual que ayuda a los arquitectos a identificar los servicios en la taxonom\u00eda que se utilizan en la empresa y luego listar las arquitecturas de transici\u00f3n y las transformaciones propuestas para esos servicios.<\/p>\n La tabla debe incluir una lista de todos los Bloques de Construcci\u00f3n de Soluciones (SBB) y describir c\u00f3mo impactar\u00e1n y cumplir\u00e1n con los servicios enumerados. Los SBB tambi\u00e9n deben marcarse para mostrar c\u00f3mo avanzar\u00e1n la Arquitectura Empresarial. Por ejemplo, si se introduce una nueva capacidad, se marcar\u00e1 como \u00abnueva\u00bb o \u00abmantener\u00bb en la tabla. Si una capacidad se est\u00e1 trasladando a una nueva soluci\u00f3n, se marcar\u00e1 como \u00abtransici\u00f3n\u00bb. Y si una capacidad se est\u00e1 reemplazando, se marcar\u00e1 como \u00abreemplazar\u00bb.<\/p>\n La tabla de evoluci\u00f3n del estado de la arquitectura de transici\u00f3n proporciona una imagen clara de los cambios que ocurrir\u00e1n en la arquitectura de una organizaci\u00f3n con el tiempo. Permite a los arquitectos ver c\u00f3mo sus cambios propuestos impactar\u00e1n los servicios de la organizaci\u00f3n y c\u00f3mo los llevar\u00e1n hacia su estado objetivo. Al utilizar esta tabla, los arquitectos pueden asegurarse de que sus cambios propuestos se alineen con los objetivos y metas de la organizaci\u00f3n y que puedan implementarse de manera efectiva.<\/p>\n Ejemplo<\/h3>\nA continuaci\u00f3n se muestra un ejemplo de c\u00f3mo podr\u00eda verse la tabla de evoluci\u00f3n del estado de la arquitectura de transici\u00f3n seg\u00fan las columnas que mencion\u00f3:<\/p>\n \n\n\n| Subdominio<\/th>\n | Servicio<\/th>\n | Arquitectura de transici\u00f3n 1<\/th>\n | Arquitectura de transici\u00f3n 2<\/th>\n | Arquitectura de transici\u00f3n 3<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Ventas<\/td>\n | Gesti\u00f3n de pedidos<\/td>\n | Estado actual<\/td>\n | Estado de transici\u00f3n<\/td>\n | Estado objetivo<\/td>\n<\/tr>\n | \n| Ventas<\/td>\n | Gesti\u00f3n de clientes<\/td>\n | Estado actual<\/td>\n | Estado de transici\u00f3n<\/td>\n | Estado objetivo<\/td>\n<\/tr>\n | \n| Finanzas<\/td>\n | Cuentas por pagar<\/td>\n | Estado Actual<\/td>\n | Estado de Transici\u00f3n<\/td>\n | Estado Objetivo<\/td>\n<\/tr>\n | \n| Finanzas<\/td>\n | Cuentas por Cobrar<\/td>\n | Estado Actual<\/td>\n | Estado de Transici\u00f3n<\/td>\n | Estado Objetivo<\/td>\n<\/tr>\n | \n| RRHH<\/td>\n | N\u00f3mina<\/td>\n | Estado Actual<\/td>\n | Estado de Transici\u00f3n<\/td>\n | Estado Objetivo<\/td>\n<\/tr>\n | \n| RRHH<\/td>\n | Administraci\u00f3n de Beneficios<\/td>\n | Estado Actual<\/td>\n | Estado de Transici\u00f3n<\/td>\n | Estado Objetivo<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n En este ejemplo, la primera columna enumera los subdominios dentro de la organizaci\u00f3n, como Ventas, Finanzas y RRHH. La segunda columna enumera los servicios espec\u00edficos dentro de cada subdominio, como Gesti\u00f3n de Pedidos, Cuentas por Pagar y N\u00f3mina. Las columnas restantes representan las diversas Arquitecturas de Transici\u00f3n, que podr\u00edan incluir el Estado Actual, el Estado de Transici\u00f3n y el Estado Objetivo.<\/p>\n Cada celda de la tabla se completar\u00eda luego con la informaci\u00f3n relevante para ese servicio y arquitectura. Por ejemplo, la celda correspondiente a Gesti\u00f3n de Pedidos y la columna Estado Actual podr\u00eda contener una descripci\u00f3n de la arquitectura actual utilizada para gestionar pedidos, mientras que la celda correspondiente a Gesti\u00f3n de Pedidos y la columna Estado Objetivo podr\u00eda describir la arquitectura propuesta para gestionar pedidos en el futuro.<\/p>\n T\u00e9cnica de Evaluaci\u00f3n del Valor de Negocio<\/h2>\nLa t\u00e9cnica de evaluaci\u00f3n del valor de negocio que describi\u00f3 es un m\u00e9todo \u00fatil para evaluar y priorizar diversas iniciativas o proyectos de negocio. Al utilizar una matriz con dimensiones de valor y riesgo, las empresas pueden evaluar sus opciones bas\u00e1ndose en criterios objetivos que se alinean con sus objetivos y metas estrat\u00e9gicas.<\/p>\n La dimensi\u00f3n del \u00edndice de valor, que incluye el cumplimiento de principios, la contribuci\u00f3n financiera, la alineaci\u00f3n estrat\u00e9gica y la posici\u00f3n competitiva, ayuda a determinar los beneficios y oportunidades potenciales que un proyecto puede aportar al negocio. La dimensi\u00f3n del \u00edndice de riesgo, que incluye tama\u00f1o y complejidad, tecnolog\u00eda, capacidad organizacional e impacto de un fracaso, ayuda a identificar los riesgos y desaf\u00edos potenciales que un proyecto podr\u00eda enfrentar.<\/p>\n Ejemplo<\/h3>\nAl asignar pesos individuales a cada criterio, las empresas pueden determinar la importancia relativa de cada criterio en el proceso de toma de decisiones. Esto ayuda a garantizar que los factores m\u00e1s cr\u00edticos reciban mayor peso en el proceso de evaluaci\u00f3n.<\/p>\n \u00a0<\/p>\n ![](\"https:\/\/guides.visual-paradigm.com\/wp-content\/uploads\/2023\/03\/28_sample.png\"\/) <\/p>\n
Finalmente, es importante establecer los criterios de toma de decisiones antes de conocer las opciones. Esto garantiza que el proceso de evaluaci\u00f3n permanezca objetivo y consistente, y que todas las opciones se eval\u00faen seg\u00fan los mismos criterios. Tambi\u00e9n ayuda a prevenir que los sesgos y preferencias personales influyan en el proceso de toma de decisiones.<\/p>\n | | | | | | |