*βeta!

Websapienza.org

webdesign, tecnologia e comunicazione

Riflessioni

Osservatorio - Assistenza: teorie e pratiche

Indice
Riflessioni
Vantaggi e svantaggi
Problem solving team
Centralità dei servizi IT
Spinta della tecnologia
Problema del lock-in
Le gerarchie servono ancora?
Ricapitolando
Trasparenza e pubblicità
Misurare e classificare
Il dominio della comunicazione
Strategia comunicativa
Trasferimento di conoscenza e forza del gruppo
Proposta pratica
Tutte le pagine

In questa lunga nota abbiamo tracciato alcune idee per il miglioramento dei servizi. Partiti dalla semplice installazione di un sistema di ticketing abbiamo riflettuto sulla pervasità della tecnologia nelle attività lavorative e sul 'primato' delle persone che lavorano allo sviluppo e alla manutenzione dei servizi IT. Primato non significa centralità, perché quella appartiene all'utente. Definire una strategia comunicativa, anzi. 'riconoscerla' nelle pieghe delle attività quotidiane è il primo passo per miglioramento. Il lavoro è lungo e difficile ma non privo di soddisfazioni.


Io e i miei colleghi stiamo facendo i primi passi nell'uso della piattaforma OTRS, un sistema per la gestione delle domande e delle richieste di assistenza tecnica per l'applicazione Infostud. Ogni giudizio potrebbe essere prematuro. Non solo. Quando si comincia a usare uno strumento è facile avere atteggiamenti come dire? bipolari. Grande entusiasmo per la scoperta di nuove funzioni e utilità, depressioni e sconforto per incomprensioni e difficoltà.

Rispetto ad altri progetti avviati da altri servizi e uffici noi scontiamo il vantaggio/svantaggio di lavorare con un sistema di ticketing (OsTicket) da circa due anni: primi alla Sapienza scrivevamo con malcelato orgoglio in una comunicazione al Magnifico Rettore. In questi due anni abbiamo 'processato' circa 27.000 richieste di assistenza a cui abbiamo dato risposte e soluzioni.

Vantaggio perché noi e i nostri utenti avevamo la dimestichezza di lavorare con un numero identificativo 'legato' alla mail e la possibilità di seguire lo stato del ticket (aperto/chiuso), svantaggio perché non potevamo organizzare il servizio partendo da zero ridisegnando i cosiddetti flussi di lavoro. Partire da zero significava stressare la struttura costringendo noi e i nostri utenti a ridisegnare processi ormai consolidati senza avere nessuna garanzia di miglioramento del servizio.

Abbiamo scelto di 'migrare' sulla nuova piattaforma nel modo più trasparente possibile per gli utenti. Nessun proclama, nessuna linea guida, nessuna complessa procedura di registrazione. Abbiamo lasciato che gli utenti continuassero a utilizzare le varie mail di assistenza infostud. Il sistema OTRS si occupa di assegnare un numero di ticket identificativo e a noi il compito di rispondere (cercando) risolvendo i problemi, gli incidenti e le difficoltà degli utenti che usano l'applicativo Infostud. Rispetto alla precedente piattaforma, paradossalmente, abbiamo fatto - per ora - un passo indietro. Infatti OsTicket permetteva di consultare una pagina web con la quale tracciare la richiesta. Al momento, invece, solo la mail richiesta-risposta è la 'traccia' tra noi e gli utenti.

OTRS è un sistema molto sofisticato che consente l'autenticazione degli utenti per aprire ticket e seguirne lo stato di avanzamento della risoluzione dei vari incidenti. Debitamente configurato potrebbe essere usato per organizzare code (le code sono le 'caselle di destinazione' dei ticket) anche tra servizi (primo livello, secondo livello) e uffici (ad esempio una segreteria studenti potrebbe smistare la richieste in base ai problemi, amministrativi, tecnici e didattici). Insomma la tecnologia disponibile permette di raggiungere il sogno (il progetto) di un'assistenza unificata della Sapienza. Attenzione: parliamo di assistenza, non di un call center o di un help desk unico (magari esternalizzato). Assistenza, per noi, vuol dire che per quanto siano vari e multiformi le strutture di servizio dell'ateneo, per quanto varie le esigenze degli utenti, i punti di contatto convergono in un solo punto dove le varie competenze si confrontano per la risoluzione dei problemi.


