Eight to Late

Sensemaking and Analytics for Organizations

Posts Tagged ‘Transaction Costs

Dark clouds, silver linings: a transaction cost perspective on the outsourcing of information systems

with 3 comments

Introduction

Some years ago, I wrote a post applying ideas of transaction cost economics to the question of outsourcing IT development work.  In that post I argued that evaluating costs on the basis of vendor quotes alone is highly misleading. One has to also factor in transaction costs – i.e. costs relating to things such as search, bargaining and contract enforcement.

In the present post I discuss transaction cost theory as it applies to the question of whether or not organisations should outsource their enterprise systems (such as ERP and CRM applications) to Software as a Service (SaaS) vendor. With the increasing number of offerings on the market, this issue is one that is high on the agenda of IT decision makers.

To be sure, there are many well-known (and massively hyped!) benefits of cloud-based solutions. To name just one: organisations that take the SaaS route do not have to worry about maintenance, upgrades etc. as these are handled by the vendor. As we shall see, however, when it comes to costs, things are not so clear.

Setting the context

Today’s IT landscape is considerably more complex than that of a couple of decades ago. Improvements in infrastructural technology now offer the IT decision maker choices that were simply not available then.  One of the basic choices a decision maker is faced when implementing a new enterprise system is whether to develop (or customize), host and support it in-house or opt for a cloud-based offering. Most often decisions on these matters are made on the basis of vendor-quoted costs alone. A typical discussion between a supporter and skeptic of outsourcing may go as follows:

Supporter: We should outsource our CRM system because we will save costs. We can save X million dollars on licensing and hardware…and then there are potential savings on personnel costs in the longer term.

Skeptic: Yes, but we lose flexibility to modify the application to suit our needs.

Supporter:  Flexibility is overrated. We have done a gap-fit analysis and have found that most of core business needs can be satisfied by the three shortlisted cloud offerings. We are not a complex business:  we call on customers, sell them our product and then follow-up from time to time to see how they are going and whether there are potential opportunities to sell them upgrades. It’s pretty much what everyone else in the business does.

Skeptic: What about vendor lock-in?

Supporter: There is no lock in we pay as we go; per user per month.

….and so the conversation goes. The supporter seems to have an answer for every question so the skeptic may eventually concede. However, the latter may still be left with a vague sense of unease that something’s been overlooked, and indeed something has…which brings us to the next topic.

Transaction costs

A firm has two choices for any economic activity: performing the activity in-house or going to market. In either case, the cost of the activity can be decomposed into:

  1. Production costs, which are direct (easily quantifiable) costs of producing the good or service
  2. Transaction costs, which are other (indirect) costs incurred in performing the economic activity.

Production costs include things such as per user cost etc. These are typically quoted upfront and are easy to contractualise (i.e. put into a contract).  Things are more complicated when it comes to transactions costs. To see this, let’s take a quick look at the different types of transaction costs:

  1. Search /selection costs: These are the costs associated with searching for and shortlisting vendors.
  2. Bargaining costs: These are costs associated with negotiations for a mutually acceptable contract.
  3. Maintenance costs: These are expected costs (i.e. those that were foreseen when the contract drawn up) associated with ongoing support, enhancements or upgrades.
  4. Costs of enforcement and change: These are costs associated with enforcing the terms of the contract and those associated with change.

These costs are typically hard to estimate upfront, and nearly impossible to contractualise. Moreover, in most cases, they are largely borne by the client.

Dark clouds

The difficulties associated with contractualising transaction costs arise from the following:

  1. Unexpected events: Unforeseen and unforeseeable changes in the customer / vendor organisations or in the business environment may entail major changes in the application functionality or even the outsourcing arrangement.
  2. Bounded rationality:  Business environments are complex and it is impossible for the human mind to anticipate everything that can possibly occur. As a consequence,  every contract is necessarily incomplete; there is bound to be something that is overlooked. It is impossible contractualise every eventuality.
  3. Strategic / opportunistic behaviour: the vendor or customer may deliberately withold certain information from the other party  at the outset in order to secure the contract at a favourable rate. Typical vendor behaviour may include not revealing certain limitations of the software on the other hand, the customer may attempt to include unfair penalty clauses into the contract or squeeze the vendor on margins.

Now before I’m accused of being unduly alarmist I should mention that certain kinds of enterprise systems are not subject to the above difficulties, or at least not significantly.  Typically these are infrastructural services such as servers, operating systems, databases and even simple, context-independent applications such as email.  These can be outsourced successfully without any problems because the services to be provided can be specified accurately upfront and thus contractualised unambiguously.

However, for enterprise applications such as ERP and CRM the situation is different because these systems are more or less unique to a given organisation – in other words, they are context-dependent.  Their uniqueness renders them vulnerable to the points mentioned above because it is impossible to foresee all possibilities. As a consequence it is inevitable that any outsourcing deal involving such systems will eventually be affected by one or more of the above uncertainties.

Silver linings

None of the above points is new: both vendors and customers are at least somewhat aware that application outsourcing deals have many unknowns. Consequently, both parties try to minimise their exposure to uncertainty. Unfortunately,  they usually go about this in exactly the wrong way:  they attempt to build safety for themselves at the cost of the other party. They do this by attempting to contractualise all possible things that can go wrong from their point of view. This is impossible because the future cannot be predicted.  Contracts, however detailed, will necessarily be incomplete.

The way out is simple. As Oliver Williamson, winner of the 2009 Economics Nobel Prize, tells us:

…important to the transaction-cost economics enterprise is the assumption that contracts, albeit incomplete, are interpreted in a farsighted manner, according to which economic actors look ahead, perceive potential hazards and embed transactions in governance structures that have hazard-mitigating purpose and effect. Also, most of the governance action works through private ordering with courts being reserved for purposes of ultimate appeal.

