Re: MRP Software Implementation (EXTRA LONG)

Pete,

In a message dated 97-11-14 14:23:35 EST, you write:

> In message <971113042705_1725828204@mrin79>, From DAsmussen@aol.com, 
>  the following was written:
>  > By "implementation", do you mean new sites or upgrading existing sites?
>   
>  
>  Dean,
>  
>  We're trying to get a handle on how much internal involvement from our
>  production people will be needed (as well as from the IT staff). We're
>  an ooolllddd heavily modified BPCS shop, but might well end up switching
>  to MAPICS. It will be an ambitious project, including MRP/ERP. It's a
>  $100M+ company that does very fancy sand casting and machining, 200
>  employees, multinational currencies, offices on 4 continents, NEW AS/400
>  <g>
>  
>  Thanks for you comments. Anything you can pass along is appreciated.

Well you asked!  Unfortunately, all I can still say is "it depends" :-(.
 While learning Synon (required for MAPICS) will certainly increase the value
of your IT staff more than learning the now "dead" AS/Set language of BPCS
(or waiting for a working copy of SSA's new ODW tool), I cannot say that
MAPICS _OR_ BPCS would be your best choice from a business perspective.  BPCS
is certainly more suited to a casting manufacturer than the MAPICS that I
know, but my MAPICS experience is too old to even compare.

I will say, based purely on hearsay evidence, that learning AS/Set and the
new version of BPCS would be quicker for your existing IT staff than learning
the new entity/object constructs of MAPICS.  At least SSA left the file names
alone!  JD Edwards is also a viable alternative on a par with your choices --
SAP sounds out of your price range, but Software PM (if it has the code
improvements that I've been told of) might fit.  From my experience, BPCS'
ERP solution is no better or worse than its competitors'.

If you're going to implement MRP "from scratch", _HEAVY_ involvement from
your most knowledgeable (and influential) management, production,
engineering, and IT staff will be required.  This _IS NOT_ a software
requirement (_NOR_ one to be determined by the IT staff), but one for a
successful MRP implementation.  In fact, if you read Oliver Wight, other
popular manufacturing "gurus", or attend APICS meetings, choosing software is
down around number 12 on the list of "Top 25 Things" you need to do to
implement MRP.  I would suggest contacting your local APICS chapter about
successful implementation strategies for industries of your size and type in
the area.  I would also recommend hiring or promoting someone with intimate
knowledge of your (or similar, such as injection molding) manufacturing
processes as "MRP Implementation Coordinator" who reports directly to the
company President or General Manager and has the _AUTHORITY_ to make things
happen in regard to the project -- to the point of making intractable
employees find other work.  IMHO, if you have a _SINGLE_ manager or employee
that can say "Ahhh don' wanna do this 'cause it ain't like we've always done
things aroun' here", you stand _NO_ chance of success.

Pete, if this weren't _SOOOOO_ easy to screw up, I wouldn't have a job.  My
earlier "head counts" were strictly for IT employees and Business Analysts
dedicated full-time to the project.  Your GM, Controller, Materials Manager,
Engineering Manager, Line Managers, and most of your Shop Foremen are going
to have to spend _at least_ one day a week on this to make it work right,
with various "worker bees" involved from time-to-time.  To perform a "Class
A" MRP implementation (in short, "Class B" is OK, "Class C" is unacceptable,
and "Class D" just plain doesn't work), you'll need an inventory accuracy of
98%, with Bill of Material and Routing accuracy at 95% -- _WITHOUT_ the
computer.  An implementation and/or review of written standards is almost
_ALWAYS_ in order.

The computer and software are irrelevant.  If you don't have (upper)
management commitment to making the project work, you're "hosed" from the
outset and will end up looking bad.  The sad thing is, while an MRP
implementation should have _ABSOLUTELY NOTHING_ to do with the IT staff
(other than assistance in evaluating/implementing software and hardware down
around step 12), it is _FAR_ too often the IT staff that takes the blame when
one doesn't go well.  If your management is committed to this MRP
implementation and you _DON'T_ see the proper delegation of authority (note
the difference between authority and responsibility), "_RUN_, run like the
wind".

If you'd like more specific answers, feel free to mail your questions
directly to me...

Good Luck!

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"One never notices what has been done; one can only see what remains to be
done." -- Marie Curie
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---