Acquistare soluzioni

Questo articolo fa parte della nostra raccolta "From the Trenches". Descrive in che modo i potenziali acquirenti di software possono rendere più efficaci le interazioni con i fornitori di software applicando metodi di analisi aziendale facilmente comprensibili. A tale scopo, viene presentato un esercizio utile per creare criteri di valutazione del software determinando i problemi che devono essere gestiti dalla soluzione software.

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

Essere un acquirente di soluzioni

Troppo spesso, un acquisto di software si basa su un elenco di funzionalità, una campagna pubblicitaria o una raccomandazione di un amico. Questo articolo descrive in che modo i potenziali acquirenti di software possono rendere più efficaci le interazioni con i fornitori di software applicando metodi di analisi aziendale facilmente comprensibili.

È sicuro che non è come una volta. L'uso del software in un'impostazione aziendale non viene più definito installazione. Al giorno d'oggi, i termini implementazione o distribuzione descrivono meglio ciò che è necessario per rendere operativo un nuovo pacchetto.

Sempre più fornitori di software parlano di ciò che vendono come soluzioni, e non c'è da meravigliarsi. Quando pensiamo alla distribuzione di un sistema aziendale come Microsoft Project Server o Microsoft CRM, dobbiamo prima pensare ai diversi livelli di tecnologia che saranno coinvolti e, prima ancora di arrivare a questo, dobbiamo pensare all'impatto sul nostro business complessivo.

Con le soluzioni da vendere arriva, naturalmente, le vendite di soluzioni. Se hai seguito questa procedura, sai che quasi tutte le organizzazioni ad alta tecnologia del pianeta che si rivolge a organizzazioni di medie e grandi dimensioni stanno lavorando per ricreare se stessa come deliverer di soluzioni di vendita. Microsoft è sicuramente tra queste organizzazioni. Microsoft ha lavorato a lungo negli ultimi anni per stabilire soluzioni di vendita come principio guida nelle sue forze di vendita e implementazione sul campo.

Che cos'è un venditore di soluzioni? È vero che sono ancora venditori. Tuttavia, i venditori di soluzioni mirano non solo a spostare una scatola di software, ma a creare qualcosa che aiuta il cliente a migliorare la loro situazione.

Sembra grande finora; un Nirvana di venditori tutti cercando di migliorare il vostro lotto nella vita. Ma questo comporta una sfida, e affrontare tale sfida è qualcosa a cui l'utente, il potenziale cliente, può partecipare.

Concentrarsi sul problema

La sfida che la maggior parte delle soluzioni devono affrontare i venditori quando arrivano sul mercato è il nostro preconcetto su come dovrebbe apparire una soluzione. Siamo così abituati a concentrarci sulle funzioni e le funzionalità del software, quando parliamo con un venditore di software la conversazione porta quasi inevitabilmente direttamente a: "Il tuo software può farlo? Il software può farlo?" I venditori esperti di software, e questi sono i tipi che vengono spostati in posizioni di vendita di soluzioni, sono così abituati a vendere funzioni e funzionalità che spesso dimenticano di porre la domanda più semplice di tutti: "Qual è il problema?"

Ora questo può sembrare sciocco, ma se si pensa alle ultime conversazioni con i venditori di software, si potrebbe essere sorpresi di quanto raramente questa domanda viene fuori. Fornitori come Microsoft e i suoi partner ricevono ogni anno molte richieste di proposte. Ne ho viste centinaia nel corso degli anni, e una cosa che è quasi sempre presente è una lunga griglia di funzioni che il fornitore dovrebbe compilare. Questo foglio di calcolo di grandi dimensioni è spesso il nucleo della risposta al client.

Ciò che raramente è presente è una descrizione delle esigenze aziendali che verranno affrontate da ognuna di queste funzioni. È così facile essere coinvolti in una funzionalità che abbiamo familiarità con un prodotto precedente o che abbiamo visto promosso da qualche parte che ci vuole una vera disciplina per concentrarsi su ciò che ci ha interessati a questo nuovo prodotto in primo luogo. Ciò può essere particolarmente importante in un ambiente aziendale in cui è presente molto input nel tipo di soluzione che si sta cercando. È molto più facile inviare una richiesta che chiede agli utenti di elencare tutte le funzioni che desiderano in un nuovo sistema software piuttosto che parlare delle loro particolari esigenze aziendali.

