ワークフローサンプル

前回「第595話：アンケート回答期限、もうひとつの設定方法」では、「タイマー時刻をデータ設定式でセットする方法」について紹介しました。

記事の中で、工程を減らしてワークフロー図の視認性を高める方法として、

「サービスタスク（データ設定）」については、ひとつの工程で、複数のデータ項目に値をセットできるようになっています。「サービスタスク（データ設定）」が連続して配置されている場合、ひとつに統合することを検討ください。

といった内容を案内しました。

「ん？具体的にはどうやってやれば良いの？？」という声が聞こえてきそうなので、実際に過去のワークフロー図を書き換えてみましょう！

[請求＆入金確認フロー１]

[請求＆入金確認フロー１（工程統合）]

前回、「イベント参加者アンケートに回答期限を設定」では、サービス工程を利用して『7日後に締め切り』をセットしました。アンケートに期限を設けることで、未回答であった場合にも、業務プロセスが滞留し続けることを防ぐことができます。

[イベント受付フロー-アンケート（期限セット）]

『7日後』の設定には、データ設定式を利用しています。
「#now.addDays(7)」と書くことで、「回答期限設定」工程にトークンが到着した時点（#now）から『7日後』を「回答期限（日付）」にセットすることができます。

＜「回答期限設定」設定画面＞

日付日時を表すデータ設定式には、他にも、

・2時間30分後：#now.addHours(2).addMinutes(30)
・月末：#now.getLastTimeInMonth()
・翌月5日：#today.getFirstTimeInMonth().addDays(4)

といったものがあります。
（他のデータ項目でも「データ設定式」を利用可能です。詳細は「M227: 業務データの結合や四則演算が自動実行されるように設定する」を参照）

前回は、「少人数セミナー」といったイベント受付を行うためのワークフローに、イベント開催後にアンケートを行うための仕組みを追加しました。参加者にアンケート回答してもらい、イベントの感想やフィードバックをもらうことで、次のイベントをより良いものに変えていくヒントになります。

ただ、前回のワークフローでは「アンケート回答されるまで待ち続ける」必要がありました。全ての参加者がすぐにアンケートに回答してくれたら、業務もスムーズに進みますが、残念ながらそういう訳にもいきません。（自分も含めて）アンケートに回答しないときもありますよね。。。

ということで、今回は、「アンケート回答に期限を設ける」ようにワークフローを改良します。期限を過ぎても回答がない場合、案件は自動的に終了するようになっています。

[イベント受付フロー-アンケート（期限セット）]

前回は、「少人数セミナー」といったイベント受付を行うためのワークフローを紹介しました。

担当者によるメール対応を卒業し、受け付けの仕組みをワークフロー化しておくことが、A. データ管理、B. フロー改善、の視点からも望まれます。

イベントが無事に開催された後には、参加者にイベントの感想やフィードバックを聞きたいものです。参加者の声を聞き、次のイベントに反映することで、「イベント開催業務」自体もカイゼンしていくことができます。そのイベントが、セミナーであれば、セミナー内容の見直しにも繋がりますね。

「イベントアンケート」収集用のワークフローを準備して、回答用URL（フォーム開始）をイベント参加者に一括でメール連絡する方法もありますが、今回は、「イベント受付フロー」の後工程にて、アンケートの入力を待ち受ける方法（フォーム待ち受け）を紹介します。

[イベント受付フロー-アンケート]

イベントやセミナーの参加受付、どうしてますか？

申込件数が100人、500人、1000人の想定なら「自動処理システム」を必死に考えるのが良いでしょう。

一方で、10人、20人、50人と言った規模ならどうでしょうか？？？

例えば「少人数セミナー」などのイベント受付。。。
イベント用のメールアドレスを設定し、受付業務は≪担当者によるメール対応≫とするのが手っ取り早いかもしれません。それはそれで良い面もあります。何事にしても素早く行動に移すコト、とても大切です。

しかし、「繰り返し開催されるイベント」になる様なら、どこかのタイミングで≪担当者によるメール対応≫は卒業すべきかも知れません。すなわち、その業務について「担当者しか知らない」と言う状況をやめ、キッチリと（できるだけ半自動的に）【記録】される様にしておきたいものです。

A. データ管理
B. フロー改善

２つ視点を踏まえてワークフロー化しておけば、受付担当者の【交代引き継ぎ】も容易になります。受付担当要員の【増員】の際にも協調的な対応が素早く実現できるようになるでしょう。そして、仮に「１年に１度」のイベントであったとしても「去年どうしたっけ？」と言う状況に陥らなくなります。

[イベント受付フロー-公開フォーム]

毎日利用する業務システムでは、入力インタフェース（入力画面）がわかりやすいかどうか、使いやすいかどうかは利用者にとってとても重要です。

ワークフローシステムにおいても、
・「何を入力したら良いのかわからない」
・「入力例やフォーマットがあるとわかりやすいのに」
・「せっかく入力したのに、入力エラーになったり、差し戻された」
・「人によって入力の仕方がバラバラで...」
といった声をよく聞きます。

そして、「出退勤の報告」「稟議の申請」「受注の報告」「問合に対する回答」などなど、、、日々の業務を思い返してみると、そこで発生する遅延や手戻りの多くは『上流工程における誤入力や不適切入力』が原因となっていることがほとんどです。

「業務改善」というと、業務フローの標準化やリソースの最適配置など大きな話になりがちですが、取り組む内容が大きくなればなるほど、その効果がでるまでに時間がかかってしまいます。一方で、「入力画面を工夫して、誤入力や不適切な入力を減らす」といったことは、日々の業務の中ですぐに取り組める小さな「業務改善」と言えるでしょう。小さなカイゼンを繰り返すことが、大きな成果にも繋がっていきます。

今回のワークフローサンプルでは、「入力例ボタン」のクリックで入力できる入力画面の工夫を紹介します。

［入力フォームのテストフロー］

「階層にバラツキがある組織での上司とその上司の指定方法」について、「職位による絶対的な指定方法」や「組織階層に従った相対的な指定方法」「業務プロセスを分離する方法、決裁者を指名する方法」を学んできました。

最後に番外編として、「職位ごとに開始位置を分ける方法」について記載された過去記を紹介します。

「業務プロセスを分離する方法」と近いアイデアですが、この記事では、ひとつの業務プロセスで開始位置を分けることで対応しています。「上司の指定方法」ではなく「上司が開始する方法」ではありますが、階層にバラツキがある組織でのワークフローアプリの設計方法のひとつとしてアタマに入れておいてください。