Prévia do material em texto
Business Case Tutorial Series how to write an effective business case Module 1 - What is the Business Case This tutorial series focuses on how to write a business case. This tutorial is taken from Prosci's Business Case Toolkit which includes a complete business case template, guidelines, exercises, worksheets and checklists for developing an effective business case. It follows the series dedicated to project planning and reengineering design. Email this page to a friend This first module is adapted from a tutorial written for Prosci by Nancy Maluso. Why should a business case be written? The most obvious reason for putting together a business case is to justify the resources and capital investment necessary to bring a change project to fruition. However, this implies that the business case is simply a financial document. While all business cases should include financial justification, it should not be the only purpose of the document. The business case is the one place where all relevant facts are documented and linked together into a cohesive story. This story tells people about the what, when, where, how and why. · Why is the project needed (issues & opportunities)? · How will the effort solve the issues or opportunities facing the organization? · What is the recommended solution(s)? · How does the solution address the issues or opportunities (benefits)? · What will happen to the business if the BPR effort is not undertaken (the do nothing scenario)? · When will the solutions be deployed · How much money, people, and time will be needed to deliver the solution and realize the benefits? What are the three roles of a business case? The writing of the business case forces the team to sit back and reflect on all of the work they have so diligently completed. It is far too easy for the team to continue to plug away toward the end result and fail to document the work they've already accomplished. This is especially true during the concept and design stages of any project. Therefore, the business case serves as a wake-up call to the team causing them to capture the knowledge they've developed about how the business will function both with and without the final solution. The second role of the business case is to verify that the solution substantiates or meets the needs of the business, and is the vehicle for receiving funding and approval to move forward. It provides a vehicle for the team to step back and subjectively review their facts and assumptions. In addition, it is vital that the team document what would happen to the business if the project is not undertaken. This base case or "do nothing" scenario is the foundation upon which all benefits from the effort are derived. By documenting everything together in one story, it is easy to link the issues to the solution and the benefit, and identify where the business would be without the project. The development of the overall business case simplifies the development of the financial justification, and will usually identify holes or problems with the solution. Moreover, you now have a way to measure your success. This analysis also is useful for your leadership team to prioritize this project against the many other initiatives in the business that may require capital investment. The final important role that the business case plays is to provide a consistent message to many different audiences. It is a high level view of the entire project and enables all organizations affected by the effort (customers, management, operations, research & development, service, sales, accounting, finance, etc.) to be knowledgeable about the project. Who should write the business case? The business case should be viewed as a story -- your team's story. Therefore, everyone on the team should contribute to its development. This does not mean that everyone will write a section of the business case. In fact, only one or two people should actually write the final document. However, all of the information used in the business case should come from team members themselves. The business case writers should be team members who have an overall understanding of the entire project and can synthesize the multiple and varied plans into one document. Keeping the actual writers of the case to a minimum ensures a consistent style throughout the document. When should the business case be written? A project lifecycle typically provides some break points where a business case should be completed. The figure below shows the steps leading up to the writing of the business case (see design phase). Every milestone in the activity of the team should result in a contribution to the business case. For example, at the conclusion of the project planning phase, all of the key project information should be documented in the business case (description, business issues, scope, objectives, etc.). Overall goals While one of your primary goals may be to get funding, your chances of success will be greater if you keep the following goals in mind as well: · Make it interesting; remember someone will have to read it. · Keep it clear and concise. · Minimize jargon and conjecture. · Communicate all facts as part of the overall story - you've done your homework, here is the chance to prove it. · Provide the reader with a picture or vision of the end state. · Demonstrate the value the project brings to the organization, customer and financial bottom line of the company. When your team is done, you should throw a business case party. The entire team should feel a wonderful sense of accomplishment, after all, the business case contains a complete record of the great work the team has completed and demonstrates the value of the work yet to be done. The benefits obtained by your team by writing the business case are many, but at a minimum they will have gained: · Organization of thoughts, activities and knowledge · An objective review of the ideas and facts of the project · The ability to identify holes, inconsistencies or weaknesses in the effort · An improved ability to communicate the purpose of the project · Financial justification for their effort · A great sense of accomplishment Coming next: Module 2 will look at the key elements of a business case and provide an outline that you can use as a starting point. Business Case Tutorial Series how to write an effective business case Module 2 - Key elements of a business case This tutorial series focuses on how to write a business case. Module 1 addresses why you need a business case and what role it serves. This module provides an outline for a business case. Module 3 provides tips and suggestions for quantifying benefits. Module 4 provides a process and checklist for costs and benefits. Module 5 provides a model for activity based costing using VTC accounting. Module 6 (concluding the series) examines how to present your business case and ensure that you have not forgotten key elements. This series is taken from Prosci's Business Case Toolkit which includes a complete business case template, guidelines, exercises, worksheets and checklists for developing an effective business case. It follows the series dedicated to project planning and reengineering design. Email this page to a friend Background Your business case tells the story of your project. It should tell the reader the problem or opportunity that exists. Then, the business case should describe how the problem will be solved or the opportunity exploited. Although the financial elements are critical, they are in no way the only important parts of the business case. The outline presented below shows you how to effectively tell the entire story of your project and concludes by demonstrating the expected ROI and financial impact you expect. The Business Case Toolkit provides complete description, guidelines, tips and examples for each of the sections presented in this outline. Executive summary The executive summary should be the first section of the businesscase, but it is the last section that is written. It is a short (one to three pages) summary of the entire business case. Pretend you have two minutes to tell someone about the project and justify your requests for resources and funding. The executive summary is this two-minute drill. Each section in the executive summary should succinctly convey vital information about the project, and communicate the entire story to the reader. The information for each section of the executive summary is extracted from the detailed sections of the business case that you have just completed. Situational (or current state) assessment and problem statement The situational assessment (or current state assessment) is the details regarding the problem or opportunities facing the organization. It is a statement about what is happening in your organization today. Most projects are started by the original project stakeholder or champion because something is wrong, or a major opportunity is being missed. Every project usually has one or two key themes related to issues or opportunities. Project description The project description section introduces your reader to the details of the project. This section should give your stakeholders confidence that your team will professionally, efficiently and aggressively seek the best processes, systems, and organizational elements to enable your company to overcome the issues presented above. There are two main components of the project description: · description and scope · objectives Solution description The solution description section summarizes the solution that your team recommends to address the issues and opportunities presented in the situational assessment. The solution description should be written in the following order: · Concept overview · Solution detail · Sub-project structure · Solution alternatives Note: refer the Reengineering Design Toolkit for vision development and solution design guidelines. Cost and benefit analysis After the current state assessment, project description and solution design, the reader is now likely to ask, "What is the cost to get to the future state, and is it worth it?" This section will provide the answer to that question. A successful business case is not complete without a thorough analysis of the costs and benefits associated with implementing the proposed solution. But remember, determining the costs and benefits can be difficult. Implementation timeline Now that management understands the solution and the financial return that will be realized from implementing the solution, they will want confirmation that the solution can actually be implemented. This section will reassure management that your team has carefully and professionally considered all major issues of the implementation. A number of major elements are important to successful implementation. Your implementation section should address each area. · Implementation components · Implementation timeline · Major milestones · Major dependencies Critical assumptions and risk assessment Most business improvement projects will make assumptions in order to develop the solution. It is vital that the business case documents these assumptions. You should test your assumptions with project stakeholders and operational managers prior to placing them in the business case. The statement of assumptions should be followed by an impartial discussion of the strengths, weaknesses, opportunities and threats (SWOT) that are associated with the recommended solution. Finally, it is also important that the business case discuss the risks associated with both implementing and not implementing the solution. In other words, the key issues associated with going forward with the solution. Conclusions and recommendations This section brings closure to the business case. It should reiterate the key themes that caused the project to be undertaken. It should restate the solution in at a high-level. It should identify the return on investment and the overall benefits of the solution. It should restate the risks of doing nothing and re-convey a sense of urgency. Finally this section should state the conclusions the reader should draw from the business case, and your recommendations for next steps. Coming next: Module 3 will look at the different solution cost components of your project Business Case Tutorial Series How to write an effective business case Module 3 - "Rules of the Road" for calculating project benefits This tutorial series focuses on how to write a business case. Module 1 addresses why you need a business case and what role it serves. Module 2 provides an outline of a business case. This module provides tips and general rules for quantifying benefits. Module 4 provides a process and checklist for costs and benefits. Module 5 provides a model for activity based costing using the VTC process. Module 6 (concluding the series) examines how to present your business case and ensure that you have not forgotten key elements. This series is taken from Prosci's Business Case Toolkit which includes a complete business case template, guidelines, exercises, worksheets and checklists for developing an effective business case. It follows the series dedicated to project planning and reengineering design. Email this page to a friend Quantifying solution benefits The financial component is a central part of your business case. While the rest of the business case tells the story of your project, including the problem and the proposed solution, many business leaders will be focused on the financials. Your financial analysis will build on all of the other parts of your business case, but calculating the financial return will require skill and dedication. It will not be easy and you may encounter resistance. This tutorial provides guidelines and "rules of the road" for making financial calculations. With these rules as a guide, you can feel confident and support your financial conclusions when presenting your business case to your senior management and executives. "Rules of the road" for quantifying your solution benefits Your financial calculations must take into account several key rules that will guide your team when determining benefits. · Pay attention to time factors - One of the most important tips for quantifying your solution is to recognize and record costs and solutions when they happen. If a cost is required at the initiation of a project, be sure to include it at that point. Ongoing or recurring costs should be recorded when you expect to encounter them. Likewise, do not claim benefits until they actually happen and account for the learning curve of your employees (ramp up your benefits rather than claiming the full value immediately). · Select your time intervals carefully - In your analysis, use intervals based on your solution timeframe and the expectations of your senior leadership. Costs and benefits can be calculated on a yearly, quarterly or monthly basis - do whatever makes sense for your solution. However, keep in mind that the shorter the interval (e.g., weeks vs. years) that you select for your calculations, the more detail and scrutiny is required for the analysis. · Measure the difference between your solution and business as usual - Your benefits will be most credible if they show the difference between implementing your solution and staying with the current business practices. This comparison between the "do-nothing" scenario and your solution creates the most compelling argument for change. Remember that business as usual is not flat or static. If costs are rising over time, for example, then your comparison will be your solution over time compared to the trend of business as usual over time. · Document assumptions - While your team is doing their cost/benefit analysis and financial calculations, be sure to document every assumption you make, both about business as usual (BAU) and about your solution. Assumptions include solution variables as wellas leader decisions. These assumptions will be attached to your solution. In some cases, they may become the focus of discussion with leaders, but it is better to have assumptions that you can change and recalculate rather than not knowing how you arrived at a particular number. · Focus on activities, not resources - Calculations of net present value (NPV), internal rate of return (IRR) and return on investment (ROI) should be based on process changes that impact activities, not merely on headcount or FTE. Effective solution design will be changing the way work gets done, and your calculations should reflect this approach. It is not simply about headcount, but the change in work time, work volume, work processes and resource costs that you will need to communicate with your business case. FTE or headcount calculations are less effective and may not show the true impact of your solution. Moreover, many teams in the past have claimed FTE or full-time equivalent headcount reductions, when in fact no one left the organization. You must connect your cost savings and revenue increases with changes in "how" activities are done. That is why activity-based costing is the recommended approach that will be addressed in Module 5. · Be consistent - Be careful when calculating the cost or benefit that you are consistent in both the business as usual scenario and the solution scenario. For example, don't use today's labor rate for the "business as usual" forecast and a labor rate for five years from now for the solution scenario. Each year the labor rates may change but it should change the same in both scenarios. Traps to avoid There are several traps that many teams fall into when doing business case calculations: · Double and triple counting - Make sure that you only count benefits once. For example, if you use a fully loaded labor rate which includes the benefits from a reduction in overhead, then you cannot also calculate an overhead savings related to the headcount reduction in supervisors or managers. Double and triple counting will result in unrealistic financial calculations (another reason to use activity-based costing using the VTC process). · Claiming benefits too early - Your solution will probably not show benefits immediately, so do not begin calculating benefits from Day 1. Be sure to allow for implementation and learning time. Begin calculating benefits only when you think the benefits will be realized. If you claim benefits too early, your calculations will be greatly inflated. · Claiming benefits that would have happened anyway - Since you are measuring the difference between BAU and your solution, be sure to make accurate assumptions about the BAU scenario. For example, if raw material costs are declining due to improved market prices, you can not count a reduction in raw material costs as a benefit of the project (unless the redesigned process uses fewer raw materials). You want your calculations to reflect the improvement that result from your solution. · Quantifying the un-quantifiable - Some benefits of your solution will not be quantifiable (improved customer satisfaction, improved employee morale, etc.). While you could come up with an equation that may be able to assign a number to these benefits, do not mix "soft returns" with "hard returns." Document these benefits as part of your business case, but do fall to the temptation of including them in your financial analysis. This can decrease the credibility of your calculations and of your project as a whole. Facing resistance Quantifying solution benefits can create some resistance from team members, business leaders and those involved with the implementation. This is often a result of past experiences. Previous projects may have realized benefits on paper, but not in reality once they have been implemented. Quantifying benefits is also a difficult task, and many leaders are skeptical about how you have arrived at the financial return numbers for your project. Because of this potential resistance, you will need to be vigilant when doing your calculations. Several suggestions will help you counter this resistance. First, engage as much of the organization as you can while doing your financial analysis, especially the leaders you will be presenting your business case to. Getting buy-in from these managers and executives early in the process will alleviate some of their concerns later in the process. Second, be sure to document all of your assumptions. When leaders resist or question particular parts of your calculation, you can quickly and confidently show them the assumptions you have used. They may have different opinions on some of the assumptions, but you can easily recalculate a value if you know how you got the value in the first place. Lastly, be conservative when ever you have a question about a particular benefit or cost. Over estimate costs and underestimate benefits to avoid "ballooning" your solution's impact. It is always better to estimate a lower ROI and come in better than expected than to estimate a high ROI and come in worse than you thought. Conclusion Quantifying solution benefits is a difficult process that can create stress and resistance in your team and your organization. If you do it properly, it will pay off in a more powerful business case. The keys are to document everything, use a proven method for arriving at your numbers (coming in module 5) and validate your assumptions and methods with members in your organization (finance, leaders, impacted groups, etc.). Finally, be honest with yourself and the organization, and use integrity when making financial calculations. It will earn yourself and your project the credibility it needs to be a success. Coming next: Module 4 - checklists for costs and benefits Business Case Tutorial Series How to write an effective business case Module 4 - Checklists and processes for identifying costs and benefits This tutorial series focuses on how to write a business case. Module 1 addresses why you need a business case and what role it serves. Module 2 provides an outline of a business case. Module 3 provides tips and suggestions for evaluating benefits. This module provides a process and checklist for costs and benefits. Module 5 provides a model for activity-based costing using the VTC method. Module 6 (concluding the series) examines how to present your business case and ensure that you have not forgotten key elements. This series is taken from Prosci's Business Case Toolkit which includes a complete business case template, guidelines, exercises, worksheets and checklists for developing an effective business case. It follows the series dedicated to project planning and reengineering design. Email this page to a friend Project costs and benefits Module 3 looked at tips and suggestions as you begin to evaluate your project benefits. This module provides more detail about how to identify and categorize the costs and benefits of your project. It provides a framework and process for both costs and benefits to use as guidelines. The Business Case Toolkit includes complete process descriptions, in-depth analysis of each of the cost and benefit categories, and spreadsheets for capturing the impact of your project. Project costs Below are the general areas of project costs you may encounter in your project. Personnel costs: includes personnel associated with the project; only assign costs for the duration that the personnel cost are assigned. For example, the training developers may only be assigned to the project for a short time period, or may split their time between two teams. Personnel cost will include company resources involved in any aspect of the project, ranging from the design team, system development, system test and implementation resources. Overhead for project: includes overhead expenses that are incurred by the project personnel listed above during the duration of the project such as facilities, supplies and travel. Equipment costs: includes equipmentand applications (systems, tools, software, etc.) that are part of the solution to be implemented. Consultant support: costs for consultants used by the project. Operational transition costs: costs for items such as productivity loss during transition and training expense. Installation costs: costs for installation expense such as wiring, facilities, etc. Outsourcing costs: costs associated with moving work to other organizations or outside the company Cost identification process 1. Choose a facilitator and form your team. Form your cost team from members of the project team. We recommend including all key members of the project team in this process so that everyone has a common understanding of the costs, and how they are linked to the original project objectives. 2. As a team, use a Cost Checklist to identify all costs. You can create your own checklist or use the checklist in the Business Case Toolkit. 3. Once cost elements have been identified enter them into a spreadsheet. Designate a column for each year, quarter or month (whichever makes more sense for your project). For each cost element determine the costs for each time period. If no cost is incurred be sure to enter $0 so that you know that you have not forgotten to look at that cost element. Enter costs as a negative number. 4. Subtotal the costs for each area for each year. Total all costs for each year. This total will be used in the financial calculations to determine the Net Present Value (NPV) of your project and the Rate of Return (IRR). 5. If there are any costs that you were unable to quantify make sure that you make a note of them. They must be included in your cost discussion in the business case, even if they are not included in the financial calculation. Note: be sure to document and validate all assumptions. You should also keep track of where you get the numbers you use in your cost estimates (industry averages, supplier proposals, subject matter experts, impacted organizations, etc.). Cost conclusion Map your costs on a project timeline and use these estimates to prepare a formal budget for the project. You likely will not need all the money in one big chunk, but rather use it incrementally throughout the project. Most companies require financial analysis to span three (3) years. Some require five (5) years. Whichever the case, be sure that your recurring costs are included in every year of your spreadsheet for the life of the project. Remember - the costs discussed in this section are the costs for designing and implementing the solution - they do not include operational costs for running the business. These costs are identified during the benefits section. Note: You will need to assess whether your accounting group wants the project team to separate out capital expenses and account for depreciation. Also, tax implications of capital versus operational expenses may need to be addressed as well. For example, a capital expense of $1M will result in a tax burden in the first year that goes against the "Year 1" costs of the project. This tax burden is later recovered over the depreciation period. Types of benefits The general categories for business case benefits include: · Operational savings: Operational savings include all changes from the business solution that contribute to cost savings to the business. This area will be a primary focus of your project. · Improved customer satisfaction: Improved customer satisfaction includes all changes from the business solution that improve your customers' experience with your services and products. · Increased revenue and market share: Many business changes including reengineered processes contribute to increased revenue and market share or increased customer retention. If a direct link can be made between changes in the process and increases in revenue or market share, then these benefits can be included in the financial return calculation. If a clear link cannot be established, then mention these improvements as qualitative benefits only (e.g., the connection of customer satisfaction with customer retention may be listed as a qualitative benefit since an exact calculation may not be defensible for your specific change). · Improved employee satisfaction: Improved employee (associate) satisfaction is often the result of new processes and tools. Overall improvements for employees should be cited in the business case under qualitative benefits. Sometimes, however, employee satisfaction will directly affect productivity. If a direct link can be established between employee satisfaction and improved productivity, then they may be included in the operational benefits. Now that your team understands the types of benefits that can be derived from the project, it is time to identify your particular benefits. This step-by-step guide should assist you with this process. The Business Case Toolkit offers an in-depth analysis of this approach and presents a model to help you understand operational savings benefits and areas for incremental revenue. Step-by-step identification of benefits 1. Choose a facilitator and form your team. Form your benefit analysis team from members of the project team (we recommend including all key members of the project team in this process so that everyone has a common understanding of the benefits, and how they are linked to the original project objectives). 2. As a team, brainstorm the benefits that your organization will see from your project. The Business Case Toolkit includes a complete list of Benefit Questions you can use as triggers for the brainstorming exercise. Using a group for this exercise ensures that you do not overlook something about the solution that produces a benefit. Remember that you are looking for hard returns in terms of cost savings and incremental revenue, and looking for qualitative benefits such as increased customer satisfaction and employee satisfaction. We also recommend having stakeholders and operational managers participate in this exercise as this builds buy-in for the business case. 3. Eliminate redundancies and combine similar answers. As a group, read through your list of benefits. Combine areas that are similar and eliminate any redundancies. Categorize the items into natural groups. You may elect to use the same benefit groups identified above or you may elect to make up your own. 4. Identify gaps and oversights. Compare the benefits you identified with the original objectives for the project. Identify any gaps associated with this comparison. Once you are satisfied with your list of benefits you are ready to begin quantifying these benefits. Cost and benefit conclusion The cost and benefit analysis is important to the success of your project. A thorough analysis will ensure the following: · All benefits from the solution will be identified and quantified where possible. · Qualitative benefits will be clarified and made part of the business case. · High-level benefits will be validated with detailed analysis with all assumptions checked with the appropriate department. · The cost and benefit analysis will enable you to revisit your solution and prioritize solution elements or discard elements that do not produce benefits; this will directly impact how you implement the solution. The cost analysis will prevent you from overlooking costs associated with implementation and help you avoid surprises during the implementation process. Including your team and your organization will help prepare them for the implementation of the new solution by working through the costs and benefits analysis. The next module will focus on an approach for quantifying benefits. Activity based costing identifies the cost for each process activity your project impacts. It enables the team to quantify the cost of the activity both in the current business and after your solution, and thereby quantify any benefit from changes to that activity or the resources the activity consumes. Coming next: Module 5 - a model onactivity based costing and computing your financials Business Case Tutorial Series How to write an effective business case Module 5 - Calculating financial benefits for your project This tutorial series focuses on how to write a business case. Module 1 addresses why you need a business case and what role it serves. Module 2 provides an outline of a business case. Module 3 provides tips and suggestions for evaluating benefits. Module 4 provides a process and checklist for costs and benefits. Module 5 (this module) provides a model for activity-based costing using the VTC method. Module 6 (concluding the series) examines how to present your business case and ensure that you have not forgotten key elements. This series is taken from Prosci's Business Case Toolkit which includes a complete business case template, guidelines, exercises, worksheets and checklists for developing an effective business case. It follows the series dedicated to project planning and reengineering design. Email this page to a friend Calculating benefits using activity-based costing Many project teams skip an important step in the overall process of designing new business processes. That step is to quantify the actual cost savings and incremental revenue generation from their design. This tutorial is designed to show the best practice in quantifying business case benefits and calculating the financial impact of your solution. Activity Based Costing (ABC) is a simple and reliable mechanism to analyze the impacts on expense and revenue when there are changes in business processes. It is not only easy to learn, but it is easy to share your results with others and to validate your results with accounting. The benefits are: · Analysis of Return on Investment (ROI) and NPV. · A credible review of your total cost savings. · The ability to prioritize different components of your solution based on their financial impact. · Easy comparison of your solution to the "do nothing" scenario. Activity based costing is an accounting method that assigns costs to activities rather than products or services. This enables resource and overhead costs to be more accurately assigned to the products and the services that consume them. For example: Traditional costing Salaries $100 Equipment $80 Supplies $20 Overhead $45 TOTAL $245 Activity-based costing Clean door $40 Paint door $75 Inspect door $75 Send door to assembly $55 TOTAL $245 ABC doesn't eliminate or change costs, it provides data about how costs are actually consumed. In this example, if you wanted to reduce costs using traditional data you would have to decrease salaries, or decrease costs of supplies. Using an activity-based costing approach, you examine the activities or the process. You can see in the table that it costs the same to paint and inspect the door. Could these processes be improved or combined to lower the costs? Why use activity based costing? This standard accounting approach is useful to business process design teams for several reasons: · Business process design is rooted in the design of new processes. Therefore a process-based approach to analyzing cost savings is preferable over other methods. · Activity-based costing is well-understood by accounting departments and can stand the test of scrutiny when done properly. · Activity based costing addresses the actual work completed within a company and takes the focus away from headcount analysis or headcount reductions and places the focus on "how work is performed." · Activity based costing enables the assumptions behind the analysis to be very evident and allows for sensitivity analysis to check how critical your assumptions really are. How to do activity based costing for process design The process steps are: 1. Identify the customer triggers for your processes. 2. Draw a process flow for: 1) how it exists today and 2) how it will look with your solution. 3. Collect the cost elements for each activity in the flow. 4. Compare the present state (Business As Usual) and future state (Solution). The following directions help explain each step. Step 1 - Identify customer triggers A trigger is an internal or external event that initiates a process. For example, a customer needing to purchase a car triggers the individual car buying process. A customer with a full cart of groceries ready to check out initiates the check out process in a grocery store. A motor vehicle accident initiates a claim process for an insurance agency. A customer's phone that stops working triggers the telephone repair process. In these examples, the customer triggers were · Customer needs a new car · Customer ready to check out · Customer involved in motor vehicle accident · Customer's phone stops working · Internal database application triggers late payment alert "Customer" can also be an internal member of an organization. For your solution, you should begin by listing the customer triggers or events that initiate your processes.Triggers could also be internal business activities. Steps 2 and 3 - Define process flows for business as usual and your solution; collect the cost elements for each activity Drawing the process flow is as easy as identifying the primary activities and creating a flow chart. Start with the process as it is today. Begin with one of the customer triggers you identified in Step 1, and ask yourself "what happens next?" Continue until the process is complete. Then document the process as it will happen with the new solution. For example, in the check out of a grocery store customer, the current process could look as simple as: Figure 1 Your flow charts could be drawn by hand (e.g., on flipcharts in a group setting), in a drawing tool like MS Powerpoint®, or with a process modeling tool such as Visio® or iGrafx® Flowcharter. You may also consider using more advanced process modeling software that enables process simulations (more about process modeling in a future tutorial). For each activity in your process flow (each box), you will need to identify three activity-based costing elements: · Volume of transactions (per year) flowing through the activity · Time to complete the activity · Cost of resources (per minute) to complete the activity By multiplying these three variables together, you get the total cost of each activity in the process flow (V*T*C). If you take the sum of all the activity costs, the result is the total cost to complete that process. For example, if you do this analysis for the grocery check-out process, the diagrams and analysis shown below would result - where V is the volume of customers checking out, T is the time required on average to check out a customer, and C is the cost per minute of the grocery store employee. Figure 2 The new process for this example involves the implementation of automated self-service stations in the grocery store for customers to perform the check-out process on their own. The new process and associated activity-based costing elements are shown below. Figure 3 Note that in this process, the VTC for each activity is based on projections or estimates from the design team. These estimates are based on benchmarking results, pilots or trials, or assumptions by the design team. In the new process, C represents the cost of the equipment and maintenance for the self-service scanners. Note that the volumes (V) must still be consistent with the current process. Step 4 - Compare the business as usual against the new solution To compare these process costs, you will need to compute the cost of each process (the current process and the future process). The total cost for the business as usual or current process (per year) is: Figure 4 The total cost for the future or new process (per year) is: Figure 5 Note: if the period of time for volume is yearly volume, then the total cost will be yearly. If the volume were expressed in months, then the cost would be monthly (and so on). Computing the total cost savingsThe cost savings of implementing customer self-service is the difference between the old process costs and the new solution costs: Cost savings = $425,000 - $263,400 = $161,600 per year Key insights to take away from this analysis approach: · Any of the VTC elements of the new solution can be varied to test the assumptions of the design team. · Any number of process activities can be used. In this example, the maximum number was four activities per process as shown in the self-service solution. This number could have been 10, 50 or any number of activities that are needed to represent the old and new process. · Any business workflow can be analyzed with this approach so long as you can identify the activity-based costing elements including volume, time and cost per unit time. · The process is simple to do and simple to explain to others outside of the design team. The business case does not need to be "rocket science" to the rest of the organization. Analysis over time It is necessary to extend this cost saving analysis over a period of time to fully understand the impact of your new solution and to assess the cost savings year over year. Also, the solution investment over time must be taken into account to determine the Return on Investment (ROI) for your solution. The math to do this analysis over time becomes more involved than the simple equations used in the grocery example, but is easy to do with a simple spreadsheet tool. For one activity, the analysis would be: Figure 6 For the complete example, the resulting spreadsheet for a three year period is shown below. The notes column indicates why the numbers are changing. Figure 7 For many processes, this entire analysis can be done with a flipchart and a calculator. While a spreadsheet tool simplifies the process, but the basic concepts are easy to apply to any business process even if done manually. Wrapping up the analysis Once you have completed this step, you can calculate the return on the investment. By using the financial functions in MS Excel (see Insert Function for automatic calculation), the IRR or internal rate of return can be calculated. For this example, the IRR is: Figure 8 Summary Your business case should capture cost savings like shown in these examples. In addition, you should show other hard-returns such as incremental revenue from the new solution. An important rule to follow is to have your accounting department or CFO review your calculations to ensure: · your math is accurate · your assumptions are valid · your financial calculations for IRR and NPV (net present value) are done properly In addition, your business case should list soft-returns such as: · increased market share potential · improved customer service · improved employee satisfaction · reduced time to market For more information on calculating and quantifying benefits and the business case development process, see the Business Case Toolkit. Coming next: Module 6 - presenting your business case and key points from the series image2.gif image3.gif image4.gif image5.gif image6.gif image7.gif image8.gif image9.gif image1.jpeg