All entries for Saturday 27 October 2007

October 27, 2007

Ops Mngt Lesson 10 Exercise

This blog will apply the analytical tool called Fishbone diagram, also known as Ishikawa diagram, to the Global Warming effect. As seen in the picture below, the average temperatures in the earth have been constantly raising in the last century.


It is known, that one of the main causes for the temperature rise in the earth, is the greenhouse effect. One cause is the concentration of the CO2 gas in the atmosphere, that has been constantly increaed since measures exist as shown in the picture below.


The CO2 concentration is not the only cause for the global warming effect and on the other hand, the resons behind the CO2 increase have to be explored. The following Ishikawa diagram can be usefull to determine the root main causes for the global warming effect.

Global Warming Ishikawa diagram

The Ishikawa diagram is a kind of cause-affect diagram which is useful to search for root causes of problems.

Our diagram has five large bones which represents the main causes for the Global Warming effect. Off each of the large bones, there are smaller bones highlighting more specific aspects of every main cause. In example, for the Population main bone, we have the following specific aspects:

  • Methane produced by cattle raising
  • Green House production (apart from CO2)
  • Transportation (Cars, Flights... etc)
  • Power Demand for Heating, lights...etc

A lot of poka-yokes (Slack et al, pg 469) can be developed to reduce the global warming effect, in example a message in the low efficiency light bulbs telling the buyer, that the use of more efficient bulbs helps to reduce the global warming.




Study Notes lesson 10

Slack, N.; Chambers, S.; Johnston, R. and Betts, A. (2006) Operations and Process Management, London: FT Prentice Hall

Ops Mngt Lesson 8 Exercise


This blog will discuss about Lean management, assessing each step of a services process and deciding whether each step is adding value from Lean thinking perspective. I will also analyse delays, quality checking points and control flow.


In the diagram below, a simple process for Wintel (Windows servers running in Intel microprocessors) infrastructure incident resolution is depicted. Once a problem is identified by any of the identification groups a call is made to the Incident Manager who attends it and open a ticket into a ticketing system with all the information available provided by the customer.

Once the ticket is open, this is shown on the technician screen who checks if the incident refers to their group (the Wintel support in this case) and if not, it returns it to the incident manager for reassignment to another group.

If the technician accepts the ticket, he began working in the incident and may call the end user or the Incident Manager for additional information.

After some investigation, the technician can discover that the problem is an application problem and not an infrastructure and in this case it will send the ticket back to the incident manager.

Finally, when the incident is resolved he closes the ticket. The incident manager receives the closed ticket and checks if the solution is working for the customer. If the customer is not satisfied with the solution it will open another incident starting the process again.

WIntel Incident Process

Reflections and Observations:

For the lean perspective, every step in the process adds some value and the synchronisation between steps is performed by the ticketing tool, but there are some delays in the process which can be creating waste (Slack et al, p. 250). The identified delays are:

      1. Once the ticket is open (step 1), the ticket is waiting for an available technician to open it (step 2)
      2. If the technician determines the ticket is not of his responsibility it will send it back to the Incident Manager and it will have to wait to be opened again
      3. In steps 5 and 6 it happens the same than the previous point
      4. If the technician need additional information to resolve the ticket it will ask for it to another groups (step 9) which will add some delays
      5. Once the ticket is resolved, there has to be an available incident manager to check with the customer if he is satisfied with the resolution

      On the other hand, there is just one quality check point at the end of process where the incident manager tests the solution with the customer. Probably additional control point would be needed in order to improve the performance of the process.

      The throughput efficiency of the process doesn’t look very good. In the first place, there are many delays in the process and the process allows looping to occur. In example, if one ticket is assigned to the Wintel group, the person analysing it can send the ticket back to the Incident manager if he thinks the tickets it’s out of his scope, but the incident manager can assign again the ticket to the same group starting the process again. The process doesn’t have any mechanism to prevent this situation to occur and can happen in two different steps of the process (3 and 6).

      A more profound analysis following the Lean thinking should answer to the following questions:
            1. How many time is employed managing “false positives”
            2. How many time is employed managing application incidents (out of the scope of this process)
            3. How many time is employed managing repetitive incidents all related with the same infrastructure element
            4. How many time is employed with indents incorrectly assigned to the group
            5. What is the average resolution time by incident
            6. What is the open queue of every group

            An analysis of the previous items should lead to the definition and implementation of additional quality control points that will require ongoing measurement of several parameters.

            The analysis could lead to the following conclusions:

                • Too many wrong assignments made by the Incident Manager (step 1)
                • Excessive information request to customer or incident manager (step 9)
                • Poor problem determination or lack of definition (steps 3 and 6) leading to loops in incident resolution

                For which appropriate actions can be developed.

                Finally, from the control flow point of view , it looks like the ticketing system implements a pull control system (Slack et al page 356) being the tickets the signals needed for synchronisation. This is clear as if there’s no ticket in the system, nobody is “producing solutions” for problems that doesn’t exist. If this is the case, the organisation must provide with enough flexibility to use the available resources.


                Slack, N.; Chambers, S.; Johnston, R. and Betts, A. (2006)
                Operations and Process Management, London: FT Prentice Hall

                WarwickUniversity, study notes

                October 2007

                Mo Tu We Th Fr Sa Su
                Sep |  Today  | Nov
                1 2 3 4 5 6 7
                8 9 10 11 12 13 14
                15 16 17 18 19 20 21
                22 23 24 25 26 27 28
                29 30 31            

                Search this blog



                Most recent comments

                • Hi Thnnk you. The best advice I was ever given was from a management consultant many years ago. It w… by on this entry
                • Hi John, First of all, many Thanks for your all comments through all the blog. Yes, I've been grante… by on this entry
                • Hi In the example of 'grandfather knows best' in my earlier feedback – it also influences the role o… by on this entry
                • Hi Some of your examples in the Maslow model are more explicit than implicit – but if you think abou… by on this entry
                • Hi As you have applied for an extension (I'm not sure if it has been granted) I have looked your blo… by on this entry

                Blog archive

                Not signed in
                Sign in

                Powered by BlogBuilder
                © MMXXIII