Se stai iniziando a pensare che forse ti sei perso qualcosa di ovvio, non sei solo. Questa condizione è così diffusa nel settore del software al momento che è nata una nuova categoria di consulente chiamata Business Analyst. Queste persone sono addestrate per stabilire la connessione dalle esigenze aziendali alla funzionalità software. Verranno ora necessari alcuni minuti per vedere come applicare i concetti di base, nel modo in cui un business analyst li applica, nelle valutazioni del software a livello aziendale.

Identificazione delle esigenze aziendali

La prima cosa a cui pensare è ciò di cui l'azienda ha bisogno ti ha portato a cercare un nuovo sistema software in primo luogo. La nostra organizzazione spesso consulta le aziende sull'implementazione di software di gestione dei progetti aziendali. Quando arrivo in un'organizzazione come consulente, molto prima di parlare se acquistare software, chiedo come l'organizzazione sta facendo la gestione dei progetti in questo momento.

Quando terminano la loro risposta, faccio sempre questa domanda di follow-up: "Questo metodo funziona per te?" Sorprendentemente, il client spesso risponde che è. Per me la conversazione di implementazione deve fermarsi qui. "Se non c'è alcun problema", spiego, "non c'è modo per me di creare una soluzione!" Spesso questa risposta rende le persone in pausa. "Perché siamo stati chiamati?" Glielo chiedo. Le risposte possono variare notevolmente, e non è raro che le persone guardino intorno alla stanza rendendosi conto che ci sono diversi programmi in corso che devono essere riconciliati – e la nostra conversazione ha meno di cinque minuti!

Quindi, chiedere "Qual è il nostro bisogno di business?" è un ottimo punto di partenza. C'è quasi sempre un obiettivo complessivo che risponde a questa domanda, un obiettivo che ha avviato l'iniziativa in primo luogo.

Esecuzione di un esercizio di visione

Successivamente sarà necessario esaminare un po 'più a fondo ciò che questo significa in termini di funzionalità software. Quando implementiamo software di gestione dei progetti aziendali come Microsoft Project Server in un'organizzazione, iniziamo sempre con un esercizio di visione che coinvolge il personale chiave, coloro che valutano il software, e i dirigenti senior, che sponsorizzano l'esercizio. Non è sufficiente eseguire questo esercizio con solo personale tecnico, perché l'obiettivo di questo esercizio è connettere gli obiettivi aziendali alle funzioni tecniche.

Ecco un modo efficace per eseguire questa operazione: inserire il personale chiave in una stanza con una grande lavagna. Dividere la lavagna in 4 colonne: iniziare con un'intestazione solo nella colonna all'estrema destra. Chiamarlo "Decisione aziendale".

Nella colonna corretta verranno elencate le decisioni aziendali che si spera di prendere usando il nuovo sistema che si sta valutando. Quando si esegue questa operazione con un client, la prima cosa che le persone vogliono fare è elencare un sacco di funzionalità, quindi dovrai insistere sul fatto che le risposte importanti sono decisioni aziendali. Ad esempio, un partecipante può immediatamente dire: "Ho bisogno di un elenco di tutte le risorse e del relativo carico di lavoro". Questo può essere vero, naturalmente, ma quello che devi scoprire è quale decisione aziendale renderanno con quell'elenco.

Alcuni esempi di decisioni aziendali possono essere:

• Assunzione o licenziamento in un particolare reparto

• Prendere una decisione go o no-go su un progetto

Una volta che hai un elenco decente di decisioni aziendali, pausa. Ora è un buon momento per esaminare l'elenco delle decisioni aziendali e identificare le decisioni con priorità principale. Potrebbe essere utile porsi questa domanda: se si potessero ottenere risposte solo per una di queste decisioni aziendali, che offrirebbe il massimo valore all'organizzazione? Scegliere le prime tre decisioni è sempre più semplice a questo punto del processo.

Se si è arrivati a questo punto, sono già state eseguite più operazioni rispetto alla maggior parte delle organizzazioni che cercano software di gestione dei progetti aziendali. Essere in grado di fornire un elenco con priorità delle decisioni aziendali più significative per i fornitori di sistemi è un enorme passo avanti per l'intero processo. Quando è possibile indicare ai fornitori di sistema quali decisioni aziendali è necessario prendere, hanno il potere di andare oltre a parlare di semplici funzionalità per parlare di come rendere l'organizzazione più efficace.

