■サイト内検索:
RPA.biz
RPA Biz > 2018年 > 12月

事例から見るRPA開発のドキュメント管理について

2018.12.11

 

一つの業務をRPA化するには、どのような順番で行う必要があるのか?

 

普通に考えると、最初に何をRPA化すべきか、つまり「業務選定」を行うだろう。

 

その後、当然RPAプログラムの開発が不可欠だ。開発終わったら、テストし、実運用を行うだろう。

 

 

大まかにいうとほぼすべてのシステム導入もこのように行うが、RPA自身の特徴があり、導入ステップをもっと細分化しないといけない。

 

 

 

図1のようにまず業務選定をし、その後は現在の業務フローを見直さなければならない。

 

 

RPAは人間のように作業することはできないので、現行手作業のフローのままでRPAできる業務はかなり少ないだろう。

そのため、RPAが対応可能な業務に変えないといけない。

 

 

 

その後、「開発設計」もとても重要な部分だ。

そもそも「開発設計」は何かから言うと、いかにRPAのプログラムを作っていくかの設計図となるものだ。

 

基本的に、開発者が見てRPA開発を行う。

その後の開発とテストは一般的な意味の開発とテストになる。

 

運用マニュアル作成については基本的にはRPA化後の業務はいかに運用するかについてのもので、ユーザーが見ることになる。

 

これを見て、ユーザー、あるいは業務担当者は普段RPAに合わせて業務を遂行する。

 

 

では、タイトルの問題に戻ると、「RPA開発にはどんなドキュメントが必要なのか」という問題は「どの段階にドキュメントが必要なのか」ということになる。

ここでの「ドキュメント」というのはRPA化する際に各プロセスを分析、記録、管理するために作るものだが、どの段階に必要かというと、答えはシンプル:「すべて」だ。

 

一見当たり前なことに見えるが、実際運用時ドキュメント管理の問題でRPA導入プロジェクトがトラブルや非効率的の原因となった事例もある。

 

今回は特に省略される傾向のあるステップの例を挙げて見てみよう。

 

 

 

 

◆業務選定

業務選定段階では、まず業務フローを一通りヒアリングし、その他と評価した上で、各業務の中からROIの高い業務を選定するのが基本だ。

 

一般的に、業務の複雑さ、RPAとの相性、削減可能な時間、開発難易度などの指標から一つの業務をヒアリングする。

 

 

ある大手会社A社が候補となる業務が非常に多いため、早く業務の初期ヒアリングを行った上で、RPAにあまり向いてない業務を排除しようとした。

もちろんこれは一般的な考え方だが、A社の問題は時間節約のために評価の書類を全部残していなかった

 

 

A社のやり方は、まず各部署から書面のRPA化リクエストが上がってくる。

リクエストの中では基本「何についての業務」、「月何時間かかっている」など簡単なものしか記載しない。

 

その後、RPA導入のヒアリング担当が約30分から1時間程度の業務フローの初期ヒアリングを行う。

 

ヒアリングの間に「人間の判断がたくさんある」、「VPNが使われている」、「RPA非対応のブラウザが必要」などの情報があれば、とにかくこれを理由として後回しとした。

 

そして、目標業務に時間を集中したため、記録のドキュメントをまとめて管理しなかった。

 

 

しかし時間を立つと、新しくヒアリングした業務より、以前後回ししたXX業務のほうがROIがよいと気づいた。

この時、当時ヒアリングしたメモや評価のドキュメントが集中管理していないため、整理するには時間がかかったし、災厄の場合、もう一度ヒアリングすることもあった。

 

あまりにも効率に重視し、逆に非効率が起きていた。

 

 

 

 

◆開発設計

ロボットは人間のような能力がないため、RPA化するには、業務フォローを必ずロボットのロジックに合わせないといけない

 

これはすでによく知られている事実なので、やらないでいきなり開発に入ることはないだろう。

 

そして、「業務フローの見直し」を重視するあまり、「開発設計」を軽視してしまう場合がある。

 

 

「業務フローさえ直せばそのままロボットが作れる」という発想はA社がRPA導入プロジェクトの早期に存在していた。

 

実際A社が使っているRPAソフトに「開発設計書」のフォーマットが存在していたが、あらゆる事情でとにかくいくつかの業務を早くオンラインさせたく、なおかつ開発設計書が書ける従業員が社内にいなかったため、とりあえず派遣のRPAエンジニアと一緒にヒアリングをしながら開発を進めていた。

 

 

「開発設計書」の作成は時間がかかるので、この進め方は一見開発期間を短縮されているように見えるが、実際はその逆だ

 

開発設計書がないため、エンジニアは業務のフローを全部理解しないといけない。

 

A社の場合はヒアリングと同行させた。もちろん、業務が少なく、あるいはエンジニアが十分の人数がいればこれも不可能ではない。

 

しかし、A社の場合は開発エンジニアのリソースも少なく、待の業務が多いという状況だった。

 

 

仮に見てすぐ開発できる「設計書」があれば開発に時間を短縮することは可能になるのと、エンジニアはヒアリングに行かなくて済む。

A社もこの問題に気づいた、設計書を作成するリソースを調達して、開発設計のドキュメントを作成するようになった。

 

 

