lunes, 29 de septiembre de 2014

Comunicación transformadora: de la empatía la resonancia

La comunicación es poderosa. La palabra es poderosa. Con la comunicación se puede simplemente informar o compartir, pero también se puede liderar, se puede mover a la acción, se puede, en definitiva, transformar

Así de claro lo expresa Nancy Duarte en su libro 'Resonate':

Genuine connections create change.

y es que la palabra es vehículo de ideas, ideas que viajan de una mente a otra, de un corazón a otro...

The spoken word pushes out of someone's head and into the open so humankind can contend with adopting or rejecting its validity.

Pero esta autora, experta en comunicación, deja claro que no vale cualquier comunicación. Ya en la primera sentencia se usa el adjetivo genuina...que por sí mismo resulta revelador...

Pero quizá hay otros dos factores más importantes. 

En primer lugar, la empatía. En una comunicación, al menos en una en que se pretende influir en nuestra audiencia, es importante no querer convertirse en el héroe, en el centro de atención. 

The audience does not need to tun themselves to you- you need to tune your message to them.

Todo lo contrario, el foco, el punto de interés es la propia audiencia, aquellos a los que se quiere mover, una audiencia a la que es preciso comprender, ponerse en su lugar, entender sus motivaciones y sentimientos. Es preciso llegar no sólo a los cerebros sino a los corazones, conseguir una profunda conexión.

Esa conexión, esa sintonía lleva a la resonancia, ese momento mágico en que el comunicador se sitúa en la misma frecuencia de la audiencia y la hace vibrar, sentir... y la mueve a la acción. 

Skilled presenting requires you to understand their hearts and minds and creat a message to resonate with what's already there.

Ese es el viaje, el apasionante viaje de la comunicación transformadora: empezar por poner el foco en la audiencia, empatizar con ella y apoyarse en esa empatía para conseguir entrar en resonancia.

Así sí. 

Así la palabra alcanza su máximo poder.

Así se puede transformar el mundo.

viernes, 26 de septiembre de 2014

Explorando el BABOK Versión 2.0

La guía 'Business Analysis Body of Knowledge (BABOK)' pretende ser el compendio y la estructuración de conocimiento dentro de la disciplina llamada Business Analysis (Análisis de negocio) y material de estudio fundamental para las certificaciones CBAP y CCBA.

Es una guía heredera en su estilo y organización del afamado PMBOK (Project Management Body of Knowledge) del ámbito de la dirección de proyectos.

El enfoque de estas guías (tanto el PMBOK como este BABOK que nos ocupa) es algo especial puesto que no profundizan demasiado en el conocimiento que exponen y no incluyen ejemplos, ejercicios o cualquier otro tipo de material pedagógico. Se trata, más bien, de una forma de estructurar el conocimiento de una disciplina y su vocabulrio fijando tan solo unos pocos principios básicos, de un modo que aspira a ser riguroso pero, al tiempo, muy abierto.

Por ello, si se lee el libro sin saber realmente lo que cabe esperar, puede ser decepcionante. La profundización en el entendimiento tanto de la guía como de la disciplina en general, debe ir acompañado por un lado de experiencia real y, por otro, de la lectura o estudio de materiales complementarios más específicos.

Por otro lado, en el caso de la versión 2.0 de este BABOK, da la sensación de que tanto a la disciplina del Análisis de Negocio, como al manual en sí mismo, le falta aún un cierto grado de madurez. Nos encontramos, en apariencia, ante una disciplina aún no del todo establecida, con fronteras algo difusas con otras profesiones y con un conjunto de técnicas aún por consolidar. De hecho, en el momento de redactar estas líneas, se encuentra ya en avanzado estado de elaboración la versión 3.0.

Este 'Business Analysis Body oh Knowledge (BABOK)' es lectura (y estudio) obligado si se pretende obtener una certificación en el campo del Análisis de Negocio y una forma de conocer los conceptos e ideas que se van convirtiendo en estándar 'de facto'. No es, sin embargo, una lectura apasionante en sí misma, ni tampoco el mejor material pedagógico para profundizar en el conocimiento de los temas que aborda.

Ficha técnica:

miércoles, 24 de septiembre de 2014

La comunicación, la magia y los magos

A medida que aprendemos más y más sobre la comunicación, especialmente la comunicación en público, nos vamos dando cuenta de la importancia de 'crear magia'.

Hemos aprendido la importancia de la narratividad, de contar historias.

