//Feedback Requested: Are groups responsible for business processes?

Feedback Requested: Are groups responsible for business processes?

I’m specifically looking for feedback on a workflow component I am working on.

We have implemented a workflow engine that maintains a distinction between ResponsibleFor and AssignmentTo.  We have ambiguity around the combination of this concept with group assignment.  I’d like to know what you think.

Here’s the conundrum:

A workflow item has the alias of the person who is responsible for it in a particular stage of the workflow.  Responsibility can span stages.  Each stage is (ideally) aligned with a business task within an overall process. 

Within a stage, we have steps.  This “containment” allows us to model two of the three levels of abstraction within a single workflow model.  Multiple people can be assigned to a different steps at the same time, and the workflow language has constructs for split and join to allow these activities to be coordinated.  The interesting thing to note about this is that assignment does NOT span from one stage to another.  When you leave a stage, all assignments are wiped clean, and the next stage gets an assignment to whomever is responsible for the item.  This provides a way for the workflow modeler to use ad-hoc workflow, while constraining the users from messing up their own business process.

Now add the notion of “assign to group.”  Our customers have asked for a way to indicate that a group of people should be made responsible for a work item, and any one member of the group can “take responsibility” for the item.  The taking of responsibility is not an event.  It simply occurs.  In our app, a person visits a web page, sees the items assigned to the group, selects the item he or she wants to own, and clicks “assign to me”.

My questions, your thoughts:

In your organization, would it be more correct to say that a “group” is responsible for an activity, or that a person is responsible and that the person has delegated assignment to the group.  In other words, if a group is responsible, who is accountable if the item isn’t worked?  If the item is ultimately escalated to someone, wasn’t that person responsible all along?

If you go with the idea of group responsibility: does it span stages?  If we accept that a group is responsible for a set of stages, then one person can take responsibility at one stage… does the responsibility revert to the group when the next stage begins?  In effect, can the group be responsible but an individual be assigned? 

By |2005-05-05T10:49:00+00:00May 5th, 2005|Enterprise Architecture|6 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

6 Comments

  1. John Cavnar-Johnson May 5, 2005 at 1:57 pm - Reply

    I’m not sure how this fits into your model, but I tend see the ‘assign to group’ function not as an assignment, but as a ‘limit the pool of potential assignees’ function. The work item is unassigned until somebody takes ownership. This view is more akin to a security group than an assignment. In that respect, it becomes easier (I think) to let it span stages.

  2. Michiel Schipper May 11, 2005 at 5:34 am - Reply

    Hi Nick,

    Found your blog in my hitlist – thanks for the reference!

    There is quite some literature on the aspect of responsibility versus assignment (often called delegation). Some modern organisation guru’s have introduced group responsibility as a social engineering way of motivating workers. However, most workflow ontologies define responsibility as something that is always associated with a function in an organisation, and at an instance level with a person. This person (who is a teamleader or other middle manager) delegates the actual work to his Dilberts.

    In practice, I have never seen group responsibility work. I did see group assignments in workflow engines, where single users would retrieve work to their personal work queue, thus showing the intention to process the workitem. In many installations I saw, deadline escalation was set up to notify the "responsible" role that work was passing a certain deadline.

    In practice, responsibility for an activity is often explained as a duty to make sure that this activity is assigned, and that the assignee has all necessary resources available to perform the work. These resources can be the right information (system), training, IQ, etc. Thus, the responsible person needs facilities to coordinate work assignment. In my opinion this should for example include a way to redistribute work when someone falls ill, etc.

    Hope this helps; good luck with your workflow component.

    Michiel Schipper,

    Topicus.

  3. MarlonDumas May 17, 2005 at 7:35 pm - Reply

    A quite detailed treatment of the distinction between "responsible to" and "assigned to" can be found in the recently published "resource allocation patterns", which extend the well-known "workflow patterns" to consider task-to-resource relations. See:

    http://sky.fit.qut.edu.au/~terhofst/rp/index.jsp

    Note however that the "resource allocation" patterns does not address the issue of "group work" and the accompanying "shared responsibilities" issues. In other words, the resource patterns are just one step in the direction of providing principled answers to questions such as yours, but (fortunately) there is still more to be done.

  4. Richard Veryard June 8, 2005 at 5:40 pm - Reply

    If you are assuming that one instance of the workflow engine handles the entire business process, then perhaps you can afford to be prescriptive. But if you want to allow federation or interoperability between workflow engines, then you probably want to allow some flexibility about the handover from one engine (instance) to another. For example, this might mean that engine A regards the entire group as responsible for something, while engine B manages intra-group delegation and accountability. And this also seems to reflect more accurately the way management processes often work in large organizations.

  5. Dmitry June 13, 2005 at 9:31 am - Reply

    I think that delegating responsibilities is better, than pre-assigning some group, even if a person re-assignment is easy to do.

    In the real world, the delegation works better.

    Important part is to get CONFIRMATION of the assigned person, plus APPROVAL by management (top next in hierarchy). Delegation could be subject of instant business rules validation.

    To avoid stale business flow, the delegation confirmation / approval should escalate higher b notifying next level management if there is no response on the regular bases (incindent).

    Basically, idea is that in real world, totally automated business flow is impossible, and our task is to not exclude inter-human communication. Still, such communication has to be traced and protocolized in frames of the business flow application.

  6. Fredrik June 28, 2005 at 5:25 am - Reply

    I’m not a big fan of group responsibilities, but when assignment is done by the user himself, there’s always the risk of an activity not getting assigned at all. Maybe one in the group should be picked by the system if noone has claimed the assignment within a certain time span?

    This is obviously depending on what kind of group you have. There could be a "group manager", or the activities should be evenly distributed over the group. Anyway, I really think there should be one single person responsible.

Leave A Comment

fifteen − 12 =