Progetto di ricerca - Gruppo 7

Camilla Veneri, Maddalena Schelfi, Tommaso Mosna

Domanda di ricerca:

Il nostro progetto di ricerca si focalizza su alcune

questioni legate al ruolo del consulente e ai processi che
hanno luogo dal momento della richiesta di consulenza
sino alla risoluzione del problema.
Che processi si attivano in seguito alla richiesta di
consulenza da parte di un’azienda del gruppo? Come
avviene formalmente questa richiesta e che rapporti si
instaurano con l’azienda richiedente? Come si sviluppa un
progetto di supporto?
• «…and of course the last one, where I’m working, Fresenius
Netcare, and we are focused on information technology. We
have 3 hundred Fresenius Netcare employees and our field
of business is IT consulting, SAP consulting, administration
of hardware architectures, operation of infrastructures and
meaning actually we are consulting providing all the
technical issues to the Fresenius group like internet,
intranet, communication, hardware, software and
everything.»
 Piattaforma epistemologica
• Nell’intraprendere il percorso del progetto di ricerca di cui
ci stiamo occupando, abbiamo deciso di utilizzare come
piattaforma epistemologica l’ articolo di Paolo Depaoli –
La ricerca nel campo dei sistemi informativi e la filosofia:
il caso di Claudio Ciborra e Martin Heidegger – del 2007.
• Tutto l’ articolo si fonda su uno dei capisaldi della teoria
di Heidegger, che proviene dalla ratio latina: come il
calcolare abbia superato il pensiero.
Alla base del paradigma scientifico delle
scienze naturali c’ è infatti la concezione
per cui esiste un mondo e una realtà
oggettiva regolata da leggi naturali.
Ciborra non critica questo paradigma in
sé bensì la sua applicazione nel campo
degli IT: la sua alternativa
fenomenologica consiste nel passare
dalla “costruzione di uniformità del
conforme” (Depaoli 2007) al tener conto
della “varietà nel difforme”.
 Il problema, che per Ciborra è avvenuto nella
gestione delle organizzazioni e delle tecnologie,
risiede nel non aver considerato l’ ordine
soggettivo, il ruolo della vita quotidiana,
ignorando quindi il carattere ibrido e socio tecnico
dei sistemi informativi.
 Tutto questo dibattito si era strutturato già nel
dibattito di fine ottocento nell’ ambito della filosofia
della scienza, che si concluse con la distinzione
tra scienze umane e naturali.
 Il cuore del metodo della descrizione
fenomenologica consiste per Heidegger
nell’interpretazione: nello studio dei fenomeni non
fermarsi all’ apparenza ma entrare nel profondo
cercando di interpretare.
Benché gli uomini non siano
completamente liberi, essi sono capaci di
pensare e sono capaci di ascoltare la
chiamata di ciò che è nascosto. In questo
senso la tecnologia moderna deve essere
considerata una destinazione piuttosto
che un destino.
 Dunque, gli uomini secondo Heidegger
dovrebbero praticare il pensiero, cioè fare
attenzione a ciò che è velato, ciò che è
nascosto e all’evoluzione della tecnologia.
 Letteratura
a)Neil Pollock, Robin Williams, Software and Organizations:
The Biography of the Enterprise-Wide System Or How
SAP Conquered the World, 2008

Le questioni legate allo sviluppo e all’adozione dei pacchetti

ERP: dal design alla post-implementazione:

Il design: com’è possibile che i produttori di questi pacchetti di

software riescano ad offrire soluzioni che apparentemente
incontrano I bisogni degli utilizzatori, nonostante l’enorme
diversità che si riscontra da organizzazione a organizzazione e
da settore a settore?
La selezione: tali tecnologie sono difficili da stimare poiché,
innanzi tutto, sono necessarie competenze specifiche non
sempre presenti nell'organizzazione e, in secondo luogo,
perché non si può sapere come il software verrà usato fino a
quando non verrà effettivamente usato. Il rivolgersi a
consulenti esterni, inoltre, complica il campo e le relazioni
sociali che andranno a costituire la scelta. Il processo
negoziale attraverso cui si identifica il pacchetto ERP più
adatto alla propria azienda è quindi difficile e complesso.
Implementazione e personalizzazione del sistema: l’azienda
utilizzatrice si trova di fronte a un dilemma, a proposito di
quanto e come adattare alle proprie esigenze il pacchetto
acquistato. Una personalizzazione eccessiva infatti potrebbe
pregiudicare la possibilità di aggiornamenti e miglioramenti nel
futuro e il sistema ERP perderebbe i vantaggi della
standardizzazione, cioè la convenienza a livello economico, la
robustezza e soprattutto il supporto da parte dell’azienda
fornitrice. Esistono comunque diverse forme di
implementazione dei pacchetti ERP:
• configuring the package
• customising the package
• partial, selective implementation of package
• add-ons, bolt-ons or ‘extension software’:
• ‘best of breed’ – multi-vendor systems
• «It’s a good question, customizing is very… for example if
you… I don’t know, you have to customize your system, you
can open different plants for example. We have plenty of
plants around the world and every plant has its own number.
For example plant in China is 3130 and other companies
have other plants they call it perhaps PPFU or something…
This is customizing and you can… some plants use
production orders and some plants use process orders: this
is customizing. Or different times owns in calendars, so
customizing means actually to adapt the standard system to
your own needs but without doing own development.»
Post-implementazione: i sistemi ERP sono investimenti
che richiedono un lungo periodo di sperimentazione,
necessario per integrare il software con le pratiche
organizzative. È necessario, attraverso il supporto o la
consulenza di esperti esterni o interni all’organizzazione,
adattare il prodotto al contesto organizzativo, contesto che
molto spesso è in continuo cambiamento.
• «Fresenius has in-house consultants, within Fresenius
Netcare of course, […]. Fresenius grow within the last five
years very big and the in-house consultants know all the
specialities, for example in production, logistic and self
processes. It is very important to keep this knowledge
inside Fresenius. Of course we also have external
consultants […] but in every projects we also have in-house
consultants, then all the knowledge is kept inside
Fresenius. We don’t want to get dependent from external
companies because if only external consultants do our
work, they go away and nobody knows exactly how the
processes have been made, how different programming in
the system has been made and all this staff and so it’s very
crucial to keep the knowledge within Fresenius
employees.»
 b)Bjerknes et alii, Evolution of Finished Computer System.
The Dilemma of Enhancement, 1991

Il contesto in cui ci si trova a lavorare è un contesto

instabile. Il sistema ERP adottato deve seguire questi
cambiamenti ed evolvere con essi.
L’enfasi sull’evoluzione dei sistemi informatici propone un
punto di vista sui sistemi informatici orientato al processo e al
sistema di sviluppo e miglioramento: successivamente al
momento dell’implementazione una versione del sistema
viene sviluppata e usata, e le attività di miglioramento, come
La correzione degli errori, vengono effettuate durante la fase
di utilizzo stessa.
«In most of the cases our customers have new
requirements in processes or they have new ideas, new
wishes, what they want to do within the SAP system.
Sometimes it’s also that we are realizing that our
customers can do something better in the SAP system
as they do it now, perhaps manually.»

Le attività di miglioramento più ampie, invece, sono

posticipate al ciclo successivo, nel quale viene sviluppata
una nuova versione del sistema. La fase di sviluppo è
seguita dalla fase di miglioramento, mentre la fase di
utilizzo e la fase di miglioramento avvengono
contemporaneamente.
c) Pollock, Williams, Grimm e D'Adderio, Forme di riparazione
post locali: il caso del Supporto tecnico virtualizzato.

Il progetto di spostare on-line il supporto tecnico di complesse

tecnologie organizzative sembra in apparenza non plausibile;
stando ai classici della micro-analisi sociologica i problemi
tecnici sono radicati in un contesto sociale e quindi non
possono venir risolti senza una sufficiente comprensione di
tale contesto. La diagnosi e la risoluzione dei guasti tecnici è
una questione intrinsecamente locale.

Oggi,in particolare nel settore del software organizzativo, molti

problemi vengono però risolti a distanza. Gli autori, al riguardo,
utilizzano due termini: 'districare' e 'esportazione'.
Sulla base di un’etnografia sul campo condotta presso un
grande produttore di software (identificato con lo pseudonimo
di SoftCo), gli autori ci mostrano come il supporto tecnico sia
stato riformulato e inserito in un nuovo regime geografico e
temporale, implicando anche una forte riconfigurazione nei
rapporti tra i vari attori, attraverso l’utilizzo delle tecnologie
dell'informazione e della comunicazione (ICT).

Il supporto si è quindi spostato da un’interazione face-to-face

