Transcript モデリング＆シミュレーション - 経営システム工学実験・演習のページ

「経営システム工学総合実験」
モデリング＆シミュレーション
ビールゲーム
担当： 森戸 晋
担当助手： 後藤 允
２００６年５月１２日（金）
協力： 森戸研究室修士，4年
「経営システム工学総合実験」
モデリング＆シミュレーションの狙い
• サプライチェーンマネジメントを「体感」
• 基礎知識の（再）確認
– 在庫管理
– ロジスティクス
– サプライチェーンマネジメント
• 問題発見
→情報収集の仕方
→研究・調査・分析の企画、企画書の作成
→問題分析／問題解決、結果概要書の作成
2
サプライチェーン（Supply Chain)
製品の流れ
サプライヤー
メーカー
配送業者
卸売業者
小売業者
顧客
需要情報の流れ
3
全３回の実験の概要
第１回 ロールプレイングゲーム
第２・３回 コンピュータ・ビ－ルゲーム(シミュレーション)
第２回 問題発見（情報の収集、問題点の把握、
問題の整理と構造化）
→ 情報収集（文献データベースの検索）
→ 分析計画の提案（研究企画書作成）
第３回 問題分析／問題解決
→ 分析結果の報告（結果概要書作成）
4
サプライチェーンマネジメント
• 問題の発見と構造を学ぶ
– 問題やそのキーパラメータはなにか
– パラメータ間の関係はどうなっているか
• 「サプライチェーンの特性は？」、「どう設計・
制御したらよいか」などに関する洞察を得る
– サプライチェーンにはどんな特性があるか
– どのような制御方法がよいか
– パラメータをどう設定すればよいか
• 在庫管理技法を復習／勉強する
• シミュレーションなどのモデル分析によりシ
ステムの特性や設計・制御方法を解明する
5
実験で注目してほしい点
１．サプライチェーンの問題点の把握
どういう現象が発生しているか？
どういう問題が生じそうか？
２．問題の整理と構造化
影響を与える主な要因や評価尺度は何か？
問題の発生原因は何か？
主な要因と問題や評価尺度との定量的関係
はどうなっているか？
３．授業等で学んだこととの関連
6
MIT ビールゲーム
• システムダイナミックス（System Dynamics: SD）を学習する
ロールプレイングゲームとして、MITで開発
• 当初は，「生産流通システムゲーム（production distribution
game）」と呼ばれていた
• ゲーム盤には「工場」・「一次卸」・「二次卸」・「小売店」の4つの
コンポーネントがあり，参加者はチームとなって各ビールゲー
ム盤に向かい勝敗を競う
• ゲームの目的は、勝つこと
• 参加者が，各コンポーネントの意思決定を分担し，相互に圧力
を感じながら自らの意思決定を遂行するロールプレイングを通
して，実社会における意思決定の雰囲気や意思決定がどのよ
うな結果を起こすかを体感する
• 「システムの内的構造が行動を生む」というSDの大原則と共に、
システム思考とはどういうものかを体験的に学習する
7
ビールゲームのボード
情報（注文）の流れ
もの（ビール）の流れ
8
ビールゲームの重要ポイント
• 工場→一次卸→二次卸→小売店と、もの（ビー
ル）が流れる
• 各コンポーネントで、
– 在庫発生→在庫管理費用がかかる
– 品切れ発生→品切れ損失費用がかかる
• 小売店で発生する需要量は未知
• 在庫を持ちすぎず、かつ品切れがないように
ものを流したい！
• 各コンポーネントが、全体の流れを考えながら、
うまく発注数を決めなければならない
9
ビールゲームの基本ルール(1)
１．ゲームの目的：チームの総費用最小化
費用の計算方法：
・各コンポーネント分担者が、各週に在庫およ
び受注残を計算し、全期間にわたって合計
・在庫＝0.5ドル、受注残＝1ドルをかけて費用
を計算し、各コンポーネントの総費用を求め
る．
・全期間・全コンポーネントの費用合計を集計
する．
２．社名を決め、記録シートに記入
３．成績優秀チームは表彰
10
ビールゲームの基本ルール(2)
４．（同一コンポーネント担当者以外は）お互いにコミュニ
ケーションはしない！
（これは、お互いに他人の活動は分からない、
という実世界を反映する）．
ゲームボード盤を見渡すことだけが許される．
５．顧客からの受注量は「小売店」だけが知る．
「小売店」は、他に情報を伝えてはならな
い！
11
BEER GAME 手順①
発注
発注
注文中
注文票
遅れ
在庫
注文中
生産要請
遅れ
遅れ
『在庫』に近い『遅れ』のチップを在庫に移す
12
BEER GAME 手順①
発注
発注
注文中
注文票
遅れ
在庫
注文中
生産要請
遅れ
遅れ
『在庫』から遠い『遅れ』のチップを近い『遅れ』に移す
13
BEER GAME 手順②
発注
発注
注文中
注文中
４
注文票
遅れ
在庫
生産要請
遅れ
遅れ
左上の『注文中』に貼られた付箋をめくって、書かれた数
と同数のチップを左隣の『遅れ』に移す。
受注残があるとき：（書かれた数）＋（受注残数）を移す。14
BEER GAME 手順③
週
在庫
1
１２
受注残
注文
０
2
3
記録シートに現時点での在庫数・受注残数を記録
（他のコンポーネント担当者に見せないこと！）
15
BEER GAME 手順④
発注
発注
注文中
注文票
遅れ
在庫
注文中
生産要請
遅れ
遅れ
『発注』の付箋を右隣の『注文中』に移す
工場は『生産要請』の付箋を開け、その数を最初の生産遅
れに置く
16
BEER GAME 手順⑤
発注
発注
注文中
４
注文票
遅れ
４
４
在庫
生産要請
遅れ
新たに付箋を用意し、自分の注文したい数を
書きこみ、裏返しにして『発注』に貼り付ける
注文中
遅れ
17
BEER GAME 手順⑤
発注
発注
注文中
注文票
遅れ
４
４
在庫
生産要請
遅れ
新たに付箋を用意し、自分の注文したい数を
書きこみ、裏返しにして『発注』に貼り付ける
注文中
遅れ
18
BEER GAME 手順⑤
週
在庫
1
１２
受注残
０
注文
４
2
3
記録シートに注文数を記録
（他のコンポーネント担当者に見せないこと！）
19
BEER GAME
発注
発注
注文中
注文票
在庫
遅れ
注文中
生産要請
遅れ
遅れ
始めに戻るので、これを繰り返す
20
ビールゲーム：再確認(1)
• ビールのサプライチェーンを想定
• ゲーム期数＝50週
• サプライチェーンは，それぞれ1施設からなる
「小売店」、「一次卸」、「二次卸」、「工場」で構
成
• 工場の生産能力は無制限
• 各コンポーネントの在庫保有量は無制限
21
ビールゲーム：再確認(2)
• 各コンポーネントは直下の需要を可能な限り満足しよ
うとする
• 満足できなかった需要は受注残（バックオーダー）とし
て記録され，可能な限り即座に満たす
• 注文（オーダー）が無視されることはなく、最終的には
必ず満たされる
• 需要を満たせなかったときは受注残（品切れ）となり，
ペナルティとして1個当り1ドル／週の費用がかかる
• 在庫保持には１個当り0．5ドル／週の費用がかかる
22
ビールゲーム：再確認(3)
• 各コンポーネントは，週ごとにオーダーを出す
• 発注リードタイム（左のコンポーネントがすぐ右
隣のコンポーネントに注文を出し，注文が右隣
のコンポーネントに届くまでの期間）は2週間
• 納入リードタイム（発注を受けてから商品を届け
るのにかかる期間）は2週間； つまり全体として
発注から納入まで4週間かかる
23
ゲーム終了後．．．
• 各チーム毎に記録シートで総費用を計算
• TAを通じて、総費用を連絡
• 各チーム毎にグラフ作成
– 在庫と受注残のグラフ
– 注文量のグラフ
• チーム内でゲームを振り返って検討
• 来週、各チーム5分間の発表
24
Excelシートによる結果の集計
• 実験のホームページ「モデリング＆シミュレー
ション」の「演習資料」から、集計シートをダウン
ロード
• 紙の集計シートから各コンポーネントのデータを
Excelシートに移す
• 各コンポーネントの在庫量の推移グラフ・発注
量の推移グラフが自動で作成される
• 集計シートを作成したら、メール添付で提出する
こと（締切：翌日５/１３（土）午後5時まで）
アドレス [email protected]
• ファイル名 班番号．ｘｌｓ （例 12.xls）
25
「経営システム工学総合実験 モデリング＆シミュレーション」
第１回宿題
• 班単位で
次回 5/19（金）の「ゲーム結果の評価と考察」に
関する発表の準備； PowerPointでスライド作成
発表用pptファイル（ファイル名は班番号）をメール添付
で提出
締切：5/17（水）午後5時
[email protected]
• 個人単位で
サプライチェーンにおけるブルウィップ効果（鞭
効果）について、資料を読んでまとめよ。
アドレス
（関連する他の資料も参考にしてよい）
森戸研メールボックスへ提出
締切：5/17（水）午後5時
26
「経営システム工学総合実験 モデリング＆シミュレーション」
ゲーム終了後の検討項目例（１）
できるだけ「系統的」に検討すること
• ゲーム結果の集計
– 在庫、受注残、発注量の平均、標準偏差、推移
• ゲーム結果の評価
– どういう方針でプレイしたか
– ゲームは思ったようにプレイできたか
• ゲームの流れのなかでシステムに振り回されていると感じなかったか
• 思うようにプレイできないのは誰か（たとえば隣）のせいだろうか
– 上流では最終需要はどれぐらいと考えていたか
– 各コンポーネントがうまくやれば、全体がうまく動くのだろうか
– （他チームの結果と見比べたりして）システムの挙動には普遍性
があるのだろうか；その裏にシステム固有の構造が潜んでいる
のではないか
27
「経営システム工学総合実験 モデリング＆シミュレーション」
ゲーム終了後の検討項目例（２）
• ゲームで学んだこと、授業等で学んでいることとの関連、
検討対象となる事柄
–
–
–
–
–
ゲームからどのようなことを学んだか
意思決定（発注数決定）にあたって重要な要因はなにか
授業等で学んだ何がどこに役立つのだろうか
ゲームで体感したことは、現実の意思決定とどう関連するか
構造的な問題が存在するならば、いかなる対処の方法があるか
• その他（ゲームそのものについての意見）
– ゲーム自体をどう思ったか
– ゲームのよくできているところ、非現実的なところはどこか
– ゲームに不具合があるとするとどう修正するのがよいか
「網羅的」というより、視点を明確に定めて「論点」のはっきり
した発表を心がけること； 定量的結果と関連づけること
28
速報： 集計結果（各班の総コスト）
班
1
2
3
4
5
6
7
8
総コスト
班
9
10
11
12
13
14
15
１６
１７
総コスト
29
班単位の宿題の
ファイル名とメールタイトル名
班単位の宿題提出にあたっては，
 集計シートExcelファイルの名称
班番号.xls （例 12.xls）
 集計シート送付メールのタイトル名
集計シート提出○班 ○○班
（例 集計シート提出12班 ）
 発表スライドの名称
班番号.ppt （例 12.ppt）
 発表スライド提出メールのタイトル名
発表スライド提出○班
（例 集計シート提出12班 ）
30