Nos han hablado de lo positivo que es hablar sinceramente, y en primera persona de las propias experiencias.

Y hemos descubierto la importancia de usar las emociones y de generar emociones.

Conjugando todos esos factores narrativos, visuales, sentimentales se pueden crear momentos mágicos, se puede tocar el corazón y la voluntad del público y se le puede motivar, transformar e impulsar a la acción.

En esa línea, en el prefacio del libro de Nancy Duarte, 'Resonate', Dan Post presidente de Duarte Design hace esta categórica afirmación.

Great presentations are like magic.

Y sigue:

They amaze their audicences.

Pero también nos revela algo de estos magos de la comunicación.

great presenters are like magicians. In adition to practicing regularly, both are reluctant to reveal the methods behind their performances.

Supongo que es comprensible. Es tan satisfactorio, tan poderoso, tan especial esa capacidad de hacer magia que es comprensible el reflejo de guardar el secreto.

Aunque, en el caso de la comunicación, no creo que sea factible ocultarlo completamente. El resultado es visible, audible.. Aun sí... ¿es realmente copiable?

Creo que parcialmente. Se pueden aprender y copiar técnicas y estilos...pero la magia, al final, es magia... y la verdadera magia no tiene explicación.

lunes, 22 de septiembre de 2014

¿Por qué lo llaman negocio cuando quieren decir TI?

Hace ya muchos años que este tema me sorprende... y a veces, incluso, me molesta.

¿Por qué los profesionales del sector de las Tecnologías de la Información se empeñan en recubrir de un halo de negocio, de visión empresarial a lo que no son más que arquitecturas o soluciones software?

Por qué utilizan un lenguaje confuso por lo ambiguo, que elude lo tecnológico para apelar a lo empresarial?

¿Qué de que hablo?

Veamos algún ejemplo...aunque hay muchos, muchos más, seguro.

Hace ya bastantes años, con la evolución de las arquitecturas cliente-servidor, surgieron las arquitecturas multicapa, típicamente en tres capas.Una de las capas, la más profunda si se quiere, era la de datos. Otra, la capa en contacto con el usuario, era la capa de presentación. Y, en medio de ambas, estaba otra capa, la que contiene el comportamiento y el control. Podría habérsela denominado capa de lógica, capa de proceso, capa de control, capa de algoritmia... ¡quién sabe! Pero no, el nombre elegido fue... lógica de negocio. ¿De negocio? Si, de negocio. No es que sea incorrecto pero...

El mundo de la tecnología software ha ido evolucionando hacia arquitecturas SOA, arquitecturas orientada a servicios en que, siguiendo los principios básicos de la ingeniería software, se encapsulan en componentes ciertas lógicas que  luego se exponen para su reutilización en una serie de servicios.Y ¿qué nombre se eligió para estos servicios? Podrían habérselos llamado, simplemente, servicios, métodos expuestos, lógica exportada ¡qué sé yo!... Pero el nombre elegido fue... servicios de negocio. ¿De negocio? Si, de negocio.

En los sistemas de lógica compleja, por ejemplo, workflows o BPMS es corriente que ciertas lógicas se recojan en reglas. Y una forma de proporcionar flexibilidad y configurabilidad a los sistemas es externalizando en reglas administrables dichas lógicas. A estas colecciones de reglas se las podía denominar simplemente así, reglas. O reglas administrables, o lógicas configurables o... Pero el nombre elegido fue... ¿Lo adivinan? Si, ese, reglas de negocio. ¿De negocio? Si, de negocio.

Negocio parece ser una palabra atractiva, por lo que se ve. Pero no le va a la zaga la palabra empresa o empresarial.

Así, por ejemplo, cuando la integración entre sistemas ganó peso en las compañías, surgió el concepto de Enterprise Application Integration. 'Enterprise', o sea, empresa. Con los años, y la generalización de SOA, a la pieza de software, el middleware, que sirve para interconetcar aplicaciones y dar servicios como la persistencia o la adaptación de datos, el bus en definitiva, se le denomina... Enterprise Service Bus. Podría haber sido sólo bus, o service bus o integration bus, o... pero 'Enterprise', seguramente, añadía valor...

Cuando hoy en día se intenta conceptualizar y modelar el conjunto de procesos, datos y aplicaciones de una compañía hablamos de una arquitectura que...si, es arquitectura empresarial ('Enterprise architecture'). Quizá, de los expuestos, sea el caso en que más sentido tiene el apelativo, puesto que se modela toda la compañía y puesto que sus usos pueden, y deben, ir más allá del mundo de los sistemas. Pero, como llueve sobre mojado...


