Skip to Content
Few months ago I wrote a ESA is around us where I said that everyone can see ESA implementations in places where she rarely expects seeing them – such as a DMV center, for instance. This time I want to talk just about the opposite. Places where an ESA implementation is crying to be there but unfortunately it isn’t.

One of my last engagements has an unusual reporting system. The customer drives its own system which tracks travel and time expenses. Every contractor to get paid ought to fill her hours and her travel expenses into this system. At the end of every week you open one ’transaction’ for filling hours you worked for the customer and another ’transaction’ for putting travel expenses. The customer has, of course, his own policy for reporting travel expenses. You put a predefined per-deem article for every day you spent in the office. No need to dive to deep into details – what is hotel price, car rent, and daily internet – just the predefined sum of money for every day you were there. Cool! No headache. That’s ok. No surprise yet.

Another system in place where every contractor has to record its time is a project-based task tracking system. Here each project member has to record his day-to-day project activities. Now each team member has to report it regardless of who her employer is – whether she works for the customer or is a contractor – just report it! So we got ’transaction’ number three. If the first system (about travel expenses and contractor’s cost) is to govern cost of contractors then the second one is to see what every project task has been cost so far. The systems probably are of interest of different groups of project management. Definitely they represent different data. Undoubtedly they don’t double each other and almost don’t overlap.

If you work for SAP then you have to report your time and travel expenses in real transactions (no quotation marks) CATSXT and PR05 accordingly. Do you see already the point? A slight feeling of redundant data? Yeah, you’re right! We’ve reported this already, at least big part of it in the customer’s ’transactions’. We don’t report exactly the same data as we provided for the customer though – now it’s another level of granularity. SAP wants to know about every day’s hotel, ration, rental car, fuel and so on. But the data we put into the customer’s system ensues from the data we put to PR05. If we have our CATSXT and PR05 completed we can populate the customer’s expenses reports with an accuracy of 100%.

Now it became quite painful. Every week I worked for this customer I had to complete 5 forms and then to email my e-tickets’ confirmations to the customer. It took good half an hour to do it and verify everything is committed correctly.

I’m sure at that moment you understand why I put the “ESA” into the blog’s name. It’s an obvious ESA scenario for all 5 systems that can interact to the benefit of their users. Let me clarify.

I’m not saying that even one of the systems should be eliminated for the sake of the cool modern architecture. All of them can remain there. Each of them has its own target, own outlook, own application, and own users. I’m just saying that if these systems were developed as services or, rather, if corresponding services were in place to communicate with the systems then it would be possible to move the burden of boring and error prone processes of double entry project related data from users to the services. I’m only talking about a technical aspect of the scenario. Even the technical one has many questions yet to get answered. Messages have to be translated, intelligently mapped (probably split and later merged), these services have to be properly orchestrated, a collision-resolving system has to be implemented, most likely some monitoring transactions could be added, and presumably there are much more self-communicating transactions than the five I ran across. All these questions are up to the ESA. They naturally belong to the ESA world and the ESA has answers for all of them.

Just a few words about a business aspect of the integration. Following to the modern fashion to name books and articles using words like “dummies” or “idiots”, I had a stupid temptation to name this blog “ESA for morons”. But then a question about the relevancy of the ESA in this case arose. What is the return of investments here? How much would it cost to build this integration (for two companies) and what are the benefits of it (for the two companies)? I was told by other SAP consultants with a decade of SAP experience that such double entry is rather an exception. So maybe it doesn’t make business sense to do it, I don’t really know. But technically speaking it is enough pragmatic during system design and planning to think that the systems may be accessed and consumed not only from its primary UI but by some inanimate service. If this approach is one of the underlying principles of the architecture from the very beginning of system design then any future integration becomes much easier, much cheaper, and ultimately more appealing for implementation.

P.S Despite such triple-work this customer is one of the best I’ve ever had occasion to work with:-)

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Anonymous
    Could business travel be improved via ESA?
    Lets take the common business trip scenario:
    I’m flying to a customer, spending money with my credit card. The credit card company has all the information required (hotel name, date, amount). Then I’m filling my expenses (again the same data). I wait for my employer to reimburse me. Basically the same amount I spent on the business trip is re-credited into my bank account (again redundancy).
    What if Visa/MasterCard/Amex had the option to transfer my expenses directly to my employer. Cut me out of this process as a middle man. Wouldn’t that save a lot of redundant work, man power, time etc?  

Leave a Reply