Cómo documentar un proceso antes de automatizarlo
Qué le pasó de verdad al documento de un proceso SAP entre el kick-off y el desarrollo, y qué conviene capturar para que el robot no se construya dos veces.
Al kick-off de un proyecto de creación masiva de materiales en SAP llegamos con el proceso escrito en siete pasos. No lo improvisamos: veníamos de ver los videos del proceso grabados por el cliente, y lo pusimos en la pantalla para que el jefe de área y el analista que ejecuta la tarea lo validaran. El paso 3 decía esto:
Jerarquía SAP: buscar un repuesto de la misma marca para copiar el código de jerarquía (8 dígitos).
Una línea. Todos asintieron. Doce semanas después ese paso es el módulo más complejo del robot, y del número "8 dígitos" no quedó nada: en la primera sesión de discovery apareció como un código de 18 caracteres, en la segunda como uno de 9. Tres largos distintos para el mismo campo, reportados por la misma gente, con dos semanas de diferencia.
Ese es el tema de este artículo. No las secciones que debe tener un documento de proceso, que están en cualquier plantilla, sino qué es lo que se rompe cuando lo escribes y cómo aprovecharlo antes de que se convierta en horas de desarrollo.
Aclaración: el cliente es una empresa chilena de arriendo y gestión de flota de vehículos. No la nombro porque el bot todavía está en desarrollo y el caso completo se publica cuando esté en producción. Los datos del proceso son los reales.
Los campos que "todos saben" son los que nadie sabe
La jerarquía de producto no era un campo exótico. Es un dato que el analista carga todos los días, varias veces por día, desde hace años. Por eso nadie lo cuestionó en el kick-off, y por eso mismo nadie lo había mirado nunca con atención: cuando una persona hace algo a mano, copia y pega el código sin contar los caracteres. El largo del campo simplemente no es información que necesite para trabajar.
Un robot sí la necesita. Y la única manera de conseguirla fue ir a mirar la tabla de SAP directamente, en lugar de seguir preguntando.
De ahí sale la primera regla práctica que aplicamos ahora en todo relevamiento: cuando un dato aparece descrito de tres formas distintas en tres fuentes, deja de preguntar y ve a mirar el sistema. La documentación se cierra contra el sistema, no contra el consenso de la reunión. Y si el acceso al sistema todavía no está habilitado, ese campo queda marcado como pendiente explícito en el documento, no resuelto con el promedio de las tres versiones.
"Se cargan tres repuestos" son 285 registros
El paso 5 del flujo original mencionaba, casi al pasar, que el analista pega los datos en una base de datos intermedia, aprieta un botón de actualizar y de ahí sale el archivo de carga. Con tres repuestos de ejemplo, ese paso devolvía 285 registros.
La multiplicación estaba en un lugar que nadie describe porque no es un paso, es una consecuencia: cada material hay que crearlo en unos 20 centros y extenderlo a unos 70 almacenes. El analista no piensa en eso, aprieta un botón. Para el robot es la diferencia entre escribir un archivo y escribir dos, con dos objetos de carga distintos que corren en secuencia.
Cuando un proceso tiene un paso donde alguien aprieta un botón y sale algo más grande de lo que entró, ahí hay un multiplicador que hay que documentar con número: cuántas filas entran, cuántas salen, y de qué depende esa expansión. Es el dato que más cambia el diseño técnico y el que más veces vi omitido, incluso en documentos de proceso hechos con cuidado.
Un documento sin contradicciones es un documento que nadie leyó
Después de la segunda sesión, la especificación quedó con una sección incómoda al final: seis contradicciones contra las fuentes anteriores. El tipo de material aparecía como un valor que en realidad era el código de un centro. El programa de carga figuraba con dos nombres distintos según el acta. La clase de valoración tenía un valor fijo en un documento y tres valores posibles en otro.
El relevamiento estaba haciendo su trabajo justamente ahí. Cada una de esas seis líneas es una pregunta que se resolvió con el cliente en diez minutos, y cada una de ellas, sin escribir, habría sido un error en producción con SAP rechazando una carga de 2.000 registros y alguien revisando línea por línea qué pasó.
Por eso pido que la sección de contradicciones exista formalmente en el documento y sobreviva a la revisión. Hay una tendencia natural, sobre todo cuando el documento va a firma, a entregar una versión pulida donde todo cierra. Un documento donde todo cierra en la primera vuelta es casi siempre un documento donde nadie contrastó las fuentes. Prefiero entregar uno con seis cosas marcadas en rojo y resolverlas en una reunión.
Lo que se documenta mal siempre: la pantalla
Hay una categoría de detalle que no entra en ninguna plantilla de relevamiento y que define si el robot funciona. Son las cosas que solo existen mientras alguien ejecuta el proceso frente a un sistema real.
En este caso concreto, tres ejemplos de lo que hubo que escribir:
- El paso final de la carga masiva tiene un parámetro que hay que fijar a mano en cada corrida. Si ese número no es mayor a la cantidad de registros leídos, la carga se corta a la mitad. Con 2.090 registros hay que poner 9.999. Ningún manual dice esto, y el analista lo hace de memoria.
- Antes de que la carga arranque aparecen tres ventanas emergentes distintas que hay que confirmar, una de ellas advirtiendo que se está trabajando en tiempo real.
- El resultado se lee por color. Verde pasó, rojo falló, y para saber por qué falló hay que hacer doble clic sobre la línea roja.
Nada de esto sale preguntando "¿cómo es el proceso?". Sale de sentarse al lado, grabar la pantalla y transcribir. La grabación es insumo obligatorio para nosotros, pero no reemplaza al documento: dentro de dos años nadie va a mirar cuarenta minutos de video para entender por qué el robot pone 9.999 en un campo.
Documentar también significa decidir dónde el robot no decide
Este proceso tiene una pausa. Después de armar la planilla y antes de ejecutar la carga en SAP, el robot se detiene y espera la revisión del analista responsable. Fue una decisión que tomamos en el kick-off, con el cliente, y quedó escrita como parte del flujo.
Hace falta decirlo porque la documentación tiende a describir un proceso ideal de punta a punta, y después el robot se construye igual de largo. Marcar en el documento cuáles son los puntos donde una persona valida, quién es esa persona y qué pasa si no valida a tiempo es tan importante como los pasos automáticos. En este proyecto, además, hay un criterio de filtro que se define en el mismo lugar: solo un tipo de material entra a la carga masiva, y todo lo demás (neumáticos, lubricantes, insumos) sale del flujo del robot y sigue el camino manual de siempre.
Ese filtro reduce el alcance del robot. También es lo que lo hace entregable en el plazo comprometido, y es una conversación que conviene tener durante el relevamiento y no durante el desarrollo.
Cómo lo hacemos hoy
El formato que nos quedó después de varios proyectos es simple y no requiere una plantilla corporativa: dos sesiones de relevamiento separadas por unos días, con grabación de pantalla, y entre una y otra el desarrollador escribe la especificación y aparecen las contradicciones. La segunda sesión existe para resolverlas. El documento se cierra recién después de esa segunda vuelta, y aun así se marca lo que quedó abierto en vez de inventar un valor.
Lo que buscamos con esto no es un entregable bonito. Es que el desarrollo empiece con las preguntas caras ya hechas. Cada campo mal documentado se paga con una vuelta completa de desarrollo, prueba y corrección, y el proceso que estoy contando tiene más de veinte campos con reglas propias. Si tu proceso vive sobre SAP, cubrimos qué se puede automatizar en qué procesos de SAP se pueden automatizar con RPA.
