Recently in イノベーションを支援するITシステム構築の極意 Category

さて、7つの作法の最後になります「実装する」です。最終的にはITに実装して、それを使って日々オペレーションしていくことが大事になります。前回作成した「プロセス要素表」から実装していきます。こういうと、要件定義をしてプログラム仕様書を書いてそれから実装するのでしょう、あるいはパッケージを持ってきてFitGapをやるのでしょうと言われる。

ここでは、そんなことはしません。まず対象が"意思決定プロセス"であることがあります。また、プロセス要素表を見てもらうとわかるようにプログラムできっちりと作れるような定型的なものではないということです。つまり、非定型で人間が介在するような仕組みでプロセス要素表にある各要素が仕込めるプラットフォームがあればそこに"設定"すればよいのです。

プラットフォームは基本的にデータ管理とプロセス管理そしてコミュニケーションができるものであればいいのです。そういったものにBPMSがありますが、意外と定型業務向きなので、ここではサイボウズ社の「kintone」を採用することにします。kintoneの謳い文句である"データとプロセスとコミュニュケーションを一体化させた"というのがコンセプトですからぴったりですね。多少使い方の工夫が要りますが十分使えるツールと言えます。
   
kintoneを使った実装の手順は本ブログの「ビジネスサービスのつくり方」という記事に詳しく出ていますのでそちらの方を参照してください。ざっとした手順だけは記しておきます。

1. Portalからアプリケーション作成方法を選択します。


portal.JPGのサムネール画像

2.はじめから作成の場合
  ステップ1  アプロの名前を入力します
  ステップ2  一般設定(アイコンやデザインテーマなど)
  ステップ3  フォームの設定(データの入力フォームを作る)
  ステップ4  一覧の追加(データの一覧画面に表示する項目を選ぶ)
  アプリの運用を開始するために「設定完了」をクリックする。


フォーム設定.JPGのサムネール画像


このように、設定だけでアプリケーションを組むことができます。フォームの設定でも、あらかじめ用意されたフィールドパーツ(ラベル、文字列、数値、日付、ラジオボタン、チェックボックス、ドロップダウンなど)をドラッグ&ペーストで貼り付けるだけです。その他にも、通知の設定やアクセス権の設定、グラフ化なども簡単にできます。最近ではAPI連携とかJavaScript/CSSカスタマイズもできるようになりかなり機能が充実してきています。ということで、7つの作法を終わることにします。
  

前回からの続きで「プロセス要素表を作成する」です。プロセスオペレーションプラットフォームの要件となぜそうした要件になったかをサイモンの意思決定プロセスで説明しました。ここでは、具体的にプロセス要素表とはどんなものか、どうやって書いていったらいいのかを見ていきます。このテーマのタイトルが「イノベーションを支援する」ですからそういった目的に合っているかどうか考えてみてください。

まずは、プロセス要素表を示しておきましょう。

ProcessElment.jpg
表の一番左のアクティビティの列には意思決定プロセスの基本の項目が入ってきます。そして、次の「確定データ・判断」では、意思決定とはデータを確定することとある判断をおこなうことだと定義してありますからその要素を入れます。「依頼受付」「要求仕様確定」「作業」「報告・登録」も一種の意思決定ですから同じように記します。例えば、依頼受付だと依頼内容とか依頼受付日といったものが確定データになります。

「付帯登録情報」は必須情報ではないが参考のためとか、付記したほうがわかりやすいといった情報になります。例えば、住所に対する地図だとか納期に納入条件を入れるとかいったことです。「業務ルール」は意思決定を行うための則るもので、その中には概念ルール、数値ルール、アクションルールなどがあります。非常に重要なものでサイモンの意思決定プロセスでも代替案の選択の基準もこのルールになります。

ルールは単純なものから、ある条件を入れてデシジョンテーブルを通して答えを返してもらうなんていうものもあります。BPMとBRMが連携するというのはこういうケースのことです。参照情報は意思決定するときは何らかの情報を参照しながら行うのが普通です。できるだけ有用な多くの情報に基づくほうがより正しい意思決定が行われるはずです。参照情報には、マスタとか履歴といった事実情報、リソース状況、シミュレション結果などの判断情報、契約とか規約などの成約情報があります。業務ルールも判断情報のひとつですが重要であるので独立した要素として抜き出しています。

「ロール」は起案、チェック、承認などを規定しておくところです。プロセス全体もさることながら、単位意思決定でも責任者を決めておくべきでしょう。パフォーマンス指標は、コントロールすべき対象と閾値を書きます。例えば、報告日の3日前に作業が終わっていなかったら担当者にアラートを出すとかいったことになります。最後のデータ連携は取り込みデータ、提供データ、連携システムとの関係などを記入します。

もちろんこの表を全部埋める必要はありません。最初に設計すると大抵は書くセルが少ないでしょうが、大事なのはオペレーションを重ねていきながら増や
していくことなのです。例えば、最初は業務ルールもちゃんとしていなくてもまずは慣例でもいから運用してみて、やっていくうちにルール化されたら、それを業務ルールとして記述していく。他の項目についても絶えずブラッシュアップしていいものに近づけることが非常に重要なのです。

意思決定プロセスのシステム化の最も重要な過程はここの「プロセス要素表」の記述です。この表が適切に書けること、すなわちこのレベルのプロセス設計ができれば実装に移ることができます。
 

今回は(8)の「プロセス要素表を作成する」になります。実装に近いプロセス設計です。前回、プロセスを構成するアクティビティのモデルは「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」というふうに定義しました。ここでは、作業プロセスがない単純な意思決定プロセスを例にとって見ていきます。

プロセスを設計するときに大事なことは、オペレーションから発想することです。どういうオペレーションをすれば戦略の実行が可能か、ひいてはビジネスに貢献できるのかという観点です。これがちょっと大げさなら、こんなことができれば自信をもってマネジメントができるというものは何かということです。

オペレーションプラットフォームの要件は次のようなことになります。
ビジネスの進捗がわかること
意思決定(データの確定・判断)に必要な参照情報を得られること
コミュニケーションをしながら意思決定が行えること
プロセス全体と単位意思決定の責任者が明確になっていること
パフォーマンスの状況がわかり対応アクションがとれること
オペレーションの結果がアーカイブされて、次に生かされること

こうした要件を導き出した背景には、ハーバート・サイモンの「意思決定論」があります。少々長くなるが引用します。

■限定合理性と満足化原理に基づく意思決定
人間が完全に合理的な存在であるなら、あらゆる代替案のなかから、一定の評価基準に照らして最も有利な選択を行うという最適化原理に基づく意思決定ができる。しかし、合理性に限界(限定合理性)があるゆえに、人間は満足化原理に基づく意思決定をせざるを得ない

■意思決定プロセス
情報活動(情報収集 )➝設計活動(代替案の探索・評価 )➝選択活動(代替案の選択)➝ 検討活動(代替案の実施 ・フィードバック)

 ■組織目的の階層化と組織の意思決定
人間 は、限界合理性ゆえに、大きな問題に一挙に対処することはできず、複雑な問題の解決にあたる場合、問題を分解して組織の目的の階層化を行う。意思決定の複合体系としての組織は、その組織目的の階層化に併せて組織の意思決定も階層化して、人間の合理性の限界を克服しつつ、組織目的の合理的達成を追求する。

簡単に言うと意思決定を自動化してロジカルに意思決定できないので、意思決定プロセスを通じてより合理的な決定をくだすしかない。また、ひとりで全部意思決定できなから組織を作って分担させなくてはいけないということです。プロセス構成要素の各アクティビティは広義の意味で単位意思決定ですから、サイモンの理論を適用することができます。

オペレーションプラットフォームの要件がこの考え方に沿っていることがお分かりになったでしょうか。次回に具体的な「プロセス要素表」の要素と書き方を説明します。
  

7つの作法の4つ目は「作業プロセスがある場合はそれをサブプロセスとして記述する」です。毎回言っていますが、プロセスの基本構成は、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」ですが、その作業プロセスのことになります。作業プロセスは前回例に出した見積提示プロセスのようなものだとほとんど作業らしきものがない場合もあります。

一方で主として作業プロセスからなる場合もあります。例えば製造プロセスのようにもうやるべきことが決まっていて、依頼がきたら手順に従って実行するといった場合です。要求仕様は逆に決まったものを受け付けるから与件としてあるし、段取りにあたる意思決定も既定のものとして扱うからです。ですから、プロセスの性格が意思決定が大事なのか作業が主たるプロセスかで多少構成が変わってくることもあります。

