3. 物理モデルの作成
コンテキストダイアグラムでは「カフェ・システム」という大きな1つのかたまりとして表現していたプロセスを、その処理する内容によって複数のプロセスとそれらを結びつけるデータフローに分割・詳細化していきます。分割する際には外部エンティティとどのようなやりとりを行っているのか、たとえばこのカフェ・システムの例ではコーヒーに関するやりとりなのか、お金に関するやりとりなのか、という点に着目するとわかりやすいでしょう。
この例の場合、コーヒーに関する流れでは注文を受け付けるプロセスとコーヒーを淹れる作業指示を行うプロセス、そしてお金に関する流れでは料金を計算してお客さまに提示するプロセスと支払いを受け付けてレシートを発行するプロセスに処理を分割しました。
そして、コンテキストダイアグラムでは省略されていましたが、お客さまからの注文を受け取る「出力先」であり、バリスタへの作業指示を行う「入力元」である「店員」をあらためて配置しています。
さらに、売上と入金のデータは台帳のようなファイル、あるいはデータベースとして保存しておく必要があります。そこで売上、入金のデータを保存するためのデータストアをDFDに追加します。ここではPOSレジがそれにあたります。現金での取引はもちろんですが、クレジットカードやその他キャッシュレスでの売上・入金についても取引の情報はPOSレジに保存され、ジャーナルとして出力することができます。
ここでの流れとしては、店員がコーヒーの注文を受けて料金を提示し、注文を確認すると売上が発生します。お客さまからお店への支払いは入金情報として処理されます。レシートを渡すことで処理完了となります。
売上・入金情報の格納先として「POSレジ」を想定したデータストアを追加した図は次のようになります。
4. 論理モデルへの変換
ここまで作成したDFDは実際にカフェの中で行われている行為をありのままに描写したものです。別の言い方をすると、コーヒーや現金、それからレシートといった現実の「もの」を中心に「実際にどう行われているか」を表した「物理モデル」と呼ばれるものです。
そこから「データや情報がどう流れているか」を整理して、たとえばこの例ではコーヒーや現金といった「もの」やコーヒーを淹れる、会計伝票に記入して切り取るといった「実際の動作（物理的な手順）」を抽象化して情報の流れに着目したものが「論理モデル」です。
本節の例である「カフェでの注文から支払い、コーヒーの提供までのプロセス」を「論理モデル」的な視点から説明すると、システムの物理的な側面を取り払って、データやプロセスの流れに焦点を当てた説明になります。
この例で考えてみると、物理モデルのDFDに外部エンティティとして存在していた「店員」は顧客からの注文のシステムへの入力や、システムから発行されたレシートをお客さまに渡す、そしてシステム経由でバリスタに作業を指示するといったインターフェースとしての「機能あるいは役割」を持っていると言えます。言い換えると「店員」は外部エンティティではなく、プロセスとして捉えることができるということに気がつくことでしょう。
あらためて、カフェでの一連の流れを論理的なプロセスとデータフローに整理してみると次のようになります。
注文
注文処理の最初の段階で、お客さまが口頭で注文を店員に伝えます。お客さまが「注文内容」を店員に伝えて、店員がその情報を基にシステムに「注文データ」を入力します。この段階では、店員がシステムに対するインターフェースとして機能します。ここでのデータフローは、お客さまから店員に「注文内容」が伝達される流れと、店員がシステムに「注文データ」を入力する流れの2つになります。
注文確認と料金計算
次に、注文処理システムは「注文データ」を解析し、料金を計算します。システムは計算された「料金提示データ」を店員に返送し、その後、店員がその内容をお客さまに伝達します。ここでは料金の計算と確認がシステム内部で行われ、店員がその結果を伝える役割を担います。データフローとしては、システムから店員へ「料金提示データ」を返送する流れと、店員がお客さまに「料金提示」を行う流れがあります。
支払いプロセス
支払い処理ではお客さまが料金を店員に支払います。店員はその「支払いデータ」をシステムに入力します。ここでは店員がシステムへのインターフェースとして、支払い情報を管理しています。データフローとしては、お客さまから店員への「支払い」と、店員からシステムへの「支払いデータ」の登録という流れがあります。
支払い確認とレシート生成
支払い確認処理では、システムが「支払いデータ」を確認して支払いの完了を確認します。確認が完了すると、システムは「レシートデータ」や「支払い確認データ」を店員に送信し、それを基に店員がお客さまに支払い完了の確認やレシートを渡します。ここでのデータフローとしては、システムから店員への「支払い確認データ・レシートデータ」の送信と、店員から お客さまへの「レシート」の受け渡しがあります。
作業指示の発行
作業指示処理が始動し、システムはバリスタに「作業指示データ」を生成して送信します。このデータは、店員を介さず直接バリスタに伝えられます。ここでは、システムがバリスタに対して製品の作成を指示します。データフローとしては、システムからバリスタへの「作業指示データ」の送信となります。
商品の提供
最後に、製品提供プロセスです。バリスタが作成したコーヒーをお客さまに提供します。ここでは、バリスタからお客さまへの物理的な提供行為が行われます。データフローをあえて描くならば、バリスタからお客さまへの「コーヒー提供」となります。
このようにして、情報（データ）の流れに注目してDFDを変換したものが次の「論理モデル」です。
5. 論理モデルのその先
ここまでカフェでの一連の流れをモデル化しながら、「店員が『インターフェース』となってデータを手入力している部分は、現行のプロセスのボトルネックとなりえるポイントじゃないかな？」ということに気がついた読者の方もいらっしゃるのではないでしょうか。
ここでは「お客さまが直接システムに注文データを入力できるようにすればどうなるか？」という気づきが改善のヒントになります。「お客さまが直接システムに注文データを入力できる」セルフサービス化することによって、たとえば次のようなことが期待されます。
- お客さまがタブレットやアプリケーションを使って直接注文を入力することで、店員を介さずに入力の手間が省ける。結果として、データの入力スピードが上がり、店員の作業負担も軽減される
- お客さまが自分で注文を入力することができれば、コミュニケーションエラーが発生するリスクが減少する。また、注文内容の確認も容易になる
- システム上でサイズやアイス／ホット以外にも、トッピングやミルクから豆乳／無脂肪乳への変更などのカスタマイズオプションを簡単に選択できるようにすれば、お客さまが自由に自分の好みに応じた注文を正確に行える。また、これにより店員の負担も軽減する
