第551話：週報スプレッドシートへのコメント

業務：週次売上報告へのフィードバック

「一週間分の売上」が Google Sheets に書き込まれるようになった。（参照：第550話）

全店長が一つのファイル（例：『売上報告2017-08-27to2017-09-02』）を同時編集するので、

• 各店長は他店を意識するようになった
• 店長同士で誤入力を指摘し合うようになった
• 本部での集計作業は（Spreadsheet任せなので）不要になった
• 役員達もファイルを閲覧し、各店舗の動向を能動的に確認するようになった

などのカイゼンが図られている。つまり、各店長のコメントを含む「売上データ」が、社内でイキイキと活用されるようになった。（これまでは「売上データ」が死んでいた？）

課題：管理職側のコメントがない

しかし、本部マネージャから全店長に「フィードバック」があっても良いのではないだろうか？

セッカク全店長が頑張って報告してくれているのに、本部のマネージャ達から何も感想がないのは寂しい。「目標達成を頼む」の一言でもイイ。マネージャの笑顔を待ちわびる店長達に伝えてやってくれ。。。

そうすれば「実績データについて本部のマネージャ達がどう考えているか／どんな助言をしているのか」を役員達が知ることもできる。

[週次売上報告プロセス-フィードバック]

第550話：スプレッドシート記入という業務の自動化

業務：週次売上報告

各店長には「一週間分の売上」を週次報告してもらっている。

確かに、メールやワークフローを使い、

1. 一人一人の『店長』が報告し、
2. 本部の『マネージャ』が確認する

というシンプルな「売上報告プロセス」を回すのも悪くない。しかし各店長は『本部マネージャの顔色』だけを見てシゴトしているような気がする。


たとえば、もっと「他店の動向データに触れる機会」を作っても良いのではなかろうか？

もし『Google Spreadsheets』であれば、全店長が同じドキュメントを編集できる（※50人まで）ワケだし…。　副産物的な話として、『本部マネージャ』の「集計する」という工程が省力化されるハズだ。「入力ミス」についても、他店とデータ比較されることで店長自身が気づくかもしれない。あるいは店長同士で「入力ミス」を指摘し合うかもしれない！　（更には店舗間のコミュニケーションも活発になり、生産性向上に…悶々）

課題：新しい SpreadSheet の準備がメンドウ

しかし、そうなると誰かが「報告用の Spreadsheets」を毎週準備する必要がある。

本部の『マネージャ』達には無理だ…。彼らは他人には厳しく、自分にはアマイ。たとえば「経費精算」など、今まで締切日が守られたタメシがない…。う～む「毎週キッチリと、新しいファイルを準備して全店長にアナウンスする」という第一工程がネックだなぁ。

[週次売上報告プロセス]

第531話：テレビ番組表の自動検索

情報収集は「業務」か？

色々な意見がありそうです。テレビ番組も会議室で視聴すれば「業務」なのでしょうね。

ただ、たとえば百貨店に勤めている方なら「百貨店」のニュースは気になるものです。あるいはネット企業に勤めている方なら「AI」「IoT」「ビッグデータ」といったキーワードが気になるものです。

もし、それらのキーワードに関係する「特集番組」がテレビ放送として企画されているなら、見逃す訳には行きません。とくに公共放送で取り上げられるとなれば、社会への影響も非常に大きなものがあります。

＜NHK API 管理画面＞

誰でも使える NHK API

日本の公共放送であるNHKは、『番組表API』を公開しています。2016年6月にはVer.2の提供が開始され、「７日先」の番組情報まで取得できるようになりました。

レスポンス抜粋

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "ＮＨＫニュース　おはよう日本",
"subtitle" : "▼国内外の最新ニュース　▼スポーツ情報　▼地域の課題や話題のリポート　▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります　▼番組ＨＰ　ｈｔｔｐ：／／ｗｗｗ．ｎｈｋ．ｏｒ．ｊｐ／ｏｈａｙｏｕ／",
"act" : "【キャスター】森田洋平，【気象キャスター】酒井千佳",

この API は非常にシンプルな OPEN API です。

ユーザー登録さえすれば、誰でもスグにアクセスでき、利用上のルールに関しても「１日300アクセスまで」と非常に明快です。OAuth1/OAuth2といった認可フローもなく、セキュア通信（HTTPS）ですらありません！


一方で、標準仕様に厳格な API と言うこともできます。

日頃いろいろな API を活用している方であれば、Web サイトで使用できる文字（UTF-8）は、そのまま通信されるものと思い込んでしまっています。しかし、ソコは「流石NHK」です。「英数記号（ASCII 文字）だけで送受信」（Unicodeエスケープ）というルール（JSON RFC7159）をしっかり守り、日本語一文字一文字が \nXXXX と変換されています。（通信ログの検証等では使いづらいのですが）

