As with all procurement operations, the requisition stage in the travel category is vital to the process, Dr. Roderick Ross, CEO of online travel management platform TravelLinck, tells SmartProcurement. This is the second article in a series of seven discussing the fundamentals of the corporate travel commodity.
Corporate travel is about face-to-face interactions that further one or more business objectives. “The corporate travel manager’s challenge is to achieve this within cost and time efficiencies,” says Ross.
A corporate travel requirement is triggered when the particular nature of an event (e.g. a meeting, a conference, a training course, etc.) requires two or more people from different locations to interact in person.
A travel requirement may be thought of as a problem specification, says Ross. As with any problem, the more accurately one can specify it, the better chances you have of achieving an optimal solution.
In a surprisingly large number of corporate and government institutions, the mechanism for specifying a travel requirement usually boils down to a piece of paper.
“The prevalence of paper-based travel requisition stems from the fact that many corporate ERP systems do not have rich enough travel request capabilities,” says Ross. He attributes this to the complexity of the travel domain, combined with a lack of travel specific information (such as traveller preferences) in corporate HR modules and vague travel policies.
In many cases it is normal for the problem specification to be incomplete. For example, a traveller may specify her travel requirements, but will rely on something or someone else to specify and enforce the policy associated with that travel requirement, explains Ross.
It stems from private travel, where a person travelling overseas would specify what they know of their travel requirements and rely on something or someone else to specify the additional requirements for Visa’s, inoculations and so forth.
It is also typical for people who specify their travel requirements to put some of their own travel knowledge into the request. For example, a traveller going from Johannesburg to Cape Town will use their past experience to allow at least three hours between departure and their meeting time.
However, in future, the request will be driven purely by the meeting requirement, since past traveller experience may not be applicable for the current trip, (e.g. due to extreme weather conditions, roadworks and so forth).
Without technology, all the above becomes very challenging, and because travel is a perishable commodity with time-based pricing, the longer one takes to specify and solve the travel arrangement problem, the greater the likelihood of the solution being inferior and more costly to what could have been obtained.
There is just so much scope for the centralised management of travel with a proven e-management system that it is worthwhile, from any point of view, to consider adopting one without delay.
In next month’s SmartProcurement, Ross will consider the approval stage, which has its own complexities due to the time-varying nature of travel commodity pricing.
