When a user raises a request, there are several paths that request ought to
follow:
* How urgently does the user need this implemented?
* Some ERP software is entangled with some industry standards, such as
supply chain contracts, gov regulations, auditor requirements. Is the
proposed upgrade consistent with these standards? Each company, subject to
standards, needs a compliance officer, aware of both internal and external
standards requirements, to review each requested change, and put stamp of
approval on, or declare a violation involved.
* Do all co-workers also want this, or will we need to have 2
versions, with and without this change?
* Does manager of user dept, approve the upgrade request, and how
urgent does that person perceive it to be?
* IT investigation, estimate how much hassle to implement.
* Manager evaluation of that estimated cost vs. perceived urgent need
. does need justify the expense?
* The longer implementation takes, the more likely the user community
will add additional enhancement requests to the original one. IT might have
a standard . if addition to work load is trivial, just accept it, but if
addition is above some threshold, then run it thru the approval process . do
we add a few weeks to the implementation schedule, or do we put this
addition into a future variant?
* Implementation includes testing.
If you are exclusively on legacy, some hassles of contemporary maintenance
are avoided.
Taxing authorities typically make upgrade demands, at best, a few months
before deadline to be correctly implemented on W-2's and other forms. The
ERP vendors typically take almost a year to implement such upgrades. Thus,
there is the need for in-house modification rush job, followed later by
dealing with the vendor repair to vanilla version vs. other modifications we
might have. PDM-54 saved a lot of research effort.
Not all users of any given program, will want the same alleged enhancements.
This can lead to menu of versions, and naming challenges, where some people
insist on still using a several years old version, where there have been a
lot of new versions added since.
Then we come to mixing and matching features, where different people want
different mixtures.
Sometimes their bosses will not want particular persons to have access to
semi-confidential data, such as costs, profits, types of activity by
geographic location, QC and other investigation results. For some reports,
I had a table of end user-names, where the person, running the report, got
some data added or blocked, based on upper management restrictions and
approvals. Then they wanted some of these reports automatically scheduled,
so I added CL variants.
The info to be added or blocked, by user, was not for just one program, but
affected many.
Programming standard important here: user name on top of every page; clarity
of date of as-of contents, especially on frequently run reports. I had a
subroutine to extract day of week (e.g. TUESDAY spelled out) to include on
top of some reports, emphasizing report vintage.
There are, what some observers might call "standard reports" but they are
shared by many people in many departments, and the auditors, all of whom
want different degrees of detail, and often what one person wants is in
conflict with what another wants, such as a version with sub-totals by
location, product class, date range etc. while another wants the data in
simple columns for hassle-free import to Excel. I have resolved that, on a
heavily used "standard" report by the program generating TWO "print" spool
file formats, one optimized for green bar paper, the other optimized for
Excel delivery, same data, just formatted differently. End User can select
either or both.
To satisfy different needs of different people regarding the "same" report,
I'd come up with a Sales version, Production version, Accounting version,
Auditor version. Then within individual depts, some managers wanted
additional sub-versions to satisfy the productivity needs by individual
employee tasks.
I got permission to use customer types in support of reports based on our
teams. Different employee clusters, one each in customer service, QC,
engineering, production leadership, etc. handled particular customers needs.
I setup customer type codes for each, then each customer was flagged with
what team involved. Then reports listing customer activity, could be
restricted to include only those for the customer team, of the user who
selected team" version of report. There was also a complete list version.
A prompt screen may sound logical, to select which team variant a person
wants to run, but management wanted reports with latest data sitting on
printer when morning crew arrived, so I put them in overnight scheduler.
Then new scenarios arrived, competing for use of the type code, so I went to
a letters & #s string. Program prompt/CL feeds in a character. E.g. "W"
means to only list those customers managed by outside sales team run by
Wayne (I had been refused access to sales person #, which some managers
planned to use in the future for some function not yet disclosed to me). As
the program gets to each next customer, the customer type string is searched
to see if this is another "W" included, to decide whether or not to include
that customer in the report.
Another type consideration was with different details required for different
customers. So characters in the customer type 4 character string got
assigned to "this customer wants _____" some greater degree of data spelled
out, which does not apply to other customers.
Once upon a time we had a senior manager who complained that there were 40
different versions of a particular "standard" report in use (an
exaggeration) & he wanted all our employees marching to the same band music,
and he persuaded all other managers to agree with this. He got what he
wanted, but it hurt clerical productivity noticeably, so after he left, the
company moved back to the kind of reality we had before his arrival.
One hassle of reality outside his tenure was ME TOO. Someone would request
a specific upgrade to THEIR version of the customer demand report, then
after implementation, other users would see that, and want it added to their
versions also. So I found programming methods, which made it easy to
transplant enhancements across versions.
During his tenure, one of the managers comes to me claiming:
* This upgrade is needed.
* It is urgently needed.
* Everyone wants it, including high level leadership.
So I implement it. Day of successful completion, I get a parade of other
users and managers, who do not like the upgrade. The manager who wanted it,
had allegedly lied about the total approval. This is not unusual.
Sometimes when I get a request, where someone says the CEO needs this
upgrade yesterday, I need to go to the CEO for clarification, and the CEO
has no idea what I am talking about. On occasion I have requested that
requests be in writing with someone signing off approval, and been told not
to waste everyone's time. You know what they want, go implement it.
Fortunately, at that time we were operating to a standard that all upgrades
be conducted in such a manner that if later they were decided to be not
wanted after all, we could easily go back to an earlier version.
There were also time periods where we operated without this, because new
managers demanded upgrades be implemented as rapidly as possible, without
the safe-guards of back out capability, or serious testing.
Alister Wm Macintyre (Al Mac)
Panama Papers group:
https://www.linkedin.com/groups/8508998
midrange.com
