|
|
STATIC AND DYNAMIC
DATA
During the conversion to a new system, one of the most important
tasks is to identify as early as possible what portion of the data
can be considered "static" versus what data should be considered
"dynamic."
Static data can be described as "stable data that does not
experience a high frequency of change." The data elements that fall
into this grouping will vary by business and the processes that
they employ, but would include such data elements as part number,
description, bill of material, customer data, and supplier data
together with many of the part codes. The significance of this
static data is that this data can be converted before the final
conversion takes place. This will significantly reduce the
conversion risk and time table.
Dynamic data is the "data that can change on a daily basis and hence
experiences a high degree of change." The dynamic data will be
converted during the final stages of the conversion process.
Dynamic data includes such information as inventory balances, open
order data, and materials in transit. This information will
typically be frozen just before the final conversion takes place,
and it may be necessary to put in place some processes to handle
such situations as emergency shipments that must occur while the
business is without a computer system. Any transactions that are
processed in this manner would be added to the new system
immediately following the final conversion and just before the
system is turned on for the users.
ONGOING DATA MANAGEMENT PROGRAM
the quality of the system data improves, control limits should be
lowered to reflect the improving quality of the system data.
LESSONS LEARNED
Having been involved in several major ERP system implementations,
there are a number of lessons that I have learned, and these are
summarized below:
• Start data cleanup task early. It always takes longer than one had
originally thought.
• There are occasions when the use of an external consultant can be
beneficial. Don't be proud—use a consultant if it is appropriate
(executive level, software application level, or as a subject matter
expert).
• As data cleanup teams get smarter, they will want additional
reports to help with their cleanup tasks. Be very responsive to
these demands as it shows cleanup teams are taking ownership of
task.
• If one can clean up any data electronically, do it. Check
conversion multiple times before actual conversion cut over to
ensure that everything is converting correctly.
• Clean up "planner codes" first and then produce all the exception
reports sorted this way.
• Identify an owner for each key data element.
• Establish cleanup metrics and goals with data owner.
• Notify functional vice president how data cleanup effort is going.
• Do several mock conversions (two or three) before real conversion.
• Do not forget about exception conditions.
• Put in place an ongoing data management program.
IN CONCLUSION
The success of any system depends upon the accuracy of the data that
it uses to perform its various calculations. To have a truly
successful implementation, not only must the systems be running
correctly, but the data must also have been successfully cleaned and
converted. It is also imperative that the accuracy of the data be
monitored, via the use of system health metrics, on an ongoing
basis. This monitoring is best achieved through the use of a data
management program that is continuously monitored to ensure that it
truly reflects the needs of the business users. With this type of
data management program in place, one can ensure that a high level
of data accuracy is maintained so that one can achieve the benefits
from the newly installed system (i.e., "find the money"). With a
high level of data accuracy, one can now position
Having now successfully converted to the new system, one should put
in place an ongoing data management program. This will ensure that
the data accuracy is maintained on an ongoing basis. Figure 3 shows
the major steps in this process.
The data management program would make regular (weekly preferred,
monthly as a minimum) sweeps of the data files looking for exception
conditions. If exception conditions are found, these would be
reported back to the data owner for resolution. One would maintain
"health metrics" that show the quality of the data over time. In
addition to examining the key data files, one may elect to run
reconciliation reports between data files if the same information
is held in any of the legacy systems and the new system.
Having established a set of system health metrics, it is important
to realize that these will change over time. As
Figure 3. Ongoing data management program
Feedback
Legacy Systems integrated with New System
Exception Conditions
Functional Users
New system can/will have better data integrity checks than old
systems
May also need to include reconciliation checks between data bases
May need to change "System Health Metrics" overtime to keep data
management program current the business to make more effective use
of newly emerging technologies such as sales force automation,
E-commerce, synchronized manufacturing, and other processes that
will give the business a true competitive advantage.
STAY
CONNECTED
To stay current on Lean Management Basics and
Best Practices, subscribe to our weekly MBBP Bulletin... and we'll send you
our PowerPoint presentation
"How to Survive in an Entirely New
Economy." All at no cost
of course.
Your
personal information will never
be disclosed to any third party.
privacy policy
Here's
what one of our 13,000 plus subscribers
wrote about the MBBP Newsletter:
"Great manufacturing articles. Thanks for the insights. I often share portions of your articles
with my staff and they too enjoy them and fine aspects where they can
integrate points into their individual areas of responsibilities. Thanks
again."
Kerry B. Stephenson. President. KALCO
Lighting, LLC
"Back
to Basics" Training for anyone ... anywhere ... anytime
Business
Basics, LLC
6003 Dassia Way, Oceanside, CA 92056
West Coast: 760-945-5596
© 2001-2009 Business Basics, LLC
|
