=========================================================================

当問題は、IT勉強宴会(http://www.benkyoenkai.org)の例題として作成しました。

著作権は著者に帰属しますが、この注意書きを含め全体であれば無料で自由に再配布する事を許可します。部分変更したい場合は全体の配布とは別に変更部分を配布して下さい。

配布方法は著作物、メール、WEBを問わず自由です。

2015.01.22 佐野初夫

-------------------------------------------------------------------------

【花束配送問題(V1.2)】

ロットと在庫推移（日別の在庫数）の管理が必要な、比較的複雑な業務要件にもとづくモデリング手法比較用の標準問題。

■事業と問題の概要

フラワーショップ「フレール・メモワール」は店舗売りとは切り離してWEBショップ事業を立ち上げた。WEBで注文を受け付けて、指定された日付に指定場所に花束を届けるという形態。

当初は受注も少なく手作業で管理出来ていたが、受注が増えるにつれシステム化の必要性が出てきた。「新鮮な花を大切な記念日に」を売り文句にしていることもあって、廃棄される在庫が多く、受注の増加にともなって利益が伸びていないため。

■回答方法

このビジネスのために、効率的な仕入・販売を支援する業務システムのモデル（回答者が通じている手法においてまとめられる各種図面）を作図する。当然ながら、実際のヒアリングでは、あらかじめ謳われている要件以外の要望やアイデアがいくらでも出てくるものなので、大きく逸脱しない限り、適宜ユーザ要件を補ったり修正してもかまわない。ただし、その際にはどのような補足や修正がなされたかをその意図とともに明示すること。

■文書化されているユーザ要件

///商品と在庫///

①花束の組み合わせは事前に「商品」として決めうちされている。１個の商品あたり、どの「単品（後述）」がどれだけ必要かも決められている。シングルレベルしかない部品表のようなもの。単品の在庫も含めて、保管場所は１箇所で、これが増える予定もない。

②花束の材料となるそれぞれの花は「単品」として管理される。「単品」はそれぞれ特定の仕入先から購入され、単品毎に品質維持可能日数が決められている。購入後にその日数を超えると結束には利用できずに廃棄されなければならない。なお、受注・出荷されるものは「商品」のみであって、単品がそのまま出荷されることはない。

///得意先と受注・出荷///

③リピータを期待するので、得意先（個人のみ）情報を管理したい。届け先は毎回違う可能性があるが、前回の受注情報から届け先を簡単にコピーできるような機能は欲しい。

④１回の受注で、１箇所の届け先に対する１種類の商品１個を、「届け日」と「お届けメッセージ」、「お届け先電話番号」とともに受け付ける。出荷日は届け先に関係なく届け日の前日とする。

⑤いったん受注を受けてから、届け日の変更が要望されることがある。その際には可能な限り変更に対応できるようにしたいが、指定日に出荷変更できないようならばその旨を顧客に直ちに伝えられるようでなければならない。

⑥単品を結束して商品（花束）にするための工程は十分に効率化されていて、材料さえあれば一瞬で結束可能とみなしてよい。したがって、出荷日当日に結束指示すれば出荷可能である。

///発注と入荷///

⑦単品を発注する際、単品毎に発注リードタイム（入荷されるまでにかかる日数）が異なる。発注リードタイムさえ越えていれば、どんな将来の入荷向けの単品も発注可能だし、入荷日の変更要望も受け付けてもらえる。

⑧「単品」毎に購入単位数が決まっている。たとえば、５０本必要だとしても、購入単位が１００本ならば１００本買わなければならない。なお、仕入先の供給能力は十分かつ、納期も正確とみなしてよい。

⑨発注の判断は、在庫推移（日別の在庫予定数）をみながら人間が行う。したがって、自動発注処理を考える必要はない。

///代金の扱い///

⑩ＩＤの登録の際にクレジットカード情報を入れるため請求や入金に関しては考慮する必要はない。

⑪入荷の実績情報があれば処理できるので、仕入先への支払に関しても考慮する必要はない。

///現状の画面・帳票///

⑫添付資料(花束問題伝票V1.0.ppt)のとおりであるが、現状のままでは使いにくいと感じているため、ユーザとしては全面的に刷新してもかまわないと考えている。

以上

-----------------------------------------------------------------