lunes, 7 de noviembre de 2011

Nos gustan las historias


Esto es real, y también tiene qué ver con patrones. En Argentina, en fútbol, hace muchos años, River Plate compró el pase de un jugador famoso llamado Bernabé Ferreyra. Lo compró por 35 mil pesos de la época. Los racionales, los rígidos, investigarían, y contarían, "muy caro", "200 mil dólares de ahora", "River gastaba mucho", "el mercado de pases...", etc, en frases que no interesan mucho en ese tiempo y ahora. Pero una revista publicó un escrito así: ¿Qué se puede comprar con el costo del pase del gran Bernabé? 11 automóviles Opel, 514trajes de Kashmir, 5600 pares de zapatos, etc., algo que sí es interesante, ilustrativo, y divertido, aún en este tiempo agitado de ver las cosas ya.

La revista,"Caras y Caretas", lo que hizo fue aplicar ejercicios de visualización, con un sentido, hacia la actualidad, las noticias. Tomar la palabra en un tema no tan simple, denso, de una forma que capte la atención al momento, fácil, y que dé una idea clara, para todos, lo hace a través de una situación, una historia, de comprar, de comprar cosas, tener mucho dinero y qué hacer con ese dinero. 

Pues, sabemos, estamos en un mundo agitado, no se puede perder tiempo, hay que ir a la fija, cuanto antes, en todo, y la idea también de visualizar, comunicar con imágenes, es atender esa necesidad de saber, informarse, tener conocimientos, al mismo ritmo. Pero también, el mundo de ahora, en serio, adulto, todo es objetivos, resultados, y uno quiere más tiempo para hacer una pausa, contemplar, jugar de vez en cuando. Todavía somos niños, nos gustan las historias, saber cosas, en forma narrativa, ilustrativa, lúdica, que no se quede en números, o como algo que pasó, o es así, y pasemos al asunto siguiente. 

En ese sentido, y personalmente, ese es el propósito de visualizar, contar historias con información. Y aplica también para cualquier campo, o situación. Y también para el espacio profesional, mayor, de diseñar, acompañar empresas, en hacer procesos, hacer sus cosas más ágilmente, sin dolor, consiguiendo lo que necesiten. En arquitectura empresarial, diseño de procesos, soluciones, se necesita ver as cosas, que sea como un libro abierto; y así como con el conocimiento, los objetivos, las expectativas, lo que quiere conseguirse, la forma de hacerlo, no debe ser oculto, reservado, solo para los expertos, los que poseen el conocimiento, o el "know how", que ya saben cómo funciona. Uno quiere saber más, hay personas afuera, "stakeholders", inversores de dinero, ente que también participa, cond eseos de saber en qué bus se subieron, a dónde llegarán.

Visualizar también aunque sea en una situación pequeña, de ocas personas, también es un ejercicio complementario, lúdico, de ilustrar, mostrar cosas, no ser rígido, tener otro punto de vista, de un negocio, de unas metas. 

domingo, 6 de noviembre de 2011

Patrones de visualización de series de tiempo

La visualización de datos es una herramienta que ayuda a razonar, comunicar mensajes, entender ideas, así como a descubrir nuevos significados con base en la presentación grafica de conjuntos de datos. En este sentido existen múltiples alternativas para lograr alguno de los anteriores objetivos mediante la visualización, siendo algunas más efectivas que otras. En este sentido es de gran ayuda el empleo de patrones de visualización.

Los patrones de visualización se pueden concebir como lenguajes visuales, que involucran forma, tamaño, color y comportamiento. En el núcleo de estos lenguajes está definida una semántica para la expresión de relaciones. Entonces podemos decir que los patrones de visualización no son más (ni menos) que soluciones probadas que ayudan a expresar ciertos conjuntos de relaciones sobre algún conjunto de datos en forma efectiva.

Un ejemplo de estos, son los patrones de visualización de series de tiempo, como por ejemplo los diagramas de barras, de puntos o de líneas sobre planos, que se enfocan principalmente en describir relaciones de cambio en el tiempo sobre uno o más atributos en los datos.

Aunque los patrones de visualización de series de tiempo son una poderosa herramienta para expresar y resaltar estas relaciones y ayudarnos a identificar o comunicar tendencias y correlaciones en el tiempo, su uso inadecuado puede llevarnos a conclusiones o ideas erróneas o incompletas. Por tal motivo, es de vital importancia siempre tener claridad del propósito de la visualización – comunicar una idea, ayudar a descubrir o identificar tendencias o correlaciones o sustentar alguna hipótesis - y el público objetivo de la presentación, como base para tomar la decisión de que patrón utilizar y como emplearlo.

En el caso de series de tiempo, en los aspectos de la forma y tamaño (o escala), es de vital importancia mostrar los datos en el contexto adecuado (tiempo inicial y final), cuidar de la escala utilizada en la variable dependiente, así como presentar y resaltar el patrón o tendencia o tendencia del comportamiento sobre los datos crudos y la forma de relacionar los datos en el tiempo (interpolación), en especial cuando hay intervalos con información incompleta o con cambios instantáneos, para evitar malas interpretaciones. En el aspecto del color por su parte, se debe buscar concentrar la atención en las formas que expresan el mensaje de importancia, sobre los demás elementos de la visualización. Las anteriores corresponden en si a un patrón general para la composición de este tipo de visualización, que correctamente usado provee de mucho valor a la hora de comunicar.

lunes, 31 de octubre de 2011

Resumen Capítulos 6 y 7

