ラベル 汎用依頼 の投稿を表示しています。 すべての投稿を表示
ラベル 汎用依頼 の投稿を表示しています。 すべての投稿を表示

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

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

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

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

[作業依頼フロー]

「現場の業務プロセスが見えない」?


2016年秋、日本では『キュレーション・メディア』による「パクり行為」が大きく報道されている。

そもそも「情報を整理する行為」は価値のある作業であり、誰でも整理記事を投稿できる「情報共有サイト」(キュレーション・プラットフォーム)も価値ある存在と言える。しかし、サイト運営会社(東証一部上場企業)自身がクラウドソーシングを通じて記事を量産し、そのアウトソースの中で「パクり」をマニュアル化していた実態が明るみになったのだ。

キュレーション記事の制作プロセス

たしかに、
"当社は、この記事の情報及びこの情報を用いて行う利用者の判断について、正確性、完全性、有益性、特定目的への適合性、その他一切について責任を負うものではありません。"
という免責注記はあった。しかし、当のサイトが「健康や命に関わる記事」を集める情報共有サイトであったため、「著作権侵害」というよりもむしろ「モラル」が問われた形だ。そして、結果としてCEOが「記事制作のプロセスに問題がある」と謝罪する状況になったのだ。

DeNAプレス:CEOからのお詫びとご説明
"他サイトからの文言の転用を推奨していると捉えられかねない点がございました。この点について、私自身、モラルに反していないという考えを持つことができませんでした。(中略)。自分自身として心の底から自信の持てるプロセスを構築していくことを約束します。"

真実かどうかは知る由もないが、おそらくは「本当に業務プロセスが見えていなかった」のだろう。(と信じたい)。では、運営会社が責任をもって記事を書く必要がある場合、どのような業務プロセスを構築すれば良かったのだろうか?

[記事作成プロセス]
「内部工数が見えない…」

企業活動において「作業コストの可視化」は重要なテーマだ。しかも、今日に至っては、情報処理技術・通信技術の進化によって多種多様な表現手法が可能なハズだ。
  • 移動経路が分かる「GPS ロガー」(移動マップ)
  • 熱分布が分かる「サーモグラフィー」(赤外線熱画像)
  • 予算履歴を把握できる「EVM グラフ」(完成度推移グラフ)
※ GPS: Global Positioning System, EVM: Earned Value Management

そもそも『可視化』とは「直視するだけでは認識しづらい情報」を、画像やグラフなどによって認識しやすくする取り組みだ。企業活動(業務プロセス)の可視化に限っても、すでに様々な図表が活躍している。
  • 作業工程の順序が分かる「BPMN フロー図」
  • 各工程での滞留状況が分かる「ヒートマップ」
  • 個人やチームでの「マイタスク処理数の推移グラフ」
  • フロー全体や一部工程における「BAM 平均所要時間の推移グラフ」
※ BPMN: Business Process Model and Notation, BAM: Business Activity Monitoring

「うーむ、何とかして可視化したい…」。


ただ一方で、、、「内部工数」をテーマにする場合には、それらの要素データとなる「実稼働時間」の情報をどのように収集するかが、大きな課題と言える。

[汎用的な作業依頼フロー]

「『ワークフロー』を体験してみたいけど、どの業務で試せば良いのか分からない」

特に「一人で試す」のではなく「組織として試したい」場合は、悩ましい。たとえば仮に「日報業務」をワークフロー化&ペーパレス化するにしても、その体験期間において、従来のやり方とクラウドなやり方の両方を行わなければならないなんて、、、試用者が可哀そうだ。


以下は、ワークフロー製品試用の際に設定されることが多い「汎用的な業務依頼フロー」だ。

「ワークフロー化&ペーパレス化」されていない業務で利用することができる。つまり、このテンプレートをワークフローとして稼働させれば、社内のメンバに対して、様々な依頼を投げる体験が可能だ。そして、依頼を受けた側もワークフロー製品内に「マイタスク」が溜まっていくのを体験することができる。
  • 「新製品用のアイコンを作成して下さい」
  • 「作成した資料のレビューをお願いします」
  • 「前回広告のデータ抽出をお願いできますか?」

なお、この「汎用作業依頼」はアチコチで紹介されるワークフローだが、ここで紹介されている「業務依頼フロー」が秀逸な点は、依頼を申請する画面において「時間コスト」が掲示されているところだ。
(上手く表現できないが)、良い意味で「頼みづらく」なる。(軽々しく依頼できなくなる)。言い換えれば、キチンと依頼するようになる。

