ウチの課長は、なぜ業務フロー図を書かないのか?

「業務フロー図」は業務改革のベースだ。では「業務フロー図」のメンテナンスにはどのような体制が必要なのだろうか?

最近「ソモソモ業務フローの必要性がワカラン」と言うコメントを複数人からもらった。
普通のヒトにとって、業務フロー図なんて、見たことが無ければ、業務フロー図に従って仕事を処理したことも無い訳で、、、整理するも何も、ソリャ全く分かんねーだろーと思う。と言う事で、今日は初心に戻って『業務フロー図の必要性と具体的な業務フロー図の書き方』について、まとめてみようと思う。(結構タイヘンかも…)

1.そもそも何故「業務フロー図」が必要なのか?
2.では、何故「業務フロー図」が無いのか?
3.ちなみに、何故「業務フロー図」はムツカシイのか?
4.では、どうすれば「業務フロー図」が書けるのか?

業務フロー図の例: 名刺追加の申請 (workflow-sample 2012-11-05)

 

まずもって「業務フロー図」とは何だろう?
「フローチャート」とか「業務プロセス図」とか「ワークフロー図」とか、表現はイロイロだ。要するに『業務の進め方がわかる図』だ。公的文書の中では「業務の流れ図」と呼ばれる。

最大の特徴は、業務マニュアルが『文字』で書かれるのに対して、業務フロー図は『チャート』と呼ばれる図で記述される点だ。カタカナで説明すると「ほな Chart ってナンヤネン」と突っ込まれる訳だが、Chart とはそもそも「海図・航空図・天気図」を表す英単語だ。つまり業務フロー図は「進むべき道を知る為の図」が記述される。「フロー」+「チャート」と言う表現は「全体の流れが解かる図」と言う意味になる。文字と違って、全体の流れを素早く理解できる。

業務フロー図は、全ての社員が、
– 「私は、全体の業務の流れの中で、どの作業工程を担当しているのか?」
– 「私は、何を受け取って(INPUT)、何を産みだし(manufacture)、誰に渡せば(OUTPUT)良いのか?」
を解決できる図である事が理想だ。

むかし「チャート式」なる参考書にお世話になったが、「この参考書が船における海図のような役割を果たすものでありたいという願いから名付けられた」(Wikipedia)らしい。(「赤チャート」はカナリ試練だったぞ・・・ん?どうでもいい!)

<業務フロー図のニーズ>
1-1. 社内に現状フローを共有したり、変更内容を共有したりするため
1-2. 社内に現状フローを教えるため
1-3. 社外に現状フローを報告するため

一番目のニーズとして挙げてみたが、『1-1. 社内に現状を共有したり、現状の変更を共有したりするため』は、実はかなりハイレベルな要求だ。確かに、現場社員にしてみれば『「おおよその流れ」しかわからない図』なんて日常においては全く必要ない。
しかし、「業務の流れを工夫してチーム全体としての生産性を高める」や「不正が起きない様な情報伝達手順を考える」と言った発展的な議論をしようとすれば、たちまち現状の業務フローが必要になる。現実問題、「現状の業務フロー」を修正すると言う形でしか議論できない
ちなみに実際に業務フロー図を作成し、共有してみると分かるが、日常の業務も、意外と「属人的」(※)であったり、あるいは「流派」が分かれていたりするものだ。例えば以下の様な属人例(※)は、どの会社にもある。

◇1-1-1. クレーム対応フロー
クレームに対する回答メールを書く際に、Aさんは全ての回答文を上司にレビューしてもらってから送信しているのに対して、Bさんはたまにしか上司レビューを受けない。

◇1-1-2. 新Webページ追加フロー
ホームページに新ページを追加する際に、Aさんは、デザイナーさんに挿絵を書いてもらってから、本文原稿を書いて、その後またデザイナーさんにレイアウトを依頼するのに対して、Bさんは完全に本文原稿を書き終えてから、デザイナーさんに挿絵とレイアウトを依頼する。

