Social BPM - BPM Social - una pequeña introducción

Es innegable el impacto que han tenido las tecnologías sociales como facebook, twitter en nuestra sociedad. Su aplicación actual ha estado enfocada al desarrollo de redes sociales, medios que han permitido que personas compartan, participen y colaboren sobre diversos contextos sociales, intereses y objetivos comunes. Ejemplo de ellos son las redes familiares, educativas, profesionales, de negocios, entre muchas otras.

Tecnologías Sociales dentro de las organizaciones

Actualmente existe un fuerte debate sobre el uso de las tecnologías sociales en un entorno organizacional y como pueden ser utilizadas para generar valor. Ya existen organizaciones que están incorporando el uso de tecnologías sociales, por ejemplo en procesos de reclutamiento donde estas tecnologías han permitido ubicar prospectos ("talentos") que comparten habilidades y destrezas similares en dominios específicos. Las organizaciones están comenzado a incorporar tecnologías sociales en casa.

BPM y las tecnologías Sociales

BPM es actualmente uno de los principales enfoques organizacionales para impulsar el desarrollo de organizaciones gestionadas por procesos, procesos que generalmente son considerados como una secuencia de actividades gobernadas por ramas, bucles condicionales y reglas. En esta ecuación, las interacciones humanas no han sido consideradas.

Un proyecto BPM organizacional sera mas consistente y efectivo si incluye la información no estructura.  En este sentido; coincido en muchos análisis  que plantean que la información no estructurada como ideas, conversaciones y opiniones, son en esencia el lugar donde se plantean y conciben nuevas estrategias e iniciativas de mejoras organizacionales, por ende deben ser consideradas en una estrategia de mejora continua.

Debemos reconocer, que el flujos de tareas en una organización son en esencia actividades sociales, estando conformadas por patrones de comunicación, participación y colaboración.

BPM Social o Social BPM

BPM Social es un enfoque basado en la creciente adopción de herramientas y técnicas sociales y su utilización en un contexto BPM, incorporando el conocimiento no estructurado generado por el intercambio y colaboracion de profesionales en diversas aristas. BPM social se convertirá según los expertos en una tendencia centrándose en la racionalización de los recursos y eficiencia mediante canales sociales.

Algunas Conclusiones

1. Definitivamente las tecnologías sociales iran sumergiendose dentro de las organizaciones para permitir que sus integrantes participen, colaboren y compartan sobre un enfoque común.
2. Las tecnologias sociales iran emergiendo y cambiando los modelos de gestion organizacionales.
3. El reto de BPM social estará centrado en identificar como extraer la utilidad de conversaciones, opiniones y puntos de vista en torno a procesos.
4. BPM Social es un enfoque que permite considerar las actividades no estructuradas como una base para generar valor hacia la mejora de procesos.

Recomendaciones 

1. Si la organizacion establecer como objetivo el desarrollo de un proyecto BPM, incluya las tecnologías sociales como un componente.
2. Utilice las tecnologias sociales para enriquecer y proporcionar un contexto útil a proyectos BPM.

Utilizar las tecnologías sociales dentro de un contexto organizacional representa en si misma un cambio de paradigma. Este requiere que la organización este convencida del poder y contribución que las tecnologias sociales pueden representar. En ese aspecto, concuerdo que la informacion y el conocimiento gestionado en las organizaciones no es estructurado, por ende es importante que la organización lo reconozca y establezca acciones para considerar el aporte que puede generar.

Bienvenido BPM Social!!!

Como desarrollar un Blueprint de Arquitectura de Software

Desde hace años he participado como arquitecto jefe en diversos proyectos de software desde aplicaciones web sencillas a soluciones de alta demanda, escalabilidad y desempeño, siendo la arquitectura un componente necesario, prioritario y vital.

Cuando se inicia el desarrollo de un proyecto de software es necesario conceptualizar en primera instancia el desarrollo de un "Blueprint de Arquitectura", el cual es un documento que describe y establece un conjunto coherente de criterios y recomendaciones de diseño arquitectónico que deberan ser utilizadas para garantizar el desarrollo de una arquitectura desacoplada, ágil, adaptable y de tecnología neutral para la solucion. Como arquitecto de software, este es un insumo que no puede falta al iniciar un proyecto de software.

Generalmente este documento está conformado por cuatro secciones. En la primera se establecen los requisitos y  atributos de calidad que deberán ser garantizados por la arquitectura de la solución como: simplicidad, flexibilidad, tolerancia ante cambios, reusabilidad, desacoplamiento, entre otros. En la segunda sección se describen las disciplinas y estilos de arquitectura que soportarán la plataforma de software y hardware de la solución, los estándares y normas abiertas que deben ser utilizados para facilitar la interoperabilidad entre los módulos de la solución, la división por capas, topología de servicios y la propuesta general arquitectónica de la solución. En la tercera sección se describen las Soluciones de Software y Hardware Propuestas. Por último, se plantean diversas recomendaciones en referencia al cumplimiento de los atributos de calidad establecidos.

El objetivo general del blueprint de arquitectura es describir el estilo de arquitectura y los marcos tecnológicos que sustentarán la plataforma de servicios de la solución. Entre sus principales objetivos:

• Describir los componentes que integran la arquitectura de software y hardware de la solución.

• Establecer las premisas generales que sustentarán el desarrollo de una arquitectura ágil y eficiente para la solución.

• Describir los criterios de calidad que deben ser garantizados para el desarrollo de una arquitectura de software y hardware ágil y eficiente para la solución.

• Establecer las disciplinas y estilos de arquitectura que soportarán la plataforma de software y hardware de la solución.

• Establecer los estándares y normas abiertas que deben ser utilizados para facilitar la interoperabilidad entre los módulos de la solución.

• Describir las estrategias de interconexión e integración que proveerán la capacidad de intercambio de información entre los componentes de la solución.

• Describir las alternativas tecnológicas propuestas para el desarrollo de la solución.

• Establecer los criterios generales para proporcionar una infraestructura de alta disponibilidad, segura, eficiente y escalable para la solución mediante un conjunto de recomendaciones.

Anexo un mapa de las areas que debemos considerar cuando diseñamos la arquitectura de software de una solucion.

