ROMとは？

  ROM

RPAをうまく導入・運用していくための方法論

どんなにRPAツールの出来が良くても、それを導入する方法が間違っていたら役に立ちません。

Blue Prismは、RPA導入・運用に関して独自の方法論も持っています。
かつて、某英国銀行がBlue Prismを導入した際、試行錯誤してまとめあげていった導入・運用のナレッジを体系化したものです。

読者の皆さんが知っている通り、RPAツールは年々増え続けていますが、導入の方法論まで持ち合わせているRPAベンダーはあまりないと思います。

今回はBlue Prism独自のRPA導入・運用方法論であるROM（＝Robotic Operating Model）について説明します。

ROMの目的

企業にRPAが文化として定着すること

下の図は、RPAの導入フェーズを3段階に分けた図です。

初期フェーズRPAの試験運用
拡張・展開フェーズRPA化する業務、対象部署を拡大
成熟フェーズRPAが文化として根付く

ROMを導入する目的は、
なるべく早く、効率的に成熟フェーズまで到達することです。

成熟フェーズは、RPAが企業に文化として根付き、機械的に行える業務をロボットに任せることが当たり前になっている状態です。

そうなれば、企業に付加価値を与えられるビジネスを考える時間が生まれます。
RPAがビジネスの開拓、発展に貢献できるというわけですね。

目の前の業務を自動化するだけで終わらないこと

自身のPC内で業務を自動化すること（巷ではRDA（＝Robotic Desktop Automation）と呼ばれていますが…）で終わらないことが重要なポイントです。

RDAは初期フェーズの段階で卒業し、他業務や部署へ
「自動化できる業務はどんどんRPA化しよう！」
という空気を広めていくこと。これが拡張・展開フェーズと言えます。

その際、拡張・展開していくにあたって、上の図の3つのフェーズがあることを知っていれば、
「初期フェーズの段階でRPAを推進していく体制を整えなければ…！」
という意識になります。

ROMでは、RPAを推進していくための体制についても言及しています。

体制を整える ⇒ 拡大していく ⇒ RPAが文化になる
この流れを作るためには、単に目の前の業務を自動化するだけに留まらず、企業全体に広めていくための仕組みづくりを、ROMを活用して進めていきます。

ROMを構成する7つの要素

ROMは7つの要素で構成されています。

時系列に並び替えると、

  1. ビジョン
  2. 組織
  3. 統制と案件管理
  4. 構築方法論
  5. サービスモデル
  6. スタッフ
  7. テクノロジー

の順に定義する流れとなります。

順に見ていきましょう。

ビジョン

文字通り、業務自動化の目的、戦略です。

  • 生産性を向上させる
  • ヒューマンエラーを減らす
  • ブラックボックス化されている業務を可視化して複数部署に横展開する

など、業務自動化の目的はいろいろあるかと思いますが、
このフェーズでは、まず業務自動化のゴールをはっきりと文面に起こします。

そして、そのゴールを経営層などの利害関係者（＝ステークホルダー）に共有し、
理解してもらうところまでがこのフェーズですべきことです。

ゴール達成の暁、もしくはゴールに向かう過程で
「RPAを導入するとこんな良いことがありますよ！」
というメリットを共有し、多くの人に周知徹底させればさせるほど、
今後のRPA導入がスムーズに進むようになります。

組織

ROMでは、RPAを推進していくための体制を3つのパターンに分けています。

分散型各部署でゲリラ的にRPAを導入する。
他ツールでの、いわゆるRDAはこの型で進めることが多い。
連合型分散型と集中型の混合型だが、企業によって千差万別。
業務部門にどこまで権限委譲するかを決める必要がある。
（例1）開発は業務部門、レビューや管理、インフラ基盤の提供はRPA中心組織
（例2）自動化対象業務のヒアリングは業務部門、開発、管理はRPA中心組織
集中型IT部門など、RPA中心組織がRPAに関わる管理、開発を行う。
ガバナンスを強く利かせたい場合はこの型。

どれが優れているか？ということではなく、
重要なのは、企業の文化や全体戦略、現状に合った体制を選ぶことです。

どの体制にするかによって、
成果物の品質担保のためのガイドラインなど、その他開発に必要なドキュメント、ナレッジの共有方法が変わってきます。

足並み揃わずRPA導入が進んでしまうと、後々メンテが大変になり、
管理コストがどんどん上がっていくので、体制をビシッと決めておくことはとても重要です。

業務部門がしっかり予算を持っていて、開発リソースもある場合は分散型で進めても良いでしょうし、
しっかりと統制を利かせたい場合は集中型で進めたほうが良いでしょう。

どういった体制で業務自動化を進めていきたいのか？
このフェーズでしっかり定めた上で、現段階で組める体制はどれなのか？
はたまた、理想の型で最初から進めていくのか？

分散型⇒集中型など、少しずつ体制を変えていくならば、
ドキュメントやナレッジの共有方法はどうやって変えていくのか？
インフラ基盤はどこをどう変えるのか？などなど…

ビジョンに立ち戻って、諸々判断し、定義していきましょう。
体制がしっかり定まれば、必要な人員数や、どんな人員が必要なのか？
といった具体的な話も進んでいきます。

統制と案件管理

RPA化要件の選定と優先順位付けを行うフェーズです。

