What’s Faster Than Real-Time?
When things happen, you have to be agile – figure out what happened right away, understand the impact, and immediately change your actions and plans appropriately. The faster you do it, the better. That’s self-evident, isn’t it?
Well, how fast can you be? Is it enough to respond with a few minutes or seconds, or does it have to be a millisecond? Is the ultimate agility where you respond instantly, or can you somehow do even better than that? Actually, you can, and you should.
Take rebounds in basketball, for example. Imagine a basketball player with lightning-fast reflexes and an awesome leap. He watches the ball hit the rim, sees the direction in which the ball bounces off, and immediately leaps to catch it. In most cases, his speed won’t help: someone who is just a bit slower will be there ahead of him. How does it happen? The trick is simple enough to describe, though is takes a lot of skill and practice: While the ball is still in flight towards the basket, predict where the ball will go if it rebounds, and move in that direction. If the ball rebounds, the best-positioned players will most likely get the rebound. If not, not much is lost. This is how prediction pays off, by responding before the event – indeed, faster than real-time. Of course, the other team’s players will try to position themselves well for the rebound, and you’d better predict that as well and prepare for it – often by collaborative and coordinated movements of the whole team.
So, “faster than real-time” is another way of saying that proactive is better than reactive, no matter how fast your reaction is. It isn’t easy in basketball, but you can’t be top players and teams without it. The same is true for field service: What if you knew that today’s workload is shaping up to be larger than usual? Could you do something about it? Certainly: You could move some preventive maintenance tasks from today to tomorrow, or you could dynamically change your appointment booking policy to offer fewer slots for today, etc. If you knew that a service engineer’s arrival at the next task location is likely to be delayed (e.g. using location monitoring, traffic updates or both), you could move the task to another engineer or reshuffle the engineer’s subsequent tasks. And if you knew how the numbers, locations and types of tasks would change next quarter, you’d know how to prepare for it. If you fail to do any of this, you’ll fail to score enough points with your customers. Even worse – your competitors may already be positioned to catch the rebound.