Capítulo 6

Patrones de Inventario 

Enterprise Inventory
La prestación de servicios de forma independiente a través de diferentes equipos de proyecto a través de una empresa establece un riesgo constante de la producción de servicio inconsistente e implementaciones arquitectura, poniendo en peligro las oportunidades de recomposición. Servicios para múltiples soluciones pueden ser diseñadas para la entrega dentro de una arquitectura estandarizada, el inventario de toda la empresa en la que se pueden libremente y en repetidas ocasiones recompuesto. En el impacto se debe tener Análisis inicial significativo es necesario para definir un modelo de inventario de la empresa y el resultado numerosos impactos de la organización de los requisitos de gobierno posteriores.
Domain Inventory
Establecimiento de un inventario de la empresa de servicios solo puede ser difícil de manejar para algunas empresas, y los intentos de hacerlo puede poner en peligro el éxito de la adopción de SOA como un todo. Los servicios se pueden agrupar en los inventarios manejable, el servicio de dominio específico, cada una de ellas puede ser independiente estandarizada, que se rige, y de propiedad. Normalización disparidad entre inventarios de dominio de servicio impone requisitos de transformación y reduce el beneficio general potencial de la adopción de SOA.
Service Normalization
Cuando la prestación de servicios como parte de un inventario de servicios, hay un riesgo constante de que los servicios se creará con la superposición de los límites funcionales, lo que hace difícil para que extendida reutilización. El inventario de servicio debe ser diseñado con un énfasis en la alineación de servicio de frontera. Asegurar que los límites del servicio son y permanecen bien alineadas introduce adicional por adelantado el análisis y el esfuerzo continuo de gobierno.
Logic Centralization
Si los servicios de agnóstico no son siempre reutilizados, funcionalidad redundante se pueden entregar en otros servicios, dando lugar a problemas relacionados con la desnormalización de inventario y la propiedad de servicios y la gobernabilidad. Acceso a la funcionalidad reutilizable se limita a los servicios oficiales agnóstico. Cuestiones de organización que recuerda de los proyectos de reutilización pasado puede aumentar obstáculos a la aplicación de este patrón.
Service Layers
Servicios de manera arbitraria la definición de entrega y se rige por diferentes equipos de proyecto pueden conducir el diseño de la incoherencia y la redundancia funcional involuntaria a través de un inventario de servicios. El inventario se estructura en dos o más capas de servicios lógicos, cada uno de los cuales es responsable de la abstracción lógica basada en un tipo funcional común. Los costes comunes y los impactos asociados con los estándares de diseño y por adelantado el análisis de necesidad de ser aceptado.
Canonical Protocol
Servicios de apoyo a la comunicación diferentes tecnologías de interoperabilidad compromiso, limitar la cantidad de consumidores potenciales, e introducir la necesidad de superar las medidas de protocolo indeseables. La arquitectura establece una única tecnología de las comunicaciones como medio único o principal por el cual los servicios pueden interactuar. Una arquitectura de inventario en el que los protocolos de comunicación estandarizados está sujeta a ninguna limitaciones impuestas por el tecnología de las comunicaciones.
Canonical Schema
Servicios con los modelos dispares de datos similares imponer requisitos de transformación que incrementar el esfuerzo de desarrollo, la complejidad del diseño, y la sobrecarga de rendimiento en tiempo de ejecución. Los modelos de datos para los conjuntos de datos comunes son estandarizados a través de contratos de servicio dentro de un límite de inventario. El mantenimiento de la estandarización de los esquemas de contrato pueda introducir esfuerzos en materia de gobernabilidad y los desafíos culturales.
Capítulo 7
Utility Abstraction
Cuando no comercial centrada en la lógica de procesamiento se empaqueta junto con el negocio específico de la lógica, los resultados de la aplicación redundante de funciones de utilidad común a través de los diferentes servicios. Una capa de servicios dedicada a la transformación de servicios públicos se ha establecido, la prestación de servicios reutilizables de utilidad para el uso de otros servicios en el inventario. Cuando la lógica de servicios públicos se distribuye a través de múltiples servicios que pueden aumentar el tamaño, la complejidad y las demandas de rendimiento de las composiciones.
Entity Abstraction
Agrupación tanto en el proceso independiente del proceso y la lógica específica de la empresa en el mismo servicio con el tiempo da lugar a la creación de lógica de negocio independiente y redundante a través de múltiples servicios. Una empresa independiente del nivel de servicio puede ser establecida, dedicada a los servicios que basan su contexto funcional de las entidades de negocio existentes. El núcleo, centrada en el negocio naturaleza de los servicios introducidos por este modelorequiere de modelado y atención diseño y sus requisitos de gobierno puede imponer cambios radicales en la organización.
Process Abstraction
Agrupación tarea centrada en la lógica con la lógica de trabajo independiente del gobierno dificulta el de la lógica específica de la tarea y la reutilización de la lógica agnóstica. Una empresa dedicada padre proceso de nivel de servicio se estableció para apoyar la independencia de gestión y el posicionamiento de los servicios de trabajo como posibles recursos de la empresa. Además de los modelos y las consideraciones de diseño asociadas a la creación de servicios de trabajo, haciendo abstracción de negocios matriz lógica de proceso establece una dependencia inherente a la realización de que la lógica a través de la composición de otros servicios.

lunes, 24 de octubre de 2011

Proceso MecaPlus: Descubrimiento de servicios

A continuación presentamos los entregables de Ecosistema y Portafolio de Servicios para el nuevo proceso MecaPlus.