Utopia? No. Già adesso le tecnologie impiegate (dalla primitiva e rozza mail al sofisticato sistema di ticket o l'uso delle piattaforme condivise come Google Apps, alle varie reti sociali - twitter, facebook eccetera) 'spingono' verso questo risultato. In più di un occasione - ad esempio - il nostro ruolo si configura sempre più come problem solving team legato magari ad un progetto specifico o una scadenza particolare. Team che si confronta quotidianamente con altri soggetti e strutture universitarie. Tutto bene quindi? Probabilmente un sondaggio tra i nostri utenti rileverebbe risultati tutt'altro che lusinghieri e non proprio in linea con queste previsioni ottimistiche. Tecnologia, buona volontà dei singoli, intuizione sulle 'tendenze' non bastano. Inoltre la maggior parte dei problemi che coinvolgono le strutture riguardano 'interruzioni' inaspettate al normale funzionamento,incidenti a cui si deve correre ai ripari nel minor tempo possibile dedicando il maggior numero di risorse. Il resto delle energie deve essere dedicato alle richieste di servizio, attività di routine,data entry,assistenza e istruzione sulle procedure (istruzioni che aumentano in modo proporzionale con applicazioni complesse e poco usabili). A questo scenario, già così denso, occorre rispondere alle richieste di nuove specifiche, aggiornamenti della normativa eccetera.

Come realizzare un punto unico di contatto tra realtà diverse e con protocolli, gerarchie e procedure articolate?


Il centro IT svolge un ruolo fondamentale: non solo perché naturalmente più vicino ai processi input/output di un'organizzazione ovvero per la pervasività della tecnologia in tutte le procedure amministrative, di ricerca e didattiche ma anche perché il reparto IT assume, volente o nolente, il ruolo di gatekeeper: ogni applicazione è applicazione informatica e passa necessariamente per i progettisti e gli sviluppatori informatici.

Non dobbiamo commettere l'errore di considerare il progettista informatico come mero esecutore delle indicazioni dell'amministrativo. La sindrome delle "chiavi in mano"..."dimmi che ti serve e io lo faccio" è una mentalità ancora radicata tra di noi e spesso rappresenta una facile scorciatoia alla defaticante ricerca di un ciclo di sviluppo condiviso.

Affermare il primato della tecnologia informatica e dei suoi attori principali significa anche 'rivedere' alcune considerazioni che davamo per scontate (cioè, continuavamo ad affermarle senza vederne gli effetti pratici nella vita delle persone e nel lavoro).

La prima affermazione sosteneva che la tecnologia che funziona davvero è quella che si usa senza essere percepita. Si presumeva i dispositivi dovessero nascondersi nelle "pieghe del reale". Il telefonino poteva essere impiantato nella cavità della gola, il computer e la sua capacità di elaborazione poteva nascondersi nelle mura delle case intelligenti, il network degli oggetti avrebbe funzionato senza che l'utente ne avesse consapevolezza.
L'invadenza delle interfacce poco usabili, le tecnologie invasive e inutili che soddisfavano gli ingegneri e provocavano frustrazione agli utenti sembravano solo bias da correggere o - per qualcuno - addirittura un destino ineluttabile. Eppure, lo sviluppo della tecnologia sembra aver preso una direzione del tutto diversa da quella prevista. La tecnologia è decisamente diventata più usabile ma ha preteso di ostentare la sua 'tecnologicità'. Il design ha tra i suoi obiettivi l'aspetto emozionale, la bellezza di unoggetto. Emozione e bellezza richiamata dagli aspetti hi-tech estilosi,aspetti che rappresentano una nuova frontiera dell'estetica.

Un progetto informatico non deve 'nascondersi', non deve risultare invisibile. Un'interfaccia - a condizionenaturalmenteche sia usabile e accessibile - può essere presentata in tutte le sue funzioni, anche le più complesse senza - con questo - generare frustrazioni per chi le usa, siano operatori che utenti finali. Anzi, metalli e plastiche, luci e pulsanti solleticano la componente emozionale dell'utente.

L'altro aspetto su cui molti di noi hanno combattuto battaglie epiche è quello di concentrare il problema sugli aspetti culturali, di flusso e di contenuto tralasciando la tecnologia impiegata. Quante volte abbiamo dovuto impedire all'utente (anche con la 'forza') di pensare agli aspetti tecnologici ("voglio un bottone qui", "devo fare un sito con wordpress, spiega come funziona ") e convincerlo a impegnarsi su quello che serve veramente per migliorare l'efficacia del suo lavoro. Quante volte abbiamo dovuto dimostrare che l'ideazione e il progetto è separato dal software che è un mero strumento di esecuzione. Bene. non è che tutto questo è sbagliato. Solo che trascuravamo il fatto che la tecnologia impiegata essa stessaspinge per una direzione o un'altra.

La scelta di OTRS non è una variabile indipendente che si adatta alle nostre esigenze e alle nostre procedure. Tutt'altro.Come dicevamo, quando abbiamo configurato la piattaforma abbiamo cercato di non sconvolgere le nostre abitudini e quelle degli utenti. Eppure la tecnologia impiegata, a volte in modo evidente, altre volte in modo sotterraneo sta modificando il nostro lavoro. E' successo con il primo uso delle mail, con il vecchio sistema di ticketing e sta succedendo con OTRS. Il fatto che la tecnologia modifichi il lavoro non significa che lo faccia in modo imprevedibile e oscuro. Se si apprende il funzionamento possiamo anche prevedere il miglioramento del nostro servizio e l'aumento di efficacia e efficienza.


Dedicato il giusto tributo e il giusto peso al software e alla centralità del progettista IT non dobbiamo cadere nella autoreferenzialità dell'uno e dell'altro. La tecnologia software dispone di una 'forza propria' capace di rideterminare i processi lavorativi: una volta installata però è difficile sradicarla dalle abitudini e dagli usi degli utenti. E' il noto fenomeno del lock-inche impedisce qualsiasi tentativo di modificare, migliorare o semplicemente introdurre semplici cambiamenti.

Parlare dell'importanza del ruolo non sottintende l'idea di una supremazia del progettista informatico. Essere al centro della tecnologia e riuscire a trovare soluzioni altrimenti impossibili ai comuni utenti rischia di far assumere all'informatico la figura di un autocrate presuntuoso e indifferente alle esigenze degli utenti. Non parliamo solo di conflitti caratteriali: lasciare all'informatico il controllo totale dei progetti può significare rinunciare alla facilità d'uso del software a favore di procedure di 'basso livello' gestite dai programmatori. Proviamo a spiegare meglio: progettare interfacce usabili è molto complesso e richiede uno sforzo non comune da parte di chi sviluppa. La tentazione è quella di trovare soluzioni 'veloci'. Ad esempio, creare procedure che modifichino direttamente la base dati piuttosto che creare dei form ad alto livello per le modifiche e gli aggiornamenti.

Ma il pericolo vero, il problema dei problemi consiste nel disegnare la forma organizzativa in base alle applicazioni. Se ci sono n applicazioni (o addirittura n 'procedure') l'organizzazione si conformerà a questo schema: creerà N settori, N responsabili e N uffici. La tecnologia 'spinge' per l'unificazione dei servizi e degli accessi ma l'organizzazione degli umani resterà attaccata al simulacro della sua antica conformazione gerarchica. Questa forma di lock-in è la forma più insidiosa e resistente al cambiamento.


Spingendo ancora di più la riflessione: le organizzazioni complesse hanno ancora bisogno dei capi e delle gerarchie? Se l'organizzazione universitaria ruota sempre di più intorno al network (web, cloud, applicazioni condivise delle risorse in rete, relazioni e conversazioni con tutti gli attori del 'sistema') e se le esigenze lavorative richiedono sempre di più mentalità aperte, spirito di collaborazione e atteggiamenti pro-attivi, ha ancora senso una struttura con complessi livelli gerarchici, catene di comando lunghe e burocrazie consolidate? Aggiungiamo, e non è un dettaglio, il fatto che l'università ha il suo carattere fondativo intorno alla libera attività dei docenti che - per definizione - non hanno gerarchie di comando se non quella liberamente espresse nella definizione degli organi collegiali. La 'libertà' accademica - anche se messa continuamente in 'tensione' dalla necessità di rilevamento e valutazione della didattica e della ricerca si dovrebbe confrontare - teoricamente - con un'organizzazione dei servizi e del personale tecnico-amministrativo flessibile e dinamico. Insomma, sembrerebbe esistere le condizioni per cercare modelli organizzativi decentrati, orizzontali e fondati su strutture snelle e correlate costruite intorno ai nodi di una rete connessa. Ebbene, la realtà sembrerebbe un'altra.

La Sapienza ha avviato un importante processo di ristrutturazione che ha - tra i suoi effetti - quello di aver aumentato i i piani gerarchici della piramide e di aver legato le responsabilità ai diversi livelli stipendiali. Unprocessoorganizzativo che sembrerebbe andare in contro tendenza alla flessibilità e dinamicità richieste. Ma questa - forse - è una lettura superficiale. A noi pare che il tentativo sia quello di inserire degli elementi di premialità e merito in una struttura altrimenti bloccata da veti e appiattimenti contrattuali. E' possibile criticare questa impostazione sopratutto per aver fatto precipitare i livelli 'bassi' in un limbo da cui difficilmente sipuòrisalire ma l'operazione (va riconosciuto) ha dato forti stimoli e motivazioni ai responsabili dei servizi.
Ricapitolando:

  • La scelta di utilizzare una piattaforma software non è una scelta neutrale. L'uso di un particolare applicativo trasforma il nostro lavoro e modifica (che ne siamo consapevoli o meno) i processi e i flussi.
  • In virtù di questa 'invadenza' delle macchine, il progettista informatico ha delle grandi responsabilità nel definire insieme all'utente le scelte da fare
  • Le forme organizzative che si adattano alle applicazioni e non viceversa rappresentano uno dei mali endemici dell'organizzazione IT
  • Nonostante la tecnologia spinga verso forme di appiattimento delle gerarchie e di lavoro in rete, la tendenza sembra andare verso forme di gerarchia verticale, con capi, capetti e esecutori di basso livello (e nessuna prospettiva).

In questo scenario un po' fosco, è possibile inserire degli elementi (anticorpi) che riescano a invertire la tendenza migliorando i processi lavorativi rendendoli più efficienti e efficaci?
Ovviamente non esiste la ricetta giusta per ogni caso e le stesse proposte possono essere sbagliate se fatte troppo presto o troppo tardi: insomma avere delle buone idee e buone intuizioni(ammesso che queste lo siano) non serve a molto se non si ha la forza, la capacità e il senso dell'opportunità di adottare queste idee nella realtà. Anche se ritenete che il nostro potrebbe essere un esercizio di pura vanità pensiamo che alcune linee, alcuni principi sono utili indipendentemente dalla volontà/possibilità di realizzarli nella pratica.


Il primo principio, il più importante è quello della trasparenza: impegnarsi a pubblicizzare tutto quello che facciamo. Togliete le valenze politiche di questo assioma. In politica le "case di vetro" possono essere evocate da destra o sinistra, da dittature e democrazie: teniamocene alla larga! Quando parliamo di trasparenza parliamo di un metodo e di una regola. Ogni organizzazione, anche la più virtuosa, ha dei segreti e dei processi riservati. Questo è assolutamente legittimo. Ma supponiamo di prendere l'impegno di dover pubblicizzare tutte le attività e tutte le procedure, anche le più nascoste: l'effetto potrebbe essere interessante. Probabilmente all'inizio si potrebbe avere l'effetto di aumentare il livello di segretezza per il rischio di diffondere notizie adesso pubblicabili per regola e una maggior livello di 'diplomazia' per oscurare le informazioni. Altro effetto probabile è quello di avere una cerchia di super utenti (perlopiù critici) più attenti, mentre la maggior parte degli utenti, semplicemente si disinteressano degli aggiornamenti e delle informazioni che forniamo pubblicamente. Ma se non ci lasciamo scoraggiare, se superiamo i momenti di imbarazzo e di caos iniziale, il principio di "pubblicare tutto" si riverbererà nella attività lavorativa in positivo. Nessun capo, nessun regolamento interno sarà più efficace dell'impegno etico di rendere pubblica la nostra attività.

Ma cosa intendiamo per 'pubblicizzare tutto'? Può essere un blog con il resoconto delle attività quotidiane, la pubblicazione di documenti interni, l'elenco aggiornato delle mansioni. Anche dati quantitativi come le mail (o ticket) che riceviamo, le risposte che diamo e le difficoltà che riscontriamo nel rispondere agli utenti. Da questo principio ne discendono altri due.


Il secondo principio è quello di misurare e classificare tutto. Quante richieste riceviamo, quante risposte, la natura e il tempo per i vari interventi. Questa attività sembrerebbe la più semplice eppure oberati da impegni e nuovi problemi è sempre difficile fermarsi a 'contare e valutare'. Contare e valutare - per definizione - hanno bisogno di una pausa.

Il terzo principio è quello dei miglioramenti continui.Questo principio è piuttosto una realtà consolidata. Tutti i processi - sopratutto quelli che investono più da vicino l'informatica - sono sottoposti a continui miglioramenti e aggiustamenti. Molto spesso questi continui interventi sono vissuti dagli utenti come inefficienze e errori da correggere. Qui si intende invece trasformarli in modalità di lavoro risultato del dialogo permanente tra chi sviluppa e chi utilizza le applicazioni.


Le attività legate alla trasparenza e alla pubblicità appartengono al dominio della comunicazione. Comunicare è un'attività complessa ed è una professionalità distinta da quella del manager, del programmatore o dell'operatore di help desk e di assistenza. In questi anni abbiamo visto trasformare il ruolo della Comunicazione da semplice collettore per la stampa (comunicati, rassegna stampa, organizzazione delle conferenze stampa) a centri in grado di stabilire relazioni con vari media (tradizionali e social) e principali attori della comunicazione interna. Questo crea un problema: come è possibile provare a comunicare senza avere le professionalità adeguate? Anzitutto occorre che chi si occupa professionalmente di comunicazione (uffici stampa, media manager, urp eccetera) stiano dentro il "ciclo di sviluppo" insieme ai progettisti e i loro utenti. La loro funzione potrebbe essere quella di aiutare a gestire il dialogo con gli utenti e formare i tecnici e i manager nell'arte della comunicazione. Naturalmente, l'intervento dei comunicatori non deve essere presente e pressante e potrebbe intervenire solo nella gestione delle crisi oppure in passaggi particolarmente delicati. Il ruolo più interessante e utile per una struttura di comunicazione potrebbe essere quello di aiutare i vari settori e i vari uffici a definire una "strategia comunicativa". Bisogna intendersi sul significato da dare al termine strategia. Partiamo dal vecchio assioma preso in prestito dalla psicologia relazionale: è impossibile non comunicare. Applicando il principio alle organizzazioni, l'affermazione "questa struttura (istituzione, ripartizione, centro eccetera) non comunica con i suoi utenti" non ha molto senso. L'organizzazione comunica: il punto è quello di individuare il 'come'. Naturalmente - se un gruppo o un settore non ha strutture e persone preposte alla comunicazione, se non ragiona su questo non significa che non comunica. Significa soltanto che è più difficile individuare la sua strategia e ancora più difficile cambiarla.


In concreto cosa significa individuare una strategia comunicativa?

Potrebbe essere utile cominciare dalla platea a cui ci rivolgiamo (docenti, studenti, personale) e gli strumenti che utilizziamo (ad esempio le mail, le lettere protocollate, le riunioni). Studiare le relazioni che hanno gli utenti tra di loro e con noi, la percezione sulla raggiungibilità e la capacità di rispondere ai problemi e ai suggerimenti. Alcuni esempi.

Una struttura potrebbe avere un approccio da 'one-man show' in cui il responsabile del servizio è l'interlocutore principale degli utenti (almeno di quelli che riescono a raggiungerlo), oppure un'altra struttura trasmette le sue funzioni attraverso la comunicazione istituzionale a colpi di newsletter e circolari pdf protocollate. Un esempio di comunicazioned'antan è quella rappresentata dalle strutture sindacali che intessono relazioni e conversazioni con i loro iscritti attraverso il contatto personale e il 'carisma' che deriva dalla loro vicinanza (o lontananza) con il potere.

Di norma queste strategie funzionano, cioè semplicemente esistono e si auto riproducono. Non c'è nessuna spinta, diretta o indiretta, che imponga naturalmente un cambiamento. Se non ci sono eventi particolari o nuovi responsabili che prediligono, per passione o per dogma, nuovi modi di comunicare, perché dovremmo cambiare? L'introduzioni di metriche, classifiche e legislazione di verifica spingono l'organizzazione a migliorarsi, razionalizzando e ottimizzando le risorse ma non stabiliscono un legame diretto tra miglioramento delle perfomance e strategie comunicative. Insomma, il cambiamento di strategia non è un passaggio scontato né tanto meno diretto.

Mettere in relazione cambi di strategia comunicativa con il miglioramento delle performance è possibile a livello macroscopico (la ricerca dell'università, il portale universitario, l'internazionalizzazione), diventa più complicato legare i cambiamenti alle attività 'ristrette' di un'applicazione o di un settore. Come dimostrare che un canale twitter gestito da un'assistenza tecnica migliora l'esperienza utente e fa aumentare la fidelizzazione e la soddisfazione e quindi, in prospettiva le metriche 'alte' della didattica e della ricerca? Torniamo quindi al sistema di misurazione. Si stabilisce una base di dati misurabili (persone impiegate, ore lavorate, canali utilizzati, quantità di problemi da risolvere, misure di valutazione della soddisfazione dell'utente) e si pongono obiettivi realistici per abbassare i parametri negativi e alzare quelli positivi attraverso anche il cambio di strategia.

