Sono stati raggiunti gli obiettivi prefissati?

Questo articolo fa parte della nostra collezione "From the Ttrenches". Descrive in che modo le implementazioni di sistema aziendali devono essere in grado di adattarsi ed evolversi per avere successo.

Per scaricare la versione di Word di questo articolo, vedere Sono già disponibili?

Per altri articoli, vedere white paper "From the Trenches".

Sono stati raggiunti gli obiettivi prefissati?

Nel corso degli anni uno dei più grandi insidie che ho visto per la selezione e la distribuzione del software aziendale è il pensiero dell'implementazione come soddisfare uno scopo statico. È possibile che questo sia solo un segno dei nostri tempi mentre cerchiamo di mordere tutto il nostro mondo. "Gestisce i nostri progetti" "È la nostra scheda attività" o "È il nostro sistema ERP" o "Abbiamo un sistema EPM" riduce al minimo la necessità di pensare continuamente a tutti gli aspetti della nostra azienda che possono essere toccati dal nostro sistema aziendale. Tuttavia, le organizzazioni che ho incontrato, che hanno avuto il maggior successo nella distribuzione di un progetto aziendale o di un sistema di schede attività aziendali, le considerano inevitabilmente come un "sistema vivente"; un sistema in continua evoluzione dal design.

Perché considerarlo come un sistema statico?

Se è vero che esiste una migliore probabilità di successo in un sistema aziendale considerato come un ambiente dinamico, perché molte organizzazioni considerano il proprio sistema aziendale come un software fisso?

Ci sono molte possibili ragioni.

Forse l'accettazione del sistema aziendale significava creare un caso aziendale in un ambiente di budget complesso in cui ci sarebbe una possibilità e una sola possibilità di ottenere un budget approvato per il sistema. Tornare indietro ogni anno o ogni ciclo di bilancio per chiedere un'altra fase e poi un'altra è politicamente impossibile.

Oppure, forse hai ereditato il sistema e sono state fatte alcune promesse su ciò che doveva offrire o forse c'è stato un po 'e tutti nell'organizzazione pensano che il sistema fornisca solo un elenco prestabilito di funzionalità aziendali.

Oppure, forse all'interno della politica sono al lavoro e ci sono quelli altrove nell'organizzazione che avrebbero paura di un sistema senza limiti.

Cosa c'è di sbagliato in questo pensiero?

È strano che si pensi anche a un sistema software come statico. In genere non si considera il problema da risolvere come statico. Le affermazioni sul problema associate all'implementazione di un sistema aziendale sono quasi sempre in evoluzione. Dipendono dalle mutevoli condizioni economiche, dal cambiamento delle condizioni aziendali, dai cambiamenti nelle attività della concorrenza, dai cambiamenti nel personale o dai cambiamenti nell'architettura tecnologica. Un'organizzazione che ritiene che le condizioni aziendali non cambieranno mai è improbabile che rimanga in azienda a lungo. Se si pensa al software aziendale, si pensi a quanto rapidamente cambia l'aspetto tecnologico della soluzione. Nel nostro business della scheda attività TimeControl, abbiamo subito 6 importanti cambiamenti di architettura tecnologica in 20 anni. Abbiamo iniziato nel 1994 con una versione DOS, poi abbiamo seguito nel 1995 una versione di Windows, quindi una versione client/server nel 1997, quindi una versione basata su browser nel 1999 e poi una versione ospitata nel cloud e una versione per dispositivi mobili nel 2010. Questa è solo l'architettura tecnologica. Un'ulteriore evoluzione si è verificata grazie alle mutevoli condizioni economiche, ai concorrenti e solo dall'esperienza. Per gli utenti che fanno parte del progetto aziendale o dell'azienda di pubblicazione software della scheda attività, si accetta che la modifica sia una costante.

