Casi siempre la pregunta llega planteada como si fuera técnica: si la inteligencia artificial ya puede hacer esto o lo otro. Casi siempre la respuesta es que sí puede, y aun así el proyecto sale mal. Lo que decide el resultado es el proceso que se va a automatizar, más que la herramienta con la que se automatiza. Un software fija por escrito cómo funciona algo; si ese algo cambia cada semana, o si dos áreas no se ponen de acuerdo en cómo debería ser, lo que queda escrito es la confusión.
Las cinco condiciones
Cuando un proceso cumple las cinco, automatizarlo suele salir bien y el precio se sostiene. Cuando falla una, el proyecto se alarga. Cuando fallan dos, conviene esperar.
- Ocurre seguido y ocurre igual. Una tarea mensual con reglas estables se automatiza; una que aparece tres veces al año y nunca del mismo modo, no.
- Alguien la puede explicar completa. Si nadie en la empresa la puede contar de principio a fin en una sola sentada, todavía no existe el documento de alcance que habría que escribir.
- La información ya está en algún lado. Una hoja de cálculo sirve. Un cuaderno sirve. Lo que no sirve es que el dato viva solo en la cabeza de una persona: entonces el primer proyecto es capturarlo.
- Hay alguien responsable que lo va a usar. Un sistema sin dueño se abandona en el segundo mes, por bueno que sea.
- El volumen justifica el gasto. Veinte minutos a la semana no pagan un proyecto. Ocho horas a la semana, casi siempre sí.
Las señales de que todavía no
| Señal | Qué está pasando | Qué conviene hacer |
|---|---|---|
| El proceso cambia cada mes | La operación todavía se está definiendo | Esperar a que se estabilice, o automatizar solo la parte que ya no cambia |
| Dos áreas lo describen distinto | No hay un acuerdo, hay dos procesos | Cerrar el acuerdo primero. Un sistema no arbitra: congela lo que encuentra |
| El cuello de botella es una decisión | Falta que alguien decida, no que alguien capture | Cambiar quién decide y con qué información, antes de comprar software |
| El dato de entrada llega mal | Se automatizaría el error, más rápido | Arreglar la captura en el origen |
| Nadie tiene tiempo para el proyecto | No hay quién responda dudas durante el desarrollo | Posponerlo. Un proyecto sin interlocutor se entrega tarde y distinto |
Cómo medirlo con tus propios números
Esta cuenta cabe en una hoja de cálculo y no necesita a nadie de fuera. Cuenta cuántas veces al mes ocurre el proceso, cuánto tiempo toma cada vez y quién lo hace. Multiplica y tendrás las horas al mes que ocupa hoy. Ese número, junto al costo de esa hora en tu empresa, es lo que hay que comparar contra el rango de inversión del proyecto.
Es aritmética sobre lo que ya sabes, no una proyección. Cualquier proveedor que te presente una cifra de beneficio antes de conocer tu operación está adivinando, y esa cifra está puesta ahí para que firmes.
Si la cuenta no cierra con las horas que el proceso ocupa hoy, tampoco va a cerrar con las que ocupe después. Ese es el momento de decir que todavía no.
Qué hacer mientras tanto
Documentar. Durante dos o tres semanas, que la persona que ejecuta el proceso anote cada vez que lo hace: qué recibió, qué decidió y qué entregó. Al final vas a tener dos cosas que hoy no tienes. La primera es el proceso real escrito, que casi nunca es el que se cree que es. La segunda es el volumen medido en vez de estimado.
Con eso en la mano, la conversación con cualquier proveedor cambia de tono. Deja de ser una cotización sobre una descripción vaga y pasa a ser un alcance sobre un proceso conocido, que es lo único que permite comparar dos propuestas.
Y a veces el ejercicio de documentar resuelve el problema por sí solo, porque lo que estorbaba era un paso que nadie había mirado de frente en dos años. Ese resultado también cuenta.