機能 - みる会図書館


検索対象: グラス片手にデータベース設計
89件見つかりました。

1. グラス片手にデータベース設計

さらに、これらの計画 / 実績に対して、管理者がきちんと承認することが求められる ケースもあります ( 内部統制対応で増えてきています ) 。 「計画どおりにモノを作り、きちんと実績を登録する」ことが、意外に手間のかかる大 変な作業であることがイメージできたでしようか。逆の言い方をすると、こがきちん とできていれば、何かあった場合に素早いアクションをとることや、管理レベルを上げ るための分析 / カイゼン活動などが容易になるわけです。 「計画どおりにモノを作り、きちんと実績を登録すること」が、品質管理の一番の基 本であると筆者は考えています。 ミスをなくすための機能 " について説明します。 検査結果の管理のところで述べましたが、検査結果によりある在庫 ( ロット ) が不合格、 あるいは不良品となったとします。この不良品となったものが、システム上で自由に使 用できてしまってはせつかく不良にした意味がありません。不良品でも見た目は変わら ないケースもあるので、システムから使うことができる在庫 ( ロット ) を作業者に明示 することが重要になります。 図 9 を見てください。第 5 章の MRP のところで述べたように、 MRP はある歩留を見 込んでオーダを生成します。しかしながら歩留は当然プレがあるので、実際の状況 ( 受 入検査 / 工程検査の実績 ) を反映し、そのうえで最新の情報で引当を行なうような機能 があると便利で、かっミスを少なくすることが可能になります ( リードタイムなどの関係 上、このような引当ができない工場ももちろん存在します ) 。 同様に不良品だけではなく、例えば有効期限の切れた在庫は引当ないような機能も有 効となります。 このように、「ミスを防止する」ための機能を生産管理システムに実装することにより、 ユーザーの品質レベル向上に寄与することが可能になるわけです。 166

2. グラス片手にデータベース設計

実績情報をタイムリーに入手してそれを基に計画を日々見直すことにより、計画のプ レを補正していこうという考え方であり、計画変更の多い業種、製品ライフサイクルの 短い業種などで、特に重要な機能になります。 PSI の実現のためには、以下の 2 点が重要になります。 まず、図 5 のように実績系の情報を販売管理システムより、正確かっタイムリーに入 手できることが前提条件になります。 また、「タイムフェンス」と呼ばれる、製造 / 物流のリードタイム、および計画立案サ イクルを考慮した「変更可能範囲」を指定できる機能を持っことが必須になります。 図 6 では、計画サイクルを 1 週間、月曜日にリリース ( それまでは計画は確定しない ) として、そのうえで製造 / 物流にかかるリードタイムを考慮して、本日から見てどの時 点から先の計画変更が可能であるかを表わしています。 この PSI の機能は、次に述べる MRP 処理を応用することで実現が可能になります。 販売計画 / 在庫計画 販売実績 / 実績 図 5 : PSI データ相関図 過去日 ( 火 ) ( 水 ) ( 木 ) ( 金 ) ( 土 ) 1 日 2 日 3 日 4 日 5 日 計画サイクル PS& 能 ・ラフカット 生産依頼 生産実績 生産管理 タイムフェンス 製造 LT ( 6 日 ) 計画変更可能 物流 LT ( 2 日 ) 6 日 要 1 3 日 ( 日 ) ( 日 ) 7 日 8 日 9 日 1 0 日 1 1 日 1 2 日 1 4 日 1 5 日 1 6 日 1 7 日 1 8 日 ( 月 ) ( 火 ) ( 水 ) ( 木 ) ( 金 ) ( 土 ) ( 月 ) ( 火 ) ( 水 ) ( 木 ) ( 金 ) ※製造リードタイムを 6 日、物流リードタイムを 2 日、計画サイクルを週次 ( 月曜日リリース ) とした場合 62 図 6 : タイムフェンスの考え方

3. グラス片手にデータベース設計

トに使用されているのかを調査することが必要になります。この機能は、先ほどとは逆 の原材料 / 部品から製品へのロットトレース機能になります。 この場合はある製品のロット ( 図④ / 品目 : モカキリプレンド 3 開 g ロット NO : MK3-1123 ) がこの原料ロットを使用しているため、この製品が製品在庫にある場合に はその在庫を押さえて出荷を取り止める、すでに出荷してしまっている場合には出荷先 に連絡するなどの対応が必要になります。 アプリケーションとしては、ロットトレース機能として上記の 2 つの流れを用意して おく必要があります。 トレーサビリティ ( ロットトレース機能 ) がどうして重要なのかがお分かりいただけ たでしようか。このような処理が可能になると、ここ数年で起こった食品製造業のトラ プルの何割かを未然に防ぐことができた、あるいは範囲を限定的に留めることが可能で あったことが想像できるのではないでしようか ( 恣意的な賞味期限切れの出荷などは、 この機能があってもどうしようもありませんが ) 。 「品質管理」を極める モカキリ包装材 モカキリブレンド ロット NO . ロット NO : ISR- 1 1 21 MKP-1 120 3 キリマンジャロ キリマンジャロ 生豆 生豆 ロット NO : ロット NO : KMJ- 1 1 01 KMJ- 1 1 01 不良ロットの影響範囲の特定 不具合理由の特定 ①問題のあった製品のロット NO を指定し、 使用された中間品や原材料 / 部品のロッ ト NO をトレースする ④影響が心配される製品のロット NO を特 定できたら、今どこにあるか、出荷され ているかを探索する ド レ 0 2 キ 3 ッ カロ モ 缶コーヒー レギュラー ロット NO : CCR- 1 1 21 在庫確認 ロ②業務用粉コーヒー ←ロット NO : BPC- 1 1 91 製造実績確認 ミルク ロット NO : MLK- 1 1 1 7 モカ生豆 ロット NO . MOK-1 028 アラビカ生豆 ロット NO ABK-1 105 ③品質に影響を与えた原因となる品目ロット NO を 特定したら、ほかのどの製品ロット NO に使用さ れたかを確認する ②使用された中間品や原材料 / 資材の ロット NO の製造実績や検査実績を 表示 / 確認する , ロ 検査実績確認 図 6 : ロットトレース業務の流れ 163

4. グラス片手にデータベース設計

注文が出ていても入荷されなかったり、工程で製造指図が発行されていてもオーダが キャンセルされたりする場合もあるので、上記のようなタイミングが一般的です。 しかしながら、品質管理担当が検査の予定を確認したい、あるいは検査のリードタ 162 キリマンジャロ生豆ロット NO:KMJ-IIOI) のロットが、ほかの中間品 / 製品のどのロッ 次に、この不具合の要因となる ( あるいはその可能性のある ) 原料 ( 図③ / 品目 : 情報を提供すること」がロットトレース機能の役割になります。 因か」をシステムで突き止めることはできないのですが、「原因を絞り込むための有効な 検査が 1 回目は保留で、 2 回目の検査で合格となっている ) 。実際に、「何が本質的な原 リマンジャロ生豆ロット NO : KMJ -110D で検査結果に問題点が見つかったとします ( 例 : ロットトレース機能を使って調査したところ、ある原料のロット ( 図 6- ② / 品目 : キ トレース ) と呼びます。 ン検索する機能をロットトレース機能 ( この場合は、製品から原材料 / 部品へのロット ます。このとき、このロットに関係あるすべての品目の製造 / 検査の実績をドリルダウ ギュラーロット NO : CCR-1121)0 このロットの製造および検査の実績を確認していき ある出荷した製品のロットに問題があったとします ( 図① / 品目名 : 缶コーヒーレ 図 6 はロットトレースの基本的な業務の流れを表わしています。 0 ロットトレース業務の流れ なんだかよく分かりませんね。図を使って説明していきましよう。 はその出荷先まで特定できること」となります。 ( 中間品 ) 製品の品目 / ロット NO が特定できる、さらには製品が出荷されている場合に NO により特定される原材料 / 部品 ( 中間品 ) について、それが使われているすべての その購入 / 製造単位 ( ロット (O) ごとに芋づる式に検索できること」および、「ロット NO により特定される製品について、原材料 / 部品の購入、製造、および検査の記録が トレーサビリティ ( ロットトレース機能 ) を一言 ( 厳密には二言 ) でいうと、「ロット 最近、トレーサビリティという言葉をいろいろなところで聞くようになりました。 0 ロットトレース機能 す。 で、検査予定情報としては発注情報 / 製造指図情報の作成時に作成するのがお勧めで イムが長い場合には先行サンプルを使って前倒しで検査を実施するケースなどもあるの

5. グラス片手にデータベース設計

賦率 ( 賃率など ) の計算を実施します。計算によって求められた配賦率を、直接設定す る機能も必要になります。 これらの処理を製品ごとに実行して「適正な」原価を設定していくわけなのですが、 例えば製品ごとに納得のいく結果が得られたとしても、工場単位ですべて集計した後に 材料費が予算を大幅にオーバーしてしまった場合などは、何回かシミュレーションを実 施できる機能があると非常に便利です ( 例 : ある共通部品を 1 円下げて再度シミュレー ションを実施してみる ) 。 このシミュレーション機能があると、計算結果を何パターンか保持しておき、最適な 原価を探っていくことが可能となります。 0 実際原価計算の流れ 図 IO に実際原価計算の流れを示します。 実際原価計算の流れについては先に述べたので詳細は省略しますが、標準原価計算 と併用する場合には、実際原価計算の処理の中で差額が計算されることになります。 生産実績 購入実績 投入実績 売上実績 、直接作業実績・・ 間接作業実績・ 入出庫情報・ 生産管理 実績データ 販売管理 実績データ 作業実績 収集 在庫・受払情報、 生産管理 販売管理 会計、経理 原価計算用 実績テーブル 経費予算データ ・製造原価集計 ・購入金額集計 ・操業時間集計 ・配賦額集計 ・原価差異の把握 数量差異 時間差異 価格差異 配賦率差異 一次配賦計算 配賦率計算 原価集計 原価差異 実際原価計算 品目 工程 品目工程 ス タ 構成表 設 作業能率 仕入単価 標準原価情報 ・実際原価計算時には、経費データと実績 データからの配賦率計算、それを用いた 実際原価積上を一度行ないます ・実際原価計算のみの実行も可能ですが、 標準原価情報があれは同時に原価差額を 計算します 図 10 : 実際原価計算フロー ( 東洋ビジネスエンジニアリング編日本能率協会マネジメントセンター 発行「図解でわかる生産の実務原価管理』より ) 共通マスタ情報 : 186

6. グラス片手にデータベース設計

COLUMN MRP と言うと「一昔前の古臭い生産管理」であると決めつける人がいます。また 「 APS と呼ばれる先進的なスケジューリングシステムを使えは MRP は不要」という 主張もたまに耳にします。しかしながら、筆者は「そのような人の頭の中こそ古臭い 固定観念に捉われているのではないか ? 」と思っています。 MRP は本文で述べているように、極めて難しい処理であるため処理に時間がかか ります。特にホストコンピュータの時代 ( あるいは最近でも ) は、処理にまる一昼夜 かかることもざらにありました。そのようなことから、機動力のない古い仕組みと誤 解されていることがあるようです ( あるいは、あまりに処理が難しいため、「実装を 諦めたパッケージべンダや SIer がそのように吹聴しているのではないか ? 」と勘くっ てもいます ) 。 しかしながら、ハードウェアが安価になったこと ( 特にメモリが大量に使用できる ようになったこと ) により、メモリ上に展開して処理することで、現時点ではかなり の高速化が可能になっています。実際に 1 日に何回も、あたかも「オンライン処理の ように」 MRP を使用している例も出てきています。 生産管理の基本である MRP をきちんと勉強することは、依然としてとても重要な ことなのです。 0 MRP の前に これまでは MRP に要求される要件を見てきましたが、こからは MRP の機能を説 明していきます。ますは MRP の前に必要となる処理について説明します。 MRP のトリガーとなるのは「基準生産計画 (MPS) 」ですが、この単位は前章も述べ たように、 1 日 ( 場合によっては 1 日数回 ) から 1 週間程度が普通です。この計画を立 てる単位を「タイムバケット」と呼びます。 図 5 には製品 x 、 Y の BOM が表わされており、 BOM の横に BOM のレベルが表 現されています。ここで重要になる概念が「ローレベルコード」と呼ばれるものです。 共通部品 a は図のように X 、 Y のいろいろなレベルに存在しますが、すべての製品の BOM の一番下位のレベル、この場合には「 3 」が a の「ローレベルコード」になります。 74

7. グラス片手にデータベース設計

0 MRP の運用について MRP はこれまで説明してきたように非常に多くのことを実現してくれる便利な機能な のですが、その特性を把握して運用することが重要になります。 ます、 MRP はバックワードと言われる処理を実現しています。説明してきた所要量 計算のロジックを考えれば分かるのですが、「ぎりぎりまで待って計画を確定する」こと が運用の「コッ」になります。ぎりぎりまで待っことにより、計画変更に「より柔軟に」 対応できるのです。しかしながら、購買処理の手間や製造の準備もあるので、どのくら いのタイミングで確定するのかを、導入する工場の運用 / 管理レベルを考慮して決める 必要があります。徐々に運用をレベルアップする ( 徐々に確定のタイミングを引き付け ていく ) ことも検討しておきましよう。 また、これは MRP の欠点とも言われているのですが、「リードタイムありき」で着手 日 ( 購買ならば発注日、製造ならば製造着手日 ) を起算するので、「その起算日がすで に過去になってしまっている」ということが起こります。なるべくそうならないように MRP の対象期間を設定するのですが、これを恐れてかなり先の期間しか MRP の対象 期間としないのでは、変更に強いという MRP の特性が活かせません。よって、実際の 現場ではこのようなことが発生しても、アプリケーション側で「警告を発生する」など の機能が必要になります。 計画の変更にあたっては、 MRP には「リジェネレーション」と「ネットチェンジ」と いう 2 つの考え方が存在しています。リジェネレーションでは「 1 回すべてご破算にして」 計算をやり直すことになります ( 確定オーダは除く ) 。 ネットチェンジは、変更のあった計画のみを再計算することです。一見するとネット チェンジのほうが良さそうに思えますが、計画変更以外に、変更のあったマスタやトラ ンザクションデータをどう取り込むかという面で難しい点が多く、現場の実態との乖離 が発生するため、必すしもネットチェンジがリジェネレーションよりも優位であるとは言 えません。 導入先の品目やオーダ点数、ハードウェア環境、 MRP 処理速度などを勘案し、可能 であれば「リジェネレーション」で実行したほうが確実です。 最後に、工場の生産がすべて MRP で行なえるとは限りません。 例えばサービスパーツ品の場合、補充生産が可能なケースもありますが、計画の立案 が難しく、しかもいきなり中間品 ( 半製品 ) レベルの計画が必要になるケースも考えら れます。また、何らかの突発事故で、中間品の有効在庫の半分をほかの工場に融通しな 0 所 要 開 を 理 解 る

8. グラス片手にデータベース設計

ではなく、「紐付けされている部品を除いて」有効在庫やオーダ残を引き当てる必要が あります。 在庫に関連して、使用可能な在庫ということで「有効」在庫という言い方をしてきま したが、モノによっては違う意味での「有効」期限 ( 例 : 食品の賞味期限など ) が存 在することがあります。この場合には、使用予定時にその在庫が有効期限内であるか どうかをチェックする必要が生じます。最近、食品の問題などで特に注目されている機 能です。 もう 1 つ、在庫に関連して補足します。先に説明したように、購買オーダは通常は有 効在庫がないときに発生しますが、このような「なくなる」管理だけではなく、特に「液 体モノ」のような場合には「タンクがいつばいになったら保存できないから、タンク分 を超えて発注できない」という上限在庫量の管理が必要な場合もあります。 まだまだ必要とされる要件はありますが、このくらいにしておきましよう。 MRP はこれらのことを「同時に考慮する」必要がある点が、非常に難しいわけです。 また、処理が「重い」ことも感覚的につかんでいただけたのではないかと思います。 いずれにしても、要求される機能がどのレベルであるのかを決定することが、開発あ るいはパッケージを選定する場合には重要になってきます。 知耳製番管理の場合 「製番管理」を徹底しており、「部品は全部製品に紐付き ( 予約 ) されていて、共 通部品がまったくない、あるいは考慮する必要性があまりない」ようなケースでは、 必すしも MRP は必要ないか、あるいは重要性は低くなります。 しかしながら、本文に書いたような部品の共通化やユニット化の流れから製番管 理を実施している場合にも、製番紐付きの品目とロットをまとめる品目が混在する 「ハイプリッド型の生産形態」が増えてきており、この場合には紐付き機能を持った MRP 処理が必要になります。 所 要 展 開 を 理 す る 73

9. グラス片手にデータベース設計

機能が MRP には必要になります。アプリケーション側から見た場合、購買については 正式発注、製造については製造指示の確定 ( 承認 ) ということで確定処理を行ないます。 オーダを確定することを「オーダリリース」と呼ぶ場合もあります ( オーダが MRP の 下を離れて独り立ちしたという感じでしようか ) 。 確定されてないオーダは「 MRP により変更されてしまう」ので、運用上は注意が必 要です。例えば BOM で表現される中間品については、当然、ある製品の需要に従属し ているので、 MRP を利用した場合は「中間品自体の計画を人間が作成 / 変更する」は 必要ありません。ところが、いままで MRP を利用していない工場などに導入する場合 には、中間品についても「勘と経験により人手で立案されている」ことがあるので、「俺 の計画を勝手に変更した奴は誰だ ! 」となってしまうことがあります ( 笑い話のようで すが、筆者は何回か経験しています ) 。 このように、 MRP の仕組みを現場の方にきちんと説明できる能力が SE には必要とさ れます ( 結構、説明は難しいですよ ! ) 。また、計画の変更に関して以下のような機能も 必須になります。 先に述べたように、 MRP の計画では製品レベルの計画変更を受けると、下位の計画 は自動的に変更されるので、「足りないオーダ」については当然、オーダが生成されるこ とになります。例えば、中間品 m を 1 開個作ると確定した計画があるとします。製造指 示に従って m を 18 個作ろうとしたところ、何らかの事情で 99 個しか作れなかったと します。このとき、 MRP はどのように振る舞うべきでしようか。 答えは 2 つあります。 1 つは「あくまでも 1 開個作るのだ」ということで、 ( ロットまとめを 1 個と仮定して ) ml 個というオーダを MRP に作成させるというケースです。 もう 1 つは「 1 個くらいはいいからそのまま先に進もう」というケースです。この場合、 製品レベルで予定されていた数量に満たない可能性が高いことになりますが、「それで 良しとする」のです。 前者が正しい気がするかもしれませんが、例えば m のロットまとめが 1 開個の場合 には 99 個の余分な在庫が製造されることになり、これは好ましくありません。 製品の特性や顧客の要求によってどちらのケースも想定されるので、 MRP としては 両方に対応するため、品目ごとに閾値を設定できるようにしておきます ( 閾値の範囲内 であればオーダを生成しないことになります ) 。 80

10. グラス片手にデータベース設計

発注時点では単価が確定せずに、検収のタイミングで決定するということが、外注委 毛の場合は特に発生します。検収データに「検収単価」を持たせて、「検収金額」お よび「検収消費税額」が仕入情報として、債務管理に連携されることになります。また、 こでも集計や照会の際のパフォーマンスを考慮して、「品目コード」とともに「取引先 購 コード」も持たせるようにします。 買 さらに「発注明細データ」の「検収済数量」の更新を行ないます。 理 さて、「発注明細データ」の「完了フラグ」の更新ですが、「発注数」坙「検収済数 発 注 量」となれば発注の完了ということになり、「発注明細データ」の「完了フラグ」を立て 入 るという自動更新も可能です。しかしながら、業種によっては「完了フラグ」の手入力 が必須である場合があります。鋼材などは一般的に「 kg 」単位で発注されます。例えば、 「 10 開 kg 」発注したとします。ところが、入荷が「 10 開 kg 」とされることはまずありません。 入 板厚の誤差によって「 998kg 」だったり、「 1004kg 」だったりします。「 998kg 」のときに「残 検 収 り 2kg 」を再納品というわけにもいきませんし、「 108kg 」で入荷したことにしようとい の うわけにもいきません ( 単価が kg 単位ですから仕入金額が変わってしまいます ) 。した がって、「 998kg 」を検収した時点で、この発注は「完了」となるわけです。この例だけ 計 でなく、「発注の打ち切り」はよく発生します。「完了フラグ」は検収機能で手入力する 項目とするべきです。 一三ロ 0 検収返品の DB 設計 検収返品は、「検査なしの品目で現場に投入後に不具合が発覚して返品する」という ような場合に使用される機能です。したがって、必すしも検収や受入検査の単位で行な われるわけではありません。現品票の運用を行なっていないようなところでは、どの発 注分の返品かも分からなくなっている場合があるので、そこは人間系で発注に引き当て てもらうこととして設計します。 図 8 が検収返品情報の ER 図になります。 データベース上では、検収返品数量はマイナスとして登録されるようにすると、集計 のときに便利です。こうすると、「検収返品金額」と「検収返品消費税金額」が債務管 理システムに連携されます。 99