4.ゆるやかな標準の使い方

業務を具体化し実装するには

あらかじめ想定していた業務シナリオあるいはシーンが見つかったとします。このとき、(1)そのような業務の流れが実現できていない場合、あるいは、(2)そのような業務の流れはあるが、IT化できていない、あるいは、(3)そのような業務の流れは自社には向いていない、の3つのパターンに分かれるでしょう。ここでは、そのような業務はすでにできている企業は対象外としています。

ここでは、(1)のパターンと、(2)のパターンについて考えます。一般に(1)の場合は、IT以前の問題であり、「業務をカイゼンしてからはじめてIT化しなさい」といったことがよく言われますが、現実には、ITの助けなしには業務のカイゼン、効率化は不可能です。したがって、このようなケースでは、業務の流れを、データ化することで向上するところを見つけ、そのようなボトルネックとなる箇所から順にIT化していくほうがうまくいきます。

これは、(2)のパターン、つまり業務の流れはあるのだが、IT化できていない場合にも共通しています。では、具体的にIT化していくときに、やらなければならないことは何でしょうか？　決してIT企業に“丸投げ”してはなりません。それぞれの業務におけるアクティビティを記述し、そこで必要となるドキュメントの形式、オブジェクトの形式（具体的にはデータ項目）を決めるのは業務を知った現場の担当者または管理者です。

標準的な業務であればそれに従う

仮に該当する業務シナリオやシーン、そして業務アクティビティがあったとしても、それを自社の個別の業務に適用しようとすると、いろいろな部分で違いが出てきます。A部門とB部門、あるいはA工場とB工場といった企業内で仕事のやり方やデータ形式などが異なっている場合は共通化することは当然のことですが、IVIのリファレンスモデルとそれが異なっている場合はどうしたらいいでしょうか？　厳格な標準の場合は、外部の企業や顧客とつながるために無理やり標準にあわせることになりますが、IVIでは、リファレンスモデルをベースとして、個別の企業ごとに修正して使うことを奨励しています。

ただし、この際に重要なことは、リファレンスモデルにあるアクティビティやオブジェクトに対して、どこをどのように修正したのかを、きちんと後でわかるようにしておくことです。これがないと、結局、外部の企業や顧客とつながることができなくなるか、あるいは膨大なコストを負担することになります。こうした、差分（変更点）を記録しておくことで、ケース・バイ・ケースで、他社ともつながり、かつ自社のこれまでのやり方を踏襲し強みにしていくことができるようになります。

一方、あえて、現場に無理を強いてリファレンスモデルに合わせる方法もあります。これは、そのリファレンスモデルが、すでに多くの企業の現場で用いられている場合、つまりすでに競争領域ではなくなっている場合です。このようなケースでは、リファレンスモデルに合わせることで、安価は業務ソフトウェアの調達が可能となり、またカイゼン等の事例やコンサルティング事例なども多くの情報の中から収集することが可能となるというメリットがあります。

ワーキング・グループの位置づけ

では、参考となる業務シナリオやシーン、そしてアクティビティやオブジェクトが見つからない場合はどうしたらよいでしょうか？　IVI設立当初は、このようなケースが多いでしょう。そうした場合は、自社の状況、自部門の課題などに関して、似た問題意識をもって活動しているワーキング・グループに参加してください。ワーキング・グループは、最終的に、リファレンスモデルを定義し登録することが一つのゴールとなりますが、その前に、メンバーがそれぞれもっている課題を解決するためのメンバー個々のモデルを得るために活動をしています。

言い換えれば、IVIに登録されたリファレンスモデルは、こうした個々の事情や背景を捨象したものであり、実は学ぶべきところは、その前のよりリアルなモデルであったりします。したがって、できあがったリファレンスモデルをただ利用するのと、リファレンスモデルを作り上げるプロセスを共有するのでは、得られる情報は比較にならないほど違いがあります。なお、ワーキング・グループは、メンバーはだれでも新規に設置を提案することができますので、あえて、課題を異なる企業のメンバーと議論しながら、既存のリファレンスモデルをもとに、新たにまとめていくことも重要なプロセスであるといえます。