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

申込件数が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))