作業プロセスの基本構成は、「作業依頼受付」「作業項目確定」「期日決定」「担当者割当」「作業結果報告」というものになります。意思決定に基づき作業すべき内容がこの作業プロセスに受け渡されます。それを受けた作業プロセスでは、作業内容に従って、作業項目(タスク)にブレークダウンし、タスクごとに期日と担当者を決めて、作業の結果を集約することを行います。

意思決定プロセス→作業プロセス→タスク管理というようにつながって行くわけですが、キーとなる作業名、作業内容、期日はちゃんと継承されていきます。こうして実行された作業結果はデータ、報告書などの帳票、制作物などとして大元の意思決定プロセに戻されます。

さて次に5つ目の作法である「プロセス構成モデルからケース分割とタスク分解を検討する」になります。これはわかりにくいかもしれませんが、作業プロセスがいくつかのケースに分割されることがあるのでそれを見ていきましょうということです。作業プロセスに受け渡す作業内容が複数の作業プロセスになる場合です。

例をあげると、新規顧客獲得プロセスというものを考えてください。いつまでに何人を見込顧客として獲得しなくてはいけないのでキャンペーンを行うというようなプロセスの場合です。例えば、展示会たけのキャンペーンでいいなら1つの作業プロセスで済みますが、他にもDMだとか訪問だとかといったものも実施するとなると作業プロセスが複数になる場合です。こうした時にはケース分割とタスク分解を行います。
  

始点と終点と中間アクティビティが決まったら、主要なアクティビティである意思決定で確定すべきデータあるいは判断項目を定義することになります。この辺になるとわかりづらくなりそうなので具体的なプロセスを例にして説明していくことにします。

「見積提示プロセス」を例に今までのおさらいも含めて見ていきましょう。このプロセスの始点は「見積依頼」で、終点は「見積書提出」です。このプロセスは典型的な顧客接点プロセスですから、始点から先に決めます。お客さんはこういうものが欲しいから見積書を作って送ってくれと言いますのでそこが出発点になります。

見積依頼は見積書をお客さんが受領して終わります。つぎの商談から受注までを一つのプロセスと考えてはいけません。顧客は見積をもらってから発注するかどうかはわかりませんから別のプロセスとして扱います。このように、リクエストに対するレスポンスという関係がプロセスの骨格となるわけです。

次に中間アクティビティをみていきましょう。意思決定プロセスでは、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」という要素からなっていることを前回示しました。ですから、「見積依頼受付」が最初で最後が「見積結果報告」ということになります。2番目の「要求仕様確定」というのは、どんなものあるいはどんなことを見積もって欲しいかを確定することです。

お客さんの頼み方も様々できちんとした依頼書を書いて提出してくれる場合もあるでしょうし、逆にだいたいこんなものでといった曖昧な表現で頼んでくる場合もあります。話は少しそれますが、この両極端の場合は注意が必要です。きちんと仕様を決めてくれるというのは一見良さそうですが、あまりに詳細に決められると提供側の裁量を入れられないという事態が起こるケースもあってやめたほうがよいと思います。

普通は見積を依頼する側よりも提供側のほうが情報が高度で多いはずだからプロの意見を取り入れたほうがいいからです。素人が玄人のことに口出しするなですね。反対に、曖昧な依頼も困ったものです。往々にしてベテラン同士のやりとりにあったりします。手戻りに泣かされることになります。

ここでの主題は「意思決定」の中身の定義の話ですから、「見積提示プロセス」ではどうなるのでしょうか。その前に意思決定と言うのはどういうことをすることなのでしょうか。それは、"データを確定すること"と"ある判断をすること"と考えています。データ確定も原則一つのデータです。こういう数値にするという決定のことです。

ここでおわかりかと思いますが、「依頼」から「要求仕様」を確定するというのは、確定してほしいデータ、判断をしてほしいことを書き出すことに等しいのです。「見積提示プロセス」では、実際には顧客要求を聞いてから意思決定アクティビティが決まりますが、理解しやすいように常識的なものをあげておきます。

見積書に記入する項目として主なものは、「商品仕様」「数量」「納期」「価格」といったものになるでしょう。こうしたデータをプロセスの中で順番に決めて行くわけです。そして、意思決定ともう一つの中間アクティビティに「作業」というのがあると言いました。この例では、「見積書作成」というのが作業になるわけですが、今どき手書きではないので、確定データを中間登録しておけば自動的に作成してくれるでしょうから、ほとんど作業なしでプロセスオペレーションできることになります。
  

