目次

RPA導入が業務部門主導で行われることが多い理由

日本でもここ数年、RPAを導入する企業が相次いでいます。しかし、狙い通りにうまくいく企業だけでなく、中には失敗といえるようなケースも散見されます。その理由は一概には言えませんが、失敗した企業で多く見られるのが、業務部門と情シス部門の連携がスムーズではないことです。多くの場合、業務効率化を実現するためにRPAの導入が進められますが、RPAの性質上、業務部門が主導することが少なくないことがその背景にはあります。RPA導入が業務部門主導となるのには、以下のような事情が挙げられます。

多くは、高度なプログラミング技術が不要、業務担当者が容易に使えることを謳っている

各社から提供されているRPAツールの多くが、『プログラミングの専門的な知識を持たない業務担当者でも、容易に使用可能』という点を強調しています。RPAを業務に活用するには、その業務を代替するためのルール設定をおこなう必要がありますが、このルール設定はプログラミング言語を記述せずとも、GUIベースで可能なものがあります。このような特徴を持つツールだと、情シス部門に頼らず導入することができます。

初期導入においては、社内システムとの連携を考慮しないことが多い

RPAツールは、段階的に導入を進めるのが一般的です。最近は、本格的な導入の前に、概念実証(PoC)をおこなうケースが増えています。スモールスタートで始め、その成果を確認してから、順次適用業務や部署を拡大していくのがRPA導入の王道です。そのため、初期導入においては、特定部署の特定業務のみRPAを適用し、社内の他システムとの連携を十分に考慮しないケースが少なくありません。社内の他システムと連携する場合、そのシステムの運用保守を担当している情シス部門に協力を仰ぐことになりますが、スモールスタートの初期段階においては、他部門に負荷をかけない範囲にとどめる場合もあります。

RPAツールの導入に情シスが協力的でない

RPAツールは主に通常・定型業務の効率化を狙って導入されるものなので、業務部門にとっては救世主的な存在といえます。一方、情シスの立場では自分たちの運用保守の範囲が広がるだけというネガティブな認識を持っていることもあり、その場合RPA導入に対して消極的な反応になることがあります。

RPA導入が業務部門主導で行われることが多い理由

情報システム部門がRPA導入に乗り気でない理由

最近は、情シスの担当者の間でもRPAへの理解が進み、RPA導入を情シスが積極的にサポートするようなケースも増えつつあります。しかし、RPA導入に対して、情シス部門が消極的な反応を示すことはまだ少なからず見受けられます。その理由としては、以下のようなことが考えられます。

RPAに対する誤解

RPAツールに対する理解が浅く、単なるマクロやスクレイピングで構成されていると捉えていることがあり、ツールを導入・活用すること自体にマイナスな先入観を持っていることもあります。

RPA導入後、サポートを求められる

RPAを導入すると、ツール利用者からRPAの使い方に関する問い合わせやトラブル時のサポートを求められるようになり、それなりの時間をとられてしまうと懸念している場合があります。

RPAのルールメンテナンスも担当範囲となってしまう

RPAのルールは、さまざまなことが原因でメンテナンスが必要になってしまうことがあります。しかし、情シス部門がそのメンテナンスを担当することになると、本来の業務が圧迫されてしまうことを危惧する場合もあります。

RPA導入は情報システム部門にもメリットがある

全社的なITリテラシーが向上する

RPAを導入すると、業務の流れが可視化され、ルールの作成にも関わることになるので、全社的なITリテラシーの向上が期待できます。その結果、情シス部門に対する社員からのサポート依頼が減る可能性もあり、さらに社員のITリテラシーが向上することで情報セキュリティへの関心も高まり、セキュリティリスクの軽減も見込めます。

情シスの存在価値が上がる

RPAを導入すると、業務部門の現場と情シス部門とのコミュニケーションが密になります。そのため、従来はあまり目立たない裏方的な存在であった情シス部門も、社内におけるプレゼンスや価値が上がります。

RPA導入は情報システム部門にもメリットがある

RPA導入には情報システム部門が積極的に関わるべき

RPA導入に対して、情シス部門が懐疑的、あるいは非協力的な立場を取っていると、RPA導入プロジェクトそのものが進展しない、あるいは頓挫してしまう可能性が高くなってしまいます。特に、PoCおよび限定的な導入において成果が出たことで、スケールアップして全社展開するような場合は、やはり情シス部門の協力は必要不可欠です。

RPAのルールは、基盤となるアプリケーションのバージョンにも影響を受けます。例えば、よくある事例として、Excelでの業務を自動化するというものがありますが、ExcelのアップデートでUIの一部が変更されてしまうと、そのままのルールでは正常に動作しなくなるため、修正作業が必要となります。また、社内システムや連携する他のアプリケーションの更新も同様です。そのため、基盤アプリケーションのバージョンアップを管理する情シス部門と密に連携をとり、RPAツールのルール修正もスケジュールに加味し、アプリケーションのバージョンアップ計画を進める必要があります。また、RPA導入後の運用保守についても、ITに関する専門家集団である情シス部門が中心となって対応するのが本来のあり方だといえるでしょう。

RPA導入では、業務部門単独で導入計画を進めるのではなく、業務部門と情シス部門が密に連携が成功のカギです。関連するすべての部門から人材を集めて、RPAを推進・運用する専門チームを立ち上げることが理想ですが、そこまでいかずとも、RPA導入・運用にコミットする情シス側の担当者をチームに参加させておくことが望ましいといえるでしょう。

RPA導入に情シス部門が適切に関与することで、業務効率化の可能性はさらに広がります。その一方で、業務の適用範囲が広がり、情シス部門の業務量が増大してしまう可能性も否めません。したがって、RPA導入にあたっては、関連するスキルあるいは実績を持つ人材採用の必要性や、情シス部門の貢献に対する適切な評価を、経営陣に訴えていくべきです。

さいごに

中堅・中小企業などの規模では、RPAの運用保守に割くだけの人的リソースがないという場合もあるかもしれません。こうした場合、RPAの導入段階だけでなく、その後の運用保守サービスも提供しているベンダーに協力を依頼することも、選択肢として考えてみるといいかもしれません。運用保守を外部にアウトソースすることで、RPAを活用した本業に注力できるため、中小企業でもRPAのメリットを最大限に得られるようになります。RPAで得られるメリットはコストに反映されるものだけでなく、従業員のモチベーションなど可視化しづらい部分にも及びます。コストにとらわれ過ぎず、総合的な視点でどうすべきか判断してみてはいかがでしょうか。