Saludos;

Hacia una Ley de Interoperabilidad

Desde hace años, he estado impulsado la necesidad y urgencia del desarrollo de una plataforma de  servicios de interoperabildiad para el Estado Venezolano. La "PIN" como la llamo es un medio, que permitirá que se establezcan las condiciones necesarias para el desarrollo y adopción de políticas, principios, estándares, normas y procedimientos para el acceso e intercambio electrónico de datos e información entre los órganos,   ciudadanos y entes de un Estado.

Desde mi punto de vista no han existido avances consistentes en Venezuela e incluso en América Latina dado que en la mayoria de países no se ha definido como una necesidad la prestación de servicios de interoperabilidad. En el campo del gobierno electrónico sigue persistiendo la idea que la creación y difusión de información mediante portales como principal acción, sin embargo los medios y políticas para el intercambio de datos e información no han sido una realidad en muchos de nuestros países.

Es mi país, existen grandes brechas en el intercambio de información, sin embargo el conocimiento es el verdadero reto. Como pueden los entes gubernamentales tomar decisiones sin un modelo de información homologado que responda a los intereses de las sociedades, y no a simples reportes de gestión?. Como podemos evaluar la mejora en una área especifica si no tenemos la capacidad de ver el bosque?. Como podemos realizar un ejercicio de tomas de decisiones ágiles y consistentes si en nuestros países todavía domina el Universo del Excel o el Calc?. Como podemos mejorar si no tenemos la capacidad de medir?. Porque no empezamos a evaluar tecnologías que permitan la medición en tiempo real?. Como podemos avanzar si no existe una política concreta para la gestión de conocimiento en TI?

Una plataforma de interoperabilidad puede convertirse en un medio para conocer de forma consistente el estado en tiempo real de las acciones de gobierno de un Estado, construyendo un canal que nos permita evaluar si vamos a buen puerto, sin estamos cumpliendo con las metas que requiere la sociedad, si somos efectivos y eficientes en nuestra gerencia.

Sobre sus componente generales
Una plataforma de interoperabilidad esta conformado por diversos componentes que la integran, entre los mas importantes:

1. Una plataforma integrada de consulta de datos, que contribuya con la reutilización de datos, información y funcionalidades en un estado.
2. Una plataforma integrada de mediación de servicios de interoperabilidad la cual contribuirá con la mediación y la orquestación de servicios.
3. Un mapa nacional de servicios de información interoperable, que proveerá un único punto de acceso a los diferentes servicios de información interoperables provistos por los órganos y entes del Estado, fomentando paulatinamente su conocimiento, reutilización, integración e interoperabilidad.
4. Una plataforma integrada de automatización de procesos interinstitucionales, que podrá administrar el ciclo de vida de procesos transversales de interés estratégico para el Estado.

El Futuro que desearía para mi hija, para mi país, para mi continente
Actualmente estoy trabajando en una propuesta técnica que aborda inclusive elementos de gestión de cambio porque estoy convencido que la calidad de vida de una sociedad esta profundamente ligada al uso efectivo, eficiente e inteligente de las tecnologías de informacion. Reflexionando en este sentido, yo desearía para mi país:

1. Que cada institución desarrolle y adopte los estilos de arquitectura y disciplinas requeridas para asegurar la interoperabildiad de sus sistemas de informacion.
2. Que cada institución pueda compartir conocimiento sobre su perspectiva.
3. Que el estado establezca políticas consistentes y de altura para garantizar la aplicacion de normas.
4. Que el ciudadano común tenga acceso a portales únicos e integrados como: denuncias.pais tramites.pais, datos.pais.
5. Que el estado pueda medir en tiempo real la gestión de sus instituciones y el cumplimiento cualitativo y cuantitativo de sus políticas.
6. Que el estado cuente con un modelo de informacion agnóstico que responda a las necesidades de sus ciudadanos.
7. Que el estado cuente con plataforma de interoperabilidad por sectores: Plataforma Nacional de Interoperabilidad para Alimentacion, Plataforma Nacional de Interoperabilidad para Vivienda, Plataforma Nacional de Interoperabilidad para Seguridad, Plataforma Nacional de Interoperabilidad para Tramites.
8. Que el estado pueda medir, mejorar y optimizar procesos transversales de interés estratégico.   

En Venezuela hemos comenzado a dar pasos

Hace meses tuve la oportunidad de desarrollar desde el punto de vista técnico y arquitectónico un borrador de propuesta de ley de Interoperablidad para el Estado Venezolano, el cual esta siendo impulsado por el Ministerio del Poder Popular para Ciencia, Tecnología e Industrias Intermedias. Una propuesta que contiene elementos innovadores que podrían a futuro convertirse en una referencia a nivel latinoamericano.

La propuesta de ley permitirá a grades rasgos:

1. Garantizar el desarrollo de un estándar común de interoperabilidad en el Estado.
2. Establecer las condiciones necesarias para el desarrollo y adopción de políticas, principios, estándares, normas y procedimientos para el acceso e intercambio electrónico de datos e información entre los órganos y entes del Estado.
3. Promover el desarrollo de servicios de información interoperables adaptados a las necesidades de los ciudadanos y los procesos del Estado.

Como ciudadano de esta tierra, felicito todas las iniciativas que se están dando desde el Centro Nacional de Tecnologías de Información (CNTI) y el CNIT (Centro Nacional de Innovación Tecnológica) instituciones que están dando los primeros pasos hacia el fin ultimo: "Una plataforma Nacional de Interoperabilidad dirigida a mejorar la calidad de vida de sus ciudadanos mediante el uso efectivo, eficiente e inteligente de las TI". Desde aquí muchas energías positivas!!!

Saludos;

SOA, ESB y BPM en el Ecuador (Integrando Mule ESB e Intalio BPM)

Hace poco tuve la oportunidad de viajar a Ecuador e impulsar la adopción de las disciplinas y estilos de arquitectura SOA, ESB y BPM en un entorno organizacional mediante transferencias tecnológicas con el apoyo de soluciones en software Open Source como Mule ESB, Intalio BPM y capacitaciones sobre Gobernabilidad SOA y BPMN2. Me resulto muy grata la estadía. Agradesco a Hugo Chamba y a Brighitt por su hospitalidad y colaboración, Lianet, Juanka y todo el equipo que labora en una organización que esta dando pasos fuertes en la adopción y puesta en practica de estas disciplinas en el Ecuador.

