Are you planning to invest in a procurement or procure to pay system?

Then the procurement system integration considerations should be on top of your requirements list along with other functional and critical requirements like the ease of use. We agree that it is the responsibility of IT to help with integration but Procurement should be the one thinking about these use cases [You might disagree with us, feel free to leave a comment].

Procurement or purchasing systems need to be integrated with back-end ERP systems to ensure that the transactions are available for further processing in the ERP system.

Here for procurement system, we are referring to purchasing, e-procurement or procure to pay system and not a system like e-sourcing and spend analysis.

We haven’t seen a single case where the procurement system is not integrated with a backend ERP system. We are using ERP terms loosely and it also means any accounting system you might be using.

Generally, integration is left to the IT team to evaluate and there is nothing wrong with that. But if you are a small company, the likelihood is that your IT Team is overloaded and might not have time to look into this.

We have seen this consistently across our target customers, they are generally running very lean on the IT side and integration doesn’t get the right attention till it is too late.

This is not a rant but a call for procurement professionals to give equal importance to defining integration requirements as they would give to defining feature requirements during evaluation of a purchasing system.

Defining requirements for integrating require procurement team to have an understanding of the different use cases for integration. We are not asking you to be an IT expert but understand the integration requirements to support the business process and the resources required to support integrations going forward.

Why Are We Discussing Procurement System Integration?

Procurement system integration with ERP or other accounting systems needs attention due to the following reasons

Cost And Complexity

In today’s day and age of cloud computing, it is not difficult to integrate any system on the cloud. Yes, it is easy if you are integrating with other cloud systems. For example, If you are integrating your system with another cloud platform like Salesforce.com, it is very easy, cost-effective and needs less ongoing maintenance.

We are sorry to break the news, but we can say with 99% certainty that you probably have to integrate your new purchasing system with an old ERP or a homegrown accounting system.

The less standard the system, the higher the cost and complexity for integrating with your system. In this case, you probably have to have a third system which is helping you bridge the gap between your new cloud-based purchasing system and your accounting system.

So the more integration touchpoints, the higher the cost and higher the complexity.

Keeping it simple makes a lot of sense here, hence the need to evaluate different integration touchpoints you might need and whether each one of them is really required.

Ongoing Management

Integration is not a one-time activity, it needs to be maintained on an ongoing basis. So who will be responsible for managing it?

Is it your internal IT team, or the vendor?

Depending on the integration method you have chosen and a number of integration touchpoints, the need for ongoing maintenance could be very little effort or a continuous effort for monitoring and enhancing it.

So while designing your requirements, keep in mind the need for ongoing maintenance.

Middleware Consideration For Purchasing System Integration

It is important to understand what middleware would be used to integrate the cloud-based procurement system and your ERP system.

The reason we mentioned the cloud-based system is that most of the vendors offer cloud-based solutions. There are still some vendors who offer on-premise solutions but if you already have a lean IT team, then the last thing you want is to burden them with yet another system to manage.

Of Course, there are additional hardware requirements which increase cost.

There are multiple cloud-based middleware solutions which are available in the market and that save some effort for ongoing maintenance,

But you still need to define the business logic for moving the data from one system to another.

Keep the use cases limited to keep cost and complexity low

Before we get into a discussion on the different integration touchpoints, make sure you have your IT counterpart involved in this discussion. As procurement wants to be involved early in the RFP process, IT wants to involved early in the design process so that there is no surprise for them.

Different Type Of Integrations Use Cases For Procurement Systems

We strongly recommend that you do this exercise along with your IT team so that they can guide you with the feasibility of each of these scenarios.

If that is not feasible then have it documented and send it to your team for further analysis.

We are going to divide integration use cases into three main areas

1. Master Data

Master data is the core data or core business objects, Examples include supplier data, customer data, budget data.

Master data is generally maintained in the ERP/ Accounting system and is required to be used in the transactions of the procure to pay system.

The other way to think about master data is the data which is not created in the procure to pay or purchasing system but required for it to work.

2. Transaction Data

Transaction data is the individual transactions which are created in the purchasing systems. Examples are requisitions, approval requests, orders, and invoices. This is not a comprehensive list but you get the idea.

3. Feeder Systems

We created a separate category for systems which are feeding other purchasing transaction data to your purchasing system. These are not master data but other systems which are feeding data to the purchasing system.

For example, It is very common for services companies to have separate work orders systems which are used by engineering teams. There is often the requirement to order materials as a part of the work order.

In that case, the order requirement or requisition is created in another system and then the same requisition is transferred to the purchasing system for approval and generating the purchase order.

4. Information Distribution

Companies who have a central data warehouse for management reporting would require the different data to be sent to a single data warehouse so that required reports can be created.

The requirement is generally defined as periodic data export in a CSV format.

Defining Requirements For Each Type Of Integration

Now we have identified different types of use cases, let’s get into more details for each one of them.

Create an excel sheet with the following details

Integration use case type

This would the type, for example – Master data, transaction data

Description

Describe what data we are talking about, for example, supplier record.

Frequency of change

How often does the data change, hourly, daily, weekly, monthly?  This would define the criticality of the integration and whether the integration needs to be batched or integration needs to be real time.

Source system

