Comience con un problema del que alguien ya se queja
Un primer flujo de trabajo debería ser un proceso que una persona identificada ya quiere corregir. No el técnicamente más interesante, ni el que tiene los datos más limpios. Si nadie está actualmente frustrado con el proceso, nadie adoptará el reemplazo.
Consideremos un ejemplo ficticio: un equipo de finanzas de cuatro personas recibe alrededor de 600 facturas de proveedores al mes. Dos de ellas dedican parte de cada día a cotejar facturas con órdenes de compra y recibos, y a resolver las diferencias por correo electrónico. El equipo puede describir el problema en una sola frase, lo cual es una buena señal de que está bien acotado.
Confirme la propiedad antes de diseñar
Todo flujo de trabajo necesita un responsable que pueda aprobar un cambio en la forma de hacer el trabajo. Si el proceso atraviesa tres departamentos y nadie puede decidir, el proyecto se estancará justo en el momento en que el diseño se vuelve concreto.
La propiedad también determina la revisión. En el ejemplo de las facturas, el contralor es dueño del umbral de excepción y de los límites de aprobación delegada. Esas son decisiones de negocio, y la arquitectura simplemente las hace cumplir.
Mida la línea base antes de cambiar cualquier cosa
No se puede afirmar una mejora sin un antes. Dedique un período breve a registrar lo que realmente ocurre: cuántas facturas coinciden en el primer intento, cuánto tiempo espera una excepción, con qué frecuencia se reintroduce un dato, cuánto del retraso de fin de mes proviene de esta cola.
Una línea base también es una prueba de factibilidad. Si las cifras son difíciles de recopilar, es posible que los sistemas subyacentes tampoco expongan suficiente información para que un flujo de trabajo opere sobre ellos.
Ponga a prueba la factibilidad frente a las fuentes, no frente a la demostración
La factibilidad reside en las fuentes. ¿El sistema contable expone la orden de compra mediante una interfaz aprobada, o solo mediante una exportación nocturna? ¿Existe el recibo en algún sistema, o solo en una fotografía adjunta a un correo electrónico? La frecuencia de actualización sigue lo que una fuente realmente ofrece.
Aquí también se decide construir versus adquirir. Si la plataforma existente ya realiza el cotejo a tres vías y simplemente no está configurada, la recomendación correcta es configuración, no construcción.
Defina la revisión antes de definir la automatización
Decida qué puede hacer el sistema por sí solo y qué debe entregar a una persona. En el ejemplo de las facturas, un cotejo limpio a tres vías dentro de la tolerancia puede enviarse automáticamente a aprobación. Una variación de precio por encima del umbral no puede. El pago nunca se libera de forma autónoma.
Las rutas de revisión deben quedar por escrito como parte de los criterios de aceptación, junto con el comportamiento de abstención: qué hace el sistema cuando no tiene la confianza suficiente para responder.
Establezca la puerta de expansión con anticipación
Antes de que el primer flujo de trabajo entre en operación, acuerde qué resultado justificaría expandirlo, qué justificaría cambiarlo y qué justificaría retirarlo. Escribir esto con antelación evita un desenlace conocido, en el que un piloto se considera exitoso solo porque fue costoso.
Un flujo de trabajo, un responsable, una línea base, una puerta. Esa secuencia no es glamorosa, y es la diferencia entre un sistema que pasa a formar parte de la operación y uno que se convierte en una demostración que nadie vuelve a abrir.