Carlo Petti

DocFlow ha creato il “sistema informativo

documentale”, in una parola Sidoc,
per guidare le aziende verso il risparmio,
l’efficienza e la qualità nella gestione
delle informazioni e dei dati
dicembre 2007
 MONDO DELL’OFFERTA A CURA DI PINO FONDATI

L’INFORMATICA
DIVENTA AGILE
Un modo diverso di “fare informatica”? Esiste, eccome. Provate a
chiedere a Carlo Petti, fondatore e presidente di DocFlow. Infor-
matico appassionato ma anomalo, “bits&bytes, ma senza esage-
rare”, ha sempre amato l’elaborazione e la riflessione, i cosiddetti
“brainstorming” (tutti rigorosamente fatti sul campo) con i suoi col-
laboratori, per arrivare ogni volta a definire una visione, una filoso-
fia da portare poi sul mercato. Non di sola teoria fine a se stessa
si tratta, quindi, ma di concetti con salde fondamenta nella pratica.
In questo modo, è nato il concetto di “informatica agile”. Che, in-
tendiamoci, non nasce come un fungo nel deserto arido, ma viene
da lontano. “In tutti questi anni, DocFlow ha elaborato e affinato
nel tempo una visione chiamata sistema informativo documentale,
in un acronimo Sidoc”. Visione sino a qualche anno fa incompren-
sibile ai più, confessa Petti, ma che oggi è pienamente condivisa
dai clienti. “Questo vuol dire che la visione era ed è corretta, e che
tutti, chi più chi meno, si muovono nella direzione da noi indicata
sei-sette anni fa”.

PROCESSI COLLABORATIVI E PROCESSI MISTI

Petti parte da una constatazione semplice: oggi, nelle aziende
viene trattata solo una parte irrilevante della conoscenza, il “famoso
10-20%”; tutto il resto, viene bellamente ignorato perché, si dice,
“è nei documenti”, creando in questo modo una forte dicotomia
tra dato e documento, invero alquanto artificiosa. DocFlow è an-
data oltre, affermando convinta che la questione non riguarda “dato
e/o documento, dato versus documento”, bensì i processi. “C’è
una quantità di processi collaborativi e di processi misti, cioè pro-
cessi in parte collaborativi in parte computazionali, usati tutti i giorni
per lavorare, che in realtà non sono supportati dall’informatica”.
Petti, informatico da una vita, addossa le responsabilità di questa
lacuna all’IT che ha cessato di svolgere pienamente il ruolo di vei-
colo di innovazione.

L’IT CHE CALA DALL’ALTO

Secondo Petti, in questi anni l’informatica ha messo a disposizione
degli utenti una miriade di dispositivi per l’elaborazione di dati.
Quando si è trattato di attivare strumenti che supportassero i pro-
cessi collaborativi, ci si è accorti fatalmente del forte ritardo accu-