Esaminare quindi ogni decisione e chiedere: "Per prendere tale decisione aziendale, quale report è necessario?" Praticamente ogni decisione viene presa dopo aver esaminato uno o più report. Etichettare la terza colonna "Report". Per ognuna delle prime tre decisioni, elencare in tale colonna i report necessari per la decisione corrispondente.

Ad esempio, per determinare se assumere o licenziare personale per un particolare reparto, è necessario un report per reparto che mostri i dati di pianificazione della capacità delle risorse. Sono incluse una previsione in avanti del carico di lavoro previsto, la disponibilità prevista delle risorse e la pianificazione. Se sei un'azienda di medie dimensioni, anche il flusso di cassa potrebbe essere un problema. Si potrebbe, ad esempio, avere bisogno di personale aggiuntivo, ma non essere in grado di trovare il denaro per assumerli. Il report sul flusso di cassa includerebbe i redditi stimati e i flussi in uscita di denaro con un saldo corrente.

Se si compila la colonna Report per ognuna delle decisioni identificate come priorità, la forma di ciò che verrà richiesto inizia già a diventare chiara. Al termine, è disponibile un elenco di output fisici richiesti dal sistema futuro.

Sospendere di nuovo qui per scoprire se sono già presenti report del tipo identificato già in uso nell'organizzazione. È probabile che tali report esistano, ma in numerosi formati e possibilmente con dati incompleti o con un eccessivo sforzo necessario per generarli. Se si trovano formati di report che hanno funzionato nell'organizzazione, è possibile aggiungerli all'elenco dei requisiti di sistema. Ora è possibile fornire ulteriori informazioni ai fornitori di sistema.

Dopo aver identificato i report chiave, è possibile passare agli elementi di un sistema necessario per generare tali report. Aggiungere l'intestazione "Analysis" alla seconda colonna del grafico. Per ogni report, identificare le analisi o gli algoritmi necessari per generare il report. Ad esempio, per un report di pianificazione della capacità delle risorse, potrebbe essere necessaria una pianificazione del percorso critico dal sistema di gestione dei progetti e un'analisi del livellamento delle risorse.

Queste analisi saranno spesso commercializzate dai fornitori sulla base della miriade di funzionalità che ognuna include. (Sì, la vendita di funzionalità per funzionalità è ancora viva e ben!) Ciò che è necessario essere in grado di determinare è la funzionalità minima che fornirà i report necessari con cui è possibile quindi prendere o migliorare la decisione aziendale identificata. Si potrebbe essere sorpresi di quanto siano di base le funzionalità necessarie per soddisfare i requisiti aziendali effettivi. Per alcuni report, non sarà necessaria alcuna analisi o calcolo; i report devono essere solo aggregazioni semplici che possono essere generate direttamente dai dati del nuovo sistema.

Infine, si arriva alla prima colonna del grafico. Dopo aver identificato le analisi necessarie, è possibile passare a determinare quali elementi di dati sono necessari per alimentare le analisi.

Aggiungere l'intestazione "Input" alla prima colonna del grafico.

Nell'esempio in uso, potrebbe essere necessario un elenco completo delle attività per ogni progetto implicato nel lavoro del reparto. Questo potrebbe benissimo essere ogni progetto nell'organizzazione. Sarà anche necessario un profilo completo della disponibilità di ogni risorsa insieme al carico di lavoro definito per ogni attività in modo che quando l'attività si sposta nell'analisi della pianificazione, il carico di lavoro si sposta nell'analisi del livellamento delle risorse. Inoltre, ricordate come abbiamo iniziato con la decisione di assumere o sparare in un particolare reparto? Sarà anche necessario essere in grado di identificare le risorse in base al reparto.

È possibile spostarsi in questo modo dagli output a destra agli input a sinistra fino a quando non sono stati identificati tutti gli elementi necessari nel nuovo sistema aziendale.

Valutazione dei rischi

