Any garden variety DBA / technical team can deliver an accurate refresh of a non-production environment. But what about the folks downline? Have you ever thought of how your users use the non-production environment? Coming from a post-production support point of view, it often takes a couple of hours to set up data for a support issue before any testing even begins.

For instance, one thing that is super annoying is that we finally set up the test, and Create Accounting is run. Then you wait and wait. But nothing gets picked up. Well, it’s often because workflow or Cost Manager has stopped running. Damnit. Then you have to go back and find the originally scheduled request, remove that off hold, or cancel it altogether, in order to get it going again.

Or… in a previous client of mine, the mailer was never turned off for clones and refreshes, so in the new non-production environment, a test for a support issue would be run, and lo and behold 200 emails would fire off to real customers. Not good. Definitely a rookie error. I remember having to go down to a pissed-off customer service team, who would be immediately flooded with calls about purchases they didn’t make, or orders they didn’t create, and embarrassingly have to explain to them how this fiasco happened. Many a box of chocolates went to this initiative as damage control. ha ha…

I did a quick search on what is out there for information about best practices post-clone, or refresh of an ERP environment. All of which I found were best practices from a technical perspective. It didn’t appear that anyone stopped to consider what the outcome of the clone was, or the purpose of the post-clone target. This once again illuminates the gap between technical folks and functional folks. I didn’t find any hits considering HOW the non-production environment would be used AFTER the clone.

How can we get from Good to Great?

I sat down and started thinking about all the issues I encountered as a user of these non-production environments. Here are some best practices from a functional perspective that really ought to be considered during or after post-clone, or refresh, so you look like a superstar.

1. What is the backup that you are going to use to clone?

Often non-production environments are used to replicate support issues that are encountered during month end. Hence the backup used should be one that is closest to the end of the month. Having a backup that is midmonth, wouldn’t be the end of the world, but one taken closest to the end of the month would be much better.

2. Ensure that the backup of 3rd party systems integrated into your main ERP (ie. Oracle, SAP, IFS, or other) is also of the same date.

A really good way to confuse the heck out of your users is to have a backup of a 3rd party system from a different date. At the very least, if you have to select a different date, TELL your users what the dates are. Really, this is a winner. It might even score you a coffee, as your users would be pretty grateful. (Well, really, I think you’d have to do more than that to get a coffee.

3. Scramble all sensitive data.
In this day and age, it’s definitely a requirement to ensure that ALL, not just some… but all sensitive data be scrambled. There is just no excuse not to do so. I’ve been with some clients who scramble their salaries, and nothing else.


4. Ensure that the mailer is turned off!!!
Depending on what happens in the refresh steps, often emails are redirected to a fake email address. Then check a sampling of customers to ensure that the email is re-directed!!!

5. Ensure that automated processes Cost Managers and Workflows are again running. 
This pertains specifically to Oracle, but I’m positive that every ERP system… no, every information system out there involves scheduled jobs. While you might have the insight to check that the workflow background engine is running, the Cost Manager, or any other manager that is scheduled on some sort of frequency often gets missed.

6. Ensure that all scheduled concurrent requests are taken off hold.
‘Nuff said.

7. Open the current period in all modules.
The period needs to be open in each module individually. If you’re backup is just prior to
month’s end, this wouldn’t really be a consideration. But if you happen to clone from a backup that is just past the month-end, or during, modular periods may or may not be open depending on where in the month-end process the backup was taken. Here is where to open / close periods in each financials module in Oracle EBS:

8. Ensure all integrations are re-connected.
Chances are, EBS doesn’t stand alone. I’ve never seen an EBS environment in my 20+ years of consulting that hasn’t been integrated with a 3rd party system in some way, somehow.

9. Ensure that the integrated environments are also up and running.
This is a biggie. And also a rookie error if they aren’t. I’ve been on projects where it took two months for the integrated environments to be functional. Not cool. Very rookie. As a result, it added months, I’m talking months to complete the same work that should have been done in days, if not hours.

10. Have someone on the functional team do and end to end smoke test.
This is a smoke test though. It shouldn’t take any more than 15 minutes to prove all the integrations are alive and the lights are on. For example, in an Order to Cash environment, it could look like this:

1. Create a sales order via iStore, or Order Management.
2. Process it through Order Management and into Receivables.
3. Run integrations to 3rd party CRM (ie. Salesforce, or other)
4. Create Accounting, and Transfer to GL.
5. Post in GL.

Clones, refreshes, and post-clone tasks are technical in nature yes. But properly thinking through the purpose of the clone, and how the users would be using the clone is the X-factor, and what most technical folks fail to consider. This is what you can do to step it up a level. This is what would separate you from good to GREAT.

Happy Cloning!