Vendiamo problemi, non soluzioni!

Di recente mi sono imbattuto in un'espressione interessante. Un venditore di software stava parlando di fornire l'intera soluzione al suo cliente. "Non vendiamo esercitazioni. Vendiamo buchi", ha detto. È una grande analogia. Molte persone (me incluso) sono andate al negozio di ferrateria e finestra shopped nel reparto strumenti di alimentazione, mentre mi chiedo quale progetto potrei pensare a quale giustificherebbe l'acquisto di questo grande strumento di potenza. Ma l'applicazione di questa logica ha tanto senso nel mondo fai-da-te quanto nei sistemi software aziendali.

Se non si ha un problema, non è necessaria una soluzione.

Proprio come nessuno dovrebbe andare alla ricerca di un drill a meno che il problema che vorrebbero risolvere è quello di fare un buco, nessuno dovrebbe andare alla ricerca di software aziendale a meno che non risolve qualche problema. Ora, se si ha un problema che la distribuzione di software aziendale risolverà, la cosa successiva per assicurarsi che ciò che si sta acquistando fornirà la soluzione necessaria. Questo è spesso molto di più che semplicemente l'acquisto del software.

La distribuzione di un sistema aziendale è una sfida complessa, quindi il payoff deve valere la pena. Nel mondo odierno dei team di progetto globali, una delle operazioni più comuni da eseguire consiste nel dividere l'enorme sforzo di una distribuzione di sistema aziendale. Anche se questo può darci economie di scala nell'uso di team altamente qualificati nel loro aspetto del progetto, essa presenta anche il rischio di ignorare gli aspetti del progetto in modo altamente rischioso. Questo rischio è aggravato dal fatto che, a livello fisico e organizzativo, i diversi team sono disconnessi.

Verranno ora esaminati gli elementi più comuni di un progetto di sistemi aziendali.

Che cos'è un'azienda?

Prima di tutto, cosa intendo per impresa? Prenderò una definizione che dovrebbe funzionare per quasi tutti. "Enterprise", in questo contesto, significa qualsiasi progetto che influirà sul funzionamento dell'intera organizzazione. Dirò che questo è vero per qualsiasi organizzazione. Le implementazioni che si qualificano come implementazioni aziendali non riguardano solo il numero di utenti, ma l'impatto che hanno. Quindi, l'aggiornamento del software di analisi antivirus dal fornitore A al fornitore B probabilmente non sarebbe qualificato. L'implementazione del software di pianificazione dei progetti sul desktop per una manciata di utenti probabilmente non si qualificherebbe. La centralizzazione della gestione dei progetti e l'uso di un sistema centralizzato di gestione dei progetti aziendali potrebbero essere qualificati.

Ok, quindi, se si tratta di un progetto aziendale, quali sono gli elementi più comuni di una distribuzione di un sistema aziendale? Nei nostri uffici l'esperienza più comune è la distribuzione di sistemi di schede attività aziendali, ad esempio timecontrol o sistemi di gestione dei progetti aziendali, come Microsoft Project Server, ma questi elementi saranno comuni a quasi tutte le implementazioni del sistema aziendale.

Bit e byte

Per prima cosa affrontiamo i blocchi predefiniti più fondamentali del software: l'architettura tecnica. In questi giorni è necessario dividere il pensiero in base alla decisione di procedere con una distribuzione locale o una sottoscrizione nel cloud. Lascerò le meraviglie di scegliere quale di queste è la migliore in quali condizioni per un altro giorno, ma ecco alcune delle nozioni di base di ciò che dovremo pensare in ogni categoria.

Se si sta usando un'installazione locale, è necessario considerare l'hardware che si userà. Quali sono i requisiti hardware per la memoria e le CPU? Si useranno server fisici o server virtuali? Si useranno server dedicati o condivisi? Quali tipi di server potrebbero essere necessari? Saranno necessari server applicazioni, server di sicurezza, server Web? Che dire del bilanciamento del carico, del ripristino di emergenza e dei backup? Saranno necessari server di backup a freddo o a caldo? Accidenti! Ma non abbiamo finito! E il database? Quali sono i requisiti? Che ne dite del supporto per le architetture di sicurezza, applicazione e database esistenti? Che dire del supporto per browser, versioni del browser e dispositivi mobili? Dopo aver risposto a tutte queste domande, è necessario gestire i problemi degli ambienti di installazione, test e produzione e quindi l'integrità e il monitoraggio del sistema dopo che il sistema è attivo e in esecuzione.