En dichos talleres pudimos compartir en áreas como:

1. Interoperabilidad, estilos y disciplinas de arquitectura SOA (Service Oriented Architecture), ESB (Enterprise Services Bus), BRE (Business Rule Engine), CEP (Complex Event Processing) y BPM (Business Process Management).
2. Introducción al desarrollo de “Blueprints de Arquitectura de Software”.
3. Modelado de procesos mediante la notación gráfica BPMN 2.0, técnicas, patrones y mejores prácticas.
4. Utilización de Eclipse IDE para el desarrollo de proyectos orientados en servicios (SOA).
5. Despliegue de un Bus de Servicio Empresarial mediante MULE ESB; desarrollo de servicios web para protocolos SOAP / REST e integración con Spring Framework.
6. Despliegue de un Sistema de Gestión de procesos de negocio (BPMS) mediante Intalio BPMS.
7. Modelado de procesos para el proyecto de la Fuerza Aérea Ecuatoriana (FAE) – Reclutamiento y Selección de Aspirantes a Oficiales y Aerotécnicos.
8. La importancia de los Marcos de Gobernabilidad y Arquitectura SOA en un entorno de planificación estratégica.
9. Formación Especializada en Intalio BPMS para la gestión de correlaciones, looping sub-process y timers. 

Pronto pondré a a disposición de la comunidad el material que utilice para realizar las transferencias tecnológicas.

Gracias Hugo por la hospitalidad. Espero que sigamos impulsando la adopción y aplicación de las tecnologías de informacion en nuestros países, enriqueciéndonos con ambas experiencias. Muchos Éxitos!!!

Organizaciones que aprenden - Aprendizaje Organizacional

En los últimos años los avances tecnológicos han sido increíblemente exponenciales, cambiando la vida de las sociedades y sus organizaciones de una forma que nunca pudo ser imaginada, por ejemplo empresas pequeñas pueden irrumpir en diversas áreas y cambiar incluso las sociedades. Este escenario ha generado mayor competencia, mayor complementariedad, mayor globalización, mayor intensidad. Las organizaciones que puedan adaptarse y aprender en este medio tendrán definitivamente mayor éxito.

En este post quise escribir sobre un tema poco abordado “El Aprendizaje Organizacional”. Son pocas las organizaciones que cuentan con políticas claras y consistentes para el aprendizaje organizacional. Es muy común que la organización centren sus esfuerzos en los beneficios de sus productos y servicios, y poco en las estratégicas necesarias para asegurar su adaptación en un medio tan cambiante, exigente y dinámico.

Nuestras sociedades requieren nuevas organizaciones, organizaciones con mayor conocimiento, con mayor capacidad de cambio, flexibilidad y velocidad para responder al cumplimiento de sus objetivos estratégicos, sobre todo en las organizaciones públicas donde generalmente existen grandes retrasos en estas capacidades.

Porque deben existir políticas de aprendizaje organizacional?

1. Las organizaciones que aprenden más rápido son capaces de adaptarse y con ello conseguir una ventaja estratégica y mejor desempeño.
2. Las organizaciones que aprenden son capaces de aprovechar el conocimiento colectivo de su talento humano. Esta capacidad, combinada con la mejora continua de sus procesos, su tecnología, y la gestión del conocimiento, permitirá crear y desarrollar “Superorganizaciones”.
3. Las organizaciones que aprenden mejoran continuamente su desempeño.
4. Las organizaciones que aprenden están más conscientes de sus debilidades y fortalezas. 
5. Las organizaciones que aprenden desarrollan un esfuerzo constante y amplio para que la informacion y el conocimiento fluya, crezca y genere valor.
6. Las organizaciones que aprenden definen el conocimiento como la informacion en acción.

Algunas Recomendaciones

1. Desarrolle un programa de aprendizaje organizacional continuo, que permita que el personal pueda registrar brechas y oportunidades de mejora en su entorno laboral.
2. Promueva mediante políticas que su talento humano pueda capacitarse a través del  aprendizaje autodirigido.
3. Utilice la tecnología para aumentar la velocidad de aprendizaje y la gestión del conocimiento.
4. Desarrolle un Programa Organizacional de medición, mejora y optimización de procesos continuo.

"El aprendizaje en el interior de la organizaciones debe ser igual o superior a los cambios que 

ocurren fuera de la organización o la organización muere”.

Cuando implementar BPM en una organizacion?

Hace poco estuve consultando recomendaciones de expertos en BPM para identificar escenarios donde pueden introducirse las disciplinas que integran BPM, en lugar de simplemente la gestión de procesos mediante aplicaciones compuestas, coreografía SOA o middleware de integración tradicionales.

Según algunos expertos, un proyecto BPM debe ser implementado cuando se cumplen estas condiciones:

1. El proceso es distribuido, es decir abarca muchas aplicaciones.
2. El proceso requiere reglas de negocio complejas.
3. Si el proceso es muy complejo.
4. Si usted tiene necesidad de monitorear y controlar un proceso.
5. Si un proceso requiere de mejoras.
6. Si muchas instancias de procesos deben ser desplegadas.
7. Si se cuenta con suficiente disponibilidad de interfaces legadas para apoyar el proceso.
8. Que el retorno de inversión sea mayor que con otros enfoques.

Desde mi punto de vista, efectivamente podrian utilizarse otros enfoques, sin embargo lo mas importante es recordar que BPM no es una tecnología, sino un enfoque que recuerda constantemente lo importante de medir, mejorar y optimizar cada acción estratégica de la organizacion para que esta pueda aprender y mejorar continuamente. Como dice un proverbio chino muy conocido "No importa de que color sea el gato, lo importante es que case ratones".

Saludos;

3 Políticas de TI para crear organizaciones agiles

