Difficoltà nella selezione del software aziendale
Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive in che modo le implementazioni di sistema aziendali devono essere in grado di adattarsi ed evolversi per avere successo.
Per scaricare la versione Word di questo articolo, vedere Le sfide della selezione del software aziendale.
Per altri articoli, vedere white paper "From the Trenches".
Le sfide della selezione del software aziendale
Succede da queste parte tutto il tempo. Un client invia una "Richiesta di proposta" (RFP) all'ufficio con le istruzioni per completare una risposta in pochi giorni o settimana e inviarla per fare in modo che il sistema aziendale venga considerato per l'acquisto. Le richieste RFP sono praticamente tutte uguali. In genere è disponibile una breve panoramica, istruzioni su cosa è necessario fare per prendere in considerazione la risposta, incluso il modo in cui deve essere formattata e quando inviarla e così via. Poi c'è una lunga griglia di funzionalità che sono necessarie e una serie di domande di saggio aggiuntive per scrivere risposte.
La sfida con le richieste RFP è che non erano ideali per la selezione del software aziendale e ciò che ne consegue quando viene seguito un processo RFP non garantisce le decisioni migliori per l'organizzazione. Gli RFP sono stati progettati dalla comunità di acquisto come un modo per ottenere la migliore merce al miglior prezzo e fanno ancora un ottimo lavoro di questo. Quando le offerte sono confrontabili, il processo decisionale può concentrarsi sul prezzo migliore con una o due variabili aggiuntive (ad esempio le date di spedizione) da affrontare. Quando le possibili soluzioni sono nella stessa categoria generale ma non sono affatto confrontabili (come nel caso del software aziendale), il numero di variabili che devono essere considerate dagli acquirenti è enorme e il processo RFP non aggiunge valore alla selezione. Il modo in cui la maggior parte delle aziende seleziona il software aziendale Iniziamo esaminando il processo che si verifica sempre in qualsiasi fornitore o fornitore di soluzioni di software aziendale. Parlerò del software di gestione dei progetti aziendali o del software della scheda attività aziendale come fornisce la mia azienda, ma il paradigma è lo stesso per praticamente qualsiasi selezione di sistema aziendale.
Selezione del software aziendale da parte della maggior parte delle aziende
Si inizierà esaminando il processo che si verifica sempre in qualsiasi fornitore o fornitore di soluzioni di software aziendale. Parlerò del software di gestione dei progetti aziendali o del software della scheda attività aziendale come fornisce la mia azienda, ma il paradigma è lo stesso per praticamente qualsiasi selezione di sistema aziendale.
Nella maggior parte delle organizzazioni, l'impulso alla ricerca di software aziendale deriva da qualche problema. Forse il problema è emerso dal personale sul campo. Forse il problema è identificato da qualcuno nella dirigenza senior. Tuttavia, l'iniziativa deve ottenere il supporto di un dirigente senior. La selezione di base di un sistema che influirà sull'intera impresa è una fantasia anche nelle organizzazioni più progressiste. Quindi un senior manager decide: "Abbiamo bisogno di questo tipo di sistema aziendale".
Il tipico processo di selezione del software aziendale è simile al seguente:
La gestione dice che abbiamo bisogno di un nuovo sistema aziendale
Project manager è selezionato
Richiedere richieste da tutti i reparti coinvolti
Unire tutte le richieste in un unico foglio di calcolo di grandi dimensioni
Inviare la griglia dei requisiti a molti fornitori
Ottenere molte risposte
Elenco breve
Guarda le dimostrazioni
Negoziare
Ottenere l'accettazione della gestione
Fare in modo che la gestione decida su qualcos'altro
Un project manager per lo sforzo di selezione è volontario. Lui o lei fa quello che facciamo tutti: andare su Internet, caricare un motore di ricerca e digitare "Software EPM" (o qualsiasi sistema aziendale sia desiderato). Immediatamente vengono restituiti mezzo milione di riscontri. Forse il responsabile del progetto diligente naviga la prima dozzina o così per scoprire che tipo di sistemi potrebbero essere disponibili prima di procedere. Chiaramente nessuno ha il tempo di navigare attraverso mezzo milione o più colpi per vedere se forse l'ultimo è il sistema ideale per l'organizzazione.
Imperterrito, il responsabile del progetto riunisce ora un comitato di selezione tra coloro che saranno interessati dall'implementazione di questo nuovo sistema aziendale. Alcuni di coloro che fanno parte del comitato possono provenire da personale sul campo che ha identificato la necessità nell'organizzazione in primo luogo. Altri potrebbero non essere. Può esserci una combinazione di persone in questo comitato di selezione che hanno interessi diversi nel tipo di sistema che verrà selezionato.
Lo sfortunato project manager ora sollecita ogni membro del comitato a eseguire il polling del proprio gruppo rappresentativo per ciò che richiede nel nuovo sistema aziendale. Come fa ogni rappresentante del comitato a farlo? Beh, prima di tutto, non tutti fanno lo stesso sforzo, ma per coloro che fanno i compiti, chiedono al loro personale di inviare un elenco di funzionalità che avrebbero trovato importanti. Poi, anche loro, colpire internet e navigare alcuni siti Web fornitore. Possono copiare e incollare da funzionalità che vedono nelle brochure di questi siti in quanto ogni sito dà loro nuove idee su quali tipi di richieste potrebbero essere in grado di fare di un nuovo sistema.
Ora il comitato viene riassemblato e il lungo foglio di calcolo di ogni membro del comitato viene unito con gli altri in un unico foglio di calcolo massiccio. Il mega foglio di calcolo dei requisiti è categorizzato, ma ci sono problemi. In primo luogo, le diverse esigenze della commissione diventano ora più evidenti in quanto le caratteristiche sono richieste da un'ampia gamma di prospettive. Possono esserci membri del comitato in reparti diversi, ma anche in paesi/regioni diversi o anche in divisioni diverse. C'è quasi sempre una richiesta in conflitto con un'altra richiesta nello stesso elenco (ad esempio, il sistema deve essere molto semplice e non avere molte richieste e il sistema dovrebbe essere molto flessibile con un numero elevato di opzioni per ogni utente).
Infine, il foglio di calcolo combinato che i fornitori vedranno è completo. Ha centinaia di richieste di funzionalità e per ognuna il fornitore dovrebbe dire "Sì", "No" o "Sì con un certo sforzo". Un sistema di ponderazione può anche essere collegato per dire se questa funzionalità è un "Must-have", un "Importante-da-avere" o un "Bello da avere".
L'RFP è quasi pronto per l'uso. Ci saranno alcune domande di saggio, in genere sull'architettura tecnica della selezione e, a seconda del numero di persone sottoposte a polling su questi requisiti, le richieste di architettura possono essere ugualmente in conflitto (ad esempio, il sistema deve avere tutti i dati archiviati centralmente nel database SQL Server ,e il sistema deve consentire l'archiviazione locale di tutti i dati sul computer dell'utente).
In realtà, sembra abbastanza buono finora, non credi? Dopo tutto, verrà restituita una serie di risposte dei fornitori che mostrano chi può offrire tutte le funzionalità necessarie. In realtà, sembra abbastanza buono finora, non credi? Dopo tutto, verrà restituita una serie di risposte dei fornitori che mostrano chi può offrire tutte le funzionalità necessarie.
Ma in realtà c'è un problema fondamentale con quello che ho descritto finora: un problema che non si verifica quando si usa il processo RFP per una merce piuttosto che per un sistema aziendale. È questo: un sistema aziendale è una soluzione a qualcosa. Ma finora non abbiamo detto niente sul problema. Questo è un evento così comune che l'industria tecnologica è venuto ad accettarlo come normale e accettabile.
Perché la selezione di software aziendale in questo modo non funziona
Gli acquirenti usano questo metodo da decenni e nessuno lo mette in discussione, ma le persone nel business del software aziendale sanno che c'è un problema fondamentale con il metodo RFP classico di selezione del software aziendale.
Prima di tutto, solo perché hai un elenco enormemente lungo di funzionalità, non significa necessariamente che sei più vicino a risolvere un problema aziendale. In effetti, se non hai ancora articolato quali problemi aziendali specifici stai cercando di risolvere, allora probabilmente rendere le cose più complesse e, in ultima analisi, peggiori, non migliori. Il processo RFP è stato progettato per l'acquisto di materie prime. Quando abbiamo prodotti omogenei come scarpe, patate o zucchero, l'acquisto di questi articoli in questo modo può comportare il prezzo più basso e la migliore selezione tra i possibili fornitori. Le risposte a un RFP per una merce simile rendono molto semplice il confronto tra i fornitori possibili. Quando le variabili per ogni prodotto nella combinazione sono infinite (così come sono con il software aziendale), le risposte al rfp hanno anche un numero infinito di variabili e il processo restituisce risultati con un valore minimo.
Quando si usa il metodo RFP per selezionare i sistemi aziendali, le richieste RFP hanno per lo più lo stesso aspetto. Questo perché sono tutti creati in risposta allo stesso stimolo. Il project manager richiede un elenco di "ciò di cui avrai bisogno in questo sistema aziendale" e l'unico vocabolario che la maggior parte dei responsabili intermedi deve rispondere a tale richiesta è un elenco di funzionalità. Di conseguenza, le risposte alle richieste RFP sono tutte uguali. Sono un elenco di controllo di tutte le funzionalità disponibili come parte del sistema o come parte del sistema con un certo sforzo.
Ciò che è più comune per i team di selezione è che riceveranno una serie di risposte alle loro RICHIESTE RFP, passeranno attraverso le centinaia di pagine e, al termine, non si sentiranno più vicini a una soluzione rispetto a quando hanno iniziato. Questo è terribilmente frustrante per gli acquirenti che si sono impegnati enormemente a creare quella che dovrebbe essere una richiesta equa di proposta e a valutare le risposte solo per scoprire che l'esercizio è stato per nulla.
Peggio di tutto questo è che i venditori aziendali esperti sanno che il processo produrrà risultati frustranti e sono al lavoro dal momento in cui sentono che ci sarà un RFP creato. Non stanno lavorando alla risposta RFP. Non è rilevante. Invece, stanno lavorando due o tre livelli più alti nella struttura di gestione, cercando l'impulso originale che ha avviato la RFP. Cercano il senior executive che ha articolato alcune sfide aziendali e ha messo in moto le ruote in modo che gli acquirenti e altri quadri avrebbero infine creato la RFP e inviarla ai fornitori.
Quando le risposte RFP finiscono senza una risposta chiara ai problemi aziendali che non sono quasi mai articolati all'interno del processo di acquisto, il venditore dell'azienda è pronto a intervenire, avendo un senior executive bypassare del tutto il processo e selezionare un sistema basato sul proprio rapporto personale con il venditore dell'azienda senior.
Se pensi che questo sembri stanco, ti sbagli. In effetti, è possibile fare un caso migliore per avere software selezionato attraverso le relazioni personali a livello esecutivo di quanto si può per l'acquisto attraverso il processo RFP.
Ma che dire di un modello di prova o pilota?
Quindi, sappiamo che il processo di acquisto classico è difettoso quando lo applichiamo all'acquisto di software aziendale. In questo caso, come scegliere il software aziendale, ad esempio un sistema di gestione dei progetti aziendali? Un metodo comune consiste nell'usare il metodo proof of concept o fase pilota.
Questi due termini vengono spesso usati come sinonimi, quindi iniziamo parlando di ciò che è un modello di prova o una distribuzione pilota.
Modello di verifica. In un modello di verifica, la potenziale organizzazione distribuisce il software aziendale in modo limitato al fine di dimostrare che può raggiungere una sfida tecnica in cui c'è qualche domanda sulla capacità della soluzione di superare tale sfida. Un esempio potrebbe essere per il volume di dati. "Siamo preoccupati che il prodotto potrebbe non essere in grado di gestire tutte le attività che abbiamo per progetto. Vorremmo che tu arrivassi con il software, prendessi due o tre progetti di esempio con 500 attività ognuna e ci mostrassi come questi possono essere caricati nel software e che il software può ancora eseguire le sue funzioni di base con questo volume in esso.
Fase pilota. Una fase pilota è un'installazione del software aziendale, ma con un ambito limitato. Una distribuzione pilota potrebbe essere destinata a un subset di utenti; ad esempio solo 10 su 1000 persone useranno completamente il software per un periodo di quattro settimane. In alternativa, potrebbe trattarsi di una sottosezione della funzionalità o di un subset del volume di dati; Ad esempio, verranno caricati solo 10 progetti su 500.
Come viene usato il modello di verifica o la fase pilota? Il problema che si verifica spesso è come viene applicata la fase pilota o il concetto di prova. È piuttosto raro quando una potenziale organizzazione chiama e ci chiede una proposta di proof of concept e può anche identificare quale concetto tecnico deve essere dimostrato. "Cosa speri di dimostrare e come saremo in grado di misurare che l'abbiamo dimostrato?", chiediamo.
Ciò che è più comune è che qualcuno nel middle management ha identificato un pezzo di software aziendale che spera possano rendere la loro vita più facile nella loro organizzazione. La direzione senior non è affatto coinvolta e il personale del middle management non ha nemmeno articolato le sfide aziendali che stanno cercando di superare. È loro speranza che se la soluzione fosse solo nell'edificio, che la prossima volta che qualcuno del management si aggirasse lungo il corridoio, vedrebbe "accidentalmente" la soluzione in funzione e darebbe immediatamente la benedizione a una distribuzione aziendale. Per prendere in prestito una frase del film Field of Dreams, "Se la costruiamo, verranno".
Raramente ha successo. Il problema con il software aziendale è che è necessario il coinvolgimento del senior management per rendere la distribuzione un successo. Sarà il senior management a essere i "clienti" dei report e dell'analisi di questo sistema aziendale. È il senior management che dovrà investire personalmente per consentire a una gamma di personale il tempo necessario per progettare, configurare e essere addestrato nel software aziendale. È il senior management che dovrà accettare o addirittura contribuire a riprogettare i processi aziendali che fanno parte di qualsiasi distribuzione di sistema aziendale. Senza la direzione senior che dà non solo la loro benedizione, ma anche il loro supporto implicito e l'assistenza diretta, nessuna prova di concetto aiuterà.
Questo vale anche per una fase pilota. Se l'azienda non si è impegnata dal massimo livello a risolvere alcuni problemi aziendali tramite l'uso di software aziendale, l'introduzione di una fase pilota non è produttiva.
Ciò non significa che le fasi pilota di una distribuzione non abbiano posto. Hanno un punto critico in una distribuzione riuscita. Tale luogo è immediatamente dopo il completamento della decisione di acquisto e la progettazione del sistema aziendale è stata completata. Ora una fase pilota è un luogo ideale per testare la progettazione del sistema aziendale e ottimizzarla per la distribuzione generale.
Quando viene eseguita una fase pilota nella speranza che vedere il software in azione comporterà la selezione da parte della gestione, allora abbiamo un pilota inefficace e non avremo più avanti nel processo di selezione.
In che modo le organizzazioni devono selezionare il software aziendale?
I sistemi aziendali vengono acquistati da organizzazioni di medie e grandi dimensioni ogni giorno e, anche se il metodo RFP potrebbe non essere il più efficace, esistono diversi metodi per selezionare il software aziendale che sono molto efficaci. Ecco alcuni suggerimenti per creare un processo di selezione aziendale efficace.
Articolare il problema. Innanzitutto, articolare il problema. Ciò significa che il senior management deve essere coinvolto e il problema da articolare è un problema aziendale, quindi deve essere articolato in termini aziendali. Una buona domanda da porsi è: "Quale decisione aziendale non possiamo prendere ora o possiamo prendere solo con grande difficoltà, il cui processo potrebbe essere facilitato con la distribuzione di questa soluzione di sistema aziendale?"
È possibile che si desideri risolvere una serie di problemi aziendali con l'uso di questo sistema aziendale.
Concedere ai fornitori una certa latitudine per creare la soluzione. Dopo aver articolato il problema aziendale o i problemi, contattare i fornitori possibili e assicurarsi che l'accesso al senior management che ha assistito nel processo sia trasparente. Le riunioni dei fornitori "segreti" con il senior management diventano impossibili quando la gestione fa parte del processo fin dall'inizio. Lasciare che i fornitori comprendano il problema e diano loro una certa latitudine per rispondere. È possibile scoprire di più sull'organizzazione per spiegare in che modo queste sfide aziendali influiscono su di te di quanto tu possa immaginare e vedrai sicuramente una gamma molto più ampia di possibili soluzioni al tuo problema quando non provi a descrivere la soluzione ai potenziali fornitori.
Quando si parla con i possibili provider di soluzioni, assicurarsi che comprendano che devono parlare sia con la tecnologia che con la sfida del processo aziendale. Non è mai stata una soluzione di sistema aziendale che non ha avuto alcun impatto sul processo dell'organizzazione. Se il provider di soluzioni non può essere d'aiuto per il modo in cui verrà influenzato il processo, si sta esaminando solo una parte della soluzione.
Vai a incontrare alcune persone. Quando si arriva a un paio di possibili provider di soluzioni, chiedere di parlare con alcuni dei loro client esistenti. Ancora meglio, vedere se il fornitore vi permetterà di andare a visitare alcuni dei loro clienti esistenti. I provider di soluzioni validi hanno spesso client che hanno avuto successo nelle proprie distribuzioni e che sono abbastanza generosi da avere tempo per incontrare potenziali clienti.
Si apprenderà di più da un paio d'ore con un cliente esperto della soluzione possibile di quanto si sarebbe mai appreso leggendo le risposte RFP o esaminando le dimostrazioni di vendita dei fornitori. Quando si chiede al fornitore possibili riferimenti client e visite al sito, si potrebbe pensare che l'azienda ideale da soddisfare sarebbe esattamente come la vostra. Non è sempre così.
È spesso estremamente prezioso incontrare aziende in altri settori correlati o in qualche modo simili al tuo. È anche possibile apprendere molto dalle organizzazioni più grandi o più piccole di te. Porre maggiore enfasi sull'esperienza dell'organizzazione con la soluzione piuttosto che sulla versione in uso o se sono delle dimensioni esatte o nel settore esatto in cui si sta usando.
Se hai la fortuna di visitare un client esistente, ricorda che non è il fornitore. Sii rispettoso, cortese e grato. Portare un piccolo regalo, forse di materiale promozionale logo aziendale è spesso ben apprezzato. Mentre si è con l'organizzazione o durante la comunicazione con i riferimenti al telefono, alcune possibili domande potrebbero includere:
Quale processo è stato usato per selezionare questa soluzione rispetto ad altri utenti?
Quale impatto ha avuto questa soluzione sui processi aziendali?
Qual è stato l'aspetto più complesso della distribuzione?
Qual è stato finora il più prezioso ritorno sugli investimenti?
Come si vede la soluzione evolvere da qui?
Non aspettarti solo risposte felici.
Un fornitore che non è completamente in grado di fornire riferimenti deve essere un po ' più sospetto di uno che ha un certo numero di clienti soddisfatti.
Infine, dopo aver effettuato la selezione, eseguire la distribuzione in fasi. In questa colonna sono disponibili altri articoli su come eseguire la distribuzione in una modalità in più fasi e in modalità big bang. Ciò ridurrà i rischi associati a qualsiasi distribuzione del sistema aziendale e consentirà di ottimizzare il processo di distribuzione man mano che il sistema si evolve.
Tenere presente che qualsiasi distribuzione del sistema aziendale è un processo dinamico. Non è una decisione una tantum con risultati felici che arrivano mese dopo mese per sempre. Le distribuzioni aziendali di maggior successo iniziano con una selezione che coinvolge il personale chiave che farà parte del processo di distribuzione dal più senior nel management al più tattico sul campo e continua attraverso l'evoluzione del sistema in fase dopo fase.
Una selezione efficace del sistema aziendale è solo la prima fase del processo.
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).