Accelerating and Improving an In-Flight Implementation

Project Summary

As part of a business transformation initiative, a Fortune 500 steel company made the decision to migrate one half of their business, 11 divisions, onto a common EBS 12.1 solution. Most data for the divisions resided in a common legacy solution; however, many additional, disparate systems were used by each division for purchasing, Enterprise Asset Maintenance (EAM), and Manufacturing Execution System (MES).

After bringing on a System Integrator (SI) for the project, the team spent a little over a year designing and configuring the new solution, developing data conversion programs, and going through test cycles in preparation for the go live of their first division. After a year and a half, the first division successfully went live, but it was a struggle. The following year, Premier met with one of the SI team members at Oracle Open World and discussed this project at length. The organization had plans to go live with the remaining 10 divisions within 20 months, meaning they would need to scale from conversion of one division at a time, all the way up to 6 at a time! Having seen the struggles the internal data conversion team had with just one division, the SI knew they needed help. A few weeks later, an introduction was set up to see how Premier could provide value as a strategic partner tackling the data migration challenges. After introductions, a few preliminary discussions, and an onsite meeting regarding current data concerns and Premier’s capabilities, Premier was engaged to conduct a proof of concept.

“Premier has done WONDERS for our data conversion process and really helped us work ahead and shorten the length of our data conversion.”

– Client Data Lead

Proof of Concept

Based on the preliminary meetings and conversations, Premier was under the impression that data was not able to be converted – at all. We assumed they had unsuccessful test cycles because they could not get master data loaded in EBS in early cycles, as frequently seen on other engagements. This was not exactly the case. Outside of some mistakes that were made in the early going, they had a level of success much higher than typically seen with other clients. Customer and supplier conversions would achieve >95% successful data loads. They had a robust master item conversion process. Overall, the master data conversions required an immense amount of man power and manual input, but they did work.

The main area of focus for the POC was customers. To showcase our abilities, Premier designed reports to bring attention to the vast amount of duplicate customer data already in EBS and show how this could impact the business. Reports were designed to show customers with too high of credit limits due to having multiple accounts, inaccurate roll up of credit limits, and other varying data quality issues. The team was impressed by what Premier accomplished in only a few days and certainly intrigued by the idea of Premier putting its talents on full display by taking over all the data conversion responsibility. It was time to get to work.

Learning the Process

Premier quickly realized the extent of labor and hours that went into each of the master conversions. To prevent further customer duplication in EBS, each customer data load required manual creation of cross references to existing accounts, cleanup of addresses on both legacy and EBS sides, and consolidation of legacy site uses. Much like on the customer side, supplier data cleanup required a fully dedicated resource cleaning up data both in legacy and EBS. These processes were both long and drawn out, but both paled in comparison to the item master conversion. This conversion required about three weeks of lead time. All conversion eligible items had to be added to a spreadsheet, so the subject matter experts could research, review, and populate the attributes before the conversion process. Each one of these steps was completely manual; there was no way they could scale this to six concurrent divisions, as required by their project plan.

All that said, the manual processes associated with data conversion were not their greatest pain point. The data validation process needed a complete overhaul. For each conversion cycle, data was loaded into two instances. The first was what was referred to as a conversion (lower) instance, the second being the actual test (higher) instance. Our initial assumption was that the conversion instance was strictly a technical test instance, and the test instance was the only place the data would be validated by the division. This was not the case.

Each data set needed to be loaded in the lower instance, internally validated (deployment team resource), and division validated. After that was completed, it would be loaded in the higher instance, internally validated, and division validated. Downstream conversions were not even considered until the predecessor was division validated in the instance. Getting through all data conversion leading up to a test cycle was taking well over a month, and even then, they still were not getting through all conversions. During the first cutover we witnessed (but were not involved with), the client was converting formulas, the first dependency after org item assignment, all the way from Saturday night into Sunday morning.

Further complicating data validation was that the documentation of how data was extracted, mapped, and transformed as part of the conversion process was non-existent, out of date, or difficult to read. Each data conversion was assigned to a single developer. Therefore, that developer was the only person who knew exactly how data was being extracted, mapped, and transformed between the legacy and target system. The only way for someone at the division to know why data was converted a certain way was to get in touch with that developer. Data conversion was a black box.

In addition, because different developers worked on different conversions, they struggled with downstream conversions. Different developers would use their own version of legacy to EBS cross references, some would manually update them, some created live views, and some never updated them at all. This caused all sorts of disconnect and made it impossible to trace back issues. Even after the first two cutovers, they never were able to complete the full stream of item conversions.

“I used to be up all night trying to solve the issues for my conversion on Go-Live weekend, now Premier just clicks a button.”

– Client Data Conversion Developer

