roadmap: gestire contatti – Parte 2

riparto da dove mi ero fermato.

obiettivo:
capire se ldap può aiutare nella gestione dei c.c.f.p.

referenze:
demystifying LDAP part 1
demystifying LDAP part 2
qualcuno che la pensa come me
ottima guida ldap

il percorso è stato tortuoso ma ha dato alcuni frutti, anche se ho dovuto accettare qualche compromesso che però non penalizza affatto il progetto, anzi sotto certi punti di vista possono essere considerati compromessi positivi.

osservo gia da tempo la rubrica condivisa di evolution e la trovo sempre piu interessante.

 

(per chi avesse problemi a configurare ldap affinchè possa ospitare una rubrica condivisa di evolution può usare questa guida)

ho verificato che la rubrica condivisa di evolution basata sullo schema evolution.schema funziona bene. è potenzialmente accessibile anche da altri email-client come thunderbird e outloook. probabilmente è accessibile anche per ekiga e gaim.
l’idea di utilizzare questa rubrica come punto di partenza mi piace molto perchè è costruita mediante componenti standard. cfr Iana OIDs 1.3.6.1.4.1.8506
questa scelta però comporta l’estensione del concetto di contatto. il concetto di contatto deve comprendere anche i soggetti giuridici ovvero anche la aziende. quindi utilizzando la rubrica di evolution come base impedirà di registrare un’azienda senza specificare almeno un contatto (nome e cognome).
da una parte questo è un vantaggio perchè ogni azienda è costituita da almeno una persona e non ha molto senso registrare un’azienda senza un riferimento umano.
dall’altra parte ci sono dei problemi:
- lo schema di evolution non comprende i campi codice fiscale e partita iva
- si dovranno gestire le aziende duplicate. infatti inserendo in rubrica piu di un contatto appartenente a una certa azienda si avranno in rubrica diversi riferimenti all’azienda.

entrambi i problemi sono sorpassabili. il primo estendendo lo schema di evolution, il secondo accettando un secondo compromesso: l’inserimento e la modifica dei contatti deve avvenire attraverso un modulo dedicato dell’erp. tutte le altre applicazioni che avranno accesso alla rubrica avranno accesso in lettura. ma questo è un bene perchè evita accidentali perdite di dati e garantisce un maggior controllo delle informazione. sicuramente sarebbe interessante se il modulo erp potesse importare vcard prodotte da altre applicazioni.
vincolando l’inserimento al solo erp si può gestire la duplicazione delle aziende puntando sul campo partita iva. si può anche gestire, per quanto riguarda la produzione di documenti fiscali, la divisione tra soggetti giuridici e non.

lo schema inetOrgPerson definisce il campo uid. questo potrebbe essere il campo che consente di collegare i contatti della rubrica con database relazionali esterni.

lo schema evolutionPerson definisce il campo category. è un campo multivalore che posso utilizzate per etichettare un contatto come fornitore e/o cliente e/o personale. il campo category viene visualizzato anche in evolution.

a questo punto il cerchio sembra essere chiuso:
- l’atomo diventa il singolo contatto.
- scrivo un contatto una volta solo.
- posso accedere alle informazioni del contatto da piu applicazioni.
- posso referenziare un contatto in un database relazionale.

sembra esserci tutto. ora la roadmap è:
- capire perchè alcuni campi di evolution risultano non editabili quando si trovano su ldap
- aggiungere i campi partita iva e codice fiscale
- verificare quali sono le applicazioni che effettivamente hanno accesso alla rubrica


{ todo: [campi lockati in evolutin, Single Sign-on, thunderbird, outlook, gaim, ekiga] }

roadmap: gestire contatti – Parte 1

problema:
cercando di realizzare un erp per la mia azienda (e ci ho provato varie volte) mi sono sempre imbattutto nella problematica della gestione dei contatti, dei clienti, dei fornitori e del personale.
Contatti, clienti, fornitori e personale sono gli attori del grande film “operatori economici al lavoro”.
Tutto ciò che è “attività aziendale” si origina dalle interazioni di questi attori. Le aziende sono il contenitore in cui queste attività si svolgono.

Volendo fare un esempio con la chimica, le molecole e gli atomi sono gli attori (contatti,clienti,fornitori,personale), le reazioni chimiche sono il risultato delle interazioni tra questi attori(attività aziendali). L’ambiente è il contenitore in cui le reazioni chimiche hanno luogo (azienda).

Definisco ora le singole categorie di attori:
contatto: è una persona che ha avuto a che fare “in qualche modo” con l’azienda. ad es. un rappresentante che dopo un colloquio ci lascia un biglietto da visita è un contatto.
cliente: è una persona o un’instituzione o un’azienda che ha acquistato un prodotto o un servizio dall’azienda. Ogni cliente ha ricevuto almeno una fattura.
fornitore: è una persona o un’instituzione o un’azienda dalla quale l’azienda ha acquistato un prodotto o un servizio. ogni fornitore ha inviato almeno una fattura.
personale: è una persona che lavora per l’azienda. il personale, mediante l’uso di strumenti, fa si che le attività aziendali possano essere completate. Facendo il solito parallelismo con la chimica, fa da catalizzatore per le reazioni.

D’ora in poi il gruppo degli attori contatti+clienti+fornitori+personale, lo chiamo c.c.f.p.

Quindi i c.c.f.p. vengono definiti in relazione all’azienda di riferimento.

Le definizioni stesse dei c.c.f.p. mettono in luce una serie di problemi:
- un contatto puo essere in alcuni casi anche un cliente e anche un fornitore
- l’oggetto “persona” è assai diverso dall’oggetto azienda o ente. Basta pensare che una persona può essere parte di un’azienda ma un’azienda non puo essere parte di una persona.
- l’oggetto “persona” ha un trattamento fiscale diverso dall’azienda. In generale le persone non hanno la partita iva ma non esistono aziende che non abbiano la partita iva. Poi ci sono persone, come i professionisti, con la partita iva.

A complicare la situazione ci si mettono i canali di comunicazione. I c.c.f.p comunicano fra loro mediante i canali di comunicazione: sono paragonabili ai tipi di legami che le varie molecole instaurano tra di loro.
Tralasciando i canali di comunicazione broadcast, dove un attore lancia il proprio messaggio a chiunque sia in ascolto (siti web, blog, radio, televisione, urlare fuori dalla finestra …) i canali di comunicazione point-to-point e point-to-multipoint piu diffusi sono:
- comunicazione verbale
- telefono
- posta elettronica
- mailing list
- posta
- sms
- chat
- video conferenza

la maggior parte di questi canali sono utilizzabili mediante dispositivi di comunicazione che sempre più spesso sono digitali (cellulare,smart-phone,voip-phone) e che utilizzano almeno una parte delle informazioni proprie di ciascun singolo attore c.c.f.p..
tra i dispositivi, estendendone un poco il concetto, si possono anche annoverare i software (email client etc)

ma ci sono anche alcuni dispositivi non direttamente necessari alla comunicazione ma che utilizzano le informazioni proprie di ciascun singolo attore. Ad es. i navigatori satellitari utilizzano l’indirizzo civico ma non possono essere propriamente definiti dispositivi di comunicazione. E non saprei nemmeno come definirli.

poi ci sono attività aziendali che usufruiscono delle informazioni legate agli attori.
ad esempio gli strumenti di fatturazione, bollettazione ed ordini che utilizzano informazioni proprie del singolo attore c.c.f.p. come l’indirizzo civico. ma non solo: le attività aziendali legate alla produzione possono richiedere informazioni che vanno al di la del semplice indirizzo di fatturazione. un dentista deve risalire alla scheda interventi del paziente, un informatico alla scheda interventi e anche alla scheda che definisce la struttura informatica del cliente. questo è un esempio di come, dalle informazioni legate agli attori discendano una miriade di dipendenze fondamentali per l’azienda anche in fase operativa non solo in fase marketing o gestionale/amministrativa. Ed ecco perchè degli errori strutturali nella gestione delle informazioni dell’insieme c.c.f.p. possono causare gravi problemi in tutti i comparti aziendali.

quindi per “gestione dei c.c.f.p.” intendo l’utilizzo di un contenitore/sistema (magari compartimentato) per l’insieme dei c.c.f.p. a cui porre domande mediante diversi dispositivi ed ottenere risposte compatibili per il dispositivo in uso.
Ho detto utilizzo perchè la gestione dei c.c.f.p. non dovrebbe costringere l’attore a porsi domande del tipo:
- Mario Rossi è un fornitore?
- in quale archivio sta Mario Rossi?
- con che strumento recupero l’indirizzo di Mario Rossi?
- è possibile che l’indirizzo di Mario Rossi che ho ottenuto dopo l’interrogazione sia obsoleto perchè nel frattempo le nuove informazioni sono state stoccate da un altro attore in un diverso contenitore/sistema?

