BCP

Business continuity planning (BCP) is “planning which identifies the organization's exposure to internal and external threats and synthesizes hard and soft assets to provide effective prevention and recovery for the organization, whilst maintaining competitive advantage and value system integrity”.^[1] It is also called Business continuity & Resilency planning (BCRP). The logistical plan used in BCP is called a business continuity plan. The intended effect of BCP is to ensure business continuity, which is an ongoing state or methodology governing how business is conducted.

In plain language, BCP is working out how to stay in business in the event of disaster. Incidents include local incidents like building fires, regional incidents like earthquakes, or national incidents like pandemic illnesses.

BCP may be a part of an organizational learning effort that helps reduce operational risk associated with lax information management controls. This process may be integrated with improving information security and corporate reputation risk management practices.

A BCP manual for a small organization may be simply a printed manual stored safely away from the primary work location, containing the names, addresses, and phone numbers for crisis management staff, general staff members, clients, and vendors along with the location of the offsite data backup storage media, copies of insurance contracts, and other critical materials necessary for organizational survival. At its most complex, a BCP manual may outline a secondary work site, technical requirements and readiness, regulatory reporting requirements, work recovery measures, the means to reestablish physical records, the means to establish a new supply chain, or the means to establish new production centers. Firms should ensure that their BCP manual is realistic and easy to use during a crisis. As such, BCP sits alongside crisis management and disaster recovery planning and is a part of an organization's overall risk management.

The development of a BCP manual can have five main phases:

1.     Analysis

2.     Solution design

3.     Implementation

4.     Testing and organization acceptance

5.     Maintenance.

Analysis

The analysis phase in the development of a BCP manual consists of an impact analysis, threat analysis, and impact scenarios with the resulting BCP plan requirement documentation.

Impact analysis (Business Impact Analysis, BIA)

An impact analysis results in the differentiation between critical (urgent) and non-critical (non-urgent) organization functions/ activities. A function may be considered critical if the implications for stakeholders of damage to the organization resulting are regarded as unacceptable. Perceptions of the acceptability of disruption may be modified by the cost of establishing and maintaining appropriate business or technical recovery solutions. A function may also be considered critical if dictated by law. For each critical (in scope) function, two values are then assigned:

• Recovery Point Objective (RPO) - the acceptable latency of data that will be recovered
• Recovery Time Objective (RTO)  - the acceptable amount of time to restore the function

The Recovery Point Objective must ensure that the Maximum Tolerable Data Loss for each activity is not exceeded. The Recovery Time Objective must ensure that the Maximum Tolerable Period of Disruption (MTPD) for each activity is not exceeded.

Next, the impact analysis results in the recovery requirements for each critical function. Recovery requirements consist of the following information:

• The business requirements for recovery of the critical function, and/or
• The technical requirements for recovery of the critical function

Solution design

The goal of the solution design phase is to identify the most cost effective disaster recovery solution that meets two main requirements from the impact analysis stage. For IT applications, this is commonly expressed as:

1.     The minimum application and application data requirements

2.     The time frame in which the minimum application and application data must be available

Disaster recovery plans may also be required outside the IT applications domain, for example in preservation of information in hard copy format, loss of skill staff management, or restoration of embedded technology in process plant. This BCP phase overlaps with Disaster recovery planning methodology. The solution phase determines:

• the crisis management command structure
• the location of a secondary work site (where necessary)
• telecommunication architecture between primary and secondary work sites
• data replication methodology between primary and secondary work sites
• the application and software required at the secondary work site, and
• the type of physical data requirements at the secondary work site.

Implementation

The implementation phase, quite simply, is the execution of the design elements identified in the solution design phase. Work package testing may take place during the implementation of the solution, however; work package testing does not take the place of organizational testing.

[edit] Testing and organizational acceptance

The purpose of testing is to achieve organizational acceptance that the business continuity solution satisfies the organization's recovery requirements. Plans may fail to meet expectations due to insufficient or inaccurate recovery requirements, solution design flaws, or solution implementation errors. Testing may include:

• Crisis command team call-out testing
• Technical swing test from primary to secondary work locations
• Technical swing test from secondary to primary work locations
• Application test
• Business process test

At minimum, testing is generally conducted on a biannual or annual schedule. Problems identified in the initial testing phase may be rolled up into the maintenance phase and retested during the next test cycle.

Maintenance

Maintenance of a BCP manual is broken down into three periodic activities. The first activity is the confirmation of information in the manual, roll out to ALL staff for awareness and specific training for individuals whose roles are identified as critical in response and recovery. The second activity is the testing and verification of technical solutions established for recovery operations. The third activity is the testing and verification of documented organization recovery procedures. A biannual or annual maintenance cycle is typical.

Information update and testing

