fbpx
■サイト内検索:
 

RPA Biz > RPA > RPA対象業務の実例(1) ~ 経理財務、人事総務、営業事務、購買等における各種書類媒体について

RPA対象業務の実例(1) ~ 経理財務、人事総務、営業事務、購買等における各種書類媒体について

2018.05.22

今回のコラムでは、実際のプロジェクト事例から、具体的にどのような業務がRPA対象として導入が進められているのか紹介していきたいと思います。主な部門は、経理財務、人事総務、営業事務、購買等になりますが、基本的な適応対象業務のパターンも列挙していきますので、その考え方をしっかりと身に付ければ他部門であっても十分応用できる内容になるかと思います。

まず、RPAの導入を検討する上で、基本となる考え方があります。それは、業務の最小単位を「入力(インプット)」と「加工」と「出力(アウトプット)」の流れで抑える事です。これはRPAによる業務範囲を特定する上で非常に重要になります。なぜなら、RPAによる自動化に向いている業務は、これらの「入力」と「出力」がしっかりと定義されている作業であることが前提となるからです。つまり、0もしくは複雑で捉えどころない情報ソースから成果を出すような創造性の高い作業はRPAではできません。インプットとなる情報とそこから加工して出すべきアウトプットとなる成果物が比較的しっかりと定義づけされうる業務がRPAに向いています。これが所謂、「定型業務」と呼ばれるものになるわけですが、現在のRPAロボットにはAI技術の導入は未だこれからの段階でありますので、この「定型」度合いも他の人間の社員の方々が行っている業務に比べてより狭義で、厳密な意味での「定型」となります。こちらについては、別コラムでも取り上げた内容になりますので、詳細はそちらを参照ください。

 

RPA導入の進め方~事例から見るノウハウ・必要ステップ(2): 2回目業務ヒアリング~RPA機会の精査・深堀り

 

RPAロボットの基本単位の考え方

 

 

それでは、具体的にRPA対象業務となる入力(インプット)と出力(アウトプット)はどのような媒体を通して、行われるのでしょうか。現在各社で行われているRPAプロジェクトの実例を鑑みますと以下のようになるかと思います。

 

RPAの入出力の基となる媒体

 

 

<システム> 

勘定奉行等の会計システムやSAPに代表されるERP、セールスフォース等のCRM、その他にもSCMのシステム等、現在の企業運営には様々なITシステムが使われています。もともと大企業はオンプレミスを志向する傾向があったものの、近年は企業の規模に関わらずSaaSによるクラウド型を利用する企業が増えています。

ITシステムの趣旨としてそもそも自動化や効率化がありますが、実はこのシステムの周辺領域ではまだ人力による手作業が残っていることが多々あります。代表的な例としては、これらシステムにインプットデータとしてCSVを入力する際に、フォーマットをそのシステムの仕様に合わせて加工する業務等です。新たに拡張システムを開発すれば、問題は解決するのかもしれませんが、システムの追加開発は大きなコストが嵩み、費用対効果の面から決断が困難なケースが多いです。そのような時に、低コストで導入できるRPAはこれら「システム周辺領域」の自動化を進めるうえで非常に便利なツールであり、実際に利用が進んでいます。

また一点、このシステム上の作業をRPA化する上で注意事項があります。それは、自社開発システムとRPAツールの相性についてです。市販されているシステム/ソフトウェアについては、主要なRPAツールであればほぼ問題なく操作はできると思われますが、自社独自で開発したシステムについては、RPA導入前の調査段階で一度、動作確認をされることをお勧めします。システム上のどのボタンを押すのか、どのセルに値を入力するのかはRPAツール上のSelectorと呼ばれる機能を使うことになるのですが、自社で独自開発したシステムの場合、そのSelectorによるシステム画面の認識について、稀ではありますが不具合が生じる場合があります。自社特有システムでの作業をメインにRPA導入を考えられている企業様は、特に自社システムに会ったRPAは何なのかの視点を持ってツール選定を行うことが必要となります。

 

 