単純に削減時間のみを考慮してしまいそうですが、
RPA化にあたって開発工数がどれくらいかかるのか？
人の作業時間は少ないが、ビジネス貢献度は高い業務の場合はどう判断するのか？

など、判断基準を明確にするフェーズでもあります。

最初に定めた「ビジョン」のフェーズで、ゴールが明確化されていれば、
判断も楽にできると思います。

ここで重要なのは、RPA化要件の選定、優先順位付けを
RPA中心組織だけで行うのではなく、現場の担当者なども含めて行うこと。
そういった場を用意して、意思決定を定例化することです。

構築方法論

「統制と案件管理」フェーズで定めた自動化要件を、どういった段階を踏んでプロセスに落とし込んでいくかを考えるフェーズです。

一般的なITシステム開発の場合、
要件定義、設計、開発、運用保守
といった流れに沿って開発を進める、いわゆるウォーターフォールモデルがありますし、アジャイルやスクラム開発など、開発手法は様々です。

Blue Prismでは、ウォーターフォール的にフェーズド（＝段階的）な工程を踏んで進めていくことを推奨しています。

また、段階的に整理するためのドキュメント一式もBlue Prismから提供されています。
※各ドキュメントの説明は割愛します

IPAInitial Process Analysis初期プロセス分析
PDDProcess Definition Documentプロセス定義文書
FRQFunctional Requirement Questionaire機能要件分析
SDDSolution Impact Documentソリューション設計文書
OIDOperation Impact Document運用上の影響に関する文書
PDIProcess Design Instructionプロセス設計書
ODIObject Design Instructionオブジェクト設定手順書

サービスモデル

各プロセスの本番稼働後、運用をどのように行っていくのか定義するフェーズです。

具体的には…

  • ヘルプデスクの体制、人員
  • （操作対象システムの稼働時間に応じた）各プロセスのスケジュール設計
  • 例外の種類による、業務担当者 or インフラ担当者への通知ルール
  • レポーティング（稼働状況、ROIを示す指標の定義など）
  • バックアップ・リストア方式（バックアップ対象データの選定、頻度など）
  • リカバリ方式（障害発生時、関連するコンポーネントのリカバリ手順、方法など）
  • 障害発生時の連絡フロー
  • プロセス、オブジェクトのバグFix手順
  • ログ出力対象と粒度、アーカイブ頻度

などなど…
ルール決めしなければならない内容はたくさんあります。

ROMの構成要素の中でも、後回しにされやすいフェーズですが、
前もって定義しておくと良いです。

スタッフ

どんな人材を必要とするのか、明確に定義するフェーズです。

必要な人材を定義するには、まず役割を決めなければなりません。
ROMの中では、一例として次のような役割分担を挙げています。

  • プロジェクトマネージャー：全体の進捗管理
  • プロセスアナリスト：要件ヒアリング ⇒ 要件定義まで
  • シニアプロセス開発者：概要・詳細設計、レビュアー
  • プロセス開発者：実装、テスト

といったイメージです。

このフェーズでは、それぞれの役割に必要なスキルセットを整理して、
トレーニング手法を確立するフェーズでもあります。

特にプロセスアナリストの育成は時間がかかります。
顧客の業務についてある程度の知見が必要な上、ヒアリングにおいてはBlue Prismに馴染む形で仕様をFixさせるだけの技術的な知見も要求されるからです。

非常に求められるスキルセットが幅広いので、どの企業でも育成には頭を抱えているのが現状のようです。

僕の経験上、プロセス開発者のトレーニング手法は早めに確立させた方が良さそうです。
中途半端な知識であっても、動くプロセスは作れてしまうためです。
各プロセス開発者が思うがまま開発を進めてしまうと、品質を一定に保てず、後々メンテで苦労することになります。

テクノロジー

プロセスを安定稼働させていくためのインフラ基盤設計を行うフェーズです。

「シニアプロセス開発者」は、このフェーズで設計されたインフラをベースに、各プロセスの設計を考えていくことになります。

また、「サービスモデル」と並行して考えていくフェーズでもあるかもしれません。

例えば、

  • 共通オブジェクト化の判断基準
  • 体制に応じたインフラ設計、拡張方式
    ⇒インタラクティブクライアント（IC）、AP/DBサーバー、ランタイムリソース（RR）の全体構成

など、インフラの観点から考えていきます。

ちなみに、Blue Prismとしては、ICやRRは仮想環境を推奨しています。

どういったインフラ構成をとるか、RPA中心組織と情シス（IT部門）ですり合わせながら決めていくことが大切です。

まとめ

ROMとは何か？
ROMを構成している7つの要素について説明してきました。

この説明ですぐにRPA導入が進められるかというと、そんなに簡単にはいかないとは思います。
それぞれの要素において、さらに決めるべきことを深堀りして成果物を定義する必要があります。

また、Blue Prismから提供されているドキュメント等もありますが、
それらがすべての企業にマッチするわけではないと思うので、
自社に合う形にカスタマイズしていくことになると思います。

とはいえ、RPAを推進していく人からすれば、ROMはとても心強い道しるべになることは間違いありません。

言い方は悪いかもしれませんが、ROMを叩き台にして、
自社に合ったRPA導入・運用の方法論を確立させていくと良いと思います。

LEAVE A COMMENT

CAPTCHA