DPC用語集「あ行」

受注データ取得時に連続置換を行う時の処理のひとつです。

　１件の月間計受注データに対して、より新しい同月の月間計であったり、当該月間を分割された日別データ等の新しい受注データ（群）で置き換えます。
この”置き換える”という処理は“削除＆挿入”という作業で行います。この削除するときにＥＤＩデータ発信者ないしは[ＩＤ]の特性により無条件に内示データを全品目削除して今回受信データを挿入するパタンと、読み込まれた受信データ個々ののグループ単位で削除してから当該データを挿入パタンがあります。（１社の中でＩＤによって切り替わることもあります）
　この時“グループ単位”の基本は[品番]ですが、多くは[品番/納入先]の単位で得意先での発注データの制御（担当者による作成）を行っているケースが多いです。
また得意先によってはさらに多くの項目を加えてグルーピングしていて、この単位で得意先の発注データ（ユーザにとっての受注）を置き換えていきます。このグルーピングする項目群が置換keyです。

1. 電子データ交換（でんしデータこうかん、EDI、Electronic Data Interchange）とは、 標準化された規約（プロトコル）にもとづいて電子化されたビジネス文書（注文書や請求書など）を専用回線やインターネットなどの通信回線を通してやり取りすること。 あるいはこうした受発注情報を使って、企業間の取引を行うこと。

   

経済産業省による定義では、 「異なる組織間で、取引のためのメッセージを、通信回線を介して標準的な規約を用いて、コンピュータ間で交換すること」となっている。　（以上出典：Wikipedeia）

  
 

2. 今多くの自動車メーカでのＥＤＩのプロトコルはＵＮ／ＥＤＩＦＡＣＴ準拠になってきています。
   本来、ＥＤＩＦＡＣＴプロトコルを使うことにより、それまで各社毎に個別に開発されていた協力工場側の「ＥＤＩ処理」を統一的処理できるようになり効率的なシステム保守が出来ることも狙いの一つのはずです。
   実際には各社の運用はそれぞれであり、それに伴って送られてくる「ＩＤ」「フォーマット」は当然のことながら違っています。これらを処理しやすいように一件一葉（一行）のデータに変換するのに「ＥＤＩＦＡＣＴトランスレータ」という仕組みがあります。この「ＥＤＩＦＡＣＴトランスレータ」の導入当初は環境整備のための費用負担をしても、その後のシステム変更に対しては親メーカによる費用負担ないしは自社で簡単にパラーメータが変更できるのなら、「ＥＤＩＦＡＣＴトランスレータ」を導入するそれなりの意味はあると思います。
   しかし現実は毎回のシステム変更の都度、協力工場自身での安くはない費用負担で「ＥＤＩＦＡＣＴトランスレータ」のサポート企業にたいして修正依頼をかけなければなりません。ここまででＥＤＩＦＡＣＴデータが読み出せるようになっただけですから、その上で更に実際の自社システムに取り込むための修正が必要となります。


3. というわけでＤＰＣでは、（特段のお客様からの要求がなければ）「ＥＤＩＦＡＣＴトランスレータ」をかまさずに、直接ＥＤＩＦＡＣＴデータを読み込んでＤＰＣの受注情報等に変換・取得してしまいます。また修正費用は（特にこの読みこみ部分は）当該親メーカ傘下の協力工場様に於いては全社共通ですのでユーザ各社で按分請求させていただきます。・・・・修正対象ははこの一本です。

コンピュータ・システムを活用するのに必要な要員（職務）を指します。

　事務処理のためのコンピュータ・システムは機械が勝手に動くものではなく、人が動かすものです。このためにコンピュータを操作することの出来る「時間のある操作者」がいなければ“動かないコンピュータ”になってしまいます。
　しかしコンピュータは火が入ってデータが入出力されればそれでよし、かというと問題があります。コンピュータ・システムが効果的に活用されるには自社（工場の）運営がどうあるべきで、いまどうなっているか、何が問題なのかが判っている「知識のある管理者」がいる必要があります。この時の「知識」とはコンピュータ知識もあることが望ましいですが、より必要なのは業務知識であり自社の運営知識です。
　さらにシステムを運用していくとある時点時点でいうと必ずしも全部署で“みんなよい”ということはあまりなく、ある部署では良くても他の部署では目の前の負荷が増えたりして賛成出来ない、といったことは往々にして発生します。この時「力のある責任者」がいないと方針が決定されず運用が崩れていきます。・・・・最終的に意志決定はトップダウンです。
　これらの３機能は必ずしも３人で分担するばかりでなく、実際の小企業では“権限と業務知識”を社長が、”コンピュータ知識と操作”を若い担当者が分担をして担うということはありだと思います。
　
　いずれにしてもこの３職務を“名目ではなく実質的に誰が担っているのか”が見えなければシステムは動きません！

Sequential Number Systemの略でＤＰＣにおいて累積進度管理として実装しています。
原型は戦時中に中島飛行機や三菱重工で零戦製造時の進捗管理技法として編み出された追い番管理に端を発します。

MRP(Materials Requirements Planning)とも呼ばれる。
 

• 資材所要量計画（しざいしょようりょうけいかく）とは工場などで使われる生産管理手法の一つ。
• 資材管理で生産を計画する手法のこと。

 

その概念を発展させて資材以外の人員、設備など製造に必要なすべての資源を管理する仕組みをMRP2という。 さらに、企業全体の在庫、決済、資産の管理を行うようにしたのがERP(企業資源計画)である。 　（以上出典：Wikipedeia）

 

1. ＤＰＣでは「引当計画」として品目単位ではなく工程単位で（後工程から前工程に向かって）ＭＲＰ展開ロジックで使われる総所要量計算/先行計算/純所要量計算/計画取り纏め　をLevel by Levelで常に実績在庫に立ち戻って運用する形で実装しています。
2. このためＤＰＣにおいては品目途中の仕掛かり工程在庫を残したままの計画も立てられます。