As he tells us, contracts need to be interpreted in a farsighted manner and governance action should work through private ordering (directly between the customer and vendor). Essentially, the success of an outsourcing deal is to a large extent the joint responsibility of the customer and vendor. Above all, it calls for a relationship based on old-fashioned notion of trust.

Interestingly, Elinor Ostrom, who jointly won the 2009 Economics Nobel with Williamson, had much to say about informal contracts, private ordering and trust.  Her extensive studies on collectives lead her to conclude that successful collective endeavours have the following two elements in common:

  1. High levels of face-to-face communication
  2. Innovative governance structures that are designed and enforced by the participants rather than external authorities.

The relevance of these to an outsourcing arrangement is clear: face to face communication builds trust, and innovative internal governance structures that are enforceable without legal recourse will discourage opportunistic behaviour from both parties. Although the latter may sound a bit utopian there are proven ways to set up such governance structures (see this paper for an example).

Conclusion

In this post I have argued that a proper analysis of SaaS deals must include transaction costs.  Although these are difficult to quantify, a consideration of the different categories of transaction costs will at least lead to a more realistic appraisal of such arrangements.  It is my belief that many outsourcing deals go sour because transaction costs are overlooked.  Given that it is impossible to foresee the future, the best course of action is to develop a business relationship that is based on trust.

To sum up:  most important factor in enterprise application outsourcing is not cost, but trust an ineffable element that can neither be quantified nor contractualised.

Written by K

October 2, 2013 at 9:35 pm

To outsource or not to outsource – a transaction cost view

with 11 comments

One of the questions that organisations grapple with is whether or not to outsource software development work to external providers. The work of Oliver Williamson – one of the 2009 Nobel Laureates for Economics – provides some insight into this issue.  This post is a brief look at how Williamson’s work on transaction cost economics can be applied to the question of outsourcing.

A firm has two choices for any economic activity: performing the activity in-house or going to market. In either case, the cost of the activity can be decomposed into production costs, which are direct and indirect costs of producing the good or service, and transaction costs, which are other (indirect) costs incurred in performing the economic activity.

In the case of in-house application development, production costs include developer time, software tools etc whereas transaction costs include costs relating to building an internal team (with the right skills, attitude and knowledge) and managing uncertainty. On the other hand, in outsourced application development, production costs include all costs that the vendor incurs in producing the application whereas transaction costs (typically incurred by the client)  include the following:

  1. Search costs: cost of searching for providers of the product / service.
  2. Selection costs: cost of selecting a specific vendor.
  3. Bargaining costs: costs incurred in agreeing on an acceptable price.
  4. Enforcement costs: costs of measuring compliance, costs of enforcing the contract etc.
  5. Costs of coordinating work : this includes costs of managing the vendor.

From the above list it is clear that it  can be hard to figure out transaction costs for outsourcing.

Now, according to Williamson, the decision as to whether or not an economic activity  should be outsourced depends critically on transaction costs. To quote from an article in the Economist which describes his work:

…All economic transactions are costly-even in competitive markets, there are costs associated with figuring out the right price. The most efficient institutional arrangement for carrying out a particular economic activity would be the one that minimized transaction costs.

The most efficient institutional arrangement is often the market (i.e. outsourcing,  in the context of this post), but firms (i.e. in-house IT arrangements) are sometimes better.

So, when are firms better?

Williamson’s work provides an answer to this question. He argues that the cost of completing an economic transaction in an open market:

  1. Increases with the complexity of the transaction (implementing an ERP system is more complex than implementing a new email system).
  2. Increases if it involves assets that are worth more within a relationship between two parties than outside of it: for example, custom IT services, tailored to the requirements of a specific company have more value to the two parties – provider and client – than to anyone else. This is called asset specificity in economic theory

These features make it difficult if not impossible to write and enforce contracts that take every eventuality into account. To quote from Williamson (2002):

…. all complex contracts are unavoidably incomplete, on which account the parties will be confronted with the need to adapt to unanticipated disturbances that arise by reason of gaps, errors, and omissions in the original contract….

Why are complex contracts necessarily incomplete?

Well, there are at least a couple of reasons:

  1. Bounds on human rationality:  basically, no one can foresee everything, so contracts inevitably omit important eventualities.
  2. Strategic behavior: This refers to opportunistic behavior to gain advantage over the other party. This might be manifested as a refusal to cooperate or a request to renegotiate the contract.

Contracts will therefore work only if interpreted in a farsighted manner, with disputes being settled directly between the vendor and client. As Williamson states in this paper:

…important to the transaction-cost economics enterprise is the assumption that contracts, albeit incomplete, are interpreted in a farsighted manner, according to which economic actors look ahead, perceive potential hazards and embed transactions in governance structures that have hazard-mitigating purpose and effect. Also, most of the governance action works through private ordering with courts being reserved for purposes of ultimate appeal.

At some point this becomes too hard to do. In such situations it makes sense to carry out the transaction within a single legal entity (i.e. within a firm) rather than on the open market. This shouldn’t be surprising: it is obvious that complex transactions will be simplified if they take place within a single governance structure.

The above has implications for both clients and providers in outsourcing arrangements. From the client perspective,  when contracts for IT services are hard to draw up and enforce, it may be better to have those services provided by in-house departments rather than external vendors.  On the other hand,  vendors need to focus on keeping contracts as  unambiguous and transparent as possible. Finally, both clients and vendors should expect ambiguities and omissions in contracts,  and be flexible whenever there are disagreements over the interpretation of contract terms.

The key takeaway is easy to summarise:  be sure to consider transaction costs when you are making a decision on whether or not to outsource development work.

Written by K

October 29, 2009 at 10:03 pm

%d bloggers like this: