Contrastes del modelo de operación de producto

Tomo desde una perspectiva de aprendizaje retomar el conocimiento y experiencia que ha desarrollado  y dispuesto en sus libros y foros Marty Cagan, que es considerado uno de los pensadores más influyentes en el ámbito de la gestión de productos tecnológicos. Tras una destacada carrera en empresas como Hewlett-Packard, Netscape y eBay, fundó Silicon Valley Product Group (SVPG), una organización dedicada a compartir las mejores prácticas en la creación de productos digitales exitosos.

Su experiencia trabajando con algunas de las empresas tecnológicas más innovadoras del mundo le ha permitido desarrollar una metodología de gestión de producto que ha revolucionado la forma en que entendemos el desarrollo de productos digitales.

Coincido con aplicar prototipos cortos con un equipo modelo, que muestre el verdadero poder de hacer productos tecnológicos de valor; para después con resultados claros, replicar esta cultura de trabajo gradualmente hasta consolidar una autentica transformación empresarial.

Esta visión requiere un cambio fundamental en cómo las organizaciones abordan el desarrollo de productos tecnológicos, pasando de un enfoque centrado en la entrega a uno centrado en la resolución de problemas reales de los usuarios de manera que beneficie al negocio.

Después de leer un par de veces, repasar sus presentaciones, comentarios directos de personas que lo han probado y entender su propuesta de Modelo Operativo de Producto, es que logre dimensionar su trilogía y cómo se lleva a la práctica con cada arista del modelo; de hecho, coincide con modelo de cubos y pilares que he venido trabando desde que manejo Balanced Scoredcard, Arquitectura empresarial, DDD, Act driven Model, Riesgos, etc.

Su estilo no es ajeno para los que hems generado valor en productos y soluciones tecnológicas con XP, Squads, aplicando los principios de la quinta disciplina bajada desde la alta dirección, lo mismo que sucede al alinear consolidar el BSC y mejor aún en su versión del execution premium, como aquellos que han puesto en práctica el juego interior en el trabajo, entre otros. Justo los equipos multidisciplinarios cuando viven sus productos crean cosas increíbles y justo de ahí nació la actitud resolutiva que he expuesto en otros artículos.

La simplicidad que me gusta y ha dado resultados en diferentes industrias (seguros, energía, farmacéutica, aeronáutica, banca, etc), coincide con su visión de enfoque claro. ¡Vaya si es generadora de valor, estando en los niveles correctos! Recordé esa enseñanza de quien era capaz de venderle pan a los panaderos, aplicando en los sectores mencionados; de ahí generamos tanto valor y soluciones que después llegaban a economías de escala.

También coexiste y se alinea con BSC, Arquitectura empresarial, DDD, RIM/ADM, MAGTICSI, etc. Eso es, el arte de acoplar lo mejor de forma natural.

Es importante no caer en la ceguera del ego, esto es, no podemos sentirnos de producto, si no entendemos el negocio, producto, entorno (regulación, riesgos, etc); en la medida que conocemos cada perspectiva, el equipo de producto toma un poder increibles para consolidar el modelo operativo de producto, esto es, que si conocemos a nuestros borreguitos el valor será alcanzado y superado, pero mejor aún, el usuario realmente será fiel, leal y promotor.

Los pilares de la metodología

Entiendo que se fundamenta su visión en varios pilares clave que revolucionan la forma tradicional de desarrollar productos tecnológicos:

1. Riesgos antes que soluciones

Siendo que los equipos tradicionales se centran en construir soluciones sin validar primero si estas resuelven problemas reales. Su metodología propone abordar sistemáticamente cuatro tipos de riesgos:

• Riesgo de valor: ¿Los clientes comprarán o usarán esto?
• Riesgo de usabilidad: ¿Pueden los usuarios descubrir cómo usarlo?
• Riesgo técnico: ¿Podemos construirlo?
• Riesgo de negocio: ¿Funciona para nuestro negocio?

2. Descubrimiento continuo de producto

Me parece entender que distingue claramente entre dos actividades fundamentales:

• Descubrimiento de producto: Decidir qué construir
• Entrega de producto: Construir lo decidido

El problema de muchas empresas es que dedican casi todo su tiempo a la entrega y muy poco al descubrimiento, resultando en productos que nadie quiere.

3. Equipos empoderados vs. equipos mercenarios

En los últimos años en las batallas por robar talento y vender falsa experiencia, el mercenario se disparó y terminó fallando; por eso existe una diferencia crucial entre:

• Equipos empoderados: Responsables de resolver problemas para los clientes y para el negocio
• Equipos mercenarios: Simplemente construyen lo que se les dice, si realmente lo saben hacer

Los equipos empoderados reciben problemas para resolver, no características para construir.

4. Product Mindset vs. Project Mindset

Entiendo que con justa razón critica duramente la mentalidad de "proyecto" donde:

• Se define un alcance fijo
• Se establece un cronograma
• Se mide el éxito por la entrega a tiempo y dentro del presupuesto

En cambio, promueve una mentalidad de "producto" donde:

• Se define un resultado de negocio a lograr
• Los equipos deciden cómo lograrlo
• El éxito se mide por el impacto en el cliente y el negocio

El equipo de producto 

Nos deja claro que el equipo de producto ideal tiene una estructura específica y roles bien definidos:

La tríada de producto

En el centro de su visión está lo que él llama "la tríada de producto":

1. Product Manager (PM): Responsable de qué construir y por qué
2. Product Designer: Responsable de cómo el usuario interactuará con el producto
3. Tech Lead: Responsable de cómo construir el producto técnicamente

Estos tres roles deben trabajar en colaboración constante durante el descubrimiento y la entrega.

De hecho con otro nombre y técnica similar me toco probar estos grupos multidisciplinarios, justo en producto, logística, marketing, tech disruptivo, etc; obviamente funcionan y dan resultados relevantes en poco tiempo, pero mejor aún, conocer y viven lo que tienen en sus manos y eso empodera el valor para evolucionarlo, extenderlo e incluso llegar a economía de escalas.

Complementado lo anterior por:

