When evaluauting a software product, one of the most important things to understand is the core metaphors around which the software is built. Why do I use the term metaphor, rather than entity or concept? Because a metaphor is a substitute, a proxy, and in software, the core concepts are proxies for real concepts in the business process that is to be supported.
Example:
If the real business process requires a contract between your organization and the customer, what system metaphor represents that contract? If there are different types of contracts, how do the system metaphors represent different properties and behaviors of those contract types? The degree to which the software metaphor for contracts reflect the real attributes or properties of the contract (term, effective date, rights, etc.) will determine what aspects of your business can be automated.
There are certain concepts that apply to system metaphors that help you determine its applicability to your business model. Here are questions to ask to determine how a software metaphor correlates to the real entities in your business model:
- How generalized is this metaphor?
For example: Does the software provide a single contract metaphor or is there a different metaphor for every kind of contract that is supported?
- How does the metaphor support variations in business process?
For example: Does the system assume that every contract has the same properties and behaviors, or is there some way to define different contracts that have different properties and behaviors?
- How is the metaphor structured?
For example: Can your customer be a person, a business, and if a business, can it represent a business hierarchy (subsidiaries) so that you can report (p&l) by
subsidiary or at the holding company level?
- How does this metaphor relate to other metaphors in your business model?
For example: If your contracts are leases, does the lease metaphor relate to an asset or property metaphor, so that a validation could be built such that a
property or asset can only be related to one lease at the moment, but could be related to multiple leases that are not for concurrent periods? Is the lease or contract metaphor related to both the property and the customer metaphor so that I could easily determine which properties are currently leased to which customer?
- How do the attributes of the metaphor support my business process?
- For example: If you have a process that determines which leases are going to expire in the next period, and proactively contacts the customer to plan to renew or amend – do the system metaphors support a convenient way to support this process?
Example:
If your business generates leases for different types of assets or properties, that vary dramatically in properties and behaviors, and the competitive business model is to continue to add variations to new leases, but a potential software solution does not adequately support variations in lease behavior. Purchasing this software will require the business to manually work around the deficiencies in the software solution, perhaps by capturing the variations in behavior as "comments" or "notes", and requiring staff to "remember" to review the comments and notes when processing the lease. Over time, these manual work-arounds build up into inefficiencies, and add risk (what happens when someone doesn't remember, customers are disappointed?) such that over time, you can reduce your profitability and customer satisfaction.
Conclusion:
In practice, a system that institutionalizes work-arounds because it does not represent information and behavior in reasonable alignment with your business model affects the ability to grow your business in two ways:
- It requires more staff because it provides less "leverage" to your employees. That is, each one can do less work in a given amount of time.
- It requires more capable staff, because it relies more on staff knowledge, diligence, and intelligence to implement all of the processes that cannot be done through the agency of the system.
What can be done?
Document your business model, especially focusing on the key metaphors, how the behaviors of those metaphors engage the ability to grow or sustain your business model, or how you would like those metaphors to change your business model to become more scalable or competitive. Understand this deeply, so that you can compare each vendor and software product to see how they "enable" growth, sustainability, or desired change.
Understand the business capabilities that you want to maintain, improve, or develop in terms of the metaphors. These are your business goals. Use this list to evaluate vendors and software products to see how their softare (with it's metaphors) will enable you to acheive the goals that you have established. Recognize that no one product is likely to perfectly match your goals, and that compromises will have to be made.
Make sure that all participants in the selection or evaluation process deeply understand the business goals. Focusing any IT project on the business goals, and never letting your goals out of site, is a way to ensure success. Your criteria for software selection should eminate from that products ability to enable goal acheivement.
No Comments