martedì 19 agosto 2014

Quality/3 - Rules prevent the best performers: true or false?

Rules prevent the best performers from standing out.

In the contest of the Workshop Questionnaire I proposed to my collegues, the meaning of “rules” concerns the provision of  adequate internal standard, policies, guidelines, procedures, working instructions, circulars etc. to establish the structure of an organization.


The topic ties in with the previous Question related to the association between quality and bureaucracy.
The answers to the questionnaire showed the widespread awareness that working processes can be established without affecting creativity and personal competences.
Moreover, the Management System requires periodical measurements to evaluate performances of processes impartially and objectively. 
These methods shall demonstrate the ability of the processes and processors to achieve planned results.
It sounds like a good opportunity for best performers to stand out, doesn't it?

Unfortunately things are not so easy because documentation has to be, first of all, prepared and often has to be shared with other departments. Always has to be submitted for approval and updated anytime there is a change,  etc.
For sure that it’s a real  effort to be considered but in any case a clear documentation, generally speaking, supports attitudes of enterprise and improvement.

martedì 12 agosto 2014

Quality/2 Quality is bureaucracy - true of false?

Quality is bureaucracy: it bridles creativity.

What do you think about above statement?


You can agree the Quality brindles the personal creativity even if  different reasons and shading.
Or, perhaps you think that It's false: this is just an alibi for those who want to avoid rules.
At least you can assert that It depends on how Quality is interpreted and implemented.

As leader of a Quality Project you might expect me to defend all Quality Systems.
On the contrary I agree there must be a valid reason if often the perception of Quality is linked with bureaucracy.
Could be sometimes companies require and obtain the "Quality Certification" only to put the Certification Logo in their web-site and their invoice forms.
Of course, the consequence of this kind of approach can be summarized by saying that, in this case what you really do and what you have documented differ. Therefore, documentation is bureaucracy - just piece of papers.

On the other hand you can find people oriented to the formal application of rules rather than  interested in improving the efficiency and effectiveness of business processes.  

I mean, for instance, the proliferation of complex forms to be filled in without any (or with poor) consideration of resources to be used and the possible benefits. 

Another example of the wrong approach is an internal audit that becomes a wild west gunfight between the Good Guy and the Bad Guy (do you remember the western film High Noon starred by Gary Cooper and Ian MacDonald?).

 
So, my personal answer to the question "Is Quality just bureaucracy?" is...."It depends". 
As I said during my Workshops,  the fruit of the Quality is tasty but it can be difficult to remove the peel to get to the fruit.
For sure, in some way, you can obtain from the Certifying Body  the formal stamp of Certification, but please be careful that you are not ignoring the purposes of the Quality standards.

Indeed the responses I received  to my questionnaire are interesting because  75% of colleagues answered "No" or "it depends" against only 25% who responded that  “quality is bureaucracy”.

The result is quite good because many employees involved were approaching the Quality Management System for the first time (i.e., Accounting, Legal and ICT departments) and further investigation was provided before the training.  

:-)

martedì 5 agosto 2014

Quality /1 - provocative statements

Some months ago, 114 d’Amico Group managers and employees before attending the Quality Awareness Workshop, responded to our “Quality” Questionnaire.

During the 15 sessions, held in Rome, Genoa, Monaco, London and Dublin, involving all the ashore departments, we shared our ideas about the Integrated Management Systems and the Processes Management. 




We also focused on Continuous Improvement through the PDCA  (Plan-Do-Check-Act) methodology.

Really, our Questionnaire was just a pretext for exploring perceptions about Quality, and to establish a starting point for further exploration.
In my upcoming posts, I will discuss some provocative statements:

- Quality is bureaucracy: it bridles creativity.
- Rules prevent the best performers from standing out.
- Our organization is different from the others.
Quality does not fit with our reality.

Follow me next days...

giovedì 10 aprile 2014

A thoughtful challenge

L'anno scorso la d'Amico ha lanciato il progetto Storyboarding che rappresenta un’opportunità di “partecipazione” alla vita aziendale e un modo nuovo per darne forma attraverso la esperienza chi ci lavora.
Tutte le storie ricevute faranno parte di un e-book e vengono pubblicate, una per settimana, tramite intranet.
Questa settimana è il turno della mia.
Propongo qui la versione in inglese  e rimando alla traduzione in italiano sul link "una sfida ragionata"





martedì 1 gennaio 2013

60 anni d'Amico Società Navigazione

Da Aprile lavoro per la d'Amico Società di Navigazione.
Mi è stato affidato un progetto di valutazione e ampliamento del Sistema Gestionale Integrato.
Questo lavoro mi ha dato la possibilità di ritornare in un ambiente di lavoro che già conoscevo per averci lavorato con grande soddisfazione dal 1999 al 2003: un onore e una gradevole opportunità essere ritornato proprio nell'anno in cui l'azienda festeggia i 60 anni di attività.


Nonostante l'espansione e la sua multiculturale presenza internazionale tipici di un'azienda multinazionale, l'azienda ha saputo mantenuto  uno stile "italiano" e mantenere i valori delle relazioni interpersonali.



sabato 18 febbraio 2012

Quando cambiare non è una scelta

Trattando "cambiamenti" questo post è stato pubblicato prima nel mio blog personale a
http://tre-chiavi-inglesi-in-dubbio.blogspot.com/2012/02/quando-cambiare-non-e-una-scelta.html

ma trattandosi di argomenti legati al counseling aziendale, mi sembra opportuno aggiungerlo anche in questa sezione.


Ci sono cambiamenti dovuti ad eventi che uno non si andrebbe mai a cercare. Uno di questi casi è la perdita del posto di lavoro.
Succede; si scatenano delle emozioni; è inevitabile che ci sia un momento di confusione e smarrimento; si può avere l'opportunità di accrescere la propria consapevolezza che, attraverso un'accettazione della nuova situazione, diventa il punto di partenza per cogliere un insight - una illuminazione, per individuare la giusta direzione da prendere.

La prima domanda potrebbe essere: perché e cosa cambiare? La perdita del lavoro non è stata frutto di un mio errore, di difficoltà nel rapporto con l'azienda o di una carenza professionale. Una ristrutturazione... un ridimensionamento, una centralizzazione, la conseguenza di una crisi del mercato...
Tutto vero ma... è successo! Ed è un dato di fatto che, senza lo stimolo derivante da un evento, la spinta al cambiamento è quasi impossibile.
Sì, si potrebbe decidere di non voler cambiare nulla, ma come ho già scritto in qualche post precedente, il mio desiderio non è girare l'interruttore e ripristinare la stessa situazione di prima. Troverei triste non aver saputo approfittare di questo momento per crescere, o almeno provarci.

Per esempio comprendere e valorizzare l'idea che non esiste un io "professionale" con i suoi attributi costituiti dalle esperienze di lavoro, dai ruoli svolti nelle varie aziende, le realizzazioni fatte, i corsi frequentati, le competenze costruite, e un altro io "personale" con i suoi attributi di natura umana, interessi individuali, rigidità o flessibilità, storia personale ecc.
Che le due "io" si compenetrano uno con l'altro dovrebbe essere abbastanza chiaro e accettabile; diverso è tirarne fuori un paradigma utilizzabile nella propria vita.
In questo periodo di cambiamento sono coinvolti i miei interessi, la rete delle mie conoscenze, la cerchia di persone che mi sostengono, gli scambi di comunicazione che avvengono, i valori che decido di mettere in luce.

Ieri ho frequentato un seminario che partendo da queste considerazioni ha gettato dei semi per sapersi muovere in questo percorso e decidere cosa si vuole diventare. 

Mi sembra giusto aggiungere che è stato guidato da Maria Cristina Manicardi di MIR-LA TENDA (nel nome il programma da scoprire).

giovedì 12 gennaio 2012

La struttura per governare i processi

Come ho già detto la definizione di una struttura è legata all'organizzazione già esistente, quindi quello che segue è solo un esempio generico.

