Casi studio: il settore dei servizi contrapposto a quello manifatturiero

1. Servizio: Softsys S.r.l. - primaria società di sviluppo software

Il lead auditor Bill è arrivato nella società presso la quale deve effettuare un audit di ricertificazione - la Softsys S.r.l. - una primaria società di sviluppo software il cui SGQ è certificato ISO 9001:2000 da tre anni.

Alpha, uno dei reparti della Softsys, fornisce supporto agli addetti software sul campo ed effettua piccole modifiche / miglioramenti al software. Gli obiettivi definiti dalla Softsys per questa attività sono di ottenere il 100% di successi e 0% di ritardo nel consegnare i lavori entro la scadenza: 24 ore per i lavori critici, 48 ore per quelli con priorità media e 72 ore per quelli con priorità bassa.

Nel monitorare i progetti per il rispetto di tali criteri, Bill scopre che tutti i lavori sono stati completati entro la scadenza e che non ci sono stati ritardi. Tuttavia, sotto al grafico che analizza i lavori c'è una nota che parla di una rettifica dei tempi impiegati nel rispettare le scadenze.

Quando Bill controlla con il responsabile del reparto, gli viene riferito che i tempi trascorsi a causa della mancata risposta da parte del cliente o i ritardi attribuibili al cliente sono detratti per calcolare il tempo impiegato "rettificato". Il risultato viene confrontato con il tempo limite specificato: quando calcolato in questo modo l'esito è che non si è verificato alcun ritardo. Tuttavia, se si considerasse il tempo reale "non rettificato" per ogni commessa, ci sarebbe un ritardo del 10% oltre la scadenza. Il responsabile è dell'opinione che - dato che il ritardo è attribuibile al cliente - non si tratti di una non conformità. Bill prende nota del fatto e si appunta mentalmente di discutere di ciò con gli altri auditor del gruppo e con il Rappresentante della Direzione (RdD).

Nel reparto successivo Zeta vengono eseguiti lavori più grandi per i clienti. Bill trova che per ogni lavoro che arriva, le ore-uomo previste ed il numero di giorni necessario per completarlo sono dapprima calcolati ed inviati al cliente ed in seguito concordati prima dell'inizio del lavoro. Scopre che in oltre il 75% dei casi, il tempo reale impiegato è dal 15% al 30% in meno del tempo preannunciato. Quando chiede al Project Manager, Mr. Furbetto, questi spiega con orgoglio che il suo team è molto efficiente, ha molta esperienza ed è altamente motivato e che è contento delle loro prestazioni sistematicamente sopra la media.

Omega, il reparto successivo, si occupa di eliminazione dei difetti ed implementazione di migliorie. Qui Bill trova che il personale è relativamente rilassato. Ad una sua domanda, rispondono che per il lavoro è un periodo morto, soprattutto perché il prodotto software del quale si occupano è stato lanciato solo di recente e quindi ci si aspetta nel prossimo futuro poco lavoro per l'eliminazione di difetti o migliorie. Bill chiede al responsabile del progetto, Mr. Rilassiamoci, cosa faccia il suo personale quando non ha lavoro. La risposta che riceve è che - dato che si occupano di un software specifico - non possono lavorare su altri progetti e che, siccome il carico di lavoro può aumentare in qualsiasi momento, non ha senso in re-impiegarli in altro. Per quanto concerne questo periodo morto, Mr. Rilassiamoci sorride e dice a Bill che il reparto Omega ha lavorato così tanto negli ultimi cinque mesi, che stanno lasciando che il personale si goda un po' di meritato riposo. In ogni caso, il personale naviga in internet, dà una ripassata alle proprie abilità di programmazione ed a volte gioca con giochi che allenano le loro reazioni. "Li tiene di buon umore!" esclama Mr. Rilassiamoci.

Alla fine della giornata, Bill ed il gruppo di audit si riuniscono - riunione alla quale è presente anche il Rappresentante della Direzione, Mr. Vaccipiano - per analizzare quanto riscontrato e finalizzare le risultanze prima della riunione di chiusura.

 

Scenari

  • Riguardo il primo episodio nel reparto Alpha, Bill è dell'opinione che per un monitoraggio efficace dei progetti il tempo impiegato "non rettificato" dovrebbe essere confrontato alle scadenze e che si tratti di una non conformità minore. Il RdD ha l'impressione che ciò sarebbe troppo duro perché a volte i clienti tardano davvero a rispondere o rispondono quando vogliono e di certo un ritardo attribuibile completamente ai clienti non dovrebbe causare una non conformità / un mancato raggiungimento degli obiettivi perché non sarebbe giusto. Qual è l'approccio migliore?
  • Dopo aver ascoltato quanto detto delle prestazioni sopra la media del reparto Zeta, un collega - Mr. Lavoroveloce - ha guardato Bill ed ha osservato "Cosa ne pensa di queste prestazioni sopra la media? Credo che si stiano lasciando un ampio margine quando definiscono le ore necessarie e la scadenza: è questo che li fa sembrare così bravi. Ritengo che ci siano margini di miglioramento". Qual è la tua opinione al riguardo?
  • Bill è stato un po' colpito dai tempi morti evidenziati nel reparto Omega, ma gli altri membri del gruppo hanno avuto la sensazione che si trattasse di un caso isolato dei tempi morti che a volte si presentano e non vi hanno prestato molta attenzione. Qual è la tua opinione al riguardo?

Soluzioni

  • Situazione 1: La situazione nel reparto Alpha non può essere tecnicamente definita un mancato raggiungimento degli obiettivi e quindi non può essere vista come una non conformità. Tuttavia, se le scadenze sono ripetutamente "aggiustate" in questo modo, alla lunga ciò potrebbe portare ad insoddisfazione del cliente e ad una minore efficienza. Potrebbe diventare una tendenza quella di cercare di spostare sempre di più la colpa sul cliente. L'ideale quindi - nonostante non sia necessario modificare gli obiettivi - sarebbe che Softsys considerasse di tener traccia delle scadenze non rettificate a fronte degli obiettivi / scadenze concordate per avvertire in anticipo e fornire indicazioni sull'andamento per migliorare le prestazioni. Questa potrebbe essere una raccomandazione per il miglioramento.
  • Situazione 2: Prestazioni sopra la media in termini di tempo potrebbero essere il risultato di compromessi / smussamenti di altri aspetti, quali ad esempio la qualità del software od altri parametri. E' necessario che questo sia verificato. L'ideale - quello che dovrebbe essere raccomandato e fatto - è un'analisi delle cause per determinare le ragioni del minor tempo impiegato. Questo potrebbe portare a miglioramenti del prodotto od a un migliore definizione degli obiettivi temporali che possono essere troppo laschi o avere margini ampi, prevenendo in questo modo un'eccessiva rilassatezza nei programmi temporali.
  • Situazione 3: Il reparto Omega è il caso tipico delle società di software che affrontano carichi di lavoro mutevoli. Nonostante non sia un aspetto preoccupante in sé, il reparto responsabile avrebbe potuto essere più proattivo ed utilizzare meglio il proprio tempo: sviluppando manuali interni, processando documentazione e sfruttando il tempo per fornire formazione di base necessaria allo staff. Il tempo libero avrebbe anche potuto essere utilizzato per attività di manutenzione o per creare componenti ri-utilizzabili. C'è decisamente margine di miglioramento utilizzando il tempo libero per migliorare le abilità del personale ed effettuando manutenzioni.