Nella nostra esperienza di sviluppo software web, in particolare riferito alle realizzazione di portali aziendali, genericamente definiti portali b2b, abbiamo individuato alcuni “punti salienti”, cioè aspetti che se trascurati possono portare a grosse problematiche future e a conseguenti attività di refactoring svolte di fretta e con i sistemi già live.
Prevedere queste criticità e farle presente al nostro fornitore IT può aiutarlo a quantificare al meglio gli effort e ci può evitare problematiche in corso d’opera.
Elenchiamo questi punti nella speranza che possano servire ad affrontare al meglio la progettazione di un portale b2b:
1. La sincronizzazione delle anagrafiche
Generalmente costituisce una specifica di progetto, ma ci può capitare di dimenticarci di segnalare il fatto che le anagrafiche gestite dal portale (clienti, fornitori, agenti, prodotti, materiali, etc) risiedono già da qualche altra parte (nel software gestionale, in un applicativo specifico, in un database…..) o di sottovalutare quali siano le implicazioni derivanti dal doversi sincronizzare con altri sistemi.
E’ quindi molto importante indagare fin da subito dove risiedono al momento le anagrafiche che intendiamo coinvolgere nel progetto e valutare accuratamente le problematiche relative alla sincronizzazione.
Queste generalmente possono impattare 3 tipologie di aspetti:
- organizzazione sistemistica: il gestionale o l’applicativo legacy è raggiungibile dalla DMZ (zona demilitarizzata) della rete in cui tipicamente risiede il portale?
- struttura dei dati: esistono informazioni a cui ci si può appoggiare per effettuare sincronizzazioni parziali come la data ultima modifica etc?
- utilizzo dell’applicativo: la procedura di sincronizzazione può essere svolta durante le ore di utilizzo dell’applicativo o è necessario “schedularla” nelle ore di chiusura? Le ore di chiusura sono sufficienti per portare tutti i dati necessari?
2. La gestione delle utenze
Anche questo aspetto può far parte delle specifiche di progetto. Le utenze che devono poter accedere all’applicativo esistono già all’interno di una directory interrogabile tramite protocollo LDAP o simili.
Questa funzionalità dovrebbe sempre essere prevista dal framework che abbiamo scelto per lo sviluppo del portale.
In particolare può essere molto utile agganciarsi ad una directory aziendale non solo per recuperare l’elenco degli utenti e verificarne le credenziali di accesso, ma anche per rilevarne l’appartenenza a ruoli o gruppi e di conseguenza l’abilitazione ad eseguire determinate tipologie di azioni. Questo aspetto può costituire una grande semplificazione per i tecnici IT dell’azienda che potranno pilotare “chi può fare cosa” nel nuovo portale b2b senza dover accedere al suo back-end e continuando a lavorare con i loro strumenti di operatività quotidiana.
3. L’implementazione del collegamento utenze – anagrafiche
Questo è uno di quei punti “subdoli” la cui complessità viene spesso sottovalutata.
L’esempio tipico è il seguente:
L’azienda decide di creare un portale b2b per far accedere i propri clienti e permettere loro di consultare alcuni dati (di produzione, gestionali, etc).
La domanda da porsi a questo punto è: i clienti verranno abilitati dall’azienda e riceveranno le credenziali via mail o dovranno registrarsi in autonomia?
Il problema insorge in entrambi i casi ed è dovuto all’aggancio tra l’utente del portale (rappresentato tipicamente da email, nome e cognome e qualche altro dato di profilo) e l’anagrafica cliente (censita all’interno del nostro gestionale e rappresentata da un codice).
Nel caso in cui sia la procedura di sincronizzazione delle anagrafiche dal gestionale a creare anche gli utenti per i clienti l’aggancio potrà essere automatico, ma bisognerà gestire con grande attenzione le credenziali di accesso (che non potranno essere uguali per tutti e dovranno essere comunicate senza intoppi ); nel caso in cui siano i clienti a registrarsi invece bisognerà prevedere un processo anche minimo di approvazione delle singole richieste di registrazione e agganciare manualmente l’utente creato all’anagrafica a cui fa riferimento.
4. Le gestione delle utenze legate ad un cliente o ad un fornitore
Una problematica che è molto importante evitare fin dall’inizio con una adeguata progettazione architetturale dell’applicativo è la gestione delle utenze legate all’anagrafica del cliente o del fornitore.
Fornire un’unica utenza (quindi una sola coppia email-password) al cliente o al fornitore implica costringerlo alla condivisione di tali credenziali all’interno del suo staff, mettendolo quindi nella condizione di non poter individuare l’autore di determinate azioni nel momento in cui sia necessario farlo. Lo si pone di fronte inoltre a varie difficoltà inerenti al reset della password, per cui se uno dei membri del suo staff la cambia è molto probabile che al prossimo accesso verrà creato un ticket di assistenza.
Per prevenire situazioni di questo genere è bene dotare il cliente/fornitore di una propria area operativa, all’interno della quale possa gestire in autonomia le proprie utenze abilitate all’accesso al portale, creando nuovi utenti e disabilitando eventualmente quelli che non fanno più parte dello staff.
5. La gestione integrata della document library
Gli allegati svolgono sempre un ruolo importante.
Durante lo sviluppo di una web application, indipendentemente dalla sua natura o dal suo utilizzo, è molto probabile che ad un certo punto il nostro capo o responsabile di progetto rivolga delle richieste del tipo “In questo punto possiamo mettere il caricamento di un allegato??”… che poi non è uno ma sono molti e soprattutto senza limiti sulle estensioni dei file (e sulla dimensione!)…
Questi file che possono essere caricati nei punti più disparati dell’applicativo, sia esso una web application o un portale, sarebbe bene che possano confluire in modo organizzato all’interno della Document Library dell’applicativo, ossia all’interno della sua area documentale.
Questo plus tecnologico, se previsto fin dall’inizio, può offrire all’azienda un accesso separato alla consultazione dei documenti e diventare una sorta di “drop-box” aziendale dotato quindi delle seguenti feature:
- possibilità di raggruppare i file tramite cartelle, categorie, tag, tipi di file
- ricerca “full text” (nel contenuto dei file) grazie al motore di indicizzazione interno delle informazioni
- versionamento dei file con possibilità di inserimento di commenti e gestione collaborativa delle informazioni
6. La ricerca basata sul motore di indicizzazione interno
Ci agganciamo alla feature relativa all’area documentale, per specificare che tale funzionalità dovrebbe contraddistinguere l’intero applicativo, consentendo una indicizzazione dei dati (e quindi una ricerca rapida e performante) non solo per i documenti ma per tutte le informazioni gestite.
E’ possibile, in determinati contesti, allestire una vera e propria ricerca “in stile Google” che non si applichi in modo rigido solo sui titoli (nomi di prodotti, identificativi di pratica, etc) ma anche sulle descrizioni, sui tag, sulle categorie e sugli attributi degli oggetti che stiamo ricercando.
7. L’adattamento responsivo
E’ un punto questo che può risultare ovvio e spesso rientra a pieno titolo nelle specifiche del progetto.
Ci teniamo a sottolinearlo comunque perchè può capitare di non considerare come si comporterà l’”adattabilità” del nostro applicativo alle visualizzazioni effettuate su dispositivi mobili come tablet e smartphone nelle sezioni in cui la ricchezza di dati si fa considerevole…
“Come viene gestita da tablet quella tabella di 25 colonne?”
“Cosa succede se un utente inserisce un valore molto lungo per quel campo a cui abbiamo assegnato un quinto della nostra videata?”
Domande di questo tipo è importante che trovino risposta in fase di progettazione del layout grafico dell’applicativo per evitare effetti (e sorprese) spiacevoli poi in fase di utilizzo.
8. Il supporto nativo del multilingua
Anche questo punto può sembrare una ovvietà…. ma nello sviluppo software di ovvietà ce ne sono davvero poche..
Infatti con “localizzazione” dell’applicativo, si intende l’attività di predisposizione dello stesso al cambiamento di lingua che l’utente può azionare in qualunque momento.
Le traduzioni mostrate non devono essere solo quelle relative alle “etichette” (i bottoni, le voci di menù, i titoli delle sezioni etc), ma anche i dati gestiti, quindi (esempio tipico) se importiamo i prodotti da un gestionale con nomi di prodotto e descrizioni (brevi, estese o entrambe) è bene prevedere che anche questi dati siano “localizzati”, cioè esista la possibilità anche a posteriori di creare per essi delle traduzioni senza dover mettere mano al codice dell’applicativo.
Inoltre la domanda da porsi spesso relativamente alle nostre famose bandierine è “quanti click deve rifare l’utente nel momento in cui cambia la lingua? Rimane nella stessa pagina in cui era o deve ripartire dalla home (o dashboard) dell’applicativo?”
Devi progettare lo sviluppo di un portale b2b?
Compila il form sottostante, riceverai una prima consulenza gratuita:
