生産スケジューラーと生産管理システムの要点

本記事の概要

    • 「製造指図」も「かんばん」も内示に基づき所要量展開するところは同じだが、製造指図が生産管理部から現場に対する生産指示であるのに対し、かんばんは現場で需要と供給の関係によって自律的に流動する。
    • 工場内で流動する工程内かんばんは、出荷ではずれて現場に戻されるまでの間滞留している分(かんばんL/T)、製造現場で加工点に達するまで滞留している分(加工L/T)、現場や倉庫にある在庫ロットに挿してある分(安全在庫)があり、現場を流動する引取かんばん(移動実績)と、生産指示となる仕掛かんばん(生産実績)に役割分担されることもある。
    • 工程内かんばんの計算方法は「{加工ロット+日当たり必要数x(かんばんL/T+加工L/T+安全在庫日数)}/入り数」であり、加工ロットは「最低連続加工時間/サイクルタイム(稼動時間まとめ)」と「最低加工コイル数 x 1コイルで何個取れるか(コイルまとめ)」と「最低加工日数 x 日当たり必要量(出荷日数まとめ)」という3つの条件の下に、最も加工コイル数の多いものを適用。
    • MRPにより計算される正味所要量に安全在庫をプラスした当月の製造指図合計数量よりも、当月の「かんばん枚数xBOXの収容数」は、現品なしでかんばん単独で滞留している「かんばんL/T+加工L/T」の期間分だけ余分に多い。

【重要】かんばん生産のためのMRPの使い方

  1. MRPの3つの目的
      1. 製造:製造指図の発行、または工程内かんばん枚数の計算
          • 製造指図は生産計画に基づく作業単位の実体演繹的なプッシュ方式)だが、かんばん生産は使った分だけ後工程が前工程から引き取った結果としての実体帰納的なプル方式)。
          • かんばんは前工程に対するBOX単位の生産依頼書であり、MRPにより計算される実所要量から現状在庫をマイナスした正味所要量に安全在庫をプラスした当月の製造指図合計数量は、当月の「かんばん枚数xBOXの収容数」になる。
            1. 製造指図合計数=実所要-現状在庫+安全在庫
            2. かんばん枚数xBOXの収容数=加工数+日当たり必要数x(かんばんL/T+加工L/T+安全在庫日数)
      2. 購買:材料発注のための所要量計算(材料かんばん枚数計算)
      3. 機械:ラインや機械の負荷計算
  2. 計画生産のMRP機能
      • 月次の内示に対する月当たり実所要量に対して
        • 1. 現状在庫と安全在庫を加味した正味所要量を計算し
          • 稼働日で割った日別の正味所要量に対し
            • 2. L/T分必要日をずらす

        これをマニュアルで行わずシステムで行うのがMRPの機能。

  3. 製造指図数量合計と(かんばん枚数x収容数)の差
    • 実所要から現状在庫と安全在庫を引いた正味所要量は、実所要を稼働日で割った日当たり必要数に(かんばんL/T+加工L/T+安全在庫日数)をかけた結果に加工数(加工ロット)を足したものとは、出荷エリアで外されて溜まっているかんばんL/T分と、加工エリアで加工点に達するまで溜まっている加工L/T分だけ一致しない

kanban

