« Oracle, why can't you predict what goes wrong ? | Main | Asking the community 'would Twitter improve the service level ?' »

You cannot put service 'on stock', how to manage the winter cold ?...

On a SIMI lecture from Gabriel R. Bitran I learned that there are 4 characteristics where service differ from normal 'goods'.   One of them is 'Simultaneity'. Services are simultaneously produced and consumed, you cannot put service 'on stock' to deploy when the market or conditions ask for it....

You might know that it's cold in the Netherlands.   We experience the first winter since 11 years and this means that the temperature ate night is -10 degrees C.  In these conditions many people suffer from problems with their car (e.g.  a frozen lock or doors or a dead and broken battery).   When this happens, the majority of these people call the ANWB/Wegenwacht to get help.  The process is that a mechanic 'on the route' is dispatched to the unfortunate car-owner to get him/her back on the road... (in 2009 till now, 6th of Jan they helped 20.000 car-drivers...).

And here I would like to come back to the characteristic from 'Simultaneity'. Because of this unexpected cold winter week, the demand on the service organisation is HUGE but.... it is very difficult to set mechanics 'on stock' to be deployed these 2 weeks.  You simply cannot clone mechanics to expand the team for these conditions.. 
As a result of this characteristic, there is a risk of a growing backlog (wait-time) and as a result less happy customers  (waiting in cold cars...).  The way the ANWB handles this situation is by making sure all resources are on the road early and making longer days. As a result, the number of people on the road and the number of cases per mechanic increase so the capacity is larger during this period.

In support we know similar situations.  When introducing a new product version (e.g. eBus V12/Db v11)  or on period- (year) end we see and increase of activity on the customer side. This often results in more calls to handle by support and development, with the same amount of engineers (no we do not keep the on stock ;-) ).   There are a few ways we anticipate on this...

  • By preparing, build experience and share this with the Oracle community so you can also avoid problems to happen.
  • By making sure we have the customers with 'pain' on our radar.  There is a team of people running a monitoring program where they, during the migration or go-live,  keep a close watch on the customer to make sure we understand what is expected and fix what has priority.
  • By keeping a close watch to the process and KPI's and adjust the process or resources when needed (you might have to wait a bit longer on a solution for non-urgent issues)

I can imagine that this service characteristic leaves some questions for you... what if it's me waiting in the cold car or who can help me when the upgrade fails ??    Some important lesson I learned is that you must make sure that you also anticipate on the situation (... change your battery in time, prepare upgrades) but equally important, make sure your service provider knows what you are doing so they can put your on their Radar screen, advice you on preventive measures and help you (with priority) when you run into unexpected problems.
..

Our lines are open...

Hans











TrackBack

TrackBack URL for this entry:
http://blogs.oracle.com/mte1521/mt-tb.cgi/9334

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About This Entry

This page contains a single entry from the blog posted on January 6, 2009 11:29 AM.

The previous post in this blog was Oracle, why can't you predict what goes wrong ?.

The next post in this blog is Asking the community 'would Twitter improve the service level ?'.

Many more can be found on the main index page or by looking through the archives.

Top Tags

Powered by
Movable Type and Oracle