Re: BPCS Upgrade Test Support Staff Challenges -- BPCS-L

Al -

Yikes!  I agree that the problems you are facing do not have anything to do
with AS/SET and Robot.  However, when I was first hired here at CFI - I was
the one wearing all your hats.   The rest of the staff had only NCR
experience and so part of my job has been to train them as well, in some
cases.  And again I say - if I had to chose I'd quit.   I ran jobs by hand
every night in some cases or used the wrkjobscde  command before we bought
ROBOT.   If you have the time to create your on utilities - you don't need
AS/SET or ROBOT - but if you don't . . .
I have both RPG and AS/SET experience and I can write a complete two-screen
on-line maintenance program with data validation  and on-line help text in
one hour - provided my phone doesn't ring during that time.  This has been
necessary because our Order Entry - A/R system is not part of BPCS but is an
integrated third party package.  And yes - I have had to go back and correct
data issues caused by the conversion programs provided by SSA.
We are running BPCS 6.02 here and have no familiarity with BPCS CD but I
would have to say that yes - BPCS 6.02 has had as many troubles and having
to back out BMR's that were tested has been a common practice here.   Our
enduser community is approximately 125 users and testing software is a new
concept here.  Each division is technically a stand alone company.  AND We
still have two more divisions to bring on-line this year.  Since each of
these divisions had a unique, custom software system on an entirely
different platform prior to BPCS 6.02 - (NCR/ S-36 / RISC 6000) each of them
feels as though the new software doesn't give them all the information that
they need.  I am unclear as to what you mean by C/S support has a higher
MIS overhead than the green screen support?   Do you mean hardware wise or
resource wise?  I would say that enduser training wise it has required more
personnel resources but that is due to needing to train people on PC's and
windows 95 more than on how to use the C/S version of BPCS once they have
basic PC training.
Anyway - I hope that I have answered your questions.

Sincerely
Wendy H. DeCair
Country Fresh Inc.

-----Original Message-----
From: MacWheel99@aol.com <MacWheel99@aol.com>
To: BPCS Users Mailing List <BPCS-L@midrange.com>
Date: Saturday, February 13, 1999 12:47 PM
Subject: BPCS Upgrade Test Support Staff Challenges