A parole sembra molto semplice: perché nella realtà è tanto difficile? Il cambio delle abitudini e la ridiscussione dei ruoli ha certo un peso ma ci sono anche motivi più terra-terra e meno meschini. La principale difficoltà è la mancanza di tempo, manca il tempo per riflettere, per provare con un approccio pragmatico e sperimentale; inoltre nelle organizzazioni si privilegia il "progetto" e la pianificazione, non c'è spazio per verifiche e errori. Un altro problema è quello del coinvolgimento degli attori. Come stabilire un cambio di strategia se siamo coinvolti pesantemente nei processi che vorremmo cambiare? Per superare queste difficoltà è spesso utile affidarci a esperienze e consulenze esterne (pagandole). Ma questo, oltre a essere costoso diventa difficile adotta tarlo per piccole strutture o per singoli processi. Inoltre le strategie, per funzionare, devono essere adattative e non definite una volta per tutte dal consulente di turno.

Riassumendo: per individuare una strategia comunicativa e proporne il cambiamento occorrono 3 ingredienti:

  1. Misura (raccogliere dati quantitativi confrontabili)
  2. Tempo
  3. Verifiche per prove e errori

Prima di passare alla proposta pratica occorre introdurre un altro paio di argomenti:

il trasferimento di conoscenza dentro l'organizzazione. Le novità introdotte dall'analisi e dal cambiamento di strategie non avrebbero effetti se non sono accompagnate da metodi di informazione e formazione. La materia è complessa e ampiamente studiata. In pratica si tratta di ragionare intorno alla questione della conoscenza e di come deve essere trasferita: un filo non sempre lineare che parte dalla 'dritta' del collega più esperto ai master e corsi di alta formazione frequentato dagli impiegati. La conoscenza - per essere trasferita ha bisogno di un ambiente che favorisca la collaborazione, la ricerca di strumenti tecnologici veloci e immediati, la consapevolezza che il proprio sapere è direttamente proporzionale alla capacità di condividere.Tutto questo è un buon punto di partenza ma non basta: se il trasferimento di conoscenza è affidato solo all'oralità, alla collaborazione ad hoc (cioè solo quando serve), contare solo sull'affidabilità e disponibilità dell' esperto del gruppoè inevitabile che ad ogni passaggio, ad ogni difficoltà si ricomincia da capo. E' la deprecabile sensazione di 'reinventare la ruota'. All'estremo opposto della pratica organizzativa c'è la scrittura e la documentazione. Per ogni passaggio, per ogni sviluppo si scrivono documenti e si 'salvano' da qualche parte. Centinaia di pagine, pdf, pagine wiki eccetera, classificati alla meglio e a disposizione di chi ha tempo e voglia di leggerli. Esiste un giusto mezzo, un metodo in grado di prendere il meglio di questi due opposti e favorire il trasferimento della conoscenza. Anche qui, un grosso aiuto può venire dall'utente. Se l'organizzazione decide di comunicare con i social network, se la documentazione viene messa a disposizione agli utenti (o a gruppi di esso) attraverso blog, microblog e siti è possibile (è auspicabile) che anche i processi interni saranno favoriti dai sistemi di comunicazione adottati.

