Skip to main content

Up YOUR Game – Become a Certified Process Design Engineer!

I find that there are many people that do not understand WHAT a Certified Process Design Engineer (CPDE) really is (be sure to scroll down on the page and then download the free whitepaper for surprising details). The CPDE role is likely much broader and deeper than you might think!

Time and Money?! Yes, but not at the expense of quality and stability! 

The role of a Certified Process Design Engineer is a critical skill set for all IT service providers. There are many frameworks and standards that define practices and methods for achieving success; ITIL 4, Agile, Lean, DevOps, COBIT, ISO, and Site Reliability Engineering (SRE) are only a few. My point is that while each describes processes and controls (what to do), they don’t provide clear, step-by-step methods and techniques for designing, reengineering and improving processes (how to do it). 

A Certified Process Design Engineer equips managers and staff at all levels to lead the organization to do the “right” things but also leads them in the “right” direction with a strategic and tactical perspective. This class can be taken virtually, is highly interactive and results in YOU as a Certified Process Design Engineer! Take action NOW and help drive your organization to success!

Fast-moving fluid cross-functional teams today are given more autonomy. This does NOT mean that governance, regulatory and risk requirements go out the window! To ensure quality, mitigate risk and ensure success you might want to become a Certified Process Design Engineer. Did you know that you can apply Agile and Lean to process design/Agile Service Management (ASM)? Did you know that instrumenting and optimizing the DevOps pipeline depends on the architecture and orchestration of that pipeline? In comes the role of CPDE!

Certified Process Design Engineer – Role:

  • Achieve a comprehensive understanding of an organization's service management capabilities, level of maturity and improvement opportunities.
  • Identify, understand, evaluate, and promote the use of multiple integrated best practice frameworks and standards (understand and explore/gain knowledge).
  • Provide recommendations to leadership on matters involving the use of best practices, frameworks, and standards to meet business goals (lead organization in the right direction).
  • Assist with the development of processes, policies, and goals.
  • Serve as a subject matter expert on matters involving process design improvement.
  • Work with development, project and process improvement teams to identify, justify and implement process improvement.
Survival today means that we must be responsive, move fast, deliver value and at the same time sustain a stable, antifragile environment. Brilliant process design ensures that we have “just enough” governance and "just enough" process to remain agile and move fast. 

Take Action Now! Become a Certified Process Design Engineer.

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…