問題１：開発期間
　ＳＣＭ展開のために情報システムの開発が必要になる場合があります。業務サイクルや部門間・企業間・顧客との間のコミュニケーションのスピードを上げようとすると、情報システムの構築あるいは再編が有効な手段となります。しかし情報システムの構築は、１年、２年と年単位でかかる場合があり、これが改革のスピードを鈍らせます。ＩＴの世界はドッグイヤーと呼ばれ、技術の進展は早いのですが、情報システムの開発期間はなかなか縮まらないようです。

対策１：パッケージの利用
　情報システムの開発期間短縮にはＥＲＰなどパッケージプログラムを利用するのが有効です。しかし、パッケージで想定している業務と自社の業務にギャップがある時にはどうしたらいいのでしょうか？通常、カスタマイズすることによって情報システムを業務に合わせるか、業務をパッケージに合わせることになります。しかしながら、カスタマイズが多くなると、開発期間や開発費がかさみます。業務をパッケージに合わせるのも抵抗が多いでしょう。

　パッケージと業務にギャップがある場合、その部分のパッケージ機能を導入しないという選択肢もあります。情報システム導入が目的ではありません。情報の加工やコミュニケーションのサイクルを上げることが目的です。ギャップのある業務が、スピードのボトルネックになっていない場合には、その部分には導入しないという作戦です。自社の業務の構造と特性を良く知り、情報スピードのボトルネック・パッケージとのギャップを見極めることが重要です。

問題２：品目コード
　異なる情報システム間のデータ交換に人手がかかっているケースがよくあります。人手がかかっても、スピードのボトルネックになっていないことが多いようです。ボトルネックは、データ交換よりも計画や調達など意思決定が伴う業務のサイクルです。しかしながら、意思決定のサイクルを速くした場合や、データ交換にかかっている人手を減らそうとした場合には、その自動化が必要になります。

　製造業の情報システムが交換するデータは、モノに係るものが主役です。人手がかかるのはデータ変換ですが、変換する上で障害になるのが品目コードです。品目コードが違っても１：１で変換できる対応表があればまだ良いほうです。１：NあるいはN：Mの関係に対応する時には、人間が介入して判断することになります。品目コードの違いは、企業間でデータ交換するときに必ず発生します。また企業内でも営業・生産・開発・会計の情報システムの間で異なる場合もあります。

対策２：コード体系見直し
　対策はコード体系の変更しかありません。少なくとも企業内では統一する必要があります。さらにグループ企業内や他社と１：１で対応できるコード体系にしていくべきです。ＪＡＮコードなど、世間の標準コードとも対応がつく体系が必要です。また、長期的な多品種化の動向を踏まえて、ケタ数には余裕をみることも必要でしょう。

　これには複数の情報システムが関係します。開発期間を短縮したいところですが、相応に時間がかかります。ＳＣＭを推進するしないにかかわらず、情報システムを利用する基盤として長期的な観点から整備を進めることが必須でしょう。

問題３：プラットホーム選択
　コンピュータシステムの処理構成は多様化しています。企業の基幹業務に使われるコンピュータシステムなら、昔はメインフレームでCOBOLプログラムを集中処理する構成が大部分だったでしょう。しかし現在では、そのOSや言語の選択肢は多岐にわたります。データベースマネジメントシステム（ＤＢＭＳ）やミドルウエアと呼ばれるソフトウエア製品は多数存在します。通信プロトコルだけは、ＳＮＡとＴＣＰ／ＩＰに集約されるでしょう。

　どの処理構成を選択しても、企業の基幹システムは構築できるようになっています。問題は、構築してからしばらくして、アプリケーションソフトの追加や、老朽化したハードウエアを更新する時に発生します。これはＳＣＭに関するシステムだけの話ではありません。企業の基幹システム全般に発生することです。問題は、アプリケーションソフトの移植性です。

　例えば老朽化したハードウエアを更新したとしましょう。ハードを更新するとＯＳを最新バージョンにしなければならない場合が多いようです。古いバージョンでは、新しいハードウエアに対応できないことがあるからです。ＯＳをバージョンアップすると、言語やＤＢＭＳも新しいバージョンに変更せざるを得なくなります。これらをバージョンアップするとアプリケーションソフトも作り変えなければならなくなります。アプリケーションソフトの移植性が低いものほど、作り変えなければならない部分が多くなります。こうした問題が発生すると、多大な時間と費用が必要になります。

　 対策３：国際標準の採用
　対策は、移植性の高いプラットホームを選択することです。特に国際的に標準化が進んでいるものを選択すれば、長期的な移植性が確保できる可能性が高くなるでしょう。オープン性を重視すれば、通信プロトコルはＴＣＰ／ＩＰ、ＯＳはＵＮＩＸとなるでしょう。アプリケーション言語はＣかＪＡＶＡが有力な候補です。

　データベースソフトは、国際標準と呼べるものがありません。リレーショナルモデルに基づくデータベースで、デファクトスタンダードになっているものを選択することになるでしょう。ただし、データベースソフトは、その製品固有の機能を使うと移植性が下がります。アプリケーションプログラムを記述する時に、標準的なＳＱＬだけを使うように制限したほうが良いでしょう。

　画面表示はHTMLをｗｅｂブラウザで表示する方式が主流となりそうです。データ交換はＸＭＬを利用する場合が多くなるでしょう。

問題４：ネットワークセキュリティ
　ＳＣＭを推進していくと、当然ながら企業内外でデータ交換が増加します。通信ネットワークの整備が必要です。現在はインターネットがその基盤となるでしょう。インターネットで全世界とネットワーキングすると、問題視されるのがセキュリティです。

　セキュリティ上の被害としては、データの漏洩・データの改ざん・システムの破壊に大別されるでしょう。その原因としては、外部から企業内システムへの侵入・コンピュータウイルス・インターネット上での漏洩・企業内部者の犯行などがあります。対策は、パスワード・個人認証・ファイアウオール・暗号化などがあります。

　考えられるあらゆる原因に対して対策を網羅しようとすると、そのコストは膨大なものになります。支払費用だけでなく、セキュリティ対策を運用する手間や、対策したためにシステムのレスポンスが悪化したり、そのために日常業務に支障をきたすことがあります。セキュリティの問題とは、データ漏洩などの被害よりも、むしろ対策コストにあります。

対策４：リスク評価
　あらゆる対策を網羅するとコストが増加する一方です。まず、想定されるリスクについて、その可能性と影響を正しく評価することが必要でしょう。データの漏洩・データの改ざん・システムの破壊といった被害も、その対象によって企業活動に与える影響は違ってきます。例えばデータの漏洩なら、開発中の新製品の仕様に関するデータと、量産品の部品注文データでは、漏洩した時の影響が違うはずです。

　リスクの発生可能性については、コンピュータネットワーク上だけでなく、紙やＦＡＸなどの媒体に対しても検討する必要があるでしょう。コンピュータ上にあるデータよりも紙に印刷されたデータのほうが漏洩・改ざん・紛失の可能性が高い場合も多いものです。発生原因も企業外部だけでなく内部犯行についても検討する必要があります。

　リスクの発生可能性と影響を評価したうえで、対策を重点的に実施します。暗号化といった技術的な対策だけではありません。利用者の教育、セキュリティに関する規定や罰則の整備といった人的要因に関する対策も必要でしょう。