■サイト内検索:
RPA.biz
RPA Biz > 2018年 > 8月

【UiPath】アクティビティパッケージまとめ 1/2

2018.08.20

UiPathは、様々なアクティビティやレコードなどを使用して作業の自動化を行うことができるように開発された

RPAツールの一つです。

 

このUiPathには初めからインストールされているアクティビティ以外にも、アクティビティを追加することができます。

その際に、インストールするのがアクティビティパッケージです。

 

今回はそのアクティビティパッケージの用途に分けた使い方をまとめていこうと思います。

 

 

アクティビティパッケージとは


アクティビティパッケージとはパッケージ化された様々なアクティビティのことを指します。

分かりやすく言うと、様々なアクティビティが一つの袋に集められているようなものです。

 

UiPathの場合にはその袋が用途ごとに別けてまとめられています。

ですので、必要なアクティビティのみをインストールして使用することが可能です。

 

様々なアクティビティがある中で自身の必要なアクティビティを確認して初期設定を行うことをおすすめします。

そのために今回はアクティビティパッケージを一つずつ中身を確認して、初期設定に役立てていただけたらと思います。

 

インストール・アンインストール方法


どのようなパッケージがあるかどうかを見る前に、

パッケージのインストール・アンインストール方法を確認しておきましょう。

ここでは、現在の自身の環境でどのアクティビティパッケージをインストールしているかどうか

確認できますので便利です。

 

1.UiPath Studioを起動する

 

2. 左側にあるアクティビティ一覧から「Manage Packages」と書かれるアイコンをクリック

これで新しいウィンドウにパッケージマネージャーを開くことができます。

(ショートカットキーとしてCtrl+Pも用意されています。)

 

 

 

 

3. 左のInstalledの下矢印をクリック

 ここで現在ご自身の環境でどのパッケージがインストールされているのかがわかります。

(ここでInstalledに表示されているのが、現在ご自身の環境でインストールされているパッケージです。)

 

また、ここでは必要がなくなった・間違えてインストールしてしまったパッケージをアンインストールすることもできます。

その場合は、Uninstallをクリックすればアンインストールできます。

 

 

 

 

 

4. 新しくインストールしたい場合は「Available」からインストールしたいパッケージをインストールします。

(すでにインストール済みのものにはチェックマークがついています)

 

 

 

 

このように自身の環境確認とインストールとアンインストールの手順を確認したところで、

実際にアクティビティパッケージについて見ていきましょう。

 

 

アクティビティパッケージ


 

UiPath.Core.Activities

 

 

この、コアアクティビティパックには、ユーザーインターフェイス(UI)の自動化の作成に必要な

基本的なアクティビティがすべて含まれています。

 

基本的にこのパッケージはインストールしておくことをおすすめします。

 

<主に含まれているアクティビティ>

 

・「Get Text

指定したUI要素(*注1)からテキストを読み込みます。

 

*注1

UI要素:ウィンドウ、チェックボックス、テキストフィールドのようなGUIを総称してUI要素と呼びます。

 

・「Type Into

指定したUI要素にテキストなどを送信します

 

・「Hover

指定した UI 要素の上にカーソルを置きます (UI 要素の上でホバーします)。

 

・「Click」「Double Click

指定したをUI要素をクリック、ダブルクリックします。

 

・「Get OCR Text

OCR の技術であるスクリーンスクレイピングを使用する際に、

指定した UI 要素から文字列とその情報を抽出します。

このアクティビティは、スクリーンスクレイピングの実行時にコンテナーと一緒に自動的に生成することもできます。

既定では、Google OCR エンジンが使用されます。

 

・「Hover OCR Text

OCR の技術であるスクリーンスクレイピングを使用する際に、指定した UI 要素の中で指定の文字列を検索し、

文字列の上にカーソルを置きます (文字列の上でホバーします)。

既定では、Google OCR エンジンが使用されます。

 

 

 

ここまで具体的なアクティビティを見て気づかれた方もいるかもしれませんが、

このアクティブパックによって、簡単なキーボードやマウスの自動化だけではなくて、

OCRや画像認識の技術を使っての、画像およびテキストの自動化を実行することが可能となります。

 

また、情報を抽出してデータテーブルを作ったり、

PC上のディレクトリやファイルを直接操作して必要な操作を自動化することもできます。

 

UiPath.Cognitive.Activities

 

 

このアクティビティにはGoogleやMicrosoft、さらにIBMといったAPIを使用して

情報を取り出すときに役に立ちます。

 

このアクティビティパックには様々なAPI操作における自動化を助けるアクティビティが入っています。

 

<主に含まれているアクティビティ>

 

・「Google Text Analysis

Googleのテキストついて機能することができるアクティビティです。

指定したてテキストについて、言語、長さなどを取り出すことができます。

さらに、テキストが肯定的か否定的かどうかも分かることができます。

注)このアクティビティが機能する言語は、英語とスペイン語さらに日本語の3か国語だけです。

 

・「IBM Watson Text Analysis」「Microsoft Text Analysis

これらも指定したテキストを解析するのに使うアクティビティです。

上の「Google Text Translate」と違うところは、解析するテキストの種類が異なるだけです。

 

・「Google Text Translate

Googleのテキストを他の言語に翻訳することができるアクティビティです。

 

このようにこのアクティビティパックにはテキストを別の言語に翻訳するだけではなくて、

感情やキーフレーズを抜き出すこと可能です。

他にも発生している可能性のあるエラーや使用されている言語の解析なども可能です。

 

UiPath.Database.Activities

 

 

このアクティビティパックには、

データベースに接続してトランザクションやクエリなどを自動かすることができます

 

<主に含まれているアクティビティ>

 

・「Connect」「Disconnect

これらのアクティビティは、データベースに接続することや、

接続を切断することを実行するアクティビティです。

Connect」で接続し、「Disconnect」で切断することができます。

 

・「Start Transaction

このアクティビティはデータベースに接続し、複数のアクションを実行してから切断できるようにすることが可能です。

データベースに接続し、データベースで複数のトランザクションを実行できるシーケンスを持っています。

 

UseTransaction という変数 が True に設定されている場合、

含まれている操作は単一のトランザクションで実行され、それらのどれもが失敗しなかった場合は最後に適用されます。

 

同様のUseTransaction 変数が False に設定されている場合、

すべての操作は個別に実行されます。

 

このアクティビティが終了すると、データベースへの接続が終了します。

このアクティビティパックにはデータベースと接続とその切断やトランザクションの分割などを行うことができます。

 

 

 

 

完全無料のRPAツールWorkFusionとは

2018.08.17

RPAツールは基本的に高額なものが多く、

エンタープライズ向けだと年間数百万円以上かかり小規模でも年間数十万円といった価格帯です。

 

なので中小企業やベンチャーでは価格がネックとなり導入に踏み切れないケースも多くあります。

 そのため無料のRPAツールは多くの企業で求められており、

Google検索でも「RPA」と一緒に「無料」「フリー」などのワードが非常に多く検索されています。

 

 

みなさんはWorkFusionというRPAツールご存知でしょうか。

このツールはなんと無料で提供されています。

 

UiPathのCommunity Editionのように小規模事業者のみなどの制約はなく商用で堂々とRPAを無料で使うことが可能です。

今回はそのWorkFusionの特徴・メリット・デメリットなどを解説していきます。

 

WorkFusionはなぜ無料なのか

 

「無料より怖いものはない」という言葉がある通り、

日本ではまだあまり浸透していないWorkFusionを無料という理由だけで使用するにはかなり不安がありますし、

すこし高くても有名なWinActorやUiPathを選ばざるを得ないのが現状かと思います。

 

まずはその不安を取り払う為に、なぜ無料で提供しているのかを解説します。

 

 

WorkFusionは2012年マサチューセッツ工科大学発祥の比較的歴史の浅い企業です。

 

さらにWorkFusionの提供するRPAツール「RPA Express」は2017年にリリースされたばかりで、

まだリリースから1年ほどしか経っていません。

 

しかし、本拠地のアメリカではすでにRPAのBIG3といわれる、

Automation Anywhere, Blue Prism, UiPathのポジションに最も近い存在とも言われるほどユーザ数を急激に伸ばしています。

 

全世界でのユーザ数は現在3万以上と発表されおり、単に無料というだけではこれほどの利用はされないはずです。

 

 

WorkFusionはRPA×AIを前提として捉えており、

現在普及しているRPAは既存の技術のみしか使用していないので廉価版として無料で提供しています。

 

廉価版といえど他のUiPathなどと管理機能など含め引けをとらない機能を有しています。

これに加えて上位版が用意されており、こちらが年間150ドルで提供されています。

 

上位版を購入するとOCRや機械学習を活用した機能が使用できるようになります。

 

つまりWorkFusionはフリーミアムのビジネスモデルで収益を得ているので、

無料の機能を安心して使用することができます。

機能面の特徴

 

 

RPA Expressの開発画面

 

・Xpathまたはイメージ認識で画面認識

自動化の対象となるシステムのインターフェースをどのように認識するかはRPAツールの個性がでるところです。

 

WorkFusionはAIを活用したイメージ認識技術に強みを持っている企業なので、

今まで画像のマッチングで場所を特定するイメージ認識が中心でした。

 

しかしどれほど優れたイメージ認識でもユーザインタフェースは変化が多いので稼働が不安定になることが多いのも事実です。

 

WorkFusionは2018年5月のメジャーアップデートにイメージ認識に加えて、

システムの構造解析をして場所を特定するいわゆるオブジェクト認識が可能になりました。

 

オブジェクト認識にも種類がいくつかありますがウェブの場合Xpathによる指定方式を採用しています。

 

すこし、技術的な知識が必要ではありますが本格的につくりこめばUiPathやBizRobo!と同レベルの安定性をもったロボット開発も可能です。

 

 

・Chrome、FireFoxと相性が良い

RPAツールはInternet Explorerにしか対応していなかったり、独自ブラウザしか使用できないといったものが多いです。

拡張機能としてChromeなどが使えるといったツールもあります。

 

しかしWorkFusionはデフォルトでChrome, Fire Fox, Internet Explorerをサポートしている為、

特定のブラウザでの操作が必要な場合WorkFusionは非常に相性が良いです。

 

 

・管理機能がデフォルトで搭載

通常RPAの管理機能を導入しようすると安くても200万円以上はしますが、

WorkFusionではControll Towerという管理機能までもが無料で使用できます。

 

しかし、無料版だと他のデバイスとの連携がとれないため実質社内のRPA全体管理に活用するのは難しいですが、

スケジュール稼働などの機能は無料版で使用することができます。

 

有償版を購入する他のデバイスと連携がとれるようになります。

有償版は日本円で約180万円程度なのでこれでも十分に安いです。

 

 

日本でのサポート体制

 

・販売代理店

本格的のアメリカでのシェア拡大に注力している為か、日本での販売代理店は現状ありません

導入や活用をサポートできる企業も限られています。

 

・オンライントレーニング

すべて英語のコンテンツですが、Automation Academyという無料のe-ラーニングサイトと、

WorkFusion ForumというFAQサイトがあります。

 

 

WorkFusionをつかうメリット

 

・無料で使える

言うまでもありませんが、無料で使えるというのは非常に大きなメリットです。

RPA活用において、ツールに費用をかけるよりも、

ツールを活用して自動化していくことにお金や人材を投資することが成功のカギです。

 

したがってツールの費用を最小限に抑えることは決して消極的ではなく合理的な選択といえるでしょう。

 

 

・将来性がある

WorkFusionはまだまだ発展途上のRPAツールでありながらユーザ数を急激に伸ばし、機能の拡充も早いスピードで進んでいます。

もともと高い技術力を持った企業でありRPA×AIを前提として開発を進めているので、

近い将来RPAのBIG3を上回るハイスペックなRPAツールに成長する可能性を秘めています

 

 

WorkFusionのデメリット・注意点

 

・細かい使い勝手では劣る

やはり細かい使い勝手ではUiPathなどに劣ります。具体的な例をあげれば、

  • バリデーションチェックがない
  • デバッグ時にスローで実行したりターゲットをハイライトすることができない
  • レコーディングでXpath指定できない
  • エラーメッセージがわかりにくい
  • ワークフローの可視性が低い

などなど多いですが、無料ということを考えれば致し方無いのかもしれません。

 

 

・エンジニアがいないと使いこなせない

まず、WorkFusionは日本でほとんど展開していない為ソフトウェアはじめマニュアルやe-ラーニングなどすべてが英語です。

さらに今後日本展開といった噂もないので日本語化される見込みも低いです。

 

 

また、レコーディングやコマンドのドラッグアンドドロップなど業務部門でも基本的な自動化だけなら使いやすいです。

しかし、作りこもうとすると手打ちでのXpath指定などが必要になるので業務部門だけでRPA活用するといったイメージだと導入は厳しく、

エンジニア中心での活用または、その中間で業務部門とエンジニアが連携して進めていく形になります。

 

一方で、コードベースで開発できる機能もあるのでエンジニアにとっては相性がよいかもしれません。

 

 

まとめ

WorkFusionの導入に向いている企業は

  • 新しいものに抵抗がない
  • 社内にエンジニアがいる
  • 将来的には非定型業務も自動化していきたい

といったものにあてはまる企業だといえます。

 

 

 

【必見】大規模RPAプロジェクトの進め方 (4/4)

2018.08.16

今回のコラムでは、前回に引き続き、大規模なRPA導入プロジェクトにおける成功の鍵について述べていきたいと思います。

 

「組織体制」と「運営」の2つに分けて説明させていただきましたが、本コラムでは後者に焦点を当てています。

 

前回コラムを参照したい方は下記のリンクを参照してください。

 

 

