Next WrldLa escena se repite seguido. Una empresa pide una reunión para cotizar un software, se sientan dos o tres personas, y la primera hora se va en explicar lo básico.
¿Quién pide qué, por dónde? ¿Dónde queda registrado? ¿Quién aprueba y quién se entera tarde? Nadie llevó esos datos ordenados, así que todo avanza a base de “más o menos funciona así”.
No es desinterés. Es que nadie les dijo qué llevar. Y lo que se entiende ahí determina el alcance, los tiempos y la seriedad de la cotización.
Prepararse no exige saber de tecnología. Exige contar bien el trabajo.
Contar el proceso tal como ocurre hoy
Lo primero es contar el proceso paso a paso, sin mejorarlo de memoria.
¿Quién inicia el pedido? ¿Quién revisa, decide, ejecuta y verifica? ¿Qué pasa cuando algo se traba?
Ayuda seguir un caso real de principio a fin. Nada de “en general hacemos”. Mejor: “la semana pasada pasó esto, y estos fueron los pasos”.
Eso muestra reglas, personas, decisiones y coordinación. La tecnología viene después, como consecuencia de ese circuito.
No hace falta tener todo perfecto ni documentado. La empresa de software ayuda a definir y ordenar. Lo que acelera todo es llegar con contexto honesto, no con respuestas cerradas.
Listar las herramientas y qué vive en cada una
Lo segundo es listar qué usan hoy y qué información vive en cada lugar.
¿Dónde se arma el pedido? ¿Dónde queda la aprobación? ¿Qué parte vive en el correo, cuál en el chat, cuál en el sistema contable?
Alcanza con una lista simple: herramienta, para qué la usan, quién la usa y qué deja sin resolver.
Ese mapa muestra dónde se duplica la carga, dónde se pierde visibilidad y dónde aparecen errores y retrabajo. Muchas veces el problema no es la falta de un sistema nuevo, sino información repartida en lugares que no conversan.
Tal vez la respuesta sea un software a medida, tal vez sea ordenar lo que existe, integrar dos herramientas o cambiar una regla interna. El criterio es uno: la menor complejidad necesaria para resolver correctamente el problema.
Definir qué quieres que cambie y cómo lo vas a notar
Lo tercero es el objetivo, dicho en términos de operación.
¿Qué debería funcionar distinto en unos meses para que el proyecto haya valido la pena? ¿Menos errores? ¿Decisiones más rápidas? ¿Menos seguimiento manual? ¿Menos compras duplicadas?
Conviene pensar cómo lo vas a notar con lo que tienes hoy: cuántas consultas de seguimiento llegan, cuánto tarda una aprobación, cuántas veces hay que pedir el mismo dato.
Si esto funcionara bien, ¿qué dejaríamos de hacer a mano? ¿Qué dejaría de depender de la memoria de una persona?
Ordenar prioridades y contar los casos borde
Todo proceso tiene su camino habitual y sus excepciones. Y suelen ser las excepciones las que definen si un software sirve.
Por eso conviene ordenar prioridades: qué es crítico, qué puede esperar, qué sería deseable alguna vez. Decirlo al inicio evita cotizar de más cuando lo urgente es una parte pequeña.
Y contar los casos borde con sinceridad: la compra urgente sin aprobación previa, el proveedor que cambia el precio a último momento, la entrega parcial, la factura que llega antes que la mercadería.
¿Cada cuánto pasan? ¿Cómo se resuelven hoy? ¿Quién puede saltear el camino normal?
Esconder estos casos sale caro. Lo que no se dice en la primera reunión aparece igual más tarde, cuando cambiarlo cuesta más.
Qué llevar físicamente a la reunión
Lo último es llevar material real.
La planilla que de verdad usan, no una versión prolija hecha para la ocasión. Un ejemplo de pedido, una aprobación típica, una factura con un error común.
También importan las personas. Quien opera el proceso todos los días tiene información que no está en ningún manual.
Y vale llevar preguntas de negocio, no de tecnología: ¿qué conviene resolver primero? ¿Qué parte conviene no tocar todavía?
Compras a proveedores: la misma reunión, dos versiones
Veamos todo en un proceso común: compras a proveedores, con su circuito de necesidad, pedido, aprobación, compra, recepción y pago.
El problema es el mismo: nadie sabe el estado de cada compra, las aprobaciones se pierden y cada tanto se duplica un pedido o se paga algo incompleto.
Primera versión: sin preparación
Asisten el responsable general y alguien de administración, pero no quien hace los pedidos a diario.
“Necesitamos un sistema de compras”, dicen. Cada área pide a su manera: algunos por correo, otros por mensaje. A veces aprueba una persona, a veces otra, según el monto.
No saben dónde queda registrado cada estado. “Creo que hay una planilla”, dice uno. Nadie la llevó.
La empresa de software tiene que suponer demasiado. La cotización será amplia, con supuestos y márgenes para cubrir lo desconocido. Y hará falta otra reunión solo para entender lo básico.
Segunda versión: con contexto
Asiste quien opera las compras. Y cuenta un caso real.
“El taller avisó faltantes por chat. Armé el pedido en la planilla. Lo pasé por correo al responsable. Como superaba el monto habitual, también aprobó dirección. Emití la orden y la envié al proveedor. Al recibir, controlamos contra el remito. Si estaba completa, pasamos la factura a administración para el pago”.
Llevan las herramientas listadas: planilla para el pedido, chat para lo urgente, correo para aprobaciones, sistema contable para el pago. Y lo dicen claro: la aprobación no queda en un solo lugar, y la recepción se controla en papel.
Definen el objetivo: saber el estado de cada compra sin preguntar por chat, evitar duplicados y detectar recepciones incompletas antes de pagar. Y cómo notarlo: menos seguimiento y menos pagos observados.
Ordenan prioridades: primero, visibilidad del estado; después, aprobación clara por monto; más adelante, historial por proveedor. Y cuentan los bordes: la compra urgente por teléfono que se registra después, la entrega parcial, el cambio de precio entre pedido y factura.
Con ese contexto, la empresa pregunta bien desde el primer día. La cotización deja de ser un cálculo a ciegas.
La diferencia es de contexto.
Una lista breve para llegar preparado
En una hoja, la preparación se resume así:
- Proceso contado paso a paso, con un caso real.
- Herramientas listadas, con qué vive en cada una.
- Objetivo como cambio en la operación, y cómo lo vas a notar.
- Prioridades ordenadas: qué es crítico y qué puede esperar.
- Casos borde contados con sinceridad.
- Material real y las personas que operan el proceso en la mesa.
Es sentido práctico. Y no exige tener todo resuelto: exige mostrar la realidad para pensar juntos la respuesta más simple que funcione.
Tres errores que frenan cualquier cotización
El primero es pedir “un sistema” sin contar el proceso. Sin circuito, personas ni reglas, solo se puede cotizar una idea genérica. Y lo genérico se paga caro cuando choca con la realidad.
El segundo es esconder la planilla real. Ese archivo que sostiene la operación muestra qué datos importan y dónde se rompe el control. Mostrarlo habla de honestidad, no de desorden.
El tercero es llevar a quien no opera el proceso. Si solo asisten quienes deciden, se habla de cómo debería funcionar, no de cómo funciona. Y el software termina diseñado sobre un deber ser que no coincide con el día a día.
Contexto claro, cotización seria
Pedir una cotización no es pedir precio por un producto. Es invitar a otra empresa a entender cómo trabajas para proponerte la forma más simple de mejorarlo.
Quien cuenta bien su operación recibe mejores preguntas. Quien define qué quiere que cambie puede decidir con criterio si conviene construir, ordenar, integrar o esperar.
La regla es sencilla: contexto claro, cotización seria.