また、開発設計書の作成は後日のメンテナンスにとっても大きいメリットがある。

 

開発設計書が正しく管理されていれば、ロボットの開発に関する詳細や仕様変更履歴まですべて記載されているはずだ。

メンテナンスが必要となる際に、開発した本人ではなくても、どのエンジニアが見ても早く分かるようになるので、非常に効率よい。

 

 

 

 

◆運用マニュアル作成

ロボットが開発完了し、オンラインになったら、開発チームがほっとする気分になるが、ユーザーにとってはそうではない。

 

知れているように、RPA化する際に、基本業務フローの見直しが発生する。

そのため、今までの作業と比べて、従業員が毎日しないといけない業務も変わる。

 

 

例えば、どのようなデータを何時までどこに格納するか、このようなエラーが起きる場合はどのように対応すべきか、RPAが止まった場合どうなるか、なども問題が出てくるだろう。

 

通常、このような問題業務フロー見直しの段階で既にある程度決めていたはずだが、運用向けのマニュアルがないと、ユーザー側でトラブルが発生する場合がある

 

 

A社の運用に関するマニュアルはドキュメント化されているわけではなく、各案件によってやり方が異なる。

 

Excelベースのマニュアルを作った開発担当者もいれば、メール程度でユーザーとやり取りしている開発担当者もいる。さらに、そこに含まれている内容も異なる。

 

 

 

A社はこの現象に気づいて、各担当者は普段どのようにユーザーに運用手順などを説明しているのかを調査した。

 

そして、統一した運用マニュアルフォーマットが作成できた。

 

内容としては、RPA化後業務のフロー、こと業務に関連するすべての部署および従業員の役割、業務手順の詳細、RPAエラー一覧および対処マニュアル、リカバリーマニュアルなどが含まれていた。

 

そして、運用マニュアルの新フォーマットが普及後、ユーザーから好評された。

 

今までRPAに関する不安などが解消され、より効率よくロボットを利用できた。

 

 

 

 

◆最後に

今回は失敗事例が多いが、反面教師として、RPA化する際にドキュメント作成と管理の重要性を説明した。

 

特に大企業の場合、部署間のコミュニケーションがすぐできない場合があるかもしれないので、ドキュメントは運用の信頼性を高めるための良い手段だ。

 

一部のRPAソフトはオフィシャルで推奨するドキュメントフォーマットもある。

 

少々面倒くさいものや「意味のない」ものもあるかもしれないが、本文にあった失敗事例にならないように、大事にドキュメント管理したほうがよいだろう。

 

 

 

 

 

 

ゆうちょ銀行、投資信託口座開設業務の効率化にRPAを導入

2018.12.10

参考記事;ゆうちょ銀行、投資信託の口座開設業務をRPAで自動化 作業時間を3分の1に――富士通の業務自動化システムを導入

 

 

 

富士通ホームページより引用)

 

 

 

富士通株式会社 ( 本社:神奈川県川崎市、代表取締役社長 :田中 達也、以下富士通)は株式会社ゆうちょ銀行(本社:東京都千代田区、社長:池田 憲人、以下ゆうちょ銀行)に自社のOCR技術を提供することを発表した。

 

 

ゆうちょ銀行では、これまで投資信託の口座開設業務を銀行の行員自らが行っていた。

日々の業務は数百名分に上り、ゆうちょ銀行の行員がすでに開設された普通口座やそこから把握できる顧客の個人情報を再確認したのち、投資信託システムに手入力していた。

 

 

ゆうちょ銀行は、富士通の提供するOCRとRPAを用いたシステムを利用することで、従来手作業で行ってきたこの手作業業務を自動化する試みである。

 

早くも自動化の結果は出ているようだ。

ゆうちょ銀行はこのシステムを9月に導入し、運用を開始してから業務時間を3分の1に短縮できることが確認されている。

 

 

 

富士通が提供するシステムの詳細については、富士通ホームページより引用する。

 

 

1.申込書の高精度な読み取りを実現(OCR)

富士通グループの株式会社PFUのOCRソフトウェア「DynaEye(ダイナアイ)」を活用し、申込書をスキャナーで読み取るだけで、印字や行員が手書きした書類を高精度に認識します。文字のつぶれや未記入部分などに対してのみエラーをあげるため、ゆうちょ銀行様の行員は該当部分のみ目視して確認するだけでよく、作業効率化が図れます。

2.顧客情報のデータ登録から完了通知までを自動化(RPA)

Kofax Japan株式会社のRPAパッケージ「Kapow(カパウ)」を活用し、OCRで読み取った情報と、普通口座の顧客情報を登録処理し、内容にミスがないかを突き合わせて確認します。確認後、投資信託システムへの入力や、完了通知を行うところまでを一貫してRPAで実施し、正確性の向上や大幅な時間短縮を実現します。

 

 

申込書の読み取りには、PFUのOCRソフトウェアである「DynaEye」を使用。

スキャンすることで印字されてある文字や手書きの文字を高精度に認識する。

これにより、ゆうちょ銀行の行員はエラーの確認だけをすればよく、効率が向上した。

 

RPAパッケージには、Kofax Japanの「Kapow」を使用。

OCRからの流れや顧客情報の入力などの自動化を行っている。

 

 

地銀もどんどんRPA化を行っている中で、今後もRPAと銀行の関係は目が離せないようになっていくだろう。

 

銀行とRPAの親和性などについては以下の記事で詳しく紹介しているのでぜひ読んでほしい。

銀行とRPA

 

 

 

 

 

 

 

【ノンプログラマー・ライトプログラマー向け】UiPathの開発においてよく発生するエラーとその対策について

2018.12.07

 

 

 弊社がパートナー契約を結んでいるUiPath社のRPAツールには、「Community Edition」という無料でRPAのプログラム作成を行うことができるツールがあります。

 

簡単にダウンロードできますので、初期投資を気にせずにRPAの体験を簡単に行うことができます。

 

その為か、プログラミングの経験が少ない人やExcelでマクロ機能を使ってプログラムを組んだことがある人といった、所謂ノンプログラマー、ライトプログラマーの人達が業務を円滑に進めるために使用されることが増えてきたと感じています。

 

 

ですが、実際にUiPath Studioを起動してプログラムを組もうとすると、意外と難しいと感じるかと思います。

 

特に、今までプログラミングの経験をしていない人には、使いこなすまでにはかなりの勉強が必要です。

 

 

UiPathには「UiPath Academy」というeラーニング教材もございますが、こちらをこなすことで一通りの知識は手に入ります。

ただ、使いこなすとなるとStudioで実際にプログラムを組んでみて、失敗を繰り返して少しずつ上達していくしかありません。

 

 

プログラムを組んでいく中で、特に初心者が陥りがちな問題が、プログラムを組んで動かしてみたけど、途中でエラーが出て止まってしまうことです。

 

 

よくわからない単語が並んでいること、若干危険そうな感じがしてしまうことから、あまり動かさずに開発をやめてしまいたくなります。

 

原因を探ろうとしても、そもそも何が原因でエラーとなっているのかわからないため、諦めてしまう人もいるでしょう。動くところまでいかずに挫折してしまう方もいるかと思います。

 

 

しかし、そこで諦めてしまっては非常にもったいないのです。

シンプルに動くようにするためには、シンプルなエラー処理のアクティビティを追加することで、簡単に動くようになります。

 

また、より深くエラーの原因を探りたい、またはエラーの内容によって分岐させたい場合には各エラーの内容とその対策を理解することで、より強固なプログラムを作成することができるでしょう。

 

 

◆Try-Catchアクティビティについて

エラー処理の対処をする際に最も使用するアクティビティが、「Try-Catchアクティビティ」です。

 

これは、まずTry内の処理を実行して、もし処理途中でエラーが発生したらCatch内の処理を行う、というものです。

また、Try内でエラーになる、ならないに関わらず、Finally内の処理を最後に必ず行います。

 

 

エラー内容での分岐は考慮せず、且つとりあえずエラー処理の制御を行いたい場合は、Try内に作成したプログラムを入れ、Catch内のExceptionを「System.Exception」にすれば、エラーが発生しても途中で停止することなくプログラムが走ります。

 

ですが、エラーの内容がわからないため、エラー内容で分岐させる処理を行いたい場合は、各エラー内容に応じた処理を行う必要があります。

 

エラーの中でも、特にメジャーな内容について、以下に列挙します。

 

・System.NullReferenceException

参照先が見つからない、あるいは参照先が対象範囲外の場合に、このエラーが発生します。

特に、Excel等でセル範囲から値を取得するときに空欄のセル(Null)を取ってしまい、その変数を使って他の操作をしようとしてしまい、結果エラーとなってしまいます。

 

このエラーは、参照先の設定を適切に設定することで回避することができます。

 

 

・System.ArgumentException

Argumentとは、引数のことです。指定した引数が無効な場合にこのエラーとなります。

 

指定した引数が無効の場合、このエラーが返されます。

Invoke Workflowを使って別のxamlファイルを参照しているときに発生することが多いようです。

 

 

・System.IO.IOException

IOとは、In/Outのことであり、入力/出力の際にエラーとなった場合にエラーとなります。

ファイルやディレクトリへの読み取り/書き込みを行う場合に、参照先は正しいが抜き出すときに読み取り/書き込みができない場合に発生します。

このエラーが発生した場合は、参照しているファイルやディレクトリが何らかの理由で読み取り/書き込みができていないため、ファイルやディレクトリの参照値あるいはそれらの内容を再度確認することで、エラーの原因を突き止めることができると思います。

 

 

・NotFoundElementException

セレクターエラーで最も発生する可能性の高いエラーです。

 

その名の通りセレクターで選択したエレメントが見つからなかった場合にこのエラーとなります。

 

レコーディング・アクティビティ等で選択したセレクターが取れない場合、特にレコーディングでwebの情報を取得するプログラムを組んだ時に多く発生します。

原因は、webページの読み込みに時間がかかってしまい、セレクターの要素が出現する前にプログラムが走ってしまうため、要素が見つからずエラーとなることがほとんどです。

 

 

・NotFoundElementExceptionのエラーに対する改善策

RPA特有のエラーである、NotFoundElementExceptionについての改善点をまとめました。

 

Webページから特定の要素を取得するためには、セレクターを使いこなす必要があります。

セレクターのタグ要素がうまく取得できているのにも関わらず、要素が見つからないエラーとなってしまう場合には、以下の方法で問題なく動作するようになる可能性があります。

 

 

  • Delayアクティビティを使用

Delayアクティビティは、指定した時間が経過するまで待機するアクティビティです。

  

ページの読み込みに3秒程度かかるが終了するまでの時間を指定することで、webページの読み込み時間より長く待機させることで、要素を安全に取得することが可能です。

 

 

  • アクティビティにて、Delay After(Delay Before)を使用

セレクターを取得するアクティビティのプロパティにDelay AfterDelay Beforeがあります。

これらを使用することで、Delay アクティビティと同様に指定の時間待機することが可能となります。

 

Delay Afterがアクティビティ実行後、Delay Beforeがアクティビティの実行前となります。

 

使用時の注意として、ミリ秒で表記する必要があります。(3秒の場合は3000と表記する)

 

 

  • On Element Appearアクティビティを使用

上記のDelayアクティビティの場合、いずれも、「次のアクティビティ実行まで待機する」ため、必ずしも要素が取得できない可能性があります。

また、想定よりも早く要素が出現したとしても、指定した時間になるまで待機してしまうため、次のアクティビティの実行まで無駄な時間が発生してしまうことがあります。

 

これらを解決したい場合に、このOn Element Appearを使用することで解決できます。

 

このアクティビティは、「要素が出現してからその動作を実行する」アクティビティです。

このアクティビティを使用すれば、要素が出現した時点で指定の動作を実行してくれますので、読み込みに時間がかかっても要素が取得でき、且つ無駄な待機時間も削減することができます。

 

 

  • Retry Scopeアクティビティを使用

Retry Scopeアクティビティは、Conditionに指定されたアクティビティ状態になるまでプログラムを繰り返す処理を行います。

ConditionElement Existアクティビティを指定することで、選択したい要素が出現するまで同じ動作を繰り返し実行してくれます。

 

 

  • Try-Catchアクティビティを使用

厳密にいえば、Try-Catch文でセレクターの取得ができるようになるわけではありません。

ただ、もしセレクターの要素が取得できなかった場合に、プログラムをエラーで終了させたくない場合は、このアクティビティを使用することで解決できます。

 

この場合、注意してほしいのは、要素が取得できなかった場合に、要素が取得できないまま先に進んでしまうことです。

もし、セレクターで取得した要素を使って以降のプログラムを走らせた場合、必ず要素が取得できなかった場合の代替案で重大なトラブルにならないように注意して設定することが求められます。

 

 

 

 

 

 

RPA導入におけるリスク/リスク管理支援サービス

2018.12.06

 

 

 

 

 

RPAの導入事例が増えるにつれ、RPAに関するリスクについて懸念の声が目立つようになってきたように感じます。

 

今回のコラムでは、RPAのリスク管理支援サービスについて紹介したいと思います。

 

 

 

 

・RPAリスク管理サービスとは?

RPAリスク管理サービスとは、コンサルティング会社等が開発したリスク管理フレームワークを使って、RPA導入における各種リスクに対して管理を行うサービスのことを言います。

 

 

 

・サービス開始の背景

RPAのリスク管理へのニーズの高まりの背景の1つには、導入時に、RPAによる業務自動化のメリットのみが注目され、導入後に起こり得る課題やリスクの管理の重要性が認識されていなかったことが挙げられます。

 

 

RPAの運用におけるリスクには、以下の

 

①法令等への違反」「②不正アクセス・情報漏洩」「③業務の停止」「④不十分な管理・非効率な管理

 

の4種類のリスクのほか、さまざまなものが考えられます。

 

 

 

・RPAにかかわるさまざまなリスク

法令等への違反

内部統制報告制度・米国SOX404条の対象企業では、RPA導入に合わせて、報告対象業務における内部統制を、マニュアル統制からIT統制に置き換える必要があります。

 

個人情報を取り扱う業務へのRPA導入の場合も、セキュリティ管理対策の再構築が必要です。

こうした取り組みを怠ると、関連法令・規則等への違反につながる恐れがあります。

 

 

不正アクセス・情報漏洩

個人情報など機密性の高い情報を処理する業務では、RPA導入による情報の形態、記録媒体、処理方法の変化に合わせて、セキュリティ管理対策の見直しが必要です。

 

見直しが遅れると、セキュリティ管理水準の低下を招き、不正アクセスや情報漏洩の発生等につながる可能性があります。

 

 

③業務の停止

停止が許されない業務や許容停止時間が短い業務でRPAを使用する場合、RPA停止時の対応について、しっかりとしたプランを用意しておく必要があります。

 

万が一のRPAの停止に対して適切な対応ができていないと、後続業務の遅延・停止などを含め、社内や取引先に大きな影響を与える恐れがあります。

 

 

④不十分な管理・非効率な管理

RPAを大規模に導入する場合、全社共通の方針、ルールの下で管理を行うことが必要です。

部門ごとに分散して導入が進められた場合、無駄や重複の発生による管理コストの増大、内部統制・情報セキュリティ対策水準の低下などの問題につながる可能性があります。

 

さらに、組織が運用する既存のリスク管理の取組みをどのようにRPAに適用させるのかといった問題に加え、内部統制報告制度に対応していくための有効な内部統制の見直しや再整備も、重要な課題として浮上しています。

 

