Servizio al cliente? Enterprise Portal

Transcript

1 APPROFONDIMENTI Servizio al cliente? Enterprise Portal Come allargare i confini della propria azienda offrendo un migliore servizio ai propri clienti di Roberto Ghislandi Nella prima parte dell articolo (VoiceCom news n.2/07) abbiamo visto cos è e a quali aziende può essere utile un Enterprise Portal, e abbiamo illustrato quale dovrebbe essere l approccio per realizzare progetti vincenti. In questo numero esamineremo invece i punti critici da affrontare e le scelte tecnologiche da attuare, e daremo alcuni consigli su come affrontare un progetto complesso. Punti critici di un progetto di EP Come già sottolineato in precedenza, la realizzazione di un EP è un percorso di sviluppo dell azienda la cui riuscita dipende da moltissimi fattori. Nel seguito cerchiamo di individuare i punti critici del percorso che partendo dallo studio di fattibilità arriva sino al rilascio dell EP. Un progetto di EP può scomporsi nei seguenti passi: individuazione degli obiettivi strategici, studio di fattibilità e stesura dei requisiti, pianificazione, sviluppo, esercizio ed evoluzione. L individuazione degli obiettivi strategici deve essere condotta all interno dell azienda coinvolgendo sia il management sia l IT manager. Se ai primi spetta il compito di individuare i processi e le funzionalità che possono trarre giovamento e guadagnare in efficienza grazie alla portalizzazione, il settore IT ha il compito di sposare un cambiamento tecnologico che consenta di ragionare in un ottica distribuita. Terminata questa fase è possibile rivolgersi a un fornitore che deve aiutare l azienda a stendere lo studio di fattibilità evidenziando un programma di interventi che, in tempi ragionevoli e con i minori traumi possibili, renda disponibili attraverso l EP le funzionalità individuate. In questa fase è fondamentale individuare anche un scala di priorità per implementare con ordine le funzionalità richieste. La pianificazione Il progetto di un EP è complesso perché, come abbiamo visto, coinvolge problemi di tipo funzionale, tecnologico e gestionale. Una volta individuati con chiarezza i servizi che occorre offrire agli utenti del portale, è fondamentale condurre una attenta analisi per individuare le categorie di utenti che possono accedervi. Tale sforzo sarà PARTE SECONDA La prima parte dell articolo è stata pubblicata su VoiceCom news 02/2007 apprezzato dagli utenti, i quali potranno accedere ad un ambiente appositamente creato per loro e vi troveranno tutti e solo quei servizi inerenti al loro ruolo nell ambito dell azienda. Detto questo occorre concentrarsi sul progetto che si va a realizzare. Uno dei rischi più comuni è quello di porsi obiettivi troppo ambiziosi o di sottovalutare la situazione complessa ed eterogenea che caratterizza il sistema informativo aziendale, rispetto alle risorse umane ed economiche che si hanno a disposizione. Proprio per questo il fornitore esperto dovrà, come anticipato, suggerire un percorso per gradi che permetta di partire con la portalizzazione di alcuni servizi di base. A questi si aggiungeranno nel tempo nuove funzioni/ processi, ma solo una volta che siano stati riorganizzati. Più si riesce a suddividere il progetto dell Enterprise Portal in sottomicroprogetti con un inizio e una fine ben definiti, più facile sarà gestirne lo sviluppo, garantirne il rilascio entro i termini stabiliti e addirittura tornare sui propri passi nel caso ci si sia incamminati in un vicolo cieco. Il rischio dei grandi progetti che

