■サイト内検索:
 

RPA Biz > RPA > RPA推進で失敗しないために

RPA推進で失敗しないために

2018.10.26

目次

 

 

 

 

オリックス・三菱UFJ銀行・日本生命など、

去年までは導入企業も金融業中心に一部に限られていたRPA(ロボティック・プロセス・オートマティック)も、

今年になって裾野が一挙に広まり、導入企業は年内に5000社に達すると言われています。

 

オフィス生産性を飛躍的に向上させた事例が華々しく紹介される一方で、

RPAベンダーの話では上手く進まないケースも散見され、中には「撤収しようか」という企業もあるようです。

 

 

今回の記事ではRPA導入でつまずかないために、

社内の推進体制(IT部門と業務部門の役割)・RPAツールの特徴と選定・トライアルの重要性について紹介します。

 

 

 

 

■既存ITシステムとRPAの違い

既存システムはコストも時間もかかる

ERP(業務統合パッケージ)を始めとする基幹システムにせよ情報系システムにせよ、

システム設計・構築ではユーザーの要件をITシステムに翻訳する作業が必須で、時間も費用も掛かります。

 

そこには以下のようなフローが使用されます。

 

  ユーザー:システム構想・要件定義

→ ベンダー:方式・アプリケーション設計、プログラミング、単体・結合・総合テスト

→ ユーザー:検証テスト

 

 

当然システム予算もIT部門のマンパワーにも限りがあるわけで、

費用対効果の大きい案件から優先順位が付けられ、システム導入が図られます。

 

システム改変も容易ではなく、

周辺環境の変化があってもシステムはそのままで担当者がハンド作業で乗り切るといったケースも散見されます

 

 

 

低コストで業務自動化ができるRPA

一方、RPAはシステムというより寧ろ「ロボット」に近い存在です。

このロボットはユーザーインターフェースに優れ、ユーザーの要件定義をほぼそのまま理解しこなすことができるのです。

 

つまりIT部門に頼らずとも、いったんRPAというロボットを導入すれば、

後はロボットに業務プロセスを覚えさせれば自動化できるのです。

(ロボット作成に関して多少のトレーニングやベンダーのサポートは必要)

 

 

その結果、自動化のコストも大幅に低減でき、

今まで費用対効果の面からシステム化が見送られハンド作業で我慢してきた業務にも光が当たるようになってきたのです。

 

 

 

 

■推進体制は横断的に

部門や事業所単独では失敗しがち

ソフトウエアにもよりますが、

デスクトップで動くようなRPAならハードルも低く部門(または事業所)単位での導入も可能であり、

その方が社内調整が不要な分だけスピーディーにRPA化が実現します。

 

一方で、部門間で選択ツールが異なる、たとえ同じとしても作成したロボットのシナリオが重複したり、

開発・運営ノウハウが共有されないといった非効率が生じがちです。

 

加えて運営体制も不充分になりがちで、放置された「野良ロボット」を産みかねません。 

 

 

 

横断的に進める

一方で全社的に進めるとなると、立ち上げるだけでも多大な労力と時間を要するので、悩ましいところです。

新聞記事で話題となったメガバンクのようにトップダウンでRPAを導入する企業なら、全社的推進体制を組むケースもあります。

 

折衷案的に、スピードと効率を両立するために、

人事・財務・総務といった機能単位で横断的な推進プロジェクトを組むという考え方もあります。

 

その上で、担当役員をPMO(プロジェクト・マネジメント・オーナー)にすえ、

IT部門には事務局に入ってもらい、各ユーザー部門は推進メンバーに入ります。

 

 

加えて、経営企画部門もオブザーバー的な位置づけで参加するケースも、最近は多いようです。

従来のIT化とは異なり、AIRPAの導入は戦略的な要素が色濃いので、経営企画部門のかじ取りが必要なのです。

 

加えてポジションパワーの強さを発揮して、予算獲得や社内調整に当たっても強い味方になってくれます。

 

 

 

 IT部門の役割

IT部門にはその道のエキスパートとして、ユーザー部門をサポートしてもらいます。

具体的にはベンダー選定の他、セキュリティーやガバナンスの確保、

