viernes, 27 de septiembre de 2013

Las fechas de un proyecto bien formulado son probabilísticas

En un proyecto sofisticado siempre hay condiciones que requieren
reevaluar los cronogramas, los riesgos y los planes de mitigación
Algunos procesos de desarrollo de soluciones de gestión de información son delicados y hay que tomarse el tiempo necesario para minimizar las probabilidades de que ocurran ciertos problemas, aguas abajo, debido a una mala construcción realizada aguas arriba. Algunos gerentes sienten mucha necesidad de correr hacia la entrada en producción de sus soluciones. Y se entiende. Las demoras suelen tener implicaciones económicas importantes. No les falta razón cuando aquilatan la importancia de cumplir los cronogramas y ahorrar costos. Los procesos fuera de control, abiertos y sin hitos que cumplir en el tiempo son ineficientes e indeseables. Pero no manejar riesgos es un sinsentido y, mientras más grande e importante es un proyecto, mayores son las razones para gestionarlos. No se debe pretender cumplir los cronogramas ignorando riesgos. En este contexto hay que tomar en cuenta que las fechas de cualquier desarrollo no trivial no son determinísticas, sino probabilísticas.

Es idílico pensar que un proyecto grande y sofisticado puede desarrollarse sin contratiempos o consideraciones de riesgos. Cuando la NASA desarrolla una misión espacial, sabe que la fecha de lanzamiento no es precisa, sino que es un hito que debe ocurrir después de otros y que debe manejarse como un período cuya precisión se plantea en términos probabilísticos. Mientras más cercano se está de un hito, es más fácil cerrar los intervalos de tiempo, pero ni siquiera al acercarse al final de una etapa las consideraciones son absolutamente predecibles. Incluso el día anterior al lanzamiento hay variables que pueden no estar determinadas. Cuando ya todo está desarrollado, probado y preparado, lo que se sabe es que la partida de la nave será al día siguiente, con alta probabilidad. Un fenómeno de condiciones meteorológicas inadecuadas o un inconveniente de salud de una de las personas críticas, por sólo colocar un par de ejemplos, podría llevar a una suspensión temporal del despegue y exigir un nuevo retraso.

Si las fechas de un proyecto son naturalmente probabilísticas, no expresa sapiencia sino inexperiencia, ingenuidad o ignorancia el pensar o intentar que con puro voluntarismo se pueden pasar por alto los riesgos asociados a la construcción de una solución y cumplir así, llueva, truene o relampaguee, un cronograma que erróneamente se ha planteado en forma determinística.

Con el tiempo, uno va acumulando experiencias sobre buenas y malas prácticas. Hemos visto gerentes ignorar los riegos de saltarse actividades necesarias pretendiendo ahorrar tiempo y recursos, con la triste consecuencia de obtener el efecto contrario, alargar los calendarios y los gastos cuando se presentan las fallas como consecuencia de omisiones y malas decisiones. Alternativamente los tiempos hay que gestionarlos. Administrar etapas y cronogramas de proyectos implica, entre otras actividades, un análisis permanente de determinación de riesgos. Las buenas prácticas de gestión de la calidad recomiendan considerar y reconsiderar los eventuales planes de mitigación, así como explorar alternativas de mejoras que surgen en el camino y que por alguna razón no fueron consideradas inicialmente.

Cuando hay análisis de gestión de conocimiento se pueden descubrir nuevos aspectos que se deben tomar en cuenta en una solución y esto puede ocurrir en cualquier fase del proceso. Ignorar estos factores no es la mejor práctica. Incluir permanentemente nuevos elementos tampoco lo es. El equilibrio está en un punto intermedio que los buenos gerentes deben medir.

Celebrar los cumpleaños de los hijos en fecha precisas es posible porque las acciones están tipificadas, las conocemos, las prevemos y las implementamos. Pero estos son procesos triviales. Un buen gerente conversa las situaciones con los desarrolladores, registra, mide, analiza y toma decisiones. No administra todos los procesos como si sólo se tratara de celebras los cumpleaños de los hijos.

viernes, 20 de septiembre de 2013

Soluciones de gestión basadas en reglas de negocios

Desarrollar sistemas basados en reglas de negocios requiere
de Arquitectos de Información de gran experiencia
Lo que ocurre aguas arriba no sólo trae consecuencias, sino que, para bien o para mal, se amplifica aguas abajo. Las aplicaciones basadas en reglas de negocios son una alternativa que busca imprimir gran eficiencia a la gestión de información y el desarrollo de soluciones. Tiene la ventaja de que al implementar una gran cantidad de decisiones aguas arriba, facilitan y simplifican el control de los procesos aguas abajo. Obviamente, requieren de Arquitectos de información de gran experiencia para su desarrollo, ya que deben abstraerse las reglas de negocio que subyacen en la institución, muchas veces bajo la forma de conocimiento tácito. El desarrollo y la implementación también son delicados por la concentración que exige el efecto de amplificación mencionado.