2 APPROFONDIMENTI vanno online solo dopo decine di mesi, se non anni, di sviluppo è che quando ci si accorge di un errore di impostazione è oramai troppo tardi per porvi rimedio. Il consiglio è dunque quello di predisporre una opportuna infrastruttura che garantisca un sufficiente margine di flessibilità e poi procedere gradualmente a popolarla con i servizi richiesti. L agilità e la prontezza di intervento sui progetti è una delle migliori garanzie di riuscita. L idea dell EP è quella della costruzione di un bazar contrapposto alla costruzione di una cattedrale. Nel primo caso, una volta individuato lo spazio e costruite le infrastrutture di base, si può procedere a poco a poco popolandolo con le singole bancarelle. Sino dalla prima bancarella è possibile aprire il bazar al pubblico senza che ci siano pericoli di sorta. Ovviamente diverrà sempre più interessante quanto più aumenteranno le bancarelle, ma avrà vita propria già dall inizio. Differente è il caso della cattedrale che, finché non sia terminata (mesi / anni di lavoro) non potrà essere dichiarata agibile e svolgere la sua funzione. Il paragone della cattedrale e del bazar è stato preso a prestito, anche in modo non del tutto ortodosso, da un famoso manifesto Linux di Eric S. Raymond che lo ha proposto osservando lo sviluppo del progetto Linux e la propria esperienza di sviluppatore open source. In questo contesto infatti lo sviluppo di un progetto è guidato dalle esigenze della comunità open source che possono notevolmente cambiare nel tempo. Proprio per progetti di questo tipo negli ultimi anni si fa ricorso sempre più di frequente a differenti modelli di sviluppo del software che stanno sostituendo quello tradizionale a cascata (analisi, progetto, sviluppo, test, rilascio). Tra i più in voga meritano un posto privilegiato le così dette metodologie agili (vedi anche riquadro) che risultano efficaci nei contesti in cui occorre procedere a piccoli passi, in stretto contatto con il cliente, con una continua serie di piccole implementazioni e veloci rilasci (ad esempio mensili o addirittura quindicinali o n. 4 - anno VIII VoiceCom news 07

3 APPROFONDIMENTI Metodologie Agili In tutti i casi in cui il tradizionale ciclo di vita del software a cascata (acquisizione requisiti, progetto, sviluppo, test e rilascio) non è applicabile, possono essere d aiuto le così dette metodologie agili. Di cosa si tratta? È un particolare approccio che permette uno sviluppo graduale, di concerto con il cliente, in modo che sia possibile utilizzare il prodotto sfino dai suoi primi vagiti e correggerlo prima di essere giunti al termine della realizzazione. Le metodologie agili consentono di reagire in modo rapido e senza traumi ai continui cambiamenti che possono verificarsi nel corso di un progetto. La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione (planning), analisi dei requisiti, analisi, implementazione, test e documentazione. Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto. I metodi agili preferiscono la comunicazione in tempo reale, preferibilmente faccia a faccia, a quella scritta (documentazione). Il team agile è composto da tutte le persone necessarie per terminare il progetto software. Come minimo il team deve includere i programmatori ed i loro clienti. (con clienti si intendono le persone che definiscono come il prodotto dovrà essere fatto. Possono essere dei product manager, dei business analysts, o veramente dei clienti). Sotto il nome di Metodologie Agili si raggruppano metodologie innovative come Extreme Programming, SCRUM, Feature Driven Development, DSDM, Crystal e Lean Software Development. Tratto da Wikipedia: l enciclopedia libera. settimanali). In questo modo il cliente può testare il software a mano a mano che viene sviluppato e rilasciato e aggiustare il tiro senza compromettere o ritardare in modo significativo l intero progetto. Questo modo di operare si applica bene agli EP, dove uno degli elementi critici è la User Experience, cioè la facilità che l utente ha nell utilizzare il sito e i servizi che gli vengono messi a disposizione. Va infatti sottolineato come nel caso di EP si rendono disponibili differenti applicazioni che non sono in alcun modo presidiate. L utente deve dunque essere in grado, in modo autonomo e spesso senza alcuna formazione specifica, di utilizzare tutte le funzioni/applicazioni messe a sua disposizione. È chiaro dunque che un EP difficile da utilizzare, con interfacce non omogenee e che richiedono sforzi cognitivi e mnemonici agli utenti è una occasione mancata e finirà per generare frustrazione negli utenti che, dopo qualche sforzo iniziale, tenderanno a non usare più il sistema decretandone la morte. Le metodologie agili consentono un approccio in cui è possibile prototipare velocemente e far testare e usare con mano la piattaforma sin da subito, per lo meno a una parte dei destinatari. La conduzione del progetto Le principali cause che trasformano quello che sembrava un brillante progetto in un bagno di sangue sono da attribuire alla perdita di interesse del top management che, dopo un buon coinvolgimento iniziale, si fa da parte e non partecipa più in modo attivo e propositivo alle varie fasi. La seconda causa di insuccesso è la mancanza di capacità gestionali da parte del fornitore. Più spesso di quanto si pensi può accadere che il fornitore non sappia cogliere gli elementi chiave del progetto e, soprattutto, non sia capace di descrivere con sufficiente chiarezza quello che si accinge a realizzare in modo che il cliente recepisca e approvi esplicitamente le specifiche. Il bravo fornitore deve riuscire a coinvolgere il cliente per avere la certezza che quanto specificato risponda esattamente alle sue esigenze. L ottimismo prematuro è fatale: proprio i clienti che, in fase di progetto e di stesura delle specifiche, sembrano approvare tutto, si rivelano poi, durante lo sviluppo, o peggio ancora alla consegna, fonte di problemi senza fine. L esercizio Una volta terminato lo sviluppo della piattaforma di base e delle funzionalità che in fase di pianificazione si sono ritenute prioritarie, e conclusa con successo una adeguata fase di test nell ambiente di prova, l applicazione è pronta per il grande

