Go-Live Cutover Planning and Conversion Strategy for Discrete Manufacturing Organization (Oracle Applications ERP)

Transcription

1 Go-Live Cutover Planning and Conversion Strategy for Discrete Manufacturing Organization (Oracle Applications ERP) Introduction: Effective Cutover Planning is very essential for successful Go-Live. Lack of effective planning and execution during this period may lead to severe reconciliation problems and transaction backlogs. Such problems often results in roll-back to legacy system or huge cost pile-up to clear the transaction backlog or reconcile the inaccurate conversion during Cutover period. Such issues can be prevented if good thought is given to plan the Cutover transition phase in a way that is least intrusive and in sync with physical situation of the organization. I've tried to explain some of the important considerations for effective Cutover planning in a discrete manufacturing organization and laid out a step-by-step approach towards the same. Though I've considered Oracle Application as the ERP platform but most of the steps are common to any standard off-the-shelf ERP system. The analysis here is restricted to Inventory and Discrete Manufacturing functions which are often the most complex functions to plan during Cutover due to large volume of data involved. Cutover Planning: Let us refer the following timeline for this case study (indicative dates used for illustration). Go-Live transition has been divided into 4 phases as follows: Production Down-time starts 29th Dec, Friday) End of Post Go-Live Syncup 7 th Jan, Monday A B C D Cutover preparation starts 15 th Dec Go-Live (1st Jan, Monday)

2 Phase A: "Cutover Preparation" This phase starts post UAT sign-off and goes until actual start date of Cutpver. There are several activities which need to be planned and executed before the actual Cutover period starts. Following is a list of steps that need to be executed within this phase. 1. Physical Counting and Stock Adjustments: To ensure accurate inventory migration to a new system at Go-Live it is essential to have accurate inventory figures in the legacy system first. Since Cutover period is usually very short to minimize the production down time, physical counting and stock adjustments in legacy system should be done in Cutover preparation phase. This should be done for all the stores including WIP stores/sub-inventories (if any) Though exact timing for this activity will vary from one organization to another but it should ideally be done as close to actual Cutover as possible to avoid any mismatch in inventory balances during the actual Cutover period. This activity will ensure that legacy system has correct inventory values (and likewise the inventory account balances) and the values recorded during Cutover can be relied upon for loading open balances to new system at Go-Live. This will prevent the users from a tedious activity of physical counting during Cutover period as legacy system has already been brought into sync. with physical stock very recently. 2. Cutover Production Planning: Production should be planned in a way that there is minimum number of open WIP jobs at the cut-over date. Lesser the no. of open jobs at cutover date, lesser would be the open WIP transactions and hence reconciliation would be lot easier and less time consuming. There are usually two production scenarios involved: i) Short Lead Time Assemblies: If the production lead times are short (as compared to the duration of Cutover preparation phase), it is recommended to complete the production of as much assemblies as possible before

3 Cutover. The objective must be to reach near zero WIP (ideally zero) i.e. to inventorize the assemblies and convert them as open stock instead of open jobs. ii) Long Lead Time Assemblies: If the production lead times are long (as compared to the duration of Cutover preparation phase) it might not always be possible to complete all open WIP jobs by cutover date. Under this scenario it is recommended that a judicious Job Cutover stage be decided for such jobs and communicated to shop-floor accordingly. It is very important to stick to this Job cutover schedule as open WIP data will be compiled based on this information and any deviations should be duly recorded in pre-specified template (conversion template for open WIP transactions). It usually becomes very difficult to assess the exact status of open jobs in a short Cutover period and that is the reason it should be a pre-planned activity with all deviations duly recorded. This process helps in quick compilation of the most complex WIP open data for conversion during Cutover phase. Further, It should be ensured that all associated sub-assembly jobs be completed and closed as far as possible before the cutover date. 3. Master data preparation: Master data should be collected and consolidated in pre-decided and well-tested (during SIT/UATs) data formats in this Cutover preparation phase. All master data elements created until this date should be collected and verified for correctness after due sanity checks. Master Data elements pertinent to Manufacturing area are: Item Master along-with Item Categories Departments, Resources and Resource-Department association Bills of Material Routing User defined costs (if any)

