Un extranet cliente è spesso presentato come una serie di schermate: cruscotto, documenti, ordini, profilo e supporto. In realtà, diventa una porta d’ingresso al sistema informativo. Espone dati, avvia operazioni e rappresenta l’azienda a ogni interazione. La sua progettazione deve quindi riunire prodotto, architettura, sicurezza e gestione.
Il successo non si misura dal numero di funzionalità. Un buon extranet riduce le richieste manuali, rende le informazioni affidabili, accelera le attività ricorrenti e dà al cliente una comprensione chiara della sua situazione. Deve anche impedire che un utente acceda al fascicolo di un'altra società, che un documento scaduto rimanga presentato o che un'operazione venga ripetuta per errore.
Partire dai compiti, non dal menu
L'inquadramento inizia con gli eventi della relazione con il cliente: richiedere un servizio, trasmettere un documento, seguire una pratica, convalidare una proposta, scaricare un rapporto, pagare, segnalare un'anomalia o aggiungere un collaboratore.
Per ogni compito, documentare:
- il grilletto ;
- le informazioni necessarie;
- l'attore e la sua organizzazione;
- gli stati possibili;
- le convalide;
- i sistemi coinvolti ;
- le prove da conservare;
- le notifiche;
- gli errori e le riprese.
Questo metodo evita di riprodurre nel portale la struttura interna dell’azienda. Il cliente non deve conoscere i nomi dei servizi o i codici tecnici per raggiungere il suo obiettivo.
Definire una fonte di verità per dato
Il portale può visualizzare informazioni provenienti da un CRM, da un ERP, da un'applicazione aziendale o da un archivio documentale. È necessario designare il proprietario di ciascun dato e la direzione di sincronizzazione.
Una copia locale può migliorare le prestazioni o la resilienza, ma richiede una regola di freschezza, una gestione dei conflitti e una visibilità sull'ultima sincronizzazione. I dati inseriti nell'extranet devono essere convalidati prima di essere propagati nei sistemi critici.
Il browser non deve mai diventare la fonte di verità per un'operazione importante. Ogni azione deve essere controllata lato server con una chiave di idempotenza quando è possibile un invio doppio.
Progettare l'autorizzazione prima degli schermi
L'autenticazione risponde a « chi sei? ». L'autorizzazione risponde a « cosa puoi fare su questa risorsa specifica? ». Questa seconda domanda è la più difficile.
Un cliente può appartenere a una società, accedere a diversi siti, delegare diritti o avere un ruolo temporaneo. La stessa persona può essere amministratrice di un istituto e semplice lettrice di un altro. Il modello deve quindi combinare ruolo, ambito e condizioni.
Le regole essenziali sono:
- rifiuto per difetto;
- controllo lato server su ogni azione;
- portata esplicita per organizzazione o risorsa;
- separazione delle funzioni sensibili;
- data di scadenza delle deleghe;
- registrazione delle modifiche dei diritti;
- test sistematici degli accessi orizzontali e verticali.
Catena di fiducia di un extranet, dall'autenticazione ai servizi aziendali e al registro di controllo.
Autenticazione: adattare il livello di fiducia al rischio
Un account e una password non costituiscono sempre una strategia sufficiente. L’extranet può offrire un’autenticazione multifattore, un SSO con il fornitore di identità del cliente, chiavi di accesso o meccanismi di recupero rafforzati.
Il livello deve dipendere dalle azioni. Consultare una notizia non ha lo stesso impatto che scaricare un documento sensibile o modificare un beneficiario. Una riautenticazione può essere richiesta prima di un'operazione critica.
I percorsi di creazione, invito, sospensione e partenza di un utente devono essere progettati con la stessa cura della connessione. Gli account orfani e gli inviti senza scadenza sono rischi frequenti.
Costruire un cruscotto orientato all'azione
Il cruscotto deve rispondere a tre domande: cosa sta succedendo, cosa richiede la mia attenzione e quale è la prossima azione?
Una pila di schede statistiche è raramente sufficiente. Le priorità possono essere: pezzi mancanti, convalida in attesa, scadenza, incidente, nuova versione di un documento o messaggio del supporto. Ogni elemento deve portare a un'azione chiara e mantenere il proprio contesto.
Gli indicatori devono utilizzare definizioni condivise con il settore. Un « fascicolo in corso » non deve significare una cosa nell'extranet e un'altra nel back-office.
Documenti: versione, prova e controllo degli accessi
L'archiviazione documentale deve distinguere il file, la sua versione, i suoi metadati e i suoi diritti. Un URL prevedibile o duraturo non deve aggirare l'autorizzazione. I download sensibili possono utilizzare link brevi firmati, sempre verificati dal server.
Per ogni documento, prevedere:
- tipo e stato;
- proprietario e perimetro;
- data di emissione e di scadenza;
- versione sostituita ;
- impronta o prova di integrità quando necessario;
- regole di conservazione;
- accessi e download registrati.
L'anteprima deve essere isolata e i file in ingresso devono essere analizzati. I formati non sicuri non devono essere eseguiti nel contesto dell'applicazione.
Notifiche senza rumore né fuga di informazioni
Una notifica deve informare senza rivelare dati sensibili in un canale non controllato. L'email può annunciare che un documento è disponibile, quindi rimandare all'extranet autenticato invece di allegare il file.
L'utente deve poter scegliere alcune preferenze, ma gli avvisi di sicurezza o gli obblighi contrattuali possono rimanere imposti. Gli invii devono essere idempotenti, tracciabili e raggruppati quando si verificano più eventi.
Integrazioni e trattamenti asincroni
Le chiamate a sistemi di terzi falliscono. L'architettura deve prevedere code di messaggi, ripetizioni, limiti di velocità, ritardi, correlazione e stato visibile. Un'azione non deve essere presentata come completata se è solo in attesa di elaborazione.
I webhook in entrata devono essere autenticati, riproducibili in modo sicuro e deduplicati. Le API in uscita devono applicare ritardi, circuit breaker e politiche di retry adeguate per non amplificare un guasto.
Ricerca e navigazione
La navigazione per organizzazione interna è raramente intuitiva. Una ricerca trasversale può riguardare fascicoli, ordini, documenti e riferimenti, pur rispettando i diritti prima e dopo l’indicizzazione.
I filtri devono rimanere comprensibili, conservare lo stato nell'URL quando questo aiuta la condivisione e fornire un'alternativa alle tabelle larghe su mobile. Le esportazioni devono rispettare lo stesso ambito dello schermo.
Accessibilità e usi reali
Un extranet è spesso utilizzato in situazioni di urgenza, su un computer bloccato, un cellulare o con tecnologie di assistenza. I moduli devono conservare i dati in caso di errore, annunciare chiaramente le convalide e consentire una navigazione completa tramite tastiera.
I tavoli complessi richiedono intestazioni correttamente associate, una visualizzazione responsive e talvolta una versione a schede. I tempi di sessione devono essere segnalati e l’utente deve poter prolungare la sua sessione senza perdere il lavoro.
Registro di audit e supporto
È necessario poter ricostruire gli eventi importanti: login, modifica dei diritti, download, convalida, modifica di un dato, invio a terzi. Un registro di audit deve essere protetto, marcato temporalmente, correlato e limitato alle informazioni necessarie.
Il supporto beneficia di una visualizzazione di assistenza che spiega il contesto senza permettere l'usurpazione silenziosa. Qualsiasi presa di controllo o impersonificazione deve essere esplicita, autorizzata, temporanea e tracciata.
Progettare lo sfruttamento fin dalla definizione dell'ambito
L’extranet ha bisogno di supervisione tecnica e commerciale: disponibilità, errori, code bloccate, sincronizzazioni in ritardo, notifiche fallite e percorsi abbandonati in modo anomalo. Obiettivi di servizio realistici devono essere definiti secondo la criticità.
Backup, ripristino, piano di continuità e gestione dei segreti fanno parte del prodotto. Gli ambienti di test devono utilizzare dati anonimizzati o sintetici.
Misurare il valore
I buoni indicatori non si limitano al numero di connessioni. Seguire:
- tempo necessario per completare un compito;
- percentuale di richieste gestite senza intervento manuale ;
- numero di solleciti per pezzo mancante;
- errori di digitazione e correzioni;
- termine di messa a disposizione dei documenti;
- contatti di supporto evitati o meglio qualificati ;
- soddisfazione sui percorsi critici.
Una diminuzione delle connessioni può essere positiva se le notifiche e le automazioni rendono alcune visite inutili.
Un extranet è un prodotto durevole
La prima versione deve dare priorità ad alcuni percorsi completi, sicuri e misurabili. Le fondamenta — identità, diritti, dati, audit, integrazioni e osservabilità — permettono poi di aggiungere funzioni senza moltiplicare le eccezioni.
Partitech progetta, acquisisce e mantiene piattaforme aziendali connesse al sistema informativo. L'intervento può coprire la definizione funzionale, l'architettura, l'esperienza utente, lo sviluppo, la sicurezza, la verifica e l'esercizio dell'extranet nel tempo.
Parliamo del tuo progetto
Inquadrare o modernizzare il vostro extranet con Partitech. Contatta Partitech.