Il secondo argomento da tenere ben presente è che la forza e la capacità del gruppo di cambiare e migliorare è pari alla forza e capacità del membro più debole del gruppo. Debolezza che può derivare da tante variabili (motivazione, stanchezza, carattere eccetera). Invece di affrontare il cambiamento partendo proprio dal soggetto più debole e meno motivato, gli innovatori trasformano il soggetto in 'zavorra' generando nuove frustrazioni e nuovi fenomeni di lock-in.


Ottenute queste condizioni 'a contorno' si può iniziare a lavorare per definire la strategia e verificare gli obiettivi da raggiungere.

Ad esempio la definizione di una strategia comunicativa articola e stabilisce le forme degli interventi diassistenza. Ecco un elenco puntuale della presenza in rete del servizio:

  • Catalogo dei servizi
    Una pagina (o un sito) dove indicare con precisione tutti i servizi
  • Linee guida e manualistica
    Rivolto agli utenti ma utilizzato prevalentemente dagli operatori per tenere traccia e aggiornare sulle modalità d'uso e le istruzioni di tutti i servizi e i processi
  • Sistema di ticket
    Interfaccia con autenticazione degli utenti per la segnalazione degli incidenti e per le richieste
  • Blog e microblog
    Pagine per l'aggiornamento e l'approfondimento dei temi pubblicati in ordine cronologico.
  • Reti sociali
    Presidio (o ascolto) nelle reti sociali (facebook, google plus, twitter).

