A ver si algo de esto les es familiar:
Chucho Melosetocho trabaja en ChidaSoft™, que ha sido contratada por Grupo Enorme (sin albur) para hacer un súper sistema porque Enorme trae pedos mayores con cómo maneja su proceso surtido de pedidos.
Grupo Enorme se dedica a hacer Chuchulucos® de todos tipos, tamaños, sabores y colores. De hecho es la empresa más grande de chuchulucos en el país. Pero últimamente, han crecido tanto que sus problemas son evidentes: cuando un cliente les hace un pedido, tardan hasta un mes en surtirlo y por lo mismo, están perdiendo terreno a la competencia, LosQueremosClientes LosQueremos, S.A. de D.R. y R.L. (o sea Sociedad Anónima de Dudosa Reputación y Responsabilidad aún más Limitada).
Así que los jefazos de Enorme se juntaron y decidieron que lo que necesitaban era automatizar todo el “proceso” de distribución, cobranza y pagos. Ellos esperan que un sistema les ahorre hasta un 25% en los costos y un 50% en el tiempo de entrega, según un estudio que hizo su departamento de “IT”—Ingenieros Tarados—y por eso contrataron a ChidaSoft™, quien sin pensarla mucho dice “pan comido” y manda al pobre de Chucho a intentar tomar requerimientos y hacer el análisis del sistema.
Pero Chucho se topa inmediatamente con problemas: la mera-mera de Finanzas, una C.P.—Cabeza de Pollo, digo, ejem… Contadora Pública—con lógica y cabeza cuadrada, se la pasa del chongo con los del almacén porque surten los pedidos de los clientes, aún cuando éstos tienen pagos atrasados; el del almacén se la pasa de la greña con los de producción porque no le entregan las cosas a tiempo y los clientes les gritan cada vez más feo porque están adictos a los Chuchulucos® y sus pedidos no están listos; y el de producción le echa la balona a los de compras que no le tienen la materia prima que necesita a tiempo… en fin… cualquier parecido a la realidad es a propósito.
Así que temeroso de perder su chamba y quedarse sin dinero para ir a teibolear, Chucho entrevista a los jefes de cada departamento por separado para ver qué es lo que necesitan que el sistema haga—intentó en un principio juntarlos a todos para que se pusieran de acuerdo pero las juntas terminaban siempre en insultos, malas palabras, sillas arrojadas y sacadas de lengua.
Cada uno de los jefazos le dice cómo se hacen las cosas en la empresa y le da una larga lista de navidad de lo que quieren que haga el sistema y de pero muchas cosas se contradicen: es evidente que nadie conoce “el proceso” y algunos no parecen saber ni a qué $#¡|\|&@dos se dedica en realidad la empresa.
Después de meses y meses de juntas por teléfono y andar conciliando requerimientos finalmente logra hacer sus diagramitas de casos de uso, sus escenarios de los casos, diagramas lógicos y todo lo demás que dicta el UML y las metodologías de desarrollo de software moderno. Se avienta una documentación clara y precisa que le pasa a al equipo de desarrollo quien con diligencia y un control de calidad estricto tira un código hermoso y elegante.
Pero Enorme no está contento. El proyecto tardó y costó casi el doble de lo que habían previsto y al correr el piloto se dan cuenta que solo ahorrarán un 10% en el costo y tiempo sobre el esquema anterior. Comienzan los gritos, los insultos y las amenazas de no pagarle a ChidaSoft™, y a pesar de que el sistema se apega a los requerimientos que todos los jefes firmaron. Enorme insiste que el sistema “no es lo que pedimos, no nos está ahorrando el dinero que estipulamos cuando los contratamos así que no les vamos a pagar”.
Abrumado y cabizbajo, Chucho visita a su Sensei, quien después de reírse descaradamente de él le dice:
—Saltamontes, has olvilalo la legla del flujo: “si fluye algo le trabajo debes consilelal wolkflow, pelo si el tlabajo fluye lejos debes usal wolkflow”.
Y Sensei le presta su copia de
Workflow Modeling: Tools for Process Improvement and Application Development (Alec Sharp y Patrick McDermott, Artech House © 2001).
¿Qué significa todo esto?
En mucho más de una ocasión me ha tocado hacer o mantener un sistema, y que de pronto me hable Fulanito de Tal, del departamento X para que le explique cómo funciona algo o qué se hace con cierto pedazo de información, o para pedir un cambio al sistema del cual se va a arrepentir luego de explicarle que el hacerlo impactaría otra cosa de otro departamento.
En pocas palabras, nosotros, las “personas de sistemas” algunas veces, en sabemos más del “proceso” que las mismas áreas de negocio. Y me pregunto: “¿Cómo es esto posible?”
Parte de la evolución de las empresas en los últimos 10 o 15 años ha sido el reconocimiento de que deben estar orientadas a los procesos de negocios—¿recuerdan todo el ruido que causaron “mejora continua” y “reingeniería de procesos”?
Esto es, la especialización en las empresas ha llevado a que cada departamento se preocupe tanto por eficientizar sus “procesos”, que en muchas ocasiones pierden de vista el “proceso global”: lo que la empresa realmente de dedica.
Dado que el flujo de trabajo (workflow) no es más que una abstracción de los procesos de negocio—el cual se formalizará típicamente en un sistema computacional—es muy importante saber analizar bien cómo fluye el trabajo antes de hacer la definición, análisis o diseño por tres grandes razones:
- Para que todas áreas o personas involucradas sepan qué están haciendo en realidad—cómo está funcionando su empresa—y qué se puede mejorar;
- No repetir simplemente cómo se hacen las cosas y/o formalizar en una aplicación actividades que no agregan valor (“no hay que pavimentar los caminos de las vacas”, o la clásica replicación ciega de procesos en papel); y
- Determinar si en realidad hay algo que se pueda mejorar/ahorrar con un sistema, o si un simple cambio en las actividades del negocio es suficiente. Si se determina que sí agrega valor un sistema, entonces automáticamente ya se tendrán los requerimientos o características deseadas en él.
Sharp y McDermott proponen un famework como el siguiente:
Estas técnicas también sirven cuando se está considerando implementar un sistema “Enterprise”—SAP, PeopleSoft, Siebel, etc.—que cuestan un lanototota. Muchas empresas los compran pensando que así recién sacaditos de la caja van a resolver sus problemas como por arte de magia, solo para descubrir—decenas o cientos de miles de dólares más tarde—que para que en verdad les sirva tienen que adaptarlos a la manera particular en la que trabajan en la empresa, lo cual lleva a que contraten gente para que les personalice el sistema hasta el punto en el que se dan cuenta que uno hecho a la medida les hubiera salido más barato desde un principio. Todo porque no comprendían su propio workflow desde un inicio.
Lo “malo” es que aprender a modelar workflow requiere un poco de habilidades de administración de empresas o incluso ingeniería industrial—¡guácala!—pero afortunadamente en dosis no-letales. Así que los ingenieros de sistemas estamos en una posición óptima para en verdad aportar valor a una empresa cuando surgen proyectos de este tipo.
La herramienta por excelencia en este tipo de modelación son los swimlane diagrams (¿diagramas de canales? maldita traducción), los cuales son distintos a los que se manejan, por ejemplo en UML o en análisis estructurado. Quizá ya los hayan visto, no son más que diagramas de flujo puestos contra un fondo de canaletas, donde cada canaleta representa el área de acción de un Actor.
Pero leer estos diagramas es mucho más sencillo que hacerlos, así que hablemos un poco del proceso para poder llegar a desarrollarlos.
El proceso para analizar, modelar y mejorar procesos
Según Sharp y McDermott:
- Encuadrar y definir el proceso
- Identificar un proceso de negocios y clarificar sus límites
- Hacer una evaluación inicial con todos los interesados
- Establecer las metas del proceso rediseñado
- Comprender el proceso actual (“as-is”)
- Modelar la manera en que fluye el trabajo (workflow)
- Hacer una evaluación más profunda tomando en cuenta los 6 “habilitadores” de un proceso de negocios: diseño de workflow, tecnología de información, motivación y medidas, recursos humanos, políticas y reglas, instalaciones y ambiente de trabajo
- Diseñar el proceso nuevo (“to-be”)
- Ingeniar las mejoras potenciales
- Evaluarlas de acuerdo a los 6 habilitadores
- Seleccionar las características principales deseadas del nuevo proceso
- Diseñar el nuevo workflow
- Desarrollar casos de uso y escenarios de uso—hacer la transición hacia análisis de requerimientos de sistema describiendo cómo los actores interactuarían con el sistema para realizar sus actividades.
No voy a profundizar en cada uno de los pasos, para eso les recomiendo el libro, el cual trae muchísimos “tips” basados en casos y ejemplos de la vida real, así como un montón preguntas que se deben hacer durante todo el proceso.
Mi intención, en los siguientes posts será enlazar el concepto de workflow con algunas de las herramientas de que conozco o que van a salir, especialmente Windows Workflow Foundation, que será parte de WinFX. Así que estén pendientes...