(参考)前回コラム:大規模RPAプロジェクトの進め方 (3/4

 

 

まず、おさらいになりますが、RPA導入プロジェクトをする上での成功の鍵として、

前回コラムからの再掲になりますが、以下のような要点が挙げられます。

 

 

  • 組織体制
    • 分散と集中
    • コーポレートで専任チームを作り、ユーザー側の担当者を明確に
    • 分業のススメ
  • 運営
    • パイプライン管理でボトルネックを探せ
    • 教育も並行で
    • ナレッジシェアリングの仕掛け
    • テスト環境に配慮を

 

 

本コラムでは、2の「運営」について詳述していきます。

 

 

2 運営

2.1 パイプライン管理でボトルネックを探せ

RPAの技術自体が目新しいものなので、

多くの導入企業にとってRPAプロジェクトに対する経験値が未だ十分に足りていない事が多いと思います。

 

金融業界でまずRPA化の先鞭をつけた形となりましたが、その他の多くの業界では、未だPOCの段階であったり、

ようやく2018年になって開発体制の準備、実行フェーズに入ったところが大多数ではないでしょうか。

 

 

そのように不慣れなプロジェクトにおいて、人員リソースの最適配分は喫緊の命題となります。

 

もともとRPAに詳しい人材が未だ市場に十分にいない状況ですので、

開発工程のうちのどこかのプロセスがボトルネックとなり、

目標とする開発ロボット数や業務負荷低減時間に到達できずに苦労している企業も多いように見受けられます。

 

 

従って、特にRPA導入プロジェクトにおいては、

ボトルネックを探し出すためのプロジェクトマネジメント技術が求められることになります。

 

そのようなスキルは、正にPM/PMOにとって腕の見せ所の領域です。

特に大規模なRPA導入プロジェクトとなった場合、

それこそ数多のロボット案件・アイデアが浮上していくことになるので、それらを捌き、整理し、

管理するための高度な技術およびシェアリングの環境が待望されています。

 

その中の一つとなる有効な手法が「パイプラインの見える化」です。

 

(参考:パイプラインの管理)

 

 

パイプライン管理は、システム開発の用語というよりかは、

歴史的に営業であったりR&Dの領域で発展してきたマネジメント手法です。

 

簡単に説明すると、営業にしろR&Dにしろ、システム開発でも構いませんが、

特定の業務を個別プロセスに分解し、各プロセス上に現在どのくらいの案件があるのか可視化する手法です。

工場生産の現場で言うと、歩留まりを把握するのに近しい手法です。

 

 

何故、RPA導入プロジェクトの現場で「パイプライン管理」が重要になるのかというと、

それはRPAプロジェクトならではの特性に起因します。

 

RPAというものは、そもそも大型のシステム開発案件とは違い、

「システム開発するにはペイしない」細々とした業務の自動化が前提となります。

 

 

そもそも大きな業務負荷低減が見込める領域であれば、

RPAでなくて抜本的なスクラッチでのシステム開発を選ぶケースが圧倒的であり、多くの企業はそうしています。

 

 

つまり、企業にとってそれなりの業務負荷低減効果を狙うのであれば、

それこそ数多のロボットを生成する可能性が出てくるということです。

 

即ち、通常のシステム開発と比べ、RPAというものは、一つ一つは小粒な、

でも数だけは膨大なロボット開発案件の集合体となるわけです。

 

そこに、パイプライン管理の重要性が屹立してくることになります。

 

 

上記にあるチャートで、RPA導入プロジェクトにおけるパイプライン管理の事例を紹介していますが、

それでは例えば其処から何が読み取れるでしょうか。

 

この例で、まず目につくのは「業務フロー設計(To-Be)」が完了しているのに次の段階に移れていない案件が多く、

その割に次フェーズの「プログラム設計書作成」で仕掛中の案件が少ないことです。

 

これは、プログラム設計書作成の人的リソースが足りないが故に全体として動脈硬化が起きている現象を示しています。

つまり、この時点で「プログラム設計書作成」が明らかなボトルネックになっているということです。

 

 

このような極端な例は無いだろう、、、と思われる方も多いと思いますが、

不慣れなRPA導入のプロジェクトの場合、現実的に起こりうる事象です。

 

おそらくPMとしては、もちろん薄々は問題を理解していることなのですが、

いかんせんそのボトルネック工程を補填する人的リソースが見当たらず、打開策が取れない状態に陥っている、

そのようなことが現実的にRPAの開発現場では起きています。

 

 

このあたりの具体的な解決策については、

次のポイントである「教育」に大きく関与してくるところではあるので次節以降に譲りますが、

いずれにせよ重要なのは、このようなパイプライン管理をすることで「迅速に」ボトルネックを洗い出し、

打ち手を講じることができることです。

 

それにより、納期と目標が決められたプロジェクトを完遂し達成する確度を上げることができるのです。

 

 

2.2 教育も並行で

次に、RPAプロジェクトにおける「教育」の重要性について語りたいと思います。

なぜRPAプロジェクトにおいて教育、つまりトレーニングが重要となるのか。

 

それは、RPAの持つ2つの特徴に起因します。

1つ目は「RPA人材の不足」2つ目は、その割には「RPAの技術自体は差ほど難しくない」ということが挙げられます。

 

 

前述しました通り、RPAは比較的新しい技術領域であり、

そのプロジェクトに精通している人材の確保が難しい状況にあります。

 

従って、プロジェクトスタート時では十分なビジネスアナリスト/業務コンサルタントおよびエンジニア双方において十分な知見を有する人材を欠いたままスタートせざるを得ないケースもまま存在します。

 

このような状況でプロジェクトを運営せざるを得ない場合、大事なのは開発と同時に「教育」も進めていく事です。

 

RPAプロジェクトの場合、小型のロボット開発を積み重ねていく進め方になるので、

最初のリソース不足の段階では、少数の案件に着手し、後のフェーズで教育を経て人材を揃えていくやり方でも進めていく事ができます。

 

 

教育に焦点を当てる領域を特定する上で、前述したパイプライン管理が役立ちます。

定期的に、各工程の歩留まりをチェックすることで、

リソースが枯渇しそうなプロセスの人員を特に重点的に教育して増やしていく柔軟性が求められます。

 

一般的に、RPAのプロジェクトでは、プログラム設計書作成やRPA開発といった下流工程がボトルネックになりがちであり、

トレーニングをして人員体制を整えることが求められます。

 

 

2.3 ナレッジシェアリングの仕掛け

上述した教育を促進させるために、KMの観点は非常に重要になります。

 

特にRPAのプロジェクトでは、ユーザー側の担当部署・担当者が多種多様に広がる可能性が高く、

またプロジェクトフェーズごとに人員体制を柔軟に変動させる必要があるため、

コアとなる知識・ノウハウを共有する工夫が開発の非効率を防ぐために必要です。

 

先進的な企業ではRPA専用の社内ポータルサイトを作り、ナレッジ共有に努めています。

 

ポータルサイトでなくとも、Slack等の社内SNSを活用していくのも有効です。

SNSを使えば、コミュニケーションの迅速化が図れ、ユーザーと、ビジネスアナリストおよびエンジニア間で、

仕様の確認や、RPAに合わせた業務フロー・ロジックの提案および承認といった、細々な点で開発スピードの向上が狙えます。

 

 

ただ、そのような大層な仕掛けがなくとも、

普通に共有フォルダを関係メンバーに公開するようなやり方でも、もちろん一向に構いません。

 

 

それでは、具体的にどのような情報コンテンツをナレッジシェアリングの対象とすべきでしょうか。

具体的な例として以下をご覧ください。

 

複数のステークホルダーが関与することになりますので、

それ毎に分けてコンテンツを用意することが見る側にとってもストレスなく使ってくれることに繋がります。

 

また、ユーザーサイドであったり、ビジネスアナリスト/業務コンサルタントに対しても、

RPAロボットの動き方を理解してもらうことは重要になりますので、

エンジニア以外にもRPAツールの紹介をする工夫がポイントとなります。

 

 

<全体>

  • 組織体制図、各コンタクトポイント
  • 案件リスト、パイプライン管理表
  • スケジュール

 

<対ユーザー部署>

  • RPAの基本の紹介(初級編。動画コンテンツ等が有効です)
  • RPA対象業務選定のコツ・ポイント
  • 業務評価リストひな型と記入例
  • 現在の完成/仕掛中業務評価リスト

 

<対ビジネスアナリスト/業務コンサルタント>

  • RPAの基礎トレーニングプログラム(簡単なプログラムを実際に自分でさせるのが理想)
  • As-Is業務分析用シートひな型・記入例
  • To-Be業務フロー設計書ひな型・記入例
  • 現在の完成/仕掛中のAs-Is/To-Be資料

 

<対エンジニア>

  • RPAの中級・上級トレーニングプログラム
  • プログラム設計書ひな型・記入例
  • 現在の完成/仕掛中のプログラム設計書
  • 開発ルール説明
  • モジュール管理リスト(複数案件に使いまわしのきく基礎プログラムを整理&説明したもの)
  • テスト設計書ひな型・記入例
  • 現在の完成/仕掛中のテスト設計書
  • ユーザー担当者/ビジネスアナリスト/業務コンサルタント側とのQAリスト

 

 

2.4 テスト環境に配慮を

RPAプロジェクトの運営面でのポイントをお伝えしましたが、

最後にテスト環境の配慮を早い段階でしておくことの重要性をお伝えしたいと思います。

 

 

RPAでは、日々の定型業務の自動化がターゲットとなりますので、メール受信や、既存社内システム、

外部アプリケーションの操作をRPAでプログラミングしていくことになります。

 

また、ロボットと人間の間のやり取りの仕方として、特定共有フォルダに人間が必要ファイルをアップロードして、

ロボットが定期的にその共有フォルダを巡回、ファイルが合ったら処理を開始する、といった方法が取られることが多いです。

 

そのような、メール、社内システム、外部アプリケーション、共有フォルダといったものに対して、

テスト用と本番用を予め設計しておくことがスループットの向上につながります。

 

必ずしもテスト用と本番用の環境を別々にする必要はありませんが、

例えば、今でも社員が使っている共有フォルダやメーリングリスト、

およびシステム・アプリケーションのアカウントをテスト用で使うのは問題になりますので、

状況に応じて環境を分ける判断が必要です。

 

その場合、例えば、システムやアプリケーションのアカウントで起こりがちですが、

権限の設定がテスト用と本番用で齟齬があると障害の元となりますので、予め設計書で指示しておく必要があります。

 

また、このようなテスト用・本番用の環境設定は、RPA開発エンジニアの仕事という訳ではありません。

環境設定と言っても、大げさなものではなく通常業務で使うアプリ等の設定の話ですので、

このあたりの役回りは開発エンジニア以外の担当でも構いません。

 

 

RPAでは、一つ一つのロボット案件は小さいので、大規模システム開発と違い、

このあたりのテスト環境の整備がなおざりになりがちで、

いざ開発する段階になって「どうするんだっけ?」となることが散見されます。

 

予めプログラム設計書のフォーマットにテスト環境と本番環境を分けて記述できるように欄を設けるなど、

工夫をすべきだと考えます。

 

  

以上、今回の一連のコラムでは、

比較的大規模なRPAプロジェクトにおいて気を付けるべきポイントを組織体制と運営の側面から俯瞰してご紹介しました。

 

プロジェクトの要所は、会社およびRPA対象部署などによって変わってくるものではありますが、

今回でご紹介した点を咀嚼し、応用していただければと思います。

 

 

 

【必見】大規模RPAプロジェクトの進め方 (3/4)

2018.08.15

今回のコラムでは、比較的大規模なRPA導入プロジェクトにおいて特に注意すべき点を述べていきたいと思います。

前回のコラムまでは、一般的な各開発工程における留意点を挙げさせていただきました。

 

 

(参考)前回コラム:大規模RPAプロジェクトの進め方 (2/4

 

 

複数の部署に跨る大規模なRPA導入プロジェクトの場合、特に組織体制と運営手法が重要になってきます。

このあたり、幾つか要点をまとめてみました。

 

  • 組織体制
    • 分散と集中
    • コーポレートで専任チームを作り、ユーザー側の担当者を明確に
    • 分業のススメ
  • 運営
    • パイプライン管理でボトルネックを探せ
    • 教育も並行で
    • ナレッジシェアリングの仕掛け
    • テスト環境に配慮を

 

 

1 組織体制

1.1 分散と集中

分散と集中とは、各工程のタスクを事業部等の個別部署に分散してお願いするのか、

コーポレートで中央管理するのかの切り分けの話になります。

 

もともと、RPAの思想として、ユーザーである現場部署が自らの力で自動化できることを謳ってはおりますが、

こと大規模なプロジェクトの場合は、開発工程に進むほど中央管理することが求められます

 

(参考: RPA導入プロジェクトの工程)

 

 

前回コラムで、上記の一般的な開発工程ステップをお見せしましたが、

理想論から言うと、最初の「対象業務選出」のところまではユーザーである現場部門主導で行い、

その後の現状業務分析(As-Is)以降は、コーポレートに所属するビジネスアナリストもしくは外部の業務コンサルタントが主導して現場ヒアリングをベースに策定していくのが望ましいと言えます。

 

 

これは、As-Isの分析資料や、To-Beの設計書というものが、

次の実開発フェーズに進むうえで標準化された仕様であることが望まれるからです。

 

個別現場部門にお願いする場合、フォーマットを規定したとしてもどうしても書き方の統一が難しく、

標準化されていないと開発チームが混乱をきたすリスクが高まります。

 

 

ただ、これはあくまで理想論であって、

中にはビジネスアナリスト/業務コンサルタントのようなリソースの十分な確保が困難である会社も多く存在すると思います。

 

その場合、百歩譲って、As-Isの現状業務分析のところはフォーマットを決めてユーザー側である現場担当者に任せることも可能です。

 

非常に単純な作業をRPA化するのであればTo-Beのところも任せられるケースもあります。

ただ、プログラム設計書作成とのころは、開発チームに標準化された仕様書を渡す最後の砦となりますので、

その工程だけはしっかりとセントラルで品質管理できるようなチーム体制は必須となります。

 

 

1.2 コーポレートで専任チームを作り、ユーザー側の担当者を明確に

(参考:RPAプロジェクト体制例)

 

 

次にRPAを推進していく上でのチーム体制についてですが、こちらについては、

もちろんリソースが許す範囲でのことになりますが、PM/PMOのみならず、

ビジネスアナリスト/業務コンサルタントおよびエンジニアまで含めて専任チームを組めることが理想です。

 

これは、おそらくどの企業にとってもRPAというものが未だ馴染みがなく、独特の注意点を要するプロジェクトとなるため、

早めにナレッジを吸収しそして歩留まりを良くするためには専任チームのほうが効率的になるからです。

 

 

また、ユーザーとなる現場部門についても、このRPAプロジェクトにおいて担当窓口となる人間は各部署で特定すべきです。

 

ここで特に言っておきたいことは、PM/PMOの役回りも、

可能であればその期間だけはRPAにほぼ特化した形で業務を遂行できるように環境を整えてあげる事です。

 

このPM/PMOの役回りは、現状だと経営企画室やもしくはコーポレートのIT部門が担うケースが多いですが、

今まで見たケースだと、どうも他業務との兼務で指示されることが多いようです。

 

もちろん、最初のPOCや、As-Isの業務分析あたりまでは、兼務であっても進めることはできると思います。

ただし、より開発に近づいたフェーズになると、より開発環境の標準化やリソースアロケーションといった点で、

漏れのない管理が必要となり、そのためにはPM/PMOがRPAに特化した専任チームであることが望まれます。

 

 

1.3 分業のススメ

システム開発の分野において、一概に「分業」が全て正しいという訳ではありませんが、

ことRPAに関して言えば、リソースの有効活用という側面において、組織設計に織り込む必要があります。

 

 

現状、社内リソースにおいてRPAの知見を十分有している社員は、

ビジネスアナリストおよびエンジニア双方において限定的である企業が多いと思います。

 

特にRPAに最も精通しているエンジニアを如何に開発業務に注力させられるか

そして意思疎通の齟齬による出戻りを如何に減らせるかがプロジェクト管理上、重要になります。

 

 

開発そのものではないのですが、エンジニアとの関係の深い工程としてプログラム設計書作成と、テストがあります。

 

一般のシステム開発であれば、SEがその工程に携わる事も多いのですが、

RPAエンジニアが限られている現状を鑑みると彼らをその工程に全投入するのは賢いやり方とは言えません。

 

そこで、開発エンジニアとは別に、プログラム設計書作成とテストを行うチームを設立し分業させるのが有効です。

 

そのチームのメンバーには初期はRPAエンジニア1~数名を入れるのもよいですが、

ゆくゆくはビジネスアナリストの人材を教育してできるようにさせる事が理想です。

 

(参考:分業体制にした場合のRPAプロジェクト体制)

 

 

このプログラム設計書&テストチームですが、

これはRPA開発を担当するエンジニアリソースの確保の観点からも重要ですが、もう一つ別の目的もあります。

 

ビジネスアナリスト/業務コンサルタント側にRPAの動き方・仕様の視点を学ばせて、

To-Beの業務フロー設計のところに役立たせることが狙いとしてあります。

 

このRPAというものは、通常の人間の作業員とは全く異なる「働き方」をするロボットです。

まとまった計算処理は早いですし、24時間働くこともできます。

 

しかし、あいまいな指示系統だとうまく動きませんし、

エクセル内の処理だけでしたらVBAによるマクロのほうが早かったりします。

 

 

このユニークな「RPAロボット」の特徴をしっかり掴んだうえでTo-Beのフローを描いたほうが、

より実現性の高いものが出来、結果出戻りも少なくなることは自明です。

 

特に複雑な業務フローにおいてRPAを導入する段になると、

人間スタッフとRPAロボットとの協業、すみ分け、分担の仕方が、非常に重要になってきます。

 

その時に、しっかりとRPAの仕様を理解したビジネスアナリスト/業務コンサルタントがいるかどうかが、導入成功の鍵を握ると言えます。

 

 

本コラムでは、大規模RPA導入プロジェクトにおける成功の鍵を、「組織体制」の面から述べさせていただきました。

 

それぞれ導入企業によって既存人的リソースの状況も違うので一概には言えないところもありますが、

あとは応用の話になりますので、要点をうまく掴んでいただけたらと思います。

 

多くの会社は、最初のRPA導入業務として経理財務、人事総務、営業事務といったあたりから始めることが多いですが、

まず直面するのがRPAならではの細々とした課題の解決と環境設定、そしてRPAエンジニアのリソース不足です。

 

この点を如何に解消できるかがポイントとなりますが、それには、コーポレートの専任チームを組成することと、

RPAエンジニアを最大限開発にリソース投入できるようにするための人員配置が重要となります。

 

 

本コラムでは「組織体制」からの話となりましたが、

次回コラムでは「運営手法」の面から成功の鍵を探っていきたいと思います。

乞うご期待ください。

 

 

【必見】大規模RPAプロジェクトの進め方 (4/4)

 

 

 

【必見】大規模RPAプロジェクトの進め方 (2/4)

2018.08.14

今回のコラムでは、前回に引き続き、大型RPAプロジェクトを行う際の工程詳細について述べていきたいと思います。

 

前回では、RPA開発プロジェクトならではの特徴と、最初の工程となる「対象業務選出」について簡単に説明させていただきました。

 

(参考)前回コラム:大規模RPAプロジェクトの進め方 (1/4

 

本コラムでは、それ以外の工程についてまずは順を追って説明していきたいと思います。

 

 

RPAプロジェクトの工程

 

参考: RPA導入プロジェクトの工程

 

 

 

工程2. 現状業務分析(As-Is

「現状業務分析」では、選出されたRPA化候補業務について深掘りしていきます。

 

具体的には、現状の作業フローや、発生頻度、リードタイム、業務量等を精査していくことになります。

 

 

このフェーズでは、社内のビジネスアナリスト、外部リソースであれば業務コンサルタントが活躍するフェーズになります。

 

もちろん、実業務を日々行っている現場担当者も知識レベルではできうることではありますが、

フローの書き方など不慣れなところもあるので、ビジネスアナリスト等が担うケースが多いです。

 

 

ただ、こちらのAs-Isと呼ばれる現状の業務分析フェーズですが、あまりにも簡易な作業が対象となる場合、

飛ばしてしまい、次の「業務フロー設計(To-Be)」に飛んでしまうケースもしばしばあります

 

 

例えば、社内システム上の一部入力操作のみをRPA化しようとするような単純なケース場合、

To-Beとなるロボットのフローも容易に想像がつきます。

 

このAs-Isの業務分析は、あくまで次のTo-Beを描くための基礎情報として使うものであり、

To-Beが容易に描けるのであれば、わざわざAs-Isに時間をかける必要はありません

 

PMとしてはこのあたりの柔軟性をもって各案件に接することが求められます。

 

 

一方、人間とロボットの入り混じった、かなり複雑な一連の業務をRPA化しようとする場合

例えば、消費者からの申請書を受け取り、それをシステム入力、さらに上司によるチェック工程が入る、

といった業務となると、やはりAs-Isからしっかりと精査したほうが良いです。

 

上記のような業務となると、OCRといったRPAとは異なる別ツールの導入を併せて検討することになり、

また人間とロボットの分担もしっかりと整理する必要があります。

 

また、そのように複雑な、いくつか作業が繋がってできる業務の場合は、

ロボットを入れることで業務フロー自体が大きく変わる可能性も高いです。

(例えば、人間による都度システム入力から、ロボットによる夜間のバッチ入力に変わる、等)

 

そのようなケースの場合は、やはり手を抜かず、まずは現状の整理から一歩一歩進めていく必要があります。

 

 

工程3. 業務フロー設計(To-Be

こちらのTo-Beの業務フロー設計では、RPAロボット導入後の業務フローを描くことになります。

ここではより分解して述べると、以下に分かれます。

 

3-1. 対象業務のTo-Be業務フロー全体の設計

3-2. 個別システム/IFの画面遷移・操作設計

 

3-1.は、工程2As-Isの業務分析のところでも述べた事と同様で、

対象業務がかなり単純であれば敢えてする必要はありません。

 

この工程が必要となるのは、人間とロボットが複雑に連携するような業務に対してです。

アウトプットのイメージとしては、通常の業務フロー図にロボットの領域が加わったものになります。

 

 

3-2.については、これはほぼどのような対象業務であっても必要になってきます。

会計システム、Webサイト、またはExcelの管理帳票といった、

RPAロボットが触ることになるインターフェースの画面操作、遷移の指示書となります。

 

 

この指示書のイメージですが、各画面の画像を切り取ったものが遷移順に並び、横に補足説明が書いてあるようなものです。

使用されるドキュメントはExcel/PowerPoint/Word等、様々ですが、

こちらの資料を基に、次の工程4.であるプログラム設計書が書かれることになります。

 

 

工程4. プログラム設計書作成

To-Beの仕様が決まったら、次はいよいよプログラムに落とし込む準備に入ります。

工程3までの業務フローでは、まだ「人間側」の設計書であり、「ロボット向け」の設計書とはなっていません

 

前工程で決められたTo-Be業務フローをロボットのロジックに合わせて書き直す必要があります。

 

簡単な例で言うと、forループやif分岐、データテーブル/コレクションと呼ばれる表形式のデータセットの作成、

入力、抽出の仕方などを具体的にイメージしたフローに直すのです。

 

 

また、この工程で、次に必要となる開発/テスト環境の設計も行う必要があります。

実は、RPA開発プロジェクトの現場では、この工程がボトルネックになることが多いです。

 

何故でしょうか。

通常のこのプログラミング設計書の作成はエンジニアの領域であり、システムに詳しい専門職が担当すべき工程です。

 

しかし、前コラムで述べたように、RPA開発エンジニア自体が枯渇している状況になると、

このプログラム設計書作成にリソースを宛がうことが難しくなるのです。

 

 

そうなると、この工程4を飛ばして、

To-Beの業務フローができたらそのままRPAエンジニアに開発依頼をしてしまう誘惑が擡げてきます。

 

しかし、それは後々の不具合の種となり、非常に危険な行為となりますのでお勧めできません。

 

 

このプログラム設計書作成のプロセスは、高度なRPAプログラミング技術は要しません。

しかし、開発に使用するRPAツールの最低限の知識は求められます

 

UiPathであれば、UiPathの仕様、BluePrismであればBluePrismの各機能の基礎知識が求められます。

 

ツール間でそれほど違いはないのですが、やはり、そのあたりを踏まえているのと踏まえていないのとでは、

その後の開発者にとってやり易さが変わります。

 

特に、RPA開発エンジニアが枯渇している昨今の現状においては、ビジネスアナリスト、

外部だと業務コンサルタントと呼ばれている人たちが、この領域まで手掛ける必要もあると考えるべきでしょう。

 

 

工程5. RPA開発/設定

プログラミング設計書ができたら、RPAエンジニアによる開発に進みます。

 

この工程はRPAの世界の中では開発とは呼ばずに「設定」と呼ぶケースもあります。

 

ここで注意する点としては、実際に業務行う現場環境と開発/テスト環境への配慮が挙げられます。

 

何度も言っていますが、RPAは、最終的に現場の業務担当者の代わりにロボットが行うソリューションです。

 

つまり、現場環境で動作できる事が必須要件となります。

しかし、実際にRPAを開発するエンジニア部隊が必ずしも業務担当者と同じシステム環境にいるとは限りません

 

 

そもそも、開発をアウトソースやオフショア等別環境で行う場合、ネットワーク環境も違いますし、

端末(ローカルPC)作動型のRPAを作るのであればPC自体の設定も異なります。

 

このあたりは、何回か開発をすれば小慣れてくると思いますが、最初は特に出戻りが無いように注意が必要です。

 

 

この開発工程については、自社で行わずに、外部のベンダーの活用を検討している企業も多いと思います。

 

それ自体は、否定はしませんが、RPAのプログラムは、

そもそも、一旦開発した後もちょっとした改修が頻繁に発生するものです。

 

 

小さな修正・メンテナンスレベルまで外注しているとコスト面での負担が増えることになりますので、

大なり小なり社内リソースでプログラミングできる体制があったほうが望ましいと言えます。

 

この際に、前工程のプログラム設計書作成において「設計書フォーマットの標準化」が為されていると、

各段に効率が上がりますので、ベンダーや社内開発チームなど複数の開発チームが存在する場合であっても、

設計書フォーマットは統一化することを心がけてください。

 

 

工程6. テスト/修正

開発が終わったら、テスト段階に入ります。

 

これは開発者自身で行うべき単体テストのレベルから、現場担当者が検証すべきユーザーテストまで渡ります。

ここでも重要なのは、先述したように、テスト環境と、実際に動かす現場環境が合っているかどうか気を付けながら進めることになります。

 

 

また、納期重視でクイックな開発がRPAは求められますので、自然と、テスト段階での微修正が発生してしまいがちです。

その場合、やはりクイックにテスト後直せるように事前にコミュケーションをとっておくことも重要です。

 

 

今回のコラムでは、比較的大きなRPA開発プロジェクトにおいて、

各工程の説明および、留意点を述べさせていただきました。

 

次回コラムでは、いよいよ、

開発プロジェクトを効率よく進めるために特にRPAならではで気を付けるべきことを挙げていきたいと思います。

 

乞うご期待ください。

 

 

【必見】大規模RPAプロジェクトの進め方 (3/4)

 

 

 

【必見】大規模RPAプロジェクトの進め方 (1/4)

2018.08.13

今回のコラムでは、比較的大規模にRPAの導入を検討しているケースにおけるプロジェクト進行の要点をまとめていきたいと思います。

 

 

大規模プロジェクトとなった場合、求められるRPA対象業務数(案件数)も膨大となり、

また関係してくる各部署ステークホルダーも複雑になります。

 

小さな目のプロジェクトであれば、まずは一部の部署だけでPOCを行って、

徐々に対象領域を増やしていく、、といった順序でも許容されますが、

大規模プロジェクトとなった場合、「●月まで●●案件のRPAプログラムを完成し、●●時間を削減せよ

というような命題が既定としてあり、その目標を完遂するための効率的なプロジェクト運営が求められる傾向にあります。

 

 

RPA開発プロジェクトの特徴

 

基本的にRPAの開発プロジェクトも、他のシステム開発案件と同様の工程を経ます。

従って、このRPAプロジェクトを進める上での要諦も、通常のシステム開発プロジェクトと大きな差はありません。

 

ただ、いくつかのポイントについてはRPAならではの特徴が存在します。

 

 

特徴1: 早期実現の要請

一つは、RPAというものが早期の実行を要求される傾向にあることです。

 

他の大規模システムと違い、RPAというものは、そもそも今までローカルPCで行っていた単純作業を自動化させるのに特化したツールであり、

経営者側とすれば早期の実行による社員の業務負荷軽減を期待してしまうものです。

 

RPAは大規模システムのような高度で入り組んだシステム設計を必要とせず、

それよりも納期の速さが故にいかに簡略化してクイックに開発を進められるかが肝になります。

 

もちろん、要件定義やプログラム設計書レベルのものは必要ではありますが、

例えば、テスト仕様書等時間をかけてじっくり作って準備するよりかは、

ユーザーテストをして早めに修正点を洗い出し完成に持っていくような柔軟性が求められます

 

 

特徴2: 低コストで開発 & 社内教育の必要性

もう一つの特徴は、RPAの案件というものは、開発予算が低めに抑えられる傾向にあり、

エンジニア人材の確保がボトルネックになりがちだということです。

 

RPAはもともと、システム要件とならないような細々とした多種多様な業務の自動化が求められる領域であり、

開発対象となる案件は一つ一つは簡易で小さなものであってもその数は膨大となる傾向にあります。

 

一案件で見るとそれによる人間の業務低減効果は限定的であり、一件一件低予算で開発をこなさなければ、

経済合理性が成り立たない状況になります。

 

従って、RPAのプロジェクトの場合、最初の時期は外部パートナー会社の協力を仰ぐことになりますが、

ゆくゆくはユーザー自社の社員で開発・運用をしていくことが求められるケースが多いです。

 

 

そうなると、社内エンジニアの「教育」という点が重要になってくるわけですが、このRPA、世の中に出回る多くのツールは、

そもそもの思想として現場担当者レベル(人事や経理など)でも自分達で「作れる」ことを目指し、

そのためのUIになってはいますが、その割には難しいのが、何と言いますか、絶妙なところです。

 

特に大規模RPAプロジェクトになると、オブジェクト指向に基づいたモジュール管理、統一ルールの徹底などが求められるため、

やはり社内リソースに任すにしてもIT部門の様な専門のエンジニア職のほうが望ましいと言えます。

 

 

特徴3: エンジニア/RPAに強いビジネスアナリストの人材枯渇

上記で述べた、エンジニアによる開発予算が抑えられがちであることとも関係していますが、

もう一つのRPAの特徴として、人材、特にエンジニアの人材の確保がボトルネックとなる傾向が挙げられます。

 

 

RPAは比較的新しい技術であり、現在世の中には、UiPathBluePrismBizRoboWinActorといったツールが出回っておりますが、

その扱いに熟練した技術者、エンジニアは、まだその需要に対して十分な供給を果たせていません。

 

エンジニアとしてもRPA開発ツールが複数存在するために、

UiPathはできるけどBluePrismはできない。。。

といったケースが出てきてしまい、ますます特定のツールに特化した技術者を確保するのが難しい状況にあります。

 

 

また、この人材の枯渇でいうと、To-Beの業務フローを書くビジネスアナリストにも同様のことは言えます。

 

ビジネスアナリストは厳密な意味ではエンジニアではありませんが、ことRPAのプロジェクトの場合、

業務フロー設計者もRPAロボットの知識が求められます

 

これは考えてみれば当然で、RPAでは今までの通常の人的リソースとは全く異なった特徴を持つ「ロボット」に業務を肩代わりさせることになる訳であり、

つまり、その「ロボット」の動き方について専門の知識を十分持っていないとTo-Beのフローが書けないからです。

 

そのような「RPAのエンジニア知識」を有したビジネスアナリストは、残念ながら、現在まだ多くは育っておらず、

リソースの確保が課題となっています。

 

このビジネスアナリストのリソース問題は、RPAの対象が簡易な単純作業だけの段階であれば、顕在化しないと思います。

 

しかし、そのような小さな単純作業のRPA化フェーズが終わり、

より高度な、ロボットと人間の分担が入り組んだ複雑な業務フローを組むようなケースになってくると、

切実な問題として直面することになると思います。

 

 

RPAプロジェクトの工程

 

次に、より具体的にRPAを導入する際の個別工程について話していきたいと思います。

比較的大規模なプロジェクトにおけるRPA導入のステップと関係ロールを下記に記しました。

 

まず、こちらの各工程について簡単に説明したいと思います。

RPAでは先述したように、早期の実行が求められることもあり、

大きめのプロジェクトであっても通常のシステム開発よりも簡略化される傾向にあります。

 

 

参考: RPA導入プロジェクトの工程

 

 

工程1. 対象業務選出

ここでは、RPA対象となる業務をリストアップする、アイデアジェネレーションのフェーズになります。

 

この工程では、実業務をしているユーザー部門の担当者が主役となりますが、

RPAの知識が無いケースが殆どですので、事前にビジネスアナリストもしくは業務コンサルタントが入って、

RPAとはどのようなものか、どのような業務がRPAに向いているのか事前に勉強会を開いておくことをお勧めします。

 

 

一旦、コツがつかめれば、現場担当者から能動的に様々なロボット化のアイデアが出て来ると思います。

 

ただ、それでもやはりアイデアが出てこない場合は、まず各現場部署に自身の業務の棚卸し(リスト化)をさせて、

そのリストをもとにビジネスアナリスト/業務コンサルタントとディスカッションセッションを設けても良いかもしれません。

 

 

あと、この工程で大事なことは、「ざっくり」で構いませんので、

月間業務量、頻度、定型作業の割合、使用アプリケーション等、「RPA化との相性を測れる情報」も記載しておくことです。

 

その情報により、挙げられたリストの内どの業務からRPA化の手をつければいいのか判断ができます。

もちろん、最初に手をつけるべきは「簡単な割に削減効果の大きい業務」からになります。

  

  

今回のコラムでは、比較的大きなRPA開発プロジェクトの特徴と、

最初の「RPA対象業務の選出の工程」について説明をさせていただきました。

 

次回のコラムでは、さらに他の工程の説明および、留意点を述べていきたいと思います。乞うご期待ください。

 

 

次のコラム:【必見】大規模RPAプロジェクトの進め方 (2/4)

 

 

 

【BPO×経理】経理業務とBPOにおける直近の情勢と課題

2018.08.10

BPOサービス市場

 

経済産業省が2015年にBPO(アウトソーシング)サービスに関する資料を公表していますが、

それによると日本におけるBPO市場規模は、1,600,000百万円となっています。

 

業務別の市場規規模は以下のとおりとなっています。

 

 

(間接業務)

コンタクトセンター 360,000百万円:コールセンター

ヘルプデスク 126,240百万円:問い合わせ対応

フルフィルメント 30,400百万円:EC販売、在庫管理、ピッキング

人事 80,000百万円:給与計算、社会保険手続き

福利厚生 36,800百万円:福利厚生業務

総務 12,480百万円:備品管理、文書管理

経理 41,280百万円:記帳代行、支払管理、債権債務管理

 

(直接業務)

購買・調達 3,520百万円:購買調達

営業 68,800百万円:営業代行

コア部門単純業務 564,800百万円:企業のコア部門が行う業務

業界固有業務 62,400百万円:特定業界の独自業務

その他 213,280百万円:包括的なサービスなど

 

 

市場規模は2022年までの年間平均成長率は3%前後という調査結果もあります。

 

また日本はアメリカに比べ、コア業務への集中を意図したBPO等の活用が遅れているため、

日本でのBPO市場は拡大を続ける見込みです。

 

 

なぜBPOサービスの必要性が高まっているかというと、働き方が変わったからということに尽きると思います。

これまでの、一人当たりのアウトプット量を最大化させる、高度成長期の製造業のような働き方から、

クリエイティビティが求められる働き方に変化しつつあります。

 

 

2014年に経済産業省から「サービス産業の高付加価値化に関する研究会の報告書」が公表されました。

 

この報告書が作成された背景として次の記載があります。

 

 

我が国のサービス産業は、GDPの約7割を占め、雇用の面からも大きなウェイトを占めており、経済全体に与える影響が高まっています。我が国経済の再生やデフレ脱却のためには、サービス産業の生産性向上・高付加価値化が必要です。日本再興戦略(平成256月閣議決定)においても、「付加価値の高いサービス産業の創出を図る」との方針が示されています。

 

 

また、サービス産業の生産性向上・高付加価値化の実現に向けた主な検討事項の一つとして、

「ビジネス支援サービスの活用促進」が掲げられています。

 

その調査報告コメントとして次の記述がありました。

 

 

企業においては、BPO サービス等の外部リソース(ビジネス支援サービス)を戦略的に活用することで、当該業務のコスト削減のみならず、ビジネスプロセス全体の見直し等につながると言われている。実際、ビジネス支援サービスを利用したサービス事業者の多くは、経営資源のコア業務への集中、コスト削減、業務の効率化といった生産性・付加価値向上の効果を得ている。ビジネス支援サービスは、それ自体が成長の期待できる一つのサービス産業であるとともに、他の産業の生産性への波及効果も大きく、これを促進していくことはサービス産業の高生産性・高付加価値化のための重要な手段の一つと考えられる。

 

 

事業を進める上では様々な「やるべきこと」が出てきますが、時間は有限です。

BPOサービスによって優先順位を明確化し、「しないこと」を積極的に決めることが重要です。

 

 

BPO導入の目的(経理財務業務の場合)

 

経理財務業務にBPOを導入する目的は、

「経営資源(人的リソース)をコア業務に集中させる」

「コスト削減」

「業務プロセスの標準化」

「社員退職などに対する業務継続性の確保」

などがあります。

 

どの目的も重要ですが、BPO導入の際は、どの目的を最重要目的とするのかを明確に決めておくことが大切です。

 

 

「経営資源(人的リソース)をコア業務に集中させる」という目的の場合、

経理財務部門におけるコア業務、ノンコア業務の分類は概ね以下のように区分できると思います。

 

 

(コア業務)

  • 管理会計による経営分析
  • 原価計算制度の構築
  • 予実管理
  • 事業計画作成
  • 資金調達戦略策定
  • 投資戦略策定など

 

(ノンコア業務)

  • 会計ソフトへの会計記帳
  • 請求書発行
  • 取引業者への支払
  • 経費精算など

 

 

現状の業務ではノンコア業務をこなすことで手一杯で、

コア業務を行えない又はコア業務を習得するための時間がないなどの課題がある場合、

BPOを導入することでコア業務に集中できたり、コア業務を習得するための時間が確保できます

 

これによって、経営判断を行うために必要な情報を管理会計で整備する、

原価管理を適切に行うための原価計算制度を構築する、

企業価値をあげるためのファイナンスなどのノウハウが社内に蓄積するため、

他社との競争優位性が高められることが期待できます。

 

 

経理財務部門の課題

人材不足は他の業種同様、経理財務部門にとっても生じています。

 

経理財務部員が1人程度の中小企業、経理財務部員育成途中の新興上場企業、大企業の子会社で経理財務部員が少数の会社などの会社で、

ベテラン人員が退職すると、経理財務部門は混乱し、在職者に過度の負担がかかることになります。

 

特に中小企業などは、業務が標準化されておらず、マニュアルも十分に整備されていないブラックボックス化状態であることが多いです。

 

十分な引継ぎを受けないまま、在職者によってさらなるブラックボックス化が図られ、

ルーティンワークに飽き、他の会社に転職を考えるようになる悪循環が生まれます。

 

退職者の穴埋めで社員を採用する場合、ある程度の経理財務知識がある社員を採用するには、

多額のコストがかかることが多いです。

 

 

このような課題を解決するソリューションの一つにBPOがあります。

 

BPOを導入するために業務の標準化を図り、マニュアルを整備する、

そしてノンコア業務であるルーティンワークはBPOすることで、経理財務部員がコア業務に注力できる環境が整います。

 

 

コア業務に注力できれば、本人のスキルアップや、やりがいにつながり、

経理財務部門の悪循環から解放されることが期待できます。

 

 

経理財務部門で発生する不正

経理財務部門で発生する不正行為の一つに現金預金の横領があります。

 

横領事件で逮捕されることが多いのは、「経理」として働いていた人です。

 

ニュースになる横領事件では、億単位の金額が横領されていることが多いですが、

その金額がすべて返済されることは少ないようです。

 

横領被害は会社にとって大きな損失になり、取引先や利害関係者への信頼にも影響することになります。

 

 

大企業などでは、経理財務部門の職員が複数人いるため、

「複数の人が業務を行っている」

「一定期間で配置転換がある」

「上司の適正なチェックが入る」

「経理(会計記帳など)と財務(現預金の入出金)が分離されている」

などの環境があるため、比較的横領などの不正は発生しにくいです。

 

 

一方で中小企業などの経理財務部門は1人で経理と財務を兼任しているケースが多いため、

他の人の目が届かず、チェック機能が働かないことがあります。

このような環境下では、横領などの不正が発生しやすくなります

 

 

このように不正が発生しやすい環境から不正が発生しにくい環境にする場合にもBPOは有用であると考えます。

 

例えば、経理(会計記帳など)は経理職員が行い、その承認は顧問の会計事務所に依頼します。

 

一方財務は、BPO会社職員が行い、その承認はBPO会社職員の上席者が行うことにより、

経理と財務が分かれさらに承認者も異なるので統制が働き、不正が発生しにくい環境になります

 

このように不正防止策の一つとしてもBPOは活用できます。

 

上記のように、BPOを経理財務部門における課題解決や不正防止策とし活用しつつ、

コア業務に注力することによって、他社との競争優位性を高めたり、

経営効率を上げていくことが大きく期待できます。

 

 

 

【導入事例】大企業人事業務におけるRPA活用事例

2018.08.09

 今までのコラムでは、中小企業経理業務のRPA活用事例を紹介しましたが、今回は異なる視点でRPAの活用を見ていきたいと思います。

 

中小企業経理業務におけるRPAの活用事例(二)

 

 業界や具体的な業務にかかわらず、RPAが最も得意な業務は大まかに二つ共通の特徴があります。

 

すなわち、

①大量に繰り返される作業

②ルールが明確化されている作業

です。

 

 

更に、365日×24時間稼働可能、人間より精度が高くコストが低いなどのメリットも挙げられます。

 

経理業務の中に、RPA導入にとても向いている業務がたくさんあるのことを既に過去のコラムで紹介しました。

 

経理業務をRPA化すれば、費用対効果は抜群であることは言うまでもないでしょう。

 

では、「せっかくRPA導入するのであれば、経理以外の業務もRPA化すればよいのではないか?」という考えも自然に出てくるはずです。

そして、今回は人事業務のRPA活用事例を見ていきましょう。

 

 

 企業Aは国内の総合ITグループです。

業務範囲はECサイト、金融、保険など様々で、従業員数5,000人以上の規模になります。

このような規模にもなると、たとえとてもシンプルな業務であっても毎月大量に単純・定型作業が発生することは想像しやすいですね。

 

例えば、「異動情報登録」という作業は月に2,000~3,000件発生しています。

この「異動情報登録」業務は自然、A社のRPA導入対象業務となります。

では、まずこの業務から見ていきましょう。

 

 

異動情報登録業務

 A社は従業員が多いため、毎月人事異動が頻繁に発生しています。

特に毎年3月や9月は集中的に発生するため、異動情報をシステムに登録するだけで人事部門は大量なリソースを割かれます。

 

業務内容を簡単にいうと、以下の図1のようになります:

 

 

まず、毎月各部門から異動情報が人事部あてに届きます(人事稟議などもありますが、本業務では考慮しません)。

 

人事部が各部門からの情報を全てまとめて、その後一項目ずつ人事システムに入力します。

 

これがこの業務のすべての内容です。

 

業務の内容はとてもシンプルで、イメージしやすいでしょう。

ただし、量が多くなると、とてもハードな作業になります。

 

従業員のスキルによって、一件の登録は5分~10分かかります。

 

A社の場合、月に2,000件あると計算すると、毎月優に300時間を超える作業時間が発生するでしょう。

 

この業務をRPA化すると、300時間が10時間以内になると予想されます。

RPA化すると、業務の流れは以下の図2のようになります:

 

 

各部門がもともと人事部あてに送信していた異動情報を共有フォルダーに入れることになります。

 

そして人事部の代わりに、RPAが毎日決まった時間で共有フォルダーの中のファイル(エクセルファイル)をチェックし、

それに基づいて、自動的に人事システムにログインして、一行一行、項目を入力していきます。

 

 

もちろん、処理できないイレギュラーな事態が発生することも想定します。

 

例えば情報が間違っていることや、そもそも必要な情報がそろっていないなどがあると考えられます。

この場合、RPAが自動でイレギュラーの情報を保存しておき、処理が終わった後に人事部の担当者にメールを送信します。

 

このプロセスはすべてRPAが実行するので、人間による関与は全く必要ありません。

人事部の担当者がRPAからの通知メールを受け取った後、イレギュラーになっている項目をチェックし、

手入力が必要か該当部署に再度確認する必要があるかなどを見て、それぞれ実行します。

 

処理時間はおよそ10時間以内で終わるでしょう。

 

 

 もちろん、実際RPAを導入する際には色々と細かい点に注意しなければなりません。

例えば、元々人間が入力していた時は、各部署からの異動情報の書式は少しずれても大した問題にはなりません。

 

情報さえ合っていれば人がそれを認識し、修正することが簡単にできます。

ただし、RPAとなると、この人間にとって簡単なことができないのです

 

そこで、フォーマットに合わせた書式を使ったり、RPAが読みやすいフォーマットを作ったりすることが必要です。

 

 ここで、もう一つの疑問があります。

A社の人事システムに「まとめてインポート」のよう機能はないでしょうか?

あるとしたらなぜ使わないでしょうか?

 

実際のところ、A社が使っている人事システムは「まとめてインポート」機能はあります。

 

ただし、この機能を使うには非常に複雑なマクロが含まれるフォーマットを作る必要がありますし、

インポートする際にうまくいかない場合が多発します。

 

システムを変える考え方ももちろんありますが、コストの問題があるだけでなく、

この膨大なシステムを変えること自体が極めて難しいでしょう。

 

こういう状況では、RPAによりロボットが人の代わりに作業することが最も現実的な選択肢になるでしょう。

 

 

契約更新業務&兼務発令業務

 「契約更新業務」というのは文字通り、A社の契約社員とアルバイト従業員の契約期間を更新するたびに発生する業務のことです。

 

「兼務発令」はA社の従業員が自分自身のメイン業務以外、他の業務も兼務する場合発生する業務のことです。

本来であれば別業務だが、ここで一緒に紹介する理由はこの二つの業務の基本フローは極めて似ているからです。図3をご覧ください:

 

 

 

この二つの業務がすることは同じフローで表現できます。

さらに、よく見ると、図1と酷似していませんか?

実は、上で紹介した「異動情報登録」ともほぼ同じ流れになります。

 

 

まず各部署から契約更新の情報や兼務発令の情報を人事部がまとめて、

その後同じ人事システムに入力するのです。

 

ここまで来れば、RPA化の基本的な考え方もイメージつくでしょう:

 

 

 

こちらも「異動情報登録業務」と同じ流れになります。

 

まず、各部署が契約更新と兼務発令の情報が記載されているエクセルファイルを共有フォルダーにアップします。

 

そして、RPAが指定された時間にフォルダーからエクセルファイルの情報を読み取り、これらの情報を人事システムに入力します。

 

処理が全て完了したら処理結果やイレギュラー情報をメールで人事部の担当者に送信をします。

最後に、担当者はRPAが処理し切れなかった項目を手作業でカバーします。

 

 

ここで、RPAの一つの大きいメリットをお伝えいたします。

それは、ロボットの「再利用」です。

 

業務フローが共通しており、操作対象となるシステムも同じため、ロボットの設計図もほぼ変わりません。

 

そのため、例えば「異動情報登録業務」のロボットをまず開発したら、

その次の「契約更新」と「兼務発令」業務の開発がより簡単になります。

 

なぜなら、「異動情報登録業務」ロボットの「パーツ」を改造すれば、

「契約更新」と「兼務発令」のロボットにも使えるからです。

 

改造するポイントとしては、例えば、入力する項目、ボタンの位置、アクセスするページなどがあります。

 

もちろん、各業務に対してそれなりの工夫は必要ですが、ゼロから開発するよりは簡単になります。

ここの「簡単」はコストが低くなることと、時間の短縮を意味する場合が多いです。

 

 

まとめ

 今回は三つの人事業務を中心にRPAの運用を紹介しました。

 

ポイントとしてはまず、単純な業務でも大企業にとって大きい削減効果があります

 

また、類似する業務を多くRPA化すればするほど、1業務当たりの導入コストが低くなり、さらに費用対効果が高くなります

 

本文のA社のように、異なる業務で開発済のロボット「パーツ」を再利用することができるからです

 

A社の場合は最初からこの3つの業務をRPA化前提で導入し、

その後「パーツ」が活用できることに気づきましたが、もちろん、まず1業務をRPA化し、

他に類似した業務を社内で探すこともできるでしょう。

 

この場合、ロボットの「パーツ」が様々な部門と業務で活かせるようになると思います。

 

 

 

経理財務業務におけるRPA導入機会vol.3

2018.08.08

はじめに

RPARobotic Process Automation-ロボットによる業務自動化)は、近年のBPOの最前線でよく聞かれるワードの一つです。

 

これまで人間が行ってきた定型の作業や業務をPC内のロボットが仮想知的労働者(=Digital Labor)として代行することで、

業務効率と品質の向上、コストダウンが期待できます。

 

ただひと口に「自動化」といっても、

抽象的すぎてどんな業務にRPAを導入できるのかいまひとつ想像がつきにくいかもしれません。

 

今回は多くの企業で実際にRPAの導入が進められている業務のうち、

経理財務業務でのRPA導入機会を前回に引き続いてご紹介させていただきます。

 

■前回記事

経理財務業務におけるRPA導入機会【vol.2】

 

 

導入が検討できる業務

今回はこれまた手作業が多く発生しがちな「請求書発行~入金消込業務フロー」の自動化を検討してみます。

 

この部分は債権管理の観点において重要な業務ですが、その実多くの手作業が発生し、

ヒューマンエラーのリスクを抱えている会社様もいらっしゃるのではないでしょうか。

 

この手のヒューマンエラーは会計上の問題だけでなく、顧客からの信用問題に直結するため、

業務の正確性が多分に求められます。

 

 

また請求書の性質上、作業が月末/月初に集中し業務の偏りが発生しやすいため、

現状のフローの中だけでは業務効率化が難しい部分でもあります。

 

このような【請求書発行~入金消込】業務はRPAを駆使して、効率化してしまいましょう!

 

 

 

 

  • 請求書発行~送付

各部署から日々発行される請求書。

 

11件には大した労力がかかりませんが、期日前になって申請が集中し、

その分一時的な労働力がつぎ込まれていることが多いのが事実。

 

その業務を効率的かつ正確に処理するには、自社の請求書発行の仕組みとそれに適合するロボットの開発が肝要です。

 

 

【請求書発行システムを利用している場合】

手軽かつ安価な業務効率化の手段として活用されることの多いクラウド型請求書システム

導入を進めている企業様も多いのではないでしょうか。

 

近年の請求書発行システムは、作成から送付まで安価で手広いサービスをウリにしているところが多く非常に便利です。

 

サービスの内容は各社とも様々。

中にはWEBバンキングや会計ソフトとの連携が可能なアプリケーションも存在しますが、

高価であったり、対応ソフトが限られていたり(全ワークフローを同系列のシステムに組み替える必要があるなど)するため、

今回は請求書発行~送付まで対応した一般的なクラウドサービスの利用を想定します。

 

 

各社員が販売明細書や売上報告書を基に顧客宛ての請求書を発行します。

多くのアプリケーションでは請求書が発行された段階で送付手続きが進行するため、

非常にスムーズに請求書を作成/送付することができるでしょう。

 

後段でロボットが参照し、そのデータを基に入力/照合を進めていくため、

請求書フォーマットはある程度統一されたものを使用できるように、あらかじめ各部署ですり合わせが必要です。

 

また、入力時も金額差異などが発生しないように、細心の注意を払って入力を進めていきましょう。

 

 

【紙ベースの請求書を発行している場合】

中小企業の中には請求書を紙ベースで発行し、直接顧客のもとへ発送しているところも多いでしょう。

 

自動化を検討する際は「Excelで請求書を作成し、電子ファイルで送付する」という手段が考えられます。

 

Excelで作成すれば、各請求書をロボットが確認し後段の作業に必要なデータを抽出しやすく、

また電子ファイル送付なら、自動メールをロボットにプログラムしておけば、簡単に発行~送付までを効率化できます。

 

具体的には、まずフォルダを作成し、そこに当月分の請求書をまとめて保管しておきます。

次にロボットが決められた日時にそのフォルダを巡回するように設定し、請求書内容を確認。

 

顧客IDなどから別途作成する「顧客マスタ」と自動で紐づけ、

送付先アドレスを抽出し自動的にメールを送付させる仕組みを作ります。

 

仕組み自体は簡単なので、手っ取り早く業務効率化が図れますが、

反面請求書データ送付を認めない(あるいは推奨されていない)企業が一定数存在するのも事実。

 

前提として請求書送付について双方の合意が必要になります。

電子ファイルでの送付が困難な顧客へは、郵送での対応をするなどしましょう。

 

 

  • 仕訳(売掛金計上)

発行された請求書を参照し、会計ソフトに売掛金として計上します。

 

 

【請求書発行システムを利用している場合】

発行の手続きが完了した請求書をロボットが確認し、会計ソフトに1件ずつ売掛金を計上していきます。

(この時点で請求書内容に不備がないように、あらかじめシステム上に承認機能を付与しておけば安心です。)

 

この際会計ソフトと連動するようにあらかじめ、

システムマスタ上と会計ソフト上の企業名などの表記を統一しておく必要があります。

 

 

自社独自の決まりで、より詳細な情報を会計ソフトに入力する必要がある場合(例えば金額の内訳入力など)は、

システムのフォーマットを変更させる、あるいは「顧客マスタ」から追記情報を取得/入力するなどで対応が可能です。

 

ただし、あまりに多くの例外的処理をロボットに実行させようとすると、必要なロボット数が増えてしまいます

 

費用対効果を考え、場合によっては例外処理を手作業業務として残し

定型化が可能な大部分の業務を自動化する方法をとるなどして、検証を進めていく必要があります。

 

 

【紙ベースの請求書を発行している場合】

フォルダに集約された請求書から必要情報を取得し、会計ソフトに転記していきます。

基本的にはシステムを利用している場合と同様です。

 

売掛金計上が済んだ請求書には、請求書内に「計上済みフラグ」を自動的に立てておきます。

これは次回以降ロボットが作動しても、二重計上をしないようにするためのロジックに必要となってきます。

 

 

  • 集計

発生月ごとに請求書発行一覧を作成します。

この請求書発行一覧上で債権管理を行います。

 

後段の「入金消込」時には、入金のあったものから明細を消し込んでいきます。

 

 

【請求書発行システムを利用している場合】

各社が展開するサービスの中には、WEBバンキングと連動し、

システム上で入金消込を実施できる機能を持ったものも登場しています。

 

しかし自社システムでそういった機能がない場合は別途一覧形式で集計する必要があります

幸い多くのクラウドサービスにおいて、任意の期間で発行された請求書情報をCSVファイルで取得できるので、作成自体は手間になりません。

 

その他必要な情報は「顧客マスタ」を参照し、付与させます。

 

 

 

 

【紙ベースの請求書を発行している場合】

こちらでは、フォルダに集められた請求書の内容をロボットが確認して一覧表を自動作成します。

 

売掛金計上が済んだ請求書から「金額」「顧客ID」「顧客名」などを抜き出し、Excelに反映していきます。

 

 

  • 入金消込

WEBバンキングを参照し、入金のあった請求書を消し込んでいきます

 

 

【請求書発行システムを利用している場合/紙ベースの請求書を発行している場合】

ロボットがWEBバンキングの入金情報を取得し、

請求書発行一覧から該当請求書を入金済みとして消し込んでいきます(入金日を入力)。

 

この際注意しなければならないのは、WEBバンキングに登録されている口座名の表記です。

 

口座名の多くは半角カナで表記されていることが多いので、

そのままではロボットが請求書発行一覧と照合することができません。

 

そのため、あらかじめ「顧客マスタ」にそれぞれWEBバンキングでの名称を入力しておき、

入金消込実施時に参照させる必要があります。

 

 

また、請求書内容によっては手数料のやり取りから振込金額が不一致となる場合もあります。

 

そういった場合は、ある程度の金額幅をロボットに設定し、

入金消込を実施させることも検討する必要があるかもしれません。

 

一定期日を以っても入金がない請求書については、自動でアラートを飛ばし通知し、

催促対応を実施することも可能です。

 

 

  • 仕訳(売掛金計上)

 

【請求書発行システムを利用している場合/紙ベースの請求書を発行している場合】

請求書発行一覧を参照し、入金消込が済んだ明細から、売掛金消込を実施していきます。

 

こちらは、②で計上した売掛金を消し込んでいくだけなので、同様のロジックでロボットに実施させることが可能です。

 

ただし一連の業務において、都度人間の目で適切な処理がなされているか確認し、正確性を担保することが肝要です。

 

 

さいごに

今回のコラムでは経理財務業務におけるRPA導入機会をご紹介しました。

 

このほかにも人事/総務部門などのバックオフィスでの活用が進んでいます。

RPA導入時まず検討するべきは、

 

  • 手作業で多くの業務時間を要しているところはどこか
  • 一連の業務を定型化できるか、例外処理はあるか
  • 自動化によりどれだけの労力/業務時間を削減できそうか

 

という観点での業務内容の見直しです。

 

そのため開発の前段階として「業務の棚卸」を実施していくことになります。

 

今すぐロボット開発/導入は無理でも、一度自社の業務フローを可視化することは、

業務効率化の第一歩です。

 

この際にぜひ一度検討してみてはいかがでしょうか。

 

 

 

【UiPath小ネタ集】開発で使用する関数Tips

2018.08.07

今回はUiPath開発中によく使用するアクティビティや関数を紹介しようと思います。

 

 

A.ファイル操作関連

ファイルやフォルダを操作するアクティビティは、アクティビティツリーの「System―File」の中にあります。

 

 

これらのアクティビティを扱うためには、ロボットが現在どのフォルダ上で作業をしているか

また、対象となるファイルが、どのフォルダ内に存在するか、意識する必要があります。

 

 

A-1 カレントフォルダ取得

ロボットが現在どのフォルダ内で作業をしているかを調べるには、Directory.GetCurrentDirectory関数を使用します。

この関数は、現在ロボットが作業場所としているフォルダのパスを、String型で返してくれます。

下図は、「C:\tmp」フォルダ内のXAMLでロボットを動かしている例です。

 

 

Dirctory.GetCurrentDirectory関数で得られたカレントディレクトリパスが、

Write Lineアクティビティにより、Outputパネルに出力されました。

 

 

A-2 フォルダ移動

Directory.SetCurrentDirectory関数に、引数でフォルダパスを与えてあげると、ロボットの作業場所をそのフォルダに変更することができます。

 

この関数は、別のフォルダに移動するだけで、値を返すことはしないので、

先ほどのGetCurrentDirectory関数と同様にAssignアクティビティで使用しようとすると、エラーになってしまいます

 

このような場合は、Assignアクティビティの代わりに、Invoke Codeアクティビティを使用するとよいです。

 

 

1つめのWrite Lineアクティビティでは、「C:\tmp」というカレントディレクトリパスが表示されています。

 

Invoke Codeアクティビティ内で実行されたDirectory.SetCurrentDirectory(“Folder A”)関数により、

カレントディレクトリが「C:\tmp\Folder A」に変更されたことが、2つめのWrite Lineアクティビティにより確認できます。

 

 

A-3 ファイル一覧、フォルダ一覧取得

ファイルの一覧を取得するときは、Directory.GetFiles関数を使用します。

 

対象となるフォルダを引数で与えれば、そのフォルダの中にあるフォルダは除いて、ファイルのみを取得してくれます。

 

ファイルは1つとは限りませんから、ストリング配列型で結果を受け取ることになります。

下図のようにファイルとフォルダが複数存在するフォルダで実行してみましょう。

 

 

Directory.GetFiles(“C:\tmp”)関数で得られた複数の結果を、For Eachアクティビティにより、

ひとつずつ取り出して、Write LineアクティビティでOutputパネルに出力しています。

「C:\tmp」の中のファイルのみが表示されていることがわかります。

 

 

引数を追加することにより、取得するファイル名を指定することもできます

このとき、ワイルドカードを使用できます。

 

 

Directory.GetFiles(“C:\tmp”,”*docx”)関数により、「C:\tmp」フォルダの中で、

ファイル名が「docx」で終わるものだけが表示されました。

 

第2引数は、あくまでファイル名の指定であって、検索ワードではありません

そのため、「*」を外して、Directory.GetFiles(“C:\tmp”,”docx”)としてしまうと、上記のケースでは、何も表示されなくなります。

「docx」に一致するファイル名しか該当しなくなるからです。

 

 

Directory.GetDirectories関数は、Directory.GetFiles関数とは逆に、フォルダの一覧だけを取得してくれます。

 

 

対象フォルダの指定の仕方や、名前を指定する方法は、Directory.GetFiles関数と同じです。

 

 

B.文字列操作関連

Webやファイルから読み込んだ文字列を操作するときに役に立つ関数を紹介します。

 

 

B-1 トリミング

文字列の前後に余分な空白があるときは、Trim関数で除去できます。

 

下図の例では、最初、「い」と「は」が、それぞれ半角スペースと全角スペースで挟まれていますが、

Trim関数により前後の余分なスペースが削除されることがわかります。

 

 

結果がわかりやすくなるように、Trim関数によりトリミングされた文字列の前後を、「@」で挟んでいます。

 

文字列の前後にあったスペースだけが削除され、文字列の中に含まれているスペースは残されていることがわかります。

 

 

B-2 部分指定

文字列のうち、一部だけを使用したい場合は、Substring関数を使用します。

使用する部分が、X文字列目からY文字だとすると、Substring(X, Y)となります。

ただし、最初の文字は一番目ではなくゼロ番目と解釈されるので、注意が必要です。

 

 

「一二三四五六七」という7文字の文字列の、2番目(ゼロからカウントするため、指定する数字は1)から3文字だけが表示されました。

文字列の最後のZ文字だけを使用したい場合は、Substring関数とCount関数を組み合わせて使用します。

Countは、文字列の長さを計算してくれる関数です。

 

 

「一二三四五六七」は7文字なので、Count関数の結果は7になります。

Substring(4,3)が実行されたため、5、6、7文字目、つまり、最後の3文字が表示されました。

 

 

C.Excel、データテーブル関連

Excelやデータテーブルを扱う際に役立つ関数を紹介します。

 

 

C-1 Excelシート指定方法

通常は、Read Rangeアクティビティを使用する際、

対象ワークシートをワークシート名で指定することが多いと思いますが、ワークシート番号で指定することもできます。

 

 

上図のようなExcelファイルの、すべてのワークシートに対して、同じ作業を行う場合を考えます。

 

下図の例では、for eachアクティビティでワークシート名を順番に指定しながら、

読み込んだワークシートの内容を、output data tableアクティビティでString型に変換してから表示しています。

 

 

同じことをワークシート番号で行ってみましょう。

事前準備として、Excel Application Scopeアクティビティで、対象ワークブックの変数を取得しておきます。

 

Excel Application ScopeアクティビティのプロパティのOutput―Workbookの欄に、

ワークブック変数(WorkbookApplication型)を設定して、値を取得します。

 

取得したワークブック変数に対し、GetSheets関数を使用すると、総ワークシート数を取得したり、

N番目のワークシートを指定したりできるようになります。

 

 

Excel Application ScopeアクティビティのプロパティのOutput―Workbookの欄に、

ワークブック変数(WorkbookApplication型)を設定して、値を取得します。

 

 

C-2 Build data tableアクティビティの列の入れ替え

Build data tableアクティビティで列名を指定しながら表を作成している最中に、

列の順番を入れ替えたくなったりすることがあります。

 

しかし、このアクティビティでは、列を追加することはできても、途中に挿入することはできません。

このようなときは、一度UiPath StudioでXAMLを保存して閉じてから、テキストエディタでXAMLを直接編集してしまうと楽です。

 

 

上図のデータテーブルの「失点」列と「得点」列をテキストエディタで入れ替えてみましょう

XAMLをテキストエディタで開き、該当箇所を検索します。

 

 

ちょっとわかりづらいですが、オレンジ色の部分の「失点」と「得点」を入れ替えて保存します。

 

 

UiPath StudioでXAMLを開いてみます。

 

 

「得点」と「失点」が入れ替わりました

 

今回のケースでは、入れ替える列のデータ型やオプションがまったく同じだったので、列名を入れ替えるだけで済みましたが、

データ型やAllow Null等のオプションが違う列を入れ替える際は、それらも入れ替えてあげる必要があります。

 

Build data tableアクティビティで最初から作り直すほうが早い場合もあります。

ケースバイケースで楽な方法で修正するとよいでしょう。

 

 

C-3 データテーブルのソート

データテーブルをソートするときは、DefaultView.Sort関数と、DefaultView.ToTable関数を使用します。

 

 

上図のデータテーブルを、総得点の降順、総距離の昇順、の順でソートしてみましょう。

 

 

上図の2つの式により、ソートされたデータテーブルが作成されます。

 

 

 

C-4 インデックス指定によるデータテーブルの値の取得

データテーブルのX行、Y列目の値を取得する場合、データテーブル変数に対し、Rows関数とItem関数を使います。

XとYはゼロから始まることに注意して使用します。

 

 

 

おわりに

いかがでしたでしょうか。

UiPathで使用できる各種関数、アクティビティの使い方をご紹介しました。

開発のお役に立てれば幸いです。

 

 

 

日本型RPAとは――考察と事例

2018.08.06

ここ数年で欧米を中心に浸透し、日本でも2017年には導入企業が相次いだ「RPARobotic Process Automation)」。

 

労働人口の減少に直面している日本にとって、

ロボット(デジタルレイバー)による業務自動化技術であるRPAはぜひとも取り入れたいシステムです。

 

 

産業界からの注目度や導入実績では、依然として海外が先行していますが、

RPAの扱い方には国や地域によって違いがあります

 

理由として、世界各国のビジネス環境や企業文化は当然ですが大きく異なっており、

自動化を求められる作業内容や、それを実現するためのソリューションも同様ではないためです。

 

今回は日本型と呼ばれるRPAと海外との違いについて考察し、具体的な事例についてご紹介していきます。

 

RPAの基本的な仕組み

まず初めに、RPAの基本的な仕組みについて、触れておきます。

 

RPAは、簡単に言うと、人間が行っている定型業務を記憶し、

自動的に24時間365日働き続けることができるロボットです。

 

マクロと違う点として、RPAは複数アプリケーションを使った作業を得意としています

 

例えば、取引先から届いたメールの発注書ファイルを取り出し、データを会計ソフトに反映したり、

販売管理システムへ反映したり、ということが可能となります。

 

 

ただし、イレギュラーに対しては、あらかじめ設定された判定基準、

対処方法によるもののみにしか対応することができず、

導入時の設定やリスクの洗い出しを十分に行う必要があります。

 

人事・経理・総務・情報システムなどの間接部門(バックオフィス)の事務・管理業務、

販売管理や経費処理、アプリケーションをまたがった入力処理などに向いていると言えます。

 

では、具体的に欧米と日本との違いはどのようなものがあるのでしょうか。

 

 

欧米におけるRPA

欧米におけるRPA導入のキーワードは「業務の標準化」です。

 

例えば、多民族国家であるアメリカは多様なバックグラウンドを持つ人々が共通して理解できることが伝統的に重視されます。

 

そのため、ビジネスの場面ではできるだけ文字要素を減らして視覚的にわかりやすく作られたツールや、

業務手順を標準化するといった配慮がなされており、RPAに関してもそうした傾向が見られます。

 

 

具体的には「オペレーター1,000人の入力画面操作を1カ月間すべて記録し、その結果をベースに標準化した手順を整備してRPAで自動実行する」というような導入パターンが多くあります。

 

 

また、欧州は言語の異なる国家の集合体であり、

各国でこれまで運用されてきたシステムを一体化する必要に迫られています。

 

この場合の導入では、システム統合のための時間と費用があまりにも大きすぎると見込まれた際、

各システムの連携を自動化するツールとして、RPAが検討されます。

 

このため、欧州でのRPAは人が介在しない完全自動のシステムとなることが大半です。

 

 

日本におけるRPA

反対に、日本でのRPA導入では「ロボットと人間の共存」が求められます。

 

理由としては、日系企業では“現場”が力を持つとされており、

その背景には絶え間ないカイゼンで品質向上を図っている設計・生産工程や、

個別の事情にきめ細かく応じる受発注業務など、職人芸が尊敬される日本の文化が深く関わっていると考えます。

 

 

また、加えて「終身雇用制のもと、職務内容を厳密に取り決めることなく採用された従業員が、実際の必要に合わせて柔軟に対応してきたこと」なども理由の一つとして挙げられています。

 

現在の仕事を「人間+RPA+機械」という3層構造にしてRPAを使いこなしていくには、

企業全体でRPAに任せられそうな業務を洗い出し、どの業務にRPAを使うのかを決めておくことが重要です。

 

例えば、経理業務で言うなら、日々の伝票入力などのルーチンワークはRPAを導入し、

人間の仕事は収支表をもとにした経営戦略の考察など、企業の経営において本当に必要な情報を提供することに注力させることなどです。

 

ここで、日本におけるRPAと人間の共存事例をいくつかご紹介します。

 

 

・日本生命保険

RPAの導入事例として最も有名なのは、大手生命保険会社である日本生命保険の「日生ロボ美」です。

 

日生ロボ美とは導入されたRPAの名前で、請求書データのシステム入力作業を担当する社員として配属されています。

 

同社では、保険契約者から保険金の請求書が郵送されてくると、

記載されている10桁近くある証券記号番号などを入力して処理しなければならず、現在ではその業務をロボ美が担当しています。

 

ロボ美が入社したことで、それまで業務にあたっていた社員は、証券記号番号をスキャンするだけで良くなりました

 

RPAが社内システムを横断し、データの収集から業務システムへの入力までを代行できるようになった結果、

1件あたり数分かかっていた処理時間が、20秒程度に短縮

 

それで浮いた人的リソースを振り分けて、パターンに応じた柔軟な対応が必要な業務など、

人間でなければできない仕事にマンパワーを割けるようになりました。

 

 

・サッポロビール

サッポロビールでは、国内各エリアに取引先小売業への提案営業支援を行うリテールサポート担当者を配置しています。

 

POSデータの分析は、営業担当者や取引先小売業に対して販売チャンスの発掘や実施した施策の検証などの情報提供を行う上でリテールサポート担当者には欠かせない営業ツールの一つであり、

これまでは各担当者が1社当たり1日約1時間かけて、POSデータを手作業でダウンロードしていました。

 

手作業のためヒューマンエラーもまれに発生しており、さらに当初は数社だったPOSデータ開示も、現在は十数社に増加。

タイムリーな分析を必要とする半面、手作業では追いつかない状況となってきていました。

 

 

そこで、同社ではPOSデータの読み込みにRPAの導入を決定。

その結果、現在は1社当たり平均約30分でダウンロードが可能になりました。

 

 

さらに、手作業では作業工数抑制の観点から一部カテゴリーは週次取得にとどめていましたが、

導入後はすべてのカテゴリーで日次取得が可能となったため、日程が固定している催事についても、

よりきめ細やかな分析や提案が可能となりました。

 

 

RPA導入の注意点

前述のように導入メリットの多いRPAですが、その成功のためには、実際にそのRPAを動かす“現場の理解”が不可欠です。

 

いくつもの企業で導入の成功事例が相次ぎ、その名が普及してきたRPAですが、

企業で働く社員ひとりひとりが、その効果を十分に理解しているとは限りません。

 

しかし、RPAを最大限活用するのに何よりも大事なのが、これまでその業務を行ってきた社員ひとりひとりの知識・経験なのです。

 

 

そのため、導入を決めるにあたっては、RPAに任せる業務内容の洗い出しと同時に、

現場の社員全員への丁寧な説明も必須事項と言えます。

 

「RPAが従業員の作業を奪うのではなく、単調な作業や時間外の作業をRPAに代行させることで、従業員をより付加価値の高い業務へ移行させてくれる」ということをしっかりと時間をかけて説明し、

決してリストラへの布石など、マイナスの効果をもたらすものではないということを理解してもらって初めて、RPAと人間の共存が叶うのです。

 

 

これまで、日本の大手企業を中心に「ロボットと人間の共存」を実現してきた日本型RPAは、

今後中小企業や地方の企業・団体へと、徐々にその活躍の場を広げていくと予測されます。

 

人事、経理、営業サポート……etc. どのような業務においても、

これまで現場で働いてきた社員の方々の知識・経験をRPAによって最大限に活用し、

より働きやすい環境で社員ひとりひとりが輝ける職場になることを期待します。

 

 

 

働き方改革から考えるRPA(Robotic Process Automation)について

2018.08.03

 日本経済再生に向けて、働き方改革がなされている今、働き方改革について学ぶとともに、

それらの動きからRPA(Robotic Process Automation)を生かしていく方法について検討していきたいと思います。

 

働き方改革とは?

 首相官邸「働き方改革の実現」の冒頭には、

 

働き方改革は一億総活躍社会実現に向けた最大のチャレンジ。多様な動き方を可能とするとともに、中間層の厚みを増しつつ、格差の固定化を回避し、成長と分配の好循環を実現するため、働く人の立場・視点で取り組んでいきます。

 

と書かれています。

 

働き方改革は、日本経済再生に向けて、最大のチャレンジであり、

これにより企業文化や風土を含めて改革させるものと考えられています。

 

 

 これらの改革を計画している背景としては、前述の通り日本経済再生に向けてというところが大きいと思われます。

 

日本の労働人口は想定以上に減少していると言われており、生産年齢人口が総人口を上回ると言われています。

 

総人口については、2050年には9000万人前後、2105年には4500万人まで減少すると考えられています。

 

労働力人口については、第二次ベビーブームに生まれた団塊世代のジュニアが労働力として加わったときにピークを迎え、

2060年にはピークの半分に減少すると言われています。

 

 つまり、これらの背景から政府が考えていることは、労働力を増やすために女性や高齢者の積極的な雇用などから働き手を増やすこと。

出生率を上昇させ、未来の労働人口率を高めること。

一人あたりの労働生産率を高めることなどの対策が挙げられています。

 

 

ここで具体的な課題とされているのは、

①正規・非正規の不合理な処遇の差について

②長時間労働ついて

③単線型の日本のキャリアパスについて

などが挙げられます。

 

 ①正規・非正規の不合理な処遇の差については、正規・非正規の不合理な処遇の格差を埋めていければ、

自分の能力を評価されている納得感が醸成され、労働者が働くモチベーションを高め、

それによって労働生産性も向上されると考えています。

 

②長時間労働については、大きくニュースにも取り上げられました。

当時24歳の広告大手新入社員が、過労自殺したことについては、みなさんもご存知かと思います。

残業時間が過労死ラインと言われている月80時間を大きく超える105時間だったと言われている。

また、その大手広告企業では、1991年にも2年目の社員が過労自殺をしており、

2010・2014・2015年と労働基準監督署から数回にわたって是正勧告を受けていました。

 

 このような長時間労働を解決することにより、健康の確保だけでなく、仕事と家庭生活との両立、

つまりワーク・ライフ・バランスが改善し、女性や高齢者も仕事に就きやすくなり、

労働参加率向上に結びつくと考えられています。

 

また、経営者はどのように働いてもらうかに関心を高め、単位時間あたりの労働生産性向上にもつながると考えられています。

 

 ③単線型の日本のキャリアパスについては、ライフステージにあった仕事の仕方を選択できるようにすることによって、

働きやすさや労働人口を高めることができるようになります。

 

例えば、日本における広義のフリーランスは、推計1,122万人に達しているとランサーズ株式会社の調査により発表されています。

2016年と比べてフリーランス人口は5%増となっており、今後も増加傾向にあると思われる。

 

ちなみに、アメリカでは2016年に5,370万人から、2017年には5,500万人へと増加すると考えられている。

日本でも若干、浸透しつつあるが、プロフェッショナルな人材がフリーランスとして、働く市場が拡大しており、

日本においてもナレッジの持った主婦や高齢者が週5とは言わずに、

企業と労働者がそれぞれニーズに合わせた形で、働くことができるようになっていくと考えられている。

 

 このように総理が自ら議長となり、労働界と産業界のトップと有識者が集まって、議論を繰り広げて、

施策を進めているわけです。

 

また、その働き方改革の施策として、最近話題にあがっているのが、高度プロフェッショナル制度です。

これについて次に話していきたいと思います。

 

高度プロフェッショナル制度

 高度プロフェショナル制度は、残業代ゼロ法案・脱時間給制度などとも呼ばれており、

年収1075万円以上の一定の業種の労働者を労基法による労働時間、休日等の規制対象から外すというものです。

 

つまり、残業代を労働者に支払う必要もありません

一方、時間などに縛られないため、成果を出せば数時間で帰宅することができるなど、

働き方を柔軟にするとも言われています。

 

この高度プロフェショナル制度について詳しく調べていきましょう。

 

 

 まず、ある業種とは厚労省によって決められており、

「高度の専門的知識等を必要とし、その性質上従事した時間と従事して得た成果との関連性が通常高くないと認められる業務」

とされており、金融商品の開発、ディーリング、企業・市場のアナリスト・コンサルタント、研究開発などが念頭に置かれています。

 

 

 また、年収が1075万円以上であることに加えて、職務内容が明確、労使委員会の5分の4以上の多数議決、本人の同意などが必要です。

 

これらの条件を見ると、ごくわずかな人にしか対象とならないように見えますが、

実は年収1075万円以上と言われている金額は、法案の条文には書かれていません。

 

なぜそのような具体的な数値が出てくるかというと、労基法改正案41条の2第1項2号ロによれば、

 

労働契約により使用者から支払われると見込まれる賃金の額を1年間当たりの賃金の額に換算した額が基準年間平均給与額(厚生労働省において作成する毎月勤労統計における毎月きまつて支給する給与の額を基礎として厚生労働省令で定めるところにより算定した労働者一人当たりの給与の平均額をいう)の3倍の額を相当程度上回る水準として厚生労働省令で定める額以上であること

 

と書かれており、「3倍の額」や「相当程度上回る水準」というのが、

曖昧であるためその金額を上げ下げできる恐れがあります。

 

 他には、この制度のメリットである「成果を出せば数時間で帰宅することができる」という点に疑問を生じる声を聞きます。

なぜなら長時間労働を前提とした、成果給の制度を意味しており、そもそも長時間労働であるがゆえという事実が抜けているからです。

 

また、収入においても時給に換算すると、実は高額収入とは言えず、さらなる長労働時間を助長してしまうとも言われています。

 

 

RPA(Robotic Process Automation)の活かし方

 高度プロフェショナル制度についても連日ニュースで流れるように、働き方について多くの人が敏感に感じており、

とくに労働時間について非常に注目されるところです。

 

つまり、これらの問題に多くの経営者も、自社の働き方や労働時間について考えていかなければなりません。

 

それに貢献するのが、RPAです。

 

RPAはRobotic Process Automationを言われるように、PCの動作全てを自動化することができるようになるツールです。

 

多くの労働者が、事務作業つまり、ルーチンとなっている単純業務を持っており、労働時間が増幅し、

作業からの考える時間が持てないのが現状かと思います。

 

しかし、RPAを導入すれば単純作業は全て自動化され、より高度な作業に集中することができます。

 

 これらのことからも、労働時間が長いような業種や企業においては、RPAの導入を検討してみてはいかがでしょうか

 

それにより、自社の働き方改革に貢献することができ、社員の労働生産性を高めることにも繋がるかと思います。

 

 

 

【RPA導入事例】イチ事業部員の私がRPAを提案・導入してみた。

2018.08.02

この記事では私が、自分が勤める会社にRPAを導入し、運用を始めた一連の流れを書きます。

 

私の実体験になりますので、思いがこめられすぎて、少し読みにくい部分もあるかもしれませんが、熱が伝われば幸いです。

 

 

について

  •  社会人歴約14年。営業中心
  •  最新技術はとても興味あり、広範囲に収集。
  •  プログラミングは早々に挫折。せいぜいがエクセル関数を駆使する程度
  •  最近はBIツールの活用のため、クエリ周りを勉強中。
  •  自分の会社のことは割と好き。
  •  自分と関わった人は、関わる前より少しでも良くなってほしいと思うタイプ。

 

 

当社について

 創業60年をこえた専門商社

 属人的に業務が進行しており、書類・データの残し方は人それぞれとなってしまっている。

 

 ここ数年、標準化を目指し改善活動を進めており機運は高まっているがまだまだ。

 多数のお客様と仕入れ先を抱えているため、それぞれのフォーマットがあり標準化は難しい

 

 

RPA導入のきっかけ(1か月目)

 事業部門トップが顧客に訪問した際に、「RPA導入を計画している」旨を聞き、私に調査を指示したことがきっかけ。

 

<Point>

 RPA導入のきっかけが欲しい方は、このパターンが良いかもしれません

 

 決裁権保有者に対し、まず第三者(できればお客様偉い人”)から情報を伝えてもらう事により、

その決裁権保有者は『良い情報を得られた』となりますので、

そこで時間をあまりおかずに整理された情報を伝えることにより、うまく進められるのではないかと。

 

いろいろなパターンはあると思いますが、一つの成功事例です。

 

なお、この時私は、RPAという単語は知っていたが詳しくは知らず、1から調査を開始しました。

 

 

▼調査結果はこちら↓

  •  RPAテクノロジーズ:Bizrobo
  •  ソフトバンク:SynchRoid ←当初、RPA テクノロジーズと出どころが同じということも知らず!笑(結果的にこれが採択)
  •  NTT:WinActor

 

 

▼調査条件

  •  基幹システムに対応していること(黒い画面に緑の文字のアレです)
  •  開発が容易であること (BluePrismはデモも見ていません)
  •  ランニングコストが100万円/月未満であること(派遣社員1名分のイメージ)

 

 

この時の、下記所感を持ちました。

 

 

「思っていたより色々と対応できそう」

「自分でロボットを作るにはしんどそうだけど、社内からはかなり喜ばれそう」

「基幹システムはいつ刷新するかわからないため、今をそのまま改善できるRPAが地に足着いた現実的な解決案かも」

 

 

これらを、RPA調査を指示した上司に説明し、導入に向けて本格的に動くことを決意。

 

同時に、ソフトバンク様にデモを依頼し、社内の複数部門、グループ会社のメンバーが出席、

それぞれが好印象を持ったことも導入に向けて推進力を高められたきっかけだったと思います。

 

 

<Point>

 思いさえあれば、情報システム部門でなくても、社内に新たなシステムを導入することができます。

 

逆に、事業部門からの方が、具体的な導入効果を表現できるためRPAについては事業部門からの発信が向いていると思います。

 

 また、調査を広範囲に行うことはお勧めしません。ただ時間と労力を浪費するだけです。

 上記のように、調査条件をシンプルにすることでかなり絞れるはずです。

 

 

RPAロボット化できそうな対象業務の調査(2か月目)

 

 普段から、若手社員と話すと(飲みながら)、“テンションが上がらない業務”、“自分以外の誰でもできる業務”など細かなものが非常に多く、

本来の営業活動ができていない。と愚痴を聞いていました。

 

 そこでRPA導入の費用対効果を出すためにこれらの調査を本格的に始めたところ、

自部門所属の数人へのインタビューだけで、ライセンス費用(60万円/月)は十分に回収できると分かったため、上申資料の作成に移りました。

 

 

▼対象業務の一例(自事業部門のみ)

  •  図面管理
  •  基幹システムへの登録作業
  •  見積作成
  •  お客様のEDIサイトから定期的な注文情報取得
  •  インボイスの作成

など

 

 

導入した後の社内体制を検討、関係者の合意を取る(3か月目)

 

 RPAの導入・運用には、サーバー環境が必要です(サーバー型RPAの場合)。

 

そのため、情報システム部門との連携を求めました。

幸い、情報システム部門も独自でRPAの調査をしており、会話はスムーズに進めました。

 

 当社では、事務局機能、サーバー周りの保守は情報システム部門。

 ロボット作成、運用は各事業部門にキーマンを置くという形で進めることとしました。

 

 

Point

 スモールスタートの場合はサーバー環境を必要としませんが、

当社では対象のロボット案がすぐに多数出てきたため、最初からサーバー環境を要するプランで進めることにしました。

 

 

社長への説明、上申!(4か月目)

 

 説明内容のストーリーはこうです。

 

  • RPAとはこういう事ができるものですよ
  • 発展させれば、こんなことだってできるんですよ

YouTubeにいくつか上がっているRPA関連の動画を使いました。お勧めはSoftBank Worldの講演動画です)

  • 各事業部門での適用例はこうです。これだけの時間が削減できる効果が望めます
  • とはいえ、業務の1から10までがRPAにできるわけではありません。例えばこの業務では、3から9までの部分がロボット化できます
  • 社内体制は、最初はこうです。これをどんどん発展していくようにします。
  • 費用の説明

 

これで当社の場合は十分に理解を頂き、導入に向けて決済を頂きました

 

 

Point

 お気づきの方もいらっしゃると思いますが、RPAロボット作成ツール自体の説明はほとんどしませんでした

 

 上層部は、そもそも“RPA”の事自体を正確に理解していないため、

BizroboWinActorだと説明しても、結局どちらも“RPA”です。(質問は受けますので、準備は必要です。)

 

 SynchRoidの柔軟性を確認できましたので、私はこの一本で上申しました。

 (よくあるいくつかの製品を並べて〇×表はあえて作りませんでした

 

 また、キメの文句は「これを導入しないと、若手社員はどんどん辞めていきますよ。」です笑

 

 

 導入の構成準備(5か月目)

 

▼必要なもの(サーバープラン)

 ・サーバー(クラウドサーバーでOK

 ・開発用のPC  *開発者の人数分

(通常、会社から配布されるPCではスペックが足りない場合が多いと思います。最低でもメモリ8GBが必要です。)

 

▼あった方が良いもの

 ・遠隔操作先用のPC

  *サーバー上に仮想PCを設けても良いですが、サーバーへの要求スペックが高まってしまうため、1台手元に置いた方が開発が楽です。

 ・外付けモニタ

  *できれば4Kモニタが良いです。開発画面では、実行ウィンドウ、タグなどいくつも

並行してみなければならず、フルHDモニタでも事足りないくらいです。

 

Point

 社内に情報システム部門があれば、このあたりは任せた方が良いと思いますが、

上記に書いた開発用のPCや、遠隔操作先のPC4Kモニタなどは“後から気づく”類のものです。

 

ぜひ参考になれば幸いです。

 情報システム部門が無ければ、必要スペックをRPAベンダーにまるまる用意していただくことも可能ですので、それもお勧めです。

 

 

ということで、予算の申請は余裕を持った方が良いです笑

決して、ライセンス費用のみで申請しないことをお勧めします。

 

 

 導入、スキルトレーニングの実施(6か月目)

 

 まず当社ではスキルトレーニングを申し込み受講しました。

 これ一回でRPAツールのことを理解するものではなく、ロボットを作る一連の流れを把握する程度と捉えた方が良いです。

 それでも、受講をしないよりはした方が良いです。

 

 

各部門への説明(6か月目*5と同時進行)

 

 これは絶対にさぼってはいけません。全部門に回るべきです。

 また、会社によっては部門に回る順番も意識した方が良いでしょう。

 

 RPA導入までの努力、労力は誰も理解してくれません。

 

逆に、メンバーは風の噂でRPA導入を知っていますので、期待を持つ人、疑心的な人などいろいろいます。

 

 私はこういったスタンスで臨みました。

 

 

  •  「業務を標準化してから…」ではなく、今困っているものを”そのまま”教えてください
  •  作成依頼に特別な申請を設けない
  •  ロボット候補の業務を、スマホで動画撮影することで要件定義作成の手間をシンプルにする
  •  仕事(ロボット案)をください!

 

あくまで、「一緒に作り上げていきましょう。」「あなたの味方です」というスタンスです。

 

 

社内からの反応(7か月目)

 

 私が直接説明をした当事業部では、比較的に業務担当者からの「これもロボット化できる?」が多かったです。

 説明の仕方が良かったのだと自負しています笑

 

 

 

運用における苦労(7~8か月目)

 

 今現在、リアルタイムに起きている問題はこちらです。

 

  1. ロボット化の案は多数上がってくるも、RPAロボット制作が追い付かない
  2. RPAロボット製作者側に回りたいという声がなかなか無い
  3. 当社(商社)では、プログラム開発に強い者が少ないため、RPAロボット制作において不明点が生じても社内での解決に時間がかかってしまう。
  4. お客様毎に特別対応している業務のRPA化が難しく、業務担当者の期待値が下がってしまう。

 

 おおよそこれらが上がっています。

 

  1. は予算に余裕を持ち、RPA技術者の派遣を考慮すればスムーズにいったでしょう。
  2. すでに自身が抱えている業務が忙しい中、新たなものに取り組むモチベーションを持つ方はやはりなかなか少なく、しばらくこの問題は抱えそうです…。
  3. これも、1.の解決策同様で解決できると思います。
  4. まず、「すべてをRPAでやらなくてはいけない」という思い込みを捨て、Excelが得意なことはExcel(マクロ)にやらせる。BIツールの方が得意ならばそれに。RPAは下処理を行う。と、時によって割り切りが絶対に必要です。

 

  

 当社でのRPAロボット制作事例

 

 まだまだ数は少ないですが、今運用しているロボットの一例を紹介します。

 

  • お客様発行の書類データ(PDF)に当社情報を加える *従来は手書きで行っていた業務です
  • インボイス作成
  • 業務用サイトへのデータ入力

 

 

総括_RPAについて

 

 当社ではまだ導入したてですが、すでにいくつかの業務で実績を上げておりすでになくてはならないものになっています。

 

なにより漠然と他の誰かでもできる作業時間と労力さえあれば行える作業をしていた社員の方にとっては、

RPAは一筋の光であり意欲の向上に一役を買っていることが私にとっては一番の効果です。

 

 しかし、RPAを導入した他の企業と話をしますと、当社の進みは早いケースのようです。

RPA導入メンバーとなった方は、しばらくはつらい時期が続くと思いますが、

その先に必ず成果が表れるものですので、ぜひ頑張ってほしいと思います。

 

ここまで駄文を読んでいただき誠にありがとうございます。

RPA導入に向けて困っている方にとって何か一つでもお役に立てれば幸いです。

 

 

 

【RPAツールの一角】BizRobo! とは

2018.08.01

はじめに

RPAに関する情報をチェックしていると、「BizRobo!」という名称を良く目にするかと思います。

しかしサービスそのものについては詳しく知らないという方も少なくないでしょう。

そこで本記事では、BizRobo!について解説します。

 

BizRobo! とは

BizRobo! とは、RPAテクノロジーズ社が提供するRPAサービスの名称です。

 

事務業務を自動化する技術であるRPARobotic Process Automation)では、

自動化を実行するプログラムのことをロボットと呼び、ロボットを作成するためのソフトウェアが必要になります。

BizRobo! は、複数のロボット作成ソフトウェアと運用サポート、導入時のアドバイスをセットで提供しています。

 

大手銀行をはじめ導入企業も多く、国内シェアNo1を謳うNTTデータのWinActorと並び知名度も高いRPAサービスです。

国内400社以上での導入実績があります。以下のような導入例があります。

 

 

【大和ハウス工業】

基幹業務の効率化を目的としてアビームコンサルティング社の支援のもとBizRobo!を導入。

情報収集やデータ整理業務、会計レポート生成等に活用し、外注費削減などを目指す。

https://www.abeam.com/am/jp/ja/about/news/20170720

 

 

【日本生命保険(ニッセイ)】

RPAロボットを擬人化した「日生ロボ美ちゃん」を社のスタッフとして正式採用し話題に。データ検索やシステム入力を担当することで1件あたり数分かかっていた作業を20秒程度で処理し時間削減を実現。

http://rpa-technologies.com/about/#07-01

 

 

RPAとRDA

RPAのロボットは、大きく分けて各PC上で動くタイプと、サーバ上で動くタイプの2種類あります。

 

PC上で動くタイプはRDARobotic Desktop Automation)と呼ばれ、導入費用が安価に済むというメリットがあり小規模導入用途で人気があります。

 

一方で一元管理ができない、ログの把握が困難といったデメリットもあります。

 

サーバ上で動くタイプのロボットが狭義のRPAです。

管理のしやすさやユーザー管理ができるといったセキュリティ上の利点から大企業で多く導入されています。

 

BizRobo! はこちらに分類されます。

 

 

BizRobo! シリーズの製品群

BizRobo! には、複数のロボット作成ソフトウェアが含まれています。

それぞれ特徴があり、利用企業の用途に合わせて適したソフトウェアを組み合わせることができるようになっています。

 

  • Basic Robo!
  • Document RPA
  • Blue Prism
  • NICE

 

Basic Robo! の操作

BizRobo! 中でも導入数が多いソフトウェアがBasic Robo!で、提供元のRPAテクノロジーズでも国内導入実績No.1を謳っています。

 

開発環境、ロボット監視環境、ロボット実行環境など複数のソフトウェアから構成されており、

ロボットを開発するソフトウェアはDesign Studioという名称です。

 

 

Basic Robo! におけるロボット作成は、プログラムの知識がなくてもできるのが特徴で、容易にループ(繰り返し)やファイル書き出しができます。

 

Excelのマクロと同様にレコーディング機能を備えており、ユーザーがクリックしたりテキスト入力したりする操作をソフトウェアが記録していきます。

 

 

一般的にプログラム言語では変数を宣言しますが、

Basic Robo!ではタイプと呼ばれる変数セットを作成し、タイプの中に複数の変数を作成します。

 

ロボットを作成する場合には、ロボットのなかにタイプを設定した後、右クリックで操作を記録しながらデータを取り出して変数に保存していきます。

記録した操作はフロー図のように表示されます。

 

Excelマクロでは実現が難しいような、Webからのデータ取得や他アプリケーションとの連携ができるのも利点です。

 

BizRobo! のよくある誤解

BizRobo! は知名度が高い反面、意外と誤解されていることもあります。ここではBizRobo! のよくある誤解を紹介します。

 

 

誤解その①:国産RPAサービスである

提供元のRPAテクノロジーズが日本企業のため、BizRobo! も日本企業が開発したサービスだと誤解されがちですが、

BizRobo! が提供しているロボット作成ソフトウェアはいずれも海外製です。

 

メイン製品のBasic Robo!はアメリカ企業のKofax社が提供しているKofax Kapow 10がベースになっています(Basic Robo!のソフトウェアを起動するとKofax Kapowという名称が表示されます)。

 

 

誤解その②:BizRobo! という単体のソフトウェアが存在する

前述のとおり、BizRobo! は単体のアプリケーション名称ではありません

 

RPAサービスを提供している多くの企業がソフトウェアとしてサービスを提供しているのに対し、

BizRobo! 提供元のRPAテクノロジーズ社では、BizRobo! をロボットの導入・運用を支援するためのサービスプラットフォームと位置付けています。

 

 

同社ではロボットのことを「デジタルレイバー(仮想知的労働者)」と呼び、人と同じように労働力として扱います。

ソフトウェアを販売するのではなく、複数のソフトウェアやOCR機能などを組み合わせたデジタルレイバーを作成、

提供するサービス全般をBizRobo! というサービス名で提供しているという位置づけです。

https://rpa-bank.com/interview/7196/

 

 

誤解その③:大企業向けのサービスである

ニュースなどで取り上げられるのは有名企業の事例が多く、

また導入費用が高額なことからも大企業向けのサービスだと考えられがちです。

 

しかしサーバ不要で初期投資を抑えられるクラウドサービス「Bizrobo! DX Cloud」をリリースするなど地方、中小企業向けのサービスも提供しはじめています。

 

 

他社との連携サービスについて

BizRobo! が競合他社と異なる点として、パートナー企業と連携したRPAサービスを提供していることが挙げられます。

 

たとえばAI開発・データ分析を行うブレインパッド社では、

自社のAI技術データマイニング技術を付加したRPAサービス「ブレインロボ(BrainRobo)」を開発・提供しています。

 

自治体向けのシステム開発を行う大崎コンピュータエンヂニアリングでは、

今まで培った自治体向けシステム開発のノウハウを生かした自治体向けRPAサービス「OCEVISTAS」を提供しています。

 

いずれもBizRobo! Basic Robo! をベースに、自社が持つ強みを組み合わせてサービス化することで差別化しています。

サービスごとにオリジナルのキャラクターを作成しています。

 

まとめ

BizRobo! は、RPAにおけるロボットを作成するために必要なソフトウェアやサポートをセットにしたサービスのことです。

 

複数のロボット作成ソフトウェアが含まれていて用途に合わせて適した組み合わせができるほか、

ベースとなるソフトウェアにAI技術などを付加した連携サービスも多数存在し、

EC運営業務代行に特化したロボットや自治体業務に適したロボットなど、

さまざまな特徴を持ったロボット提供サービスが派生しています。

 

 

BizRobo! の提供元であるRPAテクノロジーズ社は、RPA操作スキルを持った女性スタッフを育成する「RPA女子プロジェクト」や、

ロボットを売買する「RPAマーケットプレイス」の提供(運営は子会社のセグメント社)など新たな取り組みにも積極的です。

 

 

RPAツールのデファクトスタンダードが存在しないなか、

「サービス提供社が多い」、「操作できる人材の育成を支援」、「ロボットの売買ができる」、「安価なクラウドサービスを提供」などを武器に、

BizRobo! の導入企業は今後も増えていくと予測されます。

 

 

出典

http://rpa-technologies.com/products/first/

https://rpa-bank.com/column/11305/

 

 

また、Basicrobo、SyncRoidについては以下の記事も併せてご覧ください。

https://rpa-biz.com/?p=1652

 

 

 

topへ
© RPA.biz