La trampa de la implementación en serie: Por qué la consultoría tecnológica dejó de entender el negocio

Un guion que se repite

Te firman el contrato dos socios senior. Vienen a la primera reunión de inicio, se toman un café, hablan de estrategia, de mejores prácticas globales y de transformar la empresa. A la semana siguiente no los ves más.

El proyecto le queda a tres chicos recién egresados o con un par de años de experiencia que bastante tienen con entender cómo cargar sus propias horas en el sistema de la consultora. Su trabajo no es pensar tu negocio; es cerrar tickets de desarrollo antes del viernes para llegar al hito de cobro de fin de mes.

A los seis meses te entregan la plataforma. Hacen una presentación donde todo parece andar bien, muestran un par de pantallas con datos de prueba, firman el acta de conformidad y se van a la siguiente cuenta.

El problema aparece a la mañana siguiente.

La gente de ventas sigue usando sus planillas por atrás porque la pantalla nueva les pide veinte datos que no le importan a nadie. El equipo de operaciones recibe tareas duplicadas. La gerencia no puede sacar un reporte decente sin pedirle a un analista que cruce tres archivos de Excel durante el fin de semana. Y la dirección descubre que está pagando miles de dólares por año en licencias de un software que el equipo esquiva cada vez que puede.

Eso no es un accidente de tu proyecto ni tuviste mala suerte con el proveedor. Es la forma en que está armada la industria de la consultoría tradicional.

El modelo económico que nadie te cuenta

Para entender por qué la consultoría dejó de entender el negocio, hay que mirar cómo ganan dinero las grandes firmas integradoras.

Su rentabilidad no depende de que tu empresa trabaje mejor ni de que aumentes tu margen. Depende de una métrica interna llamada tasa de utilización: vender la mayor cantidad posible de horas de desarrollo con el menor costo de personal posible.

En ese esquema, sentarse a revisar los procesos del cliente es un pésimo negocio para la consultora.

Si una empresa llega con un proceso comercial confuso, con diez niveles de aprobación que no tienen sentido y reglas de descuento que cambian según quién pregunte, a la consultora tradicional no le conviene cuestionar nada. Cuestionarlo exige tiempo, discusiones difíciles con gerentes que no quieren cambiar su forma de trabajar y personas con experiencia real sentadas en la mesa.

Es mucho más fácil y rentable tomar ese desorden tal como viene y ponerlo en código. Cuanto más complejo, enredado y lleno de excepciones a medida sea el desarrollo, más horas se cobran. Si a mitad de camino descubren que la regla estaba mal pensada, mejor todavía: se emite una orden de cambio (change order) y se facturan cien horas más para emparchar la pantalla.

Se termina programando el caos. La tecnología no arregla el proceso: solo lo vuelve más caro, más lento y más difícil de cambiar en el futuro.

Lo que pasa cuando se configura sin entender

Llevamos más de 6 años viendo proyectos de software desde adentro y hay una constante que no cambia: el software casi nunca es la causa del fracaso.

Herramientas modernas como las del ecosistema de Salesforce pueden resolver prácticamente cualquier flujo comercial, operativo o de atención al cliente. Tienen la flexibilidad necesaria para adaptarse a casi cualquier industria. Lo que falla, casi siempre, es la falta de criterio antes de tocar la herramienta.

Pensemos en un escenario habitual en empresas B2B. Un equipo comercial quiere agilizar las cotizaciones porque los clientes tardan una semana en recibir un precio formal.

La fábrica de software envía un analista a tomar requerimientos. El analista pregunta: "¿Qué campos quieren en la pantalla y quiénes deben aprobar un descuento?". La empresa responde lo que viene haciendo hace diez años: que si el descuento supera el 5% tiene que aprobar el gerente regional, y si supera el 10% tiene que firmar el director comercial. La consultora va y programa esa secuencia exacta con validaciones y correos automáticos.

