Cómo Interpretar esta Lista
Las diez fallas que se presentan a continuación no están ordenadas por frecuencia, sino por su aparición en la línea de tiempo de un proyecto. Para cada una, se detallan tres elementos: la señal temprana que puede identificarse en tiempo real, la acción preventiva, y la etapa a partir de la cual la corrección se vuelve significativamente más costosa. La idea es sencilla: casi cualquiera de estas fallas tiene un costo muy bajo si se aborda en las dos semanas adecuadas.
1. Empezar por una Lista de Funcionalidades en lugar de un Proceso
La señal: El documento de requisitos está estructurado como una tabla de capacidades deseadas, y ninguna de sus filas describe un resultado de negocio.
Lo que sucede en la práctica: El proyecto genera un sistema que cumple con la lista, pero no modifica la forma de trabajar. Un año después, la gerencia pregunta qué ha cambiado y no hay una respuesta medible.
Prevención: A cada requisito se le asocia el proceso al que sirve y la métrica que debería impactar. Los requisitos sin respuesta a estas dos preguntas pasan a una lista de espera. El conjunto de entregables que evita este patrón se detalla en la Guía de Descubrimiento de CRM.
2. Ausencia de un Único Dueño de Proceso
La señal: En las reuniones, asisten cuatro personas del mismo departamento, y ninguna de ellas está autorizada para decir "así será".
Lo que sucede en la práctica: Cada decisión se resuelve mediante un compromiso que intenta complacer a todos, es decir, construyendo dos caminos en lugar de uno. El sistema se vuelve el doble de complejo de lo necesario.
Prevención: Asignar un nombre a cada proceso con una sola persona responsable. La distribución de roles recomendada se detalla en la Guía de Roles del Equipo de Proyecto de Salesforce.
3. Postergar Decisiones de Arquitectura para el Final
La señal: El equipo avanza en la construcción de pantallas mientras la pregunta "¿cuál es la fuente de verdad para el cliente?" sigue abierta.
Lo que sucede en la práctica: Cuando la decisión finalmente se toma, contradice lo que ya se ha construido. Parte del trabajo se desecha, y la estimación inicial del proyecto ya no es relevante.
Prevención: Identificar al inicio las tres a cinco decisiones que son costosas de cambiar —modelo de datos central, fuente de verdad, modelo de permisos— y asignarles una fecha de resolución antes de comenzar la construcción.
4. Importar la Deuda del Sistema Anterior
La señal: La especificación de migración contiene todos los campos del sistema anterior, incluidos aquellos cuyos nombres terminan en "_old_2".
Lo que sucede en la práctica: La nueva plataforma nace con doscientos campos que nadie mantiene, informes que se basan en datos poco fiables, y usuarios que interpretan esto como una señal de que el nuevo sistema tampoco es serio.
Prevención: Cada campo que se migre debe tener un propietario y un uso comprobado en el último año. El resto pasa a un archivo legible y no al sistema en vivo.
5. Medir el Progreso por Historias de Usuario Cerradas
La señal: El informe semanal muestra altos porcentajes de completitud, pero nadie ha logrado ejecutar un proceso completo de principio a fin.
Lo que sucede en la práctica: El proyecto aparece en el gráfico como un éxito hasta la semana previa al lanzamiento, y luego se descubre que todas las partes funcionan de forma independiente y nadie ha verificado la conexión.
Prevención: Definir un hito de "primer proceso en vivo de principio a fin" lo antes posible, incluso si cubre solo un escenario. Hasta que no se logre, los porcentajes de completitud no son información relevante.
6. Campos Obligatorios como Substitutos de la Disciplina de Datos
La señal: La pantalla de creación de registros incluye doce campos obligatorios, de los cuales nadie sabe quién se supone que conoce sus valores.
Lo que sucede en la práctica: Los usuarios seleccionan el primer valor de la lista para avanzar. Los informes reciben datos completamente completos y también completamente erróneos.
Prevención: Un campo solo es obligatorio si es necesario para una decisión en el momento en que se solicita. Los campos requeridos en etapas posteriores del proceso se hacen obligatorios en ese momento.
7. Construir Automatización antes de que el Proceso sea Estable
La señal: Existen tres mecanismos de automatización que operan sobre el mismo objeto, y nadie sabe cuál es su orden de ejecución.
Lo que sucede en la práctica: Efectos secundarios inesperados, bucles de actualización y, sobre todo, la incapacidad de cambiar un proceso sin temor a romper algo.
Prevención: Ejecutar un proceso manual o semi-manual durante varias semanas antes de automatizarlo. La automatización fija una decisión; es mejor que la decisión sea correcta.
8. UAT Realizado por Quienes Construyeron el Sistema
La señal: Los escenarios de prueba fueron escritos por el mismo equipo de desarrollo, y cubren principalmente el camino feliz.
Lo que sucede en la práctica: Los problemas que llegan a producción son precisamente los casos excepcionales: cancelaciones, abonos, clientes duplicados, usuarios que abandonaron un proceso a mitad.
Prevención: Las pruebas son realizadas por el personal del proceso, con datos similares a los reales, y con una responsabilidad definida para la aprobación o el rechazo.
9. Capacitación como Evento Único
La señal: El plan de implementación incluye dos talleres la semana anterior al lanzamiento y nada más después.
Lo que sucede en la práctica: Los usuarios aprenden pantallas, no procesos, olvidan en dos semanas y recurren a colegas o a una hoja de Excel. La tasa de uso disminuye gradualmente sin que nadie se dé cuenta.
Prevención: Capacitación por rol, lo más cercana posible al momento en que el empleado realmente realizará la acción, con un punto de soporte disponible en las primeras semanas.
10. Ausencia de Propietarios después del Go Live
La señal: El plan del proyecto no incluye una línea que describa quién gestionará el sistema en el tercer mes.
Lo que sucede en la práctica: Las solicitudes de cambio se acumulan sin respuesta, los pequeños errores se convierten en prácticas de trabajo alternativas y el sistema envejece rápidamente.
Prevención: Definir la propiedad operativa, un mecanismo de recepción de solicitudes y una cadencia de lanzamiento regular antes del lanzamiento y no después. En organizaciones grandes, esto se hace generalmente a través de un modelo de gobierno estructurado, como se describe en la Guía de Implementación de Salesforce en una Organización Empresarial.
Costo de la Corrección por Etapa
| Falla | Corrección en el Diseño | Corrección en la Construcción | Corrección después del Go Live |
|---|---|---|---|
| Modelo de datos incorrecto | Modificación en el diagrama | Reconstrucción del objeto | Migración interna y revisión completa |
| Ausencia de propietario de proceso | Nombramiento | Paradas y resoluciones repetidas | Proceso duplicado que se mantiene indefinidamente |
| Deuda del sistema antiguo | Filtrado de la lista de campos | Limpieza antes de la carga | Limpieza en el sistema en vivo |
| Campos obligatorios innecesarios | Decisión en el diseño de pantalla | Cambio de configuración | Limpieza de datos erróneos acumulados |
| Ausencia de propiedad operativa | Definición en el plan | Contratación o capacitación | Recuperación de la confianza de los usuarios |
Ejemplo Ilustrativo: Compañía de Seguros Mediana
El escenario es hipotético y tiene fines ilustrativos. Una compañía de seguros lanzó Salesforce para la gestión de agentes. Tres meses después, se descubrió que la tasa de actualización de los registros de los agentes era baja. La investigación no encontró ningún fallo técnico: se identificaron tres de las fallas mencionadas anteriormente simultáneamente: campos obligatorios innecesarios en la pantalla de creación, ausencia de un propietario para el proceso de contratación de agentes, y una capacitación que se impartió dos meses antes de que los primeros nuevos agentes ingresaran al sistema.
La corrección no fue técnica. Se eliminaron seis campos obligatorios, se nombró a un único propietario del proceso del departamento de operaciones, y la capacitación se dividió en segmentos cortos que se enviaron la semana en que cada grupo comenzó a trabajar. El único cambio arquitectónico requerido fue posponer la obligatoriedad de dos campos a una etapa posterior del proceso.
Qué Hacer con la Lista
Revise las diez fallas y marque si la señal temprana de alguna de ellas está presente en su organización en este momento. Tres o más señales en un proyecto que aún no ha sido lanzado son motivo para una breve pausa y corrección, no para acelerar. Esas mismas tres señales en un sistema que ya está en vivo justifican un diagnóstico estructurado antes de añadir nuevas funcionalidades sobre una base inestable.