<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<TITLE></TITLE>
<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=2><FONT face=Arial>Hi Mike:<BR><BR>We are talking about two
different things.<BR><BR>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 <U>light or
serious</U> 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.<BR><BR>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.<BR><BR>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. </FONT></FONT></P>
<P><FONT size=2><FONT face=Arial>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.</FONT></FONT></P>
<P><FONT face=Arial size=2></FONT><FONT size=2><FONT
face=Arial><BR>Thanks,<BR>Larry
Hu <BR></FONT><BR> <BR><BR>-----Original Message-----<BR>From:
sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>] On
Behalf Of Mike Pokraka (WUG)<BR>Sent: Wednesday, May 10, 2006 12:36 PM<BR>To:
'SAP Workflow Users' Group'<BR>Subject: RE: WORKFLOW BEST PRACTICES<BR><BR>Hi
Larry,<BR><BR>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.<BR><BR>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.<BR><BR>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.<BR><BR>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.<BR><BR>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.<BR><BR>Cheers,<BR>Mike<BR><BR>-----Original
Message-----<BR>From: sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>] On
Behalf Of lianghuan.x.hu@accenture.com<BR>Sent: 10 May 2006 14:56<BR>To:
sap-wug@mit.edu<BR>Subject: RE: WORKFLOW BEST PRACTICES<BR><BR>Hi
Jocelyn:<BR><BR>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.<BR><BR>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.<BR><BR>Thanks,<BR>Larry<BR><BR><BR><BR>-----Original Message-----<BR>From:
sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>] On
Behalf Of Dart, Jocelyn<BR>Sent: Tuesday, May 09, 2006 7:24 PM<BR>To: SAP
Workflow Users' Group<BR>Subject: RE: WORKFLOW BEST PRACTICES<BR><BR>Very
interesting conversation folks... but please remember a few things...<BR><BR>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.<BR><BR>This does
change the mix - as it means the specialist skills required to do workflow are
reduced in terms of coding.<BR><BR>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.<BR><BR>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. <BR><BR><BR>Regards,<BR>Jocelyn
Dart<BR>Senior Consultant<BR>SAP Australia Pty Ltd.<BR>Level 1/168 Walker
St.<BR>North Sydney<BR>NSW, 2060<BR>Australia<BR>T +61 412 390
267<BR>M + 61 412 390 267<BR>E
jocelyn.dart@sap.com<BR><A
href="http://www.sap.com">http://www.sap.com</A><BR><BR>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.<BR>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.<BR>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.<BR><BR><BR>-----Original
Message-----<BR>From: sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>] On
Behalf Of lianghuan.x.hu@accenture.com<BR>Sent: Wednesday, 10 May 2006 12:57
AM<BR>To: sap-wug@mit.edu<BR>Subject: RE: WORKFLOW BEST PRACTICES<BR><BR>Gavin
and Mark:<BR><BR>Thanks for your comments.<BR><BR>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.<BR><BR>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. ...<BR><BR>There is a big
misunderstanding among project leaders that a workflow developer only plays with
those graphic flowcharts.<BR><BR>Thanks,<BR>Larry<BR><BR><BR>-----Original
Message-----<BR>From: sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>] On
Behalf Of Gavin Mooney<BR>Sent: Tuesday, May 09, 2006 10:18 AM<BR>To: SAP
Workflow Users' Group<BR>Subject: Re: WORKFLOW BEST PRACTICES<BR><BR>Hi
Larry,<BR><BR>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.<BR><BR>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.<BR><BR>I would be interested to know if other people have
experience of workflow development without
ABAP.<BR><BR>Regards,<BR>Gavin<BR><BR>2006/5/9, lianghuan.x.hu@accenture.com
<lianghuan.x.hu@accenture.com>:<BR>><BR>> Sherie:<BR>><BR>>
Thanks for sharing the document. But I do not agree with one point<BR>>
under "Workflow and ABAP" on Slide 9 which says that a workflow<BR>>
developer needs only "light ABAP knowledge". In fact, a workflow<BR>>
developer is an ABAP developer with additional workflow skills. A<BR>>
workflow developer has to write all kinds of ABAP code that regular<BR>> ABAP
developer does, the only difference is that he has to put his<BR>> code
behind the business object types. The word "light" is both unfair<BR>>
and<BR>misleading.<BR>><BR>> Thanks,<BR>> Larry
Hu<BR>><BR>><BR>> n<BR>><BR>>
________________________________<BR>> From: sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>]
On<BR>> Behalf Of Munday,Sherie J.<BR>> Sent: Monday, May 08, 2006 2:21
PM<BR>> To: SAP Workflow Users' Group<BR>> Subject: RE: WORKFLOW BEST
PRACTICES<BR>><BR>><BR>><BR>> Anjan,<BR>> This attachment is a
high level summary that we did called Workflow<BR>> 101. It does not
necessarily cover best practices, but you might find<BR>>
it<BR>useful.<BR>> The most important tip I would give anyone starting to
develop<BR>> workflows is to make sure that the business process is well
defined<BR>> before you design the workflow. If the process is not
defined you<BR>> will waste time and effort chasing a moving target and the
scope creep<BR>will be unbelievable!!<BR>> Best of Luck,<BR>>
Sherie<BR>><BR>> ________________________________<BR>>
From: sap-wug-bounces@mit.edu [<A
href="mailto:sap-wug-bounces@mit.edu">mailto:sap-wug-bounces@mit.edu</A>]
On<BR>> Behalf Of Rakshit, Anjan (CA - Toronto)<BR>> Sent: Monday, May 08,
2006 12:34 PM<BR>> To: sap-wug@mit.edu<BR>> Subject: WORKFLOW BEST
PRACTICES<BR>><BR>><BR>><BR>><BR>><BR>> Our client is
requesting information about the high-level policies,<BR>> guiding
principles, and governance for Workflow used by other SAP<BR>> users -
particularly any high-tech manufacturing organizations. The<BR>> client
is approaching initial design and configuration of SAP and feel<BR>> they
need an overall governance strategy for the implementation,<BR>> change
management, and on-going maintenance of
Workflow.<BR>><BR>><BR>><BR>> If anyone has a governance document,
best practices document or tips<BR>> and tricks on workflow design for SAP,
it would be greatly appreciated.<BR>><BR>><BR>><BR>> Thanks and
regards<BR>><BR>><BR>><BR>> Anjan
Rakshit<BR>><BR>><BR>>
________________________________<BR>><BR>><BR>><BR>><BR>><BR>><BR>>
*******************************************************************<BR>>
*******************<BR>> Confidentiality Warning: This message and any
attachments are intended<BR>> only for the use of the intended recipient(s),
are confidential, and<BR>> may be privileged. If you are not the intended
recipient, you are<BR>> hereby notified that any review, retransmission,
conversion to hard<BR>> copy, copying, circulation or other use of this
message and any<BR>> attachments is strictly prohibited. If you are not the
intended<BR>> recipient, please notify the sender immediately by return
e-mail, and<BR>> delete this message and any attachments from your system.
Thank you.<BR>><BR>> Information confidentielle: Le présent message, ainsi
que tout fichier<BR>> qui y est joint, est envoyé à l'intention exclusive de
son ou de ses<BR>> destinataires; il est de nature confidentielle et peut
constituer une<BR>> information privilégiée. Nous avertissons toute personne
autre que le<BR>> destinataire prévu que tout examen, réacheminement,
impression, copie,<BR>> distribution ou autre utilisation de ce message et de
tout fichier qui<BR>> y est joint est strictement interdit. Si vous n'êtes
pas le<BR>> destinataire prévu, veuillez en aviser immédiatement l'expéditeur
par<BR>> retour de courriel et supprimer ce message et tout document joint
de<BR>> votre système. Merci.<BR>>
*******************************************************************<BR>>
*******************<BR>><BR>><BR>><BR>><BR>><BR>> This message
is for the designated recipient only and may contain<BR>> privileged,
proprietary, or otherwise private information. If you have<BR>> received it
in error, please notify the sender immediately and delete<BR>> the original.
Any other use of the email by you is prohibited.<BR>><BR>><BR>>
_______________________________________________<BR>> SAP-WUG mailing
list<BR>> SAP-WUG@mit.edu<BR>> <A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR>><BR>><BR>><BR><BR>_______________________________________________<BR>SAP-WUG
mailing list<BR>SAP-WUG@mit.edu<BR><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR><BR>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.<BR><BR>_______________________________________________<BR>SAP-WUG
mailing list<BR>SAP-WUG@mit.edu<BR><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR>_______________________________________________<BR>SAP-WUG
mailing list<BR>SAP-WUG@mit.edu<BR><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR><BR>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.<BR><BR>_______________________________________________<BR>SAP-WUG
mailing list<BR>SAP-WUG@mit.edu<BR><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR><BR><BR><BR>_______________________________________________<BR>SAP-WUG
mailing list<BR>SAP-WUG@mit.edu<BR><A
href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</A><BR></P></FONT><div id="##disclaimer##"><p></p><p style="FONT-SIZE: x-small; FONT-FAMILY: Arial, Sans-Serif">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.</p></div></BODY></HTML>