El punto de partida y el resultado
La operación de ventas vivía en Excel. Diseñé el producto que la reemplazó.
El sistema de sheets enfrentaba ineficiencias y mala usabilidad, lo que afectaba directamente la productividad de los equipos. A través de investigaciones con usuarios finales y un diseño iterativo, entregué un concepto actualizado que optimizó los flujos de trabajo y aumentó la confianza de las partes interesadas en el potencial del rediseño.
La planilla, y el módulo que la reemplazó · Arrastrá para comparar
Los datos representados en las pantallas son ficticios.
y la restricción
La empresa crecía más rápido de lo que las planillas podían sostener: más productos, más gente, y cada carga manual con más riesgo detrás.
El catálogo y el equipo se expandían al mismo tiempo. Cargar precios o stock dejó de ser una tarea de a un producto para volverse masiva, con más personas tocando los mismos datos al mismo tiempo. A ese volumen, un error de carga dejaba de ser un problema puntual y pasaba a costar plata. Y los datos sensibles del negocio vivían en archivos que se compartían por fuera de cualquier control de acceso.
Y el alcance de cada módulo tenía que salir de relevar a los usuarios internos, no de un documento. Esa era la restricción real: el conocimiento del negocio no estaba escrito en ningún lado y cada área lo contaba distinto.
01 — Dónde empieza y termina cada módulo
Se cortó por el dato, no por el organigrama.
Lo natural era organizar el producto por área, porque así está organizada la empresa y así lo describía cada equipo. Lo cortamos distinto: por dónde el dato cambia de dueño. Cada vez que un número pasaba de un área a otra había una planilla intermedia y un reproceso, ahí pusimos el límite. Pricing y Forecasting quedaron separados aunque comparten insumos, porque los ciclos de decisión son distintos.
Cómo lo validé: devolvimos el mapa de módulos a cada área y les pedí que marcaran dónde no se reconocían. Los límites que nadie discutió quedaron; los otros se movieron.
02 — Lo que no se automatizó
El ajuste final de precio sigue siendo manual, a propósito.
El sistema calcula el landed cost y sugiere el precio, pero no lo publica solo. Ese último tramo depende de contexto que no está en ningún dato: la competencia del día, un acuerdo puntual, criterio comercial.
Automatizarlo habría sido más prolijo de mostrar y peor de usar. Un producto que decide por vos algo que requiere criterio no elimina la decisión: la empuja afuera. El equipo habría vuelto a ajustar precios en una planilla paralela y, en una semana, el sistema ya no habría sido la fuente de verdad.
La regla: el producto automatiza el cálculo y las acciones masivas; la decisión que requiere juicio queda a la vista, con el sugerido al lado.
03 — La adopción
Que nadie sienta que pierde el control de su planilla
Gente que manejaba su Excel de memoria no adopta un producto que le esconde el cálculo. Mantuvimos la tabla como objeto central en vez de reemplazarla por dashboards, dejamos ver de dónde sale cada número, y agregamos edición en línea y acciones masivas para que la velocidad de la planilla no se perdiera.
Cómo lo miré: en las pruebas con usuarios, cuánto tardaban en encontrar el origen de un número y si volvían a abrir la planilla vieja para chequear.
que descartamos
Evaluamos un dashboard analítico como pantalla principal en vez de la tabla operativa.
Se veía mejor en la presentación y resolvía la lectura para dirección, pero no el trabajo diario: las personas usuarias no entran a mirar, entran a cargar y corregir. Dejamos el análisis como capa secundaria y le dimos la pantalla a la tarea.
no funcionó
Empecé preguntando en entrevistas cómo trabajaban. Las respuestas eran el proceso ideal, no el real. Recién cuando me senté a mirarlos operar aparecieron los atajos y las planillas paralelas que definían el producto.
distinto
Medir el antes. Cuánto tardaba armar el pricing, cuántos errores de carga había por semana: sin ese número, el impacto del producto se cuenta con adjetivos.