2018.11.26
ご存知のとおり、RPAの大きい特徴としては明確なルールがり、かつ大量重複な作業に向いていると言わている。
また、ソフトによっても異なるが、導入時が発生する導入費用やランニングコストがあるため、当然RPAの作業量が多ければ多いほど費用対効果が優れるだろう。
そのため、現在多くの大中企業が積極的にRPAを導入しようとし、RPAのメリットを最大限活用しようとしている。
勿論、RPAの導入により、大中企業の場合特にインパクトが大きいが、大中企業の特性により、RPA導入時が起こるかもしれないトラブルもある。
今回のコラムでは、ある大企業がRPA導入にあたって起きているトラブルを紹介し、読者の参考になれればと思う。
今回事例となった企業は日本国内の大手企業A社だ。
業員数は約15,000人を超え、ITのメイン業務以外、金融などにも進出している総合グループだ。
この規模になると、当然RPAに向いている業務はたくさんある。
例えば、A社社内に複数の情報を確認システムが使われているため、特定の業務を遂行するためにシステム間のデータ交換が頻繁に発生する。
また、各グループ会社から特定な情報を集めて、集中て処理結果したりする業務もたくさんある。
これらの業務は今まですべて従業員がマニュアルで行っているが、すべてRPA化の良い業務だとA社が判断し、今年から全社範囲の大規模RPAプロジェクトを始めた。
しかし、プロジェクト組織体制のところでトラブルが起きた。
A社のRPAプロジェクトの組織体制がとても複雑な事になっている。
プロジェクトを担当するのは社内のIT部門になっているが、表1をご覧になると、IT部門以外に、とにかく色んな会社がこのRPAプロジェクトに関わっていることがわかる。
それぞれの役割を簡単に説明する。
RPAソフト選定するために、B社のコンサルティングを受けた。
RPAソフトを選定後、導入がよりスムーズにできるのと社内IT部門がRPAソフトを取得するためにC社と契約し、顧問を入れた。
そして、開発目標業務の選定やヒアリングなどは極めて工数がかかる業務なので、元々契約していたB社と社内IT部門以外、D社とE社と契約し、業務ヒアリングを入れた。
ヒアリングのあと、如何でRPAを開発するかというRPA開発設計をする必要があるが、A社内にリソースがないため、B社とE社が担当するとなった。
最後の開発段階だが、B社がヒアリング、設計をした業務を自らのチームで開発をしている。
それ以外は元々C社の指導を受けて、自社IT部門が開発するという方針だったが、社内IT部門のトレーニングスピードが遅くかつリソースが足りないため、単価の安い海外F社にアウトソーシングしている。
ただし、F社は選択されたRPAソフトの開発経験が足りないため、C社の指導のもとで開発をしている。
ここで、まずとして、外部からの組織が多い。
もちろん、一つの会社にすべての段階をサポートしてもらうのが良いが、様々な原因があって、特に大企業の場合、実際複数の外部会社と契約している場合も多い。
複数と会社と契約するほうがコストが安い場合もある。
A社の大きい問題点は複数の会社と契約していることではなく、これらの会社を統括できていないところにある。
B社はヒアリングから開発までのリソースを持っているため、チーム内で完結をしている。
D社は業務ヒアリングや書類作成が得意な会社なので、その部分のみを担当する。
E社はRPA開発設計ができるが、D社と社内IT部門のヒアリング結果に基づいてRPA開発設計を行う。
最後E社が開発設計書類をF社にレビューし、開発を行う。
各社が自らの部分を担当しているが、プロジェクト全体の進捗などを共有する場がないため、各社も実際どこまで進んでいるかも把握していないのが結果になっている。
また、各社のコミュニケーションはA社のIT部門経由で行っているため、非効率な場合がある。
例えば、D社は業務ヒアリングなどは得意だが、RPAに対する理解度が浅いため、ヒアリング時RPA開発に必要な情報が揃っていない場合やそもそもRPA開発が困難な場合がある。
そして、この情報がE社のところに届いたら、開発設計がスムーズに進められず、D社に再度の問い合わせが必要となる。
もしD社がヒアリングしている際にE社との連携がうまくできていれば、効率がよくなるだろう。
もう一つ統合できていないのは書類の管理だ。
開発ラインを大きく分けるとB社が一つチームで、DEF社が一つチームになるが、この二つのチームが使っている書類のフォーマットもそろっていなければ、保存場所も異なる。
要するに、同じプロジェクトで同じステップの業務をしているにも関わらず、ノウハウなどはあまり共有されていない。
RPA開発では、異なる業務でも似たような操作などがあり、とても参考になるだろう。
また、書類フォーマットが統一されていないと、後日のメンテナンスも大変なことになり得る。
解決策として、もちろん、外部組織をすべて統合するPMを設けるのもできるが、外部と契約する場合構造を変えることも方法の一つだと思う。
表2のように、各機能層ごとに一つの会社と契約し、そして社内IT部門は勉強しながら外部の会社と一緒に業務を行う。
この場合責務もはっきりしているし、各機能を担当する会社が内部でリソース調整やノウハウ共有もよりスムーズにできるだとう。
RPA化業務選定の段階から、各部署にヒアリングしに行くことか必ず発生する。
ヒアリング対象は基本選定された業務の担当者が適任だが、A社の場合もこの方針だ。
ただし、問題点としては、各部署にRPA化に対応する担当者を明確には設けていなかった。
勿論RPA対応担当者が必要ではない。
例えば、部門間のコミュニケーションが簡単に取れれば、IT部署が他部署にヒアリングしに行くことも簡単だろう。
そして、実際開発する際に、色々と追加の確認事項や仕様変更の相談も必ずあるので、随時に確認することも難しくない。
ただし、A社の場合、規模が大きいため、部門間のコミュニケーションは普段十分にとられていない。
A社の業務ヒアリングは通常ユーザー部署が対象業務のマニュアルを用意し、会議の形で開発部署にプレゼンする。
しかし、ユーザー部署はあくまでRPAに詳しくないため、RPAに合わせて業務フローを修正することが十分にできないだろう。
したがって、追加の確認事項がたくさん出てくるが、ユーザー部署の従業員が自分の業務が忙しく、それ以外のことを対応しきれないなどの原因で、なかなか確認取れない。
これの対策としては、一定期間で特定な従業員をRPA対応担当者に指定し、期間内でRPA開発に必要なことを優先的に協力するようにしたら効果的だろう。
すると、例えば、RPAに合わせて現在業務フォローの改正やファイル書式変更などRPA対応担当者が集中に対応し、業務ヒアリングと開発がよりスムーズにできると予想する。
今回はA社がRPA導入時発生したトラブルのもとに、大中企業特に起こり得る組織体制問題を紹介した。
外部組織と複数契約する場合最大限各組織を活かすためにうまく統合するか、役割別の組織構造を作る必要がある。
内部に関して、各部署間のコミュニケーションがうまくいかない場合、RPA推進する役を各部署に選定したほうが有効だろう。
全てのRPA導入プロジェクトが起きる問題ではなければ、これらの対策も正解ではないが、参考になれれば幸い。
