Implementare un PSA significa modificare il modello operativo con il supporto del software. Il progetto riesce quando vendite, delivery e finance condividono definizioni e il sistema produce dati affidabili. Questa checklist ordina responsabilità, prove e decisioni necessarie.
La maggior parte delle implementazioni che falliscono non fallisce per il prodotto. Fallisce perché nessuno ha deciso cosa significhi esattamente “commessa attiva”, perché due funzioni calcolano l'utilization con formule diverse, oppure perché lo storico è stato migrato senza riconciliazione e il primo report economico non torna con la contabilità. Il software amplifica il modello operativo che già hai: se le definizioni sono ambigue, l'ambiguità compare adesso su uno schermo condiviso.
Questa è la sequenza delle fasi, con la domanda che ciascuna deve chiudere prima di passare alla successiva.
| Fase | Domanda che chiude | Segnale che puoi procedere |
|---|---|---|
| Responsabilità e obiettivi | Chi decide cosa è corretto in ogni processo? | Ogni workflow ha un owner con nome e cognome |
| Workflow minimi | Qual è il percorso da opportunità a fattura? | Il flusso sta in una pagina e nessuno lo contesta |
| Migrazione dati | Saldi e commesse tornano con la contabilità? | Due prove riconciliate senza differenze aperte |
| Controlli e integrazioni | Chi vede tariffe, costi e candidati? | Permessi provati con utenti reali per ruolo |
| Pilota | Funziona con lavoro vero e una chiusura intera? | Un mese chiuso nel sistema, non in Excel |
| Lancio | Possiamo spegnere il sistema parallelo? | Due cicli riconciliati e controlli critici chiusi |
Fase 1: assegna responsabilità e obiettivi
Nomina uno sponsor e un process owner per passaggio commerciale, allocazione, approvazione ore, economia di progetto e fatturazione. Il partner tecnico configura, ma solo il business può stabilire cosa è corretto.
Scegli pochi risultati misurabili: tempo di emissione fatture, timesheet approvati in scadenza, forecast aggiornati e ore impiegate nello staffing. Registra baseline e data obiettivo.
Tre o quattro obiettivi bastano, otto sono troppi. Con otto nessuno ha un owner reale e la revisione mensile diventa un giro di stato invece che una decisione. Scrivi ogni obiettivo con il numero di partenza, il numero atteso e la data in cui si verifica: senza quelle tre cifre l'obiettivo è un'intenzione.
Conviene inoltre separare due ruoli che spesso si confondono. Lo sponsor sblocca risorse e arbitra quando due funzioni non trovano un accordo; il process owner decide il dettaglio del proprio processo e risponde della qualità dei suoi dati. Se in una società di una certa dimensione la stessa persona fa entrambe le cose, le decisioni difficili slittano fino al pilota.
Fase 2: mappa decisioni e workflow minimi
Mappa il percorso dall'opportunità qualificata alla commessa, allo staffing, alle ore approvate e alla fattura. Per ogni passaggio definisci condizioni di ingresso, responsabile, dati obbligatori e controllo.
Separa il necessario al lancio dalle evoluzioni. Replicare subito anni di eccezioni Excel crea complessità prima che gli utenti abbiano completato un ciclo standard.
Una regola pratica: se un'eccezione capita meno di una volta al mese e ha una soluzione manuale accettabile, non entra nel lancio. Annotala nel backlog con chi l'ha chiesta e quale problema risolve. Dopo due chiusure buona parte di quelle eccezioni avrà smesso di contare, e quelle ancora vive arriveranno con evidenze reali invece che con un aneddoto.
Documenta il flusso principale come sequenza di stati con ingresso, uscita e campi obbligatori. Quando il flusso sta in una pagina e le quattro funzioni lo firmano, la configurazione del sistema smette di essere una trattativa e diventa una traduzione.
Fase 3: prepara e migra i dati
Crea un registro con sorgente, proprietario, definizione, problema di qualità, retention e destinazione. Pulisci clienti, persone, skill, tariffe, progetti e saldi iniziali; non migrare duplicati e record senza proprietario.
Esegui almeno due prove. Riconcilia conteggi e campioni economici: progetti attivi, valore contratti, cost rate e WIP. Documenta ogni trasformazione.
La riconciliazione deve essere numerica e firmata, non visiva. Confronta totale clienti, commesse aperte, ore dell'ultimo trimestre, importi fatturati e lavoro in corso con la fonte contabile, e lascia per iscritto ogni differenza con la sua spiegazione. Una differenza spiegata è accettabile; una differenza non spiegata ricompare alla prima chiusura davanti a un cliente.
Decidi anche quale storico valga la pena migrare. Portare dieci anni di commesse chiuse aggiunge di solito rumore, costo e rischio sui dati personali senza utilità decisionale. Un criterio ragionevole è migrare per intero l'aperto e l'esercizio in corso, e conservare il resto in un archivio consultabile fuori dal sistema operativo, con la sua politica di conservazione scritta.
Fase 4: configura controlli e integrazioni
Assegna permessi secondo ruolo e minimo privilegio. Verifica chi vede tariffe di costo, candidati, condizioni commerciali ed export finanziari. Definisci deleghe, audit e cambio ruolo.
Testa le integrazioni con scenari end-to-end, non singole chiamate API: opportunità, progetto, staffing, ore e billing, includendo errore e retry. Stabilisci quale sistema possiede ogni campo.
Il campo con due proprietari è la causa più frequente di sfiducia successiva. Se sia il CRM sia il PSA possono modificare la data di inizio di una commessa, qualcuno vedrà cambiare un dato senza sapere chi l'ha cambiato, e da quel momento il team ricomincia a tenere la propria copia parallela. Scrivi una tabella di proprietà dei campi prima di attivare qualsiasi integrazione: sistema sorgente, sistema lettore, frequenza e comportamento in caso di conflitto.
Prova i permessi con utenti reali di ciascun ruolo, non con un'utenza amministrativa. La domanda concreta è chi può vedere tariffe di vendita, costi interni, margini per commessa e dati dei candidati. Nelle società con partner e practice lead questa conversazione fa emergere policy mai formulate prima.
Fase 5: pilota un ciclo completo
Scegli un perimetro rappresentativo ma gestibile e includi anche un utente scettico. Porta lavoro reale fino alla chiusura mensile. Usa un registro problemi con severità, proprietario, decisione e scadenza.
Classifica ogni problema: configurazione, dati, policy o formazione. Risolvere una policy poco chiara con ulteriore customizzazione crea debito permanente.
Classificare bene le segnalazioni del pilota è ciò che evita che il progetto si riempia di sviluppi inutili. Un difetto si corregge; un dato di origine sbagliato si pulisce; una policy ambigua si decide e si comunica; una carenza di formazione si copre con un materiale da due minuti. Solo la prima categoria giustifica un intervento sul sistema.
Scegli un pilota piccolo ma completo: una practice con commesse T&M e a corpo, un manager che approva le ore, una persona del finance e almeno un utente scettico. Lo scettico non è un ostacolo, è il miglior rilevatore di attrito reale. E pretendi che il pilota comprenda un'intera chiusura mensile, perché quasi tutti i problemi economici emergono in chiusura e non nell'uso quotidiano.
Fase 6: lancio e stabilizzazione
Pubblica istruzioni per ruolo e attività. Offri assistenza breve durante i primi cicli e aggiorna la guida condivisa. Definisci quando spegnere i sistemi paralleli: due cicli riconciliati, qualità accettata e nessun controllo critico aperto.
Misura adozione e risultati a 30, 60 e 90 giorni. La guida ai costi PSA aiuta a mantenere l'effort nel TCO approvato.
A 30 giorni la domanda è di utilizzo: chi entra, chi no e perché. A 60 giorni è di qualità: quante correzioni manuali si fanno ancora e dove. A 90 giorni è di risultato: se gli indicatori scelti all'inizio si sono mossi rispetto alla baseline. Mescolare le tre domande nella prima revisione produce conclusioni premature e riconfigurazioni che poi vanno disfatte.
Checklist finale di go-live
Conferma owner, permessi, saldi migrati, monitoraggio integrazioni, export, supporto, prova di fine mese e rollback. Ogni voce critica richiede evidenza e approvatore: la dichiarazione del fornitore non è un collaudo.
Chiudi il progetto solo quando la responsabilità passa alle operations. Mantieni backlog prioritizzato, revisione trimestrale della qualità dati e definizioni accessibili.
Segnali precoci che l'implementazione sta andando storta
Ci sono quattro segnali che compaiono prima che il problema sia visibile nel piano. Il primo è la ricomparsa di fogli di calcolo paralleli per decisioni che il sistema dovrebbe già supportare: significa che manca un dato o che nessuno si fida di quello disponibile. Il secondo è una lista di richieste di personalizzazione che cresce più in fretta di quanto si chiuda, quasi sempre sintomo di policy non decise. Il terzo è che le riunioni di progetto sono condotte solo da consulenti esterni e IT, senza i process owner del business. Il quarto è che la data di go-live resta fissa mentre il perimetro si allarga.
Nessuno dei quattro si risolve aggiungendo ore. Si risolvono restituendo una decisione al business, riducendo il perimetro di lancio o spostando la data in modo trasparente.
Cosa fare quando il pilota non funziona
Un pilota che va male è informazione a basso costo, purché non venga letto come un verdetto sul prodotto. Prima di decidere qualsiasi cosa, separa le segnalazioni nelle quattro categorie e guarda le proporzioni. Se dominano dati di origine e policy ambigue, il problema è tuo e si risolve senza toccare il sistema. Se dominano i difetti veri, è una conversazione con il fornitore e probabilmente un rinvio del lancio.
L'errore costoso è la via di mezzo: lanciare comunque con la promessa di sistemare dopo. Spegnere il sistema precedente con problemi aperti lascia la società senza rete durante la chiusura, e il costo di recuperare la fiducia del team è molto superiore a quello di un mese di ritardo. Tieni il rollback documentato e provato finché due cicli completi non si sono chiusi bene.
Evidenze da conservare
Mantieni in un unico registro decisioni di processo, mapping dati, esiti delle prove, accettazioni e problemi rinviati. Per ogni elemento indica versione, data e approvatore. In questo modo un cambio di personale non cancella il motivo per cui un workflow o un controllo esiste.
Dopo novanta giorni conduci una retrospettiva con utenti, operations e finance. Confronta risultati e baseline, elimina workaround ormai inutili e scegli poche evoluzioni con impatto misurabile.
