Il Workflow Project Management è una metodologia che le aziende spesso utilizzano per gestire efficacemente il processo di integrazione di un pacchetto software di terze parti con un framework applicativo esistente.

Il metodo Workflow Project Management altro non è che un Waterfall applicato all’integrazione di un applicativo di terze parti anziché allo sviluppo di un software fatto in casa.

Come nel classico approccio Waterfall, i requisiti del progetto vengono specificati in anticipo, quindi il processo di sviluppo viene seguito in modo lineare.

Nella modalità Workflow Project Management, queste differenze non cambiano il flusso complessivo del progetto, ma si limitano a modificarne alcuni aspetti per garantire che tutte le parti interessate abbiano accesso a qualsiasi nuova informazione o approfondimento che possa essere ottenuto durante la fase in corso.

Workflow Project Management: Definizione dello scopo

Quando si tratta di sviluppare o scegliere un software di terze parti per l’azienda, c’è un requisito alla base che deve essere soddisfatto: il software deve risolvere un problema.

Definire lo scopo e l’obiettivo del software è essenziale per garantire che soddisfi questo requisito ed il primo passo è sempre lo stesso: identificare quale problema dovrebbe risolvere.

Ciò richiede una valutazione approfondita delle esigenze operative di un’azienda, come le aree in cui è possibile migliorare l’efficienza o potenziali fonti di crescita dei ricavi.

Una volta completata questa valutazione, dovrebbero essere chiari i problemi esatti che devono essere risolti.

Il passaggio successivo consiste nel creare obiettivi su come questi problemi verranno affrontati utilizzando il nuovo software.

Gli obiettivi stabiliti forniscono passi concreti su come i problemi verranno risolti attraverso l’uso della tecnologia e dovrebbero servire come punti di riferimento in base ai quali misurare i progressi.

Workflow Project Management: Raccogliere i Requisiti funzionali

I requisiti funzionali sono un insieme di caratteristiche funzionali che devono essere comprese in un sistema, prodotto o servizio per soddisfare con successo le aspettative degli stakeholder.

Questi requisiti derivano spesso da interviste, sondaggi, osservazioni, sessioni di feedback dei clienti e altre tecniche utilizzate per comprendere le esigenze dell’utilizzatore finale. Gli Stakeholder.

Definiscono cosa dovrebbe fare un sistema e come dovrebbe funzionare, determinando le proprietà funzionali e, in definitiva, ciò che è in grado di fare.

La compatibilità dei pacchetti di terze parti con gli applicativi già presenti in azienda è un esempio di tali requisiti.

Specificano se ci saranno problemi di compatibilità con l’infrastruttura esistente prima che vengano apportate modifiche.

I requisiti funzionali aiutano inoltre a valutare le opzioni di sviluppo durante le prime fasi della progettazione del software.

Forniscono informazioni utili anche quando si considerano diverse alternative di sviluppo al fine di trovare una soluzione ottimale per i problemi potenziali.

Progettazione e documentazione del software

La progettazione e la documentazione del software sono parte integrante del successo di qualsiasi progetto d’integrazione: è imperativo che siano presenti le giuste funzionalità affinché sia compatibile con il software in uso.

La progettazione dovrebbe includere componenti come diagrammi di flusso di controllo e diagrammi di relazione tra entità che dettagliano ciascun modulo o componente all’interno del sistema.

Ciò garantirà la compatibilità con altri pacchetti, consentendo agli utenti di integrare i propri sistemi in un insieme coeso.

Servirà anche la documentazione per fornire informazioni su come utilizzare correttamente il sistema e risolvere eventuali problemi che potrebbero sorgere in fase di integrazione.

Inoltre la documentazione dovrebbe riportare le caratteristiche tecniche e il piano di test per la compatibilità interna.

Questo è uno strumento necessario per garantire che le applicazioni software funzionino in modo fluido ed efficiente.

Fornisce istruzioni dettagliate sui componenti di un particolare pacchetto software, nonché dettagli tecnici relativi al suo funzionamento. Inoltre, delinea i piani passo passo per testare la compatibilità del sistema con altri pacchetti e sistemi all’interno di un’organizzazione.

Questi documenti possono essere particolarmente utili quando si tratta di valutare versioni nuove o modificate di un sistema prima che vengano integrati e rilasciati.

Senza una documentazione adeguata, le organizzazioni potrebbero non essere in grado di valutare correttamente se un pacchetto software soddisfi le proprie esigenze o è compatibile con le applicazioni esistenti.

Descrivendo nel dettaglio i passaggi necessari per i test di compatibilità, le aziende possono garantire che i loro sistemi funzionino al massimo delle prestazioni senza interruzioni o conflitti tra i diversi componenti in uso.

La documentazione dovrebbe quindi coprire tutti gli aspetti dell’interazione uomo-macchina (funzionali, tecnici e test) in modo che si possano utilizzare appieno le funzionalità disponibili in modo efficiente.

Approvazione del progetto

Un progetto ben pianificato e analizzato, indipendentemente dalla rilevanza per qualsiasi impresa deve essere approvato prima di poter compiere qualsiasi progresso.

La soluzione proposta deve mantenere la compatibilità con l’obiettivo richiesto per ricevere l’approvazione. Ciò significa che tutte le parti interessate coinvolte nel progetto devono concordare che il pacchetto o il software proposto soddisfi le loro aspettative e soddisfi le loro esigenze.

Il processo per garantire la compatibilità tra una soluzione proposta e un obiettivo assegnato comporta un attento esame di tutti gli aspetti legati all’obiettivo del progetto.

