Evitando que el Proceso sea el Objetivo o (Diseña Para Excepciones)















Un viajero está atrapado en el tráfico de Sao Paulo, Brasil, y se da cuenta que será imposible llegar a tiempo al aeropuerto para su vuelo. Llama a la agencia de viajes de su compañía y es amablemente informado que no hay nada que puede hacer por el: “lo lamento mucho señor,” indica amable pero testarudo el operador, “el procedimiento que su empresa nos impone requiere que todos las solicitudes de cambios de viaje se hagan con por lo menos 24 horas de anticipación y tienen que ser aprobadas por la gerencia de su empresa, sin excepción.” Frustrado, el viajero compra un nuevo billete con el prospecto de tener que ganar una larga negociación para que la empresa le devuelva su dinero.

Un profesor de colegio maneja más de una hora hasta el taller de su mecánico favorito para una revisión de 25,000 km y allí se le informa que no pueden recibir su carro porque no hizo una reserva de acuerdo a la nueva política implementada luego de la implementación de un nuevo sistema informático. “El sistema no me deja registrar su carro sin una reserva que corresponde a la placa de su vehículo,” explica la recepcionista. Al profesor se le indica que utilice un número telefónico para hacer una reserva para otro día. Como él hay varios clientes que no pueden dejar sus vehículos.

En ambos casos los procesos y sistemas fueron implementados para resolver problemas importantes. La compañía que contrató a la agencia de viajes estaba intentando organizar el caos existente y asegurar que los viajeros no cambien los detalles de los viajes de negocios por motivos personales. En el taller de mecánica el nuevo sistema está diseñado para ayudar a los clientes en una recepción más ordenada de los vehículos para evitar las largas filas endémicas en el popular taller.

Lo que pasó en realidad es exactamente lo opuesto a lo que se intentaba lograr. La agencia de viajes no asistió al viajero en problemas y los clientes del taller de mecánica tuvieron que regresar a casa sin ser atendidos.

Para entender el problema necesitamos revisar por qué construimos procesos de negocio y por qué construimos sistemas para automatizarlos.

Un proceso es nada más que una serie de actividades o pasos estructurados que necesitan ejecutarse para lograr un objetivo. Se necesitan para asegurar que los resultados o productos sean predecibles, para asegurar su calidad y poder estimar su costo con precisión. Construimos sistemas para automatizar estos procesos y garantizar aún más que éstos sean predecibles y aumentar nuestra capacidad para medir y analizar los datos relacionados y mejorar nuestra capacidad de presupuestar antes de tiempo. Las organizaciones maduras también implementan procesos para asegurar su sostenibilidad cuando hay rotación de personal o para evitar una catástrofe cuando sólo una persona conoce algo y se va de la empresa. En algunos casos algunas organizaciones implementan procesos para asegurar que los productos o servicios provistos están de acuerdo a regulaciones o leyes.

Un proceso de negocios típicamente comienza con un objetivo o misión que deletrea porque se está construyendo el proceso y que es lo que intenta lograr. Esta misión u objetivo actúa como un compás que apunta al norte y nos ayuda a encontrar el camino.

Pero muy frecuentemente, los diseñadores de proceso y las personas que usan los procesos se olvidan de la misión u objetivo original y dejan que el proceso mismo se vuelva el objetivo, distorsionando completamente su aplicación en el contexto original. Igualmente, los ingenieros de software frecuentemente se olvidan el objetivo del proceso e implementan sistemas que son más camisas de fuerza que herramientas de automatización.

Cuando la compañía en el primer ejemplo decidió contratar a un agente de viajes para asistir en la complicada tarea de coordinar los viajes de su personal, creo al mismo tiempo un proceso que los viajeros debían seguir para obtener pasajes y expensas de viajes, incluyendo sub-procesos para solicitar cambios a los itinerarios de viaje que demandan 24 horas de aviso y autorización de un ejecutivo de la división de personal.

En la superficie este es un proceso razonable diseñado para organizar el caos existente y asegurar que los viajeros no cambien sus planes de viaje de negocios sin autorización de los ejecutivos ya que todo cambio implica cambios presupuestarios, multas de las líneas aéreas, cargos excepcionales del hotel, etc.

El lector puede argumentar que el procedimiento está mal definido o es simplemente poco realista porque ninguna organización en su sano juicio implementaría dichos procesos, pero este ejemplo no es solamente real sino es además típico. El objetivo del proceso es asistir a los viajeros con un sistema más estructurado y ordenado para organizar viajes y en principio es correcto. Lo que la empresa y el agente de viajes olvidaron es el objetivo o misión original o (asistir a los viajeros) y los diseñadores de los procesos olvidaron incluir emergencias y excepciones en el proceso.

Éstos son ejemplos reales de compañías que tienen problemas porque los diseñadores de los procesos, ingenieros de sistemas y empleados frecuentemente olvidan que el objetivo o misión deben ser completamente soportados por el proceso y los sistemas, incluyendo excepciones o emergencias. El diseñar un proceso que solamente toma en cuenta el flujo normal que no tiene problemas es mucho más simple que diseñarlo para tomar en cuenta excepciones de forma elegante. Los diseñadores de procesos e ingenieros de sistemas experimentados saben que diseñar el proceso completo puede ser 10 veces más caro.

Pero sin un tratamiento elegante de estos casos excepcionales el proceso se vuelve un problema y no una solución, los empleados se frustran porque los procesos no toman en cuenta que frecuentemente ha excepciones y problemas y los clientes se frustran porque la organización insiste en seguir reglas y guías que son claramente ridículas dadas las circunstancias excepcionales.

Para los diseñadores de sistemas y procesos ofrecemos algunas reglas que tal vez deseen incorporar el esquema de trabajo: espera lo inesperado y diseña sistemas que lidian con eventos excepcionales de forma elegante, como permitir cambios fuera de los tiempos permitidos, permitir transacciones sin el proceso normal de autorización, permitir reversión de transacciones que fueron ingresadas por error, etc.  Estos sistemas serán más difíciles de construir, dado que necesitan incorporar excepciones, sistemas de seguridad especiales, logs y reportaje de excepciones, pero hará la vida de tus clientes mucho más productiva y menos estresante.

Comentarios