プロセス名を決め、始点と終点を決めると、次はプロセス構成に従って中間アクティビティを記述することを行います。ここでプロセス構成に従ってと言っているからには、プロセス構成について説明しておかなければいけませんね。基本的な構成は下記のようになっています。

プロセス構成.JPG

まず大きく意思決定プロセスと作業プロセス、タスク管理から成り立っています。ここで詳細に行く前にこのプロセス構成のバリーションを考えてみます。現実のプロセスでは意思決定プロセス、作業プロセス、タスク管理の重要度というか構成割合が違ってきます。そのバリエーションが下図となります。
 

構成バリエーション.JPG
 

ここも大きく3層と2層の構造に分かれます。3層では意思決定主体か作業主体かがあります。また、2層のものもあって、同じように意思決定が主体か作業が主体かでタイプが違ってきます。それぞれの説明は省きますが、従来システム化の対象となったのはDタイプです。どんな作業をすべきかがすでにあって、それをいかに効率的に実行するのかが焦点となるケースです。

ですから、ここはITを使って自動化することが目的になる場合が多く見られます。ところが、このプロセス構成では、段取りが与件としてあるという前提なのですが、実はこの段取りをどうするかが重要なのです。段取りが悪いものをいくら効率的にやったとしても手戻りが発生したりしたら何もならないわけです。

さて、プロセスの構成にある中間アクティビティを見ていきましょう。意思決定プロセスでは、「依頼受付」「要求仕様確定」「意思決定」「作業」「報告・登録」という要素が提示されています。前回始点と終点を先に決めると言いましたが、その始点は「依頼受付」、終点は「報告・登録」になります。つまり、内部でも外部でもいいのですが、何かこうしてほしいという依頼が出発点となります。その依頼に対する答えを作って依頼主に報告しでデータベースに登録するのが終点になります。

その間にあるのが中間アクティビティです。まず依頼がきたらその依頼の内容、どんな要求なのかをきちんと把握して固めておくことが大事です。あいまいなままにしておくと手戻りが発生してしまいます。依頼者は往々にしてこんな感じにといった抽象的な依頼をしてくる場合が多いのできちんとつめておいたほうがよいと思います。

その後は、単位意思決定を連鎖させたものになります。要求項目は複数のものがほとんどですから、複数の意思決定や判断になります。そして、作業がある場合には作業プロセスに落とし込みます。意思決定したものと作業プロセスから生成されたデータを合わせて報告・登録に持って行くことになります。


作業プロセスでは始点が「作業依頼受付」から作業指示がだされ、終点が「作業結果」ということになります。そして中間アクティビティは基本的には様々なアクションのつながりになります。このように、どんなリクエストがあってその内容を確定し、どんな答えを返してあげればよいのかを決め、どんな意思決定や判断を行うのか、作業な何があるのか定義していくことになります。
  

5つの誤解のあとは、7つの作法になります。いよいよシステム構築のHowの領域に入っていきます。その7つの作法というのが下記のとおりです。

(1) プロセス名を決め、始点と終点を決める
(2) プロセス構成に従って中間アクティビティを記述する
(3) 主要なアクティビティである意思決定では確定すべきデータあるいは判断項目を定義する
(4) 作業プロセスがある場合はそれをサブプロセスとして記述する
(5) プロセス構成モデルからケース分割とタスク分解を検討する
(6) プロセス要素表を作成する
(7) 実装する

ここで"作法"と言っているのは、厳格な技法でその通りにやらなくてはいけないというものではないことを意味しています。だいたいのやり方があって、人によって違っても構わないということでもある。ただ、勝手にやっていいかというわけではなく、最低限の決まりは守ってよねというものです。

では、最初の「プロセス名を決め、始点と終点を決める」です。プロセスというのは必ず始まりと終わりがあります。その時何を持って始まって、どうなったら終わるのかは決めておいたほうだがいいですよね。というか、それがないと業務という意味がなくなってしまいます。目的がないことをやるのは組織では許されませんから、きちんと始点と終点を決めないといけません。しかも、始点と終点は密接に関係していて始点が決まれば必然的に終点が決まるし、その反対もあるということです。

では、始点と終点はどちらを先に決めたらよいのでしょうか。これはプロセスの性格によって違ってきます。ざっくりと言うと顧客接点プロセスか、内部プロセスで決め方が変わります。顧客接点では始点を先に決めていきます。お客さんの要求が起点になるからです。

