 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| はじめに | ||||||||||||
|
前回、ビジネス・プロセス・インテグレーション（BPI：Business Process Integration）は単なるシステム統合技術としてではなく、サービス・オリエンテッド・アーキテクチャ（SOA：Service Oriented Architecture）の中のコンポーネントとして位置づけることで企業戦略を支える重要な技術であることを解説した。 今回はBPIのためのソリューションがなぜ必要なのか、どのような意味を持つのかを具体的に説明していく。 |
||||||||||||
| BPIの特徴と要件 | ||||||||||||
|
まずはBPIの実行時における特徴を考えてみる。前回で、BPIを「複数システム間での処理を連携させて、プロセスとして統合することにより、ビジネス的に意味のある一連の作業の『End To End』での自動化を実現すること」と定義した。 これを「複数システムの連携」「ビジネス的に意味のある一連の作業の自動化」の2つに分けて考えていく。 |
||||||||||||
| 複数システムの連携 | ||||||||||||
|
従来、多くの業務システムは特定部門の業務を支援するよう設計・開発されてきた。単一のシステムで業務が完結するのであれば、それでだけ十分である。連携によってオーバーヘッドが発生することもなく、効率的に業務が行えるだろう。しかしながら、昨今のめまぐるしい経営環境の変化によって、業務システムに対する要求は多様化し、複数のシステムをまたがる業務が多く存在するようになってきている。このため、様々なシステム連携の仕組みが考えられてきた。人手による連携／バッチジョブ連携／EAIなどがあり本連載で解説するBPIもその1つである。 まずは複数システムの連携の要件として、連携するシステムのアーキテクチャおよびインターフェースの違いを吸収する必要がある。 今日、単一のシステムアーキテクチャで構成されたシステムしかない企業などはほとんどない。多くの企業が昔からのホスト系システムやオープン系のシステム、またはパッケージ製品などの様々なシステムを使って業務を行っている。一見、業務的には単一システムで行われているように見える場合でも、マスターデータは別のシステムと連携している場合が多いのである。 また、1つの組織の中のシステムだけでは終わらない業務も多数存在する。自身の組織内だけでなく他の会社（同じグループ会社、取引先の会社、アウトソーシング委託先の会社など）と連携することも少なくない。 このように違ったシステム間で連携するために必要な要件として、以下の項目をあげることができる。これらの各項目について、さらに詳しく考えていく。
|
||||||||||||
|
表1：システム間で連携するための必要な要件 |
||||||||||||
| データ変換・セマンティック変換 | ||||||||||||
|
お互いのシステムで理解できるようにデータを渡すためには、物理的なネットワークのレイヤーからプロトコル、セマンティックにいたるまでのすべてのデータが変換される必要がある。 これができて、はじめて意味のある処理が可能になるのである。特にBPIで重要となるのがセマンティック変換であるが、単純に相手のフォーマットに変換するだけのものから、変換テーブルが必要なもの、そのテーブルを自動的にメンテナンスする必要があるもの、などの要件が存在する。 例えば、システムAでは取引先の国をあらわすのに国番号として整数値を使用していて、システムBでは略字3文字で国をあらわしていたとする。この2つを変換するためには、国番号と略字3文字との変換テーブルが必要である。なぜなら、単純な規則だけであらわすことができないからである。ここで今まで取引したことのない国の取引先ができたとき、システムAに新しい国番号とシステムBに新しい略字3文字を追加した場合、変換テーブルも追加しないと新しい国に対して変換することはできない。このような変換の場合には、変換テーブルのメンテナンスという要件も必要なのである。 そして、このような変換の要件を解決するBPIシステムの機能として「データマッピング機能」がある。  図1：データマッピング機能の例
表2：データマッピング機能の例 また別の例として、システムAとシステムBとで顧客情報を管理していたとする。システムの中では一人の顧客を識別するのにキーがアサインされているが、一般的には別のシステムでは別のキーがアサインされている。先ほどの国の例と同じように、同じ顧客をシステムAとシステムBの間でキーの変換テーブルを使用すればシステムAとシステムBの変換ができる。 ここで先ほどと同じように新しい顧客を追加した場合を考えてみる。システムAに顧客を追加して、システムBにも顧客を追加する。これは変換テーブルもメンテナンスすれば変換可能である。しかし顧客の追加が頻繁に行われるとすると、その度にメンテナンスしていたのでは業務がまわらない。そもそもBPIを使って自動的に連携しようとしているのに、連携のためのメンテナンスが頻繁に発生してしまっては本末転倒である。 この問題を解決するためには、新しい顧客が追加された際に変換テーブルの追加も自動的にされればよい。また削除された場合にも変換テーブルの自動的な削除が必要になる。このような場合、変換テーブルの自動的なメンテナンスという要件も必要なのである。そして、このような要件を解決する機能として「リレーションシップ機能」がある。具体的には以下のようになる（図2、表3）。  図2：リレーションシップ機能の例 （画像をクリックすると別ウィンドウに拡大表示します）
表3：リレーションシップ機能の例 なお、これらの「データマッピング機能」や「リレーション機能」は、システム連携においてデータの差異を吸収するものであることから、両方まとめて「メディエーション機能」とも呼ばれている。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