Non si tratta di un modo diverso di pensare alla distribuzione di un sistema aziendale. Nel tempo necessario per implementare un sistema aziendale come Project Server, l'organizzazione che la implementa è destinata a cambiare. Ci saranno nuovi clienti, nuovo personale e personale che partono. Nel tempo necessario per scegliere e distribuire il sistema EPM, emergeranno altri prodotti concorrenti. Abbiamo visto le organizzazioni paralizzate da questo fenomeno. Per timore che non selezioneranno il prodotto perfetto, il rilascio di un altro prodotto da parte di un altro fornitore ha il gruppo di selezione sospendere il suo lavoro per prendere in considerazione il nuovo prodotto. In alternativa, il rilascio di una nuova versione di uno dei prodotti considerati è motivo di preoccupazione per tutti che la valutazione non considererà tutte le alternative. Questi gruppi ricominciano più e più volte. Una decisione finale non viene mai realizzata perché i requisiti dell'organizzazione e le opzioni della soluzione non smettono mai di cambiare.

Il problema per queste organizzazioni è che la sfida aziendale che li ha fatto cercare una soluzione in primo luogo non scompare e, in assenza di una decisione, non vengono risolti.

Quindi, se non statico, allora cosa?

Le distribuzioni di sistema aziendali avranno maggiori probabilità di successo se sono ambienti viventi. Dovrebbero crescere, evolversi e adattarsi alle mutevoli condizioni intorno a loro. E, sì, forse a un certo punto in futuro, quando saranno vecchi, dovranno essere ritirati. La modifica più critica a questo modo di pensare è che la soluzione perfetta non è il punto di partenza. Le priorità diventano la scelta di una soluzione che soddisfi le esigenze più critiche, ma che abbia la capacità di adattarsi a esigenze più complesse in futuro, anche se non sono state ancora perfettamente articolate. Uno dei criteri di selezione più importanti diventa flessibilità anziché ampiezza di funzionalità.

Come è possibile evitare l'accoppiamento statico?

È possibile eseguire diverse operazioni per evitare di rimanere bloccati in un paradigma di distribuzione statica.

• Creare fasi nel piano di implementazione e non esaurire mai le fasi.

  Se si adotta un approccio graduale all'implementazione aziendale, è possibile concentrarsi su una prima fase molto più modesta. Al nostro staff di consulenza viene insegnato a identificare non il più che potevamo fare, ma il meno. Diciamo loro di "cercare la distribuzione più minima, la cui distribuzione produrrà un continuo ritorno positivo sull'investimento". La grande notizia su questo è che il valore del sistema inizierà molto, molto più rapidamente e nell'uso del sistema, anche a un livello più minimo, i requisiti per l'uso futuro diventeranno più chiari.

• Creare un budget che consenta l'evoluzione.

  Una delle sfide riscontrate in molte distribuzioni è il pensiero "una visita al pozzo" in cui una richiesta per un sistema aziendale può essere effettuata una sola volta. Fare un budget in più fasi, invece, con l'aspettativa che i primi due budget di fase siano piuttosto dettagliati, ma le fasi future sono meno, quindi inevitabilmente ha più successo.

• Scegliere soluzioni altamente flessibili.

  Il nostro staff ha adottato il motto "Semper Gumby" (dopo il giocattolo flessibile Mr. Gumby). È un gioco di parole coniato per la prima volta nell'esercito degli Stati Uniti, ma si adatta perfettamente al nostro pensiero. Proprio come il signor Gumby, non sappiamo mai in quale forma saremo contorti, quindi pensiamo in termini di flessibilità. In qualsiasi soluzione aziendale si scelga, l'inserimento di un premio sulla flessibilità è un criterio di successo.

• Non abbandonare tutto il team di implementazione quando si entra in funzione.

  Mantenere le risorse chiave in futuro. Si tratta di una sfida estremamente comune. Spesso in una distribuzione aziendale, l'organizzazione è attirata dall'assegnazione delle risorse più esperte e qualificate e questo certamente aiuta a selezionare e implementare il sistema. Tuttavia, queste risorse sono proprio quelle che saranno necessarie per il prossimo progetto critico e probabilmente saranno tirate fuori da questo proprio come il sistema va in diretta ed è al suo momento più critico. Pianificare in anticipo che determinate risorse chiave rimangano con l'implementazione per un periodo più lungo può fare un'enorme differenza.

