August 9, 2013
Dear Everyone:
Just when I thought there would be nothing silly to write about this
week, along comes our “Training” Team Leader with the latest update on
the Document Management Upgrade, also known as the “Simplification” of
the Document Management System.
I first started training people to use this system about ten years ago.
At that time, the “business model” was something like this:
There would be the “Basic System”, which everyone would use.
Training was based on what a “typical” user could do in the
system. Some operating
companies and/or departments wanted “additional” functionality, not
unlike the “options” you might choose when buying a new car, or ordering
a house to be built in a development.
“Change the carpet color on the stairs and move the kitchen over
here.”
This was fine as long as they paid for the programming and
configurations required. If
their “improvement” was actually useful, it might then be offered as
part of the “basic” package once it had been paid for by the group that
first requested it. In the
meantime, all these divisions and departments developed their own
training customized to meet their actual situations.
The problems arose when one department wanted “A” and another department
wanted “B” and “A” and “B” were diametrically opposed to each other.
Layers of programming were built on top of each other until the
whole mess threatened to collapse.
Back to Square One.
The “new and improved” system was, again, the “basic” setup, only this
time it was called the “Federated Build”.
And again, individual departments and divisions began demanding
changes to meet their specialized areas.
And, again, the system became increasingly cumbersome to maintain
with all the specializations going on.
Then the company that manufactures the system announced a major
“upgrade”. And management
decided that this was the perfect time to “Simplify” the system.
There would be a basic system that everyone would use.
And so on.
Back to Square One. Again.
Only this time, each “Business Unit” gets to decide which parts of the
system they want to use and how.
Instead of five
Lifecycle States, there will be only three,
unless you pick a different Document Type, in which case your role in
the “Business Unit” will determine if you can, or cannot, perform any or
all functions with your document.
Yesterday, the team leader sent us no less than five distinct
lists of “Business Units”, each with a complex matrix of user roles,
document types, lifecycle states, etc. each of which will required
specialized training, since there is now no such thing as a “typical”
user. One even boasts over
80 different kinds of user
profiles. What happens when
they have more profiles than users?
In other words: The first
casualty of “Simplification” is…simplicity.
Why are they now called “Business Unit” instead of division or
department? Because it’s
faster and easier to say, “Bee-You” than to say,
“Dee-vi-shun-or-dee-part-ment”.
In the meantime, the programmers are frantically finishing “Build 4”,
following “Build 3” and in preparation for “Build 5”.
What does that mean?
“Builds” are “milestones” chosen, seemingly at random, by management to
create the illusion of accomplishment.
Each “Build” appears to replace the previous one, so all the work
done to meet the needs of Build 3 now have to be replaced for Build 4
and… are we “simple” enough yet?
“Cleaning the house while the kids are still growing is like shoveling the walk before it stops snowing.” – Phyllis Diller
In other words, Situation Normal.
Love, as always
Pete
| Previous | Next |