I have been pretty psyched about BPM/BRM from the time SAP has been talking about it – maybe even earlier. I religiously read all the SDN blogs on it, and have RSS feeds that get me BPM news from elsewhere. Every time I attend an SAP event, I try to make it to a couple of lecture sessions and at least one hands on session. I did that this year in Phoenix too – and in addition, Marilyn very kindly let me into the Process Slam too. There is much to like about the tool, and the methodology that goes with it. There are plenty of blogs on the good part in SCN and elsewhere. I don’t think I have anything original to add there. I am mostly in agreement with all of it.
So, where do I think BPM is going? hmmm…not anywhere in a hurry that I can see. And I want to explain my views and concerns here. I am a consultant, and of course my views are possibly affected by that. Also, I will try my best to stay away from the philosophical discussion around BPM – and stick to just my views on how the suite will potentially get used in the field.
What kind of users are primarily expected to use the BPM suite? If the answer is “Functional Consultants” , “Business Analysts” ( or BPX, if you want to go fancy), I would say – think again. If you answered “developers” – then you win. As your reward, skip my whining in the next 4 paragraphs.
Let us look at a simple scenario here. As part of business process flow, we want to create a transaction – say a sales order. We find a service from ESR that does it, choose the 10 fields we want to expose to our user, generate a UI with Web dynpro or VC and so on.
I have tried to educate a bunch of functional people on how services work, and how to navigate in ESR. While they don’t seem to take it like fish to water, I think they will figure out easily if they need to. Similarly VC is a tool most functional guys can figure out. After all, these are folks who play with variant configuration and pricing. How hard can VC be? I agree – this part works well.
In real life though, having a simple set of UIs is not enough in most cases – we will need additional screens and logic for error handling etc. This is where things don’t always go well – not all functional folks are used to thinking about custom error handling. In the “good old world”, SAP screens handle this for them for free. Also, the more complex the functionality gets – the chance of Web Dynpro replacing VC is also pretty high. This is not easily possible for functional folks – and they will need a java developer for this process. Of course WD for ABAP is not an option (at least not yet), otherwise we could have argued that those functional people with basic ABAP skills could have figured their way around. And what happens when we need to debug? This needs more effort than doing so from SAP GUI.
I suppose all this is good news for programmers – they will very much be in demand.
Lets talk about the workflow aspect for a bit now. This was the primary lesson that was covered in the 4 hour hands on session I attended on Thursday in Phoenix, on an empty stomach :). A very simple workflow – took us 250 steps or so and 3 hours. Some of it can be attributed to lesson organization (example – repeatedly creating similar forms, rather than creating copies of the form screen created once, and changing them), but I did not find the tool friendly for a non-developer type person. To add to my frustration, there was the curious case of missing tasks. Another issue was on drag and drop – only certain ways of drag and drop would work for mapping. Thankfully the instructors warned us that this is a new version, and these are known bugs that they will fix soon.
I spoke to several people after I stepped out of the class – for two reasons. One, I had a splitting headache, and needed some aspirin or something (Which Marilyn gave me later when I met her in the club house. I am VERY grateful), and two, I wanted to check whether it is just me who thinks this way about the toolset, or whether there are others too. I spoke to mostly developers and a couple of functionally oriented people (who were fewer in number). While developers seemed to like it more than functional folks, I did not see any one getting really excited about this amongst these people. I also checked via twitter with fellow mentor Michael Koch, and he confirmed that he also thinks that this is very much an IT tool. I should add that Michael, and his colleagues appreciated the newer features of CE. Considering the fact that these guys have more exerience using developer studio and CE than me, I am inclined to believe that SAP will have a good product in a couple more releases or so.
Off to my next point – business rules. Decoupling business rules and reusing them consistently is a great idea. But I have a few issues here.
1. Business rules reside outside the transaction processing systems in this model. So what happens if that system is not up and running when a transaction gets processed? Sure we can have high availability around such systems too – but is the cost justified?
2.Rules act on master data and master data sits in ERP. How do we keep this in sync between the two systems? and again, is it worth the cost?
3. Some rules are very tightly coupled to the ERP transaction for a variety of reasons, like complexity, performance etc. Pricing, Output determination etc come to mind here. This would mean that some rules exist in ERP and some outside. What is the big advantage then?
4. What kind of user does SAP expected to use BRM tool? I have hardly seen a business user who has told me – lets create an Enumeration type, and while we are at it – lets choose java type as java.lang.string .
I am sure SAP will hit this out of the park at some point soon, but till then I have taken a note to self – Do not attend future BPM/BRM sessions on an empty stomach.