4 passo: il così detto deploy o messa in produzione. Le criticità di questa fase sono sovente legate ad aspetti sistemistici e di eventuali sottostime dei volumi di traffico da garantire. Per scongiurare il primo problema occorre accertarsi che il proprio fornitore abbia anche skill di tipo sistemistico su tutte le tecnologie coinvolte, in modo da risolvere i problemi che possono insorgere. I primi vagiti di un progetto di EP richiedono una cura costante, tanto più qualificata quanto più sono eterogenee le tecnologie e le architetture coinvolte. Per quanto riguarda invece la scalabilità, è vero che oramai l hardware, soprattutto in caso di scalabilità orizzontale (vedi anche Scalabilità nel Glossario), ha costi molto contenuti; ma occorre aver progettato un software in modo opportuno, ad esempio con una gestione quanto più possibile leggera della sessione utente. È questa infatti una caratteristica fondamentale da tenere sotto controllo per non spostare il collo di bottiglia dai server alla rete, che potrebbe venire in breve tempo intasata dal traffico generato dal bilanciamento del carico. L evoluzione Qualsiasi progetto di EP, soprattutto se riuscito, richiede una costante evoluzione nel tempo: già nella fase di progettazione iniziale infatti si sarà pianificata una serie di funzionalità da rilasciare successivamente al primo deploy. Sarà dunque importante accertarsi di avere a disposizione (all interno dell azienda, in outsourcing dal fornitore o in outsourcing da terzi) le risorse per mantenere sotto controllo l architettura hardware e software. Oltre ad avere le adeguate competenze, chi effettua la manutenzione dovrà dare prova di una adeguata efficienza operativa supportata da un opportuno SLA (Service Level Agreement). Come si può vedere, il progetto di un EP è complesso in quanto non si tratta di acquistare un prodotto software (per esempio un Word Processor) o commissionare un applicativo per cui può essere sufficiente limitarsi a passare al fornitore le specifiche (es. gateway di pagamento) ma occorre realizzare e mettere in produzione una soluzione tecnologica. È quindi importante che il progetto dell EP venga sviluppato insieme al fornitore e utilizzato il prima possibile per far sì che si adatti alle esigenze aziendali. Un altro pericolo in cui ci si imbatte è quello di portarsi a casa soluzioni pre-confezionate che richiedono poi un notevole sforzo per essere adattate. Questo tipo di errore può avvenire sia per colpa del fornitore che può essere, ad esempio, legato commercialmente a un azienda produttrice, sia a causa di IT manager innamorati di un particolare pacchetto che si intestardiscono a voler utilizzare nonostante le riserve del fornitore. Scelte tecnologiche Non intendiamo entrare qui nel dettaglio delle architetture tecnologiche di un progetto di Enterprise Portal ma vogliamo fornire solo alcune indicazioni di massima per potersi orientare nell ampio panorama delle soluzioni disponibili. Quanto proponiamo nel seguito è, tra le tante possibili, la soluzione che noi prediligiamo poiché è in grado di offrire ottime garanzie di stabilità unitamente alla capacità intrinseca di adattarsi a progetti che divengono nel tempo sempre più complessi. Architetture base Nella sua accezione più ampia un Enterprise Portal è una soluzione che consente di pubblicare e accedere attraverso il web a: contenuti informativi statici (ad accesso libero / limitato). Ad esempio il profilo aziendale (ad accesso libero) o il report dell ultima convocazione del Consiglio d Amministrazione dell azienda (ad accesso limitato ai soli facenti parte del CdA); contenuti dinamici (ad accesso libero / limitato). Ad esempio la disponibilità degli articoli contenuti in un catalogo prodotti (accesso libero), l esposizione di un cliente verso l azienda (ad accesso limitato ai clienti mediante la loro login e password); applicazioni aziendali/gestionali/erp (ad accesso libero / limitato). Ad esempio apertura di un ticket per l assistenza (ad accesso libero, supponendo che sia aperta a tutti), l accesso alla posta elettronica via web (tramite indirizzo di e password) o il livello di raggiungimento del proprio budget per un agente (ad accesso limitato con la propria login e password). In figura abbiamo rappresentato le tre situazioni identificandole con frecce di differenti colori (rispettivamente azzurre, rosse e verdi) n. 4 - anno VIII VoiceCom news 07