‍

Moreover, even if they cleared every hurdle leading up to cutover weekend, they still had the daunting task of entering thousands of open purchase order and open sales order lines, because there was no automated conversion process in place. As a result, the division had to shift away from validation of the oft-troubled item related data sets to ensure all orders were entered by Monday morning.

‍

How We Could Help Right Away

By the time Premier was fully engaged, the UAT data conversion for the first division was underway; therefore, it was too late to take on any of the data conversion responsibilities. Premier’s priority was designing reports to simplify and speed the post-load validation process, allowing them to free up some of their resources leading up to and on cutover weekend. The first way Premier did this was through comparison reports. These reports would allow the deployment team and the division to compare data between the lower and higher instance. If the data was the same between both instances, and they already validated in the lower instance, they could move on. If there were differences, they would just need to understand the differences, and confirm whether they were expected.

Premier also developed several master data reconciliation reports to help track changes that needed to be made through the dual maintenance period. These reports compared the data loaded to EBS against the legacy production environment. These reports not only identified dual maintenance issues, but clearly outlined integrity issues across the existing conversion processes. The information gained from these reports allowed our client to resolve significant data issues before they turned into product manufacturing issues.

After the first go live, the focus shifted to development of data conversion programs. By consolidating the data conversion activities within one cohesive team and working in a single development environment, Premier could ensure consistency between data conversions dependent on one another. For example, rather than each resource creating their own unique mapping, Premier established a single cross reference to map legacy part codes to EBS items that could be referenced by all conversions. By the time the third and fourth divisions were beginning data conversion, Premier had taken on most of the conversion responsibility. The client saw immediate progress in the quality and efficiency in the data migration process. The next challenge was to automate the conversion of open purchase orders and open sales orders.

Premier was told time and time again by subject matter experts that automation of open purchase orders and open sales orders would not be possible. They felt they had too unique of a situation and that it was lower risk to enter every open line in EBS over cutover weekend. However, Premier was able to convince the PMO that it was in their best interest to explore an automated solution, with the understanding that a certain fall out of orders would be expected.

‍

Because the SI did not have the bandwidth for development, and because they did not want to take on the risk, Premier worked directly with the client’s internal SOA team to build these programs. Initial design, data mapping, and most importantly functional process review with stakeholders at all levels of the organization took a few months. But after thorough testing through SIT and UAT, automated transactional conversions were ready to use for next cutover. Suddenly, open sales order data conversion time went from 48 consecutive hours of stressful, error prone manual entry by a team to about 30 minutes. It was a huge win for all parties.

Long Term

By the time the fourth wave of divisions started up, all data conversion activities were being executed in one common environment. Premier’s processes had been refined and streamlined for maximum efficiency.

Conversions within each process area flowed smoothly between Premier’s team members. Premier built robust, efficient processes to generate customer, supplier, and item cross references specific to any EBS instance that Premier was loading to. This prevented the issue of using the wrong cross reference and served as the backbone to all of Premier’s downstream conversions.

Premier had refined pre-validation checks to the point where migration results across the conversions were known prior to the load into EBS. This helped the team avoid the practice of passing data to a source table, needing someone to execute the load program, and then waiting to learn the results before seeing any data quality issues. Additionally, the pre-validation process allowed the division and deployment teams to preview the data and address issues across entire conversion streams without having to wait for a predecessor to finish loading. This in turn led to dramatically increased data quality and decreased conversion run times.

The Results and Future Plans

When Premier was brought onto the project, the client had 10+ resources dedicated to data conversion for a singular division. Within 9 months, Premier’s team of 4 was executing the data conversion work for 3, and, at one point, 6, concurrent divisions in less time then it previously took to get 1 division ready. The implementation of pre-validation led to a significant increase in both data quality and validation time. Automation of the open purchase order and open sales order conversions completely changed cutover weekends.

After 10 successful go-lives, the second half of the client’s business is embarking on a four-year transformation initiative that will combine and migrate approximately 15 legacy ERP systems into Oracle ERP Cloud. With a full understanding of the importance of data and the risk it poses to the implementation, the client is going to take this opportunity to adopt and improve data migration practices that couldn’t previously be done under their old process.

In the planning stages of this initiative, the client fully placed their trust in Premier. Premier was selected for the project before the System Integrator and was asked to present suggested process changes for this new line of business. Some of the key changes included simplifying the data mapping process, synergizing work between the data, division, and functional teams, and streamlining the data pre-validation process from nearly entirely post-load, to nearly entirely pre-load. The value of each of Premier’s recommendations was recognized and adopted into the project plan. Through the strength of our partnership and additional process improvements, we are anticipating that we will continue to accelerate data conversion timelines while improving data quality.