一方、内部プロセスでは逆に終点から決めていきます。内部プロセスというのは、企業としての事情で起こされたプロセスを指していて、例えば、決算で売上の集計が欲しいといったような場合は、初めにアウトプットがあってそのためにどういうインプットがいるのかという流れになるからです。

始点と終点が決まると自ずとプロセス名も決まってきます。この時気を付けなくてはいけないのが、プロセスの具体的な動きがわからないような曖昧な名前にしないことです。よくつけられる名前に〇〇管理プロセスというのがありますが、こういった名前は避けましょう。単に「見積管理プロセス」なんてつけないで「標準品見積提示プロセス」というふうにします。
  

さて、最後の誤解は「ワークフローのことである」です。これはよくある誤解ですね。ただ、プロセスとワークフローの違いについて明確に規定したものはないでしょう。ということは定義の仕方でプロセスにもなるしワークフローにもなると言えます。ですから、ここは筆者の定義をベースに明らかにワークフローなのに業務プロセスと名乗っていることの間違いを指摘したいと思います。

また、ワークフローとBPMの違いをいう人がいますが、これは土俵が違うので比較することに意味がありませんので注意してください。業務とか仕事の流れをどう呼ぶかという観点になります。両者とも言い方としては、インプットがあってそれに対して何らかの処理を経てアウトプットを出すということでは一緒です。従って、どんな構造をもっているのか、どんなことをするのか、どういう使われ方をするのか、そして何のためにあるのか、という切り口でみていくことにします。構造、機能、使い手、目的の違いを検討するということななります。

まずは構造という問題です。先ほど言ったように両者ともインプットとその中間の過程とアウトプットから成っているといいましたが、ワークフローの場合は、そのフローが基本的には一層になっています。つまり、中間の過程がアクションとか単位作業になっていてそれは分解できない構造になっていることです。それに対してプロセスは、しばしば階層構造をとることになります。

プロセスでは中間過程は複数のアクティビティから構成されますが、その個別アクティビティにサブプロセスを持つことがあります。そして、そのサブプロセスがワークフローであることもあるわけです。中間過程の粒度が違うのです。つまり、プロセスはワークフローも内包したような大きな包括的な構造をもったものなのです。

次にどんなことをしたいのか、どのような機能をもたせているのかというところです。モニタリング機能が大きいように思います。そこから、パフォーマンス管理やプロセスコントロールといったところへ持っていくことがプロセスの重要な機能です。

使い手の問題が一番わかりやすいかもしれません。ワークフローは基本的には個人が使うものです。典型的なワークフローに申請承認ワークフローというのがありますが、これは個人が願い出てそれを承認してもらうという流れですから割と単純なフローで個人用になります。プロセスは組織としてチームとして業務処理を行うためのものです。要するに個人競技と団体競技の違いです。

最後の目的という側面では、ビジネスとの結びつきの程度が問題になります。ビジネス上の要求に応えられるかどうかです。戦略とか事業方針、あるいは改革課題といったところから絶えずビジネス要求が出てきますが、その受け皿にワークフローはなれるでしょうか。個人の仕事の流れであるところでは無理です。すなわち、重要な差異はビジネス要求を実行する仕組みとしてプロセスがあり、個人レベルのタスクを処理する仕組みとしてワークフローがあるということではないでしょうか。
  



誤解の4つ目は「データや機能は重要ではない」ということで、ITでよく出てくる3文字熟語とかキャッチフレーズは、ぱっと注目されて流行りだすと、あたかもそれ一辺倒になることがしばしば起こります。昔のことでいうとクライアント・サーバーが言われた時は、メインフレームは全部駆逐されるのではないかくらいの勢いだったし、ERPの登場は猫も杓子もERPだと叫んでいた。だからBPMというと(まだは流行っていませんが)プロセスだけだと誤解するかもしれません。

システムだからどれか一つだけということはありえないわけで、さまざまな要素が複合して構成されているから、どこを重要視するのか、どこから始めるのかとかいった軸の置き方が違って来るだけなのです。筆者はITシステムは大きくプロセス、データ、機能(UI)から構成されているという捉え方をしている。フローとストックとインターフェースということです。

