Skip to Content
Far too often I am called by a client to clean up the mess of one or more previous workflow consultants. It seems to be quite common for clients or ICT partners to use ABAP developers who like to claim that they know workflow. The consultant comes in with little or no experience, and has “Practical Workflow for SAP” tucked into their laptop bag in order to figure things out – After all, it can’t be that difficult, can it? To be honest, it’s not difficult. With some research and a little trial and error, it’s actually relatively easy to design a workflow that does the job. What is not so easy is designing a workflow that will accommodate future business change and growth. It is not so easy to design a workflow that other workflow consultants will understand and find simple to maintain. And finally, it’s not easy or even possible for inexperienced workflow consultants to provide valuable advice that only comes with experience. This advice could help clients recognise problems in their workflow engine configuration, or point out other workflow design flaws. Even more importantly, this advice could enlighten clients to the features of workflow that they never knew about – Features that might change the way they use workflow in their business. Companies seem to often justify the use of an inexperienced consultant by the low cost incurred, but of course in hindsight, it’s easy to realise the benefit of experience.

One of my recent projects included an HR Leave workflow that had already been worked on by 4 other consultants – none of them managed to complete the job ; no one in the business knew “who did what” ; transports were a mess ; the wheel was reinvented far too many times. I landed up undoing a lot of their work, and reverted to using standard business objects, steered clear of using custom tables, and added meaningful and valuable descriptions to tasks and workflow templates. By the end of it the client had a working leave workflow, which was a lot simpler in design but achieved exactly what was needed – Not only that, but the end users love the fact that more meaningful content is now being delivered to them. In the big scheme of things, user acceptance is everything – Why didn’t the previous consultants emphasize this? Even more importantly, why didn’t the previous workflow consultants finish the job properly? Because they didn’t know how to.

Another typical example recently popped up with a client of mine – I was asked to quote on the design and development of 11 QM Notification workflows. The consultant that previously worked on the project adopted a very rigid design that did not allow for any change to the business process. They also told the client that certain things could not be done. After my initial assessment, I proposed a generic workflow design that would mean one workflow for all notification types. My design included the flexibility for business change and growth – It was not restricted to particular notification types. QM configuration was used to manage deadlines and task processing. In the end, instead of creating eleven new workflows, only one was needed – It had a much simpler design, and achieved a lot more, while still reducing future maintenance costs.

The moral of the story:

  • Inexperience = Low initial cost, future redesign,lower business value, less return on investment, higher overall cost of ownership.
  • Experience = Higher initial cost, higher business value, higher return on investment, lower overall cost of ownership.

Experience conquers all!

To report this post you need to login first.

