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

そこに表示される選択肢リスト(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』もマンネリ期だ。ふと・・・、「業務設計演習」(プロセスモデリング演習)の形式で投稿してみよー、と思った!)

[データ項目一覧画面]

業務プロセス『アルバイト採用』、、、における課題。

<課題1:「今」が分からない>
  • ○○君の応募は、今、誰が対応しているのか?
  • ○○君の応募に対して、次は、何をするのか?
  • 採用(不採用)通知まで、何ステップが残ってるのか?
  • 応募者とのコミュニケーションに、ヌケモレは無いか?
<課題2:「過去」が分からない>
  • ○○君は、どんな評価で、いつ採用されたのか?
  • 不採用となった人の不合格理由は何だったのか?
  • 去年は何人の応募があって、何人合格したのか?
  • 結果の通知まで、どのくらいの時間がかかるのか?

例えば、『履歴書の受理』、『電話での面談日程調整』、『口頭での合否通知』と言った「日常的な業務」、、、いずれも、記録を残すとなると結構な手間だ。結果として、業務ノウハウは共有されず、業務の流れは属人的になる。組織としての「あるべき業務フロー」が議論される事も無い。

確かに

 「採用活動なんて、その時々のマネージャによって手法がチガウもんだ!」 

そう言う結論もアナガチ間違っていないのかも知れない。しかし、(他の業務にも言える事だが)、「標準化」なくして「分業化」は実現しない。『採用フロー』は、事業規模の拡大、新規事業の開発、他市場への進出など、会社の進化を大きく左右する業務だ。人事業務の進め方は、少しずつであっても、「可視化」する方向に、そして「標準化」する方向に改善して行きたい。

[アルバイト採用判定フロー]

「自動メールへのデータ埋め込み、便利だよね!」

誰かが開始させた『案件』が、業務フロー図を流れ、そしてフロー図の中の「とある地点」を通過する。すると、

自動的にメールが送信されたり、
自動的にPDF帳票が生成されたり。。。

そう、、、業務の自動化は、「業務コスト」を大幅に下げ、「ミスの発生」を減らし、「し忘れ」を撲滅する。特に【自動メール】は、社内の関係者に「業務アラート」として送信したり、社外の方に「受付完了通知」として送信したり、応用範囲が非常に広い。

以下は【自動メール】へのデータ挿し込み(差し込み)を体験できるサンプル(業務テンプレート)だ。

文字列型だの、日付型だの、ファイル型だの、、、色々なデータをメール本文に挿し込んだ際に、実際どの様なメール本文が生成されるのか?、を体験できる。以前、『【入力インターフェース】を体験できる』と言うサンプルを公開したら、意外にも人気コンテンツになってしまったので、いわゆる「二匹目のドジョウ」だ。いつもの記事にある様な「仕事の進め方についての考察」は、今回もなーい。(なんか寂しい)

『文字列型(!)、日付型(!!)、ファイル型(?!)、掲示板型(?!!)』 (2014-02-24)

▽公式マニュアルはコチラ▽
M224 自動イベント 業務データを挿し込んだメール文が、自動的にメール送信されるように設定する

[自動メールのテスト]

[メール設定画面]

その【アイデア】は、ビジネスの「種」だ。
  1. 【アイデア】無くして、新製品(New Product) の「花」は咲かない。
  2. 【アイデア】無くして、新生産方式(New Process) の「花」は咲かない。
  3. 【アイデア】無くして、新市場創造(New Market) の「花」は咲かない。
  4. 【アイデア】無くして、新原材料(New Source) の「花」は咲かない。
  5. 【アイデア】無くして、組織改編(New Organization) の「花」は咲かない。

しかしながら、多くの【アイデア】は未成熟のままに死んでいく。つまり、誰かの脳の中でポンッと生まれても、その9割はその脳から出る事なく蒸発し、また幸運にもその脳から脱出した1割も上手く他の脳に寄生できずに絶滅する。【アイデア】の生存率は、あり得ない程に低い。(思いついた本人も、1晩寝ればキレイに忘れる)

もし、その【アイデア】が大切に育まれたのなら、、、
もし、その【アイデア】が社内に発散できたのなら、、、
イノベーションの花畑が広がったのかも知れないのだが。。。

以下のワークフローは、社内の【アイデア】を集めるフローだ。製品開発現場での利用が想定されている。『顧客の声』とは違い、一歩踏み込んだ生々しい『社内の声』(提案)が集まる。 もちろん、文学作品や映画制作のように「誰かの才能に大きく依存する製作手法」が否定されるべきではない。しかし多くの組織においては、組織内の優れた【アイデア】が有効に活用される仕組みを構築すべきだ。

[製品アイデア育成フロー]

【会社の意思】は取締役会で決まる。

多くの場合、「議論の深まり」の中で決まっていく。と言うか、典型的なパターンは社長が取締役達を説得し、「あーだ、こーだ」と事前のヤリトリがあった後、取締役会の場で決まる。当然ながら【取締役会議事録】には、『慎重審議の結果、提案は全員異議なく可決』とのみ記録される。込み入ったヤリトリや各取締役の当初意見などは、公式記録に残らない。

しかし【最も大切な情報】は、決まるまでの「過程」だ。
未来の取締役達が読みたくなる情報は、決まるまでの「過程」だ。

以下のワークフローは、各取締役が独立して意見を記録できるシステムだ。まず『-2.反対』『-1.どちらかと言えば反対』『0.分からない/判断保留』『+1.どちらかと言えば賛成』『+2.賛成』を選び、その上で、自分の意見を自由に記録する。とかく形式主義に陥りやすい『議事録』とは別に運用される。つまり、会議の前に意見や考えを表明しておくため、あるいは会議の後に議論後の意見や議論感想を記録しておくために活用される。単なる「電子採決システム」とは違う。

[事案に対する意見表明フロー]