<時間コスト(目安)>
  • オフィサー: 10,000 円/時
  • マネージャー: 7,500 円/時
  • 常勤スタッフ: 5,000 円/時
  • パートスタッフ: 2,500 円/時

[汎用的な作業依頼フロー]

部下の原稿をチェックするなら「赤ペン」に限る?

確かに、紙に原稿を印刷して、
  • この辺がダメ!
  • この辺が読みづらい!!
  • この辺をもっと具体的に!!!
とかとか、アレコレと自由に書き込むのは気持ちイイ。。。場合によっては、矢印つけたり、文章全体を囲んだり、、、その作業効率は非常に良い。(紙を手渡しできるなら/口頭で補足できるなら/記録が残らなくてイイなら)

この「赤ペンが持つ機能」(?)は、パソコンソフトであれば「校閲機能」に該当するのだろう。『Microsoft Word』の場合、上司は「変更記録」モードで書き込み、部下は「変更箇所/コメントの表示」モードで確認する。

うんうん。 ん? Web ワークフローであれば、どうすればイイの?

以下のワークフローは「JavaScript のレビュー業務」を表している。このレビュー工程では、レビューされるべき原稿が「2段組み表示」の左側に表示され、レビューコメントを右側にある入力フォームに書きこむ、と言う仕組みになっている。

確かにこの設定は「仕組みとしてシンプルすぎる感」が否めない。が、しかし、使ってみると意外と便利だったりする。何と言っても、特別なパソコンソフトを立ち上げる必要もなく、素早く対応できる点がスバラシイ。

[スクリプト・レビュー]

新年、明けましておめでとうございます。

2015年がやってきました。本年も「世界の業務革新」に貢献すべく頑張って参ります。願わくば、1人でも多くのビジネスパーソンに「あるべき業務プロセスのヒントになった!」と感じてもらえる様に、記事のクオリティを上げてまいりたいと思います。

さて、、、日本には「一年の計は元旦にあり」というコトワザがあります。(直訳すれば "The whole year's plans should be made on New Year's Morning." と言ったところでしょう)。実際、約半数の日本人が神社や寺院に参拝し、そこで「一年の誓い」を立てます。統計上、1月1日から3日までの間に参拝する初詣参拝者数(延べ人数)は、9000万人を超えるそうです(人口は1億2千万人)。

もっとも、セッカクの「年末年始休暇」なんだから「元旦(=1月1日の朝)くらいゆっくり寝ようよ」と言う声があるのも確かなのですが、このコトワザは戦国武将の時代(400年前)から大切にされてきた風習みたいなモノでもあり、本ブログとしても「一年の誓い」を立ててみようと思います。
  • 毎週1本以上、記事を書く (これまでと同じ)
  • 複数人から頂いたリクエストについては、必ず記事化し、またキッチリと満足度調査を行う
  • 日本語記事とその英語翻訳記事で配信していますが、更にもう一つくらい…(せめて本文だけでも…)を検討する
あああ、、、来年の今頃はどうなっているのでしょう。

と言うコトで(??!)、2015年1本目の業務プロセス雛形は、「汎用作業依頼プロセス」です。

[作業依頼フロー-担当替]

前回に引き続き「社内アンケート業務」とよばれる業務について考えたい。前回は、最大8人に対して「任意のアンケート」を実施できる汎用ワークフローについて考察した。ポイントは、
  • 8人分のスイムレーンを用意し、
  • 8人分の回答データを格納できるように設計した
の2点だ。いつでも色々なアンケートを実施できる所はスバラシイ。

しかし、この方式のワークフローでは50人や100人に対するアンケートは現実的ではない。もちろん、
  • A. 100のスイムレーンを用意し(!!)、さらに
  • B. 100人分の回答データを格納できるように定義する(!?!)
と言う拡張を行うのも悪くはないのだが、、、やはり色々な意味でナンセンスだ。 中でも特に問題視すべきは、データ集計を行うに「非常に使い勝手の悪いフォーマット」になってしまう点だ。集計という視点に立てば、「アンケート実施」の単位で記録されるのではなく、「アンケート回答」の単位で記録されるようにしたい。

以下の業務プロセス例は、まず「B.データ項目が発散する問題」を解決すべく、「アンケート準備」の業務プロセスと「アンケート回答」の業務プロセスの2つの業務プロセスに分けて定義した例だ。準備が1に対して回答がN、、、その「繰り返し単位」の違う業務プロセスをつなげる事で、それぞれ集計しやすいフォーマットになる。

[アンケート準備フロー]