Catalogo dei servizi. Sorprende, ma neanche tanto, che nell'attività quotidiana, nelle concitate dinamiche dello sviluppo e della manutenzione dei servizi spesso è difficile anche capire 'cosa e chi sta facendo cosa'. Eppure non sarebbe difficile definire un elenco dettagliato dei servizi forniti. Il catalogo è un patto che il 'fornitore' stabilisce con l'utente, è un impegno pubblico e trasparente su quello che si può fare, sui tempi necessari e sulle regole che ci diamo per onorare i nostri impegni. Non è retorica da marketing né ipocrite affermazioni sull'"importanza" del cliente. Una semplice pagina web che contenga il catalogo sei servizi potrebbe essere un passo avanti per la definizione di una strategia comunicativa. Ma una pagina web, sopratutto pubblicata con gli stessi standard visivi e ipertestuali del resto del web aziendale, da sola non basta. Un sito web aggiunge valore al servizio se fa parte di un ecosistema in cui punti di contatto, interfacce per i sistemi di ticket, presidi e conversazioni sulle reti sociali, informazioni continue e aggiornate (blog e microblog), cura dei contenuti di interesse e manualistica sono integrati e raggiungibili dagli utenti.

Linee guida e manualistica. Chi legge le istruzioni? Compulsare manuali e linee guida è piuttosto raro e spesso è l'ultima spiaggia quando non si riesce proprio a capire come usare un'applicazione (e se un software serve a fare semplici operazioni e tu hai bisogno di un manuale è sintomo di qualcosa che non funziona). Le linee guida hanno però una utilità che travalica la semplice (e certo utile) consultazione. E' un testo che si colloca come elemento fondamentale dell'attività comunicativa. E' come la casa pieni di libri che - parafrasando Umberto Eco - rappresenta il luogo della 'memoria universale', il repositorio dovetroveraiquello che cerchi e che altri hanno trovato e scritto per te.