Al termine di questo esercizio, vale la pena tornare a ognuno degli input e determinare la disponibilità di questi elementi di dati. È possibile che, come spesso accade, alcuni di questi elementi non esistano. Ad esempio, alcune organizzazioni non mantengono un elenco completo della disponibilità delle risorse. Si potrebbe anche notare che non tutti i progetti hanno una pianificazione caricata dalle risorse che mostra il carico di risorse generato da tale progetto. In molte organizzazioni alcuni tipi di progetti non vengono inseriti in un sistema di alcun tipo. Il lavoro di emergenza, il lavoro di supporto tecnico o il normale lavoro di manutenzione sono alcuni esempi comuni.

Se non si ha accesso ai dati fondamentali necessari per fornire il valore aziendale, è necessario considerare tale elemento del sistema come ad alto rischio. Ad esempio, se si rileva che è possibile identificare pianificazioni caricate dalle risorse per l'80% dei progetti dell'organizzazione, è ragionevole aspettarsi di migliorare la decisione aziendale di aumentare o ridurre il personale? La risposta è probabilmente "No". Perché? Perché forse il 20% dei progetti che non sono nel sistema potrebbe rappresentare l'80% del carico di lavoro per un particolare reparto. Se non si dispone di tutti i dati, non si saprà mai se il report finale è accurato.

Ci sono modi per aggirare questo tipo di problemi, naturalmente. Un metodo consiste nell'isolare tutti i processi aziendali di quegli aspetti dell'organizzazione in cui non è possibile ottenere l'accesso agli elementi dati. Una divisione i cui progetti potrebbero non essere presenti nel sistema non includerebbe nemmeno le risorse. Questo non può essere fatto semplicemente in ogni caso; dovrai cercare elemento per elemento per capire quanto rischio sono i processi aziendali e le decisioni aziendali per l'implementazione. Non è raro a questo punto del processo assegnare nuovamente la priorità alle decisioni aziendali finali che si spera di migliorare. È possibile che si abbia una decisione molto auspicabile, ma che si rivela molto rischiosa e quindi non vale la pena perseguirla nelle prime fasi della distribuzione.

Documentazione delle operazioni eseguite

Quando si conduce questo tipo di riunione, assegnare uno scriba, qualcuno il cui compito sarà quello di registrare note e commenti durante tutto il processo. I motivi per cui una determinata decisione aziendale è stata classificata come priorità alta o bassa o perché qualcosa è stato considerato ad alto rischio verranno rapidamente dimenticati se non si hanno buone note a cui fare riferimento.

È molto importante registrare:

• Cosa hai scritto sulla lavagna

• Chi ha partecipato al processo

• Chi è proprietario di ogni decisione aziendale finale

Se ti senti sopraffatto a questo punto, non temere. L'intero esercizio può essere eseguito molto rapidamente, anche nelle organizzazioni più grandi. Non è raro essere in grado di completare l'intero processo in un giorno o forse due. La chiave per avere successo è ottenere il giusto livello di gestione nella stanza. Inoltre, questo tipo di riunione è meglio facilitato da qualcuno esterno all'organizzazione che non è predisposta a fare le cose nel modo in cui sono sempre state fatte.

La conoscenza è potere

Se si stanno esaminando i sistemi di gestione dei progetti aziendali, in effetti, i sistemi aziendali di qualsiasi tipo, il completamento di questo esercizio offre un'enorme quantità di potenza quando si interagisce con i fornitori di sistemi software. È possibile distinguere immediatamente tra gli elementi di un sistema importanti per l'utente e quelli che non lo sono. I fornitori di software possono essere forniti con l'elenco di report e decisioni che si desidera prendere.

Si potrebbe essere sorpresi di alcune delle risposte che tornano a voi dai fornitori. Liberati per rispondere in modo diverso da funzionalità per funzionalità, ovvero cercando di adattare una funzione quadrata a un requisito rotondo, i fornitori migliori saranno in grado di mostrarti come rispondere alle tue sfide aziendali usando i loro sistemi al massimo vantaggio.

Ecco il vantaggio principale dell'esecuzione di questo esercizio: sono stati creati criteri di valutazione pronti. Ora, durante la fase di verifica del concetto, è possibile concentrarsi immediatamente sul fatto che il sistema fornisca le informazioni necessarie per migliorare le decisioni aziendali che è necessario prendere.

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).