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

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

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

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


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

今回からは、実際にプロセスをどう設計していくかというお話になります。

2. プロセスデザインの進め方  
(1) 対象プロセスの特定
「特注品で新分野を開拓し売上げ・利益をのばす」という戦略に対して「ベテランの営業に依存しない要求確認」「収益性を確保した見積」「役割分担の明確化」といった課題が抽出されました。

特注品だと顧客がどんなものを望んでいるのかをきちんと把握する必要があります。しかし、これはある程度の経験やノウハウがないと難しいのでどうしてもベテランの営業にたよってしまいます。若手でも的確な要求確認ができるような仕組みが要るなあということになります。また、原価を計算しないで要求通り作ってみたら赤字だったなどということも出てきます。特注品は粗々の設計をしますから、顧客要求に対する設計の関わり方も問題になってきます。

こうした問題点をみていくと、最も優先して整備すべきものは何かが見えてきて、それが「見積提示プロセス」であると結論付けました。このように、戦略からそれを実現するための阻害要因を検討し、課題化したものを解決するための狙い所のプロセスを特定していったのです。いきなりこのプロセスにBPMを適用してみましょうといった取組を見聞きすることもあるのですが、単に効率化の手段としてという意味は多少はあるかもしれませんが、大事なことは、戦略とか事業方針といったものとの連動性を持ったBPM適用が効果的です。

さらに、その後特注品という新規商品へシフトしても既存顧客の範囲では限界が出てきて売上げの伸びが止まったため、(STEPⅠ)顧客の範囲を拡大した新たなビジネスモデルを設定し、それを実行するために営業プロセスの中の別のプロセスである「プロモーションプロセス」を対象としたBPMを実行しました。(STEPⅡ)
  

このように、BPMをいきなりプロセス設計や実装から入ってしまうのではなく、新しい戦略に沿ったビジネスモデルからBPMを適用すべきプロセスを選定していくアプローチが大事になってきます。つまり、ビジネス上の要求の受け皿としてプロセスがあるということなのです。
 
【成功のポイント】
ビジネスモデルに戦略や課題を記述して、そこを起点としてプロセスにマッピングすること

  

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

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

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

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

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

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

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

(4)期待と効果
BPMに何を期待するのでしょうか。その期待に既存の手段では応えられなかったからBPMに期待するのでしょうか。もし、このあたりが明確になっていて、効果が実感できれば、今頃は大ブームになっているはずです。ところが、徐々に浸透してきているとはいえまだまだのようです。ということは、期待するところがないのか、期待することはあるのだがBPMではできそうもないと思っているのかのどちらかなのでしょう。

おそらく今の経営者は期待するところというか、自分たちを取り巻く環境の変化に対して臨機応変に手を打っていかないと持続的な発展どころか事業の継続さえ危なくなるという危機感は持っていると思います。ですから、俊敏にかつ的確に経営の舵取りができる仕組みと仕掛けを期待しているはずです。

そうした期待をかつてはERPやCRMなどに求めたと思いますが無理だったというのが定まりつつあると思っています。ただ、まだまだERPを入れればプロセス改革ができると思っている人もいるように、大金をかけた割には効果がないと分かっていながら、ではどうしたらいいのかと悩んでいるのかもしれません。そうした人たちがそこはBPMだとなぜ飛びつかないのでしょうか。

プロモーションの不足といえばそうなのだが、難しいのは、これこれの問題があるからそれを解決するものとしてBPMがあるといった単純さで訴求できないところがあることです。たとえば、在庫が多いからそれを削減するために在庫管理システムを作ろうといった場合などはわかりやすいのですが、BPMと在庫削減が結びつかないと言われてしまうのです。

つまり、BPMというのは大前提が"ビジネス(事業)全体のプロセスを記述する"ということなのですが、そこがなかなか始められないのです。大前提という意味は、プロセスを書くことで自分たちのやっている事業がいったいどんなものなのか、どんなことをしているのかが俯瞰できるからなのです。すべてはそこから始まるのです。先ほどの在庫の問題にしても単に在庫の部分だけを見ていては、真の原因を見損なってしまうこともありえるのです。

自分たちの事業をプロセスという姿で掌中に納めれば、そこにどんな問題が潜んでいるのか、こういう戦略を実行するにはどこのプロセス改革を行えばいいのかがわかるようになります。これがBPMに期待する大きな理由です。ただ、いま言ったように直接的な問題解決にすぐにいけないので、"せっかち"な経営者になかなか理解してもらえないのかもしれません。

BPMのプロセスを記述して俯瞰して見るということは多くの効果をもたらします。本事例でも、まずプロセスを書いてそれを皆で眺めているとさまざま問題点や課題が浮かんできました。というのも、プロセスというのは多くの要素から成り立っていますから、どの要素に問題があるのかがわかるわけです。業務ルールの不備で混乱しているとか、責任の所在がはっきりしていないとか、同じような仕事を重複してやっているといったようなものが抽出され、そこを改善することで多面的な成果が生まれてきます。成果の主なものは次の3点でした。

事業成果の実現
人材育成、組織能力の向上
IT投資の低減

事業成果の実現では、当初の狙いが、標準品から特注品にシフトして売上を増加させることでしたが、それは特注品の売上を前年比でほぼ倍増させることができて成果を確認できたのですが、予想外というかうれしい誤算だったのが②の人材育成、組織能力の向上という成果です。

え、BPMで人材育成、組織能力の向上?と思われるかもしれませんが、実際に成果が上がったことです。プロセスで自分たちの業務も捉えるわけですから、自分が何をすべきか、他の人が何をやっているのかが見えてきます。そうすると、チームで働くことの意義を自覚でき、結果的に組織能力も向上し、人が育つことにつながるのです。

【成功のポイント】
ビジネス成果を得るには自分たちのビジネスプロセスを手のひらに乗せること、またBPMの大きなメリットである人材育成・組織能力の向上には、多くの人を参加させて大いに議論し成果を共有できる体制をとること
  

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

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

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

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

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

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

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



Find recent content on the main index or look in the archives to find all content.

Recent Assets

  • 2013-04-02 22.12.29.jpg
  • 2013-03-29 18.28.05.jpg
  • 2013-03-29 18.45.02.jpg
  • 2014-10-26 12.24.58.jpg
  • フォーム設定.JPG
  • portal.JPG
  • ProcessElment.jpg
  • 構成バリエーション.JPG
  • プロセス構成.JPG
  • BMC.png

Pages

Powered by Movable Type 4.34-en