Resources
Material to decide better.
Practical guides and articles for directors, operations managers and IT teams evaluating a software, integration or artificial intelligence project.
How to know whether your company needs custom software
Casi ninguna empresa llega a la conclusión de que necesita software propio de un día para otro. Llega después de meses de parches: un Excel que alguien mantiene a mano, un reporte que tarda tres días en armarse, un pedido que se capturó dos veces. La pregunta real no es si la tecnología puede ayudar, sino si lo que tienes enfrente es un problema de proceso o un problema de sistema.
Cuando Excel deja de ser suficiente
Excel es una herramienta extraordinaria y la mayoría de las operaciones deberían empezar ahí. El problema no es la hoja de cálculo: es el momento en que deja de ser una herramienta y se convierte en el sistema de la empresa.
Hay tres señales claras de ese cruce. La primera es que ya nadie sabe cuál es la versión buena del archivo. La segunda es que una sola persona entiende cómo funciona la fórmula que sostiene el reporte. La tercera es que el archivo dejó de servir para decidir y ahora sirve para justificar decisiones que ya se tomaron por otro lado.
Cuando aparecen las tres juntas, el costo ya no es la licencia de nada: es el tiempo de personas con sueldos altos reconstruyendo información que el sistema debería entregar solo.
Procesos demasiado particulares
La razón más honesta para construir software a la medida es que el proceso que te da ventaja no se parece al de nadie más. Una regla de precios que depende de volumen, zona y antigüedad del cliente. Un esquema de aprobaciones que cambia según el monto y el área. Una manera de calcular disponibilidad que combina inventario propio, material en tránsito y compromisos ya firmados.
Un sistema comercial estándar puede acomodar parte de eso con configuración. Cuando la respuesta del proveedor empieza a ser "eso se resuelve con un campo personalizado y un proceso manual", estás pagando una licencia para seguir operando a mano.
El criterio práctico: si el proceso es parte de lo que te distingue en el mercado, vale la pena construirlo bien. Si es un proceso que toda empresa hace igual —nómina, contabilidad, correo— casi siempre conviene comprarlo hecho.
Las señales operativas
Más allá de la intuición, hay síntomas que se pueden medir. Vale la pena ponerles número antes de tomar cualquier decisión.
- Doble captura. La misma información se teclea en dos lugares. Cuenta cuántas veces al día pasa y cuántos minutos toma cada vez.
- Información dispersa. Para responder una pregunta de negocio hay que abrir tres sistemas y un archivo. Cronometra cuánto tarda responderla.
- Errores manuales. Un precio mal puesto, un pedido duplicado, un pago mal aplicado. Registra cuántos ocurrieron el último trimestre y qué costaron.
- Sistemas que no se hablan. El ERP no sabe lo que sabe el CRM, y alguien hace de puente con un archivo exportado.
- Reportes armados a mano. Alguien dedica horas fijas cada semana a copiar, pegar y cuadrar.
- La operación creció y el proceso no. Lo que funcionaba con 30 pedidos al día se rompe con 300.
Estos números son la base de cualquier conversación seria sobre presupuesto. Sin ellos, cualquier inversión en tecnología es un acto de fe.
Cuándo NO necesitas software a la medida
Esta parte se dice poco y es la que más dinero ahorra.
No necesitas desarrollo propio cuando el problema real es que el proceso nunca se definió. Automatizar un proceso confuso produce un sistema confuso, más caro y más difícil de cambiar. Tampoco cuando el sistema que ya tienes cubre la necesidad pero nadie lo configuró bien ni capacitó al equipo; ahí el proyecto es de adopción, no de desarrollo.
Y no lo necesitas cuando lo que buscas es una función que el mercado ya resolvió mil veces. Facturación electrónica, firma de documentos, videollamadas, correo. Construir eso desde cero es pagar por reinventar algo que puedes rentar por una fracción.
SaaS, a la medida, o los dos
La decisión rara vez es binaria. La combinación que mejor funciona en empresas medianas suele ser: sistemas comerciales para lo estándar, desarrollo propio para lo que te distingue, e integraciones que los mantengan sincronizados.
| Criterio | Sistema comercial | Software a la medida |
|---|---|---|
| Tiempo al primer uso | Semanas | Meses |
| Costo inicial | Bajo | Alto |
| Costo a cinco años | Crece con usuarios | Estable, más mantenimiento |
| Ajuste al proceso | El proceso se adapta al sistema | El sistema se adapta al proceso |
| Dependencia | Del proveedor y su roadmap | De quien mantiene el código |
| Mejor para | Procesos estándar | Procesos que dan ventaja |
Cómo evaluar el retorno sin inventar cifras
El cálculo útil no es "cuánto vamos a crecer". Es "cuánto nos cuesta hoy hacerlo como lo hacemos". Suma tres cosas medibles:
- Horas. Personas × horas semanales dedicadas a tareas que el sistema haría solo, por su costo por hora.
- Errores. Costo directo de los errores del último año: notas de crédito, reenvíos, penalizaciones, descuentos de disculpa.
- Decisiones tardías. Qué cuesta enterarte de algo tres días después en lugar de el mismo día. Este es más difícil de estimar, pero en operación y cobranza suele ser el más grande.
Compara ese total anual contra el costo del proyecto más su mantenimiento. Si el número no cierra en menos de dos o tres años, probablemente el proyecto es más chico de lo que estás imaginando, o el problema no es de software.
Antes de pensar en tecnología, documenta el proceso que quieres mejorar. Un proceso escrito —quién hace qué, con qué información, bajo qué reglas y con qué excepciones— vale más que cualquier cotización. Con ese documento cualquier proveedor serio puede decirte si necesitas desarrollo, configuración, integración o simplemente orden. Sin él, todos te van a cotizar cosas distintas y ninguna comparación va a ser real.
Where to start with artificial intelligence in a company
La mayoría de los proyectos de inteligencia artificial que fracasan en empresas medianas no fracasan por la tecnología. Fracasan porque empezaron por la frase "queremos IA" en lugar de por un proceso concreto que alguien sufre todos los días. Este marco sirve para invertir ese orden.
El error de empezar por la tecnología
Cuando la conversación arranca en la herramienta, el proyecto se vuelve una búsqueda de excusas para usarla. Se termina con un asistente que contesta preguntas que nadie hacía, o con un piloto impecable que nadie integró a la operación.
La pregunta correcta no es "¿dónde podemos usar IA?". Es "¿qué trabajo repetitivo, lento o propenso a errores nos está costando dinero?". Una vez que tienes esa lista, la tecnología se elige sola: a veces es IA, a veces es una automatización tradicional y a veces es cambiar una regla del proceso.
Los cinco filtros de un buen candidato
Toma cualquier proceso de tu operación y pásalo por estos cinco filtros. Los que aprueban los cinco son por donde conviene empezar.
- Repetición. ¿Alguien hace esto muchas veces, de forma parecida? Lo que pasa una vez al mes no justifica el esfuerzo.
- Volumen. ¿Cuántas veces al día o a la semana ocurre? El volumen es lo que convierte minutos ahorrados en dinero.
- Datos disponibles. ¿La información que el proceso necesita ya existe en algún sistema, correo o archivo? Si hay que crearla desde cero, el proyecto es de datos antes que de IA.
- Riesgo. ¿Qué pasa si la máquina se equivoca? Un correo mal clasificado se corrige. Un pago mal aplicado, no tanto.
- Criterio humano. ¿Cuánto juicio, contexto o negociación exige? Mientras más, más debe quedarse la persona en el centro.
La matriz de decisión
Con los filtros anteriores, cada proceso cae en uno de tres lugares. Esta matriz es lo único que necesitas para ordenar una lista de veinte ideas en una tarde.
| Situación | Qué hacer | Ejemplo |
|---|---|---|
| Alto valor · bajo riesgo | Empezar aquí. Sin dudarlo. | Leer correos de solicitud y extraer los datos a un formato estructurado. |
| Alto valor · alto riesgo | Hacerlo, con supervisión humana obligatoria antes de ejecutar. | Preparar una cotización completa que un vendedor revisa y envía. |
| Bajo valor | No priorizar, aunque sea técnicamente atractivo. | Un asistente que responde preguntas generales sobre la empresa. |
La casilla de arriba a la izquierda es donde vive casi todo el retorno de los primeros seis meses. La tentación es siempre empezar por lo espectacular; el dinero está en lo aburrido.
Copilotos, agentes y automatización: qué es cada cosa
Los tres términos se usan como sinónimos y no lo son. La diferencia importa porque determina cuánta supervisión necesitas.
- Automatización tradicional. Reglas fijas: si pasa A, haz B. No interpreta, no improvisa. Es la opción correcta cuando el proceso está bien definido y no hay ambigüedad. Es más barata, más rápida y más predecible que cualquier IA.
- Copiloto. Asiste a una persona que sigue tomando la decisión. Redacta un borrador, resume un expediente, sugiere una respuesta. El riesgo es bajo porque siempre hay un humano antes del envío.
- Agente. Ejecuta una secuencia completa por su cuenta: consulta sistemas, aplica reglas, produce un resultado y lo deja registrado. Es lo más potente y lo que más disciplina exige, porque actúa sin que nadie mire cada paso.
Una regla práctica: si el proceso se puede describir completamente con reglas, no uses IA. La IA vale la pena cuando la entrada es desordenada —lenguaje natural, documentos, formatos inconsistentes— y hay que interpretarla antes de aplicar las reglas.
Cómo se diseña un piloto que sí sirve
Un piloto no es una demo. Es un experimento con criterio de éxito definido antes de empezar. Cuatro condiciones lo separan de un ejercicio decorativo:
- Un proceso, no un área. "Automatizar compras" no es un piloto. "Extraer los datos de las solicitudes que llegan por correo al buzón de ventas" sí lo es.
- Una métrica anterior. Mide el proceso como está hoy antes de tocar nada: tiempo promedio, volumen, errores. Sin línea base no hay forma de saber si funcionó.
- Un plazo corto. Seis a ocho semanas. Si necesita más, el alcance está mal recortado.
- Un dueño interno. Alguien de la operación, no de sistemas, responsable de que el resultado se use.
Qué medir después
Tres números bastan para decidir si el piloto escala o se cancela: tiempo del ciclo completo antes y después, porcentaje de casos que la máquina resolvió sin intervención, y errores que llegaron al cliente. Si el primero baja, el segundo sube y el tercero no empeora, el caso está hecho.
Conviene aceptar desde el principio que el porcentaje de casos resueltos sin intervención nunca llega a 100%, y que no tiene por qué llegar. Un proceso donde la máquina resuelve el 70% y escala el 30% restante a una persona ya cambió la economía del área.
Empieza por el proceso más aburrido de la lista. El que nadie quiere presentar en una junta, el que consume horas de gente capaz en trabajo mecánico. Ese es el que produce resultados medibles en semanas y el que le da credibilidad al siguiente proyecto, que ya podrá ser más ambicioso.
What to ask before contracting an integration project
Los proyectos de integración se cotizan por lo que se ve —conectar el sistema A con el sistema B— y se complican por lo que no se preguntó. Estas quince preguntas son las que distinguen una propuesta seria de una que va a necesitar tres alcances adicionales. Haz todas, aunque alguna parezca obvia.
Acceso y arquitectura
-
¿Los sistemas que vamos a conectar tienen API, o hay que trabajar sobre la base de datos?
Una API es un contrato: el proveedor se compromete a que funcione de cierta forma. Entrar directo a la base de datos de un sistema comercial suele violar su soporte y se rompe en cada actualización. Si no hay API, el proyecto es más caro y más frágil, y eso debe estar en la cotización desde el día uno.
-
¿Existe documentación de esa API y podemos verla antes de firmar?
"Sí tiene API" y "la API está documentada" son cosas distintas. Sin documentación, una parte del presupuesto se va en descubrir cómo funciona, y ese descubrimiento lo pagas tú.
-
¿Qué pasa cuando el proveedor del otro sistema cambie su versión?
Las APIs evolucionan. Pregunta si hay versionado, cuánto aviso previo dan y quién asume el costo de adaptarse. Es la diferencia entre un mantenimiento planeado y una urgencia.
-
¿La integración es en tiempo real o por lotes, y por qué?
Tiempo real cuesta más y falla distinto. Muchos procesos operan perfectamente con una sincronización cada quince minutos. Que la decisión sea explícita y justificada por el negocio, no por costumbre técnica.
Datos
-
¿De quién son los datos que van a pasar por la integración?
Debe quedar por escrito que los datos son de tu empresa, que puedes exportarlos completos en cualquier momento y en qué formato. Sin esa cláusula, cambiar de proveedor después es carísimo.
-
¿Cuál sistema manda cuando los dos tienen el mismo dato distinto?
Si el CRM dice que el cliente tiene crédito y el ERP dice que no, algo tiene que ganar. Esa regla se define en el proyecto, no cuando ocurra el primer conflicto.
-
¿Qué pasa con la información histórica?
¿Se migra, se deja donde está, se consulta desde el sistema nuevo? Es una de las tres cosas que más se subestiman en tiempo y presupuesto.
-
¿Dónde van a vivir físicamente los datos?
Importa para cumplimiento, para latencia y para tus propias políticas. Pregunta en qué país, en qué proveedor de nube y quién más tiene acceso.
Seguridad y operación
-
¿Cómo se autentica la integración y quién custodia las credenciales?
Las llaves de acceso no deben estar escritas dentro del código ni en un archivo compartido. Pregunta cómo se guardan, cada cuánto se rotan y qué pasa si se filtran.
-
¿Vamos a tener un ambiente de pruebas separado del de producción?
Sin ambiente de pruebas, cada cambio se prueba con datos reales de clientes reales. Es la causa número uno de incidentes evitables.
-
¿Qué pasa cuando un registro falla?
¿Se pierde, se reintenta, se encola, avisa a alguien? Una integración sin manejo explícito de errores funciona bien el primer mes y después empieza a perder información en silencio.
-
¿Hay bitácora de lo que pasó y quién puede consultarla?
Cuando el cliente reclama que su pedido no llegó al sistema, la única respuesta útil es poder mostrar qué se envió, cuándo y qué contestó el otro lado.
-
¿Cómo nos enteramos de que la integración se cayó?
La peor forma de enterarse es que un cliente lo diga. Debe haber monitoreo con alerta activa y un responsable que la reciba.
Continuidad
-
¿Qué incluye el soporte y con qué tiempos de respuesta?
Diferencia entre corregir un error del desarrollo —que debe ser gratuito— y atender un cambio que tú pediste. Pide tiempos de respuesta por severidad y horarios de cobertura.
-
Si mañana dejamos de trabajar con ustedes, ¿qué nos queda?
La respuesta correcta incluye código fuente, documentación, accesos y credenciales. Si la respuesta es vaga, la dependencia es el producto que te están vendiendo.
Una integración bien hecha se nota por lo que no pasa: nadie captura dos veces, nadie exporta archivos para cuadrar, y cuando algo falla alguien se entera antes que el cliente. Si las respuestas a estas quince preguntas son claras y están por escrito, ya eliminaste la mayor parte del riesgo del proyecto.
Automation with agents: what is actually worth automating
Un agente es software que recibe una entrada desordenada, consulta lo que necesita, aplica las reglas del negocio y produce un resultado, sin que una persona lo lleve de la mano paso por paso. La pregunta que importa no es si puede hacerlo, sino en qué tareas conviene que lo haga.
La diferencia con la automatización de siempre
La automatización tradicional sigue un camino fijo: si llega el archivo, procésalo; si el monto supera el límite, manda a aprobación. Es rápida, barata y predecible, y sigue siendo la mejor herramienta para la mayoría de los procesos de una empresa.
Su límite aparece cuando la entrada no viene ordenada. Un correo donde el cliente pide "lo mismo del mes pasado pero con veinte piezas más" no cabe en ninguna regla. Ahí es donde un agente aporta: interpreta lenguaje natural, entiende documentos con formatos distintos y decide qué hacer con la ambigüedad antes de aplicar las reglas.
El criterio es sencillo: si puedes escribir el proceso completo como una lista de condiciones, no necesitas un agente. Si la primera línea sería "leer lo que el cliente quiso decir", probablemente sí.
Los cuatro tipos de trabajo que un agente hace bien
- Leer y estructurar. Convertir correos, PDFs, mensajes o formatos inconsistentes en datos que los sistemas entienden. Es el caso con mejor retorno y el de menor riesgo, porque al final hay un registro que alguien puede revisar.
- Clasificar y enrutar. Decidir de qué se trata una entrada y a dónde va. Un error aquí se corrige moviendo el caso; el costo de equivocarse es bajo.
- Consultar y componer. Reunir información de varios sistemas para armar algo: una cotización preliminar, un resumen de cuenta, una respuesta con el estatus real de un pedido.
- Dar seguimiento. Vigilar que algo ocurra en el plazo esperado y actuar si no ocurre. Es trabajo que las personas hacen mal no por incapacidad, sino porque es imposible sostener la atención sobre cientos de casos abiertos.
Qué automatizar, qué supervisar y qué no tocar
Esta tabla resuelve la mayoría de las discusiones. La columna correcta depende de dos cosas: qué tan reversible es el error y cuánto criterio exige la decisión.
| Automatizar | Supervisar | No automatizar |
|---|---|---|
| Extraer datos de una solicitud por correo | Preparar la cotización completa | Aprobar un descuento fuera de política |
| Clasificar y enrutar mensajes entrantes | Responder una queja de un cliente importante | Negociar condiciones comerciales |
| Actualizar el estatus entre dos sistemas | Aplicar un pago con diferencia contra la factura | Decidir si se cancela a un cliente |
| Generar el borrador de un documento recurrente | Enviar ese documento al cliente | Contratar, evaluar o desvincular personas |
| Avisar que un pedido lleva tres días detenido | Reprogramar una entrega comprometida | Comprometer una fecha con penalización |
Nota el patrón de la columna del centro: casi siempre el agente hace el trabajo y la persona aprueba. Esa combinación conserva la velocidad y deja el juicio donde debe estar.
Dónde debe quedarse la persona
Hay tres territorios donde la intervención humana no es una limitación tecnológica, es una decisión de negocio.
El primero es la relación. Cuando el valor de la interacción está en que alguien entienda el contexto del cliente y ajuste en consecuencia, automatizarla destruye justamente lo que la hacía valiosa.
El segundo es la excepción cara. Los procesos tienen casos raros que representan poco volumen y mucho dinero. Automatizar el 5% más complejo suele costar más que el 95% restante y es donde los errores duelen.
El tercero es cualquier decisión que la empresa tendría que defender ante un cliente, una autoridad o un tribunal. Ahí la firma tiene que ser de una persona.
Cómo se pone en marcha sin sustos
La forma que mejor funciona es por etapas, y suele tomar unos tres meses por proceso:
- Sombra. El agente procesa todo pero no ejecuta nada; su resultado se compara con lo que hizo la persona. Sirve para medir precisión real antes de arriesgar.
- Aprobación. El agente propone y una persona confirma con un click. Se mide cuántas propuestas pasan sin cambios.
- Autonomía acotada. Ejecuta solo dentro de un rango definido —monto, tipo de caso, cliente conocido— y escala todo lo demás.
Muchas empresas se quedan cómodamente en la segunda etapa para siempre, y está bien. El ahorro grande ya ocurrió: el trabajo de preparar dejó de hacerlo una persona.
El mejor primer agente es el que le quita a alguien capaz un trabajo que no debería estar haciendo. No el más visible ni el más impresionante: el más repetido. Si al medirlo el tiempo de ciclo baja y los errores no suben, ya tienes el argumento para el siguiente.
Indicators a management team should be able to see every day
La mayoría de las direcciones no sufren por falta de información, sino por exceso de tableros que nadie abre. Un buen tablero ejecutivo cabe en una pantalla, se revisa en dos minutos y provoca una acción concreta cuando algo se sale de rango. Todo lo demás es reporte, y el reporte tiene otro lugar y otra frecuencia.
Menos indicadores, más confiables
Un indicador sirve solo si se cumplen tres condiciones al mismo tiempo: se actualiza solo, todos entienden igual cómo se calcula, y alguien sabe qué hacer cuando se pone en rojo. Si falta una de las tres, el número decora.
La segunda condición es la que más se ignora. "Ventas del mes" parece obvio hasta que resulta que comercial cuenta pedidos, finanzas cuenta facturas y dirección cuenta cobranza. La definición debe estar escrita al lado del número, no en la cabeza de quien armó el tablero.
Como referencia práctica: entre ocho y doce indicadores diarios es un tablero ejecutivo sano. Más de veinte significa que nadie decidió qué importa.
Diario, semanal o mensual
Antes de elegir indicadores, conviene separar por frecuencia. Un número va al tablero diario solo si cambia todos los días y si un día de retraso en enterarse tiene costo.
- Diario. Lo que se puede corregir hoy: pedidos detenidos, entregas comprometidas para hoy, incidencias abiertas, cobranza vencida.
- Semanal. Lo que necesita una tendencia para significar algo: avance contra meta, pipeline, productividad por área.
- Mensual. Lo que exige cierre contable o comparación estructural: margen real, rotación de inventario, costo por unidad.
Un tablero ejecutivo de ejemplo
Cuatro bloques, dos o tres números cada uno. Esta estructura funciona en empresas industriales, comerciales y de servicio; lo que cambia es el contenido, no la forma.
Ventas
- Pedidos ingresados hoy — contra el promedio de los últimos treinta días.
- Cotizaciones pendientes de respuesta — cuántas y cuántos días llevan.
- Avance del mes contra meta — un porcentaje, no una tabla.
Operación
- Pedidos detenidos — cuántos y por qué motivo, agrupado.
- Entregas comprometidas para hoy — y cuántas están en riesgo.
- Faltantes que bloquean pedidos — no el inventario completo, solo lo que frena una venta.
Finanzas
- Cobranza vencida — monto y a cuántos días, con los cinco casos mayores.
- Flujo proyectado a treinta días — entradas comprometidas contra salidas comprometidas.
- Facturas pendientes de emitir — trabajo ya entregado que todavía no se cobró.
Clientes
- Incidencias abiertas — cuántas y cuántas llevan más de 48 horas.
- Tiempo de primera respuesta — el indicador de servicio más fácil de mover.
- Clientes sin actividad — los que compraban y dejaron de hacerlo.
Los tres errores que matan un tablero
- Actualización manual. Si alguien tiene que exportar y pegar, el tablero se va a desfasar y va a perder credibilidad. La automatización no es un lujo del proyecto: es la condición para que exista.
- Números sin dueño. Cada indicador necesita un nombre al lado. No para señalar culpables, sino porque un número que no es responsabilidad de nadie no genera ninguna acción.
- Rojo sin umbral. Un semáforo solo sirve si el rango se definió antes. Si el color lo decide quien presenta, el tablero se volvió narrativa.
Cómo empezar esta semana
Haz una pregunta en la próxima junta de dirección: "¿qué número te gustaría ver cada mañana antes de abrir el correo?". Anota las respuestas. Vas a encontrar dos cosas: que se repiten menos de las que esperabas, y que la mitad ya existe en algún sistema pero nadie la puso enfrente.
De esa lista, elige los tres que ya se pueden calcular de forma automática con los datos que hoy existen. Ponlos en una pantalla y déjalos correr un mes. El resto del tablero se va a diseñar solo, porque el uso diario revela rápidamente qué falta.
Un indicador que nadie mira no es un indicador: es un costo de mantenimiento. Antes de pedir un tablero nuevo, vale la pena revisar cuáles de los que ya existen se abrieron la semana pasada. Esa lista corta suele ser el mejor punto de partida.
How to describe a software project without being technical
La mejor descripción de un proyecto de software no tiene una sola palabra técnica. Describe qué duele hoy, quién lo sufre y qué resultado se espera. Con eso, cualquier proveedor serio puede decirte si necesitas desarrollo, integración, automatización o simplemente configurar mejor lo que ya tienes. Esta plantilla toma unos cuarenta minutos y ahorra semanas.
Cómo usarla
Llénala con la persona que hace el trabajo todos los días, no solo con quien lo dirige. Escribe en lenguaje normal: si dirías "el muchacho de almacén nos avisa por WhatsApp", escríbelo así. Las palabras exactas de la operación valen más que cualquier intento de sonar técnico.
No intentes proponer la solución. El apartado más valioso no es el diez, es el tres: cómo funciona hoy. Ahí es donde un buen proveedor encuentra la mitad de las oportunidades que tú no habías visto.
La plantilla
- Problema actual¿Qué está pasando que no debería pasar? Descríbelo con una situación concreta, no con un concepto.
- Quién utiliza el procesoPuestos y cuántas personas. Quién lo inicia, quién lo continúa, quién lo autoriza.
- Cómo funciona hoyPaso a paso, tal cual ocurre. Incluye los correos, las llamadas y los archivos que realmente se usan.
- Qué información entraQué datos llegan, de dónde vienen y en qué formato.
- Qué resultado necesitamosQué debe existir al final: un documento, un registro, un aviso, una decisión.
- Reglas importantesPolíticas, límites, autorizaciones, descuentos, plazos. Todo lo que hoy alguien tiene que recordar.
- Sistemas involucradosQué sistemas se usan hoy, aunque sean hojas de cálculo o carpetas compartidas.
- ExcepcionesLos casos raros que rompen el proceso normal y cómo se resuelven hoy.
- VolumenCuántas veces al día, a la semana o al mes ocurre. Y cuánto tarda cada vez.
- Resultado esperadoQué querrías poder decir dentro de seis meses que hoy no puedes decir.
DESCRIPCIÓN DE PROYECTO 1. PROBLEMA ACTUAL ¿Qué está pasando que no debería pasar? 2. QUIÉN UTILIZA EL PROCESO Puestos, número de personas, quién inicia y quién autoriza. 3. CÓMO FUNCIONA HOY Paso a paso, tal como ocurre hoy. 4. QUÉ INFORMACIÓN ENTRA Qué datos llegan, de dónde y en qué formato. 5. QUÉ RESULTADO NECESITAMOS Qué debe existir al terminar el proceso. 6. REGLAS IMPORTANTES Políticas, límites, autorizaciones, plazos. 7. SISTEMAS INVOLUCRADOS Sistemas, hojas de cálculo y carpetas que se usan hoy. 8. EXCEPCIONES Casos raros y cómo se resuelven hoy. 9. VOLUMEN Cuántas veces ocurre y cuánto tarda cada vez. 10. RESULTADO ESPERADO Qué queremos poder decir dentro de seis meses.
Ejemplo completo
Una empresa que prepara cotizaciones a mano. Así se vería la plantilla llena.
Un cliente pide una cotización por correo y tardamos entre uno y tres días en responder. Cuando contestamos, varias veces ya compró en otro lado. Además, cada vendedor cotiza con precios ligeramente distintos.
Cuatro vendedores, un coordinador comercial que revisa, y el gerente de ventas cuando el descuento pasa del 12%.
Llega el correo al buzón de ventas. El coordinador lo asigna. El vendedor busca al cliente en el sistema para ver su nivel de precio, revisa en otro archivo si hay material, arma la cotización en un formato de Word, la guarda en su carpeta y la manda. Si el descuento es alto, primero la manda por WhatsApp al gerente.
Correos en texto libre. A veces traen una lista en Excel, a veces una foto de una requisición escrita a mano. Casi nunca usan nuestros códigos de producto.
Una cotización en PDF con nuestro formato, registrada en el sistema, con el precio correcto según el nivel del cliente y con una fecha de entrega realista.
Tres niveles de precio por tipo de cliente. Descuento hasta 12% lo autoriza el vendedor; arriba de eso, el gerente. Clientes con saldo vencido a más de 60 días no pueden cotizar a crédito. La cotización vence a los 15 días.
Sistema administrativo (clientes, precios, inventario), un Excel compartido de material en tránsito, el correo y las carpetas de cada vendedor.
Productos especiales que no están en el catálogo y hay que pedir precio al proveedor. Clientes de gobierno con formato propio. Pedidos urgentes que se cotizan por teléfono y se documentan después.
Entre 25 y 40 solicitudes diarias. Cada cotización toma entre 20 y 45 minutos de trabajo del vendedor.
Responder el mismo día, con un solo criterio de precios, y saber cuántas cotizaciones se convirtieron en pedido sin tener que preguntarle a cada vendedor.
Si solo tienes tiempo para tres apartados, llena el 3, el 6 y el 9: cómo funciona hoy, cuáles son las reglas y cuánto volumen tiene. Con esos tres, una conversación de una hora alcanza para saber si vale la pena seguir.
Is your company ready to implement an ERP or CRM?
Los proyectos de ERP y CRM rara vez se complican por el sistema elegido. Se complican porque la empresa llegó sin procesos documentados, sin dueño interno y sin acuerdo sobre qué problema estaba resolviendo. Esta evaluación toma diez minutos y sirve para decidir si conviene arrancar ahora o preparar el terreno primero.
Marca las casillas que puedas responder con un sí honesto. El resultado se calcula solo y no se guarda en ningún lado.
Cómo leer tu resultado
0 a 4 · Antes de implementar, ordena la operación
Implementar ahora significa automatizar el desorden actual y pagar por ello. El trabajo previo —documentar el proceso, limpiar el catálogo de clientes y productos, nombrar un responsable— cuesta mucho menos que un proyecto que hay que rehacer. Dos o tres meses de preparación suelen ahorrar el doble en implementación.
5 a 8 · Hay una buena base, pero faltan definiciones
Se puede arrancar, con una condición: cerrar los huecos antes de que el proveedor empiece a configurar. Identifica cuáles casillas quedaron sin marcar y resuélvelas en las primeras semanas. Las que más riesgo traen son la del responsable interno y la del acuerdo de la dirección sobre cambiar procesos.
9 a 12 · La empresa tiene buenas condiciones para iniciar
El proyecto tiene alta probabilidad de salir bien. Aprovecha para exigir un plan por etapas con entregas revisables, en lugar de un arranque único al final. Y define desde ahora cómo vas a medir el resultado, porque en seis meses nadie va a recordar cómo estaban las cosas antes.
Las cuatro preguntas que más peso tienen
No todas las casillas valen igual en la práctica. Si tuvieras que elegir cuatro para asegurar antes de firmar, serían estas:
- ¿Hay un responsable interno con autoridad? Un proyecto sin dueño se convierte en una serie de juntas. El responsable no tiene que ser técnico, pero sí tiene que poder decidir sin consultar cada punto.
- ¿La dirección aceptó que los procesos van a cambiar? Si la instrucción es "que el sistema haga exactamente lo que hacemos hoy", vas a pagar desarrollo a la medida sobre un producto estándar, que es la peor combinación posible.
- ¿Está limpio el catálogo? Clientes duplicados y productos con tres códigos distintos se multiplican dentro del sistema nuevo. La limpieza es tediosa y siempre se subestima.
- ¿Qué problema concreto estamos resolviendo? "Tener un ERP" no es un objetivo. "Cerrar el mes en cinco días en lugar de veinte" sí lo es, y además se puede verificar.
Un buen resultado en esta evaluación no garantiza que el proyecto salga bien, pero un mal resultado casi garantiza que salga mal. Si quedaste abajo de cinco, la conversación que conviene tener no es con un proveedor de software todavía: es interna.
10 processes a company should automate first
Casi toda empresa tiene diez o quince tareas que consumen horas todos los días y que nadie defendería en una junta. No son estratégicas, no requieren criterio y se hacen porque alguien tiene que hacerlas. Estos son los diez lugares donde, en la experiencia de proyectos B2B, aparece primero el retorno.
Captura de leads
Problema típico. Los contactos llegan por formulario, correo, WhatsApp y LinkedIn, y cada canal termina en un lugar distinto. Alguien los concentra a mano en una hoja, o no los concentra.
Qué automatizar. Que todo contacto entre al CRM con su origen, su campaña y su mensaje original, sin importar el canal, y que se asigne según una regla clara.
Resultado esperado. Ningún contacto perdido y, por primera vez, un dato real de qué canal trae clientes.
Cuándo no. Si el volumen es de tres o cuatro por semana, el problema no es de captura sino de generación de demanda.
Seguimiento comercial
Problema típico. Las oportunidades se enfrían no por falta de interés, sino porque nadie recordó dar seguimiento en el momento correcto.
Qué automatizar. Recordatorios basados en el estado real de la oportunidad: cotización enviada sin respuesta a los tres días, cliente sin contacto en treinta días, propuesta por vencer.
Resultado esperado. Menos oportunidades que mueren en silencio y un pipeline que refleja la realidad.
Cuándo no. Si el equipo no registra las oportunidades, automatizar recordatorios sobre datos incompletos genera ruido y desconfianza.
Cotizaciones
Problema típico. Cada cotización toma de veinte a cuarenta minutos: buscar precios, verificar disponibilidad, armar el documento. Y cada vendedor lo hace ligeramente distinto.
Qué automatizar. El borrador completo, con el precio correcto según el nivel del cliente, la disponibilidad real y el formato de la empresa. El vendedor revisa, ajusta y envía.
Resultado esperado. Responder el mismo día y con un solo criterio de precios.
Cuándo no. Si cada cotización es un proyecto distinto con ingeniería de por medio, automatiza la parte administrativa y deja el contenido técnico a la persona.
Aprobaciones
Problema típico. Descuentos, compras y gastos se autorizan por WhatsApp o de viva voz. No hay rastro de quién aprobó qué, ni cuánto tardó.
Qué automatizar. Un flujo con reglas por monto y tipo, notificación al autorizador correcto y registro permanente de la decisión.
Resultado esperado. Trazabilidad completa y menos tiempo muerto esperando a que alguien conteste.
Cuándo no. Si las políticas de autorización no están definidas, primero defínelas. Automatizar una regla que nadie acordó genera conflictos.
Facturación y documentos
Problema típico. Se factura al final del mes en una carrera contra reloj, y siempre queda trabajo entregado que se facturó tarde o no se facturó.
Qué automatizar. La generación del documento a partir de lo que ya está registrado como entregado, con su envío y su acuse.
Resultado esperado. Facturar antes, cobrar antes, y saber en cualquier momento qué está entregado y pendiente de facturar.
Cuándo no. Si las entregas no se registran con disciplina, la automatización va a facturar lo incorrecto más rápido.
Conciliaciones
Problema típico. Alguien cruza a mano los movimientos del banco contra las facturas, cada semana o cada mes, en una hoja de cálculo.
Qué automatizar. El cruce automático por monto, fecha y referencia, dejando para revisión humana solo lo que no coincidió.
Resultado esperado. Días de trabajo convertidos en minutos de revisión de excepciones, y una cartera que refleja la realidad.
Cuándo no. Si los clientes no usan referencias de pago, primero hay que resolver eso; sin referencia el cruce automático es adivinanza.
Actualización entre sistemas
Problema típico. Un dato se captura en el CRM y alguien lo vuelve a capturar en el ERP. O se exporta un archivo y se importa en otro lado.
Qué automatizar. La sincronización directa, con una regla clara de qué sistema manda en cada campo.
Resultado esperado. Desaparece la doble captura y con ella una categoría entera de errores.
Cuándo no. Si alguno de los sistemas está por reemplazarse en los próximos meses, conviene esperar.
Reportes recurrentes
Problema típico. Los mismos reportes se arman a mano cada semana. Quien los arma ya no los analiza, solo los produce.
Qué automatizar. Generación y envío programado, con los datos tomados directo de la fuente.
Resultado esperado. El tiempo se mueve de producir información a discutirla.
Cuándo no. Si nadie los lee, la acción correcta no es automatizarlos: es dejar de hacerlos.
Atención y clasificación inicial
Problema típico. Todo llega al mismo buzón: cotizaciones, quejas, facturas, proveedores. Alguien lee todo y reparte.
Qué automatizar. La clasificación y el enrutamiento al área correcta, con una respuesta de acuse inmediata.
Resultado esperado. Tiempo de primera respuesta más corto y nada que se quede semanas sin abrir.
Cuándo no. Si el volumen es bajo y una persona lo maneja sin esfuerzo, el retorno no justifica el proyecto.
Alertas y seguimiento operativo
Problema típico. Los problemas se detectan cuando el cliente llama: el pedido detenido, el material que no llegó, la entrega que se venció.
Qué automatizar. Vigilancia continua de condiciones definidas —días detenido, stock bajo, compromiso por vencer— con aviso al responsable.
Resultado esperado. Se pasa de reaccionar a anticipar, que es la diferencia más visible para el cliente.
Cuándo no. Si se configuran demasiadas alertas, el equipo deja de leerlas. Empieza con tres.
No automatices un proceso roto. Si el proceso tiene pasos que existen solo porque alguna vez alguien se equivocó, o aprobaciones que nadie recuerda por qué se pusieron, automatizarlo congela ese desorden y lo vuelve más difícil de cambiar. Primero entiéndelo, después quítale lo que sobra, y hasta entonces automatiza lo que quedó. Casi siempre, la versión simplificada necesita la mitad de la tecnología que se había imaginado.
Tell us how your business works.
Tell us the problem. We'll help you find the technology.