/>iIf you have been around technology-centric work for a while, you may have come to realize that many “technology” programs really aren’t about technology at all—the technology simply functions as a conduit for business change. A classic example of this phenomenon occurs in enterprise resource planning (ERP) projects, which used to have very high rates of failure, typically because companies didn’t realize the amount of “heaving lifting” that was required from an organizational change management perspective. This also tends to be true for other process-driven work such as business process outsourcing (BPO), and it seems to be the common denominator that has held through various evolutions of technology.
Regardless of the flavor of the technology being used, it can be very helpful to look to the contracting strategy that is required to meet the business objective. Let’s review three examples and use in-house hosted robotics to illustrate the changing technology.
Client Participation Considerations
Among the most important aspects to look at during contracting is whether there will be significant client participation required to make the project a success. If the project involves simple software licensing, for example, then everything the seller has to accomplish is contained within the four corners of the contract. A contract like this is complete as written and is relatively simple in its execution. Commercial off-the-shelf software (COTS) is an example of this; if you get the software that you contracted to buy, the contract has been completely performed and the transaction was successful.
It’s easy to get distracted by “shiny objects” and marketing hype when thinking about these types of projects. For example, many types of robotics acquisitions prevalent in the current environment initially may seem complex, but a COTS-like software contracting model may fit nicely. The robot essentially is just a piece of software, and getting it to do anything is very similar to the configuration exercise for more typical software we used to see in the old days (way back in, say, 2014). So, licensing the bot may not be so difficult, but getting it to actually do something could be a different story.
Business Requirements Considerations
The next layer of complexity happens when the seller has to analyze potential buyers’ business requirements to develop functional and technical specifications (think software development, complex software configuration, and the like). This would be the systems integrator work in a complex software implementation, and it requires a different type of contract than a simple software license. However, the relationship between the buyer and seller—although somewhat interdependent—can still be delineated. In the case of complex software, the buyer has to participate in defining business requirements and various sign-offs, but once that is done, the seller does the bulk of the work. Applying that to our robotics example, this represents the step of defining the process definition documents (or similar term) that is used to generate scripting that the robot executes.
Value Delivery Considerations
The next and final layer of contracting complexity in this space happens when the buyer has to actively participate in the seller’s delivery of value. This is typical for deals that are intended to drive process improvement or efficiencies on the customer side of the performance line. Many outsourcing deals fit into this category because to be successful, the customer and provider often have to act very closely together to drive the outcomes that deliver value.
Throwing robotics into the mix, robotic process automation (RPA) is becoming an increasingly important part of the BPO solution. This use of process automation is driving unprecedented value into these deals but also requires unprecedented transformation on the customer’s part. These transactions can provide a nice incentive for the customer to change in ways that it should have anyway, and to be able to see substantial rewards for its efforts. The other side of this, though, is that by using process automation, it is possible to promulgate awful processes because such processes can be completed so quickly that they feel more efficient—and feelings don’t always match with reality.
Conclusion
Much of the success of the deals we’ve discussed in this post rests with the fee schedule, how pricing is set up, and how the risk of transformation is shifted.