[アンケート回答フロー(ユーザ指定開始)]

「社内アンケート業務」とよばれる業務について考える。ナンてことは無い、社内に対して行われるアンケートだ。

(1) たとえば「回答用の Web フォーム」を作成し回答してもらうという方式。
Questetra の業務プロセス定義でいえば、先頭に [フォーム開始イベント] を配置すればよい。「回答用の Web フォーム」が自動生成され、アンケート回答が入力されるたびに、ワークフローが起動する。(社内ユーザに限らない)
使い方220 自動開始 公開フォーム画面に入力があった時に自動的に開始されるように設定する

(2) あるいは定期的に「アンケートに回答する」というタスクが割り当たるという方式。
Questetra の業務プロセス定義でいえば、先頭に [タイマー開始イベント] を配置すればよい。「毎月1日」や「年に4回決まった日時」など、セットされた時刻になると関係者のマイタスク一覧に「アンケートに回答する」という仕事が一つ増える。
使い方217 自動開始 決められた日時に先頭処理が自動的に開始されるように設定する

いずれの方式もその下流工程において、「アンケート回答に対して御礼を送る」や「どちらとも解釈できる記述について回答者に確認する」といった様々な作業工程を設計する事ができる。だが、、、これらの方法は、アンケートごとに業務プロセス定義を作成する([プロセスモデル] を作る)ことを意味する。重要なアンケートであったり、何度も行われるアンケートであれば、これらの方法で良い。

多様なアンケートを、もっと気軽に流せないものか?

たとえば、理解度を確認したり、意見集約をしたり、飲み会のお店候補に投票してもらったり、、、、、汎用的に使えるアンケート・ワークフローとは、どの様なプロセス図になるのだろうか? (もちろん [プロセスモデル] の複製を行い、編集すべきトコロを編集し、別の業務として定義すれば良いだけではあるが。。。)

[汎用アンケート・レビュー]
「自動メールへのデータ埋め込み、便利だよね!」

誰かが開始させた『案件』が、業務フロー図を流れ、そしてフロー図の中の「とある地点」を通過する。すると、

自動的にメールが送信されたり、
自動的にPDF帳票が生成されたり。。。

そう、、、業務の自動化は、「業務コスト」を大幅に下げ、「ミスの発生」を減らし、「し忘れ」を撲滅する。特に【自動メール】は、社内の関係者に「業務アラート」として送信したり、社外の方に「受付完了通知」として送信したり、応用範囲が非常に広い。

以下は【自動メール】へのデータ挿し込み(差し込み)を体験できるサンプル(業務テンプレート)だ。

文字列型だの、日付型だの、ファイル型だの、、、色々なデータをメール本文に挿し込んだ際に、実際どの様なメール本文が生成されるのか?、を体験できる。以前、『【入力インターフェース】を体験できる』と言うサンプルを公開したら、意外にも人気コンテンツになってしまったので、いわゆる「二匹目のドジョウ」だ。いつもの記事にある様な「仕事の進め方についての考察」は、今回もなーい。(なんか寂しい)

『文字列型(!)、日付型(!!)、ファイル型(?!)、掲示板型(?!!)』 (2014-02-24)

▽公式マニュアルはコチラ▽
M224 自動イベント 業務データを挿し込んだメール文が、自動的にメール送信されるように設定する

[自動メールのテスト]

[メール設定画面]

【会社の意思】は取締役会で決まる。

多くの場合、「議論の深まり」の中で決まっていく。と言うか、典型的なパターンは社長が取締役達を説得し、「あーだ、こーだ」と事前のヤリトリがあった後、取締役会の場で決まる。当然ながら【取締役会議事録】には、『慎重審議の結果、提案は全員異議なく可決』とのみ記録される。込み入ったヤリトリや各取締役の当初意見などは、公式記録に残らない。

しかし【最も大切な情報】は、決まるまでの「過程」だ。
未来の取締役達が読みたくなる情報は、決まるまでの「過程」だ。

以下のワークフローは、各取締役が独立して意見を記録できるシステムだ。まず『-2.反対』『-1.どちらかと言えば反対』『0.分からない/判断保留』『+1.どちらかと言えば賛成』『+2.賛成』を選び、その上で、自分の意見を自由に記録する。とかく形式主義に陥りやすい『議事録』とは別に運用される。つまり、会議の前に意見や考えを表明しておくため、あるいは会議の後に議論後の意見や議論感想を記録しておくために活用される。単なる「電子採決システム」とは違う。

