Skip to Content

Here is the background. I was managing a project where we implemented some complex functionality that includes multiple steps. This was not a process they needed to do every day – at best they had to go through this 2 or 3 times a month. During blueprinting, we realized that using guided procedures could reduce the effort for users to learn the new system. We prototyped it, and the users loved it. Every one was happy – I was happy because I originally thought of the idea, My developers were happy because they got to play with new technology, and the users were REALLY happy because a complex solution was made simple, and the manager of the group took us out to lunch to celebrate. So we implemented it, tested it thoroughly, and went live. I am told that every time I walked across a user who had the GP screen on his machine – I had a smug look 🙂

 

As time progressed, the business for my client picked up – and this business process we implemented with guided steps had to be used more frequently. Users became real masters of the mechanics and could do it in their sleep. Also, instead of 3 users using it – now we had close to 10 users doing this several times a month.

 

And then started the trouble. The guy who took us out to lunch originally, called me to his cube and told me that he is seeing a productivity loss in his team because they have to go through multiple steps to finish a process that they are experts at. He wanted me to explore the possibility of creating something like a “GL Fast Entry screen”. Customer is king in my business – so I asked for some time, and pulled in my technical team and some key users for some brain storming.

 

What we found from the users was that there were two kinds of requirements – The guys who used it from the beginning thought this process was too slow for them, where as the newer users wanted to stick with the existing solution. Since we could not reach an agreement – we pulled in the manager of this group. His position was simple. He said that in his view – we will need two UIs. One for experts, and one for new users. He didn’t want to hear about IT maintenance costs for 2 sets of UIs. On top of that, he wanted a third option to upload data from a spreadsheet.  He had the budget to do the development, and pay for extra maintenance effort. So he won the argument hands own. So now we had 3 UI options for one process – and all our users were happy. At least for the moment.

 

This raises a question in my mind. Was this an optimal solution? I don’t have a black and white answer yet . What is the purpose of any business solution ? To solve the problem at hand in the most efficient way possible. But efficient for who? In this situation – the 3 UI option was very efficient for users, and inefficient for IT. We used an SOA approach – so IT solution was not terribly inefficient, but still we had 3 variants of the same process to maintain.

 

There is also a long term question – invariably the solution will need to change with time. And we will have to change 3 variants, and retrain users. Assuming the ROI continues to be high, we can argue that this is completely ok to do. If this is an isolated case of just one business process – it is probably ok. But if users of other business processes find that there is an option to have multiple UIs for a given process, then I bet they will have a reason to ask for that too.

 

With SOA, BPM etc – we can probably implement such changes quickly. I don’t doubt that – but all of that still needs IT involvement in developing and maintenance. And this is costly over time, and not always readily apparent or quantifiable when decisions need to be made.

 

So I have two questions –

 

One, a tactical question : Once a user masters a process, it is apparent that guided procedures hinder productivity. So should all (or most) applications that use GP have an expert mode UI also – and let the user switch between the modes according to their needs?

 

And two, a bit more strategic one : Just as we let some end users create adhoc queries in BW and ABAP, do we need a paradigm where they can alter the UI as they need? Of course a lot of personalization options exists already where you can move around stuff within a screen, hide/unhide fields and put default values. But a user cannot really alter the screen flow itself easily without IT support. Maybe this means BPM should be made simple enough to make a BPX out of a common user?

To report this post you need to login first.

