ワークフローサンプル

最終話：ご愛読の御礼とこれから

2018-12-27T09:00:00.000+09:00

長年、本ブログをご愛読いただき、誠にありがとうございました。

2010 年から続けてきました本ブログですが、少し形を変えて、以下２サイトにて、継続していくことにいたしました。

スタッフブログ (https://questetra.com/ja/category/blog/)
一般の方向けに、業務改善／ BPM ／ワークフローをテーマに、幅広い内容を発信していきます
デベロッパーズブログ (https://support.questetra.com/ja/category/developer-blog/)
Questetra BPM Suite のユーザの方向けに、「ワークフローアプリの作り方」等、サービスに特化した内容を発信していきます

業務テンプレートにつきましては、以下に整理していく予定です。

業務テンプレートの一覧 (https://questetra.zendesk.com/hc/ja/articles/360012492211)

今後とも、クエステトラをよろしくお願いいたします。
みなさま、よいお年を！

第596話：複数工程をひとつにまとめてワークフロー図を見やすく改良

2018-07-17T06:00:00.000+09:00

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

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

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

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

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

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

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

連続する複数の「サービスタスク（データ設定）」がそれぞれひとつの工程に統合されていて、ワークフロー図がスッキリ見やすくなっているのがわかります。「統合後」のワークフロー図の方が、人が処理する工程（ヒューマンタスク）が目立ちやすく、処理担当者にとってもわかりやすいのではないでしょうか。

一方で、自動処理工程（「サービスタスク（データ設定）」）で複数の処理を行なっているので、各処理内容については、少しわかりにくくなってしまっています。これは、「スクリプト工程」を利用してスクリプトで処理を行なっている場合や、「サービスタスク（アドオン）」を利用している場合にも言えることかもしれません。自動処理工程の名称の付け方には工夫が必要ですね。

「件名、ファイル名等 Set」工程では、データ項目への入力を自動的に行なっており、ここでは前回も紹介した「データ設定式」が活躍しています。

日付/日時をフォーマットを指定してセット

#{#format(data[25] , 'yyyy年MM月dd日')}
「請求書発行日（25）」のままだと「2018-07-17」で出力
フォーマットを指定して「2018年07月17日」を「◆請求書発行日表示（26）」にセット

工程が処理された日付/日時をセット

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

「プロセスID」等から「請求書ファイル名」をセット

Invoice-p#{#sformat('%05d', processInstanceId)}-#{#format(data[39], 'yyyyMMddHHmm')}-#{#format(data[28], 'yyyyMMdd')}.pdf
プロセスIDを5桁表示：#sformat('%05d', processInstanceId)}

プロセスIDが3桁の場合は、先頭に「0」が埋められる：00123
プロセス連番「#{processInstanceSequenceNumber}」やアプリ名「#{processModelInfoName}」などを表す変数も利用できる

関数を利用（今回の業務テンプレートでは未使用）

指定文字数のランダムな英数文字列を生成：#{#randomString(12)}
「件名」からハッシュ文字列を生成：#{#sha256(processInstanceTitle)}
JavaScript エスケープされた文字列を生成：#{#escapeEcmaScript(data['1'])}
XML エスケープされた文字列を生成：#{#escapeXml(data['2'])}

値をクリア（今回の業務テンプレートでは未使用）

「値もしくは式」に何もセットしない（空）ことで、入力値をクリア可能

[「件名、ファイル名等 Set」設定画面]

類似プロセス

雛形ダウンロード (無料)

業務テンプレート : 請求＆入金確認フロー１（工程統合）

(英文記事 (English Entry))

第595話：アンケート回答期限、もうひとつの設定方法

2018-07-09T06:00:00.000+09:00

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

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

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

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

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

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

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

『7日後に締め切り』をセットする方法ですが、実は、「タイマー中間イベント」単体でも実現することが可能です（Questetra Ver. 11.7）。

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

タイマーの設定に、データ項目を指定するだけでなく、「式」を指定することができるようになりました。これまで、ふたつの工程アイコンで実現していた『7日後に締め切り』を、ひとつの工程アイコンで実現できるようになります。

＜「回答待ち」設定画面＞

単に簡単に設定できるようになったというだけでなく、少ない工程アイコンでワークフロー図の視認性を高めることは、業務の流れの見える化において大切です。

工程アイコンの数を減らす、というのは、そのひとつの方法です。利用されていない工程アイコンは思い切って削除してしまうのも良いかもしれません。また、「サービスタスク（データ設定）」については、ひとつの工程で、複数のデータ項目に値をセットできるようになっています。「サービスタスク（データ設定）」が連続して配置されている場合、ひとつに統合することを検討ください。

ワークフロー図は、案件の進捗状況を把握する際にも大きな役割を果たします。ワークフロー設計者自身だけでなく、ワークフローの処理担当者にとってもわかりやすいワークフロー図を描くことを心がけましょう。

類似プロセス

雛形ダウンロード (無料)

業務テンプレート : イベント受付フロー-アンケート（期限セット２）

(英文記事 (English Entry))

第594話：イベント参加者アンケートに回答期限を設定

2018-07-02T06:00:00.000+09:00

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

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

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

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

アンケート依頼を行なった後、7日後に回答が締め切られるようになっています。フォーム待ち受け（「受信タスク（フォーム）」）工程にて、直接締め切りを設定できると良いのですが、そのような設定はできないため、少し工夫が必要です。
アンケート依頼を行う際、フローを分岐して、一方のフロー途中に「タイマー中間イベント」を配置しています。7日後にトークンが進み、アンケート回答済みであれば「終了イベント」に、アンケート未回答であれば「全終了イベント」に流れます。「全終了イベント」に進んだ場合、案件は自動終了され、回答待ち受けのフォームも無効となります。
回答待ち受けフォームの URL は、推測されにくい文字列により構成されていますが、表示内容や業務内容によっては、公開されたままになっているのは望ましくない場合もありますし、無期限だと攻撃されてしまうリスクも高まります。そういった点でも、期限を設定して、自動的に終了されるようにしておくのが良いですね。

[データ項目一覧画面]

雛形ダウンロード (無料)

業務テンプレート : イベント受付フロー-アンケート（期限セット）

類似プロセス

申し込みフォームに期限を設定する — 受信タスク (フォーム) の使い方 —

第593話：イベント終了後に参加者にアンケートを依頼

2018-06-25T06:00:00.000+09:00

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

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

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

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

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

このワークフロー定義では、「イベント受付」を行うだけでなく、イベント開催後に「アンケート」の回答を依頼できるようになっています。

イベント参加者ごとに、アンケート回答用のユニークURLがメール送信されます。参加者は、メールに記載されているURLを開いて、アンケートに回答することができます。

「アンケート」工程にて、受付時の「氏名」「所属」が表示されているように設定しておけば、記名アンケートとして意識してもらうことができます。一方で、この仕組み（ワークフロー）の場合、「氏名」「所属」をアンケート項目に含まなかったとしても、誰が回答したのかはわかってしまうので、無記名アンケートには向かないですね。

[イベント受付フロー-アンケート：「アンケート」画面]

[データ項目一覧画面]

類似プロセス

「社内アンケート」をガンガン行える汎用レビュー依頼 (2014-09-29)
企画１に対し回答がＮ集まる「社内アンケート」のデータ構造 (2014-10-06)
展示会アンケートを活かす業務プロセス (2014-02-10)

申込フォームで、メールの存在確認をはさむ — 受信タスク (フォーム) の使い方 —

第592話：ワークフローでイベント申し込みを受け付ける

2018-06-18T06:00:00.000+09:00

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

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

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

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

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

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

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

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

このワークフロー定義は、ウェブサイトに「申し込みフォーム」を埋め込む事が想定されています。

申込者がウェブサイトから申し込む事でワークフローが開始されます。必然的に「自動的に記録」され、データ閲覧権限のある社員ならいつでも参照することができます。
その後の対応は、「受付完了メール」の送信は自動化されているものの、仔細のやり取り履歴については受付担当者が手動記録する汎用的な仕組みになっています。もし「かならず行われるオペレーション」があるなら、工程として追加するのが良いでしょう。

[イベント受付フロー-公開フォーム：「1.確認/受付完了メール作成」画面]

[データ項目一覧画面]

＜類似プロセス＞

イベント参加証を PDF で送る（ワークフローの自動化） (2014-03-17)
第558話：クレーマーを減らす「受付番号」の採番工夫 (2017-10-23)
第477話：社外からの依頼で始まる業務プロセスは改善のしがいがある (2016-04-04)

雛形ダウンロード (無料)

業務テンプレート : イベント受付フロー(公開フォーム)

M220 (自動開始) 公開フォーム画面に入力があった時に自動的に開始されるように設定する (使い方)

(英文記事 (English Entry))

第591話：入力画面を工夫して、業務カイゼンに繋げよう！

2018-06-11T06:00:00.000+09:00

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

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

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

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

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

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

[入力フォームのテストフロー：「1.入力テスト」画面]

入力画面を設計する際は、わかりやすい「データ項目名」を設定したり、入力説明の文章や入力例を記載しておく（入力ヒント）ことが基本となります。さらに、文字入力ではなく選択肢で選べるようにしたり、データ初期値を設定しておくことで、利用者の入力負荷は軽減されますし、入力データのバラツキを抑えることにもつながります。

その上で、入力支援を行うためのボタンを配置したり、入力チェックや他のデータ項目へのデータセットを行うようなスクリプトの利用を検討するのが良いでしょう。

Questetra の［入力ヒント］には任意の HTML／JavaScript を設定できますが、場合によっては「入力フォームの全体レイアウトを崩してしまう」等のトラブルになる可能性もあります。HTML／JavaScript の知識や経験のあるスタッフ自身が、自己責任においてメンテナンス可能な範囲で設定する必要があると言えます。
▼［入力ヒント］設定サンプル（HTML/JavaScript）：『サービス名』

例：<button type="button" id="btnConsultant_1">月額顧問料（月単位）</button>、
<button type="button" id="btnInstruct_1">講習会講師料（日単位）</button>、
<button type="button" id="btnDoc_1">ドキュメント作成費</button>
<script type="text/javascript">
jQuery('#btnConsultant_1').on('click',function(){
jQuery('input[name="data\\[1\\].input"]').val( "月額顧問料（月単位）" );
});
jQuery('#btnInstruct_1').on('click',function(){
jQuery('input[name="data\\[1\\].input"]').val( "講習会講師料（日単位）" );
});
jQuery('#btnDoc_1').on('click',function(){
jQuery('input[name="data\\[1\\].input"]').val( "ドキュメント作成費" );
});
</script>

▼［入力ヒント］設定サンプル（HTML/JavaScript）：『見積価格』

例：<button type="button" id="btnS_2">（15年キャリア）820,000</button>、
<button type="button" id="btnA_2">（5年キャリア）452,000</button>、
<button type="button" id="btnB_2">（5年未満）339,000</button>

<script type="text/javascript">
jQuery('#btnS_2').on('click',function(){
jQuery('input[name="data\\[2\\].input"]').val( "820000" );
});
jQuery('#btnA_2').on('click',function(){
jQuery('input[name="data\\[2\\].input"]').val( "452000" );
});
jQuery('#btnB_2').on('click',function(){
jQuery('input[name="data\\[2\\].input"]').val( "339000" );
});
jQuery('input[name="data\\[2\\].input"]').parent().parent().css("background-color","#FFC0CB");
</script>

▼［入力ヒント］設定サンプル（HTML/JavaScript）：『欠勤理由』

例：<button type="button" id="btn1_5">レジャーや家庭の都合など：私用（プライベート）</button>、
<button type="button" id="btn2_5">地域のイベントに参加する場合：私用（地域行事参加）</button>、
<button type="button" id="btn3_5">朝起きて腹痛だった場合：体調不良（腹痛）</button>、
<button type="button" id="btn4_5">子供発熱の場合：看病（子供）</button>

<script type="text/javascript">
jQuery('#btn1_5').on('click',function(){
jQuery('input[name="data\\[5\\].input"]').val( "私用（プライベート）" );
});
jQuery('#btn2_5').on('click',function(){
jQuery('input[name="data\\[5\\].input"]').val( "私用（地域行事参加）" );
});
jQuery('#btn3_5').on('click',function(){
jQuery('input[name="data\\[5\\].input"]').val( "体調不良（腹痛）" );
});
jQuery('#btn4_5').on('click',function(){
jQuery('input[name="data\\[5\\].input"]').val( "看病（子供）" );
});</script>

▼［入力ヒント］設定サンプル（HTML/JavaScript）：『稟議概要』『予算区分』

頻出：<button type="button" id="btnExhibit_78">（予算内の展示会出展）</button>、
<button type="button" id="btnProcurement_78">（想定外の備品調達）</button>

<script type="text/javascript">
jQuery('#btnExhibit_78').on('click',function(){
jQuery('input[name="data\\[7\\].input"]').val( "Cloudエキスポ出展に関連する外注" );
jQuery('input[name="data\\[8\\].selects"][value="1"]').prop('checked', true);
});
jQuery('#btnProcurement_78').on('click',function(){
jQuery('input[name="data\\[7\\].input"]').val( "故障に伴うパソコンの購入" );
jQuery('input[name="data\\[8\\].selects"][value="3"]').prop('checked', true);
});
</script>

▼［入力ヒント］設定サンプル（HTML/JavaScript）：『稟議理由』

<span style='color:#ff0000;'>※要点を押さえ、箇条書きで記入すること</span><br>
文例：<button type="button" id="btnReasonA_9">（パソコンの故障）</button>、
<button type="button" id="btnReasonB_9">（人員増に伴う急な追加）</button>、

<script type="text/javascript">
jQuery('#btnReasonA_9').on('click',function(){
var myReason = "";
myReason += "運搬中の落下(2015年12月)によりモニタ外部出力が破損している\n";
myReason += "2013年1月の購入から3年以上が経ち最新OSの動作に支障がある\n";
myReason += "D社は最安値とはなっていないが、他社の差額は小さく、使い慣れた従来シリーズ機とする";
jQuery('textarea[name="data\\[9\\].input"]').val( myReason );
});
jQuery('#btnReasonB_9').on('click',function(){
var myReason = "";
myReason += "想定を超える注文を受け、対応アルバイトを30人増員する\n";
myReason += "予備パソコンは20台しかなく、10台の追加が必要となった\n";
myReason += "（D社は最安値かつ最短納期となっている）";
jQuery('textarea[name="data\\[9\\].input"]').val( myReason );
});
</script>

▼［入力ヒント］設定サンプル（HTML/JavaScript）：『契約開始月』

<button type="button" id="btnThisMon_11">今月</button>、
<button type="button" id="btnNextMon_11">来月</button>

<script type="text/javascript">
jQuery('#btnThisMon_11').on('click',function(){
var myToday = new Date();
var y = myToday.getFullYear();
var m = myToday.getMonth() + 1; // Jan: 0
if (m < 10) { m = '0' + m; }
jQuery('input[name="data\\[11\\].input"]').val( y + "-" + m );
});
jQuery('#btnNextMon_11').on('click',function(){
var myToday2 = new Date();
myToday2.setDate(1);
myToday2.setMonth(myToday2.getMonth() + 1);
var y2 = myToday2.getFullYear();
var m2 = myToday2.getMonth() + 1; // Jan: 0
if (m2 < 10) { m2 = '0' + m2; }
jQuery('input[name="data\\[11\\].input"]').val( y2 + "-" + m2 );
});
</script>

▼［入力ヒント］設定サンプル（HTML/JavaScript）：『契約終了月』

<button type="button" id="btnOneYear_12">→１年契約</button>、
<button type="button" id="btnTwoYear_12">→２年契約</button>

<script type="text/javascript">
jQuery('#btnOneYear_12').on('click',function(){
var myDateStr = jQuery('input[name="data\\[11\\].input"]').val();
var myStartMon = new Date( myDateStr + "-01");
var myEndMon = new Date();
myEndMon.setMonth( myStartMon.getMonth() + 11 );
var y = myEndMon.getFullYear();
var m = myEndMon.getMonth() + 1; // Jan: 0
if (m < 10) { m = '0' + m; }
jQuery('input[name="data\\[12\\].input"]').val( y + "-" + m );
});
jQuery('#btnTwoYear_12').on('click',function(){
var myDateStr = jQuery('input[name="data\\[11\\].input"]').val();
var myStartMon = new Date( myDateStr + "-01");
var myEndMon = new Date();
myEndMon.setMonth( myStartMon.getMonth() + 23 );
var y = myEndMon.getFullYear();
var m = myEndMon.getMonth() + 1; // Jan: 0
if (m < 10) { m = '0' + m; }
jQuery('input[name="data\\[12\\].input"]').val( y + "-" + m );
});
</script>

＜データ項目一覧画面＞

類似プロセス

M213 (入力画面) 処理フォーム画面をデコレーションする（HTML/JavaScript） (使い方)

雛形ダウンロード (無料)

業務テンプレート : 入力フォームのテストフロー

(英文記事 (English Entry))

第590話：階層にバラツキがある組織での上司とその上司の指定方法４（番外編）

2018-06-04T06:00:00.000+09:00

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

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

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

471話：オレの申請に「決裁」は要らぬ！（by 部長）

部長自身が「稟議書」を書く。。。

そもそも決裁権者なのだから、稟議する（決裁権者に判断を乞う）という行為自体が要らないハズだ。それが部予算内での判断なら、なおさらだ。しかし、そうであってとしても「稟議書を作成すべし」としている会社は少なくない。つまり、「組織として形成された意思は文書として記録に残す」という視点にたつとともに、監査対応の効率化を想定している。

ただ、、、ワークフローシステムにおいて、「自分で申請して、自分で決裁する」というのは、たしかにメンドウな話だ。

以下のワークフローは、2016年版の基本業務に収録されている「第462話：稟議書を回す」をアレンジしたものだ。「部長ロール」を持つユーザは『2.決裁する』を通らないフローで、稟議書を提出できるようになっている。

[稟議フロー]

アレンジ前の業務フロー図（以下）と見くらべてもらえば分かるが、、、この業務フロー図には『2x.部長自身が作成する』という先頭工程が追加されている。つまり「部長ロール」をもつユーザは、このワークフローを『2x.部長自身が作成する』から開始することができるのだ。そのフローに「二度手間」はない。

＜「第462話：稟議書を回す」の稟議フロー＞

ちなみに、（これまた一目瞭然だが）、たとえ部長提出の記録であっても「100万円超の外部支払」が発生する場合には、自動的に『3.役員承認する』の工程に流れていく。つまり役員が「不承認」の判断をすれば、その決断自体が無効となってしまう。注意が必要だ。

「むむむ。ならば、100万円以下に分割して・・・。」　そういう発想は「やや不純な動機」とも言えるが、それはそれでルールなのだから仕方がないのだろう。

[稟議フロー：「2x.部長自身が作成する」画面]

＜自動生成PDFの例＞

＜データ項目一覧画面＞</div>

雛形ダウンロード (無料) 業務テンプレート : 稟議フロー

類似プロセス

(英文記事 (English Entry))

第589話：階層にバラツキがある組織での上司とその上司の指定方法３

2018-05-28T06:00:00.000+09:00

「階層にバラツキがある組織での上司とその上司の指定方法」について、「１」では「職位による絶対的な指定方法」を、「２」では「組織階層に従った相対的な指定方法」を学びました。

いずれの方法も、良し悪しがあり、承認・決裁者ほど、運用時に注意してもらう必要がありました。結局のところ「深さにバラツキがある組織」の場合、どうしても業務ルールをシンプルに記述することが難しくなってしまいます。

組織の規模や、組織メンバーの業務ルール／システム習熟度などによっても、運用しやすい・使いやすいワークフロー（設定方法）は変わってきます。今回、さらに２つのワークフローを紹介しますが、過去に紹介したものも含め、各社の実態に合わせて、「どの記述が誤解無く運用しやすいか」を検討＆選択してください。

ひとつ目は、起案者によってワークフローを分離する方法です。
つまり、申請する立場によって承認経路が変わるなら、ワークフローを分けてみても良いかもしれません。

[稟議フロー（マネージャ起案を別の業務プロセスとして分離）]

「稟議フロー（絶対的表記２）」や「稟議フロー（相対的表記）」では、階層の異なるフローをひとつのワークフローで実現しようとしたため、分岐などが必要となり設定が少し複雑になりました。
ワークフローを分離することで、管理すべき対象は増えますが、ひとつひとつのワークフローはシンプルに設計できるというメリットがあります。

ふたつ目は、起案時に「承認者」「決裁者」を指定する方法です。

[稟議フロー（承認・決裁者を指名）]

担当者を直接指定できるため、非常にわかりやすく、どのようなケースにも対応できるシンプルな方法となります。「承認者」が未指定の場合は、「2.承認」工程は、自動的にスキップされます。
一方で、担当者の指名は起案者自身に委ねられるため、業務ルールがわかっていない場合や誤って指定してしまった場合など、期待通りの「承認者」「決裁者」に案件が回らない可能性もある点に注意が必要です。

＜オペレーティング画面：（１.を入力中の状態）＞

雛形ダウンロード (無料)

業務テンプレート : 稟議フロー（マネージャ起案を別の業務プロセスとして分離）
業務テンプレート : 稟議フロー（承認・決裁者を指名）

類似プロセス

(英文記事 (English Entry))

第588話：階層にバラツキがある組織での上司とその上司の指定方法２

2018-05-21T06:00:00.000+09:00

先週に引き続き「処理担当者の設定方法」について学びます。

「階層にバラツキがある組織での上司とその上司の指定方法１」では、『上司』の承認を得て、さらに『上司の上司』の決裁を得る二段階決裁の方法を紹介しました。稟議業務以外でも良くある承認フローの形式です。今回は、前回の業務フロー図について、違う書き方を紹介します。

以下のワークフロー図では、２番目のスイムレーンを「マネージャ」（職位による絶対的な指定）ではなく「申請を行った人の上司」（相対的な指定）にしています。
この様に設定すると、申請者が所属する組織の上司に『2.承認／決裁』仕事が割り当てられる事になります。すなわち「部長(役員)2人、マネージャ4人、メンバ12人」の内、『メンバ』が申請した場合は『マネージャ』が『承認』する事になり、『マネージャ』が申請した場合は『部長』が『決裁』する事になります。

[稟議フロー（相対的表記）]

前回紹介した業務フロー図では、『マネージャ』の地位にある人が『1.申請』で申請した際には、自分で「1.申請」と「2.承認」を連続して処理する必要がありましたが、この業務フロー図であれば「申請」するだけで部長決裁に回すことができます。

[稟議フロー（絶対的表記１）]

もっとも、この様なルールを実現するためには、組織設定において、『マネージャ』は「チームの責任者として」と「部の一員として」の両方の所属設定が必要となります。こうする事で『マネージャ』は、申請時に「部の一員として上司の承認を得る」という業務になる訳です。なお、部長達にしてみれば、タスク『3.決裁』以外にも、タスク『2.承認／決裁』で決裁処理する必要がでてきます。もっとも『2.承認／決裁』で決裁処理した案件を『3.決裁』に回す必要はありません。

「これはコレで、部長が混乱するな…」
結局のところ「深さにバラツキがある組織」の場合、どうしても業務ルールをシンプルに記述するのが難しいです。実際、規程文自体も、「原則として、マネージャー承認を経て、部長が決裁する」と、例外を記述せざるを得ません。なお、前回（絶対的表記１）および上記（相対的表記）で示した業務フロー図以外にも、次のような書き方もできます。各社それぞれの実態に合わせて、「どの記述が誤解無く運用しやすいか」を検討＆選択して頂く必要があります。

[稟議フロー（絶対的表記２）]

類似プロセス

稟議ワークフローに大事な「組織」と「ロール」 (2012-01-23)
稟議書ワークフロー、「代理決裁」の書き方 (2013-02-12)
第471話：オレの申請に「決裁」は要らぬ！（by 部長） (2016-02-22)

雛形ダウンロード (無料) 業務テンプレート

(英文記事 (English Entry))

第587話：階層にバラツキがある組織での上司とその上司の指定方法１

2018-05-14T06:00:00.000+09:00

過去の人気記事から、「処理担当者の設定方法」について学びます。

「上司」の指定方法については、いくつかの方法があり、組織構造との関係もあるため、ワークフロー設定の中では難易度が高めの内容となります。まずはいろいろな考え方を知っておくのが良いでしょう。

社長1人、部長(役員)2人、マネージャ4人、メンバ12人。仮に、この「メンバ12人」の内の2人が『部長直下』に配属されているとします。具体的に例示すれば、

2人の部長が主管する部に直接所属している人が『2人×2』
4人のマネージャが主管する「チーム」に所属している人が『2人×4』

の組織を想定してみます。もちろん「チーム」自体は「部」に所属します。具体的には、営業部の傘下に多くのチームがありながらも営業部長自身が営業事務メンバ2人を直接指揮し、製造部の傘下に多くのチームがありながらも製造部長自身が品質管理メンバ2人を直接指揮しているようなケースとなります。

この組織構造の特徴は「深さにバラツキ」がある、ということになります。良くある話ですね。

さて、こう言った「深さにバラツキがある組織」の場合、稟議承認フローのエスカレーションは、どの様な業務フロー図で表記すべきでしょうか？国際標準記法 BPMN に従った書き方を考えてみましょう。議論が分かれる部分は「原則として、マネージャー承認を経て、部長が決裁する」と言う社内ルールを、どの様に描くべきか、という点です。すなわち、この組織の『2人×2』にとっては「マネージャ」が居ません。

[稟議フロー（絶対的表記１）]

最もシンプルな書き方は、まず「部長がマネージャを兼務している」と考えるやり方です。

すなわち「営業部長自身が直接指揮する営業事務メンバ5人」を「営業事務チーム」と解釈します。組織の深さのバラツキが無い様に取り扱うと言っても良いでしょう。

この場合、全ての起案は「1.申請」→「2.マネージャによる承認」→「3.部長による決裁」の流れを踏襲します。大した手間では無いものの、この BPMN をそのままシステム化すると、部長はタスク「2.承認」と「3.決裁」を続けて処理しなければならない仕様となります。

ちなみに、この考え方を準用すれば、「マネージャが起案したいケース」もシンプルに考えられます。すなわち、マネージャは「1.メンバとして申請」し、自分自身が「2.マネージャとして承認」し、部長に「3.決裁」をもらえば良いです。

なお、「営業部」が『組織』なのに対して、「マネージャ」は『組織』ではありません。すなわち「マネージャ」は『ロール』で定義されるべき集団です。この業務フロー図で言えば、全ての構成員は『自分の所属する組織』もしくは『上位組織』に居る「マネージャ」の承認を得ることになります。

次週は、相対的な関係を使った業務フロー図の書き方を紹介します。「続けて処理」を無くし、ステップ数を減らす事ができます。

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート : 稟議フロー（絶対的表記１）

＜類似プロセス＞

稟議ワークフローに大事な「組織」と「ロール」 (2012-01-23)
稟議書ワークフロー、「代理決裁」の書き方 (2013-02-12)
第471話：オレの申請に「決裁」は要らぬ！（by 部長） (2016-02-22)

(英文記事 (English Entry))

第586話：BPMNでワークフロー図を書こう！（後編）

2018-05-07T06:00:00.000+09:00

先週に引き続き、BPMN (Business Process Model and Notation) を利用したワークフロー定義の方法について、『Workflow Sample』の過去記事を紹介します。
BPMN は、「Model（モデル）)」であり、「Notation（記法）」です。BPMN で書いたワークフロー定義は、BPMシステム上でワークフローシステムとして稼働させるこができます。BPMN を覚えて、あなたの業務をシステム化してみませんか？
BPMN の書き方については、『BPMN超入門』も参考にしてください。

(5) トークンが無限増殖するループ構造
ワークフロー定義では、いろいろなループ構造を表現することができます。ただ、中には、エラーとなってしまうループ構造もあるので、注意が必要です。

[BPMNサンプル-ループエラー]

M204 (業務の流れ) 処理フロー途中に、ループ構造を設定する (使い方)

(6) 業務フロー図を我流で書くなんて、ダメダメ
複数人が同時並行で処理を進めている場合の、処理の「中断」に関する書き方を学びます。BPMN では、「全終了イベント」として定義されています。

[BPMNサンプル-一箇所全終了]

(7) 成果物は同じでも、プロセス開始のキッカケは様々
ワークフローは様々なキッカケで始めることができます。人が開始するだけでなく、タイマーなどにより自動的に開始する方法も想定されています。

[BPMNサンプル-複数多種開始イベント]

BPMNの基礎、Questetra でのモデリング方法

(英文記事 (English Entry))

第585話：BPMNでワークフロー図を書こう！（前編）

2018-05-01T06:00:00.000+09:00

本ブログ『Workflow Sample』では、様々な業務のワークフロー定義を紹介しています。ワークフロー定義は、BPMN (Business Process Model and Notation) を用いて書かれており、ワークフロー図を見れば業務の流れが（直感的に）わかるだけでなく、業務内容を共有することも容易です。

世の中は黄金週間（GW）、この２週は「BPMNの書き方」についての過去記事を紹介します。業務フロー図の表記法 BPMN や業務フロー図の書き方について、学習する機会としてください。

(1) 業務フロー図表記法BPMNの基本は「分岐」だ

業務の流れを「分岐」させる方法について学びます。3つある分岐パターンのうち、「どれかひとつ」に進む「XOR分岐（排他分岐）」と「全て」に進む「AND分岐（並列分岐）」を紹介します。

[BPMNサンプル-XOR分岐]

[BPMNサンプル-AND分岐]

(2) 案件によっては同時並行処理が必要になる業務フロー

3つの分岐パターンのうち、条件を満たす「いくつか」に進む「OR分岐（包含分岐）」を紹介します。この分岐が利用されるケースは非常に稀です。

[BPMNサンプル-OR分岐]

(3) 業務フロー途中で「定型メール」を自動送信

BPMN の「イベント」について学びます。クラウド型ワークフロー『Questetra BPM Suite』で利用可能なイベントは、2018年5月現在、14種類あります。

[BPMNサンプル-メール送信-ループ]

M224 (自動イベント) 業務データを挿し込んだメール文が、自動的にメール送信されるように設定する (使い方)

(4) 「子プロセス」を産む業務フロー定義の書き方

「メッセージ送信中間イベント（HTTP）」を利用して、プロセス接続（プロセス連携）を行うための方法を学びます。

[BPMNサンプル-双子プロセス生成]

M411 (プロセス接続) "納品プロセス" から "請求プロセス" が自動開始されるように設定する (使い方)

BPMNの基礎、Questetra でのモデリング方法

[英文記事 (English Entry) ]

第584話：「休暇申請」は事前にしっかりと！

2018-04-23T06:00:00.000+09:00

先日紹介した「出退勤申請フロー」では、出退勤時刻の報告が行われずに締め切りを過ぎた場合、勤怠ステータスが「休暇」となる仕組みとなっていました。ということは、出退勤申請フローの処理記録、すなわち出勤簿を見れば、本人や上司、管理部門は、いつ休暇を取ったのかを確認することができるのでしょうか？

いや、ちょっと待てよ。。。出退勤申請を忘れてしまって、出勤したのに休暇になってしまっている可能性もあるのではないでしょうか？そもそも、「休暇」については、事前に申請し、上司に承認されて初めて取得できるものですね。

管理部門は、「休暇申請」と「出勤簿（出退勤申請の記録）」を突き合わせて、毎月の勤務実績を確認しています。出勤簿では休暇となっているのに、該当する申請が提出されていない場合は、、、出勤簿の修正（再申請）か休暇申請（事後申請）を依頼することになります。管理部門の余計な手間を減らすためにも、出退勤申請や休暇申請は正しく行い、月末には抜け漏れがないかを自ら確認するのが望ましいですね。

[休暇申請フロー]

「休暇申請」は休暇を取得する日よりも前に行い、上司に承認されるべきです。そうすれば、同僚に不在時の対応を依頼したりするなど仕事の調整もできます。しかし、時には、朝起きて「風邪や病気で会社に行けない」場合もあるでしょう。その点、クラウド型ワークフローであれば、布団の中からスマホで申請することも可能です。

また、この「休暇申請フロー」では、業務マニュアルを参照できるようになっています。「休暇申請」であれば、入力フォームの画面を見れば、おおよそ記入すべき内容もわかると思いますが、申請処理時に業務に関するマニュアルや規定を参照できるのは便利ですね。業務マニュアルがきちんと整備されていれば、良くある質問への回答を減らしたり、後工程での無用な手戻りを避けるといったメリットもあります。これもひとつの「業務改善」と言えます。

＜業務マニュアルの例＞

＜オペレーティング画面＞

＜データ項目一覧画面＞

雛形ダウンロード (無料) 業務テンプレート : 休暇申請フロー

類似プロセス

(英文記事 (English Entry))

第583話：類似ワークフローの統合でプロセス改善

2018-04-16T06:00:00.000+09:00

新年度も半月が経ち、新入社員も新しい環境に慣れてきた頃ではないでしょうか？

この２週は、「出退勤報告フロー」「日次報告フロー」とふたつの新入社員向け（とも限りませんが）のワークフローを紹介しました。毎日、きちんと「報告」してきた方なら、ワークフロー基盤の操作にもすっかり慣れたと思います。

・第581話：新入社員は勤怠報告でワークフローに慣れよう！
・第582話：毎日の業務報告で1日を振り返ろう！

このふたつのワークフロー、見比べてみると（使ってみると）、とてもよく似ていることがわかります。

毎朝、自動開始され、全社員の［マイタスク］に入れられる
社員が報告し、上司（リーダー）が確認する
締め切りが設定されていて、それまでに完了しないと自動終了する

「出退勤時刻」「業務内容」と報告すべき内容は異なりますが、ワークフローの大きな流れは同じです。それなら、ひとつにまとめちゃえば良いのでは？！

[出退勤・日報フロー]

第581話の「出退勤報告フロー」をベースに、「業務内容」も報告できるように改良してみました。これで、「出退勤時刻」とその日の「業務内容」をひとつのワークフローで報告・確認できるようになりました！便利になりましたね！！

今回はちょっとした変更なので、ものの10分もあれば新しいワークフローが完成します。あれもこれも、ひとつのワークフロー定義に盛り込みすぎるのは良くありませんが、類似したフローを統合することで利用者は少ない操作で報告を完了できます。変更箇所は少ないですが、毎日、たくさんの人が利用するようなワークフローであれば、改良の効果は大きいでしょう。
（一方で、複雑になりすぎた壮大なワークフローを分割するのも大きな業務改善に繋がります。）

日々、ワークフローを利用・運用していく中で、継続的に改良し続けることは非常は大切です。データ項目名を変えるだけや、説明を加えるだけで、利用者にとって使いやすくなることも多いです。また、業務ルールが変更になったときに、即座にワークフロー定義に反映させることも大切です。組織や利用者に合わせて、柔軟な変更・改良を心がけましょう。

＜オペレーティング画面：（2. を入力中の状態）＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]
業務テンプレート：出退勤・日報フロー

＜類似プロセス＞

プロセス改善物語（ホテル編）

プロセス改善物語（Web メディア編）

プロセス改善物語（SaaS ベンダー編）

≪関連記事≫

[英文記事 (English Entry) ]

第582話：毎日の業務報告で1日を振り返ろう！

2018-04-09T06:00:00.000+09:00

春というより初夏のような日が続いていますね。桜はもう見納めでしょうか。

前回は、新入社員も毎日行う「出退勤報告フロー」について紹介しました。初期値や入力画面を工夫することで、入力負荷を軽減し、毎日きちんと報告されることを念頭に設計されていました。毎日きちんと報告する、と言えば、日報もそのひとつでしょう。研修期間中であれ、配属されてからであれ、「実施した業務」や「日々の学習事項」を上司や先輩に報告することは、新入社員にとって大切な仕事と言えます。

日報を通じて、ビジネスマナーや仕事の仕方を学んだり、上司や先輩、あるいは他の社員とコミュニケーションを図るきっかけにもなります。何より、1日を振り返り、学んだことや気付いたことを整理する機会は、新しい環境では特に大切ですね。

[日次報告フロー]

毎朝8時30分に自動起動する非常にシンプルな報告フローです。新入社員だけでなく、全社員の［マイタスク］に、「日報記入」タスクが入るようになっています。

退社時にまとめて入力するのも良いですが、都度、実施したことをメモしておいて、一時保存しておく方法もオススメです。新入社員は、不明点や疑問点、相談事項を記載しておけば、上司や先輩から適切なフィードバックを得られるでしょう（もちろん、わからない時に直接聞ければ良いのだけど...）。

毎日、報告を完了してから退社するのが望ましいですが、報告できなかったり、忘れてしまうこともありますよね。この「日次報告フロー」では、締め切りを設定し、締め切りが来たら「未報告」として、自動終了されるようになっています。夏休みの宿題のように(!?)、1週間以上も前の出来事を思い出しながら報告するのは、本来の趣旨とは異なります。「未報告」とならないよう、［マイタスク］にあるうちにきちんと処理するように心がけましょう。

＜タイマー設定画面＞

＜オペレーティング画面：（１.を入力中の状態）＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：日次報告フロー

＜類似プロセス＞

日報

ワークフローの無料試用期間、何を流す？（日報） (2013-12-30)
日報や週報の書き方を教える必要がないワークフロー定義 (2011-11-07)
「タイマー開始」なワークフローは、仕事のリズムを整える！ (2014-09-08)
「滞留マップ」で日報ワークフローを加速させよ (2013-09-02)
溜まるハズの「日報」が、溜まらない仕組みを作れ！ (2014-11-04)
リモートワーク、「就労時間管理」も意外と大切デス (2014-09-22)
業務用スマホアプリの Backend に SaaS Workflow を使う (2014-12-22)

営業日報

「日報」に気象データを取り込む意味（天気API活用） (2013-10-21)
売上高をその日の為替レートで自動変換（為替API活用） (2013-10-28)
取引先マスターを参照する営業日報 (2015-10-05)
日報プロセスに「GPS情報」も記録する (2015-10-19)

≪関連記事≫

[英文記事 (English Entry)]

第581話：新入社員は勤怠報告でワークフローに慣れよう！

2018-04-02T06:00:00.000+09:00

春、桜の季節、新生活の季節です。

今日から新年度、多くの会社で入社式が行われます。新入社員が配属されると、上司や先輩社員、あるいは人事担当者が会社生活のアレコレをレクチャーすることになります。その中にはきっと「勤務報告の仕方」も含まれているハズですね。

「働き方改革」や「裁量労働制」が話題となることが多い昨今、労働時間を適正に記録し、把握できるようにすることは非常に重要です（勤怠管理）。古くは紙への記入やタイムカードへの打刻にはじまり、ICカードでの打刻、専用の勤怠報告システムなどなど、様々な方法で出勤・退勤時刻の記録、報告が行われていますが、汎用なワークフローシステムを利用するのもひとつの方法です。

「出退勤報告フロー（勤怠報告フロー）」は、基本業務パックで紹介した「稟議フロー」「物品購入依頼フロー（調達購買フロー）」「立替金精算フロー」と合わせて、『ワークフローの４大アプリ』と呼ばれることもあります。クラウド型ワークフローを利用して、勤怠管理を行うことで、次のようなメリットがあります。

テレワーク／リモートワークや外出の多いスタッフも、作業場所や外出先から記録できる
毎日の処理により、新しいメンバーもワークフローの操作に慣れることができる
組織に合わせて、継続的に、使いやすく改善できる（働き方改革にもつながる）

[出退勤報告フロー]

新入社員にとって、新しい組織、新しい仕事、新しいシステム...新しいことだらけで覚えることがいっぱいです。勤怠報告、経費精算、休暇申請などなど、目的ごとに異なるシステムへのログインが必要だとしたら、とても大変です（よね？）。その点、すべてをワークフローシステム（ワークフロー基盤）で実現できたら、覚えることは最小限で済みますし、習熟のスピードも速くなるでしょう。

この「出退勤報告フロー」では、報告漏れを防いだり、入力者の操作を軽減したりするために、様々な工夫がなされています。

自動開始

「出勤報告忘れ」（打刻忘れ）の発生を最小化すべく、「出勤時刻を報告する」という『マイタスク』が毎朝自動的に割り当てられる仕組みになっています。労働者側は、毎朝届くリクエストに応じる形で出勤時刻を入力すればよいため、ヌケモレが発生しづらいようになっています。（ちなみに、何も入力せず20時間放置すれば自動的に「休暇日」とみなされるため、長期休暇などの際には特に操作する必要がありません）

初期値設定

デフォルト値（初期値）が予め入力されている点も「入力負荷」を下げるという観点で良いでしょう。つまり「出勤9:00／退勤17:00／休憩１時間」という想定通りの勤務を行った日は、数字入力の手間なく申請することができます。

入力支援

入力支援ボタンが装飾（デコレーション）されている点も注目すべきです。最近では「カレンダー入力」や「30分ごとの時刻セレクト入力」が入力支援として多用されるようになっていますが、この例では更に「よくある候補ボタン」が列挙されています。確かに『退勤時刻』として入力される値は24時間の内でも限られている訳で、労働者の時刻入力の手間を大幅に低減していると言えるでしょう。

＜オペレーティング画面：（１.を入力中の状態）＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：出退勤報告フロー

＜類似プロセス＞

出勤時刻と退社時刻をワークフローで！ (2014-01-20)
第465話：勤怠管理もクラウド型ワークフローで！ (2016-01-12)
第472話：業務システムでインフルの兆候をつかむ？ (2016-02-29)
第523話：クラウドを用いた労働時間の適正な把握 (2017-02-20)
第524話：サーバサイド JavaScript による業務の自動化 (2017-02-27)
第535話：システムを改良し続ける事こそ、真の働き方改革 (2017-05-15)

≪関連記事≫

[英文記事 (English Entry) ]

第580話：基本業務パック(3) 「立替金精算フロー」

2018-03-26T06:00:00.000+09:00

過去２週に引き続き、クラウド型ワークフロー『Questetra BPM Suite』にプリインストールされている「基本業務パック」の業務について紹介します。

第３弾は「立替金精算フロー」（経費申請フロー）です。
第464話：立替金精算依頼を回す（基本業務パック） (2016-01-04)

領収書をスマホ撮影した画像をメール添付して申請する業務フローです。逐次申請することで、領収書画像との対応を管理しやすくするところに主眼があります。これは「スマホ撮影の領収書画像で領収書原本を破棄できるようになる制度」を念頭においた業務プロセスとなります。

[立替金精算フロー]

本ワークフローでは、立替金が発生するたびに逐次申請していますが、月に１回まとめて申請するような業務も考えられます。もしかしたら、紙で申請を行っていた組織では、月次申請の方が馴染み深いかも知れません。月次申請の場合は、社員分の申請を一括起動しておいたり、申請書PDFを自動生成する、といった工夫が考えられます。

下記に、これまでの記事で紹介してきた様々な例を一覧していますので、参考にしてください。

なお、「メール開始」を利用するためには、ワークフロー基盤で設定を「有効」にする必要があります（初期状態は「無効」）。システム管理権限を持ったユーザでログインし、［システム設定］>［プロセスモデル外部連携］>［メッセージ開始イベント(メール)］より、設定を有効にして下さい。（詳細はこちら => http://www.questetra.com/ja/tour/m3/m318/）

＜オペレーティング画面：（１.を入力中の状態）＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：立替金精算フロー

＜「立替金精算／経費申請」に関する業務フローの一覧＞

シリーズ

オンライン化、領収書保存

立替金申請を完全にオンライン化しよう（電子帳簿保存法） (2015-01-26)
領収書は『スキャナ保存』のススメ (2015-01-19)
立替金の事務処理コストを８割カットするワークフロー (2012-03-12)

申請書PDF自動生成

わぉ！立替金申請書が自動生成？ (2013-04-30)
立替金フロー、月初の自動起動がイイ、PDFの自動生成がイイ (2013-07-01)

データ補正、不正防止

申請された立替データを、直接修正しない！ (2015-05-11)
第510話：もう経費精算フローの中で「事後承認」すればイイ (2016-11-21)
御社の立替金精算、「不正」が起きない業務フローですか？ (2015-02-02)

逐次申請

ユーウツな月末処理を、ラクチンにするワークフロー？ (2010-11-08)

月次申請

立替金申請プロセスを月次起動させるタイマー設定 (2011-05-21)
立替金申請、全社員に「毎月5日」の締切を守らせる方法 (2013-04-15)

入力画面

立替金申請のワークフローは、新入社員にも分かりやすく！ (2010-12-28)
申請フォームのあるべき姿（経費申請ワークフロー） (2011-03-02)
経費申請の入力フォームに「管理者の想い」を書いておく (2011-03-03)

決裁後通知

立替金申請が決裁＆承認されたら自動的にメールしてね (2010-12-29)

データ活用、分析

テーブル型の立替データから、必要項目の CSV を出力する (2015-05-04)

≪関連記事≫

[英文記事 (English Entry) ]

第579話：基本業務パック(2) 「物品購入依頼フロー」

2018-03-19T06:00:00.000+09:00

先週に引き続き、クラウド型ワークフロー『Questetra BPM Suite』にプリインストールされている「基本業務パック」の業務について紹介します。

第２弾は「物品購入依頼フロー」です。
第463話：物品購入依頼を回す（基本業務パック） (2015-12-28)

消耗品から設備備品まで、社員であれば誰でも購買を依頼できる業務フローです。「購入判断保留中」や「納品待ち」などのステータス管理が自動化されているため、いつでも進捗を確認することができるようになります。

[物品購入依頼フロー]

「10万円を超える申請」の場合、「事前に『稟議フロー』にて決裁承認されていること」が購買条件となります。入力画面では、「購買総額」が「10万円以上」となった際に、「関連する稟議プロセスID」の入力を求めるようデコレーション（入力ヒントの表示）を行なっています。

利用者が入力しやすい画面を設計することも、業務カイゼンのひとつの方法です。入力すべき内容の例や説明を適切に記載することで、利用者は効率的かつ円滑に必要事項を入力することができます。一方で、「凝り過ぎた」画面は、メンテナンス性を悪くする可能性もあります。利便性やメンテナンス性などのバランスも考えながら設計し、運用しながら改善していくことが大切です。

＜オペレーティング画面：（１.を入力中の状態）＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：物品購入依頼フロー

物品の購入（購買、発注）や管理に関する業務については、過去にも次のような記事にて紹介してきました。合わせて参照ください。

＜「物品購入／管理」に関する業務フローの一覧＞

購買・発注フロー

消耗品調達・管理

相見積

相見積審査の可視化と省力化 (2015-03-23)
相見積を取り業者選定を行うワークフロー (2012-06-11)

物品貸出管理

第522話：会社物品の「長期貸し出し」を管理したい (2017-02-13)
行政機関における物品管理業務をオンライン化する (2012-12-17)

≪関連記事≫

[英文記事 (English Entry) ]

第578話：基本業務パック(1) 「稟議フロー」

2018-03-12T06:00:00.000+09:00

「第577話：作業依頼フローこそ、ワークフローの基本」では、どんな組織にもオススメできる業務として「作業依頼フロー」を紹介しました。クラウド型ワークフロー『Questetra BPM Suite』にプリインストールされている業務フロー（アプリ）のひとつですが、他にも3つの業務フローがプリインストールされています。今回から３回にわたって、「基本業務パック」の業務について紹介します。

第１弾は「稟議フロー」です。

第462話：稟議書を回す（基本業務パック） (2015-12-21)

社員が稟議書を「申請」し、申請者の上司が「決裁」する、シンプルな業務フローです。外部支払金額が100万円以上の場合は、役員の「承認」にも回るような流れになっています（24時間放置で自動承認）。

[稟議フロー]

決裁された稟議については「稟議書PDF」が自動生成されます。監査対応などで必要な場合は、プリントアウトして利用することも可能です。

＜自動生成PDFの例＞

＜オペレーティング画面：稟議を提出する＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：作業依頼フロー

「稟議フロー」に関しては、この基本形以外にも、様々なパターンを紹介してきました。テーマごとに一覧しますので、気になるものはリンク先の記事も参照してみてください。
＜「稟議フロー」の一覧＞

決裁者指名、他部署決裁・回覧

稟議フローでは、柔軟に承認者を増やしたいね (2010-11-22)
回付中に承認者を増やせる稟議フロー (2012-05-14)

決裁者が申請

第471話：オレの申請に「決裁」は要らぬ！（by 部長） (2016-02-22)

代理決裁

稟議書ワークフロー、「代理決裁」の書き方 (2013-02-12)
第474話：500万円超は「代理承認」を許さない稟議フロー (2016-03-14)

決裁担当者の設定

スマホ決裁、スピード決裁

決裁時間

決裁に要している時間、平均で何時間？ (2014-08-25)
「稟議力」をキタエル(？)、不思議な業務プロセス (2015-03-09)

決裁予算

第501話：予算の消費額がワカラン！？！ (2016-09-20)

稟議システム移行、過去データインポート

過去の稟議記録を一括インポートする (2014-11-25)

≪関連記事≫

[英文記事 (English Entry) ]

第577話：作業依頼フローこそ、ワークフローの基本

2018-03-05T06:00:00.000+09:00

「ワークフローを試すのにオススメの業務は何ですか？」

よくある質問ですが、どんな組織にもオススメできる業務が「作業依頼フロー」です。「誰かに（ちょっとした）仕事を依頼する」というとメールや電話、口頭で行うことが多いと思いますが、シンプルな依頼こそワークフローを活用したいところです。

「ワークフロー」とは文字通り、「仕事の流れ」「仕事の依頼の流れ（連鎖）」を表したものです。すなわち、組織で仕事を行う上でもっともシンプルな行為である「誰かが誰かに仕事を依頼する」ということこそ、ワークフローの基本（本質）と言えます。

クラウド型ワークフロー『Questetra BPM Suite』では、無料版にお申し込みいただくと、次の「作業依頼フロー」がプリインストールされており、すぐにお試しいただくことが可能です。

[作業依頼フロー]

「作業依頼フロー」は、過去の記事でも多く取り上げられてきたテーマで、これまでにもいくつものサンプルを紹介してきました。記事ごとに視点が異なり特徴はあるものの、ワークフローを利用して作業依頼を行うことで、次のような効果が期待できます。

依頼内容を明確にできる: 曖昧な依頼を防ぎ、成果物を明確にできる。依頼を受ける側も対応しやすい。
状況がわかる: 自分が依頼した仕事が誰のところにいって、どうなっているのかがわかる。依頼を受ける側も複数の依頼を一覧し、優先度を決めて対応できる。
記録が残る、実績がわかる: 明確に定義されていない業務でも、依頼内容・対応内容の記録が残り、後に参照しやすくなる。対応コストなどを記録しておくと集計や分析もできる。
過去の依頼を再利用できる: 1年に数回程度の稀な依頼内容も過去の記録を参照し、スムーズに行うことができる。
社内の「依頼」を可視化できる: 業務フローとして定義されていない作業を明らかにできる。誰が誰にどんな依頼を行なっているのかの依頼関係や、依頼状況が見えるようになる。
同種のものから専用の業務を設計できる: 実績を分析し、例えば、発生頻度が多い「依頼」を新しい業務フローとして設計することで、ワークフローの活用範囲が広がる。

時間がある方は下記リンク先の各記事も参照ください。
シンプルだけどメリットの多い「作業依頼フロー」、新年度に向けて運用をはじめてみませんか？

＜「作業依頼フロー」の記事＞

単純依頼もワークフローで流し続けると何かが見えてくる？ (2011-06-27)
「丸投げ」の連鎖を想定した依頼ワークフロー (2011-12-12)
メールボックスは「依頼仕事」の墓場だ (2012-06-08)
ワークフローの無料試用期間、何を流す？（作業依頼） (2014-01-06)
新年のワークフロー試用は「作業依頼フロー」が良い (2015-01-05)
依頼の連鎖こそワークフロー（シンプルな依頼で製品試用を） (2015-11-09)
実作業コストを記録させる作業依頼フロー (2015-11-16)

＜オペレーティング画面：＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：作業依頼フロー

≪関連記事≫

[英文記事 (English Entry)]

第576話：プロセス改善物語（SaaSベンダー編３）

2018-02-26T06:00:00.000+09:00

業務：アイコン作成やポスター制作など

新しい業務プロセス定義で、社内からの「依頼」を一元的に管理できるようになった。

マーケティング部でのデザイン案件、製品開発部でのデザイン案件、営業部でのデザイン案件、、、そんな依頼を「チーム」として効率よく対処できるようになった。また、デザイナ同士がお互いの制作物に興味を持つようになり、各デザイナのスキルアップにも寄与していると思う。

※参照：「第574話：プロセス改善物語（SaaSベンダー編１）」、「第575話：プロセス改善物語（SaaSベンダー編２）」

課題：納品スケジュールが守れないケースも

ただ、それでも、「納期」に間に合わなくなるケースが発生している。

たとえば、「急ぎの依頼」が入ると「通常の依頼」があおりを受けてしまうのだ。特に「新サービスのリリース」「新しいキャンペーンの準備」といった大きなプロジェクトが動きはじめると、様々な「急ぎの依頼」が発生する。結果として「締切に融通が利く通常の案件達」が納期に間に合わなくなってしまう。

外部リソースを活用するなどしてでも「制作スケジュールを守れるデザインチーム」でありたい。

[デザイン依頼対応プロセス]

解決：アウトソース活用

言うまでもない話ですが、繁忙期における「外部リソースの活用」は有効です。

たしかに、『依頼受入金額（契約額）』が「作業担当者」の評価や報酬に反映される人事制度が機能しているなら（デザイナの収入増に直結するなら）、社内立候補を募り、積極的に社内の「作業担当者」を指名するのも良いでしょう。しかし、その「肯定的に考えられる仕事量」にしても、限界はあります。

このワークフロー定義では、外部委託フローが追加されています。

具体的には、『2.担当者の指名』の工程や『3.成果物の制作』の工程において、『3x.制作の委託』に進む経路が追加されています。（ユーザ型データ項目『作業担当者』の名称が『作業担当者もしくは委託担当者』に変更されています）。外部に委託できるものは外部に委託する、という処理が行えるようになります。

考察：クラウドソーシング

インターネットや Cloud の技術進化に伴って、「Crowd Sourcing」（不特定多数の人への外注）が注目されています。

日本でも、政府の推奨するモデル就業規則に「労働者は勤務時間外において他の会社等の業務に従事することができる」という文言が明記される（2018年2月）など、「自分の空き時間を内職に使う人」が今後より一層増えていきそうな状況です。

もちろん、「未公表／社外秘の事実に基づくデザイン作業」といった「社外へのアウトソースが許されないデザイン案件」もあります。したがって、多くの会社では「一定規模のデザインチーム」を維持し続ける必要があります。

しかし、従来のアウトソーシング手法（オフショア等も含む）と比べても、Crowd Sourcing の「委託費」や「委託管理の手間」が大幅に下がったと実感している人は少なくありません。「品質」についても、「Crowd Sourcing プラットフォーム内での評価制度」があるため、成果物の納期・提案クオリティ・コミュニケーションへの回答、など様々な面で高いレベルにあると言えます。またその他にも「デザイン業務のインプットとアウトプットを見直すキッカケにできる」や「外部者視点からの意見を吸収できる」といったメリットもあげられるでしょう。

今日では、業務プロセスによっては、その特定の「工程」について「全面的に Crowd Sourcing に依存する」という考え方も、十分に検討する価値があると言えます。

＜具体的な「Crowd Sourcing」の例＞ ※ クラウドワークス社の利用例

なお、日本の所得税法では、「原稿料」や「デザイン料」などを個人に対して支払う際、その支払金額に応じた所得税（及び復興特別所得税）を差し引いて支払う必要があります。（「源泉徴収義務者」は、その後、翌月10日までに国に納付します）。そして、年間支払総額が50,000円を超えるような受託者がいる場合には、年末に、（社員ごとに「給与所得の源泉徴収票」を作成するのと同様）、「報酬、料金、契約金及び賞金の支払調書」（国税庁用・受託者用）を作成しなければならないケースがあります。

＜支払う側の会計処理の例＞税率：10.21%
広告宣伝費　10,800　／　普通預金（〇〇銀行）　9,779
　　　　　　　　　　　　預り金（源泉所得税）　1,021

ただ、その際に必要となる「マイナンバー」について、（委託業務中のコミュニケーション方法に依存しますが）、その「本人確認」は容易ではありません。特に「なりすまし」については、全く見抜けない可能性もあります。クラウドソーシングの活用は、コンプライアンス上のリスク回避の観点に影響される可能性があり、場合によっては「特定の受託者に大きく依存しない」といった経営管理上の工夫が必要になるかもしれません。

＜オペレーティング画面 : 3b デザインレビュー＞

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：デザイン依頼対応プロセス

＜類似プロセス＞

第529話：PayPal業務のサブルーチン化 (2017-04-03)
第515話：契約書の承認はワークフローで！（改善編） (2016-12-26)
第475話：「シナリオ」を書けば「マンガ」が出来上がる業務プロセス(2016-03-22)

≪関連記事≫

[英文記事 (English Entry) ]

第575話：プロセス改善物語（SaaSベンダー編２）

2018-02-19T06:00:00.000+09:00

業務：デザイン制作

社内から次々と「依頼」が舞い込んでくるデザインチーム。
デザイン制作の「依頼フォーム」（ワークフローの開始工程）を整備したことで、以前より安定して依頼をこなせるようになってきた。（参照：「第574話：プロセス改善物語（SaaSベンダー編１）」）
自動開始イベント（メッセージ開始イベント）も用意したので、『デザイン依頼対応プロセス』が「サブプロセス」として利用されるケースも増えてきた。つまり販売部門や製造部門の業務プロセス図（メインプロセス）に「呼び出しイベント」と「待ち受けイベント」が配置かれ、業務プロセス間の連携が API POST 通信によって自動化されるようになった。（←要は「依頼案件タイトル」や「依頼仕事の作業詳細」といったデータでプロセスが開始され、作業完了と同時に「デザイン報告テキスト」と「成果物ファイル」といったデータが戻される）
さらに「サブプロセス」を呼び出すメインプロセスのサンプルも社内提示したので、今後、様々な部門におけるデザイン業務が『デザイン依頼対応プロセス』に集約されていくハズだ。

課題：スキルアップしない

デザイナごとに「担当案件の数」や「担当総額」が可視化されるようになった。また、ベテランデザイン達が「窓口担当者」として「作業担当者」の作業進捗をコントロールするようになったので、若手デザイナが「ノーチェック納品」（誰もチェックしない納品）してしまうことも無くなった。しかし、デザインは本来、「品質」こそが命だ。この業務プロセスのままでは、社内の満足度が下がっていくような気がする。もう少し、チーム全体として実力を伸ばしていけるような業務プロセスにならないものだろうか？　せっかく「デザイン依頼対応プロセス」として独立性を高めているのだから、単に数をこなすためだけの業務プロセスではなく、スキルアップにつながる仕組みを考えたい。

[デザイン依頼]

[デザイン依頼対応プロセス（レビューあり）]

解決：アンケート形式のレビュー

「デザインの良し悪し」は数値化できるものではありません。仮に、とあるデザインについてデザインチーム内で議論したとしても、三者三様の意見がでてくるでしょう。もし創作者自身が満足している部分について否定的なコメントが出れば、不毛な議論にも陥りかねません。ただ「創作者自身が不安に思っている部分」についてのコメントであれば、否定的な意見でも喜んで受けられるものです。この業務プロセスでは「デザイン担当者」が感じている『デザイン上の反省および不安』、、、たとえば「もう少し明るい色合いの方が良いかも知れない」といった不安について書き込み、同僚に対して『3b.デザインレビュー』を依頼することができる仕組みです。（「デザインレビューお願いしまーす」という声かけをすれば尚良）。依頼を受けた同僚は

そう思う
ややそう思う
あまり思わない
全く思わない
分からない

を選択します。

考察：スキルアップ環境

マーケティング部のデザイナ、製品開発部のデザイナ、営業部のデザイナ。「デザイナが各部に配属されるケース」と「デザインチームを独立させるケース」は、どちらが良いとは言い切れません。それぞれに一長一短があるでしょう。ただ仕事の進め方として、誰にも相談できない／誰にも相談しない、という状況は望むべくもありません。特にデザインアウトプットは、社内ソーシャル（社内SNS）で「いいね！」とクリックしてもらうだけでも、何かの会話につながるものです。特に「組織としてのスキルアップ」を志向するなら、同じスキルを持つ者同士が切磋琢磨できるような、そんな業務プロセス環境を模索し続けるべきだと言えるでしょう。

＜オペレーティング画面 : 3b デザインレビュー＞

＜データ項目一覧画面：デザイン依頼＞

＜データ項目一覧画面：デザイン依頼対応プロセス（レビューあり）＞

＜メインプロセス⇒サブプロセスにおける自動送信設定の例＞

key=${sub-process api key}
title=${デザイン依頼タイトル}
data[1].email=${デザイン依頼者} #ユーザ型
data[6].selects=${デザイン依頼の種類} #選択肢型：アイコン作成/イラスト作成/…
data[7].selects=${デザイン依頼予算} #選択肢型：0-5,000/5,000-10,000/10,000-50,000/…
data[8].input=${デザイン納品希望日} #日付型
data[9].input=${デザイン納品ファイル形式の指定} #文字列型
data[10].input=${デザイン依頼仕事の目的} #複数行文字列型
data[11].input=${デザイン依頼仕事の作業詳細} #複数行文字列型
data[12].upload: ${関連ファイル} #ファイル型
data[2].input=${受信中間イベントURL} #文字列型
data[3].input=$processInstanceId
data[4].input=${受信中間イベントKEY} #文字列型

※ デザイン報告を自動受信したい場合、「接続元プロセスの受信イベントURL」「接続元プロセスの案件ID」「接続元プロセス受信イベントのKey」は必須。その他のデータ項目は、必要な範囲で受け渡し。

＜サブプロセス⇒メインプロセスで自動送信されるデータ＞

key=${（接続元プロセス受信イベントのKey）} #main-process api key
processInstanceId=${（接続元プロセスの案件ID）}
q_reportText=${（デザイン報告）} #複数行文字列型
q_deliverableFile: ${成果物ファイル（接続元プロセスに返す成果物ファイル）} #ファイル型

※ メインプロセス側に、「デザイン報告」を格納する複数行文字列型データ（フィールド名：q_designreport）と「成果物ファイル」を格納するファイル型データ（フィールド名：q_designfiles）が必要。

※ メインプロセスへのデータ送信には、デフォルトのパラメータ書式（例：data[9].input）ではなく、カスタム書式（フィールド名。例：q_reportText）の使用を前提。

[雛形ダウンロード (無料)]

業務テンプレート：デザイン依頼
業務テンプレート：デザイン依頼対応プロセス（レビューあり）

＜類似プロセス＞

第529話：PayPal業務のサブルーチン化 (2017-04-03)
第515話：契約書の承認はワークフローで！（改善編） (2016-12-26)
第475話：「シナリオ」を書けば「マンガ」が出来上がる業務プロセス (2016-03-22)

≪関連記事≫

[英文記事 (English Entry) ]

第574話：プロセス改善物語（SaaSベンダー編１）

2018-02-13T06:00:00.000+09:00

業務：デザイン業務

デザインチームの業務は多岐に及ぶ。

たとえば、「SaaS製品内のアイコン」の変更や追加といった小さな案件もあれば、「新しいSaaS機能」のインターフェース開発といった大きな案件もある。
ただ…、それ以外にも、セールスチームが書いた「導入事例記事」をWeb掲載するという案件が発生したり、さらにそれをチラシ制作するという案件が発生したりする。はたまた、マーケチームの「展示会」企画にあわせて、Webコンテンツを制作案件が発生したり、ポスター制作したり…。

つまるところ、全社から「手伝ってラブコールを受け続けるチーム」と言っても良い。

課題：受け身な案件の効率化

確かにデザインチームが愛されていることは事実だ。
しかし、直接部門である「製品開発部門」や「営業販売部門」が日ごろ主体的に動いているのと比べると、やっていることは地味と言わざるを得ない。たとえて言えば、小売店にある「ラッピングコーナー」みたいなものか？　日々、社内のアウトプットに対して「お化粧」をし続けるのだ。そして、気がつけば「受け身の姿勢」がしみついてしまう。

これがもし建築の世界であれば、、、むしろ「意匠系」が主体的に動き、エンジニア集団である「構造系」や「環境系」が受け身になるところなのに。。。と、ボヤいたところで「社内からのラブコール」が無くなる訳ではない。まずはこの「受け身仕事」を手際よくこなすことを考えたい。（経理担当だって、人事担当だって、情シス担当だって、、、「受け身仕事」を華麗にサバいているのだから…）

[デザイン依頼対応プロセス]

解決：デザインプロセスを独立させる

直接部門を支援する間接部門が「受け身」になってしまうことは、ある程度はやむを得ません。そして、直接部門の業務プロセス内に間接部門の工程（スイムレーン）が組み込まれることも少なくありません。

しかしその場合、デザインチーム自身が業務プロセス定義のオーナーシップを持たないため、

デザインチーム内のプロセスが改善されない
デザインチーム内での仕事負荷状況が認識しづらくなる
デザイン工程のインプット・アウトプットが業務によってバラバラになる

といった問題が発生する傾向にあります。

この業務プロセス定義は、チーム外からの依頼を受け付けられるだけでなく、他の業務プロセスから「プロセス連携」させる（サブルーチン呼出のように連携させる）ことも可能です。このように独立した業務プロセスとして定義しておくことで、デザインチーム内が受けている様々な仕事を容易に可視化できるようになります。
（直接部門がチーム内に「専属デザイナ」をオカカエしているようなケースには当てはまりません）

考察：成果計測の必要性

間接部門は、デザインチームだけではありません。組織内には他にも数多くの間接部門があります。（バックオフィスとも言われます）

たとえば「法務チーム」や「人事チーム」や「情報システムチーム」といったチームは、仮に「フラットでない組織構造」であっても、あるいは「1000人を超える大企業」であっても、間接部門として独立しているケースが一般的と言えます。（他にも、翻訳チーム、品質管理チーム、ブランド管理チーム、BPMチーム、などなど）
ただ、同じ間接部門であっても、

「人事チーム」のように、直接部門の日常業務に組み込まれない組織と
「法務チーム」や「デザインチーム」のように、直接部門の日常業務に組み込まれがちな組織

とでは、業務プロセス管理の方法が大きく異なってきます。

すなわち「人事チーム」であれば、人事業務プロセス群について自らオーナーシップをもって改善し続けることが可能です。が、たとえば「受注契約プロセス」の一工程として組み込まれる「法務チェック」といった工程については、あまり改善対象になりません。

このケースにあるデザインチームは、各人の成果計測も重要となるクリエイティブチームとも言えます。もし、競争力のある組織に成長させていく必要があるなら、他部署からの「依頼受付」を開始ポイントとする独立した業務プロセスについて検討してみるべきだと言えるでしょう。

[デザイン依頼対応プロセス：「1.デザイン依頼」画面]

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：デザイン依頼対応プロセス

＜類似プロセス＞

第529話：PayPal業務のサブルーチン化 (2017-04-03)
第515話：契約書の承認はワークフローで！（改善編） (2016-12-26)
第475話：「シナリオ」を書けば「マンガ」が出来上がる業務プロセス (2016-03-22)

≪関連記事≫

[英文記事 (English Entry) ]

第573話：プロセス改善物語（Webメディア編３）

2018-02-05T06:00:00.000+09:00

業務：Web記事制作

記事の執筆ワークフローを変えた。（第571話：プロセス改善物語（Webメディア編１）、第572話：プロセス改善物語（Webメディア編２）、参照）

これで「記事」の品質を高めるとともに、「ライター」さん達のスキルアップにもつながるフローになった、、、様に思う。

いずれにせよ、『仮タイトルの設定』に始まり『Web記事の掲載』というアウトプットに至る一連の「記事制作フロー」がスムーズに回るようになった。「進捗を確認しに行く」や「レビューを督促しに行く」といった無駄なコミュニケーションも、すっかりなくなったといえる。

編集長：季節連載などの企画を立ち上げる
編集者：個別記事の仮タイトルを決める
ライター：記事を執筆する

編集長・編集者・ライターのそれぞれが、本来の役割に没頭できるようになったという表現の方が正しいのかも知れない。（もっとも、「手直し」や「教育的指導」が完全に無くなったワケではないが…）

課題：ネタ切れ問題

一方で、「記事制作フロー」へのインプットである『仮タイトル』について、その品質が議論されるようになった。

つまり、（これはオウンドメディアにとっての永遠の課題なのかも知れないが）、毎日の『仮タイトル』の設定にネタ切れ感が漂うケースがあるのだ。「似たような記事を最近書いたような…」「これは流石に誰も読まないんでわ…」など。

この際、記事のアイデア（仮タイトルの案）や連載企画のアイデアについて、社内から提案できるようにしたい。アイデアが沢山溜まっていれば、編集者や編集長の助けになるに違いない。そして『仮タイトル』の設定クオリティも高まるハズだ。

[記事アイデア受付プロセス]

解決：目安箱

アイデアを受け付ける業務プロセスは、意外と運用されていないものです。

組織の中にある「企画を担当する職責」は、企画という言わば「最上流の工程」を担当します。言い換えれば、何のインプットもなく「週に5つの企画を行う」や「月に10本の企画を立てる」といったアウトプットを出し続けなければならない仕事です。

そして、日ごろ自らが「流す側」に立っていると、「受ける側」になることを忘れてしまうものです。それは、学校の先生が生徒の声を聴く機会が無くなっていたり、製品ベンダーがユーザの声に耳を傾けることが無くなっていたりするのと同じような傾向（症状）なのかも知れません。

時事ニュースに関連する記事アイデア、他社メディアの人気記事に関連するアイデア、などなど、、、組織全体で広く「アンテナ」を張り巡らし、組織として「読者の望む記事」を制作し続けられる体制を維持したいものです。

考察：メールでもプロセス開始が可能に

もっとも、アイデアを受け付ける「目安箱的な業務プロセス」については、「適宜メーリングリストやチャットで送ってくれれば良い」という意見もあるでしょう。たしかに「アイデアをワークフローに流す」と聞けば、ややメンドウな印象を受けるかも知れません。

しかし、

過去のアイデアが全て記録されていく
各アイデアに対して「企画者」がどう考えたのかが記録されていく
他部署スタッフや新人スタッフも過去記録を参照できるようになる

といった点を考えると、きちんと業務プロセスを定義しワークフローシステムに流す、という方法も検討してみたいものです。

ここに例示されている業務プロセス定義は、ワークフローシステムの「入力画面（Webブラウザ）」だけでなく、「メール送信」でもアイデアを流すことができるよう、工夫されている点が秀逸と言えるでしょう。

[記事アイデア受付プロセス：「1.アイデア投稿」画面]

＜データ項目一覧画面＞

[雛形ダウンロード (無料)]

業務テンプレート：記事アイデア受付プロセス

＜類似プロセス＞

第552話：働き方改革は「アイデア募集」が大事 (2017-09-11)
第535話：システムを改良し続ける事こそ、真の働き方改革 (2017-05-15)
第516話：ワークフローを「メール」で起動しておく方法 (2017-01-02)

ワークフローサンプル

最終話：ご愛読の御礼とこれから

第596話：複数工程をひとつにまとめてワークフロー図を見やすく改良

類似プロセス

雛形ダウンロード (無料)

関連記事

第595話：アンケート回答期限、もうひとつの設定方法

類似プロセス

雛形ダウンロード (無料)

関連記事

第594話：イベント参加者アンケートに回答期限を設定

雛形ダウンロード (無料)

類似プロセス

関連記事

関連マニュアル

第593話：イベント終了後に参加者にアンケートを依頼

類似プロセス

関連記事

関連マニュアル

第592話：ワークフローでイベント申し込みを受け付ける

関連記事

第591話：入力画面を工夫して、業務カイゼンに繋げよう！

類似プロセス

関連記事

雛形ダウンロード (無料)

第590話：階層にバラツキがある組織での上司とその上司の指定方法４（番外編）

471話：オレの申請に「決裁」は要らぬ！ （by 部長）

類似プロセス

関連記事

第589話：階層にバラツキがある組織での上司とその上司の指定方法３

雛形ダウンロード (無料)

類似プロセス

関連記事

第588話：階層にバラツキがある組織での上司とその上司の指定方法２

類似プロセス

雛形ダウンロード (無料) 業務テンプレート

関連記事

第587話：階層にバラツキがある組織での上司とその上司の指定方法１

関連記事

第586話：BPMNでワークフロー図を書こう！（後編）

BPMNの基礎、Questetra でのモデリング方法

第585話：BPMNでワークフロー図を書こう！（前編）

BPMNの基礎、Questetra でのモデリング方法

第584話：「休暇申請」は事前にしっかりと！

類似プロセス

関連記事

第583話：類似ワークフローの統合でプロセス改善

第582話：毎日の業務報告で1日を振り返ろう！

第581話：新入社員は勤怠報告でワークフローに慣れよう！

自動開始

初期値設定

入力支援

第580話：基本業務パック(3) 「立替金精算フロー」

第579話：基本業務パック(2) 「物品購入依頼フロー」

第578話：基本業務パック(1) 「稟議フロー」

第577話：作業依頼フローこそ、ワークフローの基本

「ワークフローを試すのにオススメの業務は何ですか？」

第576話：プロセス改善物語（SaaSベンダー編３）

業務：アイコン作成やポスター制作など

課題：納品スケジュールが守れないケースも

解決：アウトソース活用

考察：クラウドソーシング

第575話：プロセス改善物語（SaaSベンダー編２）

業務：デザイン制作

課題：スキルアップしない

解決：アンケート形式のレビュー

考察：スキルアップ環境

＜メインプロセス⇒サブプロセスにおける自動送信設定の例＞

＜サブプロセス⇒メインプロセスで自動送信されるデータ＞

第574話：プロセス改善物語（SaaSベンダー編１）

業務：デザイン業務

課題：受け身な案件の効率化

解決：デザインプロセスを独立させる

考察：成果計測の必要性

第573話：プロセス改善物語（Webメディア編３）

業務：Web記事制作

課題：ネタ切れ問題

解決：目安箱

考察：メールでもプロセス開始が可能に

471話：オレの申請に「決裁」は要らぬ！（by 部長）