「失敗しないRPA」のススメ 導入・運用で注意すべきポイントは？：特集・RPAで仕事が変わる（2/6 ページ）

[小林啓倫，ITmedia]

　そこで次に目を向けられるのがCの領域。部門間やチーム間で似たような業務を行っているにもかかわらず、微妙な差異があるために、その差異を人間が作業することで吸収しているケースだ。作業する時期や関係する第三者（ベンダーや顧客など）などが影響している場合もある。

　この場合、差異を残したままではRPA化が難しい。しかし部門間の意見を調整して作業手順を一本化したり、ベンダーに依頼してドキュメントのフォーマットを整理したりすることができれば、1つの定型業務としてまとめられる。つまり、C領域にある業務をB領域に移すことでRPA導入を進めるのである。

　ただこれは大掛かりなBPR（Business Process Re-engineering、業務プロセスの再設計）につながる可能性が高く、RPA導入プロジェクトの期間が大幅に伸びてしまうというデメリットが発生する。一方でそうしたBPRの効果が（結果として）得られる点をメリットとも捉えられるので、まさに「自社では何をRPA導入の目標に設定するのか」が問われることになる。

　最後のD領域は、従業員個人が自分なりのやり方で処理している業務だ。従来であればマクロを組むなどして、各人が独自に効率化を進めていた領域である。ここをターゲットとしたRPA製品も存在し、まさに「マクロの延長線上にあるもの」として導入される場合がある。また全社プロジェクトとしてA〜C領域でRPA導入を進めつつ、各部門の判断で独自にD領域に対応するRPA製品を購入する、という例も出ている。

その2： 「部門横断」の組織づくり

　ここから先は、設定した目標によって話が異なってくるが、主にB領域とC領域でのRPA活用を目標としたプロジェクトを念頭に置いていると考えてほしい。

　RPAは特定の業務に導入して終わりではなく、効果検証のためのプロジェクトや先行導入プロジェクトが終われば、そこからさらにRPA適用範囲を広げていくための活動が始まる。

　また後述するように、RPAは導入後のメンテナンス（操作対象のシステムが更新された場合の対応など）が欠かせない。最近はRPAを管轄する専任組織をつくり、管理業務の運営やノウハウの蓄積を行う企業も増えている。

　細かな組織の在り方や役割分担などは企業ごとに異なるため、ここでは具体的な解説は控えたい。ただこうした専任組織には、いわゆる「CoE」（Center of Excellence）＝部門横断型の組織形態を取ることが多い。

　理由は簡単で、RPA導入・運用に関する知見や役割は、会社内で分散する傾向があるためだ。営業部門と経理部門が社内システムを使って行う業務をRPA化したいとなれば、両部門と社内システムを管理するIT部門とで、調整と情報共有が必要になる。開発を外注せず自社でまかなう場合は、開発者の管理も必要になる。この場合、ノウハウや人材を組織横断で活用できれば、RPAの導入・運用を効率的に行うことができるというわけだ。

　こうした組織体制をどこまで設計できるかによって、RPAの成否は大きく左右される。しかし、組織は設計図を描いたら明日その体制が実現するというものではない。場合によっては社内の手続きや根回し、人材の調達・育成にシステム開発以上の時間が要求されることになる。

　従って、「RPAの検討を始めたばかりで組織の話など必要ない」と思うのではなく、早い段階から組織体制の検討を進めておきたい。