la-z-boy keeps jde humming with clean data using purge-it!
DESCRIPTION
La-Z-Boy makes use of most modules in JD Edwards EnterpriseOne, and makes heavy use of the distribution and manufacturing modules in particular. With over 2TB of data and multiple sites coming on to JDE, there was a definite need to be able to keep their JDE tables clean and crisp. Too much data would impact their data copies, backups, and batch jobs - they wanted to get on top of this before it became a problem. Being risk adverse, they needed a rock solid solution. Originally presented at JDE INFOCUS 2013 (December 03, 2013)TRANSCRIPT
La-Z-Boy keeps JDE humming with clean data usingPurge-it!
Presenter (remote) :
Andy Weidenbach, ERP Program Director
La-Z-Boy Incorporated
FacilitatorMike Guerin, President, TeamCain
La-Z-Boy Incorporated
Presented at InFocus 2013 –Session ID 1001870
Agenda
Introduction to La-Z-Boy
Our JDE set up and environment Why we decided to purge and archive our JDE data Selection, decision and implementation process Current process JDE purge and archiveCurrent process JDE purge and archive Summary of benefits and lessons learned
JDE Purge and archive best practices, courtesy of Mike Guerin
Wrap up and Questions
About La-Z-Boy
Established in 1927 –first recliner sold by “Floral CityFurniture”(our original name)
First upholstered recliner –1929, and with it the newname of La-Z-Boy
First Reclina-Rocker –1961, propelled growthimmensely
Went public March 1961 Went public March 1961 Revenue exceeded 1 billion in 1997
Went live initially on JDE 8.9 in 2007, staged module go live Migrated to JDE EnterpriseOne with 9.0 in 2011 (still there) 1775 users, 600 concurrent average JDE Modules Used at La-Z-Boy:
• Financials (AP, AR, GL), Fixed Assets• Distribution / other (PO, SOP, IN)• Manufacturing –heavy usage (bread and butter)
Our JDE set up, environment and upgrade
• Manufacturing –heavy usage (bread and butter)• Fair number of custom tables
JDE support staff size is about 12 in total, total IT is just shyof 100
Running Intel / SQL Server at present, VMWare, etc.
Data files growing rapidly and needed to get a handle on thegrowth –currently 2.2 TB
2009 implementation in Mexico added immensely to records 2010 –up to 200 million mfg transactions Made system changes, down to ~ mfg 100 million Performance impact
Why we looked for a purge and archive solution
Why we looked for a purge and archive solution
Alternatives reviewed, decision factors
Looked at JDE “tactical”purge processes –would have neededto customize
Determined needed “out of the box”solution / JDE specific Looked at several solutions out there –end 2011
Solution selection and implementation
Looked at several solutions out there –end 2011 Decided to go forward with Purge-it! –less of a technical
solution, more user friendly, more like JDE
Decision factors
We are risk averse, and wanted a solution the business userscould have control over (not IT)
Ability to largely implement the solution ourselves, and have“ownership”of it going forward.
Solution selection and implementation
“ownership”of it going forward. Purge-it! worked within EnterpriseOne –easy for users and IT
to set up, manage and work with Ability to view archived data within PROD without separate set
up / sign on / environment Audit reports and capabilities; reversal
Solution selection and implementation
Solution selection and implementation
Decisions and process:• Purged from the “outside in”in terms of modules, so MFG PO Sales
and Inventory AP AR and GL in pretty much that order• Allowed us to purge related transactions and work down to the final
“resting spot”of GL• Thought GL would be the “big one”but turned out MFG was instead• Keep 16 months in PROD for MFG, determination in process for how
much to keep in archive
Solution implementation
much to keep in archive• Purge for other modules to come, business discussions happening• Ran in the usual proof mode then final mode• Currently –about 10 million transactions per year in GL and IN, about
23 million in MFG• Light on SOP right now, but will grow as we expand use of it
Solution implementation
Our experience:• Installed the ASU, package build and deploy• Got a couple of hours training from Klik IT for config and
processing options / jobs• Started late 2012 after installing / testing in 1st half of 2012, then did
the sequence of purges.• Completed proof and final modes within a couple of months –series
of purges.
Solution implementation
Completed proof and final modes within a couple of months –seriesof purges.
• Beg of June –over 200 million records in MFG modules; by secondweek of July were down to about 100 million (50% reduction)
• Validated records counts between production and archive• We are using the “FYK”set up –easy access to archive data in
production; thinking of changing to standard table name option forreporting and BI processes and setup.
Doing purge on a rolling basis –monthly now for MFG side Move to archive, just letting the archive grow for now Do it all ourselves Have the “custom”module –use it for MFG add on / tag
files Have tested out and are ready for the PD purge / archive for
Our Purge / Archive process now
Have tested out and are ready for the PD purge / archive forother modules … just a matter of timing with other higherpriority projects going on (hopeful spring / summer 2014)
Purge-IT: features we liked
• Uses JDE menus for access and set up –what we and our users are usedto
• Single job runs the whole process• Archive access –choice available for how to do this with latest release
is helpful for us going forward• Installed as ASU –in our comfort zone• As we upgrade, will just get the new Purge-it! version for the JDE• As we upgrade, will just get the new Purge-it! version for the JDE
release and move forward; new Purge-it! releases include updates toarchived FYK tables for new release
We received the following payback from implementing Purge-IT!:
With the PROD access to archived data, users have easy access tothis data –not widely used, but very helpful
We started (pre purge) with 200 million MFG table records andended up with half that after the initial series of purges
Data copies are less time consuming now (partially due to Purge-IT!, partially due to processor / horsepower changes) –from 8
Our payback …
Data copies are less time consuming now (partially due to Purge-IT!, partially due to processor / horsepower changes) –from 8hours to 4
Virtually no consulting “drag”for implementing Upgrade assistance will be minimal
User Perspective:– Works, looks and acts just like JDE– Access to the archived data, although not huge, is helpful
IT Perspective:
What we like about it
IT Perspective:– Simple to install and use– Works just like JDE –contributing to the ease of use: processing options,
data selection, JDE menu access, inquiry screens for archived data
Our “lessons learned
Easy to get busy and leave purge and archive as a “somewheredown the road”project –don’t do this!
Don’t be a “data hoarder” Involve business users –for course of actions, what stays in
prod and what goesStay on top of it –purge and keep clean Stay on top of it –purge and keep clean
Consider reporting / data retrieval side of things –shouldimpact what you end up doing for archived data
Select the right tool
Questions ?
Purge and archive best practices
Courtesy of Mike Guerin / TeamCain
Purge and archive best practices
Why purge and archive?• Performance
• JDE is a batch system and transactional … performance can drop significantly
• Upgrade
• Most common reason of late … purge before upgrade can reduce risk andspeed things up (can always migrate archived data later). Gets rid of “dirtydata”too
• Business change
• LOB sold off, plant / location closed
• Disk and backup
• Disk is “cheap”, but not never ending. Backup implications
• Spin off impact
• BI Data loads, disaster recovery …
• If you have more than 10 years –it is probably just time to get it done.
• Did you realize? 10 minutes per day for 50 people = 1 Full Time Equivalent
What to purge and archive?
• Look for the “heavy hitters”–larger transaction files (typically GL, AP,AR, PO, IN, SOP
• Run reports to show disk usage in descending order –record counts too
• Watch for tag files –often these are heavy disk use as well (F55 –F59)
• Add on systems?
Purge and archive best practices
• Add on systems?
• Master files? Often not (other implications) and often not large usage /performance implications
• Old / dead / dirty data that can be swept away?
When to purge and archive, and how far back?
• How much to keep –question for the business
• Most common –current plus 2 in PROD; another 2 in Archive tables
• Can be up to 7 in PROD depending on industry
• Legislative –what MUST you keep and how accessible does it need to be?
• Reverse also holds true –if the data is there you will have to produce it (exposure)
• Users will almost always want more –ask the “why”question. Often can be
Purge and archive best practices
• Users will almost always want more –ask the “why”question. Often can besatisfied in other ways
• Consider go-forward plans as well –how often (monthly, quarterly, annually) as abest practice
Who is involved?
• A purge and archive project is a business project supported by technicalstaff
• Users own the data, IT owns the process to manage it and dealappropriately with storage and technical aspects
• Business staff decide on purge and archive cut-off dates, companies / unitsto carve off, legal interpretations, etc.
• Business users should sign off on test purge results and validate the data
Purge and archive best practices
• Business users should sign off on test purge results and validate the data
• Outsourcing can make sense depending on schedules … but not the signoff by users
Watch out for / other points
• Integrity
– Normal to keep, but sometimes need to break
• What to do with archived data
– Who needs access / how often
• If upgrading
– Benchmark time needed for data conversion
Purge and archive best practices
– Benchmark time needed for data conversion
• Pre or post upgrade?
• Top features
– Ease of use
– No table locks or system down time
– The option to self install / self train / self operate
– How Purge-it! looks, feels and works just like JD Edwards
– The out of the box access to archive data within Production (only forEnterpriseOne clients)
Our recent customer survey –selected details
EnterpriseOne clients)
– Single process for purge, summarize and archive
• Top Reasons for choosing Purge-IT!
– Ease of use
– Ability to access archived data from within production directly
– Price / investment
– How it worked just like JD Edwards
– Product presentation
• Over 95% said they would purge as part of their upgrade, and 85% said itwould be before the upgrade
• About 60% do annual purges, another 25% as required
• Current + 2 most common retention policy
• About 83% use custom tables
• 58% purged in less than a month, none were more than 3 months elapsedtime
Our recent customer survey –selected details
time
• About 25% had used JDE purge routines before, just under 50% had donenothing, 12% had used ARCTOOLS
P - Purpose builtJDE, release, module, no hardware, no MTR's
U - Update or proofComfort and confidence
R - ReversibleWhole, part
G - Get access to dataArchive data in PD, safe, secure, no new Environments
E - ExtendableModular, Custom module, ASU install and updates, multi-server
I - IntegrityHard- and soft-coded, preserves data integrity
T - ToolsetMiddleware, CNC, easiest to configure and run
How can we help??
Come chat at our booth Get a copy of this presentation Arrange to speak with Andy at La-Z-Boy (or others) File review for recommendations on what to purge One page “Benefits of a JDE purge and archive”document One page “Benefits of a JDE purge and archive”document Recorded solution webinars on our site Specific presentation for you? Happy to provide investment estimate
Andrew Weidenbach: [email protected]
How to reach us…
www.teamcain.com
[email protected] President | TeamCain
[email protected] Director of Sales | TeamCain