5 Contenuti informativi statici Come si può vedere i contenuti informativi statici vengono di solito prodotti con un Content Management System che mette a disposizione un semplice editor con cui il redattore può inserire i testi, le immagini, le tabelle e gli altri elementi che compongono il contenuto informativo della pagina. Una volta composta, il CMS provvede a inserire la pagina nel template di visualizzazione finale e a formattarla secondo le guideline aziendali imposte. Il redattore può dunque controllare il lavoro finale e procedere con la pubblicazione. I migliori CMS, con uno spiccato orientamento a servire portali con alti volumi di traffico, invece che ricostruire le pagine Html ogni volta che un utente ne fa richiesta provvedono a generarle precedentemente e a salvarle sul file system come una normale pagina html. I vantaggi di una soluzione di questo tipo sono molteplici: la parte del portale così realizzata è sempre disponibile anche quando qualche servizio o qualche applicazione o database potrebbero essere fuori linea per guasti o manutenzione; affidando anche la generazione del sito statico vecchio stile al CMS, si assicura comunque alla pagina una grafica e una impostazione uniforme tra pagine statiche e pagine servite dinamicamente; il redattore deve preoccuparsi solo dei contenuti in quanto formattazione e impaginazione sono automatizzati; la pubblicazione di pagine statiche non carica l application server che, per mostrare una pagina, deve solamente accedere al file system senza alcun accesso ad applicazione o data base che potrebbero rallentare il sistema; essendo pagine statiche, in caso di elevato traffico non si hanno problemi a servire un notevole numero di utenti. Per contro la pubblicazione richiederà un passo in più, che però va visto come un ulteriore controllo a garanzia che tutto sia avvenuto secondo il processo di pubblicazione predisposto dall azienda. Contenuti dinamici Oltre ai contenuti statici, - come le informazioni sull azienda, la mission e i servizi offerti - vi sono una serie di pagine di un Enterprise Portal che possono definirsi ibride in quanto composte da informazioni che vanno aggiornate con una certa frequenza ma che non richiedono comunque l accesso diretto ad una applicazione aziendale come ad esempio la posta elettronica o la procedura per inserire un nuovo ordine. Questa sezione, identificata nel nostro grafico dalle frecce rosse, prende i dati dalle applicazioni interne spesso sotto forma di file XML che vengono in una seconda fase riformattati attraverso, ad esempio, l applicazione di un file XSL e dunque, in funzione della dinamicità richieste, o staticizzate e pubblicate sul file system (ad esempio catalogo prodotti senza gestione disponibilità) o prodotte solo su richiesta, nel caso qualche utente lo richieda (ad esempio pagina catalogo con visualizzazione della disponibilità in tempo reale). Questo approccio consente una sufficiente flessibilità caricando al minimo i server e limitando il più possibile l accesso ai database e alle applicazioni aziendali. Applicazioni aziendali L accesso alle applicazioni aziendali è la vera e propria parte del framework dell Enterprise Portal nel senso più restrittivo del temine. Nel nostro schema è identificato dalla sezione di destra con le frecce in verde. In questo caso le applicazioni aziendali mettono a disposizione dell EP una serie di servizi, che possono poi essere combinati tra loro e inseriti in una pagina, a seconda delle regole di presentazione impostate in un template e rese disponibili all utente. È il tipico caso di un cruscotto aziendale in cui in un unica pagina è possibile vedere in tempo reale l avanzamento degli ordini, il cash flow e la To Do List. Il vantaggio di questo tipo di soluzioni è che la pagina risulta essere un patchwork uniforme dove contemporaneamente vengono eseguite più applicazioni. L utente può interagire con ognuna di queste attraverso un interfaccia funzionalmente e graficamente omogenea. Una architettura orientata a questo tipo di soluzioni è la così detta SOA (Service Oriented Architecture). Secondo questo modello, la varie applicazioni aziendali mettono a disposizione dell Enterprise Portal una serie di servizi che esportano alcune funzionalità. L EP si occupa di combinare i vari servizi, corredarli dell interfaccia grafica e renderli disponibili sul portale. Spesso la pagina del portale viene costruita con una serie di portlet che non sono altro che finestre dove viene eseguita un applicazione più o meno ignara che la sua interfaccia venga mostrata insieme ad altre