KPMGコンサルティングWebサイトより引用:

https://home.kpmg.com/jp/ja/home/media/press-releases/2018/04/rpa-risk-governance.html )

 

<参考>

株式会社イーセクター:RPA の盲点 IT ガバナンスの重要性

https://www.esector.co.jp/special/rpa/rpa6.html

KPMGコンサルティング:RPA導入に伴う内部統制の整備ポイント~想定されるリスクにどう対応するか?~

https://home.kpmg.com/jp/ja/home/insights/2018/04/rpa-internal-controls.html

AccentureRPARPAガバナンス ~本格導入に向けてのガバナンス整備の必要性

https://www.accenture.com/jp-ja/_acnmedia/Accenture/jp-ja/Documents/DotCom/FS-Architect/45/Accenture-Finance-FSArchitect-vol.45-1.pdf

PwCコンサルティング:RPAのガバナンスとセキュリティ

https://www.pwc.com/jp/ja/japan-knowledge/archive/assets/pdf/rpa-governance-security1608.pdf

EYアドバイザリー・アンド・コンサルティング:RPAを監査する RPAのリスクを低減する内部監査

https://www.eyjapan.jp/services/advisory/risk-transformation/pdf/RT-03_rpa-audit.pdf

 

 

 

 

・リスク管理サービスを提供しているコンサルティングファーム事例

ここでは、現在リスク管理サービスを提供している事例について3つ紹介します。

 

1.PwCあらた有限責任監査法人

 

 

[サービス名]

RPA導入におけるガバナンス/リスク管理態勢 評価・整備支援サービス

[サービス開始時期]

20171218

[サービス内容]

同社は、RPAの導入、利用に当たって必要な、リスク管理やガバナンス面での対応事項を洗い出すフレームワークを開発。

同フレームワークは、個々のロボットの重要度とリスク評価、ロボットに対するIT全般統制などのセキュリティ確保、内部統制監査対応などの「守り」の部分と、RPAの導入、目標、戦略達成や人材育成などの「攻め」の部分を含んでいるという。

同社は、同フレームワークを活用し、RPAの組織への浸透や定着化、各プロセスのモニタリング、評価など、ガバナンスの維持、改善のための仕組み作りを支援するとしている。

[サービスプロセス]

1.概要調査:評価実施にあたっての概要把握を実施

RPA導入によって解決すべき経営課題、導入の目的・目標の確認、RPA導入状況の概要把握

・評価アプローチの検討

2.評価:フレームワークを活用した評価実施

・フレームワークを活用したRPA導入に係るガバナンス/リスク管理態勢の評価

RPAニオケルIT全般統制整備状況の評価

3.構築計画支援:ガバナンス/リスク管理態勢構築に向けた計画策定 

・評価結果より課題の整理・対応方針策定

・ガバナンス/リスク管理態勢構築・展開に向けたロードマップの策定、体制の策定

SOX対応に係る計画策定

・報告書作成/報告実施

4.構築実施:RPA導入に伴うガバナンス/リスク管理態勢構築

RPA推進組織(全社組織)の立ち上げ

RPAの棚卸・リスク評価、重要なRPAの特定

RPA導入に係る方針

 

[URL]

https://www.pwc.com/jp/ja/services/assurance/process-system-organization-data-management/risk-governance-advisory/rpa.html

 

 

2.KPMGコンサルティング

 

 

[サービス名]

RPAリスク管理支援サービス

[サービス開始時期]

2017424

[サービス内容]

KPMGコンサルティングは、RPAの導入対象、範囲、管理要件、ライフサイクル、既存の内部統制やシステムリスク管理の状況、および個別のニーズに応じてRPAに対する柔軟で効果的なリスク管理とガバナンスの構築・運用を支援しています。

①財務報告に関連する重要な業務へのRPAの導入を計画・実施している

⇒効果的で有効性の高い、RPAにかかわる内部統制の整備と運用、継続的な維持・改善・評価を支援

②個人情報、重要情報の取り扱い業務へのRPAの導入を計画、実施している。

⇒既存のセキュリティ管理の枠組みを活かした、RPAに関わる効果的な情報セキュリティ対策の導入と運用を支援します。

③ 中断・停止による影響が大きい業務へのRPA導入を計画、実施している

⇒業務の重要性や許容停止時間などを踏まえて、RPA導入対象における効果的で実行可能な業務継続計画の立案、訓練を支援します。

④ RPAの大規模な導入を計画、実施している

⇒既存の枠組みと整合した、RPAの導入・展開・運用にかかわる全社的なリスク管理の方針・ルールの設計と運用を支援します。

[リスク管理フレームワーク]

KPMGコンサルティングは、RPAのライフサイクル全体をカバーするフレームワークに基づいて、RPAに関わる「戦略リスク」「導入展開リスク」「運用リスク」の各要素に対して、「RPAの戦略」「RPAの導入」「RPAの運用」「RPAのリスク管理とガバナンス」の観点から対応します。

 

[URL]

https://home.kpmg.com/jp/ja/home/services/advisory/risk-consulting/it-advisory/rpa-risk-management.html

 

 

3.日立コンサルティング

 

 

[サービス名]

RPA導入におけるガバナンス構築支援コンサルティング

