コンポーネント化
プロセスができたら、そこから機能（プロセスまで含む場合もある）をカプセル化して、コンポーネントを作成していく。まず、コンポーネントの分類と粒度ということから考えていこう。
業務プロセスは、業務サービス―業務コンポーネント―システム機能コンポーネントから成り立っていると考える。例えば、「販売管理」で「受注」～「代金回収」までのプロセスを考えると、そこには「出荷」という業務サービス（この単位でコンポーネントとしてもかまわない）があり、そのなかの「出荷指示」というアクティビティが業務コンポーネントになる。
一方、認証だとか帳票やコード変換といったシステム的な機能については、システム機能コンポーネントとして括り、共通部品的な使い方となる。もう少し、例示的言うと、
・業務サービス ：見積り、受注、発注、与信、クレーム処理、出金伝票承認・・・
・業務コンポーネント ：受注受付、在庫引当、検収、見積査定、出荷指示・・・
・システムコンポーネント：カレンダー管理、データ集配信、ロール管理、メール・・・
これらの粒度でコンポーネント化をしていきます。コンポーネント化は、MVC（model/view/control）モデルをベースにして行ないます。また、当然データベースがきちんと構築されているという前提です。ただし粒度については、これでは大雑把すぎますので、作業者がひとりで行える単位にするとか後続機能に後処理を依存させない単位にするだとかの基準は設ける必要があります。
ちなみに、大和総研の池田大造氏は、コンポーネント化の指針で、分割基準として、「最小構成単位」と「機能的な完結」，「コンポーネント構造」をあげていて、その中の「最小構成単位」でつぎのように言っています。
複数のアプリケーションを集めたコンポーネントの最小構成単位は，ビジネスで扱う人や物など「もの」として定義された対象物（エンティティ）の生 成から消滅までにしている。例えば債権についてのコンポーネントは，債権の発生から消滅に関する更新要求や参照要求への対応，ビジネスロジック（債権充 当，充当修正，滞納判定，滞納情報作成，滞納解消情報作成，回収代行債権返戻情報作成など），コンポーネント外部とのインタフェースを制御するデータ変換 部分を対象とする。コンポーネントは，情報として管理するものの最小単位ともいえる。
また、何でもかんでもコンポーネント化すればいいというものではなく、なかにはコンポーネント化に向かない機能もあるので、そういうものは無理してコンポーネントにしたところで再利用もされないわけなのであきらめます。例えば、スタッフの不定形作業なんていうのは難しいのではないでしょうか。
こうして作られたコンポーネントをライブラリーに格納して使い回していきます。
さて、このコンポーネントすなわち業務モデルは標準業務モデルであるのかという問題がある。前にも書いたが、標準化では、内なる標準化と外なる標準化という表現をした。内なる標準化というのはいわば社内標準であって、支店や営業所でまちまちであった処理慣習などを標準のものにすることである。一方外なる標準というのは、業界標準であるのかとかグローバルな目でみたとき固有性が排除されているのかといったことになる。
おそらく、業務コンポーネントのレベルでは、自社固有の部分は少なく、業務サービスのレベルで固有性が現れるのではないかと筆者は考える。従って、業界あるいは一般的に業務コンポーネントを共通利用するのは可能であるように思える。ですから、業務サービスはこの業務コンポーネントの集合ですから、その組み合わせで“クセ”が出ると考えられないか。このことは、逆に差別化する源泉でもあるわけで、他社と比べて違った業務サービスを持っていることが事業上で有利になるとも言える。「組合わせの妙」ということだ。
さて、業務サービスという言葉で言ったようにこのレベルでひとかたまりにして大きな粒度のコンポーネントにしてもかまわない。だから、狭義のERPや業務パッケージもコンポーネントと考えてもいいと思う。その場合は、カスタマイズやアドオンがほとんどないという前提での話しだが。
さらに、そうしたサービスを自分たちで作るのではなく外部から持ってくることも可能だ。例えば、与信管理のサービスを外部の信用調査会社のサービスを利用するとか、最近では福利厚生関連の多くは外部サービス化している。
次回にこうしてできたコンポーネントあるいは外部サービスを使ってシステム開発する「コンポーネント開発」について論ずる。