業務改革、改善の中で(その1:RPA)

久しぶりの投稿になります。

今日は業務改革について。

昨今、昔からあるERPを軸に様々な業務ツールが販売されてきました。

また、世界各国で少しずつ浸透してきたコンピューティング技術のお陰で、人の動作や入力パターンを記憶し再生するRPA(Robotics Process Automation)ソフトや、IoT(Internet of Things)やIoH(Internet of Human)などで発生する事象を観測するハードウェア、それらを分析するデータ分析ソフトウェア、そして何よりAIと呼ばれる各技術群。

さて、今日はそんな様々な技術の中でRPAについて語ります。

RPAとは

RPAは前述の通り、人に成り代わってルーチンワークを回してくれる、パソコン上のロボットです。

RPAの第一歩

業務改革の中で、一番RPAで手をつけやすいのは、ルーチンワークで入力を行う、俗に言うパンチング作業ですね。

定型の書類に書かれている内容を、所定の場所に入力して保存なりシステムに処理をかける作業です。

パンチング作業の流れは簡単です。

「文字を読む」「入力する」「確認する」、この3工程をひたすら繰り返しています。

今までの作業と問題点

さて、今までのパンチング作業はこうでした。

「社員にやらせるには社員の時間が勿体無いから、請負にさせよう。そしたら社員を一人雇う金の70%で済む」

中間管理職は特にこういう方向に走りがちです。

これの非効率な点に気づいてないんです。

何が非効率か。

検品

です。

(人を使ってる時点で非効率、なんて身も蓋もないツッコミは無しで。その思考に至ってる人は既に問題解決に挑戦も苦労もされてますから読む必要が多分ないです…)

単純とはいえ入力するデータは仕事に必要なデータ。

間違ったデータを使えば当然間違った結果が出ます。

自分でやってれば自分を責めて済むのでいいです、任せてた場合はどうでしょう？

任せて、やらせて受け取ったデータ、それを使って間違った答えから仕事を進めて、トラブルが起きた時に振り返ったら…

「打ってもらったデータが間違ってた！」

こんな経験ありませんか？

間違ってたことを責めようにも、基本的に検収済みであれば「内容に問題なし」として受け取ったと見なされるので、責められないケースが多いのが事実です。

もしそこで頑なに責めた場合、パワハラや下請法違反として法的に罰せられるケースがありえますね。

そんな経験をしてしまうと、次から周りが信用出来ないのでちゃんと検品するようになります。

そして、最終的に自分がやった方が早い、という結論に至ります。

それでは本末転倒。

もう一つのアプローチもあります、それは作業手順の見直し。

間違うなら対策を、といってプロセスを変えにかかります。

検査記録をつけさせる、という手もありますね。

確かに有効打かもしれません。

ただこちらにも致命的欠陥があります。

手順を変えても人がやる作業。

見間違い、打ち間違いを0には出来ません。

また、プロセスを変える事を検討する時間、新しいプロセスを教育する時間が必要ですよね。

検査工程を増やせば、社員がやろうが依頼先がやろうが時間がかかるので当然工数が増えてこちら本末転倒。

それがトラブル起きる度に繰り返されるんだから、そりゃあ効果出ませんよ。

さて、ここまでで何が必要かうっすら分かったんではないでしょうか？

問題点で要求されている目的とは

検品の話題、これは入力前後のデータ照合作業が目的です。

プロセスを変える、これは失敗を繰り返しにくいプロセスを作り込むことが目的です。

目的が満たされないから自分で満たす、では満足出来るはずもありません、楽にもなりません。

 

目的から見える解決策

では解決策を考えてみましょう。

検品、これは「見る」「比べる」という手段があればいいので、元データがデータ同士の場合、DBのように複数のデータを集約したり、比較したりというのはSQLやExcelの関数などでも可能ですね。

