March 2013 Archives

■    プロセス要素の定義

具体的なプロセス要素の定義をみていきましょう。コアのデータ確定というのは意思決定の典型的なものですよね。例えば提供商品名を決めるとか、納期を確定するなんてことになります。確定するデータがどんなものなのか、どういった判断をすることなのかが決まるとそういった意思決定に必要な"もの"や"こと"をプロセス要素として定義していきます。

確定データは基本的にひとつなのですが、現実的には複数になることもあるし、補足するべき情報として登録したいものが出てきます。このあとのほうで言っているものが「付帯登録情報」です。例えば、納期が確定データだとそれに付随する納入条件といったものはこうした付帯情報として定義しておくということです。

意思決定というのは、単に誰かが勝手に決めることもでき、よく言えばと裁量ということになるのですが、往々にして属人的な決定プロセスになってしまい、人が変わると決定の仕方も変わってしまうことになります。ですから正常な組織ではそうした属人性をできるだけ排除すべく取り決めをすることになります。それが業務ルールです。実際にプロセス設計をしていくとルールがない状態が多いことに気づくと思います。ただルールといってもきちんとルールブックに記述していなくてもよくて、組織構成員で共有されていればよいと考えても構わないでしょう。

業務ルールには、規程・基準・規則・ガイドラインといった様々な名前がつけられていますがあまりこだわる必要がないと思っています。そこをきちんとしようというとルール体系を作りましょうとなるわけですが必ず失敗します。重要なことは、プロセスの意思決定のために使うルールは何かというアプローチでルールを定義することです。そのルールがどんなプロセスのどの場面で使われるかに紐づいていないと意味がないということなのです。ですから、ルールマネジメントというのは必ずプロセスに従属的にやるべきことなのです。

意思決定には情報を参照して行うという側面もあります。その参考とする情報にはどんな種類のものがるのかというと、事実情報、判断情報、制約情報の3種類です。業務ルールも参照情報の判断情報一種ですが重要なので抜き出しでおきます。事実情報には、マスタ、販売実績のような履歴情報、予算といった計画情報、競合他社情報といった外部環境情報などがあります。

判断情報には、業務ルールの他にリソース状況のようなものがあります。例えば担当者を指名する場合に要員の稼働スケジュールをみるなんてことをするわけです。また、ちょっとした計算だとかシミュレーションをした結果から何かを判断する場合もあります。さらに帝国データバンクに与信チェックをしてもらうような外部サービス情報なんてこともあります。制約情報は、契約・規約、制約条件、コンプライアンスといったものから得る情報になります。

次はロールです。ロールはプロセスの意思決定に関係する役割のことです。例えば、起案、確認、承認といった役割を誰にやらせるかになります。一番重要なのはだれが最終的にその意思決定に責任を持つのかです。すなわち、承認者は部長なのか課長なのかといったことを定義することです。業務プロセスでは、基本的にはプロセス全体の責任者と単位意思決定の責任者という階層を持ちます。このあたりも今は曖昧になっているケースをよく見かけます。

最後に「パフォーマンス管理指標」についてですが、プロセス制御という考え方からいうと何か変な方向に向かいそうになるとそれを戻すような動きをすることが大事です。その変な方向なのかを測定する指標のことです。ですから、測定対象となる変数とその正しい設定値と異常を検知した場合の知らせ方と戻し方を定義することになります。例えば、見積提出期限というものを制御するとします。測定対象は見積書作成日となり、設定値は提出期限の一週間前で、それを超えたらすぐに作成担当者にメール通知機能を使って早期作成を促すメッセージを送るといった具合に定義します。

まだ、多少定義したほうがよい項目もありますが基本的にはこうしたここにあげた要素を定義すると設計が完了します。
■    いったい何を定義したら設計されたことになるのか

こうした議論で設計というといわゆるITシステムの設計というふうに捉えられがちである。そうなると、(1)要件定義 (2)外部設計 (3)内部設計とか、あるいは(2)(3)を概要設計、詳細設計と呼んだりします。まずシステム要件を定義して、それに従って、システム機能設計、具体的には、画面設計、帳票(レポート)設計、データベース設計などを行い、そこで決まった機能をプログラムレベルに落とした設計を行うというわけです。

ところがここでは、"ビジネスサービスの提供プロセス"を設計することですから、ITシステム設計とは異なることがおわかりになるとい思います。画面や帳票、データベースを設計することはもちろん必要ですが、それは一部といった側面しかないように思えます。この章の最初に言ったようにサービスとは「提供者が受給者の望む状態変化を引き起こす行為」であるから、そのための構造や機能を設計することになります。

