Implementar un PSA es cambiar el modelo operativo con apoyo del software. El proyecto funciona cuando ventas, delivery y finanzas comparten definiciones y confían en los datos. Esta checklist organiza responsables, pruebas y decisiones.
La mayoría de implantaciones que fracasan no fracasan por el producto. Fracasan porque nadie decidió qué significa exactamente "proyecto activo", porque dos áreas calculan la utilización con fórmulas distintas o porque el histórico se migró sin conciliar y el primer informe económico no cuadró con la contabilidad. El software amplifica el modelo operativo que ya tienes: si las definiciones son ambiguas, la ambigüedad aparece ahora en una pantalla compartida.
Esta es la secuencia de fases, con la pregunta que cada una debe cerrar antes de pasar a la siguiente.
| Fase | Pregunta que cierra | Señal de que puedes avanzar |
|---|---|---|
| Responsables y éxito | ¿Quién decide qué es correcto en cada proceso? | Cada workflow tiene un owner con nombre |
| Workflows mínimos | ¿Cuál es el camino de oportunidad a factura? | El flujo cabe en una página y nadie lo discute |
| Migración de datos | ¿Los saldos y proyectos cuadran con contabilidad? | Dos ensayos conciliados sin diferencias abiertas |
| Controles e integraciones | ¿Quién ve tarifas, costes y candidatos? | Permisos probados con usuarios reales por rol |
| Piloto | ¿Funciona con trabajo real y un cierre completo? | Un mes cerrado en el sistema, no en Excel |
| Lanzamiento | ¿Podemos apagar el sistema paralelo? | Dos ciclos conciliados y controles críticos cerrados |
Fase 1: responsables y éxito
Nombra sponsor y process owner para traspaso comercial, asignación, aprobación de horas, economía de proyecto y facturación. Solo el negocio puede decidir qué significa “correcto”.
Elige pocos objetivos: tiempo de factura, timesheets aprobados, forecasts actualizados y horas de staffing. Registra baseline y fecha objetivo.
Tres o cuatro objetivos son suficientes y ocho son demasiados. Con ocho, ninguno tiene dueño real y la revisión mensual se convierte en un repaso de estado en lugar de una decisión. Escribe cada objetivo con su número de partida, su número objetivo y la fecha en la que se comprueba; sin esas tres cifras el objetivo es una intención.
Conviene además separar dos roles que a menudo se confunden. El sponsor desbloquea recursos y arbitra cuando dos áreas no se ponen de acuerdo; el process owner decide el detalle de su proceso y responde de la calidad de sus datos. Si la misma persona hace ambas cosas en una firma de cierto tamaño, las decisiones difíciles se posponen hasta el piloto.
Fase 2: workflows mínimos
Mapea desde oportunidad cualificada hasta proyecto, staffing, horas y factura. Define entrada, owner, datos obligatorios y control en cada paso.
Separa requisitos de lanzamiento y mejoras. Reproducir todas las excepciones de Excel antes del primer ciclo crea complejidad prematura.
Una regla práctica: si una excepción ocurre menos de una vez al mes y tiene una solución manual aceptable, no entra en el lanzamiento. Anótala en el backlog con quién la pidió y qué problema resuelve. Después de dos cierres, buena parte de esas excepciones habrá dejado de importar, y las que sigan vivas llegarán con evidencia real en lugar de con una anécdota.
Documenta el flujo principal como una secuencia de estados con entrada, salida y campos obligatorios. Cuando el flujo cabe en una página y las cuatro áreas lo firman, la configuración del sistema deja de ser una negociación y pasa a ser una traducción.
Fase 3: migración de datos
Crea un registro de fuente, owner, definición, calidad, retención y destino. Limpia clientes, personas, skills, tarifas, proyectos y saldos. No conserves duplicados sin propósito.
Haz dos ensayos como mínimo y concilia recuentos, proyectos activos, contratos, costes y WIP. Documenta transformaciones.
La conciliación tiene que ser numérica y firmada, no visual. Compara total de clientes, proyectos abiertos, horas del último trimestre, importes facturados y trabajo en curso contra la fuente contable, y deja por escrito cada diferencia con su explicación. Una diferencia explicada es aceptable; una diferencia sin explicar reaparecerá en el primer cierre delante de un cliente.
Decide también qué histórico merece migrarse. Traer diez años de proyectos cerrados suele añadir ruido, coste y riesgo de datos personales sin utilidad de decisión. Un criterio razonable es migrar completo lo abierto y lo del ejercicio en curso, y conservar el resto en un archivo consultable fuera del sistema operativo, con su política de retención escrita.
Fase 4: controles e integraciones
Configura mínimo privilegio y comprueba quién ve tarifas, candidatos y datos financieros. Define delegaciones, auditoría y cambios de rol.
Prueba escenarios end-to-end, incluidos error y reintento. Aclara qué sistema es propietario de cada campo para evitar sobrescrituras.
El campo con dos propietarios es la causa más frecuente de desconfianza posterior. Si el CRM y el PSA pueden modificar la fecha de inicio de un proyecto, alguien verá cambiar un dato sin saber quién lo cambió, y a partir de ahí el equipo empieza a mantener su copia paralela. Escribe una tabla de propiedad de campos antes de activar cualquier integración: sistema origen, sistema lector, frecuencia y qué ocurre ante conflicto.
Prueba los permisos con usuarios reales de cada rol, no con una cuenta de administrador. La pregunta concreta es quién puede ver tarifas de venta, costes internos, márgenes por proyecto y datos de candidatos. En consultoras con partners y practice leads, esta conversación suele revelar políticas que nunca se habían formulado.
Fase 5: piloto completo
Elige un grupo representativo, pequeño y con algún usuario escéptico. Ejecuta trabajo real y un cierre mensual. Registra severidad, owner, decisión y plazo.
Distingue defecto, mala fuente, política poco clara y formación. Más customización no resuelve una política ambigua.
Clasificar bien las incidencias del piloto es lo que evita que el proyecto se llene de desarrollos innecesarios. Un defecto se corrige; un dato de origen malo se limpia; una política ambigua se decide y se comunica; una carencia de formación se cubre con un material de dos minutos. Solo la primera categoría justifica tocar el sistema.
Elige un piloto pequeño pero completo: una práctica con proyectos T&M y de precio cerrado, un manager que aprueba horas, alguien de finanzas y al menos un usuario escéptico. El escéptico no es un obstáculo, es el mejor detector de fricción real. Y exige que el piloto incluya un cierre mensual entero, porque casi todos los problemas económicos aparecen en el cierre y no en el uso diario.
Fase 6: lanzamiento y adopción
Publica instrucciones por rol, ofrece soporte breve y actualiza la guía. Apaga sistemas paralelos solo tras dos ciclos conciliados, calidad aceptada y controles críticos cerrados.
Mide a 30, 60 y 90 días. La guía de costes PSA mantiene el esfuerzo dentro del TCO.
A 30 días la pregunta es de uso: quién entra, quién no y por qué. A 60 días es de calidad: cuántas correcciones manuales se siguen haciendo y dónde. A 90 días es de resultado: si los indicadores elegidos al principio se han movido respecto a la baseline. Mezclar las tres preguntas en la primera revisión produce conclusiones prematuras y decisiones de reconfiguración que luego hay que deshacer.
Checklist final
Confirma owners, permisos, saldos, monitorización, exportación, soporte, ensayo de cierre y rollback. Cada punto crítico necesita evidencia y aprobación.
Cierra el proyecto cuando la responsabilidad pase a operaciones. Mantén backlog, revisión trimestral de datos y definiciones visibles.
Señales tempranas de que la implantación se está torciendo
Hay cuatro señales que aparecen antes de que el problema sea visible en el plan. La primera es la reaparición de hojas de cálculo paralelas para tomar decisiones que el sistema ya debería soportar: significa que falta un dato o que nadie confía en él. La segunda es una lista de peticiones de personalización que crece más rápido de lo que se cierra, casi siempre síntoma de políticas no decididas. La tercera es que las reuniones de proyecto las llevan solo consultores externos y TI, sin process owners del negocio. La cuarta es que la fecha de go-live se mantiene fija mientras el alcance crece.
Ninguna de las cuatro se arregla añadiendo horas. Se arreglan devolviendo una decisión al negocio, recortando el alcance de lanzamiento o moviendo la fecha con transparencia.
Qué hacer cuando el piloto no funciona
Un piloto que va mal es información barata, siempre que no se interprete como un veredicto sobre el producto. Antes de decidir nada, separa las incidencias en las cuatro categorías anteriores y mira la proporción. Si dominan los datos de origen y las políticas ambiguas, el problema es tuyo y se resuelve sin tocar el sistema. Si dominan los defectos reales, es una conversación con el proveedor y probablemente un aplazamiento del lanzamiento.
El error caro es el intermedio: lanzar igual con la promesa de arreglarlo después. Apagar el sistema anterior con problemas abiertos deja a la firma sin red durante el cierre, y el coste de recuperar la confianza del equipo es muy superior al de un mes de retraso. Mantén el rollback documentado y probado hasta que dos ciclos completos hayan cerrado bien.
Evidencias que deben conservarse
Mantén en un registro único decisiones de proceso, mapping de datos, resultados de pruebas, aprobaciones y problemas aplazados. Cada elemento necesita versión, fecha y aprobador. Así, un cambio de personas no elimina el motivo de un workflow o un control.
Tras noventa días realiza una retrospectiva con usuarios, operaciones y finanzas. Compara resultados con baseline, identifica campos que nadie usa, elimina workarounds y prioriza pocas mejoras con impacto medible. Revisa también accesos, integraciones fallidas, calidad de datos y capacidad del equipo de soporte interno.
