1. [PROJECT] FINDINGS AND RECOMMENDATIONS FEBRUARY 28,2010

2. 210/25/2015 Background and Problem Definition Problem Definition  Description of the analysis request and objective  Scope of what was investigated The Findings and Recommendations is used to document the preliminary analysis of a perceived problem. Its purpose is to define the root cause and provide recommendations or next steps for resolving the problem. Since the Findings and Recommendations may become incorporated into the Business Case, the topic format should be consistent with the Business Case format.

3. 310/25/2015 Background and Problem Definition  Conducted interviews with Purchasing and Accounts Payable SMEs  Conducted structured walkthroughs of Purchasing and Accounts Payable process  Prepared workflow diagrams of the Purchasing and Accounts Payable process Approach The following methods were used in analyzing this problem:

4. 410/25/2015 Findings Current State Description of Current State of the process being analyzed  The current process is manually intensive and takes 2-3 weeks to process a vendor invoice  Invoice Processing manually records information on a Processing Form, then enters it into the system  Two copies are made of the Invoice and Processing Form, which are sent to Accounts Payable and Purchasing. The originals are filed for reference High level description of the current process, issues/risks and opportunities for improvement.

5. 510/25/2015 Findings Areas Impacted The problem impacts the following functional areas/systems  Purchasing System  Accounts Payable System Opportunities for Improvement  Implement automated interface between Purchasing and Accounts Payable System  Use central document management system to store and share copies of invoices

6. 610/25/2015 Recommendations Assumptions and Risks  Purchasing and Accounts Payable Systems will not be replaced  Processing information can be entered directly from the invoice  Processing costs will continue to be high if improvements are not implemented Define assumptions/constraints, recommendations, and costs/benefits of the recommended solution (if applicable) Alternatives Considered  Purchasing enterprise software that includes all Accounting functions − Current systems are customized and would be difficult to replace − Cost is prohibitive at this time

7. 710/25/2015 Recommendations Description of recommended solution  Anticipated Benefits  Estimated Cost  Challenges

8. 810/25/2015 Next Steps ActionResponsibleDue Date This section is used to assign responsibility and a completion date for the identified tasks required to move to the next phase of this project.

9. 910/25/2015 Appendix 1 – Workflow Model Guidelines Business Analysts use Workflow models to document and analyze current and future state business processes and identify opportunities for process improvement. A workflow model is used to describe the tasks, decisions, inputs, outputs, people and systems involved in a specific process. Workflow models show: - How various tasks and departments interact with each other - How information flows through the business area - How workers are involved with each business activity General Guidelines 1. Flowchart should depict the entire process. If more than one process is involved, it should be depicted on a separate flowchart. 2. Use ‘swim lanes’ to denote each department or function. Swim lanes can be either horizontal or vertical depending on the needs of the process. 3. Steps should flow downward to depict flow over time, except when the activity returns to a previous step for correction

10. 1010/25/2015 Appendix 2 – Root Cause Analysis Guidelines Overview Root cause analysis (RCA) consists of problem solving methods used to identify the root cause of problems or events. RCA is based on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, the likelihood of problem recurrence will be minimized. However, it is recognized that complete prevention of recurrence by a single intervention is not always possible. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement RCA consists of the following steps: 1.Define the problem. 2.Gather data/evidence. 3.Identify the causal relationships associated with the defined problem. 4.Determine which causes if removed or changed will prevent recurrence. There are a large number of techniques that can be used in Root Cause Analysis. Cause and Effect Diagrams Cause and Effect diagrams (also called Ishikawa diagrams or fishbone diagrams) are a technique to graphically identify and organize many possible causes of an event. Possible causes are grouped into major categories to identify these sources of variation. These can then be narrowed down to a small number of main, root causes which need to be addressed. The diagrams help the team identify the most likely cause of the problem. Cause-and-effect diagrams are designed to: Stimulate thinking during a brainstorm of potential causes Provide a structure to understand the relationships between many possible causes of a problem Give people a framework for planning what data to collect Serve as a visual display of causes that have been studied Help team members communicate within the team and with the rest of the organization

11. 1110/25/2015 Appendix 2 – Root Cause Analysis Guidelines Causes can be derived from brainstorming sessions using the following steps. 1. Determine the problem to be analyzed. Make sure that the problem is specific, tightly defined and relatively small in scope. 2.Determine the major categories that could be the possible cause. The categories typically include: People: Anyone involved with the process Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws Machines: Any equipment, computers, tools etc. required to accomplish the job Materials: Raw materials, parts, pens, paper, etc. used to produce the final product Measurements: Data generated from the process that are used to evaluate its quality Environment: The conditions, such as location, time, temperature, and culture in which the process operates Note: these categories may not fit every situation and different categories might be appropriate. However, the total number of categories should not exceed six. 3.Set up a blank diagram on a white board or flip chart. Enter the problem in the Effect box and the categories identified in Step 2 along the spines.

12. 1210/25/2015 Appendix 2 – Root Cause Analysis Guidelines 4.Brainstorm all possible causes and label each cause under the appropriate category. (For more detail, see Section 2.4 Brainstorming). It is useful to write the possible causes on Post It Notes first, assign them to categories after the brainstorming is finished and then place the Post Its on the diagram. 5.Rank all possible causes according to likeliness to be a root cause and circle the most likely ones for further study and consideration. 6.Investigate the circled causes. Brainstorming Brainstorming is a process in which a group quickly generates as many ideas as it can on a particular problem. Brainstorming is useful because it uses the collective brainpower of the group to generate many ideas. Guidelines for conducting a successful brainstorming session are: 1.Collect a mixed team representing all parts of the process 2.Have impartial facilitator conduct the session. The facilitator should not lead the session, but keep it moving and prevent value judgements from being made 3.Assign two people to write ideas down on a flip chart or white board so that all ideas are captured 4.Go for quantity rather than quality of ideas; ideas can be ranked later 5.No judgements – every idea is a good idea 6.Stop the session after sufficient ideas have been gathered

13. 1310/25/2015 Appendix 2 – Root Cause Analysis Guidelines The Five Whys The Five Whys is a question-asking method used to explore the cause/effect relationships underlying a particular problem. Ultimately, the goal of applying the Five Whys method is to determine the root cause of a defect or problem. The following example demonstrates the basic process: 1.Write down the specific problem, i.e. My car will not start. This helps formalize the problem and describe it completely. 2.Ask Why the problem happens and write down the answer below the problems, i.e.the battery is dead. 3.Ask Why again and write that answer down, i.e. the alternator is not functioning. 4.Repeat asking Why until you feel the root cause has been reached. This may be more or less than five whys. The "five" in Five Whys is not gospel; rather, it is postulated that five iterations asking why is generally sufficient to get to a root cause. The real key is to encourage the troubleshooter to avoid assumptions and logic traps and instead to trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem. Although a generally accepted technique, the Five Whys has its drawbacks: Tendency for investigators to stop at symptoms rather than going on to lower level root causes. Inability to go beyond the investigator's current knowledge - can't find causes that they don't already know Lack of support to help the investigator to ask the right "why" questions. Answers to the Whys are different depending on who is being asked.