iSixSigma

Involving Finance in Six Sigma – Do It Early and Fully

It is common to hear great claims of monetary benefits from various improvement initiatives. But how confident can a company be that those “benefits” – both cost saving and generation of additional revenue – actually impacted the bottom line? BHP Billiton Base Metals considered this question and found an answer through the involvement of its finance department in its deployment of Six Sigma.

With operations in four different countries on three different continents, the deployment was fairly complex, involving a variety of cultures, styles and languages. To assure confidence in project numbers, the company decided to have 100 percent of the reported benefits be calculated under the principles of a strict “benefit capture protocol” and subject to audit at any time. A finance leader was charged with putting together a network that allowed the company to standardize the calculation of the benefits and, more importantly, assure that every dollar reported as a benefit was realized.

This network was created allocating one finance department representative from each operations unit as a “business partner” to work with Six Sigma project teams.

Finance as a Business Partner

The key decision made at the design stage of the deployment was that finance had to be involved in the Six Sigma projects from the very beginning. Finance was included as a partner in the quantification of the “burning platform” as well as the deployment design. This may sound easy, but in fact it was not, especially in the beginning. Many operations people see the finance people as bookkeepers, scorekeepers or auditors. They typically do not like it when “those finance guys” get involved in operational decisions. This was the first big barrier to overcome.

It was made mandatory that any idea that had the merit to become a Six Sigma project had to be reviewed by finance prior to going into the Six Sigma pipeline. Finance verifies that each possible project has potential to impact the bottom line. This prevents process owners from having to identify Six Sigma projects. Instead, they identify opportunities, and the financial evaluation is part of a business decision on whether or not the opportunity represents a viable Six Sigma project. A Six Sigma Steering Committee at each location makes that decision. Once approved, the project moves into the Six Sigma pipeline and is eventually allocated to one of the Belts. This step avoids wasting a Belt’s time and moves the process owners towards managing with data.

Handpicked Content:   Calculating ROI to Realize Project Value

Obviously there were many problems in the beginning. The Belts and process owners constantly complained about finance being the reason “good projects” were not moving into the pipeline. Later, the same Belts and process owners realized that many of those “good projects” were in fact pet projects, or that the potential benefits of some projects would not affect the bottom line. Throughput projects were a good example. A process owner might identify a good improvement project for their area, but if that area is not a bottleneck, the project will not affect the bottom line.

Throughout the DMAIC process, finance works closely with teams to identify the benefits of a given project. Many times projects actually report more benefits than process owners originally envisioned due to insight provided by the finance representatives. During this period, finance and the process owner agree on how the benefits will be calculated once the project is implemented. At the end of the DMAIC process, immediately before transferring ownership of the solution to the process owner, there is a second official review by finance and a recalculation of the expected benefits using the data gathered during DMAIC. Belts do not become involved with calculating the benefit. They can focus only on the DMAIC process.

A third and final review from finance is scheduled six months after the project has been executed. At this time, finance verifies whether the company is obtaining the benefits that were expected. If there is a significant deviation, the Belt in charge of the project goes back to the project and, in conjunction with the process owner, identifies the reason(s) why the performance is not as expected.

Handpicked Content:   Monitoring Return on Investment for Internet Initiatives

During the 12 months following the date solutions are implemented, the company captures and reports the benefits. After that period, a new baseline is calculated using the already improved key performance indicator (KPI). From that time forward, only incremental benefits beyond the new baseline are captured and reported. If there is room for additional improvement, a new Six Sigma project is generated. While the involvement of finance in a project begins before the involvement of the Belt, it also continues long after the Belt has transferred ownership of the solution to the process owner, as is illustrated below.

Advertisement

Some projects start capturing benefits during the DMAIC process since some portion of a solution may create immediate benefits even before the entire solution has been executed. Every month, all the benefits as well as the performance indicators are reported internally in a standard format. By doing this, there is continuous tracking on the KPIs that are being improved and also the financial impact of those KPIs on the bottom line. Both indicators are compared with the official target that was agreed to at the time the project was launched.

Benefits of Having Finance Fully Involved

1. Integrity. By having a different entity (finance) calculating the benefits, it is possible to avoid the temptation by a project team to record potential benefits instead of real benefits. With integrity embedded in the process, the company is confident that the results are real. It also allows teams to focus only on improving the KPI, without worrying about financial results. If the KPI improves, by definition the bottom line will be impacted.

