Comments
Description
Transcript
化学品専門商社 基幹システム導入プロジェクト報告
化学品専門商社 基幹システム導入プロジェクト報告 クロスフィールド 橋本 哲也 AGENDA 1. プロジェクト概要 • システム化範囲 • プロジェクト全体スケジュール • プロジェクトにおける問題 2. システム機能概要 1. 販売管理/会計システムの分離 • 課題と対応 • I/Fデータとルール • 想定請求書番号の仕組 2. ホームセンターEDI連携 • 課題と対応 • EDI連携処理概要 • 流通事業の標準EDIルール • EDI専用ツール 2 2. システム機能概要 3. メーカー連携 • 課題と対応 • 商流とデータの流れ • 連携対象外の重要項目 3. おわりに 1．プロジェクト概要 3 1. プロジェクト概要 クライアント プロジェクト期間 化学品専門商社（大手商社のグループ会社） （以下、A社） 2年(システムカットオーバーまでは1年9カ月) 背景 システム環境の変化、および業務効率の低下という問題に対応するために、新基幹システム（販売管理/会計システム ）の導入を目的としてプロジェクトが立ち上がりました。 システム環境の変化 • 旧システム（パッケージを利用）のメーカー保守期限の到来 • グループ会社標準会計システムの導入 業務効率の低下 • ホームセンター取引拡大に伴う販売及び経理業務負荷の拡大 • 内部統制対応に伴う各種統制業務負荷の拡大 新基幹システム導入の効果 システム基本機能 • 応答レスポンスの向上（機能にもよるが総じてレスポンスタイムは50％以下に短縮） • システムによる十分なエラーチェック、入力制御機能を装備 業務効率の改善 • ホームセンター取引における取引データの可視化および債権管理の精度向上 内部統制の実現 • システムから必要なログ情報を出力可能 4 1. プロジェクト概要 ～システム化範囲 当プロジェクトでのシステム化範囲は以下の赤枠線内の販売管理システムおよび会計システムです。 A社 システム全体構成イメージ ホーム センター メーカー 販売管理システム 販売管理 D社 EDI連携 E社 受発注管理 請求管理 売上/仕入情報 在庫情報 等 売上仕入 管理 在庫管理 マスタ管理 与信管理 マスタ情報 （取引先関連） 与信管理用 債権情報 Y社 情報分析 販売実績管理 （BI） CSV 当プロジェクトの システム化範囲 債権管理 債務管理 （請求を除く） （支払を含む） マスタ管理 CSV 手形管理システム Z社 分析用 会計情報 会計システム 銀行入出金 システム EDI連携 手形発行 凡例： 領収書発行 5 財務管理 自動連携 手動連携 1. プロジェクト概要 ～プロジェクト全体スケジュール 当プロジェクトのシステムカットオーバーまでのスケジュールは以下の通りです。 なお販売管理システムと会計システムのシステムベンダーは異なるシステムベンダーであり、データセンター やネットワークベンダーを合わせると合計5社のベンダー管理を行う必要がありました。 システムカットオーバー 1年目 販売管理 システム 会計 システム 導入 準備 ベンダー 事前 要件 選定 準備 定義 導入 準備 提 案 見 積 要件分析※ フェーズ名 2年目 開発/ 総合テスト/ 結合テスト 詳細 設計 基本設計 移行 計画 事 前 準 備 凡例： 要件定義/ 基本設計 /詳細設計 受入テスト/ 教育/ 移行準備/移行 マスタクレンジング 開発/ 結合テスト 移行 移行 テスト 計画 準備 総合テスト 受入テスト/ 教育/ ※親会社の情報システム部局がA社に対して要件分析（要件定義に相当）を実施。 要件分析以降は、会計システムベンダーが実施。 6 運用保守 運用保守 移 行 1. プロジェクト概要 ～プロジェクトにおける問題 旧システムから新システムへリプレイスするにあたっては、下図のようにシステム間連携箇所が増加しました （メーカー連携についてはデータの流れが変更）。そのためシステムに求められる要件は高度なものになり、 かつ、システム構成全体における複雑性は増しています。当プロジェクトを推進して行く上で発生した問題は 、社内外問わずシステム間連携に係わる箇所に集中しました。 旧システム全体構成 イメージ A社 メーカー 旧基幹システム 販売管理 売上仕入 管理 受発注管理 情報分析 販売実績管理 （BI） 与信管理 銀行入出金 システム 債権管理 （請求を含む） 債務管理 （支払を含む） Y社 在庫管理 EDI連携 Z社 マスタ管理 財務管理 CSV 会計管理 CSV 手形管理システム 新システム全体構成 イメージ A社 ホーム センター 販売管理 EDI連携 E社 受発注管理 売上仕入 管理 在庫管理 請求管理 与信管理 マスタ管理 売上/仕入情報 在庫情報 等 銀行入出金 システム メーカー 販売管理システム D社 ②ホームセンター EDI連携の問題 ③メーカー連携 の問題 手形発行 CSV マスタ情報 （取引先関連） 与信管理用 債権情報 会計システム 債権管理 （請求を除く） 債務管理 （支払を含む） 手形管理システム 手形発行 マスタ管理 CSV 7 領収書発行 Y社 情報分析 販売実績管理 （BI） 分析用 会計情報 財務管理 EDI連携 Z社 ①販売管理/会計システ ムの分離の問題 （システム間データI/F） 1. プロジェクト概要 ～プロジェクトにおける問題 前項でも挙げた通りシステム間連携に係わる箇所において多くの問題が発生しましたが、その中でも代表 的な問題としては以下のようなものが挙げられます。これらはスケジュールや費用、稼働後の業務運用に大 きく影響するものでしたので関係者間で検討を重ねて対応を決定する必要がありました。 問題発生箇所 ① ② 販売管理/ 会計システム の分離 ホームセンター EDI連携 問題 販売管理システムと会計システムが分離 してしまう。 ※旧システムでは販売管理/会計機能はオール インワンの統合システムであった 将来的にはEDI連携先の拡張を見込んで いるが、その対象先が正式に決定してい ないため、プロジェクト期間中に全てのシ ステム要求を盛り込むことができない。 本来システムで管理すべき情報（受注・売 上・債権など）をシステム外管理している。 （担当者の手作業による業務が多く残っている） ③ メーカー連携 メーカー側のシステム制約により、様々な オフライン作業が発生してしまう。 ※メーカー側システムは当初A社とEDI連携しな いことを前提に構築しており、後付けで連携機 能を追加したため多くのシステム制約が発生 8 影響 ユーザは業務シーンによって操作 性の異なるシステムを利用しなけ ればならない 旧基幹システムにはなかったシス テム間データI/Fが発生する 汎用的なシステム構成にしないと EDI連携先を拡張する度に多額の 費用が発生する可能性がある 今後の取引拡大に業務が耐えら れない 商流と同じ流れでデータ送受信が できないことや、伝票摘要項目等 （重要な情報）が連携されないこと 等により、業務運用に混乱を招く 恐れがある 2. システム機能概要 1. 販売管理/会計システムの分離 9 2-1. 販売管理/会計システムの分離 ～課題と対応 A社は元々オール・イン・ワンの統合システム（販売管理機能と会計機能は１つのシステム）を利用していまし た。新基幹システムではグループ会社標準会計システムの導入を前提としていたため、販売管理システムを 旧システムと同じパッケージ製品にすると、そのパッケージの会計モジュールは利用できず、販売管理システ ムと会計システムを分離しなければなりませんでした。 販売管理システムと会計システムを分離することで以下のような課題が発生したため、両システムの機能特 性や制限、および改修が必要になった際の費用を鑑みて対応方法を決定しました。 課題 対応 以下のように機能役割を定義しました。 ① 販売管理システムと会計管理シ ステムの機能切り分けを明確化 しなければならない。 • 販売管理 受発注管理、売上仕入管理、請求管理、在庫管理、 与信管理、マスタ管理、販売実績管理 • 会計システム 債権管理、債務管理、マスタ管理、財務管理 以下のようにI/F対象データとルールを定義しました。 ② 販売管理システムと会計管理シ ステム間でデータI/Fが発生する ため、その対象とルールを定義し なければならない。 ③ 会計システムで回収消込する際、 消込対象債権の特定が容易に 出来るようにしなければならない。 販売管理システムで売上計上時に想定請求書番号を採 番することで、会計システムで回収消込対象の特定が出 来るようにしました。※詳細は12頁を参照 • 販売管理システム⇒会計システムへI/Fするデータ 売上仕入情報、在庫情報、マスタ情報（取引先関連） • 会計システム⇒販売管理システムへI/Fするデータ 与信管理用債権情報、分析用会計情報 10 2-1. 販売管理/会計システムの分離 ～I/F対象データとルール 販売管理システムと会計システム間のI/Fについては両システムの機能特性（役割）や制限、および改修費 用を鑑みてI/F対象やルールを決定する必要がありました。特に会計システムに関してはグループ会社標準 会計システムと言うこともあり容易にカスタマイズができなかったため、販売管理システム側で要件の多くを 吸収したり、自動連携が難しいマスタについては連携対象外としてオフライン同期（人的対応）するなどのル ールを詳細に決定しました。 販売管理システム 課題①に対する対応 機能役割 • • • • 受発注管理 請求管理 ※1 与信管理 販売実績管理 ・ 売上仕入管理 ・ 在庫管理 ・ マスタ管理 ※1 請求書には品目情報を表示するため販売管理 システムから出力する （会計システムには品目情報を保持しない） 課題②に対する対応 販売管理システム ⇒ 会計システム へI/Fするデータ 課題②に対する対応 会計システム ⇒ 販売管理システムへ I/Fするデータ 会計システム • 債権管理 （請求を除く） • 債務管理 （支払を含む） • 財務管理 • 売上仕入情報 ※2 • 在庫情報 • マスタ情報（取引先関連） ※3 ※2 売上仕入情報については日次で取引先＞決済条件の単位でサマリーする ※3 勘定科目や社員マスタについてはオフライン同期（人的対応）で運用する • 与信管理用債券情報 ※4 • 分析用会計情報 ※4 販売管理システムで与信管理を行うため、会計システムで回収消込した 消込金額情報を販売管理システムへ戻す 11 2-1. 販売管理/会計システムの分離 ～想定請求書番号の仕組 以下のようなシステム機能と制限によって会計システムで回収消込する際の債権特定が困難になることが 想定されました。そのため売上計上時に販売管理システムで想定請求書番号を採番し、会計システムでは その番号で対象債権を特定することで、回収消込業務の効率化を図りました。 ◇システム機能と制限 販売管理システム 会計システム ① 日次で取引先＞決済条件の単位でサマリーした売上情報（仕訳）を会計システムへI/Fする ② 月次で請求書を出力する（請求書番号はこのタイミングで採番される） ③ 売上情報（仕訳）取込後に、請求書番号がI/Fされても売掛金情報に紐付けできない 販売管理システム 取引先X商事 売上伝票 課題③に対する対応 売上計上時に取引先＞決済条件の単位で想定 請求書番号を採番し、売上情報上に保持して会 計システムへI/Fする 計上日 伝票 金額 回収 予定日 想定 請求書番号 9/1 売上1 400円 11/30 K001 9/1 売上2 200円 11/30 K001 9/2 売上3 500円 11/30 9/2 売上4 300円 12/31 請求書出力（月次） 【請求書】 請求書番号K00101 得意先 X商事 支払期限11月 --------------合計金額：1,100円 請求書出力時に、事前に採 番されている想定請求書番 号に枝番を付与する形で請 求書番号を採番する 会計システム 債権情報（仕訳） 入金 借方 貸方 金額 計上日 請求書 番号 売掛金 売上 600円 9/1 K001 K001 売掛金 売上 500円 9/2 K001 K002 売掛金 売上 300円 9/2 K002 システム機能と制限② 【請求書】 請求書番号K00201 得意先 X商事 支払期限12月 --------------合計金額：300円 売上情報 I/F（日次） システム機能と制限① 回収消込 得意先 X商事 11月分 （請求書K00101） 1,100円 得意先 X商事 12月分 （請求書K00201） 300円 × システム機能と制限③ 本来なら請求書の請求書番号をセットした いが、会計システムの制限により既に取込 済の売上（債権）情報は更新できない。 12 課題③に対する対応 請求書出力後に採番される請求番号を保持することが できないため、売上計上時に採番される想定請求書番 号を保持する。 想定請求書番号によって、得意先からの入金に対して、 回収消込対象の債権を特定することを可能とした。 2．システム機能概要 2．ホームセンターEDI連携 13 2-2. ホームセンター EDI連携 ～課題と対応 ホームセンター（以下、HC）との取引においては、膨大な伝票数を手入力しなければならないことによる受注 ・売上管理の難しさや、HCとA社の計上基準の違いからHC検収数量・支払金額とA社出荷数量・請求金額 に差異が生じる等の課題を旧基幹システムでは抱えていました。 またHCとEDI連携取引を行う際は、HC各社が固有のシステムを構築しているため先方のシステム仕様（通 信プロトコル）に合わさなければなりません。新基幹システムカットオーバー時点では、拡張対象先が明確で はなかったため、先方のシステム仕様は確認不可能な状況でした。そのため新基幹システム稼働後に拡張 改修するとなると多額の費用が発生する恐れがありました。 課題 ① 膨大な受注・売上情報を迅速か つ漏れなくシステムへ取込みシ ステム管理しなければならない。 ② HC検収数量とA社出荷数量、お よびHC支払金額とA社請求金額 の差異を伝票レベルで特定し原 因を把握しなければならない。 （債権管理の精度向上） ③ 全てのHCにおいて先方のシステ ム仕様（通信プロトコル）に合わ せなければならない。 対応 EDI受注取込機能、および一括売上機能により、システ ムで受注・売上管理を可能としました。 A社とHCの以下のデータを突合し、差異リストを出力する ことで差異原因（対象伝票）の特定を容易にできるよう にしました。 • HC受領データとA社出荷データを突合 ⇒受領/出荷差異リスト • HC支払予定データとA社請求データを突合 ⇒支払/請求差異リスト 多様なデータ変換や各種通信プロトコルに対応可能な EDI専用ツール（ACMS）を採用し、汎用的な仕組を構築 しました。 14 2-2. ホームセンター EDI連携 ～EDI連携処理概要 HCとEDI自動連携することで、新基幹システムにて受注・売上情報を管理し取引の可視化を図りました。 またHC受領（検収）データとA社出荷データの突合、およびHC支払予定データとA社請求データの突合を行 い差異リストを出力して、差異原因（対象伝票）の特定を容易にすることで債権管理の精度向上に繋げまし た。 連携処理凡例 ◇ホームセンターとのEDI連携処理概要 ホームセンター 発注データ 送信 課題①に対する対応 HCの発注データを自動取込し 、A社の受注伝票を作成する EDI連携 オフライン連携 A社 販売管理システム 発注データ 受信 発注データ 受注作成 商品マスタ （JANCD） 寄託先倉庫 商品マスタ （JANCD） 入荷予定 データ受信 入荷予定 データ 入荷予定データ 作成・送信 入荷予定データ 受信 受注修正 受領データ 受信 受注と受領データ の突合 課題①に対する対応 A社の計上基準の制約上、HCか らのデータをもとに売上計上は できないため、一括売上処理を 構築した。 出荷 検収 受領データ 送信 注文確認データ 作成 発注データ受信 ＆受注作成 受領データ 在庫表送付 在庫表 受領/出荷 差異リスト 売上計上 課題②に対する対応 差異リストを出力可能とした 請求データ 受信 請求データ 請求データ 送信 請求データ 作成 支払予定データ 送信 支払予定 データ 支払予定データ 受信 請求と支払予定 データの突合 支払/請求 差異リスト 回収消込 入金 15 会計システム 2-2. ホームセンター EDI連携 ～流通事業の標準EDIルール 企業間でデータ連携を実現するには企業同士で独自ルールの取り決めを行いシステム開発を行う必要があ りました。連携先が増えればルールが増えシステムは複雑化していくため、そのような問題を解決すべく経済 産業省から標準EDIルール「流通BMS」が制定されました。 しかし流通BMSの導入は、卸・メーカーの負担が大きく中々導入が進まないため、従来のWEB-EDIを活用で き、小売業者にも導入が容易な手順として「BACREX手順」が存在します。 流通BMS（Business Message Standards） 2007年4月に経済産業省の「流通システム標準化事業」により制定された小売業、卸売業、メーカー等、あらゆる流通事業者の 取引を電子化するための標準EDIのルール。従来のJCA手順では発注/請求データ等、企業間で連携するメッセージの内容が小 売企業ごとに異なり、卸やメーカーが注文を受けるためには個別のシステム開発が必要であった。 流通BMSで規定された標準通信手順 ◇“流通業界”で利用されている通信手順 JCA手順 BACREX手順 JX手順 ebMS EDINT AS2 通信環境 電話回線 インターネット インターネット インターネット インターネット 通信速度 2,400bps/9,600bps 10Mbps～100Mbps 10Mbps～100Mbps 10Mbps～100Mbps 10Mbps～100Mbps 通信可能 データ 英数カナ ー 制限なし 制限なし 制限なし システム形態 プル型 プル型 プル型 プッシュ型 プッシュ型 データ長 128バイト 256バイト 固定長 制限なし 制限なし 制限なし データ量 少量向け ー 少量向け 大量向け 大量向け 添付データ 不可 ー 可 可 可 特徴 JCA（日本チェーンストア協 会）が1980年7月に定め た通信手順。 正式名称は取引先データ 交換標準通信制御手順。 電話回線等を使う旧来型 EDIからJX手順のインター ネットEDIによる流通BMSへ の移行において、中間的な 対応を実現する手順。 国際標準で定められてい る通信プロトコル(SOAPRPC)を使用した日本独自 の通信手順。 アジア圏を中心に利用され ている国際標準。SSL通信、 XML暗号をサポート。 国際的なインターネット標 準化団体のIETFが策定し た国際標準の通信手順。 ウォルマートを始め、欧米中 心に利用。 16 2-2. ホームセンター EDI連携 ～EDI専用ツール A社はBACREX手順とJX手順を採用しているHCとEDI連携（予定を含める）するため、通信手順によってEDI サーバを分けることがないよう汎用的なEDIの仕組みを構築しなければなりません。 そこでデータ変換や各種通信プロトコルに対応可能なEDI専用ツール（ACMS）を採用することで、通信手順 が異なるHCに対してもEDIシステムを分けることなく、最小限のシステム投資でEDI連携先の拡張を可能とし ました。 A社 （販売管理システム） (※) D社 F社 上図はDAL社ホームページより抜粋 ※ACMS（Advanced Communication Management System） 販売元：DAL（Data Applications Company）社 企業間取引、企業内の分散システムとの効率的な連携を実現するために、各EDI手順、ERPシステムとの連携及びデータ変換をサポートするツールであり、EDI分野 では国内シェアNo1のソリューション。Web-EDI、全銀、JCAなどの国内標準手順、次世代EDIなど様々なプロトコルをサポート。RDB、固定長、CSV、XMLデータなど 多様なデータ・フォーマット変換に対応。SAP、IBMMQ、RDBアダプタなどにより、業務システムと容易に連携可能 17 2-2. ホームセンター EDI連携 ～EDI専用ツール 具体的には、下記のようにEDIサーバへEDI専用ツール（ACMS）を導入し、販売管理システムサーバとEDIサ ーバ間で情報連携することで販売管理システム側でもデータ送受信管理を可能としました。 またEDI専用ツール（ACMS）でHC毎に個別ファイル定義（項目のマッピング）を行い、販売管理システム側の 改修を最小限に抑えるシステム構成にしました。 EDI専用ツール（ACMS）からEDIデ ホームセンター 課題③に対する対応 HC毎に個別の定義を行い、EDIサーバを分けること なくEDI連携先を拡張可能 A社 販売管理システム EDIサーバ 受注管理 E社 （BACREX手順導入） 受注 ERP F社 （JX手順導入） ータ送受信ステータスを返してもら い、販売管理システム側で送受信 ステータスを照会可能とする パ ッ ケ （ 標ー 準ジ 機デ 能ー タ ）連 携 処 理 EDI専用 ツール G社 （今後調査） H社 （今後調査） 出荷予定 検収 売上管理 請求 支払予定 マスタ管理 ・・・ 商品マスタ 18 デ ー タ 送 受 信 管 理 2．システム機能概要 3．メーカー連携 19 2-3. メーカー連携 ～課題と対応 メーカー側システムは当初A社とEDI連携しないことを前提に構築しており、後付けで連携機能を追加したた め多くのシステム制約が発生しました。 最も大きな制約としてはメーカー側システムはA社からのデータ受信ができないため、データ連携は 「メーカー⇒A社」の一方通行の流れにせざるを得ませんでした。そのためA社発注業務（メーカーにとっては 受注業務）においては、本来の商流通りにデータ連携ができないと言う事態が発生しました。 またメーカー側では受注伝票の摘要項目に価格の特別条件や出荷予定日を入力していますが、摘要項目 は連携対象外項目であるため、価格や出荷に係わる重要な情報がA社に伝え漏れる恐れがありました。 課題 ① ② 発注業務において商流通りに データ連携ができないため、メー カーと特殊なシステム仕様、およ び運用ルールを定義しなければ ならない。 連携対象外の重要項目につい ては、その情報を漏れなく把握し、 手入力で販売管理システムへ反 映しなければならない。 対応 【システム対応】 A社販売管理システムはメーカーから受注伝票情報を受 信し、その情報に基づいてA社発注伝票および受注伝票 を作成する仕様とし、商流と異なるデータ連携に対応す るシステム構成としました。 【運用対応】 本番稼働前からメーカーと綿密に運用ルール（情報伝達、 帳票送付、確認項目など）の定義とユーザへの周知を行 い、ユーザの運用に対する不安を取り除きました。 また連携対象外の重要項目については連携した場合の メリット・デメリットを考慮し、システム対応の要否を検討 しました。システム対応しない場合には、上記同様運用 ルールを定義してユーザへ周知しました。 20 連携処理凡例 自動連携 オフライン連携 2-3. メーカー連携 ～商流とデータの流れ 新基幹システムでは、発注業務において商流とデータ連携の流れが異なるため、特殊なシステム仕様を定 義すると共に、本番稼働時に円滑に業務が遂行できるよう稼働前にメーカーとの間で綿密に運用ルールの 定義を行いました。 また定義したルールをユーザに周知・徹底するため、全国の支店から本社へ関係者を招集し集合教育を実 施することに加え、本番稼働後もリクエストがある支店に対しては出張教育サポートを実施しました。 商流（発注業務） 注文 商流通りの データの流れ （あるべき姿） A社 得意先 注文書 注文書受領 受注入力 注文確認書受領 注文 新基幹システ ムでの データの流れ 注文確認書受領 注文 確認書 注文書 注文 確認書 課題①に対する対応（運用対応） 注文確認書は得意先と売買契約の あるA社が必ず得意先へ送付する メーカー 注文確認書 発注入力 発注 データ 課題①に対する対応（システム対応） メーカーからの受注情報をもとにA社発 注情報作成⇒受注情報作成を行う 受注作成 課題①に対する対応（運用対応） 得意先からの注文書を必ずメーカ ーへ送付する 注文書受領 注文書送付 注文書 注文書受領 受注作成/確認 発注作成 メーカー 受注データ 受注入力 注文確認書 21 課題①に対する対応（運用対応） メーカーから受領した受注データに 基づいて、Ａ社発注および受注デー タを作成しているため、必ず得意先 の注文書とＡ社受注データが同じで あることを確認する データの流れが商流と 逆向きである 2-3. メーカー連携 ～連携対象外の重要項目 連携対象外であった重要項目については、連携すると便利になる半面、デメリットも発生します。連携の要 否についてはメリット・デメリットの両面を加味し、実際の運用を想定して判断しなければなりません。 以下は、今回課題に挙がった連携対象外の需要項目である「伝票摘要」項目を連携した場合のメリット・デ メリットです。 例）摘要項目を連携した場合のメリット・デメリット メリット デメリット 【情報の網羅性】 • 価格や出荷日に係わる重要な情報は漏れなくA社に連 携される。（漏れなくA社へ連絡される） 【業務運用】 • 価格や出荷日以外の情報についても摘要に入力した 情報は全て連携されるため、A社にとってどれが重要 な情報か精査しなければならない。 （A社からメーカーへ電話もしくはメールで能動的に確 認しなければならない） 【情報の正確性】 • メーカー側でシステム入力した情報が正確にA社へ連携 される。（正確にA社へ連絡される） 【業務運用】 • メーカーはA社へ電話やメールで連絡しなくてもよい。 • 摘要項目は得意先へ送付する請求書に表示する項 目であるため、請求書に表示したくない情報が摘要で 連携された場合は、摘要情報を都度削除しなければ ならない。 実運用を想定するとA社側の業務負荷は高くなることが予想されるため、摘要項目のデータ連携はしないことにし ました。そのためＡ社が把握したい重要な情報が漏れなく伝達されるよう以下のような運用ルールを定義しました。 • 価格や出荷日に係わる重要な情報については必ずメーカーからA社へ電話連絡する運用とする。 （必要であれば売上伝票（紙）をA社へ送付する） • A社はメーカーから価格や出荷日に関する重要な情報の連絡を受けたら必ず販売管理システムへその情報を 反映する運用とする。 22 3. おわりに 当プロジェクトを推進していく上で問題・課題は数多く発生しましたが、それらの多くは前述した通り主にシ ステム間連携に係わる個所に集中していました。昨今のシステム構築においてシステム間連携対応は避け ては通れないことですので、稼働後のトラブルを最小限に抑えるためには関連システムとの仕様定義やシス テムテスト（結合・総合テスト）、および稼働後のルール定義やユーザへの周知などを事前にしっかりと行わな ければなりません。 A社新基幹システムにおいては、本報告書記載時点（稼働後約8カ月）では大きなトラブルも発生することな く安定稼働しているのは、事前に関係各所と多岐に渡る調整を実施した結果だと思います。 またＡ社は独立した情報システム部門を持たず、業務担当者がシステム管理者を兼任する体制でプロジェク トに参画していたので、業務担当者に掛かる負担は相当なものでした。そのため我々クロスフィールドメンバ ーがしっかりと旗振りを行い、各々の役割を明確にした上で、ユーザ側タスクについては最大限のサポートを 行うことにより、ユーザへの負担を軽減しました。それがプロジェクトを円滑に推進することにも繋がったと思 います。 最後に、A社新基幹システム導入プロジェクトは一旦区切りをつけることになりますが、今後HCとのEDI連携 拡張や、その他ユーザからの要望による機能追加が想定されます。その都度、部分最適を優先せずにシス テム全体の整合性や費用対効果を鑑みたシステム設計をすること、および関係者とのコミュニケーションを 密に取り事前調整を怠らないことを念頭において質の高いサポートを継続して行きたいと思います。 23