Se si sta usando un'implementazione di sottoscrizione nel cloud, sono ancora presenti domande a cui rispondere, anche se potrebbero essere domande molto diverse. Quale servizio online si usa? Si usa un'installazione dedicata o un servizio multi-tenant? E la sicurezza? È possibile eseguire l'integrazione con la propria autenticazione? Come si gestisce il ripristino di emergenza con il servizio di sottoscrizione? Dove si trovano fisicamente i dati? Questo presenta problemi legali per noi? Che ne dici del supporto per i nostri browser interni e dispositivi mobili? Come si ottengono i dati e come è possibile connettersi con database interni esterni o altri servizi SaaS (Software as a Service) esterni per integrare le funzionalità?

Ancora senza fiato? Quando si parla di un sistema aziendale, queste domande e altre sono all'ordine del giorno. Se spostiamo questa parte del nostro progetto al nostro team tecnico altamente qualificato, potrebbero iniziare a pensare a questo come all'ambito dell'intero progetto, quando questa è solo la costruzione della nostra esercitazione, non ancora la realizzazione del foro di cui abbiamo bisogno.

Configurare me!

Oltre a far funzionare il sistema, la funzionalità all'interno di tale sistema viene applicata anche ai problemi specifici. Sono state illustrate distribuzioni di Project Server in cui il client rende operativo Project Server e quindi si rende conto di non aver allocato alcun finanziamento per la creazione di flussi di lavoro, di apprendere come assegnare priorità al portfolio di progetti o di imparare a creare un singolo report. Proprio come Systems Analysis 101 al college, in genere iniziamo questa parte dell'implementazione all'estrema destra di una lavagna bianca mentre chiediamo agli uomini d'affari che hanno il problema aziendale effettivo di quali "output" avranno bisogno. Ne ho già parlato in altri scritti, quindi non lo farò qui, ma gli output dovrebbero essere decisioni aziendali. Per prendere queste decisioni, quali report, analisi e, in definitiva, input di dati sono necessari? Si lavora dal lato destro dello schermo a sinistra e si finisce con un elenco di tutti i blocchi predefiniti necessari sotto forma di elementi di dati, calcoli analitici ed esportazioni e report che dovranno essere configurati nel sistema. Questo esercizio di configurazione può richiedere settimane o mesi a seconda della complessità.

Spesso i tipi di risorse necessari per questo aspetto del progetto sono una combinazione di analista aziendale ed esperto di sistema ed è comune che, anche se queste persone possono essere altamente qualificate nella funzionalità del sistema distribuito, non sono così abili nell'architettura tecnica. Ciò rende abbastanza comune avere team disconnessi per due elementi critici del sistema. Meno questi due gruppi comunicano, più è probabile che si verifichino problemi in un secondo momento.

Si tratta di un processo

È impossibile distribuire un nuovo sistema aziendale e non influire sui processi dell'organizzazione. Anche se stai abbandonando un sistema aziendale centralizzato e passando al suo concorrente, i processi cambieranno. Infatti, se non si vuole che i processi cambino, è del tutto possibile che non si abbia un problema che deve essere risolto, e qui sta l'ennesima sfida. Quando la routine quotidiana di una persona cambia, provoca turbamento. Non intendo un po' di tempo. Nella mia esperienza, sconvolto in questo momento di cambiamento è un dato di fatto. Questo è vero anche quando la modifica del processo comporterà un processo migliore! Quindi pensare a come cambieranno i processi e lavorare con coloro che saranno interessati è fondamentale per il successo del progetto. Tuttavia, gli stessi esperti che sono fondamentali per progettare questo cambiamento di processo sono probabilmente le stesse persone che saranno interessate da tale cambiamento, quindi questo può essere un aspetto impegnativo dell'implementazione. In genere, un facilitatore esperto ed esperto collaborerà con gli esperti interni per guidare il cambiamento di processo che è diventato possibile con l'implementazione del nuovo sistema. Nella nostra linea di lavoro, vediamo questa sfida tutto il tempo. "Ma i project manager devono prima eseguire le approvazioni della scheda attività", ci dice un nuovo client TimeControl. "Questo è il nostro processo." Quando spieghiamo che le approvazioni della matrice possono consentire ai project manager di eseguire le approvazioni della scheda attività come parte di un processo più grande ed efficace, ci arrabbiamo; Pushback. A questo punto, abbiamo uno dei nostri collaboratori più esperti con le persone interessate per garantire che le loro preoccupazioni siano curate e che siano parte integrante del modo in cui il processo cambierà.

