業務データ入力欄の設計時には「数値型」「日付型」と言った【データ型】を設定する。例えば、『取引先電話番号』であれば「文字列型(単一行)」を言う【データ型】を指定するだろうし、『ご請求総額』であれば「数値型」と言う【データ型】を指定するだろう。

では『商品名』や『都道府県名』と言った入力欄であれば、どうか?

多くの場合は「選択肢型」の入力欄を設定する。つまり、≪セレクト≫や≪チェックボックス≫と言った選択式インターフェースによって、入力者の入力手間を省き、またデータの揺らぎを無くすことができる。(データ入力を手助けしている)

  <item value="h1" display="コーヒー" />
  <item value="h2" display="アメリカン" />
  <item value="h3" display="カフェオレ" />
  <item value="h4" display="紅茶" />
  <item value="c1" display="アイスコーヒー" />
  <item value="c2" display="アイスティー" />
  <item value="c3" display="オレンジジュース" />
  <item value="c4" display="レモンスカッシュ" />
  <item value="c5" display="コーラ" />
  <item value="e1" display="トースト" />
  <item value="e2" display="サンドイッチ" />
  <item value="e3" display="ピザトースト" />
  <item value="e4" display="ナポリタンスパゲッティー" />
  <item value="e5" display="ピラフ" />
  <item value="m1" display="モーニングAセット" />
  <item value="m2" display="モーニングBセット" />
  <item value="m3" display="モーニングCセット" />

しかし、その「選択肢」は、常に最新状態が維持されなければならない。

たとえば、季節の変わり目等に「全チェーン店の喫茶メニューを刷新する」なんて良くある話だが、それがナカナカ難しい。【データ型】の中で「選択肢型」だけは、メンテナンス作業が必要なのだ。(結構悩まされる)

過去3回の記事に渡って「喫茶メニュー」(選択肢XML)を "一元管理する方法" を例示してきた。
  • 前々々回(業務ローカルな選択肢):
    とある業務内において、複数の入力欄から「喫茶メニュー」(選択肢XML)が参照される
  • 前々回(業務ローカルな選択肢):
    とある業務内において、複数の入力欄から「喫茶メニュー」(選択肢XML)が参照される(+分類絞込)
  • 前回(全社で利用される選択肢):
    社内の様々な業務の入力欄から「喫茶メニュー」(選択肢XML)が参照される

今回は更に、その "選択肢データのメンテナンス" について考察する。ここでは、選択肢をメンテナンスするための特別な自動処理工程[サービスタスク(選択肢マスタ更新)]を活用して、社内共通利用の「選択肢XML」を更新するワークフローを考える。

ちなみに、この「システム共通設定を更新するフロー」は、≪業務基盤≫を統制する行為だ。『内部統制』の強化と言って良い。つまり、ワークフローシステムは≪業務≫を統制していると言える(いわゆる「ITに係る業務処理統制」)が、それに対してこのフローは更に基盤となる部分を統制している。(いわゆる「ITに係る全般統制」)

[喫茶メニューの更新:「2.次期選択肢の表示テスト」画面]

「選択型」のデータ入力、、、顧客業種、契約形態、商品分類。。。

そこに表示される選択肢リスト(Options)を、システム内で一元的に管理したい、と言うニーズは大きい。前々回記事、前回記事、に引き続き、「チェーン喫茶店事業」における『喫茶メニューの一覧』を例に「選択肢」の共通利用化を考える。
  • 前々回: 複数の入力欄(選択型)で同じ「喫茶メニュー」(選択肢XML)が参照される
  • 前回: 複数の入力欄(選択型)で同じ「喫茶メニュー」(選択肢XML)が参照される(+メニュー分類を選ぶと候補が絞り込まれる)

