WORKFLOW BEST PRACTICES

Wed May 10 14:41:16 EDT 2006

Hi Mike:

We are talking about two different things.

I was talking about the job of a workflow developer, the guy who writes the code for a custom workflow that has been designed by a functional expert. And the topic is whether this guy needs light or serious ABAP skills. My opinion is that he needs serious ABAP skills. The coding skills needed for workflows are often underestimated. A workflow developer might not have to code dialog programming, but he sometimes has to change it to have the right event raised. BSP coding is no less challenging than dialog programming.

You are talking about a dream situation where an individual is taking care of both functional and technical stuff, who would be a better candidate for such a person. I agree with your analysis and recommendations for this scenario.

I have high respect for our functional co-workers. Occasionally I play functional roles too. In the real business world out there, the depth of their special skills are also often underestimated. Many believe that one or two weeks' training would be enough, not a year or two, as you suggested. As I said in my prior email, the technologies are updating so fast and the field has become so wide that it might be difficult for an individual functional expert to master all the skills. Thus some degree of specialization might be needed too. 

In my opinion, both workflow as a technology and workflow'ers as a profession need serious promotion in the SAP world. And I hope that our fourm will help.

Thanks,
Larry Hu 

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Pokraka (WUG)
Sent: Wednesday, May 10, 2006 12:36 PM
To: 'SAP Workflow Users' Group'
Subject: RE: WORKFLOW BEST PRACTICES

Hi Larry,

No disrespect intended to any (ex) ABAP programmer out there, but I would disagree here. I have met many and worked with quite a few Workflowers, and some of the best people whom I have a lot of respect for are not the strongest of ABAP-ers. I have done my time as a programmer, and from a workflow perspective I have absolutely no use for knowledge about packed decimals, logical databases, dialog programming, operating system calls, etc.

I advise companies wishing to 'train someone up' to either choose a good functional person who's willing to get their hands dirty or a techie willing to venture into the business/functional world. Both approaches work equally well, but it will take a year or two to really get fully into it.

It's all in how you/the company chooses to approach matters. Do you have a heavily customized system? Is the client intent on having as little custom coding as possible? If they treat workflow as 'black box development' that's just done to spec (far too common for my liking) then you're gong to be heavily ABAP based. If your functional consultants understand WF then you will get reasonably customizable requirements where little coding is needed but you'll spend more time in SPRO than SWO1 and talking to the functional consultants or business people rather than SDN ABAP forums.

A programmer is far more likely to just go ahead and code a solution, whereas a functional person will spend time looking for functional and/or design alternative. Both ways have their drawbacks and advantages, both will get you there in the end; it is only through experience that you will know which the best approach to a given problem will be.

In short, there is no clear answer other than you need to have at least a good *understanding* of ABAP, but you needn't be a complete whiz to design a good workflow.

Cheers,
Mike

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of lianghuan.x.hu at accenture.com
Sent: 10 May 2006 14:56
To: sap-wug at mit.edu
Subject: RE: WORKFLOW BEST PRACTICES

Hi Jocelyn:

I was an ABAP developer before I was assigned to work as a workflow admin, then a workflow developer. I have found that my workflow job demands no less ABAP skills. In fact, I have found the job tougher, not just because you have to learn workflow macros and flowcharts, but because in many situations, you are the "workflow guy", and as such, you are expected to deliver workflow solutions that require both functional and technical skills, many of which being outside the domain of a regular ABAP developer, such as Basis configurations for approvals, emails, etc. That is why I feel upset when I read that a workflow developer only needs light ABAP skills.

Your comment further shows how tough it is to be a good workflow'er, as there are so many new technologies to learn. I even feel that it might be too much for an individual to master them all, and there might be a need for division of work among workflow designers (those who do the functional design), and among workflow developers (those who write the code). It would be wonderful If you could add some more guidance about various career paths for workflow professionals in your book.

Thanks,
Larry

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Dart, Jocelyn
Sent: Tuesday, May 09, 2006 7:24 PM
To: SAP Workflow Users' Group
Subject: RE: WORKFLOW BEST PRACTICES

Very interesting conversation folks... but please remember a few things...

1. Once you get to a 6.20 system ABAP OO skills are much more useful (and thankfully much more common) than BOR skills.  As of 6.20 I am currently of the opinion that the only thing  you should change on a BOR object is the events.... The rest of any development can be ABAP OO with an attribute link to the standard BOR object to use standard attributes methods.

This does change the mix - as it means the specialist skills required to do workflow are reduced in terms of coding.

2. Throughout the conversation I've only seen the flowcharts and the code mentioned, but these days critical workflow skills also include a good understanding of UWL including XML configuration options, and transactions SWFVISU and WF_EXTSRV to set up web service calls.  All of which I would consider base knowledge for a workflow developer without even going into specialist topics like WF-XML. While anyone can fill in a configuration table, understanding XML is usually back in the developer domain.

3. If you are talking about workflow-without-code and you have or are looking at NW04S, start taking a look at Guided Procedures.  Because that is exactly the market Guided Procedures is aimed at.  My assessment is that Guided Procedures will not replace Workflow as we know it but will provide another tool alongside workflow for frequently changing, process owner directed scenarios requiring only light integration. 

Regards,
Jocelyn Dart
Senior Consultant
SAP Australia Pty Ltd.
Level 1/168 Walker St.
North Sydney
NSW, 2060
Australia
T   +61 412 390 267
M   + 61 412 390 267
E   jocelyn.dart at sap.com
http://www.sap.com

