導入の経緯
新しい本支店営業所間のネットワークインフラを構築及び、10数年間利用していたオフコン上位クラス内の業務システムをオープンシステムへ全面的に刷新するとともに、情報系システムへのシームレスな連携を図る新基幹システムを構築開発しました。
対象業務
需要計画、物流、購買、生産計画、生産管理、在庫管理、販売管理、予算管理、部門会計、原価管理、支払管理、リース管理、本社会計、給与補助、その他約520機能
期間
約2年
費用
約2億5千万円
構成・開発環境
| 拠点間ネットワーク | インターネットVPN |
| データベース | OracleRAC |
| 開発言語 | VB6.0 |
| ミドルウェア | MetaFrameXP、デルバイforMetaFrame |
システム構成図
データが分散するホストコンピュータ
一般的な概念では、ホストコンピュータは集中型のシステムであり、パソコン系のシステムは分散型のシステムであるので、ホストコンピュータのほうがデータを一元管理しているイメージがありますが、現実的にはその逆の場合が多いのです。
お客様も長くホストコンピュータを利用していました。
しかし、結果的にはホストコンピュータが福岡本社と関東工場に各1セット、そして全国の支店営業所には営業所向けのシステムがパソコンベースで作成され、運用されていました。
当然それぞれに顧客データや販売データが存在し、夜間に整合性を取るという格好にならざるを得ず、非効率な運用を強いられていました。ホストコンピュータが持つ処理能力や通信機能の限界、システムやデータの流動性に欠ける構造によるものではありますが、ユーザの視点ではなく、システム販売側の理論を盾に、顧客に適切な提案をしてこなかったメーカーの責任によるものです。
SCMの観点からもシステム対応の限界が見えており、このようなデータの分散は情報漏洩という観点でも好ましくない状態であり、一刻も早いシステムの再構築が必要な状態だったのです。
パッケージではなく、手作り開発
お客様経営陣は、このような硬直したシステムの現状と、「脱コンピュータメーカー論理」実現のために、全面的な基幹システムの刷新を決断しました。全社に散らばるデータを一元管理し、社会情勢の変化にすばやく対応できる柔軟な新システム構築を目指して、複数社のコンペを経て、新システム構築を当社に委託することを決定されました。
他社のすべてがERPパッケージベースでの提案の中、手作り提案は当社だけでした。当社の提案理由は、顧客の文化とビジネスモデルを察してのことであり、安易なパッケージ適用は失敗するとの判断でしたが、お客様経営陣はそのコンセプトを理解されました。また、当社がデータ一元管理を確実に実行できるシトリックスのインテグレーターとして豊富な実績があったことも選定のポイントとなりました。
多種多様な受注形態への対応と、標準原価計算を実現する生産管理システム
人事給与、財務会計に関しては既存のパッケージシステムの利用としましたが、再構築の対象となる業務ごとのサブシステムは16に及び、機能数では約520、モジュール数は約2,000個という膨大な量を開発するに至りました。プロジェクトの推進は、顧客各部署から選抜されたメンバー及び情報システム担当で構成されるワーキンググループとの密接な連携を行い、問題点を早期解決する体制とし、要件定義から基本設計～運用テスト、並行稼働まで約2年間を費やしました。
構築したシステムを大きく分けると、全国の営業所の営業担当によるハンディ端末を使ったルート販売、各顧客の要望に応じたEOS・EDI（TC/営業所/本部代行）等の多様な受注形態への対応、各営業担当のモチベーションの持続を目的とした目標達成管理機能、受注～生産計画～所要量計算～原材料発注～物流出荷までの連動型処理機能、そして、個別の売上伝票NO.から取引をトレースする機能、厳格な棚卸処理機能、物流の運送コストを正確に付き合わせる機能といった、高レベルの監査基準に対応した機能を網羅したお客様独自の販売管理系システムと、データ入力のしやすさに配慮した標準原価計算機能によって、原価計算精度を向上させていくことができる生産管理系システム、そして正確な現在在庫の把握機能、原材料のロット管理や棚卸作業の効率化、余剰在庫のチェック機能等を盛り込んだ在庫管理システムで成り立っています。システム全体でのデータの二重入力を排除し、各サブシステムと連動するERPシステムといえます。
そして、システム構成図にあるように、外部とのデータ送受信をひとつひとつ作り込み、本部通信サーバー(COMサーバー)へ集約させることで省力化と高速化（FTP）を実現できました。
全面的なオープンシステム化をシトリックスによって一気に実行
構築したシステムの規模は相当な量であり、当初は販売管理系と生産管理系を分割し、段階的本番稼働も検討しましたが、新旧並行運用時の煩雑さ、データコンバート等の一時的利用プログラムの作成等のデメリットから、全システムの一括リリースを決断しました。シトリックスを基盤としてシステムを構築すれば、ある時点での全社一斉の新システム稼働が可能となるからです。システム構成上では、シトリックスのインテグレーションには絶対の自信を持っていた当社でしたが、今回導入を決定したORACLE RACとの組み合わせは構築当時前例がなく、社内での動作確認には相応の時間を費やしました。ハードウェアとの相性もあり、メーカー（オラクル社とhp社）との密接な連携により、なんとか正常稼働にこぎつけました。
全システムの一括カットオーバーの実現だけではなく、カットオーバ以降のプログラム修正の即時対応や、リモートメンテナンスが正確に実行できた点も、シトリックスを基盤にしていたから実行できたことです。
そして、複写伝票を大量印字するドットプリンタ等の存在は、当社が開発した帳票開発ツールであるデルバイがなければ、現場への致命的な障害を発生させていた可能性もあります。そのようなシステム構成に関わる障害はほとんど発生しなかった点から考えても、今回の構成は正しい判断であり、ホストコンピュータをオープンシステムへリプレースする際の最適な構成であると考えています。
ブラックボックスのないシステム
ERPパッケージをベースにシステムを構築するメリットはあります。カスタマイズを行わない状態であれば、正常動作が保証されている点です。極力そのまま活用するという強い意志があればERPパッケージベースでも成功の可能性があります。
一方、手作り開発の場合は、新たな設計、新たなプログラミングを行うわけですから、その動作は保証されません。十分なスキルをもったSEが設計し、十二分なテスト工程をすべての機能に渡って実施し、機能を連動させた総合的な整合性を確認する期間もできるだけ多く必要となります。従って、納期は長くなりますし、不足の事態や仕様変更等で進捗が遅れると、割を食うのは必ずといって良いほどテスト工程であり、本番稼働後から品質の悪い部分が一気に露見することになります。今回のシステム開発でもそのような部分があり、顧客にご迷惑をおかけしてしまったことは事実です。
しかし、パッケージシステムをベースにするのとは異なり、システムにブラックボックスはありません。問題発覚時には突貫工事ができます。そこに制約はありませんし、顧客に不条理な妥協を強いることもありません。自社のシステム担当者による情報の継承を間違いなく実行していけば、システムを時代の変化に応じて、いかようにでも拡張することが可能です。
お客様新基幹システムは、更なる発展を目指して、既に第二次開発がスタートしています。