RPAシナリオを作成するだけであれば然程難しいことではありません。特に、仕事の流れを理解している業務ユーザーが自分の業務を自動化するのであれば猶更です。RPAの難しい点は運用移行後にも安定して動作させ続けることが出来るかなのです。
その他にも多くの理由で、RPAを作成する辞典から考慮してくべき点が多くありますので、その辺りをここではかみ砕いてご説明しています。
RPAロボットをモジュール化・標準化すべき理由
皆さんは、自動車業界で起きている変化をご存知でしょうか？
従来から車台（プラットフォーム）のサイズは全社ほぼ共通で、Dセグメント、Eセグメントなどと、主に欧州メーカーの分類方法だった呼び名が使われてきましたが、完成車メーカーの合従連合もあり車台がほぼ共通設計になってきています。
そして、車台が共通設計になってきたことで、部品も共通化が進み、ある程度組み付けられたモジュールと呼ばれる部品の塊で完成車メーカーの組み立てラインに搬入・組み付けがされます。
こうする利点は非常に多く、同じ部品を大量に仕入れるほうが安価で品質が安定する。部品メーカーも含めて部品在庫を削減でき、開発費用も落とせる。また共通モジュール化することで開発スピードが格段に上げられるなどがあげられます。
この考え方を企業内の業務フローにあてはめると、RPAロボットをモジュール化しておき、使いまわす考え方になり、下記のような多くの利点が考えられます。
再利用性が高まる
RPAロボットをモジュール化して後に記しているカタログ化しておくことで、再利用を促進することに繋がります。再利用する為には、ある程度標準的な構造で、適切な業務フローの切り方をしておく必要があります。
利用頻度が高まる
RPAロボットを再利用できるようにしておくことで、各RPAモジュールの利用頻度が上がることになります。
品質が安定する
利用頻度が高まることで、結果的に各RPAモジュールの品質が向上・安定してきます。
管理・メンテナンス性が良くなる
品質が高いRPAロボットのモジュール化を進め、利用頻度を高めていくと言うことは全体での管理すべきRPAロボットの本数が少なくなります。
結果的に管理・メンテナンス性が向上し、好循環で保守・運用を継続することが可能となっていきます。
モジュール化したRPAロボットを前提に業務プロセスを見直す
人が実施することを前提とした業務フロー
恐らく、現在の殆どの会社は基幹システムや周辺システムを使って人が行うことを前提とした業務フローとなっているかと思います。この事は下記のような多くの問題を含んでいますが、不幸なことに経営者もやっている本人達すらその問題に気付きにくいのが更に問題です。なぜなら、
これらの課題を含んだ業務プロセスで日々業務をやっていると、次第にそのやり方が当然のように思えてくる。その非効率な業務フローに疑問も持たなくなり、単純作業さえやっていれば仕事をしている【単純作業依存症】に陥ってしまうのです。
■ 本来の作業が削られている
最大のビジネス効果を考えた場合に、本来は「こうすべき」、「この手順・作業が必要」と言う業務フローが会社にはあるはずです。
業務プロセスの設計をしていると、その本来の業務（作業手順）を曲げることがしばしばあります。それは、下記のような原因で発生します。
- 手作業では到底不可能な作業量
- 手作業では現実的な時間で終わらない
- 現実的な業務時間帯ではない
- 現場の手作業への抵抗
■ 手作業で可能な作業に縮減されている
もしくは、本来のやるべき作業手順、作業量が手作業で人が行うのに無理が無い作業量、作業項目に減らされていることも同様にあります。
■ インターネットなどを使う事を前提になっていない
本来は、最新のテクノロジーを活用してインターネットを使った情報収取を顧客数分繰り返すなどの業務に変更していくべき業務が旧来のままの業務フローで実施されている。
- 市場価格などの調査・最適化
- 需要に影響を及ぼすような情報の収集
- リスク算定・分散の元情報収集
RPAを前提とした業務フロー
インターネットの通信技術やAI機械学習による異常検知、予測、最適化など日々進化しているにも関わらず、なぜ同じ業務のやり方を繰り返すことに疑問を持たないのでしょうか？
まるで、蒸気機関車が発明され走っているにも関わらず飛脚に手紙を運ばせているようなものです。蒸気機関車で手紙を運んでいる会社や電話・インターネットでメッセージを送っている会社と競争できるわけが有りません。
標準モジュール化したRPAロボットを前提にした業務フローを設計するにはどうしたら良いか、ポイントを挙げておきます。
- モジュール化したRPAロボットを管理台帳・カタログ化しておく
- 現状の業務フローをベースにRPAで代替する業務を選定するのではなく、ゼロベースでRPA化出来る作業部分を先ず確定する
- 「RPAロボットを最大限働かせる為に、その周辺業務を人手でどう補うか」と言う視点を持つ
- 時代に即した最新技術などを取り入れたビジネス効果の最大化を出来る業務フローになっているか
「本当にこの単純作業はやる必要があるのだろうか」と言う意識を持ち、業務は常に改善していく姿勢・意識が重要
変化のないところに進歩はないのです。
RPAロボットモジュールへの分け方
上記にも書きましたが、RPAロボットに関してもある程度纏まった単位の部品（モジュール）のほうが、その機能や使い方を理解し易く扱いやすくなります。
RPAモジュールに分けて設計する場合、下記のような視点を持ってその対象業務の選定や実際の設計を進めて頂ければ良いかと思います。
モジュール化するRPAロボットの単位
■ 周辺システム接続
例えば、ERPなどの基幹システムに対する伝票登録の業務をRPA化しようと考えた場合、その前の業務として他の周辺システムからのデータ抽出やその後のExcelでのデータ加工など一連の業務を１体のRPAにする事も可能かも知れません。
しかし、抽出元システムが複数あったり、抽出したデータのフォーマットが違うような場合はその全てのデータ加工パターンを含めて１体のRPAロボットにしてしまうのは考え直したほうが良い場合もあるかと思います。
この様な場合は、ERPへの伝票登録部分を担当するRPAと、周辺システムからのデータ抽出・加工を担当する複数のRPAロボットの組合せチームワークのほうが、後々の運用・メンテナンス性などを考慮すると適切かも知れないのです。
■ 汎用性を考慮
上記の例の場合、受注伝票などのERPの特定伝票の登録は、かなり汎用的なRPAロボットと言えるかも知れません。通常の会社では店頭販売や代理店販売、ネット直販サイトなど多くの受注の口を持っています。
よって、もしこの様な企業がRPAをモジュール化しようと考えた場合、一連の業務の流れに沿って１体のRPAにするのではなく、むしろ受注する製商品、サービス毎に分けたほうがシンプルになるかも知れません。
なぜなら、受注登録する場合にERP等の受注画面に入力すべき必要項目、内容は製商品やサービス毎に違う可能性が高いと思われます。
■ メンテナンス性を考慮
更に言えば、上記の場合製商品・サービス毎にその受注の一連の流れを通して１体のRPAロボットにする事も可能です。しかし、これをやると、恐らくこの一連の流れを受注の口＊製商品・サービス毎にRPAロボットを１体作成することとなってしまいます。
不可能ではないかも知れませんが、恐らく相当な数のRPAロボットとなってしまうでしょうし、メンテナンスが出来ない状態になってしまうと思われます。
人がやるべき業務
現状の人がやっている業務プロセスの一部をRPAロボットにするのではありません。
- 全体の業務の内、どこの部分をRPAに任せるべきかを先に決める
- RPA化すべきと決めた業務の内、纏められないか（標準モジュール化できないか）と言う視点で見直し、標準RPAロボットの仕様を決定する
- 決定した標準RPAモジュールにどの様なインプット情報が必要なのか、アウトプット情報があるのかを整理する
- 標準RPAロボットで行う作業の前後、もしくは例外処理を整理して人が手作業で行う業務とする
RPAロボットモジュールの管理・統制
RPAをモジュール化し、再利用を促進する為にもロボットのカタログ・リストを作成します。
RPAロボットをカタログ化しておく
RPAロボットのカタログに含めるべき内容は下記のようなものが考えられるかと思います。
■ RPAモジュールの仕様
そのRPAモジュールが何をやるロボットなのか、その目的や処理の概要フロー、インプット情報、アウトプット情報などを整理します。
■ RPAモジュールの入力
そのRPAがどの様な入力情報を想定しているのかを記述しておきます。このインプットがビジネス環境変化などが原因で変わってしまったことが原因でRPAロボットがうまく動作しなくなる場合が多いのです。
- データの形式やテーブル構造であれば項目レイアウト
- インプット値が数値なのか、文字情報なのか
- 数字の場合は桁数や単位
- システム帳票や紙の伝票の場合はそのレイアウトイメージ
■ RPAモジュールの出力
そのRPAが実行後に何をアウトプットするのかを整理し、まとめておきます。
- どの様な値を何処に、どの様な形式で出力するのか
- どのシステム・画面に対して入力処理を実行するのか
■ 起動時間・前後関係
そのRPAモジュールが実行されるには決められた起動時間があったり、他のRPAモジュールとの前後があったりするような場合もあります。従って、この様な点も含めて記述し、後で他の方が見たときにそのRPAモジュールの使い方を理解できるようにしておくべきです。
■ 他のRPAロボとの前提条件
モジュール化したRPAロボが別のRPAの前提になっていたり、内部で使っている変数が別のRPAモジュールで定義されていることを前提にしているような場合には、その前提となる条件を明記しておきます。
そのRPAをモジュール化した時は当然把握しているような事でも、他の方がそのRPAモジュールを使うような場合もありますし、作成した当の本人も時がたち忘れてしまうような場合もありまっすので、やはりこのような点も明記しておくようにしましょう。
■ その他の管理項目
RPAツールにもよりますが、その他に下記のような様々な情報を記述しておくことで後々のメンテナンス性が向上します。
- 内部的に持っている変数
- 待機時間設定
- 使っている機能（部品）
など
RPAモジュールの管理体制を整える
標準モジュール化したRPAロボットは、RPAの動作を監視し運用する組織体制を組んで管理、メンテナンスしていきます。その組織は業務部門の中に設け、業務ユーザーや派遣社員を管理するように管理します。
IT部門では、日常業務の詳細な流れを定義したRPAロボットを管理することは困難と思われ、むしろ、技術的なバックサポートやRPAのソフトウエア的なライセンス管理、RPA展開プロジェクトの計画・推進などに徹します。