これらの例は「共通利用される選択肢」を1つのファイル(選択肢XML)で管理する仕組みだ。しかし『週次報告業務』と言う業務に閉じた世界で「複数の入力フォーム」の表示リストを一元管理しているだけであって、言わば「業務ローカル」な一元管理にすぎない。
  • A1.週次報告:売れ行き好調の喫茶メニューを選ぶ
  • A2.週次報告:売れ行きが不調の喫茶メニューを選ぶ

今回は、他業務の入力フォームからも参照される様な、言わば「業務横断的」な選択肢XMLを視野に入れて考察したい。以下は、『調理器具の故障』を各店舗が本部報告する業務フローだ。その調理器具が利用できなくなると、どの「喫茶メニュー」に影響がでるか、を併せて報告してもらう。
  • B.故障報告:影響がある喫茶メニューを選ぶ

[調理器具故障の報告フロー:「1.調理器具の故障を記入」画面]

前回に引き続き、「チェーン喫茶店における『週次報告』業務」を考える。

この喫茶店チェーンでは、メニューの数がまだ「全17種類」なので、「メニュー」を選択する入力操作に不自由を感じるケースは少ない。しかし、全30種、全50種ともなれば、やはり選択しづらくなるだろう。ミスの無いデータ入力のためにも何らかの工夫をしたい。

<cafe-menu.xml>
<items>
  <item value="h1" display="コーヒー" />
  <item value="h2" display="アメリカン" />
  <item value="h3" display="カフェオレ" />
  <item value="h4" display="紅茶" />
  <item value="c1" display="アイスコーヒー" />
  <item value="c2" display="アイスティー" />
  <item value="c3" display="オレンジジュース" />
  <item value="c4" display="レモンスカッシュ" />
  <item value="c5" display="コーラ" />
  <item value="e1" display="トースト" />
  <item value="e2" display="サンドイッチ" />
  <item value="e3" display="ピザトースト" />
  <item value="e4" display="ナポリタンスパゲッティー" />
  <item value="e5" display="ピラフ" />
  <item value="m1" display="モーニングAセット" />
  <item value="m2" display="モーニングBセット" />
  <item value="m3" display="モーニングCセット" />
</items>

HTML の選択フォームは、表示名(display属性)以外に「value属性」がセットされる。そして、このケースでは「value属性」に「大分類コード」が入っている。(H:ホットドリンク、C:コールドドリンク、E:軽食、M:モーニングセット)

そこで、この「大分類コード」を使った簡単なフィルタを考えてみる。(JavaScript を使った表示非表示制御)

[データ項目一覧画面]

チェーン喫茶店における『週次報告』業務。

各店舗の店長は、毎週月曜日の朝までに『店舗概況の報告』を入力する。報告内容は以下の6項目。
  1. 一週間の来客数 (数値型データ)
  2. かなり売れた商品 (選択肢型データ)
  3. かなり売れた理由 (文字列型データ)
  4. 売れなかった商品 (選択肢型データ)
  5. 売れなかった理由 (文字列型データ)
  6. 当週の成果と次週の目標 (文字列型データ)
本部のエリアマネージャは、月曜の午前中に店長報告を確認する。一つ一つの報告に対して「コメント」や「質問」を入力する。「コメント」が記入された場合には店長にメールが届き、また、店長への「質問」が記入された場合には、店長にメールが届くと共に、その店長は『本部質問への回答』と言う入力が必要になる。

なお、繰り返し行われる日常的な業務だけに、報告の負担を出来るだけ下げ、毎週確実に報告できる様にしたい。また、報告内容は全店にオープンな形とし、他店の報告内容もいつでも閲覧できるようにしたい。

<組織情報>
  • 全社
    • 関東エリア - 東京店、品川店、横浜店
    • 中部エリア - 名古屋店
    • 関西エリア - 京都店、大阪店

(当ブログ『Workflow-Sample』もマンネリ期だ。ふと・・・、「業務設計演習」(プロセスモデリング演習)の形式で投稿してみよー、と思った!)

[データ項目一覧画面]