Una solución basada en reglas de negocio puede implementarse desarrollando un software a la medida institucional, pero una mejor práctica muchas veces será el uso de alguna plataforma que permita gestionar la información en forma tal que la lectura de las reglas de negocio permita cambiar los flujos de trabajo.

¿Cuáles son los componentes que intervienen?
Un repositorio de reglas de negocio que normalmente tiene la capacidad de almacenar no sólo las reglas actuales sino la historia de las reglas que tuvieron vigencia en ciertos períodos.

Un mecanismo de captura de políticas y reglas de negocio, expresadas en una manera comprensible para las personas involucradas. Este mecanismo debe permitir la inserción, modificación, consulta y eliminación de reglas.

Un mecanismo dinámico de interpretación de estas reglas, capaz de cambiar la funcionalidad y el curso de las acciones según los valores contenidos en las reglas.

La integración de estos tres componentes permite realizar cambios en los procesos de negocios, incluso cambios estructurales, importantes, en forma rápida y fácil, sin que esto implique el desarrollo de software o de bases de datos, salvo los generados en forma automática por el propio sistema.

La posibilidad de hacer cambios en los procesos sin necesidad de desarrollar software constituye una oportunidad de diferenciación institucional ya que proporciona una alta capacidad de respuesta. También permite realizar auditorías basadas en los períodos de vigencias de las reglas.

Más que desarrolladores de software, este tipo de sistemas lo que requiere es de Arquitectos de información capaces de dirigir procesos de abstracción de la lógica implícita en los procesos de negocios institucionales trabajando en forma directa con el personal involucrado. Una vez abstraída, esta lógica plasmada en reglas puede usarse para un desarrollo de software convencional, pero su empleo en un sistema basado en reglas de negocio proporciona más agilidad y eficiencia ya que simplifica el proceso de introducir nuevos productos y servicios, así como cambios en los ya existentes.

Una vez implementada la solución, el personal de las unidades de negocio puede participar, dirigir, implementar y probar directamente los cambios, ya que no se requiere de programación.

Como consecuencia, las aplicaciones basadas en reglas de negocios se implementan en  forma más rápida y resultan de más fácil mantenimiento por lo que ahorran costos en forma significativa. No requieren los delicados, largos y onerosos procesos de desarrollo y prueba de software.

viernes, 13 de septiembre de 2013

Las reglas de negocio como estrategia de desarrollo

La formulación explícita de reglas de negocio se usa hoy día como una
estrategia coompetitiva para desarrollar sistemas ágiles que responden
más rápidamente a situaciones cambiantes.
Es un proceso intensivo en conocimiento
El uso de Tecnologías de la Información es hoy día un “commodity”, es decir, un conocimiento que está generalizado y que por tanto es una condición necesaria en toda institución, pero no un diferenciador.  Uno de los problemas que tiene que enfrentar un gerente de tecnologías de la información es cómo efectivamente introducir capacidades y soluciones que efectivamente aporten diferenciadores en el desarrollo del quehacer cotidiano institucional. Si lo logra, la institución avanza y se distingue en su categoría. Si no lo logra, la institución sólo se mantendrá alrededor del promedio. Los sistemas de gestión de información basados en reglas de negocio son una de las estrategias que actualmente se usan para distinguirse.

La aproximación “tradicional” en las décadas pasadas estuvo basada en el desarrollo de software a la medida, construido para las necesidades institucionales. La estrategia funcionó, pero hoy día luce como un método insuficientemente dinámico para ser exitoso. Por un lado, suele ocurrir que los cambios en el entorno van mucho más rápido que el desarrollo de software institucional. Por otro lado, cuando se generalizan el uso de herramientas, métodos y prácticas hay una necesidad de nuevas estrategias para toda organización que quiere distinguirse en su sector.

Una buena solución programada no es fácil de construir. Tiene, como hemos visto, un ciclo de desarrollo (ver El ciclo de vida de una solución de gestión de información) que pasa por varias fases. Dentro de estas fáses, el análisis y el modelado de la información es algo ineludible. Sería un sinsentido intentar e incluso pensar en el desarrollo de una solución sin un buen análisis y modelado. Sería una navegación sin brújula que no llevaría a ninguna parte y que sólo ocasionaría gastos. El problema es que después de este trabajo en el dominio del problema y de la información, típicamente hay que implementar lo que la solución implica en el manejo de los datos y, por mucho que las bases de datos son herramientas consolidadas que ayudan a diseñar, modelar y construir aplicaciones, ellas trabajan en el dominpo de los datos y de allí que los procesos de desarrollo de soluciones son típicamente sofisticados y lentos.

