電機大手の「RPA」推進チームが、事業部門のRPA導入要請をあえて断った理由：Schneider Electricが直面したRPA導入の障壁

　RPAへの取り組みは、Schneider Electricが進めるデジタルトランスフォーメーション（DX）の一部になっている。同社のRPA初期導入の成功は、2019年7月1日時点で社内に170個のソフトウェアロボットを実稼働させるという成果につながっている。これらのソフトウェアロボットのうち大半（100個強）は中国に配置されている。

　Schneider Electricは、現在Blue PrismとUiPathのRPA製品を使用している。ハッケンソン氏によると、両製品はよく似ているが、同社は双方の比較を続けているという。これまでのところ同社は、RPAのソフトウェアロボットを顧客サービスセンターや財務、人事、サプライチェーンの部門に導入済みだ。

　ハッケンソン氏は、当初2019年7月1日までに220個を超えるソフトウェアロボットを導入したいと考えていた。目標まで導入数が伸びなかった原因の一つは、事業部門からの導入の提案を、RPA導入チームが拒否したケースがあったことだ。Schneider ElectricのRPA導入チームは同社のIT部門に属している。同チームは、事業部門の責任者から提出されたRPAの導入依頼を検討し、ソフトウェアロボットを作成することを主に担当している。同チームが拒否した提案は承認した提案よりも多いとハッケンソン氏は話す。

　「RPA導入チームは、単にサイロ化したプロセスをRPAで自動化したいわけではない。プロセス全体を通して無駄や手間を削減したいと考えている」とハッケンソン氏は言う。そのため自動化したいと考えているプロセスが根本的に機能していない場合や、十分な変革の可能性を示せない場合、RPA導入チームはRPAの導入を拒否する可能性がある。

　RPA導入チームは事業部門に対して、RPAに適した業務プロセスの組み立て方や、最善の利用方法についてのトレーニングを始めた。「このトレーニングを始めてから、承認されるRPAの導入提案が大幅に増えた」とハッケンソン氏は説明する。ただし同チームは、さらなるRPAへの理解が必要だと考えている。

　社内のRPA普及におけるもう一つの問題は、ソフトウェアロボットのパフォーマンスに対する期待値を設定することだ。承認を経て実導入したソフトウェアロボットでも、その全てが想定した目標を達成できているわけではない。こうしたケースではRPA導入チームがソフトウェアロボットの一部を一時停止し、再検討している。

　例えばSchneider Electricがコールセンターに導入したソフトウェアロボットは、当初フルタイムの正社員5人分の問い合わせ業務を肩代わりし、その正社員をもっと価値の高い業務に振り向けることを目的としていた。しかしこのソフトウェアロボットの初期導入では、2人分の業務時間しか削減できなかった。

　「RPA導入チームは、導入作業が1回で終わりではなく、反復するプロセスであることを学んでいる」とハッケンソン氏は話す。同氏は、事業部門は労働力削減の目標値を見直す必要があると指摘。その上で目標値に達するためには「業務プロセスとソフトウェアロボットの導入方法を再検討しなければならない」と注意を促す。

RPAの導入速度の向上

　業務プロセスの担当者にソフトウェアロボットを迅速に引き渡すことが、RPA導入チームの目標だ。現時点では、ソフトウェアロボットの開発に約4週間を要している。チームの目標はこれを2～3週間に短縮することだとハッケンソン氏は話す。

　RPA導入チームがソフトウェアロボットを事業部門に引き渡すと、通常は事業部門内の導入担当者が4～8週間をかけてそのソフトウェアロボットの導入作業をする。ハッケンソン氏によると、RPA導入チームはソフトウェアロボットの導入作業がこのように長引く理由を調査しているという。推測できる原因の一つは、自動化によって変わる業務内容を、従業員が受け入れるための時間にある。

　事業部門がソフトウェアロボットの本格的な利用を始めるまでの時間を大幅に短縮する可能性があるのは、チェンジマネジメント（組織の業務変革を進めるための手法）を取り入れた従業員教育だとハッケンソン氏は信じている。同氏は、事業部門でのソフトウェアロボットの受け入れ作業を2週間以内に短縮したい考えだ。

　RPAによる自動化にはさまざまな課題がある。それでもハッケンソン氏は成功を確信し、取り組みを進める。