Handpicked Content:   Six Sigma Costs and Savings

2. Standardization of calculation method. Sometimes inconsistencies can be generated because different people have different ways of doing things. Insistence on a single process which makes sure every operation calculates the benefits in the same manner creates results that are always comparable.

3. Avoidance of recording incorrect benefits. When the calculation of benefits resides with process owners, they might fail to take into account other processes outside their project, which are affected by their actions.

4. Results available for being audited. As with any other activity in finance, project benefits are subject to audit. Operations units are encouraged to have internal audits as well as to invite other groups within the company to review benefits calculations.

5. Budget mechanism. Any improved process has to be embedded in the next budget or financial forecast. This is the only way to make sure those improved KPIs will be as permanent as possible.

6. Finance with a pro-active approach. Effectively, there is one finance member away from his desk, working in the field. In companies that devote large efforts and resources from the finance department in the accounting-to-reporting process, this becomes an important leverage for both understanding the business better and influencing the results of the company.

7. Accountability. Finance becomes responsible for calculating and reporting the benefits.

By applying financial knowledge, business savvy, change management and common sense, the finance department knows with certainty that the company’s Six Sigma program has accomplished beyond what was targeted a year ago.

Comments 4

  1. Jud VanWyk

    Yes, finance’s early involvement may be beneficial in accurately determining benefits. BUT, should CI actions (projects) be limited to those that have a measureable bottom-line impact? If the benefits are nebulous, it’s not worth the effort? Are you sure?

    0
  2. Chris Seider

    I’d suggest that financial initial review happen during the 6S committee review. It’s kind of unrealistic to expect baseline data and goals to be specifiied before the end of the Define phase. Without knowing specific goals and baseline numbers (not known at high level 6S committee reviews), then why have a definitive stamp of approval outside of the 6S committee. The committee ought to have finance/business alignment within the committee review before being passed along as reasonable projects. Finance ought to be involved before closure of the define phase after goals, baselines, project boundaries are well defined.

    My two cents.

    J. VanWyk’s statement was very appropriate.

    0
  3. Mike Carnell

    Just some thoughts on what is generally a good article.

    First this is not a new concept. Extensive resources were used during the Allied Signal deployment in 1995 – 1996 to make sure the finance calculations were reasonable. Since that time in the design phase of deployments since then we have a documented procedure agreed to in how benefits calculations are done. During the BHP Billiton deployment we had a full time finance person assigned to the deployment (first year only) to assure that the document was adhered to. There are articles available on the site written by Cristian Ulloa about some of the issues he dealt with (2 part article).

    We did the same document during the Lonmin deployment that withstood 2 audits by major accounting firms that not only passed the audit but also stated that the benefits were understated. What we did learn from that experience was that the calculations document was the first thing the auditors asked to see. Without that document the audit would have been much different. We also had a full time accounting person attached to that deployment that worked on the project financial models which increased all the “belts” understanding of the business not just the technology.

    There is a distinct difference between a finance person and an accounting person. The finance person was much more useful in getting people to understand benefits. An example would be when we broke a bottleneck loose the accountants only saw increased cost because we were processing more material. The finance person understood the business impact.

    The other issue is “bottom line impact.” Not all projects make a bottom line impact i.e. safety projects. I am sure you can attach a dollar value to a fatality or even an injury but that is not why those projects are selected. There is a moral obligation.

    We also book benefits two ways. First is the annualized benefit that gets booked at the end of a project. This is basically a forecast. Monthly we check the benefits and move money from annualized to realized (what was actually measured). Two benefits to this. First you have a factually and auditable number of the benefit. Second is lets you identify projects that have implementation issues. That is what we call leakage. Leakage is when a project under delivers and the opportunity for the full financial benefit is lost you can react immediately to identify the issue. Basically the benefits calculation becomes a tool for change management.

    Just my opinion.

    0
  4. Mike Carnell

    All right I screwed up big time. I didn’t realize Crisitian had written this article and he was our finance guy on BHP Billiton (probably obvious since I cited his own article to him – as if he hadn’t seen it). Nobody better on a Six Sigma deployment.

    Chris Seider was on the Lonmin deployment so he has seen the stuff we did there which was built on what Crisitian did at BHP Billiton.

    My apologies Crisitian. Consuelo is cracking up over this.

    0

Leave a Reply