dicembre 2007 39
L’INFORMATICA DIVENTA AGILE
mulato. La spiegazione sta nel fatto che gestire processi col-
laborativi è complesso e costoso, perché sono destrutturati, e
quindi difficilmente ingabbiabili. Per poterli trattare al meglio, la
cosa migliore è “andare dall’utente, vedere e capire il modo in
cui lavora e, finalmente, costruire strumenti che lo aiutino a la-
vorare”. Perché nei processi collaborativi l’unico padrone è
l’utente e per cambiarli è necessario conquistare il suo con-
senso.
Per implementare i processi collaborativi non sono sufficienti i
nuovi strumenti disponibili, occorre anche un nuovo modo di
progettare che DocFlow chiama “informatica agile”. Di cosa si
tratta? “Noi pensiamo che l’Erp debba tornare a fare le cose
essenziali, gestire la mole di dati che documenta le transazioni
dell’azienda. Per i processi collaborativi è possibile una pro-
gettazione bottom-up che coniughi la nuova tecnologia con
l’esperienza dell’utente”.
IL BUSINESS PROCESS MANAGEMENT
Oggi è possibile un approccio diverso ai processi collabora-
tivi, grazie agli strumenti per la gestione dei flussi documen-
tali: il document management e il workflow management,
esteso oggi al Bpm, che permettono un approccio essenziale,
di tipo progressivo. Un bel balzo avanti rispetto all’approccio
top down tipico dei grandi progetti computazionali, nei quali
la rigidità è d’obbligo per evitare ritardi e aumenti di costo. Al
contrario, l’approccio bottom up parte dall’analisi del pro-
cesso, al fine di cogliere solo le coerenze indispensabili con il
resto, per focalizzarsi sull’implementazione del processo. Inol-
tre, il bottom up permette a sua volta un approccio “proto-
tipo incrementale”: si va dall’utente, si cerca di capire in tempi
brevi di cosa ha bisogno, si abbozza una soluzione, la si va-
luta insieme, e sempre insieme si prosegue la realizzazione
sul campo. Fino ad arrivare, ritocco dopo ritocco, alla solu-
zione finale.
PROTOTIPO INCREMENTALE
Alla formulazione della metodologia del “prototipo incremen-
tale”, DocFlow è arrivata con un’esperienza sul campo, ri-
guardante lo sviluppo di un’applicazione per la gestione dei
reclami per una nota catena italiana di supermercati. “L’evolu-
zione è durata più di due anni, perché tutte le volte che met-
tevamo in produzione un modulo ci accorgevamo, noi e loro,
che occorreva aggiungere nuovi dettagli e varianti”. E questo
non derivava certamente da un errore di analisi bensì dal-
l’evoluzione del modello organizzativo; uno dei punti essenziali
infatti dei processi con forte impatto collaborativo è che è pos-
sibile definire la situazione attuale (as is) ma è impossibile de-
40
Chi è Carlo Petti
Carlo Petti, fondatore e presidente di DocFlow, ini-
zia la sua attività professionale nei Laboratori di Ri-
cerca e Sviluppo dell’allora Olivetti a Pregnanza
Milanese, prima come pro-
gettista logico poi dedican-
dosi allo sviluppo del
software di base e al sup-
porto sistemistico. In seguito,
il passaggio a Texas Instru-
ments, dove ricopre il ruolo di
Direttore commerciale della
Divisione Sistemi Digitali. Nel
1979, inizia l’attività imprendi-
toriale prima come consu-
lente e poi con la creazione
di Brain Informatica, società attiva nel settore del
Cad/Cam. Nel 1987 fonda la filiale italiana di Inter-
leaf, società leader nell’electronic publishing, di cui
è presidente fino al 1995, anno in cui si costituisce
DocFlow. Gioca a tennis e a golf.
terminare a priori la situazione futura (to be) dal momento che
è ignoto l’impatto che il nuovo modello avrà sugli attori del pro-
cesso. “Da qui, i continui aggiustamenti fino a trovare un equi-
librio stabile”. Fortunatamente, l’adozione tempestiva di uno
strumento di Bpm ha permesso di fare le modifiche “senza
buttare via tutto ogni volta” e direttamente sul campo senza
bloccare l’operatività. Alla fine, l’applicazione oggi in uso è
molto più completa di quella originariamente concepita. Tutto
questo ha fatto capire a Petti e ai suoi come una soluzione per
processi misti a prevalenza collaborativi sia anche il frutto di un
compromesso, di un continuo dialogo col cliente. “Per questo
la metodologia dell’approccio incrementale è quella più adatta.
Non abbiamo inventato nulla, sappiamo che questa metodo-
logia è già adottata in altri campi. Noi l’abbiamo applicata ai
processi di gestione dei flussi collaborativi”.
MISSIONE EFFICIENZA
L’approccio dell’informatica agile, del prototipo incrementale,
permette a DocFlow di dare vigore al messaggio e all’azione di
vendita: il cliente paga l’incremento di efficienza, il resto (effi-
cacia, qualità, conformità) viene data a titolo gratuito. Come,
anche la qualità? “Certo, perché no? Dieci anni fa si vendeva
argomentando sulla qualità, si andava dai clienti e si diceva
loro ‘ti do l’innovazione, la produttività, il time to market’. Poi
dicembre 2007
è arrivata la crisi, e un profondo ripensamento nei confronti dei
soldi che si spendevano per l’informatica, e con la sola qualità
non si vende più nulla. La qualità ormai si può solo regalare”.
La missione di DocFlow è di portare efficienza; il resto è all’in-
terno di questo concetto. Detto questo, Petti ha in serbo un
altro argomento, molto attuale e dibattuto: la compliance, o
conformità, che dir si voglia.
LA COMPLIANCE
Compliance, questa incompiuta, verrebbe da dire. Già, per-
ché, se ne parla tanto (anche troppo) ma a quanto pare si fa
poco, molto poco. In America, ricorda Petti, la Sarbanes Oxley
l’han fatta talmente complicata, che le società che hanno cer-
cato di implementarla hanno dopo un po’ alzato le mani in uno
sconfortante “help, ci arrendiamo”. A detta di Petti, il problema
si risolve per conto suo quando si ha il controllo totale delle
informazioni (tutte, email comprese). “La grande differenza tra
il nostro mondo e quello dell’Erp, sta nel fatto che a me non in-
teressa solo un determinato dato così com’è adesso, ma vo-
glio sapere anche chi, come e quando l’ha prodotto e tutti gli
stadi che ha percorso”. La cosa, dunque, è ben più com-
plessa, visto che l’esigenza è quella di conoscere e tracciare
il processo che ha portato a una determinata elaborazione.
Detto in soldoni, se si riesce a impostare i processi collabora-
tivi e misti con un sistema di business process management,
in qualche modo “cablati”, ecco che la compliance viene da
sé, è completamente gratuita. La ragione è molto semplice:
se un processo è ben definito e documentato e la sua esecu-
zione è controllata passo passo da una applicazione che ne
traccia il percorso e trasporta l’evidenza documentale, ecco
che risulta possibile dimostrare a terzi la conformità ad una
definita normativa. “La compliance non deve essere qualcosa
di estraneo alla operativa aziendale, ma i normali processi si
devono svolgere in modo compliant, cosi come per la Qualità
Iso: se si lavora in qualità non si deve far nulla di specifico per
dimostrarlo, la qualità è nei fatti”.
IL SERVIZIO
Nell’ultimo anno, DocFlow ha anche ripensato le problemati-
che relative al servizio. Un tema che fatalmente sposta ancor
di più l’azienda al di là della mera tecnologia. Però, con una vo-
cazione diversa. “È cattiva abitudine di chi si occupa di progetti
informatici, una volta superato positivamente il collaudo finale,
sciogliere la squadra e abbandonare il cliente a se stesso. Pa-
radossalmente, vengono a mancare proprio nel momento in
cui il sistema del cliente una volta entrato in produzione deve
dare i vantaggi prospettati”. Partendo da questa considera-
dicembre 2007
L’Azienda
DocFlow è una “piccola grande azienda”, o, a
seconda dei punti di vista, una “grande piccola
azienda”: piccola per il numero di persone che
la compongono (una cinquantina), grande per-
ché ha clienti importanti e opera con modelli or-
ganizzativi tipici di una multinazionale.
L’azienda nasce nel 1995 per operare nel mercato
della gestione documentale e da subito si specia-
lizza nel settore dei documenti digitali e dell’auto-
mazione dei processi. Specializzazione ed
esperienza sono due parole chiave per DocFlow,
che si pone a metà strada tra l’azienda di consulenza, e
quella che si occupa di sviluppo software. L’approccio al
mercato è duplice: da una parte creare soluzioni ah hoc
basate su prodotti semilavorati che poi vengono persona-
lizzati in base alle esigenze del cliente, dall’altra offrire so-
luzioni standardizzate già collaudate in ambienti di
produzione presso grandi aziende.
zione, Docflow ha esteso la durata del suo intervento proget-
tuale. “Abbiamo creato Effective Care, una metodologia che
la nostra nuova Divisione Servizi applica per l’intero ciclo di
vita della soluzione creata in fase di progetto. In pratica, siamo
garanti nelle fasi pre, durante e post, dell’effettivo utilizzo del
progetto, coerentemente con gli obiettivi di efficienza e di com-
pliance alla base del progetto e condivisi dai progettisti di Doc-
Flow e da quelli del cliente”. Una vera e propria partnership,
come si vede, che esula dal mero rapporto fornitore-cliente.
DocFlow sta sperimentando il servizio Effective Care su alcune
aziende clienti “pilota”. “Un nostro esperto va a trovarle perio-
dicamente, verifica che utilizzino il sistema rispettando le logi-
che sottese al progetto. Nel caso si riscontrino problemi o non
conformità, vengono effettuati degli interventi correttivi, tipica-
mente evolutivi. È evidente che tutto questo deve configurarsi
all’interno di contratti che rifuggono dalla rigidità dei contratti
tradizionali”.
Le opinioni riportate sono riferibili esclusivamente alla persona o orga-
nizzazione che le ha espresse; esse, inoltre, non impegnano e non sono
fatte proprie né da Executive.it né da Gartner Italia, che non esprimono
in questa sede giudizi sui prodotti o servizi oggetto di tali informazioni,
tantomeno assumono responsabilità o garantiscono in alcun modo la
veridicità delle stesse.
41