[サービス開始時期]

2018年(月は不明)

[サービス内容]

日立コンサルティングでは、RPA導入で必要となるガバナンス構築時の対応事項をフレームワークとして定義し、それをベースにRPAの導入、開発・保守、運用を円滑かつ安全に使うための規定類をテンプレート化しています。

これらのフレームワークとテンプレートを用いることで、短期間でお客さまのガバナンス構築を支援します。

[サービスプロセス]

日立コンサルティングのフレームワークとテンプレートを用いて、お客様へのヒアリングと打ち合わせを行いながら、RPAガイドラインと規定類(テンプレート)の整備を支援します。

1.現状確認:RPAの検討状況と現状のガバナンスのないようを確認する。

2.RPAガイドライン(全体方針)の初版のまとめ:RPA導入におけるガバナンス方針と対応項目を検討し、RPAガイドライン(全体方針)の初版をまとめる。

3.規定への改定内容検討:規定類への改訂内容を検討し、改定(ドラフト)を作成する。

4.規定への改定内容レビュー:改定(ドラフト版)を確認する。

5.既定の整備:改定した規定類を展開する。

 

[URL]

http://www.hitachiconsulting.co.jp/solution/digital/rpa_governance/index.html

 

 

 

 

 

RPA初めての導入 最初に選ぶべき業務5選

2018.12.05

 

 

 

 

 

 

 

近年、業務の自動化を実現するツールとしてRPA(Robotic Process Automation)が注目を集めています。

 

では、実際に導入を検討しようと検討しているが、どの業務へ導入すれば良いのかわからない、または、導入したが思ったような結果が出なかったというケースが多々見受けられます。

 

本記事では、今後のRPA導入の手助けになるような「最初に選ぶべき業務を5つ」紹介することで、これらの課題の解消に一助出来ればと考えています。

 

 

 

■RPAってたいしたことない?


 

RPAはAIやビックデータと並ぶ、最先端の技術であるという認識が世間ではあるように思います。

 

RPAを使えば、とんでもなく凄いことが出来るという勘違いが要因の1つにあるようです。

 

しかし、RPAはそれ自体がまったく新しい付加価値をわたしたちに提供してくれるものではありません。

あくまでも、個々の業務単位で自動化を手助けしてくれるツールに過ぎないのです。

 

 

その意味では、RPA自体はたいしたことないと言っても過言ではないと考えています。

 

もちろん、基幹システムなど他のシステム、そしてAIなどとの組み合わせにより、大きな革新が生まれる可能性はありますが、これは将来的な話しです。

 

 

現時点では、将来的な全体業務最適化の1部分を担当するツールとしてRPAを捉えるべきです。

 

 

 

■RPA導入は小さく始める


 

前述にて、RPAは「将来的な全体業務最適化の1部分を担当するツール」としましたが、RPA導入当初においては、これをしっかりと見据えることは非常に困難だと言えます。

 

RPA自体、大手企業を中心に導入実例が出始めたばかりであり、まだまだノウハウを積み重ねている発展途上です。このノウハウが結集した結果、当初導入したRPAはレガシー、つまり過去の遺産になってしまう可能性があります。

 

 

これを回避するためには、RPAの導入は「小さく始めること」、後々の全体業務最適化を手探りで進めることが重要です。

幸いなことに、RPAはこれらの要件を兼ね備えたツールです。比較的安い費用でしかも簡単に扱うことが出来るものです。

 

 

 

 

■最初に選ぶべき業務5選の紹介


 

それでは、初めてRPAを導入するにあたり、最初に選ぶべき業務を紹介致します。

 

最初の1歩となることに適した業務であり、ここからRPAを発展させていくことになります。

 

また、RPA導入の結果、人の削減や配置転換など企業内部の仕組みを変える結果となることがあります。

つまり、一定の社内抵抗勢力が存在してしまう結果となる場合があります。

 

その為、削減効果をしっかりと出す業務を選ぶことで社内でのPRAの認知度を高めることが重要です。

 

 

 

単純作業だが作業量及び作業時間の絶対量が多い業務

<例>

〇 売掛などの入金額照合作業

概要:銀行入金情報とExcel上で管理している入金管理表を自動化。

 

 

時間効率の悪い業務

<例>

〇 営業日報の印刷作業

概要:Excelやシステム画面などに表示される営業日報の印刷を自動化。深夜など人がいない時間帯

   に行うことで、印刷機を占領する必要もなくなる。

 

 

業務時間外に発生する業務

<例>

〇 システムエラー発生時のログ収集

概要:システムエラーが発生した時、その対象となるログを自動的に収集して担当者へメール。

 

 

同じ作業が続く業務

<例>

〇 メールでの問い合わせ内容をシステム登録

概要:メールで問い合わせがあった記録を対象システムへ自動的に転載し登録を行う。

 

 

RPAに強い関心を持った担当者の業務

<例>

〇 なし

概要:RPAは万能ツールでは無いため、トライ&エラーで導入を進めるものである。

   その為、RPAに理解や関心がある担当者と取り組むことで最初のRPA導入が容易になる。

 

 

 

 

■初めてのRPA導入における注意点


 

RPAは人間が行っていた業務をそのまま置き換えることが出来るツールです。

 

