Diez a quince días contra seis a doce meses

Cuando una empresa decide que necesita medir su operación de campo o la de sus centros comerciales, casi siempre compara dos caminos: contratar un desarrollo a la medida o conectar una plataforma que ya existe.

La comparación suele plantearse en términos de plazo y de precio. Es la parte menos interesante.

Qué toma cada camino

Nuestras puestas en marcha toman entre diez y quince días. No es una promesa comercial: es el plazo que se repite porque lo que ocurre en esos días es configuración, no construcción.

Un desarrollo a la medida de alcance equivalente se suele estimar entre seis y doce meses. Esa segunda cifra es una referencia de mercado, no una medición nuestra: sale de lo que cuestan proyectos comparables, y si su empresa tiene un dato propio de un desarrollo que haya hecho, ese dato vale más que este.

Por qué la diferencia es tan grande

Porque no se está haciendo lo mismo.

En una puesta en marcha sobre plataforma existente, las dos semanas se reparten así: un par de días para entender cómo opera hoy y qué quiere medir; unos cinco para ajustar reglas, usuarios, formularios e indicadores; cuatro o cinco para conectar con los sistemas que ya usa; y desde ahí, acompañamiento y entrenamiento.

En un desarrollo desde cero, ese mismo calendario es el prólogo. Después viene definir el modelo de datos, construir la aplicación de campo, construir el tablero, resolver el trabajo sin conexión, probar en dispositivos reales, corregir, y volver a probar.

Lo que casi nunca se compara

Hay tres cosas que no aparecen en la comparación de plazos y que deciden el resultado a los dos años.

Quién arregla lo que se rompe. Un desarrollo a la medida vive mientras viva el equipo que lo hizo. Cuando esa gente cambia de trabajo, el código queda, y el conocimiento no.

Quién paga la siguiente versión. Un sistema operativo de teléfono cambia dos veces al año. Una plataforma que sirve a muchos clientes absorbe ese trabajo en su propio ciclo. Un desarrollo propio lo cobra cada vez.

Con qué se empieza. El primer día de una plataforma en producción desde 2016 viene con diez años de casos raros ya resueltos encima. Un desarrollo nuevo empieza con el código escrito y sin ninguno de esos casos resueltos.

Cuándo sí conviene construir

Hay situaciones en las que un desarrollo propio es la respuesta correcta, y conviene decirlas:

• Cuando lo que se quiere hacer es el negocio, y no un apoyo al negocio. Ahí la ventaja está justamente en tener algo que nadie más tiene.
• Cuando el proceso es tan particular que configurarlo en una plataforma existente equivale a reescribirla.
• Cuando existe un equipo propio de producto y de desarrollo con capacidad de sostenerlo por años, no de entregarlo una vez.

Si su caso es alguno de esos tres, lo que sigue no aplica y conviene que alguien se lo diga antes de firmar.

La pregunta que ordena la decisión

No es «¿cuánto cuesta?» ni «¿cuánto demora?». Es: ¿qué queremos estar haciendo dentro de dos años, mantener un sistema o usarlo?

Quien responde «usarlo» compra tiempo de su equipo, que es el recurso que no se repone. Quien responde «mantenerlo» tiene una razón para hacerlo, y esa razón debería poder escribirse en una frase.

Cómo comprobarlo antes de decidir

Pida el calendario día por día de la puesta en marcha, con lo que se hace en cada etapa y quién lo hace. Pida ver un tablero con datos reales, no una demostración con datos de ejemplo. Y pregunte qué pasa con su información el día que termine el contrato.

Las tres respuestas se piden por escrito. Un proveedor que solo las da de palabra está diciendo algo sobre lo que va a pasar dentro de dos años.