Desde hace algunos años he estado incentivando desde diversos medios la adopción de disciplinas y arquitecturas de TI dirigidas a mejorar el desempeño de las organizaciones en la administración de sus servicios informáticos. En mi andar por organizaciones de diversos ramos (publicas y privadas) siempre he evidenciado con preocupación la falta de acciones de direccionamiento tecnológicos y la existencia de programas de agilidad operacional en las organizaciones. Si el direccionamiento tecnológico fuera una política organizacional formal, se entendería que este es un instrumento de cambio necesario para evolucionar las practicas de TI.

Sin entrar en mayores aristas para describir la problemática actual, es una necesidad urgente comprender que las organizaciones publicas (sobre todo estas!) y privadas cambien sus practicas de TI actuales, adoptando nuevos paradigmas, paradigmas mas acordes con nuestros tiempos.

Un instrumento que puede ayudar en el cambio de una dirección de TI es el establecimiento de políticas. En este post comparto tres políticas que desde mi punto de vista pueden impulsar la transformación de las practicas de TI de una organizacion. El objetivo es crear una organizacion ágil, efectiva y eficiente mediante el uso de las TI.

Por ultimo antes de entrar en las políticas, una pequeña reflexión: "Las organizaciones son sistemas vivos que deben evolucionar y mejorar continuamente, y el direccionamiento tecnológico es un instrumento para cumplir con esta premisa". Tu puedes ser un agente de cambio!!!.

Políticas Organizacionales

• Las aplicaciones que se desarrollen en la organizacion deben implementar un enfoque arquitectónico orientado en servicios, conocido como Arquitectura Orientada en Servicios (Service Oriented Architecture SOA, con el objeto de promover la reutilización de sus diseños y funciones de negocio. Este estilo requiere del establecimiento de políticas, prácticas y frameworks que permitirán que las funcionalidades de los módulos pueda proveer y ser consumidas como un conjunto de servicios. Los servicios podrán invocarse, publicarse y descubrirse y deberán estar abstraídos de su implementación mediante la utilización de una sola forma estándar de interface. Este estilo de arquitectura garantizara la reutilización de servicios, su integración con otros servicios, disminución de los esfuerzos de desarrollo,  mayor mantenibilidad, basado en contratos estandarizados, evita el acoplamiento, promueve el desarrollo de capas uniformes, entre otros beneficios.

• Los intercambios de datos entre sistemas heterogeneos deberan ser mediados mediante un Bus de Servicios Organizacional (ESB - Enterprise Service Bus) que proveerá una plataforma de integración y comunicaciones flexible para solucionar problemas de integración que requieran ser atendidos por la organizacion. El ESB simplifica la comunicación y ofrece un conjunto de servicios de manera unificada. El ESB soporta los principios SOA. Este provee diversos estándares y protocolos de comunicación, adaptadores y conectores, mensajería sincrónica, asincrónica, punto a punto, publicación-suscripción, entre otros, ademas permite la orquestación y coreografía de servicios y procesos, uso de enrutadores, filtros, transformadores, un modelo de seguridad integral, entre otros beneficios.

• Las reglas de negocio de la organizacion deberán ser gestionadas de forma centralizada mediante la utilización de un motor de reglas organizacional (Business Rule Engine, BRE por sus siglas en inglés). Estas reglas deberan ser expuestas sobre una plataforma de servicios.

Es posible desarrollar un proyecto BPM sin incluir SOA?

Hace algunos meses estuve prestando una asesoría organizacional BPM/SOA en Colombia, y uno de las preguntas más comunes con las que me enfrente fue si es posible implementar un proyecto BPM sin incluir SOA. La respuesta es sí, sin embargo no es lo más óptimo.

Imagínense un Ferrari con todas sus conexiones eléctricas desordenadas, rígidas, inflexibles, viejas, corroídas. Una propuesta BPM sin una implementación SOA puede terminar en una solución rígida e inflexible. La promesa de agilidad operacional se vería afectada.

Las arquitecturas orientadas en servicios proporcionan el sentido, la modularidad y el ordenamiento que requiere una solución BPM para integrar servicios tecnológicos con interacciones humanas.

Por ende:

1. Un proyecto BPM organizacional debe estar alineado con una plataforma de servicios SOA robusta, ordenada, ágil, y segmentada.
2. BPM sin SOA tiende a crear soluciones aisladas y rígidas.
3. BPM y SOA proporcionan una solución organizacional total para desarrollar la capacidad de agilidad operacional.
4. Un buen proyecto BPM debe descansar sobre una estrategia que vincule los procesos y servicios en la organización.
5. SOA es un estilo arquitectónico natural que debe ser adoptado por una organización que se preocupe por una óptima implementación BPM organizacional.
6. BPM es un componente natural en una estrategia SOA y SOA es un componente natural para una estrategia BPM.
7. Hoy en día no tiene sentido crear soluciones que no estén orientadas en servicios.

Saludos;

Recomendaciones para abordar un proyecto BPM - I

He tenido la oportunidad de asesorar a organizaciones que tienen como objeto la inserción de las disciplinas BPM; y en el proceso, he identificado un conjunto de premisas que son necesarios para disminuir los riesgos de su adopción.

Actualmente estoy desarrollando 2 post para compartir con la comunidad mi experiencia en proyectos organizacionales. Comparto las primera recomendaciones con la comunidad. Para mayor referencia sobre BPM pueden visitar el siguiente link: http://mijao.blogspot.com/2009/12/bpm-y-sus-beneficios-dentro-del-estado.html

• Es importante comprender la verdadera esencia de BPM. BPM provee a la organización las capacidades para medir, mejorar y optimizar cada una de las acciones que debe desarrollar para cumplir con sus objetivos estratégicos. BPM impulsa el desarrollo de una política de control sobre los objetivos estratégicos de una organización, equilibrando sus procesos, tecnologías y talento humanos. Los procesos representan el sistema nervioso que requiere una organización para orquestar sus diversos recursos.

• La organización debe implementar un marco metodológico que permita identificar sus indicadores de desempeño y resultado en las diversas áreas de dominio que sustenta su modelo de negocio. En esencia la organización debe conocer que debe medir para evaluar continuamente su desempeño. Sin este insumo, el ejercicio de la toma de decisiones es pobre e inconsistente. Los procesos deben responder a estos indicadores organizacionales.

• Es deseable que cada una de las unidades que integran la organización identifiquen sus productos y servicios. Estos productos y servicios debe estar relacionados con un proceso transversal y un conjunto de indicadores.

• Es importante entender que el insumo principal para abordar un proyecto BPM es el establecimiento inicial de un marco de gobernabilidad. La gobernabilidad es el proceso de toma de decisiones acertadas y adecuadas para alinear y direccionar los esfuerzos para implementar un proyecto BPM. Generalmente, un marco de gobernabilidad está conformado por 9 dimensiones: Estrategia y Objetivos de Gobernabilidad, Principios y Políticas, Organización y Actores, Procesos, Roles y Responsabilidades, Comportamiento y Refuerzo, Métricas y Desempeño, Tecnología, Desempeño de la Gestión de Gobernabilidad y Finanzas y Presupuesto.

• Antes de iniciar un proyecto piloto BPM realice un diagnóstico de las condiciones generales de los procesos presentes: documentación, diagramación, herramientas, normas y procedimientos, entre otros.
•  
• Es deseable que la organización formalice la notación grafica a utilizar para el modelado de procesos. En esencia es recomendable adoptar BPMN (aquí puede conocer más sobre el tema). Es importante destacar que la práctica de modelados de procesos requiere de técnicas y patrones.

• Generalmente las organizaciones tienen una descripción de procesos con un nivel de granularidad inapropiado para permitir que este pueda medir y mejorar su desempeño. Identifique las actividades concretas, acuerdos de servicios, áreas claves de procesos, productos, servicios e indicadores de desempeño y resultados, reglas de negocio, entre otros.

• Durante el desarrollo de un piloto establezca dos categorías de procesos: Procesos que puedan impedir que la organización alcance sus objetivos estratégicos, y procesos que aprovechando su capacidad actual puedan elevar su nivel operativo y cumplimiento de metas.

• Es deseable que inicie en primera instancia la ejecución de un plan estratégico de direccionamiento tecnológico y el desarrollo de una marco de arquitectura que describa las acciones estratégicas de mejora que incidan en el ordenamiento de las Tecnologías de Información y agilidad operacional en la organización. Se pueden incorporar los estilos SOA, ESB, BRE, CEP, MOM, entre otros. Estos estilos de arquitectura simplificaran el desarrollo de un proyecto BPM.

• Fomente la creación de una política para el registro de brechas en la organización como mecanismo de aprendizaje organizacional continuo.

Las 4 Habilidades Personales

Son muchas las publicaciones y libros que describen las diversas habilidades que debemos desarrollar para convertirnos en personas completas. Esta imagen describe las 4 áreas que deberíamos desarrollar, impulsar, incentivar, promover y crear constantemente. Preferí no explicarlas para que cada uno de nosotros reflexione al respecto.

Saludos;

Modelos de Negocio, una aproximación. (The Business Model Generation)

El día de hoy tuve la oportunidad de participar como ponente en un seminario impulsado por el "Periódico El Emprendedor" http://www.periodicoelemprendedor.com.ve/ donde pude compartir con una audiencia llena de energia la importancia y necesidad urgente de adoptar "Modelos de Negocios" como medio para guiar nuestras ideas de emprendimiento.

Comparto con la comunidad mijao esta experiencia. Si desear desarrollar una idea de emprendimiento, un idea innovadora, esta presentación y los conceptos inmersos en ella te serán de mucha ayuda.

Modelos de Negocio - The Business Model Generation

View more presentations from julio cejas

Generación de modelos de negocio - Business Model Generation

Hace poco tuve la oportunidad de escribir sobre "Modelos de Negocio" para el Periódico El Emprendedor http://www.periodicoelemprendedor.com.ve, primera publicación sobre el emprendimiento en nuestro país. Comparto con la comunidad este tema de vital importancia.

El emprendimiento en esencia descansa en la generación y desarrollo de una idea innovadora, idea que debe ser llevada a la acción e ir de lo intangible a lo tangible. Es en la acción donde los emprendedores tenemos los mayores inconvenientes. Ir a la acción implica el establecimiento de un conjunto de tareas que pueden abarcar muchas áreas de dominio como clientes, oferta, procesos, tecnología, entre otros. En este post voy a describir las áreas mínimas que un emprendedor debe considerar para desarrollar de forma sostenible y sustentable su idea de emprendimiento.

En primer lugar es importante reconocer que estamos viviendo tiempos exponenciales, tiempos donde las relaciones con los clientes están cambiando hacia modelos más cercanos y de mayor confianza, ejemplo de ellos son las tecnologías como facebook y twitter y la forma en que las organizaciones están utilizando estos medios para innovar. 

En este escenario, los emprendedores debemos adaptarnos a un entorno cambiante e incluir dentro de nuestra idea de emprendimiento nuevas estrategias para desarrollar y mantener la relación con nuestros clientes, contar con una estructura de costos adecuada, entre otras áreas de importancia.

Dentro de este contexto, es vital e imprescindible que los emprendedores cuenten con una guía o modelo de negocio que describa las áreas mínimas que deben ser consideradas para desarrollar una idea de negocio y disminuir los riesgos en su ejecución. Actualmente existen diversas aproximaciones para el desarrollo de modelos de negocio de autores muy reconocidos; una propuesta desarrollada por Alexander Osterwalder y Yves Pigneur ha sido una de las más aceptadas. Estos autores describen un modelo de negocio como la estrategia que utiliza una organización para crear, entregar y captura valor, y está conformada por 9 bloques:

1. Segmentos de Cliente.
2. Propuesta de Valor.
3. Canales.
4. Relación con el cliente.
5. Flujo de Ingresos.
6. Recursos.
7. Actividades.
8. Aliados de negocio.
9. Estructura de Costos.

El primer bloque establece los diferentes grupos de personas u organizaciones que debemos alcanzar y servir. En el segundo, establece la propuesta de valor que busca resolver los problemas de los clientes y satisfacer sus necesidades. El tercero establece los medios mediante los cuales se realiza la entrega de la propuesta de valor; como canales de distribución, ventas, entre otros. El cuarto describe como son establecidas y mantenidas las relaciones con los segmentos de cliente. El quinto componente describe los canales utilizados para obtener el flujo de ingresos necesario para garantizar la salud de la organización. El sexto, establece los recursos requeridos para ofrecer y entregar la propuesta de valor. El séptimo describe las actividades principales requeridas para desarrollar los productos y servicios; el octavo establece los aliados de negocio necesarios para entregar la propuesta de valor, y por último la estructura de costos requerida para producir los bienes y servicios.

El desarrollo de un modelo de negocio puede ser guiado por estos 9 bloques, sin embargo la generación de ideas es imprescindible para desarrollar un modelo de negocio innovador. Estos modelos pueden ser construidos mediante técnicas, herramientas y procesos.

Algunas Recomendaciones:

1. Antes de poner en ejecución su idea de emprendimiento, desarrolle primero su modelo de negocio.
2. Recuerde que su modelo de negocio no es estático, vivimos en tiempos exponenciales.
3. Conozca que técnicas y herramientas están disponibles para desarrollar su modelo de negocios.
4. Sea creativo e innovador, recuerde que la innovación es recorrer el camino que los demás no han transitado.

Saludos;

Contrato de Software Agil - Principios Scrum

Cuando una organización necesita contratar una empresa para abordar el desarrollo de sistemas de información generalmente suscribe un contrato donde se describe en esencia los derechos y deberes de ambas partes.

En este post comparto algunas políticas que he utilizado en contratos para garantizar una adecuada gestión en proyectos de software mediante la incorporación de algunas practicas ágiles. Los beneficios son incalculables!

A continuación describo las secciones o áreas de dominio que podrían ser utilizadas para modificar los contratos.

Sobre el enfoque de ejecución

1. El proyecto sera ejecutado sobre un enfoque iterativo e incremental.

Sobre el Acta de Inicio y Contrato

1. LA ORGANIZACIÓN realizara con LA CONTRATISTA reuniones de inicio para establecer las premisas requeridas para la firma del contrato y el acta de inicio del proyecto.

Acta de Inicio

1. LA ORGANIZACIÓN realizara con LA CONTRATISTA reuniones de inicio para establecer las premisas generales del proyecto, las cuales serán descritas en un acta de Inicio.
2. El tamaño de cada iteración, será acordado entre ambas partes, y dependerá del tiempo del contrato y el alcance previsto.
3. Los roles y responsabilidades requeridos para la ejecución del proyecto, será acordado entre ambas partes, registrándose en el acta de inicio del proyecto.
4. Las políticas de comunicación requeridas para la ejecución del proyecto, será acordado entre ambas partes, registrándose en el acta de inicio del proyecto.

Entregables o Requisitos

1. LA ORGANIZACIÓN realizara con LA CONTRATISTA reuniones de inicio para establecer los entregables o requisitos que serán desarrollados en el plan iterativo e incremental del proyecto.
2. Los entregables o requisitos por cada iteración, serán acordado entre ambas partes, y dependerá de su priorizacion y valor por parte de LA ORGANIZACIÓN.
3. Los entregables o requisitos serán priorizados a partir de un acuerdo entre las partes, de modo que en las primeras iteraciones se obtendrán los objetivos más importantes del proyecto.
4. El plan de trabajo estará conformado por los entregables por cada iteración, registrándose en el acta de inicio del proyecto.

Contrato

1. LA ORGANIZACIÓN establecerá las condiciones de contratación, utilizando los acuerdos y compromisos registrados en el acta de inicio.

Control y Seguimiento de Proyecto

1. Las actividades de control y seguimiento del proyecto se basará en los entregables completados en cada iteración y en la demostración que debe realizar LA CONTRATISTA. Se entenderá como requisito completado, si incluye todos los entregables asociados de las iteraciones anteriores.
2. El proyecto se ejecutará en iteraciones, con una demostración del producto al finalizar cada iteración.
3. En cada iteración, se generara un acta de aceptación de los entregables y demostración.
4. En cada iteración, se generara un informe de avance para el Gerente del area, donde se deberá registrar el porcentaje de finalización para cada requisito y la tasa de requisitos completados.
5. LA ORGANIZACIÓN ejercerá funciones de inspección del servicio, quien podrá hacerse asistir por personal interno o externo, según lo estime prudente, a su solo juicio. LA CONTRATISTA se compromete a facilitar a la organización o a la persona que hubiere designado, toda la información que fuere necesaria o conveniente para verificar, fiscalizar y supervisar la ejecución del presente contrato; en general, LA CONTRATISTA prestará al personal encargado de la inspección del servicio la más amplia cooperación a los fines de facilitar la adecuada ejecución dentro de los tiempos, calidad y demás condiciones convenidas.

Control de Calidad

1. Todos los entregables acordados entre ambas partes, serán sometidos a un ciclo de calidad definidos en el “Plan de Aseguramiento de Calidad” y no serán admitidos como productos del proyecto, hasta alcanzar un nivel aceptable.
2. Cada iteración deberá producir software con calidad de producción, probado, integrado, y documentado.
3. El proyecto deberá incorporar prácticas “Desarrollo Gestionado por Pruebas”. Cada uno de los entregables, deberá contener scripts de pruebas unitarias, integrales, funcionales, entre otros.
4. En caso que LA ORGANIZACIÓN encontrare alguna incidencia en la demostraciones del producto realizadas en cada iteración por la LA CONTRATISTA, la organización informará a LA CONTRATISTA sus observaciones para que proceda a realizar su corrección.

Controles de Cambio

1. Sólo podrá solicitar cambios en los requisitos y sus prioridades el propietario del producto y estos serán debidamente analizados para establecer si no impactan el alcance del proyecto.
2. LA ORGANIZACIÓN podrá solicitar cambios en los entregables durante la demostración que realiza LA CONTRATISTA, al identificar alguna corrección funcional, técnica, o dependencia requerida para cumplir con los entregables que integran una iteración.
3. La adición de nuevos requisitos tras las demostraciones, no implicará ningún costo adicional si no impactan el alcance del proyecto, de lo contrario deberán ser negociados entre las partes  para determinar su viabilidad, en función de no impactar el alcance del proyecto.
4. Todo cambio solicitado por LA ORGANIZACIÓN sera debidamente documentado y registrado mediante un formato para la realización de “Controles de Cambio”.
5. No se consideran cambios las subsanaciones por parte del equipo de desarrollo de los defectos de calidad de los entregables entregados en cada iteración.
6. Se conformará un comité de proyecto que analizará los cambios solicitados y nuevas solicitudes.
7. Los cambios en prioridades de la lista de entregables o requisitos no implicarán ningún coste adicional en el proyecto siempre que se mantenga el cómputo total de horas del contrato.

Documentación

1. Toda la documentación del proyecto deberá ser entregada de forma incremental e iterativa, es decir, la documentación no se liberara al final del proyecto, sino en entregables parciales.

BPMN 2.0 by Example - Interacciones

Nuevos post del blog http://comunidad-bpmn.blogspot.com/:
http://comunidad-bpmn.blogspot.com/2011/02/ejemplo-de-bpmn-2-bpmn-20-by-example_17.html

BPMN 2.0 by Example

Nuevos post del blog http://comunidad-bpmn.blogspot.com/:
http://comunidad-bpmn.blogspot.com/2011/02/ejemplo-de-bpmn-2-bpmn-20-by-example.html

Ejemplo de BPMN 2 - "BPMN 2.0 by Example" 

Políticas para el desarrollo de software ágil

Una organización que requiera agilidad en la ejecución de sus proyectos de software necesita del establecimiento de políticas que garanticen entrega temprana y continua de artefactos y servicios de software de valor y utilidad.

A continuación describo un conjunto de políticas que he utilizado en consultorias, que permitirán a la organización alejarse del modelo de desarrollo de software tradicional donde se realizaba un levantamiento de información durante 3 meses, y luego 2 meses para el desarrollo. Este tipo de desarrollo no permitía la entrega temprana de valor y no consideraba las siguientes realidades:

1. Es imposible reunir a todos los requisitos al principio de un proyecto.
2. La actividad de análisis y diseño no garantiza que no habrá cambios.
3. Siempre existirán desviaciones en tiempo y recursos.

Lineamientos Generales

1. El proyecto deberá ser ejecutado en iteraciones incrementales con una demostración del producto al finalizar cada iteración: con esta política, se conocerá el estado del proyecto, evaluando si los requisitos cumplen con las expectativas del cliente, si la calidad es la esperada, o si hay retrasos; agilizando la toma de decisiones correctivas.
2. El proyecto se ejecutará en iteraciones incrementales con una duración fija de 3 semanas.
3. Los requisitos se desarrollarán priorizados por el valor aportado al cliente: Esta política permitirá que los objetivos más importantes del proyecto sean atendidos.
4. El control y seguimiento del proyecto se basará en los requisitos completados en cada iteración. Se entiende como un requisito, los entregables asociados a: análisis, desarrollo, pruebas, documentación, etc. e integrados con los entregables de las iteraciones anteriores.
5. Cada requisito debe ser independiente del resto de los requisitos, en la medida de lo posible.
6. Cada requisito debe ser demostrable, permitiendo cómo comprobar con el cliente que el requisito está completado y que se cumplen sus expectativas.
7. El requisito debe ser de un grado de esfuerzo para ser completado semejante al del resto de requisitos: de manera que la organización y el cliente, puedan realizar una extrapolación del progreso del proyecto.

Desarrollo

1. Los componente de software, deberán ser desarrollados y liberados por partes, y no entregados al final del proyecto.
2. El desarrollo de los componente de software que conformaran la solución, deberán ser liberados en varias iteraciones.
3. Cada iteración deberá producir software con calidad de producción, probado, integrado, y documentado (funcional, técnica).
4. Cada iteración deberá cumplir con un subconjunto de requerimientos.
5. Cada iteración deberá contemplar (análisis, diseño, implementación, documentación, etc.).

Pruebas

1. Cada proyecto debe incorporar las practicas de TDD (Test Driven Development).
2. Cada uno de los entregables, deberá contener scripts de pruebas unitarias, integrales, funcionales, etc; mediante la utilización de frameworks como junit, dbunit, mockObjtects, etc.

Documentación

1. La documentación del proyectos, específicamente:  manual de usuario, manual de operaciones, arquitectura de la solución, especificaciones, etc; deberán ser entregables parciales para cada una de las iteraciones, es decir, la documentación no se liberara al final del proyecto, sino en entregables parciales.

Control de Calidad

1. Cada uno de los entregables, serán sometidos a un script de calidad, que ejecutara la organización,  y no serán admitidos como productos del proyecto hasta alcanzar un nivel aceptable.

Control de Riesgos

1. Los riesgos serán identificados en la primera iteración, llevándose a cabo también una valoración inicial de la exposición al riesgo y planes de contingencia. En cada iteración se revisará y actualizará el documento “Lista de Riesgos”, añadiendo además la lista de riesgos más importantes actualizada por cada iteración.

Control de Artefactos

1. Cada uno de los artefactos del proyecto, deberán ser mantenidos bajo un sistema de control de versiones.
2. La organizacion disponibilizara un sistema de control de versiones, que deberá ser actualizado por el cliente de forma remota.

"Es increíble el cambio que puede producir en una organización la incorporación y aplicación de políticas de desarrollo de software ágil".

Visual Thinking, creatividad, innovación y generación de ideas en la organización

“Cuando estas deprimido, tus pensamientos son completamente diferentes cuando estas feliz. Cuando tienes éxito, tus pensamientos son completamente diferentes cuando tienes fracasos. De forma similar, cuando sientes que eres creativo, tus ideas son completamente diferentes cuando no lo sientes”

Inicio este post con una descripcion muy directa sobre la importancia de la creatividad y la generación de ideas. Si lo analizamos, todas las acciones en una organización son impulsadas por ideas, ideas para solucionar, cambiar y mejorar.

Estoy convencido que la ausencia de una cultura organizacional de innovacion continua es la causa que muchas organizaciones no puedan adaptarse a estos tiempos exponenciales, donde las relaciones entre tecnología, procesos y talento humano son la base para el éxito. Las organizaciones deben impulsar la creación de una cultura de emprendimiento e innovación incentivando la generación de ideas, la creatividad, los cambios, la imaginación, por supuesto con una clara orientación a la resolución de problemas.

Algunas recomendaciones para gerentes, impulsores del cambio, evangelizadores e innovadores:

1. Incorpore a la organización las técnicas del Visual Thinking (Utilice un enfoque visual para facilitar la resolución de problemas mediante el pensamiento creativo).
2. Utilice metodologías para incentivar la creatividad como medio para solucionar problemas a través de herramientas y técnicas visuales(utilizando palabras, imágenes, dibujos, diagramas, gráficos, entre otros).
3. Utilice como referencia el libro ThinkerToys, tremenda lectura.
4. Utilice como referencia el libro Gamestorming.
5. Impulse la generación de dinámicas de trabajo, motivación y captación de ideas.
6. Diviértase en el camino :)