• Creare un team permanente di miglioramento del sistema, piccolo forse, ma abile.

  Il team che assembla i requisiti per il sistema aziendale esamina i processi aziendali, le funzionalità del sistema, l'integrazione con altri sistemi aziendali chiave e altro ancora. L'abbandono del sistema da parte di queste persone una volta installato rende l'evoluzione futura molto difficile. Mettere questo sistema aziendale e forse altri sistemi correlati in una cura evolutiva a lungo termine in cui le esigenze dell'organizzazione e le funzionalità del sistema vengono valutate regolarmente.

Imparare dall'uso effettivo

• Portare il sistema in produzione in anticipo.

  Questo è molto più facile nel mondo di oggi rispetto a 5 anni fa. È possibile sfruttare le installazioni basate sul cloud e i servizi accessibili in remoto per far funzionare rapidamente il sistema. La maggior parte dei sistemi aziendali che dispongono di offerte cloud e locali ha metodi di evoluzione da uno all'altro. Questo è certamente vero con Project Server. È vero anche per i nostri sistemi.

• Assicurarsi che sia presente un ciclo di feedback che comporta un miglioramento del sistema.

  È bello vedere cose che possono essere migliorate, non male. Alcuni team di implementazione scoraggiano i suggerimenti per il miglioramento, preoccupati che impediranno agli utenti di usare il sistema già distribuito. La nostra esperienza è che coloro che fanno suggerimenti per il miglioramento sono di solito i più grandi alleati del sistema aziendale. Anche se un'idea non può essere implementata immediatamente, deve essere accolta con favore. La creazione di un sistema per identificare e incoraggiare nuove idee per il sistema aziendale mantiene tutti investiti e può portare enormi vantaggi.

• Non abbandonare la speranza troppo velocemente.

  Alcune aziende diranno "Il problema è nel software" e jump ship prima che ci sia una possibilità di successo.

Sono stati raggiunti gli obiettivi prefissati?

Allora, quando ci arriviamo?

Speriamo di non esserlo mai.

Questo non significa che le stazioni lungo la strada non saranno ottimi posti in cui fermarsi. Il primo obiettivo per una nuova implementazione di software aziendale, ad esempio un progetto aziendale o un sistema di schede attività aziendali, deve essere un ambiente di produzione che offre un ritorno positivo sull'investimento. Cercare un sistema che possa essere distribuito in livelli o fasi e con flessibilità sufficiente per crescere, adattarsi e cambiare e probabilmente lungo il percorso si troverà più produttività di quella che si potrebbe trovare in attesa di scegliere la destinazione perfetta.

Informazioni sull'autore

Chris Vandersluis è il presidente e fondatore di Montreal, HMS Software, un partner microsoft certificato. Ha una laurea in economia presso la McGill University e oltre 30 anni di esperienza nell'automazione dei sistemi di controllo del progetto. È un membro di lunga data del Project Management Institute (PMI) e ha contribuito a fondare i capitoli di Montreal, Toronto e Quebec del Microsoft Project Users Group (MPUG). Le pubblicazioni per le quali Chris ha scritto includono Fortune, Heavy Construction News, computing Canada magazine, e PMNetwork di PMI, ed è un giornalista regolare per Project Times. Insegna Advanced Project Management alla McGill University e spesso parla alle funzioni dell'associazione di gestione dei progetti in America del Nord e in tutto il mondo. HMS Software è l'editore del sistema timekeeping orientato al progetto TimeControl ed è partner di Microsoft Project Solution dal 1995.

Chris Vandersluis può essere contattato via e-mail all'indirizzo: chris.vandersluis@hms.ca

Per altre informazioni sugli articoli correlati a EPM di Chris Vandersluis, vedere il sito guida EPM di HMS (https://www.epmguidance.com/?page_id=39).