Inside NIRMA Spring 2020 FINAL
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
camps” – the “process” or business people were all<br />
about the latest and greatest computer technology that<br />
would take care of their problems, and the information<br />
technologists would be about getting the “fill-in-theblank<br />
users” to come up with a cogent process<br />
description so they could fit in the technology.<br />
When I would facilitate a process review, there would<br />
be times when I’d scratch my head on a particular series<br />
of steps, and ask “why do you do this?” I’d get back,<br />
“That’s how we’ve always done it.” I would then think,<br />
you know, that’s a bad process; if they implement the<br />
system according to this process, they’re only making a<br />
bad process go faster! On the other hand, the nature-of<br />
-the-beast with technology is that there is an inherent<br />
“management system” in the software, processes that<br />
may not fit a company’s current culture or processes.<br />
So, do you adopt the process to meet the system, or do<br />
you adopt the system to meet the process?<br />
I’ve seen it both ways, with extraordinary hoopjumping<br />
and accompanying cultural angst. On one<br />
hand, so much change was done to a software<br />
application to meet a company’s process that it was<br />
Back then, the buzzword<br />
that got change going<br />
was “total quality<br />
management”; today,<br />
it’s Lean-Six Sigma.<br />
Tomorrow? No doubt<br />
there will be another<br />
methodology to get<br />
excited about, but the<br />
clash will be the same: is<br />
it process improvement<br />
or technology change?<br />
nearly unrecognizable if you saw that system used in<br />
another company. On the other hand, I’ve seen “edicts<br />
from on high” that the software must be used “as-is”,<br />
so the company needs to change its ways of doing<br />
business to meet it. Don’t get me wrong; there are valid<br />
reasons for either way, with justified cost-benefits, it’s<br />
just an interesting dichotomy I’ve observed – or been a<br />
part of!<br />
The best implementations, especially at the fleet-wide<br />
scale, is where a compromise is achieved between<br />
process improvement and technology change. There are<br />
some processes that must stay in place in order to meet<br />
regulatory needs (“if the process is bad, go tell the<br />
guv’mint!”); on the other hand, if a software company<br />
has a track record of effective success, a client should<br />
“listen” as to why the automated process is in place and<br />
strive to implement it.<br />
Back then, the buzzword that got change going was<br />
“total quality management”; today, it’s Lean-Six Sigma.<br />
Tomorrow? No doubt there will be another<br />
methodology to get excited about, but the clash will be<br />
the same: is it process improvement or technology<br />
change?<br />
Eugene has been a member of <strong>NIRMA</strong> for<br />
over 33 years. At the time he joined,<br />
<strong>NIRMA</strong> had only been in existence for 11<br />
years. He would love to hear about stories<br />
and anecdotes from others, so please email<br />
him at:<br />
eugene.yang@kismetconsulting.com.<br />
<strong>Inside</strong> <strong>NIRMA</strong> <strong>NIRMA</strong>.org <strong>Spring</strong> <strong>2020</strong> 11