<電子書類(Excel/CSV/PDF)>

PC上の事務作業を語る上で、Excel等の電子書類の存在は欠かせないでしょう。RPAの事例を見てみても、ExcelCSVといった電子帳票類を扱った業務が非常に多く存在します。これらに加え、お客様や外部のサプライヤーからいただくPDF書類も、テキスト認識ができるのであれば十分RPAによる作業対象となりえます。

まず、ExcelRPAの関係については、少々その役割分担について知識が必要かと思います。皆様ご存知のことかと思いますがExcelはそれ自体、非常に優秀なツールです。Excel内の作業に限定されてしまいますが、マクロを使った作業の自動化もできますし、何よりも計算式のレパートリーが豊富であり、vlookup等を使った参照機能も充実しています。実際のRPA導入プロジェクトを進めている時にも、「この作業はExcel内のマクロや計算式の活用で対応させたほうが良い」というケースが出てきます。このような場合は、無理にRPAロボットにアルゴリズムを構築して作業させるよりも、専用のExcelマスタを作り、Excel内で終わらせるようにします。こういったRPAによるロボットと、Excel機能の役割分担の考え方が重要になってきます。

例えば、vlookupのような参照機能は、RPAロボットでも代用できますが、実際にそのアルゴリズム(forループやif分岐を多用するのですが)をRPA上に実装させようとすると非常に計算処理に時間がかかってしまう事例が報告されています。そのような場合は、無理にRPAにさせるのではなく、予め計算式を埋め込んだExcelのマスタファイルを準備しておき、RPAで入力情報となる値だけを外部から取って、そのマスタに貼り付け、あとの計算処理はExcel内で行わせる、といった分担になります。

次にPDFの扱い方です。RPAPDFを扱うのは主に入力情報としてです。またRPAに特に向いているのは、画像認識されたPDFではなくて、テキスト認識が可能なPDFになります。お客様からの電子注文書や、サプライヤーからの電子請求書で送られてくるPDFは、一般的にこのテキスト認識ができるケースが多く、RPA対象として取り組まれることになります。もちろん、画像認識のPDFであってもOCR技術を使えば、RPA化できる可能性があります。ただ、それは「紙書類」の項で後程説明しますが、認識精度が100%ではなくRPA対象として優先度はどうしても落ちてしまう領域となります。

PDFからRPAへの入力情報を取得する方法ですが、これには幾つか方法があります。PDF自体が比較的シンプルな帳票形式であれば、お勧めするのは、そのPDFをまずはRPA上でテキスト認識させて、その後にそのテキスト情報をCSVに変換するやり方です。そうすることで表形式であるCSVPDF情報を落とし込めることになり、「●列の●行目」といった形で取得先の情報の特定がしやすくなります。ただ、この方法はより複雑なフォーマットのPDFの場合には向かなくなります。その場合は、Acrobat等にあるPDFからExcelへの変換用のアプリケーションを使用します。具体的にはRPAロボットにそのAcrobatアプリケーションを起動させるフローになるのですが、そうすることで、PDFは何かしらかの形でExcelの表形式に変換され、RPAロボットが扱いやすいような形に加工されることになります。

 

 

<メール>

メールは、送り元から送り先、タイトル文からメール本文、そして添付書類等からなる電子情報の集合体です。実際にRPAの現場では、入力および出力の双方で使用される媒体となります。入力情報としては、内部および外部からのメール両方のケースがありえます。内部とは、社員からのメールであり、外部の場合はお客様やサプライヤー等からのメールが該当します。出力としてメールを使う場合も同様で、内部と外部向け双方での活用ができます。