Aquí unas notas para reflexionar sobre los cambios que nos esperan a la vuelta de la esquina.

"Las organizaciones que utilizan prácticas colectivas de aprendizaje como el Visual Thinking, Gamestorming, entre otros estaran bien preparadas para prosperar en el futuro, porque serán capaces de desarrollar cualquier habilidad que se requiera para triunfar. En otras palabras, la capacidad de ganancia futura de cualquier organización está directa y proporcionalmente relacionada con su habilidad y capacidad para aprender cosas nuevas. De este modo, las organizaciones que prosperarán en el futuro serán “organizaciones inteligentes”, organizaciones que explotarán la experiencia colectiva, talentos y capacidades de cada persona para aprender a cómo triunfar en conjunto. El aprendizaje se convertirá en una forma de vida y en un proceso continuo, en vez de una parte específica de la carrera de una persona. Para las corporaciones, el aprendizaje es vital para su éxito futuro."

Saludos;

BPMN 2.0

Este año, he decidido crear un nuevo blog dedicado a las tecnicas, patrones y mejores practicas en la actividad de modelado de procesos mediante la notacion grafica BPMN 2, espacio que pretende compartir y colaborar con el desarrollo de una base de conocimiento en esta disciplina BPM.

En este link comienzo con una breve introduccion de BPMN:
http://comunidad-bpmn.blogspot.com/2011/01/bienvenido-bpmn-20.html

