33 自社開発時のトランザクションデータ管理（受発注在庫管理）

　自社で「受発注在庫管理」をExcelで行っている場合、現在管理している情報（データ）をシステム上の
テーブル（個々のデータの集合）に振り分けなければなりません。
以下は、トランザクションデータテーブル（業務単位に発生するデータ）の例となります。
①受注データ
　・受注顧客の商品、受注日、受注数、納品予定日など顧客受注単位に発生する情報を管理
　・受注単位の管理のため、受注番号が必要
②発注データ
　・発注商品、発注日、発注数など発注商品単位に発生する情報を管理
　・受注商品の発注、在庫管理上の商品の発注を管理
③入荷データ
　・入荷商品、入荷日、入荷数など入荷商品単位に発生る情報を管理
　・商品の置場、倉庫など、入荷・入庫を判別する必要がある場合は、
　　入荷データ・入庫データの個別管理が必要
④出荷データ
　・出荷商品、出荷日、出荷数など出荷商品単位に発生る情報を管理
　・商品の置場、倉庫など、出荷・出庫を判別する必要がある場合は、
　　出荷データ・出庫データの個別管理が必要
上記以外に、業務により下記データを管理
⑤返品データ
　・商品返品を受けた時：顧客へ出荷済商品の返品管理
　・商品返品を行う時　：発注先からの納品済商品の返品管理
⑥廃棄データ
　・在庫商品の廃棄管理

32 自社開発時のマスタデータ管理（受発注在庫管理）

　自社で「受発注在庫管理」をExcelで行っている場合、現在管理している情報（データ）をシステム上の
テーブル（個々のデータの集合）に振り分けなければなりません。
※各種情報は、コード化（太字の部分）が必要になります。
以下は、マスタデータテーブル（元となる基本データ）の例となります。
①顧客マスタ
　・受注顧客のコード、氏名、住所、電話番号など、顧客独自の情報を管理
②商品マスタ
　・受注商品のコード、商品名、発注先、受注単価、発注単価など、商品独自の情報を管理
　・商品単価が時期により変更される場合は、単価適用日付なども必要
③発注先マスタ（または、取引先マスタ）
　・受注商品を発注する取引先のコード、発注先名、住所、電話番号など、発注先独自の情報を管理
④在庫マスタ
　・在庫管理を行う商品のコード、在庫数、棚卸日など、在庫商品独自の情報を管理
　・商品マスタに登録済の商品が対象

31 システム要員の経費例（派遣会社・パート社員）

　経費事例を下記に示します。（あくまでも参考値です。）
①人材派遣、パート職
　SE、PG、作業領域と単価を貴社判断し、費用対効果は自社で判断することとなります
　時給単価は、1,500～3,000円

30 システム要員の経費例（開発会社）

　経費事例を下記に示します。（あくまでも参考値です。）
①依頼会社のSE（システムエンジニア）
　主としてシステムの設計を主業とする技術者
　月単価は、70万～100万（大手企業では、200万程度もあり）
　※システム規模、依頼会社の要員構成を踏まえて判断（経歴は？、経験は？）
　※依頼会社ではSEだが、貴社判断ではPGということもありえます、
　　要件をシステム化できることが重要になります
　※自社常駐ならば、費用対効果を判断できるが、依頼会社での開発ならば
　　判断不能となります
②依頼会社のPG（プログラマ）
　主としてシステムの開発を主業とする技術者
　月単価は、50万～80万
　※システム規模、依頼会社の要員構成を踏まえて判断（経歴は？、経験は？）
　※依頼会社ではPGだが、貴社判断ではSEということもありえます、
　　要件をシステム化できることが重要になります
　※自社常駐ならば、費用対効果を判断できるが、依頼会社での開発ならば
　　判断不能となります

29 システム化後の問題原因と対応

　システム化を行ったが、業務効率は上がらない場合はどうするのか？
【原因】
①業務整理を行わずにシステム化を行い、そのシステムが都度の要望により
　肥大化している → 現場業務が対応できない
②業務改変（経営者の経営方針、管理者の業務方針）が頻繁に変化し、
　システム対応の遅れ、現場対応の遅れが発生
③その他要因（経営者・管理者問題）
　経営者・管理者は現場業務を把握せず、現場担当者はシステム利用を行わず、
　独自の業務管理を行っている → システム化は時間とお金の無駄
　→ システムは使用しなければ、無駄な箱
【対応】
①システム化を行っている業務に関わる業務変更については、システム管理者と
　業務連携を行う → 要求定義、要件定義の見直し
②システム利用者の要望に合わないシステムを使用続けていないならば、現状業務を
　稼働しながらシステム改修
　・不要と思われる機能は「使用不可」にしておき、その後、時期をみて「削除」
　・追加が必要な機能は「使用不可」にしておき開発を継続、時期をみて「稼働」

28 システム関連ドキュメントの必要性

　各種ドキュメントを整備しておかないと下記のような問題が発生します。
①「要求定義、要件定義」がない
　要求・要件に基づきシステム化を進めたのに、システム運用を開始したら不具合が発生
②「外部設計・内部設計」がない
　システム変更時に後任の別のシステム開発者が参照する場合があります。この設計書がないと、後任開発者はプログラムソース
　より現行の仕様を確認しつつシステムの変更を行うこととなり、改修に時間が掛かることとなります
③「操作説明書」がない
　新入社員、異動などで新たなシステム利用者が増えた場合、その都度システムの「操作手順、操作方法」の説明に
　時間が掛かることとなります

27 システム運用後のドキュメント例

　開発後、システム利用者へのシステム運用を正しく行ってもらい、業務変更によるシステム変更を行うためにも下記のような
ドキュメントを準備する必要があります。
①操作説明書
　システム化された業務の「操作手順、操作方法」等をシステムサイドの用語ではなく、ユーザサイド（システム利用者）に
　理解できる用語で記載します
②仕様変更書
　・開発時のテストでは不具合が発見できず、運用後に発生した不具合を記録し、改修（変更）した仕様を記載します
　・運用後、業務変更等でシステムに改修（変更）が必要になった場合、改修した仕様を記載します