[テレビ番組のキーワード検索]

日報プロセスに「GPS情報」も記録する

「たしかに営業日報は『地味な報告作業』だ。しかし同時に『非常に重要な活動記録』でもある。」 （取引先マスターを参照する営業日報）

という投稿に対して、「記録としての価値を高めるためにも『GPS 情報』も記録したい」という話を頂いた。

なるほど。たとえば、客先往訪した直後にスマホで日報を書くスタイルなら、そのスマホが保持している「緯度経度情報」（GPS 情報）を使うべきだ。その『GPS 情報』は現場サポートの記録として、非常に有用な情報になるだろう。（GPS: Global Positioning System ／ 全地球測位システム）


今日『GPS 情報』は、非常に使いやすくなった。つまり、多くのブラウザが「GPS 情報を取得する機能」を持つようになり、スマホに限らず、パソコンですら、想像以上に正確な位置情報を取得できる。事実、この機能（「ジオロケーション機能」という）は、新しい表示フォーマット「HTML5」（by W3C）の中で、最も人気がある機能だ。


以下は、以前投稿した「営業日報プロセス」が改良されたものだ。

変更点は、入力項目『活動詳細』（textarea）の下の［入力のヒント］部に、２つのボタンが追加されただけだ。しかし、これが非常に使いやすい。

• 「Googleマップ URL を表示するボタン」
• 「表示 URL をテキストエリアに貼り付けるボタン」

[営業日報プロセス]

取引先マスターを参照する営業日報

たしかに営業日報は『地味な報告作業』だ。しかし同時に『非常に重要な活動記録』でもある。

• もし「販売が好調だった月」を振り返ろうと考えた時、
• もし「不調に終わった月」を反省しようと考えた時、

その月の活動記録がなければ分析のしようが無い。たとえば、セールス部門全体として、どのような顧客グループに、何をプッシュしたのか？、、、各メンバーにヒアリングしたとしても、「まともな分析資料」が出来上がるには相当な時間を要してしまうだろう。

言い換えれば、日々の営業日報は「次のセールス戦略」を考えるための重要な基礎資料なのだ。

とは言っても「顧客の属性」や「顧客社名」あるいは「活動内容」の入力にユラギがあるようでは、それはそれで意味がない。また一方、入力の手間がかかってしまうなら、それも本末転倒だ。（ホント悩ましい）

以下は『面談記録』と『上司コメント』で構成される「極めてシンプルなビジネスプロセス」だ。

ただ、何より秀逸な点は、その入力支援の仕組みと言える。つまり、「顧客の属性」や「顧客社名」にはワークフロー基盤で統一管理している『顧客マスター』を参照できるようになっている。また「セールス活動内容」には『基本活動・重点提案活動』の一覧が参照できるようになっている。

[営業日報フロー]

溜まるハズの「日報」が、溜まらない仕組みを作れ！

朝、自分の「マイタスク」に『11月4日の日報』というタスクが増える！

悪くナイ。

もしこの機能が無かったら、週の半分で「日報」の提出を忘れる。（…自信アル）。 ちなみに、ルールとしては「帰る時までに提出。もし忘れたとしても翌日提出、最悪でも翌々朝までに提出」ということになってる。

でも、、、

メンバ全員、それなりに機嫌よく、このワークフローで「日報」を流してるケド、、、この【自動開始】という機能、、、、少し問題やとも感じてる。

つまり、仕組みとしては月曜から金曜の毎朝に全員の「マイタスク」に自動追加されるんやけど、、、数日休むと「日報提出タスク」が無駄に溜まってしまう。。。例えば、

• 忌引き、大型連休、年末年始休暇とか、
• 育休、産休、介護休暇とか、
• （あと、変則出勤の人もオルな…）

まぁ、数日分なら１つ１つ頑張って消すんやけど、30日分とか、60日分とか。。。もし1年分なんてなると、消すに消せんのよ。。。（いや、やればデキル子なんやで…）

[日報フロー 1]

「タイマー開始」なワークフローは、仕事のリズムを整える！

「受け身」で仕事をする！？

とてもネガティブな表現に聞こえる。しかし、そもそも「業務」を概念的に種類分けすると、

• A. リーダ主導型の業務プロセス
• B. メンバ主導型の業務プロセス

といったカテゴリがあって、この「A.リーダ主導型」に分類される業務工程（タスク）は非常に多い。例えば以下の様なトリガーで始まる業務だ。

• a1. 上司が原稿の翻訳を依頼する
• a2. 上司が企画書をまとめる様に指示する
• a3. 上司が顧客問合の回答担当者を割り当てる

