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

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


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

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

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

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

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

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

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

[請求&入金確認フロー1]


[請求&入金確認フロー1(工程統合)]




前回、「イベント参加者アンケートに回答期限を設定」では、サービス工程を利用して『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. フロー改善

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

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





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

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

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

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

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

[入力フォームのテストフロー]




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

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

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


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

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

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

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

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


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

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

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

[稟議フロー(相対的表記)]


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

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

社長1人、部長(役員)2人、マネージャ4人、メンバ12人。仮に、この「メンバ12人」の内の2人が『部長直下』に配属されているとします。具体的に例示すれば、
  • 2人の部長が主管する部に直接所属している人が『2人×2』
  • 4人のマネージャが主管する「チーム」に所属している人が『2人×4』
の組織を想定してみます。もちろん「チーム」自体は「部」に所属します。具体的には、営業部の傘下に多くのチームがありながらも営業部長自身が営業事務メンバ2人を直接指揮し、製造部の傘下に多くのチームがありながらも製造部長自身が品質管理メンバ2人を直接指揮しているようなケースとなります。


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

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

[稟議フロー(絶対的表記1)]


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

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

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

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

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


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

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


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


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

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

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

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

[BPMNサンプル-XOR分岐]

[BPMNサンプル-AND分岐]


関連記事


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

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

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

[休暇申請フロー]

新年度も半月が経ち、新入社員も新しい環境に慣れてきた頃ではないでしょうか?
この2週は、「出退勤報告フロー」「日次報告フロー」とふたつの新入社員向け(とも限りませんが)のワークフローを紹介しました。毎日、きちんと「報告」してきた方なら、ワークフロー基盤の操作にもすっかり慣れたと思います。

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

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

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

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


[出退勤・日報フロー]


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

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

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

[日次報告フロー]

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

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

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

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


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

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

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

[立替金精算フロー]


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

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

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

[物品購入依頼フロー]


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

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

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

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

[稟議フロー]

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

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

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

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

[作業依頼フロー]


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

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

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

※参照:「第574話:プロセス改善物語(SaaSベンダー編1)」、「第575話:プロセス改善物語(SaaSベンダー編2)

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

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

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

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

業務:デザイン制作

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

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

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

[デザイン依頼]

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