Bienvenida mi pequeña exploradora Ariana Isabella

El 12 de Enero del 2011 con 3 kg, 49 cm nació Ariana Isabella, mi pequeña exploradora, la que viene a descubrir y cambiar mi mundo, la que viene a darme de esa energía creadora, la que viene a darle otro color y nota a mi vida, la que viene acércame a ni niñez, la que viene a jugar conmigo, la que viene a recordar mis historias y las suyas, la que viene a ser mi pequeña emprendedora, la que viene a unir, a fortalecer, a querer sin ningún tipo de reserva. No imaginas como te esperaba mi niña. Gracias mi querida esposa por ese hermoso regalo que me has dado, cuanto mundo nos falta por recorrer.

No podía dejar de escribir sobre este acontecimiento que llena mi vida. Bienvenida Ariri a Mijao Blog!!!

Toma, aprieta y guía nuestras vidas mi niña!!!

Bienvenida mi pequeña exploradora!!!

...

Palabras de creatividad, innovación y liderazgo para el 2011

Llego un nuevo año, año de nuevas ideas y acciones. Comparto con la comunidad el mapa de palabras que nos debe guiar para desarrollar nuestra vida profesional y familiar.

Disciplinas: SOA, BPM, CEP y EDM y la cultura organizacional

Hace unos meses escribí una intro para un informe de TI que considero relevante para compartir con toda la comunidad mijao. En estas notas describo las disciplinas que deberían insertarse en la cultura de una organización ágil y eficiente.

