HP3000-L Archives

October 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Thu, 26 Oct 2000 16:54:02 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
X-no-Archive:yes
I'm no SAP expert. But as I understand it, SAP and other systems attempt to
institute some perceived "best practices". These are at worst likely to be
on average better than what many companies come up with on their own,
especially where functionality can be determined by committee or by the
imagination of the IT staff, close acquaintances of VPs or IT staff, or some
"squeaky wheel" approach. The aberrations are the Henry Fords of our world,
who just see a better way to do things than anyone else has come up with
before. And the assembly line in this analogy is but one part of the
operation.

And yet, SAP implementations can and do fail, probably for one of a few
obvious reasons. InformationWeek has had some good articles on failed
efforts. Previous posts have already said well what some of those failings
are, such as not planning first before implementing (when all else fails,
look in the trash for the instructions), or simply not using the software as
provided, or not training users to do so. It is one of the perversities of
the business world that companies will refuse to invest in things that would
have an obvious and immediate benefit, whether its training its own people
(they might leave and take that learning with them) or upgrading an existing
system (at a fraction of what it would cost to replace it).

In a previous life, I worked on a material handling system (which I had done
before and have done since). One of the Distribution Center (DC) supervisors
commented that he used to manage his DC, and now he managed the system.
Exactly. He used to manage inventory by walking around, for example. He saw
what overstocks and understocks caught his eye (and missed others), and
those he could remember, he would address. Now, he had a screen to give him
* all * such information, and he could address all of them. This assumed
accurate inventory data, which was another aspect of the system that was
used properly, and so it did its job within audit requirements (not to brag
too much, though, as there was this one metrics subsystem that was
demonstrably so inaccurate as to be worthless...). And in spite of the
apparent benefit, he was not entirely happy with this state of affairs.

There are groups of various stripes, that attempt to discuss and agree upon
best practices. These can and do have value. In the above context, The
Educational Society for Resource Management at www.apics.org comes to mind.
In many cases, some alignment with best practices can and will help. It
would be a good thing if people would voluntarily accept change in order to
improve, but people hate change (have you read Peopleware?). So, depending
on whether it is the workers or the management that resist change for the
better, anything that can make that alignment less voluntary can at least
accomplish those necessary changes. That can come in the form of
participation in one of these groups to help enforce better practices, so
management can feel like they are leading the charge, or by investing in a
system that gives the no one any choice but to use the system as is, or
obviously fail. And yet, some chose failure.

I spent fifteen months at a company that filed chapter eleven bankruptcy
after I joined (the two were unrelated for those who are wondering), then
chapter seven, by which time I had left. Recommendations for improvement
were vigorously argued against as not necessary. A report I devised which
delineated inventory errors uncovered during the annual physical inventory
was totally and completely ignored. I believed that they had nothing to lose
by trying, that wasn't already at risk from not trying.

Greg Stigers
http://www.cgiusa.com
In some cases,
failure is not an option.
It comes already built-in.

ATOM RSS1 RSS2