RPAへの入力情報としてメールを扱う場合は、「フォーマットを定型化できるか」が鍵となります。人間が読み手であれば、ある程度の自由筆記形式のメールでも文脈から内容を読み取ることが可能ですが、現行のRPAはまだそこまで器用ではありません。まずそもそもメールの目的を判断させるために、特定のメールタイトル(例:タイトルの頭に【XXX】といった記号を入れるなど)や、特定のファイル名を付けた添付書類、もしくは特定のアドレスでの送付を指定するといった必要が出てきます。社内の社員からのメールであれば、まだ時間をかけてお願いすることで統一が図れますが、お客様やサプライヤーとなるとコントロールが難しいケースが散見されます。ただ、その外部からのメールであっても、例えば、予め決められた様式・名前のExcelフォーマットを添付することを徹底できるのであれば、RPAの対象として見なせるようになります。

しかし、やはり上記のようにメールのフォーマットを統一化するのは、理想として掲げられても、実現となるとなかなか骨の折れる作業になります。そのような場合は、メールでのやり取りではなく、Googleフォーム等のワークフローツールを使用してしまうことをお勧めします。これは特に社内からのメール対応になりますが、経理や人事総務に係わる諸々の申請についてはワークフローシステムの使用を決めてしまえれば、必然的に送られてくる情報形式は標準化されます。メール送付のルールを決めてモグラたたきのように統一化を進めるよりかは、「●●の申請の時は●●ワークフローを使ってください」としたほうが管理部側としてもコミュニケーションがとりやすいといった事情もあります。

次に、出力としてメールを使用する場合ですが、これは主な用途としてはアラートやエラー告知機能になります。既存のシステムでも、何かエラーが起こった時、異常値が検出されたときにメールで担当者に自動送信する機能がありますが、それと似たようなものをイメージしていただけたらと思います。例えば、Excelか何かのフォーマットで管理部に申請する業務があったとします。そのExcel書類の中身をRPAにより一次的に確認して、明らかな入力ミスや添付漏れがあった際に申請者に対して、再申請の依頼をメールで投げるなどの活用が考えられます。既存のワークフローシステムでも一部そのような機能はついていますが、より細かい内容の精査となるとRPAに実行させたほうが有効なケースも多いです。

ただ、このアラートやエラー告知は管理部内への通達であれば問題にはならないのですが、それが直接、社内の他部署や客先/サプライヤー等の外部関係者に行ってしまうことを気にされる現場担当者様は多いです。RPAは、あくまで決まりきった定型ルールに乗っ取ってでしか内容の精査はできません。「誰から送られてきたのか」とか「特例として認めなければいけない暗黙のルール」などを考慮しなければならない場合、ロボットにそのままアラート/エラー告知メールを先方に送らせるのは得策ではありません。このような場合、あくまで告知メールは経理財務、人事総務といった管理部内だけに留め、それを人間の担当者が見て吟味した後に改めて対象者にメール/電話するといった方法が取られることが多いようです。

 

<ウェブサイト>

インターネットを介しての外部サイトの使用もRPAでは一般的に行われています。ここでは、前述の「システム」の項で述べたSaaS型のクラウドシステムではなく、あくまで外部であるウェブサイトに焦点を当てていきたいと思います。ウェブサイトの例としては、購買や営業事務が市場トレンドをモニタリングするために外部サイトの情報を定期的に取得したりすることが挙げられます。外部ウェブサイトはRPAにとって出力先というよりかは、入力情報の取得先として扱われるのが多いのが実情です。

外部ウェブサイトをRPAで扱う場合、重要になるのが「そのサイトの様式が変更しないか」どうかです。RPAで、特定のサイトから情報を取得するため、そのサイトのデザインや画面遷移の方法が変わってしまったらそれだけでロボットは動かなくなります。従って、頻繁にデザインが変わるようなサイトはRPAには向いていないと言えます。また、RPAは主にHTMLベースのサイトに対応します。Flashを使用したサイトでは動作が上手くできませんので注意が必要となります。

 

<紙書類>