4 Since the volume of data involved in a typical Manufacturing organization is huge, getting this master data ready and validated beforehand goes a long-way in achieving smooth conversion. Any potential data issues are identified and resolved way earlier then actual Cutover period thus preventing critical situation in short Cutover period. 4. Configuration and Setups: All system configurations and setups (to be initiated post UAT sign-off) should be completed on Production instance in Cutover preparation stage itself to make the system ready for master data conversions. If possible responsibility matrix and user assignments should also be completed at this stage itself. The objective is to complete as much setup as possible leaving only the last minute setups for Cutover period. 5. Master Data Conversions: All master data collected in step Step # 2 should be migrated to Production instance in this phase to make this instance ready for open transactions data load during the next Cutover phase. Further there should be a process in place to identify the incremental master data records post this conversion and before go-live. It can be a SQL script for each of the master data elements where creation date is greater post this conversion date or there has to be a manual process for this brief duration i.e. whenever a new master data element is created post this date it must be recorded in a separate template as well which can be loaded again prior to Cutover phase start date. 6. Smoke Test: It is recommended to carry out a smoke test to identify any potential issues with Production Setups and overall configuration. Production instance should be cloned post execution of step Step # 5 & 6 to a testing environment where one complete manufacturing cycle can be executed to validate the core setups and master data definitions. It will help in early identification of issues (if any) which if not resolved timely may become show stoppers during Go-Live.

