Arquitectura de automatización de compras

¿Qué significa realmente automatizar el área de compras?

"La automatización de compras" abarca diversos enfoques, desde la automatización de flujos de trabajo basada en reglas que enruta una solicitud a través de una cadena de aprobación fija, hasta la automatización robótica de procesos (RPA) que opera las pantallas existentes tal como lo haría una persona, pasando por la automatización inteligente que incorpora comprensión de documentos o lógica de coincidencia. La investigación evaluada por pares describe a la RPA como el uso de programas de software de código bajo para automatizar procesos comerciales rutinarios y repetitivos, y la califica como la tecnología de más rápido crecimiento en la categoría de software empresarial. Ninguno de estos enfoques reemplaza el proceso de procure-to-pay; se integran en él y cada uno asume un paso específico y bien definido, razón por la cual la pregunta útil es cuáles pasos en este arquitectura de procure-to-pay son lo suficientemente rutinarios como para delegarlos en el software y cuáles todavía requieren el juicio humano.

¿Qué pasos del flujo de trabajo se automatizan primero y por qué?

Cuatro pasos aparecen repetidamente como candidatos tempranos para la automatización, debido a que cada uno maneja un gran volumen, se rige por reglas y tiene un resultado claro de éxito o fallo: el enrutamiento y aprobación de requisiciones, la concordancia de tres vías entre la orden de compra, el recibo y la factura, la emisión de la orden de compra una vez que se aprueba la requisición, y la gestión de excepciones de facturas para las discrepancias que señala la concordancia de tres vías. La evaluación comparativa actual de compras muestra que la automatización mejora la capacidad de aprovechar los descuentos por volumen, consolidar las compras y reducir los costos y errores derivados de las tareas manuales, lo cual ocurre al tratar estos pasos como el punto de partida en lugar de toda la ambición. El mismo trabajo de evaluación comparativa añade una condición que vale la pena tomarse en serio: la estandarización de procesos ayuda a garantizar que el impulso por la velocidad no resulte en un aumento de los errores, por lo que automatizar un flujo de trabajo de órdenes de compra lo que aún no está estandarizado solo acelera la inconsistencia, porque la estandarización debe ocurrir primero o en paralelo con el desarrollo.

¿Qué controles debe preservar la ruta automatizada?

Dos principios de control se trasladan sin cambios desde las compras manuales, y un flujo de trabajo automatizado debe expresarlos en software en lugar de asumir que sobreviven a la migración. El primero es la separación de funciones: las directrices de control federal autorizadas la definen como dividir las funciones y responsabilidades clave entre distintas personas para reducir el riesgo de error, uso indebido o fraude, separando las responsabilidades de autorización de transacciones, su procesamiento y registro, la revisión de las transacciones y el manejo de cualquier activo relacionado, de modo que ninguna persona controle todos los aspectos clave de una transacción o evento. El segundo es la autorización: las transacciones son autorizadas y ejecutadas únicamente por personas que actúan dentro del ámbito de su autoridad. En un proceso manual, esto se manifiesta como personas diferentes que intervienen en una orden de compra en escritorios separados. En uno automatizado, debe reflejarse como un modelo de roles, una configuración de umbrales de aprobación y un mapa de permisos que un bot o un motor de flujo de trabajo no pueda eludir silenciosamente solo porque técnicamente tenga la capacidad de escribir en todos los campos a los que puede acceder.

¿Cómo se planifica una implementación en la que la gobernanza sea lo primero?

¿Dónde fallan realmente las integraciones de ERP heredadas y de dónde provienen los silos de datos?

El punto en el que una plataforma de automatización de adquisiciones se conecta con el ERP es donde se concentra en la práctica el riesgo de gobernanza, y también es donde se crea un silo de datos si la automatización mantiene su propia copia separada de los datos de proveedores, presupuestos o aprobaciones en lugar de tratar al ERP como la única fuente de datos maestra. La guía de integración de un proveedor de automatización señala claramente el riesgo de acceso: un conector al que se le otorga un acceso más amplio del que requiere su función puede leer datos que nunca debería ver y escribir en campos que jamás debería tocar. Por lo general, se concede un acceso amplio por comodidad durante la configuración, no porque el flujo de trabajo lo necesite, y vale la pena tratarlo como un elemento de verificación proporcionado por el proveedor para realizar pruebas en lugar de una afirmación sobre el producto propio de cualquier proveedor en particular. La misma guía señala un segundo modo de fallo más silencioso: una pista de auditoría que cubre las acciones humanas pero deja sin registrar las decisiones automatizadas está incompleta y generará hallazgos en cualquier auditoría rigurosa. Si un bot aprueba una factura, esa decisión necesita el mismo registro que requeriría la aprobación de una persona: qué lógica se aplicó, qué datos utilizó y cuál fue el resultado.

¿Por qué la automatización sin verificar cuesta más de lo que ahorra?

La tentación es tratar la automatización como un problema de despliegue: configurar la herramienta, aplicarla al proceso y lanzarla. La investigación fundamental sobre verificación de flujos de trabajo advierte en contra de omitir el paso intermedio. Al estudiar los sistemas de gestión de flujos de trabajo en general, los investigadores descubrieron que las consecuencias, sin embargo, son que pocos flujos de trabajo se revisan a fondo antes de implementarse en la práctica, lo que a menudo resulta en que los errores deban corregirse de manera improvisada y, con frecuencia, a costos prohibitivos. Este hallazgo es dos décadas anterior a las plataformas actuales de automatización de código bajo, y el problema subyacente no ha desaparecido: la especificación de un flujo de trabajo es una pieza lógica, y la lógica que no se ha comprobado en cuanto a las opciones, secuencias y excepciones que realmente necesita gestionar falla de la misma manera, ya sea que una persona o un bot la ejecute, solo que el bot falla más rápido y a mayor volumen. Los lenguajes de especificación de flujos de trabajo deben admitir la especificación de momentos de elección, ejecución secuencial, paralelismo, sincronización e iteración precisamente porque los procesos reales necesitan todo eso, y un piloto que solo ejercita el recorrido ideal (happy path) no ha verificado en absoluto el flujo de trabajo.