情報発信
情報発信
標準で用意されているインタフェース機能としては、SAP標準の対外フォーマットでのデータ入出力(通信)と各データ種と対応アプリケーションとの連動モジュール、モニターツール、テストツール、フォーマット開発ツールなどです。
パッケージの標準機能を利用するメリットは、まず第一に開発費用が削減できることです。 仮にユーザプログラムのコーディングと標準機能の利用設定とが同じ手間(工数)だとしても、テストに掛る工数は大きく違います。 言うまでもありませんが、ERPの標準機能は、世界中の企業が何年も使用しているので、そのプログラムを自分たちで独自にテストする必要はありません。 ですが、新規に作成するアドオンは、単純正常ケース以外にも、単体UPまでにイレギュラーケース、エラーケース、モニター&リカバリーなどの多くのテストをする必要があります。
二番目のメリットとして、標準機能はベンダーサポート対象ですから、アップグレードなどに影響を受けないことです。万が一、本体のアップグレードやパッチなどで不具合が発生してもベンダーが対応してくれます。
ユーザアドオンはそうは行きません。 勿論ベンダーサポート対象外ですから、自分達で何とかしなければなりません。 ERP導入時のSIベンダーに開発を頼んでいるなら、そこにトラブル対応をお願いすることになると思いますが、EDIの障害はタイムクリティカルな場合が多いのでなるべくなら、社外リソースではなく自社で解決できるといいですね。
使い易いかどうかは別にして、パッケージに標準機能が搭載されていて、しかも細かいユーザ仕様をカバーできるようにExit機能も用意されているのにも関わらず、アドオンプログラムを開発してしまうのは本当に勿体ないことです。
現行のEDIサーバが継続利用できない理由もいくつか考えられます。 ハードウエア老朽化、ソフトのサポート切れ、独立したEDIサブシステムではなく廃止されるシステム上に構築されているなどです。 ですが、どうしてもERP導入と同時に新システムを立ち上げなければならない場合を除いて、できるだけ延命策を考えてみてください。 弊社にお声掛けいただければ一緒に検討させていただききます。
現在の業界規約が今後何年継続されるかは分かりませんが、新EDIシステム構築プロジェクトは、ERPと同時進行ではなく、新業界規約への対応時に十分な時間を掛けて実施されることをお勧めします。
ポイントとなるのは、現行のEDIシステムの機能です。 3種類に大別して対策案を紹介します。
1:ホスト内サブシステム
(ERPにリプレースされる汎用機アプリ内のサブシステムとして、現行仕様に依存したEDI処理が組み込まれている場合)
このケースは新EDIサーバを立ち上げる必要があるので、ERP導入計画初期段階からEDIチームを作りプロジェクトスケジュールを最終取引先接続テストに必要な期間から逆算して引いてください。
SAPのEDI機能に対応したEDIサブシステム用ツールが何種類かあります。 必ずしもSAP対応である必要はありませんので、このツールを使いたい場合はSAPとの接続はどうしたらいいかなどのご相談はいつでもお受けします。
2:独立EDIサーバ(通信機能のみ)
(取引先との通信を担当するEDIサブシステムがあるが、社内の基幹システムとはファイル転送だけで中身の変換等はできない場合)
そのまま使えるのであれば、現行のEDIサーバを活かして、SAPとの接続とフォーマット変換機能の追加だけ考えることをお勧めします。 SAPアダプタとして弊社のConnectPlusがこの役目を果たします。
3:独立EDIサーバ(EDIトランスレータ付き)
(外部通信だけでなく、EDI規約に沿ったデータ変換などのアプリケーション機能が使える場合)
このケースは特に、現行のEDIサーバをそのまま利用されることをお勧めします。 EDIトランスレータ機能を備えたツールをご使用されているなら、国際EDI標準のEDIFACTに準拠したSAP標準フォーマットへの対応も可能 だと考えられます。
SAPとの接続部分の調整で済みますので、期間も費用も抑えられます。
EDI受注はボリュームも大きく、取りこぼしや障害遅延などが許されない、業務的に重要なデータです。
本稼働の3カ月前に“そういえば、EDIはどうしよう…”では致命的です。 (そこを何とか! というご相談はいつでもどうぞ)