Para este trabajo se aplicó un enfoque vertical, aplicando el patrón de descubrimiento Top-Down encaminado a Atributos. Esto es porque para expresar nuevo proceso, requerimos realizar seguimiento de los negocios, a nivel de características de los negocios, como entidades, y también capacidades de estos negocios. Los entregables también se basan en ejercicios de creación de un modelo de atribución y un árbol de decisión.

También se practicó el patrón Top-Down encaminado a Procesos de Negocio, para verificar en manejo de repuestos, cómo se realiza este proceso ya existente.

Lista de capacidades del proceso


Portafolio de Servicios


Ecosistema de Servicios

sábado, 22 de octubre de 2011

¿Qué patrón aplicamos hoy?

Downward, Top-Down, procesos, atributos, interfaces, productos de legado, etc. Estamos ahí, en una mesa grande, con colegas, escribiendo notas, devorando documentos, referencias, de empresas, departamentos, trabajos de investigación, casos de éxito,en busca de una idea, no de cualquiera, sino de la más, la más factible, la más económica, la que de  más y mejores resultados en poco tiempo, una idea para encontrar capacidades, o cosas que pueda hacer un producto, un sistema, y además que todos en el mundo puedan usar por la Web, tomarla de ahí, cuando la necesiten, ya sea, transferir dinero de Bogotá a Singapur, o una boleta para la gira de U2, o conseguir la maquinaria para ser fabricante de un coche de marca europeo.

El trabajo de Michael Bell, de SOA Modeling Patterns, no es otro trabajo académico, en la oscuridad de una universidad clásica, para estudiosos. No en vano, está en Amazon, tiendas importantes, referenciado en muchas investigaciones importantes, como un gran estudio para modelar, hacer de procesos, los productos deseados por empresas, empresarios, para satisfacer sus necesidades. Me encontré viendo referencias, en busca de complementos, sumarios de las lecturas. El trabajo de Bell es extenso, las lecturas son extensas, y aunque  so una gran guía, se necesita tiempo, y algo más, habilidades, competencias, para diseñar y construir productos de calidad, desde el arte de encontrar servicios, capacidad, lo que puede disponer un sistema para el resto del mundo.

En mi caso, no he trabajado con Unisys, o Amazon, menos con Oracle, EC2, y reconozco que no sé de Web Services más que escribir uno y arrancarlo en un servidor casero. Por eso, tal vez, puedo hacerme a la idea, o ideas generales, del propósito de cada enfoque, modelo, o patrón dado el caso. Puedo hacer las asociaciones siguientes: Enfoque vertical para ir al corazón y los detalles de los procesos para encontrar servicios. Modelo Top-Down para a partir del nivel macro, las imperaciones y los proceso de negocio, encontrar los servicios simples. Patrón Encaminado a Procesos de Negocio, para investigar y conocer íntimamente los proceso que ya existen, Patrón Encaminado a Atributos para hallar las características de los procesos en general, Front-2-Back para procesos nuevos de monitoreo y manejo de información en tiempo real, Back-2-Front para procesos de informes gerenciales y analítica visual, Patrón Bottom-Up para servicios desde sistemas de legado, etc.; y desde ahí, ser curioso, saber cómo más aplicar los patrones, aplicarlos a VehiAlpes, y a los negocios de ejemplo.

Pues, tal vez sea una idea general, fácil, con más experiencia se puede advertir más aplicaciones de los patrones, cómo aplicarlos hábilmente, etc. Pero sí hay una idea, una sensación, que vale la pena adquirir, con o sin experiencia, y es cómo aplica, a diseñar soluciones, más allá de la parte técnica, o pragmática, rgeresando alas primeras sesiones del curso de Patrones, y es la de conseguir soluciones, acercándose a la estética, la elegancia, productos, que más que servir, funcionar, trasmitan sensaciones de gusto, comfort, placer, al hacer uso de ellas. Esto lo consigue SOA, a través de su filosofía, sus principios de bajo acoplamiento, reutilización de servicios, y sus patrones de descubrimiento de servicios; de forma que el diseñar, descubrir servicios, sea más que estar en la mesa, devorando documentos, sea un momento de crear, hacerlo con inspiración, abstraerse en la forma, las cualidades. Por eso también, más que saber los enfoques, o patrones para encontrar servicios, se necesita también cierto toque, cierto desenvolvimiento para decir, esto que ocurre en el proceso, lo puedo hacer una capacidad de este servicio.

En este trabajo vale la pena también echar un ojo a la introducción del libro, el sentido de éste, más allá de la descripción formal de los patrones. También, como complemento, practicar Web Services, verlos, como ir a la excursión, o a la fábrica, y ser curioso de cómo encontrar eso que vemos funcionar en el computador. Para el caso de VehiAlpes, en mi caso, aplicaría hoy Top-Down encaminado a atributos, y algo de Bottom-Up, para nuestro enfoque de poderes

lunes, 17 de octubre de 2011

Diseño de patrones de integración