11 Comments

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

  1. Matthew Billingham
    And it’s not just workflow.  I’m writing a blog entry at the moment covering similar ideas, from an ABAP Developer perspective, so it’s pretty timely.  I’ll have a link to your blog too.

    cheers

    matt

    (0) 
    1. Thorsten Franz
      Couldn’t agree more, both with David’s and Susan’s elaborations about workflow and with Matt’s about custom ABAP development.
      A good, experienced developer can always see beyond the scope of the current problem and lay the foundation for future growth, and see how to achieve maximum future benefit with minimum investment. It’s a bit of an art to see the alternative solution that doesn’t cost more, but will bring great saving when future modifications come.
      This is especially true in the workflow area, where a good design of business objects (BOR or classes implementing IF_WORKFLOW) makes the difference between great reusability and transparence and none at all.
      Cheers,
      Thorsten
      (0) 
  2. Susan Keohan
    Hi David,
    As a customer who has been working with workflow for quite a few years now, I deeply appreciate this blog.  I’ve had a couple of qualifed, experienced, high-quality consultants to work with, and some that were not so.  Designing a ‘holistic’ approach to not just one workflow application – but leaving the infrastructure in place for many future applications is something that was often over-looked.  And it’s not just me; I’ve heard this time and again in the WF World. 
    The results of the inexperienced consultants were clearly just ‘one-offs’ – which were not intended to integrate with other aspects of our systems at all, nor to leave room for future growth.  Thankfully, this has been corrected over time.
    So, while it’s true that good ABAP knowledge is handy for implementing a workflow – an understanding of workflow in depth (ie: Experience) is indispensable.
    Regards,
    Sue

    PS: Not to diminish the Book at all, though! 

    http://www.sap-press.com/product.cfm?account=&product=H3057

    (0) 
    1. Vijay Vijayasankar
      1. It takes time and money to implement a good solution. If customer skimps on either, there is a risk of having a bad solution in their hands. Experienced consultants are not cheap even in this horrible economy, and not every client has a long term view when they budget projects.

      2. Very few projects budget for more than one workflow consultant. So the chance for inexperienced guys to  get mentored by experienced guys is minimal. And if cost is the prime factor in this decision, then the chances are that an ABAPer with “some” workflow is thrown to do workflow, and even then – with the expectation that she multi-tasks.

      3. Inexperienced guys are all not dumb. Given time, they figure often their way out. And good design principles can be extended from another part of SAP to workflow to some extend. It depends on the individual consultant whether he/she can do this.

      4. When things go down the drain, then money spent on consulting stops being the major factor and customers pay to get the experienced hand. And life returns to normal 🙂

      (0) 
  3. David Bann Post author
    Thanks everyone for your contributions – I am working on a wiki around this topic to enable the community to contribute and build some sort of platform for things to look out for in the design and development of SAP workflow. Of course, once the wiki is published I will blog about it to get feedback and more contributions. Thanks again!
    (0) 
  4. Bjorn-Henrik Zink
    Hi Dave,

    Thanks for a great blog. I too, fully agree with you regarding using experienced workflow experts. Some thoughts that I would like to add:

    1) It would be interesting to get your view on how inexperienced workflow developers can become experienced experts?

    2) What parts of workflow are suitable for inexperienced developers and where is the need of an expert crucial.

    3) Perhaps the main problem is that most projects have one workflow resource assigned (and therefore does not discuss the design with anyone else) and that there is no design QA with a workflow expert? 

    4) Number of years working with workflow does not necessarily make you a workflow expert! This is a regular pitfall for many customers.

    5) Conversely – I believe that workflow developers with little ABAP knowledge are just as bad as ABAPers with little workflow experience. They tend to make bad workflow designs, which often lead to workflows that are difficult to maintain and grasp.

    Cheers,

    Björn-Henrik

    (0) 
    1. David Bann Post author
      Thanks Björn – I fully agree and I will most certainly address the topics you have mentioned in the wiki that I am currently putting together.

      I appreciate your input!

      Regards,
      David

      (0) 
    2. Mike Pokraka
      Björn-Henrik,

      The question about experience & expertise is a matter of what resources and experience is on the business side of a workflow project.

      A functional consultant with a good understanding of WF and BPM can provide guidance for a lesser experienced WF developer. If a company hasn’t had any exposure to WF before they definitely need someone who has good experience in both the technical and functional sides of WF.

      Simliarly, for a workflow developer to gain experience they need to get their hands dirty on the business side. Work closely with your functional consultants to develop the process. My functional specs (or ones where I have a lot of input) are always signed off alongside a working prototype, and those are my happiest customers.

      Sadly I still end up on projects where I’m asked to build to horrific specs written by folks who have obviously not worked with workflow before, nor have any BPM experience. It does amaze me at times what some large consultancies get away with….

      Cheers,
      Mike

      (0) 
  5. Bill Wood
    The single largest problem I have seen over the years, on numerous projects as a functional consultant, is the lack of proper prep or design work.

    Workflow, like functional configuration, is a process-driven and rules-driven technology component of the implementation.  Because of that instead of the typical “functional” or “technical” specs that almost always trigger workflow requirements a full-blown blueprint should be developed that defines all of the processes, triggers, actions, etc.  That is the best and most effective way I have ever seen to get a decent solution without taking forever.  Without a good blueprint up front, for all of the WF development, it is a scramble to make, re-make, adjust, change, integrate, all of the custom coded (usually) WF components of an implementation.

    Just my two bits.

    (0) 
    1. David Bann Post author
      Thanks Bill – I agree fully and I always make sure to spend most of my workflow “development” time on the blueprint phase – There is no doubt that the blueprint/design is one of the major aspects that sets apart good workflows from bad ones.

      Great point – Thanks again!

      (0) 
  6. Mike Pokraka
    …very true indeed.
    One issue is that some customers see workflow as a pure coding exercise, forgetting that it’s more about Business Process Management than jamming a few lines of code into a pretty flowchart, which  – as you rightly pointed out – is the easy bit.
    (0) 

Leave a Reply