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?