13 Comments

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

  1. Michael Nicholls
    Or 3 front end variants sending data to the same process? That is meant to be the power of SOA. It’s the same business process steps, presumably available as a set of services, and different frontends which call the services.
    So for the occasional user they see a multi screen entry as a Web Dynpro, the more experienced used checks a box on the first screen and enters “warp speed” mode, with a different look and feel, and the manager who wants to upload a spreadsheet is given an area on the first screen where they drag and drop their spreadsheet.
    (0) 
    1. Vijay Vijayasankar Post author
      Yes indeed – but let me ask this.
      How does the average business user visualize a process? What comes to her mind first – visio flow diagrams or the actual screenflow she uses every day?

      SAP has made great strides in improving the UI personalization options. I have noticed first hand how much productivity improvements have been gained as a result of the webclient changes in CRM. ( But for some strict confidentality agreements, I wanted to blog here or make a video on that for the influencer summit.)

      However, the user is still restricted by the screenflow that SAP has put in place. User can do all he wants in a given screen – but he cannot re-order or combine or split an existing screen flow to suit his variant of a given process.  Imagine how much more a BPX can do if this power is given to an actual end user. Then BPX can move up the value chain, knowing that once a framework is set up – then the actual users can sustain it without too much support from BPX or programmers.

      (0) 
      1. Marilyn Pratt
        I confess.  I was leading the witness and in addition I even had an ulterior “evil plan”.  I have a group at the Process Design Slam evening (in Phoenix is the one coming up) which will be looking at this very idea of visualizing process.  Are you coming to Phoenix.  We need someone to lead a roundtable conversation around the visualization of these screens.
        (0) 
  2. Martin Lang
    Thanks Vijay, another great blog! In your case and especially if you already built multiple interfaces, I would recommend to put in a framework that would count e.g. how often the transaction itself (e.g. each one of the three) or even a certain functionality within the transaction or report was used.
    Here’s an excerpt of a talk of Marissa Mayer at the Stanford Entrepreneurial Thought Leader Speaker Series, where she talks about something very similar. If we come with facts, e.g. such data points, plus a deep understanding of the underlying business process to these Business managers that ultimately make the decision, we have a much better chance to recommend one or in some cases two solutions, if there is indeed value in several. Ultimately I agree with you the “customer” will decide which way to go, but most customers would appreciate a strong, solid and fact based advise.
    (0) 
      1. Martin Lang
        Ah, sorry, forgot to attach the link I guess. This is exactly the link I was talking about. I think the entire talk from Marissa there is enjoyable, but this section Data is Apolitical has inspired me in the past to collect some more data on tools and functions we built or support.
        Thanks for posting the link!
        (0) 
    1. Vijay Vijayasankar Post author
      Thanks Martin. We did such an analysis in legacy system before we switched to SAP. However, the last two cases – fast entry, and excel upload were “wishes” from users and their manager. This was new functionality that they made a good case for – by citing volume of transactions being increased since we went live.
      We write application logs for these transactions since the data is critical and we need traceability. Maybe a year later, we can scan the log to see if it is time to sunset one of the three options.

      We clearly explained the cost associated with the solution – and the sponsor had a strong case for his ROI being better with 3 UIs despite the cost. He did understand that there is always a risk that his current assumptions could be proven wrong over time. Also,in this particular case – I was convinced that 3 UIs was actually an appropriate solution.

      (0) 
  3. Vineeth Varghese
    Whats your conscience saying. Are you also towards having 3 UI’s. How the other process users also will look towards this new change. Surely one day they will also ask for UI’s like in there process too.

    its just my view

    (0) 
  4. Thorsten Franz
    Hi Vijay,
    Great blog. I’m familiar with the phenomenon: We often build data entry screens twice, once for rapid fire-and-forget entry (with only the barest checks) by data typists and once for data maintenance by experts.
    The task of the experts is not primarily to type in data, but to resolve any errors (beyond the simplest ones) that were found in the documents entered by the typists. Depending on the type of document and especially depending on the error, a workflow directs the document to the right expert.
    It’s obvious that you need two UIs for this purpose. The data typists need speed: No mouse clicks, just tab from field to field and enter everything rapidly. The experts need plenty of data around the case, rich navigation links to other business objects, value helps, and such.
    I wonder how common this pattern is?
    Again, thanks for a great blog,
    Thorsten
    (0) 
    1. Vijay Vijayasankar Post author
      Thanks Thorsten.
      This particular functionality is mostly about audit of data that came via interfaces, and posted as transactions in SAP.

      Apart from the GL fast entry screen, and condition mass maintenance – I cannot think of many other scenarios where SAP themselves provided multiple options in standard to do the same transaction.

      So I have been thinking – can we have an intelligent BPM solution that can somehow interpret the underlying datamodel (an abstract one like the BOL in CRM might be easier than a physical one with a hundred tables) and propose alternate screenflows to a user that she can choose from?

      I think this is a valid usecase for any process where multiple transactions or line items are required. My expectation here is that user gets to choose how to arrange the flow for a given process, on the fly (like how he can use personalization settings on webclient to rearrange blocks within his screen, or hide fields ) without needing IT support. Depending on underlying model, system should be able to prevent a user from doing an illogical flow.

      What do you think? It is 5AM and I have had only one coffee so far. so bear with me if I sound like a mad man 🙂

      (0) 

Leave a Reply