Workflow functional specification

[David Trant]

Here's something I came up with a while back:
 
I have come up with a list of “header level” and “work item level” bullet points of content that I think are good to have in a functional design for workflow.  Obviously, not every item will necessarily apply to any given workflow definition.  If you could incorporate these items into the functional design template, that would be great.  The first list can be added pretty easily.  For the “item level” points, there are a couple of possible approaches.  The template can simply be repeated over and over for each step in the workflow.  Alternatively, a spreadsheet could be used with rows for the work items and columns for the bullet points listed below.
 
Here is the “header level” information:
 
·       Detailed description of end-to-end process workflow process (as a part of the overall business process)
·       VISIO diagram of the workflow process
·       Name of the workflow (i.e. Address Change) – if there is a corresponding SAP workflow, give its name and, if available, technical number (WS20000123)
·       Triggering event(s) or other triggering mechanism(s), including any needed filters or start conditions (restrictions such as only start the workflow if certain rules are satisfied, such as particular data fields having specific values)
·       Terminating event(s) if applicable – an example would be if a relevant document is deleted while the workflow is in progress, then perhaps the entire workflow should be terminated rather than allowed to continue while referencing a document that no longer exists.
·       Mass update concerns:  if there is an expectation that mass updates could occur that would raise the event that triggers this workflow, address whether any special handling is required.  For example, if the workflow is initiated by a change to a particular document, and there is a job that runs periodically to update a large number of these documents, then a decision should be made whether it is appropriate for the workflow to commence in these situations.  If not, then the mass update procedure needs to include a step to disable the event linkage during the update and then re-enable it.  Then, the scenario of a “normal” update occurring during this window needs to be considered as well.
·       Business object being used (i.e. BUS12345) if applicable
·       Escalation – overall escalation and deadline monitoring requirements; note that each step will have its own individual escalation procedure
·       Organizational structure and agent determination – note the overall org structure / agent determination approach (i.e. state that the HR org structure will be used, or individual rules to be defined for each step will be used and will reference positions in the overall HR structure – note any unusual requirements); address ongoing maintenance as well – who will be responsible for both initial data population and day-to-day maintenance going forward; also note any special requirements with regard to forwarding of work items
·       Auditing and metrics – note any special requirements, and be sure to include specific requirements in the individual steps below
·       Estimate the volume of workflow instances expected and note any known performance concerns
·       Workflow administration:  identify who will be responsible for ongoing administration of this workflow from a functional perspective; duties include handling of errant workflows (as notified by the technical workflow administrator), including missing or incorrect agents, unexpected results, etc.  It is also a good idea to have this person or group of people proactively monitor the “health” of the workflow, typically by watching the built-in metrics
·       Be sure to consider security and authorization in the back-end system and in the portal
 

Here is the information to be included for each step / work item in the workflow:
 
·       Process step / activity name
·       For user activities, work item subject (to appear in the users’ inbox / work list, including parameters) – i.e. “Approve address change for user <userID>.”  If this is a system or background task, indicate that here.
·       For user activities, work item description – detailed description, including variables and parameters – i.e. “Please approve the address change for user <userID>.  If request is denied, please provide reason for denial in field blah blah blah.”
·       Transaction code, Adobe form, web screen, or other application to be invoked by this step.  If this is a method of a business object, give the method name here.  If detailed technical information is unknown, give as much functional information as possible as to what activity is being performed within this step.
·       Terminating events:  what events, if any, indicate this step is complete?  This is useful for both normal termination of a step, and to accommodate the possibility that someone performs an activity outside the workflow.  For example, if a status change indicates that the workflow should move on regardless of whether an agent actually executed the current work item, then this is a terminating event for the step.
·       Outcomes:  list the possible outcomes for this step, giving the name and descriptions of each one, for example “request approved,” “request rejected,” and “request sent to secondary approver.”
·       Confirm end of processing:  indicate whether this step requires a specific confirmation of completion by the user.  This is useful when the work item invokes a generic transaction such as “change document,” and the user may or may not have actually completed the task at hand.  A pop-up asks the user to confirm whether the activity is complete and, if not, retains the work item in the inbox for later reprocessing.
·       Agent determination:  give possible agents, actual agents and excluded agents.  Possible agents will define who is authorized to perform this task in general.  For actual agents, give the rule or algorithm for determining who should receive the work item.  For example, it may be that person’s “chief” in the org structure, or it may be a more complicated rule based on parameters or other input.  For excluded agents, indicate if someone should be disallowed.  An example of the use of excluded agents is when, say, two approvers are required from a pool of agents, so the first approver is excluded from also being the second approver.  If special handling is required when no agent is found, define it here as well.  Also note any forwarding restrictions or requirements.
·       Escalation:  define any deadlines and how they are determined (number of hours, days, etc. after the entire workflow begins, or after this step has been sent, etc.), and what action is to be taken (notification sent, work item re-routed [and to whom], additional processing [define in additional steps], etc.).  Not all steps need to have deadlines defined.  Four deadlines are possible, although “latest end” is the most commonly used.  Possible deadlines are:  requested start, latest start, requested end and latest end.
·       Notifications:  define any notifications that need to occur that indicate a work item has been created.  Include the agent, subject text and descriptive text of the notification.  If the recipient is expected to perform any work that needs to be tracked by the workflow, do not use notification and instead create a separate task.
·       Error handling:  define the error paths for any known exceptions that may occur within this step.  For example, if the step is a background step to update an address, and the user’s record could not be found, then what needs to take place next – a notification to someone perhaps, or a work item to an administrator to manually complete the task?
·       Parallel processing:  indicate algorithm for parallel processing if applicable.  This is useful if the same step is to be executed for each of, say, several line items in a document or entries in a table.

Enjoy,
David



> Subject: RE: Workflow functional specification> Date: Tue, 15 Jan 2008 13:20:40 -0600> From: Rick.Sample at gbe.com> To: sap-wug at mit.edu> > Ed,> > I don't really have a 'good' Functional template, but I do have a tool> for Estimating WF development time.> Was initially created by someone named D. Harmon and I added a bunch of> other stuff. (I think I got it off this list)> > Visual (spreadsheet) for showing all that is required. > Example: > A task of difficulty (H, M, L) takes X1 time, > a BOR Object of difficulty (H, M, L), takes X2 time, > etc. > Each object is configurable for how much time you think it should take. > Great for showing management the break down of what is actually> required.> > Let me know and I will e-mail it to you...> > > ________________________________> > From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf> Of Edward Diehl> Sent: Tuesday, January 15, 2008 12:54 PM> To: sap-wug at mit.edu> Subject: Workflow functional specification> > > Hello All,> I am looking for a good format for a workflow functional specification> template. If any of you have one that you have used successfully I> would appreciate it if you would send it on to me.> > A lot of the checklist items in The Book are helpful, but a functional> spec for workflow can encompass so many things, such as special metric> reporting requirements. I'm sure many of you have experienced the> frustration of trying to make some enhancement or interface or report> functional spec work for workflow. Surely some innovative person out> there has managed to bridge the gap.> > Thanks,> Ed Diehl> > > > > ________________________________> > Get the power of Windows + Web with the new Windows Live. Get it now!> <http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008>> > > > _______________________________________________> SAP-WUG mailing list> SAP-WUG at mit.edu> http://mailman.mit.edu/mailman/listinfo/sap-wug
_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080115/02b3ea9d/attachment.htm