¿El resultado? Ahora las cotizaciones tardan diez días en lugar de siete. El sistema notifica de inmediato a dos ejecutivos que ya estaban tapados de reuniones y que ahora se convirtieron en cuellos de botella digitales. Los vendedores, para no perder la venta, aprenden a dividir los pedidos en dos facturas más chicas o acuerdan condiciones por fuera del sistema.

Una consultoría de arquitectura de negocios hace una pregunta distinta antes de configurar nada: "¿Por qué un descuento del 5% necesita la firma de un director? ¿Cuál es el margen real de ese producto y cuántas solicitudes de este tipo se rechazaron el año pasado?".

Cuando miras los números, casi siempre descubres que el 95% de esas solicitudes se aprobaban en piloto automático sin que nadie mirara los datos. La solución no era construir un flujo de aprobación complejo en el CRM; era darle margen directo al vendedor bajo ciertas reglas claras y eliminar la necesidad de aprobación humana en la mayoría de los casos.

Configurar pantallas o crear campos es la parte sencilla; cualquier profesional con una capacitación técnica básica puede hacerlo. Lo difícil es sentarse a discutir la política comercial con la dirección, mostrar los puntos donde la empresa pierde tiempo y simplificar las reglas antes de ponerlas en un sistema.

El costo "silencioso" dentro de la empresa

Cuando un proyecto tecnológico se despacha como si fuera una línea de montaje, el costo no es solo lo que se le pagó a la consultora. El costo real empieza a pagarse todos los días después de que la consultora se fue.

Aparece una fricción silenciosa en varios frentes:

• En la fuerza comercial: Los vendedores perciben el CRM como una carga burocrática creada para que la gerencia los controle, no como una herramienta que los ayuda a vender más. Pasan horas completando campos obligatorios al final de la semana solo para cumplir, cargando información basura o incompleta.
• En el equipo de TI interno: El departamento de tecnología de la empresa hereda un "espagueti" de código a medida, automatizaciones mal documentadas y parches que se rompen cada vez que hay que hacer una actualización. El equipo pasa de innovar a apagar incendios.
• En la dirección: El C-Suite sigue recibiendo informes contradictorios. El área de marketing muestra métricas de prospectos generados, ventas muestra un tubo de negocios que no se cierra y finanzas mira números completamente distintos en el ERP. La promesa de la "vista unificada del cliente" se transforma en discusiones semanales sobre cuál planilla tiene el dato correcto.

Cuando la prioridad de un proyecto es cerrar tickets de desarrollo para cumplir un cronograma artificial, la tecnología pasa a ser una capa decorativa costosa por encima del desorden que la empresa ya tenía.

Por qué armamos Zarasa de otra manera

Frente a esa inercia de mercado, en 2020 decidimos estructurar Zarasa sobre una premisa distinta.

Tras acumular años de experiencia asesorando a organizaciones corporativas en sus proyectos de tecnología, Mathias Möller y Dagoberto Suarez sabían que el mercado no necesitaba otra consultora vendiendo miles de horas de desarrollo masivo con equipos rotativos. Hacía falta un equipo experimentado, capaz de involucrarse sin intermediarios en la realidad del cliente.

Esta postura no es un lema de marketing; es una decisión concreta sobre cómo trabajamos:

Decidir no operar como una fábrica masiva es una decisión sobre la calidad del entregable. En el momento en que una consultora prioriza el volumen de cuentas, pierde la capacidad de involucrarse en los detalles operativos que realmente definen si un proyecto funciona o no.

Desde nuestra base en Uruguay, trabajando con clientes de diversos sectores en toda la región, confirmamos día a día que el verdadero valor de un socio tecnológico no está en la cantidad de código que escribe, sino en la sobriedad del diseño: soluciones simples, estructuradas y fáciles de mantener que la empresa pueda adoptar y sostener en el tiempo sin quedar rehén de nadie.

La herramienta como consecuencia, no como punto de partida

