http://perfdynamics.blogspot.com/2014/07/restaurant-performance-sunk-by-selfies.html
1 comment | 0 points | by WazanovaNews 約12時間前 edited
Performance Dynamicsのブログで、PDQ(Pretty Damn Quick)モデルを利用して、Rでレストランのパフォーマンスを試算した話を紹介しています。
データの元はこちらの記事。NYの老舗レストランが、10年前と比較して、1日当たり同じ数の顧客を対応しているのに、サービスが遅いとのクレームが増えているため、店内の監視カメラで録画したスタッフの動きを比較して分析。その結果、店内の無料Wifiのつなぎ方の問い合わせやつながりづらいというクレームへの対応、顧客がスマホでメニュー/食事を撮影し(おそらく)ソーシャルメディアにアップしている時間、顧客の集合写真をスタッフが手伝って上げてる時間、そうこうしている間に冷めてしまった食事を暖め直す対応、などで顧客グループあたりの流れが悪くなっていて、それが全体のサービスの低下のクレームにつながっていたというストーリー。
記事の中で全ての係数が明示されているわけではないですが、そこはPerformance Dynamics側で便宜上推定した数値を置いて試算してます。
まずは、アクション別の時間を仮設定。
> df obs.2004 obs.2014 wifi.data 0 5 menu.data 8 8 menu.pix 0 13 order.data 6 6 eat.mins 46 43 eat.pix 0 20 paymt.data 5 5 paymt.pix 0 15 total.mins 65 115
次に、レストランのスタッフと顧客の動きをキューモデルに従って分解。
- 顧客はテーブルに着き、メニューを見て食事を選ぶ。このアクションはPDQモデルにおいて、ウェイターが介在しないので、キューには溜まらず、平均8分(固定値)の遅れとなる。
- 顧客が注文をする。ウェイターが対応するので、PDQモデルにおいては、ウェイターをservice facilityと定義して、キューに溜まって処理されるアクションになる。
- 食事時間は平均45分(固定値)の遅れとして計上される。正確な値は、記事から読み取れる全体の時間と他のアクションの時間の差分で計算する。
- テーブルで支払を済ませるのは、ウェイターが対応するので、キューに溜まって処理されるアクションとして計上される。
- 顧客がウェイターをつかまえて、無料Wifiの接続方法について問い合わせする、もしくは電波が弱いとクレームを言う。(米国でよくある風景。日本だと携帯のネットワークがしっかりしているので、ないでしょうね。)キューに溜まって処理されるアクションとして計上。
- 顧客がメニューを眺めるが、スマホで写真をとったりソーシャルメディアにアップしている時間があるので、以前よりも長くかかる。
- 注文は、キューに溜まって処理されるアクションとして計上される。
- 食事は固定値の遅れとして計上されるが、スマホでの撮影などがはさまるので長めにかかる。
- 支払は、キューに溜まって処理されるアクションとして計上される。
- 支払時にもスマホを使ってのアクションは続くが、ウェイターを絡めていないものは、固定の遅れとして計上。
上記のアクションをRのコードに反映し、計算結果が、仮置きした数値とほぼ変わらないのを確認。
1. library(pdq) 2. 3. ncust <- 45 4. year <- c(2004,2014) 5. waiters <- c(6,6) # number of waiters assumed 6. 7. wifi.data <- c(0,5) 8. wifi.serv <- c(0,4) # est. service time 9. menu.data <- c(8,8) 10. menu.pix <- c(0,13) 11. order.serv <- c(4,4) # est. service time 12. order.data <- c(6,6) 13. eat.pix <- c(0,20) 14. paymt.serv <- c(3.5,3.5) # est. service time 15. paymt.data <- c(5,5) 16. paymt.pix <- c(0,15) 17. total.mins <- c(65,115) 18. 19. sub.mins <- wifi.data + menu.data + menu.pix + order.data + eat.pix + paymt.data + paymt.pix 20. eat.mins <- total.mins - sub.mins 21. df <- data.frame(year,wifi.data,menu.data,menu.pix,order.data,eat.mins,eat.pix,paymt.data,paymt.pix,total.mins) 22. 23. for(i in 1:length(year)) { 24. model.name <- paste("Restaurant Model of",as.character(year[i])) 25. Init(model.name) 26. eat.delay <- menu.data[i] + eat.mins[i] 27. pix.delay <- menu.pix[i] + eat.pix[i] + paymt.pix[i] 28. CreateClosed("WaiterReq",TERM, ncust / waiters[i], eat.delay + pix.delay) 29. 30. CreateNode("WifiHelp", CEN, FCFS) 31. CreateNode("Ordering", CEN, FCFS) 32. CreateNode("Payment", CEN, FCFS) 33. 34. SetDemand("WifiHelp", "WaiterReq", wifi.serv[i]) 35. SetDemand("Ordering", "WaiterReq", order.serv[i]) 36. SetDemand("Payment", "WaiterReq", paymt.serv[i]) 37. 38. SetTUnit("Mins") 39. SetWUnit("Cust") 40. 41. Solve(EXACT) 42. Report() 43. }
次に、レストランの録画映像を目で追って分析する手法ではできないが、PDQモデルでは簡単できる応用事例として、顧客当たりのウェイター数でのスループット(顧客/分)と顧客滞在時間のシミュレーションをしてみる。
#r