■サイト内検索:
 

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

事例から見る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ソフトはオフィシャルで推奨するドキュメントフォーマットもある。

 

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

 

 

 

 

 

 

topへ
© RPA.biz