Un proceso de información es un cambio que ocurre en el dominio de la información y de un modo natural implica muchos, quizá decenas o centenas de procesos de gestión de datos. Una relación de información conlleva, implícitas, numerosas relaciones de datos y un proceso de negocios, una gestión documental o transacción de flujo de trabajo simple, requiere de implementar numerosas relaciones de información. De allí la lentitud que es característica del desarrollo de las soluciones, la alta tasa de fallas y la gran cantidad de proyectos de tecnologías que se quedan a medio camino y que se cierran sin presentar resultados productivos.

Por eso es de gran ayuda si se logra automatizar el proceso mismo de modelado y construcción del manejo de datos de las soluciones de gestión de información. Esta es una estrategia que viene siendo usada por generadores de aplicaciones que tienen éxito en ciertos dominios verticales.

La formulación explícita de reglas de negocio y el desarrollo de sistemas y soluciones basados en ellas luce como una estrategia claramente diferenciadora, ágil y dinámica. Se trata analizar cada problema de negocio hasta abstraer el conocimiento que subyace y expresarlo en términos de reglas de negocio (ver Formulación de Reglas de negocios). Si luego se logra crear una capacidad de implementar soluciones directamente  a partir de estas reglas el camino se simplifica y la velocidad de implementación aumenta. No es un camino trivial, porque es muy intensivo en conocimiento. Pero es altamente productivo, un auténtico reto para Arquitectos de información, gerentes de negocios, de tecnologías y de información.

viernes, 6 de septiembre de 2013

Aprender a generalizar: Los valores constantes en las reglas de negocio

Los Arquitectos de Información aprenden a generalizar los
valores constantes en la formulación de reglas de negocio
La semana pasada estuvimos hablando de la formulación de reglas de negocio como una de las estrategias que usan los Arquitectos y gerentes de información para definir o caracterizar las propiedades de un  sistema que deben estar presentes en una solución automatizada, independientemente de las tecnologías que se usen en la construcción de la aplicación. Hicimos una introducción general a lo que las reglas de negocio son y vimos que éstas podían formularse de muchas maneras, si bien en general se recomendaba hacerlo lo más simple y entendible posible. Esta semana queremos complementar un poco el tema de la formulación de reglas de negocio ampliando como, en algunos casos, aunque suene menos simple, debemos buscar la manera de generalizar algunas de nuestras afirmaciones cuando usamos valores constantes.

Valores constantes son números, fechas, cantidades, roles, que resultan puntualmente específicos y que, en el trabajo que nos ocupamos, suenan como valores que permanecen inalterables en el tiempo.

Precisamente lo que ocurres es que, como lo sabe la gente de mucha experiencia, estos valores constantes en muchos casos dejan de serlo. Debido a ello es conveniente que encontremos maneras en que estos valores constantes puedan ser formulados en forma de abstracción simple, por ejemplo, hablando del número máximo, número mínimo, monto crítico, monto máximo de otorgamiento, monto mínimo de transacción, fecha de caducidad de la oferta, período de vigencia, etc. Este tipo de formulación normalmente aumenta la vida del enunciado que le damos a la regla de negocio. Y sólo requiere algunas definiciones adicionales.

Por ejemplo, si decimos "el precio de un grupo de ítems es de un 20 % por encima del costo", la regla queda atada al valor 20%. Si decimos "el precio está definido como el costo multiplicado por el porcentaje de venta establecida en la temporada", estamos en presencia de una regla que puede mantener su vigencia durante varias temporadas, con varios valores de porcentajes definidos para ellas. Por supuesto, nada es gratis en la vida, el cambio requiere que nos demos el trabajo adicional de definir los porcentajes en cuestión para cada temporada. Pero esto es sólo un valor en un sitio establecido, no una formulación de una regla de negocio.

Si nos referimos a “los recaudos para el crédito menor de cinco millones”, estamos en presencia de una formulación de una regla donde la categoría clasificatoria (el crédito menor de cinco millones) queda atada, innecesariamente, a un valor constante. En cambio, si alternativamente formulamos: “los recaudos para el crédito simple son estos”, estamos usando un tipo de enunciado (el crédito simple) que seguramente será más duradero, con la obligación, eso sí, de apuntar en algún lado de algún documento, que el crédito simple es un crédito inferior a los cinco millones.

Con la práctica los Arquitectos de información aprenden de esta forma a redactar reglas de negocio simples, entendibles y con el nivel de abstracción adecuado para que sean más duraderas. Lo interesante es que estas reglas de negocio forman así un lenguaje común que permite al jefe y a los colaboradores, a los diseñadores de modelos y a los constructores, conversar y entenderse en las distintas fases del desarrollo de una solución de gestión de información.