昔から機械プログラムの差分チェックとかにWinMergeみたいなフリーソフト使ってる人もいるんじゃないでしょうか、今知った人は是非調べて見てください。

知らないって怖い。

さて、紙の場合は「見る」って行為が電子的ではないのがネックです。

そこで使われるのがスキャンした紙の画像ファイルから、文字を認識するOCRであったりするわけです。

ただ、一つ問題があってOCRの認識率は100%ではありません。

いくらいいものでも98%だの99.2%だの、と言われます。

 自身でもMoneyFowardさんの家計簿アプリを使っていて、OCRは日常的に触れるのですが、光の当たり方、レシートに入った傷、赤帯、書式の違いなどで結構ミスがあります。

ただ、正しく修正されたデータと取り込んだ元の値とを比較すれば当然どういう所が間違いやすく、正しく直すべきパターンにこれがある、というのを機械学習させることは可能です。

まだまだこれからの部分ではありますけど。

それでも一言一句見直していくことを考えれば、かなり短縮出来ます。

次にプロセス改修

プロセスを直すにあたり、まずフローが必要です。

業務フローが出来れば次にするのは、起きた問題、起きる問題がないかの洗い出し。

リスク回避を考えます。

次にそのフローを見せながら、新人や他部署の人間にやらせてみます。テスト運用のモデルケースになってもらうわけです。

回避してたはずの問題や見落としてた問題が発生する可能性を見ます。

導入にかかる前に

さて、ここまで出来ればRPAは比較的簡単です。

(簡単、といってもエンジニアの作業は簡単ではないですが…)

OCRを使って防ぐなら…

表比較したら…

業務フローはこうか…

他の手段で解決出来ないフローか

合格率の閾値をどこまで設けるか…

仕様が見えてくるわけです。

要件定義と呼ばれる内容を、さっき述べたことで大方しているわけです。

もちろんシステム開発をするところに投げるにあたり、ユーザーの思う言葉がエンジニアには理解出来ない可能性がありますが、その為に上流工程で要件定義をしっかりします。

RPA導入までの時間短縮は、他の事業の成功例と同じです。

自分達が何をしたいか、どういう風にしているか、何が材料としてあるか、何に困っているか、何が問題か、をハッキリさせておくことです。

それがあれば要件定義の時間は然程かかりません、ただ人の操作を置き換えるだけなので。

あとは詳細の調整をしていくだけなので金額変動も少ないです。

上記が守れてないと

逆にハッキリしていないと、

管理者「改善だ！RPA入れたい！」

担当者「業者いくつか連れてきました」

管理者「値段ピンキリだなぁ、ここでいいか」

業者「どの作業を自動化したいんですか？どういう風に処理されているか分かればこの値段と技術でいけますが…」

管理者「えっ？この仕事なんだけど…」

業者「やり方どうされてます？必要なインプットとアウトプット、どういう風に処理されてます？」

管理者「担当者くん、これ普段どうやってんの？」

担当者「あー、こんな流れなんですけど、本来のルールはこうで、勝手が悪いから今はこうやるんですけど、関係部署のあそこはやり方合わせてくれないからやり方が昔のままなんですよね。あっ、でもこうしてくるケースもあったかも」

業者「…それだと、作業分析からになるので…これくらいの値段に…」

管理者「えっ、そんなに高くなるの…無理じゃないか…」

というように要件定義する時点になって断念してしまうケースもあります。

従来のシステム導入との違い

RPAも、従来のシステム・ソフトウエアと根本的に違いはありません。

使う技術が少し違うだけで、人のやってた事を機械にさせる為に、人の動きを知る必要があります。

RPA導入を考えている方や悩んでいる方は、上記を参考にして、まずは自分達の仕事を明確にしてみてください。

改善の一歩はそこからです、技術は人が使うものであって、人が技術に悩まされ遊ばれるべきものではありません。

長くなりましたが、業務改善は体力と資金力が物をいいます。

経営者の方は、そこを考えて指示してあげてください。