Estar especializados como partners en el ecosistema de Salesforce (cubriendo desde Sales Cloud y Service Cloud hasta Data Cloud, MuleSoft, Tableau y Agentforce) nos da la capacidad técnica para resolver arquitecturas complejas. Pero la herramienta va siempre en segundo lugar.

El trabajo real empieza mucho antes de abrir la plataforma. Empieza por entender la mecánica operativa del negocio:

1. ¿Cómo entran y se cierran realmente las ventas? No lo que dice el manual de procesos escrito hace cinco años, sino lo que hace hoy el vendedor que mejor rinde para destrabar una negociación.
2. ¿Dónde están los cuellos de botella reales? Identificar qué decisiones se frenan por política interna, por falta de datos o por duplicación de tareas entre áreas.
3. ¿Qué información vive en la memoria de las personas y no en la organización? Detectar los puntos críticos donde la operación se paraliza si una persona clave se enferma o se va de vacaciones.
4. ¿Qué métricas necesita ver la dirección para decidir sin adivinar? Eliminar el exceso de indicadores de vanidad y enfocarse en los datos que mueven el margen, la retención y la velocidad de ejecución.

Cuando se trabaja con este nivel de claridad, la implementación de tecnología deja de ser un evento traumático y se convierte en un ejercicio de ordenamiento. El software deja de sentirse como una obligación impuesta y empieza a funcionar como la infraestructura natural que sostiene la operación.

Mantenimiento de la claridad operacional

Evolucionar proyecto tras proyecto exige la disciplina de renunciar al volumen fácil para enfocarse en la solidez de los resultados.

Las empresas que perduran no son las que compran más licencias ni las que llenan la organización con herramientas de moda desconectadas entre sí. Son las que logran mayor claridad sobre su propia operación. Y esa claridad no se logra agregando complejidad técnica; se logra eliminando la fricción de los procesos y asegurando que cada decisión de software responda a un objetivo de negocio medible.

Al final, la tecnología existe para que el negocio funcione mejor, más rápido y con mayor margen; no para mantener ocupada a una consultora.

Preguntas frecuentes

¿Por qué la mayoría de los proyectos de software empresarial terminan desviándose en tiempo y presupuesto?

Porque se arranca por la herramienta antes de resolver el proceso. Si te pones a configurar software sin haber simplificado las reglas de negocio, los permisos y los flujos de trabajo, las decisiones se van tomando sobre la marcha de forma improvisada. Las desviaciones casi nunca son problemas de código; son el resultado de construir sobre ambigüedades operativas que nadie se tomó el tiempo de ordenar antes.

¿Cómo sé si mi empresa cayó en una "implementación en serie"?

El síntoma típico es que tienes un software de primer nivel pero tu equipo sigue coordinando las cosas importantes por WhatsApp, planillas de Excel o correos sueltos. Si para entender cómo viene el mes la dirección tiene que pedirle a un gerente que arme un informe manual porque la pantalla del sistema no da datos confiables, la herramienta se instaló como un trámite administrativo y no como el cerebro operativo de la empresa.

¿En qué se diferencia una consultoría de arquitectura de una fábrica de software?

La fábrica de software cobra por horas de programación y mide el éxito en cantidad de tickets de desarrollo cerrados, aunque la solución termine complicándole la vida al usuario. Una consultoría de arquitectura trabaja desde la experiencia senior para diagnosticar la lógica del negocio, diseñar la estructura de datos adecuada y usar la menor cantidad de desarrollo a medida posible, evitando llenar la empresa de parches técnicos que después son caros de mantener.

¿Se puede arreglar un proyecto de Salesforce que quedó mal implementado sin hacer todo de nuevo?

Sí. En la gran mayoría de los casos no hace falta tirar las licencias ni la inversión a la basura. Lo que hay que hacer es un trabajo de simplificación: entrar al sistema, eliminar todos los campos obligatorios, flujos y automatizaciones que nadie usa y que solo meten fricción, y reordenar la arquitectura de datos (Data Cloud) para que la dirección tenga la información real que necesita para decidir sin dar vueltas.