納期半減の生産清流化

業務と組織の変革で、しなやかな企業体質を創ります。

トップページ

アルビスについて

業務一流化

組織自律化

情報清流化

見積清流化

資料室

リンク

お問合わせ

製造企業のデリバリー管理とSCM
第2章 サプライチェーンマネジメントの実践
2.4 SCM展開上の問題と対策
 (6)情報システムの問題

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

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

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

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

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

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

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

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

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

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

  対策3:国際標準の採用
 対策は、移植性の高いプラットホームを選択することです。特に国際的に標準化が進んでいるものを選択すれば、長期的な移植性が確保できる可能性が高くなるでしょう。オープン性を重視すれば、通信プロトコルはTCP/IP、OSはUNIXとなるでしょう。アプリケーション言語はCかJAVAが有力な候補です。

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

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

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

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

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

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

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

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

<前のページ      目次      次のページ>

トップページ

アルビスについて

業務一流化

組織自律化

情報清流化

見積清流化

資料室

リンク

お問合わせ

Copyright(C) 2004-2017 ALBS All Rights Reserved.  アルビス 神奈川県相模原市中央区矢部1-23-18 代表:若槻直