Traditional ERP systems have become expensive due to high upfront capital costs, ongoing maintenance fees, and customization and upgrade costs. ERP coupled with the cloud can help do away with some of those issues. It’s convenient to access over the Web and, contrary to common wisdom, has the same level of security and flexibility compared to traditional on-premises deployment.
The lifecycle of putting JD Edwards in the cloud – or any ERP applications – includes four major steps: initialization, implementation, go-live, and stabilization and product support.
You must understand the contract and scope for hosting applications and services before you start your cloud project. That means preparing and agreeing upon the roles and responsibilities for the hosting partner, the ERP implementer and the client. In JD Edwards that means understanding roles for configurable network computing, operating system support and printing requirements.
As the customer, you (and not the hosting partner) should buy the licenses, although this may vary depending on the contract. Putting JD Edwards in the cloud may mean needing some third-party software there as well. That must be accounted for.
Hardware sizing is important, and should be based on the number of servers, users, and transactions. The hosting partner should do this analysis. You should also decide on the number of developer clients, depending on the scope of your project. The ERP implementers should create a testing strategy for the entire project and decide on the number of instances and environments required. In the case of JD Edwards, if you plan to use large codes for advanced pricing or job-costing, it can have an impact on hardware configuration.
Finally, don’t forget about network connections, which need to be managed. Special routers or VPN devices need to be confirmed with your hosting provider ahead of time to prevent project delays.
For implementation of your ERP project in the cloud to go smoothly, your hosting or ERP provider should make a joint project plan or, at the very least, share their own with the other. For example, the instance release plan from your hosting provider must jibe with the conference room pilot and user acceptance testing plan from your ERP provider.
Governance is crucial for managing multiple teams – your own internal team and those of the hoster and ERP vendor. There must be agreed-upon procedures for addressing service requests, evaluating and mitigating risks, and communication in general.
More on Oracle JD Edwards
Take a look at JD Edwards mobile applications
Read about how third-party JD Edwards support has benefits and drawbacks
Depending on the project, certain expertise might not be available from the hosting or ERP provider. That means your own internal IT team will have to handle it. A good example is skills to address data security requirements.
You should also develop a CEMLI framework, where CEMLI stands for configuration/customization, extension, modification, localization and integration. The JD Edwards recommended process flow must be understood for any customization development, version-naming conventions and package-build process. Adhering to this framework ensures better performance of custom objects. For interfaces, you should work with your hosting partner to make sure that user IDs are matched with appropriate privileges.
Planning around refresh, backup and restore requirements are key. Assess the impact of security updates and patches beforehand. There should be an instance validation checklist for each instance release, as well as a document that lists lessons learned. Discuss the data migration requirements with your hosting and ERP partners, and check application performance during test cycles. The instance validation checklist for JD Edwards should include functional and technical items, and there should be performance tests for critical JD Edwards applications that mimic real business scenarios.
Cloud providers have different service levels for implementation and support. During implementation, timelines are generally strict, and any delay can severely impact the project. Hence, service levels must be studied and acceptable to the implementer and client’s team.
The production readiness should be assessed carefully and should include network checks, CEMLI adherence and a sign-off from the business. Review and address any project issues, and define the code-freeze date. A detailed cut-over plan should include production configuration, job scheduler set-up, confirmation of a working interface, and final data migration schedule.
It is essential to identify the risks for business critical processes. In order to minimize disruption to business, the disaster recovery plan must be prepared and ready to go live in the event of any unforeseen circumstances..
Stabilization and production support
Proper support procedures include a setup of the help desk and defining everyone’s role. Retaining the ERP implementer and the hosting partner teams through the first month after transition can help. Periodic data maintenance procedures should also be in place. Support teamsmust be aware of any changes to the ERP system in the cloud. Some of the data maintenance procedures for JD Edwards include creating user IDs, revising the char of accounts, updating user-defined codes, viewing tasks, and revising the approval matrix.
It is particularly important to make sure all end users are trained and have manuals to assist them. Other possible documentation could include integrity reports and documents around error handling. Super users should be familiar with the hosting partner’s support process.
Nukul Dinkar is a delivery manager in consulting and systems integration at Infosys. He has more than 17 years of experience in the IT industry with a focus on Oracle applications. Yogesh Punde is a senior project manager in consulting and systems integration at Infosys. He has more than 16 years of experience, which includes 10 years of experience in the ERP space.
This was first published in March 2012