ERP Project Recovery

ERP Project Recovery

When They Need Help With ERP Project Recovery?

 

The adoption rate is low among users? Inventory and allocation issues? ERP is primarily configured as an IT system, and business users can’t connect with it? KANO ERP project recovery expertise is designed to help companies when they struggle with these challenges.

ERP Is Primarily An IT System

Do business teams rely on IT to get data from the system? Are business teams afraid of using the system? Is the adoption rate low among the users? Companies seek help from KANO when they need help in selecting an ERP.

Significant Issues Post Go-Live

Was your go-live premature? Did you have significant disruptions post-go live? Does your system feel slow? Companies seek help from KANO when they need help in selecting an ERP.

Unable To Go-Live

Are you not comfortable going live as you feel that the system might not work for the business? Are your issues stopping you from go-live? Companies seek help from KANO when they might not be able to go live.

Inventory And Allocation Issues

Do you have significant allocation issues with the system? Are you not able to allocate the inventory in the system? Are you reconciling inventory using journal entries? Companies seek help from KANO when they have significant inventory and allocation issues.

Feels Like A Transactional System

Does your ERP feel like a transactional system? Are you able to process the transactions but not able to analyze or plan? Do you not get the insights that you expect from the ERP? Companies seek help from KANO when their system feels like a transactional system.

System Highly Customized

Do you need to customize your system all the time to accommodate even simple scenarios? Do your ERP screens look completely different from another instance that you may have seen of this product? Companies seek help from KANO when they need help in recovering a highly customized system.

OUR METHOD

Our Methodology For ERP Project Recovery

The process starts with an assessment that helps build the as-is and to-be process models, along with the enterprise architecture. The assessment will find processes and data sets that might need to be redefined or re-engineered to remove the over-bloating of the system. Once agreed on the to-be state of the system, the changes are then implemented and deployed.

Step 1: Assessment

This phase starts with a deep diagnosis of the current issues, including the diagramming as-is and to-be states of the processes and enterprise architecture. This phase would come up with a few solutions with their pros and cons that can be explored further as the potential options to recover the project.

Step 2: Business Analysis

This phase takes a deep dive into the option identified and builds the change journey for each persona impacted. This phase also explores the associated financial risks and identifiers a back up plan for each financial risk.

Step 3: Technical Analysis

The phase is a very detailed design of the solution identified in the previous step. This step documents the interfaces and data mappings if there are going to be any technical changes.

Step 4: Implementation

This phase implements and tests the changes required to recover the project. Sometimes the recovery could mean reimplementing the whole project. But the total time taken for re-implementation may not be as high as your data is already translated and exists in the right format.

Step 5: Optimization

This phase is the optimization phase if there might still be room for improvement after making those changes. Or if the suggested changes don’t work as expected. Then the next step would be to explore the other options.

en_USEnglish