Imagine an organization with a troubled history of procurement. Let’s think of it as a bank, but it could be anything large and complicated.
In this story, there are many different players.
First, there is the business. There are various trading desks focused on derivatives in different asset classes including asset-backed securitization, equity derivatives, mortgage-backed securities, corporate derivatives, and foreign exchange options. Each one of them is made up of hard chargers, individuals focused on performing at the highest level. They want to get paid; they want to get promoted. They do not have much patience for bureaucracy. It’s highly unlikely that one group works well with the other group, but they’re all important to the bank. Their work is very technology-dependent. Many of them have specialized expertise in technology. They are highly educated. It’s not uncommon to see PhDs on business cards.
Next, we have the technology group, all of which reports to the Chief Technology Officer. They are responsible for making sure that the line business gets what it needs and for ensuring that it stays up and running. This is not as simple as it sounds. It is a complex, interdependent system. They need to make sure that the various products they buy play well together. They’re responsible for guarding against cybersecurity threats. But they’re still at a bank and the traders rule the roost. If they worked at a pure play technology company, some of them might be senior power brokers within their organization, but here, they play a support role. It’s a vital position, but nevertheless, it’s secondary. The traders print the profits. Working in technology is a good job. They get to deal with leading-edge systems. It is challenging to make sure that everything fits together and keeps running. They’re constantly learning. But still. They’re not in the driver’s seat. And they’re very status conscious when it comes to anyone other than the line business.
There’s management. They hire the traders. They raise the capital and manage the bank’s compliance with various regulators. They keep the shareholders happy. Management needs to see over the horizon anticipating the kinds of business that might be exciting and relevant in the future. They must recruit the best and the brightest and keep them paid and fed, otherwise they’ll have staffing issues. It can be difficult managing the prima donnas. Heaven forfend they have employee turnover. The bank can have the best technology in the world, but if they don’t have the right people in the “front office” trading seats, it’s all for nought. And one reason traders leave for greener pastures is inadequate technology.
There are the risk management and control functions. These people enforce adherence to the rules so that the traders don’t blow the place up with bad trades, or worse. They measure risk, report it, and make recommendations as to how to optimize it. But it’s not just risk. There is financial reporting, too. There are controls in place to ensure that people cannot embezzle funds. Everyone remembers Dr. Copper from the mid-1990s, a trader at a Japanese bank who lost hundreds of millions of dollars by taking advantage of weak controls, poorly enforced.
There are other corporate functions such as legal to reinforce regulatory compliance. They manage the bank’s legal risk, whether it be its exposure to litigation with clients and other counterparties or its reputational risk from engaging in certain transactions. There is an investment bank with corporate clients, some of which are vendors to the bank as well.
And there is procurement. Whenever there is a large purchase, say for some new technology, the bank has a procurement department who ensures that there is a proper RFP, in addition to the rigorous testing the CTO must execute. It’s important to generate competition on price and solution so that they know and can prove to their stakeholders value-for-money.
Let’s add some more context here.
In the past, there have been problems coming out of the various trading desks when it comes to procurement. The first step is to generate a set of requirements. What is the problem that the trading desk seeks to solve? What must a solution be capable of doing?
Historically, the traders have tended to game the process in two possible ways.
First, in putting in a request for the funding to purchase a system, the traders have fudged the requirements. Instead of describing the problem they have and the things that any potential solution will have to do (or should be able to do), before putting pen to paper, the traders decided on the system they wanted to buy. Then, when they put together the requirements (and working with the salespeople from the company that makes the product they want to buy), they structure the requirements document to emphasize the things at which their desired solution is good and to ignore (or, at least) discount the things at which it is bad. They are so ham-fisted in their reverse engineering that the procurement people can see through it. Their description is so skewed that it limits the logical selection to just one vendor: their supplier of choice.
Second, since they are dealing with corporate money (and not funds that will affect their bonuses), they ask for more than what they need. So, in addition to distorting the description of their actual requirements, they embellish them so that they can purchase more bells and whistles for the vendor’s existing product or they can buy several additional products at the same time. If their real requirements were for a simple pen knife, they would ask for a Swiss Army Knife that had to be made in Switzerland and needed to have the Swiss cross with a red enamel handle. These traders get promoted and paid based on how well they do; they do not get paid based on the bank’s share price.
The procurement department is well aware of this problem. So they lobbied the Chief Financial Officer and the Chief Operating Officer to give them complete power over all procurements above some threshold of value, say $1m. The traders can make recommendations when it comes to the requirements, but the procurement department now sits in the driver’s seat. There is some input from the CTO’s office. Sometimes the procurement department listens to the business’ preferences, sometimes they don’t.
The business and the CTO group resent the procurement department. Who are they to tell them what to do?
In some cases, the investment banking department gets a whiff that one of their customers is trying to win a deal with the bank for their technology. The investment bankers will try to lobby on their behalf. Synergies.
Over time, the bank has evolved a cumbersome way of handling these projects to account for these behavioral distortions and cross-departmental lines. Practically, it means that a project that should take six months takes twelve to eighteen months to complete. It means that something that should have cost $100 comes with a total cost of $200. And because the process is so complicated and difficult and opaque, there are often legal challenges when a supplier who was convinced to invest in an expensive proposal loses, causing in turn further delays and further increases in costs. What’s worse, the timeline for implementing the solution in the business gets pushed out, so that the business’ ability to make money from a new revenue line or to lower costs is delayed.
Some of the other banks notice and begin to steal our bank’s clients. Our bank becomes less relevant in the marketplace.
How would we fix this setup?
One problem stands out straightaway. In the language of Silicon Valley, there needs to be “one throat to choke.” Ideally, there should be someone who works in the office of the Chief Financial Officer or the Chief Executive Officer who is in charge of overseeing the technology projects that exceed $1m in cost. This one person is responsible to the CEO for getting the best outcome, shortening the procurement cycle, and lowering both transaction and opportunity costs.
Given the fact that there are people from across the enterprise involved in the purchase, there needs to be a cross-departmental committee in place before the requirements are laid down. Instead of asking the bankers to form the requirements, these need to be developed by the entire committee, including people from technology, procurement, compliance, legal, and finance. This obviates the gamesmanship.
There needs to be a common technology system so that people using different systems and with little experience in procurement can access the procurement projects and do everything they need to do in one contained space. The procurement function for most of them will be an adjunct position, an additional duty to their primary roles within the firm. They don’t want to log into five or six different systems.
Just as there is one throat to choke, there needs to be one place to work on this project. The user experience of this platform needs to be intuitive and simple to use. Ideally, it will be plugged into the procurement system of record via application programming interface. In a sense, this platform is the layer that broadens the reach of the procurement system, exposing data and collaboration, all with an audit trail that tracks internal performance measures..
This platform will also be the place for vendors to interact with the buying committee, sharing information. The RFP takes place in this digital platform. All the communications are easily reported to authorities like the SEC. The simplicity and transparency is proof of fairness to the vendors, along with tools to help them reduce their costs.
Get this right and the bank shortens the procurement cycle, reduces the number of challenges, and attracts the level of competition on price and solution necessary to obtain real problem-solution fit at a reasonable price.
This is what we have built at EdgeworthBox, a dedicated, contained system for executing RFPs and coordinating large complex groups internally (and externally). Let’s talk.