※ ちなみに「業務フローが属人的」と言う表現は、しばしば大きな誤解を招いてしまうので注意が必要だ。特に
– [A].個人のスキルが属人的: 「人によって成果の品質が違う」「特定の人にしか成果を出せない」
– [B].情報伝達経路が属人的: 「人によって成果伝達の手順や経路が違う」
の2つ意味を混同してはならない。当然ながら、ここでは[B]「仕事を回す経路や順序にルールが無い」と言う意味で使っているが、日常会話は[A]のケースで使われる事の方が多いので注意が必要だ。例えば、[A1]「Excelスキルは人によって違うから成果がバラバラだ」とか、あるいは[A2]「A部長とB部長では判断基準が違う」と言った場合にも、「業務フローが属人的」と言う表現が使われる。

『1-2. 社内に現状フローを教えるため』は非常に分かりやすいニーズだ。特に、チームに新人を受け入れる際に、業務フロー図があれば便利だ。新卒採用や人事異動があった時に、「ホレ、ウチのチームは、こんなカンジでやってるんだよ」って渡してあげれば、新人は即座におおよその仕事の流れを理解できる。事業拡大期にある積極採用企業や、定期的な人事異動が多い会社であれば、業務フロー図は非常に有効な武器だ。「社内規定と業務マニュアルをお渡しシマスね・・・」とは比べ物にならない。

※ 「ウチには業務フロー図なんてネーぜ。OJTだ、おー・じぇー・てー!」などと、カタカナ用語でごまかそうとする上司には細心の注意が必要だ。確かに、実際の現場に身をもって飛び込んでいく On Job Training は即戦力化と言う視点で有効な手法かも知れないが、一方で「獅子の子落とし」的な残酷な教育訓練になってしまうケースも少なくない。すなわち、先輩社員のフォローが少ない新人は、自力でガケから這い上る羽目になり、結果として社内ノウハウとしての業務の流れを教わらずに成長してしまう。

上記2つのニーズと比べ、3つ目の『1-3. 社外に報告するため』は少し消極的なニーズだ。最も分かりやすい例はSOX法による内部統制報告制度だろう。上場企業等は金融庁に対して「業務の流れ図」を提出し、ガバナンスが効いてますよぉ~と報告する。延いては投資家保護に役立つ。

 

業務フロー図は必要だ。では「必要」なのに、何故「無い」のだろうか?

<業務フロー図が存在しない理由>
2-1. 作れない
2-2. 作れるけど、意味が無いから作らない
2-3. 作れるけど、誰が作るべきか分からないから作らない

『2-1. 作れない』は分かりやすい。作れないものは存在しえない。トンビが居ればタカも生まれるが、トンビすら居なければタカも何も生まれない。(なんか違う)
しかしこの例は非常に多いのだ。実際、身近な業務フローを描いてみて欲しい。百戦錬磨のベテラン社員であっても、パワポ(Power Point)やビジオ(Visio)で『新規作成』を選ぶと、その真っ白なキャンバスを目の前に、何から書けばいいか分からなくなる。業務を知らないわけではない。むしろ誰よりも知っている。単に、業務フローの描写がムツカシイのだ。
筆者自身、今でこそ500業務ほどをモデリングした経験があるから、およそどんな業務でもヒアリングすればその場でフローを描けるようになった(自慢)が、最初は1つ仕上げるのに5時間も10時間もかかったものだ。しかも、寝て起きてそのフロー図を見返すと、まだまだ改良できる点が何か所も残っている。最初の10フローは、何度も何度も書きなおす羽目になる。
『2-2. 作れるけど、意味が無いから作らない』はある意味深刻だ。しかしこの例も少なくない。では何故「意味が無い」と感じるのか?

それは
– [A]「業務フロー図が、陳腐化してしまうから」と
– [B]「業務フロー図だけでは、業務の流れを統制できないから」
の2つの理由に集約される。

