La prueba que diferencia un MVP de un sistema temporal
Dos proyectos pueden lanzarse con el mismo número de pantallas, pero uno servirá de base para el crecimiento mientras que el otro se convertirá en una deuda a solventar. La diferencia no radica en el alcance, sino en el tipo de concesión.
La regla práctica es: en la primera fase, se reduce el alcance de negocio, no la profundidad arquitectónica. Es permisible limitar la cantidad de procesos, unidades y tipos de clientes a incluir. Sin embargo, no se debe comprometer el modelo de datos central, el modelo de permisos ni la definición de la fuente de verdad. Estos deben construirse correctamente desde el principio, incluso si inicialmente solo atienden a cincuenta usuarios.
Quien reduce la profundidad en lugar del alcance obtiene un sistema que funciona durante un trimestre y luego debe ser reconstruido. El contexto más amplio de las fases del proyecto se detalla en la Guía de Implementación de Salesforce.
Tres definiciones que suelen confundirse
| Término | Qué es en la práctica | Cuándo es apropiado | Riesgo principal |
|---|---|---|---|
| Prueba de Concepto (PoC) | Demostración de viabilidad técnica de un componente. | Cuando existe una duda genuina sobre la posibilidad de algo. | Se tiende a escalarlo a producción. |
| Piloto | Operación completa en un grupo reducido. | Cuando la solución es conocida y la cuestión es la adopción. | El grupo no es suficientemente representativo. |
| MVP (Producto Mínimo Viable) | Primera versión en producción que genera valor real. | Cuando se busca aprender del uso práctico. | Se convierte en permanente sin una decisión formal. |
La elección entre estos tres no es una cuestión semántica. Una PoC puede descartarse, un MVP no. Por ello, un MVP solo debe construirse con estándares de producción.
Decisiones que no se deben posponer
Existe un conjunto de decisiones cuyo costo de modificación aumenta exponencialmente una vez que se tienen datos en producción. Estas decisiones deben abordarse en la primera fase, incluso si en ese momento solo cubren una pequeña parte del panorama:
- El objeto que sostiene el proceso de negocio y su relación con las entidades centrales.
- La clave única que identifica a un cliente frente a sistemas externos.
- La visibilidad predeterminada en cada objeto clave.
- La estructura de propiedad de un registro — quién es el Propietario y qué sucede cuando un empleado se va.
- La definición de la fuente de verdad para cada entidad sincronizada con otro sistema.
Por otro lado, las decisiones que se pueden y deben posponer incluyen: el diseño de informes avanzados, automatizaciones de conveniencia, la integración de canales secundarios, la localización para unidades no incluidas en la primera fase, e integraciones que no son críticas para decisiones en tiempo real.
Cómo seleccionar el proceso para la primera fase
No se elige el proceso más sencillo ni el más problemático. Se selecciona el proceso que cumple con tres condiciones simultáneamente: tiene un único propietario de proceso disponible, genera un resultado visible para la dirección, y representa el modelo de datos central. Un proceso que cumpla con dos de las tres condiciones aún es viable; uno que cumpla con solo una resultará en una primera fase que no aportará aprendizaje significativo.
Otra consideración es el volumen: un proceso que ocurre diez veces al mes no generará suficiente uso para aprender de él en un trimestre.
Criterio de salida — qué indica el éxito de la fase
Un MVP sin un criterio de salida se convierte en un estado permanente. El criterio debe ser medible, conciso y conocido de antemano. Un ejemplo de estructura:
- El porcentaje de procesos del tipo seleccionado que se ejecutan realmente en el sistema y no fuera de él.
- No hay incidencias bloqueantes abiertas por encima de un número definido de días.
- Los datos generados durante el período cumplen con el umbral de calidad predefinido.
- El propietario del proceso confirma por escrito que el proceso se ejecuta sin soluciones alternativas permanentes.
Es importante destacar que ninguno de estos es "el sistema ha sido lanzado". Esa fecha es el punto de inicio de la medición, no su final.
Costo de la demora — la herramienta para resolver discusiones de alcance
Al debatir si una funcionalidad debe incluirse en la primera fase, la pregunta útil no es cuánto cuesta construirla ahora, sino cuánto costará construirla más tarde. La siguiente tabla sirve como herramienta de trabajo en una reunión de alcance:
| Tipo de funcionalidad | Costo de construcción en la primera fase | Costo de construcción en la segunda fase | Conclusión |
|---|---|---|---|
| Cambio en la estructura del objeto central | Bajo | Muy alto — incluye migración | Se incluye en la primera fase |
| Nuevo modelo de permisos | Medio | Alto — la exposición ya ocurrió | Se incluye en la primera fase |
| Informe de gestión | Bajo | Bajo | Se pospone |
| Automatización de alertas | Bajo | Bajo | Se pospone |
| Integración requerida para decisiones en tiempo real | Alto | Alto + solución alternativa establecida | Se incluye si el proceso depende de ella |
| Integración solo para informes | Medio | Medio | Se pospone |
Ejemplo ilustrativo: una empresa de logística internacional
El escenario es hipotético y tiene fines ilustrativos. Una empresa de transporte con operaciones en tres países quería lanzar un MVP en once semanas. La propuesta inicial era incluir los tres países, pero solo la fase de cotización, sin la fase de pedido.
El equipo invirtió el enfoque: un solo país, pero el proceso completo desde la cotización hasta el pedido aprobado, incluida la integración que extrae las tarifas. La razón era simple: cortar el proceso a la mitad habría obligado a los usuarios a continuar en el sistema antiguo para la fase de pedido, es decir, a introducir datos dos veces. En lugar de aprender si el sistema ayudaba, la empresa habría aprendido que el sistema dificultaba el trabajo.
El alcance total en semanas se mantuvo similar. La diferencia fue que, tras la primera fase, la empresa tenía un proceso completo en funcionamiento, en lugar de medio proceso en tres países.
Señales de que el MVP se ha convertido en un sistema temporal
- Existe un proceso manual permanente diseñado para "cubrir hasta la siguiente fase" y que lleva funcionando dos meses.
- Se acordó un campo que se utiliza para dos propósitos diferentes porque no hubo tiempo para dividirlo.
- Existe un grupo de usuarios que trabaja simultáneamente en dos sistemas.
- No hay una fecha de decisión para la siguiente fase, solo una lista de espera.
Estos patrones aparecen detallados, junto con otros errores comunes, en la Guía de Errores Comunes en la Implementación de CRM.
Integración con el cronograma general
La definición del MVP impacta directamente en la duración del proyecto, y a veces en la dirección opuesta a la esperada: una primera fase demasiado estrecha alarga el proyecto global, ya que cada fase conlleva un costo fijo de pruebas, formación y lanzamiento. Cómo traducir esto a una planificación realista y detallada se explica en la Guía de Duración de Proyectos Salesforce, y en caso de reemplazar un sistema existente, también en la Guía para la Migración a Salesforce.
El siguiente paso
Escriba en una frase cuál es el proceso de la primera fase, quién es su propietario de proceso y cuál es el criterio que, en un trimestre, indicará su éxito. Si alguna de estas tres frases no se puede redactar ahora, ese es el punto de partida, no la lista de funcionalidades.