「業務と情報システムは整合していますか？（２）」

　前号では、整合しているとはどういう状態を指すのかについて概観し、業務と情報システムが整合していることの重要性を確認しました。
　本号では、業務と情報システムとの整合の度合いを比較的簡単に推し量るための方法を注意点とともに紹介します。

１．基本アプローチ

　これから紹介する、業務と情報システムとの整合の度合いを比較的簡単に推し量るための方法（以降、簡易手法と呼びます）は、既存システムの構造を「標準業務モデル」(※)と照らし合わせ、システムの機能配置を可視化することで業務と適合していない可能性が高い機能を効率的に抽出することを基本アプローチとしています。

　　　※標準業務モデル：

　業種によらず業務の体系を階層構造で整理したもの。
　米国発のものとしてはAPQC（米国生産性本部）のプロセス分類フレームワークやサプライチェーンカウンシルによるSCOR(Supply Chain Operation Reference model)などがあるが、日本のものとしては、2004年末に日本政府が採用したEA(Enterprise Architecture)のなかで使われた技法・方法論をとりまとめたTENOHA（Total Empowerment New Open Holonic Approach)において紹介されている。

　なお、業務構造そのもの良し悪しを抽出しようとするものではないことに注意をお願いしたいと思います。

２. 簡易手法

　以降に順を追って紹介していきます。

（１）既存システムの機能構造の整理

　既存システムの構造と機能との関係を機能構成図（DMM）に整理します。機能構成図（DMM）とは、業務機能を階層的に3×3のマトリクスで示し、業務・システムの対象範囲を明らかにしたものですが[1]、これを活用し整理します。イメージをつかんでもらうために、下図に一部例示します。

図１　既存システムの構造整理結果

　これは、筆者の知る製造業のSCMシステムの機能構造をもとに、手法を分かりやすくするために筆者が販売機能に着目して再構成したものです。ここでは割愛していますが、実際には「3.2.受注」を中心とするマトリクスにシステム機能が配置されることになります。
　なお、DMMにより整理することは、基幹システムの間取りと機能の配置とを階層的に視覚化することでもあります。システムの保守性向上にも有効と考えますので是非この機会に整理してみてはいかがと思います。

（２）標準業務モデルとの比較

　次に、標準業務モデルとの比較ステップを説明します。比較ステップは三つで構成されており各ステップにおける注意点とともに紹介していきます。

ステップ１：サブシステムと業務プロセス（Level-1）との対応付け

まずは、システムの間取りを構成するサブシステムが標準業務モデルのどの業務プロセス（枠組み）に相当するのかを突き止めることから開始します。これは、例えば、販売業務を支援するためのシステム機能の集合が販売サブシステムである、という考えに立っています。

ここで最初に問題となることは、対象業務の名称が、都合よく標準業務モデルの名称と一致するとは限らない、ということです。これは、標準業務モデルが標準であるがゆえに抽象度の高い名称が付与されているためと考えられます。 　そこで、サブシステムが支援する業務機能の目的や役割と標準業務モデルにおける業務機能の目的や役割を比較することで対応関係を明確にしていきます。

図２　Level-1業務プロセスの対応付け

ステップ２：サブ機能と業務機能（Level-2）との比較

次にサブシステムを構成するサブ機能レベルの比較に入ります。業務機能、システム機能双方を、各々の目的や役割のレベルで比較する点はステップ１と同様の考えです。

図３　Level-2業務機能の比較

名称レベルで単純比較してみると、販売サブシステムを構成するサブ機能と標準業務モデルの販売業務を構成する業務機能との間には、見た目だけでも次の違いがあることがわかります。
・	販売サブシステムには「引合」、「納期回答」、「部材支給」が存在するが、標準業務モデルの販売業務機能には存在しない。
・	標準業務モデルの販売業務機能には「請求」や「回収」などのカネ系の機能が存在するが、販売サブシステムには存在しない。
など。

販売サブシステムのスコープが標準業務モデルより狭い場合があり、このような場合、サブシステムで実現している機能群が標準業務モデルの一段下の階層に対応していることがあるため注意が必要になります。

ステップ３：個々の機能と業務機能（Level-3）との比較

サブ機能を構成する個々の機能についてステップ２と同様のステップを繰り返します。下位レベルに行くほど個別性が高まるため、目的や役割に則した対応付けという抽象化の工数がかさみだしますが、それでも全体を精緻に分析するよりはるかに短い工数で整合の度合いを推し量ることが可能だと考えています。 　ここでの注意としては、個々の機能の下位レベルに踏み込まないことです。というのも、個々の機能の下位レベルは、もはやソフトウェアコンポーネントのレベルと同じであるため、このレベルまで立ち入ると（前号でも述べたとおり）大変な労力とコストが掛かり費用対効果の保証もないためです。

（３）比較結果のまとめ

　(1)(2)の作業を通して、差異が判明した「引合」、「納期回答」、「部材支給」などが業務と整合していないと可能性がある機能候補ということになります。
　(2)のステップ２でも述べましたが、「引合」、「納期回答」は、図3の標準業務モデルにおける「受注」のサブ機能に含まれていますので、結果的には「部材支給」が業務と不整合の可能性が高い機能という結果が得られたことになります。

３．まとめ

　本号では、整合の度合いを比較的簡単に推し量るための方法を紹介しましたがいかがでしたでしょうか。
　簡易手法により、業務と整合しておらず改善が必要と考えられる機能が得られました。一方で、現在のシステムの機能配置は、業務分担やシステムの非機能要件、あるいは競争力向上を狙った結果であることも十分考えられます。このため、得られた差異の理由を明らかにしておくことが重要となります。理由を明らかにしないままに安易にシステム改修を行うと業務効率の低下や延いては競争力の低下を招きかねないためです。
　そこで、次号では、差異理由から再配置を検討する過程を簡単に紹介できればと考えています。

（参考文献）
[1]経済産業省 EAポータル

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。