>Posting from Al Macintyre
>
>In Subject "ASSET Y2K Dating" there was discussion of V6 issues that were
>somewhat at odds with my company's prior vision of several products so I
>thought it useful to clarify some points
>
>So, in "Subject: Clarify AS/Set?" I had asked about the merits of various
>tools, since we have newly migrated to BPCS 405 CD from BPCS/36, and are
>somewhat reliant on guidance from people who may have another agenda in
>places, so additional opinions might be constructive, and I thank y"all for
>the input
>
>Wendy H DeCair talked about another point I would like to pursue - staffing
>requirements for implementing BPCS upgrades - I am snipping out, from
Wendy's
>input, just what I want to comment further on
>
>> We implemented BPCS 6.02 full c/s at 5 divisions in less than one year -
>> with three programmers and one of them was learning AS/SET.
>> We could not have done this with RPG .
>> We also use Robot Scheduler, Console, Alert and Autotuner.
>> We do not have a night operator.  We have a very small MIS staff here at
CFI
>> The cost
>
>(She is talking the cost of AS/Set & ROBOT)
>
>> can be justified especially when you consider what consultants, and
>> night operators, and having to rerun jobs due to data entry errors cost.
>
>I am the only MIS staff at CIII's 4 divisions of green screen operations
>actually in 3 physical locations, except for some power users who serve in
a
>help desk capacity, and troubleshooting PC hardware issues.  I do the
>programming & I am the night operator & other stuff.  We have just some
>fundamental tools that came from IBM & SSA, and some of them have
operational
>problems.
>
>We have one non-BPCS application still on Machine/36 but thankfully it does
>not appear to have any Y2K implications.
>
>I think of myself as akin to a locomotive engineer.  The AS/436 is a train
>carrying the business into the future & it is my job to keep it on the
tracks,
>while making it go faster with more frills.  I have failed at my job if
there
>is serious downtime due to a derailment or other disruption, so whenever
>things are running smoothly, I take credit.  I am also a computer janitor,
>cleaning up whatever messes occur, for whatever reasons.
>
>As a labor intensive globally competitive manufacturer we have a lot of
>seasonal business, such as wiring harnesses for air conditioners.  Our
biggest
>customer is some telephone wiring that we wrested away from Singapore by
>beating them on Quality.  Outside MIS & factory supervisors, there are
about
>20 end users who interface on-line with the AS/436, and many managers who
>depend on its reports but have no other contact with the system.  Factory
>supervisors do use inquiry but do not key in any data.
>
>For Wendy & 3 programmers - what is the size of the end user community that
>you service?  I understand that C/S support has a higher MIS overhead than
>green screen support - by how much?
>
>Errors leading to re-do costs are invariably found to be due to one of 3
>reasons:
>1. SSA problem needing another BMR - e.g. A/P discount terms date math went
>south starting February 1999
>2. End user turn-over with gaps in their training, leading to patterns of
bad
>transactional data entry
>3. Baggage from our Y2K conversion e.g. we had to use some contract
>programmers, some of whom unfortunately did not realize that when BPCS
labels
>a field as a NUMBER it often can be CHARACTER content, so we have decimal
data
>errors in several places & one I have not been able to fix is an
intermittent
>problem in shop order release where they are very heavily using SQL inside
one
>of the SFC52* RPG programs and I have not yet learned enough of SQL to fix
>this code.
>
>I do not see that As/Set & Robot would help with any of that.
>
>So my new question relates to what actions are prudent when implementing
SSA
>upgrades PTF BMR etc. because we are on BPCS 405 CD PTF-1 & we need to go
to
>PTF-2 and this will be our first merger with modifications for BPCS/400.
>
>We've done lots of BMRs/400.  Typically the first tape from SSA has
problems
>with the media, the internal labeling in sync with SSA standards, sending
us
>CISC when we asked for RISC, or some other problem resulting in asking for
>another SSA try, but we get the code loaded, sometimes needing help from a
>consultant dialing in via the ECS line, & I tell users they can test the
fix
>in our education environment by ADDLIBLE BMR whatever the number is, at the
>command line.  Then when they tell me they are happy & confident the fix is
A-
>Ok, I move it to a conglomerate BMR library in the live environment library
>list, with appropriate back-out insurance, and plan to clean up duplicate
>copies months later after plenty time allotted for any problem reporting.
>
>We learned on BPCS/36 that it was not smart to load PTFs without
significant
>testing, and provisions for backing out to our previous level - here are
>examples of the kinds of problems we had:
>
>I circulate to the users a copy of SSA's list of what had been upgraded &
why,
>to help them focus their quality assurance testing.  I also listed cases
where
>SSA had included upgrades that were not on their official list, and those
>programs where I had had to merge lines of code - what we had modified vs.
>what SSA modified.
>
>A manufacturing executive tells me WE NEED THAT fix PDQ because we got
>problems in production & inventory that it is addressing.  I ask about a
test
>data library & am told that there is no budget for any testing, we will
just
>have to take our chances & cope as best we can.  2 days later the same
person
>is telling GO BACK TO THE EARLIER VERSION PDQ (pretty damn quick) because
we
>have a horrible mess worse than we ever had, and it is because of that SSA
>"fix."  Fortunately I had done my job in such a way as to be able to do so,
>which does require some advance thinking about possibilities, that might
never
>happen.
>
>One department tested ONLY what was on the LIST such as a bunch of 500
>programs, then we went live on the release, and immediately a bunch of 600
>programs, that call 500 programs, failed hard, because of bugs that the
>testing failed to identify, because the department staff had not realized
that
>unmodified code calls modified code & it is all interdependent.
>
>A combination of departments saying "We cannot live with all the bugs
>introduced by this version" and "We positively absolutely have to have what
is
>in this version" meant that different application areas ended up out of
>version sync, so we were frequently doing fixes on the fly for data
crossing
>version threshholds such as input to General Ledger.
>
>Is this BPCS/36 "experience" typical of what to expect on BPCS/400?  I told
my
>staff & management that in my opinion the most cost effective way to
implement
>PTF-2 would be for me to work on merging it into the education environment,
>then schedule Conference Room Pilots like we did for the Y2K conversion.
So
>far, no concensus has been reached on this, and my marching orders have
been
>to continue adding to the collection of modifications.
>
>Thanks in advance for your insight
>
>Al Macintyre
>Central Industries of Indiana
>Newcomer to RPG/400 but we are often doing the same old job with new tools
>+---
>| This is the BPCS Users Mailing List!
>| To submit a new message, send your mail to BPCS-L@midrange.com.
>| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
>| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner: dasmussen@aol.com
>+---
>

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---