Skip to main content

ITSM – We’ve Gone Loopy! [part 2 of 2 ]

In Part 1 we discussed homeostasis in animals and compared it to negative feedback loops required to stabilize and sustain performance via Continual Service Improvement systems for optimized service management.  Negative feedback loops allow for real-time self-correction in systems and therefore contrary to the name have a very positive effect for the delivery of services throughout the value stream.  Ok!  If negative feedback loops are positive then what about positive feedback loops and how might those be used for ITSM?

What is so positive about positive feedback loops?
In a positive feedback loop we see the target set point as a challenge to move away from. We strive to move beyond the set point or perhaps from one stage to another. Positive feedback loops are used when we want something to happen very quickly.  We can optimize and exploit with positive feedback loops.
Vivid childhood memories make real the lessons of patience as we waited for the fruit to ripen before we could pick it.  It was not ripe for so long and then just a few pears, or apples or cherries would begin to turn.  All of a sudden POW!  The whole tree was ripe!  How does that happen? 

Fruit on a tree is the target set point.  Let’s say we want to move from fruit on a tree to fruit that is ripe. The first cherry on the tree becomes ripe and transmits ethylene that ripens cherries close to it.  Those cherries create more ethylene and transmit it to ripen all the cherries close to them.  As the ripe cherries increase so does the ethylene causing the cherries to ripen at an increased rate until all cherries on the tree are ripe.
What if instead of reacting to Demand, or even managing demand our strategy was to exploit demand? Tying positive feedback loops and systems to our visions, aspires and strategies could change the landscape of service management as you know it today!

Positive feedback loops produce the desired outcome at an increased rate!  Application of positive feedback loops can be applied to any domain in the value network to optimize for the delivery of services. The only constant for any service provider is change and we know the poison Ivy effect from the loud contentious voices of resistance.  Likewise think of the results if we invested in the ethylene of a few to ripen those close to them on the tree!  Communication, knowledge and increased capability is your ethylene and can be monitored measured and exploited.
If demand is growing at an exponential rate year over year then positive feedback loops in our service management systems can provoke and optimize to control change at the same rate!  Not only aligning IT with the business but moving with it through controlled looped systems.  With negative and positive feedback loops the entire value stream becomes one organic system.  Service management becomes the service provider’s strategic advantage able to live, grow, and dynamically shift for business outcomes and customer value. 

Loopy Challenge:  What are some very real world examples for you and your organization of where or how both negative and positive feedback loops can be leveraged?  

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…