Skip to main content

CPDE and Six Sigma

I was asked recently how Certified Process Design Engineer® (CPDE) and Six Sigma might work together. I was also asked to clarify the value of holding a Certified Process Design Engineer® certification. To deal with these questions we must first clarify the difference between CPDE® and Six Sigma. First CPDE® is a role and a set of methods and approaches for that role to use in defining, designing and implementing strong IT Service Management processes. Six Sigma is a quality framework based on the work of men like W. Edwards Deming, Joseph Juran and Philip Crosby (the Big Three of the quality movement) and developed out of Motorola’s efforts to improve quality. The two are not at odds, rather they complement each other.

A CPDE has the skills to look at an organization, understand its culture, its approach to process and quality and its need for improvement. Once this assessment is done (using tools like the ITIL Process Maturity Framework, or CMMI) the CPDE would identify which elements or aspects of all the available ITSM frameworks (including Six Sigma, Microsoft Operations Framework, CObIT, TOGAF, Zachman, and any number of others) could become part of an appropriate mix of approaches to meet the unique needs of a company’s customers and challenges. This proprietary mix of elements could then be continually improved or changed by the CPDE to meet ongoing or future challenges or needs.

A CPDE would be versed in how the various frameworks work and interact; which framework is right for a given issue or challenge; how to assess the maturity of an organization and their current efforts; how to make improvements to processes, culture and organization to better succeed in meeting challenges.

An example might suffice in this situation. Let us say we have a large organization in an electronics manufacturing industry. It has a number of clients who have large orders. Our organization is having difficulties meeting these orders because the manufacturing line computerized equipment keeps failing. This causes delays in producing the orders and the quality is not meeting the needs of the clients who begin to become dissatisfied. The business is looking to IT to help fix the situation because they support the computerized equipment.

A CPDE would be able to look at the situation and recognize that lack of good design processes, as well as incident management, problem management, project management and continual improvement are all lacking. They could then recommend to the IT department that efforts be made to use ITIL, Project Management Book of Knowledge and Six Sigma methods to help improve the situation. The CPDE could then lead the effort to define and develop these approaches and help see them get implemented and maintained over time.

So a CPDE is a type of internal consultant, expert, auditor, project leader and implementation leader who brings the right elements and parts together to create the correct solution for a given issue or challenge or need to be met. This might be through Six Sigma or ITIL or a large selection of available methodologies, frameworks and standards.

When first introduced to the role of the CPDE I thought “what a brilliant idea”. Here, finally, was a way to be taught and shown the proper way to help an organization succeed in their ITSM effort. I have long sought for a definitive approach to being a consultant to others without only being very smart about a subject. Being a Professor I know well that just having knowledge of a subject does not mean you automatically know how to teach, train or lead others in executing an action. The role of CPDE helps to fill that gap for the implementation of ITSM and the associated processes and frameworks by having the knowledge of how to implement the best combination of elements for their organization.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…