5 Phase B: "Cutover Period" Phase B represents the actual cutover period. No production activity should take place in this Cutover period until absolutely essential since it may lead to reconciliation problems which might be difficult to overcome during short span of Cutover. As per our illustration, it starts on 29 th December, Friday i.e. no production activity will take place between Friday morning and Monday morning. Following is a list of activities to be taken care of during this phase: 7. Incremental Master Data Load: Since bulk of Manufacturing master data is loaded in Cutover preparation phase itself, very few master data records (which have been added since the last load and duly captured as mentioned in Step # 5), would need to be migrated to Production instance during Cutover. Once incremental master data load is completed, it should be reconciled with total records in legacy system as per the pre-tested scripts to ensure that no record has been left out. 8. Incremental Production Setups: There might be few incremental production setups which might need to be done in addition to Step # 4 to make the Production instance ready for transactions e.g. Opening inventory periods. 9. Open Transaction Data Load: Once all remaining master data has been loaded and Production Setups are completed, immediate next step is open transactions loading. Following Open Data elements would need to be loaded for Discrete Manufacturing: Open Inventory Stock (including all inventory stores as well as WIP/shop-floor stores) Since physical stock was already reconciled in cutover preparation phase (Step # 1), no physical counting or adjustments are requiring during this short Cutover period. Please note that open inventory stock conversion should be carried along-with the cost: Average Unit Item Cost (Average Costing) or Standard Unit Item Costs (Standard Costing)

6 Open WIP conversion This conversion will be required in long lead time production scenario as mentioned in Step # 2: Following data elements would need to be converted in case open WIP jobs exist in Cutover: o Open Discrete Jobs: Standard / Non-Standard Discrete Jobs which are still under process during Cutover. o Open Move Transactions: Operation completion transactions which have already been booked against these open jobs. There are usually two options for converting move Transactions. (i) Automated - Convert move transactions through Oracle WIP Move Transactions interface (ii) Manual In this approach users need to perform the move transactions against open jobs manually once Open WIP jobs are converted. It depends upon the availability of time and manpower to choose one of the above approaches. o Open WIP Material Transactions: WIP Material (components) issue transactions (time charged) which have already been booked against these open jobs. There are usually three scenarios for converting WIP Material transactions. (i) Move Transaction linked: If charge type for material is either "Operation Pull" or "Assembly Pull", material will be charged automatically as move transactions are converted in above step or charged during job completion respectively. (ii) Through Interface - Convert WIP material transactions (for components with charge type as "Push") through Oracle WIP Transactions Interface (iii) Manual In this approach users need to perform the WIP material transactions (for components with charge type as "Manual") against open jobs manually to incur the material cost into job valuation. It depends upon the availability of time and manpower to choose one of the above approaches

7 Note: WIP Material conversion is very critical activity as it directly impacts the inventory - WIP valuation. All WIP components which are to be transacted after Job creation must first be converted as inventory stock in WIP stores (or respective sub-inventories which are mapped as supply subinventories in Oracle BOM) i.e. all material stock which has been consumed until Cutover for open jobs must be recorded in pre-specified formats and this stock should be converted as open inventory stock in respective stores as discussed above. o Open Resource Transactions: Resource issue transactions (time charged) which have already been booked against these open jobs. There are usually three scenarios for converting resource transactions. (i) Move Transaction linked: If charge type for resources is used as "WIP Move", resources will be charged automatically as move transactions are converted in above step. (ii) Through Interface - Convert resource transactions (for resources with charge type as "Manual") through Oracle Resource Transactions Interface (iii) Manual In this approach users need to perform the resource transactions (for resources with charge type as "Manual") against open jobs manually once Open WIP jobs are converted to incur the resource cost into job valuation. It depends upon the availability of time and manpower to choose one of the above approaches 10. Pre-Production Smoke Test: It is recommended to clone the Production instance once again (once all above steps are completed successfully) to testing environment to carry out pre-production cycle testing once before Go- Live. 11. Reconciliation: One last step which is most essential before Go-Live is Open Data Reconciliation. All open transaction data balances must exactly match with the balances from legacy system in terms of quantity as well as value. Following are some of the key reconciliation activities:

8 Open inventory stock balances: On-hand Quantity with inventory data compiled from legacy system, Inventory value with the Trial Balance (Material Valuation Account) in legacy system Open WIP balances: No. of Jobs, Material and resource quantities issued to jobs with open data compiled from legacy system; WIP valuation with WIP account balance in Trial Balance from Legacy system Note: Since this article focuses on Cutover Planning and Conversion strategy, I've not covered Reconciliation in detail. I might write a separate post to cover the detailed reconciliation steps involved. There will also be one short article on Account selection and its financial implications for Open Data Migration in Oracle (For Inventory and Manufacturing open data). 12. Go-Live: Once pre-production smoke test and Data reconciliation steps are completed successfully, new system can be pronounced Live and released to business for normal usage.

9 Phase C & D: "Post Go-Live Sync-up and Stabilization Phases" 13. Sync-up Activity: Although it is strongly recommended to shut down all operations during Cutover period but still there might be few transactions which have been carried out in the Cutover period due to their absolutely essential nature. Such transactions, if any, should have been recorded manually outside the system since legacy system is frozen as soon as Cutover phase is pronounced active. Users must enter these transactions manually in the system as soon as the new system goes live. This step is required only in exceptional scenarios and may not be required if everything goes as planned. 14. Demand Aggregation and Production Plan Runs: MDS is defined post go-live to capture all open demand. MDS Run fetches all open Sales Orders and Projects against which shipping is yet to be done and consolidates it into the chosen MDS plan. Master Production Schedule (MPS) and MRP (Material Requirement Planning) plans are then launched to get the supply plan to meet the open demand as recorded by MDS. All open orders are automatically netted as supply thus preventing any duplication. Note: "Net WIP Jobs" should be checked in Plan options. Subsequent plan runs can be scheduled as required by the business. 15. Data References for Business Users: Since business users are usually acquainted to legacy data definitions it often becomes difficult for them to correctly identify data elements in the initial phase after Go-Live due to probable changes in data structures or nomenclatures. This affects their operational efficiency and may lead to lags in transaction recording in new system. Thus, it is recommended to share ready data references to business users for normal functioning of business processes.

10 Hope you will find this analysis interesting; your suggestions and feedback are most welcome! Regards, Manu Singhal The Oracle Manufacturing Blog