Skip to Content

Workflow Developers and Many Hats

If you haven’t already done so, you should check out Jim Spath’s video about the many hats of an SAP Mentor – just to set the tone 🙂

Are you back?  OK, well, I’d like you to check out another group that wears many hats – if you’ve been following my recent posts, you can probably already guess I am talking about SAP Workflow Developers.  

I’ve captured a sneak preview of some of the responses from our International User Groups SAP Business Workflow Survey, and would like to share this info with you.

But first, let me share my own perspective on the many hats of an SAP Workflow Developer… First off, of course, we need to understand the many ins and outs of SAP workflow.  But that’s not enough.  We need to be able, if not ABAP_Freak-like debuggers and even (gasp) coders.  Furthermore, we need to be able to run the typical business transactions – create invoices, perform personnel actions, create shopping carts, etc.  If you specialize in one functional area of SAP, you know that the challenges to mastering that area are legion.  Imagine trying to become conversant in all the functional areas that your company has implemented!  Your workflow developer may not be a ‘master’ at SRM – but bet your boots they have to learn to be a super-user in order to be effective. Workflow developers also get their hands in the configuration (release strategies, anyone?) as well as spending quality time engaged with the Basis or NetWeaver team – since we are interested in things like RFC destinations, and outgoing notifications.  ALE? Check.  We also need to know if critical master data is replicated across systems.  Archiving? Check.  Security?  Check.  So, again, while we are not masters of all these domains, we certainly have to have a working knowledge, and better yet, a warm collegial relationship with the real experts in all these areas.

But enough about what I think.  Here’s what some of the kind souls who have already filled out the survey think:

What’s really interesting to me is what was indicated in the ‘Other’ response…

Business Analyst

WF Admin & Developer

ABAP Developer

Security Analyst

Workflow Admin & Dev

Director IT / Project Manager

General SAP Support and User Admin Manager

Supply Chain and workflow developer Solution Architect

I have many hats, and change them often

SAP Technical Architect Manager (HR, Organisation)

Enterprise Technical Architect

Solution Architect

Workflow Liaison / Technical Area Expert

System administrator

NetWeaver Technician

These answers pretty much support what I have been thinking all along.  There is a whole lot of stuff we need to cram into our heads to be effective.  And I know that any good SAP professional worth their salt can say the same thing.  For example, what would a Security Administrator be if they didn’t understand the transactions? 

What do you think?  Are there even more hats that we wear?  Let me know here.
Some of the results of this survey will be presented during the Friday Morning Report 24 Hour Marathon on April 9.  We are working to raise money for Doctors Without Borders.  I will be honored to have as my co-host Mr. Jon Reed, of  Oh wait, that’s two more hats!  Volunteer Fundraiser and… oh heck,  that’s enough for now.

You must be Logged on to comment or reply to a post.
  • Additionally we have to know about Portal. Another thing all Workflow developers or Expert gets the blame first of all Workflow is not working but it is due to some configuration getting misplaced some data issues and so on. But this blame of Workflow is not working may work for 5% times. We need to propose to Customer about Business solutions and ofcourse you can no more than any other technical Consultant of even functional consultant about the Real Business. I have learnt a lot and Love to do Workflow 🙂
    • Hi Arghadip,
      Yes, it's very important to communicate with your functional teams and with the teams responsible for maintaining master data.  If your workflows are dependent on certain pieces of Master Data - under the assumption that they will always be there, and someone deletes it, the first call will be to the WF developer 'Your workflow is broken!'.  Same thing with configuration changes.
      So we should add another hat - something about chief collaborator? 
  • Who (or whom) should do the Workflow development?  Should it be in ABAP?
    Should it stay functional?
    This was a discussion we had at work this week...
  • It is finally difficult to say whether someone is a workflow developer or something else. For example I would say that my core skill is business workflow, but on the other hand there are so many other skills that are needed to really be an effective workflow consultant: You need at least the basic ABAP skills to do the necessary adjustments for the business objects or ABAP classes or BADI-implementations, etc. You preferably need some UI development skills (classic & web dynpro, etc.), and you need to be able to play with the portal & UWL. And as you said, you definitely need to understand the functional side: At first, it is enough to be able to go through the business process by using the transactions/applications without really deeply understanding the process - but to really be able to propose some improvement ideas to the actual business process itself, you need more deep understanding about the functional side (I guess here were are already talking about some kind of BPX role?). And sure a workflow developer/consultant might need to be able to use some business process modeling tools.

    If you have all the above-mentioned skills, it would be an underestimation to call yourself only as a workflow developer. I suppose that then you would be a solution and/or technical architect or possibly something else.

    For Tammy ("Who (or whom) should do the Workflow development?") I would answer that workflow developer is a technical role. Or at least you will usually need the basic ABAP skills. 


    • Nicely articulated, I agree with you, it is an underestimation to call ourselves workflow developer.  Reinstating your views, I guess, a solution architect would be more appropriate, because to be a good workflow developer you need to have knowledge and skills from end to end.


  • Just knowing how to develop a work flow "technically" is hardly enough to do justice in a real project. So you do need some ABAP expertise, some functional expertise etc to make an effective workflow. And of course - nothing ever stops with one workflow - whch means, you have to develop an architecture than can scale to many workflows.

    While, I personally do not see any difference between BPX and Soln Architect roles - the above logic seems to indicate that an effective workflow expert is a BPX/Soln Arch.

    • Hi Vijay, Karri, Tammy,
      I think the variety of opinions here shows exactly one of the dilemnas facing many companies embarking workflow implementations.  An argument could well be made that the developer needs technical skills, and IMHO this is true.  We also need, as Vijay has pointed out, the functional/business skills. 
      In an ideal world, I'd get to do both.  Oh, wait a minute, I do!
  • When we do a Workflow development 30% time goes for Workflow development and 70% time takes for Workflow Testing. Workflow development makes you aware of Business Process always more than you can acquire being a Technical Consultant. Even being in Workflow for 5 Years I have sometimes more Business knowledge than a functional guy. You also come to know about Org. Management. It is a always a pleasure to work in SAP Workflow as you become a Technical Architect as well as Business Process Analyst.


    • Hi All,

      All above is well suited I would like to add one more that
      Solution expert..
      You may wonder why this??
      It's because every time any process goes stuck first guy whom users search for is workflow consultant! Because he knows all the integration process so that he can easily track the whole system..:)

  • I think the only way to be a successful workflow developer and implement effective workflow is be that one person who can do all... understand functionality, design business process, design objects, design workflow, implement configuration, code ABAP, integrate systems and most of all, know to collaborate with everyone in the process - users, developers, functional analysts, basis, business owners, security and all of them.

  • Hi Sue,

    Nice work and I believe what you suspect is definitely true.  Being a jack of all trades solution architect, ABAP/JAVA developer, business analyst, etc; I believe that workflow is one of the most under utilised but powerful areas of the NetWeaver ABAP stack; especially with the integration with ABAP Objects now and strong UI friendly overrides available.

    For example, if you were predominantly an ABAP shop with good workflow skills in-house; with a PI available; then why install BPM when you can do it all within ABAP Workflow (leveraging proxy classes to PI for Web Service calls).  The ARIS integration is not really going to cut it as the only reason. (Obviously there are other reasons coming soon)

    The problem is workflow is complicated to pick up and it's like doing WD4J via Adaptive RFC to ABAP stacks without knowing ABAP.  If you don't have the big picture/understanding, you're partially blind (thank god SAP changed their strategy there too).

    Anyway, it does feel like we're slowly losing Workflow skills within SAP as SAP introduces BPM, PI, Guided Procedures (put that there for fun), CE, etc; but wouldn't be nice if they invested stronger in workflow.  Even I don't keep up with workflow anymore as it's hard to push a platform that so few really understand the intricacies of.


    • Hi Matt,  I choked a little when I read your post 😉

      You do say that companies can leverage their in-house workflow expertise, but you also seem to think SAP workflow is dying because it's so hard to keep up with all its' intricacies.

      The last major release of workflow functionality was NW2004s, I believe, which gave us local events and correlations.  I have not had either the opportunity or the need to use these newer features, but essentially, workflow remains the same - a robust, industrial strength engine for improving business processes.  What *has* changed over the years is the increasing complexity of the business scenarios (and I know that workflow can't possibly handle all of them) - and that SAP has unfortunately ceased giving the workflow certification exam (hello? C5?).  Classes are hard to find even though they are listed. 

      I think the activity in the Workflow Survey (which I will publish in toto as soon as I can) will show that there are many levels of WFers out there, and they all share a passion for the tool.  And hopefully SAP and the user groups involved (Thank you ASUG for sponsoring the survey!) will be able to put the material to good use.

      I really appreciate all of the thoughtful comments to this blog.

      PS: 'WD4J via Adaptive RFC to ABAP stacks' - that's where I choked 🙂

      • Woops - Sorry about that. Okay new analogy - it's like Thomas J going shopping for his girls...He knows how to take them, pay for their clothes, but doesn't really understand what goes through their head in choosing (refer to recent Tweet for that inspiration).

        Another more technical analogy is those PI consultants who don't know ABAP/iDocs/ABAP Proxies...They can do their job, but it's so much better if they knew it.

        You're right and I probably got my point wrong so let me have another go - For the most part Workflow hasn't changed too much and is easy to keep up with (provided you have kept up with Object Oriented ABAP); but with so much to learn in the ABAP world and focus no longer being on Workflow (or at least solely on workflow), the people skilled in Workflow must be being diluted.

        And for those who have (at least kind of) mastered workflow; they know the power of it and it's shame not everyone realises it.

        And just for completeness:
        WD4J - Web Dynpro for Java...
        Adaptive RFC - The way that WD4J creates RFC calls to ERP ABAP systems.
        Travel Expense Management used this approach and I had problems with consultants who knew JAVA or ABAP but not both so they could never diagnose the defects found without significant effort and coordination.


  • I was constantly nodding when I was reading the blog. I came to realize that the reason why I learned so many things in my implementation projects is because of these too many responsibilities.

    As a technical consultant, I have become more and more inclined to functional areas to back up my technical know-how. Because of these roles, I am currently an ABAP.Workflow.SRM consultant.

    Thanks for this blog! All I can say is that 'I so can relate'.

    Kind regards,
    Reymar Ellazo

    • Thanks Reymar.  I think your title says it all too, technical/functional/skilled.  Intregration expert?
      Maybe we should add that hat?
  • This is so interesting. I'm marketing a seminar on Workflow ( and I'm finding that titles are across the board. Pinpointing the right person is definitely a challenge. How does someone come to be responsible for workflow within a company, and if managing workflows isn't their full-time job, what else are they commonly responsible for?
    • Hi Sean,
      I have heard that those seminars are very good!
      I think it's an eternal struggle - to see where the administration and/or development lies.  Over the past 2 years, I have transitioned much of the Admin to a very skilled SRM guy - he's not a developer per se, but he totally understands the processes.  He also manages the day-to-day running of the SRM system, while I keep my hands in on ECC. 
      It's always a toss-up whether it's the functional superuser or the WF developer or an ABAPer. 
      Where do you think WF Admin belongs??
      • Thanks, Susan! With our attendees, we're finding that they're leveraging the person who best understands SAP and business processes--much like the way you're utilizing the talents of your SRM guy. What's so interesting is that no two companies seem to attack WF projects the same way.
  • As a Business Analyst Technical (my position), my fedoras reflect everything from ABAP to WF to WebDynpro to BSP to cFolders to Adobe forms to functional support analyst whenever the pure analysts are unavailable. In downsized companies these days it's nearly impossible to replace headcount that has been lost, therefore, those left behind pick up more and more responsibility. As the sole implementer and supporter of WF in my company I'd love to expand it more and to increase its usage (as well as visit this forum more frequently), but alas, there is too little time in the day to answer all bells and to wear all hats.  As the saying goes "the squeeky wheel gets the grease", which relegates WF to the background as it hums consistently well, that is, of course, until support packs or rogue config changes.