しかし、予め命令(設定)された動きしか行うことが出来ません

つまり、イレギュラーが発生する可能性が高い、業務に判断を必要とするケースが多くある場合は、RPA導入のハードルになります。

 

それらの情報を全て洗い出して、RPAに命令(設定)をする必要がある為です。

 

 

漏れの無い業務の洗い出しは大きな負担となる上、漏れは必ずと言ってよいほど発生します。

 

それを人間がしっかりと監視してRPAが正しい業務を行っているか確認をする必要があります。

 

とりわけ、導入当初は、RPAの業務結果も含めた全般的なチェックが必要となります。

 

 

 

 

■最初のRPA導入はコンサルタントを活用するべき?


 

RPAの流行とともに、RPA導入を支援する会社が多数生まれました。

 

大手ベンダから中小企業まで様々なRPA導入コンサル事業を行っている企業があります。

 

日本を代表する大手ベンダのRPAコンサルタントに御社の強みは何かと聞いたところ、「現時点ではどのRPAコンサルティング会社も似たようなソリューションしか提供出来ていない。正直なところ、自社での導入が一番の実績。」と言っていた記憶があります。

 

 

これは2017年末頃のことで、2018年は既に状況も変わっているかもしれませんが、RPA導入コンサルタントに過度な期待を寄せることは難しいかもしれません。

 

 

 

しかし、実際問題、RPAを導入して全体業務最適化を図っていきたいといった場合は別です。

一業務を自動化させたいというくらいの要件であればRPAコンサルタントは必要ないかもしれませんが、「他のツールやシステムとの連携を考えたい」「複雑な業務に適用を将来的に考えたい為、RPAを作り込みたい」といった場合は、RPA導入コンサルタントは有効だと言えます。

 

 

とりわけ、業務の洗い出しは自社のみで無く、外部からの客観的な視点が重要と言われている為です。

 

つまり、ゴールをどこに設定するのかという大方針によって、RPA導入コンサルタントの必要性の有無が分かれると考えています。

 

もちろん、そのゴールをどこに設定するのかをRPA導入コンサルタントを活用することで探っていくことも良いと思います。

 

 

 

 

■まとめ


 

RPAを言い換えると、言われたことはしっかりと行うが、珍しいケースや判断を必要とするケースに対応できない真面目な新卒の新入社員のようなものだと言えます。

 

しかし、この新入社員は24時間365日働くことが可能で、なお且つ反抗をすることはありません。

 

この新入社員を今後育てる上で、最初にやらせる業務は何かと考える視点を持つと面白いと思います。

 

 

初めてのRPA導入における選ぶべき業務を中心に書きましたが、既に多くの発展的な導入事例が大企業を中心に存在します。

 

それらの事例を研究しながら自社の要件に合ったRPAを考えていくべきではないでしょうか。

 

つまり、自社のゴールをどこに設定するのかを事前にしっかりとした検討が最重要となります。

 

 

 

 

 

業務改善、目標達成のためのフレームワークとシステムの活用

2018.12.03

 

 

日々の業務にすぐに取り入れることができる、業務改善や目標達成のためのフレームワークを紹介します。

 

 

 

1.6W2H

(1)目的

問題の多面的把握、思考整理

 

 

 

(2)内容

6W2Hは6つのW2つのHの計8つ疑問詞を用いて、物事やテーマ、問題、課題などを多面的な切り口から考察するためのフレームワークです。

 

テーマに対してさまざまな角度から問いを投げかけることで、思考が広がり、それまで気付いていなかった視点を得ることができます。

 

思考を広げた先にあいまいな情報がある場合は、その情報についても考えるきっかけになります。

 

 

 

(3)6W2Hの内容

Who(だれが):人物や組織、役割、グループなど、主語を明らかにする。

 

What(なにを):問題や事象、商品やサービスなど、考察する対象について事実や構造を明らかにする。

 

Whom(だれに):ターゲットや関係人物など、対象者を明らかにする。

 

When(いつ):実行日や納期など、時間軸(期間やタイミング)を検討する。

 

Where(どこで):場所や位置、地理情報やエリアなどを検討する。

 

Why(なぜ):目的や原因、意義や前提条件、狙い、意図を明らかにする。

 

How(どのように):手段やプロセス、方法、手順、構造などを明らかにする。

 

Hom much(いくらで):時間やお金、人材など資源を検討する。

 

 

 

(4)手順

①テーマ(問題)を決める

 

②情報を広げる

テーマに対して、8つの疑問詞のそれぞれに回答しながら思考を広げていきます。

 

 

 

(5)フレームワーク図

 

 

 

 

 

2.ロジックツリー(マインドマップ)

(1)目的

情報の整理、全体像の把握

 

 

 

(2)内容

物事を分解して考えていくことで、全体と部分を網羅的に整理するフレームワークです。

何か問題が起こっている場合、そこには必ず原因が存在します。

 

その問題、あるいは解決策を「因果関係」という切り口で発想を広げていくことにより、より的確で網羅性のある原因リスト、あるいは解決策リストが出来上がります。

その出来上がったリストに優先順位をつけて、実行するものを決めていくことで、限られた時間と資源を有効に配分することができます。

 

 

 

(3)手順

①問題を設定する

ロジックツリーの頂点となる問題を設定します。

 

 