6 sulla stessa pagina. Il portlet può essere anche visto, dal punto di vista funzionale, come un canale dove le informazioni scorrono in un flusso che va dall applicazione interna all azienda all utente sul web e viceversa. Alcune sensate raccomandazioni Forniamo qui cinque indicazioni, non in ordine di importanza, che vogliono sottolineare i principali fattori di riuscita, ma anche di rischio, di un Enterprise Portal. Sono cinque campanelli di allarme che dobbiamo imparare a tenere sott occhio anche quando siamo concentrati sulla definizione, l implementazione e lo sviluppo di un dettaglio. Potremmo addirittura dire che questa è la regola zero: in qualunque momento non perdiamo di vista i principi generali e le linee guida di partenza! La prima indicazione che diamo è quella di applicarsi per rendere statico tutto quello che si può. La generazione di pagine dinamiche richiede per sua natura l accesso alla struttura dati che carica il server in misura maggiore della visualizzazione di una pagina html statica. La conversione di pagine dinamiche in pagine statiche permette di alleggerire l intero sistema e far lavorare il solo web server senza coinvolgere applicativi, database ed altri oggetti che per un qualunque malaugurato caso potrebbero bloccarsi o dare problemi. La staticizzazione permette dunque di rendere sempre disponibile la consultazione della maggior parte del portale anche nel caso in cui alcuni elementi critici, come i database o le applicazioni aziendali coinvolte, presentino dei malfunzionamenti o non siano disponibili. Il secondo concetto è quello di assicurarsi che il sistema preveda un impostazione per cui la generazione delle informazioni sia separata dalla relativa rappresentazione. Una caratteristica che deve avere un Enterprise Portal è quella di presentare al navigatore un ambiente uniforme per aspetto e interfaccia di navigazione indipendentemente dal fatto che si stia accedendo in realtà a servizi che interagiscono con differenti applicativi. Un EP deve dunque tener distinta la fase di produzione / inserimento dei contenuti da quella di vestizione o generazione del mock up. Queste due fasi, oltre ad essere distinte dal punto di vista logico, vengono anche curate da persone con skill molto differenti: i primi orientati alla programmazione e i secondi orientati al design e alla presentazione. Il terzo elemento chiave che caratterizza un progetto di Enter n. 4 - anno VIII VoiceCom news 07

