Un buon team privo della collaborazione degli utenti interni non “porterà a casa il progetto

Zero chiacchiere, una volta approvato l’ERP Project dal Board dell’azienda, scende in campo la squadra destinata a “mettere le mani nell’olio“, quelli che faranno il lavoro sporco.
E per noi è questo il momento di verificare che tutte le risorse necessarie siano effettivamente disponibili, con la benedizione dei vertici aziendali.

L’importanza dei key users

E’ del tutto inutile dire che il successo di un progetto è legato alle persone ed alle loro competenze. Qualunque sia la metodologia applicata.
L’analisi dei requisiti effettuata in fase di prevendita, raramente raggiunge una profondità accettabile, e tuttavia necessaria a garantire che il modello finale rispecchi le attese del management.

Dove troviamo i dettagli di ogni procedura aziendale da implementare in modo appropriato?
Generalmente sono informazioni in possesso degli utenti, e spesso nemmeno presenti in un ipotetico “mansionario”.

Nella scelta degli utenti di riferimento o, se preferite, Key-Users, dovremo tenere conto di alcuni aspetti che, molto spesso, sono solo tangenziali al progetto.

Individuare un key-user capace, per ognuna delle attività che il sistema andrà a gestire, è di grande valore, direi  indispensabile se vogliamo consegnare un prototipo molto vicino alle aspettative del cliente.

Può succedere che la scelta dei key-users non cada, come erroneamente si potrebbe pensare, sui responsabili di questo o quel reparto.  Inevitabilmente questo genererà frizioni interne al reparto che saranno da gestire e contenere al meglio.

L’utente difficilmente ha la visione dell’arco di vita del progetto e spesso fa “confusione” fra le attività progettuali e quelle d’ufficio, la routine per capirci.
E’ sempre bene, una volta individuata la persona a cui assegnare l’attività progettuale, concordare con il relativo responsabile tempi e impatti sulle attività di routine, per attenuare gli attriti che inevitabilmente si faranno sentire.

L’esperienza mi consente di considerare questa, una vera e propria attività di PR in un ERP Project.

Fra routine e attività progettuali

Superato il problema che abbiamo descritto qui sopra 🙂 è opportuno tenere sempre presente che durante tutta l’attività progettuale, l’azienda continua la propria attività. La priorità dei Key-User è sempre quella assegnatagli dal loro boss.

Il progetto, tuttavia, è una importante occasione per aumentare la performance aziendale, oltre che un corposo investimento di risorse e denaro. E noi ne siamo garanti e certificatori.
Il nostro compito è quello di tenere in equilibrio, spesso sovraccaricando la nostra giornata, i due aspetti della vita aziendale investita dal ciclone progetto.

Ogni mezzo lecito è consentito per attrarre l’attenzione dei key-users, sia nella fase di micro-analisi che in tutte le successive di test.
Un buon team privo della collaborazione degli utenti interni non “porterà a casa il progetto”

Processo standard e personalizzazioni

Un buon progetto tende a mantenere il sistema quanto più possibile vicino allo standard rilasciato dalla ERP software company di turno. La famosa “vanilla version“.
I vantaggi di un atteggiamento progettuale di questo tipo sono infiniti. Uno per tutti? Pensate agli upgrade, che nel mondo ERP sono spesso molto impattanti, tanto da somigliare a mini-progetti.

Per questo motivo è da ritenersi un errore risolvere problemi, apparentemente insormontabili, con modifiche al software ERP.
La modifica software è l’ultima spiaggia.  Da utilizzare con estrema attenzione e parsimonia.

Fra i rischi della proliferazione di modifiche software, facilmente intuibili, c’è quello di consegnare al cliente un sistema funzionante ma lontano anni luce dall’ERP che pensa di aver comprato.

  • ri-analizzare il processo,
  • verificare eventuali Fixes rilasciate dalla ERP Company,
  • applicare modifiche funzionali al software,
  • modificare il processo, se questo non ha impatti sulla performance e non devasta la percezione dell’utente.

Solo dopo queste verifiche potremo, ahimè,  pensare di mettere in moto il “lato tecnico del team” e analizzare le possibili modifiche software da effettuare.

Un po come succede quando si ha un dolore al ginocchio, se andiamo da un osteopata tende a a curarci, viceversa se finiamo in mano all’ortopedico chirurgo….. bisturi 😉

buona giornata

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *