Application independant workflow ?

[Mike Pokraka]

Hi Phil,

SAP is regarded one of the best (if not the best) workflow engines out
there, it's biggest drawback is that you need to run SAP apps to take full
advantage. However I'd still see it as a perfectly useable tool. Amongst
the biggest strengths are the organizational management and routing
capabilities. Naturally there will be processes which will cross over into
your SAP systems, which means you're all set to go with minimum interface
headaches.

You say 200 apps, are you talking separate applications?!?? Or 200
processes. The concept of business object is academic, every process
revolves around one or more objects. So if you want to define a
'MarketingEvent' object, go ahead. An object doesn't need a key, so you
don't even need anything in the database, just create your BO and add your
methods to form your tasks. Or go one better - this is a perfet
opportunity to go fully ABAP-Class based.

Other pros for SAP WF is the open architecture - XML, SOAP and various
other TLAs which all make it (supposedly) interact nicely with other
compliant apps. With the latest NW, you can even mail out PDF forms, have
people fill them in and receive them back into WF (might address the
userid-question Mark raised). I plan to check this one out at TechEd (See
you there, Sherie).

Concering your 'development effort' concerns... you're going to have that
if you are replacing a WF system anyway, might as well make it a
re-useable effort.

In short, I say it's perfectly feasible but still depends on the exact
nature of the existing apps.

Cheers,
Mike


On Tue, September 5, 2006 23:17, Philip Kisloff wrote:
> Thanks Paul,
>
> I agree there is the development track, and building up a workflow from
scratch is the way to do that.
> But, and there is a but, our support model doesn't scale up to make this
a corporate standard. Say 200
> applications would be using SAP, I would imagine that would be a big SAP
workflow team needed in place
> for all the custom developments, something perhaps tricky to source.
>
> Now, if we could leverage a packaged solution's customising approach to
implementation, after the initial
> implementation costs might support could be cheaper and more feasible ?
Anything dealing with this
> constraint in the new NetWeaver suite ?
>
> Phil
>