Sistema di ticket. Utilizzare il ticket comesistema tracciato di risposta via e-mailper gli incidenti è solo un modo parziale e insoddisfacente di usare un sistema di questo tipo. Come abbiamo cercato di dimostrare prima, strategie, pianificazione e metodo delle verifiche per prove ed errori insieme allaforza naturaledel software può trasformare ilsistema di ticketing (nel nostro caso OTRS) nel cuore del servizio di assistenza.Per ottenere questo risultato occorre anzitutto eliminare le e-mail come principale strumento per la gestione degli incidenti. L'utente accede ad un pannello (cruscotto) e autenticarsi. Se ha bisogno di aiuto apre un ticket e le sue richieste sono tracciate e archiviate nel sistema. Per ottenere l'autenticazione senza aggiungere un altro fardello (nome utente e password) è possibile utilizzare il sistema di autenticazione unico per tutti i servizi e le applicazioni. Utilizzare un sistema unico di autenticazione comporta però il problema del recupero password, una richiesta che ovviamente non è possibile onorare senza autenticazione. Il sistema quindi deve prevedere un meccanismo di recupero efficiente (automatico e non). Questo 'problema' comporta anche un'opportunità. La tipologia degli utenti può essere suddivisa in 'urentiautenticati' e quelli che per vari motivi (non dispongono della password oppure non sono interessati a essere 'riconosciuti' o semplicemente non hanno credenziali nel sistema). Ecco un esempio di come il software spinge verso una direzione solo partendo dalle sue 'caratteristiche'.

Blog e microblog. Il blog è un sistema di pubblicazione semplice e immediato che consente di veicolare brevi messaggi oppure segnalare documenti e articoli di interesse. Può anche servire come canale di comunicazione interattivo attraverso commenti e interventi degli utenti. E' fondamentale tenere equilibrati tutti gli elementi della strategia comunicativa altrimenti il blog si trasforma in un forum indiscriminato di richieste di aiuto. Curare un blog è un'attività piuttosto pesante e deve avere - non solo - l'adesione del management ma anche la partecipazione 'attiva' dei responsabili.

Reti sociali. La presenza nelle reti sociali del servizio di assistenza e delle persone che ci lavorano è una attività obbligata per qualsiasi strategia. Obbligata non significa 'a qualsiasi costo'. La strategia comunicativa deve affrontare il problema, articolare gli interventi e decidere quale tipo di presenza (presidio, ascolto attivo, partecipazione e attivatori di comunità) è un'attività non banale e - anche in questo caso - ha valore se inserita in un disegno strategico razionale.

Scritto da Francesco Carnera