【重要】出荷エリア(かんばんL/T)と製造現場(加工L/T)と置き場(安全在庫)

  1. かんばんの在り処
    1. 出荷エリアで外されて溜まっている分(かんばんL/T
      • 出荷でかんばんがはずれて現場に戻るまでの遊休期間
    2. 現場で加工点に達するまで溜まっている分(加工L/T
      • 現場横のかんばんが加工点に達するまでの期間+加工ロット分を完了させるべき期間
    3. 現場や倉庫にある在庫ロットに挿してある分(安全在庫
      • 切ってはいけない在庫水準N日分であり、安全在庫=0なら「納期遅れせずに在庫なし」で運営できるベストな状態だが、これだと不安だから余分に持つのが安全在庫であり、過去のある期間の使用実績から平均使用量とバラツキを計算し、統計的に欠品を起こさないだけの量を持っておく。
  2. 置き場のBOXが0で、次に来る引取かんばん分を加工現場の工程内かんばんでまかなうのが、在庫0かつ工程在庫のみ存在という究極の運用になる。
    • 月次生産計画を日割り平準化した1日あたり必要量が100個で入数10個の場合、安全在庫日数0日、加工L/T1日&かんばんL/T0日であれば最低でも(加工数+100)/10枚必要。
  3. 工程内かんばんを引取かんばんと仕掛かんばんに分ける
    1. 出荷ではずれて出荷エリアで滞留
    2. 加工エリアに戻されて、BOXが引き取られ、加工エリアで滞留
    3. 加工点に達したら加工を開始してBOXに挿される
    4. 2に戻る

    工程内かんばんは現場を流動する引取かんばん(移動実績)と、生産指示となる仕掛かんばん(生産実績)に役割分担する。

    1. 出荷時にBOXの引取かんばんはeかんばんに差し替えられ、出荷エリアで滞留(引取かんばん)
    2. 加工エリアに戻されて(引取かんばん) 、BOXが引き取られる際に挿してある仕掛かんばんは引取かんばんに差し替えられ、加工エリアで滞留(仕掛かんばん)
    3. 加工点に達したら加工を開始してBOXに挿される(仕掛かんばん)
    4. 2に戻る

【重要】かんばん枚数計算の流れ(加工数が現在加工中のロットでそれ以外は滞留しているロット)

  • かんばん枚数計算の目的は、当月回転枚数に対して次月の内示から計算すると何枚増やすか(減らすか)を知ることである。
  • 工程内かんばん枚数={加工数+(日当たり必要量)x(かんばんL/T+加工L/T+安全在庫)}/収容数
  • 加工数は今現在加工中のロットであり、かんばんL/Tや加工L/Tや安全在庫は現場や置き場に滞留しているロット。
  1. 月次の内示を取込、所要量展開(L/T=0日)し実所要量を計算。
  2. 日あたり必要数=月次の実所要量/月稼働日
  3. 1コイルあたり何個取れるか
    • 標準コイル重量(kg)=板幅(mm)x3.4
    • 1コイルあたり何個取れるか=標準コイル重量/1個あたり重量
  4. 加工数(1回で加工するロット)を算出
    1. 最低連続加工時間(マスタ値)最低何時間機械を止めたくないか(稼動時間まとめ)
    2. 最低加工コイル数(マスタ値)最低何本コイルを使い切りたいか(コイルまとめ)
    3. 最低加工日数(マスタ値)最低何日分まとめて生産したいか(加工日数まとめ)

    3つの条件の下に最も加工コイル数の多いものを適用。

  5. 工程内かんばん枚数(In-Processかんばん)
  6. 材料かんばん枚数(Materialかんばん)

かんばん方式では後工程から要求される品種と量が頻繁に変わったらコスト高で対応できないので、平準化して生産できるための外段取化・シングル段取化・多能工化が必要

  1. 「材料は外れたかんばんに必要な分だけ紐付け必要なものを必要な数量だけ製造」とは1対1紐付きであり、受注単位やロット単位(製造指図数量)で製造するスケジューラーは矛盾するので、かんばんによる後引きに細かく対応できない成形やプレスなどの前工程にスケジューラーを導入し、中間在庫をコントロールするという運用。
  2. 必要な品種を必要な量だけ製造するのはOKだとしても、現場の生産設備で毎日後工程から要求される品種と量がコロコロ変わったらコスト高になってとても対応できないので、かんばん方式運用では品種と量を日ごとに平準化する必要がある。
  3. ロット生産では専門工が段取り回数を減らすために同じものをまとめて生産するが、平準化生産では色々な種類の製品を均等にばらして生産する必要があるので、実現するには内段取り(主資源段取)の外段取り化(副資源段取)や段取りの標準化によるシングル段取りの実現と多能工化が必要となり、平準化を突き詰めると1個流しになる。

【重要】トヨタのオーダを消化するためのタクトタイムと工場の目標値であるサイクルタイム

  1. タクトタイム
    タクトタイム(T/T)がオーダ数量をこなすのに1個あたり何秒かかるかという顧客(トヨタ)重視の考え方(上意下達)。

    • タクトタイム=稼動可能時間÷日当たりオーダ数量
  2. サイクルタイム
    サイクルタイム(C/T)は自社の生産設備の標準能力という自社(下請工場)重視の指標で、生産管理部が立案した来年度の予定稼働時間と目標生産数から算出

    • サイクルタイム=目標稼働時間÷目標生産数
      • サイクルタイム>タクトタイムなら能力不足(欠品)
      • サイクルタイム<タクトタイムなら能力過剰(在庫)

【重要】トヨタ生産方式では時間ベースの負荷率、プレス工場の現場ではストロークベースの負荷率

  1. トヨタ生産方式の負荷率(時間ベース)
    • 負荷率=(生産数量xサイクルタイム)/稼動時間
      =(ストローク数x取数xサイクルタイム)/稼動時間

      • 品目によってストローク数は変わるので単位は時間
  2. プレス工場の負荷率(ストローク数ベース)
    負荷率=ストローク数/(GSPHx稼動時間)

    • 段取時間や停止時間を含めた1時間当たりのストローク数であるGSPH(Gross Stroke Per Hour)という機械能力のうち、オーダ数量を消化するためには機械を何回動かすか(何ストロークさせるか)という機械本位の考え方で負荷率を計算。
    • 個数(何個生産できるか)とか時間(何時間動かすか)に換算することなく、需要(オーダ数量)を消化するために必要なストローク数が供給能力(何ストローク動かせるか)に収まるかどうか、収まらなければ何ストローク分の残業を稼動時間に積み上げればよいか、残業でも足りなければ土日に何ストローク分の救出を入れればよいか、というストローク数ベースの考え方。

負荷計算を月末日付納期で行う場合、月末日付のライン能力に対する負荷が計算され、月単位で見ればOKだが日単位では見られない。

  1. MRPとスケジューラーの負荷計算の違い
    1. MRP
      • 品目ラインマスタに品目ごとラインごとにサイクルタイムを設定
      • L/Tずらしでかかった日に「オーダ数量xサイクルタイム」分の負荷を山積みする(日単位の山積み⇒週末のやりたいことリスト)
      • ラインマスタの設備能力(Facility Capacity)15時間に対して、品目ラインマスタの単位数量(Unit Qty)1時間の標準負荷(Standard Load)200個を設定する場合、MRPでは主ラインにのみ割り付き代替ラインには自動で割りつかないので、代替ラインに標準負荷をセットする意味はない。
    2. スケジューラー
      • 製造BOMで品目ごとラインごとにサイクルタイムを設定。
      • 負荷100%の範囲で「オーダ数量xサイクルタイム」分の時間を占有(時間軸の占有⇒セミナーのアジェンダ)
      • 代替ライン(主ライン以外)に標準負荷をセットすれば、主ラインが一杯のとき空いている代替ラインを狙ってサイクルタイムに基づいて割り付く。
  2. 日ばらしの意味
    • 負荷計算を月末日付を納期として行う場合、月末日付のライン能力に対する負荷が計算され、月単位で見れば月の稼働日合計に対する負荷が確認でき、これは日ばらしして計算される負荷の合計と同じ。
    • 週次の内示に基づいて負荷計算する場合は、月初の週で前月にかぶっている分だけ負荷が過少になり、月末の週では翌月にかぶっている分だけ負荷が余分。月単位の負荷を見るには日ばらしが必要。
    • 現実には月単位の内示を所要量展開した結果を稼働日で割り負荷を計算すれば十分(週次の内示はない前提)。

内部関数MaxとMaxIFとSumとSumIFの第一引数にオブジェクトを指定し、第二引数以降でTARGETを指定することで、第一引数のオブジェクトを指す。

内部関数Max, MaxIF, Sum, SumIFの第一引数にオブジェクトを指定し、第二引数以降でTARGETを指定することで、第一引数のオブジェクトを指します。

  • SumIF (ME.’親品目(再帰)’ .受注予定オブジェクト, TARGET.種別==’内示’,TARGET.数量)

HOLDERとFindNumberLとINPUTは仮想プロパティ逆変換式で、OTHERは品目紐付条件式で使う

  1. 表示式はカレントオブジェクトの自プロパティに対する表示変換だが、
    • 仮想プロパティ式はカレントオブジェクトの中の他プロパティを参照し、それぞれの逆変換式で書き込み可にする。
    • MEもHOLDERもカレントオブジェクトを指すが、MEで参照するとRead only(利用者オブジェクト)になりHOLDERで参照するとRead write(所有者オブジェクト)になる。
    • HOLDERは仮想プロパティ逆変換式でしか使えない。
    • MEは式の中で現在実行中のインスタンス(テーブル)のカレントオブジェクト(レコード)であり、外部から特定のオブジェクトを参照する場合にはProjectから子オブジェクトを参照していく。
  2. 表示式と表示逆変換式
    1. Format(ME.LET, ‘M月d日 23:59’)
      • 表示式で自プロパティである納期の時刻を固定するとRead Onlyになる。
      • 表示式: DateF(GetYearPart(ME.最遅終了日時), GetMonthPart(ME.最遅終了日時), GetDayPart(ME.最遅終了日時),23,59,59)
    2. FindNumberL(INPUT,1)
      • 表示逆変換式によってRead writeにする(但し直接Editするとおかしくなるのでカレンダーコントロールから選択)。
      • FindNumberLは文字列INPUTの左から1番目の数字を取得し、INPUTは表示式または仮想プロパティ式に入力された文字列をあらわす。
      • 表示逆変換式: DateF(FindNumberL(INPUT,1), FindNumberL(INPUT,2), FindNumberL(INPUT,3), 23,59,59)
  3. 仮想プロパティ式と仮想プロパティ逆変換式
    1. ME.オーダ数量+’個’
      • ユーザー定義プロパティの仮想プロパティ式でRead Onlyのプロパティを作成。
    2. FindNumberL(INPUT,1)
      • 仮想プロパティ逆変換式でRead writeにして、数量を変えたり’個’を消したりしてみても、仮想プロパティ式が効いており、オーダ数量自体を変更しない限り元に戻る。
    3. HOLDER.オーダ数量=FindNumberL(INPUT,1)
      • 仮想プロパティ逆変換式から他プロパティであるオーダ数量を変更する。
  4. 品目紐付き条件式で同一オブジェクト内の2つのレコードオブジェクトの値を比較するとき、ME.オーダ.仕様1==OTHER.オーダ.仕様1とする。

SSEE(Start-Start End-End)は前工程と後工程の開始と終了を合わせEES(End-Each-Start)は分割された後工程を前工程の途中から開始

  1. SSEEは前工程と後工程の開始と終了を関連付けますが、後工程が早く終わる場合に使用します。
  2. EESは、後工程が分割(Each)されているとき、前工程の途中から作業開始します。

製品の出荷3日分を1製造ロットとしてまとめるためにまとめ期間3日・まとめサイクル週・まとめ開始日月曜日にする

「まとめ(Rounding)」とは納品する分をまとめて製造する製造まとめと、使う分をまとめて調達する購買まとめがあるが、出荷は顧客の意向なのでまとめられない。

  1. 出荷3日分をまとめて製造するには、製品の出荷3日分を1製造ロットとしてまとめて製造指図を発行するということなので、まとめ対象は最終工程の出力品目である製品である。
  2. 同様に材料所要量(投入数量)10日分を1購買ロットとして購買指図を発行する場合、まとめ対象は購買オーダの出力品目である材料である。
  3. まとめ期間を3日、まとめサイクルを週、まとめ開始日を月曜日にすると、月火水と木金の出荷をまとめた製品の製造指図を生成する。

段取り時間を主資源に設定すると機械を止める内段取りとなり、副資源に設定すると機械を止めない外段取り

  1. 金型も作業者も主資源を動かすための制約条件であり、段取り時間を主資源に設定すると機械を止める内段取り(Internal Setup)となり、副資源に設定すると機械を止めない外段取り(External Setup)となる。
  2. プレス機の金型の交換を、内段取りの外段取り化と段取りの標準化によって時間短縮し、10分以内にを完了することをシングル段取りと呼ぶ。
  3. 設備能力に余裕があっても金型や作業者などの副資源の影響が生産計画に及ぶ
    =副資源を設定することによって設備の生産計画の割付順序に制約をつける。
  4. 前作業が完了してから後作業を開始するという制約は、前後の作業に共通の副資源を設定することで、シリアルな生産計画を作成する。

フォワードで最遅終了日時を越える時に強制割付にして負荷オーバー時期を確認し、バックワードで割付け開始日時を超えた時に強制割付にして期間内の負荷オーバーを確認

  1. 強制割付とは期間内に収まるように無限能力で無理やり割付けることであり、無視とは文字通り何も考えず期間内には有限能力、期間外には無限能力で割付けることです。
  2. フォワード割付けで時間制約違反(最遅終了日時を越える時)する時に限って強制割付(無限能力)にすることで、負荷オーバー(能力ショート)の資源と時期を確認します。
  3. バックワード割付けは納期を基準に考えているため納期遅れは発生せず、割付け開始日時を超えた時を強制割付にして山積みさせれば、期間内でどれだけ負荷オーバーしているか確認できます。

【重要】全体バックワード後その日の朝一番からフォワード割付直し、全体フォワード後ボトルネックの前工程のみバックワード割付直し

  1. 全体バックワード後その日の朝一番からフォワード割付直し
      1. バックワードではオーダリストからオーダ収集&オーダ絞込&オーダ展開して作業作成し、フォワードでは既存の作業リストから作業収集&作業絞込&オーダ割付/紐付を行うという複合計画パラメタになる。

    backforward

      1. 現資源をフォワードで割付直す際には、最早開始日時にStartOfNextDay(ME.製造開始日時,0)で、始業時刻より前に割りついてはダメ=0日後の開始時間=その日の朝一番から割り付ける。
      2. また現資源のディスパッチングは開始日時の早いものから割付けるので、作業着手時刻(前回の製造開始日時)⇒前回ディスパッチング順の指定する。

  2. 全体フォワード後ボトルネックの前工程のみバックワード割付直し
      1. 生産工程にボトルネックが存在する場合、フォワード割付を行うと前工程に待ち時間が発生するので、作業絞込みで前工程のみバックワードで割付直す。

    1. オーダ収集&オーダ絞込&オーダ展開で親の計画パラメタにオーダリストと作業リストを生成し全体をフォワードで割付ける。
    2. ボトルネックの前工程のみ作業収集&作業絞込&オーダ割付/紐付で現資源に対してバックワードで割り付け直す。

【重要】オーダ収集と作業収集でリストを生成し割付解除、オーダ展開で作業入出力指図を生成しオーダ割付/紐付で作業使用指図を生成

子であるコマンドで、オーダリスト⇒作業リスト⇒作業(作業入力指図と作業出力指図)の順番で生成し、親オブジェクに保存し、オーダ割付/紐付けで親オブジェクトの作業を割付ける(作業使用指図)。

  • 親:デフォルト計画パラメタ(オーダリストと作業リストが保存される)
    1. 子:オーダ収集コマンド⇒オーダリストを生成
    2. 子:オーダ絞込みコマンド
    3. 子:割付解除コマンド
    4. 子:オーダ展開コマンド⇒オーダリストから作業リストを生成し、そこから作業入力指図と作業出力指図を生成。
    5. 子:オーダ割付/紐付けコマンド⇒割り付けることで作業使用指図を生成。

schedulingcommand

  1. オーダ収集と作業収集
    オーダテーブルからオーダリストを生成するのがオーダ収集で、作業テーブルから作業リストを生成するのが作業収集であり、リストは親の計画パラメタに保存されます。

    1. オーダ収集
      • オーダ収集(Prepare for assignment):オーダテーブルからオーダリストに収集
      • オーダ絞込み(Filter orders):オーダリストから絞込み
    2. 作業収集
      • 作業収集(Upload operations):作業テーブルから作業リストに収集
      • 作業絞込み(Filter operations):作業リストから絞込み
  2. 割付解除
      割付け解除(Unassign all):作業リストの作業を未割付

    • 計画数量の修正や実績入力後に、作業ステータスが「割付済み」のまま再度リスケジュールしても何もしないので、前回と同じ結果になるだけです。
    • よって一旦割付解除により作業のステータスを「未割付」に戻し、作業収集してからオーダ割付/紐付けで更新を反映させたスケジュールを作成します。
  3. オーダ展開(Explode orders
    1. オーダリストから作業リストと作業生成(作業入力指図と作業出力指図)
      • オーダー展開は自動補充機能で、オーダリストからBOMを参照しながら作業(作業入力指図と作業出力指図)を生成する。
    2. BOMを参照し自動補充
      • 受注オーダの作業入力指図(入力品目)の不足分の製造オーダ(MPS)を子オーダとして生成し、MPSの作業入力指図の不足分の製造オーダを孫オーダとして生成
      • 対象は自動補充設定のある受注オーダ(製品)、製造オーダ(仕掛品)、購買オーダ(材料)、在庫オーダ同士、または自動補充のない品目でBOMの繋がりのある品目の製造オーダ同士。
    3. オーダ間の紐付け
      • リスケジュールの結果として生成されるオーダは、紐付けオブジェクトクラスによって作業同士の紐付きに、さらに出力指図と入力指図の紐付きとして、紐付けオブジェクトテーブル(Peg table)という形に実体化される。
  4. オーダ割付/紐付け(Assign/peg orders
    作業リストから作業使用指図を生成し割付け

    • ディスパッチングルールと資源評価のプロパティを見ながら作業使用指図を生成し、作業リストから作業割付けする。
    • 最適な割付結果を模索する方法は、仮割付けで作業をすべての候補資源に割付けてみて評価値を計算し、評価値の最も高い候補資源の時系列上に実割付けを行う。
    • 追加評価式が呼ばれるときにはまだ作業が割り付いていないので、仮割付けの結果に基づいて追加評価を行なうためには、0.1/ME.評価時-対象資源.表示順のように、TentAssignではじまる割付評価式を用いる必要がある。

オーダテーブルから変更できるステータスは未着手と完了のみである理由は、オーダテーブル上からはどの作業まで着手済みなのか特定できないからで、着手済みは作業テーブルからのみ設定可能で、初工程作業を完了させるとオーダは着手済みになり、最終工程まで完了させると完了になるが、オーダを未着手に戻しても作業は完了のまま

  1. 作業ステータスとオーダステータス
    • 作業ステータスは、計画段階の「計画済」、製造指図出力段階の「指示済」または「確定」、製造実績段階の「着手済」または「完了」があります。
    • オーダテーブルから変更できるステータスは「未着手」と「完了」のみであり、オーダテーブル上からはどの作業まで着手済みなのか特定できないので「着手済み」は作業テーブルからのみ設定可能です。
  2. 作業ステータス変更時のオーダステータスの変化
    • 初工程作業を「完了」させると該当オーダは「着手済み」になり、最終工程作業まで完了させるとオーダは「完了」になりますが、オーダを「未着手」に戻しても作業は「完了」のままです。
    • オーダを完了させるとすべての作業は完了になり、作業をすべて「未着手」にするとオーダも「未着手」に戻ります。

製造予定表(月次生産計画)と受注予定表は開始日ベースの供給で、PSI表が終了日ベースの供給で、製造L/Tが0日の場合は製造予定表とPSI表の供給が一致

  1. 供給:この日にある出力指図の数量の合計
  2. 需要:この日にある入力指図の数量の合計
  3. 在庫:この日の終了時の、在庫の数量

  1. 受注予定表と製造予定表の関係
    1. 受注予定表は、需要(内示・確定受注日=出荷日)と供給(製造指図開始日)であり、供給だけを切り取ったものが製造予定表=供給(製造指図開始日)である。
    2. 製造L/Tが日またぎすることによる製造指図発行済みかつ未完了の状態が製造残で、受注即製造指図発行、完了即出荷と考えると受注残とも言える。
  2. 製造予定表とPSI表の関係
    • 製造L/TがN日で開始日と終了日が日をまたぐ場合は、供給数量が生産能力に応じて日別に按分されるが、製造L/Tが0日の場合は、供給日(IN)と需要日(OUT)が同じになるので製造予定表の製造(開始日ベース)とPSI表の供給(終了日ベース)が一致する。
    1. MRPで安全L/T(手番)N日、製造L/Tを0日に設定している場合は供給日(IN)と需要日(OUT)が同じになるので製造予定表の製造とPSI表の供給が一致しますが、製造開始日と終了日が日をまたぐ場合は供給数量が生産能力によって日別に按分されます。
    2. つまり製造予定表の製造は開始日ベース、PSI表の供給は完了日ベースの考え方。
    3. PSI表は受注予定表と製造予定表を補完するため追加された機能。
  3. 生販在システムと1セットでまとめるのは、3つのシステムで供給(IN)-需要(OUT)=現在庫(Balance)を管理できるから。
  4. 生産管理システムで実績ベースのPSIを作成する場合は、製造実績テーブルと投入実績テーブルから該当品目を日別に集計するが、スケジューラーで計画ベースのPSIを作成する場合は、作業出力指図と作業入力指図から該当品目を日別に集計する。

1対1紐付けにより実績に合わせて後工程のオーダー数量を自動調整するのでロットまとめとは矛盾する

  1. 1対1紐付と1対N紐付
    1. 1対1紐付けするということは、自作業に紐付く相手は1作業のみであり、親子の必要数量が1個である限り、基本全ての工程作業の製造数量(ロットサイズ)は同じである必要がある。
    2. ロットサイズが工程ごとに異なる場合、前工程と自工程の必要所要量をマッチさせるためには、1対Nで紐付かざるを得ない。
  2. 前工程の実績で後工程の計画数量を上書きする方法
    1. 1品目複数工程で1オーダから複数作業を生成し実績入力済み作業の数量固定レベルを上げて後工程作業の計画数量に反映させる。
    2. 1品目1工程で自動補充を1対1にして、前工程オーダが他のオーダと紐付かないようにする。
  3. MRPとスケジューラーの違いといえば、無限能力山積みと有限能力山崩しの違いが有名だが、計画に対する実績の差異の扱いという点で見た場合、MRPは基準生産計画の数量ありきで、製造オーダーの数量は基準生産計画の数量を満たすように決まるのに対して、スケジューラーは実績に合わせて後工程のオーダー数量を自動調整する機能がある。

サイクルタイムプラン(時間軸の占有)は負荷平準化しながら作業に順番をつけるカレンダー重視で、キャパシティプラン(日単位の山積み)は1日のキャパの範囲にロットを山積みするキャパ重視

  1. サイクルタイムプランは、ラインを負荷平準化しながら作業に順番をつけて作業日程計画を作成するカレンダー(横軸)重視の方法。
  2. キャパシティプランは、1日のキャパ(設備能力)の範囲内に作業ロット(標準負荷)を山積みしていき、今日はそれぞれのラインでこれだけの作業ロットを消化してください、という資源キャパ(縦軸)を重視したより現実的な方法である。

【重要】内示と確定受注の置き換えのプロセス

  1. 販売手配区分
    1. 発注:受注がそのまま発注(直送や受注ベースの発注)。
    2. 引当後発注:受注に対して在庫が十分なら自動引当、不十分ならそのまま全て発注。
    3. 引当:受注に対して在庫から自動引当、不十分なら何もしない(MTS生産)MRP用の日次生産計画に内示を登録し、出荷指示に繋げるための受注登録を別途行う必要がある。
    4. 所要:受注が在庫と紐付かずそのまま日次生産計画へ(MTO生産)
  2. 内示所要調整(Daily MPS2)を適用し販売手配区分を「なし」
    1. EDIデータ一覧から受注登録された受注オーダは、製品在庫を引き当てた後の受注残として内示所要調整にコピーされ、生産スケジューラーの「受注オプション+製品に在庫1対1自動補充」で受注残のMPSを生成する動きと同じになる。
    2. 販売手配区分が「所要」だと在庫を引当てない、「引当」だと在庫不十分だと何もしないので「なし」にする。
  3. MRP運用が難しい理由
    1. 「製造ロットサイズ」と「リードタイムずらし」のせいで、どの製造オーダがどの所要に紐付いているか見えにくくなる
    2. 内示を確定で置き換える運用が難しい。
      1. 前回内示レベルでもらった情報が今回確定受注になっている。
      2. 今回の確定受注に前回の確定受注が含まれている。

    というように客先からのオーバーラップした確定受注情報と内示情報を、システム上では二重登録にならないよう考慮しなければならない点

  4. 「内示を確定で置き換える」ための具体的な方法
    • 「新規の確定受注のみを追加して内示は洗替する」ことであり、理屈ではこれにより確定受注の二重登録と内示の二重登録が同時に防止される。
    • 直近の製造指図を発行し、製造残(製造指図発行済み未着手)を受注残から差し引くことで、余分な生産を行わないようにする。

受注オーダと生産計画は1対1でなくロットサイズと製造L/Tのため確定オーダに対してどの計画を確定すべきか難しく、計画外で工程ごとに指図を発行するようになる

  1. MRPは受注から計画(指図)を生成するが、ロットサイズと製造L/Tが受注と生産の紐付きを複雑にし、確定オーダが2週間でも確定する計画は直近部分のみなので、内示が確定オーダに差し替え(確定オーダで内示を引き落とす)られるたびに、1対1に紐付いていない計画のどれを今回確定すべきかという問題が発生するため、生管は計画外で工程ごとに指図を発行するようになる。
  2. ところが計画外指図は手間がかかり、現場も目標生産数があるのに指図に縛られるのは負担なので、生管と現場の思惑が一致し、計画外製造実績という運用になりがちになる。
  3. この場合、受注(需要)と製造(供給)の紐付きの管理が難しくなり、現場は独自裁量で月次生産計画の帳尻を合わせ、その結果設備能力計画が現場に反映されない、という生管と現場の乖離が発生する。
  4. これが受注に基づき生産計画(クラス)を作成し、製造指図(実体)に落とし込み実績入力(プロパティの値)するという流れが大切である理由です。

【重要】翌月内示のための正味従属需要を計算するには、内示以外に残当月オーダと受入確定量と現在の在庫情報が必要

独立需要と従属需要

  1. データのレベル
    1. 所要(独立需要)
    2. オーダ(未確定の従属需要)
    3. オーダの確定
    4. 製造指図または発注情報
  2. 従属需要(製造オーダと購買オーダ)を作る方法
    1. MRP(ステータス「未確定」)
    2. 販売手配区分が発注の受注登録
    3. オーダ詳細一覧からのインポート(ステータスは「マニュアル」)

所要量展開

  1. 「月内示に必要な材料の正味従属需要を計算するに月末時点の製品と材料の予測在庫を引当た上での需要を計算する」ということは
    1. 現在から月末までのオーダ
    2. 現在の製品と材料の在庫
    3. 月末までの受入確定量

    という3つの情報を元に月末在庫を予測しているのと同じこと。

  2. ロットまとめと製造L/Tが正味従属需要の計算を難しくする
    • ロットまとめなしの条件では、残当月製品オーダを元に残当月材料投入(予定)を計算できるが、製造ロットまとめがあると「残当月製品オーダ=残当月製品生産(予定)」は成立せず、購買ロットまとめがあると「残当月材料入荷(予定)=残当月材料投入(予定)」が成立しない。
    • 製造L/T0日の条件で翌月内示に必要な材料従属需要を計算するために引当てるべき在庫は月末在庫だが、製造L/Tがある場合は「月末日-L/T日数」時点の在庫になる。
  3. 所要量展開が原価計算より難しい理由
    • システムのカットオフが難しい最大の理由は、カットオフ時点でも過去に入力されたオーダが存在し継続中であるからであり、計画系システムのカットオフが実績系システムに比べて難しい理由は、カットオフ時点でのデータの管理が実績系に比べて不明確だから。
      1. 実績系:受注残、発注残、発行済みインボイス等⇒明確
      2. 計画系:製造残(発行済み製造指図)⇒不明確(指図を出していないところもある)
    • 原価計算は実績ベースなので「月末在庫金額を押さえて材料発生費用を計算する」ことも「材料発生費用を押さえて月末在庫金額を計算」することもできるが、所要量展開は予測ベースなので「今月末在庫数量を押さえて当月投入予定数量を計算する」ことができず、当月オーダ数量をもとに「当月材料投入予定数量を押さえて今月末在庫数量を予測する」しかできない。
    • その上、残当月材料投入(予定)を計算するにあたって、ロットまとめとリードタイムが正味従属需要の算出を難しくする。

【重要】MRPは納期遅れオーダも受入確定量として前倒しして紐付けることで余分なオーダを生成しない。

  1. MRPはバックワードで前倒し(早くする)機能
    • MRPはMPSを元に所要量展開を行い、在庫を差し引いた正味所要量を計算すると同時に、L/T分だけバックワード割付で「前倒し(早くする)」することで購買オーダや製造オーダの発行タイミングを計算する。
    • ASPは初工程を基準にフォワード割付で「後倒し(遅くする)」ことが可能で、MPSのズレが納期遅れとして確認できる。
  2. MRPは受入確定量を前倒しすることで余分なオーダを生成しない
    • ただしMRPの基本は正確な正味所要量の計算にあるため、所要量の不足は時間制約違反を無視して、納期遅れ(時間制約違反)したオーダも「前倒し」して紐付けることで、余分なオーダを生成しない。
    • この受入確定量で余分なオーダを出さないようにする機能がシステムを運用する人間から見たとき、オーダ間の紐付けを見づらくしてしまう。
    • 生産スケジューラーではオーダが時間制約違反で確定すると、前後作業がひきつけられて移動し、割付開始日を越える過去日のオーダは「無視」され突き抜け無限能力で割付けられるか、「強制割付」され計画基準日内に無限能力で山積みされることになる。

ハンディターミナル導入は実績入力の簡素化と間違い防止が目的

実績入力の「簡素化」と「間違い防止」が目的

  • 入庫(現品票と入庫先棚のバーコードをスキャン)
    1. 入荷・検査後、未検査エリアから倉庫へ入庫(移送指図)
    2. 製品の製造完了・検査後、未検査エリアから倉庫へ入庫(移送指図)
    3. 在庫戻しのため、製造現場から倉庫へ入庫(移送指図)
      • 製造指図の実績を上げて完了させることで、引き当たっていた材料がリリースされる。
  • 出庫(現品票と入庫元棚のバーコードをスキャン)
    1. 製造指図後、倉庫から製造現場へ材料出庫(出庫指図)
    2. ピッキングリストより、製品倉庫から預け場所へ出荷(出荷完了実績)。
    3. 廃棄のため、倉庫から廃棄倉庫へ出庫(移送指図)

仕入返品は(仕入返品情報登録⇒仕入返品実績登録⇒仕入インボイス登録)

締処理前

  1. 確定解除(仕入インボイス登録)
  2. 仕入返品情報(入荷実績)
    • デフォルトでインボイスNOがあるが、インボイス確定後なら別インボイスNOに書き換え(マイナスインボイス) 更新で仕入返品情報が作成される。
  3. 仕入返品実績(仕入返品一覧)⇒在庫が消える
  4. 仕入インボイス一覧(インボイス登録)
  5. インボイス登録(更新・確定)
    • 元の入荷数量行対して返品数量行が追加されている(金額はマイナス)ので更新・確定。

締処理後

  • 「仕入返品情報登録」から締処理前後で可能。
    • Dr. -仕入 30 / Cr. – AP 30
    • または
    • Dr. AP 30 / Cr. 仕入 30
  1. 仕入返品情報登録(更新)
  2. 仕入返品一覧(仕入返品実績)⇒在庫が消える
    • インボイスNOを入力するが、締処理前の未確定インボイスであればOKだが、締め処理後の確定済みインボイスの場合はエラーが出るので、インボイスNOを新規に書き換える。
  3. 仕入インボイス一覧(インボイス登録)
  4. インボイス登録(更新・確定)
    • マイナスインボイス発行。

出荷返品は締処理前なら(出荷返品登録⇒出荷インボイス登録)、締処理後なら(返品受注登録⇒出荷返品登録⇒出荷インボイス登録)

  1. 締処理前
    1. 10個出荷し100売上。
    2. 2個NG発覚、出荷返品処理により返品倉庫に2個入荷。
    3. 売上・Invoiceキャンセルと出荷返品処理し「出荷100-返品20」のInvoice再発行、売上登録。
    4. 代替品2個の新規受注登録・出荷処理を行い備考欄にどの出荷に対する代替出荷か明示する。
  2. 締処理後
    • これが月締め後の返品であれが、返品受注処理にてマイナスInvoice、マイナス出荷、マイナス売上を計上。
    1. 前月の10個出荷し100売上。
    2. 2個NG発覚、受注返品処理でマイナス2個受注
    3. マイナス2個のInvoice発行
    4. 出荷返品処理でマイナス2個を計上することで返品倉庫に2個入荷。
    5. マイナス20の売上登録。

    出荷返品処理でマイナス売上実績を計上することにより、原価計算の売上原価が正しく修正される。

在庫計上のタイミング

在庫数量照会画面(Inv Qty Reference)の在庫ステータス3種類が見られるが、参照した時点の現在庫なので、日付指定の現在庫を見たい場合はInventory Summary Sheet(在庫集計表)を日付指定で出力する。

  1. Inventry Qty(在庫数量)
  2. Available Qty(引当可能数量)Arriving Entryで反映され、Reservation(在庫予約)を使わなければ1と2は常に同数
  3. Outgoing Qty(払出可能数量)Purchase Entryにて反映

FIFOや移動平均法での制約

  • 売りの場合は、Shipping EntryのみSales Entryなしで在庫反映(出庫は単価に影響しないから)
  • 買いの場合は、Purchase Entryなしでは在庫に反映されない。(在庫照会画面からAvailable Qtyとして参照できるがレポートに表示されない)

総平均法

  • 単価はInventory Transaction List(在庫受払表)でのみ表示され、在庫数量照会画面には出ない。
  • Balance Updateでは月次のGross Averageで計算される。
  • 月中でもGross Averageに基づいてInventory Transaction List(在庫受払表)を出力可能(原価計算のルーチンがある)。
  • Purchase Entryなしで出庫可能(マイナス在庫許容の場合)。
  • 月末に単価確定し、Sales Summary Sheet(売上集計表)の粗利も確定する。

直送は入荷/仕入と出荷/売上をまとめて計上する。

  1. S/O Entry(受注入力)
  2. P/O based on S/O(受注展開発注入力)
    Direct Shipping(直送)
    Succeeded S/O(引継)
  3. D/S Entry (直送入力)入荷仕入/出荷売上をまとめて計上。
    仕訳承認(Dr.仕入 Cr.AP)と(Dr.AR Cr.Sales)が必要

得意先からの返品が発生した場合には売上返品と仕入返品の2つを実行する必要があり、売上返品のみ行った場合、本来在庫残がないはずの直送用仮想倉庫に在庫が残る。

積送品は在庫管理されない。

  1. 船積時に入荷画面(Arriving Entry)から積送中チェックボックスをチェックする。入荷データ検索画面(Arriving Data Search)でステータスin-transitをチェックして検索すると出てくるが在庫数量照会画面(Inv Qty Reference)には表示されない。
    積送品で債務計上する場合、仕入登録画面ではなくAP登録画面から入力する。

    • Dr. GIT / Cr. AP
  2. インドネシアに到着時に入荷画面から積送中チェックボックスをはずす。
    • ACの振替伝票でGITをGoodsに振替える。
      • Dr. Goods / Cr. GIT
  3. 積送品は在庫管理されないので、管理したければ積送品倉庫を作成し入荷実績を上げる、または出荷時に積送品倉庫に在庫移動するしかない。

締処理の流れ

  1. 在庫締処理(Inventory Closing)
  2. A/R, A/P科目の外貨評価換算(FC Revaluation AR/AP)
  3. G/L科目の外貨評価換算(FC Revaluation)
  4. A/R, A/Pの締処理(AR and AP Entry Closing)
  5. 会計締処理(Journal Entry Closing)
  6. 在庫月度更新(Inventory Balance Update)
  7. 会計月度更新(Accounting Balance Update)

ビールゲームでは発注時に在庫コスト(在庫過多)と機会損失コスト(受注残)を恐れる心理を、需要予測(P/O発行時または製造指図発行時)で克服する

beergame

  1. 部分最適化と全体最適化
    • 生産管理システムは工程ごとに管理を分けることで部分最適化するが、工程間を隔てる壁がモノの流れと情報の流れを滞留させ、リードタイムが緩くなり仕掛在庫が増える要因となるため、生産工程を串刺し状につなげ生産に流れを作るために、生産スケジューラーで生産拠点の全体最適化を行い、L/Tを短縮する。
  2. 在庫コストと機会損失
    • 小売店⇒二次卸⇒一次卸⇒工場というサプライチェーンの中で、意思決定が働くのはP/O発行(製造指図発行)であり、受注残を消化(機会損失を減らす)しようとして発注過多が連鎖、または在庫コストを減らそうとして発注過少が連鎖するため需要予測が重要。
    • 発注するときの「在庫切れたら怖いな、でも注文しすぎると余りすぎるし。どれくらい受注来るか予測が難しい。しかも発注して最短4週間で入荷するけど業者で在庫切れならそれ以上かかるし」という心理。
    • 2週間前に発行されたP/Oの受領時は、在庫から出荷または入荷即出荷することで、購買L/T4週(P/O2週+モノ2週)、製造L/T4週(指図2週+モノ2週)をキープするのがベスト。
  3. ビールゲームでのサプライチェーンの機能
    1. 販売業務(左)
      • ③移動:得意先から前週に発行された注文書を2週目開始マスへ移動
      • ②注文書を見る:得意先からの注文書の受領
      • ②出荷:得意先への出荷
      • ①移動:得意先へ前週に出荷した未着品を4週目開始マスへ移動
    2. 購買業務(右)
      • ④注文:仕入先への発注書を発行(意思決定余地あり)
      • ①入荷:仕入先からの入荷
    3. 製造業務(右)
      • 移動:工場から前週に発行された製造指図を2週目開始マスへ移動
      • 製造指図を見る:工場からの製造指図の受領
      • 出庫:工場への出庫
      • 移動:工場へ前週に出庫した未着品を4週目開始マスへ移動
      • 製造指図を発行:現場への製造指図を発行(意思決定余地あり)
      • 入庫:現場からの入庫

荷受人に対してインドネシアの船会社発行のB/Lよりも日本代理店からのArrival Noticeが先に届いてしまう場合、船会社で発行済みB/Lをサレンダード(貨物が荷受人の荷物であるという船会社による裏書)にしてFAXで日本の荷受人に送信

  1. Bill of Landing(船荷証券)は、Invoiceとパッキングリストと原産地証明書COO(Certificate Of Origin)に基づき、インドネシアの船会社が発行する貨物の引き受けを証明するものであり、輸出の場合B/L日付が売上計上日となる。
  2. 船会社がB/Lをカーゴに送り、カーゴが日本の荷受人(consignee)に発送するが、カーゴから船会社へのB/L発行フォローが遅れると、荷受人に日本の船会社代理店からArrival Noticeが到着したのにカーゴからのB/Lが発送済み未着で、貨物の受け取りができない。
  3. この場合、船会社による発行済みB/Lをサレンダード(貨物が間違いなく荷受人の荷物であるという船会社による裏書・テレックスリリースとも言う)にして、郵送ではなくFAXで日本の荷受人に送信するよう、カーゴ会社に依頼する。

SmallTalkの構造とパッチの反映プロセス(visual.exeがvisual.imまたはruntime.imを実行する)

Cincom社のVisualWorks(visual.exe)は開発言語Smalltalkを使った開発環境(GUI、クラスライブラリ、DBインターフェイス等)で、アプリ(拡張子imのイメージファイル)を生成、実行する。

  • visual.exe(vw7.6フォルダC:\vw7.6\bin\win)とvisual.im、visual.cha(アプリフォルダC:\MCFrame\MCFrame38000\image)の関係
    1. visual.exeはバーチャルマシンでOSの違いを吸収することでイメージファイルを変更せずイメージ(アプリケーション)が動作する。
    2. visual.imはクラスライブラリのバイナリイメージで作成したクラスのコードやコンパイルされたバイナリが保存される。
    3. visual.chaは、visual.imから変更された内容の全てが記録され開発途中でアプリケーションエラーが発生しても、すぐ直前(Acceptを実行した場所)まで戻ることができる。
  • パッチ適用順番
    各モジュールごとに①SQLスクリプトによるDB修正・②STファイルによるイメージ(visual.chaとvisual.im)の修正・③メッセージカタログlblの追加の3つの作業が発生し、最後に④メッセージカタログlblをイメージに反映するために、FrameManagerのLocalChangerのMessageCatalogsから、各モジュールの解凍先に指定したパスC:\MCFrame\MCFrame38000\image\messageCatalogを指定してLoadを押す。

    1. SQLの修正スクリプトファイル(.sqlファイル)はUTF-8で記述されているので「set NLS_LANG=American_America.AL32UTF8set NLS_LANG=American_America.AL32UTF8」で環境変数をセットする。
    2. DBの変更(テーブル、トリガー、ストアドプロシージャー、ビュー)(SQLスクリプト .sql)
    3. イメージの修正(SmallTalkプログラムvisual.imとvisual.chaにstファイルをファイルインして修正)
    4. メッセージカタログの追加(オブジェクトに送信するメッセージを追加)lblファイル
    5. メッセージカタログをイメージに反映 lblファイルをvisual.imとvisual.chaに反映
  • 要約するとパッチ反映に必要なことは4つ
      1. DBの修正
      2. イメージの修正。
      3. メッセージカタログの追加。
      4. イメージにメッセージカタログを反映。

    これによってvw7.6フォルダ内のコアvisual.exeがイメージ反映後のviual.imを実行する。

  • リンク先と作業フォルダ
    コンパイルするとvisual.imがruntime.imに変わる。

      • Target(リンク先)
        C:\vw7.10.1\bin\win\visual.exe visual.im -inifile “C:\MCFrame\MCFrame38000\image\mcframe.ini” -color “C:\MCFrame\MCFrame38000\image\color.ini” -locale “C:\MCFrame\MCFrame38000\image\locale.ini”
      • StartIn(作業フォルダ)
        「作業用フォルダ」は、リンク先のプログラムが動作する際に一時的に使用する
        作業用のファイルを保存するフォルダ。
        C:\MCFrame\MCFrame38000\image

アプリ(Shipper)⇒ ADO(カーゴ)⇒ODBCやOLE DBプロバイダー (Forwarder) ⇒DB(Consignee)

  1. 開発アプリ(Shipper)からDBやExcel, Texfile(Consignee)にアクセスするにはODBC(DBのみ)やOLE DBデータプロバイダーという仲介人(Forwarder)に手続きをお願いするのだが、直接OLE DBとやりとりするのはややこしい書類手続きなど煩わしいのでADO(カーゴ業者)にやってもらう。
  2. AsprovaはODBCやOLEを直接サポートするが、開発アプリがDBにアクセスできるか否かはドライバーがADOやPDOをサポートするか否かにかかっている。
  3. ODBCはRDB限定だがOLEはExcelやTextとリンクできる。

最新情報
お届けします

Twitter で