Operations Management Lesson 3 Exercise
The selected process to map is the IBM Request For Service (RFS) process. The RFS process exists on all outsourcing contracts to deliver any client work that doesn’t exist within the base service contract. This process step is an important stage within the end project lifecycle of a company and is often the first visibility IBM has of the customers’ project portfolio.
HIGH LEVEL PROCESS MAP & OBSERVATIONS
Below is a high level process diagram (figure 3.1) of typical companies’ project lifecycle from identifying an idea or need all the way through to realising the benefits of that idea or need.
Highlighted in yellow is the IBM RFS process, which is a critical stage where many projects do not progress far beyond. At this stage the solution developed identifies the estimated costs, time and risks of the project, which are evaluated against the intended project benefits and enables a company to evaluate whether the project provides sufficient return on investment to progress into implementation.
DETAILED PROCESS MAP & OBSERVATIONS
The process is a best practice process applied to all IBM Outsourcing contracts and deals with a wide variety of requests in terms of volume and size, some clients submit only a few requests per month where as others submit more than one hundred per month. The requests vary from requesting some desktops to be moved (as little as one man days work) to developing a proposal to outsource the support of all our companies’ business applications (millions of dollars, to implement and provide an on-going service requiring labour, hardware and software services). Because of the variety, the time taken to pass through the process varies significantly from anywhere between two days to two months.
Below is a line of visibility process diagram (figure 3.2) of the RFS process from receiving a new RFS from the customer through to rejecting or releasing a proposal in response to the customers RFS.
Mapping the process onto a service blueprint (figure 3.2), shows that IBM have designed this process to be a predominantly back office function, where the customer does not have any visibility of the tasks being undertaken except where an interaction is required. This level of visibility for simple requests which can be processed quickly is probably sufficient, however as requests become more complex/large then this level of visibility could be quite disconcerting to the client as they are unable to observe the level of activity and direction of the solution.
Many of the outsourcing contracts have service levels in responding to simple & medium complexity requests, within a given period. As the process is long and thin, with no activities being completed in parallel, there is a high risk of delay within the process caused by growth in RFS volume or complexity or resource absences. Any delay will have a direct impact in delaying the release of the proposal response and poses a real risk to RFSs missing their service level target.
Therefore variable resourcing is needed to support the variety fluctuations in RFS volume and size, as well as dissolving bottlenecks as they occur. This is fundamental if the process is achieve some of its key objectives of delivering:
- Incremental Revenue
- Maintaining process overhead in-line/below revenue growth/decline
- Service levels
- Customer satisfaction
BIBLIOGRAPHY & REFERENCES
- Slack, N., Chambers, S., Johnston, R., Betts, A. (2006) Operations and Process Management, London: FT Prentice Hall
- Walley, P. (2007) The Warwick MBA: Operations Management, Coventry: University of Warwick
Effective map – but should there be an entry transportation activity?
Interesting comments. In outline, how is variable resourcing effected?
21 Oct 2007, 21:39
Add a commentYou are not allowed to comment on this entry as it has restricted commenting permissions.