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

申込件数が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 通信によって自動化されるようになった。(←要は「依頼案件タイトル」や「依頼仕事の作業詳細」といったデータでプロセスが開始され、作業完了と同時に「デザイン報告テキスト」と「成果物ファイル」といったデータが戻される)
さらに「サブプロセス」を呼び出すメインプロセスのサンプルも社内提示したので、今後、様々な部門におけるデザイン業務が『デザイン依頼対応プロセス』に集約されていくハズだ。

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

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

[デザイン依頼]

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

業務:デザイン業務

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

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

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

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

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

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


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



業務:Web記事制作

記事の執筆ワークフローを変えた。(第571話:プロセス改善物語(Webメディア編1)第572話:プロセス改善物語(Webメディア編2)、参照)

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

いずれにせよ、『仮タイトルの設定』に始まり『Web記事の掲載』というアウトプットに至る一連の「記事制作フロー」がスムーズに回るようになった。「進捗を確認しに行く」や「レビューを督促しに行く」といった無駄なコミュニケーションも、すっかりなくなったといえる。
  • 編集長:季節連載などの企画を立ち上げる
  • 編集者:個別記事の仮タイトルを決める
  • ライター:記事を執筆する
編集長・編集者・ライターのそれぞれが、本来の役割に没頭できるようになったという表現の方が正しいのかも知れない。(もっとも、「手直し」や「教育的指導」が完全に無くなったワケではないが…)

課題:ネタ切れ問題

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

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

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

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

業務:校閲・校正

記事の校閲に「他のライター」も参加させる業務フローに変えた。(第571話:プロセス改善物語(Webメディア編1)、参照)

「誤字・脱字」や「名称まちがい・日付まちがい」といった『ミスの修正指摘』もさることながら、、、「起承転結についての意見」や「見出しやタイトルについての対案」といった『スキルアップにも通じるコメント』が、ライター同士で行われるようになった。

「編集者」は校閲やライター指導に費やしていた時間が減り、「新しい特集」について考えたり、「勉強会」を開催したりする時間が持てるようになった。

ちなみにその「勉強会」では、現実に発生した校正例が報告される。たとえば、「決済日」はお客さんが入金した日で「決裁日」は上司が判断した日ですねーとか、、、"過去" を償うことが「補償」で "未来" を約束することが「保証」で "砦" (障壁/障子)を築いて守り続けることが「保障」ですねー、国家や保険会社による安全保障・社会保障・生活保障といったケースでしか使われませんねー、、、といったディスカッションが行われている。地道なスキルアップこそ「生産性向上」だ。

課題:長時間の滞留

しかし「ライター」からすれば、他人記事の校閲という業務が増えたことよりも、差し戻し修正しなければならないタイミングも増えたことが問題だったりする。

特に新人ライターの場合、複数の記事が同時に『2x.記事修正』の工程に舞い戻ってくる、といったケースも発生してしまうようになった。そして、そういったケースには「他のライターが書いた記事を校閲する時間」が取れなくなるという事態になる。。。

うーむ、『3.一次校閲』には締切日時を設定し、その締切日時をもって強制的に次工程に進捗させる、、、つまり滞留を許さない、ようにした方が良いと思うに至った。

[記事の校閲フロー-打ち切り有り]

業務:サイト記事の作成

いくつかのWebメディア発行会社では「記事の校閲」が実践されているようだ。

それは「医療サイト」や「ファッションサイト」といった商業ベースの『まとめ系サイト』(キュレーションサイト)に限らず、自社事業関連情報を発信する『オウンドメディア』でも、記事の「信頼性」高める努力が払われているらしい。

ウチでも、
  • 「編集長」が季節連載などの企画を立ち上げ
  • 「編集者」が個別記事の仮タイトルを決め、
  • 「ライター」が記事を執筆し
  • 「編集者」がチェックし、
  • 「Webデザイナ」が記事や写真を掲載する
という流れ(ワークフロー)の中で「編集者」が「記事の校閲っぽいこと」をしてはいる。しかし「全ての発信情報に間違いはない」と断言できる体制ではない。

課題:一次草稿の品質

色々と議論はあったが、まずは「ライターさんのスキルアップ」を考えることにした。特に編集者から何度も「差し戻し」を食らっているライターさんを何とかしてあげたい。

スキルアップの方法はイロイロと考えられるが、ウチでは「ライター自身も他のライターが書いた記事を校閲する」という方針を立ててみた。やや荒療治ではあるが、「人の振り見て我が振り直せ」とでも言えば良いのだろうか、、、いずれにせよ、日ごろから他のライターが書いた記事を見ることで自分自身の反省すべき点に気づいてもらう、という作戦だ。

副次効果的そして中長期的に「編集者」が感じている校閲の負担感も下がると思う。

[記事の校閲フロー]



業務:マルチタスク正社員への情報共有

「深夜のフロント業務」、「朝のチェックアウト対応」、そして「チェックアウトされた客室の清掃」。。。

ワークフローで社内情報を可視化することで、正社員が様々な業務を「掛け持ち」できるようになってきた(マルチタスクオペレーション)。すなわち、夜勤担当からチェックアウト担当に「宿泊客からクレーム苦情を頂いた」という情報が共有され、またチェックアウト担当から客室清掃担当に対して「宿泊客がチェックアウトした」という情報がスムーズに共有される。


結果、パートやアルバイトへの依存度が高かった「夜勤フロント」や「客室清掃」にも、かなり正社員が参加できるようになった。そして同時に、(想定外の展開として)、パートやアルバイトが「正社員として働ける道が開けてきた」という現象も現れてきた。

<正社員の勤務シフト例>
  • 早番(7時間労働、8時間拘束)
  • 遅番(7時間労働、8時間拘束)
  • 夜勤(12時間労働、13時間拘束:2日勤務相当)

課題:なおも発生する手待ち時間

しかし、特に深夜時間帯においては、どうしても「手待ち時間」(てまちじかん)が発生する。

正社員が「夜勤」にも積極参加するなら、深夜帯においても「何か生産的な業務」を引き受けられるようにしたい。そこで、BPM コンサルタントとも相談し、今度は「スタッフブログの発信」に挑戦することにした。(期待する「マルチスキル度」高すぎ?、という不安もある)

ちなみに、ホテル館内の「見回り業務」をもっと念入りに行えばよい、という意見もあった。だが「不必要なまでの丁寧さ」を追及することは「生産性向上」とは言えない。すでに行われている「定時見回り」で、安全面は十分担保されていると思う。

[ブログ執筆投稿フロー]