¿Qué le pasa al sector de las Tecnologías de la Información? ¿Por qué no se siente satisfecho con ser lo que es y se empeña en darle ese barniz de negocio?

¿Es que aún no ha superado el famoso artículo 'IT doesn't matter' de Nicholas Carr y se siente, quizá acomplejado, quizá obligado a demostrar que es capaz de entender y aportar al negocio?

¿Es que es una forma en que los CIOs pueden hacer ver que tienen una visión transversal que les habilita para cotas mayores de mando y posición en las compañías?

¿O es puro marketing porque las palabras 'negocio' y 'empresarial' son glamurosas y biensonantes?

Creo que las tecnologías de la información constituyen un campo interesante por derecho propio, importante por derecho propio, estratégico por derecho propio,... y además, suficientemente complejo.

¿Por qué no hablan de TI tranquilamente?

¿Por qué se empeñan en descafeinar y confundir?

¿Por qué, en fin, lo llaman negocio cuando quieren decir TI?

viernes, 19 de septiembre de 2014

Poniendo en marcha iniciativas de arquitectura empresarial con Guy Sereff

Estamos ante un libro muy breve, apenas unas 80 páginas, que recoge conceptos básicos sobre arquitectura empresarial en general y arquitectura empresarial de negocio y sobre todo algunos consejos prácticos para la autoevaluación de la madurez y para el lanzamiento de iniciativas relacionadas con arquitectura empresarial.

El propio autor reconoce al inicio del libro que se trata de una presentación Powerpoint 'venida a más', que suscitó tanto interés que valió la pena convertirla en libro.

El libro se estructura en tres partes:
  • 'Enterprise Architecture baseline' que introduce el concepto de arquitectura empresarial, , sus componentes habituales y algunas ideas básicas sobre cómo llevarla a cabo

  • 'Enterprise Business Architecture' que adopta un enfoque parecido al de la parte anterior pero ahora con el apellido 'business' (negocio) como cualificador de arquitectura empresarial

  • 'The game plan: implementation approach playbook' que es donde más se vuelca con los consejos y técnicas de orden práctico.
Entre las ventajas del libro, aparte de su brevedad, está que los concpetos que explica, que realmente son pocos, se exponen con orden y claridad y que da una panorámica muy rápida de algunos de las tendencias más relevantes en arquitectura empresarial lo que da pistas para estudio posterior.

Por lo demás, aunque tenga algunos consejos valiosos, la verdad es que tampoco se le puede sacar un gran jugo. Es lo que es, y probablemente cumple con los objetivos que se planteó el autor.

Guy Sereff

(Fuente: Elaboración propia a partir de perfil en Linkedin)

Guy Sereff es un profesional con más de 25 años de experiencia en tecnología, ocupando una amplia variedad de roles, entornos y servicios y actualmente Vicepresidente de Arquitectura Empresarial de American Express.

Su experiencia incluye investigación y desarrollo en un importante fabricante de software, gestión del desarrollo interno de tecnología y prestación de servicios de Arquitectura Empresarial en una institución financiera global y liderazgo de diferentes funciones relativas a arquitectura empresarial en una organización de tarjetas y medios de pago.

Puedes saber más sobre el autor consultando su perfil en LinkedIn.

Ficha técnica:

AUTOR: Guy Sereff
EDITORIAL: Guy Sereff
AÑO: 2012
ISBN: N/A
PAGINAS: 83

Artículos de este blog relacionados

miércoles, 17 de septiembre de 2014

Arquitectura empresarial, proyectos y la necesidad de ver el fin

A veces, quizá por falta de conocimientos, quizá por falta de disciplina o, más probablemente porque la magnitud del empeño abruma, se acometen grandes iniciativas sin un fin claro, sin una plan.

Existe una ambición y un objetivo difuso que parece deseable y lejano. 

Y se inicia la marcha.

Uno de los casos en que eso puede suceder es en proyectos de gran magnitud como una reingeniería de procesos o la definición e implantación de una arquitectura empresarial

Quizá se confía en la intuición. Quizá se considera un rasgo de iniciativa y arrojo. Quizá se piensa que no se es capaz de fijar unos objetivos hasta que no se haya avanzado en el camino.

Creo que es un error. 

