Re: one server versus multiple servers -- BPCS-L

>  From:        kcthai@nemic.co.jp (kcthai)
>  
>  We are considering installing BPCS on one server in our HQ.

     {Al Macintyre}
We have 3 factories & from time to time I have proposed the idea that we 
shoot for 3 smaller AS/400'ds - one per site, for purposes of performance & 
speedy access to that site's data, compared to whatever the baud rate is on 
the phone line that takes a vacation whenever a more than very mild weather 
front passes through a city at either end of the phone line, which is a 
seasonally fluctuating issue due to the direction of the prevailing winds & 
the latest type of El Telco global weather patterns.

>  Users from our factories in the Asia region will access the system 
>  through leased line. 

I have been saying that our telephone infrastructure would put a banana 
republic to shame, but I have also heard horror stories about phones in other 
parts of the world.  A key question is what kind of uptime you can expect & 
if your telco tech support goes down when your phone line goes down, which is 
something we have had to contend with, and how long you can tolerate the 
damage done to your business when a site needs to get at data via a phone 
line that is down just because the weather is having its weekly storm & our 
phone line is physically running through a heavily wooded area whose trees 
are getting a back rub party on the phone lines.

>  Is it better to have one server in each factory or just one centralized 
server.  

The reasons why we ended up with all our eggs at HQ, with the other places 
being remote sites on the end of a leased line, were due to:

The data is integrated, not easy to separate what belongs each place.

We tried having separate data bases by facility & found that by splitting off 
what logically should be integrated, it had a multiplication effect on the 
work load of HQ staff, if not more - the work to be done, not multiplied by 
number of factories, but raised to the mathematical power of number of 
factories (cubed in our case), like economy of scale inverted.

Pricing - one big AS/400 & remote stuff is cheaper than 3 smaller AS/400 - 
how many copies of the software do you have to buy, licensed to what CPUs --- 
for the price of one copy of the software you can have several copies of it 
on the same CPU, with people at many different factories using the same 
software, but not on different CPUs within your enterprise.

We are nervous about tech support & have a centralized IT at HQ - when stuff 
goes down, we think we need to have qualified personnel everyplace the 
servers are.  Using Leased Lines & Perle Remote Controllers, the remote sites 
have all the benefits of local virtual servers but not in reality, except 
some stuff is more difficult to diagnose & configure when the problem is not 
at the same site as the tech person.

>  The important thing is the HQ must get all info and data of each factory. 
>  What is the pro and cons of just setting up one server in HQ ?

We are on BPCS 405 CD mixed mode - both twinax interactive & PCs.

I do not believe this version of BPCS is doable on multiple hosts from the 
perspective of what you want, because of the nature of the data being 
integrated - any given file will have fields that are HQ and remote factories 
AT THE SAME TIME, and data that is one or the other.  Where do you store that 
file?

Or do you copy files between sites, and don't sweat it when cost & efficiency 
& lead times & etc. are not in sync & no way really to correlate what is 
different, that logically should be identical.  So that some files are at HQ 
& some are elsewhere, based on predominant content.

The only way I see to do it, is have each factory do its BPCS in a totally 
different environment with each able to dial into the other place's systems.  
 HQ & the factories would not have the same mix of applications, which might 
confuse some people dialing into the other set of rules.

Forget about any kind of corporate consolidation, from either a Financial 
perspective or manufacturing advantage from the perspective that you have 
more than one factory - you are in fact using BPCS like totally independent 
divisions that have friendly access to each other's data.

When the data is at HQ with everyone remote, any user at any factory is only 
a keystroke or two away from the corresponding data for the other factories 
or a consolidated picture.  When the data is diversified, you have to totally 
exit from YOUR BPCS at YOUR SITE to sign onto the environment of the BPCS at 
some other site, which is a much more cumbersome process.

Do your factories share commonality of raw materials, vendors, customers, 
finances?  Do you want to enter & maintain your common static data one time 
only, or one time for each of your factories?  Do you plan to have a set of 
files for receivables & payables for each of your factories, maintained in 
parallel, with careful planning of bank accounts, so you know what goes 
where, and also manage transfers when stuff gets posted to the wrong 
factory's records?  

How will you transfer data between the different systems?  Do you have 
inter-facility transfers?  Some facilities manufacture resources that become 
raw materials at the others.  Some have specialized sub-assembly work on 
behalf of others.  If this data is not in one centralized system, you have to 
figure out what needs to be communicated between the servers at each of your 
sites.  This is a potential nightmare of extra work & personnel over-loaded 
clerical payroll compared to a central system.

Our BPCS is licensed to one CPU.  Can you buy BPCS that is licensed to all 
the CPUs of a corporate enterprise, at some price discounted below full price 
times the number of your factories?  When we were on MAPICS & we had a 
separate CPU at each site, IBM made us pay full price for each copy, until 
management beat them down to a 5% discount on copies after the first one for 
the same corporate enterprise.

There is one major advantage of BPCS over MAPICS in a communication reality 
of telco downage.  Every time the weather took down some job or user, we had 
a major scramble to repair the damage & it was not unusual in the middle of a 
work day to have to restore to the last backup & tell everyone to have to do 
all today's work over again, because we did not have a LAP (Local Area Power 
protection for 100% of peripherals, and not available for telco).  I remember 
arguing with my boss - I thought everyone should be sent home until the bad 
weather had passed through the region - I lost - the result was that we 
restored to the last backup 7 times in a 48 hour period & it took a week 
until everyone got their work caught up.  That scenario is unheard of with 
BPCS.

We take weather hits on our telco connection at the average rate of several 
per day, and business just rolls on unfazed, it is only a nuisance if a line 
is down for several hours, because people cannot get at the data they need to 
get to, but with BPCS, unlike the version of MAPICS we were on 15 years ago, 
if telco goes down when someone is updating an order via that telco, the only 
problem is that we have to do a 2 minute fix to that order, or that the user 
neglects to tell IT about the order involved, so we do not know what to reset.

When we migrated to better hardware at HQ & replaced remote site CPU with 
becoming at the end of a 500 mile leased line, the remote site performance 
skyrocketed.  We were amazed.  Everyone had been doing number crunching with 
- here is the baud rate, 2 k per screen, number of simultaneous users, 
distance the data has to travel - we were expecting a slow down & instead 
went from multi-second to sub-second response times.

Hope I have illuminated some issues in a helpful yet concise manner.

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