(Public) cloud-based software is on everyone’s lips, and gradually also in more and more service portfolios. However, many companies are still reluctant to take a serious look at these technologies. Yet certain user groups would benefit extremely from the advantages.
These are the employees who are hardly known in the office. Those who, day after day, week after week, throw themselves death-defyingly into the battle with the elemental forces of rail and air, for the benefit of the company and its customers. Those out on the front lines holding the flag high. The traveling colleagues, called „Frequent Travellers“ by one or the other.
… then you’ll experience something
Because it is precisely those who very often suffer from suboptimal procedural and technical specifications for travel management. This refers to the many little nasty things that get in the way of a traveler. A selection…
Planning
- Can a weekend be included before and after?
- Business class for intercontinental flights?
- Can I get a deposit?
- ..
Implementation
- The hotel is overbooked, and is now offering me an upgrade for a fee. Can I?
- When did the connecting train leave again, I can’t get into the system from here?
- A colleague from another location has a central contact for travel questions. Why not us?
- ..
Accounting
- 4 hours a month are spent entering receipts, mostly on weekends. Is there a surcharge?
- When will my money finally come?
- The wrong amount has been transferred. What do I do now?
- ..
The principle is clear – planning, executing and invoicing travel is more complicated in terms of specifications (T&E policy) and processes (tools and processes) than one might think. This is what many technical implementations look like: intransparent, inhomogeneous and ineffective. Remedies are promised by travel worry-free solutions such as SAP concur.
More travel, less hassle
SAP concur is a cloud-based solution that promises to simplify the planning, execution and billing of travel. Compared to the previous in-house product SAP Travel Management, it offers major advantages in the areas of planning support, supplier integration and FI localization (instead of just HR). In addition, from a user perspective, it is much more accessible in the cloud than the SAP ERP system usually is.
The structure of the solution in its components (partly associated with additional costs) looks something like this:
Numerous interfaces are available for connecting suppliers. Here, one benefits in particular from the automatic exchange of electronic invoice documents – in these cases, the annoying scanning and typing is no longer necessary. A lot of love has also been put into the usability and accessibility of the solution, not least because the end user needs to be able to get to the functions they need quickly. As such, Concur makes it quite easy to work with effectively as well.
Searching and finding the solution
An implementation project is quickly thought of, but depending on the size of the company and existing (?) T&E policy, not so quickly implemented. The process scope in Travel Management is not very high compared to other ERP-related projects, but neither is the integration willingness of the international locations in most cases.
So first you have an organizational (change) challenge before the technical issues can be solved. If you already have a global travel & expense policy that is rolled out and lived (!), then you are already halfway there. Then you can start touting the benefits of a centralized, cloud-based tool to excite future users. Since Concur looks pretty handsome, you can do a lot of change management with fancy interfaces and smiling employees.
For the project, you should choose a focus. While similar goals are often pursued, you usually want to focus on one of them:
- Save money (focus on costs)
- Make employees happy (focus on persona and their requirements)
- Harmonize processes (focus on policy)
Once you’ve made that decision, you can align the appropriate business and IT workstreams and decisions. Concur itself only offers technical implementation support. You can accept this offer, or find a separate (certified) resource for process consulting and large parts of the project management (Change!).
Once the contracts are signed (don’t forget the Concur test system, which is not included by default) and the partners are involved, you can write the process and IT concept. Concur specialists are still comparatively rare in Europe, and the solution has its roots and broadest customer base in the US. Keep this in mind when planning time and money for staffing.
Unsurprisingly, the global rollout will then take place in stages. Because of the natural fragmentation into country-specific regulations and languages, it also makes sense to take a country-by-country approach to Concur rollouts.
The nitty gritty
Moving into local rollouts, the main work is in communications. Since we’re talking about a cloud solution (technology) based on a central policy (process), the customization options per location are correspondingly small aside from purely legal requirements. The fit-gap sessions with works councils (!), HR, FI and Legal should therefore also be quite short. Concur divides countries worldwide into tier levels based on the solution’s standard coverage. These levels will obviously greatly affect the requirements gathering effort depending on where you have your locations.
Tier the sites in the selected pilot country by enthusiasm (descending) or site age (ascending), and process them sequentially at first. You need good references, especially at the beginning of a program like this, for the rest of the process. A few botched introductions along with negative publicity can make the whole program very difficult for you, so take your time. So change management is critical here as well. Provide demo environments for users to play in. Think carefully about whether you want to provide documentation and presentation in corporate language only, or localize per country / country group. The latter means more effort, but will greatly increase adoption.
Use lighthouse colleagues and examples from highly affected departments, get future users excited about the solution, and gather input from before and after users. A project manager alone cannot spread the good news, you need fans to promote the project.
You can finally parallelize rollouts when there are a few internal references, the group has basically swallowed the change, and your project team has become more experienced thanks to the pilot country. Then appoint local project managers and teams and reel off your proven rollout plan.
Also, solicit feedback from each rollout. If there is room for improvement, adjust the approach accordingly. With each wave, the central team will become more familiar with the procedure, but there will always be new surprises waiting for you.
Once you have completed your pilot country soon, you can put other countries (with similar requirements) live in a much shorter time.
Good luck with that,
