クラウド型 ワークフロー

フィールドエンジニアリングBPM事例1・業務プロセスの可視化(見える化)

フィールドエンジニアリング事業の「修理依頼対応」業務プロセスの可視化(見える化)の第一歩、業務プロセス図の作成事例を紹介します。

こんにちわ!矢作です!

企業の情報システムは、従来はオフィスに設置されたパソコンでしか利用できなかったものが、スマートフォン、タブレットPCのようなスマートデバイスの普及により、様々なシーンで利用できるようになってきました。

多くのエンジニアがオフィスの外で働くフィールドエンジニアリングの現場でも、スマートデバイスを活用した業務改革を実現している例があります。フィールドエンジニアが活躍する現場での、業務改善手法のひとつであるBPM(※)を「Questetra BPM Suite」というBPMシステムを使って実践した事例を紹介します。
※BPM = Business Process Management

 

本当は本記事にて、事例の内容を全て書きたかったのですが、かなりの長文になってしまうため3分割しました。最初の記事である本記事では、フィールドエンジニアリング事業の「修理依頼対応」業務について、業務プロセスを定義する事例について、紹介します。

(後日加筆)続編は次の2つ。

顧客満足度に直結する「修理依頼対応業務」

フィールドエンジニアリング事業の業務には様々なものがありますが、その中でもお客様と直接触れ合い、顧客満足度の良し悪しに大きな影響を与える、「修理依頼対応」業務(プロセス)について話を進めます。

「修理依頼対応」業務では、フィールドエンジニアと呼ばれる、各種機器に関する専門知識を持つエンジニアが、お客様のオフィスや工場などで利用されている各種機器について修理や調整を行う業務です。

 

修理依頼対応プロセスの概要修理依頼対応プロセスの概要

 

「修理依頼対応」業務プロセスの標準的な流れは、およそ次のとおり。

  1. お客様が、メーカーのコンタクトセンターに修理を依頼する電話をする。
  2. コールセンターは、お客様を管轄する地域のマネージャに対応を依頼する。
  3. 地域マネージャは、依頼への対応を担当するエンジニアを決定する。
  4. 担当になったエンジニアは、お客様に連絡を取り、訪問日程を決定する。
  5. エンジニアは、訪問日時にお客様の元へ訪問し修理作業を行う。
  6. エンジニアは、修理作業に関する報告を行い、消耗品の手配などを行う。
  7. 地域マネージャは、エンジニアの報告内容を確認する。

 

この「修理依頼対応」業務プロセスには、2014年4月10日に書いた記事にも触れましたが、

  • 工程、作業のヌケ・モレが発生する
  • 業務の遅れに気づきづらい
  • 目標と実績を比較しづらい

という課題が潜んでいます。

 

BPMでは、業務プロセス図を書くことから始め、「工程、作業のヌケ・モレが発生する」という課題を解決することからスタートします。

業務プロセス図を書く!

自分が関わっている業務を改善したいと思ったら、まずはその業務の流れを絵に描く!これが全ての始まり!

フィールドエンジニアリング事業を展開するA社では、「修理依頼対応」業務プロセスについて、現在どのような流れで顧客からの修理依頼に対応しているのかを整理し、業務プロセス図に描きました。

 

修理依頼対応業務プロセス図「修理依頼対応」業務プロセス図

 

実際にはもっともっと複雑なのですが、できるだけ分り易くするため、この業務プロセス図は要点を押さえた簡略なものにしています。

 

この業務プロセス図は、BPMN(※)という表記ルールに従って書かれています。BPMN とは、簡単に言うと、世界的に標準とされている業務プロセス図を書く方法のことです。
※BPMN = Business Process Model and Notation

例えば、

  • この業務プロセスに登場する人物を、「スイムレーン」と呼ばれる横長の四角で表現する
  • その人が処理する作業や工程を「タスク」と呼び、角の取れた四角で表現し、スイムレーン上に配置する
  • タスク等は、その順序を示す「フロー」と呼ばれる矢印で接続する

などが、BPMNで決められています。

 

改めて、BPMNで書かれた業務プロセス図(「修理依頼対応」業務プロセス図)を見てください。この図を構成する部品それぞれの詳細を知らなくても、じっと眺めていると、この業務プロセス図で表現される業務が、どのような業務であるのか、なんとなく直感的に理解できると思います。

BPMNは、多くの知識を持っていなくても直感的に業務の流れを理解しやすいという点が、他の業務プロセスを描画する方法に比べて高く評価されています。

業務プロセス図の書き方

本記事の最初に、「修理依頼対応」業務プロセスがどの様なものであるのか、7つの手順で示しましたが、文字で説明するよりも、プロセス図にするととてもわかりやすいですね。「誰が」「何を」「どのような順番」で行うのかが一目瞭然です。

 

