Social Procure-to-Pay (P2P)

I have been involved with business process analysis and design throughout my career, as a logistics and supply chain practitioner and as management consultant assisting clients with business transformation initiatives. More recently I have taken an interest in the adoption of social business collaboration (SBC) tools by businesses and other types of enterprises. In particular I am interested in the potential for changing business processes, practices and organizational structures to take advantage the opportunities created by SBC technologies.

The Procure-to-Pay (P2P) business process is one of the core end-to-end processes of almost every enterprise. As depicted below, the process usually begins with a requirement to procure goods or services and is completed with payment to the supplier. In many organizations this process is enabled by an Enterprise Resource Planning (ERP) system.

In a discrete manufacturing environment, where ERP systems were first deployed, the requirements are driven by a production schedule and determined by a bill of materials (BOM). The process is repetitive and often highly automated. In most cases, with perhaps the exception of approval workflow and exception management processes, there is restricted scope for social collaboration. The opportunities for social collaboration are upstream in the master data management, product lifecycle management and supplier relationship management processes.

However in most organizations the P2P process also supports procurement scenarios that are not repetitive and the requirements are not as clearly defined. In these cases there are real opportunities to change the way that work is done to exploit the capabilities of SBC tools.

For example if I have a need that could be satisfied by a range of different products then it would be useful to publish a description of my need to my social network, soliciting comments on the “best tool for the job”. This approach, often called crowdsourcing, is common practice in personal social networks, but current ERP solutions cannot easily support it. The ERP assumes that the requestor knows exactly what they want when they create the purchase requisition. In addition, if I share my needs with the network there will be situations when my needs can be met from existing unused inventories, much of which is not visible to the ERP system once it has been financially expensed.

These are but two examples of how the existing P2P process can be changed to take advantage of the capabilities of SBC tools. There are many more opportunities in this and other ERP business processes.

Today’s ERP systems carry with them the legacy of their past – their logical model of the business process is based upon the documents that manually flowed from function to function in the days before automation. The purchase requisition form feeds the purchase order, which in turn is acted upon to recognize the goods receipt. The supplier’s invoice is matched with the purchase order and the goods receipt document before payment is made. Each of these electronic documents existed as a paper document prior to ERP systems. In some cases the paper documents are still produced and filed.

In contrast, and in recognition of how knowledge work is done, the emerging SBC tools are people centric, not document centric. It will be interesting to see how the ERP software vendors choose to integrate SBC tools into their offerings. Can they bridge the people and document centric divides successfully?

Let me know what you think about the prospects for “Social Procure-to-Pay”.