11.03.2020 Views

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!