Tecnología a utilizar
La herramienta de Mule nos parecio el mejor softwate para el manejo de la mensajería, ya que es un excelente gestor de objetos escalable y distribuible que puede manejar interacciones con servicios y aplicaciones que usan distintas tecnologías de transporte y mensajes.
Además que Mule es un framework muy liviano y fácilmente de embeber en aplicaciones Java, y se puede integrar con frameworks como spring, hivemind y plexus y soporta muchos componentes de transporte y servicio como JMS, SOAP, JBI, BPEL, EJB, AS/400, HTTP, JDBC, TCP, UDP, SMTP, FILE, FTP y más. Adicionalmente una extensión beta de Mule es Mule estudio, la cual facilita aún más la implementación grafica de la aplicación con respecto a la mensajería, pero fundamentalmente Mule es una herramienta que posee un gran soporte ya que es la herramienta más utilizada de integración en el mercado, lo que permite una mejor retroalimentación de la comunidad a la hora de solucionar problemas.

Solicitud servicio grúas
Patrones SOA implantados

Comunicación Asincrónica
“Un servicio puede requerir que los consumidores se comunican con él de forma asíncrona y proporcionar una dirección de devolución de llamada para que el servicio pueda enviar mensajes de respuesta.”
Este patrón se utiliza al solicitar el servicio de grúa, a un conjuntos de aplicaciones diferentes de grúas que atienden solicitudes ya sea de manera asincrónica, ya que necesitan procesar primero  las solicitudes en Batch y luego si dar una respuesta.


Transformación del formato de la información.
“Intermediario formato de datos lógica de transformación debe ser introducido con el fin de convertir dinámicamente un formato de datos a otro.”
Para poder comunicarse con las aplicaciones de las grúas se debe hacer una transformación de la información y/o de los datos para que dependiendo de la aplicación de la grúas, esta pueda procesar la información de manera adecuada






Diseño completo de solicitud 



lunes, 10 de octubre de 2011

Patrón BPM Reclamación

Ilustración


Borrador


Motivación

Cubrir de manera formal y única le proceso de reclamos y devolución de productos o servicios.


Problema

El proceso de reclamos y devolución se aplica en las compañías para cada caso, de manera particular, sujeto a reglas, directrices e intereses por parte de la compañía que maneja este proceso. Por tanto, al realizar modelado de procesos, nos encontramos con que este proceso debe modelarse de manera particular, rehaciendo nuevamente subprocesos, tareas y elemento gráficos que pueden ser innecesarios.


Solución

Se propone para este proceso un patrón de modelado que cubre los elementos "estándar" en el proceso, bajo la perspectiva también de un proceso formal, ordenado, aplicable a cualquier entorno. En éste, entran en escena 4 actores que son: Cliente, Vendedor, Proveedor y Contratista. Y se manejan los casos de reparación y devolución del producto adquirido que desea ser reclamado por garantía.

Un ESB, muchos buses.