All organizations change over time, therefore a BCP manual must change to stay relevant to the organization. Once data accuracy is verified, normally a call tree test is conducted to evaluate the notification plan's efficiency as well as the accuracy of the contact data. Some types of changes that should be identified and updated in the manual include:

• Staffing changes
• Staffing personal
• Changes to important clients and their contact details
• Changes to important vendors/suppliers and their contact details
• Departmental changes like new, closed or fundamentally changed departments.
• Changes in company investment portfolio and mission statement
• Changes in upstream/downstream supplier routes

Testing and verification of technical solutions

As a part of ongoing maintenance, any specialized technical deployments must be checked for functionality. Some checks include:

• Virus definition distribution
• Application security and service patch distribution
• Hardware operability check
• Application operability check
• Data verification

Testing and verification of organization recovery procedures

As work processes change over time, the previously documented organizational recovery procedures may no longer be suitable. Some checks include:

• Are all work processes for critical functions documented?
• Have the systems used in the execution of critical functions changed?
• Are the documented work checklists meaningful and accurate for staff?
• Do the documented work process recovery tasks and supporting disaster recovery infrastructure allow staff to recover within the predetermined recovery time objective.

Treatment of test failures

As suggested by the diagram included in this article, there is a direct relationship between the test and maintenance phases and the impact phase. When establishing a BCP manual and recovery infrastructure from scratch, issues found during the testing phase often must be reintroduced to the analysis phase.

http://en.wikipedia.org/wiki/Business_continuity_planning 

SIX SIGMA - P2

Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or incidents. The practice of RCA is predicated 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, it is hoped that 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, initially is a reactive method of problem detection and solving. This means that the analysis is done after an incident has occurred. By gaining expertise in RCA it becomes a pro-active method. This means that RCA is able to forecast the possibility of an incident even before it could occur. While one follows the other, RCA is a completely separate process to Incident Management.

Root cause analysis is not a single, sharply defined methodology; there are many different tools, processes, and philosophies of RCA in existence. However, most of these can be classed into five, very-broadly defined "schools" that are named here by their basic fields of origin: safety-based, production-based, process-based, failure-based, and systems-based.

• Safety-based RCA descends from the fields of accident analysis and occupational safety and health.
• Production-based RCA has its origins in the field of quality control for industrial manufacturing.
• Process-based RCA is basically a follow-on to production-based RCA, but with a scope that has been expanded to include business processes.
• Failure-based RCA is rooted in the practice of failure analysis as employed in engineering and maintenance.
• Systems-based RCA has emerged as an amalgamation of the preceding schools, along with ideas taken from fields such as change management, risk management, and systems analysis.

Despite the seeming disparity in purpose and definition among the various schools of root cause analysis, there are some general principles that could be considered as universal. Similarly, it is possible to define a general process for performing RCA.

Basic elements of root cause

• Materials
• Defective raw material
• Wrong type for job
• Lack of raw material
• Man Power
• Inadequate capability
• Lack of Knowledge
• Lack of skill
• Stress
• Improper motivation
• Machine / Equipment
• Incorrect tool selection
• Poor maintenance or design
• Poor equipment or tool placement
• Defective equipment or tool
• Environment
• Orderly workplace
• Job design or layout of work
• Surfaces poorly maintained
• Physical demands of the task
• Forces of nature
• Management
• No or poor management involvement
• Inattention to task
• Task hazards not guarded properly
• Other (horseplay, inattention....)
• Stress demands
• Lack of Process
• Lack of Communication
• Methods
• No or poor procedures
• Practices are not the same as written procedures
• Poor communication
• Management system
• Training or education lacking
• Poor employee involvement
• Poor recognition of hazard
• Previously identified hazards were not eliminated

A CTQ tree (Critical to Quality tree) is used to decompose broad customer requirements into more easily quantified requirements. CTQ Trees are often used in the Six Sigma methodology.

CTQs are derived from customer needs. Customer delight may be an add-on while deriving Critical To Quality parameters. For cost considerations one may remain focused to customer needs at the initial stage.

CTQs (Critical to Quality) are the key measurable characteristics of a product or process whose performance standards or specification limits must be met in order to satisfy the customer. They align improvement or design efforts with customer requirements.

CTQs represent the product or service characteristics that are defined by the customer (internal or external). They may include the upper and lower specification limits or any other factors related to the product or service. A CTQ usually must be interpreted from a qualitative customer statement to an actionable, quantitative business specification.

To put it in layman's terms, CTQs are what the customer expects of a product... the spoken needs of the customer. The customer may often express this in plain English, but it is up to the CTQ expert to convert them to measurable terms using tools such as DFMEA, etc.

A Pareto chart, named after Vilfredo Pareto, is a type of chart that contains both bars and a line graph, where individual values are represented in descending order by bars, and the cumulative total is represented by the line.

Simple example of a Pareto chart using hypothetical data showing the relative frequency of reasons for arriving late at work

The left vertical axis is the frequency of occurrence, but it can alternatively represent cost or another important unit of measure. The right vertical axis is the cumulative percentage of the total number of occurrences, total cost, or total of the particular unit of measure. Because the reasons are in decreasing order, the cumulative function is a concave function. To take the example above, in order to lower the amount of late arriving by 80%, it is sufficient to solve the first three issues.The purpose of the Pareto chart is to highlight the most important among a (typically large) set of factors. In quality control, it often represents the most common sources of defects, the highest occurring type of defect, or the most frequent reasons for customer complaints, and so on.These charts can be generated by simple spreadsheet programs, such as OpenOffice.org Calc and Microsoft Excel and specialized statistical software tools as well as online quality charts generators.

Ishikawa diagrams (also called fishbone diagrams, cause-and-effect diagrams or Fishikawa) are diagrams that show the causes of a certain event -- created by Kaoru Ishikawa (1990)^[1]. Common uses of the Ishikawa diagram are product design and quality defect prevention, to identify potential factors causing an overall effect. Each cause or reason for imperfection is a source of variation. Causes are usually grouped into major categories to identify these sources of variation. 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

The 4 Ss (used in service industry)

• Surroundings
• Suppliers
• Systems
• Skills

The check sheet is a simple document that is used for collecting data in real-time and at the location where the data is generated. The document is typically a blank form that is designed for the quick, easy, and efficient recording of the desired information, which can be either quantitative or qualitative. When the information is quantitative, the checksheet is sometimes called a tally sheet.

A defining characteristic of a checksheet is that data is recorded by making marks ("checks") on it. A typical checksheet is divided into regions, and marks made in different regions have different significance. Data is read by observing the location and number of marks on the sheet. 5 Basic types of Check Sheets:

·         Classification: A trait such as a defect or failure mode must be classified into a category.

·         Location: The physical location of a trait is indicated on a picture of a part or item being evaluated.

·         Frequency: The presence or absence of a trait or combination of traits is indicated. Also number of occurrences of a trait on a part can be indicated.

·         Measurement Scale: A measurement scale is divided into intervals, and measurements are indicated by checking an appropriate interval.

·         Check List: The items to be performed for a task are listed so that, as each is accomplished, it can be indicated as having been completed.

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.^[1]

Sterneckert (2003) suggested that flowcharts can be modelled from the perspective of different user groups (such as managers, system analysts and clerks) and that there are four general types:^[9]

• Document flowcharts, showing controls over a document-flow through a system
• Data flowcharts, showing controls over a data flows in a system
• System flowcharts showing controls at a physical or resource level
• Program flowchart, showing the controls in a program within a system

Notice that every type of flowchart focuses on some kind of control, rather than on the particular flow itself.^[9]

SIX SIGMA - P1

Six Sigma has evolved over time. The concepts behind Six Sigma can be traced through the centuries as the method took shape into what it is today.

The roots of Six Sigma as a measurement standard can be traced back to Carl Frederick Gauss (1777-1855) who introduced the concept of the normal curve. Six Sigma as a measurement standard in product variation can be traced back to the 1920's when Walter Shewhart showed that three sigma from the mean is the point where a process requires correction. Many measurement standards (Cpk, Zero Defects, etc.) later came on the scene but credit for coining the term "Six Sigma" goes to a Motorola engineer named Bill Smith. (Incidentally, "Six Sigma" is a federally registered trademark of Motorola).

In the early and mid-1980s with Chairman Bob Galvin at the helm, Motorola engineers decided that the traditional quality levels -- measuring defects in thousands of opportunities -- didn't provide enough granularity. Instead, they wanted to measure the defects per million opportunities. Motorola developed this new standard and created the methodology and needed cultural change associated with it. Six Sigma helped Motorola realize powerful bottom-line results in their organization - in fact, they documented more than $16 Billion in savings as a result of our Six Sigma efforts.

Since then, hundreds of companies around the world have adopted Six Sigma as a way of doing business. This is a direct result of many of America's leaders openly praising the benefits of Six Sigma. Leaders such as Larry Bossidy of Allied Signal (now Honeywell), and Jack Welch of General Electric Company. Rumor has it that Larry and Jack were playing golf one day and Jack bet Larry that he could implement Six Sigma faster and with greater results at GE than Larry did at Allied Signal. The results speak for themselves.

Six Sigma has evolved over time. It's more than just a quality system like TQM or ISO. It's a way of doing business. As Geoff Tennant describes in his book Six Sigma: SPC and TQM in Manufacturing and Services: "Six Sigma is many things, and it would perhaps be easier to list all the things that Six Sigma quality is not. Six Sigma can be seen as: a vision; a philosophy; a symbol; a metric; a goal; a methodology." We couldn't agree more