一方で「B.メンバ主導型」に分類される業務工程は、以下の様なトリガーで始まる業務プロセスだ。

• b1. 上司に日報を提出する
• b2. 上司に稟議書を提出する
• b3. 上司に客先に提出する見積の承認をとる

想像するに容易な話だが、リーダから降ってきた仕事をこなす「A.リーダ主導型」の方がラクなのだ。人間そう言うものだ。話が脱線しかねないが、、、現実、会社組織の中ではガンガンと仕事を流す側の鬼部長も、家に帰れば「受け身」だったりする！（はへ？？）

さて、以下に紹介する「時刻が来たら仕事をする」類のワークフローは、「A.リーダ主導」でも「B.メンバ主導」でもない。「T.タイマ起動」と言うべきトリガーだ。コレは、いわゆる「ルーティンワーク」と言う業務に該当する。

実は、これはこれで非常にラクだ。月曜日や金曜日に「T.タイマ起動」系の仕事を入れる人は少なくない。つまるところ自動的に起動される案件は、仕事のリズムを整えてくれる。

[時限メール-タイマー起動]

取引先名をユラギ無く入力する技

ワークフローだって、【取引先マスタ】が欲しい。
もし「法人名」がユラギなく入力されていれば、どれほど素晴らしいだろう。

資料請求対応、往訪報告、見積提出、受注報告、請求書郵送、問合対応、、、そしてそれらの業務データの集計や分析。。。もし、法人名の「ゆらぎ」が無ければ、「見積書発行額と請求書発行額から成約率を確認」したり、「資料請求から受注までの平均時間」を分析したり、、、戦略立案のための基礎情報もすぐに確認する事が、カンタンにできるようになる。≪綺麗なデータ≫から得られる≪情報≫は、果てしなく大きい。（ビッグデータになるなら尚更）

業務プロセス（業務ルールや業務手順）がある程度整備されたアカツキには、事業特性や会社の規模に合わせた【取引先マスタ】を構築したくなる。

ここでは、(1)『取引先マスタの更新申請』と、(2)『取引先XMLの作成』の２つの業務フローに分けて考えたい。すなわち、各部署の社員が日常業務において、「移転のお知らせ」を受け取った際や「社名変更」の事実を知った際に申請するワークフローと、管理部門において一元的に取引先マスタを更新する業務を分ける事にする。

第一弾は、上司への往訪報告（面談報告）の業務フローにおいて、ついでに(1)『取引先マスタの更新申請』を行える仕組み（ワークフロー）を考える。

[面談報告フロー：「1.面談内容を入力」画面]

システム共通の『選択肢XML』を予約更新する

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

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

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

  <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）が参照される（＋メニュー分類を選ぶと候補が絞り込まれる）

これらの例は「共通利用される選択肢」を１つのファイル（選択肢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』もマンネリ期だ。ふと・・・、「業務設計演習」（プロセスモデリング演習）の形式で投稿してみよー、と思った！）

[データ項目一覧画面]

売上高をその日の為替レートで自動変換（為替API活用）

各支店からの「売上高報告」、その速報値を集計したい？

前回紹介した日報ワークフロー（※）があれば、いつでも売上高の日次変動を確認できる様になる。絞り込み機能を使えば、任意の期間の売上高を集計する事も容易だ。しかし一部の売上高報告が、異なる通貨になっていればどうか？？？
※ 「日報」に気象データを取り込む意味（天気API活用）

以下のワークフローは前回紹介の『営業日報フロー』をベースに、当日の為替レートで売上高を変換する機能が追加されている。すなわち、その日の為替レート情報をインターネットから自動的に取得し、海外店の店長が入力した売上高（現地通貨）を本店通貨表記に自動変換する仕組みだ。実際に本店の通貨に換金するタイミングは異なるにせよ、売上高の「速報値」を自動集計できるようになるのはスバラシイ。

[営業日報フロー-為替]

「日報」に気象データを取り込む意味（天気API活用）

「天気」に左右される業務は少なくない。

良く議論される事例として「ビールの仕入業務」がある。ウェザー・マーチャンダイジングなどと言われる事もあるが、要するに「売れ行き」を予想して「仕入」を行う業務だ。担当者は天候や予想最高気温などを見て（更に祭事やイベントをチェックして）その発注数量を決めるのだ。

もちろん他にも色々ある。
「建設現場の週間計画」、「農業の悪天対応」、「イベント体制の準備」、「ゴルフ場のキャンセル対応」などなど、様々な業務で天気が影響する。また、一見『屋外』とは縁の無さそうな「通販業の問合対応」なども、実は天候に左右されるらしい。