このシリーズで強調しているのはITシステム構築はプロセス中心、プロセス先行で行こうよねということです。そうなると、データとかUIはどうなるのかということなります。もちろん両方とも絶対に必要です。ただ、イノベーションを支援するという目的を考えると、データをマネジすること、UIを充実させることがそれにあてはまるかというとこうではないように思います。

画期的な商品の開発とか、圧倒的な市場占有率の獲得とか、卓越した商品提供力といったことはプロセスを重視したアプローチが有効であると言えそうです。では、データとかUIの出番はどこなのだろうか。まず、データですが、以前DOAというのが注目されました。データ中心アプローチでシステム開発をするというもので、せっせとER図を書いたものです。
  
しかしながら、それはあくまでITシステム、もっと正確に言うとデータベースシステムを作るためのものであったと言わざるを得ないと感じています。つまり、データの登録・更新、検索、帳票出力の仕組みをDOAで作ったわけです。DOAにおけるデータの捕捉を画面と帳票から行うということはそれを意味しています。ですから、プロセス表現が難しいしわかりにくいのです。

では、データ中心は必要ないのかというとそうではありません。データには大きくリソース系のものとイベント系のものがありますが、リソース系すなわちマスタデータはデータ中心で捉えるべきなのです。ビジネスを行うためのリソースを整理しておかなくてはビジネスモデルを変えるにしても、プロセスを改革するにしてもできないわけで、先行してデータベースを設計しておかなくてはいけません。

一方、UIは最近ではスマホに代表されるデバイスの多様化、進化があります。これは、顧客やサプライヤーといった外部接点にしても、あるいは内部の従業員にとっても使い勝手のよい、効率的な機能を要求していけるようになったわけです。ですから、プロセスサイドからの要求としての機能は当然ありますが、マンマシンインターフェースはプロセスとは必ずしも関連しないでも設計していくことになります。繰り返しますが、プロセス、データ、UIは重要となるエリアが違うのでそれ相応のアプローチが必要であるということです。
  

次なる誤解は「新たな業務プロセスを開発する」ということになりますが、誤解が誤解を生むかもしれないので少し注意が必要です。というのは、新たな業務プロセスを全く開発しないのかというとそんなことはなくて、場合によっては開発することもあるからです。

ここであえてこういう表現をしたのは、最初から新しいプロセスをつくり上げるのだと意気込まないほうがよいという警鐘をならしたかったからです。業務システム構築のプロジェクトが発足すると、IT化されていない部分がプロセスがないかのように錯覚して、そこが問題だと言わんばかりに新業務システムを開発するのだということになる。

ただ、最初に言ったように結果的には新たなプロセスにはなるのだが、順序が逆なのです。つまり、AsIsとかToBeというのをあまり意識せずに素直に業務プロセスを記述することから始めたらどうだろうか。なぜなら、業務プロセスというのは、ビジネスをやっている以上必ず存在するもので、意識、無意識に関わらず日々プロセスを回しているのです。

それは、マクロレベルのプロセスを見ればわかると思いますが、会社の大小、業種・業態に関係なしに共通的なもので、例えば販売、購買、受注出荷、生産なんていうプロセスは同じプロセスです。ですから、それをIT化しているから高度なプロセスであるというのも一概には言えないわけです。ホワイトボードとメールで仕事していても良いプロセスということだってありえます。

システム化のアプローチとして、最初に新しい業務プロセスを開発するのを目的化するのではなく、あくまで、自分たちのビジネスをオペレーションするためにはどんなプロセスになっているのがよいのかの観点でプロセスを記述することです。そこから、さまざまな問題が浮かび上がってきます。

個人の裁量で進めていたり、お客さんを無視して自分たちの都合だけで処理していたり、時間がかかっても平気だったり、ルールに従わなかったりといったプロセスの仕組みというより、プロセスを進めるための仕掛けのところの不備だとかが問題になってくる。こうしたプロセス管理に不可欠な組織能力をどう醸成していくかが大きいような気がします。

広義の意味ではこれもプロセスとも言えるのですが、フロー的な部分よりもこちらのほうが開発要素が多くあるのではないでしょうか。例えば多く見受けられるのはルールの欠如と役割の不明確です。このことは、別な言い方だと業務フローを変えるのが業務プロセスを開発することだとは必ずしも言えないのです。ルールがない中で業務フローを変えても意味がないのです。今回はプロセスとはが頭に入っていないとちょっとわかりづらかったかもしれませんね。