When learning about Six Sigma, it may help to consider these charts, which detail how sigma level relates to defects per million opportunities (DPMO), and some real-world examples.

Sigma Performance Levels - One to Six Sigma
Sigma Level	Defects Per Million Opportunities (DPMO)
1	690,000
2	308,537
3	66,807
4	6,210
5	233
6	3.4

What Would This Look Like In The Real World?

It's one thing to see the numbers and it's a whole other thing to see how it would apply to your daily life.

Real-world Performance Levels
Situation/Example	In 1 Sigma World	In 3 Sigma World	In 6 Sigma World
Pieces of your mail lost per year [1,600 opportunities per year]	1,106	107	Less than 1
Number of empty coffee pots at work (who didn't fill the coffee pot again?) [680 opportunities per year]	470	45	Less than 1
Number of telephone disconnections [7,000 talk minutes]	4,839	467	0.02
Erroneous business orders [250,000 opportunities per year]	172,924	16,694	0.9

DMAIC

Define, Measure, Analyze, Improve, Control. Incremental process improvement using Six Sigma methodology.

DMAIC refers to a data-driven quality strategy for improving processes, and is an integral part of the company's Six Sigma Quality Initiative. DMAIC is an acronym for five interconnected phases: Define, Measure, Analyze, Improve, and Control.

---

Each step in the cyclical DMAIC Process is required to ensure the best possible results. The process steps:

Define the Customer, their Critical to Quality (CTQ) issues, and the Core Business Process involved.

  Define who customers are, what their requirements are for products and services, and what their expectations are

  Define project boundaries ­ the stop and start of the process

  Define the process to be improved by mapping the process flow

Measure the performance of the Core Business Process involved.

  Develop a data collection plan for the process

  Collect data from many sources to determine types of defects and metrics

  Compare to customer survey results to determine shortfall

Analyze the data collected and process map to determine root causes of defects and opportunities for improvement.

  Identify gaps between current performance and goal performance

  Prioritize opportunities to improve

  Identify sources of variation

Improve the target process by designing creative solutions to fix and prevent problems.

  Create innovate solutions using technology and discipline

  Develop and deploy implementation plan

Control the improvements to keep the process on the new course.

  Prevent reverting back to the "old way"

  Require the development, documentation and implementation of an ongoing monitoring plan

  Institutionalize the improvements through the modification of systems and structures (staffing, training, incentives)

 LEAN

"Lean" as defined by the MEP Network ...
"A systematic approach to identifying and eliminating the Eight Wastes (which are considered non-(customer) value adding activities) through continuous improvement by flowing the product at the 100% pull of the customer"

The Eight Wastes of Lean...

Waiting:

• Definition: The item/work in the process has stopped.
• Manufacturing examples: Machine downtime, bottlenecked operations, equipment changeover
• Service/Office examples: System downtime, system response time, approvals from others, information from customers

Defects:

• Definition: Any form of scrap, mistakes, errors or correction resulting from the work not being done correctly the first time.
• Manufacturing Examples: Production of defective parts, scrap or waste.
• Service/Office examples: Data input errors, design errors, engineering change orders and invoice errors.

Extra Processing:

• Definition: Having to do anything more than needed.
• Manufacturing examples: Taking unneeded steps to process the parts, inefficient processing due to poor tool and product design.
• Service/Office examples: Re-entering data, extra copies, unnecessary or excessive reports

Inventory:

• Definition: Any supply that is in excess, any form of batch processing. Producing more than customer demand.
• Manufacturing examples: Any excess inventory, batch processing.
• Service/Office examples: Office supplies, sales literature, batch processing transactions.

Excessive Motion:

• Definition: Movement of people.
• Manufacturing examples: Reaching for, looking for, or stacking parts, tools, etc.
• Service/Office examples: Walking to/from copier, central filing, fax machine or other offices.

Transportation:

• Definition: Movement of work or paperwork from one step to the next step in the process.
• Manufacturing examples: Move materials, parts, or finished goods into and out of storage.
• Service/Office examples: Movement of documents from site to site, office to office or in-basket to in-basket.

Overproduction:

• Definition: Producing more, sooner, or faster than is required by the next person.
• Manufacturing examples: Inventory piling up at a slower downstream step.
• Service/Office examples: Printing paperwork before it is really needed, purchasing items before they are needed, processing paperwork sooner than needed by the next person.

Underutilized Employees:

• Definition: People's creativity, ideas, and abilities are not fully utilized.
• Manufacturing examples: Losing ideas, skills, and improvements by not listening to employees.
• Service/Office examples: Limited employee authority and responsibility for basic tasks, management command and control.

http://en.wikipedia.org/wiki/Six_Sigma