安定性と効果を最大化させる包括的なプロジェクト導入方法論

今回はプロジェクトを安定させ、継続して効果を上げるための運用方法論を解説します。プロジェクトがうまくいかない理由の多くは、ロボットが止まる、現場にロボット開発と運用を任せたため情報漏洩の発生、基幹システムに負荷をかけて基幹業務に影響を与えてしまう、ロボット修正の工数や管理負荷が増えてしまうなど、まさに安定性の課題と効果に関するものがほとんどです。

すでに安定稼働させるための仕組みや開発工数、管理負荷を抑えるためのアーキテクチャについて解説しましたが、今回はもっと広くプロジェクト全体にわたって安定化と効果最大化を考えるための包括的なフレームワークで解説します。Blue Prism の包括的な導入方法論は、Robotic Operating Modelと呼ばれ、運用で利用されています。以下にあるように7 つの要素で構成されるフレームワークです。概要はこちらでも参照いただけます。

• ROM(Robotic Operating Model)の概要

ビジョン

まずプロジェクトにはビジョンが必要です。RPAの 導入により達成するゴールは何なのか？業務改革で生産性を上げるのか、オペレーションの削減や安定化を狙うのか、属人化した業務のブラックボックスを可視化するためか、など、組織によって異なりますが、重要なのはビジョンを明確にすることです。

ビジョンを明確にし、各ステークホルダーとベネフィットを共有することで大きな推進力が生まれます。特に経営層に周知してコミットを得ることは、非常に重要です。また、どの業務を自動化すべきかについて、優先順位を決める際にはビジョンが重要な基準として機能します。

組織

プロジェクトを強く推進するためには、組織体制も深く考えることが必要です。また、どんな組織体制にするかについては、企業の文化や戦略と合致するものを選択することがポイントです。例えば、現場主導で開発と運用を行う「分散型」はビジネスを把握している現場が比較的自由にロボットを活用します。

一方、各現場部門から自動化業務を募り、IT部門や経営企画部門が推進の基盤組織を形成した上で開発やサービス提供まで含めて運用する「集中型」、そして「連合型」は開発を現場に任せつつ、中央にいる推進組織がレビューし、自動化部品を提供することでガバナンスを効かせます。

分散型は、ガバナンスは弱いものの、開発及び運用でリソース不足は起きにくくなります。また、集中型は組織全体としてガバナンスを効かせたり、ノウハウ共有を容易にしたりしますが、開発および運用でリソースが枯渇する可能性があります。ガバナンスとリソースのバランスを考えたのが連合型です。

これらが基本の3パターンですが、現場と中央の分担の線引きが多少異なるケースもあります。加えて、中長期的なロードマップを描き、体制を進化させるという柔軟性も必要です。例えば、適用範囲の広がりに伴いガバナンスを効かせるために分散型から集中型へ変更、といったように最適な体制はフェーズによっても変動します。

統制と案件整理

これは自動化ニーズを抽出して優先順位付けをするプロセスです。トップダウンで検討されるもの、各現場の要望を吸い上げるものと、大きく二つの方法で拾い上げます。それぞれのニーズを実現するための方法を洗い出し、難易度、必要な時間および工数についても整理します。

その上で、ビジョンに立ち返って優先度を判断するという流れになります。改めて、ここでの判断にビジョンの定義が重要になるわけです。例えば、中長期的に開発効率を重視するのか、ビジネスへの効果を最大化することに重点を置くのかなど、見えないビジネス効果をいかに定量化していくかも適切に優先度をつける上で重要です。

また、現場の責任者を含め幅広いステークホルダーと意思決定を定期的に行うことで、得られた効果や優先度判断基準を全社へ共有・波及させ、さらなる自動化ニーズの掘り起こしを推進します。

構築方法論

ここは業務を実際にどんな手順で自動化に落とし込むのかというプロセスです。ここでは各プロセスをフェーズに分けた上で、明確なルールのもとで運用をすることが肝となります。Blue Prismが推奨しているのは、全体をフェーズ(要件定義、設計、構築テスト、ユーザ受け入れテスト、構築)にわけて、それぞれのフェーズの完了クライテリアを明確に定義します。

例えば、設計のフェーズの成果物の定義は何か。どのような情報を必要なインプットとして定義するのか、何をどのレベルまで落とし込んで文章化することが必要なのか (最低限記載する内容)といったことを、明確にすることが重要です。

また、誰が書いて、誰が承認したのかといった履歴情報も管理し、変更があった場合は更新する手順など含めて定義します。組織・プロジェクトにあったものをテンプレートとして採用し、運用することをお勧めします。プロジェクトでは引継ぎや外部委託などが頻繁にありますので情報の受け渡しの基準を作ることは非常に重要です。このように品質を担保しておくことは、安定したプロジェクト運用・成果の実現に大きさに影響が出ます。

サービスモデル

これは、RPA 推進チームが本番稼働後、どうやってサポートするかを体系立てて定義することです。トラブルがあった場合の原因を切り分ける作業や製品サポートへの問い合わせ、自動化部品の改変など、その手順を定義します。

また、作成したプロセスをどのタイミングでリリースするかといったスケジュールや、レポーティングとして必要な情報は何かなど、詳細な定義もなされるべきです。

スタッフ

これはRPA 推進組織がどんな人材や役割を必要とするかを定義するものです。小さなプロジェクトは少人数ですべてをやり切ることもあります。ただし、役割ごとに何を実施するのか定義しておくことは重要です。

必要なスキルが不明瞭になったり、組織が拡大した場合や分業が必要になったりした場合、また引継ぎの際にも非常に重要となります。さらに各役割に必要なスキルセットは、どのような手順で習得できるか、どのようなトレーニングパスでその役割を任せられるのかなども、検討する必要があります。

これらは、最終的に成果物の質に大きな差を生み、運用の安定性や効果に大きなインパクトを及ぼします。Blue PrismのROMの中でも役割を明確に分けていますが、1つポイントとなる役割を挙げるとすると、プロセスアナリストになります。

この役割は、要件定義フェーズで要件を集めて文書に落とし込むことです。従って、業務とRPAの両方に熟知している必要があり、育成には時間がかかる傾向にあります。また、開発経験を積んだシニア開発者は、共通部品の使い方や運用保守を効率化するためのプロセス検討や、拡張時における設計やレビューに重点をおき、実際の開発は、一般開発者に任せるといった分業を推奨しています。

テクノロジー

これは構築の際のインフラストラクチャを考える部分です。インフラストラクチャは、中長期的な視点や柔軟性を取り入れたデザインが必要です。スモールスタートなら1台の機器でスタートしても構いませんが、しばらくすると自動化範囲を拡張したり、共通部品を増やす仕組みを整えたり、分散型から集中型に移行したりするなど、さまざまな変更が発生します。

そこでスムーズかつコストを抑えて変更ができるように、インフラストラクチャのあるべき姿を考えておくことは重要です。例えば、簡単に自動化の能力を拡張・縮小できるように、あらかじめインフラストラクチャ全体を仮想化テクノロジーを使って構築するといった具合です。予算やロードマップの観点を踏まえつつ、IT部門が責任をもってインフラストラクチャのデザインを考えることも必要なポイントです。

まとめ

RPA 導入は業務部門だけでも、ITや企画だけで考えて運用しても大きな成果を得にくいことが、経験上わかっています。業務部門、ITや企画部門、そして経営層を巻き込んだ上でビジョン策定からインフラデザインまで包括的にカバーしながら、RPAを導入しないと大きな成果を出すことはできません。

組織全体で考え、One Teamで機能するための体制とフレームワークが必要であり、その方法論がROMです。同時に、この各プロセスで定義したものは安定した運用にもつながっていきます。このROMを活用することで、RPA導入の目的を組織全体で共有し、安定運用と成果を実現しがら、業務改善が自然と実施される文化の醸成まで推進できるとベストです。

抜けもれなく最短距離でこの文化に到達するための答えは、この ROM にあります。 次回は、ビジネス環境の変化に対し柔軟にプロセス変革し競争優位を実現するために RPA に求められるポイントについて整理します。