Separata para Profesionales de Proyectos TI

    por Roger T. Burlton, Ronald G. Ross y John A. Zachman1

     
     

     ~~~

    A. La verdadera Agilidad del Negocio

    • La verdadera agilidad del negocio no depende únicamente del desarrollo constante del software sino del cambio constante del negocio.
    • La verdadera agilidad del negocio no se mide solamente por la capacidad de reacción ante peticiones, cambios o interrupciones sino también por la coherencia de esa reacción.
    • La verdadera agilidad del negocio solo funciona cuando se han eliminado todos los silos o cadenas de montaje no integradas dentro de las cadenas de valor.

    B. Los equipos que actúan de manera autónoma

    • Los equipos que actúan de manera autónoma, así como otras organizaciones ágiles, no conducen por sí mismos a la agilidad del negocio.
    • Los equipos que actúan de manera autónoma son un medio, no un fin. En lugar de reducir, aumentan la necesidad de establecer las estrategias de negocio, la coherencia en la cadena de valor, la reutilización del conocimiento del negocio, y un portfolio de dirección eficaz.

    C. Enfoque centrado en el cliente  / orientado al cliente

    • El enfoque centrado en el cliente es esencial, pero nunca puede ser el único objetivo del negocio. Algunos aspectos del negocio son inamovibles, por ejemplo, la compensación/el intercambio con otros objetivos del negocio, el coste total de la propiedad, el cumplimiento, los riesgos inasumibles y los costes prohibitivos.
    • El verdadero cliente del negocio es el cliente del producto del negocio, no el propietario del producto de software.
    • Entre la gente de negocios, el término “cliente” debería referirse siempre a cliente del negocio y la palabra “producto” a producto del negocio.
    • Los usuarios no son necesariamente clientes: la experiencia de un usuario no tiene por qué ser la experiencia de un cliente; por lo tanto, debe predominar/prevalecer la experiencia del cliente.
    • La experiencia de cliente excelente incluye todos los puntos de contacto con los clientes, no únicamente los digitales.

    D. Fracaso rápido 

    • El fracaso costoso o repetido, aunque sea rápido, es un desperdicio que hay que eliminar (que una empresa no se puede permitir).
    • Habría que valorar si fracasar rápido para aprender rápido compensa otros aspectos como el impacto que este fracaso pueda tener entre los clientes, el coste de rehacer el producto y la exposición al riesgo. 

    E. Comunicación

    • Es muy arriesgado confiar únicamente en las conversaciones cara a cara para  transmitir y conservar el conocimiento de negocio.
    • La comunicación eficaz del conocimiento del negocio a través del tiempo, es decir, su retentiva, no tiene precio. Esto resulta mucho más difícil que simplemente cerrar la brecha de comunicación en los proyectos.
    • Una habilidad fundamental para los analistas es la de involucrarse en diálogos para evaluar  el conocimiento del negocio en busca de brechas, conflictos, ambigüedades e integridad. 

    F. Cambio

    • Nuestro objetivo no es el cambio inmediato, si no el cambio sopesado que consigue el efecto de negocio deseado y evita los efectos secundarios involuntarios.
    • Nuestro objetivo tampoco es el cambio pactado, pero sí lo es aquel cambio que ha sido acordado/moldeado según la estrategia del negocio, su política, y las obligaciones y compromisos del negocio.
    • Y tampoco es nuestro objetivo el cambio privado y excepcional, si no el cambio expansible y constante.

    G. Líneas de negocio existentes

    • No tiene sentido escatimar en la calidad del software del negocio —creando así una deuda técnica—ya que perjudica al esfuerzo de los negocio que intentan cambiar líneas de negocio ya existentes.
    • En las líneas de negocio ya existentes, los equipos de desarrollo de software que actúan de manera autónoma contribuyen a la agilidad del negocio únicamente si se basan en, y colaboran con, el conocimiento del negocio explícito y mutuo.
    • En líneas de negocio ya existentes el plazo de comercialización depende directamente de la agilidad de reconfiguración.

    H. Modelos conceptuales

    • Un modelo conceptual se centra en qué palabras hay que utilizar a la hora de hablar del negocio, sobre todo por escrito y en cualquier otra comunicación, prestando especial atención al significado de esas palabras.
    • Las cosas en un modelo conceptual no representan cosas en el mundo real, si no la comprensión común de esas cosas en el mundo del negocio según lo expresan las definiciones del negocio.
    • Las conexiones en un modelo conceptual indican cómo se relacionan los conceptos entre ellos de manera lógica, es decir, de forma estructural. 
    • Un modelo conceptual se representa con un vocabulario de negocio estructurado que incluye frases nominales y verbales. 
    • No son modelos conceptuales los siguientes: un modelo de datos, un diagrama de clase, un diagrama entidad-relación, un modelo de proceso, un caso de uso o un diagrama de actividad. 

    I. Reglas de negocio

    • La expresión eficaz de las reglas de negocio necesita un modelo conceptual.
    • Los negocios se basan en obligaciones y compromisos contractuales que pueden infringirse aunque eso conlleve consecuencias personales o de negocio.
    • Una vez que las reglas de negocio se han codificado de manera procedimental, la semántica se pierde y no puede restablecerse de forma automática. Esta pérdida se traduce en un objetivo de negocios confuso y en una reutilización imposible.

     J. Diseño y desarrollo de software

    • La agilidad en los negocios no se consigue únicamente con prácticas ágiles de software.
    • La rápida producción de software tiende a sub-optimize subsequent rapid cost- eficaz modificación del conocimiento de negocio.
    • Las historias de los usuarios, los casos de uso, y los prototipos de software pueden perder fácilmente gran parte del conocimiento del negocio que se necesita para una solución de negocio completa, eficaz y variable.
    • Algunos aspectos no tienen orden jerárquico contra las prioridades de software feature, por ejemplo: el cumplimiento de las obligaciones y compromisos contractuales, la adecuación en la cadena de valor y la reutilización del conocimiento de negocio explícito.
    • Una estrategia de software que falle a la hora de capturar, conservar y reutilizar el conocimiento de negocio resulta inapropiada para la economía del conocimiento. 

     

    Dutch Download Button


    1 Gracias a Gladys S.W. Lam por sus aportaciones al contenido y por la organización del conjunto de documentos del manifiesto, y a Sasha Aganova por coordinar la obra completa.

    © Business Rule Solutions, LLC. 2017.                                                                                                        

    © John A. Zachman, Zachman International. 2017. 

    © Process Renewal Consulting Group (2015), Inc. 2017.

    © Traducción 2022 by The Anonymous Architect y Natural Rules http://www.theanonymousarchitect.com/ https://www.naturalrules.net/

    Se concede permiso para la reproducción y distribución ilimitada de este documento bajo las siguientes condiciones: (a) Los derechos de autor y este aviso de permiso están claramente incluidos. (b) La obra está claramente acreditada a sus tres autores. (c) Ninguna parte del documento, incluyendo el título, el contenido, los derechos de autor y el aviso de permiso, es alterada, abreviada o extendida de ninguna manera.