次にデジタル媒体ではなく、アナログ媒体となる紙書類について述べます。オフィスオートメーションの進化により、多くの紙書類が電子化されて久しいですが、現実の職場ではまだまだ紙の帳票を使った業務が残されているのが実情です。特に経理財務、人事総務、営業事務、購買といったバックオフィス業務では、領収書、請求書、契約書、申請書、履歴書、等など多くの紙書類に囲まれています。実際に、RPA導入する前の業務分析の段階で、定型業務でかつ非常に負荷が大きい業務として、この紙関係を扱った仕事は上位ランクの常連となっています。

従って、この紙関係の業務、特に紙書類からの手打ちによる「入力業務」を自動化することは、管理部門にとって永遠の夢でもありました。その中で、現在AI技術も活用され始めたOCR技術に業界の注目が集まっています。この日進月歩で向上しているOCR技術ですが、これは世の中にある各種OCRアプリケーションを試した人ならご理解いただけると思いますが、「まだ一部にしか使えない」というのが実情かと思います。特にRPAの現場では「フォーマットがこちら側で統一できる書類」のみが対象としたほうが無難です。OCRの精度を高めるには「OCRにとって読み込みやすいフォーマット」に手直しする必要があり、この事が可能な帳票業務についてのみRPA対象とされているのが現実には多いです。

例えば、サプライヤーからの請求書ですが、この書類様式をこちら側でコントロールできるかどうか、という話になります。それが難しい場合、せめてもということで主要サプライヤー2~3社の請求書に絞ってOCR対応させることもありますが、その限られた書類様式であったとしても、そのサプライヤーの請求書がOCRに対して気を使っていない場合(例えば網掛けをしていたり、文字の行間の幅が不均等であったりする)、途端にOCRの精度が落ちてしまいます。そのような現状を踏まえると、現在この紙帳票においてOCR対応が向いているのは、契約書や申請書などのこちら側でフォーマット指定ができる類の帳票になります。これらのネックとして手書きが発生することが挙げられますが、そちらについては現在AI技術を活用した技術が開発されつつあり、帳票内の手書きの場所を特定できれば読み取り精度向上も可能となります。また、現行で行われているRPAプロジェクトにおいてもこれらOCRを活用した紙書類関係の業務が対象となることはありますが、ただ、やはり精度が100%ではないため、仮に読み取りを自動化させたとしても人間による確認・チェック作業は厳然として残ります。この事を念頭に置いて、RPA導入後の業務設計を行う必要があります。

次に紙関係の業務で挙げられるのは、印刷などの「出力業務」です。これは例えば人事の採用面接において面接官に応募者情報を事前に印刷して配布しておく業務であったり、経理による自社からの請求書発行・捺印業務などが挙げられます。これはプリンター・複合機の仕様にも関わりますが、実はこの細々とした印刷業務が管理部門の社員の負荷を高めている事実が業務分析で発見されることは非常に多いです。これら出力業務をRPAにより自動化し、社員は印刷されたものを回収するだけにするアイデアは、経営層にはピンとこない話かもしれませんが現場スタッフにとっては非常に喜ばれる一手となります。

 

<電話>

電話によるコミュニケーションは今後も残っていくことと想定されますが、RPAにとっては一番扱いづらい領域です。AIによる音声認識技術の向上により、将来的には業務上の音声情報を電子化できる可能性が十分あり得ますが、これも紙書類でのOCR技術と同様、現時点ではRPAの現場では対象とはなりにくい領域となっています。

 

以上が、各媒体の説明と、RPAへの適合を検討する上での概要となります。次のコラムでは、より具体的にどのような業務にRPAが適合できるのか、主要なパターンを類型化してみたいと思います。乞うご期待ください。

 

RPA対象業務の実例(2) ~ 経理財務、人事総務、営業事務、購買等における実導入事例のパターン(前編)

 

topへ
© RPA.biz