7 prise Portal è quello di predisporre una opportuna architettura che permetta non solo l interazione dell utente con le varie applicazioni ma anche un unico punto di accesso. Con SSO (Single Sign- On) si indica proprio la modalità di autenticazione che permetta all utente di autenticarsi una sola volta e avere accesso quindi a tutte le applicazioni di propria pertinenza. Il nostro utente dunque una volta identificatosi al proprio portale aziendale non avrà più bisogno di Login e Password per consultare la propria e- mail, inserire un ordine o controllare un numero di telefono di un cliente. Il quarto must è la User Experience. Un Enterprise Portal è fatto per gli utenti. Se non si riesce a far sì che l utente si trovi a proprio agio sul portale, non viva quindi il portale come un fedele e insostituibile compagno che gli semplifica la vita, possiamo scommettere che in breve tempo il progetto, osteggiato da tutti, imploderà su se stesso. L ultima regola da seguire è la scalabilità. Il sistema Enterprise Portal deve essere progettato in modo che possa essere in qualunque momento scalabile con semplicità e economicità. Come scegliere un fornitore Ancora prima della selezione e della scelta del fornitore c è l amletica scelta tra lo sviluppo interno o la scelta di un fornitore esterno. In questo contesto, supponiamo per semplicità, che si sia scelto di procedere con un fornitore esterno. Cosa chiedere dunque a un fornitore per sapere se è quello giusto? Suggeriamo di concentrarci su tre aspetti: esperienza dimostrabile nell avere già affrontato progetti simili, qualità della soluzione proposta, metodologie di progetto e di controllo del progetto utilizzate. I tre fattori sono di pari importanza e vanno valutati con attenzione. Con il primo possiamo capire se il possibile partner, a prescindere dalle opportune conoscenze tecnologiche, ha già affrontato progetti simili e sarà dunque in grado di mettere a frutto la propria esperienza per guidarci durante tutte le fasi del progetto. Il secondo aspetto, quello che riguarda la qualità della soluzione proposta, deve spingerci a valutare bene se l architettura offerta sia facilmente scalabile e flessibile, si basi su prodotti open source o soluzioni commerciali (vedi anche oltre), permetta di essere ampliata in un secondo tempo. Il terzo aspetto è quello relativo alla gestione del progetto. È fondamentale capire se il nostro partner ha dimestichezza con la gestione di progetti complessi e critici come quello di un EP. Tempi e costi Quando si parla di EP il prezzo può variare addirittura di due ordini di grandezza in funzione della complessità del lavoro da affrontare e dall ambizione del progetto. Diciamo comunque che non si può pensare a un progetto di EP con budget per il primo anno inferiore ai 40 mila Euro, che dovranno essere affiancati da un investimento pari ad almeno la metà per l anno successivo, comprendendo oltre alla manutenzione correttiva e evolutiva, lo sviluppo di tutte le funzionalità aggiuntive che si sono giudicate di secondaria importanza in fase di pianificazione iniziale. A questi costi vanno affiancati quelli dell infrastruttura e delle licenze software se ci si affida a una soluzione su licenza (in questo caso occorre considerare per i contratti annuali di manutenzione circa un 20% del costo di acquisto delle licenze). Per quanto riguarda i tempi dipende molto dalle tecnologie che si adottano, e dalle modalità di conduzione del progetto. Nel caso si adottino modelli classici (ciclo a cascata) si parte dai sei mesi, che possono essere significamene ridotti se invece si adottano metodologie agili che consentono di verificare il progetto in corso d opera. Conclusioni Lo sviluppo di un Enterprise Portal per una azienda è al contempo l occasione per riorganizzare strategicamente le proprie interazioni con gli utenti e la possibilità di ridurre costi e acquisire competitività. Va tuttavia sottolineato che, anche se consistente, il progetto tecnologico è solo una parte dell impegno poiché il vero lavoro è quello che l azienda deve fare su di sé mettendosi in gioco e, in molti casi, ristrutturandosi. La nostra esperienza ci ha insegnato che è una sfida che va colta, convinti del percorso che si sta intraprendendo e cautelandosi con un partner affidabile e competente che si dimostri capace di indicare la soluzione migliore per le esigenze dell azienda indipendentemente dalla scelta a priori di una determinata tecnologia o di un determinato prodotto (commerciale o open source). Roberto Ghislandi Marketing and Business Development di B-Human srl