Application Versus Workflow Log Revisited Due to TechEd Presentation

Tue Oct 11 20:58:22 EDT 2005

Hi David, 

Think I may be being quoted in vain here...

The audit trail will only ever show who physically changed the document,
which of course could be WF-BATCH. 

The workflow log shows the history e.g. of how we made the decision to
change the document - who intiated the change, who approved it, etc.
Workflow logs are only transitory in the sense that at some point they
will be archived - and this may be before the archiving of the related
document. 

Depending on your decision making process the workflow log may not be
simple to interpret - particularly if  you went through a few rounds of
rejection/change/reapprove.  Another factor is that you may allow users
to perform actions outside of the workflow - which would skew the data.

In reality of course you need both sets of information to get the full
picture - the audit trail to track direct changes, the workflow log to
track indirect changes and decision making processes related to the
change.   Of course if you can prevent direct changes, then the workflow
logs alone are sufficient, and vice versa. 

>From an audit perspective, when the audit trail shows "WF-BATCH" made
the change, the workflow log must be called to see who changed it. This
is where setting up, e.g. Generic Object Services, is useful - so that
you can see the workflow history in summarized form (and drill down to
detailed logs) alongside the data in question. 

If you want a consolidated log of who changed what, then this is really
where we start talking about BI and capturing the history of completed
processes and audit trails for later evaluation. 

The other issue from an audit perspective is "how long is the history
kept" - and this is where the need to archive work items must be
balanced against data retention.   Of course some information can be
retrieved from the archive, but you would need to make sure that this is
sufficient for audit purposes.  Again BI could be used as a way to
capture summarized data so that the actual work items can be archived
without impunity. 

The pain at the moment is that you have to set up the BI extracts
yourself - but that's not insurmountable if you really need it.   As
Alan mentioned some months back, in future, sending workflow data to BI
will be able to use SAP provided extracts. 

There's another thing that you should consider - is your workflow log
legible - i.e. can an auditor or other interested party look at the
summarized log and clearly understand who was involved in the decision
making process. This is where using good, standardized work item texts
and the "step not in workflow log" option to hide technical steps in the
summary log can help satisfy audit requirements. 

If I were you, I would definitely not create a custom table... I would
be showing your auditor(s) the workflow logs, and discussing whether:
a) the information shown is sufficient 
b) how the long the information needs to be kept
c) what level of detail needs to be kept 

Hope that helps. 

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 Trant, David
Sent: Wednesday, 12 October 2005 5:52 AM
To: SAP Workflow Users' Group
Cc: Guan, Yan
Subject: Application Versus Workflow Log Revisited Due to TechEd
Presentation

In a thread on the WUG dated September 8 - 12, 2005, and entitled
"Workflow Substitution Report," there was a good discussion that
included whether historical data such as who approved what is best
obtained form the workflow log or the application.  One of the comments
was:

The application is the only reliable source for auditable information,
not workflow.  Workflow logs are transitory and not guaranteed to be the
source of the update.

There were other similar statements, and Jocelyn seemed to confirm this
notion.  A colleague of mine attended a presentation at TechEd Boston
entitled "BP1107 SAP Business Workflow - Harnessing the Power of Five
Questions."  Slide 18 of this presentation looks something like:

Do What - As Little as Possible
  Let the Decision Makers be just that
    Is it necessary for your key decision makers to actually effect
their decision?
    Once the decision has been made, let the system do the work for you!
  Automate Your Processes
    The Workflow environment offers a background (system) user to
perform actions where all necessary decision have been made and the
necessary data is available
    This user is called WF-BATCH
  What about Change Tracking and Auditing?
    Once you rely on WF-BATCH to perform key actions, document headers
are no longer indicative of who was involved.
    Forget the header, look to the Log!

The last point on the slide seems to contradict the consensus from our
earlier e-mail string.  We are redesigning an existing custom workflow
on 4.6C that involves changing the status of a sales order to indicate
where we are in an approval process.  Today, the status object change
log indeed shows WF-BATCH as the user making all the changes.  Our
auditors would like to know who actually approved these changes, and
based on experience and the WUG e-mail thread, I'm reluctant to rely on
the log for this, even if it were easy to do so programmatically - and
it's not!  As much as I hate to create a custom table to store such
information, I'm starting to lean toward that solution.

Does anyone have additional thoughts as to whether we really should be
relying on the log for reporting, including auditing?  Given that we
archive completed workflows after 60 days due to performance needs, I'm
not sure how viable that would be for us.  Eventually, I envision this
type of information being sent to BW prior to archiving, but since we
don't have a BW solution for workflow objects right now, that isn't
viable for us either at the moment.  The only other option I see is to
force the user to make the changes directly in the application so their
userID is actually listed, but then that defeats the joy of having the
workflow execute the step for them in the background.

Any thoughts on the subject?

Thanks,
David
------------------------------------------------------------------------
------------------------
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 unauthorized use of
this email is prohibited.
------------------------------------------------------------------------
------------------------
[mf2]

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