Tutti i pacchetti o software considerati per l’approvazione dovrebbero essere valutati attentamente da ciascuna parte interessata al fine di determinare se sono in grado di soddisfare tutti i requisiti necessari in modo efficiente.

Inoltre, dovrebbe essere condotta anche un’analisi costi-benefici per garantire che il denaro speso per queste soluzioni sia giustificato dai potenziali guadagni derivanti dalla loro attuazione.

Workflow Project Management: Tipo di integrazioni

Le principali soluzioni sono sostanzialmente due:

• Il software viene “hostato” direttamente in casa, ovverosia si riporta sui propri server una copia fisica del software acquistato
• Il software rimane in gestione al produttore e ne garantisce la continua evoluzione e stabilità.

Nel primo caso avviene il tipico “Fork”, ovverosia si prende un software alla sua ultima versione stabile, la si copia in locale e da quel momento è responsabilità interna quella di continuare a garantirne il corretto funzionamento.

Questo può diventare oneroso se il software acquistato è in uso in ambienti che impattano sulla UI, quindi sull’interfaccia utente. Infatti, la continua evoluzione delle tecnologie, impone un continuo aggiornamento delle soluzioni software per mantenere la compatibilità dell’interfaccia con i dispositivi (desk o mobile) che continuano ad uscire sul mercato.

Nel secondo caso invece, questa responsabilità rimane a carico del fornire della soluzione software. Si utilizzano librerie e soluzioni di sicurezza di alto livello per garantire la comunicazione criptata fra i due ambienti, ma in questo modo si ha la certezza di poter usufruire sempre dalla miglior soluzione software disponibile sul mercato.

Applicativo di terze parti

In questa fase è previsto il processo di ricerca e selezione del software da integrare nel framework interno: questo è quindi un passaggio cruciale per il successo del progetto.

Una volta definite le caratteristiche di base che deve avere il software che stiamo ricercando, le attività successive da svolgere sono:

• La ricerca vera e propria del pacchetto software da integrare con i sistemi interni (questo significa fare ricerche online, contattare i produttori, esporre i requisiti funzionali che si stanno cercando, chiedere informazioni sul loro software, valutare eventuali installazioni e casi d’uso, pianificare eventuali dimostrazioni del software, chiedere le specifiche tecniche facendo “parlare” i reparti tecnici delle due aziende, ecc…);
• Eseguire, per ogni singolo applicativo identificato un’analisi approfondita delle caratteristiche funzionali partendo dalle attività in collaborazione con i produttori contattati;
• Far valutare al team tecnico la compatibilità tecnica con i nostri sistemi (per es. con quale linguaggio di programmazione è stato scritto) e garantirci maggiore semplicità di integrazione;
• Mettere a confronto (benchmark) le applicazioni selezionate ed eseguire un attenta valutazione dei Pro e Contro delle soluzioni identificate;
• Non dimenticare di fare un’attenta valutazione dell’esperienza utente (la UX) ed evitare di “metterci in casa” un software che, se fornito in dotazione a team operativi, non si trasformi in uno strumento ad alto consumo di tempo e risorse.

Integrazione del software

L’integrazione di software di terze parti nei sistemi esistenti può essere una sfida scoraggiante.

Tuttavia, è essenziale garantire che il nuovo software non solo si adatti perfettamente al framework esistente, ma rimanga anche sicuro e funzionale.

È importante valutare che i comportamenti funzionali e i test prestabiliti siano tutti rispettati quando si integrano software di terze parti.

Per valutare correttamente l’integrazione di software di terze parti, è fondamentale comprendere i requisiti di sistema. Ciò include assicurarsi che qualsiasi pacchetto soddisfi gli standard del settore e sia conforme alle normative.

Inoltre, è necessario eseguire simulazioni per diversi scenari con il software integrato per testarne la funzionalità in varie condizioni.

Identificare i potenziali problemi in anticipo aiuterà a evitare che diventino problemi molto costosi in seguito.

Pubblicazione

La pubblicazione può essere più o meno critica in base a come è organizzato il framework aziendale. Se si dispone di ambienti di sviluppo e di staging, ambienti di pre-produzione e produzione, la fase di “rollout” sarà meno dolorosa di quel che potrebbe essere in caso di assenza di questi layer che, comprensibilmente, in base alla dimensione dell’azienda potrebbero diventare troppo onerosi da mantenere.

Indipendentemente da ciò, il roll-out avviene come una qualsiasi altra pubblicazione con la sola differenza che c’è uno strato di software esterno che, in base alla scelta fatta in fase di integrazione, potrebbe dover essere gestito.

Conclusione

In conclusione, l’integrazione di soluzione software di terze parti può diventare un processo complesso ma, adottando l’SDLC Workflow Project Management, può essere reso facilmente gestibile.

Utilizzando questo metodo, le aziende che hanno identificato aree di miglioramento nel proprio processo interno, possono decidere di migliorare o semplificare le procedure semplicemente sfruttando soluzioni esistenti già pronte all’uso minimizzando e riducendo sensibilmente i tempi di integrazione.

Sfruttare soluzioni esterne consente quindi di gestire in modo rapido la necessità di doversi adattare alle mutazioni delle esigenze organizzative e operative aziendali.

Soprattutto se si utilizzano soluzioni completamente esternalizzate ed integrate da connessioni sicure tramite chiamate via server (chiamate S2S o API con Token di certificazione utente).

Il processo WorkFlow è a mio avvisto uno strumento efficace per gestire le integrazioni di terze parti e garantire il raggiungimento di risultati positivi.