May/June 2004

"Dynamic scheduling' is becoming a field service buzz-phrase, and in its new guise as Vidus, the former a.p.solve reckons it's ahead of the game

It might seem surprising for a spin-out company to change its name within a year of winning independence from its former parent. But it certainly doesn't seem to have done any harm to Vidus, which started life just over a year ago as a.p.solve, a spin-off from BT's Brightstar business.

The company was set up to focus on the task of managing field service delivery. That means functions such as assembling call-out requests into logical journeys, allocating them to field staff, scheduling the journeys and managing the whole process, including the wireless networking that supports it all.

The initials of the original name, a.p.solve, stood for "advanced planning"; the new name, Vidus, apparently means "reliability", and is arguably more wide-ranging. Stuart Potchinsky, who joined last year to spearhead the company's growth, says the market is changing. "The accent is more than ever on customer service," he told m.logistics. He says the rebranding is meant to underline this focus.

Whatever it's called, the company seems to be thriving. It has only a handful of customers so far, but they are impressive names. BT, perhaps inevitably, is still the biggest, accounting for half of the volume of Vidus's work; but the balance is changing fast. The company quotes a figure of 73 per cent as its growth rate since its spin-out.

The other big customers are Centrica, NTL and E.ON, the massive international power conglomerate whose subsidiaries include Powergen. And these are seriously big roll-outs. Centrica, for instance, will eventually be using Vidus systems to manage 15,000 technicians. E.ON, working on a rather smaller scale, is still using it to manage 1,500 technicians in Hungary.

Does this mean Vidus is not interested in smaller users? "Not at all," Potchinsky says. "It's more a question of complexity and unpredictability." He says Vidus's Taskforce product has been benchmarked at MIT with just 100 users. Where it really shines is in managing complexity, he maintains. "Scale is just one measure of complexity. It also depends on other factors such as number of locations, contingency activities, tightness of time windows."

He sums it up thus: "Taskforce is not for delivering washing machines. It's more likely to be for delivering catering supplies to airlines, or in construction projects."

But what about delivering and installing gas cookers, where several members of an installation team might have to be coordinated? Here Potchinsky relents. "Yes, it could certainly be good for that," he agrees.

service delivery

When you look at what Taskforce does, you start to understand his point. It sets out to manage all the resources necessary for ensuring service delivery. It sets appointments, builds schedules, and updates them "on the fly" (it can reconfigure journey plans by reassigning jobs among available staff).

Potchinsky is keen to put across the point that the product involves much more than just scheduling. As he puts it: "Scheduling is the "now', whereas Taskforce concentrates on the "pre' element Ð the "before now'."

To give some measure to this, he says scheduling accounts for perhaps 10 per cent of the product's effort, while changing the plan on the fly ranges up to 30 per cent. Most of the rest of the effort is taken up with marshalling stocks and resources, and synchronising them all to achieve a "first-time, right-time" service.

"Most customer service operators can only offer an am or a pm delivery," Potchinsky maintains, "whereas we've got E.ON offering two-hour slots in Hungary." He says in theory it would be possible to get down to half-hour slots, "though it does depend on the business model and available resources." He says he's not aware of any company in this business actually offering half-hour slots yet. "But maybe in a couple of years."

post-delivery functions

Taskforce also puts emphasis on post-delivery functions such as billing and updating database entries. The product doesn't however attempt to provide the computing capability to handle all the these functions; instead, it integrates with external databases holding information on stocks, staff, skills levels, service level agreements and so on.

Mention of SLAs prompts Potchinsky to raise a question. "SLAs measure something, but is it always the right thing?" he wonders. "Perhaps we ought to be developing an ELA Ð an "experience level agreement' that measures customer satisfaction instead?"

Taskforce also integrates with various mobile computing devices and communications systems. BT, for instance, uses Panasonic ruggedised laptop computers and GSM communications (though it might consider PDAs later, Potchinksy says). "They don't need to know where people are from moment to moment, so constant tracking isn't necessary." NTL by contracts is using GPRS from Orange.

The ability to build schedules on the fly is giving new freedom to operators, Potchinsky says. BT, for instance, feeds jobs to field engineers one at a time; the Taskforce system then decides on the most economical way to allocate the next job. However, he says users who employ third-party contractors are more inclined to opt for the "tour" approach, in which a complete schedule is worked out in advance.

"NTL takes that approach, although it does encourage franchise operators to drip-feed jobs if possible." But he adds that it is important to take account of employee attitudes. "Empowerment is the key."