I produttori di Erp avrebbero l’interesse a tenere traccia, e codice, di progetti sviluppati ad hoc per i propri clienti. La prassi, tuttavia, non è di uso comune. Nell’analizzare il perchè, tracciamo i vantaggi e le difficoltà che si incontrano nella storicizzazione delle customizzazioni
Il sistema informativo assume sempre più il ruolo di centro nevralgico aziendale, in grado di condizionare il funzionamento di
ogni attività. Proprio nell’ottica di accrescerne la flessibilità, molte
società si orientano verso l’acquisto di un Erp, seguendo alcuni
comportamenti fondamentali. Per effettuare la scelta corretta di un
gestionale, è necessaria un’opportuna valutazione dell’architettura hardware
e software e dei pacchetti reperibili sul mercato, definendo le specifiche
funzionali delle verticalizzazioni in base alle esigenze. Non bisogna
dimenticare la progettazione e il dimensionamento di reti e applicazioni
Internet e intranet, nonché eventuali aperture all’e-commerce.
Lo
sviluppo di funzionalità ad hoc è un aspetto, spesso poco considerato se non
addirittura trascurato dalle imprese. Questo, tuttavia, può costituire una
delle maggiori voci di costo. Una volta effettuata la scelta del package, le
fasi più delicate all’interno di un progetto di installazione di un Erp
riguardano lo studio dei requisiti e della
configurazione delle procedure, l’addestramento del personale e l’avviamento operativo, l’analisi critica
dell’impatto tra organizzazione, pacchetto applicativo e risorse umane, la
verifica della completezza e correttezza della
documentazione, nonché l’affiancamento operativo a “knowledge worker” durante
l’avviamento e nei momenti più critici.
Opportunità
o costo?
La domanda sorge spontanea: per le aziende distributrici e
sviluppatrici di software, la personalizzazione richiesta da un’azienda
costituisce un problema da affrontare e risolvere (per via della cronica
mancanza di risorse preparate come analisti, sviluppatori, capi progetto ed
esperti di reti) o, piuttosto, una concreta opportunità di business? In
effetti, ogni giornata lavorativa trascorsa presso un cliente è ben
remunerata e spesso “dispiace” limitarsi alla semplice installazione di un
package standard senza fornire servizi aggiuntivi, considerando anche il
fatto che il “di più” è spesso richiesto con insistenza dagli utenti
stessi. Questi ultimi, infatti, desiderano che il nuovo software si
discosti il meno possibile dalle vecchie procedure cui si è abituati, e
vengono richieste applicazioni e schermate il più possibile simili alle
precedenti. Da qui la pressione, più o meno esplicita, esercitata sul
vendor. Ma le particolari richieste di un cliente danno realmente corpo a
personalizzazioni uniche? Rappresentano, cioè, esigenze non replicabili o
possono essere, in qualche modo, riutilizzate per altri clienti?
A parte
i casi, abbastanza rari, in cui le customizzazioni richieste sono
effettivamente troppo legate a specifiche realtà, spesso capita che una
stessa applicazione, magari opportunamente parametrata, possa essere riproposta
anche ad altre aziende, provvedendo a limitate variazioni. Si tenga conto
del fatto che anche la domanda di nuovo software, per consentire un più semplice
e immediato utilizzo del pacchetto, rientra nella categoria delle
personalizzazioni.
Detto questo, cerchiamo di ipotizzare una corretta
strategia di “customization management”, evidenziando problemi e opportunità
che si possono porre lungo la strada. Alcuni dei concetti che seguono
possono sembrare banalità, ma molto spesso le argomentazioni più ovvie
risultano anche le meno considerate. I vantaggi, a cui abbiamo già
accennato, quelli che una software house ottiene storicizzando le
personalizzazioni sviluppate presso i vari clienti sono, sostanzialmente,
molteplici, primo fra tutti il fatto di possedere un software già sviluppato,
testato e pronto per l’uso (paradigma diffuso tramite i linguaggi object
oriented). Ovviamente il tutto deve essere adeguatamente documentato per
consentire a chiunque di capirne il funzionamento e la logica applicativa. Va da
sè che, sulla falsariga di quanto accade, ad esempio nel campo dell’automobile,
la capacità di proporre, durante una trattativa di vendita, sia il pacchetto
standard sia, in aggiunta, optional già a catalogo (ovviamente a pagamento)
rappresenta un plus. Verso il cliente, poi, il vendor può far leva su un
comportamento propositivo, che esprime una necessità, proponendo una soluzione
“on the shelf”, già pronta, anche se lievemente differente da quanto richiesto.
Il risparmio, infine, è legato alla possibilità di liberare risorse di sviluppo
che, in tale modo, possono essere destinate ad altri
progetti.
Tra il dire e il
fare…
I motivi per cui, in realtà, ben pochi produttori attuano le
predette azioni di storicizzazione e riutilizzo delle personalizzazioni
possono essere ascritti a quattro filoni.
Il primo riguarda la mancanza
di documentazione specifica, fatto troppo spesso trascurato durante lo
sviluppo delle customizzazioni.
Molto raramente le nuove funzioni
implementate per uno specifico cliente sono registrate e, spesso, nemmeno
sono inserite in un database aziendale, a disposizione dei potenziali attori
coinvolti internamente, tra cui commerciali, analisti, capi progetto. La
motivazione espressa in generale riguardo tale carenza si lega alla
“mancanza di tempo” da dedicare alla stesura, essendo le risorse
aziendali perennemente impegnate per “urgenze” più o meno reali.
Queste
argomentazioni non reggono: per fare un paragone, sarebbe come se, in fase di
interramento di tubazioni, cavi e quant’altro, nessuno si preoccupasse di
documentare opportunamente le coordinate delle localizzazioni in cui sono stati
effettuati gli interventi. Immaginiamo il caos il giorno in cui si dovesse
presentare la necessità di aprire nuovamente il medesimo tratto di strada.
Si
riscontra, poi, l’assenza di un responsabile delle personalizzazioni sviluppate.
In genere le organizzazioni gestiscono i “progetti” in modo isolato, senza alcun
coordinamento tra di essi. Questo accade tanto nelle grandi imprese, quanto in
quelle medio-piccole, ed è proprio su queste ultime che si riverbera l’effetto
peggiore, in quanto si sa che i mezzi economici e di appeal per reperire esperti
e sviluppatori sono principalmente in mano alle aziende di dimensione
enterprise.
Il terzo motivo è di carattere commerciale e concerne lo scarso
(o nullo) interesse del management del vendor nei riguardi di queste particolari procedure. Anzi, correntemente, si tende a considerare che
riscrivere “n” volte lo stesso codice presso “n” clienti diversi si traduca
in un concreto guadagno economico, dato il maggior numero di giornate
addebitabili.
Infine, va fatto cenno alla difficoltà nel riutilizzo delle
nuove applicazioni. Per quanto i linguaggi evoluti siano ormai diffusi,
impiegare la medesima applicazione per soddisfare esigenze aziendali che
differiscono tra loro non è così semplice. Se si ha intenzione di rendere il
software più flessibile, è necessaria una fase d’analisi maggiormente
approfondita, con conseguenti costi iniziali superiori.
… c’è di mezzo il tempo
Senza dubbio, a
breve termine, una politica di corto respiro risulta essere vantaggiosa, ma
nel medio-lungo emergono varie considerazioni che capovolgono l’impressione
iniziale. Si va dalla già accennata carenza di skill di sviluppo, con i
conseguenti ritardi di consegna, all’alta probabilità di inserire ogni volta
nuove toppe ai bug di programma, unitamente all’aumento, anziché alla
diminuzione, dei tempi necessari allo sviluppo. Ciò, oltre a ripercuotersi
sui costi, può rischiare di incrinare i rapporti vendor-cliente: in molti
casi quest’ultimo richiederà drastici sconti sulle customizzazioni
apportate, quando addirittura non opporrà un netto rifiuto al pagamento
di un prodotto consegnato in ritardo o con problemi di funzionamento.
Un’altra ragione per cui le imprese troppo spesso trascurano la duplicazione
delle personalizzazioni è data dalla crescita che il mercato dei gestionali
ha vissuto in questi ultimi anni. Di fronte a fatturati e utili in costante
aumento si tende, inevitabilmente, a trascurare le disfunzioni interne. Per
“tradizione”, per quieto vivere, per mancana di obiettivi chiari, salvo, poi,
pentirsi in un secondo momento quando il vento cambia e subentra un periodo di
crescita aziendale inferiore al passato o addirittura un calo. Come sempre,
prevenire è meglio che curare.