Le persone del processo probabilmente non sono le persone di configurazione o le persone tecniche, ma se non è previsto questo team, tutto il nostro duro lavoro sull'installazione e la configurazione probabilmente non verrà distribuito. Anche questo team deve far parte della nostra pianificazione, inclusa nelle comunicazioni e nelle decisioni prese dagli altri due team.

Formazione

"Quindi, avremo bisogno di formazione?" è purtroppo una domanda che viene spesso posta per ultima. Alcuni corsi di formazione possono venire attraverso i cambiamenti di processo come quella parte del progetto richiede un sacco di discussioni pratiche, ma che dire della guida utente effettiva di come il nuovo sistema funzionerà in modo più dettagliato? Una volta, la formazione era considerata un elemento critico delle distribuzioni software e i client si aspettavano di mettere da parte circa il 20% del budget totale su di esso. Ma, con i cambiamenti nei costi del software e la velocità di installazione, gradualmente che il 20% è diventato sempre meno denaro. Se stiamo pagando $ 20 al mese per utente per un sistema, dovrei mettere da parte $ 4 per utente per la formazione? Non posso promettere che non andrà troppo lontano. Esistono molte opzioni di sottoscrizione online per il training, ma nessuna di queste prenderà in considerazione la soluzione esatta progettata.

I formatori possono provenire dall'esterno o possono provenire dalle parti della configurazione o del processo del progetto, ma sono spesso persone che sono specialisti piuttosto che persone che hanno effettivamente svolto il lavoro di implementazione. Quindi, anche se hai messo da parte i finanziamenti per questo team (e spero che tu abbia), devi comunque assicurarti che queste persone sappiano in che modo il sistema in cui stanno addestrò le persone è effettivamente progettato per fare. Ho visto i formatori arrivare per Microsoft Project Server e hanno iniziato a spiegare agli utenti come configurare i campi aziendali e configurare i driver aziendali nell'analisi del portfolio, solo per fare in modo che gli utenti diano uno sguardo vuoto perché i campi aziendali erano già tutti configurati e non usano l'analisi del portfolio nella loro implementazione iniziale. I formatori sanno anche qual è il problema che questa particolare distribuzione dovrebbe risolvere? Dovrebbero. Pensare alla formazione all'inizio del progetto offre le maggiori possibilità di successo. I team tecnici, di configurazione e di elaborazione possono mettere da parte i dati critici attraverso tutte le sezioni per il training che verrà infine fornito. Ciò significa coinvolgere il team di formazione in anticipo.

Implementazione/accettazione/modifica delle impostazioni cultura

Se avete pensato e messo da parte le risorse per avviare questi team e li hanno tutti lavorando e comunicando insieme attraverso il progetto, allora l'implementazione del nuovo sistema è probabile che vada molto più liscio di quanto potrebbe altrimenti, ma non sottovalutare la resistenza al cambiamento culturale. La disponibilità di evangelisti chiave al momento giusto può essere fondamentale. Inoltre, tutti questi membri del team saranno impacchettarsi e passare al loro prossimo progetto? Ci saranno molte conoscenze di sistema racchiuse in queste persone al momento dell'avvio del progetto. Sono rimasto particolarmente colpito da uno dei nostri clienti all'inizio dell'anno scorso. Era il reparto IT di una grande organizzazione finanziaria. Una delle preoccupazioni emerse all'utente tecnico chiave che stava valutando il software all'inizio del progetto era "chi sarà l'amministratore dopo aver eseguito il completamento del progetto?" "Lo farò", disse. Era fedele alla sua parola. Le sue competenze e conoscenze si sono evolute attraverso la distribuzione multi-mese, che è stato un grande successo, e rimane ancora l'amministratore chiave.

Ritorno a capo

Ci sono centinaia di altre cose a cui pensare per assicurarsi che i team comunichino e lavorino come parte di un obiettivo più grande e ne abbiamo parlato solo di alcuni. Si spera che stia già facendo pensare alla prossima distribuzione del sistema aziendale. "Che dire della documentazione?" si potrebbe pensare. "E il supporto tecnico?"

L'aspetto fondamentale da ricordare è questo: quando si pianifica una distribuzione del sistema aziendale, è necessario espandere la prospettiva per includere non solo lo sforzo di installazione, ma anche il recapito della soluzione completata. Assicurarsi che il foro venga visualizzato esattamente dove deve essere nella giusta dimensione, profondità destra e angolo destro.

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