× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Multiple BPCS Environments?
  • From: MacWheel99@xxxxxxx
  • Date: Thu, 25 Feb 1999 15:17:09 EST

Andrew asked

>  Has anyone got any ideas/experience on the issue of multiple vs single
>  environments?

We used to have FOUR separate environments for production divisions and number
FIVE for testing & education when we were on BPCS/36.  On our current BPCS 405
CD we now have ONE for all divisions, ONE for testing & education & I am
trying to persuade the powers that be that there is ONE from Y2K conversion
that we do not need any more, eating our disk space.

>From the perspective of end users in various departments whose job it was to
maintain customers vendors items general-ledger etc. they did not like having
to do their job FOUR times over for common used ingredients - actually it was
usually needed only THREE times over, but there was mass confusion regarding
which things really needed to be in the other environments, so some people did
not get the duplication that needed to be done.  What is the ratio of staffing
levels & their payroll to useful work done & your competitiveness when some
work has to be done FOUR times over?

IT found it neccessary to write a bunch of comparison programs --- the costs
are inconsistent across environment for the same part - is that valid? --- the
BOM is inconsistent - is that valid?  The revision number on a common part is
inconsistent --- is that valid?  How do you structure those programs so that
if another division gets added, no sweat adding another column of differences?
How much time is spent by how many people in how many departments fighting
this battle - that is easily a full time job added to your payroll & for what
benefit?

An upper level of management not involved in the computer operations would
decide to move this or that model line to a different factory, in the
interests of balancing the overall load between factories, and specializing in
the kinds of work done where.  When you are on ONE environment, this is a
simple matter of some order maintenance to change facilities that the work is
being done in, then MRP to dictate intercompany transfers of inventory.  With
MULTIPLE environments, customer requirements need to be transcribed to the
right factory, without access to history data for forecasting purposes, and
the orders closed out on the old factory, with similar upheaval for everyone
else.  

Are the divisions truely independent with ALL the work being done by a TOTALLY
separated bunch of people?  In our case there is a CORPORATE HQ which does
SOME of the work for all divisions, like planning & purchase orders.  Are they
now going to have to do that work however many times you have environments?
Consider the purchasing department getting raw materials for 4 divisions.  Do
they need a consolidated system?  That one purchasing department is going to
require more work to get the same job done.  The lead time for your raw
materials just got longer.

We have people whose job it is to enter customer orders at corporate level -
do they know which division this is for? - do they know which division they
are in? - do they sometimes key the stuff into the wrong division? YOU BETCHA
& most important, how much hassle is it to fix this when they realize what
they just did?

Why does accounting have to have a consolidated picture anyway?  Why can't
they just run however many different companies using the same template?  I
think the main issue is that when you look at the needs of the corporation
through the eyes of different departments, the benefits & harm of such a split
up is viewed totally differently.

Customers pay bills to our company.  They usually do not divvy up their
payments to match the billing that might have been separate for each
environment.  So now you have to figure out how to post some of that payment
to each of several environments & if there ever is any communication problem
with the customer regarding what they owe & what they paid, there is a
nightmare translating from our jigsaw puzzle to what makes sense to the
customer accounting department.  I do not know about YOUR company, but at
Central there are ALWAYS tardy customers and there are ALWAYS questions about
shipments, that contribute to the Receivables department reconcilliation
challenges.  

Some customers are not too well organized in how they track what they
received, or perhaps they are playing some game with us to string out how long
they do not have to pay.  They question a bill.  We fax copies of invoices
showing our total.  They fax original POs showing that they did not order as
much as we sent.  We fax copies of changes to those POs signed by their
personnel, that we acted on in good faith.  They question that they even
received some of the shipments, and fax the payments they made.  We fax
photocopies of whoever at their facility signed for what they ordered, and an
itemization of how we applied the payments.  Now run this scenario through
multiple divisions with one environment each.  Your cash flow is going to
suffer, with bills not paid as fast.  The accounting work load will increase
to get the same job done.

Will you have separate bank accounts for every application for every
environment?  Our corporate handles the payroll & billing & payables & POs for
all divisions, while the actual factories tend to focus on inventory &
production & shipping nuts & bolts.  So we have one bank account for payables
because THAT is what is convenient for the accounting department, and we had a
modification that used a code character associated with the check writing that
identifies what environment is involved - the checks are all the same color
--- I was arguing for a different color check for each environment & through a
different bank account, to keep the reconciliation separate by environment,
while the accounting department wanted one bank account, one set of checks to
run thru the printer --- well this is something you will have to discuss with
your people, because if you are not careful you will end up with a royal mess,
unable to match bank reconciliation statements with your individual
environments.

There is also the IT issue of transition between the two ways of doing
business - how do you populate your environments?  I betcha you will need a
LOT of extra hard disk space along the way, and have to use software that does
not come from SSA.  We used File Track from http://www.outlookcomputing.com

Do you have end users writing Query or other reporting / inquiry tools that
are rooted in a particular environment?  Will they want to get that report
into that other environment?  Do you see a security hassle there?  I expanded
security to permit people to move their Query reports into the environment
where they wanted to be able to run it, then some people forgot some stuff &
we have the phenomena of someone running a report ostensibly in one
environment but the data is from a different one.  This becomes an extra load
on training.

I don't see any business benefits, once you factor in the impact due to all
departments, unless you really have several factories that are so independent
they might as well be totally separate companies with different owners &
managers & personnel for all functions & different computers unconnected.  The
only reason we did this on BPCS/36 was that SSA had not yet invented multiple
facilities to keep the inventory & MRP separated from a consolidated picture.

Al Macintyre
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.