ad un’interazione principalmente face-to-portal; perciò il
venditore non tratta con utilizzatori fisici, ma con utilizzatori
virtuali.
La Product Support Chain messa in campo dalla SoftCo
prevede una forma organizzativa piuttosto distintiva che
influenza la natura delle risposte del venditore. Una volta che
un problema è stato riportato nel portale, viene ricevuto dal
primo link della catena, ovvero uno dei centri di supporto
primario. Quando un programmatore dei quel livello non
riesce a risolvere il problema, questo viene passato
‘verticalmente’ al livello successivo della catena, un centro di
supporto secondario, dotato di conoscenze più specifiche. Se
il problema resta insoluto, viene infine passato ai
‘Development Support’, strutture super specializzate.
«…there are three level of support tickets. The first level
support – we don’t do the first level support – this is when the
customer calls and says: ok, he can’t log in, there is a problem
with the customer order or with the production order or
something like this. This is all first level. If the first level support
can not solve this problem, he will send the tickets – this is
online – the ticket to us, and we are second level, because we
are more deeply in the processes and know the customizing
and know the programming of the processes. And if we can’t
solve it or, in most of the cases, we find that there is a failure in
the programming then we give it to the third level support. And
third level support are really the informatics guys, the
information-technology guys, the programmers, the...I don’t
wont to call it freaks.»
I problemi, inseriti nel portale, vengono spediti alla ricerca di
competenze, implicando problemi temporali e un dilemma per
l’azienda venditrice: lo staff di supporto o scovava le corrette
competenze, ma al rischio di non essere tempestivi
(chiedendo
all’utilizzatore di aspettare), o manteneva la tempestività e
distribuiva i messaggi senza badare a che quelli che li
ricevevano possedessero le competenze adeguate.
Quest’ultima possibilità portò spesso a una pratica conosciuta
come ‘ping-pong’ (il messaggio salta tra vari settori
dell’organizzazione e a volte viaggia attraverso i continenti per
settimane, finché non si trova l`esperto appropriato).
SoftCo, nel momento in cui si verifica un problema di
affollamento della casella inbox, cerca di spostare la
questione da un piano di discrezione individuale ad un
formale e tecnologico processo decisionale.
Viene quindi introdotto un nuovo pezzo di software nel
portale che permette automaticamente di rendere prioritari
alcuni messaggi e di metterne in stallo altri.
Oltre al setting di priorità dei messaggi, viene introdotta la
possibilità che lo user, se non è soddisfatto di come sono
stati trattati i suoi problemi, possa decidere di ‘scalare’
(‘escalate’) il suo problema. Dopo l`escalation la natura del
problema cambia radicalmente: raggiunge subito la
Massima attenzione e viene istituito un team ‘giudicante’ per
investigare la questione.
Avvento delle forme di supporto cosiddette ‘post -local’:
emerge un nuovo modo di organizzare che si basa su
‘disentanglement’ e ‘exporting’.
Una delle conseguenze di questo è che lo staff di supporto
non è responsabile degli specifici user, cosicché un
problema può saltare tra le varie parti dell`organizzazione
anche per settimane senza che nessuno se ne incarichi.
• «…if we have a problem whit the standard SAP system
we can open the ticket online then they will also tray to
solve it and most of the cases they solve it and it needs
quite long time and after that problem is solved they offer
the solution not only to us but to all customers because
if there is a problem then all the customers have it, not
only we. […] We do a request, this is called SAP Service
Marketplace and actually every SAP consultant or
everybody, who has to do whit the SAP system, has a
user for this and then you can login and open ticket. It’s
call ‘OSS’ (online SAP support ticket).»
«So, we are doing process consulting and we are doing IT
system consulting, and we are doing it pro- actively, like
going to the customer and we also do it like, when the
customers coming to us.
So, if they have new problems or a new idea they call us,
we do workshops together and discuss the problem or
ideas. Only small problems we also discuss it by phone or
just do a small phone call and open a so called ticket»
 Ulteriori domande di approfondimento.
• Le imprese che fanno parte del gruppo hanno dei
servizi/processi in comune? Di quali risorse dispone
Fresenius Netcare per dispiegare la proattività nella
consulenza? Cioè: quanto conoscete i processi delle
diverse aziende del gruppo Fresenius e in che modo li
conoscete e li monitorate?

• Quanti clienti avete? Come vi dividete il portfolio dei

clienti? Come è diviso il lavoro internamente? C’è una
corrispondenza particolare tra i moduli SAP e i fornitori
di supporto?
• Quanto sono standard i processi dei vostri clienti?

• E’ possibile avere una copia, vecchia o vuota, di una

User Requirement Specification e di una Functional
Specification?

• Chi decide quando non è più necessario fare ulteriori

workshop? Chi decide insomma che il problema è stato
analizzato a sufficienza ed è possibile passare alla fase
in cui viene proposta una soluzione?
• In che cosa consiste la Change Request? Come viene
reso operativo il V-Model?

• Come funzionano i tre livelli di supporto? Come

avvengono i passaggi da un livello all’altro? Disponete di
un sistema informativo che raccoglie le richieste? La
strutturazione su tre livelli viene imposta dell’agreement
SAP, o viene adottata come best-practice?