I believe that there is distinct difference between a “tool” (i.e. product) and a “solution”. While the analysis I present here, focuses on software, I believe that the distinction holds across all categories where solutions/products are sold.
Both products and solutions are designed to address a need, but solutions are holistic in their coverage whereas products address only part of the need. You might think that I am picking nits, I am not. And, my challenge here is to convince you that I am right, and the difference is material and if implemented properly a solution can provide a long term competitive advantage over a product.
Let me start out by describing three ways to deliver accounting system functionality to a company. While not the most exciting subject area, it provides an excellent example:
- I could provide you with a product called a spreadsheet and let you implement double entry accounting using this general purpose “tool”. While no one would argue that it is possible to use a spreadsheet for this purpose, no one would even remotely consider this option a solution even though, using a spreadsheet is undoubtedly a significant improvement over manually recording transactions in a paper ledger.
- Alternatively, I could provide you with a general ledger product. Some of you might remember McCormack and Dodge or possibly MSA—they were mainframe-based general ledger systems. They performed basic GL functionality and later (and relatively briefly) formed the core for 3rd party provided systems (accounts payable/receivable, manufacturing and HR) that together with the core GL provided relatively complete order-to-cash functionality for those willing to go through the effort and expense of implementing them. Most large business enterprises did. But, once again, the “GL” didn’t deliver a solution. It was still a tool that needed to be configured and, as noted, required “bolt-ons” from other software providers to deliver the functionality required by their clients.
- Oracle and SAP changed the game (accounting software for large entities) with their ERP (which incorporated complete order-to-cash functionality) offerings. They liked to refer to them as solutions (they incorporated all the functions that had to be bolted-on in the previous generation of software), but they were still lacking. A product that requires such significant effort to implement and maintain (professional services firms made hundreds of millions of dollars installing these products and delivering working solutions to its customers) still isn’t a solution. It is a tool, that if properly applied, will deliver desired outcomes.
- Finally, companies like PwC, offered BPO (business process outsourcing) to their clients. This combined the software offering with services designed to provide a turnkey solution to their clients. The “solution” include:
- The software;
- Ongoing upgrades that are necessary to take advantage of the latest functionality and security updates;
- Services necessary to interact with the parts of the business that must provide data for the accounting function to operate and perform the accounting function.
Now that we have seen the examples, I would like to outline the characteristics that define a “solution”:
- There is the approach. The approach is important, it defines how the solution will be implemented, used and maintained over time. If it is well designed, it incorporates a deep understanding of the work (which include an understanding of both the industry and process specific components) that the solution is going to support. At Textura, much of our solution development time was spent trying to understand what our clients were doing, what challenges they faced and how we might be able to assist them. This lead us to focus on payments and gain a deep understanding of the payment process which lead us to produce CPM, a product that increased the effectiveness and efficiency of the payment process. It also armed us with the expertise necessary to prescribe the best way to implement the software and supporting processes. This did two things:
- It lowered implementation costs. The software doesn’t need to be modified and the need to define and document processes is obviated since they were already defined and documented by Textura;
- It ensured that improvements (based on what the product planners learn from the sum experience of the client base) in the process will be incorporated as part of the work Textura did in updating and improving the solution. Those of you who have modified software understand what it takes to upgrade which is why much of the software installed (and modified) rarely, if ever, gets vendor supplied upgrades.
I will beat a dead horse by pointing out that processes like accounting, warehouse management, payments (i.e. spaces where there are multiple “packaged” products/solutions are very unlikely to provide an opportunity for long-term competitive advantage. So, buying a solution customizing it (i.e. not just leveraging the investment that the solution provider makes in the product) doesn’t make sense.
- There are services to support the delivery of the of the solution. There are three legs to this services component:
- Implementation support— if solutions are implemented incorrectly the value will not be realized. The best way to ensure that the product is implemented is to deliver a solution (approach and product) is high quality support that ensures that the solution is implemented as intended. And you will here this point two more times; implementation support provides the vendor with opportunities to understand both the environment into which their product is being deployed and issues that customers might have with the product in its current implementation—this market intelligence is PURE GOLD;
- Ongoing operating support— a well-designed solution should not need a lot of support, but when it does the vendor should be there, for two reasons: 1) to make sure that the customer gets the best experience, given the need for support, possible; and 2) as I said in the previous point above, the contact provides an opportunity to understand what is and isn’t working for the customers; and
- Support for product and process improvements— I see products (they aren’t solutions because they don’t hit this point) that don’t incorporate feedback into their ongoing product refresh. Solutions should be evolving entities. They should incorporate observations that the customer service and product development team make when they spend time with the clients. Practitioners who are good at this are not order-takers. They are individuals who are experienced observers who have exceptional analytic skills and are capable of synthesizing what they see into well-crafted elements (improvements to the process that are instantiated in the product) that enhance the value customers get from the product and improves the long-term competitive position of the product.
- There is the product (which is defined by the approach to solving the customers’ problem as outline above) which is designed to optimize the work that it is designed to support. Developing software that isn’t an integrated part of this trio ( 1) a well-defined approach to attacking the problem; 2) a support organization designed to ensure that implementation, operation and on-going upgrades to the solution go flawlessly is not a solution; and 3) a product that in this case automates the process) is a tool, not a solution.
There isn’t anything inherently wrong with a tool, but it requires much more investment to implement and maintain and since, as I noted above, there are few cases where packaged software is what is going to provide your sustainable competitive advantage, you are unlikely to get a return on investment, i.e. the tool won’t provide the value that a solution does.
For example, in the early days, SAP Software had the reputation of being “inflexible” and requiring their customers to perform their accounting in a way that was dictated by the software. SAP was clumsy in their presentation of their solution which while not complete (by my definition), was getting there. it did manage to incorporate two components of a solution— 1) a product; and 2) an approach to dealing with the company’s accounting related tasks.
And to give them credit, SAP had spent quite a bit of time and energy researching best practices. They build those best practices into their product. It didn’t sell well against Oracle’s claims of allowing the client flexibility to “do it their way” and forced SAP to change its marketing and sales approach.
And customers wanted to perform these functions the way “they always had”, not have it dictated to them by a software vendor. This made a lot of money (reference my previous statement about PwC’s experience implementing Oracle and SAP) for those who implemented the products. It was very costly as it meant substantial costs (implementation and maintenance for modifications, not to mention the increased costs associated with implementing upgrades provided by SAP and Oracle) that didn’t add any value to the customer and kept the offering in the product rather than solution category.
SAP and Oracle took a fork in the road (toward “tooldom” instead of toward being solution providers) and are still on that path.
Products like the payment application we built at Textura were part of a solution. Its implementation as a cloud-based offering helped us there. We were able to sell the standardized (driven by our approach to payments) as a benefit/requirement of being cloud-based. And, from the beginning we made sure that the client service organization had responsibility for: 1) selling the product; 2) implementing it; and 3) supporting it. They weren’t a sales organization or a customer support organization they were a full-fledged professional services organization. To be fair, I can not say that I was always happy with the feedback loop. It sometimes took on more of the character of a order-taking process, but there is always room for improvement.
If any of these three components are missing you don’t have a solution. But, when they are in place, they have the potential to provide a long-term competitive advantage to both the solution and the company offering it.
I hope that my examples and characterizations have helped to make my initial point: That there is a difference between a product (tool) and a solution. If you agree, please let me know. If not, why not?
Copyright 2017 Howard Niden
— you can find this (days earlier) and other posts at www.niden.com
and if you like this post: 1) please let me know; and 2) pass on your “find” to others.
Leave a Reply