I ruoli da definire potrebbero essere:
BPO: Business Process Owner; spesso si tratta di un ruolo strategico, quindi viene affiancato da un
BPC: Business Process Coordinator; se l'azienda è complessa o distribuita geograficamente, probabilmente altre figure di Local Business Process Coordinator (LBPC) dovranno essere introdotte.
Mentre queste primi ruoli sono di provenienza Business, quello che segue è di estrazione IT (per esempio un analista di esperienza).
BIE (BIC): Business IT Expert (Coordinator); anche in questo caso in funzione della complessità aziendale altre figure tipicamente IT sono coinvolte in seconda battuta (responsabili di un prodotto/servizi IT).

Manca ancora un tassello; perché la struttura funzioni veramente bisogna identificare e inserire anche dei Key-User; utenti dei sistemi e applicazioni che per la vicinanza con l'esecuzione day-by-day del processo sono in grado di valutare l'efficacia degli interventi e suggerire e filtrare miglioramenti.

Questa struttura si troverà ad operare con il classico approccio della ruota a ciclo continuo di Deming: Pianifica, Fai, Controlla, Agisci (Plan, Do, Check, Act).
Dovrà inoltre pianificare meeting periodici (non troppi, non troppo pochi) e avrà, tra l'altro il compito annuale di stilare il Portfolio IT.
Naturalmente la struttura si ripeterà N-volte per ogni processo identificato.
L'insieme dei BPO, IT Manager e Board dell'azienda costituiscono insieme il Comitato Esecutivo.

lunedì 9 gennaio 2012

Governare i processi

Per un Manager Informatico analizzare e descrivere un Processo Aziendale è qualcosa di familiare, un po' perché è una necessità che si incontra nell'analisi del software gestionale un po' perché i Sistemi di  Qualità lo richiedono.
Diverso è prendere in esame  il Governo di un Processo.

Governare un processo vuol dire saper individuare e proporre una direzione strategica, e non solo, significa impostare le priorità; approvare i budget, seguire i progetti nello stato di avanzamento, verificare il ritorno degli investimenti e naturalmente saper rendere conto di tutto ciò al Board.

Il governo di un processo non può essere efficace se non è condiviso con l'area IS (Information Services).
Ricordo ancora con incredulità quando un Direttore (preferisco non citare nel dettaglio il caso) mi chiese di "prestargli" delle risorse IT per poter costituire un centro di sviluppo e manutenzione sotto il suo diretto controllo. La sua idea era: io sono l'esperto del processo io mi gestisco le risorse incluse quelle IT. Insomma un'azienda nell'azienda.
Era una posizione inaccettabile, non per una mia difesa di potere, ma perché denotava una visione limitata delle potenzialità informatiche, ignorava completamente la necessità di avere in azienda un'antenna tecnologica, un consulente interno, pronto, perché esperto e dedicato alla funzione, a proporre e sfruttare le novità come opportunità di business; era un'idea che non teneva conto degli altri processi aziendali, delle sinergie possibili, delle sovrapposizione che si sarebbero verificate e, alla lunga, sarebbe stato fonte di extra costi.

Un'altro atteggiamento che contrasta con questa impostazione viene spesso attuata dagli amministratori delegati o dai direttori generali. Nel momento in cui si organizzano meeting di tipo cosiddetti Commerciale, i direttori IT, i direttori delle Risorse Umane, l'Organizzazione in generale, vengono esclusi pensando che farli  partecipare sia una perdita di tempo. 
Non dovrebbe essere così la dove si decide di Governare i Processi.
Ritorno quindi a caldeggiare un lavoro di team fra componenti di Business e IT per il governo dei processi.

Come un Direttore Commercial o un direttore Tecnico deve avere avere una consapevolezza delle opportunità tecnologiche, così anche il Direttore IT deve avere una competenza sul Business nel quale opera.

Non capisco e non approvo quei direttori IT che pretendono di ignorare il Business perché pensano che il loro ambito sono i Server, le reti i Sistemi, i servizi IT. Non bisogna poi stupirsi se con questa impostazione i software strategici subiscono dei ritardi e dei costi imprevisti. 
E' nel manico che mancava la sensibilità per impugnare e utilizzare bene l'attrezzo...






