Guided Procedures and Workflow

jerry.martinek jerry.martinek at shawbiz.ca
Fri Jun 9 09:51:51 EDT 2006


Hi Jocelyn,

We haven't tried a lot of the things you're suggesting for various different
reasons as well as not being aware of some of the product features.

At this point in the development stage of our project, introducing new
unknown technology to write our own travel request and expense application
is not the correct decision. 

Your answer confirmed my suspicion that there is more to it than you're led
to believe. So when a non IT person reads that article, they get the
impression that the IT guys are holding back. They can't understand why
we're telling them that it's not that straight forward in 'our' case.

Thanks,
Jerry   

-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of
Dart, Jocelyn
Sent: June 9, 2006 12:18 AM
To: SAP Workflow Users' Group
Subject: RE: Guided Procedures and Workflow

Hey Jerry, 

The standard SAP trip allows you to split up the  travel request items to
different accounts. We use the same one at SAP and it works fine. 

Possibly its a missing customization issue?  Or it's just the EP views that
are a problem
in which case yes you are better off adjusting the iviews.   You could try
calling the original app via SAPGUI for HTML as well. 
 
Have you checked to see if there is an Adobe or WebDynpro version that you
can use?  This will probably depend on the backend release you are running
ESS on, as with NW04s portal you have the lot in terms of capability.  Both
would let you do attachments or easily extend to do attachments. 

Also remember that in NW04s the UWL has the attachment manager which may
give you some further options, e.g. start form, send work item "do you have
any attachments" (make it processing rejectable), then go forward to
approval. 

GP will let you do attachments but:

1. Remember its still relatively new - e.g. agent determination and
asynchronous/terminating event functionality is not approaching the standard
of SAP Workflow as yet.

2. You still need an underlying application to call from GP - similar to
workflow.  You can use Adobe or a WebDynpro for instance as an alternative
to iviews.  It does provide a number of helper applications but for
something as complex as a travel request you will probably end up doing your
own app or an adjusted version of SAP's standard app anyway. 

GP is great if you want to run a step by step process that your business
analyst maintains and that may run against multiple backend systems - i.e.
if you want process integration driven by the business rather than IT.  But
it's still early days and you should not expect the depth of features you
find in SAP Workflow currently.  

If your management is super keen you might want to do a proof-of-concept to
explain the differences.  Given the trip request is fully in one system, and
given the relative maturity of Workflow vs GP, I would suggest SAP Workflow
is probably going to meet your needs better, even if you have to do some
work on the web app for the original travel request entry. 

Don't discourage them from using GP - it's going to be a case by case basis
for a while yet.  For the moment think - multi-system/frequent business
changes -> GP, single system/stable process/deep integration -> Workflow. 

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
Mikko Mäki-Rahkola
Sent: Friday, 09 June 2006 4:39 PM
To: sap-wug at mit.edu
Subject: Re: Guided Procedures and Workflow

Hi Jerry,

Alan will probably give you a more 'official' view on GP himself but
here are my comments...

First, I didn't quite understand one of the requirements you stated.
What did you mean by travel request itemization? Do you have a
requirement to split up the travel request advance amount?

Writing the travel doc entry applications from scratch is I think a
huge task, not only do you need to get all the view logic there but
also connect to the backend to get help values, transfer the data etc.
So I think the business case might not be that good counting in the
maintenance cost in addition to the development cost.

Couldn't you just modify the current travel request/expense report Web
Dynpro apps directly and then use them as is? SAP delivers the source
code for these so putting in some logic of your own (like attachment
entry or itemization) shouldn't take that long from a skilled WD
developer.

In my current project we have implemented Web Dynpro-enabled travel
request and expense report approval workflows (running on ECC5.0 &
EP6.0). We have had some smaller changes done to the entry
applications and created a custom approval/checking application (I
believe ECC6.0 has a standard app for this), too. All this works well
together, workflow as the backbone glueing all the WD pieces into a
fully web-enabled workflow.

Regarding Guided Procedures, I think you can't directly include the
standard travel WD apps there because of missing WD interfaces. Using
GP would thus basically require you to develop your own GP-supported
Web Dynpro application or a plain form, which brings me back to the
business case point I raised at first. SAP's view on GP's usage also
seems to be against this, I believe they recommend GP only for
departmental processes, not company-wide like a travel request or
expense report approval process.

So in conclusion, I believe GP might not be the best choice here. You
have quite a lot of existing functionality exposed as Web Dynpros
which you can use by doing small modifications and tying them up with
workflow. The other GP way would require a lot of SAP standard
overwriting and would leave you out on your own regarding support.

If you are interested in our project details, please contact me
directly and I'll be happy to share any helpful information.

Best regards,
Mikko
_______________________________________________
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