1 / 56

Freudenberg-NOK Sealing Technologies (FNST) Project: QAD 2010 SE Migration

Freudenberg-NOK Sealing Technologies (FNST) Project: QAD 2010 SE Migration. Migration to a Single Hosted Multi-Domain Environment. Agenda. FNST introduction; who are we? Business Challenges Current Environment Process Realized Benefits Lessons Learned Q&A.

meira
Download Presentation

Freudenberg-NOK Sealing Technologies (FNST) Project: QAD 2010 SE Migration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Freudenberg-NOK Sealing Technologies (FNST) Project: QAD 2010 SE Migration Migration to a Single Hosted Multi-Domain Environment

  2. Agenda • FNST introduction; who are we? • Business Challenges • Current Environment • Process • Realized Benefits • Lessons Learned • Q&A

  3. Freudenberg-NOK Sealing Technologies Established 1989 Headquartered in Plymouth, Mich., USA (Privately Held) • Established 1849 • Headquartered in Weinheim, Germany • (Privately Held) • Established 1939 • Headquartered in Tokyo, Japan • (Publically Traded on the NSS)

  4. Diverse and Established Partners Headquarters Plymouth, Michigan Weinheim, Germany Tokyo, Japan Established 1989 1849 1939 2008 Sales $1 Billion $6.5 Billion $4.5 Billion Ownership Privately Held Privately Held Publicly Held Products Radial Shaft Seals O-Rings Gaskets Fluid Power Products Diaphragms Specialty Sealing Products Radial Shaft Seals O-Rings Gaskets Fluid Power Products Oil and Gas Products Diaphragms Specialty Sealing Products Vibration Control Devices Medical Products Radial Shaft Seals O-Rings Gaskets Fluid Power Products Diaphragms Specialty Sealing Products Vibration Control Devices

  5. Freudenberg Global locations Production Sales Production and Sales

  6. Plymouth, MI Technology Center Shelbyville, IN Milan, OH Boots & Bellows Heavy Industry Lead Center, Imported Products Troy, OH Findlay, OH PTFE Products PTFE Products Morristown, IN Custom Molded Rubber Products Santa Ana, CA O-rings Cleveland, GA Sao Paulo, Brazil Radial Shaft Seals Valve Stem Seals and Powertrain Seals Querétaro, Mexico O-rings Cuautla, Mexico Radial Shaft Seals and Custom Molded Rubber Products and Vibration Control Devices Production Locations in the Americas New Hampshire Facilities: Ashland–Aerospace Radial Shaft SealsIndustrial Radial Shaft Seals Bristol –Mechanical Face Seals, Bonded Piston Seals Northfield –Axle Seals Necedah, WI Gaskets Manchester– Gaskets Manchester– Microcellular Polyurethane LaGrange, GA O-rings Elgin, IL Simrit Sales Office Tillsonburg, ON Silicone and Fluoro-silicone Products

  7. Freudenberg-NOK Sealing Technologies Today • Responsible for sealing technology business in the Americas • Total sales in 2010: US$ 798.7 million • Workforce in 2010: 4,224 • Locations in: U.S., Canada, Mexico, • Brazil, Malaysia, China • Sales exceeded market recovery in 13 • of 15 principal market segments • Sites: 35 production, sales and • technical facilities

  8. Agenda • FNST Introduction; who are we? • Business Challenges • Current Environment • Process • Realized Benefits • Lessons Learned • Q&A

  9. Business Challenges • Move to a Supportable QAD Release • Make .NET Available to All Sites • Reduced training time – Process Maps • Improve user access to QAD data – Browses created by IT • Provide users with tool for generating ad hoc queries - Browses • Reduce Support Costs • Eliminate several aging HP servers • Reduce the number of databases being maintained • Streamline Custom Processes • AR and AP Buy-ups • Centralized Pricing Pushdown

  10. Our Plan • Move 20 databases on 13 geographically separate servers into a single database on one central server • Each database became a Domain

  11. FNGP ERP Current Landscape

  12. Future QAD Architecture RH Linus 64 Bit

  13. 2010 SE Project Timeline • January 2011 – Project Approved • January 2011 – Hardware installed in Raleigh, NC • February 2011 – Began Code conversion from eB2 • September 2011 – Created Golden Image database (G.I.) • October 2011 – Completed coding – IT Pilot • November 2011 – User Pilot at first conversion site • December 2011 – First Site converted – merged into G.I. • Q1 2012 – 5 more sites converted and merged • Q2 2012 – 10 more sites converted and merged • Q3 2012 – Final 4 sites converted and merged

  14. Agenda • FNST Introduction; who are we? • Business Challenges • Current Environment • Process • Realized Benefits • Lessons Learned • Q&A

  15. eB2 Hardware Environment • 12 Distributed HPUX RP54xx Class Servers • Character only • “Computer Room” class environments at best • Central (Corporate) HPUX RP54xx • Buy-up processes • Source for NFS mounted on all remote servers • Central development HPUX • Remote Linux HP DL Class Server and supporting Windows servers (2013 Project) • Character and NetUIUpLift • Central Linux development (2013 Project)

  16. Other Environments • QAD 2007 • HP Blade center • Database Linux blade • NetUI Linux blade • Supporting windows servers • QAD 2008 • HP DL-series Linux database server • HP DL-series Linux NetUI server

  17. 2010 SE Hardware Environment • Central (co-lo) HP C7000 Blade Center • Class 6 Data Center • Database blade (BL-460c G7) • QA blade • Development blade • QXI blade • NetUI blade • Virtualized NetUI server • Central (NH) HP C7000 Blade Center • DR blades - Cold (Warm near future)

  18. Agenda • FNST Introduction; who are we? • Business Challenges • Current Environment • Process • Realized Benefits • Future Plans • Lessons Learned • Q&A

  19. Code Upgrade • Established list of QAD programs with invasive code (total of 430) • Developed initial time estimates • Grouped programs according to functional area • Assigned resources to update code, by functional area • Assigned resources to test changes - usually different than person who updated code • Established shared spreadsheet for tracking completions and recording hours • Programming started in April 2011 - completed all except Pricing by end of June 2011

  20. Code Upgrade (continued) • Testing - Invasive Coding • Established formal procedures for creating and executing Test Plans • Test Plan documents were created in SharePoint; testers recorded results and hours • Testing started in mid-April 2011- completed by end of Sept 2011 • Testing – Custom Programs • Established list of FNST Custom programs; sorted by usage volume • Established shared spreadsheet for tracking completions and recording hours • Testing started in mid-July 2011 - completed by end of Sept 2011

  21. “Golden Image” • Identified data elements that all Sites shared: • Browses and Lookups • Menus and Security Groups • Messages • Countries and Languages • Built Golden Image database containing only these tables. • Custom Menus and Browses needed to be integrated • For each Site Conversion, the tables that were part of the Golden Image were not merged into the Combined database

  22. Piloting – IT Pilot • Developed Pilot Script - over 500 tests, grouped by functional area • Some Team members tested solely in Character; others tested solely in .NET • Team members tested independently, recording Issues as they were encountered • As team members completed the Pilot, they were assigned to the resolution of Issues that were uncovered during the Pilot • IT Pilot started on October 3rd - ended on October 21st.

  23. Piloting – Complex Sites • Full Pilots were conducted prior to the conversions of the more complex sites: • Number of users • Range of functionality being used • Unique custom functionality being used • Foreign Currency • Significant business issues at the site • ‘Pilot Script’ created by Site Team and IT • Script executed over multiple days/weeks • Sites Piloted with their own data

  24. Piloting – Simple Sites • Limited Pilots conducted prior to conversions of the less complex sites • No formal ‘Pilot Script’ was prepared • IT recommended programs to Pilot, based on experience with Sites that had already been converted • Users tested the programs that they used most heavily

  25. Conversion Process

  26. Data Validation • Established a standard Validation Cycle that was used for each Site Conversion: • Baseline Reports – • General Ledger (Income Statement; Balance Sheet; Un-posted Trans) • Accounting (AR and AP Aging; Memo Register) • Inventory (Inventory Valuation; Cost of Sales; Cost of Production) • Supply Chain (Purchase Receipts; Customer Commitment; Open Orders) • Environment – • Printers • Security • Control Files • Eagle Setup

  27. Data Validation (continued) • Validation Steps performed for each Site Conversion: • Established Baseline on eB2 before data transfer • Ran Report Validation after eB2 data was transferred to Raleigh • Ran Report Validation after eB2 data was converted to 2010 SE • Ran full Validation Cycle after the data for the site being converted was merged into the Combined Production database

  28. Moving the database - HP to Linux • Review database stats to determine candidates for individual table dumps • Multiple scripts dumping tables • Multiple scripts waiting for work • Compressing dump files • Transfer to central host • Uncompressing at central host • Loading at central host

  29. Moving the database (continued) • Use table statistics to find candidates for individual dump scripts

  30. Moving the database (continued) • Run standard utility to build dump scripts • Run custom script to add control information to each of the dump scripts: • Save the script start time and end times • Update the logging files • Set the semaphore indicating each dump script is complete

  31. Moving the database (continued) • Split into parallel dump scripts using control file (containing the tables identified in our table analysis) – Ran up to 14 dumps concurrently • Estimated time of largest individual dumps equal to three sets of individual bulk dumps • Build the 3 “bulk” dump scripts for remaining small tables • grep "d-[a-i]" dump-0.sh > dump1.sh • grep "d-[j-s]" dump-0.sh > dump2.sh • grep "d-[t-z]" dump-0.sh > dump3.sh • Pull the individual dumps from the master script file as separate scripts and strip from the bulk scripts

  32. Moving the database (continued) • run_all_dumps.sh (source host) • Launches all of the bulk dump scripts • Launches all of the individual table dump scripts • Starts multiple scripts waiting for the “dump complete” semaphore and when found gzips the file, then sets “ready to copy” semaphore • Starts multiple scripts waiting for the “ready to copy” semaphore and when found does the rcp and sets semaphore on remote host indicating copy complete

  33. Moving the database (continued) • run_all_loads.sh (target host) • Starts multiple scripts waiting for the “copy complete” semaphore and when found unzips the file, then sets “ready to load” semaphore • Starts multiple scripts waiting for the “ready to load” semaphore and when found does the load

  34. Conversion Prep • Prepare updated crontab’s each side • Exclude site from source host • Include site on central host • Prepare updated procmail’s each side • Extract HPUX printers via SAM, load via script • Prepare target eB2 and 2010 SE databasesand menu picks • Prepare the dump/load scripts • Extract Eagle users, load via script

  35. Pre-Load Large History Tables (optional) • Utilize pilot conversion • Pre-stage prior years to target • Only transfer current year data from eB2 during production merge

  36. Conversion Weekend Timeline

  37. Conversion Timeline (continued) • Friday 5PM (Times local to site) • Shutdown source databases, assign password for conversion team, restart databases • Shut off backups, monitoring and QXI • Update database start-up files, crontab, procmail • Run standard reports for validation • Friday 6PM • Run table statistics for validation • Invoke the dump/load scripts

  38. Conversion Timeline (continued) • Late Friday (or verrrrrry early Saturday ;-} ) • Run table statistics against target and validate • Index rebuild (due to no integrity load) and restart • Copy eB2 target to “validation” database • This allows ERP Team to run validation of the transfer (mfgutil wants new environment) • Start the conversion • Get through the initial steps, get long unattended step running

  39. Conversion Timeline (continued) • Saturday AM • ERP Team can verify eB2 at their leisure • Continue the conversion through short steps (index rebuild, field updates), get to the next unattended long step (OID pop) • Admin conversion • Saturday Afternoon • License the converted database • Perform update steps, manual table loads • Sidecar and ADG conversions

  40. Conversion Timeline (continued) • Saturday 4PM • ERP Team validation of converted database • User security updates • Merge script prep • Saturday 5PM • Backup the consolidated database • Password protect consolidated database • Invoke merge (dump and load) script

  41. Post Conversion Steps • Update licenses • Update the mfg user and assign licenses • Dump and load browses • brwf_det, brwt_det and brw_mstr • Load standard labels • lbl_mstr.d and lbld_det.d • Load NetUI items • /appl/qadea10/admin, [us|ls]/admin

  42. Post Conversion Steps (continued) • Load Language • lngd_det, lng_mstr • Run updates and advisories • Sequences (utsequp.p ) • Inventory Location Update (utinloup.p) • Tokens (uttoken.p) • Trading Partner Para Desc Update (utrplpd.p) • Update Transformation Variables (uxedtrv.p)

  43. Post Conversion Steps (continued) • Load online help • Load our field help • Convert ADG (Automotive Development Group) tables • cald_det, calh_det, calm_mstr, cals_det, ptre_det • Convert Sidecar Database (our extensions to QAD) • Program (per table) • Populate Domain • Assign OID • EDI Fixes • TpParamConversion.p, ecom_batch_cv93.p, edupxref_cv93e.p

  44. Security Merge • Since the user security points to OIDs in the converted database, extract and update pointers to the merge target • Extract the group records (usrg_mstr) from converted and from merge target • Update each detail record (usrgd_det) by parsing the assigned group from its OID in the group record and looking up corresponding group record in the target • Merge this updated file

  45. Merge Prep • Similar to offload/reload • Run prep script • Builds a dump script per table (only tables with content) • Offload/reload used binary dump • Builds the dump .p per table • Builds a load script per table • Builds the load .p per table • Modified load to allow 100% errors

  46. Merge Prep (continued) • Similar to offload/reload • Semaphore set when dump complete indicating one of the multiple load scripts now has work to do • Split dump into multiple bulk scripts • Low volume tables • Separate scripts for large tables

  47. The Merge • Down, backup the combined database, Restart • Password assigned • Invoke the process • Multiple load scripts waiting for work • Invoke individual dumps and the bulk dumps • Strips off QAD and QADRSRV Domains • (Ran up to 17 wide)

  48. The Merge (continued) • Final ERP Validation • EDI Updates • QxTendUpdates • Password Removed

  49. Agenda • FNST Introduction; Who are we? • Business Challenges • Current Environment • Process • Realized Benefits • Lessons Learned • Q&A

  50. Realized Benefits • Reduce Support Costs • Eliminate several aging HP servers • Reduction in service tickets related to hardware • Reduce the number of databases being maintained • Reduction in off-site storage fees • User Acceptance of .NET has been limited • Roughly 10% of users are full-time .NET users • Mainly Finance; some Supply Chain • Split one eB2 database into two 2010 SE Domains • Separate locations; previously shared parts & production • Separate businesses that wanted to have separate data

More Related