• Ingenieros: No solo implementadores, sino colaboradores activos en el descubrimiento
• Data Scientists: Proporcionan insights basados en datos para informar decisiones
• User Researchers: Especialistas en entender profundamente a los usuarios

Liderazgo de producto

Define roles clave de liderazgo:

• Head of Product/CPO: Define la estrategia general de producto
• Head of Design: Garantiza la excelencia en diseño y experiencia de usuario
• Head of Engineering: Asegura que la organización pueda construir lo necesario
• Head of Product Marketing: Conecta el producto con el mercado

El proceso de descubrimiento de producto

Un concepto fundamental en su metodología  es el "descubrimiento de producto", que consiste en validar ideas antes de invertir en construirlas. Este proceso incluye:

Técnicas de descubrimiento

1. Entrevistas con clientes: Conversaciones profundas para entender problemas y necesidades
2. Pruebas de usabilidad: Verificar si los usuarios pueden utilizar el producto intuitivamente
3. Pruebas de valor percibido: Determinar si los clientes valoran la solución propuesta
4. Prototipos de alta fidelidad: Validar conceptos antes de construirlos completamente
5. Tests A/B y experimentos: Probar hipótesis con datos reales

El ciclo de descubrimiento

Me agrada como propone un ciclo continuo:

1. Generar ideas basadas en necesidades de usuarios y objetivos de negocio
2. Crear prototipos rápidos para representar estas ideas
3. Probar con usuarios reales para validar valor y usabilidad
4. Iterar basándose en lo aprendido o pivotar si es necesario

Lo crucial es que este ciclo debe ser rápido (días, no semanas) y continuo (no solo al principio de un proyecto).

La cultura de producto 

Más allá de prácticas específicas, enfatiza la importancia de cultivar una cultura organizacional que favorezca la innovación:

Principios culturales clave

1. Obsesión por el cliente: Tomar decisiones basadas en necesidades reales del usuario
2. Asumir riesgos calculados: Promover la experimentación y aceptar que algunas ideas fracasarán
3. Aprendizaje continuo: Valorar lo que se aprende incluso de los fracasos
4. Colaboración multidisciplinar: Romper silos entre departamentos
5. Datos sobre opiniones: Basar decisiones en evidencia, no en jerarquía
6. Foco en resultados: Medir éxito por impacto en negocio y usuarios, no por características entregadas

De "feature factories" a "outcome factories"

Con justa razón critica duramente las "fábricas de características" donde los equipos simplemente implementan listas de funcionalidades sin cuestionar su valor. En cambio, propone organizaciones centradas en resultados, donde:

• Los equipos son responsables de métricas específicas de negocio
• Tienen autonomía para decidir cómo mejorar esas métricas
• Son juzgados por los resultados, no por la cantidad de funcionalidades

Diferencias entre empresas exitosas y no exitosas

A través de sus libros, Cagan identifica patrones claros que diferencian a las empresas que crean productos exitosos de aquellas que fracasan:

Empresas exitosas

1. Tienen equipos de producto, no equipos de proyectos
2. Asignan problemas a resolver, no características a construir
3. Valoran el descubrimiento tanto como la entrega
4. Confían en sus equipos para tomar decisiones
5. Tienen líderes que facilitan en lugar de microgestionar
6. Miden el éxito por resultados de negocio
7. Están dispuestas a pivotar cuando la evidencia lo sugiere

Empresas no exitosas

1. Operan con mentalidad de proyecto
2. Tienen roadmaps llenos de características sin validar
3. Confunden entrega con valor
4. Separan a quienes piensan de quienes construyen
5. Tienen líderes que actúan como "proxy del producto"
6. Miden el éxito por adherencia al plan
7. Se aferran a planes incluso cuando la evidencia sugiere cambiar

Implementando la visión: pasos prácticos

Para organizaciones que desean adoptar la metodología de Cagan, él propone un enfoque gradual:

Para organizaciones nuevas o pequeñas

1. Formar la tríada de producto (PM, diseñador, tech lead)
2. Dedicar al menos 20% del tiempo al descubrimiento
3. Establecer OKRs (Objetivos y Resultados Clave) claros
4. Implementar ciclos rápidos de prototipado y prueba
5. Eliminar roadmaps basados en características

Para grandes empresas en transformación

1. Comenzar con equipos piloto que adopten nuevas prácticas
2. Transformar el liderazgo para entender el enfoque de producto
3. Cambiar sistemas de recompensa para premiar resultados, no entrega
4. Eliminar dependencias entre equipos
5. Adoptar arquitecturas técnicas que permitan autonomía
6. Transformar el proceso presupuestario para financiar equipos estables, no proyectos

En "Transformed", Cagan enfatiza que la transformación debe ocurrir simultáneamente en cuatro dimensiones:

• Valores y principios: La cultura organizacional
• Estructura organizativa: Cómo se organizan los equipos
• Personas y habilidades: Quién hace el trabajo
• Procesos y prácticas: Cómo se hace el trabajo

La trilogía: Inspired, Empowered y Transformed

De una forma sintetizada se cristaliza en sus libros los fundamentos que sin afán de exaltar conforman una especie de "biblia" para los profesionales de producto:

INSPIRED: Cómo crear productos de tecnología que los clientes amen

Ciertamente lo publicó en 2008 y lo actualizó en 2017, Inspired a mi parecer establece las bases de lo que Cagan considera una gestión de producto efectiva. El libro siento que responde a una pregunta fundamental: ¿Por qué algunos productos tecnológicos tienen éxito mientras que otros fracasan?

Hace énfasis en:

• La diferencia entre buen y mal desarrollo de producto
• La importancia del "descubrimiento de producto" frente a la simple "entrega"
• Los roles fundamentales en un equipo de producto eficaz
• Técnicas para identificar problemas valiosos para resolver

EMPOWERED: Equipos de producto ordinarios creando productos extraordinarios

Publicado en 2020, Empowered siento que profundiza en cómo crear y liderar equipos de producto de alto rendimiento. Ciertamente si Inspired se centra en qué hacer, Empowered se enfoca en quién debe hacerlo y cómo.

Los temas principales incluyen:

• El papel crucial de los líderes de producto, diseño y tecnología
• Cómo desarrollar equipos realmente empoderados que puedan innovar
• La transición de una cultura de "proyecto" a una cultura de "producto"
• Las habilidades necesarias para ser un líder de producto eficaz

TRANSFORMED: Reimaginando la innovación radical en las grandes empresas

Publicado en 2023, Transformed aborda el desafío de implementar prácticas modernas de producto en organizaciones grandes y establecidas.

Este libro examina:

• Por qué las grandes empresas suelen tener dificultades para innovar
• Cómo transformar una organización tradicional en una impulsada por producto
• Estrategias para superar la resistencia cultural y estructural al cambio
• Casos de estudio de transformaciones exitosas en empresas establecidas

Conclusión: 

La visión de Marty Cagan representa un cambio paradigmático en la forma de crear productos tecnológicos. Sus ideas han influido en gran número de empresas alrededor del mundo.

El mensaje central que atraviesa su obra es profundamente transformador: los mejores productos no surgen de procesos rígidos o de ejecutar fielmente un plan predefinido, sino de equipos empoderados que entienden profundamente a sus clientes y están orientados a resolver sus problemas reales.

La metodología de Cagan puede resumirse en una frase: "Productos que los clientes aman, creados por equipos que aman construirlos." Esta visión dual, centrada tanto en el valor para el cliente como en la cultura interna, es lo que hace que su enfoque sea tan efectivo y duradero.

La pregunta ya no es si adoptaremos estas prácticas, sino cuándo lo haremos, porque como el propio Cagan suele decir: "El mundo no necesita más productos, necesita mejores productos."

Jorge Mercado,

#JMCoach

Arquitectura empresarial, camino a la realidad

Imagina que quieres construir una casa. Necesitarías planos que muestren la estructura, el sistema eléctrico, la fontanería, y cómo se integra todo. La Arquitectura Empresarial (AE) funciona de manera similar para las organizaciones: proporciona un plano integral de la estructura, procesos, información y tecnología de una empresa, alineada a su estrategia y cubriendo regulaciones.

La Arquitectura Empresarial podría definirse como:

"El conjunto de representaciones descriptivas que son relevantes para describir una empresa de manera que pueda ser producida según los requisitos de calidad y mantenida durante su período de utilidad."

En términos simples, es una práctica estratégica que conecta la misión y visión de una organización con sus operaciones diarias a través de:

• Arquitectura de Negocio: Procesos, funciones y estructura organizacional, normas, riesgos
• Arquitectura de Datos: Estructura de datos e información
• Arquitectura de Aplicaciones: Sistemas de software y sus interrelaciones
• Arquitectura Tecnológica: Hardware, redes y plataformas

¿Por qué es importante la Arquitectura Empresarial?

En el mundo actual, donde la transformación digital es constante, la Arquitectura Empresarial se ha vuelto fundamental por varias razones:

1. Alineación estratégica: Asegura que los proyectos de TI estén alineados con los objetivos del negocio, normatividad, compliance, riesgos.
2. Reducción de complejidad: Simplifica sistemas y procesos redundantes.
3. Mejor toma de decisiones: Proporciona una visión integral para tomar decisiones informadas.
4. Adaptabilidad al cambio: Facilita la evolución y adaptación de la organización.
5. Optimización de recursos: Identifica duplicidades y oportunidades de sinergia.

Ejemplo práctico: Una cadena de supermercados implementó arquitectura empresarial para unificar sus sistemas de inventario, ventas y logística. Resultado: reducción del 30% en costos operativos y mejora del 25% en tiempo de respuesta a cambios del mercado.

El Framework Zachman: La matriz que organiza tu empresa

El Framework de Zachman, creado por John Zachman en 1987, es uno de los modelos más reconocidos en Arquitectura Empresarial. Se presenta como una matriz de 6×6 que aborda seis preguntas fundamentales (columnas) desde seis perspectivas diferentes (filas).

Las seis preguntas fundamentales:

1. ¿QUÉ? (Datos): Información relevante para el negocio
2. ¿CÓMO? (Función): Procesos y operaciones
3. ¿DÓNDE? (Red): Ubicaciones y conexiones
4. ¿QUIÉN? (Personas): Recursos humanos y estructura organizacional
5. ¿CUÁNDO? (Tiempo): Eventos y ciclos
6. ¿POR QUÉ? (Motivación): Objetivos y estrategias

Las seis perspectivas:

1. Contextual (Planificador): Alcance y visión general
2. Conceptual (Propietario): Modelo de negocio
3. Lógica (Diseñador): Requisitos del sistema
4. Física (Constructor): Especificaciones técnicas
5. Detallada (Subcontratista): Implementación específica
6. Funcional (Empresa): Sistema en funcionamiento

Ejemplo aplicado: Tomemos como ejemplo una aerolínea que aplica Zachman:

• En la intersección "¿QUÉ?" y "Contextual": Define que necesita datos de vuelos, pasajeros y aeronaves
• En la intersección "¿CÓMO?" y "Lógica": Establece los flujos de procesos de reserva y check-in
• En la intersección "¿QUIÉN?" y "Física": Determina roles específicos y permisos en sistemas

TOGAF: El método práctico para implementar Arquitectura Empresarial

TOGAF (The Open Group Architecture Framework) es un marco metodológico desarrollado por The Open Group que ofrece un enfoque paso a paso para el desarrollo de arquitectura empresarial. Su componente principal es el ADM (Architecture Development Method), un ciclo iterativo de desarrollo arquitectónico.

El ciclo ADM de TOGAF consta de:

1. Fase Preliminar: Preparación y definición de principios
2. Fase A: Visión de Arquitectura: Establecer alcance y expectativas
3. Fase B: Arquitectura de Negocio: Desarrollo de la arquitectura de procesos
4. Fase C: Arquitecturas de Sistemas de Información:
   • C1: Arquitectura de Datos
   • C2: Arquitectura de Aplicaciones
5. Fase D: Arquitectura Tecnológica: Infraestructura técnica
6. Fase E: Oportunidades y Soluciones: Planificación de la implementación
7. Fase F: Planificación de la Migración: Plan detallado de transición
8. Fase G: Gobernanza de la Implementación: Supervisión del desarrollo
9. Fase H: Gestión de Cambios: Monitoreo y adaptación
10. Gestión de Requerimientos: Proceso central que interactúa con todas las fases