Basado en el libro, donde se dice que el mejor esquema de integración es aquel basado en mensajería, o al menos es el que mas problemas puede resolver, puedo decir desde mi experiencia personal que es completamente cierto.
Es cierto que cada problema es diferente y en cada situación, las necesidades de integración pueden atacarse de maneras distintas dependiento de la naturaleza del problema, con un esquema basado en mensajería se resuelven la mayoría de los retos que se plantean en una necesidad de integración.
Hoy en día las herramientas para proveer este tiopo de soluciones. Por necesidades laborales, llevo algún tiempo trabajando con la suite de herramientas de IBM y quiero compartir mi experiencia sobre ello.
IBM cuenta principalmente con 3 productos que actuan como ESB.
  • WebSphere ESB el cual es totalmente basado en tecnología Java y esta soportodado (dependiente) en el servidor de aplicacion WAS. Esta es quizas la mejor opción cuando se trata de integrar aplicaciones escritas en el mismo lenguaje(java) y que su esquema de su formato de mensajería este basado en estandares SOAP, WS, XML, y tecnologías relacionadas.

  • WebSphere Message Broker Es el mas apropiado cuando se trata de integrar aplicaciones en tecnologias heterogéneas. Tiene muchas facilidades para convertir mensajes de un formato a otro y convertir tambien protocolos heterogeneos. Es el apropiado para implementar patrones de integración complejos.

  • WebSphere DataPower Es el mas poderoso en cuanto a desempeño se trata. WebSphere DP es un appliance (Hardware) donde se pueden definir transformaciones de XML y tambien conversión de protocolos de comunicación. Dado su alto poder de procesamiento es el preferido cuando se requiere minimizar la latencia adicionando una capa de integración. En general es recomendable implementar patrones simples en esta tecnología.



  • Por fortuna, he tenido la oportunidad de trabajar con las 3 herramientas y es importante saber escoger cual usar en cada momento.
    Espero sea de ayuda la información aca expuesta.

    BPMN 2.0 = Holy Grail?

    El libro BPMN 2.0 de Thomas Allweyer, provee de una concienzuda exploración al estándar BPMN 2.0, su semántica y aplicación en el diseño de procesos de negocio. Luego de la lectura de sus capítulos me quedo una impresión general del poder expresivo de la notación y su semántica. Así mismo, los comentarios de diseño del autor, son en mi opinión enriquecedores, particularmente en lo que respecta a los problemas a los que uno se enfrentara un diseñador durante su uso. Luego de la lectura me inquietaron algunos puntos respecto a BPMN 2.0.

    En primera medida, creo que la notación ofrece un lenguaje visual altamente rico, pero a su vez complejo. En este sentido me cuestiono si al modelar un proceso típico, es empleado todo el abanico de elementos que este ofrece. Por otro lado, un mayor número de elementos de la notación puede finalmente entrar en conflicto con una de sus filosofías, el ser lingua franca para la representación de modelos de negocio. Creo que BPMN 2.0 puede ser de difícil acceso (y comprensión) para el público en general -si uno peca por ser muy detallista en sus modelos, lo cual puede ser muy probable. Lo anterior representa una debilidad en mi opinión, pues toda la responsabilidad en este sentido recae sobre el modelador, pues BPMN 2.0 aporta poco en términos de restricciones sobre el modelaje los procesos de negocio.

    Ahora con respecto a los modelos ejecutables, la semántica de BPMN 2.0 y su potencial expresivo, sin duda es muy alto, pero considero que las notaciones simplificadas como los eventos de inicio y final, así como los gateways implícitos, hacen más complejo entender el detalle del comportamiento de un proceso, pensado para ejecución. En este sentido, entiendo el ánimo de BPMN 2.0 de ofrecer expresiones que son visualmente más simples (y accesibles para quienes es presentado el proceso), pero en mi opinión pueden terminar confundiendo a quien tiene interés en el detalle del proceso y su consistencia.

    domingo, 9 de octubre de 2011

    Patrones de Integración

    Integración en Aplicaciones (Bernarnd y Laurent)



    El libro ilustra y es escrito de manera clara asumiendo un conocimiento inicial básico. Es un libro muy completo, que va más allá de patrones de integración presentando al lector una amplia gama de temas y de comparaciones entre los diferentes estilos, también se proporciona conocimiento y propone  formas de uso de la mensajería para solucionar diferentes problemas de manera efectiva, y proporciona una manera clara por medio de pasos para poder tener éxito en la implantación de las técnicas de integración. Me gusta especialmente la forma en que Bernard y Laurent diseña cada modelo usando el lenguaje y los estilos visuales para delimitar las secciones de forma natural del patrón, esto aumenta significativamente la legibilidad y el entendimiento de la idea de integración.
    El libro es muy independiente de la tecnología, ya que se enfoca más hacia la generalización de la idea, ilustrando las ideas de los patrones y maneras de integración sin tener que ligarse con una tecnología o herramienta, lo que permite una generalización del conocimiento para poder aplicarlo a cualquier tecnología si ésta lo permite.
    El problema por menor que le vi al libro es que eran muy largos sus capítulos,  lo que hacía que me perdiera el hilo, pero en general el lenguaje utilizado era bastante entendible, lo que si puede mejorase es  en ser más concreto y resaltar las características más importantes, ya que se pueden quedar en medio de las frase históricas, preguntas, etc.

    lunes, 12 de septiembre de 2011

    Propuesta de innovación VehiAlpes


    Para esta iteración, la propuesta está encaminada hacia las dos fuerzas de negocio: Venta (v) y Postventa (p). Para cada una  se propone una opción innovadora, con base en una perspectiva de poder, en la cual VehiAlpes asume el control de la información de clientes, ofreciendo beneficios a sus socios.

    Para venta se propone cotización y venta a través de móvil, y para postventa, un portal corporativo CRM ERP, inspirado en el modelo del portal de Audi Colombia, para la propuesta de mecánica prepagada. Los esfuerzos para la implementación y entrega de la solución se encmainarán principalmente en esta alternativa.



    En la entrada después de esta, se modelan algunos procesos usando BPMN.

    Procesos Vehialpes

    Registro de clientes (Pagina web)

    Consulta de clientes

    Garantía de clientes

    lunes, 5 de septiembre de 2011

    Comentarios en la implementación de proyectos BPM.

    El BPM como disciplina de administración ofrece un medio para alcanzar los objetivos estratégicos bajo una visión centrada en los procesos. Al igual que otras disciplinas como la reingeniería de procesos (BPR), la administración de la calidad total (TQM) y Six-Sigma, que tienen un común el mismo propósito, BPM no es el santo grial, pues al igual que las anteriores su implementación en las organizaciones es un problema difícil.

    En principio BPM requiere de procesos funcionales, que puedan ser optimizados. En este sentido BPM potencia la eficiencia solo si ya hay eficacia. Lo anterior representa un aspecto primario a la hora de evaluar la implementación de un proyecto BPM.

    Cuando se tiene alguna certeza de la eficacia de los procesos, el siguiente aspecto se deriva de la pregunta ¿Por dónde empezar? Una causa frecuente de fracasos en las iniciativas BPM, se deriva de no contar con claridad en este punto. Es común sub-dimensionar o sobre-dimensionar el alcance de los proyectos BPM, lo que deriva a percibir un valor no correlacionado con el esfuerzo invertido y el incumplimiento de los objetivos. En este sentido establecer los objetivos de forma clara y realizable dado un presupuesto de recursos es de vital importancia.

    Otro aspecto clave gira alrededor de la gente. La administración del cambio es una parte integral del BPM. La razón está en que son las personas las que finalmente implementan e interactúan con los procesos. Muchos problemas a la hora de aplicar BPM sobre los procesos deriva de la resistencia de la gente al cambio; no importa que tan bien diseñada y alineada es la estrategia del proyecto BPM, si la gente se opone el proyecto finalizará bajo tierra.

    Jeston y Nelis, en observación de la dificultad y complejidad de BPM, proponen un marco (framework) metodológico para la adopción del BPM como disciplina organizacional. Este marco consta de diez fases: Estrategia Organizacional, Arquitectura de procesos, despegue, entendimiento, innovación, personas, desarrollo, implementación, realización de valor y desempeño sostenible. Las anteriores dan en general un tratamiento iterativo a los proyectos BPM, buscando su consolidación en la organización hasta hacer del proceso parte de la rutina organizacional y enfatizando en el mejoramiento continúo como capacidad objetivo.

    En mi opinión, el marco propuesto por Jeston y Nelis, integra la administración del cambio como una parte integral del BPM, pero debería abordarse con mayor profundidad, pues no ofrece una metodología más detallada para construir estrategias en este sentido. Como bien lo indican los autores, la administración del cambio es un proceso transversal a las fases de marco y cuya misión es permitir el avance, en particular en la fase de implementación, en la cual el proceso representa el mayor impacto. Así mismo puntualizan en la importancia de involucrar a los stakeholders que son impactados por el proyecto.

    El involucrar a los stakeholders y empoderar a las personas en la organización son estrategias generales claves en la administración del cambio. Aunque es fácil decir que esto es lo que hay que hacer, en mi experiencia lograr estos puntos es increíblemente difícil y creo que ahí esta una de las debilidades del marco, pues no explica cómo abordar estos problemas. Creo que en este sentido es imperativo entender las posiciones de los stakeholders y las personas en la organización y estimar que implica para estos la realización del proyecto.

    El cambio implica desbalances entre los aportes y las retribuciones que espera cada stakeholder. Ejemplos en los cuales las personas en la organización no sentirán motivación para ayudar al cambio son la inserción de nuevas responsabilidades, el incrementar su exposición al riesgo o simplemente quedar en una posición que a su criterio es desfavorable frente a otros en su mismo nivel. Creo que en un proyecto BPM se debe integrar este tipo de análisis e incluir la negociación como una fase adicional anterior al despegue del proyecto. Lo anterior esta dado por la necesidad de definir y asegurar compensaciones adecuadas y consensuadas frente al impacto derivado del cambio y así lograr la aceptación y participación proactiva (ponerse la camiseta) de los involucrados, mitigando enormemente los riesgos.

    BPMN Method & Style


    Para aprender BPMN en detalle pueden existir muchas formas distintas de lograrlo. Pagar cursos, tomar cursos en la web, comprar libros, buscar manuales, etc. Lo valioso del aporte que se hace en esta lectura es como tomar en cuenta la práctica de alguien quien ya ha sufrido con la implementación y como solucionar y dar un mejor enfoque a esos problemas con los que se puede uno enfrentar día a día.

    Existe un problema grande que se refleja en la perdida de semántica entre un proceso en BPMN y su implementación en un lenguaje de orquestación de procesos como BPEL. Se supone que esto es uno de los problemas que se pretende resolver en la versión 2.0 de la especificación. Personalmente no he tenido oportunidad de verlo en acción pero al menos la promesa de valor es bastante interesante. Existían problemas en la traducción entre un proceso escrito en BPMN y su contraparte en BPEL pero era aún mas fuerte el problema de hacer la conversión a la inversa, en otras palabras, era casi imposible.

    En BPMN 2.0 es posible ejecutar el proceso sin necesidad de hacer una conversión a BPEL, esto lo he visto personalmente a modo de demo en IBM BPM 7.5 que recoge lo mejor del mundo de WebSphere Process Server y WebSphere Lombardi.

    BPM para todos

    -Buenas, deseo aplicar al cargo de "Business Developer" -¿Tiene 5 años de experiencia en "foundation" para TI en arquitecturas de procesos? -No, no tengo. -¿Qué experiencia tiene? -5 años de Java, patrones de diseño, Test Driven, Web Services. -Gracias, después lo llamamos.

     Igual, todos somos administradores, todos somos empresarios, manejamos una empresa, aunque sea un proyecto de vida, unas aspiraciones, cosas que queremos conseguir, es empresa, organización, objetivos, procesos. Pero no todos somos administradores por profesión, o por vocación, no todos estudiamos administración, o hemos hecho los cursos de economía, gestión, etc, o no tenemos la visión "visionaria", a futuro, de negocio, de oportunidades, o no nos expresamos en el "jargon" de administración, en términos de organización, objetivos, procesos.

     ¿Cuánto hay que adentrarse en el mudo de la administración? ¿Saber BPM puede ayudar? ¿También saber BPMN? Desde el punto de vista de estudio, y personal, hasta el maestro en ciencias de computación, e ingeniería de información en la organización, con experiencia en negocio, empresa, más que saber BPM, requiere un recorrido en administración, en hacer negocios, hacer empresa.

     Aunque BPM, su notación, su aplicación a los negocios, implique gente del mundo de la información, todavía es muy del dominio del mundo de los negocios. La esencia, el sentido de BPM, es muy de organización, está dedicado a la organización, a su estructura, como entidad que tiene objetivos, procesos. BPM es denso, redundante, aplicado incorrectamente, por no ser comprendido juiciosamente, por adquirir la cultura "de la calle", de ser algo de tecnología, y por darse a conocer "para todos", sin bases de administración.

     En este viaje por BPM, está muy bien comenzar por desmitificarlo, como algo de tecnología. BPM no necesariamente es algo que usa tecnología. Puede aplicarse BPM sin tecnología, pero no se puede, sin sintonizar con administración, o negocios. Saber BPM puede ayudar, si se complementa con saber de administración, tener bases, expresarla. Es positivo, fabuloso, conocer BPM, expresar procesos, con un saber de negocios claro, saber a qué se refiere un "foundation", un "proceso en una organización", así como en un juego, ubicando cada cosa en su lugar, sin que todo acerca de organización, procesos, se vuelva borroso, redundante, o avasallante.

     En BPM el sentido es mejorar, hacerlo con sentido común. Pero sin disposición, o tiempo de complementarlo con saberes de administración, todavía no es comprendido correctamente, y un método muy costoso, y peligroso. Ya pasó hace mucho la era de los negocios orientados al producto, estamos en el presente de la competencia agresiva, y hay necesidades de negocios sostenibles. BPM es para administradores, y para todos, si se comprende juiciosamente.

    lunes, 29 de agosto de 2011

    Acercamiento a una propuesta de negocio para VehiAlpes




    Aquí, después de retomar desde las bases el caso de VehiAlpes, y poner en la mesa y discutir varias alternativas, con base en las lecturas, y el enfoque de poder de las partes. Se escogió una propuesta que consiste en una plataforma corporativa, que aplica tanto para clientes, como para concesionarios.

    Nuestra solución se basa en abordar un problema importante, que también es un reto para VehiAlpes, que es tener un conocimiento suficiente, oportuno, de sus clientes de mercado -Venta y postventa, y así redefinir su estrategia de ventas para aumentar el volumen de sus ventas, y hacer frente a las nuevas competencias.

    Se ha adqirido como inspiración el caso de la compañía Audi Colombia, la cual, a través de su website, dispone de una gran plataforma para su clientes, con un gran portafolio de servicios para ellos, a través del cual acompaña a sus clientes, está con ellos, y a su vez, puede disponer de la información de ellos cuando necesite, al mismo tiempo que también la de sus concesionarios, como clientes corporativos.

    domingo, 28 de agosto de 2011

    Estrategia y Procesos de negocios


    La estrategia de un negocio Porter la define como: "a combination of the ends (goals) for which the firm is striving and the means (policies) by which it is seeking to get there.", este autor se puede considerar como el principal autor en estrategia, y el propone varios métodos que permiten analizar a las empresas o negocios desde una manera interna y externa de la empresa para luego así poder a construir una estrategia, pero no es solo se llega a una estrategia, sino se llega a una estrategia diferenciadora, en donde se está creando valor en la medida de que se está diferenciando de la competencia. El método principal que propone Porter es el de las 5 fuerzas, un enfoque muy popular para la planificación de la estrategia corporativa ha sido el propuesto en 1980 por Michael E. Porter en su libro Competitive Strategy: Techniques for Analyzing Industries and Competitors. El modelo de las Cinco Fuerzas de Porter propone un modelo de reflexión estratégica sistemática para determinar la rentabilidad de un sector, normalmente con el fin de evaluar el valor y la proyección futura de empresas o unidades de negocio que operan en dicho sector.




    Este modelo propuesto por Porter está muy relacionado con el modelo estratégico propuesto por Alexander Oxterwalder, en donde describe cuatro fueras: la industria, factores macroeconómicos, el mercado y tendencias claves. Y este modelo estratégico se incorpora en el modelo Canvas, lo que permite un mejor entendimiento de los factores directos que se ven afectados en el negocio.
    A su vez Alexander Oxterwalder hace una aproximación modifica del modelo clásico de DOFA adicionándole una métrica de precisión del impacto que tiene la variable en el análisis interno externo. El método DOFA es una herramienta generalmente utilizada como método de diagnóstico empresarial en el ámbito de la planeación estratégica, es increíble que una herramienta tan conocida, pocos grupos de trabajo realmente conocen a cabalidad su aplicación, es usual que se avance hasta la primera parte del proceso DOFA, que corresponde a la lluvia de ideas que culmina en la construcción de la matriz básica de diagnóstico. Sin embargo, el método DOFA es mucho más que esa parte del ejercicio. Podríamos asegurar que el proceso, si es que se lleva adecuadamente hasta la construcción básica de la matriz DOFA, solo corresponde al 10% del desarrollo del método. No cabe duda de que este modelo, entre muchos otros, es bueno y muy difundido a nivel mundial, pero el desconocimiento sobre el mismo, ha hecho que la informalidad le merme poder e importancia a la implementación de una herramienta tan poderosa que no solo encuentra aplicación en la administración moderna sino también en el área técnica y operativa de las industrias.

    lunes, 22 de agosto de 2011

    ¿Funcionará?

    Ahora, revisando el canvas para el modelo de VehiAlpes, complementando con el enfoque de nosotros, y las lecturas, cuestioné de forma inocente, hasta qué punto, para el caso de la lectura de Ross, su tesis dará la solución esperada a las compañías en sus estrategias.

    En mi pregrado, coincidí con el cambio de paradigma en el mundo empresarial, de pasar de enfoque al producto, a enfoque al cliente. Leí sobre Reingeniería, Círculos de Calidad, matriz DOFA, etc., y en ese tiempo estaba seguro del éxito del cambio, la utopía, empresas más flexibles, clientes más satisfechos. Ahora leyendo el libro de Ross, siento también esa confianza, y es un libro muy bien sustentado, en estudios de empresas, casos de éxito, recopilación de información, y estudios al detalle de cómo ahora funciona tener éxito en los negocios.

    Bueno, justamente, en el libro de Ross, se da a cita a inconvenientes, los nuevos inconvenientes, los obstáculos que afrontan las empresas de ahora, que en pregrado no se me habían ocurrido. Inconsistencias en la información, aislamiento de unidades de negocio, cada uno por su cuenta, cosas que se viven también como cliente de empresas, como suscriptor de televisión, telefonía, clientes, de bancos, o sea, el no estar seguro de un buen servicio, estar pensando en hacer reclamos, y saber que será un esfuerzo en vano, porque la tecnología, los servicios, no pueden cubrir las necesidades de información consistente, oportuna, y lo que yo creí, el cambio, al final no ha sido para todos, y no es la solución directa a los problemas.

    Ahora, en este tiempo también, hay factores nuevos, la competencia es más agresiva entre empresas, es desleal también, hay una prisa desmedida por acaparar todos los mercados, quedarse con todo, con las implicaciones de implementar soluciones urgentes, expuestos a todos los riesgos de hacerlo, que sean obsoletas las ideas de proyectos a largo plazo, etc, y para este tiempo, se necesita algo más que diseñar y construir una estrategia de arquitectura, ubicar una compañía en un plano de estandarización e integración, hacer diagramas de procesos, unidades, datos, etc. ¿Funcionará? para mi, para que funcione, es bueno también que se dé un cambio, importante, también en hacer negocios.

    domingo, 21 de agosto de 2011

    Algo de critica cons(disruptiva) sobre las lecturas.

    Luego de amasar un poco la cosa, quiero compartir algunas palabras e ideas respecto a las lecturas. En mi opinión personal, las lecturas son efectivas en presentar la importancia del modelar y poner en el papel la abstracción del negocio, como ejercicio clave y necesario – mas para nada suficiente - para entender bien el negocio, que bien se tiene o que se desea crear, y con esto partir a detallar aspectos más específicos y detalles de su arquitectura y organización. Sin embargo creo que las lecturas omiten-eluden de forma sistemática dos aspectos claves en la discusión y analisis, que en mi opinión son de alto nivel y sus efectos impactan el resultado, particularmente en su viabilidad de implementación, continuidad y sostenibilidad. Aclaro que mi punto es la falta de considerar estos dos aspectos a la hora de evaluar y decidir el diseño del modelo de negocio y su arquitectura operativa. Los dos aspectos a los que voy a hacer mención son el riesgo y el poder.

    En el caso del riesgo, uno se pregunta como una determinada arquitectura se ajusta mejor (mitiga) o peor (incrementa) frente a la incertidumbre del sistema donde la organización va a operar (el riesgo exogeno) o el derivado de vulnerabilidades de su misma estructura (el endógeno). Creo que pueden coincidir con migo en que esto no es algo que sea tratado debidamente. Por ejemplo una modelo multi-cara con una arquitectura unificada, es altamente vulnerable en dos aspectos: Existe un único punto de falla, la plataforma, que conecta a los grupos interdependientes. Si esta falla, bien por deficiente diseño de sus interfaces con los grupos (ej: no es lo suficientemente accequible, pues requiere clientes costosos o tiene poca usabilidad) o por no soportar la demanda (el crecimiento es desmesurado y no da abasto). Por otro lado la estabilidad de un sistema multi-cara es un tema de cuidado. Lo es debido al equilibrio que se debe preservar entre los tamaños de los grupos para que el sistema (el negocio) sea sostenible. En este sentido, ¿un modelo unificado provee la suficiente agilidad en la toma de decisiones y su implementación, para responder al cambio del entorno (crisis económica, entrada de un competidor)?

    Por su parte, el poder y su manejo (gobierno), requiere ser analizado con mucho cuidado. La gobernabilidad esta íntimamente relacionada con el modelo de negocio y su arquitectura, ya que define como es distribuido el poder y como es administrado. Recordar que son las personas y sus decisiones las que finalmente hacen que las organizaciones funcionen, entonces el problema de establecer el status-quo equilibrado es crítico. En este sentido, una arquitectura diversificada, asigna el poder de forma muy importante a las unidades de negocio, hasta el límite en que la corporación (su cúpula), puede quedar en una posición desfavorable a la hora de negociar el cambio. Estas crisis de gobernabilidad pueden estancar por completo el cambio (por resistencia al mismo), lo cual es irónico, ya que un fuerte del patrón diversificado está en su flexibilidad para el cambio. Esto también debe entrar en consideración al evaluar que se hace en casa y que no (Ej: Outsourcing), pues se corre el riesgo de ser controlado por otros y perder la autonomía para tomar decisiones.

    Para finalizar quiero hablar del enfoque de nuestro grupo (El dilema del prisionero, es un clásico sistema en teoría de juegos, que exhibe equilibrio-Nash) y su enfoque centrado en el análisis de poder. Nuestro interés es que nuestras soluciones se conviertan disruptores naturales del equilibrio de poderes (del status quo) entre los diversos actores en la organización y fuera de ella. La idea es que la solución como conjunto (no solo algo tecnológico), permita alcanzar al cliente, objetivos estratégicos dados, bajo un marco que provea de herramientas para negociar el poder, dando y recibiendo a cambio. Con esto buscamos ser exitosos en nuestros proyectos, mitigando los riesgos que los conflictos de poder representan, cuando se implementan soluciones de tecnología.

    En el caso de VehiAlpes, me es claro que todos los puntos de la lista de regalos de navidad de las directivas de VehiAlpes, tienen aspectos complejos desde el punto de poder (pues ya se tiene un equilibrio). En este sentido, no considerar lo anterior, solo derivara en grandes dolores de cabeza a futuro o el finalizar con una “solución” tecnológica para enmarcar. Lo anterior es altamente riesgoso (muy probable y de mucho impacto), tanto para VehiAlpes como para nuestro grupo.

    Recomiendo leer este manga: Liar Game, pues trata mucho sobre temas de poder y estrategia (psicología también).

    Modelo Canvas - VehiAlpes


    PDF
    PPTx (para editar)