Method for Operator Setting Being out of Process Model

Hello, everyone.

Another fiscal year has started here in Japan.
I suppose the organizational changes have been made in many of the companies in this season.

 
Work is very hard“, I hear from customer users, saying “for the organizational changes that is going to be made again, also in this year!“.
(To be exact, I heard it around February and March, though…)
 

On the other hand, they say there are greater or lesser changes of organization and roles around a year, regardless of the fiscal year.

Settings on Questetra BPM Suite must follow the organizational changes of user company, as well.

The procedure of change will be;

  1. Modification of the User/Organizational information
  2. Modification of “Operator setting” in Process Models according to the changes in organizational hierarchy
  3. Releasing the Process Models
You must be careful in proceeding these or it will be a big trouble if you made mistakes in setting.

Modification of “Operator setting” in Process Models according to the changes in organizational hierarchy” is particularly important, especially if;

  • Target Process Models are many
  • Organizational hierarchy is multi-staged (3 or more levels)
  • The depth of the organizational hierarchy is different by the organizations
  • Organizations increase or decrease frequently

I would like to introduce an example that allows you;

  • Easy to understand the approval route
  • Process Models to be less likely to be affected by organizational change

by devising in Process Model designing.
 

<Sample Organization chart>
Sample Organization chart

I would like to make this example on assumption of a business which the requirements are;

  • The first approver is always a User of the same organization with leader attribute
  • Go with the approval to the upper layer along the hierarchy

within an organization of above figure.
Even though it seems the frequent case, its implementation is surprisingly difficult.

The difficult point is that the hierarchy of approver varies by the level of the hierarchy where the applicant is assigned.
If you provide a Swimlane for each layer and you configure Operator setting relatively to the applicant, for example, there will be a problem which Approval Step will not be carried out in desired Swimlane for the staff of “Marketing Dept.” or “IT Dept.”, although there is no problem for the staffs in “Sales Team 1”.(As well as the staffs of “Sales Dept.” and “Sales HQ”.)

There will be solutions that are available by using Script Task and Conditional split (or other methods), but also, there will be problems as follows.

  • Complexity of Process Model
  • Problem upon organizational change (Revising will be required in many Process Models.)

 

You are able to correspond these problems by the following measures.

  • To determine the approval route in each organization in advance
  • To store the approval route information outside the Process Model (Options XML)
<Overview>
Overview

Put the approval route information on the organization figure above, into a table.

<Approval route Matrix>
Approval route Matrix

* The numbers in the table stand for each layer. Approval is carried out in ascending order of the numbers.
3= Dept. layer, 2= HQ layer, 1= Directors layer

To describe the “Approval route Matrix” above into Options XML, is as follows.

<Options XML; Approval Route>

<items>
<item value="Director役" display="::" />
<item value="IT Dept." display="::Director" />
<item value="Sales HQ" display="::Director" />
<item value="Sales Dept." display=":Sales HQ:Director" />
<item value="Sales Team 1" display="Sales Dept.:Sales HQ:Director" />
<item value="Sales Team 2" display="Sales Dept.:Sales HQ:Director" />
<item value="Marketing Dept." display=":Sales HQ:Director" />
</items>

<Configuration of the Options XML>

<item value="Applicant's Org." display="Dept. layer Org.:HQ layer Org.:Director layer Org.">
Approval route where the applicant belongs to “Sales Team 1”
Sales Team 1 -> Sales Dept. -> Sales HQ -> Directors

In this case, Options XML is;

<item value="Sales Team 1" display="Sales Dept.:Sales HQ:Director" />
Approval route where the applicant belongs to “IT Dept.”
IT Dept. -> Directors

In this case where “Dept. layer” and “HQ layer” do not exist, so the Options XML is;

<item value="IT Dept." display="::Directors" />

(Dept. layer / HQ layer are blank)

<Implementation sample: Process Model>
Implementation sample: Process Model

The main points are as follows.

  • Searching for the Approval route out of “Approval route (Options XML)”, based on the applicant’s organization upon completion of application. (Script Task)
  • Setting the search result into Process Data items that are arranged for each layer
  • Using the Process Data items that are arranged for each layer for Operator setting of Swimlanes of Dept./HQ/Directors

<Approval route (Sample setting of Script Task “approval route (Options XML) search>

var requestOrgNum = "0";   // Applicant's
var accept3rdOrgNum = "1"; // Organization of the third layer (Dept.)
var accept2ndOrgNum = "2"; // Organization of the second layer (HQ)
var accept1stOrgNum = "3"; // Organization of the first layer(Director)
var acceptRootFileName = "General Approval route";  // Approval route Optionsw XML
var orgs;
var sep = ":";
// Retrieving Applicant's organization name
var requestOrgName = (data.get(requestOrgNum)).getName();
// Search for Approval route by the Applicant's organization
var item = itemDao.findByValue(acceptRootFileName,false,requestOrgName);

if (item != null){
	orgs = (new String(item.getDisplay())).split(sep);
	if (orgs[0] != null){
		retVal.put(accept3rdOrgNum,qgroupDao.findByName(orgs[0]));
	}
	if (orgs[1] != null){
		retVal.put(accept2ndOrgNum,qgroupDao.findByName(orgs[1]));
	}
	if (orgs[2] != null){
		retVal.put(accept1stOrgNum,qgroupDao.findByName(orgs[2]));
	}
}

 

Expected advantages are as follows.

  • You will be almost able*1 to correspond organizational changes by revision of Approval route (Options XML).
    (No need to modify Process Models)
  • Approval route (Options XML) can be described intuitively easy-to-understand.
    (Refer to Approval route Matrix above.)
  • You will be able to automatically generate Approval route (Options XML)*2.
*1 You will need to revise Process Models when the hierarchy increases.
*2 E.g. Creating Approval route with Excel, generating Options XML using Macro.

In short, you might say “You can apply from the Approval route that is described in the internal regulations intuitively.

In addition, some business operation may require skipping over of hierarchies.
In these cases, you can easily implement by preparing another Approval route (Options XML) for individual purpose.

The disadvantage is “laborious of the creation of the approval route (Options XML)“.
You need to set up the Approval route of the entire organization.
Settings are easy to understand, on the other hand, creating work will be laborious. (It will be too tough If you do not automate the creation.)
 

In fact, there is a similar way of implementation.
It can be achieved in a more simple by the use of Roll. (I will introduce in the next and subsequent)

This time, there is a characteristic on the point where “Operator setting exists out-of-Process Model“.
I hope that you can effectively apply in some cases.

Please give it your consideration.

2016-04-18

About Masato Furukubo

Questetra, Inc. Sales Department
View all posts by Masato Furukubo

Recommendations
Prev article - 50. Questetra Tips Measures for "Cannot Delete Issues!"
Next article - 50. Questetra Tips How to Substitute Approval Step with "Email Reply"
Another article - Masato Furukubo How to Change Filenames Automatically following the Rule

Archive

 RSS