■    いったい何を定義したら設計されたことになるのか

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

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

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

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

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

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

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


No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/82

Leave a comment