The Concur solution is very different from SAP Travel Management, and Concur projects are very different from ERP projects
If you haven't seen Concur yet, this 6 minutes Concur Expense demo video from Hannah is good way to start.
You're considering implementing Concur Travel and Expense? Brilliant! You have the opportunity to really add value to your Travel and Expense process and reduce cost at the same time. Emphasis on "opportunity" as opposed to "guarantee". Whilst the majority of Concur projects are successful, there is a real risk that you are losing out on the full business benefits.
And if that happens it's no fault of the Concur solution, nor is it your fault: it's because nobody really prepared you for the fact that Concur as a Travel and Expense solution as well as the implementation project are likely to be very different from what you've experienced so far. That's certainly the case when you migrate from SAP to Concur, but applies to many other migration scenarios as well.
You are likely to underestimate the Concur solution scope and therefore miss out on a lot of value, because you don't plan the time in your project to tap into these opportunities
The Solution Scope
So, let's start with the risk of missed opportunities because of Concur's solution scope.
The expense process in Concur is definitely great, particularly regarding its user interface, mobile capability and guid
ing the user to capture the right information. More than any other system I've seen, you are less likely to have to make any corrections at the tail end of the process (e.g. because your users get VAT wrong, or captured duplicate receipts). And I'm speaking not just from a consultancy perspective, but also from the perspective of a small business owner, who until recently had still done the final expense review for the team on the first Saturday of the new month. Migrating to Concur has given me my Saturday back. The little work left fitted into the journey home on a Thursday night or was done on the sofa on a lazy Friday night.
But the expense process is not where you'll find the biggest improvement opportunities, if you come from a reasonably advanced system like SAP. Yes, it will free up time for your travellers and line managers, and out-of-the box analytics are really strong, but there is also a risk that you'll try to emulate your old admin-focused process, spend all your time, energy and budget on automating some obscure plausibility checks or workflow rules for the last 1% of special cases, and you then miss out on the real benefits.
Don't be the company that replaces their company cars' wheels with mechanical legs!
So, think of your old system as horseback travel in the 1940s and of Concur as the latest car at the time. The risk is that you buy the car and then realise it's not able to jump fences. So, you spend a lot of effort to replace the wheels with mechanical legs, making it slow, unstable, high maintenance and high fuel consumption. It will also still be quite bad at jumping fences. The point is that in the 1940s, for normal travel, there where not that many fences to jump. There were roads and using them with your car would give you an awful lot of advantages - if you don't believe me, send me a picture of yourself on your daily commute to work on horseback. I'll add all those pictures to this blog 
So, what are the opportunities you are likely to miss, if you try to make Concur a better looking version of your old SAP Travel Management system?
In core expense, you'll probably find fewest, but still some important points:
- user experience
- mobile capabilities
- vendor integration / e-receipts
It's a real shame some customers use Concur Expense only
But the other end of the process, Concur Travel and possibly Concur Request, is probably where you'll be really amazed. Particularly, when you move to Concur from SAP Travel Management. So, it's a real shame that some customers want to use expense only:
- the booking engine, integrating with loads of large and small Travel Management Companies (TMCs), just makes it so much easier for your employees to find and book the best option. You'll reduce your TMC bill considerably, because Concur-booked tickets come at a much lower fee than phone/email bookings (e.g. GBP 7 vs. GBP 21)
- Direct integration with vendors or aggregators e.g. via Travelfusion cuts out even the agency fee and adds more choice. The new Triplink integration launched earlier this year allows you to integrate with Concur, even when you are booking directly on the vendor's website, as the data flows seamlessly into your Concur instance, can be reported on and checked against policies.
Significant value can come from the Concur ecosystem
But looking at the core Concur solution only will always make you miss an ever bigger chunk of the opportunities. A lot of the innovation is happening in the Concur ecosystem, where additional apps and services can create a lot of value; foreign VAT reclaim being just one example.
The neglected part of the Travel Management process? Travelling!
And finally, we get to the widely neglected part of Travel Management: the actual trip. Yes, that's right. We talked about SAP Travel Management for a long time and in 80% of the cases we were referring to expense management only. Then the pre-trip activities got some more attention, but very few systems did anything to support the traveller during the actual trip. I guess that happened because it doesn't directly affect the back office staff dealing with Travel and Expense admin. It only affects your travellers – the people, who are out there to sell your products, serve your customers and make sure you get the right supply. Well, helping those people to be more effective should be a good thing, shouldn't it?
This is where some innovation is happening within the Concur solution portfolio as well as in the ecosystem. The Tripit app is what first hits the eye. Nothing an ERP-focused admin person, who rarely travels to new places for business, would get excited about; but as a frequent traveller, I really appreciate how it makes my life easier. To begin with: I stopped cutting and pasting all my booking confirmations into my calendar appointments – creating a mess. I have a very clean itinerary on my Tripit smartphone app instead. And it comes with value-adding information like maps, directions and delay alerts.
Tripit for teams takes it one step further. It does allow travellers to identify colleagues travelling in the area or on the same flights and trains. That can facilitate cost-cutting by sharing cabs and rental cars, or make travel time value-adding by serving as impromptu meeting time. It also helps to make business travel just a little bit more pleasant.
You have a duty of care, but do you care?
And then there is Concur Messaging. Originally designed to comply with employers' duty of care for traveling employees so you can identify travellers who might be affected by any emergency (say, a natural disaster) and communicate with them, it now goes further, acknowledging that travellers deserve more than mere survival 
You can design messages, so Concur helps your employees to find their way around with a minimum of frustration and maximum of efficiency. One of the latest Concur updates from Q1 2015 just improved this process by allowing different messages for different target groups. E.g. in our team at iProCon, we would provide travellers from our German office with information about the best way to get to our London office from the six London airports or the Eurostar terminal, but wouldn't bother our London team with that information.
There is also an increasing number of 3rd party apps within the Concur ecosystem to help your employees during the trip, some of them aiming at professional networking aligned with the particular trip.
By excluding non-employees from your Travel and Expense system you may lose track of 20% of your travel cost
Finally, there is a different dimension where you'll lose out if you just try to emulate your old SAP Travel Management solution in Concur Travel and Expense. Q1 2015 has brought a new feature: sponsored guests. This allows you to set up contractors, candidates and other non-employees temporarily to use Concur - probably following a different policy with more limited options. As a result, you'll get an even more complete picture of your travel cost
It is a real shame when new customers approach a Concur implementation with the narrow objective of replacing a last-generation solution like SAP on-premise Travel Management, and just making the process covered already a bit more efficient and better-looking; they'll usually also find a couple of admin points where the old solution suited their purpose better (possibly due to custom programming) and focus on these points rather than aiming at the real value. Your car doesn't need legs: use the roads!
The Project Effort
A Concur implementation project can be very intense!
The second reason for failing to seize opportunities to get the most value out of your Concur implementation is that customers underestimate the resource requirements for the project. The SaaS model allows for a pretty fast deployment of the technical solution and your project plan would usually make use of that. You would also not have a technical implementation partner (this may change), but Concur would provide the resources for the technical deployment. If your target processes are clear and feasible, communication and training are taken care of, resources for interfaces available, your legal team understands SaaS contracts and is available to get them signed in time, and the whole context is ready (TMC, credit cards, device management, SSO infrastructure, travel policy,...), you'll probably be fine, if you really do provide the internal team members with the required capacity.
If you don't have perfect project condition, then don't plan as if you had them!
However, I have yet to see this perfectly prepared client. In fact, my very first experience with Concur was due to a customer request to rescue an implementation project stuck due to lack of resources and "blank sheet inertia". There was nothing wrong with the solution or the objectives, but the lack of internal resources and experienced project management required some 3rd party help.
When you are used to typically long running (>6 months) ERP implementation projects, your implementation partners would have planned for enough resources to do a lot of these extra tasks for you. But Cloud deployments, and certainly for Concur, are usually planned as just that: technical deployments. They may provide tools and templates to help you along the way, but they are not meant to comprise longer discussions to design process requirements, help you negotiate with a new TMC (or indeed the old one, who will see their fee income go South with most bookings done online), or win over regional fiefs who don't like the idea of change. A typical Concur deployment is like a well-oiled machine. If your own machine isn't ready and well oiled as well, you'll risk being left behind or the project grinding to a halt. The typical SaaS issue: the technical side of the project is getting faster, but people and organisation are not always keeping up.
SaaS projects can be incredibly fast, but don't lose your goat!
If you are from Germany, you'll know the popular folk song "Uff de schwaebische Eisebahne" (on the Swabian Railway). It talks about a farmer, who wants to travel with a goat. He does the same as he would've done when travelling by ox-cart: he fixed the goat's leash to the last carriage (Going with the common Swabian stereotype, I guess he wanted to save money for the goat's ticket ). Unfortunately modern technology had become too fast for goats. When he got off the train eventually, he only found the goat's head.
As I said: there is nothing wrong with the approach. Nor is anything wrong or indeed unusual about customers not being ready for this. It's just important that all parties involved share the same expectations and then take action to align. Just imagine you buy this new fancy kitchen for your home and the price includes installation. Then one guys deliver it and wants to instal it – only to find out that the electric wiring they need to connect to isn't in place yet, that parts of the old kitchen still need to be taken out and the plumbing of the sink needs to be extended two yards to the left. Chances are they'll just leave and that's even the better outcome. The other option would be that they just unload everything into your kitchen, tick the "delivered, but couldn't be installed due to customer's fault" box and you'll be charged the full price.
Those little "side projects" that can be crucial to reap the full benefits
Actually, the better you do with understanding the full value discussed in the first part of this paper, the more likely you'll be overwhelmed with the tasks at hand during the project. Because in that case, you'll probably have a much larger scope involving people from further parts of your organisation:
- You may have to discuss paperless expenses and even e-receipts (as opposed to just electronic copies of receipts) with your audit team and indeed the tax office
- You'll educate employees about the team features coming with Tripit and have to discuss this with your data privacy team beforehand
- You'll redesign (or establish) your duty of care process for travellers
- You'll find yourself with the fun task of designing a gamification approach to incentivise travellers for making smart choices
- Your travel policy may need a good re-write to make use of the options to book low-cost carriers in Concur and to integrate vendors like Uber and Trainline through Triplink
- Accounts with a number of vendors may become necessary to make full use of new booking options and Triplink
- And to finish this excerpt with a big one: if you have hitherto had assistants booking for travellers, you'll face the significant change effort of having employees booking for themselves in all but a few exceptional cases, because that allows them to align their plans with the available options interactively and usually leads to lower cost, faster booking and less frustration. But there may be a big effort required to change mindsets before yo get there.
Is it all about paying for more consultants?
So, by now you will have had one thought for sure: "Look at that. Here's a consultant and surprisingly he's suggesting we use 3rd party consultants in our Concur implementation."
Well, I can't argue with that. Of course, I am biased in this matter and sure, one of the options to deal with the possible barriers described above is the use of 3rd party consultants to help you in your project. Alternatively, you can prop up your own resources or phase the implementation, so it's easier to cope with the change at any stage (though, some changes make most sense when they are brought in at the same time, so you would have to plan interdependencies carefully). In fact, 3rd party consultants should be the last thing to throw into the mix, but can probably help you to use the other two elements most effectively. And of course, you shouldn't let the implementation team from Concur off the hook. There are limits of what they can do within the contract, but you should make sure that you make best use of what you've paid for and there is nothing wrong with occasionally pushing these limits gently
And that's where we close the circle: to get the most from your assigned Concur team, you need to be ready: there are dedicated periods in the schedule for collecting requirements, configuration and testing. So, if your requirements are incomplete, you may not get them configured as part of the project further down the line and if you don't do your homework while you have a dedicated consultant to ask, when you are stuck general support may not be able to answer all questions for free after the project.
Conclusion
It is very likely that your organisation will be able to get a lot of value out of Concur, even though it's not perfect in every detail (it's human-made software, after all). There is a risk that you focus too much on incremental improvements in those parts of the process your old solution has covered already – or indeed spend all your energy on some details your old solution was perceived to be better. There is also a risk that you lose out because the project is paced too fast for your organisation to pick up all those golden nuggets along the way.
If I created the impression that a Concur implementation requires more resources than other Travel and Expense implementations of comparable scope, then I've done a very bad job. This couldn't be further from the truth. But what you need to understand is that two forces tend to squeeze project resources to breaking point:
- A typical Concur project is planned for a shorter duration than an ERP project, because the technical deployment is much faster indeed, but this is often projected to the non-technical parts of the projects that won't go away
- Concur offers so many more opportunities which often require changes in organisation, process, behaviour and mindset. All these opportunities require attention and time to translate into value
- SAP Managed Tags:
3 Comments
