[PROJECT]FINDINGS AND RECOMMENDATIONS

FEBRUARY 28,2010

2 04/20/23

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 04/20/23

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 04/20/23

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 04/20/23

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 04/20/23

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 04/20/23

Recommendations

Recommendations

Description of recommended solution

Anticipated Benefits

Estimated Cost

Challenges

8 04/20/23

Next Steps

Action Responsible Due 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 04/20/23

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 Guidelines1. 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 04/20/23

Appendix 2 – Root Cause Analysis GuidelinesOverview

 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 04/20/23

Appendix 2 – Root Cause Analysis GuidelinesCauses 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 04/20/23

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.

BrainstormingBrainstorming 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 process2.Have impartial facilitator conduct the session. The facilitator should not lead the session, but keep it moving and prevent value judgements from being made3.Assign two people to write ideas down on a flip chart or white board so that all ideas are captured4.Go for quantity rather than quality of ideas; ideas can be ranked later5.No judgements – every idea is a good idea6.Stop the session after sufficient ideas have been gathered

13 04/20/23

Appendix 2 – Root Cause Analysis GuidelinesThe 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.