Ejemplo práctico de TOGAF: Un banco decide modernizar sus sistemas usando TOGAF:

• En la Fase A, establece la visión de ofrecer banca digital omnicanal
• En las Fases B, C y D, define los nuevos procesos de negocio, arquitecturas de aplicaciones y tecnología
• En las Fases E y F, planifica la transición gradual de sistemas antiguos a nuevos
• En las Fases G y H, implementa y monitoriza el cambio

Comparación entre Zachman y TOGAF

Muchas organizaciones combinan ambos enfoques: utilizan Zachman para estructurar su conocimiento y TOGAF para implementar cambios.

Casos prácticos de implementación

Caso 1: Sector Financiero

Un banco internacional implementó arquitectura empresarial para consolidar sus sistemas tras varias fusiones:

• Problema: 12 sistemas de gestión de clientes diferentes
• Solución: Utilizó TOGAF para crear una arquitectura unificada
• Resultado: Reducción de costos de TI del 40% y mejora en experiencia del cliente

Caso 2: Sector Público

Un gobierno municipal aplicó Zachman para reorganizar sus servicios:

• Problema: Servicios administrativos fragmentados y redundantes
• Solución: Modeló cada servicio en la matriz de Zachman
• Resultado: Tiempo de trámites reducido en 60% y mejor satisfacción ciudadana

Caso 3: Manufactura

Una empresa industrial aplicó una combinación de ambos enfoques:

• Problema: Sistemas de producción desconectados y procesos manuales
• Solución: Zachman para clasificar y TOGAF para implementar
• Resultado: Aumento del 25% en productividad y reducción del 35% en errores

Conclusiones

La Arquitectura Empresarial, ya sea implementada con Zachman, TOGAF o una combinación de ambos, proporciona una base sólida para la transformación digital y la alineación estratégica. No se trata solo de tecnología, sino de cómo la tecnología se integra con las personas, procesos y objetivos de negocio.

Las organizaciones que implementan con éxito la Arquitectura Empresarial obtienen una ventaja competitiva significativa: mayor agilidad, mejor toma de decisiones y optimización de recursos. En un mundo empresarial cada vez más complejo y digital, contar con un "plano maestro" de la organización ya no es un lujo, sino una necesidad estratégica.

Breve paso por la Administración de Riesgos

Administración del Riesgo: Un Enfoque Integral

Más allá del dogma y desconocimiento, el verdadero valor de administrar riesgos es la llave para la continuidad de todo negocio/producto. La aplicación de un enfoque más sofisticado a la gestión de riesgos puede ayudar a los líderes a seguir generando valor a través de la disrupción y la incertidumbre.

Esto es habilitado por la simplicidad y flexibilidad, dado que, la capacidad de una empresa para adaptarse rápidamente ante los acontecimientos que se desarrollan es esencial para su supervivencia y prosperidad.

La administración del riesgo es una disciplina esencial para cualquier organización que busca alcanzar sus objetivos mientras minimiza las incertidumbres. La norma ISO 31000 proporciona un marco internacional para gestionar riesgos de manera estructurada y efectiva. Este estándar se basa en principios como la integración, la adaptabilidad y la mejora continua, lo que lo hace aplicable a diversos sectores.

¿Qué es la ISO 31000?

La ISO 31000 define el riesgo como el "efecto de la incertidumbre sobre los objetivos". Su enfoque se centra en identificar, analizar, evaluar y tratar los riesgos, promoviendo una toma de decisiones informada. Este estándar es flexible y puede adaptarse a diferentes contextos organizacionales, desde pequeñas empresas hasta grandes corporaciones.

Métodos Complementarios

Además de la ISO 31000, existen otros enfoques y herramientas para la gestión del riesgo:

• Análisis FODA: Identifica fortalezas, oportunidades, debilidades y amenazas
• Matriz de Riesgos: Evalúa la probabilidad e impacto de los riesgos.
• Método Bowtie: Visualiza las causas y consecuencias de un riesgo, junto con las medidas de control.
• Análisis de Causa Raíz (RCA): Permite identificar las causas subyacentes de un problema o riesgo, asegurando que las soluciones sean efectivas y sostenibles.

• Gestión de Riesgos del PMI: Según la guía PMBOK del Project Management Institute, la gestión de riesgos es un proceso estructurado que incluye identificar, analizar, responder y monitorear riesgos. Es ampliamente utilizado en la gestión de proyectos para garantizar que los objetivos se alcancen a pesar de las incertidumbres.
• TOGAF: En el contexto de arquitecturas empresariales, TOGAF (The Open Group Architecture Framework) considera la gestión de riesgos como una parte integral del diseño y desarrollo de soluciones tecnológicas. Ayuda a identificar y mitigar riesgos relacionados con la implementación de sistemas y procesos organizacionales.
• Open FAIR: Este modelo se enfoca en la evaluación de riesgos en términos financieros, lo que permite a las organizaciones cuantificar el impacto económico de los riesgos y priorizar estrategias de mitigación.

Matrices de Riesgos y su Aplicación

Las matrices de riesgos son herramientas visuales que ayudan a clasificar los riesgos según su probabilidad de ocurrencia y su impacto potencial. Estas matrices se dividen generalmente en niveles como bajo, medio y alto, lo que permite priorizar los riesgos más críticos.

El control de los riesgos a través de su ciclo de vida incluye los siguientes pasos:

1. Identificación: Documentar los riesgos potenciales asociados a procesos o actividades.
2. Análisis: Evaluar la probabilidad y el impacto de cada riesgo.
3. Planificación de Respuesta: Diseñar estrategias para mitigar, transferir, aceptar o evitar los riesgos.
4. Monitoreo: Supervisar continuamente los riesgos identificados y nuevos riesgos que puedan surgir.
5. Mitigación: Implementar acciones correctivas para reducir la probabilidad o impacto de los riesgos.

El proceso del Riesgo se vería así:

De forma práctica, una matriz simplifica seguimiento:

Casos de Uso 

• Sector Financiero: En instituciones financieras, la gestión del riesgo es crucial para evitar pérdidas económicas y garantizar la estabilidad. Por ejemplo, el uso de modelos predictivos ayuda a identificar riesgos de crédito y fraude
• Aeronáutica: En este sector, la seguridad es primordial. La implementación de la ISO 31000 permite identificar riesgos operativos y técnicos, asegurando la calidad y confiabilidad de los sistemas
• Salud: En hospitales y clínicas, la gestión del riesgo ayuda a prevenir errores médicos y garantizar la seguridad del paciente. Herramientas como el análisis de causa-efecto son útiles para identificar áreas críticas
• Energía: Las empresas energéticas, como las de petróleo, gas y renovables, enfrentan riesgos ambientales, regulatorios y técnicos. La gestión del riesgo incluye planes de contingencia para derrames, interrupciones en el suministro y accidentes en plantas de generación.
• Bancos: En el sector bancario, la gestión del riesgo se centra en aspectos como ciberseguridad, riesgos de liquidez y cumplimiento regulatorio. Por ejemplo, implementar auditorías periódicas y sistemas de encriptación avanzada ayuda a minimizar vulnerabilidades.

Nos referimos a la  inteligencia de riesgos como la capacidad perfeccionada para interpretar rigurosamente los riesgos y las consecuencias u oportunidades que suponen para una empresa. Permite a los líderes ver a través de la complejidad del entorno e identificar, categorizar e interpretar sistemáticamente los riesgos. Esto les permite mirar más allá de los factores de riesgo conocidos y explorar intencionadamente los riesgos que aún no se conocen, aceptando así la incertidumbre en lugar de evitarla.

La categorización del riesgo comienza con la comprensión del alcance de un evento de riesgo, lo que transmite una idea de cuán ampliamente se sentirán los efectos de un riesgo en toda la gama de partes interesadas afectadas.

En resumen,

La administración del riesgo no solo protege a las organizaciones de posibles amenazas, sino que también les permite aprovechar oportunidades. Adoptar la ISO 31000, junto con técnicas como el análisis de causa raíz, y modelos como los del PMI, TOGAF y Open FAIR, asegura un enfoque integral y efectivo. Las matrices de riesgos y un control adecuado a lo largo del ciclo de vida del riesgo son herramientas clave para mantener a las organizaciones preparadas y resilientes.

De acuerdo a la administración y controles de cada empresa y regulación, se personalizan estos elementos y se complementan con diferentes artefactos de definición, control y seguimiento.

Jorge Mercado

#JMCoach el original, desde 2013

IT-Governance praxisnah

 

IT-Governance ist ein integraler Bestandteil der Unternehmensführung und besteht aus Führung, Prozessen und Strukturen, die sicherstellen, dass die Technologien der Organisation die Ziele und Strategien des Unternehmens unterstützen.

Da der erhebliche Einfluss, den Informationen auf den Erfolg eines Unternehmens haben können, für die Unternehmensleitung von strategischer Bedeutung ist, werden sie zu einem Schlüsselfaktor bei der Festlegung des weiteren Vorgehens.

Regelmäßig muss man wissen, ob die in der Organisation verwalteten Informationen Folgendes ermöglichen:

Ø  Sicherstellung der Zielerreichung

Ø  Über ausreichende Flexibilität zum Lernen und Anpassen verfügen

Ø  Verlassen Sie sich auf ein umsichtiges Management der Risiken, denen Sie ausgesetzt sind

Ebenso wie die Unternehmensführung von entscheidender Bedeutung ist, um sicherzustellen, dass wichtige Entscheidungen mit den Werten, der Vision und der Strategie eines Unternehmens/einer Institution im Einklang stehen, ist die IT-Governance von wesentlicher Bedeutung, um sicherzustellen, dass Entscheidungen in Bezug auf Informationstechnologien mit den Zielen der Organisation/Institution übereinstimmen.

Um den Ertrag jeder IT-Investition zu maximieren und die Technologie als Waffe im Wettbewerb einzusetzen, ist eine Veränderung der IT-Rolle erforderlich. Auf diese Weise stellen wir sicher, dass sich der Geschäftsansatz der IT von einer rein reaktiven zu einer proaktiven Herangehensweise wandelt, die die Bedürfnisse der Organisation/Institution vorwegnimmt.

Untersuchungen zu den IT-Managementpraktiken bei Hunderten von Unternehmen auf der ganzen Welt haben ergeben, dass die meisten Organisationen ihre IT-Investitionen nicht optimieren. Der entscheidende Faktor zwischen erfolgreichen und erfolglosen Unternehmen liegt in der Einbindung des Managements in wichtige IT-Entscheidungen. Eine angemessene Einbindung des Managements in diese Entscheidungen steigert den Wert von IT-Investitionen und trägt dazu bei, IT-bezogene Katastrophen zu verhindern. Es muss zwischen strategischen und operativen Entscheidungen unterschieden werden, und diese Entscheidungen müssen mit den strategischen und operativen Plänen des Unternehmens in Einklang gebracht werden.

In der Branche gibt es üblicherweise vier Implementierungsstile für IT-Governance, jeder mit seinen eigenen Vor- und Nachteilen. Tatsache ist, dass sie stark in der Definition des „Was“ und schwach im wichtigen Teil der Definition des „Wie“ sind. Hinzu kommt, dass sie von einem Management wie der IT und ihren Grenzen ausgehen.

Notwendigkeit der IT-Governance

Zur Wertschöpfung bedarf es einer guten Governance und Verwaltung der IT-Ressourcen, -Risiken, -Strategien und -Informationen.

Manager müssen die IT als wichtigen Bestandteil des Geschäfts akzeptieren.

Externe Anforderungen an die Nutzung von Informationen und Technologien – sowohl gesetzliche als auch regulatorische und vertragliche – steigen täglich. Wenn sie nicht erfüllt werden, sind Vermögenswerte gefährdet.

Es wird ein IT-Governance-Modell vorgeschlagen, das grundsätzlich auf ISO 38500:2008 basiert. Das Modell hat 4 Ebenen:

1.      Grundsätze der Norm ISO 38500. Sie stellen die oberste Ebene des Modells dar und sind Verantwortung, Strategie, Beschaffung, Compliance, Leistung und menschliches Verhalten.

2.      IT- Ziele . Sie stellen eine Zwischenebene des Modells dar und sollten für IT-Manager als Referenz dienen, um alle erforderlichen Ziele zu ermitteln, um eine gute IT-Governance zu erreichen und den größtmöglichen Nutzen für die Institution zu erzielen.

3.      Beziehung zwischen ISO-Prinzipien und IT-Zielen . Jedes Prinzip kann durch mehrere IT-Ziele erreicht werden und ein Ziel kann zum Erreichen verschiedener Prinzipien des Standards beitragen.

4.      Indikatoren . Sie nehmen die unterste Ebene des Modells ein und dienen der Messung des Erreichungsgrads der IT-Ziele.

Eine Studie von Managed Objects zeigt, dass 41 % der IT-Leiter nicht planen, Grundsätze der IT-Governance einzuführen. Mehr als ein Drittel der 179 befragten britischen IT-Direktoren geben Zeit- und Geldmangel als Hauptgründe dafür an, dass sie die Leistung ihrer Prozesse nicht messen. Darüber hinaus weisen sie auf die Schwierigkeit hin, Schlüsselkennzahlen zur Berechnung der IT-Leistung zu identifizieren.

Führung

Governance besteht aus einer Struktur von Beziehungen und Prozessen, die der Leitung und Kontrolle des Unternehmens/der Institution dienen, mit dem Ziel, die Unternehmensziele zu erreichen, Mehrwert zu schaffen und gleichzeitig Risiken und Erträge der IT und ihrer Prozesse abzuwägen.

Um den Ertrag aus IT-Investitionen zu maximieren und Technologie als Wettbewerbswaffe einzusetzen, ist eine Veränderung der IT-Rolle erforderlich. Auf diese Weise stellen wir sicher, dass sich die Einstellung der IT gegenüber dem Geschäft von einer bloßen Reaktion zu einer proaktiven Haltung wandelt, die die Bedürfnisse der Organisation vorwegnimmt.

„Strategie ohne Taktik ist der langsame Weg zum Sieg.

 „Taktik ohne Strategie ist der Lärm vor der Niederlage.“

#JMCoach    

https://www.linkedin.com/in/mxjormer 

Accompagnement plutôt que formation ou conseil traditionnel (Coaching appliqué, Immersion pratique)

 Comment s’est opéré ce changement de formation et/ou d’accompagnement ?

Dans la vie réelle, les entreprises doivent développer le talent humain, pas seulement avec des théories, de bons vœux, un bon diplôme et de jolis timbres.

Ils ont besoin de leur talent pour créer, produire, proposer, innover, résoudre, développer ; faire en sorte que tout cela contribue à la productivité, à l’efficacité, à de meilleurs résultats, aux conditions de travail, au plaisir de ce qu’ils font, etc.

Du côté de la formation, par exemple, nous avons développé un modèle qui reprend certainement les bases théoriques ; mais nous les mettons en pratique avec des artefacts tangibles. Autrement dit, nous ne pratiquons pas les outils de manière classique pour que les gens prennent conscience du potentiel de ce qu'ils apprennent. Dans le modèle traditionnel, nous les laissions alors libre d'apprendre par essais et erreurs, au mieux.

Contrairement au modèle traditionnel, nous concentrons les exercices pratiques sur des situations commerciales réelles afin qu'à la fin, ils disposent d'artefacts utiles dans leur travail quotidien et servent de modèles pour continuer à développer des avantages de manière exponentielle .

Par exemple, si le sujet est le BPM, au-delà de l’identification de la théorie et des outils les plus connus ; Ils auront des artefacts appliqués à leur projet/entreprise.

Ou s'il s'agit d'une amélioration continue, ils proposeront des prototypes mis en œuvre avec des résultats dans leur entreprise/projet basés sur JICA et Six Sigma.

En conséquence de ce qui précède, les entreprises disposent de zones de développement personnalisées, de cabinets de conseil, d'usines de logiciels, etc. Comme nous le savons tous, lorsque nous arrivons sur des projets, ils se débattent avec la qualité de leurs produits et l'établissement de normes et de modèles qui leur facilitent la vie dès le début de chaque projet.

Pour les entreprises qui ne disposent pas de départements informatiques pour le développement et les processus, la formation ou le conseil comprend la mise en œuvre et les résultats avec des experts.

C'est ainsi qu'est né l'accompagnement , c'est-à-dire le placement d'experts fonctionnels dans les entreprises afin qu'en plus de former le talent humain avec méthode et une culture axée sur les résultats, ils les aident également à développer leur propre infrastructure de développement avec des artefacts utiles, pratiques et réutilisables, ainsi que des modèles PMO agiles.

Un exemple typique est l’automatisation du domaine de l’assurance qualité avec des BOT.

Ce qui précède n’est qu’une petite partie du grand potentiel de la mise en œuvre des bons outils tels qu’Enterprise Architect, qui offre de nombreux avantages pour réduire le temps et augmenter la qualité du SDLC.

En poussant cela à un autre niveau, nous parlons par exemple de Systèmes Évolutionnaires ; où nous avons déjà atteint MegaSoftware et sa mise en œuvre dans la vie réelle, comme c'est le cas dans le segment de la santé et de la biotechnologie, où nous avons ajouté une culture avec des résultats incroyables.

Les méthodes conventionnelles de développement de logiciels ne répondent pas au développement scientifique de logiciels, et encore moins à des logiciels qui ne sont plus administratifs, mais plutôt évolutifs et biologiques.

Le développement doit se concentrer sur le métamodèle de création du logiciel qui permet sa mise en œuvre et son adaptation à l'écosystème, c'est-à-dire qu'une entité logicielle intelligente doit implémenter les interfaces et les données nécessaires pour automatiser le processus et les activités.

Les outils générés pour aider les personnes à effectuer des tâches spécifiques dans leurs processus doivent dépendre du processus et de ses objectifs ; aboutissant à des méta-modèles d'outils générant du code (BOTs, intelligence artificielle, etc.)   et à leur implémentation.

Le développement logiciel enseigné dans les écoles au Mexique et dans de nombreux autres pays est dépourvu de logique des objets et des actes de la vie quotidienne, et conserve une grande partie de la logique administrative et conventionnelle « orientée objets ». Si la programmation était réellement orientée objet, il n'existerait pas de logiciels obsolètes aux coûts de maintenance élevés.

Refléter un objet dans un miroir ne garantit pas que nous puissions le créer ou le cloner, le développement logiciel actuel est le reflet de la collecte des besoins commerciaux ; Il n’obéit pas à une méthode de création mais plutôt à une méthode d’automatisation et la réalité est que le logiciel doit être créé par un « MegaSoftware », c’est-à-dire un « Software » qui crée un logiciel basé sur l’essence et les principes de l’écosystème d’entreprise.

Aujourd’hui, l’acceptation est élevée et les entreprises, au-delà des modèles de conseil ou d’usine de logiciels, ont adopté l’immersion pratique, qui consiste à placer du personnel hautement spécialisé dans les problèmes les plus douloureux des entreprises. Leur travail consiste non seulement à résoudre, mais aussi à partager et à accompagner les équipes de travail pour les aider à résoudre, développer et analyser avec une nouvelle approche ce dont l’entreprise a besoin pour générer de la valeur, résoudre les problèmes et résoudre les crises. Au final, vivre la culture des solutions en faisant bouger les choses, vivre le modèle de solution au jour le jour et apprendre des techniques, des outils, des raisonnements.

#JMCoach      Jorge Mercado

mx.linkedin.com/in/mxjormer

Between digitally functioning cultures

Much has been heard about methodologies, frameworks, best practices, trends, or whatever you want to call them, based on experience in a project or company.

The issue really starts with how to organize and personalize the good practice(s) so that they bear fruit, which in the end we know as culture; yes, it is an ecosystem that goes beyond implementing an agile framework, some type of project management, products or values ​​(PMO, VMO, etc.), following a line that lately seeks more multidisciplinary teams focused on a product or business area, similar to Squads or whatever name you want to give it, in the end the effort is not comprehensive.

 Often, efforts are somewhat isolated, failing to consolidate or generate the expected value, precisely because they forget to start from unity and understand the full context of needs. That is, there is no strategic alignment, and the consequences are mixed, and in some cases, not what was expected.

 

Lack of knowledge of strategic planning is also not a limitation, as every company has objectives to address and, in some way, defines or plans them to achieve them.

Some companies focus on processes, others on products, and some float and define things as they go along. In any case, the culture mentioned above can bear fruit, since this flexibility is what empowers people to make things happen. Breaking the belief that they only think about results is possible if they permeate the culture and trust the processes, which will empower the lines or ways of operating.

As complex as it may seem, in the end culture starts with putting order in order to govern and orchestrate people, products, services, operations, administration and whatever else you want to add. To ensure that a company, of any size or area, obtains its results, positioning, growth; this organized and orchestrated mix comes into play, enabling the “how to” and breaking the nightmares experienced over time with different isolated efforts, consultancies or in-house areas of all types and sizes that come and go with mixed or unexpected results.

 

It is then that the experience developed over decades and collaborative work has been polished with a model based on perspectives and pillars that support precisely this famous culture that, when adopted, allows things to happen, that areas and teams organized with global knowledge of the business produce greater value and operate in a simple, flexible, truly agile way and oriented towards how yes, simply living the process of this form of orchestrated organization from a comprehensive perspective.

This is how the "Harmonized Perspectives Model" was born, which we will explore in upcoming publications. It has been refined and tested for years in different companies and sectors, both in cloud-based and cloud-free models, as well as hybrid models, among other factors that will be discussed in subsequent articles. In short, it has been refined for digital transformation and improvement solutions.

Jorge Mercado

#JMCoach

Un acercamiento a las bases del ADM (Acts Driven Model)

ADM surge como el facilitador y orquestador para que el negocio explote los beneficios de los procesos, productos, tecnología, etc; para lograr los objetivos estratégicos, alinear las áreas y lograr la preferencia de los clientes. El secreto pasar a la acción sin ahogarse en la documentación, tampoco construir sin sentido y sin lo mínimo necesario. Es importante saber, dónde estamos, hacia dónde vamos y sobretodo cómo lo haremos. Conocer el negocio, tanto en su pulso que es identificar lo que sucede con números; así como, identificar de forma simple, fácil y flexible el cómo agregar o ajustar los modelos/procesos actuales para seguir adelante ante la competencia y oportunidades empresariales.

En cierta forma un modelo similar con orientación específica en salud fue impulsado por una organización y lo llaman HL7(Health Level 7), con varias versiones actualizadas. Su punto es que nacieron sin considerar la programación orientada a objetos, la homologación de modelos de datos, sin trazabilidad/rastreabilidad, mezclaba mensajes-eventos-campos; requiere ajustes personalizados. Sin duda es un modelo eficiente en su nicho y se alineó sobre RIM, mejoró vocabulario controlado, adoptaron en modelos recientes la POO y UML, incluso con un salto con dominios y clases base. Lo he visto en sectores como aeronáutica y energía también ya con algunas variantes. Algunos esfuerzos aislados de gente que de forma básica solo cubren algunas partes como addra, erpac, aba, asn, etc.

En HL7 se asimilan los objetos al representar Roles de aplicación, Eventos de Activación y Escenarios con casos de uso, que recaen sobre modelos de datos y la interacción que encola el proceso. Toda la estructura de los mensajes HL7 se construye a partir de clases y asociaciones basadas en RIM. Las entidades quedan en bases de datos relacionales principalmente.

RIM que también es una parte menor del Acts Driven Model, considera 6 clases fundamentales: Actuación/Actos, Entidad, Rol, Participante, Actuación relacionada, Rol relacionado. De estas clases se pueden crearse especializaciones de la clase. Con UML se representa de igual forma la cardinalidad y asociaciones, independiente de los atributos y métodos. Dejando al final un modelo de mensajes de información o eventos.

Lo anterior se enriquece en ADM con diagramas de estado y siguiendo la práctica del 4+1 vistas, alineación estratégica, modelos de gestión/operación de producto, arquitectura empresarial, entre otros, según sea el caso.

Estandarizar las acciones, es un plus si tomamos de la estimación por puntos, la práctica de la verbalización. Que también es parte de ADM.

Las Entidades en ADM viven en bases de datos relacionales, llave-valor, orientadas a objetos o de grafos. Y se prefiere usar Json sobre XML que era todavía hace poco tiempo la base de HL7. y Ahora con la madurez de las bases de datos de grafos se ha simplificado bastante, además de la versatilidad lograda con llave-valor. El secreto parte de estructuras los dominios para que la data genere valor y cuente historias, más allá de solo acumularla en bruto, al final esto habilitará su explotación, ML, AI, etc.

Esto nos va llevando sin duda al terreno de los patrones, algoritmos, metadata y en sí a las bases de metasoftware que sería la versión con mayor madurez de la generación de código empleando el diseño y modelado con ADM, como una evolución de las herramientas CASE.

ADM considera desde un inicio implementación con arquitecturas de alta disponibilidad en modalidad lambda (las kappa tienen limitantes al manejar solo data caliente). Se busca simplificar con orquestadores como Kafka o equivalente según las preferencias del cliente final, microservicios verificados y orquestados. Además de cuidar en todo momento el linaje y protección de los datos; así es todo debe viajar seguro y hay foco en cuidar datos, servicios, plataforma; no solo construir sin sentido y omitiendo documentar como sucede en muchos casos; obviamente esas malas prácticas no son el espíritu de ADM, tampoco se pelea documentar y hacer las cosas bien con la calidad, control, el CI/CD, simplicidad, flexibilidad y alto performance.

Una parte interesante recordando instrucción en ingeniería que agrega mucho valor, es recordar las bases de los compiladores, autómatas y lenguajes, así como los principios de las redes neuronales, que viene a enriquecer la ingeniería de software y los modelos de arquitectura que han evolucionado a la fecha.

Fuera de tecnicismos, ¿a dónde vamos?, es a recordar que se ha evolucionado la tecnología y métodos para simplificar el lograr los objetivos de negocio; al alinearse con el producto y/o negocio para que realmente las empresas generen valor, produzcan resultados tangibles para sus clientes y así mismos; crear e innovar con simplicidad y flexibilidad, alimentar realmente equipos multidisciplinarios que rompen lo convencional sin alejarse la regulación, más aún, haciendo que el mismo proceso sea rentable, que pase de un simple ROI ha modelos de economías de escala y la habilidad de adaptarse al cambiante entorno que cada año reta con pandemias, guerras, crisis, etc; al final son el alimento para salir de las zonas de confort y crear productos/servicios que realmente producen valor para todos.

Puede sonar loco desde un inicio, pero justo conocer tu empresa, procesos; es parte de implementar el pulso de la empresa; que terminará por consolidar el modelo de negocio tomando decisiones realmente con oportunidad y visibilidad de los impactos al ajustar algo y simplificar su implementación para consolidarse en el mercado.

Cómo implementarlo, bueno ya se prepara un libro con ejemplos y casos reales que sirvan de guía. Además del exitoso modelo de acompañamiento que ya he explicado en otro artículo de mi blog.

Si nos gusta un poco más de referencia, además de la parte de patrones e ingeniería de software; algunas partes provienen de compiladores, teoría de autómatas, lenguajes, redes neuronales, entre otros.

A finales del siglo anterior, las redes neuronales tenían un avance relevante con los lenguajes disponibles y que hoy en día explotan en AI y/o ML. Desde los años cuarenta, toma fuerza y se lleva a materializar en los años cincuenta con el perceptrón, adaline, madaline y otros modelos/arquitecturas. Hay un ensamble con la aparición de los computadores digitales, el procesamiento neuronal y las teorías sobre el aprendizaje; nacen los ANS (Sistemas Neuronales Artificiales); vaya que nos tocó modelar con C, C++ y Ada en aquel entonces en ingeniería. Fue enriquecido por el PDP(Procesamiento Paralelo Distribuido). Hoy en día ya no es bloqueante conocer matemáticas avanzadas para los practicantes. Entre convergencias y divergencias las 14 arquitecturas típicas hoy en día se han traducido en herramientas simplemente listas para usar.

Los compiladores más allá de los análisis, sintaxis, comprobaciones, parseos; dan pauta para la generación de código (parte de verdadero plus de ADM, CASE, otros). Los principios y técnicas de escritura de los compiladores crean un gran abanico de posibilidades; esto comprende lenguajes de programación, arquitecturas, teoría de lenguajes, algoritmos, ingeniería de software, entre otros; con el beneficio y apoyo de los traductores. Es entonces que se puede generar código correcto mas no óptimo. Las estructuras de datos, sobre todo árboles y grafos, así como verbalización estandarizada suman simplicidad y control.

Para los que gustan de la teoría de autómatas, lenguajes y similares por el tema de la máquina de Turing, que tan solo es uno de los tantos modelos. igual parte de grafos, árboles, lenguaje, conjuntos, cadenas, inducción matemática, parseo (aquí algunos que manejan datos encontrarán sentido). Puede recibir un aderezo con la Fuzzy logic (.La lógica difusa, es una lógica que permite llegar a conclusiones “razonadas” a partir de información ambigua o imprecisa. Se presentó como una forma de interpretar información basada en la pertenencia parcial de tal información con respecto a un determinado tipo de conjuntos, definidos como conjuntos difusos. Es una rama de las matemáticas que busca modelos capaces de expresar lo que conocemos como incertidumbre o grados. Cuando trabajas en lógica matemática clásica, para cada frase o cada tema que vayas a tratar solo tienes dos posibilidades de definirlo: o es verdadero o es falso). Luego ponerle el poder de PROLOG (un lenguaje declarativo: se especifica qué problema se desea resolver en lugar de cómo resolverlo).

Así es este mundo de conocimiento pero que ahora simplemente se consume.

Jorge Mercado

#JMCoach el original