Buscaste en internet "requisitos para elegir un ERP" y bajaste una plantilla con 240 líneas. La abriste, leíste veinte y la cerraste.
Le mandaste esa misma lista a tres proveedores. Los tres contestaron que cumplen con todo. Y ahora estás exactamente donde empezaste, pero con tres cotizaciones que no podés comparar.
Una lista larga no te protege. Te desarma. Cuando todo es requisito, nada lo es, y gana el que mejor sabe decir que sí.
Lo corto
Escribí requisitos como situaciones, no como funciones. "Vender en dos monedas" no dice nada; el caso completo sí.
Máximo 25 requisitos. Si te salen 200, no priorizaste.
Clasificá en tres grupos: obligatorio, valioso y opcional. Y sé duro con el primero.
Incluí las excepciones. Ahí es donde los sistemas se rompen, no en el flujo normal.
Cada requisito se prueba con una demostración, no con un "sí, se puede".
Escribí situaciones, no funciones
Un requisito escrito como función es imposible de verificar. Uno escrito como situación se prueba en dos minutos.
Comparalo:
Función: "Manejo de créditos".
Situación: "Un cliente lleva C$ 8,000.00 en mercadería, abona C$ 3,000.00 hoy y el resto en dos pagos. Necesito ver el saldo, registrar cada abono y que el sistema no lo deje comprar si pasa su límite de crédito."
Con la primera, cualquier proveedor dice que sí. Con la segunda, tiene que enseñártelo funcionando.
Cada situación debería contestar: quién lo hace, qué pasa, qué tiene que resultar y qué no debería poder pasar.
Sacá los requisitos de tu operación, no de una plantilla
La forma de llegar a 25 requisitos que sí importan es recorrer tu propio proceso, no descargar la lista de otro.
Seguí una venta completa de principio a fin y anotá cada momento en que el sistema tendría que hacer algo.
Repetilo con una compra, desde el pedido al proveedor hasta que la mercadería queda en estante.
Repetilo con una devolución y con un cierre de caja.
Anotá las cinco situaciones raras que más te complican hoy.
Agrupá y quedate con lo esencial. Muchos requisitos se repiten con otro nombre.
De ahí salen entre 20 y 30 requisitos reales. Y son tuyos, no de una empresa de otro país con otro modelo de negocio.
Tres grupos, y el primero tiene que doler
Obligatorio. Sin esto no puedo operar. Si un sistema no lo tiene, queda descartado hoy mismo.
Valioso. Me ahorra trabajo real, pero puedo vivir sin ello unos meses.
Opcional. Estaría bueno. No influye en la decisión.
La prueba para saber si tu lista de obligatorios está bien: si tenés más de 10, no son obligatorios. Volvé a pasarla y preguntate en cada línea si de verdad cerrarías el negocio sin eso.
Ejemplo de obligatorio real para una llantera: "Registrar el número de serie en la venta, porque sin eso el proveedor no me reconoce garantías". Ejemplo de falso obligatorio: "Que el reporte se pueda exportar a PDF con el logo".
Las excepciones son la mitad del requisito
Los sistemas se ven perfectos en el camino normal. Se rompen en lo raro. Escribí explícitamente:
¿Qué pasa si no hay internet? ¿Se puede seguir vendiendo y sincronizar después?
¿Qué pasa si el precio está mal cargado? ¿Quién puede corregir y queda registrado?
¿Qué pasa si el cliente devuelve la mitad de una factura?
¿Qué pasa si el mismo producto entró con dos códigos?
¿Qué pasa si alguien anula una venta ya cobrada?
Estas cinco preguntas suelen separar más a los proveedores que las otras veinte juntas.
Cada requisito se demuestra, no se declara
Al mandar la lista, agregá una condición: cada requisito obligatorio se tiene que mostrar funcionando en una demostración con datos tuyos.
Y anotá la respuesta en tres estados, sin punto medio:
Lo hace hoy, y lo vi funcionando.
Se configura, con costo y tiempo estimado por escrito.
No lo hace o depende de un desarrollo futuro.
Si una función depende de algo que "va a salir en la próxima versión", tratala como que no existe. Si el proveedor insiste, pedí fecha en el contrato y qué pasa si no llega.
Cómo saber si te está funcionando
Tu lista cabe en dos páginas y la entendés completa.
Dos proveedores distintos contestan cosas distintas. Si todos dicen que sí a todo, tus requisitos son muy vagos.
Podés descartar un sistema en la primera reunión, con razón escrita.
La lista te sirve después como base del contrato y de las pruebas.
Errores comunes
Bajar una plantilla genérica. Describe un negocio que no es el tuyo.
Marcar todo como obligatorio. Es lo mismo que no priorizar.
Escribir funciones sueltas. "Control de inventario" no se puede verificar.
Olvidar las excepciones. Es donde vas a sufrir a los tres meses.
No involucrar a quien usa el sistema. El dueño conoce el negocio; el de mostrador conoce los casos raros.
Empezá esta semana
Seguí una venta completa en tu negocio y anotá cada punto donde el sistema tendría que responder. Con eso solo vas a tener entre 8 y 12 requisitos reales, escritos como situaciones.
Si preferís saltarte este trabajo porque lo tuyo es un local de mostrador con necesidades bastante estándar, Tienda en Control ya viene con el alcance definido por escrito: qué incluye, qué no y qué tenés que entregar.