RPAによる基幹システムへのアクセス権限設定やワークフロー開発申請手続きなどのルール整備を担当します。

 

 

ただしワークフロー開発については、通常のITシステムと違って、

ユーザー部門がベンダーの支援を受けつつ主体的に進めてもらいます。

 

言い換えれば、IT部門のマンパワーを大きく割かずに開発を進められるのが、RPAのメリットなのです。

 

 

 

 

 

■RPAツール選定のポイント

RPAツールは、

ビスロボ・ウインアクター・ブループリズム・UIパス・オートメーションエニーウエア

5種でシェアの大部分を占めています。

 

 

ツール選定に当たっては、どうしてもコストばかりに関心が向きがちです。

とくに最近は、デスクトップでロボットを稼働させるタイプなら年間100万円以下での導入も可能です。

 

 

一方で、見落としがちなのが将来的な動作の安定性(ロボット操作のIDPW管理)や

拡張性(複数ロボットの同時稼働)、運営管理の担保(スケジューラー・ログ管理)などです。

 

スモールスタートで少数のソフトウエアロボットが動いているうちはあまり気になりませんが、

数が増えてくるにつれて必要性が強まります。

 

コストとこうした機能は相反しがちなので、

自社におけるRPA展開範囲やRPA化の調達予算等を見極めた上で判断すべきでしょう。

 

 

 

 

■対象業務の選定-かき集めて工数削減効果を捻出する

RPAを紹介するWEBなどでは、RPA化を最優先すべき業務として「単純作業かつ業務量が膨大な仕事」とされています。

 

 

ところがこうした業務は、

すでにERP・経費精算システムや得意先とのEDI(電子データ交換システム)自動化が実現しているケースが多いのです。

 

つまり「単純作業かつ業務量が膨大な」業務は費用対効果が大きいので、

ロボットに頼るよりITシステムを構築した方が効率的なのです。

 

 

RPA化の対象となるのは、IT化するほどでもない「中途半端に手間がかかる」ハンド業務をです。

こうした業務をかき集めて工数削減効果を出すには、複数のユーザー部門を巻き込んでの連携が不可欠です。

 

 

 

■トライアルの重要性

ITシステム導入は、稼働テストを経た後は本稼働という流れです。

RPAの場合はそれとは異なり、本格展開する前にトライアルを実施するのが一般的です。

 

トライアルで確認するのは、まず各種システムとのインターフェースです。

 

エクセル・アウトルック・インターネットエクスプローラーに関しては間違いなくつながるようですが、

問題なのは「レガシーシステム」です。

 

レガシーシステムとは、メインフレーム(真黒バックに緑文字の画面を見たことありませんか?)や

クライアントサーバー系で動く、80年代-90年代に構築されたシステムです。

 

 

多くの企業ではERP等を導入する一方、過去に構築したレガシーシステムを相変わらず使い続けています。

今までは部門の要求に応じて個別にシステムを作ってきたため、これらを一度に置き換えることは不可能です。

 

RPA対象化業務にこうしたシステムが絡んでいたらまずは検証が必要です。

最悪インターフェースできない場合は、画面マッチングを使うしかありませんが、

この方法は端末の画面設定が変わったりしただけで作動しなくなるなど、安定性に難があります。

 

 

もう1つは動作性の検証です。

例えば経費精算システムの操作にRPAを使う場合、以下のような基本的動作を確認します。

 


・ログインできるか(ID・パスワードを入力する)

・端末を変えても動作するか(端末の画面設定が変わっただけで動作しない事例もあり)

・タブ・クリック・ファンクションキーの操作

 

トライアルを通じてRPAの癖について知見を蓄積し、いざ本稼働となった時につまずくことがないようにしましょう。

 

 

 

 

 

■むすび

今回は推進体制の整備から、機種の選定、業務の洗い出し、トライアルの実施について

RPA導入で失敗しないポイント」を紹介しました。

 

 

次回以降は、機種選定や業務洗い出しプロセスについて個別に詳細を解説するほか、

導入後の運営に関するポイント(コンサルによるサポート・本格展開の進め方・ガバナンスの整備)

についてご紹介します。 

 

 

 

 

 

 

topへ
© RPA.biz