RE: Data mapping -- BPCS-L

Thanks Al,
You are, as always, a wealth of information and ideas and why you
continue to labor for anyone other than yourself remains a mystery.  If
not a bullseye it is certainly in the first ring and will give us some
very interesting avenues to explore.

Much thanks,

Mitch Damon, CPIM
Data & Process Integrity Manager
Birds Eye Foods
Rochester, NY
(585) 383-1070 x 250

-----Original Message-----
From: Alister Wm Macintyre [mailto:macwheel99@xxxxxxxxxxx] 
Sent: Tuesday, September 21, 2004 3:54 PM
To: SSA's BPCS ERP System
Subject: Re: Data mapping

You have been given some awesome responsibilities, that we all should
have, 
but normally we so distracted with the consequences of no one having
these 
duties, that we never have time to get to it.  In other words, dirty
data 
flowing through flawed reports, without easy ways for people to fix
errors 
they know about, can contribute  keeping us extremely busy, but perhaps
we 
would be better off without the flawed reports or the dirty data, that
many 
end users probably oblivious to.
    * Convenient access to good solid big picture of how various fields
in 
BPCS files are used ... in which I think the one most useful tool you 
should have, for the data mapping purpose, is the BPCS Reference Manual 
from http://www.dssolutionsinc.com/OverviewManual.asp which I have
wanted 
for years, but my employer won't buy it for me (there are lots of things
I 
have wanted over the years to help me be more productive, but selling
the 
value of that concept can be difficult for me), and I have been too
cheap 
to cough up the $ 350.00 to buy it for myself.  Look at 
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
for 
other such resource links.  We might also have a discussion (this may 
already be in BPCS_L archives) why we are not using XREF that came with
BPCS..
    * Quality assurance in reports ... vanilla BPCS, modifications
in-house 
over history, software from third parties, queries developed by end
users, 
how users are using BPCS data transferred to spread sheets on personal
PCs 
... one thing I have suggested (another Al proposal that went no place)
is 
to have the outside auditors get a report on which reports and inquiries

get the heaviest usage (a datum that you can get from *OUTFILE software 
directory) to run our company, then with each annual audit, let the 
auditors pick a handful of those heavily used information sources for a 
professional inspection to see what flaws might be there, if any.
    * Quality Assurance in data ... we know that there are many places 
where errors creep in giving us dirty data ... are our work arounds 
adequate? ... have we identified all the causes? ... How does Sarbanes 
Oxley factor into this? I see little point in having auditors say that 
certain financial reports are Ok, based on the immediate underlying
data, 
when they sit in a foundation of questionable data sources.  We should 
identify those problem data sources and clean them up long before time
to 
check the annual reports.
    * It also helps to have access to a test data base, which can be a 
quick way of figuring out what happens if we do this or that ...
sometimes 
looking at the source code is the fastest way, sometimes it is faster to
do 
some trials of a nature that are not a good idea in the live data.
    * Another manual you should seek (that I also want but not have for
the 
same reasons) that costs I think in the neighborhood of $ 135.00 is the 
BPCS Handbook for Auditors  http://www.unbeatenpathintl.com/audhand.html

... the principle here is that people have certain expectations of the
data 
in any ERP, and those expectations may be misplaced ... in other words,
the 
data in the reports can be accurate, but there can be a people problem 
interpreting that data, and this manual helps an auditor understand
areas 
of discontinuities between the ERP and its users ... areas of common 
misconceptions for BPCS users world wide, some of which might be found
in 
the company you auditing ... where to look for common problems.
You might be interested in a project I engaged in several years ago.
The boss (at the time), felt that we were having far too many errors of
a 
certain kind, that were having catastrophic impact down stream.
For approx 8 months, my software development focus was to try to
intercept 
BPCS error messages before they got to the humans, and take appropriate 
responses every time.  We also identified safer practices for end users 
such as
    * Even if nothing goes wrong 99% of the time, capture on spool file 
audit trails of your work, so that when something does go wrong, we have

some hope of figuring out how to fix the problem.
    * If you are running this kind of application, ALWAYS send updates
to 
JOBQ, and let's periodically check to make sure everyone in that 
application is using the same JOBQ ... we also deactivated the ability
to 
run certain jobs interactive on-line.
    * If you are running this other kind of application, ALWAYS do your 
stuff interactive on-line.
    * Perhaps you need to update some shop orders, change the order 
quantity for example ... be aware that if labor is being keyed in and 
updated on that same shop order while you working on that, there could
be a 
collision.  Here is how to avoid any such collision.
    * When you doing a string of related tasks, whatever you do, do not 
launch early tasks to JOBQ then before you got confirmation of
completion 
start next steps on-line.
    * We do not want to be posting regular activities to GEN LED (via 
INV920 then GLD540) while those regular activities are on going ....
turned 
out our list of those activities was incomplete as we found out in
recent 
months.
    * In the end day processes, there are a bunch of reports listing a 
variety of glitches (a no fault word meaning data mucked up) ... if the 
reports empty then nothing to fix ... if stuff there, then get to it
fixing 
them
    * When we have a hardware problem, such as a PC going down in the 
middle of updating customer orders, it is kind of predictable what kind
of 
a mess that will cause to the work that was being done when the hardware

problem occurred, so we have a series of steps off a user menu to follow
to 
fix the problem, assuming it is reported by the victims in a coherent 
manner to the people who know how to run the fixes.
The above might not be precisely what you looking for, but for us, what 
these practices accomplished was to eliminate major causes of dirty
data, 
but in recent years we been backsliding on some of this, and getting
dirty 
data again.

Mitch Damon wrote:
>Hi folks,
>
>
>
>Again I am turning to the wonderfully knowledgeable professionals on
>this list for help and guidance.  I have recently been given
>responsibility for ensuring that the data used to build management
>reports, links to other systems and used in critical business processes
>is accurate and used appropriately.  Of course this is a huge
>undertaking and if the team hopes to get it done before we are retired
>we will need a head start.  Does anyone have or know where I could get
a
>directory of the most important fields in BPCS with definitions of what
>they are, where they are used and what programs are effected by them?
>As always your input is greatly appreciated.
>
>
>
>Thanks in advance,
>
>Mitch Damon, CPIM
>Data & Process Integrity Manager
>Birds Eye Foods
>Rochester, NY
>(585) 383-1070 x 250

-
Al Macintyre  http://www.ryze.com/go/Al9Mac
Find BPCS Documentation Suppliers 
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
Part time may get commission from some BPCS vendors for helping them ...
I 
will now say in a post if the product I commenting on is also one 
potentially involved with this ... not that I have made anything from
this yet.
_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.