"Actualmente existe una enorme brecha entre la gestión de operaciones y la tecnología que debe soportarla en muchas organizaciones. Esta situación generalizada es originada en la mayoría de los casos por problemas de gobernabilidad y direccionamiento tecnológico afectando el desempeño, calidad y capacidad de aprendizaje organizacional necesaria para el cumplimiento de su visión, misión y objetivos estrategicos. En este sentido una organización debe emprender acciones para poder medir, mejorar y optimizar sus procesos de negocio.

Para alcanzar dicho objetivo, es necesario que la organización explote todo el potencial de las tecnologías de información y adopte nuevos enfoques con el fin de hacer realidad su visión. La clave de esta visión es la comprensión del papel y el rol de las disciplinas y arquitecturas SOA, BPM, CEP y EDA, tendencias actuales y normas que están desarrollando organizaciones ágiles y efectivas actualmente.

En líneas generales, SOA (Arquitectura Orientada en Servicios) proporciona estrategias para el desarrollo de un mapa de servicios de información flexible, adaptable e interoperable el cual ordena la arquitectura de TI de la organización en una gama de servicios reutilizables e independientes de tecnología. SOA aumenta en gran medida el potencial de intercambio de datos entre unidades internas y externas a la organización, haciendo énfasis en la reutilización e interoperabilidad de funciones de software, e integración de sistemas heterogéneos.

BPM (Gestión de Procesos de Negocio) proporciona estratégicas para el desarrollo de un marco de procesos flexible que permita su medición, mejora continua, optimización y sirva de soporte efectivo a la toma de decisiones que requiere la organización. Con esta disciplina, la alta dirección podrá contar con herramientas para la toma de decisiones, que direccionaran sus esfuerzos y recursos en aras de optimizar los costos operacionales, la calidad y velocidad de despliegue de servicios, la convergencia de procesos, la identificación de productos, servicios, acuerdos de servicios e indicadores de desempeño y resultado.

EDM (Gestión de decisiones Organizacionales) proporciona estrategias para la toma de decisiones empresariales y su planificación, las cuales pueden ser optimizadas desde una perspectiva organizacional. Por último y no menos importante CEP (Procesamiento de Eventos Complejos), proporciona estrategias para la gestión de eventos.

La aplicación de cada una de estas disciplinas en la organización supera con creces los beneficios de TI asociados; su adopción requiere de una transformación que permita explotar nuevos cambios de paradigmas logrando la agilidad operacional, mejorando la velocidad, costos y calidad de las operaciones y servicios de la organización. Estos beneficios permitirán que la organización pueda adaptarse a nuevos escenarios y responder a nuevas oportunidades.