Quindi gestire i c.c.f.p. significa per esempio:
voler:
- inserire i dati di Mario Rossi a partire da un unico punto di accesso
- consentire l’accesso alle informazioni di Mario Rossi al solo personale autorizzato
- frammentare le informazioni relative a Mario Rossi affinchè informazioni sensibili siano disponibili al solo personale competente
- accedere ai numeri telefonici dei ccfp utilizzando il client di posta.
- accedere ai numeri telefonici dei ccfp utilizzando lo smat-phone o il cellulare o il voip-phone
- accedere alle email dei ccfp utilizzando il client di posta
- accedere alle email dei ccfp utilizzando lo smart-phone o il palmare

non voler:

- trovare i dati di Mario Rossi sparpagliati in piu punti e soprattutto discrepanti fra loro
- riscrivere i dati di Mario Rossi sui vari dispositivi che utilizzo per stabilire comunicazioni
- esportare/imporare dati tra vari contenitori al fine di poter accedere alle informazioni mediante i vari dispositivi. se l’attivita di esportazione, importazione è proprio necessaria a causa delle incompatibilità tra i vari dispositivi allora deve essere il sistema a gestire queste attività. L’attore è un utilizzatore delle informazioni, non un componente del sistema informativo.

quindi:
la situazione è assai complessa. non sono un esperto nel settore e magari sto solamente vaneggiando, ma personalmente non ho mai trovato un contenitore/sistema che possa davvero risolvere i problemi sopra esposti. ho la netta impressione che l’atteggiamento generale dell’informatica di fronte a questo scenario sia qualcosa del tipo:
vaneggio on
“ok è un gran casino. semplifichiamo: i contatti non esistono. Il personale e le autorizzazioni le gestiamo da un’altra parte per i windows, mentre per i linux … rimandiamo la decisione, i mac … ma la apple non era fallita? :-D => esistono solo clienti e fornitori…. Accedere a clienti e fornitori attraverso il palmare? attraverso il software per la posta elettronica? non se ne parla neanche. Tralasciamo l’uso attraverso il web perchè tanto non lo usa nessuno e poi ci vuole un sacco a svilupparlo …”
vaneggio off
risultato: tante soluzioni tutte decisamente limitanti sotto tutti i punti di vista. possibile che non si possa fare qualcosa di piu ??? … porco cane siamo andati sulla luna ma facciamo ancora fatica a trovare un numero di telefono.
ok ok ci saranno sicuramente dei compromessi da accettare ma forse la sfida di partenza dovrebbe essere: compromessi zero o quasi …
un compromesso accettabile potrebbe essere quello di utilizzare solo alcuni tipi di dispositivi piuttosto che altri (nokia piuttosto che sony, tanto per dire), quello di utilizzare un browser piuttosto che un set di applicazioni java, quello di usare mozilla piuttosto che internet explorer. sicuramente è inaccettabile penalizzare un sistema operativo o un altro, oppure l’idea di utilizzare contenitori/sistemi eterogenei per accedere alle informazioni obbligando l’utente a diventare parte del sistema informativo.

studiando la faccenda la domanda che ricorre piu spesso nella mia mente è: possibile che non esistano sistemi per la gestione di questo marasma? in effetti i sistemi ci sono e chissa quanti. il punto è che non sono per tutti. ci sono soluzioni offerte dai grandi player come IBM, SUN etc. ma costano e sono molto molto complesse. è addirittura difficile capire che cosa offrono. chiaramente c’è bisogno di un supporto da parte del produttore gia dalla fase di valutazione del sistema.
è pero impensabile che piccole aziende possano usufruire di tali sistemi … anche se, a pensarci bene, non vedo grandi differenze di utilizzo di tali informazioni tra grandi e piccole imprese. tant’è che io stesso mi sto concentrando su queste cose.
e poi diciamocelo chiaro … le soluzioni non-open-source non sono poi cosi simpatiche :-D

allora voglio vedere se il mondo open-source mi offre dei “componenti” con cui posso assemblare qualcosa di interessante.