Lo schema che segue mostra l' architettura di una possibile applicazione BBT atta a creare un Archivio di Sintesi: con questa definizione facciamo riferimento ad una struttura che contiene un insieme sintetico di info ricavate dall' attività svolta nel tempo dall' Azienda ed utilizzabili a 360 gradi per prendere decisioni aziendali o effettuare valutazioni sui contatti esterni. Il mondo esterno alla BBT è, in questo caso, rappresentato dall' ERP aziendale da cui si prelevano informazioni amministrative e gestionali e dal CRM da cui si prelevano informazioni commerciali: le informazioni acquisite vengono elaborate (Engine e Box) sulla base del modello di regole aziendali definito e concorrono alla costruzione del nostro Archivio di sintesi.

Il rapporto con l' esterno è regolato da flussi che a loro volta sfruttano come nodi i metodi, procedure c# che possono raggiungere anche un certo livello di complessità, per l' interfacciamento con i sistemi ERP e CRM.

Di seguito riportiamo l' esempio di un flusso da cui si rileva da subito la fondamentale importanza per la generazione di documentazione aziendale: il problema della documentazione è basilare non tanto nella fase di realizzazione di una applicazione quanto nella manutenzione della stessa che si richiede nel tempo. Diventa fondamentale nel momento in cui l' esperto che ha fornito gli elementi per la costruzione del modello di regole, per motivi diversi non fa più parte dei quadri aziendali: la conoscenza/esperienza rimane in azienda.

Il flusso consente di accedere a tutti iClienti dell' azienda e per ognuno di essi preleva informazioni commerciali ed amministrative: queste infomazioni vengono elaborate sulla base di un modello di regole predefinito e vengono salvate all' interno di un Archivio di Sintesi, disponibile al mondo aziendale.

Analizziamo i singoli nodi del flusso:

ReadNextClient

Metodo che si interfaccia sia con il CRM che con l' ERP per acquisire le informazioni da elaborare: non ci sono limitazioni alla sua architettura;

ArrangesTheDataForClassification

Decision Rule il cui obiettivo è quello di inizializzare gli oggetti utili alla classificazione: ad es. valorizzare il valore totale degli ordini fatti dal cliente, il numero di ordini fatti, il numero di offerte non andate a buon fine, l' indice di affidabilità, la nazione di appartenenza, .....

CustomersCommercialClassification

Flusso il cui obiettivo è definire la Classificazione Commerciale del Cliente: a seguire ne vedremo un esempio;

CustomersAccountingClassification

Flusso il cui obiettivo è definire la Classificazione Contabile del Cliente: a seguire ne vedremo un esempio;

UpdateSummaryArchive

Metodo il cui compito è l' aggiornamento dell' Archivio di Sintesi;

Modello x la Classificazione Commerciale

Classificare i Clienti potrebbe servirci ad es. nelle campagne marketing (quali promozioni e/o prodotti da proporre) o per definire il livello di sconto minimo o massimo da applicare in fase di Ordine o ....

In questo esempio, possiamo pensare ad una classificazione semplice che ci consenta di definire il Cliente (non si classifica l' importanza del Cliente in quanto lo stesso è sempre e comunque importante) di:

• Livello Alto;
• Livello Medio;
• Livello Basso;

Ipotizziamo che questa classificazione possa dipendere da:

• Area geografica di appartenenza: Italia, Europa, Asia, Africa, America, Australia;
• Nr. ordini emesso x mese;
• Importo medio degli ordini;
• Tipologia di prodotto ordinato: alto livello, medio livello, basso livello;

Di seguito un esempio di Decision Rule (per motivi di leggibilità ci limitiamo a svilupparne solo un ramo) che potremmo utilizzare per classificare i Clienti:

I Clienti che appartengono all' area geografica Italia se hanno un numero medio di ordini mensile inferiore ad uno e un importo medio dell' ordine minore di 25.000€ sono classificati di Basso Livello. Se invece l'importo medio dell'ordine è maggiore o uguale a 25.000€ sono classificati di Livello Medio.
Nel caso in cui Il numero medio mensile di ordini sia maggiore o uguale ad uno con un importo inferiore ai  25.000€, si valuta la tipologia di prodotto: per prodotti di Alto/Medio Livello il Cliente viene classificato di  Livello Alto, per prodotti di Basso Livello viene classificato di Livello Medio. Se l'importo medio dell'ordine è maggiore o uguale a 25.000€, comunque viene classificato di Livello Alto.

Modello per la Classificazione Contabile

In questo esempio ci limitiamo a classificare il Cliente come:

• Affidabile: i suoi pagamenti sono regolari e in tempi accettabili;
• Ritarda: i suoi pagamenti sono regolari ma non sempre in tempi accettabili;
• Inaffidabile: pagamenti in ritardo e su sollecito o mancati pagamenti;

Per semplicità basiamo questa classificazione sulle informazioni che seguono (informazioni che sono ricavate dall' ERP):

• Presenti pagamenti insoluti;
• E' stato sollecitato;
• Tempo medio di ritardo in gg;

Di seguito un esempio di Decision Rule che potremmo utilizzare per classificare i Clienti:

I clienti che presentano insoluti sono classificati come Inaffidabili. I clienti che non hanno insoluti ma hanno solleciti sono classificati come ritardatari.
I clienti che non hanno insoluti e non hanno solleciti e hanno un ritardo medio nei pagamenti minore o uguale a 45 giorni, sono classificati Affidabili: se il ritardo medio è maggiore di 45 giorni sono classificati come Ritardatari.

Esempio di gestione dell' Archivio di Sintesi

Lo schema che segue mostra l' architettura di una possibile applicazione che vede il CRM utilizzare l' ambiente BBT come BRMS per elaborare informazioni contenute nell' Archivio di Sintesi.

Il CRM può accedere all' ambiente BBT utilizzando il servizio BBT-Service messo a disposizione dall' ambiente BBT stesso, indicando quale Box/Modello si vuole utilizzare per elaborare le informazioni dell' Archivio di Sintesi.

A puro titolo di esempio possiamo ipotizzare che il CRM nella fase di creazione dell' Offerta richieda alla BBT quale sconto può applicare al Cliente.

Questo avviene richiamando il servizio indicato e fornendo allo stesso le informazioni:

• Box / Modello da utilizzare;
• Flusso o Decision Rule da attivare: questa informazione può non servire se si utilizza un modello ad hoc , predisposto per definire questo tipo di informazione;
• I riferimenti del Cliente: sostanzialmente il Codice; 
• Cosa si apetta di risposta: nel caso in oggetto sarà il valore dello Sconto;

Il Servizio attiva l' ambiente BBT sul Box/Modello indicato e ritorna il valore dello Sconto.

Di seguito un esempio di quello che potrebbe essere il flusso che viene attivato (per motivi di leggibilità ci limitiamo a svilupparne solo un ramo) :

Si accede all' Archivio di Sintesi per prelevare le info del Cliente che servono quindi si procede a definire lo Sconto applicabile.

La decision Rule si documenta da sè.