[事案に対する意見表明フロー]
「入力フォーム、どんなカンジ??」

ワークフロー システムにとって「Input Form」は重要だ。特に、現場で【プロセスモデリング】を担当する人(※)にとって、データ入力画面がどんな風に出来上がるのか、気が気でならない。例えば、『どこに、どんな注意書きを書けば、組織の仲間たちにとって便利になるか』を真剣に考えたい。(※「プロセスモデリング」を担当する人が創ったモノ⇒【プロセスモデル】)

と言う事で、以下は入力フォームの体験サンプルだ。文字列型だの、日付型だの、ファイル型だの、、、色々な「データ型」への入力を一度に体験できる。大人の事情でクラウド型ワークフロー『Questetra BPM Suite』にインポートできる雛形しかダウンロードできないが、ワークフロー製品の選定過程にあって「データ入力体験」は必須なのかも知れない。

『オンラインデモ環境』にもアップロードしておく。が、編集されてしまう可能性もあるので、『無料版』をご利用の方はとりあえず自分の環境にインポートしておこう。(損はない)

ちなみに当サイト『Workflow Sample』では、もう3年半も「サンプル」を提供し続けているが、これほどまでに「業務カイゼン」と関係ない記事は初めてではなかろうか? (ま、毎回堅苦しいのもナンなので、こういうのがたまに紛れているくらいがイイだろう)

[入力テスト]
会社には「多くの人に参照されるべき文書」が、いくつもある。
製品の『取扱説明書』、現場の『作業マニュアル』、あるいは『契約書の雛形』や『各種社内規程』などなど、実に多種多様だ。そして、その「文書」をメンテナンスし続ける事は、非常に難儀だ。改定時に「他の言語への翻訳」が必要になる類の「文書」なら、更にその管理は困難を極めるだろう。

以下のプロセス図は『製品マニュアル』の改訂を行う業務手順を表している。この業務プロセス定義でシステム化すれば、文書の改訂ポイントや最終確認者などが自動的に記録される様になる。

[マニュアル改訂]

※「スグに試せるシリーズ」、連載その3。

ワークフロー・システムの導入検討、、、少しでも「意味のあるデータ」を流してワークフロー製品を評価したい。

シリーズ第3弾は「汎用作業依頼」をテーマに取り上げる。以下に紹介する『汎用作業依頼フロー』は、少し変わったワークフローだ。何せ、どんな業務にでも利用できる。ヘンな言い方をすれば「未定義の業務フロー」を定義している。

しかし、この「未定義領域の作業」を可視化する事(あぶりだす事)は非常に重要だ。「汎用作業依頼」で何度も依頼されている内容は、すなわち何か重要な業務プロセスが未定義となっている可能性が高い。仮に全く同じフロー図(構造※)になったとしても、業務履歴を自動記録するためにも、別のワークフロー(プロセスモデル)として稼働させた方が良いかも知れない。
※ 『1.作業依頼』→『2.完了報告』→『3.完了確認』と言う2者間の依頼構造

[作業依頼フロー]

「業務フロー」に組み込まれるべき「業務フロー」を考える。(へ?)

結論から言えば『専門技能を部門横断的に発揮すべき仕事』が、それにあたる。事業内容あるいは会社規模によって大きく異なるが、「誤植確認」「原稿翻訳」「商標法違反チェック」「プレゼン資料ブラッシュアップ」などなど様々だ。

以下のワークフロー定義は、「原稿の日英翻訳業務」が多くの部署で発生する会社の「原稿翻訳フロー」だ。他の業務フローから呼び出される事(組み込まれる事)が想定されている点が秀逸だ。しかも翻訳完了後、「元の業務プロセス」に対して英訳済原稿データを自動的に送り返す。古いIT用語で言えば『サブルーチン』と言う仕組みだ。ビジネスプロセス的(BPM的)には『サブプロセスの呼び出し』と言っても良い。

社内の「翻訳センター」とでも言うべきこのチームは専門技能者の集まりだ。「彼らへの入力」と「彼らからの出力」を定義することは全社の業務効率の改善に大いに貢献する(在宅勤務制度のヒントにもなろう)。ちなみに、しばしば「本業に集中すべくこの業務は社外アウトソースしましょう」と言う議論になるが、社内用語・専門用語を熟知している点で、社外へのアウトソースとはクオリティが違う。

[原稿翻訳フロー]

業務の流れを定義する際、「業務プロセスの【S:始点】と【E:終点】を何に設定するか」は、センスが問われる。

