Minimizing the Total Cost of Technical Support for Enterprise Applications
Enterprise software selection is a big decision for any organization. Licensing fees are costly, and choosing the software that matches the company’s business model can be a daunting decision. If the enterprise decides to go with a particular vendor, and the vendor does not deliver, the company will incur a large financial loss. Thus, when selecting an enterprise software solution, there are many factors that need to be considered in the decision. These include the quality of the product or solution; customer service; the purchasing price of the software or license; and other cost factors involved in the process of procurement.
In purchasing an enterprise software solution, there are three types of costs:
* direct costs (related to purchase, implementation, and other immediate costs arising from purchase);
* opportunity costs (the costs arising from forgoing the benefits of an alternative solution); and
* indirect costs (the costs that are not directly calculable, but that impact the business once the solution is implemented).
To curb the dilemma of unwanted costs of any kind, one way an enterprise can evaluate vendors is by examining their technical support plans. This article will examine the implicit costs behind the support plans, and help users avoid losing revenue due to inefficient or unresponsive technical support.
Cost Analysis
The following sections deal with the three different types of costs. To make an educated decision on the software solution and support plan, enterprises should consider these costs as a way of minimizing the risk of having poor technical support response times from vendors. The consideration of these costs can be used as criteria for an informed decision.
Anatomy of Direct Costs
In order to give a basis for the analysis of costs relating to enterprise software, the general formula should be noted:
total cost of solution = cost of actual software or licensing fee + cost of support + cost of implementation + cost of maintenance
The weights assigned to each component in the model are assigned as a rule of thumb, based on data from typical implementations:
1. cost of actual software or licensing fee = 50%
2. cost of support = 20%
3. cost of implementation = 30%
4. cost of maintenance = 10%
Note that although some companies consider maintenance and support to be a single factor, for proper analysis they must be viewed as two different components.
This formula is the foundation on which analysis can be started, and the weights should give the individual or team searching for an enterprise solution a basis on which to proceed.
A second criterion for software selection is the service-level agreement (SLA). Decision makers should obviously be cognizant of the terms and conditions in the SLA. Since support represents 20 percent of the total cost of the solution, the type of support negotiated between the enterprise and vendor is critical to minimizing the risk of having a bad technical support plan.
Anatomy of Opportunity Costs
Now that the direct costs have been established, the second type of cost in selecting the support plan is the opportunity cost. As mentioned above, opportunity cost is defined as the foregone opportunity of having one benefit over another.
For instance, consider an individual with particular skills and a certain level of education, who receives a job offer. This individual can either accept the position and earn the salary which is offered, or forgo the opportunity by pursuing further education or training. The total opportunity cost of choosing the second option is the cost of education, plus the foregone income that would have been earned had the original position been accepted.
We can now apply this concept to the selection of support plans from vendors. The power of this idea lies in comparing vendors side by side. Let’s say there are two vendors in the enterprise resource planning (ERP) market, selling identical enterprise software solutions, with the only difference lying in their technical support plans. The organization purchasing the enterprise application looks at both these vendors, and does a comparison. Let’s say that vendor 1 has a 50 percent better response time than vendor 2 in terms of responding to any technical problem (ranging from a simple workstation problem, to the entire system crashing); thus, vendor 1 delivers support when the enterprise needs it. The opportunity cost that the organization incurs by purchasing the product from vendor 2 is the amount of support paid to vendor 2, plus the revenue lost due to the solution being down.
To be clear, since vendor 1 is 50 percent more responsive, had the firm gone with vendor 2, the opportunity cost of purchasing this solution would have been the cost of licensing, plus all the implicit costs (explained below). This solution is 50 percent more costly than that of vendor 1 in terms of the associated downtime and loss of production.
Anatomy of Indirect Costs
As mentioned above, indirect costs may not be evident in the initial purchase of the solution. They are not directly quantifiable and cannot be measured in the accounting sense. However, they can be measured by other means. They include the costs for the additional pieces of equipment and labor that have to be resourced in order for production to continue without loss of time when the solution is down.
The most important indirect cost (and by far the largest) is the revenue lost when the solution is down. In other words, as long as the solution is down, the enterprise cannot be productive, and is thus losing money during every minute of downtime.
Other general indirect costs are incurred when an enterprise solution is down:
*
Wages
People who are working on solving the problem are losing the opportunity to be productive elsewhere, and are thus costing the enterprise the wages lost in trying to solve the problem.
*
Additional human capital
Additional people may need to be allocated in the IT department or in the production environment in order to prevent production stoppage or slowdown.
*
Rental costs
The enterprise may need to rent additional software, hardware, or equipment in order to prevent production stoppage.
*
Time
Although time is not generally measured as cost, it is the most essential resource lost when a solution is down. Time is directly linked to productivity, revenue, and every other variable of operation. If the software application is down, time (for both equipment and human capital) is devoted to finding a solution.
Other examples of indirect costs include the average shift time of the people working to get the solution working again; rollback time; the number of phone calls or e-mails made to the vendor’s technical support department; and length of time it takes to resolve the problem. These costs, all directly related to time (in different measurable forms) thus create a framework for enterprises to evaluate vendors in a side-by-side comparison.
Depending on the industry and type of application, other types of costs may also be incurred. However, the above is a general guideline to assist enterprises in the selection of their technical support plans.
Leaning toward a Methodological Approach to Curbing Lost Revenue
To avoid the cost traps that organizations can fall into, there are a number of options that they can implement in order to streamline their productivity and minimize lost revenue.
One way organizations can do this is by investing in a solution support methodology. In resource terms, the concept of investment is that when individuals or firms put forth money to leverage equipment or human capital, they expect to gain revenue in return.
When an enterprise needs a solution, one way it can invest into the business in order to cut lost revenue is by taking a best practices approach to its support plan. One such approach is put forth by the Information Technology Infrastructure Library (ITIL). This framework stipulates how a company can manage each process, and thus eliminate the indirect and opportunity costs mentioned above. Applying the idea of investment to this methodology, by investing in the future, companies can minimize the confusion that ensues when a solution is down. In other words, investing in this type of methodology will help everybody use the current enterprise solution, and help the organization to develop processes for when the solution is in trouble.
There are also a number of software applications that a company can use along with the methodology to complement organizational processes in order to minimize the risk of having poor and inefficient technical support. These might include a service management application (SMA) or a business activity model (BAM). An SMA or BAM will be able to detect a technical problem when it occurs, and report it to the IT manager responsible for the application. Large-scale vendors will usually have these types of tools already integrated into their software, but when considering a solution, it’s a good idea to verify that an SMA or BAM is in place.
The Final Word
In terms of technical support, organizations may not necessarily follow a formalized process for technical support selection and evaluation. However, as noted above, technical support is an extremely vital component to any organization running enterprise software. The financial impacts of poor technical support can affect the total cost of ownership (TCO) and return on investment (ROI). The impact is even more severe if the solution is not a proper match for the business. Poor technical support impacts the life cycle of the solution, and also causes frustration for the people actually using the solution—this can translate to increased stress in the workplace, which is another indirect cost that nobody wants.
To reiterate, when an enterprise is searching for a solution, they want to look at the following factors for each vendor:
1. What type of service does the vendor offer? (One example would be three-tiered support.)
2. Does the vendor have some form of SMA or BAM in its solution?
3. Is it possible to obtain recommendations from other users that have selected the vendor, and to get a general view of how responsive the vendor was in solving the problem?
4. How does the vendor fare in terms of the quality of the answers it gives to users?
5. What is written in the SLA? For instance, does the vendor stipulate how it will deal with downtime and how fast it will deal with the issue?
As for the users, they can curtail risk by adopting an ITIL methodology (or similar) in order to minimize confusion when downtime occurs and increase speed to uptime when something of this nature arises.
SOURCE :http://www.technologyevaluation.com/research/articles/minimizing-the-total-cost-of-technical-support-for-enterprise-applications-19949/
In purchasing an enterprise software solution, there are three types of costs:
* direct costs (related to purchase, implementation, and other immediate costs arising from purchase);
* opportunity costs (the costs arising from forgoing the benefits of an alternative solution); and
* indirect costs (the costs that are not directly calculable, but that impact the business once the solution is implemented).
To curb the dilemma of unwanted costs of any kind, one way an enterprise can evaluate vendors is by examining their technical support plans. This article will examine the implicit costs behind the support plans, and help users avoid losing revenue due to inefficient or unresponsive technical support.
Cost Analysis
The following sections deal with the three different types of costs. To make an educated decision on the software solution and support plan, enterprises should consider these costs as a way of minimizing the risk of having poor technical support response times from vendors. The consideration of these costs can be used as criteria for an informed decision.
Anatomy of Direct Costs
In order to give a basis for the analysis of costs relating to enterprise software, the general formula should be noted:
total cost of solution = cost of actual software or licensing fee + cost of support + cost of implementation + cost of maintenance
The weights assigned to each component in the model are assigned as a rule of thumb, based on data from typical implementations:
1. cost of actual software or licensing fee = 50%
2. cost of support = 20%
3. cost of implementation = 30%
4. cost of maintenance = 10%
Note that although some companies consider maintenance and support to be a single factor, for proper analysis they must be viewed as two different components.
This formula is the foundation on which analysis can be started, and the weights should give the individual or team searching for an enterprise solution a basis on which to proceed.
A second criterion for software selection is the service-level agreement (SLA). Decision makers should obviously be cognizant of the terms and conditions in the SLA. Since support represents 20 percent of the total cost of the solution, the type of support negotiated between the enterprise and vendor is critical to minimizing the risk of having a bad technical support plan.
Anatomy of Opportunity Costs
Now that the direct costs have been established, the second type of cost in selecting the support plan is the opportunity cost. As mentioned above, opportunity cost is defined as the foregone opportunity of having one benefit over another.
For instance, consider an individual with particular skills and a certain level of education, who receives a job offer. This individual can either accept the position and earn the salary which is offered, or forgo the opportunity by pursuing further education or training. The total opportunity cost of choosing the second option is the cost of education, plus the foregone income that would have been earned had the original position been accepted.
We can now apply this concept to the selection of support plans from vendors. The power of this idea lies in comparing vendors side by side. Let’s say there are two vendors in the enterprise resource planning (ERP) market, selling identical enterprise software solutions, with the only difference lying in their technical support plans. The organization purchasing the enterprise application looks at both these vendors, and does a comparison. Let’s say that vendor 1 has a 50 percent better response time than vendor 2 in terms of responding to any technical problem (ranging from a simple workstation problem, to the entire system crashing); thus, vendor 1 delivers support when the enterprise needs it. The opportunity cost that the organization incurs by purchasing the product from vendor 2 is the amount of support paid to vendor 2, plus the revenue lost due to the solution being down.
To be clear, since vendor 1 is 50 percent more responsive, had the firm gone with vendor 2, the opportunity cost of purchasing this solution would have been the cost of licensing, plus all the implicit costs (explained below). This solution is 50 percent more costly than that of vendor 1 in terms of the associated downtime and loss of production.
Anatomy of Indirect Costs
As mentioned above, indirect costs may not be evident in the initial purchase of the solution. They are not directly quantifiable and cannot be measured in the accounting sense. However, they can be measured by other means. They include the costs for the additional pieces of equipment and labor that have to be resourced in order for production to continue without loss of time when the solution is down.
The most important indirect cost (and by far the largest) is the revenue lost when the solution is down. In other words, as long as the solution is down, the enterprise cannot be productive, and is thus losing money during every minute of downtime.
Other general indirect costs are incurred when an enterprise solution is down:
*
Wages
People who are working on solving the problem are losing the opportunity to be productive elsewhere, and are thus costing the enterprise the wages lost in trying to solve the problem.
*
Additional human capital
Additional people may need to be allocated in the IT department or in the production environment in order to prevent production stoppage or slowdown.
*
Rental costs
The enterprise may need to rent additional software, hardware, or equipment in order to prevent production stoppage.
*
Time
Although time is not generally measured as cost, it is the most essential resource lost when a solution is down. Time is directly linked to productivity, revenue, and every other variable of operation. If the software application is down, time (for both equipment and human capital) is devoted to finding a solution.
Other examples of indirect costs include the average shift time of the people working to get the solution working again; rollback time; the number of phone calls or e-mails made to the vendor’s technical support department; and length of time it takes to resolve the problem. These costs, all directly related to time (in different measurable forms) thus create a framework for enterprises to evaluate vendors in a side-by-side comparison.
Depending on the industry and type of application, other types of costs may also be incurred. However, the above is a general guideline to assist enterprises in the selection of their technical support plans.
Leaning toward a Methodological Approach to Curbing Lost Revenue
To avoid the cost traps that organizations can fall into, there are a number of options that they can implement in order to streamline their productivity and minimize lost revenue.
One way organizations can do this is by investing in a solution support methodology. In resource terms, the concept of investment is that when individuals or firms put forth money to leverage equipment or human capital, they expect to gain revenue in return.
When an enterprise needs a solution, one way it can invest into the business in order to cut lost revenue is by taking a best practices approach to its support plan. One such approach is put forth by the Information Technology Infrastructure Library (ITIL). This framework stipulates how a company can manage each process, and thus eliminate the indirect and opportunity costs mentioned above. Applying the idea of investment to this methodology, by investing in the future, companies can minimize the confusion that ensues when a solution is down. In other words, investing in this type of methodology will help everybody use the current enterprise solution, and help the organization to develop processes for when the solution is in trouble.
There are also a number of software applications that a company can use along with the methodology to complement organizational processes in order to minimize the risk of having poor and inefficient technical support. These might include a service management application (SMA) or a business activity model (BAM). An SMA or BAM will be able to detect a technical problem when it occurs, and report it to the IT manager responsible for the application. Large-scale vendors will usually have these types of tools already integrated into their software, but when considering a solution, it’s a good idea to verify that an SMA or BAM is in place.
The Final Word
In terms of technical support, organizations may not necessarily follow a formalized process for technical support selection and evaluation. However, as noted above, technical support is an extremely vital component to any organization running enterprise software. The financial impacts of poor technical support can affect the total cost of ownership (TCO) and return on investment (ROI). The impact is even more severe if the solution is not a proper match for the business. Poor technical support impacts the life cycle of the solution, and also causes frustration for the people actually using the solution—this can translate to increased stress in the workplace, which is another indirect cost that nobody wants.
To reiterate, when an enterprise is searching for a solution, they want to look at the following factors for each vendor:
1. What type of service does the vendor offer? (One example would be three-tiered support.)
2. Does the vendor have some form of SMA or BAM in its solution?
3. Is it possible to obtain recommendations from other users that have selected the vendor, and to get a general view of how responsive the vendor was in solving the problem?
4. How does the vendor fare in terms of the quality of the answers it gives to users?
5. What is written in the SLA? For instance, does the vendor stipulate how it will deal with downtime and how fast it will deal with the issue?
As for the users, they can curtail risk by adopting an ITIL methodology (or similar) in order to minimize confusion when downtime occurs and increase speed to uptime when something of this nature arises.
SOURCE :http://www.technologyevaluation.com/research/articles/minimizing-the-total-cost-of-technical-support-for-enterprise-applications-19949/
1 Response to "Minimizing the Total Cost of Technical Support for Enterprise Applications"
Post a Comment