[A]の業務フロー図の陳腐化の例で言えば、例えば、[A1]「パソコンの購入は、総務部で一括して調達する事になった」や[A2]「組織が改編され部署やチーム構造が変わった」などの内部要因や、[A3]「ライバル企業の出現で標準納期を半分にする必要がでてきた」などの外部要因で、業務フローそのものが変化してしまうのだ。その瞬間に、せっかく作った業務フロー図も過去のものになってしまう。メンテナンスが難しいことは改めて説明するまでもない。また、[B]の統制が困難と言う話は、「業務フロー図を壁に貼る」「毎月研修をする」などなど、色々な施策が考えられるが、やはり紙に書いた業務フロー図だけでは限界がある。

『2-3. 作れるけど、誰が作るべきか分からないから作らない』は困った話だ。デキルけどシナ~イと言う言わば職務放棄的な話だ。意外に思われるかもしれないが、業務フロー図に慣れた成熟組織でしばしば発生する。例えば製造部門と販売部門の業務をスムーズに流すと言った話になった際には、どうしても利害対立が発生するのだ。部署を横断する業務フローと言うヤツだ。「受注情報のチェックは販売部門でしておけよぉ」と言ったヤヤコシイ話にケリを付けなければならない。どちらの部門の業務についても精通している必要があるだけでなく、両部門を「全体最適」の名のもとに調停しなければならない。やっぱり人間、面倒なことはゴメンだ。(このケースは高度に組織論な話になる。結局のところ組織のトップが「プロセスオーナー」(後述)を任命するしかなさそうだ)

 

『2-1. 作れない』で触れた様に、業務フロー図の描画はムツカシイ。ここでは、業務フロー図が描きづらい理由を探ってみたい。
ちなみに、描写ツール側の問題には触れない。絵画に喩えるなら、紙や筆がツールにあたる。ここでは、「走る馬」は何故に描きづらいのか、「裸体」は何故に描きづらいのか、と言った対象物に内包する難しさの原因について考察してみたい。

<エクセレントな業務フロー図が描けない理由>
3-1. 実は社内ルールが無かった
3-2. 処理をどの粒度で書くべきか悩ましい
3-3. 例外処理をどこまで書くべきか悩ましい

『3-1. 実は社内ルールが無かった』は痛恨である。何せ描こうとする被写体が居ないのだ。まぁ、居ないと言ってしまうのは、やや乱暴だが、描こうとする業務フローが、「馬」の様だったり「車」の様だったり「寺院」の様だったり・・・。どれが本当の姿なのか全くわからない場合には、流石に描けない。
業務フロー(社内ルール)が無くても業務が動くのか? まぁそれはそれで動くのだ。人間と言う生き物はスゴイとしか言いようが無い。
『3-2. 処理をどの粒度で書くべきか悩ましい』は、上級者の口から出るであろう表現だ。第1章で「クレーム回答文を書く」と言う作業工程を例示したが、更に「タイトルを書く」「本文を書く」「見返す」などに分解する事ができる。描写粒度は幾らでも細かく出来る。
色々な粒度設定が考えられるが、まぁ原則論として、業務フロー図に描くべき工程の粒度は「一人の社員が Input を受けて Output を出すまで」とするのが良い。
『3-3. 例外処理をどこまで書くべきか悩ましい』は、究極の悩みだ。永遠の悩みと言っても良い。
これも原則論としては、発生頻度の低いものは省略する事になる。発生頻度の低い例外処理を描き出せばキリがない。そして、描けば書くほどに全体が見にくくなる。とは、言いながらも一方、重要業務については、コンティンジェンシープラン(不測事態手順)と言う考え方もある。滅多に発生しないものの、発生すれば、その際には速やかに切り替えられる様にしたいのだ。

 

必要な理由(第1章)、現存しない理由(第2章)、描写困難な理由(第3章)を踏まえて、業務フロー図の書き方や、業務フロー図を誰が書くべきか、を考察したい。

簡単にメンテナンスできるレベルの業務フロー図でなければならない。
働き手みんなにとっても便利な業務フロー図でなければならない。
会社を良くするための業務フロー図でなければならない。

4-1. ITツールの高度化の動き
4-2. 国際的な記法標準化の動き
4-3. プロセスオーナーと言う考え方

ヤッパリと言うか、当たり前の話と言うか、道具としてはITを使いたい。コンピュータはエライ!
2000年以降、21世紀に入り「業務上のデータやり取りをコンピュータに任せてしまおう」と言う思想に基づいたITが開発されている。もっとも20世紀にも「ワークフローシステム」と言う名称で存在していたのだが、それを大幅に拡張させたITだ。まだまだ認知度は低いが、それは「BPM システム」と呼ばれる。
概念は簡単。コンピュータに業務フロー図等で業務ルールを教えてあげると、人間同士のデータやり取りをコンピュータが仲介してくれるようになる、と言う仕組みだ。つまり「つぎの工程は何か」や「この案件は誰の処理に回すべきか」を判断して、良しなに仕事を回してくれる様になる。例えば、誰かが「見積書」を作ったとしてコンピュータに登録すれば、コンピュータが申請者の上司に対して「内容を確認して承認するか決めてチョ」と問う仕組みだ。また例えば、誰かが「日本語原稿」を作ったとしてコンピュータに登録すれば、コンピュータが翻訳者に対して「この日本語原稿を英語原稿にしてチョ」と言う。
100個だろうが1000個だろうが、会社内の全ての業務の進捗を把握し、どんどん仕事を回してくれるのだ。悪い言い方をすれば、人間は「歯車」になる。コンピュータが仕事を運んでくるので、言われるがままに作業を行う。
ちなみに、産業革命による「機械化」によって人間の尊厳が問われたが、この「IT化」の動きも人間の仕事を大きく減らす事につながるだろう。しかし、人間は次の役割を担えば良い。スマホが電話番号を覚えてくれるようになって、人間は退化したかも知れないが、それはそれで良いのだ。
(チェスや将棋で負けてもいいぢゃないか。小説を書いたり、ブログを書いたり、、、人間にしか出来ない事はまだまだある)
ならば、簡単にメンテナンスできるレベルの業務フロー図でなければならない。これは世界中の人が考えてきたことで、これまでにも沢山の業務フロー図フォーマット(アイコンの描き方やアイコン同士の接続の仕方)が提唱されてきた。
2000年以降、この「ITツールの高度化の動き」と連携して、業務フロー図の書き方(描き方)が BPMN と言うフォーマットに決まった。フォーマット自体が未だに進化の過程にあるが、およそ間違いない標準(デファクト・スタンダード)となっている。これは IBM・Oracle・Microsoft などの大手IT会社が主導したモノだが、流石に合理的で、コンピュータも人間も理解しやすいフォーマットと言う特徴がある。(Questetra だけが提唱している訳ではない)
最近では、米国政府や日本政府も相次いで採用の動きを見せており、政府内業務も BPMN で記述される日が近い。(KeyWord: 「業務・システム最適化」)
「ITツール(BPMシステム)を使いこなし、BPMN を学べばイイのか?」 答えは元気よくハイだ。しかし、より重要な事がある。それは、誰が業務フロー図のメンテナンス責任者であるかを明確にする事だ。彼らは、プロセスオーナーと呼ばれる。言い換えれば、社内にあるそれぞれの業務フローにプロセスオーナーを決定するべきだ。当初は兼務であっても良い。
これは本稿の中で、もっとも大切な事で、もっとも重要な事で、もっともインポータントな事だ。(?!?!)

情報システムや品質管理と同様、この人間の雇用は「間接投資」に該当するが、中期的に見てとても投資効果が高いはずだ。いや投資効果が高い人を雇用しなければならない。組織によっては、そのプロセスオーナー達を束ねるトップを役員待遇で雇用すべきかもしれない。 実際、情報戦略を担う CIO (Chief Information Officer) や技術戦略を担う CTO (chief Technical Officer) と同様に、業務フローの全社最適化を担う CPO (Chief Process Officer) と言う統括ポジションを用意する会社も少なくない。(COO や CFO が担うべきと言う議論もあるが、「業務プロセス」に関する専門的な知識で全社を統治すべきだ)