例えば『問合対応フロー』であれば、「s:問い合わせの受信」に始まり「e:回答の送信」に終わる。
例えば『請求書発行フロー』であれば、「s:請求データの入力」に始まり「e:入金確認」に終わるだろう。
・・・これらのワークフロー設定に異論は少ない。

しかし仮に、『s:引合対応』から『見積受注』や『製造』などを経て『e:請求入金確認』に至る様な、、、長い工程を「一つの業務プロセス」として定義したとすれば、それには大きな反論があるだろう。何と言っても、フロー図が複雑になり、その作業工程が見づらくなる。更には「業務データ」の項目数も必然的に多くなり、処理に必要なデータが見づらくなってしまう。


最も簡単な解決策は、≪(A)フェーズに分割して管理≫する手法だ。

一連の業務を「東京から大阪までの新幹線」に喩えれば、「(1)東京から名古屋」と「(2)名古屋から京都」と「(3)京都から大阪」に3分割して管理する方法だ。つまり、(1)~(3)それぞれのフェーズで重要な手順を、各設計責任者が定義する。『建築工事』や『研究論文作成』など、プロジェクト自体が長期に及ぶ業務を想像すればイメージしやすい。関与する人間(管掌する部門)が変わるポイントでフェーズ分割するのが王道だろう。

もう一つの解決策は、抽象化して≪(B)単純サイクルに分割して管理≫する方法だ。

「東京から大阪までの新幹線」で言えば、これを「発車から停車」と言うシンプルな業務プロセスの繰り返しと捉える。極めて汎用性が高くなり、また業務手順を詳細に記録できるようになる。同時に(一般論ながら)「全体」を俯瞰しづらくなる。

[発車から停車までの業務プロセス]

業務記録と言えば「紙」が定番。

『請求書』や『発注書』、あるいは『契約書』や『議事録』などなど、様々な情報が「紙」で記録されるのだ。基本的な考え方は、江戸時代の『朱印状』や聖徳太子が遣隋使に持たせた『国書』と大して変わらない。要は証拠を残したい。

しかし、紙の管理は容易ではない。。。
何と言っても「情報検索性」が低い。更には「情報共有」も不可能に近い。
  • 「あの契約書って、いつ郵送したんだっけ???」
  • 「あの注文請書、ちゃんと誰か郵送した???」
情報端末が爆発的に普及した21世紀。我々は「証拠を残しておきさえすればイイ!」と言う考えから、「活用しやすい形で業務データを記録する!」と言う発想に改めなければならない。少しずつでも電子化/電磁的記録を推進する必要がある。

以下は、「会社から発送される郵送物」を、少しでも電磁的に記録しようと試みるワークフローだ。
コピー機でコピーをとってバインダーに閉じるのではなく、元となったデジタルデータと処理時刻を正確に記録する所に主眼がある。押印やサインが必要な書類の場合には、「スキャンデータ」も追加で保存される。

[押印/郵送フロー]

ちょっとした「仕事」を誰かに依頼する、、、日常的に良くアル!

多くの場合、『Email』と言う「魔法のツール」で解決される。すなわち仕事の依頼元であるAさんが依頼先であるBさんに対して
  • ワタシの在職証明書を発行して下さい
  • 競合製品XXXの調査をお願いします
と言った内容のメールをしたためるのだ。しかしこの Email と言うツール、「魔法のツール」であると同時に「タスクの墓場」でもある。。。

ここでは、
  • 「業務プロセス」と呼ぶにはタメラワレルような『発生頻度』が低い業務
  • 「業務プロセス」と呼ぶにはタメラワレルような『工程』が短い業務
から見直す事を考えたい。その後には、発生頻度が高い業務プロセスや、工程が長い業務プロセスをも改善できるようになるだろう。

[汎用依頼ワークフロー]

クラウド型グループウェア Google Apps の進化が止まらない。
この12月(2012年)、オンラインストレージ『Google Drive』の書類を気軽に「添付」できる様になった。(この4月にリリースされたネット上のファイル保管領域)

「Gmail の多機能さ」、「Google Calendar の使い易さ」、「Android スマートフォンとの親和性」、あたりが人気の Google Apps だったが、今後は「Google Drive の包容力」(?)も大きな支持を得て行くのだろう。世の中の会社から『ファイルサーバ』が消えて無くなる日も遠くない。

以下の人事考課ワークフローでは、人事考課シートを Google Drive に置いたまま、そのシートを参照する形で「評価工程」が進む。実にクラウド時代のワークフローだ。

参考)Cloud News 『Gmail と Drive が更に密に』

[人事考課フロー]