A couple of months ago, SI ran a short series on Why You Should Not Build Your Own e-Sourcing System, which also included pieces on Why You Should Not Build Your Own Spend Analysis, Why You Should Not Build Your Own e-Negotiation Platform, and
Why You Should Not Build Your Own Decision Optimization because he heard that a few public sector organizations have this crazy idea that they can build their own and that it can, somehow, compete with best-of-breed solutions on the market today. As per that series, this is not the case.

Neither is it the case that an organization should build its own C(L)M system, as per SI’s post last week on Why You Should Not Build Your Own Contract Management System. It seems that there are (at least) a few organizations that not only think they can (which is often true) but think they should (which is usually not a good idea). Unfortunately, it doesn’t stop there.

Since basic e-Negotiation and e-Procurement is a commodity, and there are even free and open source solutions for both still available on the net (like WhyAbe and archived versions of open source by Coupa and Bupros), some organizations and public sectors think they can roll their own and, believe it or not, do it cheaper and better than just acquiring a low-cost on-demand solution (which might even cost less than the resources the organization / public sector body would require to maintain their own software and hardware, not counting the dollars they would have to invest up front to roll their own). When it comes to B2B or B2C, building your own in this day and age is, well, ridiculous. With so many options to choose from, the chances of your organization not being able to find a cheap, easy solution that meets at least 80% of your needs, and 90% with a few minor process changes, is low. Not only are there no cost savings (which becomes clear when a full total cost of ownership is done, see this classic SI post on X), there’s no value generated by building your own solution. Inflation is coming back with a vengeance, GDP is slowed to a crawl in first world countries, and risks are multiplying faster than Fibonacci’s rabbits. Wasting money on anything with no risk of value generation is just not something 99.99% of companies can afford to do.

While most P2P functionality is straight forward, and the cycle, which has more steps than pre-contract Sourcing, is simpler as it is more tactical in nature, a few requirements, while simple in theory, are actually quite complex to implement technically. In particular, the following three functions are quite demanding to implement technically.

Requisition Management

While the process of managing an approved requisition is no more complicated than managing any other e-Document, the process of approving a requisition can be quite complicated as it could require one or more approvers in one or more departments with the rules for determining who approves dependent upon the item, it’s category, it’s dollar value, it’s (un)approved status, the overall amount of the requisition, and whether or not any affected budget for the buyer, category, or department would be exceeded if the requisition was approved. The approval chain could actually consist of multiple approval chains that need to be executed in parallel, which can possibly be overruled by the last approver in the sub-chain or the entire chain (if it had to get final approval from a VP or CXO because of the amount), and which might need to be approved all-or-nothing for the requisition to help the requisitioner. This implies the need for powerful, configurable, and flexible workflow management that is rather time-consuming and sometimes tricky to implement and not always going to be available in an open source solution that you can easily integrate into a roll-your-own solution.

Purchase Order, Invoice, & Good Receipt Management

Not only do all of the these e-Documents have to be tracked, but they have to be cross-correlated in many-to-many-to-many relationships. For example, a purchase order may need to be split across multiple vendors, each of whom may ship the order in pieces due to geographic stock location and customer locations, and issue multiple invoices, and then the shipments might arrive in pieces, requiring each invoice to be associated with multiple good receipts, or which might arrive in unison, require one goods receipt to be associated with multiple invoices. Similarly, a shipment might arrive before an invoice, requiring goods receipts to be associated with one or more purchase orders. There’s a lot of cross-correlation logic here. Plus, documents can come in as XML, EDI, CSV, PDF (which need to be processed using OCR), or platform specific formats – so there is a lot of pre-processing that needs to be done as well. And then an m-way match has to occur against each line, because, otherwise, the platform is not very useful.

e-Payments & Tax Reclamation

These days, an organization that wants to go e-Payment has to support ACH and wires, and do very difficult secure integrations into a bank; Paypal, Stripe, and similar online platforms for small businesses; and credit cards so its employees can use their P-cards, and integrate into a credit card processor. It’s a lot of integration work that has to be done precisely, because if anything is not done up to Bank, Paypal, or CC Processor spec, and it gets hacked, it will be on the hook for all of the fraudulent payments that will result. And that can add up to hundreds or thousands or millions of dollars very quickly. Very, very quickly. This is one example of just because you can, it does not mean you should.

You’re not buying running shoes here. Just don’t do it.