「クラウド」をキーワードに、情報システムの『所有』から『利用』へのシフトが益々加速する中、クラウドの一形態である SaaS(Software as a Service)も、その接続性が問われる時代になっています。バージョン 7においては、API(Application Programming Interface)機能が大幅に整備拡充され、
Questetra は、米 IT 調査会社ガートナーの「Cool Vendors in BPM, 2010」において『Cool Vendor(注目ベンダー)』に選定されました。
※ BPM: Business Process Management (ビジネスプロセス管理) ※ Gartner “Cool Vendors in Business Process Management, 2010” by Michele Cantara, Jim Sinur, Janelle Hill, and Kimihiko Iijima. (2010-04-09)
This is “not as simple as it seems,” and we often get stuck when finding the answer. Probably, it may be “a combination of several elements that play a certain role as a whole.” For example, “an integrated kitchen system,” stoves, a sink, and storage space help cooking, while “a physical distribution system” is a system in which those who are responsible for pickup, storage, and shipping deliver things.
Likewise, “an information system” is merely “a mechanism to output information”, involving hardware, software, and communication networks.
Figure 1
However, “sales,” “list of royal customers,” “a latest business manual,” and “Top 3 of customer’s comments on the new product,” … As we may know, information that humans would want to know is not enumerable. That’s why numerous system integrators are needed in the society.
Complaints of Entrusters
Here are Top 4 of the moments when entrusters feel dissatisfied!
[Proposal Stage] Low quality of proposals. There is almost no proposal
[Design Stage] I don’t know what’s happening with the latest specification.
[Acceptance Stage] Low quality of products. I want to know how it was tested
[Operation Stage] Late response to inquiries. Sometimes responses are totally irrelevant
These are all based on my experiences, but not more than my personal guess. I do not have any statistical data at all. And, needless to say, of course, entrusters must feel dissatisfied at various moments, for example, when they receive a technical explanation, when they sign a contract, when they see an estimate (!), and so on.
Well, to begin with, I would like to meet “entrusters’ dissatisfaction” by focusing upon a Process related to “delivered product inspection.” The reason why I chose this is simple; that is because, compared to other Processes, many Tasks in this Process are almost independent of human ability. For example, even if the Process related to “Proposal” is not well-organized, some people win “the entruster’s satisfaction.”
Here, members make reports to their project manager upon completion of each “outcome” in the fields that they are engaged in, such as module development, module integration, establishment of production environment, etc. Triggered by those reports, the Inspection Process starts.
Figure 2
In this Process, after the brief confirmation by the project manager, two inspectors, who are chosen arbitrarily, inspect the outcomes and record the inspection reports. Of course, the project manager has to decide, based on his/her experience and discretion, how often and at which timing the outcome reports are to be made.
Contents of Tests
“Including the intermediate inspection report, all should be delivered.”
There are few project managers performing such an act of chivalry. But, as a general rule, “the inspection report per element” of delivered products should be submitted with the system time stamp on it.
Figure 2 (Reprinting)Table 1
In fact, anyone would hesitate to say, “Let’s take CMMI(*).” But, we have to be brave enough to say, “Let’s submit the inspection report of products.” In this case, if there are 100 elements in a product, because there are two inspectors for each element, “(100 + # of re-inspections) * 2 sheets” of the inspection report will be generated.
For your information, as a whole SI business, necessary cost for tests and inspection should occupy at least 20% of the total cost. Roughly speaking, there should be 20 inspectors in an organization of 100 people.
* CMMI: Capability Maturity Model Integration
Existence of “the inspection report” is helpful especially for the sales person in charge. Actually, many sales people can’t grasp what the produced products are like. And, they cannot do anything but accepting the complaints.
However, with “the inspection report,” it is possible for sales people to compare inspection items that the entruster was not satisfied with when examining delivered products against inspected items written in the inspections reports. That is to say, it is possible to compare claims of the entruster and ones of the entrustee.
Explicit Specification and Implicit Specification
The “inspection report” rescues sales people to some extent, but it doesn’t solve “the problem of implicit specification,” which is an eternal issue for humans.
More specifically, it is a problem that occurs in case “the entruster believes certain specifications must be realized” even though RFP, Demand Specification, Requirement Definitions, and any other documents do not mention them.
We have no other way to avoid such a problem but to keep a log of agreed specifications in detail. But, what is “a well-recorded/easy-to-record Process”? I wonder.
Specification Management
When Process output is insufficient:
Are executors wrong?
Is the Process itself wrong?
The Process Owner has to discern which the cause of the problem is. Probability of most human-caused accidents, including information leakage, and misconceptions, can be minimized by improving Processes (in other words, systems).
Now, the situation in which “the final agreed specification is not shared” can be more or less changed by improving document management Process. We must improve the current situation in which after discussions on the basis of drafts, minutes of meeting and reviewed drafts are sent by e-mail and moreover indications about the implication in a long meeting minute are sent repetitively by e-mail.
Figure 3Table 2
The stance of this Process Owner is that:
You can hold meetings as many times as you want
Moreover, you can discuss by e-mail as much as you like
You can do anything as long as you can “keep a log without omission”
However, you have to follow the specific rule only as for “the final decision Process”
Therefore, there are few rules. Moreover, the rule just obligates to make the final decision online. The procedure itself is similar to Diet sessions. Concerning tiny typos or mistakes, all you need to do is to clearly include errata in the online meeting minute. Every stakeholder says “OK,” it’s done. So, there is no need to change the actual document or to discuss again.。
Incidentally, the project manager had better throw him/herself into the role as chairperson. Also, obviously, enough consensus-building in advance is expected in order to conduct “a calm chat.”
Revision Control
What’s called “rule” should be simple. Depending on business, the kind and number of specification to be defined in the project differs. In some cases, the number of files would excess 100. Moreover, some specifications have to be updated in the middle of the ongoing project.
However, all laws, regardless of a new law or an amended one, must pass the Congress. Similarly, any modified specification should also always get approved through a Process of “final agreement of specification.”
That is to say, it is not preferable to search around each individual’s e-mail box when a trouble occurs.
Besides Specification Determination and Acceptance…
Well, I would like to offer some suggestions, focusing only on the conclusions, regarding the remaining two “moments of dissatisfaction” (1 and 4).
[Proposal Stage] Low quality of proposals. There is almost no proposal
[Operation Stage] Late response to inquiries. Sometimes responses are totally irrelevant
Figure 4Table 3Figure 5Table 4
Timing to Brush Up a Process Itself
“A Process” is namely “a rule.” A rule should not frequently be changed. In many cases, we can solve problems by changing personnel allocation and so forth. But, if we can not eliminate “stagnation” or “mistakes” by any means, the Process Owner may take courage in making a decision to change it. [The End]
In Japan, we have an expression “A customer is a god.” Inquiries from customers might be literally “voice of gods.” At least, there are large differences between such customers and others who leave things they do not understand.
Many companies have set up a support desk to deal with complaints of customers. Such a support desk could be a call center or could be an inbound e-mail correspondence team. This “activity to meet complaints” is, seen from another angle, a “Process that enables us to list pieces of information which are not well informed to customers.”
Figure 1
The reasons why customers are not well informed are various.
The information is not dispatched (Lack of information dissemination)
The information is dispatched, but its quality is low. (Quality of disseminated information)
The information is dispatched but it cannot be found. (Searchability of disseminated information)
Anyhow, “listing of pieces of information that are not well transmitted to customers” can be a stepping stone to identify the causes.
Also Inquiries within the Company
In my considered opinion, there are important tips in inquiries within the companies, too. Probably, “things to be announced inside the company” should include “things to inform customers of.” If we can make a list of “the thing to be announced in the company,” it is very useful to secure the completeness of “things to be transmitted to customers.” That is to say, it is more likely that “lack of information” can be avoided.
If necessary, one can receive suggestions (T1), undergo evaluations (L1, Mb1), and record quality of responses (L2). Such Task operation control is illustrated as follows.
Figure 2Figure 3
Formulated Recording of Responses
To manage progress of inquiry correspondence is effective to “deal with complaints” as soon as possible. At the same time, to continuously logging the responses leads to future improvement of the information transmission.
Figure 3 (Reprinting)Table 1
Start with Resolving Lack of Information
Sharing formulated inquiries and responses might not look special, but it is very important.
In addition to the improvement of information dissemination aiming at just reducing the number of inquiries, we may want to reduce the requests for advises of R&D by sharing knowledge etc., particularly in case of organizations requiring 5 or 10 responders in the support desk.
As a general measure for improvement, we can add information to FAQ. But if possible, we want to gather measures for improvement besides just adding them to FAQ. I would illustrate a process below in which each Participant prepares a draft of a measure for improvement in advance in order to dare to have periodical meetings to discuss various measures for improvement.
Figure 4
Even if we add FAQ to resolve the lack of information transmission, we had better to examine “whether the quality of explanations of added information is satisfactory or not” or “whether added information is confusing because of its similarity to other information or not.” In some cases, we might need to change or remove existing information to be transmitted. There are few organizations that can thoroughly manage FAQ for customers. There is almost no organization that can manage FAQ for inside the company.
Needless to say, meeting minutes themselves are important data for subsequent improvement activities.
If No One Knows, Create Information
When we treat information that someone probably knows, we just need to find such a person. For instance, we can consult developers when we deal with specifications of a product. However, there is sometimes a case in which we are required to answer to inquiries regarding “unknown and undecided information.”
More specifically, we can expect various cases such as a specification policy of an unreleased product or information about the release date. However, any consultant in R&D section cannot answer at his/her own discretion. Needless to say, a person at a support desk has no way to do that.
In the first place, a Process in which a draft is brushed up based on the consensus of members is difficult. However, it is obvious that a rough draft is necessary.
Figure 5
On the basis of the rough draft, we must discuss thoroughly. In some cases, we need another draft. Then, we should manage the generated new information with the consensus process.
Drafts by Two People Is Better Than Ones by One Person
“Two heads are better than one.”
In all countries, it is said that a better conclusion is led when multiple people gather. But the number of heads varies, say 2 or 3, depending on countries.
The same reasoning works out also regarding the creation of rough draft. When we define and transmit new information, we hope to express it in a considerate manner so that more people can easily understand. Here, we think about a Process in which a discussion regarding the final draft is carried out based on two rough drafts, which are created by different people in advance.
Figure 6
We should note that two draft creation tasks (Ma1, Mb1) are carried out in parallel after a theme is decided (L1). For example, this can be a Process in which we expect “arbitrary two people” in the team to make drafts about the development policy concerning a product specification.
Each split in a Diagram is called as follows.
A split selecting one flow is called “XOR-Split.”
A split selecting more than one flow is called “OR-Split.”
A split selecting all flows is called “AND-Split.”
L1 is AND-Split and D1 is XOR-Split. Depending on BPM engines, you could face some limitations. For example, you might not be able to use OR-Split or And-Split in case a flow goes out of a loop.
Discussion on Organization Policy Triggered by an Inquiry
As an example, let’s assume an inquiry from an important client. In this case, triggered by an inquiry, we need to create a response document.
Figure 7
This sample Diagram shows a case in which each sectional adviser “brings back the inquiry to the section to examine and respond it in a document.
Establishment of Consensus
In order to establish consensus, discussions are indispensable. Based on the business contents, a Process Owner needs to consider well what Process is appropriate to reach an agreement in the group. Such a Process always has a loop.
Figure 8
Most of Tasks are supposed to be executed by “someone” in the group defined in Swimlanes. In addition, when someone has already executed a Task in a Swimlane, such as Ma2 Task in Figure 7, that “executor” will be appropriate to carry out the others in the Swimlane. That rule is referred to as “Retain Familiar.”
In fact, in Draft Editorial Meeting in Figure 7, we could say that the “anyone” can “Take Meeting Minutes,” but it is more natural to think that there is a task that is to be executed by “everyone.” And, implementation of “Task by Everyone” varies depending on types of BPM software. [The End]
The success of corporate Sales activities depends on the individual’s “ability” of Sales people. In fact, in many cases, how well they understand consumers’ needs and how concretely they can make suggestions are actually determined largely by the ability of Sales people rather than any reputation of their companies offering services and products.
In general, “originality” rather than “cooperativeness” is required, and in reality, a number of organizations are forced to realize that they can not provide, in the organization level, enough support to develop each Sales person. Sales people repetitively create and present proposals to their customers.
Figure 1
Though this is a little slanted view, usually most workers do not (are reluctant to) consult their supervisors almost at all, while few employees inform, contact and consult the supervisors in detail. Also, supervisors are so busy with super-sales that they don’t have time (are reluctant) to hear subordinates in many cases. Such a tendency exists in both small and large companies.
Points to Manage
“You are on your own.”
In fact, leaders using a phrase “laissez-faire” do manage well. In other words, they request only reports of critical information, and they don’t demand reports about trivial issues occurring daily.
Figure 2
This is good for members (followers) to move forward. For instance, they can take action freely as long as they observe a rule “if the proposal contains a deal more than one million JPN yen or if the estimate includes more than 50% discount, it is necessary to receive the supervisor’s approval in advance.” The clear definition of the discretionary range, including the rules and procedures, enables workers to fully exercise their “ability.”
Then, the leader sends an e-mail to members only when the rule gradually gets violated, “Please use the following format to receive my approval in advance if you treat more than one million JPN yen in your proposal.”
Table 1
Advice to a Proposal
A series of Tasks in “Approval for the Proposal/Customer Proposal Result Report” process can be illustrated in the following diagram. (*: Required)
Figure 3
A member (follower) ask for “approval for the proposal,” and his leader gives him necessary advice (L1). In some cases, the leader directs the member to revise it (M1). If the proposal do not have any problems, the leader says, “Present and propose this to your customer and then tell me the customer’s responses as you feel.” Later, the member reports the proposal result to the leader (M2).
The table below shows the summary of Tasks in this Process (Hereinafter, this is called Process Data).
Table 2
Not All Proposals Require Advice
Of course, if the organizational rule specifies that not all proposals always require the leader’s approval, it is necessary to rewrite the steps from “Prepare Proposal Draft (M1)” to “Proposal Result Report (M2)” to the customer. More specifically, we need to define a Conditional Split rule that doesn’t go through L1.
Figure 4
In this case, proceeding toward “State: Ready to Submit the Proposal,” that is to say, “State: Waiting for Input of Proposal Result Report (M2)” requires not only completion of necessary data for proposals besides the proposal itself but also the following conditions to be satisfied.
A: Estimated price is under 1 million JPN yen.
B: Estimated price is over 1 million JPN yen, but approved by the leader.
Well, most parts are organized up to this level, so I feel like properly documenting not only the proposal but also e-mail and verbal advice contents.
Cooperativeness Is Also Important
Once a Process of Approval for the Proposal becomes clarified, members who understand it submit proposals one after another. Moreover, if members start using BPM software to manage systems, they can refer to saved past proposals to quickly submit proposals of better quality. In some cases, the leader would be required to correspond and give approvals to members in remote sites who used to have few opportunities to obtain approvals.
Everything goes well with the company, but, in reality, the Process could more often stagnate at the leader’s “Evaluation Suggestion Task.”
However, calmly thinking, the leader does not have to approve all of them. Rather, co-worker review would often be more appropriate.
Figure 4Figure 5
Want to Check Data of the Past
“Go back to square one.”
You may rarely be said in the tone like this, but we are often required to submit a proposal again. If we change the process, “Write a proposal and receive a sectional approval,” to a process, “Write a proposal, receive an approval, complete and improve the proposal well enough to satisfy the customer to a certain extent,” the diagram is changed as shown below.
Figure 6
The focus of this Process management is switched from “Complete the proposal” to “Acceptance of the proposal by the customer,” but in real this Process is often hard to manage. More specifically, the branching condition could become ambiguous, for example whether or not “Co-worker Review (Ma1)” will be again required even when only small revision are made on the proposal etc., or could unnecessarily increase the burden on the colleagues and leader. Thus, I do not recommend the management represented in the Image 6.
Improve Reusability of Proposals
It is not easy to organize Processes, but if a team can share them, such a team can achieve improvements from the following perspective. Especially, processes that strongly rely on ability of the individual make significant gains.
Including new employees, everyone understands how to execute business and does not get lost
Achievement can be quantitatively measured, and each worker’s achievement can be grasped
Outcomes in the past can be easily referred to, and the quality of outcomes gets improved
When we focus on “Prepare a proposal and receive a sectional approval,” we want to encourage the members to refer to the outcome created in the past, i.e. the proposals that some other people wrote in the past.
Particularly, it is significantly effective to add “Search tags of proposals,” and “Evaluation of proposal quality.” By managing proposals based on the format as shown in the table below, as a result, the organization can strengthen the proposal ability.
Figure 5Table 3
Afterward, furthermore…
If you want to improve the quality of deliverables created by Human Processes, the leader’s or a co-worker’s review is indispensable. In that case, a Process Owner needs to carefully consider the order of Data items to be managed and Tasks (Workflow) according to characteristics of the organization. Specifically, the Owner needs to think well about whether all of outcomes need to be checked or not, whether all of them must be always checked or not, and, in some cases, whether the work can be partially left to others or not. [The End]
“Translation task” is a typical human-related workflow.
Even though computer-“assisted” cases increases, (I think) humans are likely to keep on participating in this task in the foreseeable future.
Well, if I am asked to “draw a Business Flow Diagram for a Japanese/English article writing Process,” what sort of diagram would come to my mind? I wonder. I might be hesitated because the diagram is as simple as the Diagram below.
Figure 1
But, also you can tell just by thinking for a while, I haven’t taken into consideration “sending back” to “W1: Write Document” Task in this Diagram. In other words, this Diagram is based on the assumption that “there is no mistake in the draft in Japanese.” Let me see… Well, I wonder what I need to do to illustrate it more accurately.
Incidentally, if someone says, “Nay! Sending back is implicitly included.” I wouldn’t refute it strongly. Yet, I just want to promote awareness of the fact that there is no way to define such a “Workflow with no sending-back.”
For your information, work units such as T1 or W1 are often called either “Activity” or “Task” according to definitions by an International Standards Body (OMG). A “Task” is defined as an “Activity that cannot be divided further,” and so W1 and T1 in the Diagram above should be called Tasks.
To go back or forward; “Decision”
When if I were a translator, I can’t help accumulating frustrations in thinking, “This original draft in Japanese must be rewritten.” Uncompleted sentences, too poor to read… “I can’t stand this!” I might be on the point of leaving in saying so in disgust. (Really?) In fact, “I can’t translate such sentences. So, I’ve ignored them…” If possible, I hope to avoid such a cold scene, but this type of conversations may happen thousands of times everyday anywhere in the world (no data, though).
Now, as a rule of business, I’m going to draw a “Workflow in which a translator is authorized to make a decision for sending back.”
Figure 2
I see. By getting a translator authorized, fruitless stagnation can be avoided. Well, now we carry out our work according to this rule, and a question strikes me, “why in the world is a translator checking original drafts in Japanese?”
Of course, even without any rule concerning authority, there might be a case in which “aura of fury” forces the author of the original draft in Japanese to submit it again. And yet, if the author is absent or at a remote location, the aura doesn’t reach. (Nay, it just might arrive.)
Better leave it to a specialist
Necessary abilities are different between “writers in Japanese” and “translators.” If there are 10 “writers in Japanese,” they should inspire each other to improve their ability to make Japanese drafts.
So now I examine a case in which “another writer” of drafts in Japanese reviews a draft.
Figure 3
Hm. Quality of drafts in Japanese has improved dramatically. I can concentrate on my translation though I need to confirm the meaning of some sentences just sometimes. I don’t have to shake with rage any more.
However, on a peaceful day, an accident happens. Contents of one of our press releases written in Japanese are evidently untrue to the facts. “I translated the most this month among 3 translators. So I just ignore…,” I am tempted by an evil spirit for an instant. But, my sense of justice comes out of hibernation, and I can’t help unlocking it.
Tons of Loops
Now, I want to examine modification into a “Workflow in which the original draft in Japanese can be rewritten if necessary.” Should I send back the draft to the author or via the reviewer? This decision is unexpectedly quite difficult.
Figure 4Figure 5
The reviewer may feel obligated to know the reasons why the draft is sent back. This is a rare case in the first place. After considering it very carefully, I concluded that the best is a rule which obligates to send back to the author by agreement with the reviewer although it takes time.
After many twists and turns…
The reasoning for “quality improvement of drafts in Japanese” would work out for quality of “translation drafts.” Half a year later, I came to the following Business Process.
Figure 6
Both 10 members in charge of “Japanese version” and 3 translators try to upgrade their skills by learning from others. The quantity of drafts made per week tends to incline! Quality must be improved, too. However, this team still has a challenge…
Want to refer to previous data
“I translated a similar draft, but…,” a translator murmurs. Last month, her favorite PC departed, and she is chagrined at being unable to refer to previous deliverables. Great sorrow, comfortable memories. So now, I’m concentrating on centralized control of data that the team produces.
Groupware handling this sort of thing is likely to be called “BPM software” or “BPM Suite.” If I fix a format called “Process Data” in addition to “Business Flow Diagram (Business Process Diagram),” I seem to be able to manage deliverables. In addition, the current stagnation seems to become visible. By turning tears into courage, I decided to introduce it.(!?) When I think about it now, some translators had attached word processor data to e-mail, while some others had pasted text data on e-mail body. It was, in fact, inefficient.
Task operation control by BPM software
fixed “Process Data” and input/output settings as follows.
Table 1
I minimized required(*) fields in consideration of secretive people who would want to send each other e-mail as they used to do. I ran the software, and it automatically recorded date and time of task completion…Fantastic! I won’t shed a tear anymore!! And, I realized that one of the leader’s tasks “task counting” had come to be unnecessary to do.
In addition, after that…
Translators sometimes get busy. That is when they receive drafts in special fields that they have never treated. They need to accumulate know-how for translation techniques. In contrast, writers in Japanese don’t appear to drop their pace even when they handle different fields. So, I decided to hire home-based part-timers to allocate easy tasks. Of course, I ask them to use BPM software. Regular employees produce finished versions from drafts that part-timers make. Translators have to take longer time to deliver translation, so I have the client (writers in Japanese) determine whether we allocate some parts to part-timers. Incidentally, I make a change for having the leader, who takes care of less work, check and approve all deliverables. These improvement results are as Image 7. Additional improvements will come soon. A draft in Japanese sometimes has some parts with immediate importance and some others with less importance. Consequently, a new idea strikes me. That is “Process Division.” This enables “multiple-division high-speed production.”
Days of Kaizen (improvement) never end…. (The End)
企業の競争力の源泉は業務プロセスです。企業はビジネスプロセスを変化させ続けなければなりません。そしてまた、企業は変化し続けるビジネスプロセスを把握共有し続けなければなりません。ベテランスタッフの知見にばかり頼るのではなく、BPMNを活用したビジネスプロセス管理(Business Process Management)を推進しては如何でしょうか。