October 27, 2007

Ops Mngt Lesson 8 Exercise

Foreword

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.

Introducción:

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.

                References:

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

                WarwickUniversity, study notes


                October 25, 2007

                Ops Mngt Lesson 6 Exercise

                This blog entry will discuss some examples for different strategies of medium term capacity planning, yield management and queue design.

                Level CapacityManagement:

                This strategy, keeps the production level (capacity) stable on the medium term. During the periods where production is below demand it builds inventory and where demand exceeds production, the inventory is consumed as shown in the picture below. The goal is to adjust capacity in order to balance the areas below and above the capacity, otherwise either we will have increasing inventory over the time or it won't be possible to satisfy demand.

                levelcapacity.jpg

                An extreme example of a company that uses this strategy could be a quality wine producer. This kind of business cannot adjust demand on the medium term as the amount of grapes produced by a vineyard plantation is quite fixed and growing more grapes in order to increase demand it takes years. Buying grapes to a third party is difficult as each quality wine producer uses a particular kind of grape. Of course they can harvest less grapes if the demand falls below expectations adjusting capacity in this way, but their strategy if this is the case, usually will be to lower the price, not reducing the quantity of wine produced.

                Chase Capacity Management:

                This strategy pursuits to match the capacity with the demand leadint to a resource optimization and inventory reduction compared with the Level strategy. 

                As an example, I will use a real example from my own experience that it's the way a Help Desk adjust their capacity (number of persons answering calls) according with the demand (number of incoming calls) in one particular day.

                In the picture below can be seen (in blue) the number of incoming calls and the number of people attending those calls at every time frame (in yellow).  

                chasecapacity.jpg

                It can be noticed how the curves are very similar and it's clear that chase demand has been used. It can also be seen that there is a shift between the demand curve and the capacity curve. This was a defect of the timetable containing the starting working hours of every Help Desk agent and had the effect of increasing the number of abandoned calls (red curve) that was just what the study tried to improve (reduce). Once the scheduling was corrected, a better matching between demand and capacity lead to a reduction of the number of abandoned calls.

                This strategy is used because it optimises the number of resources employed, in this case, mainly the number of Help Desk agents.

                Yield Management:

                This strategy tries to maximise the revenue from perishable fixed resources. I'll try to explain in this section how an utility company (Electricity Producer) it makes use of Yield Management.

                First of all, we have to clarify two aspects of electricty production:

                1. Electricity is a perishable resource. it has to be used or "destroyed", but you cannot store electricity.

                2. Usually an electricity producer uses a "chase demand" strategy that has some limitations. Commonly, they have a number of Nuclear Power generators that cannot be stopped to adjust for demand variations and that account for a big part of the production. They have also a number of Hydro plants, Fuel Plants...etc that they can switch on and off depending on the demand.

                Now that this is clear, the problem is that during night there's more electricity produced from Nuclear Power plants than the demand for it. So what the electricity producers can do about it? They use Yield Management lowering the price of the electricity during night, in order to increase the demand covering the capacity (very similar to the strategy followed by the airlines when they change the seat price when there is low demand)

                They use this strategy to obtain some revenue from a resource that won't produce any revenue at all if it is not consumed in the precise moment it's produced.

                Queue Design:

                Single Queue/Multi Server:

                This is a very common approach to queue design. An example could be a computer Operating System distributing jobs among different microprocessors. The supervisor of the operating system, waits for a microprocessor to be available and then sends the next job in the queue to this processor (this is the way computers used to work some time ago although now they use more sophisticated approaches).

                What is interesting from this example is that the supervisor can implement several strategies for managing the queue. The simplest of all is the FIFO (First In First Out) meaning that the first job that entered in the queue will be the first to go out.

                But the supervisor can also use a strategy call SJF (Shortest Job First) in which it will prioritise those jobs whose execution time is expected to be shorter.

                Multiqueue/Multiserver:

                This strategy is sub-optimum and is rarely used when all the servers serve the same resource (the example of the Business check-in resource at an airport, compared with the economy class desks is not valid as they are not serving the same resource). On the other hand, the queues formed at the different cashes of a supermarket are not a valid example either, as one person waiting at one queue will normally move to another when there is availability of a new cashier.

                A valid example for this queue design, could be the tolls of some highways when a separation exists among the lanes, so when you're in a

                particular lane you cannot change to another as you will normally have one or more cars behind you.


                October 21, 2007

                Ops Mngt Lesson 5 Exercise

                In October 2007, IBM announced that had awarded an outsourcing contract to AT&T which will provide outsourced telecommunication and networking services to IBM. The deal is worth $1 billion and it will last 5 years. IBM will transition an unspecified number of employees to AT&T. A link to the announcement follows:

                http://money.cnn.com/news/newsfeeds/articles/apwire/D8S13SKG2.htm

                This blog will analize the above case as an example of supply chain de-integration, but first a little of history about IBM supply chain de-integration.

                IBM succeeded with vertical integration for many years, in 1989 the company had $60 billion in sales and 420,000 employees. But from that point on, the company began to experience increasing competition from more agile competitors that were highly networked with strategic alliances focused on providing unique core competencies.

                After losing billions in the early 90s, IBM shifted from a command and control vertical integration to a service-based networked integration, shedding employees, and gaining back revenue.

                The AT&T outsourcing deal is one more of the many movements IBM took in the last years to de-integrate his supply chain

                Accordint to Slack et al (p. 75) the movement should benefit IBM in the following aspects:

                • Quality:  ST&T is a telecommunications company that is specialised in this area, quality should improve as the range of skills and economies of scale that AT&T have are bigger than IBM's.
                • Speed:  IBM requirements regarding speed can be built into the AT&T outsourcing contract in the form of SLAs (Service Level Agreements)
                • Dependability: Again, SLAs should assure delivery on time
                • Flexibility: The way the outsourcing contract will be built will determine the flexibility, but usually it exist a high range of variation that the contract permits, so in this case, the flexibility is increased a lot and this is, in my opinion, one of the main benefits of the operation.
                • Cost: One of the main reasons for outsource is reducing costs and headcount. In fact AT&T said that "the deal is not expected to materially impact its financial results", making clear that the company doesn't expect huge profits from the operation in the short term (although in the long term the deal could help AT&T to reinforce his position as a global communications provider)

                This is a long term relationship so can be considered as a partnership relation that has as main concept, according to (Slack et al p.216), the closeness of the relation ship is influenced by a number of factors, the following will take part in this deal:

                • Success is shared. From the deal, IBM will obtain flexibility, innovation and probable cost saving and AT&T will obtain reinforcement of his overall position as communications provider and an considerable source of revenue)
                • Long term expectations. Clear from the paragraph above
                • Problems will be solved together
                • A lot of information sharing

                Supplier selection is another important concept talking about supply chain de-integration, according to Slack et al p. 218, the following aspects, among others should be considered:

                • Range of product or services. Surely the range of products, regarding communications that AT&T has is very high, taking into consideration that this is their core business (and not IBM's)
                • Quality. Communications is the AT&T core business so the quality should be high
                • Delivery and volume flexibility. This will be assured by the outsourcing contract and facilitated by the economies of scale AT&T can achieve
                • Ease of doing business. IBM already signed an outsourcing contract with AT&T in 1998 that lasted several years so, IBM already know very well AT&T as a provider (see link below)

                http://www.internetnews.com/bus-news/article.php/23851

                The deal can also be seen as a movement towards what is called like "agile supply chains" (Slack et al, p.214) as the main objectives of the deal, from my point of view, are to increase responsiveness and produce innovative products.

                However the deal can have some disadvantages for IBM, compared to the current situation, among others:

                • If problems arises, these can be more difficult to trace as the visibility is reduced to the level that AT&T decide
                • Communicating of quality problems can be also difficult as these will have to be articulated by the mechanisms that the contract will provide
                • Improvements when needed will take more to implement (and may require contract re-negotiations)
                • Speed will be assured by the Service Level Agreement in place, but exceptions can be difficult to manage


                Ops Mngt Lesson 4 Exercise

                The Apple iPhone

                This blog entry will analyse the new apple iPhone which is the first entry of apple into the mobile world, dominated now by companies like Nokia, Motorola or Samsung.

                Apple iPhone

                Apple tries to do with the iPhone what they did with the iPod, putting a lot of technology and top level design into a device. The iPhone is truly a high tech device with a sleek interface, high quality music and video features, and innovative design. It's equipped with a touch screen, Internet connection and lots of software features

                In order to analyse the device, I will complete the quality function deployment matrix (QFD).

                The QFD Matrix for the iPhone

                The QFD matrix above, shows the key points, which brings customer preferred characteristics along with technical specifications.

                QFD iPhone

                The matrix shows in a visual way the relation between customer valuable features of the iPhone and the technical features that this device has. It can be seen that there exist many strong relationships between customer requirements and the technical specifications which is good, although it comes with a price, many of the high tech and nice features of the iPhone make the device very expensive (the iPhone costs more than 700€). Also the battery life is limited. in example the 8Gbs of memory increases the power requirements and reduces the time the phone can operate unpluged, given that the battery cannot be big because every piece has to be small (thin) in order to fulfil the design requirements.

                But the iPhone is really a piece of high tech, as en example the device it has some advanced and cool features such a motion sensor, that automatically adjust the display orientation when you flip the iPhone on its side while using the music and video players and the Internet browser. Also, a proximity sensor turns off the display automatically when you lift the iPhone to your ear for a conversation.

                Sumarising, the QFD shows clearly that this is a High tech device with no competition in the market in terms of technology, design or advanced features, but at a cost of reduced battery life and very high price.


                October 20, 2007

                Ops Mngt Lesson 2 Exercise

                Introduction:

                This blog entry will analyze two processes by profiling them, establishing process choices and layout decisions that have been taken. The process are:

                • The Service Desk Process
                • The Request For Services Process (RFS)
                The Service Desk is described in my previous blog entry. The RFS process in included in the serviced provided under an outsourcing contract and allows to the customer to request new services that are outside of the scope of the contract. As an example, we can imagine that the customer need a new system to manage the company Inventory, then asks IBM by means of the RFS process to install, configure and move into production the new system.

                Profiling the Service Desk process:

                Volume:

                The Service Desk process is typically a high volume process. In a medium size Help Desk, thousands of calls can be managed by year.

                Variety:

                The part of the process related to call management is totally standard (a call it’s just a call) so no variation at all. The part of the process related to incident resolution has some level of variation although in my opinion is low for the following reasons:

                • The scope of the services provided is well defined (and reduced)
                • There is standardization on the types of requests (either new software installation or password reset, there is a well defined catalog of services that the Help Desk provides)
                • If the incident is too complex the Help Desk will transfer it to another group outside Service Desk
                • There is a knowledge database which effectively reduces variability by transforming and "unknown problem” to a know one with documented resolution. The knowledge database in my opinion, reduces the perceived variety

                Variation in Demand:

                Although there is high seasonality (number of calls during working days vs weekend days, in example), this is in general highly predictable (not taking into consideration the singular events described in my previous blog entry, which on the other hand are not predictable and are very infrequent). Managing the capacity (between certain levels) is easy just by scheduling the working times of the agents, the effective variation in demand (defined as the variation that can cause headaches to the operations manager) is low.

                Visibility:

                The Service Desk process has high visibility as almost the entire process is visible to the user of it.

                Service Desk profile

                Profiling the Request for Services process:

                Volume:

                The number of new projects that a customer can sponsorize is very limited, so the Volume of the request for Service process in an outsourcing contract is typically medium-low.

                Variety:

                The variety is very high. Every project will have his own solution (from architectural point of view), his own hardware and software products and will require a different skill set every time, even will require skills that are not available in the organization and will have to be contracted.

                Variation in Demand:

                The variation on demand is medium-low, although there is strong seasonality, usually exist an schedule months before the project commencement date.

                Visibility:

                The visibility is also medium-low. Mostly all of the process is similar to a manufacturing process. The customer ask IBM to produce something with well defined and documented specifications and when the job is done, the result is delivered to the customer. Unfortunately the specifications are not always completely clear and well defined and some interaction is needed during the implementation phase which makes the process less transparent to the requester.

                RFS profile

                Process choice of the Service Desk process:
                • Under the Slack et all taxonomy of process types it looks like the Service Desk is a “Mass Services” for the following reasons:
                • It serves high volumes but variety is controlled by means of catalog of services, escalation of complex problems to other groups…etc.
                • The Help Desk uses Knowledge systems with the intention of deskill the work.
                • The service is not customized and the customer has to accept that not every request can be solved by the Help Desk.
                • Value added is low (value is usually provided by the backoffice groups)
                • Customers spend few time on the service process (a big percentage of the calls can be attended and the incident solved in less than 5 minutes)

                It’s interesting to note that a company’s internal IT Help Desk is different from a Help Desk receiving calls from customers (i.e. an air flight company). The last one is more on the Mass Services than the internal IT Help Desk as its model implies less customization.

                Process Choice of the Request for Services process:

                The RFS process falls under Professional Services type of process as it implements unique projects using a different set of high level skills for every project. Project typically can range from two months to more than a year, so the customer spend considerable time in the service process. The customization levels are high and the is one project manager designed for every project in flight which is the focal point with the customer for everything related with the project.

                Layout decissions of the Service Desk process:

                Although the most efficient process layout from Low Variety-High Volume processes (according to Slack et al) is “Product Layout”, the implemented Service Desk process Layout looks more like a Functional Layout. The Help Desk agents are normally grouped by skills (i.e. front desk, back-office for applications, back-office for operating system…etc) and in some occasions even by language. When a particular group cannot solve a problem and the call has to be transferred to another group there’s a virtual flow of the customer from one group to another, similar to the patients flow from one section to another in Hospitals.

                This looks the most efficient way of organizing the work in a Help Desk. Having similar skills together has many advantages, from information sharing to economies of scale and the theoretical disadvantage of the time needed to travel from one functional group to another is minimized due to the fact that transferring a call between two groups is fast and easy and does not constitute a big issue for the customer.

                Layout decisions of the Request for Services Process:

                The request for service process is also organized like a functional layout. IT Technicians are grouped by skills (Database Administration, Operating System Windows, Operating System Linux, Mainframe…etc). When a new project arrives, the project manager do a breakdown decomposition of the work to be done and send every activity to the appropriate group taking into consideration dependencies and parallelizing when it’s possible. A specific tool is used to control all the activities in flight and the project manager is responsible for all the pieces fitting together the end of the process.

                References:

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

                WarwickUniversity, study notes


                May 2022

                Mo Tu We Th Fr Sa Su
                Apr |  Today  |
                                  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

                Tags

                Galleries

                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

                Loading…
                RSS2.0 Atom
                Not signed in
                Sign in

                Powered by BlogBuilder
                © MMXXII