②主な原因を書き出す

設定した問題に対して「なぜ?」を問いかけ、主な原因と考えられる要素を書き出します。大きな分類を把握することがポイントです。

 

 

③原因を細分化する

上記②で書き出した原因に対して、さらに「なぜ?」を問いかけ、各原因を細分化して掘り下げていきます。

視点や論点に偏りがなく、網羅的に情報を書き出せているかがポイントです。

 

 

④ツリーを整理する

情報を出し切ったら、各要素のつながりが理論的であるかどうか、上位概念・下位概念の関係に間違いがないかなどチェックします。

 

 

 

(4)フレームワーク図

 

 

 

 

 

3.オズボーンのチェックリスト

(1)目的

9つの問いを用いて新たな視点を得る、課題解決のためのアイデアを練る

 

 

 

(2)内容

アイデアが浮かばない際に発想する切り口として利用する為のリストです。

9つの問いで新たな視点を得るフレームワークです。テーマに対して新たな問いの視点うぃ得ることができているか、テーマに対する理解が深まっているか、アイデアを発展させる方向性を複数見出すことができているかがポイントになります。

 

 

(3)9つの問いのパターン

転用:転用できないか、他の方法で使えないか、新しい使い道はないか

 

応用:応用できないか、似たようなアイデアはないか、他のアイデアを応用できないか

 

変更:変更できないか、色・形・デザイン・仕様・利用目的・意味付けを変えてみたら

 

拡大:拡大できないか、大きく・高く・長くしたら、付加価値や頻度、割合を高めたら

 

縮小:縮小できないか、小さく薄く、短くしてみたら、機能や情報を減らしたら

 

代用:代用できないか、素材や人、物、場所、方法を代用できないか

 

置換:置換できないか、要素や順序、配置、パーツ、プロセスなどを置き換えたら

 

逆転:逆転できないか、上下や左右、前後、内と外、順序、考え方を逆にしたら

 

結合:結合できないか、セットにしたり、新旧や真逆の要素を組み合わせると

 

 

(4)手順

①テーマを設定する

 

②9つの問いでアイデアを広げる

 

 

(5)フレームワーク図

 

 

 

4.OKR

(1)目的

目標管理、戦略立案、組織開発

 

(2)内容

Objective and Key Result(目標と主な結果)」の略で、企業のチームメンバーそれぞれの目標と期待されている結果を明確にし、組織のオペレーションとコミュニケーションを効率化するためのシステムです。

 

OKRを組織に導入するメリットはいくつかありますが、一番大きなメリットはゴール(目標)を明確にすることによって何にフォーカスするべきなのか、何を無視しても良いのかをクリアにできることです。

 

そして、OKRは会社全体に公表されるのでコミュニケーションの効率化にも繋げることができます。

OKRの定量的な効果測定である目標達成度指標(Key Results)と類似している業績管理手法として、KPI(Key Performance Indicator:重要業績評価指標)が挙げられます。

 

KPIは「最終目標を達成するための必要なプロセスを経過目標」と定義され、それらが適切に実行されているかどうかを順次チェックしていくことで、最終目標を達成していきます。

 

KPIはプロセスチェック、OKRはコミュニケーションの促進が目的となっており、性質が異なります。

 

 

 

(3)手順

①Objective(目標)を決める

Oは次の条件を満たす一つの文とする

 

  • 定性的で人を鼓舞する内容にする
  • 時間的な縛りをつくる(3か月以内。1か月や四半期など)
  • 各チームが独立して実行できるようにする

 

例)イベントを成功させる

 

 

 

②Key Result(主な結果)を決める

KRではOの感覚的な言葉を定量化します。難しいが不可能ではない範囲で1から最大4つのKRを設定します。

例)イベントページUU10,000人 イベント来場者数3,000人 

 

 

 

③OKRの評価

仮に四半期で期間を設定した場合、四半期が終わったら、個人で設定したOKRの達成率を個別に振り返ります。全社メンバーを集めて、チームや部署そして会社全体の達成率を評価します。

 

 

 

(4)図

 

 

 

5.KPT

(1)目的

業務を振り返り、今後のアクションを考える。

 

 

(2)内容

KPT(ケプト、ケーピーティー)とは、「Keep(継続すること)」「Problem(改善すること)」「Try(新たに挑戦すること)」の3つの要素から、現状の業務状況を振り返るフレームワークです。

 

よかったところと悪かったところを整理して今後のアクションを考えます。

 

業務中に個々人が感じている課題や気づきを、チームとしての課題や気づきに変えることが目標です。

週ごと月ごとなど、定期的に実施することが理想です。改善が必要な要素をはっきり書き出せているか、Tryがアクションとして書き出せているかなどがポイントとなります。

 

 

(3)手順

①前回のTryを確認する

 

②継続することを書き出す

前回設定したTryの内容と、現在の業務状況を踏まえて、継続する要素(Keep)を書き出します。よかった点や成功したことが該当します。

 

③改善点を書き出す

改善点(Problem)を書き出します。

 

④新たに挑戦することを書き出す

KeepとProblemを踏まえて、今後新たに挑戦すること(Try)を考えます。

 

 

(4)フレームワーク図

 

 

 

 

 

topへ
© RPA.biz