WORKFLOW BEST PRACTICES
Dart, Jocelyn
jocelyn.dart at sap.com
Wed May 10 20:21:33 EDT 2006
Ok I'm going to stop answering this thread after this....
Yes you can have functional analysts do good workflow with existing components. And yay! to the fact that someone is interested in looking at what's there before developing their own. And again I say ... Guided Procedures! ... is a big interest area for this group.
My mantra has always been that you need both functional (process owner) and technical (workflow developer) people involved in a workflow project - either of which could be responsible for the flowchart itself depending on the skills they have. I honestly don't mind which so long as they do a good job.
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 Mike Pokraka (WUG)
Sent: Thursday, 11 May 2006 2:36 AM
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
More information about the SAP-WUG
mailing list