以下の業務フローは飲食業の売上日報だ。典型的な「日次報告型のワークフロー」と言える。
ここでは天候と気温も併せて報告させ「気象による売上変動」を分析するための基礎データとなるようにしている。特筆すべきは、その気象データがあらかじめ自動的に入力されている点だ。報告担当者は『天候』や『気温』を入力する必要が無い。この雛形は、清掃業・建設業・人材派遣サービス等でも転用できるだろう。（「夏休みの絵日記」に転用してはイケナイ…）

[営業日報フロー-天気]

「滞留マップ」で日報ワークフローを加速させよ

調達部門や営業部門に付き物の「日報」。
成果や感想をまとめ、毎日マネージャに提出する仕組みだ。業種業態によっては、非常に有効な情報共有手法だ。提出する側も、コメントを書く側も、毎日のサイクルの中で処理できるのが都合良い。

しかし、一方でこの「日報」、、、マネージャ以外に参照される事は少ない。せっかくの生きた情報なのに、、、せっかくの履歴なのに、、、、何ともモッタイナイ話だ。

以下の報告フロー例『面談報告業務』では、その報告頻度が、「日次」ではなく「都度」を想定している。つまり報告書のタイトルは、『X年Y月Z日 佐藤一郎』ではなく『京都株式会社 X年Y月Z日往訪』となる。

こうしておくと、「取引先名」で検索した際に参照しやすい。ワークフローシステム全体を「取引先名」で検索すれば、『面談報告業務』に格納された履歴情報だけでなく、『発注業務』や『見積提出業務』などの履歴情報も、併せて一覧できるだろう。
例えば、経理担当者が外部からの請求書に疑念を持った際には、過去のコンタクト履歴を素早く参照する事が出来るようになる。例えば、経営者が初期コンタクトから見積業務・成約処理・請求業務と言った時系列の情報を得ることが出来るようになる。社内の情報が一気に整理される。

[面談報告フロー]

長いワークフロー定義を、分割する方法

業務の流れを定義する際、「業務プロセスの【S:始点】と【E:終点】を何に設定するか」は、センスが問われる。

例えば『問合対応フロー』であれば、「s:問い合わせの受信」に始まり「e:回答の送信」に終わる。
例えば『請求書発行フロー』であれば、「s:請求データの入力」に始まり「e:入金確認」に終わるだろう。
・・・これらのワークフロー設定に異論は少ない。

しかし仮に、『s:引合対応』から『見積受注』や『製造』などを経て『e:請求入金確認』に至る様な、、、長い工程を「一つの業務プロセス」として定義したとすれば、それには大きな反論があるだろう。何と言っても、フロー図が複雑になり、その作業工程が見づらくなる。更には「業務データ」の項目数も必然的に多くなり、処理に必要なデータが見づらくなってしまう。


最も簡単な解決策は、≪(A)フェーズに分割して管理≫する手法だ。

一連の業務を「東京から大阪までの新幹線」に喩えれば、「(1)東京から名古屋」と「(2)名古屋から京都」と「(3)京都から大阪」に3分割して管理する方法だ。つまり、(1)～(3)それぞれのフェーズで重要な手順を、各設計責任者が定義する。『建築工事』や『研究論文作成』など、プロジェクト自体が長期に及ぶ業務を想像すればイメージしやすい。関与する人間（管掌する部門）が変わるポイントでフェーズ分割するのが王道だろう。

もう一つの解決策は、抽象化して≪(B)単純サイクルに分割して管理≫する方法だ。

「東京から大阪までの新幹線」で言えば、これを「発車から停車」と言うシンプルな業務プロセスの繰り返しと捉える。極めて汎用性が高くなり、また業務手順を詳細に記録できるようになる。同時に（一般論ながら）「全体」を俯瞰しづらくなる。

[発車から停車までの業務プロセス]

日報や週報の書き方を教える必要がないワークフロー定義

「週報」や「日報」は、チーム内の作業状況や作業予定を可視化するツールとして有効だ。（管理職視点で言えば、各メンバの「考課資料（評価資料）」としても重要なのだろう）

しかし、週報や日報は「書き忘れ」や「未提出」がツキモノだ。いつでも『マイタスク一覧』に表示される様に自動起動させておくのが良いだろう。以下のワークフローサンプルでは、毎週月曜日の朝9時に『1.週次報告を書く』と言うタスクが自動的に立ち上がる。すなわち『タイマー開始イベント』でプロセスが開始される。メンバは少しずつ書き足して毎日「途中保存」すればイイ。最終提出となる「締切」は4日後の金曜日だ。

＜各タスク名＞
1.週次報告を書く、2.チェック＆指摘、3.指摘への対応、4.確認