Hi, there.

This post is a continuation of the series of „Cool Evaluation Method for Workflow Systems„.

Looking back on the Evaluation method (1)

The other day, I introduced in a post which was „Cool Evaluation Method for Workflow Systems (1)„, the steps of how to evaluate Questetra BPM Suite.

Then somebody told me that „I understand the flow of evaluation, alright, but I want to know about the construction concretely. Especially I want to know the tips for writing Workflow diagrams from scratch!“ So, I would like to tell about my „ideas of ways designing Workflow diagram“, since I have been doing that for almost 10 years. Wish this will help you.

Steps in a flow of designing are as follows.

1, Summarize the business rule
2, Analyse the summary
3, Put it down into a Workflow diagram

I will explain in a simple reporting work for a superior and a subordinate as an example.

Summarizing and analyzing of a business rule

First, you work on „1, Summarize the business rule„. Let’s first organize the business rule to be the target by sentences.

<Business rule: by hearing>
* The superior instructs the subordinate to prepare a report, and the subordinate prepares and submits it to the superior.
* The superior checks the submitted content.

The results of the hearing are as above. Next, you summarize in a bullet. Here are some things to keep in mind:

* Clarify the subject, the predicate, and the object.
* Make sentences into a bullet and clarify outputs
* Arrange in time series.

When you arrange these, it will be as the following.

<Business rule: summary>
1, The superior instructs preparation of a report to a subordinate. (Output: instruction of report preparation)
2, The subordinate prepares a report and submits it to the superior. (Output: a report)
3, Checking it, the superior sends back if it has a problem, otherwise, ends the Process. (Output: a result of checking on the report)

If you look at the summary, don’t you feel like you can draw a workflow diagram anyhow? If you map these sentences to Swimlanes and Tasks, the sentences by the hearing at the beginning will be drawn in the workflow diagram.

Drawing the content of sentence #1 into Process diagram

* „1,“ is the starting step of work, so it will be connected from a „Start Event“.


I guess you might wonder that „Hm? What happened to the part of „to a subordinate“?“ It will be clear when you put the sentence #2.

Drawing the content of sentence #2 into Process diagram

Likewise, when you draw the content of sentence #2, it will be as the figure below.


The part of „to a subordinate“ is expressed by the direction of the arrow connecting the steps of „Instruct Preparation“ and „Prepare/Submit„. In addition, for the subordinate, there are two tasks of „prepare a report“ and „submit a report„. However, those are things that can be done successively at a time, so those can be combined as one step.

Drawing the content of sentence #3 into Process diagram

When you put #3 in the same way as #1 and #2, it will be as the following figure, and it is completed.


* Since work is completed with #3, it is connected to an „End Event„.

Closing

Although the example, „Reports management“ work in this post, is quite simple, you now understand that drawing a Workflow diagram with the sentences of a business rule is rather easy, I suppose. It is important „to confirm how the workflow you want to achieve will turn out to be“ when evaluating workflow systems, not only for Questetra. Why don’t you try comparing and evaluating by organizing your business rules using trial services, if you have similar workflow systems other than Questetra to evaluate?

Next time, I would like to go further and explain the tips for setting the details based on the workflow diagram created in this post.

Supplement

I have named the Tasks respectively as „Instruct Preparation„, „Prepare/Submit„, and „Check„. You may consider that it is not easy-to-understand „to do so to what“ only at a glance on the names. However, suppose if you name this work (Business Process) as „Reports Submission Management“, then workers will be able to understand the object is a report, by the combination of Task names and the Process name. Therefore, you can name Tasks only with the predicate of it and omit its object.

About The Author

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Nach oben scrollen
%d Bloggern gefällt das: