業務プロセス管理（BPM）は、ワークフロー（ワークフローアプリ）を把握するところから始まります。この『プロセス改善ストーリー』を参考にして、あなたも業務プロセス改善を始めてみませんか？
顧客からの問い合わせの意味・・・
日本には「お客様は神様」と言う表現がある。顧客からの問い合わせはまさに「神の声」かも知れない。少なくとも、分からない事を分からないままに放置している他の多くの顧客とは大きな違いがある。
多くの企業では、問い合わせ窓口を設置して、顧客の不満を解消する。それがコールセンターであったり、インバウンドメール処理チームであったりする。しかしその「不満解消活動」は、別の角度から見れば「顧客に伝わっていない情報をリストアップできるプロセス」でもある。
伝わっていない原因は、さまざまに想像できる。
- 情報を発信していない （情報発信不足）
- 情報を発信しているが、品質が低い （発信情報品質）
- 情報を発信しているが、見つけられない （発信情報検索性）
いずれにせよ「顧客に伝わっていない情報のリストアップ」は、原因特定の足掛かりとなろう。
社内からの問い合わせも
よく考えれば、社内からの問い合わせにも大きなヒントがある。およそ「顧客に伝えるべき事」は、「社内に伝えておくべき事」に含まれるはずだ。「社内に伝えておくべき事」がリストアップされていれば、「顧客に伝えるべき事」の網羅性担保に役立つ。すなわち「情報不足」が回避される可能性が高い。
必要あれば助言を受け（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エンジンによってその使用が制限されるケースがある。
問い合わせに始まる組織方針の議論
たとえば重要クライアントからの問い合わせを想定したとする。この場合、問い合わせを起点に回答文書の作成が必要になるケースがある。
このダイアグラム例は、各部の助言担当者が「部に持ち帰り検討し、文書回答する」と言ったケースを示している。
合意の形成
グループ内での合意の形成に、議論の場は欠かせない。プロセスオーナーはどの様なプロセスでグループ内合意を図っていくべきか、その業務内容に応じて熟考する必要がある。得てしてプロセスはループする。
なお、多くのタスクは、スイムレーンに定義されるグループの「誰か」が対応すれば良い。更に図７Ma2タスクの様に、スイムレーン内のタスクを誰かがすでに実行している場合には、「その実行した人」が実行すれば良い（そのようなルールはリテインファミリア/精通者維持と呼ばれる）。
確かに図７の原稿編集会議（D1）において、「誰か」が「議事録を入力する」と言う形を取っても構わないが、「みんな」で実行すべきタスクが存在すると考える方が自然だ。そして「みんなでタスク」はBPMソフトによってその実装が大きく異なる。 [完]
