Send in the poka-yokes

While dabbling around with some Six Sigma papers this afternoon, I stumbled upon a funny term: poka-yoke. You can read about it here. A poka-yoke device is any mechanism that either prevents a mistake from being made or makes the mistake obvious at a glance, such as an USB connector which can be plugged one way only. It’s an error control mechanism oriented to avoid human mistakes when operating it.

There are plenty examples of poka-yoke devices and how to implement them on manufacturing chains and industrial processes, but I wonder: could they be useful on IT processes and procedures and how could they be implemented?

It’s important as many incidents raise in an organization due to human error; frequently, some RCA on those incidents conclude that an operator hit the wrong key or inserted the wrong tape on a drive… So, as to me poka-yokes look like a sound error-control mechanism, I’m looking for ideas on how to implement them on our IT Operation.

Problem Management: your customers deserve a (reasonable) explanation

I read on  The Opposite of Luck blog a post about a forensic report explaining the cause of an incident that caused an outage at Fisher’s Plaza Technology Complex in Seattle and took down many websites hosted there.

Like them, I applause how transparently Fisher’s Plaza have dealt with this incident, specially regarding their tenants, as they really deserve an explanation.

You can read the full report here.

Your users also deserve an explanation when an IT service goes down; you don’t have to give them a 12 page report for every problem you manage, but you can’t simply shrug your shoulders and tell them “shit happens”.

Spanish trends on quality management: downgrading quality

Sometimes the best work meeting is the one that never took place

I’m back from one of the most surreal work meetings I’ve ever attended, with my boss and a fellow worker, to plan the moving of three branches to a single building. I had my list of topics to be covered at the meeting, including which changes we would have to do at our servers and network configurations (and the changes we would have to raise to our external providers) in order to get everything up and running by the end of the 4-days time frame we’ve been allocated to complete the moving, that is: for all applications and services to be running at normal levels for all users.

But my boss has told me to put it aside and we wouldn’t talk about it at the meeting, because he prefers to deal with other issues of the process of moving (such as connecting users’ computers and relocating an incredibly vintage -but resilient- AS400 server). About those other things on my list… he wouldn’t worry a bit; once the users begin their work at the new building, they would report us what’s wrong and what they miss and what app is crashing or won’t print or won’t connect to the database server, and then we’d get fixing and changing all those configurations we could have made in advance.

That’s a deathly strike for anyone aiming to reach high quality levels at his work, as he’s asked to put aside his will of continuous improvement and work on downgrading the quality level of the IT services instead.

Sadly, I must admit this is not the first time I’m faced with such an awful attitude at other jobs I’ve had, and I wonder if this need to turn down quality for no reason, this need of continuously claim the need to change “something” to improve but, when the chance to effectively do something to improve comes, do nothing, is just an Spanish syndrome or it’s pandemic.