Creo que es muy importante tener una idea clara de los objetivos que queremos lograr, de cuáles son los 'entregables' del proyecto que acometemos y cómo llegar a ellos. Es necesario tener una visión y es necesario, siguiendo la metodología tradicional de dirección de proyectos, un alcance, una planificación, unas tareas...

Es cierto que en proyectos de gran alcance es difícil ver con nitidez todos los detalles y que una planificación detallada o una descomposición de tareas finas no se pueden lograr quizá al principio. 

Es cierto que, por ejemplo, en el caso de una arquitectura empresarial, los detalles del modelo de procesos o de información o de la arquitectura tecnológica no es fácil establecerlos con nitidez en las primeras fases. Es cierto que en un proyecto complejo puede resultar algo lejano el definir los pasos de su despliegue.

Es cierto, también, que en proyectos complejos es necesario tener cierta flexibilidad y capacidad de adaptación. Es cierto que, como el algún artículo he afirmado, es importante 'saber conducir'...

Pero hay que tener una visión, un objetivo, un fin...y una idea de cómo llegar.

Incluso sabiendo conducir no se llega a ningún sitio...si no se sabe dónde se quiere llegar.

En el ámbito específico de la arquitectura empresarial, me alegra encontrar una idea parecida en el libro 'Launching an enterprise business architecture practice' de Guy Sereff cuando afirma:

one of the paramount habits of highly effective Enterprise Business Architects is the ability to begin with the end in mind.

Definir e implementar una arquitectura empresarial es uno de esos proyectos complejos y abrumadores. Por ello, ese 'fin en la mente', ese sentido de dirección, de objetivo...es fundamental.

Difícil lograr el éxito en caso contrario.

lunes, 15 de septiembre de 2014

Cinco dominios para una arquitectura empresarial

Hablar de arquitectura empresarial no sólo puede resultar algo ambicioso sino, también,  abstracto.

¿En qué se traduce realmente ese modelado de la empresa de qué hablamos?

Pueden existir variaciones de unos modelos y otros, pero aprovecho la lectura del libro 'Launching an enterprise business architecture practice ' de Guy Sereff para recoger los cinco grandes componentes que éste autor propone.

En el camino de la estrategia a la solución, Guy Sereff nos propone estos cinco componentes:
  • 1.- Arquitectura de negocio: elementos fundamentales de la estrategia de negocio, la visión, los objetivos, etc. Algunos de los elementos habitualmente descritos en este componente son:

    • Capacidades de negocio (AS-IS y TO-BE)
    • Estructura de componentes de negocio
    • Procesos de negocio y flujos de valor
    • Modelo de negocio conceptual

  • 2.- Arquitectura de información: elementos de información acompañados si es pertinente de metadatos y con una descripción tanto conceptual como lógica. Algunos elementos son:

    • Modelos de información
    • Modelos de servicios
    • Flujo transaccional de datos
    • Metadatos persistentes/transitorios

  • 3.- Arquitectura de soluciones: introduce las consideraciones específicas de las diferentes plataformas, así como componentes de soporte. Elementos:

    • Arquitectura de referencia
    • Optimización de diseño específico para cada plataforma
    • Solución de gestión del porfolio
    • Capacidad tecnológica

  • 4.- Arquitectura de aplicaciones: proporciona especificaciones de diseño para generar una instancia específica de una solución basada en un proyecto o versión específica. Utiliza artefactos como diagramas de secuencia, especificaciones XML, matrices de trazabilidad de requisitos, etc para describir aspectos como:

    • Implementación y herramientas
    • Despliegue de la solución
    • Gestión de configuración software
    • Gestión de activos de propiedad intelectual

  • 5.- Arquitectura de plataformas: se centra en el despliegue físico de la solución proporcionando datos como ubicación en data center, direcciones de dispositivos y servidores, versiones de sistema operativo y nivel de parcheado, etc. Incluye, pues:

    • Despliegue de infraestructura estratégica
    • Monitorización de prestaciones / planificación de capacidad
    • Escalabilidad horizontal y vertical
    • Gestión de activos físicos
    • Continuidad de operaciones de negocio

Para mi gusto, el modelo que propone Guy Sereff está demasiado sesgado hacia los aspectos IT y de implementación, apenas rozando los aspectos de negocio. Aún así, y aunque algunos elementos pueden resultar confusos y podrían precisar más detalles, creo que puede servir para entender algo más el concepto de arquitectura empresarial.