We have used UPI services in the past to help us when moving data from one
facility to another, due to a shift in the number of factories, and basis
for moving work between them. The task was simplified by many similarities
& our good understanding of our data rules & prior modifications that laid
some relevant groundwork. The conversion effort was successful, with their
help.

However, the process did reveal some gaps in our understanding.

For example, some engineering had been copied from facility A to facility B
years ago, then maintained separately in the 2 facilities, and now we needed
to reconsolidate all work for customer C in facility A. For some parts
facility B had the more advanced revision, and for others facility A had the
more advanced. It was not acceptable to just wipe out all facility A
engineering with a copy of what was in facility B. We needed to identify
which facility had latest version. This was not something we had been
tracking.

Years earlier, we used a UPI competitor, and SSA/Infor conversion tools.
The result was a disaster, and we had to start over.

Be aware that while SSA/Infor has conversion tools, to help move from one
version of BPCS to another, and do other stuff, the customer base of
feedback to identify problems & get them fixed, is probably at best a few
hundred customers, while using BPCS itself has a customer base of tens of
thousands of customers, and years ago was hundreds of thousands, so the
quality of BPCS itself is thousands of times superior to the conversion
tools.

When we first got BPCS, it came with an understanding of the rules of what
gets changed when new releases came out. We crafted our modification rules
so that there would be no conflict between our modifications and new
releases. Then SSA/Infor changed the rules, and now our modifications were
in conflict with new releases.

We are fortunate in not having a lot of compliance regulations that apply to
our business. If you are subject to compliance, they probably apply not
only to the day to day operations, but also the change process, the running
of your enterprise during the conversion, and access to the data from before
the conversion.

We use auditors that visit scores of other customers, of the auditors, when
they are not visiting us. Every customer of the auditors has a different
computer system, different rules, different policies. It is not reasonable
to expect that the auditors will have a good understanding of BPCS or how we
have implemented it.

Auditors are like new bosses. They demand data mining reports on how stuff
was done 5 years ago, when company rules very different from today, and
quite possibly before some conversion, or change in corporate ownership. So
not only do you need to figure out how to migrate your data to the new
reality, you also need to figure out how to pass an audit that needs access
to the data as it existed before the conversion.

Auditors are not limited to what top management decides to audit, there are
also legal obligations imposed on auditors to go beyond what top management
decides.

We have passed an IRS audit that needed to see data older than what is
normally retained by BPCS rules. We are regularly audited by the bank from
which we borrow money, using BPCS data about our assets, such as A/R.

UPI has a manual to tell auditors what they need to know about BPCS so as to
do a good job of auditing.

-
Al Mac

-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of Milt
Habeck
Sent: Tuesday, March 17, 2009 9:07 AM
To: BPCS user group
Subject: [BPCS-L] Merging 2 BPCS companies together ?

Dear Peter,

We've helped our customers consolidate and split ...... and our experience
with the
process has yielded some insights; here's a top-line sample:

a. Not a trivial undertaking
b. Eventually exposes very small differences in policy, practice, and
convention
between the entities
c. Auditors end up deciding what data to keep and the starting point is
your
compliance profile (SOX, FDA 21 CFR part 11, Tabaksblat Code, etc.)
d. Whether it's a split or a consolidation, the process creates plenty of
data that
requires clean-out attention.
e. There's a fine line between data clean-out that is fully constructive
and
data clean-out that is well intentioned but accidentally harmful.
f. Tools for item deactivation, archiving, and database integrity
analysis
can collectively save man-years of technical effort.

With respect to the data tools, please look at our "Janitorial Implements
for BPCS."
Click the green diamonds in the right-hand box:
www.unbeatenpathintl.com/2.3bw/source/1.html

With respect to considering technical assistance, please look at our
NoExcuses HelpLine
service; it has earned "Standing Ovations" from our customers:
www.unbeatenpath.com/up-a-notch/noexcuses.pdf

Best of good fortune on your project!

Warm regards,

Milt Habeck
Founder/CEO
Unbeaten Path International

(888) 874-8008
+(262) 681-3151





From: Peter Heeren
To: bpcs-l@xxxxxxxxxxxx
Sent: Tuesday, March 17, 2009 3:35 AM
Subject: [BPCS-L] Merging 2 BPCS companies together ?


Hello All,

We are running BPCS 8.2.01 in a client server and Mixed mode environment.
The system is setup for 7 companies in a single database environment.
We are now facing the challenge of merging 2 of the companies to 1
company.

Is there anyone who has done this before?
Was the history converted ?

best regards,
Peter Heeren

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2022 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.