ちなみに、BPMN はコンピュータのためのモノでもある。業務フローを良くしたいなぁと思っている一般の方(末端のプロセスオーナーを含む)は、BPMN の深い部分について理解する必要が無い。しかし、数多くの業務フロー図に触れ、おおよそ読めるようになる必要はある。

では、プロセスオーナーは何をすればよいのだろうか。(2013年現在の所見だが)、それは、[A]「セオリー(コツ)を学ぶ事」と[B]「良い事例を真似る事」に集約されると思っている。

[A]セオリーについては、「BPM 100 Success Secrets」などの専門的なマニュアルもあるが、まだ決定的な教科書は存在しない。(ただ今後「OMG認定BPMエキスパート資格試験(OCEB=オーセブ)」の分かりやすい解説書が出てくるとは思う)。今のところは、業務フローの書き方については、様々な良書や雑誌記事が出回っているので、それらをチェックするだけで良いだろう。ちなみに Questetra サイトにも「業務プロセスモデリングの鉄則」などの学習記事が多数ある。

[B]良い事例については、なかなか無い。これは実は当たり前の話で、業務効率を良くするワザは、なかなか公開されるものではない。場合によっては「競争力の源泉」だ。しかし、最近は、業務フロー図のテンプレートやサンプルであれば、数多く検索できる様になってきた。Questetra も御多分にもれず「ワークフローサンプル」と言う業務雛形提案サイトを運営している。500以上の業務フロー図が掲載されているので、「見積書」や「稟議書」などのキーワードで検索して欲しい。

 


何とも長い文章になってしまった(そして後半は疲れの見える文章になってしまった)が、最後に Questetra の宣伝だ。(そう、このために書いている・・・)
実は、、、なんと、、、 Questetra は、、、、この夢の様なITツール「BPMシステム」の開発会社だ。(シラジラシイ)。しかも、世界最大の調査会社 Gartner から、「グローバル BPM の中の Cool Vendor」と注目されていたりする。(たぶんスゴイ事です)

そして Questetra には、なんと「無料版」がある。この際、是非、実際に使ってみて頂きたい(コレ、強く言いたいコト)。少人数組織であれば、ずっと無料で使い続ける事ができる。大企業の方も、まずはチーム内で試してみては如何だろうか?

無料版に申し込む

 

なお使い方は簡単だ。しかもWebブラウザさえあればイイ(SaaS BPM)。詳しくは『モデリング各機能』のページや「使い方」のページ等を見てもらいたいが、一部抜粋すれば以下の様な手順になる。

30分で業務アプリ

  1. フローを決める(Drag & Drop)
    アイコンを配置して業務の流れを設計します。各処理工程(タスク)は角丸長方形で表現されます。
  2. 入力項目を決める(データ設定)
    文字型・日付型・選択肢型など、業務に必要な項目を設計します。
    例:「申請理由」「申請者名」など
  3. アクセスレベルを設定する
    どの処理工程で、どの項目に入力できるのかを決定します。
    例:「決裁工程で『申請理由』の編集は不可」など
  4. 担当者を設定する
    各工程の処理を誰が(どのグループが)担当するかを決定します。
    例:「決裁工程は申請者の上司」など
  5. 分岐ルールを設定する
    ゲートウェイにおける条件分岐式を記述します。
    例:「500万円以上は社長へ」など

 


世界中のシゴトが、もっとスムーズに回るようにする!!
株式会社クエステトラ 代表執行役CEO 今村元一 (2013-01-18)

questetra-modeldriven

 

.

IMAMURA Genichi の紹介

CEO & Founder - Questetra, Inc. || http://www.facebook.com/imamura.genichi
IMAMURA Genichi の投稿をすべて表示

あわせて読みたい
15.野望・展望・志 の前の記事 Facebook ページの「多言語設定」が、また一歩
15.野望・展望・志 の次の記事 新スマホの「かざす」は、業務フローを変える
IMAMURA Genichi の他の記事 こおり水、かぶらない。。。 って、ダメかな?

アーカイブ

 RSS