The information contained in or attached to this electronic transmission is confidential and may be legally privileged. It is intended only for the person or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any distribution, copying, review, retransmission, dissemination or other use of this electronic transmission or the information contained in it is strictly prohibited. If you have received this electronic transmission in error, please immediately contact the sender to arrange for the return of the original documents.
Electronic transmission cannot be guaranteed to be secure and accordingly, the sender does not accept liability for any such data corruption, interception, unauthorized amendment, viruses, delays or the consequences thereof.
Any views expressed in this electronic transmission are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of SAP AG or any of its subsidiaries. SAP AG, its subsidiaries, and their directors, officers and employees make no representation nor accept any liability for the accuracy or completeness of the views or information contained herein. Please be aware that the furnishing of any pricing information/ business proposal herein is indicative only, is subject to change and shall not be construed as an offer or as constituting a binding agreement on the part of SAP AG or any of its subsidiaries to enter into any relationship, unless otherwise expressly stated.

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of lianghuan.x.hu at accenture.com
Sent: Wednesday, 10 May 2006 12:57 AM
To: sap-wug at mit.edu
Subject: RE: WORKFLOW BEST PRACTICES

Gavin and Mark:

Thanks for your comments.

I did not know some projects trying to build up workflows using workflow developers doing the BO shell only to call  functions and ABAP developers actually coding those functions. Situations like these highlight the need for a workflow developer to have serious ABAP skills.

And let's remember, the ABAP code behind BO is not the only thing a workflow developer has to work on. Sometimes he has to code the right event to trigger the workflow. And some companies want their workflow developers to code or maintain BSP code. ...

There is a big misunderstanding among project leaders that a workflow developer only plays with those graphic flowcharts.

Thanks,
Larry

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Gavin Mooney
Sent: Tuesday, May 09, 2006 10:18 AM
To: SAP Workflow Users' Group
Subject: Re: WORKFLOW BEST PRACTICES

Hi Larry,

It's an interesting question - I think a workflow developer who doesn't know ABAP is like a mountaineer without a rope. In the simplest cases it won't be needed (e.g. a simple approvals workflow) but for anything a bit more complicated it will be.

At my project the client wanted to train two resources in "Workflow without ABAP", and the ABAP parts of their developments would be outsourced to an 'ABAP-er'. They have now seen that this approach doesn't really work and the resources are going to learn ABAP. At design time there are problems as the workflow developer doesn't know what is possible with ABAP and may not know how to specify the ABAP requirements. Also an 'ABAP-er' without workflow experience won't know about containers and the swc* macros, nor the function of a agent determination rule, the BOR, the SAP_WAPI function modules, etc.

I would be interested to know if other people have experience of workflow development without ABAP.

Regards,
Gavin

2006/5/9, lianghuan.x.hu at accenture.com <lianghuan.x.hu at accenture.com>:
>
> Sherie:
>
> Thanks for sharing the document.  But I do not agree with one point
> under "Workflow and ABAP" on Slide 9 which says that a workflow
> developer needs only "light ABAP knowledge". In fact, a workflow
> developer is an ABAP developer with additional workflow skills. A
> workflow developer has to write all kinds of ABAP code that regular
> ABAP developer does, the only difference is that he has to put his
> code behind the business object types. The word "light" is both unfair
> and
misleading.
>
> Thanks,
> Larry Hu
>
>
> n
>
>  ________________________________
>  From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Munday,Sherie J.
> Sent: Monday, May 08, 2006 2:21 PM
> To: SAP Workflow Users' Group
> Subject: RE: WORKFLOW BEST PRACTICES
>
>
>
> Anjan,
> This attachment is a high level summary that we did called Workflow
> 101.  It does not necessarily cover best practices, but you might find
> it
useful.
> The most important tip I would give anyone starting to develop
> workflows is to make sure that the business process is well defined
> before you design the workflow.  If the process is not defined you
> will waste time and effort chasing a moving target and the scope creep
will be unbelievable!!
> Best of Luck,
> Sherie
>
>  ________________________________
>  From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf Of Rakshit, Anjan (CA - Toronto)
> Sent: Monday, May 08, 2006 12:34 PM
> To: sap-wug at mit.edu
> Subject: WORKFLOW BEST PRACTICES
>
>
>
>
>
> Our client is requesting information about the high-level policies,
> guiding principles, and governance for Workflow used by other SAP
> users - particularly any high-tech manufacturing organizations.  The
> client is approaching initial design and configuration of SAP and feel
> they need an overall governance strategy for the implementation,
> change management, and on-going maintenance of Workflow.
>
>
>
> If anyone has a governance document, best practices document or tips
> and tricks on workflow design for SAP, it would be greatly appreciated.
>
>
>
> Thanks and regards
>
>
>
> Anjan Rakshit
>
>
>  ________________________________
>
>
>
>
>
>
> *******************************************************************
> *******************
> Confidentiality Warning: This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential, and
> may be privileged. If you are not the intended recipient, you are
> hereby notified that any review, retransmission, conversion to hard
> copy, copying, circulation or other use of this message and any
> attachments is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately by return e-mail, and
> delete this message and any attachments from your system. Thank you.
>
> Information confidentielle: Le présent message, ainsi que tout fichier
> qui y est joint, est envoyé à l'intention exclusive de son ou de ses
> destinataires; il est de nature confidentielle et peut constituer une
> information privilégiée. Nous avertissons toute personne autre que le
> destinataire prévu que tout examen, réacheminement, impression, copie,
> distribution ou autre utilisation de ce message et de tout fichier qui
> y est joint est strictement interdit. Si vous n'êtes pas le
> destinataire prévu, veuillez en aviser immédiatement l'expéditeur par
> retour de courriel et supprimer ce message et tout document joint de
> votre système. Merci.
> *******************************************************************
> *******************
>
>
>
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you have
> received it in error, please notify the sender immediately and delete
> the original. Any other use of the email by you is prohibited.
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20060510/d047497a/attachment.htm