Objectives
Our clients often find that it can be tricky complying with parent company or head office reporting requirements. This is particularly so when their ERP is different to others in use. We tend to see clients initially believe that it will be more cost effective to have someone manually piece the reporting data together rather than automating it. This is always proven to be a false economy!
Different clients have different budgets and their reporting requirements can also be pretty distinctive. We have two clients who both needed to get reportable data into Adaptive Workday. The first had no budget constraints, but they were on a very old version of their ERP; while the second had budget limitations impacting their choices. Our third client needed to get their data into Snowflake, which was a much bigger project. Their project was influenced and controlled by their overseas Head Office.
Read on below for the different methods we used to meet each of their requirements.
Solution Delivery
Client A – Old ERP, high volume transactional data, report building expertise in the business
Client A was a well-established ANZ business. They’d recently been acquired by a multi-national group headquartered in France. Their ERP software version was over ten years old and they did their reporting through a version of Cognos. Their new Parent wanted the monthly reporting data in Adaptive Insights (as it was called at the time). They also wanted access to transactional data (as needed).
Issues
- The parent company wanted transactional data, and they wanted it frequently.
- They were on a version of their ERP that was over five years old and did not have any API capabilities, or secure methods of data extraction. They didn’t have the option of upgrading their ERP – the project would take up to a year.
- They had lost a lot of their technical expertise post-sale, specifically anyone who was able to marry the requirements of ERP, network security and parent company.
- Their ERP vendor was keen to help, but very specifically was only concerned about the ERP needs. Their initial preferred option was an ERP upgrade, which would give Client A advanced data connectivity capabilities.
Actions Taken
- We looked at options available for connecting to Adaptive Insights and one was through a JDBC connector.
- The ERP currently had an ODBC connection available, so we talked to the vendor about whether it was possible to install a JDBC connector. While it was (and is) old technology, it was the best option at the time.
- The JDBC connector was available, but it required a minor ERP operating system upgrade.
- We coordinated the operating system upgrade with our client and then the installation of the JDBC connector.
- We tested the connectivity over to the client and they started building their extracts.
Client B – Low volume transactional data, small budget
Client B is also a well-established ANZ business, which had recently been sold to a multi-national company with an overseas head office. The new parent was content to let Client B run the business and only required finalised monthly results in Adaptive. The data required was both financial and operational. Client B did not have a large amount of money to spend on this work.
Issues
- Low level of technical expertise in the business (external IT providers in use).
- Budget was tight and needed to include work of the Adaptive vendor to build the reports
- The Adaptive vendor was keen to build a real-time, API-based, transactional integration between the ERP and Adaptive
Actions Taken
- We immediately pulled back the scope of the project, knowing that a real-time, API based, transactional integration would not fit within the available budget. We confirmed the parent company requirements with our client and knowing that data was only required after the month end results had been finalised, we simplified the integration requirements.
- We checked whether the Adaptive vendor could use other integration options. Luckily, they could accept an Excel file. This was manageable for our client, as this process would only occur once a month.,
- Knowing that the Excel files were a lot simpler to create, where we could we used tools in the ERP designed to create Excel exports.
- While we could do this for the financial data, the operational data requirements were a little more complicated. We got our client to clarify the data they needed, then custom-built two extracts to meet the operational data requirements.
- We built the extracts relatively quickly, and did some tweaking around requirements. The data was then available to the Adaptive vendor so that they could build the required reports.
Client C – High volume transactional data, large budget, demanding Head Office
Client C is a very high volume sales business. Their European Head Office had recently rolled out Snowflake for their global reporting and Australia/New Zealand were last on the list
Issues
- Our client did not use the same ERP as other companies in the Group. It was subject to restrictions on access to data, which the European Head Office build team did not understand and found very frustrating.
- The European Head Office team wanted to directly interrogate the ERP data, like they had done elsewhere. They didn’t understand relationships between data structures in the ERP, or how to extract the data they needed. Initially they weren’t keen on getting help.
- The ANZ CIO was keen to ensure the integrity of the data, so wanted a solution which made data available to the Head Office Snowflake team, without them directly accessing it.
- Client C’s ERP was running on an aging, space-maxed, internally hosted server. This meant that the load that these processes would add to the server processors had to be balanced carefully.
Actions Taken
- The ANZ CIO knew that we had built a low-cost piece of Middleware, an API integrator, that could be hosted within their network and managed by them. He decided the best option was to get us to build ERP extracts and send the collated/harmonised data to the middleware. Snowflake could then access the data from the middleware, through the middleware sending API-based updates.
- The European Build Team did not want to deviate from their current methods, and wanted real-time transactional data. This was not possible due to the ERP server issues.
- The European Build Team eventually agreed that we would also on-send the data packets from the Middleware to Snowflake, using the available APIs. They agreed this could happen once a day. This somewhat mitigated the ERP server processor issues.
- We documented the technical specifications for all the ERP to Middleware packets, as well as Middleware to Snowflake. Once this was complete, and agreed on by all parties, we commenced the build.
- Tweaks to the data occurred as/when checks on quantities and values occurred during testing
Achievements
- Integrations or data extracts don’t need to be all or nothing, or very expensive. Like all technology problems, it comes down to understanding requirements and budget, and then finding the right tools and methods to solve the problems.
- Each of these clients had the same need – a parent company wanting access to their data. However, each had scope to meet needs in a way that fit budget and requirements. Client B’s simplified Excel process could only work as their parent only needed data periodically. Client A could have possibly used methods similar to Client C, provided they had been on a more recent version of the ERP.
- Ultimately, we were able to meet the brief and each of these clients had a way to automate providing data to their global parents.
If you’d like to learn more about this project or talk to us, click here for our contact details.