ブログ

  • クラウド型ワークフローv7.0、API機能を大幅強化

    クラウド型ワークフローv7.0、API機能を大幅強化

    法人ソフト開発の株式会社クエステトラ(京都市、代表執行役 CEO 今村元一)は、クラウド型の業務プロセス管理システム「Questetra BPM Suite SaaS Edition」の最新版『September 2010 バージョン7』を、9 月15 日世界同時発売します。
    バージョン7では、サードパーティソフト等からの接続機能(API 機能)が標準装備されるため、導入企業は、例えばセールスチームの見積書発行依頼業務に特化した iPhone アプリや、決裁フロー早期化に注目して決裁や承認を促す様なデスクトップアプリ等、自社のコアプロセス強化を実現するアプリケーションを自由に作成する事ができるようになります。

    Questetra BPM Suite SaaS Edition の概要

    『Questetra BPM Suite SaaS Edition』は、業務フローと業務進捗を可視化する国産のグローバルクラウドです。ドラッグ&ドロップで業務の流れを編集する事で、ワークフローシステムが自動的に変更される為、タスクの追加や分岐条件の変更など、現場主導の業務フロー改善が実現できます。(5 ユーザ無料)立替金申請の様な決裁系ワークフローに限らず、「見積書を提出する前に経理部門がチェックする」、「客先に提出する重要提案を複数人が同時レビューする」と言った複雑なワークフロー環境も容易に構築する事ができます。Google Apps 連携機能を標準装備しているのが大きな特徴です。(受賞歴:「グローバル Cool Vendor BPM」、「アジア Top50 Apps」など)

    Questetra BPM Suite SaaS Edition バージョン 7 の概要

    「クラウド」をキーワードに、情報システムの『所有』から『利用』へのシフトが益々加速する中、クラウドの一形態である SaaS(Software as a Service)も、その接続性が問われる時代になっています。バージョン 7においては、API(Application Programming Interface)機能が大幅に整備拡充され、

    • スマートフォンアプリ(Android や iPhone など)
    • タブレット端末アプリ(iPad など)
    • 各種ミニアプリ(デスクトップ Widget や Gadget など)
    • 基幹システム内の連携アプリ

    などが簡単に開発できるようになります。なお、バージョン7の公開にあわせ、iPhone クライアントおよび Android クライアントのサンプルコードをオープンソース公開します。

    API 機能の利用例

    • BPMN 受信イベント API(セキュリティキー)
      • 基幹システムから「請求書送付先住所を再度確認するフロー」を起動(メッセージ開始イベント)
      • 社内サイト「目安箱フォーム」から「社内提案対応フロー」を起動(メッセージ開始イベント)
      • 基幹システム側から「顧客の与信限度額」を自動取得(メッセージ受信中間イベント HTTP 通信)
    • BPMN 送信イベント API
      • 基幹システムへの受注内容を POST(メッセージ送信中間イベント HTTP 通信)
      • ファイル管理(ECM)へ提出済提案書ファイルを POST(メッセージ送信中間イベント HTTP 通信)
      • 問合元に対するメール回答を自動作成してメール送出(メッセージ送信中間イベントメール通信)
    • プロセス実行 API(ユーザ認証)
      • 自身のタスクを締切が近い順に表示するスマートフォンアプリ作成(マイタスクの一覧 JSON 取得)
      • 担当が未割当のタスクを部屋内の大型スクリーンに掲示(オファータスクの一覧 JSON 取得)
    • ユーザ管理 API(ユーザ認証)
      • 基幹システム側からユーザの追加削除を行うプログラム作成
      • 人事給与システム側からグループ情報を改変するプログラム作成

    なお、ユーザ認証には BASIC 認証、OAuth が利用可能です。

    クエステトラ CEO:今村元一のコメント

    「クラウド時代・マッシュアップ時代にあって、ソフトウェア会社として API の強化が最も大切であると考えています。今後 Questetra はワークフローエンジンとプロセスモデラの強化に注力すると共に、API を更に拡充し、コンサルティングパートナ様、インテグレーションパートナ様との共存関係を推進して参りたいと考えています」

    Questetra の概要

    『世界中のヒューマンタスクを最適化する』 を使命に、ビジネスソフトウェアを創造し続ける京都のスタートアップ企業です。ソフトウェア開発技術で世界中のビジネス革新に貢献します。

    商号

    株式会社クエステトラ (Questetra, Inc.)

    代表

    代表執行役CEO 今村 元一

    所在地

    京都市中京区御池通間之町東入高宮町206 御池ビル4階

    設立

    2008年4月

    事業

    法人向けソフトウェア開発

    資本金

    1 億 4 千万円

  • Named ‘Cool Vendor’ by Leading Industry Analysts

    Named ‘Cool Vendor’ by Leading Industry Analysts

    Gartner, Inc. has included Questetra in “Cool Vendors in BPM, 2010”

    Original Japanese version

  • 調査会社により『Cool Vendor』に選定される

    調査会社により『Cool Vendor』に選定される

    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)

    Questetra は 2008 年 4 月の創業以来、「人間タスクの可視化」をテーマに、世界中で使われるビジネスソフトの開発に取り組んできた日本のスタートアップ企業です。2009 年に発売を開始した SaaS 製品『Questetra BPM Suite』は、「オンラインの業務処理環境」を簡単に構築する事できる BPM ソフトウェアであり、例えば「今この瞬間、誰が、何件、どの様な“見積対応業務”を行っているのか」を“見える化”する事が出来るツールです。

    製品特徴

    • 管理職者自身がスグに使えるプロセスモデリング機能
    • Google Apps とも連携するクラウド上での業務処理機能

    これまでビジネスソフトの領域で日本のベンチャー企業が世界に注目される事はほとんど無かった中、今回「創造的(innovative)で、興味深く(interesting)、IT の将来に大きなビジネスインパクトをもたらすであろう企業」として選定された事は、Questetra にとって、大きな喜びであり、誇りでもあります。Questetra は、今回の受賞を励みに、今後も世界中のヒューマンタスク最適化に貢献して参りたいと思います。

    ガートナーの注目ベンダー選定プロセスについて

    ガートナーの注目ベンダー・リストは、特定のテクノロジ分野におけるベンダーを網羅するものではなく、革新的で興味深い新興ベンダーや製品、サービスに注目することを目的としています。ガートナーは、本リサーチの内容に関して、商品性の保証あるいは特定の目的への適合性も含めて、明示的にも黙示的にも一切の保証を行いません。ガートナーは、次のようなテクノロジやソリューションを提供する企業を、注目ベンダーとして定義します。

    1. 革新性:ユーザーがこれまで不可能であったことを可能にするもの
    2. インパクト:ビジネス・インパクトを現在有するか、あるいは将来有し得るもの (単なるテクノロジのためのテクノロジではない)
    3. 魅力:過去約 6 カ月間にガートナーの関心や好奇心を呼んだもの
  • How to Balance Productivity and Customer’s Trust? – How to Improve the Process? (4)

    How to Balance Productivity and Customer’s Trust? – How to Improve the Process? (4)

    Original Japanese version

    BPM starts with grasping improvement of workflow (Workflow App). Please benefit from the following story about Workflow improvement activity.

    System Integrator

    What does “a system” mean?

    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!

    1. [Proposal Stage] Low quality of proposals. There is almost no proposal
    2. [Design Stage] I don’t know what’s happening with the latest specification.
    3. [Acceptance Stage] Low quality of products. I want to know how it was tested
    4. [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:

    1. Are executors wrong?
    2. 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 3
    Table 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).

    1. [Proposal Stage] Low quality of proposals. There is almost no proposal
    2. [Operation Stage] Late response to inquiries. Sometimes responses are totally irrelevant
    Figure 4
    Table 3
    Figure 5
    Table 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]

  • How to Exercise Knowledge Management? – How to Improve the Process? (3)

    How to Exercise Knowledge Management? – How to Improve the Process? (3)

    Original Japanese version

    BPM starts with grasping improvement of workflow (Workflow App). Please benefit from the following story about Workflow improvement activity.

    Meaning of Inquiries from Customers…

    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.

    1. The information is not dispatched (Lack of information dissemination)
    2. The information is dispatched, but its quality is low. (Quality of disseminated information)
    3. 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 2
    Figure 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]

  • What kinds of business can we improve remarkably? – How to Improve the Process? (2)

    What kinds of business can we improve remarkably? – How to Improve the Process? (2)

    Original Japanese version

    BPM starts with grasping improvement of workflow (Workflow App). Please benefit from the following story about Workflow improvement activity.

    Originality Rather Than Cooperativeness…

    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 4
    Figure 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.

    1. Including new employees, everyone understands how to execute business and does not get lost
    2. Achievement can be quantitatively measured, and each worker’s achievement can be grasped
    3. 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 5
    Table 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]

    Figure 7
  • 生産性改善と顧客信頼獲得の両立 – プロセス改善活動の進め方(4)

    生産性改善と顧客信頼獲得の両立 – プロセス改善活動の進め方(4)

    業務プロセス管理(BPM)は、ワークフロー(ワークフローアプリ)を把握するところから始まります。この『プロセス改善ストーリー』を参考にして、あなたも業務プロセス改善を始めてみませんか?

    システムインテグレータ

    「システム」 どういう意味?

    なかなか回答に窮する“意外と難しい質問”である。およそ「複数の要素が組み合わせられ、全体として何かの役割を担うもの」なのだろう。「システムキッチン」はコンロ・流し台・収納が料理を助け、「物流システム」は集荷者・保管者・配送者がモノを運ぶ仕組みである。

    「情報システム」でも似たようなもので、ハードウェア・ソフトウェア・通信ネットワークが“情報を出力する仕組み”に過ぎない。

    しかし 「売上」、「ロイヤル顧客のリスト」、「最新の業務マニュアル」、「新製品に対する顧客の声、上位3つ」・・・考えてみれば当然の話ながら、ヒトが得たいと思う情報は数限りない。情報システムの組立屋(Integrator)が世に無数と必要になる所以だ。

    委託者の不満

    委託者が不満に感じる瞬間、トップ4!

    1. [提案段階] 提案のレベルが低い。て言うか無い
    2. [設計段階] 最新合意仕様がどうなっているのか分からない
    3. [検収段階] 納品物の品質が低い。テスト内容を聞きたい
    4. [運用段階] 問合に対する対応が遅い。たまに的外れ回答

    以上は経験にこそ基づいているが、あくまでも著者の勝手な推測だ。何の統計データもない。また言うまでもなく、技術説明を受ける瞬間、契約の瞬間、見積の瞬間(!)など、他にも色々な瞬間で不満を感じる事もあろう。

    さて・・・、手始めに「納品物テスト」に関連するプロセスにフォーカスし「委託者の不満」を解消したい。選択理由は簡単。他プロセスと比較して、人間能力への依存度が高くないタスクが多いからだ。たとえば「提案」に関連するプロセス自体が整備されていなくても、「委託者の満足」を得る人はいる。

    ここではモジュール作成、モジュール結合、実機構築など、メンバは担当範囲の「成果」を出した単位でプロマネに報告する。そこを起点に検査プロセスが始まる。

    このプロセスでは、プロマネの簡単な確認の後、任意の検査者二人が検査を実施し、検査報告を記録する。もちろん、どの単位どのタイミングで成果報告をさせるかはプロマネの腕の見せ所となる。

    テスト実施内容

    「途中の検査報告も、すべて納入する」

    そこまでの“男気” を見せるプロマネはなかなか居ないと思うが、本来、納品物に対する「要素単位の検査報告書」は、システムタイムスタンプ付で提出したいものだ。

    確かに「CMMIを取ろう」と唱えるのは躊躇するだろう。しかし「納品物の検査報告書も提出しよう」と言う勇気は、是非とも持ち合わせてもらいたい。このプロセスの場合、仮に納品物の要素が100個あるなら、検査者が二人いるので、「(100+再検査回数)×2枚」の検査報告書が生成される事になる。ちなみに、SI事業全体を俯瞰すれば、テストや検査にかけるべき費用は全体コストの2割程度は必要だ。乱暴に言えば、100人組織には20人の検査部隊が存在することとなる。

    ※ CMMI: Capability Maturity Model Integration

    「検査報告書」の存在は、特に担当営業としては有難い。現実、多くの担当営業はどんなものが出来上がったかを把握できていない。そして、クレームは一方的に受け付けるしかない。

    しかし「検査報告書」があれば、委託者が納品物を検収したときに満足できなかった検収項目と、検査報告書の検査項目を比較する事が出来る。すなわち、委託側の主張と受託側の主張を比較する事が出来る。

    言った仕様、言ってない仕様

    「検査報告書」である程度は救われるはずの担当営業氏だが、人類永遠の課題「思い込み仕様問題」は解決されない。

    すなわち、RFP・要求仕様書・要件定義書など、いずれの書類にも書き切れていないが、「委託側としては当然実現されると思いこんでいた仕様」が存在してしまう問題だ。

    こればっかりは、地道に合意仕様をきちんと記録していくしかないのだが、「きちんと記録できる/しやすいプロセス」とは、如何なるものなのだろうか。

    仕様書管理

    プロセスのアウトプットが不十分であった時、

    1. 実行者が悪いのか?
    2. プロセスそのものが悪いのか?

    のいずれであるか、をプロセスオーナーは見分ける必要がある。情報漏洩だの、勘違いだの、多くの人為事故は、プロセスそのもの(体制と言っても良い)を改善する事で発生確率を下げられる。

    今、「最終合意仕様書が共有できていない」と言う状況は、文書管理プロセスの改善で少なからぬ変化が期待できる。草稿ベースに打ち合わせを行い、議事録と修正原稿をメールし、さらに長文議事録の行間指摘をメールしあっている現状を打破したい。

    このプロセスオーナーのスタンスは、

    • 打ち合わせは何度してもらっても構わない。
    • なんならメール議論も好きなだけやりとりすれば良い。
    • 「漏れなく記載する」と言う事に主眼に何でも実践して欲しい。
    • ただ、「最終決定プロセス」だけは特定のルールに従ってくれ。

    と言うものだ。おかげでルールが少ない。しかも最終決議をオンラインで行うと言っているだけだ。流れ自体は、議会での法案審議プロセスに近い。微細な誤植であれば、オンライン議事録で修正の内容を明記し、利害関係者が「同意する」と発言するだけでよく、対象書類を改変し再議論する必要はなかろう。

    ちなみに、プロマネは議長役に徹するのが良い。また“穏やかなチャット”にするための十分な事前根回しが期待される事は言うまでもない。

    変更管理

    ルールと呼ばれるものはシンプルな方が良い。プロジェクトで定義すべき仕様の種類・本数は、案件によって異なる。場合によっては100ファイルを超えるケースもあるだろう。そして、その中にはプロジェクト実施中にやむなく更新される仕様もある。

    しかし、新規法律にせよ、法律修正にせよ、全ての法律が議会を通過するのと同様、仕様の変更であっても必ず「最終仕様合意」のプロセスを経て承認されるようにしたい。

    すなわち、何かもめごとが起きた時に、個人のメールボックスを探しまわるようなことはしたくない。

    仕様決定と検収検査の他に・・・

    さて、「不満瞬間」の残り二つ(1.および4.)も結論だけになるが、提案しておきたい。

    1. [提案段階] 提案のレベルが低い。て言うか無い
    2. [運用段階] 問合に対する対応が遅い。たまに的外れ回答

    プロセス自体のブラッシュアップタイミング

    「プロセス」はすなわち「ルール」でもある。ルールの改編は頻繁に行うべきではない。人数配分の変更等で対応できる場合も多い。しかしどうしても「滞留」や「ミス」が無くならない場合、プロセスオーナーは勇気を持って変更する決断をしたい。 [完]

  • 業務処理統制下のナレッジ管理 – プロセス改善活動の進め方(3)

    業務処理統制下のナレッジ管理 – プロセス改善活動の進め方(3)

    業務プロセス管理(BPM)は、ワークフロー(ワークフローアプリ)を把握するところから始まります。この『プロセス改善ストーリー』を参考にして、あなたも業務プロセス改善を始めてみませんか?

    顧客からの問い合わせの意味・・・

    日本には「お客様は神様」と言う表現がある。顧客からの問い合わせはまさに「神の声」かも知れない。少なくとも、分からない事を分からないままに放置している他の多くの顧客とは大きな違いがある。

    多くの企業では、問い合わせ窓口を設置して、顧客の不満を解消する。それがコールセンターであったり、インバウンドメール処理チームであったりする。しかしその「不満解消活動」は、別の角度から見れば「顧客に伝わっていない情報をリストアップできるプロセス」でもある。

    伝わっていない原因は、さまざまに想像できる。

    1. 情報を発信していない (情報発信不足)
    2. 情報を発信しているが、品質が低い (発信情報品質)
    3. 情報を発信しているが、見つけられない (発信情報検索性)

    いずれにせよ「顧客に伝わっていない情報のリストアップ」は、原因特定の足掛かりとなろう。

    社内からの問い合わせも

    よく考えれば、社内からの問い合わせにも大きなヒントがある。およそ「顧客に伝えるべき事」は、「社内に伝えておくべき事」に含まれるはずだ。「社内に伝えておくべき事」がリストアップされていれば、「顧客に伝えるべき事」の網羅性担保に役立つ。すなわち「情報不足」が回避される可能性が高い。

    必要あれば助言を受け(T1)、回答文の評価を受け(L1・Mb1)、回答文の価値を記録する(L2)業務処理統制例を以下に示す。

    定式化された回答文の記録

    問合処理の進捗管理は「不満解消」を一刻も早く実現するために有効である。他方、回答文を記録し続ける事は、今後の情報発信の改善を導く。

    まずは情報不足の解消から

    定型化された問い合わせ内容と回答文を、情報共有する活動は地味ではあるが、非常に重要な活動である。

    単に問い合わせ件数を減らすための情報発信改善に留まらず、特に問合対応窓口の回答者が5人や10人と必要になる組織の場合、知識共有等を通じて技術部門への助言依頼を少しでも減らしたい。

    一般的な改善施策として、FAQへの追加が挙げられる。しかし、出来る事ならFAQ追加に留まらない改善施策を集めたい。あえて様々な改善施策を議論できる場を定期的に持つべく、会議日までに各自が改善施策を立案するプロセスを以下に例示する。

    情報発信不足を解消するためのFAQ追加であったとしても、議論の中で「追加情報の説明品質は十分か」、「他の発信情報と類似して紛らわしくないか」などの検証をしたい。場合によっては既存の発信情報を改変削除する必要があるかも知れない。顧客向けFAQをしっかり管理できている組織は少ない。社内向けFAQを管理できている組織はほとんどない。

    なお、議事録そのものも、その後の改善活動のための重要なデータである事は言うまでもない。

    誰も知らない情報は作るしかない

    誰かが知っているはずの情報(知識)であれば、知っている人を探せば良い。たとえば、製品の仕様であればどんな些細な事でも製品開発者に問えば分かるはずである。しかし、時として「誰も知らない、未決定の情報」に答えなければならないケースもある。

    具体的に言えば、未発表製品の仕様方針であったり、発売日の情報であったり、様々なケースが考えられる。しかし技術部門の助言者も一存では答えられない。ましてや窓口担当は何も答えられない。

    そもそも、メンバ合意のもとに原稿をブラッシュアップするプロセスは難しい。しかし、素案が必要である事は確かだ。

    素案となる草稿をベースに議論を尽くす。場合によっては、再度草稿作成が必要となる場合もある。そしてそこで生み出された新しい知識は、その経緯を含めて管理したいところだ。

    一人の起案より、二人の起案

    「Two heads are better than one.(3人寄れば文殊の知恵)」

    洋の東西を問わず、複数の人間が集まると良い結論が導けるらしい。(そして、集めるべき知恵の数は、2であったり、3であったり、国によって異なるらしい)

    素案作成においても同じ理屈が成り立つ。新しい情報を定義し発信するに際しては、より配慮された、より多くの人が理解しやすい表現にしたい。ここでは二人の人間に草稿を作成させ、それらを持ち寄って最終原稿に関する議論を行うプロセスを考えたい。

    ここで注意したいのは、テーマ決定(L1)後、二人の草稿作成(Ma1・Mb1)が同時並行的に実施される事だ。たとえば、特定の製品仕様に関する開発方針を、チーム内の「誰か二人」にその草稿作成を期待するプロセスとなる。

    なお、ダイアグラムの分岐部分において

    • 単一の経路が選択される分岐は 「XOR分岐」
    • 複数の経路が選択される得る分岐は 「OR分岐」
    • すべての経路が選択される分岐は 「AND分岐」

    とそれぞれ呼ばれる。(L1はAND分岐、D1はXOR分岐)。OR分岐やAND分岐は、ループ外に分岐させる様なケースでは使用できないなど、BPMエンジンによってその使用が制限されるケースがある。

    問い合わせに始まる組織方針の議論

    たとえば重要クライアントからの問い合わせを想定したとする。この場合、問い合わせを起点に回答文書の作成が必要になるケースがある。

    このダイアグラム例は、各部の助言担当者が「部に持ち帰り検討し、文書回答する」と言ったケースを示している。

    合意の形成

    グループ内での合意の形成に、議論の場は欠かせない。プロセスオーナーはどの様なプロセスでグループ内合意を図っていくべきか、その業務内容に応じて熟考する必要がある。得てしてプロセスはループする。

    なお、多くのタスクは、スイムレーンに定義されるグループの「誰か」が対応すれば良い。更に図7Ma2タスクの様に、スイムレーン内のタスクを誰かがすでに実行している場合には、「その実行した人」が実行すれば良い(そのようなルールはリテインファミリア/精通者維持と呼ばれる)。

    確かに図7の原稿編集会議(D1)において、「誰か」が「議事録を入力する」と言う形を取っても構わないが、「みんな」で実行すべきタスクが存在すると考える方が自然だ。そして「みんなでタスク」はBPMソフトによってその実装が大きく異なる。 [完]

  • カイゼン効果の高い業務領域 – プロセス改善活動の進め方(2)

    カイゼン効果の高い業務領域 – プロセス改善活動の進め方(2)

    業務プロセス管理(BPM)は、ワークフロー(ワークフローアプリ)を把握するところから始まります。この『プロセス改善ストーリー』を参考にして、あなたも業務プロセス改善を始めてみませんか?

    協調性より独創性・・・

    「法人向け提案営業」はセールスパーソン個々人の“能力” に依存する。確かに、どれだけ顧客のニーズを聞き取って、どれだけ具体性がある提案ができるかは、サービスや製品を提供する会社ブランド力などより、実はセールスパーソンの能力の方が大切であるケースが少なくない。

    得てして「協調性」よりも「独創性」が求められ、一人一人のセールスパーソンの能力開発を組織として実践する事には、多くの組織が限界を感じているのが実態だ。セールスパーソンは、自分の担当する顧客に対する提案書作成と、その提出説明を繰り返す。

    やや勝手な私見だが、逐一細かい事柄まで報告と連絡と相談をする人より上司にほとんど何も相談しない(したくない)人が多く、また上司自身がスーパーセールスで相談を聞く時間がない(聞きたくないと思っている)ケースが多い。それは企業の大小を問わない。

    管理すべきポイント

    「一人一人の裁量に任せている」

    実は「放任」を口にしているリーダ達こそ、実は上手に管理しているケースが多い。すなわち彼らは、重要情報だけを報告させる事で、日頃の微細情報報告は求めないのだ。

    メンバ(フォロワ)からしても行動しやすい。たとえば「100万円を超える規模の提案書ともしくは50%以上の値引きが必要となる見積書だけ事前承認を受ける」と言うルールを守ってさえいれば、自由に活動できる。裁量範囲がそのルールや手順を含めて明確になっている事で、自分の“能力”をフルに発揮できる。

    そしてリーダは、ルールが守られなくなりつつある折々に、メンバに対してメールする。「100万円以上規模の提案書は、以下のフォーマットで事前承認を得て下さい」。

    提案書への助言

    「提案書承認・顧客提案結果報告」と言う一連の業務をプロセスダイアグラムに描くと、以下の様になる。

    リーダの所に「提案書承認」を求めに来たメンバ(フォロワ)に対して、リーダは必要な助言を行い(L1)、場合によっては再度作成を命じる(M1)。問題の無いレベルに達した時点で、リーダは「顧客に提出提案して、得た感触を教えてくれ」と言い、メンバは後日、提案結果をリーダに報告する(M2)。

    このプロセスに流れている情報(プロセスデータと言う)を整理すると、以下の様になる。(※:必須項目)

    必ずしもすべての提案書で助言を要しない

    ちなみに、全ての提案書でリーダ承認が必ずしも必要ではない組織ルールなのであれば、「提案書草稿作成(M1)」から、顧客への「提案結果報告(M2)」に至る過程を修正する必要がある。すなわち、L1を経由しない条件分岐ルールを定義する事になる。

    この場合「提案書を提出できる状態」、すなわち「提案結果報告(M2)の入力待ち状態」となるには、提案書のほか提案に必要なデータが完成しただけでなく、以下の条件を満たしている必要がある。

    • A: 概算見積価格が100万円以下である
    • B: 概算見積価格は100万円超だが、リーダ承認を得ている

    ここまで整理されてくると、提案書だけでなく、メールや口頭で助言していた内容までも、きちんと記録したくなる。

    協調性も大切

    提案書承認と言うプロセスが明確になると、要領を得たメンバは次々と提案書を出してくる。まして、BPMソフトを利用しシステム管理する様になれば、記録されている過去の提案書を参考に、より品質の高い提案書を素早く提出できるようになる。場合によっては、承認を得る機会が少なかった遠隔地メンバからの承認までも、リーダは対応しなければならなくなる。

    会社組織にとっては良い事だが、現実問題としてリーダの「評価助言タスク」でプロセスが滞留するケースが少なくない。

    しかし冷静に考えれば、何も全てリーダが承認する必要もない。むしろ同僚助言の方が適切である場合も少なくない。

    過去のデータを見たい

    「出直してこい」。

    そんな言われ方は滅多にないだろうが、顧客から再提案を求められる事は多い。「提案書を作成し社内承認を得る」と言うプロセスから、「提案書を作成し社内承認を得て、顧客のある程度の満足を得る提案書に仕上げる」と言うプロセスに変更すると以下の様になる。

    ただし「提案書の完成」から「提案書の顧客受け取り」にフォーカスしたプロセス管理だが、現実的には管理困難になるケースが少なくない。すなわち、再作成した提案書が、微細な修正にとどまっている場合にも再度「同僚レビュー(Ma1)」等が必要なのか、その条件分岐が不明瞭になったり、同僚やリーダの手間が無駄に増えたりするケースも想定される。図6の管理単位は推奨しない。

    提案書の再利用性向上

    プロセスを整理する事は容易ではないが、チーム内で共有できた場合には、以下の様な面で改善が図れる。特に、個々人の能力に強く依存するプロセスにおいては効果が大きい。

    1. 新人も含め、業務の進め方に迷う事が無くなる
    2. 成果量を定量的に計測でき、個々人の成果把握ができる
    3. 過去成果物が参照し易くなり、成果物品質が高まる

    「提案書を作成し社内承認を得る」にフォーカスした場合、過去成果物、すなわち過去に誰かが作成した提案書の参照を促進したい。

    特に効果的なのは、「提案書の検索タグ」、「提案書品質の評価」を追加しておく事だ。以下の表の様なフォーマットで提案書を管理することで、結果として組織としての提案力が向上する。

    その後も更に・・・

    ヒューマンプロセスからの成果物品質を高めたい場合、リーダのチェック、あるいは他者のチェックが欠かせない。その場合、プロセスオーナーは組織特性にあわせて、管理すべきデータ項目やタスクの並び(ワークフロー)を熟考する必要がある。特に、全ての成果物をチェックするのか、必ずしもすべてのチェックは必要ないのか、場合によっては他者に一部の役割を委ねる事が出来るか、良く検討する必要がある。 [完]

  • How to draw a Business Flow Diagram – How to Improve the Process? (1)

    How to draw a Business Flow Diagram – How to Improve the Process? (1)

    Original Japanese version

    BPM starts with grasping improvement of workflow (Workflow App). Please benefit from the following story about Workflow improvement activity.

    I wonder what “Business Flow Diagrams” refers to…

    “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 4
    Figure 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)

    Figure 7
    Figure 8a
    Figure 8b
  • 業務プロセス図の書き方 – プロセス改善活動の進め方(1)

    業務プロセス図の書き方 – プロセス改善活動の進め方(1)

    業務プロセス管理(BPM)は、ワークフロー(ワークフローアプリ)を把握するところから始まります。この『プロセス改善ストーリー』を参考にして、あなたも業務プロセス改善を始めてみませんか?

    業務フロー図ってナンダ・・・

    「翻訳業務」は代表的なヒューマンワークフローである。機械に「支援」させる場面は増えても、人間関与は当面なくならない(と思う)。

    さて、「日英記事作成プロセスの業務フロー図を描け」 と言われたらどの様な図を思い浮かべるだろう? 思い浮かぶ図のあまりの単純さに躊躇するかも知れない。以下の様な図を想像するからだ。

    しかし、しばらく考察してみれば分かる事だが、この図では「W1:和文原稿作成」タスクへの「差し戻し」が想定されていない。言い換えれば、この図は 「和文原稿に間違いが無い」 と言う前提に成り立っている。はて、正確に描写するにはどうしたらよいのだろうか?

    ちなみに、「否!。差し戻しは暗に含んでいるのだ」と突っ込まれた場合には、まっこう反論はしない。ただ、仮にそれを認めた「差し戻しを許さないプロセス」を定義する術が無くなる事には注意したい。

    なお、T1やW1の様な作業単位は、国際標準化団体(OMG)の定義に従って「アクティビティ」あるいは「タスク」と呼ばれる事が多い。「タスク」は「それ以上分割できないアクティビティ」と定義されており、上図のW1やT1はタスクと呼ばれるに相応しい。

    戻るか、進むか、の「判断」

    「翻訳担当」の立場に立てば、「和文原稿を書き直して欲しい」と言う欲求が抑えられない局面はしばしば起こる。文章が途中で切れていたり、読むに堪えない稚拙な文章であったり、「仕事にならん」と啖呵を切って帰りたくなることもある(あるか?)。現実、「こんな文章、訳せませんよ。なので無視してました…」 そんな寒々しい現場には、出来る事なら居合わせたくない無いが、この様な会話は毎日1000件、世界中で発生している(根拠なし)。

    では、業務上のルールとして 「翻訳担当自身が差し戻し判断できるプロセス」 を描いてみよう。

    なるほど、差し戻し権限を持たせる事で「不毛な滞留」を回避できそうだ。さて、このルールで業務を遂行している日々、ふと思う。「なんで翻訳家が日本語の文章チェックをしているんだ?」 と。

    ちなみに権限なんてルール化しなくても、「怒りのオーラ」で和文担当に再提出させるケースも考えられる。がしかし、相手が欠席していたり、遠隔地にいたりする場合には、届かない(否、結構届くかも)。

    モチは餅屋

    「和文担当」と「翻訳担当」、それぞれが備えるべき職能は異なる。「和文担当」が仮に10人居るなら、その10人が互いに刺激しあって、「しっかりとした和文原稿を書き上げる能力」 を鍛えるべきだ。

    と言う事で、和文担当の中で「他の誰か」に原稿確認(レビュー)してもらうケースを考えてみる。(入り込んで来た!!)

    フムフム、和文原稿の品質は劇的に向上。稀にその文意を確認する様な事はあっても、「翻訳担当」は本来の翻訳業務に集中できるようになり、髪の毛を逆立てて怒りに震える機会も無くなった。

    だが、そんな平和なある日に事件は起きる(!!?)。プレスリリース用の和文原稿に書かれている内容が、明らかに事実に反する内容となっている。「今月の翻訳分量は、翻訳担当3人の中でもトップになれそうだし、ここは黙って・・・」とも一瞬思うが、久々に甦った正義感は押さえられない。(俺、誰?)

    ループが沢山

    ここで 「必要あれば和文原稿を作成し直してもらえるプロセス」 への変更を検討してみたい。原稿作成者に差し戻すべきか、原稿確認者を通じて差し戻すべきか?、これが意外と難しい。

    確認者は差し戻された理由を知る義務もあろう。そもそもレアケース。熟慮の結果、時間はかかるが、確認者と合意の上で執筆者に差し戻すルールが最善であると判断とした。

    紆余曲折の後・・・

    「和文原稿の品質向上」と同じ理屈は、「翻訳原稿」の品質にも成り立つ。半年後には以下の様な業務フローに落ち着いた。

    「和文担当」の10人も「翻訳担当」の3人も互いに切磋琢磨し、リーダが管理している週次原稿作成数も増加傾向!。きっと品質も良くなっている。だが、そんなチームにまたしても課題はやってくる・・・。

    過去のデータを見たい

    「似た様な原稿を翻訳したんだけどなぁ」 そう呟く翻訳担当。先月愛用のPCが昇天なさったために、過去の成果物を参照できずに悔しがっている。悲しみは深く、思い出は美しい(?)。そこで、チームが生産するデータの集中管理に燃える(事にする)。

    その手のグループウェアは「BPMソフト」あるいは「BPM Suite」と呼ばれているらしい。「業務フロー図」(ビジネスプロセス図)に加えて、「プロセスデータ」と呼ばれるフォーマットを設定すれば、成果管理が出来るらしい。しかも、現在の滞留具合も見えるらしい。涙を勇気に変えて導入即決(!?)良く考えると、それまでワープロソフトのデータをメール添付する人もいれば、メール本文にテキストデータを書き込んでいる人も。確かに効率も悪かった。

    BPMソフトで業務処理統制

    「プロセスデータ」およびその入出力設定は以下の通りとした。

    必須項目(※)の設定を少なめにしたのは、従来通りメールでやり取りしたい秘密主義者たち(!?)への配慮だ。運用してみたところ、タスク完了時刻がすべて自動的に記録されていく・・・感動的!!。もう涙は流さない!!。そして気が付けば、リーダの「作業集計」と言う仕事が無くなっていた。

    その後も更に・・・

    翻訳担当が忙しくなる時期がある。それは、扱った事のない専門分野原稿が来はじめた時だ。用語の訳し方ノウハウを溜める必要がある。一方の和文担当は、分野が変わっても原稿作成量はあまり落ちない様だ。そこで在宅アルバイトを雇い簡単な仕事を割り当てる事にした。もちろんBPMソフトを使ってもらう。彼らの作成した翻訳原稿は社員が清書。どうしても納期が長くなるので、アルバイトに任せるかどうかの判断は依頼者(和文担当)に委ねる事とした。ついで(?)に仕事が減ったリーダには全成果物の承認者になってもらう変更も同時に実施する。これらの改善結果は図7の通りとなった。更なる改善はすぐに訪れる。1つの和文原稿も、急ぐ部分と急がない部分に分けられる場合がある。そこでひらめくニューアイデア「プロセス分割」。これで「複数分割特急仕上げ」も実現できる(図8)。カイゼンの日々は終わらない・・・。[完]

  • BPMN 図だけで業務システムが構築できるか? – BPMN 超入門(4)

    BPMN 図だけで業務システムが構築できるか? – BPMN 超入門(4)

    BPMN を全く知らなくても、コレを読むだけで業務プロセスの作成が可能になる!?
    業務改善に取り組みたい貴方のための超入門編!

    1. 各タスクの定義が各入力画面に!

    ソフトウェアの進化は恐ろしいモノで、BPMNでビジネスプロセスを描けば、「業務システム」が出来上がる時代になりました。
    特に「BPM Suite」と呼ばれるソフトウェアでは、角丸四角のタスク毎が自動的に入出力画面になります。早い話、上流からプロセスが到着すると、担当者は情報入力を求められます。

    ちなみに「ワークフロー」と呼ばれるソフトウェアと目的とする所に大きな違いはありません。概念的に「BPM Suite」に内包されるので、ハマチとブリの違いみたいなものです。 (編注:ん???)

    ただ、ビジネスプロセス定義が「描画設定」できる為、ループや分岐と言った複雑なルール設定や、あるいは定義そのものの変更管理が容易に実現できます。

     2. 何種類のアイコンを覚える必要があるか?

    BPMNには、意外と多くの、意外と細かい表記規定があります。
    しかし他方、「BPMNを認識理解する」と標榜している「BPM Suite」でも、実はその9割を理解できません。そしてソフトウェア製品によって理解できる範囲が異なります。

    ビジネスプロセス図を壁に張り出して周知徹底させたい場合や、あるいはオーダーメイドの情報システムを発注するために仕様定義したい場合などには、多くの規定を学習しても良いかも知れませんが、「BPM Suite」への入力を前提とするなら、最初から「理解してくれる規定」だけを学べば良いです。

    各ソフトウェア製品のサポート範囲詳細は各販売社からの情報に任せるとして、総じて言える事は以下の通りです。

    • アクティビティ (マーカー5種類)
      多くのBPMSは通常タスクのみを理解し、いずれのマーカーも非対応
    • 開始/中間/終了イベント (マーカー10種類)
      メール等を外部から受信しプロセスを起動させることは多くのBPMSが対応。一部BPMSでは、プロセス途中でのメッセージ送信、プロセス終了時のメッセージ送信に対応している。途中で特定時刻を待つものや、特定時刻に自動的にプロセス開始できるものもあり。
    • ゲートウェイ (マーカー5種類)
      データによる単一選択[XOR分岐]と、全ルート選択[AND分岐]は、多くのBPMSが対応。一部のBPMSでは、1つもしくは複数の分岐を選択[OR分岐]することが可能。イベントによる単一選択は多くが非対応。

    3. BPMNを学ぶ目的

    前述の通り、BPMNはデータの取扱いは定義できません。また業務を実施する組織員の地位や権限を定義する事もできません。プロセスの流れについても、曖昧な表記を認めています。さらに打ち明ければ、一つのビジネスプロセスを、様々な方法で記述することができてしまいます。また、ビジネスプロセスの詳細な定義をするには、別途文章等で詳細に記述する必要があるでしょう。場合によってはビジネスプロセスがかかえるリスクについての考察も別途まとめておく必要があります。

    しかし、BPMNによるビジネスプロセス図は、「多くの閲覧者に直観的にビジネスプロセスを理解させること」ができます。

    • 改善議論
      現状のプロセスを描画、改善後のプロセスを描画、リスクの分析
    • 説明
      新人教育(業務マニュアル)、株主報告(SOX法対応)

    さらに「BPM Suite」等のソフトウェアを活用する事で、今この瞬間の現状や一定期間の結果など、現実の処理状況が把握できるようになります。

    • 統制
      標準化(属人手法の排除)、不正防止(業務ログの取得)
    • 生産性向上
      滞留検知(エラー検知)、再利用性向上
    • 人事考課
      個人別グループ別の生産量測定、時間当たりの生産量測定

    何を目的にBPMNを学ぶのかは人によって異なりますが、まずは例えば上記のいずれを目的とするのかを決めてから学習を進めたい所です。もちろん、同じ目的意識を持ってチームで学習を進めるに越した事はありません。

    4. 最後に

    最後の章になりました。感動の涙で、ここまで読んで下さっている貴方の顔が見えません。 (編注:もともと見えるものではありません)

    企業の競争力の源泉は業務プロセスです。企業はビジネスプロセスを変化させ続けなければなりません。そしてまた、企業は変化し続けるビジネスプロセスを把握共有し続けなければなりません。ベテランスタッフの知見にばかり頼るのではなく、BPMNを活用したビジネスプロセス管理(Business Process Management)を推進しては如何でしょうか。

    BPMN 超入門シリーズ