このような業務プロセス図を作成する場合、次のポイントを整理していくと進めやすいと思います。

★「登場人物」を整理

「コールセンター」「各地域マネージャ」「フィールドエンジニア」の3種類の人物が登場します。

★それぞれの人が「やるべきこと」を整理

  • 「コールセンター」は問い合わせ内容を確認の上、地域マネージャに『対応依頼』を行います。
  • 「地域マネージャ」は、問い合わせ内容及び部下であるフィールドエンジニアの状況を確認の上、『担当エンジニア決定』を行います。
  • 「フィールドエンジニア」は、問い合わせ内容を確認の上、お客様にアポイントを取ります(『依頼内容確認』)。アポイント当日、お客様のオフィスに入り(『オフィス入館』)、実施した修理作業の報告を行います(『修理完了』)。
  • 「地域マネージャ」は、フィールドエンジニアリングの修理作業の結果を確認(『対応結果確認』)します。

★やるべきことの「順序」を整理

それぞれの「登場人物」が「やるべきこと」をどのような順序で行うのか整理します。

 

これらを整理すると、「登場人物」は『スイムレーン』として配置、「やるべきこと」を『タスク』としてスイムレーン上に配置、最後にタスクを「順序」に従って『フロー』で接続すると業務プロセス図が完成します。

「修理依頼対応」業務プロセス図では他の記号も幾つか出てきますが、それらは分岐などを表すものです。他にも多くの記号を用いて、自動処理などを表現することができますが、そのような説明はまた別の機会に行います。

 

私どもの提供する業務改善プラットフォーム「Questetra BPM Suite」には、業務プロセス図を描画するプロセスモデラーが用意されていますので、BPMN(スイムレーン、タスク、フローなど)を使って、是非業務プロセス図を描いてみてください。(無料で使えますよ!)

 

もちろんA社でも業務プロセス図の作成には、Questetra BPM Suite を利用されました。

業務プロセス図は少しずつ成長させる

フィールドエンジニアリング業務に携わる人には、早速、「修理依頼対応」業務について業務プロセス図を書いて欲しいと思います。

なぜかと言うと、業務プロセス図を書こうとすると、これまであまり気付かなかった問題に気づいたり、改善のアイデアが次から次に湧いてくるという効果を感じていただけるからです。

 

業務プロセス図を書くとき、業務プロセスに参加する人にヒアリングを行うと、まず感じられるのは「属人性の高さ」です。フィールドエンジニアによって修理完了の報告のタイミングが異なったり、その内容が異なったりすることなどが顕在化してきます。(属人性が高すぎる現場では業務プロセス図を書くことに苦労するかも知れません)

 

また、業務プロセスを図に表現してみることで、やっていないけどやるべき事、に気付くことがあります。

地域マネージャが最終的に対応結果の確認を行った際、その内容によっては、コールセンターからもフォローを入れさせるべき場合があります。そうであれば「対応結果確認」タスクの後に、コールセンターに「満足度チェック」させるタスクを配置しよう、というアイデアが湧きます。

 

このように、最初は100点満点の業務プロセス図でなくても、ある程度合格点の業務プロセス図を作成するから始め、少しずつ属人性を排除して標準の流れを育てる、また完成した業務プロセス図を眺めて、湧きでてきた改善のアイデアを反映させていく、という作業を繰り返し、少しずつ業務プロセス図を成長させることができます。

成長した業務プロセス図のとおりに仕事を進めることが出来れば、工程、作業のヌケモレを防止することにとどまらず、効率よく工程、作業を処理することができ、高品質なアウトプットを生み出すことを実現できます。

 

まずは携わる業務について、「業務プロセス図を書く!」ということが、BPM(Business Process Management)=業務改善の第一歩です。

 

フィールドエンジニアリング事業の「修理依頼対応」業務(プロセス)の可視化のうち、「業務ルール」の可視化について書いてきましたが、続いて「業務遂行状況」の可視化、「業務実績」の可視化について書きます。

今回はここまで!

参考

 

YAHAGI Hajime の紹介

幸せを生み出すITを追求するクエステトラの一味です。 国産の BPM ソフト Questetra BPM Suite で日本・世界を幸せにしたい。
YAHAGI Hajime の投稿をすべて表示

あわせて読みたい
55.カイゼン Tips の前の記事 超高速開発で情報システム部門が本来の役割を取り戻す
55.カイゼン Tips の次の記事 フィールドエンジニアリングBPM事例2・業務プロセス進ちょくの可視化(見える化)
YAHAGI Hajime の他の記事 興味本位でスタートした案件を減らす方法

アーカイブ

 RSS