■サイト内検索:
 

RPA Biz > RPA > 【RPA導入のために】推奨する業務システムの作り方

【RPA導入のために】推奨する業務システムの作り方

2018.07.18

業務システムの導入を検討しているみなさんは、

おそらく繁雑で複雑な業務をコンピューターにやらせて楽したい!って想いがあるかと思います。

 

そこで、業務システムを導入する前にやっておいたほうが良いことについて、書きたいと思います。

 

業務システムを作る際のフローは大まかに、以下の工程に分解されます。

 

  1. システム化する作業を整理し、 
  2. その業務のどの部分をシステム化するか検討し、 
  3. どのようなシステムにするか検討して 
  4. 実際に作ります。

 

上記13をお客様の言う通りにシステム化しても何の問題もないように思えます。

 

しかし、その手作業でおこなっている業務に無駄な作業や、実はやらなくてもいい作業が含まれていたらどうでしょう。

 

システム化した際にも同じようにシステムにも無駄が残ります。

 

このような不具合が起こるケースとして2種類あります。

 

  • システムでの処理プロセスを、人間の手作業のプロセスそのままに移管してしまっているケース

 

例えば、RPAのプロジェクトで、何かの情報ソース(Excel等)から、一件一件情報を参照して、システムに入力する作業を自動化するプログラムを組むとします。

 

その場合、人間の既存の作業工程だと、一件Excelから情報を見たら、それをシステムに入力していくことになりますが、

これはロボットの動作ロジックとしては効率的ではありません

 

ロボットで動かす場合、まずExcel等の情報ソースから「全件」情報を取得してしまい、

それを一気にシステムに入力するほうが効率的ですし、ロボットの処理速度も速くなります。

 

このような点は些細なことに思えるかもしれませんが、処理件数が膨大になると致命的な問題になりえます。

 

 

だがしかし、このような処理のプロセスの詳細までは、お客様側としては、差ほど注意をしておらず、結果だけを見る傾向です。

なので、重要なのは、お客様が仕様で伝えたことをそのまま鵜呑みにせずに、

SEの観点からシステム上で動作に適した処理プロセスを提案していくことです。

 

過去に、お客様からの依頼で、既存のシステムの改修を頼まれて、コードを見ることがありますが、

意外とそのような配慮がなく、(プログラム上最適ではなくても)お客様が言った通りの処理ロジックにしてしまっているな、、、という感じを受けることが多々ありました。

 

 

(2)人間側の作業プロセスを頑なとして変えないケース

また、システム開発をしても、人間側の作業は多少なりと残ることになりますが、

その人間側のフローをシステムに合わせて変えるのではなく、今までのやり方を頑なに踏襲してしまうケースもあります。

 

例えば、受付業務に対してRPAを導入するケースで、もともとの既存の業務フローでは、

1件1件訪問者からの申請書類を受付担当が目視チェックし、システムに入力していました。

 

ただ、この業務をRPAで自動化する場合、本来もっとも効率がいいのが、

受付では一旦紙での申請書受領に留め、1日の最後にバッチ処理のようにRPAがOCRをかけてまとめてシステム入力処理をする方法になります。

 

この場合、業務フロー自体の変更が求められるわけですが、お客様側としては、今までのフローを変えるのに抵抗があり、

本来RPAの観点からすると最適なやり方に変えきれないケースが多いです。

 

ただ、それだと本来RPAを含めたシステム導入の目的である、効率化の効果が限定的になってしまいます。

 

このあたりは、システム導入するまでに業務を行う現場側でしっかりと意識合わせをするのが重要なのではないでしょうか。

 

まぁ、お客様がそれで満足するならそれはそれで良いのではありますが。。。。

 

 

しかし、後になってから無駄作業を取り除きたい!となった場合、人に対しては口頭で言えば済みますが、コンピュータは万能ではありませんので、

いったん作ってしまったシステムを修正するには、多くのお金と時間が必要になります

 

 

現在ベンダー経由でシステム構築をされた企業様においも、このような理由で本来必要のなかった改修を行わざるを得なく、多大な改修費用が発生しまったケースをよく聞きます。

 

そこで、システム化する前に業務フローの見直しをしてみましょう!という提案です。

 

少なからず 1.のタイミングで意識しなくても、それっぽい業務フローの見直しは行われるかとは思いますが、改善や効率化とまではいかないのではないでしょうか。

 

改善や効率化を考えた業務フローの見直しは、なかなか難しいし、めんどうですが、システム化を機に取り組むチャンスです。

 

システム化する作業の担当者は、自身の行っている業務がベストだと考えている場合も少なくありませんので、

 開発プロジェクトに参加するSEPGは客観的にロジカルに物事を整理することが得意な人たちですので、

彼らの能力をフルに活用し、業務フローの見直しを行ってみてもいいかもしれませんね。

 

外部の意見も聞きながら業務フローを見直すことで、新しい発見もあるかもしれません。

 

ですが、SEPGはシステムを作ることについてはプロですが、その業務については無知識です。

実際に作業される方がその業務において、プロですから、あくまでも参考程度でしょうけどね。

 

1.の部分で必要な業務の手順を整理出来たら、次は2.のどの部分をシステム化するかです。

 

例えばシステム化対象の作業の、この部分は自動化したほうがいいな、この部分は人の手が入ったほうがスムーズだな、などに切り分けをします。

 

専門用語で1.2.は仕様決めですかね。何を作るか?のフェーズです。

 

次に3.ですが、画面はどういった画面でどのように遷移するや、出力結果を誰々にメールするや、出力結果をほかのシステムに投入する、などどういったことを技術的に検討します。

 

ここではどうやって作るか?のフェーズになりますので、設計のフェーズですね。

 

 

ここまできて、システム化が現実味を帯びてきます。実際に作っていくフェーズですね。

 

本当であれば、1.で、業務フローを見直した後に、手作業による運用を行い、

手順などの検証をしてからシステム化したほうが、リスクも抑えられて、良いシステムができるような気がしますが、

 この後は作りながら、直しながら作っていくことになるでしょう。

 

こうして完成した業務システムをテスト運用していただいて、初めて完成となります。

 

 

こうした業務フローの見直しをせずに、開発した場合、すくなからず、意思疎通がおろそかになり、プロジェクトがうまくいかないことがあります。

 

お客様の頭の中のイメージと実際出来上がったシステムの乖離が大きい場合ですね。

作り手は言われたとおりにもちろん作ります。

でも実際はお客様のイメージとは違う場合があるんですね。

 

こうしたことにならないよう、我々SEは提案するための選択肢を多く持ち、

物事を決定してから作業に取り掛かる必要があるでしょう。

 

ただ、合理的に考えれば、そうなるはずなのですが、実際のシステム開発現場では、

往々にして合理的な判断にならないことが多いのも事実です。

 

それは、しがらみというか、業務を行っている現場の人たちが本質的に「変化」を忌避する性向があるからです。

合理的に正しかろうが、間違っていようが関係なく、今までの自分のやり方を変えたくない

今のやり方がベストプラクティスだ、、、そういう偏見をもともと持っているのだと思います。

 

 

高いお金と時間をかけて開発する業務システムです。

無駄の少ないシステムを作ったほうが、発注側も受注側もお得なのではないでしょうか。

 

 

 

topへ
© RPA.biz