This is the system which originates the data to be integrated.

Target system

This is the destination system to which data needs to be transferred.

What if we don’t integrate

This is where you define the scenario where the transaction data or master data is not integrated with your procure to pay system. In that case,  you are looking at options on how to manage the data synchronization without integrating the systems.

Priority

The reason you assign priority is that you can decide which integrations to pick up first. Also, in the case where you have budget or time constraints, you can decide which integration use cases to focus on.

Once you have the structure ready, populate with different types of master data and the detailed information for each type of data.

Following is a simple example of how it would look once completed. Please note that this is just an example, but you would need to change this based on your specific scenarios.

Integration use case: Master data

Name:  Supplier master

Description: Supplier master data including supplier details like name, address, payment terms etc.

Change frequency: Daily

Source system: Your accounting/ERP system

Target system: ProcureDesk

What if we don’t integrate: The data needs to be manually updated and based on the number of changes it could require additional manpower.
However, if the changes are minimal then we can manually update the records in both systems.

Priority: High

For example, here is a good list of different use cases across various categories.  We have listed a lot of use cases here, so don’t get scared. The idea is to list whatever is applicable to you.

If 50% of these cases don’t apply to you then that is even better. The fewer integration cases, the simpler the integration and fewer resources required to maintain it.

By the time you are done completing the template, it should look something like this

If you would like to use this template, you can download the e-procurement integration use cases template.

Methods For Integration Procurement Systems With ERP/Accounting Systems

We don’t want to get all technical on you now but the next step is how you plan to integrate each of these use cases.

Your IT team should be able to decide the method of integration between systems based on the frequency.

Here is a simple explanation of the two main type of integrations

File-based

As the name suggests, the integration is managed by exchanged data via files across both systems. The data is generally processed in a batch based on a defined frequency.

Where to use it

1. For data which doesn’t need to be available immediately.

2. For large data sets like catalogs etc.

Pros

1. It is easy to implement as most systems have the ability to upload data via files.

2. If the capability doesn’t exist, it is fairly easy to develop a routine to read a file and upload the data in the system.

3. It is less expensive than real-time integration because you need minimal infrastructure to support this type of requirement.

Cons

1. It is not real time so users usually have to wait, in most cases the next day for the data to be available.

2. Since the information is not real time, it needs to be continuously monitored to ensure that all records are being processed.

Real-time

Real-time integration enables systems to talk to each other in real time and exchange information or data to enable business processes.

Where to use it

Real-time integration is useful or preferred for scenarios where you need to provide immediate feedback to the user.

The other scenario where this is very helpful is where you need data in another system for the process to be completed.

Pros

1. It enables faster business processes because there is no delay in exchanging information. For example, You need PO in your ERP system for further processing

2. Users can get immediate feedback in case there is a problem with the data as compared to file-based where users have to wait till a fixed time to see if there were issues with the data.

3. Since the users are getting real-time feedback, it is easier to correct data and ensure that the transaction is completed.

Cons

1. It is expensive to implement if the standard web services are not available.

2. It needs additional infrastructure to support integration. Especially when you are connecting a cloud-based system to a system behind the firewall.

Prioritizing Your Integration Use Cases

Now you know the pros and cons of different types of integration, the next step is to identify a preferred integration method for each of integration use cases.

Remember the integration use cases from the previous exercise where we identified individual use cases.

Now we need to mark a preferred integration method for each one of these cases.

The three options are

1. File-based
2. Manual – data to be synced manually. In this case, you need to identify which team would be responsible for ensuring that data remain in synch across different systems.
3. Real-time

After the exercise, you should see a table like this

If you would like to use this template, you can download the e-procurement integration use cases template.

What To Do With This Information

So you must be wondering where do I use this information?

There are two ways to use this information

a) During the RFP

If you are doing this exercise before the RFP, then include this in your RFP.  

b) After the RFP

If the RFP is already out and you have already shortlisted the vendors, then use this for reviewing integration requirements with your shortlisted vendors.

It serves two purpose

Accurate cost estimates

If the vendor is responsible for building the infrastructure to support your integration requirements, then this helps them to better gauge the effort and provide a more accurate quote.

Nobody likes surprises especially when it impacts the cost on each side. This can help you achieve accurate forecasts and avoid any issues later.

Keep in mind, it is not just about cost. It also leads to a delay in launching the system.

Clear role and responsibilities

Defining clear requirements and discussing this with your vendors and IT team enables both teams to come up with a better understanding of what is required for them to have a successful implementation.

For example – The vendor has agreed to build the integration infrastructure at a fixed cost but your IT team needs to ensure that web services for required processes are available.

If any internal development effort is required, then this exercise allows your IT team to clearly define the requirements.

Conclusion

Being able to have a reliable integration between procurement system and your ERP/Accounting system is very critical to ensure the success of your procurement tool.

Having an integration checklist helps in you in many ways

–  It helps you to prioritize your requirements and focus on things which are critical to the day to day operations.

– You can avoid any surprises during the implementation.

– Having well-defined procurement system integration requirements helps you to clearly define the timelines for implementation.

We hope this would help you to make your procurement implementation a huge success.

Good luck!

Want to know how ProcureDesk can support your integration requirements? Register for a free demo.