domenica 8 gennaio 2012

chi decide priorità e tempi di sviluppo delle applicazioni software in azienda

La domanda potrebbe essere questa: chi decide la direzione, le priorità e tempi di sviluppo delle applicazioni software in azienda?
Sono convinto che in giro c'è ancora qualche IT Manager che si sente ancora investito da questo ruolo; da svolgere da solo o insieme ad una ristretta cerchia di suoi collaboratori.
Un po' per ragioni storiche; un po' per difesa di poteri interni; un po', purtroppo, per mancanza di visione nella Direzione, ma penso che oramai dovrebbe essere abbastanza chiaro che una corretta gestione per processi, determina uno spostamento di questa responsabilità dall'area IT ai responsabili di processo.

Naturalmente, attenzione a non confondere processo con reparto. La definizione di reparto è strutturale e gerarchica, quella di processo è spesso trasversale e coinvolge differenti uffici interni, clienti e fornitori ed è legata a una sequenza di attività che a partire da un'origine (input) hanno il compito di realizzare uno scopo (output).

Dire che il business process owner (BPO) , cioè il responsabile delle attività di un processo, decide le priorità, detta i tempi, seleziona le funzionalità da far crescere, deve però uscire dalla teoria e diventare una pratica operativa all'interno dell'azienda.
Perché questa affermazione sia reale bisogna fare qualcosa.
E' evidente che le figure dell' IT non possono essere estranee a questo meccanismo,  ma laddove si è vissuto un periodo IT-centrico, bisogna rimodellare il contributo degli informatici all'interno di un nuovo paradigma. Gli analisti e analisti-programmatori senior sono i migliori candidati a recitare il ruolo di Business IT Expert (BIE).

Un'ipotesi di lavoro, che poi va personalizzata all'interno di ogni realtà organizzativa, è quella di dare spazio a una struttura dove BPO e BIE lavorano a stretto contatto.

Definire responsabilità e ruoli non è argomento esauribile in un singolo post.
Per il momento vorrei solo appuntarmi che è necessario che questi due gruppi di persone che, sia ben chiaro, hanno radici, conoscenze e approccio completamente differenti al lavoro, si mettano insieme per creare una sorta di portafoglio IT dinamico.

L'esperienza vissuta in questi ultimi anni mi fa anche aggiungere che comunque ci sono dei rischi da non ignorare; rischi che possono portare, estremizzati, ad una paralisi informatica, o a gravi perdite di produttività; mi ripropongo, nelle prossime settimane di illustrare a grandi linee, struttura, processo, compiti e focalizzare pro e contro.


domenica 28 agosto 2011

Centralizzare o decentralizzare i controlli



Centralizzare comporta un grosso dispendio di risorse economiche e di sforzi organizzativi, soprattutto se si parte da una situazione preesitente dove l'adozione di standard è minima.
Si avvia questo tipo di transizione con la convinzione di raggiungere uno stato finale in cui controllare sarà più semplice e il costo di gestione del sistema ridotto.
Infatti è vero che è' più facile raggiungere un metro uniforme di controlli dove è presente un'unica entità centrale che assume la responsabilità di sicurezza,  di contro però, questa unica entità centrale può trasformarsi in un collo di bottiglia per l'attività aziendale, rallentando o addirittura bloccando le innovazioni.

Infine, a conti fatti, si può scoprire che l'investimento per il cambiamento è stato così alto da rendere impossibile qualsiasi ritorno economico.

Una soluzione decentrata, invece, potrebbe essere più efficiente, mpurchè si presti attenzione affinchè le diverse componenti del controllo mantengano un livello di accuratezza adeguato a garantire la robustezza della policy.
Centralizzare le scelte e le operazioni di definizione senza smantellare la periferia e le sue teste pensanti mi sembrerebbe una strada che garantisce maggiore flessibilità, maggiore capacità innovativa pur con un contenimento di costi.