つまり、"受給者の望む"ことが何なのか、そのリクエストに対して、どうやって応えていくのか、その結果として"受給者が満足してくれる"かという一連のプロセスを設計することが大事なのです。しかも、それはただ格好を作るだけではなく継続的に使い続けることを考慮したものでなければいけないのです。そうなると、プロセスをオペレーションするために必要な機能から発想したらどうでしょうか。これも一種の要件定義ですが、システムにとっての要件ではなく、サービス提供プロセスとしての要件ということになります。

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

これらは、サービスを提供するプロセスの機能概要ということになります。次にこうした要求機能を実現するためにプロセスを構成する要素が必要になってきます。プロセスというのは、始点と終点があってその間に複数のアクティビティがあるもので、アクティビティというのは単位意思決定を伴うものです。単位意思決定というのはさらに具体的に言うと、データを確定すること(文書も含む)、判断をすることです。

さて標題の「いったい何を定義したら設計されたことになるのか」ということになりますが、まずはコアで必須の要素である「確定するデータは何か、どんな判断をするのか」を定義します。プロセス設計というと順序性を重視してフローの定義を一生懸命しますが、サービスプロセスはそれほど厳密ではなくてもかまいません。サービスの順番ってきちっと決められたものではありませんよね。お客さんによっては順番を変えたりすることもあるからです。ですから、おおよその順番で並べておきます。

次に、各アクティビティ(単位意思決定=データ確定・判断)で必要なプロセス要素を定義します。「付帯登録情報」「業務ルール」「参照情報」「ロール」「パフォーマンス管理指標」「分岐先・連携先」といったものになります。この段階でIT的な設計がないのがおわかりだと思いますが、基本的にはプログラミングしてスクラッチで開発することは考えていないからです。つまり、市販ソフトウエアを利用するのでそこに内包している機能を使えばよいからです。
 


■    いきなりToBeを書く

プロセス設計というと普通は現状分析をしてAsIsとして書き出して、それをいろいろな角度から分析して、見直しをして、変えるところを見つけ出し追加・削除・変更を施してToBeにする。これって、ちょっと変だと思いませんか。AsIsに問題があるから、直そうとしているのにAsIsをベースにしているわけです。そこでは、どうしても現在の延長線すなわち連続的な思考になり、少なくともイノベーティブなものは出てきそうもないですよね。

だから、そんなことをする必要があるのかということです。もちろん、業務プロセスは現状にないわけではなく、現にビジネスをやっている限りどんな企業でも必ずあります。それならその業務プロセスがAsIsではないのかという指摘もあろうかと思います。問題は、ほとんどの場合、AsIsのプロセスを書いていますといっても業務分析、作業手順になってしまっているから意味がないと言っているのです。

業務体系表に従って、組織のそして個人のタスクを書き出すわけです。それって、組織や人の仕事を解析するのであって、改革とかビジネスモデル変更要求引き出しとかいった動きとは別です。重要なのは、今やっている事業にとってどういう業務プロセスだとビジネスの要請から持ち込まれる要求を実現できるかである。設計とは、そういった業務プロセスを設計することです。

ですから、設計アプローチは現状がどうのというよりToBeをいきなり設計するという感じにならざるを得ないのです。つまり、これも何度も言っているのですが、組織と人から離れて、かつITシステとも無関係に俯瞰的な目線で書き出しましょうと言っているわけで、そうなるとほぼ必要なプロセスは決まってきます。このプロセス(まだフローを主体にしたもの)はすでにToBeというわけです。

さらに、そのプロセスに必要な要素を当てはめていくことで全体としてのToBeになります。ただ、ここで気をつけなくてはいけないのが、ToBeのレベルのことである。本当に理想的なものといったら技術的に難しかったり、リソースが不足していたりということは往々にしてありますし、経済合理性がない場合もあります。ですから、ToBeという言い方がよくないのかもしれません。ベストは難しいのです。

会社の成熟度に応じた、その時点で採れる最適な形態をToBeというふうに定義したほうがよいと思う。現有する経営資源のもとで当該ビジネスの執行にもっともよい業務プロセスを現状からではなく、ビジネス起点で書いてみるというのが最も簡潔で分かり安いアプローチだと思うのです。いきなりToBeを書こうというよりも、ビジネス起点で書き出すと自ずとToBeを書く事と同じになってしまうと言ったほうが適切なのかもしれませんね。