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

【RPA業界必見!!】大手外食企業におけるRPA導入事例

2018.09.28

 

<目次>

 

■大手外食企業が進める“働き方改革”

 

■RPA導入に向けた調査開始

 

■RPA導入の流れ

 

■RPA導入実績のまとめ

 

■RPA導入に関する所感

 

■まとめ

 

 

 

 

 

働き方改革」という言葉はニュースでも盛んに流れています。

そして、多くの企業でも「働き方改革」を旗印に、様々な施策が動いています。

 

某大手外食企業における「働き方改革」プロジェクトの中で、

実際に導入されたRPAの事例を軸に紹介していきたいと思います。

 

 

 

 

■大手外食企業が進める“働き方改革”

 

●社会全体が人手不足

 

2018年現在、社会は空前の人手不足と言われています。その理由の1つに少子高齢化があります。

 

 

(出典)国立社会保障・人口問題研究所

 

 

図を見ると、2010年以降急速に生産人口が減っていることがわかります。

 

つまり、働く人が減っているのです。

 

そして、2018年現在の好景気(諸説ありますが)という要因もあり、

企業は人の採用が難しくなっている現状があります。

 

 

 

●外食ってブラック?

 

外食業界は、他の業界と比較しても、人手不足感は際立っています。

労働集約型産業の代表的な業界ということもありますが、

給料が安い」「労働時間が長い」「休めない

というイメージがあることも原因の1つです。

 

 

給料が安い」ことは、今回のプロジェクトの対応範疇外ですが、

後の2つをどうにか改善する必要があります。

 

実際問題、「給料が安い」はイメージ先行かもしれません。

高くはないかもしれませんが、大手外食チェ-ンの正社員であれば、問題なく家族を養えます。

 

 

 

●外食業界のもう1つの問題点

 

外食業界のもう1つの問題点は、大手含めて利益率が少ない会社が多いということです。

 

 

(出典)StockClip「国内外食産業の業績ランキング」

 

 

売上高順に並んだランキングですが、

大手外食チェーンは軒並み1桁台の利益率だということがわかります。

 

この為、社員を安易に増やせる状況ではなく、

その少ない正社員と多くのアルバイトやパートなどの非正規人材によって成り立っている現状の中、

その少ない正社員は、事務作業などの非付加価値業務に追われているという現状があります。

 

 

前置きが長くなってしまいましたが、

 

・外食産業は人手不足だが、給与を高く設定することが困難な為、採用難である。

・社員には仕事の負荷が重くのしかかっている。

 

上記を改善させるべく、今回のプロジェクトが始まりました。

※このプロジェクトの内、RPA導入に関するシーンを切り取っています。

 

 

 

 

■RPA導入に向けた調査開始

 

●店舗はどれだけ事務作業をしているのか?

 

シフトの作成、レジ締め作業、本部への売上報告書の作成、クレーム報告書、発注作業

 

など多数の事務作業があります。

1日の内、3割が事務作業という結果でした。

 

 

 

●本社(本部)は売上や入金をどのように確認しているのか?

 

売上といっても、現金以外に金券(ギフト券、商品券、株主優待券など)・クレジット・電子マネー

といった売掛が多種に渡ります。

専属の社員を多数用いて、既存のシステムとエクセルで日々確認しています。

 

 

 

 

■RPA導入の流れ

 

●業務フローの確認と現場ヒアリング

 

RPA導入において、大事な点は、業務フローがキチンと整備されていることです。

 

たとえ整備されていたとしても、業務フローには記載されていない業務は必ずあります。

担当者にヒアリングをして、必ず業務を確認しましょう。

 

 

<注意点>

RPAは、あらかじめ決めた業務を行ってくれるロボットです。

つまり、臨機応変な対応は出来ません

イレギュラー業務が発生するのであれば、そのパターンを全て網羅しておく必要があります

逆に網羅出来ない業務が発生する場合、RPA導入はお勧め出来ません。

 

 

 

●業務改善案を練る(コンサルの方のみ)

 

たとえ大企業といえども、そもそも必要なの?という非効率な業務は必ずあります。

何のための業務なのか誰が必要としている業務なのか

という視点で案を練りましょう。

 

 

<注意点>

RPAに置き換えるという視点では無く、業務がどうあるべきかという視点を持つことが重要です。

ほとんどの場合RPAは必要ないかもしれません。

 

 

 

●RPA製品を選びます

 

2018年現在、有料無料含めて10数個のRPAツールが存在しているようです。

最終的には、以下の2つが候補となりました。

 

 

  • WinActor」 販売元:NTTデータ

   国産型RPAツール。デスクトップ型のPRA。フローの作成画面などのUIがわかりやすい。

   小規模業務を得意としている為、中小企業でも導入しやすい。

  • BizRobo!」 販売元:RPAテクノロジーズ

   RPAツールの大手。サーバ型とデスクトップ型の2つから選ぶことが可能。

   実績が豊富であり、ほとんどのバグや不具合は解消されている。価格面から大企業向き。

 

 

この内、「BizRobo!」を選ぶことになりました。

また、販売元であるRPAテクノロジーズからではなく、某大手ベンダ経由になります。

 

 

理由としては、以下があります。

 

・将来の拡張性を考えてのこと。

 

現時点では、デスクトップ型RPAのみで実現可能な為、

どのRPAツールを使った場合でも問題ないのですが、

検証を重ねてRPA業務の対象範囲を今後広げていきたい為

 

 

・ベンダを経由することで、RPAのフローの書き方などのコンサル支援を受けることが出来る。

 

値段が高くなることがネック。

 

 

<注意点>

BizRobo!」は、提供元会社であるRPAテクノロジーズ以外にも、

ソフトバンクやリコーなど様々なベンダがソリューション(RPAコンサル含め)

として提供を行っております。

 

しかし、2018年現在では、どのベンダを利用したとしても大きな違いはありません

ベンダ各社はRPA導入に関するノウハウを蓄積し始めたばかりであり、

ソリューションの中身はどこも似たようなものです。

 

 

 

●システム環境の確認

 

サーバ型RPAなのか、デスクトップ型RPAなのかという違いはありますが、

RPAはシステム環境が変わっただけで、不具合を起こす可能性があります。

 

 

<注意点>

RPAは、GUIが少しでも変わっただけで不具合を起こします

サーバやPCなどは、担当者との情報共有はしっかりとしておきましょう。

 

 

 

●RPAの設定を行う

 

RPAのフロー作成自体は、ものすごく簡単です。

一度、操作方法さえ覚えてしまえば、ITに詳しくない人でも問題なく設定することが可能です。

 

 

 

●今回は、スクリプトが必要になるなどの難しいRPA業務は導入しませんでした。

 

複雑な業務に対してRPAを使う場合は、スクリプトなどでのプログラミングが必要となります。

 

 

<注意点>

フローは粒度をとにかく細かく書く記述する必要があります

例えば、「メール送信」という動作も

 

「メーラー立ち上げ」→「宛先の入力」→「題名の入力」

→「本文の入力」→「送信ボタンの押下」→「OKボタンの押下」

 

などです。

 

 

 

●RPA動作開始と検証

 

RPAが動作開始後は、動作と結果がしっかりと想定通りなのかどうかを確認します。

他ソフト(Excelなど)との連携状況もしっかりと確認します。

 

想定業務外の事態が発生、既存のソフトウェア(たまにしか動かないソフトなど)が

RPAを邪魔してしまう事態が発生する可能性があります。

 

暫くは、常時監視する姿勢が必要です。

 

 

<ポイント>

RPAのナレッジは社内でしっかりと蓄積しましょう

 

RPAが出来ることの理解、RPAの障害パターンの把握が深まれば、

より複雑な業務へと拡張させていくことが出来ます。

 

 

 

 

■RPA導入実績のまとめ

 

●結果事例① 【店舗】レジ締作業の時間短縮、【本社(本部)】エラー確認の時間短縮

 

これまで、店舗はレジ締作業において、1日あたり30分~1時間を擁していました。

その内、売上データの不備確認が多くの時間を占めていました。

 

売上データは本部へ自動送信されますが、売上データに不備がある場合、

自動送信がエラーとなってしまいます。

 

 

本社(本部)は毎日、そのエラーの有無の確認、エラーがあった場合の調査に時間を費やしていました。

店舗、本社(本部)の2重チェック体制となっていました。

 

 

RPA導入により、店舗はレジ締作業において、売上データの不備確認を不要とし、

自動送信にエラーが発生した場合は、

その発生と発生理由を本社(本部)の担当者へ自動でメール送信されることになりました。

 

 

店舗の作業が大幅に減ると同時に、本社(本部)も、

メールによるアラートにのみ対応すれば良いということになりました

 

 

 

●結果事例② 【本社(本部)】売掛請求の入金照合を時間短縮

 

本社(本部)は、金券類やクレジットカード、

そして電子マネーなど多種に渡る売掛の入金確認を行っています。

 

様々な売掛先からの入金日は1か月の中で十数回もあり、

これまでは、その照合チェックをエクセル上で行っていました。

 

1年を通してみても、請求額と入金額に相違が発生することは、

まず無い為(金券が偽物だった場合などであり得ますが事前連絡により承知済です)、

内部統制上での必要事項とも言えます。

 

 

RPA導入により、入金データと請求データの照合を自動で行い、

相違がある場合のみ、メールで担当者へ自動メール送信されるようになりました。

 

 

これは、本来であれば、システム開発によって対応されていても良いかと思うのですが、

対応されていませんでした。

 

新たにシステム開発した場合との費用検討の結果、RPA導入にメリットがありました。

 

 

 

 

以下は、検討したが断念した事例

 

 

●断念事例①店舗における発注作業のRPA化

 

店舗では、毎日の作業として、食材や備品(食器など)を、

Web発注システムを使って発注作業を行っています。

 

これをエクセルに発注内容を記入してメール添付することで、

RPAが自動的に外部のWeb発注システムに登録することで、発注作業の簡易化という検討を行いました。

 

 

しかし、食材は結構な頻度で変わる

(例えば、エビでもインドネシア産エビが高騰の為、ベトナム産エビに代わるなど)為、

RPAのメンテナンスが大変だということで、メリットを生み出すことが出来ませんでした。

 

 

 

●断念事例②RPAが印刷を行う

 

本社(本部)では、毎日の作業として、数百枚にも及ぶ法定帳票を印刷するという作業があります。

それを深夜に自動的に行うことで、日中の印刷作業を無くすよう検討を行いました。

 

 

しかし、そもそも法廷帳票を紙で保存では無く、

データ保存とすることで印刷作業を無くすべき姿だという結論に至りました。

 

単純な話しかと思いますが、

既存業務をRPAに置き換えるという観点だけではいけないということに気が付きました。

 

 

 

 

■RPA導入に関する所感

 

●RPAありきではダメ

 

RPAが出来ることは限られいます。

 

RPA自体が何か新しい価値を生み出すわけではありません。

あくまでも既に回っている既存業務の改善がメインです。

 

また、多くの場合、

既存のシステムを改修すればRPAではなくても対応出来る

ということです。

 

既存の業務を改善する上でのソリューションの1メニューとして捉えるべきだと感じました。

 

 

 

●社内コンセンサスの大変さ

 

RPA導入によってこれだけの効果が出ます」と言えば、経営層は喜んでくれます。

 

 

しかし、RPA導入によって、仕事が無くなってしまう人がいるのも事実です。

 

または、慣れ親しんだ業務が無くなることが嫌だという人もいるでしょう。

 

とある店長は閉店後の売上データ不備確認でその日の業務を振り返ると言っていました。

RPA導入は本社(本部)のみならず、店舗を含めた幅広い、且つ、丁寧なコンセンサス形成が必要です。

 

 

 

●RPA導入により属人的な業務が減る

 

会社の規模に関わらず、会社にはその人しか知らない業務という属人的な仕事があったりします。

 

また、人によって業務の進め方にクセがあることも多いかと思います。

 

RPA導入によって、業務が可視化され、

また、業務の進め方もある程度統一されると感じました。

 

この観点で言うと、効率化もそうですが、内部統制の面でも良い影響があるかと思います。

 

 

 

 

■まとめ

 

今回は、大きな流れでRPA導入についての説明をしました。

 

RPA導入を考えている会社は、

チャットボットなどの簡易AIの導入も同時に検討していることが多いかと思います。

 

RPA導入担当者は、それらの他のプロジェクトを把握して、

どのような連携が考えられるか、という視点を持っても面白いかもしれません。

 

いずれにせよ、RPAはこれから発展していくツールです。

 

RPAに関わることはあなたの社内はもちろん、市場価値が高まることは間違いないと思います。

 

 

 

 

【RPAにより】ホワイトカラー業務が変化する?

2018.09.27

RPAとホワイトカラー業務の課題

 

 

企業において、業務効率化は至上命題のひとつではあるものの、

比較的小粒の業務についてはコスト面および対応のしづらさから、人手に頼っている部分が多く残っています

 

 

多くのコンサルティング会社は、

企業のバックオフィス部門の生産性向上と人的資源の有効活用を推進するため、

RPA(Robotic Process Automation)ツールを活用し、

業務自動化を推進する業務改革サービスを提供しています。

 

 

大量定型業務はビジネス・プロセス・リエンジニアリングや大規模システムの導入により、

効率化が実現できているものの、

小粒の業務はさまざまな理由によりいまだ人海戦術で対応している企業が散見されます。

 

 

RPAツールによって、従来型のシステム開発手法では対応しにくい

ボリュームが小さい」「変更が多い」「標準化できない

といった業務であっても、RPAツールを活用することで効率化が可能となります。

 

 

数多くの業務改革経験を生かし、現場を巻き込んだスピーディな業務改革を実施するRPA業務改革サービスは、

RPAと、コンサルティングの業務改革ノウハウを組み合わせたサービスです。

 

RPAの対象業務としては、

これまで自動化できなかったERPWebメールファイルサーバーデスクトップ上のExcel

などアプリケーションをまたいで発生する広範囲の業務を自動化することが可能です。

 

業務の一連の流れと参照情報を整理し、ロボットが記憶し自動化するため、

コーディングなどのシステム開発が不要です。

 

 

そのため、従来のシステム開発手法では対応することが難しかった

業務量が少ない」「変更が多い」「標準化できない

といった業務でも自動化することができます。

 

 

また標準的なアプローチのため、簡易効果診断では、ロボット化する対象業務の洗い出しを行い、

工数削減の効果および開発費用の概算を算定します。

 

トライアル導入では23つのロボットを導入し、実環境におけるロボットの有効性を検証し、

効果の実感を確認した上で本格導入へと進みます。

 

 

 

RPAで「ホワイトカラーの仕事の47%がなくなる」の意味

 

 

 

 

 

生産性向上が必要になる中で、企業での積極活用が叫ばれているテクノロジーが、

RPA(Robotic Process Automation:ロボティック・プロセス・オートメーション)です。 

 

 

去年開催された日本RPA協会の主催セミナー「やらざるを得ないRPAと取り組みの実態」では、

いまITにおいてキーワードになりつつあるRPAについての解説がありました。

 

 

今後、日本は労働者人口が大きく落ち込むと予想されています。 

 

内閣府の「平成28年版高齢社会白書」によると、2025年には日本の人口は700万人減少し、

15歳から64歳の人口が約7000万人まで落ち込むと言われています。 

 

そのような日本の労働人口が減少する状況下において、

日本人の働き方を大きく変えるテクノロジーがRPAなのです。

 

RPAはアプリケーションを使って行うオフィスワークを学習し、それをそのまま実行することができます。

 

 

いわば、人が手動で行っていた各種ツールによる事務処理などの

ルーティンな作業を代行してくれるデジタルレイバー(仮想知能労働者)です。 

 

人がやりたくない、やるべきではない作業を人の200倍のスピードで処理してくれます。

そして、36524時間稼働してくれます。 

 

 

デジタルレイバーという新しい労働力が活用できるというわけです。 

 

また、RPAは人の操作を記憶させるだけなので、

稼働させるために大規模なシステム導入やプログラムの修正・変更の必要はありません。 

 

 

ノンプログラミングで容易に構築でき、短期間かつローコストで導入することができる

というメリットも生まれます。 

 

 

 

ホワイトカラー生産性調査の必要性について

 

 

ユーザー部門が対象システムを活用することによって、

どの程度生産性を向上できたか、定量・定性両面から把握します。 

 

これにより、成功事例の全社展開や費用対効果の振り返りなど、

積極的な IT マネジメントを遂行できるようになります。

 

 

 

ホワイトカラー生産性調査をどのようにすれば良いのか

 

 

測定が難しいシステム導入によるホワイトカラーの生産性向上度合いを、

短期間で簡易的に調査して定量的に示します。 

 

さらに、その部門の“業務項目”にブレイクダウンしその効果を示します。

 

同時に、定性面での特徴も示すことで、数値とその論拠をマネジメント層がわかるような形で表現します。 

 

 

生産性調査でよくみられる“調整”や“資料作成”といった作業項目での評価のみならず、

年度計画立案”“市場調査”といった、マネジメント層が理解できる業務項目ベースで効果を示すべきです。

 

 

 

RPAは従来のシステム変更とどう違う?

 

 

業務の自動化は業務システムの見直しでも実現できますが、RPAは概念が異なります

 

 

例えば、顧客管理業務のケースで考えてみましょう。 

 

顧客管理システムが導入されている企業でも、

顧客データのインポート作業などはたいてい人の手で行ないます

 

また、入力作業の報告メールを送ったり、入力作業後に他のスタッフがダブルチェックしたり、

人手による作業はそれなりに発生します

 

業務効率化のためにシステム改修を行なったとしても、

システム間のデータ移行やチェック業務などはなかなかシステムに組み込みにくい作業です。

 

一方RPAの場合、入力作業からチェック、報告までのプロセスすべてをソフトウェアロボットが代行します。 

 

つまり、

システム変更ではカバーしきれない業務範囲でも、RPAでは自動化できる可能性が高い

というのがポイントです。

 

システム変更ではイレギュラー対応など非定型業務の自動化が難しいケースが多いのですが、

RPAならAIなどの導入で実現できるケースもあります。

 

 

 

RPAでロボットがホワイトカラー業務を代行できる時代へ

 

 

とある銀行グループが業務自動化技術を導入して、

9,500人相当の仕事量を削減する方針を20179月に発表したことが大きな話題となりました。 

 

この業務自動化技術のメインとなるのが、

RPA(Robotic Process Automation:ロボットによる業務効率化)です。 

 

もちろん、RPAの導入により、

品質の向上とリードタイムの短縮、労働不足の解消につながっており、効果は出ているそうです。

 

 

ロボットによる業務代行というと製造業をイメージしがちですが、

RPAはPCを使った業務などホワイトカラーの業務を代行します。

 

そのため、仮想労働者(デジタルレイバー)とも呼ばれることもあります。

 

ロボットによる業務効率化というと、単純作業の代行というイメージを持つ方も多いかもしれません。

 

RPAでは3つのクラスに分かれていて、最も高度なクラス3になると

AI(人工知能)の学習能力によって分析や業務改善などの複雑な業務ができるものもあります。

 

 

<クラス詳細>

  • RPAクラス1:定型作業の自動化
  • RPAクラス2:一部非定型作業の自動化(イレギュラー対応もできる)
  • RPAクラス3:高度なタスクの自動化(業務プロセスの分析・改善もできる)

 

 

RPA2016年以降、働き方改革の手段の1つとして注目を集めている技術です。

 

自動化技術などの導入により、

人間は人にしかできない仕事や新しい仕事を担当するようになるでしょう。

 

 

仕事に必要なスキル向上も合わせて行い、オフィスワーク全体の生産性を高めていきます。

 

今、人が行なうPC業務をRPAによって自動化することを目指している企業は少なくありません。

 

 

 

 

オフィスワークにおけるAI導入: メール/文書分析

2018.09.26

 

今回のブログでは、オフィスで行われる事務作業について

既にAIの技術が開発され導入していっている事例をご紹介したいと思います。

 

 

 

昨今の電子化の流れを受け、ビジネス上の様々な情報が電子データとして扱えるようになってきました。

 

これは即ち、AIにとって「教師データ」となるソースが質量ともに高まったことを意味し、

ビジネスシーンにおけるAIの活躍の場を押し広げる事に繋がりました。

 

 

教師データ」というのは、AIが学習する上で必要不可欠な参考データのことですが、

これは端的に言えば、今まで人間様が行っていた判断・意思決定の記録を意味します。

 

 

 

例えば、今まで社員が夜を徹して行っていた文書やメール文などの

チェック業務のレコードを「教師データ」としてAIに学習させれば、

 

次からはAIが自動で今までの判断基準を参考に人間の代わりにチェックを行ってくれるようになります。

 

 

 

今回のブログでは、AIを使ったユニークなビジネスソリューションを展開している、

FRONTEO社の取り組みをご紹介したいと思います。

 

 

FRONTEO社は2003年に設立、現在マザーズに上場しています。

 

KIBITとという独自の人工知能モデルを活用し、

法律事務所や医療機関、官公庁や民間企業へのサービス展開を行っている企業になります。

 

 

特に実績として名高いのは、

法律関係での「ディスカバリ」とよばれる

訴訟案件における証拠の収集や特定、提出にいたるプロセスと、

 

フォレンジック」という

情報漏えい、談合・カルテル、横領、労務問題、ハラスメント問題、セキュリティ事案

をはじめとするさまざまな不正調査プロセスへのAI適用です。

 

 

これらいずれの業務も、本来人間(調査員)が行う場合は、

膨大な量の文書や電子メールでのやりとりのチェックが発生します。

 

 

この膨大な調査業務をAIで効率化するというのが、サービスのコンセプトになります。

 

 

参考: FRONTEO ホームページ(http://www.fronteo.com/

 

 

 

 

少ない教師データでも学習効果を高められる独自人工知能技術「KIBIT」

 

 

FRONTEO社では、Landscapingと行動情報科学を併せた同時の人工知能術を開発しており、

 

特徴としては少量の教師データで、パターン解析・学習をすることができることを謳っています。

 

 

この「教師データ」というものは、AIを実務で活用しようとするときに必ず直面する厄介な問題です。

 

AIの精度をそれなりのものにするためには、まず実際に人間が行った

評価・判断・意思決定に付随するデータをAIに「喰わせる」必要がありますが、

 

実際にそのファクトとなるデータがなかなか集まらず

結果、AIの学習が滞り、「頭の悪いAIしか育たないケースが散見されます。

 

 

 

これは、AIの一大分野である「画像認識」の技術でも言えることです。

 

 

よくIoTとの絡みで、工場内の検品業務にAIを導入するような取り組みが

新聞雑誌で取りざたされることがありますが、

 

この場合も事前に人間が判別した「不良品」の画像データを相当数AIに喰わせる必要がありますが、

そもそもそれほど不良品率が低い工場だと、教師データ自体が集まりません。

 

これを改善する方法として「不良品」ではなく「良品」のほうを教師データとしてAIに入れ、

その基準から外れたとAIが判断したものを「不良品」と一次判定するような取り組みが挙げられていたりします。

 

 

いずれにせよ、この工場の検品という領域ではまだ大ロット少品種の大量生産品が対象であり、

ジュエリーなどの小ロット多品種のケースではまだまだAIの導入の壁は高い印象です。

 

 

この「教師データ」の問題を、FRONTEOが得意とするフォレンジックの領域に当てはめると、

 

例えばそれは社内の社員の不正の証拠となる電子メールの数々が「教師データ」となります。

 

 

FRONTEOでは、おそらく膨大な数のクライアントにおける不正事例をもっており、

それをAIにインプットし学習させているのだと推測されます。

 

この社員のメール文面から不正示唆を判別する能力ですが、しっかりと学習されたAIであれば、

普通の一般的では見過ごしているような点まで気づいてくれるようになります。

 

例えば、一見、サプライヤーの担当者と親睦を深めるために飲みに誘うだけにしか見えない

メールであっても、わずかなニュアンスの違いを検知し、

談合の可能性を示唆してくれるようになります。

 

 

 

 

 

様々なビジネスシーンへの適用可能性

 

 

このような文書やメール文を解析し示唆をだすAI技術ですが、

この効能の潜在的価値はビジネス上で計り知れません。

 

 

そう、それは何も法律関係に事象にとどまらず、かなり広範囲に適用できる武器となりえます。

 

例えば、以下のようなシーンでの活用が見込めます。

 

 

  • 人事部: 退職リスクの事前検知
    • 全社員のメールをAIに定期的に読み込ませることで、退職する可能性のある社員(モチベーションが下がってそうな社員)をいち早く発見
    • 人事部は、いちはやくそのような社員にフォローを手掛けることで、離職率の減少に貢献できる
  • 人事部: パワハラ・セクハラの防止
    • 上司のメールや、社員の愚痴メールなどをAIが検知
    • パワハラ・セクハラの兆候をいち早く検知し、人事部側で防止策をとれる
  • 営業部: 失注リスクの事前検知
    • 既存顧客との担当営業のメールや日報等をモニタリングし、失注リスクをいち早く検知
    • 営業マネージャーは、失注リスクのある顧客に対していち早くフォローを講じれる
  • コールセンター: 潜在的営業機会の検知
    • 顧客からの問い合わせメールやコールセンターでの録音データをテキスト化したものから、潜在的な営業機会を検知
    • 営業としては、受注確度の高い問い合わせを優先的に開拓することができるようになる
    • さらに発展系として、顧客の問い合わせメールを、クレーム、改善要望、感謝といったようなカテゴリに分類し、それぞれの関係部署に転送することも考えられうる

 

 

ここで挙げた事例は、ほんの一部にしかすぎず、

アイデア次第では様々な用途にこの技術が使われうることは皆さん用意に想像できるかと思います。

 

 

要するにこの技術は、

「テキストデータ群から、ある傾向をもつものを自動で抽出する技術」

に他なりません。

 

 

我々の日常業務は常にドキュメントやメールといったテキストデータに囲まれています。

 

 

 

また、最近では音声データの自動テキスト化技術も急速に発展していっています。

 

これは即ち、

コールセンターでの応答や、入社面接での面談応答、会議の討議内容といったことまで自動でテキスト化され、

AIの恩恵に与れるようになるということです。

 

 

今まで熟練社員でしか見つけられなかった「気づき」のノウハウを、

入社1日目の新入社員でも享受できるようになる時代が到来しようとしています。

 

 

 

 

RPAとの関係

 

 

最後に、このKIBITのようなAI技術とRPAの関係について述べたいと思います。

 

RPAは他のコラムでもご紹介している通り、現在市場で実装されているものは「考える」力は持たず、

手を動かす」方を中心に自動化するのが主流でした。

 

つまり、判断や示唆出しといったものではなく、

その後の定型操作・作業の自動化のみに特化しているということです。

 

一方、AIの技術というものは、まさに今回のコラムでご紹介したFRONTEO社の技術のように、

まさしく人間が「考える」とこであった判断・示唆出しを高度に自動化してくれます。

 

 

このAIRPAが融合できたときに、

考える」ことと「手を動かす」こと

が同一のPCもしくはサーバ上で行えるようになります。

 

これこそがロボットワーカーの最終形態とも呼べるものであります。

 

このAIRPAの融合というテーマは、昔から様々な識者が唱えている事であり、

 

近い将来に実際の巷間のオフィスで実現化される可能性が高いと言えます。

 

そのような世界が到来した時、RPAの活用はさらにもう一段広がることは確実であり、

人間である社員側は今とはまた違う働き方を求められる世界がやってくることになります。

 

 

 

 

【UiPath Orchestrator環境を構築する】 その4 Orchestrator

2018.09.25

 

前回は、UiPath Orchestrator環境を構築するために、ElasticsearchKibanaをインストールしました。

 

 

【前回記事はこちら】

【UiPath Orchestrator環境を構築する】 その3 ElasticsearchとKibana

 

 

 

今回は、Orchestratorをインストールします。

 

今回も、Orchestrator v2018導入ステップバイステップガイドを参考にしながら、インストールしていきます。

 

OrchestratorTCP443ポートを使用しますが、インストーラーが設定してくれます。

 

インストーラーは、UiPathサイトからダウンロードできます。

インストーラー実行後、ライセンス条項に同意して、「Advanced」を選択します。

 

 

 

 

デフォルトのインストール項目にOrchestratorは含まれていませんので、追加しましょう。

 

 

 

 

不要な項目を外して、Orchestratorだけをインストールすることもできます。

 

今回は、Orchestrator Websiteとロボットロボット自動起動機能をインストールします。

 

 

 

 

ホスト名が正しいことを確認して次に進みます。

 

 

 

 

Application Pool Identity」を選択して次に進みます。

 

 

 

 

SQL Server名uipath_sqlの名前パスワードを入力して次に進みます。

 

 

 

 

ElasticsearchURLを入力して次に進みます。

 

 

 

 

Windows認証を使用する場合は、チェックを入れて、ADドメイン名を入力します。

 

今回は、チェックを入れずに進みます。

 

 

 

 

Install」をクリックします。

 

 

 

 

インストールが完了しました。「Launch ~」のチェックを外して終了します。

 

 

 

 

インストーラーがちゃんとWindowsファイアウォールを設定してくれたか確認します。

 

 

 

 

TCP443ポートが許可されています。

インストーラーでロボットの自動起動を選択した場合は、サービスも確認しておきます。

 

 

 

 

IISマネージャーで「UiPathOrchestratorYYYY.X」サイトが作成されていることを確認します。

 

 

 

 

SSMSUiPathデータベースにテーブルが作成されていることを確認します。

 

 

 

 

続いて設定ファイルを確認します。

 

まず、IISマネージャーでサイトを停止します。

 

 

 

 

サイトが停止したら、設定ファイル

C:\Program Files (X86)\UiPath\Orchestrator\Web.config

をメモ帳で開きます。

 

 

組織単位機能を有効にしたい場合は、「OrganizationUnit.Enabled」を検索し、

見つかった行のfalsetrueに変更します。

 

Orchestratorガイドには、まだテスト中、と書いてありますが、

この機能を必要とする環境は多いと思います。

 

 

 

 

Web.config内では、「<!–」と「–>」で囲まれた部分はコメントアウトされます。

続いて、Orchestratorのログの書き込み先を確認します。

 

logger name」で検索すると見つかります。

 

 

 

 

図のようにdatabase, robotElasticBufferと書かれている場合は、

SQL ServerElasticsearchの両方にログが書き込まれます。

 

Orchestratorガイドには、200万を超えるログを保持すると、

パフォーマンスの問題が発生する場合がある、と書かれています。

 

書き込み先をElasticsearchのみにする場合は、「database, 」を削除します。

 

 

 

 

Web.configには他にもたくさんの設定項目がありますので、Orchestratorガイドを見ながら、

ご自身の環境に合うように設定しましょう。

 

 

Orchestratorガイドは、ところどころ和訳文がわかりづらくなっているので、

英語版を読む方がよいかもしれません

 

 

 

Web.configの確認/変更が終わったら、IISマネージャーでサイトを開始します。

 

 

 

 

Orchestratorの画面を見てみましょう。

 

ブラウザで「https://ホスト名」を開きます。

 

ブロックされる場合は、信頼済みサイトに追加します。

 

 

 

 

 

 

Login画面が表示されたら、「default」テナントに、「admin」ユーザーでログインします。

 

パスワードは「890iop」を使用します。

 

ログイン後、パスワード変更を要求されます。

 

 

 

 

 

 

Orchestratorの管理画面が表示されたら、

右上のAボタン(adminの頭文字)をクリックしてメニューを表示し、「Settings」を選択します。

 

 

 

 

Generalタブで、Timezoneを変更します。

 

 

 

 

日本のタイムゾーンを選ぶ場合は、UTC+09:00の中から探します。

 

選択後、「SAVE」をクリックします。

 

 

 

 

 

 

他のタブにも設定項目があるので、環境に合わせて設定します。

 

 

設定が終わったら、他のPCのブラウザでもアクセスできることを確認します。

 

自己証明書は信頼度が低いので、ブラウザに警告が表示されますが、かまわずアクセスします。

 

 

 

 

 

 

他のPCのブラウザでもログイン画面を確認できました。

 

 

この時点で、管理用ユーザーの追加等はできますが、ロボットの登録はまだできません

 

ロボットを登録するには、ライセンスが必要となります。

 

 

ライセンシングについては、次回、説明します。

 

 

 

 

 

 

 

おまけ1 httpsではなくhttpでOrchestrator管理画面にアクセスできるようにする

 

 

ブラウザでOrchestratorを見るたびに自己証明書で注意されるのは面倒です。

 

設定をいくつかいじって試してみたところ、

httpでOrchestratorにアクセスできるようになりましたので、

ここでは、その方法について書きます。

 

 

まず、UiPathOrchestratorサイトを停止します。

 

 

 

 

UiPathOrchestratorサイトのバインドを編集します。

 

 

 

 

まずhttpを追加します。

 

 

 

 

種類がhttpになっていることを確認してから、ホスト名を入力し、OKをクリックします。

 

 

 

 

httpsを選択して削除します。

 

 

 

 

httpsが削除されたことを確認してから閉じます。

 

 

 

 

サーバーを選択して、サーバー証明書をダブルクリックします。

 

 

 

 

サーバー証明書を削除します。

 

 

 

 

Web.configをテキストエディターで開き、https接続に関する部分を探し出します。

 

 

 

 

コメントアウトします。

 

 

 

 

Web.configを上書き保存してから、IISマネージャーでサイトを開始します。

 

 

 

 

以上で設定は終わりです。

 

 

ブラウザで「http://サーバー名」を開いてみましょう。

 

ブロックされる場合は信頼済みサイトに追加します。

 

 

念のため、他のPCのブラウザでも確認しておくとよいでしょう。

 

 

 

 

おまけ2 ディスク使用量

 

 

今回作成した3サーバーの、Orchestratorのインストールが終わった時点でのディスク使用量を調べました。

 

Orchestrator用サーバーのディスク使用量:

 

 

SQL Server用サーバーのディスク使用量:

 

 

Elasticsearch+Kibana用サーバーのディスク使用量;

 

 

 

 

 

今後、ロボットを動かしながら、ディスク使用量や、ログやデータベースのサイズの変化を見ていく予定です。

 

 

 

 

 

事例から見る中国のRPA発展外観

2018.09.21

 

近年、日本のRPA市場が急速に成長していることは言うまでもない事実ですが、

今回のコラムでは、中国のRPA市場発展を紹介していきたいと思います。

 

この数年間の中国では、モバイル決済、シェア経済などを始めた

「インタネットプラス」産業が急速に発展し、

いくつかの業界から言うと世界のトップランクになっていると言っても過言ではありません。

 

TencentBaidu、アリババ、Huaweiなどの企業は

最近盛り上がっているAIビッグデータにも力を入れています。

 

こんなITが好調に成長している環境のなか、RPAはどのようになっているでしょう。

本文は近年中国国内RPAに関するビッグニュースを基に、中国RPA発展の外観をみていきます。

 

 

Ernst & Youngがサポートする中国南方航空

 

中国南方航空(以下「南方航空」)は国営大手航空会社です。

2016年の売上は約1148億元(約1.8兆円)、運輸人数は約1.1億人でした。

近年LCCなどの格安航空の参入や燃料費上昇に伴い、コスト削減が大きい問題になっています。

 

そして、南方航空がRPAに目を付けました。

20186月前後から、その第一弾として、Ernst & Youngとコラボをし、

車内の財務システムをRPA化することを図りました。

 

Ernst & Youngはまず南方航空の財務業務を分析し、重要度の高い業務を180個洗いだしました

続きまして、最もRPA化に向いている業務を13個選出し、

費用対効果で評価した上で、試験として4つの業務に絞りました

 

つまり、「国内昇降費精算」、「銀行決済」、「コスト月報」と「食事費用精算

を先行業務として開発をし、実装すると同時にその効果を検証していったのです。

 

具体的な業務内容は公開されていないですが、

南方航空は業務を選定した理由については推測できるでしょう。

 

航空会社は分社や子会社がとても多いため、財務試算や精算する際に、

各グループ会社のデータを集めて、フォーマット変換などをし、

最終的に社内の会計システムに取り込みます。

作業の量が多く必要時間が長いです。

 

銀行決済、食事費用精算なども似たような特徴があります。

 

当然、これらの業務は費用対効果が大きく

RPA開発も比較的にしやすいとErnst & Youngが判断したのでしょう。

そして、試験段階の結果について、Ernst & Youngが目安結果を公開して、下記表1になります:

 

 

 

 

効果は極めて大きいと言えるでしょう。

南方航空は中国航空会社の中ではRPA導入の一番手として、今後とも他の業務をRPA化する予定です。

 

 

中国保険業界を攻めるデロイト

 

20186月の「CIFI中国保険財務革新会議」では、デロイトは参加者として、

自社の金融・保険会社向けRPAソリューション「小勤人」を披露しました。

デロイトの講演では、自社がRPA導入に成長したABC三社の事例を中心に説明をしました。

 

大手金融サービス企業A社はデロイトのRPAソリューションを利用し、

ネットバンキング突合業務を自動化しています。

 

内容として、RPAが毎日ネットバンキングから取引履歴をダウンロードし、

自社会計システムとの履歴を突後します。

とても単純な業務ですが、量が極めて多く、膨大な時間が使われています

 

このシステムの導入により、A社グループ全体で約200人の従業員がこの業務から解放されました。

 

大手外資保険会社B社は近年中国での業務量が急増しているため、

契約書処理と賠償データ処理業務も多くなっています

 

それを解消するために、RPAを導入しました。

RPAのメインの業務は新規契約書入力賠償データ更新になります。

 

業務内容についてデロイト詳しく語っていなかったですが、

主にシステムの間の転記、または突合業務になります。

 

それ以外、契約書の標準用語チェックもRPAが実行し、

間違っている言葉が使われたら自動で治すことが可能になっています。

 

結果として、今まで従業員10名が必要となる作業はRPAが代わりに行い

処理時間も70%短縮されました。

 

企業Cは中国国内大手上場保険会社であり、人事業務においてデロイトのRPAシステムを導入しました。

主に新入社員の情報確認などについてつかわれています。

 

例えば、

政府のサイトに身分証明書ID(マイナンバー相当なもの)により新入社員の個人情報取得

医療保険番号により医療保険情報の取得

などです。

 

導入により、該当業務の効率は50%向上しました。

デロイトのRPA小勤人」はデータ収集、入力、システム間の接続などに得意し、

さらにAIと組み合わせ、データ分析することも可能だと言われます。

 

 

アリババの「アリクラウドRPA」

 

アリババは中国ECサイト運営会社最大手として、近年世界中でも活躍しています。

会社が1999年設立以来、高速成長をし、2017年の売上は3.77兆元(約61兆円)に達しました。

規模が大きくなるとともに、各部署の業務量も急増しています。

 

対策として、2016年にアリババがRPAにたどり着き、自動化によって効率向上を図りました。

 

最初は問い合わせ対応(チャットボックス)ロボットを実装しました。

お客様から問い合わせがあれば一回ロボットがキーワード検索とナビの形で対応し、

対応しきれない場合従業員に振るという形でした。

 

実際の効果はとてもよく、アリババ傘下の各グループの各業務に普及してきました。

それが最終的に「アリクラウドRPA」(使用RPAソフトの種類は未公開)となり、

2016年から2017年の間で他社にサービス提供し始めました。

 

現在アリクラウドRPAはカスタマーサービス以外に、

財務文書処理などにも対応できるようになり、汎用性の高いロボットを開発しています。

 

小売、IT、金融、証券以外、自社既存のネットワーク

(地方政府がアリババのクラウドソリューションを採用しているところが多い)を生かし、

政府機関に「アリクラウドRPA」を導入しています。

また、アリババは2018年に中国RPA市場規模が急成長し、60%以上の増加率と信じています。

 

 

「国産」RPAソリューション、i-SEARCHの「iS-RPA」

 

i-SEARCH(芸賽旗)は2011年上海に設立されたITベンチャー企業です。

主にビッグデータなどのデータ分析に注力しています。

 

20181月、世界中にRPAが好調だという背景に、

i-SEARCHは「国内初のRPA総合ソリューション」とアピールポイントとし、

「iS-RPA」( i-Search Robotic Process Automation)を発表しました。

 

iS-RPA」は開発言語Python3.0をベースにしたRPAソフトです。

レコーディング操作、UI情報読み取り、

デスクアプリ対応、OCRなど主流RPAソフトの機能は一通り揃っています。

 

中国大手コールセンターは既に「iS-RPA」に基づいたソリューションを実装しています。

従業員の電話対応時間短縮をメインの目的として、

iS-RPA」は総合的なソリューションを提供しています。

 

まず、インタネットからのチャットボックス問い合わせはまずRPAナビに繋がり、

お客様の問い合わせ内容により割り振りをします。

そして人間が対応する段階になると、チャットする間にチャット内容をモニタリングをし、

特定なキーワードがチャット内容の中に現れるとRPAがそれに関連する情報を担当者に勧めます。

 

これにより、従業員がキーワードを検索する時間を短縮します。

また、電話対応するときもRPAによる「ワンタッチ業務」ロボットが実装され、

特定なUI操作をマウスクリックだけでバックグラウンドで実行されます。

 

iS-RPA」のコールセンターソリューションは完全な「無人化」することではないですが、

問い合わせ対応の時間を平均15%短縮することができました。

 

 

まとめ

 

中国のRPA市場は後発ではありますが、海外大手会計事務のリードやローカル企業の台頭により、

市場がどんどん拡大しています。

 

ざっくり分けると、中国のRPAベンダーは3種類があるように見えます:

 

  • 大手外資企業:Ernst & Youngとデロイトをはじめとしたグローバル企業は自社の高い技術力と豊富な経験を武器として中国市場に攻めている。
  • 大手ローカルIT企業:アリババなどの大手ローカル企業は自社の技術とローカルに馴染んだマーケティングルートなどを生かし、事業展開をしている。
  • ローカルベンチャー企業:i-SEARCHのような企業が現地市場に合わせた独特な製品を開発している。

 

また、今回の事例では、RPAを導入した企業のいずれも大手でした。

原因として、人件費による可能性が高いです。

 

近年中国の平均人件費は高くなっているとはいえ、日本に比べまだ低いです。

 

賃金の高い上海でも、現在の最低賃金は4万円弱/月になります。

この環境では、大きい規模でなければ、費用対効果はあまり良くない可能性もあります。

 

勿論、一概にはいえないですが、これは原因の一つだと考えられます。

逆に言うと、人件費が高い日本では、RPA導入がより多くの中小企業にも有効でしょう。

 

 

 

 

【UiPath Orchestrator環境を構築する】 その3 ElasticsearchとKibana

2018.09.20

前回は、UiPath Orchestrator環境を構築するために、SQL Serverをインストールしました。

 

【前回記事はこちら】

【UiPath Orchestrator環境を構築する】その2・・・SQL Server

 

 

今回は、ElasticsearchとKibanaをインストールします。

今回も、Orchestrator v2018導入ステップバイステップガイドを参考にしながら、

インストールしていきます。

 

 

まずはWindowsファイアウォールの設定をします。

SQL Server用にTCP 1433ポートを設定したときと同じ手順で、

Elasticsearch用のTCP 9200ポートKibana用のTCP 5601ポートに受信許可設定をします。

 

 

 

 

 

作成した規則をダブルクリックすると、

プロパティが表示されるので、設定内容を確認しましょう。

 

 

 

 

続いてJava Runtime Environmentをインストールします。

Javaのサイトから推奨バージョンをダウンロードします。

 

 

 

 

推奨バージョンのJREのインストールが完了したら、

エクスプローラーでインストールされたフォルダのパスをコピーします。

 

 

 

 

コピーしたパスを、環境変数JAVA_HOMEに設定します。

 

スタートメニュー右クリック→システム→システムの詳細設定→環境変数

 

の順にクリックしていきます。

 

 

 

 

 

 

 

環境変数ウィンドウが表示されたら、ユーザー環境変数(上段)ではなく、

システム環境変数(下段)の新規ボタンをクリックします。

 

 

 

 

変数名に「JAVA_HOME」と入力し、

変数値に先ほどコピーしておいたパスをペーストしてOKをクリックします。

 

 

 

 

システム環境変数にJAVA_HOMEが追加されたことを確認したら、

OKをクリックしてウィンドウを閉じます。

 

 

 

 

 

Javaの設定が終わりました。

 

 

次は、Elasticsearchをインストールします。

 

Elasticsearchのサイトから、インストーラーをダウンロードします。

 

 

 

 

ダウンロードしたインストーラーを実行すると、ウィザードが表示されます。

 

LocationとServiceについては、デフォルト値を使用するので、

NEXTをクリックするだけでよいです。

 

 

 

 

 

 

Configurationでは、いくつか確認すべき点があります。

まずはウィザードが自動入力してくれているNode nameがホスト名になっていることを確認しましょう。

ADに参加している場合は、ドメイン部分まで書きます。

 

 

 

 

次に、Elasticsearchが使用するメモリサイズを指定します。デフォルトは2GBです。

ステップバイステップガイドには、OSメモリの半分以下を割り当てる、と書かれています。

今回使用しているサーバーはメモリが4GBしかないせいか、2GBから変更できませんでした。

 

 

 

 

もっと多くのメモリが積まれている場合は、

つまみを左右に動かすことによって割り当てるメモリサイズを変更することができます。

 

Hyper-Vの仮想マシンで動的メモリを有効にしている場合は、注意が必要です。

動的メモリの場合の注意点については、後半のおまけの中で説明します。

 

 

Lock JVM memory」は、スワップによるパフォーマンス低下を避けるための設定です。

ここではデフォルトのままにしておいて、使用していくうちに問題が出てきたら設定を変えることにします。

 

Network hostは空欄にしておきます。

ここを空欄(デフォルト)にしておくと、localhostからのアクセスのみを受け付けるようになります。

インストールが無事成功したら、設定ファイルを編集し、

プライベートIPアドレスからのアクセスも受け付けるように設定しなおします。

 

 

 

 

ウィザードを進めると、プラグインを選択するパートになりますが、

筆者の環境ですと、日本語検索のためのプラグイン「Japanese (kuromoji) analysis」等

にチェックを入れるとValidation Errorとなり、インストールを進められなくなります

 

 

 

 

よくよく見てみると、ステップバイステップガイドのサンプル画像でもValidation Errorが出ています

ひとまずここはチェックを外して、プラグイン無しでインストールします。

Elasticsearch installed successfully」と表示されたら、さっそくブラウザで確認してみましょう。

Open Elasticsearch in the browser」をクリックします。

 

 

 

 

Internet Explorerのダウンロード

~.json このファイルを開くか、または保存しますか?」が表示されたら、

ファイルを開きます。

今回は内容を表示するだけですので、ファイルを開くためのアプリは何でもかまいません。

 

 

 

 

 

 

 

 

 

ブラウザを閉じて、ウィザードを終了します。

設定ファイルを編集するために、サービスを終了します。

 

 

 

 

C:\ProgramData\Elastic\Elasticsearch\config\elasticsearch.yml」をメモ帳で開きます。

C:\ProgramData」フォルダは、デフォルトでは隠しフォルダになっています。

 

 

 

 

ウィザードではデフォルトにしていたNetwork hostの設定を追加します。

追加する内容は、「network.host: _site_, _local_」です。_site_は、

プライベートIPアドレスからのアクセスを受け付ける設定、_local_は、

localhostからのアクセスを受け付ける設定です。

 

 

 

 

変更内容を保存してメモ帳を閉じたら、サービスを起動します。

 

 

 

 

http://localhost:9200」と「http://ホスト名:9200」の両方で接続できることを確認します。

 

http://ホスト名」が信頼済みサイトではない、という警告が表示されたら、

信頼済みサイトに追加してから、もう一度URLを入力します。

 

 

 

 

さらに、同じネットワーク内にある他のPCのブラウザでも、

http://Elasticsearch用サーバー名:9200」で接続できることを確認します。

 

 

 

 

設定が反映されたことを確認できたら、先ほど入れられなかったプラグインを追加しましょう。管理者権限のコマンドプロンプトで、以下のコマンドを入力します。

 

cd \Program Files\Elastic\Elasticsearch\bin

elasticsearch-plugin.bat install analysis-kuromoji

 

 

 

 

成功すると、「Installed analysis-kuromoji」と表示されます。
サービスを再起動すると、プラグインが読み込まれます。
Elasticsearchの設定は以上です。

 

 

 

次は、Kibanaをインストールします。

Elasticsearchのサイトから、ZIPファイルをダウンロードします。

 

 

 

 

ダウンロードしたZIPファイルをダブルクリックすると、

kibana-5.5.2-windows-x86」というフォルダが表示されるので、

これを、「C:\ProgramData\Elastic」フォルダ内にコピーします。

 

 

 

 

ファイル数が多いのでコピーには時間がかかります。コピーが終わったら、

フォルダ名を「kibana-5.5.2-windows-x86」から「Kibana」に変更します。

 

 

 

 

C:\ProgramData\Elastic\Kibana\config」内のkibana.ymlをワードパッドで開きます。

メモ帳で開くと、改行されていない状態で表示されてしまうので、ワードパッドを使用します。

server.host」の設定を追加してテキスト形式で保存します。

 

 

 

 

 

 

C:\ProgramData\Elastic\Kibana\bin」フォルダ内にあるkibana.batを実行します。

 

 

 

 

Status changed from yellow to green – Ready」と表示されたら、成功です。

このコマンドプロンプトは閉じてしまうと、Kibanaも同時に終了してしまいます

コマンドプロンプトをそのまま置いておいて、Internet Explorerで「http://自ホスト名:5601」を開きます。

 

 

 

 

about:blank」に関する表示が出たら、信頼済みサイトに追加します。

 

 

 

 

Configure an index pattern」というページが表示されれば成功です。

 

 

 

ブラウザとコマンドプロンプトを閉じてKibanaを終了します

(インデックスパターンの設定は、Orchestratorをインストールした後に行います)。

 

Kibanaをサービスに登録するために、NSSMを使用します。

NSSM 2.24のZIPファイルをNSSMサイトからダウンロードします。

 

 

 

 

ダウンロードしたZIPファイルをダブルクリックすると、

nssm-2.24」というフォルダが表示されるので、

これを「C:\Program Files」フォルダにコピーします。

 

コピー後、管理者権限のコマンドプロンプトで、以下のコマンドを入力します。

 

 

cd \Program Files\nssm-2.24\win64

nssm.exe install “Elasticsearch Kibana” “C:\programData\Elastic\Kibana\bin\kibana.bat”

 

 

 

Service “Elasticsearch Kibana” installed successfully」と表示されたら成功です。

サーバーマネージャーからサービスを起動して、

Elasticsearch Kibana」サービスが登録されていることを確認しましょう。

 

 

 

 

自動起動設定はされていますが、

この時点ではまだ「Elasticsearch Kibana」は実行されていません。

右クリックして「開始」します。

 

 

 

 

 

 

Elasticsearch Kibana」サービスが「実行中」状態になりました。

Internet Explorerで「http://自ホスト名:5601」を開いて、

Configure an index pattern」が表示されることを確認します。

念のため、他のPCのブラウザでも確認しておくと良いでしょう。

 

 

 

 

以上で、ElasticsearchとKibanaの設定は終わりです。

 

 

次回は、Orchestratorをインストールします。

 

【次回記事はこちら】

【UiPath Orchestrator環境を構築する】 その4 Orchestrator

 

 

 

 


おまけ1 Hyper-V仮想マシンへのElasticsearchインストール

 

Hyper-Vの仮想マシンで動的メモリを有効にしている場合、注意が必要です。

 

 

 

 

動的メモリが有効になっていると、

ウィザードが起動された時点で仮想マシンに割り当てられていたメモリサイズが、

ウィザード上でElasticsearchに割り当てられるメモリサイズの最大値となってしまいます。

 

 

 

動的メモリを無効にしている場合

 

 

 

 

 

 

 

動的メモリを有効にしている場合

 

 

 

 

 

動的メモリを使用する場合は、あらかじめ「この仮想マシンが使用できるメモリの量」、

もしくは、「最小RAM」を大きめに設定しておきましょう。

 

 

 

 

【UiPath Orchestrator環境を構築する】その2・・・SQL Server

2018.09.19

【前回記事はこちら】

 

【UiPath Orchestrator環境を構築する】その1・・・初期設定

 

 

 

前回は、UiPath Orchestrator環境を構築するためのWindows関連の設定を行いました。

 

 

今回は、SQL Server用サーバーに、SQL Server 2017をインストールします。

 

まずはWindowsファイアウォールを設定します。サーバーマネージャーのツールメニューで、

セキュリティが強化されたWindowsファイアウォール」を選択します。

 

 

 

 

セキュリティが強化されたWindowsファイアウォール」が表示されたら、

左ペインの「受信の規則」を選択してから、右ペインの「新しい規則」をクリックします。

 

 

 

 

新規の受信の規則ウィザード」が表示されたら、「ポート」を選択して次に進みます。

 

 

 

 

TCP」と「特定のローカルポート」を選択し、

SQL Serverが使用するポート番号「1433」を入力してから、次に進みます。

 

 

 

 

接続を許可する」を選択して次に進みます。

 

 

 

 

規則が適用されるプロファイルは、ご自身の環境に合わせて選択してください。

筆者の環境では特に限定する必要が無いので、すべてにチェックを入れています。

 

 

 

 

最後に、受信規則に名前を付けます。「SQL Server」等、わかりやすい名前を付けましょう。

完了をクリックすると受信の規則が追加されます。

 

 

 

 

SQL Server用の受信の規則が作成されました。

 

 

 

ファイアウォールの設定が終わったら、SQL Serverをインストールします。

SQL Server 2017の評価版は、Microsoftのサイトからダウンロードできます。

 

 

EXE形式をダウンロードして起動すると、インストールの種類を選択する画面が表示されます。

メディアのダウンロード」を選択すると、インストールメディアをISO形式でダウンロードできます。

 

 

 

 

 

 

ダウンロードしたISOファイルをダブルクリックすると、メディアの中身が表示されます。

Setupを実行すると、SQL Serverインストールセンターが表示されます。

 

 

 

 

 

 

左のインストールメニューから、新規スタンドアロンインストールを実行します。

 

 

 

 

今回は、無償のエディションを指定します。

 

 

 

 

ライセンス条項に同意すると、ルールチェックが行われた後に、

Microsoft Updateを使用するか尋ねられます。

チェックを入れて次に進みます。

 

 

 

 

インストールルールでチェックが行われます。

Windowsファイアウォールの警告は無視してよいです。

 

 

 

 

インストールする機能の選択で、「データベースエンジンサービス」を選択して次に進みます。

 

 

 

 

インスタンスの構成で「既定のインスタンス」を選択します。

 

 

 

 

サーバーの構成では、照合順序を「SQL_Latin1_General_CP1_CI_AS」に設定します。

 

 

 

 

 

 

 

 

認証モードはどちらでも構わないようです。

今回は混合モードに設定します。

現在のユーザーの追加」を行ってから、次に進み、インストールを実行します。

 

 

 

 

 

 

 

 

インストールが完了したら、SQL Serverインストールセンターも終了します。

SQL Server関連サービスの設定を確認します。

サーバーマネージャーのツールメニューからサービスを選択します。

 

 

 

 

 

 

続いてSQL Server Management Studio (以下SSMS)を、

Microsoftのサイトからダウンロードしてインストールします。

インストーラーを実行して、インストールボタンを押すだけです。

 

 

 

 

 

 

スタートメニューの「Microsoft SQL Server Tools」内にある、

SSMSを起動してSQL Serverにログインします。SQL Server認証で接続します。

 

 

 

 

ログイン後、オブジェクトエクスプローラで、UiPathデータベースを作成します。

 

 

 

 

データベース名に「UiPath」と入力し、OKをクリックします。

 

 

 

 

次に、新しいログインを作成します。

 

 

 

 

全般メニューで、ログイン名「uipath_sql」を入力します。SQL Server認証を選択します。

 

 

 

 

次に、サーバーロールメニューで、dbcreatorを追加します。

 

 

 

 

続いて、ユーザーマッピングメニューで、masterデータベースとmsdbデータベースのpublic

UiPathデータベースのdb_ownerpublicの役割を与えたら、

OKをクリックしてユーザーを作成します。

 

 

 

 

 

 

 

 

最後に、作成したユーザーに権限を与えるクエリを発行します。

新しいクエリ」ボタンをクリックします。

 

 

 

 

以下のクエリを書き込んだら、「実行」ボタンを押します。

 

USE master

GO

GRANT EXECUTE TO [uipath_sql]

GO

 

USE msdb

GO

GRANT EXECUTE TO [uipath_sql]

GO

 

 

作成したユーザーでログインできることを確認するため、SSMSを終了してから接続しなおします。

終了時にクエリを保存するかどうか尋ねられますが、保存する必要はありません。

 

 

 

 

以上でSQL Server関連の設定は終わりです。

 

次回はElasticsearchKibanaをインストールします。

 

 

【次回記事はこちら】

【UiPath Orchestrator環境を構築する】 その3 ElasticsearchとKibana

 

 

 

 

 

おまけ UiPathデータベースの中身

 

UiPathデータベースの中身が気になる人もいらっしゃると思います。

今回の手順ではデータベースを作成しただけなので、

テーブル一覧を表示させても結果は下図のようになります。

 

 

 

 

Orchestratorのインストール直後に同じことをすると、以下のような結果が出ます。

 

 

 

 

58個のテーブルが作成されています。

ときどき中身を確認したくなりそうなテーブルもいくつか作られています。

 

 

 

 

 

 

 

【UiPath Orchestrator環境を構築する】その1・・・初期設定

2018.09.18

UiPathの扱いに慣れてくると、

きっとUiPath Orchestratorを使ってロボットを管理してみたくなるでしょう。

 

UiPath Orchestratorを導入することにより、スケジュール管理やログ管理など、

さまざまなことを実現できます。

 

UiPath Orchestratorを試すのに最も簡単な方法は、

UiPath社が公開してくれているUiPath Community Edition Orchestratorを利用することです。

 

簡単な手続きをするだけで、UiPath Orchestratorによるロボット管理の雰囲気を掴めるようになります。

こちらを利用しても良いのですが、サーバサイドの理解も深めるために、

UiPath Orchestrator環境を構築してみようと思います。

 

UiPath Orchestrator環境を用意するために必要なハードウェア要件やソフトウェア要件は、

UiPath Orchestratorガイドにまとめられていますので、一度、目を通してみてください。

 

 

大まかに言うと、以下の役割を果たすWindows Serverを用意することになります。

 

・UiPath Orchestrator Web Server (必須)

・Microsoft SQL Server (必須)

・Elasticsearch、Kibana (オプション)

 

基本はサーバー3台、小規模な環境ではサーバー2台でも可、とガイドに書かれています。

今回は、Hyper-V上に仮想サーバー3台を用意します。

 

 

Orchestrator v2018導入ステップバイステップガイドを参考にしながら、

以下の順番でインストールしていきます。

 

1:Windows Serverの設定

2:SQL Serverの設定

3:ElasticsearchとKibanaの設定

4:Orchestratorの設定

 

今回はWindows Serverの設定をします。

MicrosoftのサイトからWindows Server 2016評価版をダウンロードできます。

 

 

まずはOSのインストールやネットワークの設定、Windows Update等を済ませましょう。

準備が終わったら、以下の設定を行っていきます。

 

1:役割と機能の追加

2:Web Deploy 3.5とURL Rewrite 2.1のインストール

3:自己署名証明書の作成

 

いずれも、Orchestrator用サーバーに対して行います。

 

 

まずは、役割と機能を追加します。

念のため、デフォルトの役割と機能を確認しておきます。

 

 

 

 

ウィザードをサーバーマネージャーから起動して、役割と機能を追加していきます。

 

 

 

 

ウィザードが表示されたら、「サーバーの役割の選択」が表示されるまで「次へ」を繰り返します。

サーバーの役割の選択」が表示されたら、「Webサーバー(IIS)」にチェックを入れます。

 

たまに、追加しようとしている役割に必要な機能も追加するかどうかを尋ねられるので、

そのときは、追加してあげましょう。

 

 

 

 

次へ」をクリックすると、「機能の選択」が表示されます。

ステップバイステップガイド「2.2. 前提条件のコンポーネントのインストール」内の

表に記載されている機能を追加します。

 

 

 

 

 

 

 

 

 

 

インストールオプションの確認」に進み、

必要に応じて対象サーバーを自動的に再起動する」にチェックを入れてから、

インストールをクリックします。

 

 

 

 

 

正常に完了しました」と表示されたら、「閉じる」をクリックして終了します。

役割と機能がちゃんと追加されているか確認します。

 

 

 

 

問題なさそうです。

 

次は、Web Deloy 3.5URL Rewrite 2.1をダウンロードします。

どちらも、x86用ではなくamd64用をダウンロードします。

 

 

 

 

 

 

 

 

ダウンロードしたインストーラーを実行します。

Web Deploy 3.5は「標準」セットアップでインストールします。

 

 

 

 

URL Rewrite 2.1もインストールします。選択する項目が無いので割愛します。

 

次は、自己署名証明書を作成します。

サーバーマネージャーからIISマネージャーを起動します。

 

 

 

 

IISマネージャーで、サーバーを選択してから、サーバー証明書をダブルクリックします。

 

 

 

 

自己署名入り証明書の作成」をクリックします。

 

 

 

 

FQDNを入力し、証明書を作成します。

 

 

 

 

自己署名証明書が作成されたことを確認します。

 

 

 

Orchestrator用サーバーのWindows関連の設定は以上です。

 

次回は、ElasticsearchKibanaの設定を行います。

 

【次回記事はこちら】

【UiPath Orchestrator環境を構築する】その2・・・SQL Server

 

 

 

おまけ

 

UiPath Orchestratorとは直接関係ありませんが、

Windows Serverの設定をするときに手助けになりそうな小ネタを書きます。

 

 

 

 

おまけ1 コンピューター名の設定方法

 

 

コンピューター名の設定方法がわからない方のために。下の画像を参考にしてください。

 

 

 

 

スタートボタン右クリック→システム→システムの詳細設定→コンピューター名タブ→変更、

 

とクリックしていくと、コンピューター名の入力欄が表示されます。

新しいコンピューター名を入力してOKボタンを押すと、

再起動を促す表示が出ますので、再起動しましょう。

 

 

 

 

おまけ2 役割と機能の一覧

 

 

Windowsの役割と機能の一覧をPowerShellで出力する方法です。

Windows ServerPowerShellで「Get-WindowsFeature」コマンドを実行すると、

役割と機能の一覧を取得できます。

 

 

 

 

ただし、機能の名前が長いと、省略されてしまいます。

 

この例ですと、「Active Directoryライトウェイトディレクトリサービス」が省略されています。

 

省略させずに表示させたい場合は、

Get-WindowsFeature | Format-Table -Autosize -Wrap」を使用しましょう。

 

 

 

 

インストールされている機能だけを表示したいときは、

Get-WindowsFeature | oss | sls \[X」を使用します。

 

Format-Tableと組み合わせることも可能です。

 

 

 

 

おまけ2のおまけ

 

 

Windows10にはGet-WindowsFeatureコマンドはありませんが、

代わりにGet-WindowsOptionalFeatureコマンドを使用できます。

 

Windows10で役割と機能の一覧を取得したいときは、

Get-WindowsOptionalFeature -Online | Format-Table」とすると、見やすくなります。

 

 

 

 

【実際の導入事例】RPAを導入してから運用まで

2018.09.14

RPA導入の目的

弊社のRPA導入の最大の理由は

事務員の人手不足を解消し、より専門的な知識を必要とする業務に時間を割くこと」です。

 

人手不足の問題は多くの中小企業が直面していると思います。

弊社の事務員は女性20名ほどで構成されており、仕事内容から3つのグループに分かれています。

 

 

産休・育休を積極的に取り入れているため、結婚や出産後も安定して勤めることができる反面、

復職後の席を空けておく必要があるので、安易に新しい社員を採用できないという問題があります。

 

 

しかしながら、現場は当然人手不足に陥り、以前よりも残業を強いられることになります。

 

このような背景の中で、今回、RPAを導入し事務仕事の機械化を進めようというプロジェクトが発足しました。

 

 

筆者は、そのプロジェクトチームのメンバーの一人であり、一事務員の立場です。

 

プロジェクトチームは、3つのグループを束ねるリーダーと

各グループから1名ずつ選出されたメンバーで構成されています。

 

 

 

RPA vs 派遣社員

人手不足はRPAでしか解消されないのか、と問われれば答えはNOです。

 

弊社でも当初派遣社員の雇用が検討されていました。

 

説明するまでもないですが、休職者が復職するまでの期間限定で派遣社員を雇い、

事務員の業務の負担を軽減するためです。

 

 

比較する際のポイントは下記の2点が挙がりました。

① 費用 ・・・ 経営者サイドで重要な検討事項
② 効果 ・・・ 事務員サイドの要求事項

 

一つ目の費用については、筆者は一事務員であり具体的な数字は把握していないため割愛しますが、

結論として派遣社員よりもRPAの方が安く済むとのことでした(長期的な目で見た結果かもしれません)。

 

 

二つ目の効果については、派遣社員の場合、教育時間を懸念する声が挙がりました。

 

また、時間を割いて教育したのに関わらず期間限定で辞めてしまうのは非効率であるという意見も挙がりました。

 

一方、RPAに関しては、最初にシナリオ作成や操作者の教育に時間が必要になりますが、

長く使っていけるという意味では効率的であるという肯定的な意見が多く挙がりました。

 

こうして、経営側と事務側の意見が一致する形で、弊社ではRPAの導入が決定することになりました。

 

 

 

Winactorの導入

弊社ではRPAソフトの中でNTT系Winactorを導入しました。

理由はより感覚的に操作ができるからです。

 

 

弊社では、システム担当の社員がRPAの開発に携わるのではなく、

事務員が全て対応するという方法をとりました。

 

会社によっては情報システム課のような部署がまとめてシナリオ作成をする場合もあれば、

弊社のように現場の社員が作成する場合もあるようです。

 

 

事務員は、基本的システム系は弱かったため(筆者も専門知識はない)、

とっつきやすいソフトを選択しました。

 

 

下の画像は、Winactorの画面です。

 

 

 

 

シナリオを作成する画面ですが、ご覧の通りプログラミングのような専門知識は不要で、

必要なパーツが予め用意されています(パーツは表示されている部品は一部です)。

 

その項目を繋ぎ合わせていくとシナリオが完成するというイメージです。

 

 

例えば、エクセルを開いてA2セルの数値をコピーし、A3セルにペーストしたい場合は、

 

「エクセルを開く」→「A2セルに移動」→「選択中のセルをコピー」

→「A3セルに移動」→「選択中のセルにペースト」

 

という5つのパーツで表現することができます。

 

 

複雑な操作をしたい場合にはパーツを改造する必要が出てきますが、

一般的な事務作業には充分対応できるパーツが揃っています。

 

 

 

シナリオ作成のtips

 

上述の通り、プロジェクトは4名で進められましたが、

各チームで仕事内容が異なるため、実際には各々が異なるシナリオ作成を進めることになりました。

 

 

弊社は3日間の保証プランに入ったため、

最初の3日間はWinactorの代理人の方にお越しいただきシナリオのベースを作成してもらいました。

(詳しい契約内容は把握しておりませんので割愛します。)

 

 

基本的に、Winactorは自分たちでシナリオを作成する(そのためにより感覚的な操作が可能)こと

をコンセプトとして商品を売り出しているため、代理人に作業してもらえる3日間は非常に貴重です。

 

自分たちでシナリオを作成するためのヒントをどれほどもらえるかが勝負になります。

 

 

保証期間に臨む際のポイントは下記の3点です。

① 自動化したい業務のフローを細部まで説明できるようにしておく
② 多くのシナリオに共通する部分を作成してもらう
③ より高度な操作を要するシナリオを作成してもらう

 

 

毎日何気なく行っている作業でも、機械にやらせようとすると

一つ一つの作業を順序だてて考える必要が出てきます。(人間がいかに優秀な動物であるかを実感します。)

 

 

例えば、Aのときは○をクリックし、Bのときは△をクリックするという簡単な操作も、機械だと次のように認識します。

 

「Aの場合→true」、「A以外の場合(つまり、ここではB)→false」、

「trueの場合→○をクリック」、「falseの場合→△をクリック」

 

このように、true/falseの場合分けのような部品が必要になります。

 

 

業務フローを細部まで理解しておくことで、代理人に的確な説明をすることができ、

短い保証期間を有効に使うことができます。

 

 

 

また、共通する事務作業の部分を作成してもらうこともおすすめします。

 

クライアント毎に異なるシステムを使用している場合もあると思いますが、

社内のデータベースの操作等は共通する部分だと思います。

 

その部分を作成してもらうことで、他のシナリオ作成時にインポートして再利用することができます。

 

 

 

最後に、より複雑なシナリオ作成を依頼することも重要です。

 

やはり、プロが作成するシナリオと初心者とでは雲泥の差です。

 

 

何が違うかというと、運用した際のエラーの数が全然違います。

プロのものは、エラー対策の工程が組まれているためです。

 

エラーの対策ができるまでにはWinactorの経験が必要となると言えます。

そのため、難関な作業は最初にプロに作成してもらうことが得策です。

 

 

 

RPA導入の効果

実運用から半年以上が経過しましたが、確実に業務負担の軽減が実現しました。

 

今まで、エクセルに入力し、その情報をクライアントのシステムに入力し、

二つに齟齬がないかダブルチェックをし・・・

 

と随分無駄なことをしていたと思い知らされる日々です。

 

現在は、入力箇所が一つとなり、そこから機械が自動で必要な情報をピックアップしてくれます。

 

弊社では、クライアント毎に異なるシステムやフォーマットを使用しているため、

運用方法を覚えるということも重要な仕事の一つでした。

 

しかし、現在ではクライアントを意識することなく業務を統一化できています。

 

作業がより単純になることでミスも大幅に減り

余った時間をより専門的な知識を要する業務に割くことができています。

 

残量時間でいうと半分になった人が大半です。

 

 

 

RPA操作の課題

RPA導入により、操作する側の教育は依然として課題が多く残ります。

 

筆者もなかなか忙しい毎日を過ごしています。

 

新しいシナリオの作成も必要ですし、運用中のシナリオのエラー対策も欠かせません。

何度やってもエラーがなくならない箇所もあり、素人が操作する限界を感じることもあります。

 

 

そこで、RPA教育用の教材や研修の参加を会社から勧められたので受講を検討しているところです。

また、使う側(事務員)の教育も日々進めなければなりません。

 

事務員は今までとやり方が変わる部分を覚える必要があり、

例えばファイルを格納するフォルダを間違え、機械がファイルを認識しない等、

慣れるまでは人的ミスが発生することがあります。

 

 

こうした課題を一つ一つクリアにしていき、安定したRPA運用を実現していくことが、

プロジェクトチーム使命であります。

 

 

 

 

 

 

 

RPAのクラウド化はどこまで進んでいるのか?クラウド型RPAのメリット・デメリット

2018.09.13

RPAツールの提供形態は、大きく分けて「開発型」「オンプレミス型」「クラウド型」の3つに分かれています。

 

これまで、多くのRPAツールは、オンプレミス型として提供されており、

一部が開発型で提供されていました。

しかし最近では、RPAの機能をクラウドサービスとして提供するクラウド型も増えてきています。

 

そこで、RPAのクラウド化はどこまで進んでいるのか、

クラウドで提供されるRPAツールにはどのようなものがあるのか、

メリット・デメリットにはなにがあるのか、などを解説していきましょう。

 

 

既存RPAは開発型かオンプレミス型

 

クラウド型RPAの話しをする前に、開発型RPAオンプレミス型RPAとはどのようなものなのかを説明します。

 

 

開発型RPAとは、汎用プログラミング言語とAPIを利用して自動化をしていく形態のことをいいます。

パッケージをそのままインストールしていくのではなく要件定義から設計していきます。

 

そのため、自社の環境に合わせて柔軟にカスタマイズできますし、

自動化できる業務範囲も広げられるメリットがあります。

 

一方、高度なプログラミング知識が必要となるほか、ある程度の人員も必要になります。

そのため、導入までの期間が長くなり、コストも高めになるといったデメリットがあります。

 

この開発型RPAには「ROBOWARE」などのツールが存在します。

 

 

オンプレミス型RPAとは、RPAベンダーが用意したパッケージをインストールして使用する形態のツールです。

このタイプは「ルールベース」「マクロ」「スクリプト」など、

ある程度決められたテンプレートをもとに業務の自動化を行っていきます。

そのため、テンプレート型RPAと呼ぶこともあります。

 

オンプレミス型RPAでは、複雑なプログラミングをする必要がないため、

現場のユーザー自らが業務の自動化を実現できます。

コスト的にも、開発型RPAより安価に導入ができるといったメリットが存在します。

 

ただし、

テンプレートが提供されている単純作業以外の複雑な作業には対応できない

可能性があるといったデメリットもあります。

 

また、「どの範囲までRPAを適用できるのか」「どこまでカスタマイズできるか」

といったことはツールに依存することになります。

 

「UiPath」「WinActor」「BizRobo!」など、

市場に存在する多くのRPAツールは、このオンプレミス型RPAとして提供されています。

 

 

クラウドサービスとして提供されるRPAの登場

 

 

クラウド型RPAとは、

インターネット上のサービス(=クラウドサービス)へとログインして、Webブラウザ上で行える業務を自動化

させるものです。

 

インターネット上で必要な機能だけを提供しますので、

SaaS(Software as a Service)型RPA」と呼ばれることもあります。

 

得意とする業務は、

Web上のデータ収集やリサーチ、Excel、CSV、Google Spreadsheetsファイルなどへ出力

他のクラウドサービスへのデータ入力

あるいは、その組み合わせになります。

 

そのため、Web上のデータを取得したり取り扱ったりする定型業務に向いています。

 

 

クラウド型RPAのメリット

 

クラウド型RPAのメリットは、クラウド上でサービスが提供されることで

初期導入コストも運用コストも低く抑えられることです。

導入までの期間も短いため、すぐに導入ができるのも特長です。

 

また、クラウド型RPAで自動化できるのはWebブラウザ上で行う作業ですから、

現場の担当者が日常的に行っている業務をすぐに自動化していくことができます。

 

担当者レベルでも、導入効果をすぐに感じることができるでしょう。

 

  • ロボットを稼働させながら他の作業ができる

 

デスクトップにインストールするタイプのRPAツールの場合、インストールしたパソコン上で動作します。

そのため、ロボットを稼働させている間はパソコンが占有され、他の作業は基本的にできなくなります。

 

しかしクラウド型RPAの場合、ロボットはクラウド上では稼働していますのでパソコン自体は占有しません。

RPAツールを稼働させていても通常業務を行えるということです。

 

それだけでなく、サービスからログアウトしたとしても、Webブラウザを閉じたとしても、

さらにパソコンの電源を落としたとしても、

クラウド上で365日24時間ロボットは稼働しているわけです。

 

したがって、RPAを稼働させるためのパソコンを用意するコストや設置するスペースは必要ありません。

 

  • 別のパソコンでもすぐ稼働できる

 

RPAツールをインストールしたパソコンが故障などで使えなくなった場合、

別のパソコンにRPAツールを再度インストールし、環境設定を行う必要があります。

 

その点、クラウド型RPAなら、インターネットへ接続できる環境さえあれば、

別のパソコンを使うことで作業を継続できます。

(クラウドサービスは全般的に同じだと思いますが)

 

クラウド型RPAは、端末にサービスが紐付いているのではなく、アカウントにサービスが紐付いています。

そのため、アカウントさえ持っていれば、

異なるパソコンでも、異なる拠点でも、すぐに同じ作業が続けられるわけです。

 

 

クラウド型RPAのデメリット

 

クラウド型RPAWebブラウザ上で動作するシステムです。

そのため、他のクラウドサービスを操作したり、Webサイトから情報を取得したりといった、

Web上での作業の自動化が得意領域です。

 

その反面、パソコン内のファイル閲覧やシステム操作といった

ローカル環境での作業はできませんので、導入にあたって注意は必要です。

 

 

クラウド型RPAのルーツ

 

クラウド型RPAが登場したのはここ最近のことですが、

広義のRPA”あるいは“クラウド型RPAのルーツ

ともいえるWebサービスの連携ツールは数年前から提供されていました。

 

その代表といえるサービスは、「IFTTT」(イフト)と「Zapier」(ザピア)です。

 

これらのサービスは、「●●●がされたら、×××をする」というような

「きっかけ」と「行動」のコンビネーションが基本となります。

 

例えば、

「ツイートしたら、その同じ内容を自動的にEvernoteに保存する」

「●●●(特定の相手)からメールを受信したら、SMSでプッシュ通知する」

というように複数のWebサービスを連携してくれます。

 

ただ、IFTTTZapierもインターフェイスが日本語化されていないのはネックです。

 

日本語化された同種のサービスには、

Yahoo! JAPANの「myThings」、

Microsoftの「Microsoft Flow

があります。

 

myThingsは個人ユーザー向けWebサービスとの連携が中心になっていますが、

Microsoft Flowは、Microsoft社製アプリケーション中心に連携できるアプリケーションも増加し、

仕事でも使えるようになってきています。

 

BizteX cobitを皮切りに続々登場するクラウド型RPA

 

Webサービス連携ツールと比べ、クラウド型RPAが登場したのはつい最近のとです。

国内で提供されるクラウド型RPAとしては、20177月に登場した「BizteX cobit」が初めてとなります。

 

2018年になってからはBizRobo!を採用したクラウド型RPACREO-RPA」や、

BizRobo!をクラウド化したRPAツール「BizRobo! DX Cloud」がサービスをスタートしています。

 

また、クラウド環境である「AWS」(Amazonウェブサービス)にRPAツール「UiPath Orchestrator

を導入できるクラウド型RPA導入支援サービス「RPA on AWS」も登場しています。

 

さらに、20189月からは注目に値するクラウド型RPAも登場します。その名は「Robotic Crowd」です。

 

Robotic Crowdは、UiPathの導入支援やRPAコンサルティングで実績を持つ

株式会社チュートリアルが自社開発したRPAツールです。

 

クラウド型RPAを前提として開発したツールであるRobotic Crowdは、

ドラッグ・アンド・ドロップで直感的に操作できるほか、テキストベース(YAML)での設定もサポート。

RPA入門者から熟練開発者まで対応しているのが特長です。

 

また、ディベロッパー向けのコミュニティが提供されているので、

公開されているワークフローを利用したり、わからないことの相談・質問をしたり、

といったことが無料でできるようになっています。

 

2018年8月まではクローズドβ版として提供されていましたが、

既に大手Web系企業で採用事例もありことから、注目すべきクラウド型RPAといえるでしょう。

 

まとめ

 

クラウド型RPAWebブラウザ上で動作するシステムです。

そのため、ローカル環境だけで行うファイルの閲覧やシステムの操作などは自動化できません。

当然、基幹システムに入りこんだ作業も不可能です。

 

そのため、自社の業務内容の棚卸しをしてから導入するかどうか決めることが大事です。

ただ、開発型RPAやオンプレミス型RPAなど、既存RPAツールとの共存も可能ですので、

すでにRPAを導入している企業でもクラウド型RPAを検討する余地はありそうです。

 

 

 

地方自治体におけるBPO【vol.4】・・・オペレーター側

2018.09.12

 

【前回記事】

地方自治体におけるBPO【vol.3】・・・委託側

 

 

これまで、BPOの委託業者と自治体側について述べてきました。

本ブログはRPAに関する情報サイトなので、RPAについて述べていきたいと考えていましたが、

オペレーター側のこともと要望があったため、オペレーター側について述べていきたいと思います。

 

 

1.改めてBPOとは

ネットなどで、「BPO」と検索すると、

 

Broadcasting Ethics & Program Improvement Organization(放送倫理・番組向上機構)

 

がヒットし、情報収取するとそちらのBPOの情報がヒットするため、

BPOに関係ない分野の方から『BPOって面倒』とご指摘を受ける場合があります。

BPO関連について検索する際は、【BPO 業務改善】など、単語と組み合わせて検索すると良いでしょう。

 

そもそもBPOとは、business process outsourcingの頭文字から取っているだけで、

BPO(ビーピーオー)と呼び人もいれば、アウトソーシングと呼ぶ人もいます。

BPOを受託する会社のことをBPO業者とも呼んだり、アウトソーサーなどと呼んだりもします。

 

 

業務委託といった方が通用する場合もあります。

中には派遣と勘違いされる方もいますが、派遣と業務委託には大きな壁があり、

実際、働く人にとっては、BPOでも常駐型BPOになると

BPO業者が一切入らない派遣では働き方は大きく異なります

 

給与計算代行サービスやNHKの収納代行サービスなどもBPOの一部として以前よりも定着してきましたが、

中々理解を得られないので、経済産業省でもBPO市場規模が一番大きい

としているコールセンターを例えに説明すると理解を得られやすいかと思います。

 

 

2.BPOの分類

 BPO業者がBPO業務を分類する際、直接業務や間接業務に分類が一般的ですが、

他にも様々な分類方法があります。

 

本ブログでは、

フロント業務(受付・窓口)バックヤード業務(事務)中間業務(コールセンター・カスタマーセンター)

と分類させていただきます。

 

確かに営業や研究開発もBPO業務の一種なのですが、雇用形態が正社員をメインとしているため、

BPO関連業務で働くオペレーター目線に立つと、

フロント業務、バックヤード業務(事務)、中間業務(コールセンター)が妥当なところかと思います。

 

一般的なBPO業務として、コールセンターが代表的なものであるというのは先で述べた通りです。

例えば、コールセンターで想像が付きやすいのは、通販業界の受注センターかと思います。

 

特にTV通販は電話での受注が多く、TV通販の番組など時間帯に合わせて増員をかけたりする必要があります。

名物社長がよくテレビに出ているような大きな会社はさておき、

中小規模の会社が受注センターを運営しようとするとかなり大変です。

 

TV通販は扇動的に商品アピールをし、なおかつ購買層が高めなので、

電話注文が多く、コールセンターに頼らなければいけません。

 

 

一方、世界的なネット通販の大手などでは、電話での注文を受けることはしません。

その要因としては、注文データのデジタル化までの時間にあります。

 

電話だと電話を受けたオペレーターが電話で聞いた注文情報を発注システムに登録するまでに10分程度、

短くても登録前のチェックも含めて5分程度かかります。

 

 

しかし、ネットだと顧客がデジタル化する作業や確認まで顧客自らがやってくれるため、

 

通販業者のデジタル化にかかる時間は0分になります。

 

世界的なネット通販の大手は効率性を重視し、その代わりに安い値段設定をするよう、企業努力をしています。

大企業が本気でやっている効率化というのは見習うべき点も多いと思います。

 

先ほど述べた世界的な通販サイトだと効率化が図られており、事務系職が極端に少ないと聴いています。

世界的な通販サイトの話は極端すぎますが、中小の通販サイトでも電話での受注を受ける場合、

電話での受注が多ければ受注センターを外部に委託したり、

受注事務があるようであれば、受注事務も合わせてアウトソーシングをしたりしています。

 

話はそれましたが、

日本のBPO業界というのは特殊なものを除けば、コールセンターを中心として回っていて、

それに付随しバックヤード業務(事務)があるという形態が比較的多いようです。

 

一方で内閣府から各地方自治体に対し、窓口業務を委託するようにと通達があり、

各地方自治体の担当者はアウトソーシングするにあたり、頭を悩ませているようです。 

 

 

3.働く側について

BPOで働く人達の雇用形態は、パート派遣契約、以上の3つの雇用形態に集約されるかと思います。

 

以前であれば、BPOの雇用形態のメインとなっていたのはパート社員でした。

特に多かったのは育児中の女性でした。

子育てをしているとどうしても時間的な制約があり、

サービス残業も少ない(ないとは言い切れないのが日本の実情です)仕事を探すと、

比較的BPO関連業務になります。

 

パート社員でも中小企業の直雇用だとサービス残業が多いため、

時間的融通が利く業種や業態を選ぶ傾向があります。

 

また、配偶者控除が変更され、BPO関連業務に従事する方の中でもフルタイムで働くより、

扶養の範囲内で働きたいという方が以前より増えています。

BPOを運営する事業者にとって、短時間勤務で就労する方をどのように戦力化するかは腕の見せ所となります。

 

 

4.働く側の動向について

実際、地方自治体BPO関連で応募をかけるとこの数年で応募状況はかなり様変わり

しました。

 

 

 

実際上記添付の資料を見ていただければすぐに分かるかと思いますが、

18歳未満の子供がいる世帯は年間1%ずつ減っています。

追い打ちをかけるように求人倍率がバブル期を超えており、

転職バブルという言葉もあるように求職者と企業のバランスは崩壊しています。

ただし、女性から人気がある事務職の有効求人倍率は0.5以下なので、

事務職に関しては競争率がかなり高いです。

事務系職の少ない地域で事務系の求人を出せば、

応募者が多くてBPO事業者が勘違いし、人が辞めても次に採用すればよいと安直に考えてしまいます。

 

 

業務によって数値はかなり異なりますが、BPO関連で働くパート社員1年以内の離職率は3割と言われています。

実際、次のステップに進む人もいれば、職場が嫌になって退職する方もかなりいます。

 

特に地方自治体BPOだと、BPO業者と自治体の契約が終われば雇用も終わるため、

将来的な雇用状態を考えると退職しやすい環境です。

 

 

5BPO関連で働く人のキャリア

BPO関連で働く人のキャリアモデルとしてコールセンターも事務センターも多くは下記の通りです。

 

OP(オペレーター)→LD(リーダー)→SSV(サブスーパーバイザー)

→SV(スーパーバイザー)→MGR(マネージャー)

 

LDかSSVぐらいで契約社員、SVかMGRぐらいで正社員、といった流れでなるのですが、

それはあくまでも民間BPOでかつ長期でセンター運営がなされている場合のみです。

 

自治体BPOだと委託の契約期間が1年や、中には半年ぐらいもあります。

また数名ぐらいの規模なので、上記のようなキャリアモデルが形成されているとは言い難い状態です。

民間BPOと違い、自治体(市役所内)に入っていることが多く、そのようなキャリアモデルが築くことができません。

怖いSVが圧政を敷いている現場が比較的多いです。

 

運営能力の低いBPO業者で働くと、すぐにSVになれることはあるかもしれませんが、

基本的にSV教育はほぼないと考えるとよいでしょう。

募集要項などに教育体制が充実していると表現している企業で

本当に教育体制が充実しているところは極稀です。

 

キャリア形成を考えて、この企業では無理だと判断して辞めるケースが多く、

優秀な人であればあるほど退職までの期間は短くなります。

 

 

BPOの目的はあくまでもコストカット目的です。

ノウハウの活用を目的にBPO業者に委託するというのは建前です。

コストカットを目的に委託しているので、教育に費用はかけません

 

BPOで教育が充実しているのは、金融業界生保業界です。

どちらも中途半端な教え方をすると間違った案内や処理をすると後で大問題になるからです。

 

採用企業もダイバーシティ(多様性)ということで雇用形態を多様化することで、

応募者の掘り起こそうとしていました。

その結果、BPO関連で働く人のメインの雇用形態はパート社員が一時増えました

最近は地方自治体BPOでも契約社員にするケースが増えましたが、

雇用情勢の変化の波も、遂に地方自治体BPOまで来たかというところだと思います。

 

 

6.雇用形態について

最近話題になった2018年問題もあり、有期契約社員(パートや契約)の正社員化が進んでいるようです。

どちらかというと契約社員を採用する企業は、

試用期間という意味合いキャリアアップ助成金の受給が目的だったりします。

BPO関連でも今後は契約社員から正社員化というキャリアアップが出来るような時代が来るかと思います。

 

 

7.まとめ

オペレーターで働く人の動向は今後かなりシビアになってきます。

BPO関連業務の市場規模は拡大する一方ですが、その現場で働くオペレーター不足がすでに起こっており、

比較的高収益な専業代行(給与計算代行・経理代行)を除けば、

コールセンターや事務センターなどの人的BPOの運営は過渡期に入ってきています。

 

次回、RPAについて述べていきたいと思います。

  

 

 

【次回記事】

地方自治体におけるBPO【vol.5】・・・RPA

 

 

 

RPAを現場に浸透させるために~RPA運用研修編~

2018.09.11

 今回のコラムでは、RPAを導入した後、運用フェーズを迎える前にどのようなことを

現場の社員に対して教育を行えばよいか、RPA導入プロジェクトの経験から紹介したいと思います。

 

RPA運用フェーズにおける論点

RPAの運用フェーズを迎えるにあたって考慮すべき点は大きく

RPA業務全体の運用ルール」、「ヘルプデスク窓口について」、「ID・権限管理のルール

3つあります。以下、順番に説明いたします。

 

<RPA業務全体の運用ルール>

RPAを業務で使用していくにあたり、まずはRPA業務運用の全体像を知る必要があります

RPAではロボットを構築しますが、

それを「誰が」「いつ」「どこで」「どの業務を」「どうやって」行うかを決めなければなりません。

 

  • ロボ構築の申請方法

 

ロボ構築は現場社員が自身で行うこともあれば、

IT部門が主導してRPAを推進する形をとる企業では、

ロボ構築の機能はIT部門に集約したりと、企業によってやり方が分かれます。

 

また、ロボ構築を自身で行わない場合は、

申請してからいつまでにロボを使用開始できるのか

どのくらいの規模のロボットまでなら何週間以内にロボが完成するか

といったことまで決める必要があります。

 

ロボット構築を依頼する際にどう申請したらよいか。

私が参画したRPA導入プロジェクトでは、

ロボ構築の依頼を保守チームにメールで申請する体制を組みました。

 

ロボット構築を申請する際は、

業務フローやマニュアルと合わせてロボット構築のための申請書をメールに添付し、

それを見た保守チームがロボット化の可否判断を実施後、ロボ構築を開始するといった手順でした。

 

 

  • ロボットの内容変更の申請方法

 

ロボットの内容を変更する申請を出す際は、

上記のように一度新規でロボット構築の申請が出ているはずですので、

細かいロボットの内容はそちらを参照できるような仕組み

(例えば、フォルダ名や申請書ファイルのネーミングルールを工夫して以前申請したロボ内容を簡単に参照できるようにする等)

を作り、変更申請の際はロボットの管理番号と変更内容、変更理由のみを申請する運用としていました。

 

 

  • ロボ構築における制約

 

また、どんな業務でもロボ化してよいわけではなく、ロボ化についての制約も明確にしておくべきでしょう。

例えば、

承認行為をロボにさせない

費用対効果が出ない業務はロボット作成の優先度を下げる

顧客に直接影響がある業務の自動化は極力避ける

社内システムに高負荷を与えてしまう業務の自動化は避ける

等です。

 

 

  • ロボット構築ルール

 

ロボット構築ルールについても社内できちんと議論する必要があるでしょう。

例えば、

ロボットの命名規則をどうするか共通部品をどう使いまわしていくか

などがあげられます。

共通部品とは、一度作成したロボットを他のロボットにも転用できるようにすることです。

社内システムのログイン作業等、ある程度共通した作業は一度ログインロボットを作ってしまえば、

あとはそれを他のロボットでも使いまわしができるようにすることで、

ロボットの作成が効率的に進みますし、ロボットの品質も担保されます

 

 

  • 申請書フォーマット

 

ロボ構築の申請の際、申請者ごとに申請内容に違いや漏れがあると非常に手間なため、

これを防ぐためにも申請フォーマットを運用開始前の段階で整備しておくことをお勧めします。

 

申請内容は

・申請者の情報(氏名、部署)

・使用する社内システム

・月当たりの作業時間ロボット化できる業務か否かの確認

(承認行為を行わせない、等あらかじめロボ構築における制約事項や基準を設けるべきでしょう)

等があります。

フォーマットを作成することで、

申請内容の漏れが防げるだけでなく、ロボ構築における確認ポイントが明確になります。

 

 

  • ロボットが故障しても場合でも業務が回る業務設計

 

ロボットは一度構築したら終わりではなく、改作が必要なケースがあります。

 

例えば、ある外部Webサイトから単価等の情報をインプットして、それをExcelに貼り付けるロボットの場合、

インプット元の外部Webサイトのインターフェースが変更されると、

ロボットのデータ取得位置の情報も変わるため、ロボットの内容も合わせて更新しなければなりません。

このことから、ロボットが上記のような理由によって

使用できなくなることをあらかじめ想定した上で業務設計をする必要があります

要するに、ロボットに頼り切った業務運用をせずに、

ロボットが万が一故障しても、業務運用は正常に回る仕組みを検討するべきでしょう。

 

私が参画したRPA導入プロジェクトでは、ロボットが故障した場合でも業務運用が担保される仕組みとして、

手動業務用のマニュアルを作成したり、

1週間のうち1日はロボットを使用せずにあえて手運用で業務を行う

などの工夫をしていました。

  

 

<ヘルプデスク窓口について>

ヘルプデスクでは、RPAの総合受付窓口のような位置づけで、主にロボットの構築申請の受付、

ロボットの内容変更についての申請窓口、

ロボット障害時の対応やそのたRPAに関する問い合わせ管理の機能を果たします。

 

RPAツールは、プログラミングの知識が無くてもロボットが作れるとよく言われていますが、

そんなことはありません。ある程度のプログラミングの知識は必要です。

したがって、プログラミングの素養がないがロボを作成したいという場合はヘルプデスクに申請を出します。

 

上記でも述べた通り、この時に業務マニュアルや業務フローがあるとヘルプデスクで申請を受け付けた際も

ロボ構築担当者が業務のイメージをしやすく、ロボットが完成した後の認識齟齬を防ぐことができます。

最近では、社内ヘルプデスクにチャットボットを導入している事例もあるようです(下記をご覧ください)。

 

<参考Webサイト>

アイテック阪急阪神 RPAで社内ヘルプデスク業務を効率化する「チャットボット」入門セミナーを開催

https://itec.hankyu-hanshin.co.jp/event/2018/04/20180417.html

RPA Bank RPAで社内ヘルプデスク業務を効率化するチャットボット入門セミナー

https://rpa-bank.com/event/8017/

 

 

<ID・権限管理>

RPAで使用するIDPasswordは大きく分けて3つあります。

RPAツールを使用するためのID・Password」「Windowsアカウント」「社内システムID・Password」です。

 

  • RPAツールを使用するためのID・Password

 

まずRPAツールを使用するにあたってユーザ登録を行うと、

RPAツール上でIDPasswordが発行されます。

これはRPAを初めて使用する際に必要となり、主に新入社員などが申請の対象となるでしょう。

 

 

  • Windowsアカウント

 

RPAツールによっては、業務担当者のWindowsアカウントと

ロボットの実行端末の紐づけの設定を行う必要があります。

 

 

  • 社内システムID・Password

 

RPAで動かす社内システムのIDPasswordをあらかじめ記憶させることで、

ロボットの起動の都度IDPasswordを入力するのではなく、自動でIDPasswordを呼び出し、

処理を行うことが可能です。

 

ここで注意しなければいけないのは、

ある社員が他人の社内ID・Passwordを使ってロボットを起動し、機密情報を得る

等のセキュリティの観点からこのID・権限管理方法について検討する必要があることです。

このあたりの詳しい情報は下記をご参照ください。

 

<参考Webサイト>

KPMG RPA導入に伴う内部統制の整備ポイント~想定されるリスクにどう対応するか?~

https://home.kpmg.com/jp/ja/home/insights/2018/04/rpa-internal-controls.html

Accenture RPARPAガバナンス~本格導入に向けてのガバナンス整備の必要性

https://www.accenture.com/jp-ja/_acnmedia/Accenture/jp-ja/Documents/DotCom/FS-Architect/45/Accenture-Finance-FSArchitect-vol.45-1.pdf

株式会社イーセクター RPA の盲点 IT ガバナンスの重要性

https://www.esector.co.jp/special/rpa/rpa6.html

 

 

まとめ

いかがでしたでしょうか。

今回はRPAの運用フェーズを迎えるにあたって考慮すべき点といたしまして、

RPA業務全体の運用ルール」、「ヘルプデスク窓口について」、「ID・権限管理のルール

3つを紹介いたしました。

 

企業の規模や思想等によって運用フェーズで実施する内容は異なりますが、

大きい部分はそれほど変わらないと考えています。

既にRPAを導入し、これから運用を開始される場合はこちらの記事がお役に立てれば幸いです。

 

 

 

地方自治体におけるBPO【vol.3】・・・委託側

2018.09.10

【前回記事】

地方自治体におけるBPO【vol.2】・・・受託側

 

 

全国に地方自治体はいくらあるかご存知ですか?

 

総務省の最新データによると合計で1718(市790745183)存在します。

地方自治体の分類で、人口50万人以上の政令指定都市、人口20万人以上の中核市、

人口20万人以上いるが中核市に移行しなかった特例市の3つがあり、

政令指定都市20市、中核市54市、特例市31市、

以上の合計105市が全国的に知名度の高い自治体になっています。

 

都道府県と市町村の公務員は270万人(都道府県約135万人、市町村135万人)ほどいます。

地方公務員の中には警察や消防を除き、

市役所などに勤務する一般行政に関わる勝因は70万人弱と言われています。

 

 

今回のコラムで中心に記述するのは地方自治体に勤務する一般行政職の職員の方です。

発注側でもある地方自治体側では実際どのような問題点があるのかを記述したいと思います。

 

 

 

人事制度

地方自治体が民間委託をする際に発生する問題の多くは、

短期ジョブローテーションという人事制度が原因だと考えられます。

 

地方自治体の多くの職員、行政事務という観点では民間人が及びもしない見識がありますが、

 

人事や広報など特定業務の知識においては民間レベルからすると不足している

 

と言わざるを得ない職員が多くいます。

 

それは職員の能力不足が起因しているわけではなく、

地方自治体の人事制度上、必ず発生する問題です。

むしろその短期間で良くそのレベルに達したと驚くこともあります。

 

地方自治体職員のジョブローテーションは3年ないし5年で異動となります。

私の知る限り、5年よりも3年で異動するケースが多いようです。

 

3年で異動するジョブローテーションは地方自治体職員が行政事務全般を覚えるためには必要な制度です。

 

経験を積んだ職員が別の部署に異動し、

その代わりに未経験の職員が新たに入ってくまた一から業務を覚えるということを繰り返す

 

という制度になっており、入庁し、10年もいれば様々部署を経験することができます。

 

自治体によって差はありますが、下記の行政組織が人口20万人の中核都市の一般的なモデルとなります。

この行政組織内全てが職員の異動先の対象となります。

 

議会事務局」、「総務局」、「企画財政局」、「観光文化スポーツ局」、「市民生活局」、

福祉保健局」、「こども未来局」、「観光局」、「商業振興局」、「建設局」、「都市整備局」、

水道局」、「教育委員会」、「選挙管理委員会」、「選挙管理委員会」、「農業委員会

 

更にこの局の中でも広報課人事課などに分かれており、多種多様な部署があります。

 

例えば、

農業委員会で農地等の政策に関わっていた職員が翌年には秘書課で市長のスケジュール管理をし、

更に4年後には、選挙管理委員会で資料作成をする。

 

そのようなジョブローテーションが実際に行われています。

 

そのようなジョブローテーションを行うことで行政事務全般が分かる職員が育成されます。

最近はそのようなゼネラリストではなく、スペシャリスト育成のため、

人事制度を設けている自治体も増えています。

ただし、制度としては機能していないとは聞いていますが。

 

 

そのようなジョブローテーションの目的は、

 

癒着防止」・「適性の見極め」・「人材育成

 

おおよそこの3つの目的に集約されていると言われています。

 

 

癒着防止については、

東京医科大学の贈賄罪事件でも報道されていたため、ご存知の方もいるかと思いますが、

昔と比べて公務員の収賄起訴件数は減っており、問題ないという風潮になっています。

コンプライアンスなどの整理がなされ、職員も火ないところに煙は立たない、

という風にかなり気を付けているようで、民間の人と飲みに行くのも大変だと言う職員もいます。

 

民間と比べて、コンプライアンス研修など徹底しているようですが、

公権力をバックに業務を行う地方自治体職員は何かと言動に気を付けなければなりません

 

 

適性の見極めについては、複数の業務を経験させ、

その中で適性を見極めることは確かに必要ですが、30代以上の職員には異動の必要ないという意見もあります。

 

地方自治体と同規模の民間企業の場合、総合職で入社し、

入社時に配属された部署を中心に異動となるケースが多く、

どちらが良いのかはその職場の風土によっても変わるかと思います。

 

3年で異動するジョブローテーションだと上司も異動となりますので、

嫌な上司でも最長3年我慢すれば別になるので、民間と違い、離職率が低めである要因かと考えられます。

 

 

人材育成については、公文書の作成など様々な業務を経験する必要があると言われてはいます。

公文書の作成などはある程度ノウハウ化出来ており、

ジョブローテーションで習得する必要はないかと考えられます。

 

ちなみに国の省庁は、地方自治体の局、例えば、「企画財政局」が、国では「財務省」になり、

深度が増しており、専門性が深くなるので、中央と地方で公務員は大きく変わるという意見もあります。

 

このような目的で短期ジョブローテーションが行われ、

民間委託する際にはマイナスとして作用することが多くなっています。

 

 

1.BPO業者の管理


特に問題となるのは、BPO業者の管理面です。

先ほど、記載した通り、職員は知識不足です。またBPO業者のことも詳しくありません。

そのため、BPO業者の管理が不十分な状態に陥ってしまいます

 

地方自治体が民間委託をする際、最初に仕様書を作成します。

その仕様書が悪いため、運営管理能力が低いBPO業者でも業務を実施し、

 

更にBPO業者のやりたい放題にしてしまう結果になることが多々あります。

 

委託する業務によっても変わりますが、

1人でできる事を4人でやるなど非生産的でも地方自治体側は発注元として、

発注先に何も言わないことがあります

 

NHKの集金をやっているBPO業者に聞いたところ、

NHKだと1日60件回るけど、地方自治体で訪問業務をやった場合、115件程度で十分だと聞いたこともあります。

 

特にアウトバウンド系業務の委託でBPO業者は手を抜きます

そもそもBPOの管理能力が弱い社員が管理して更に手を抜くのでとんでもないことになります。

 

私自身もそのような現場に入らされることが何度かあり、業務改善で生産性を上げても、

手を抜く体質は変わらないので、人の配置から変える必要があり、業務改革に入るケースが多くなります。

 

BPO業務では採用も大切な業務であり、問題のある職場は、採用フローにも問題があるため、

業務改革(BPR)は業務全体の見直しが一般的な定義ですが、

BPO業務では採用も大切な業務なので、業務改革の対象となり、見直しを実施します。

 

もしこのコラムをお読みの地方自治体の委託担当職員の方がいれば、

機会があれば是非どのような面接が行われたかを聞いてみてください。

面接の内容である程度BPO業者のレベルが測ることができます。

BPO業者の面接官によって変わりますが、衝撃的な内容に驚くことになる可能性が高いです。

 

 

2.職員側の引継ぎ


地方自治体職員から今まで委託業者が何をやっているのか分からないので

委託業務の「見える化」をして欲しいと要望を受けたことがあります。

 

なぜこのようなことが生じるかというと委託開始時の担当職員が異動でいなくなり、

引き継ぎがなされていないケースが多いからです。

 

地方自治体の委託担当職員がそもそもいない場合や

管理職が1名でBPO業者対応をしているところも多くあります

 

地方自治体BPOでよく行われる月例報告会に参加する職員が少なければ少ないほど、

BPO業者を野放しにすることになります。

 

更に毎年異動の時期になると委託担当職員が変更になり、前任者から引継ぎがなされていないことが多く、

どちらかというと地方自治体BPOで手を抜きたいBPO業者にとっては歓迎する状況になります。  

 

基本的に委託担当職員は2名で、異動時期が被らないよう1年目と2年目の職員を組み合わせるなどの工夫が必要です。

地方自治体職員は3年でベテランとなり、4年目にはその部署にはいない。

そしてBPO業者の受託期間は長くなると5年などになり、もはや何を委託しているのかも分からない状態になり、

どちらが発注しているのか分からない状態になるそうです。

 

 

 

まとめ

今回は発注側である地方自治体について記載しましたが、書けないことも多いのですが、

もう少し発注側が委託のための体制を構築すれば、より良い効果が出ると思います。

 

前回でお伝えした通り、民間のノウハウでと言って丸投げして、

公にはうまくいっているように謳っていても、実は失敗事例ばかりです。

 

もし、地方自治体の委託担当者になった場合、

委託検討段階で他の地方自治体への視察を何度もして自分なりの委託モデルを作り、

その上でBPO業者の選定に入るようにするなどした方が良いかと思います。

 

【次回記事】

地方自治体におけるBPO【vol.4】・・・オペレーター側

 

 

労働市場の人手不足が与える影響

2018.09.07

2018年上半期の企業倒産の傾向

 

2018年上半期(1月~6月)の全国の企業倒産は、件数が4,148件、負債総額が7,466300万円でした。

倒産件数は前年同期比2.7%減(119件減)で、上半期としては9年連続で前年同期を下回り、

1990年(2,948件)以来の低水準に留まりました。

 

都道府県別では前年同期を上回ったのが22府県、減少が18都道府県になり、

地区別では全国9地区のうち、5地区(東北、中部、近畿、四国、九州)で前年同期を上回りました。

 

また、産業別では10産業のうち、7産業で前年同期を下回りましたが、

サービス業他(前年同期比0.1%増)が3年連続の増加、

小売業(同0.5%増)が上半期としては2007年以来11年ぶりに増加に転じるなど、

個人消費関連業種を中心に今後の推移が注目されます。

 

上半期倒産企業の特徴は次のとおりです。

  • 従業員数別:従業員5人未満の構成比が74.49%、上半期では過去20年間で最高
  • 負債額別:負債10億円以上の大型倒産が90件、上半期としては28年ぶりの100件割れ
  • 資本金別:資本金1億円以上が31件、上半期では過去20年間で最少
  • 従業員被害状況:上半期としては28年ぶりの2万人割れ
  • 「人手不足」関連倒産が184件(前年同期164件)、このうち「求人難」型が19

 

従業員5人未満の構成比が74.49%で上半期では過去20年間で最高の水準となっている一方で、

負債10億円以上の大型倒産が28年ぶりの100件割れ、資本金1億円以上の倒産が過去20年間で最少となるなど、

企業規模によって倒産の傾向が異なっています

 

 

2018年上半期人手不足関連倒産の傾向

 

東京商工リサーチによる2018年上半期の「人手不足」関連倒産のコメントは以下のとおりです。

 

“ 2018年上半期(1-6月)の「人手不足」関連倒産は184件

(前年同期比12.1%増、前年同期164件)で、前年同期を上回って推移している。

 

 内訳をみると、「後継者難」型が145件(前年同期比11.5%増、前年同期130件)、

「求人難」型が19件(同18.7%増、同16件)、「従業員退職」型が10件(同25.0%増、同8件)、

「人件費高騰」型が前年同期同数の10件になり、「後継者難」型が約8割(構成比78.8%)を占めた。

 

 2018年上半期(1-6月)の産業別では、最多がサービス業他の50件(前年同期比25.0%増、前年同期40件)。

次に、卸売業35件(同75.0%増、同20件)、建設業32件、製造業31件、小売業14件の順。

 

 2018年上半期の地区別では、全国9地区のうち関東(71→81件)、中部(17→23件)、

東北(8→15件)、四国(4→8件)、北陸(1→2件)の5地区で前年同期を上回った。

一方、減少は近畿(23→17件)、中国(10→9件)、北海道(12→11件)の3地区。

九州は前年同期同数の18件。“

 

2015年の年間の人手不足倒産件数の内、

「後継者難」型の割合は87.7%2016年は88.8%2017年は78.7%2018年上半期は78.8%となっています。

後継者不足による、「後継者難」型の割合は低下している一方で、

「求人難」型・「従業員退職」型の割合が増加しています。

 

人手不足が叫ばれる中、人手不足による影響が具体的な数字となって表れてきています

 

人手不足倒産の類型

 

1.「後継者難」型

代表者、役員の死亡・引退などに際し、事業承継者(後継者)がいないことによる廃業・倒産

 

2.「求人難」型

人手確保が困難で事業継続に支障が生じ、廃業・倒産

 

3.「従業員退職」型

中核社員の独立、転職などの退職から事業継続に支障が生じ、廃業・倒産

 

4.「人件費高騰」型

賃金等の人件費のコスト増から収益が悪化し廃業・倒産

 

代表者等の高齢化に伴う「後継者難」型の廃業・倒産は引き続き高い水準で推移すると思われますが、

今後は「求人難」型・「従業員退職」型・「人件費高騰」型の廃業・倒産割合が増加していくことでしょう

 

人手不足の主な原因

1. 生産年齢人口の減少

国立社会保障・人口問題研究所の発表によると、日本の総人口は201510月時点で約127095000人。

そのうち、15歳~64歳までの生産年齢人口は約77282000人となっています。

しかし、少子高齢社会の影響により、この数字は今後急激に減少すると予測されており、

2040年における生産年齢人口は約59777000人、

2100年には約30737000人にまで減ってしまうと考えられています。

 

2.  求人倍率の上昇と失業率の低下

2018年6月の有効求人倍率は1.62倍と高い水準となっています。

また完全失業率は2.4%となっています。

求職者の選択の余地が増えることで労働環境やイメージが悪い業界はより人手が不足する状況になります

 

3. 賃金の向上が期待できない

厚生労働省は710日、今年の中小企業の賃金上昇率が1.4%だったと発表しました。

今年度の最低賃金の引き上げ幅の目安を決めるうえで重要な参考データとされるもので、

人手不足を背景に前年を0.1ポイント上回りました。

ただし、政府が目指す最低賃金の引き上げ幅の年率3%程度と比べると、伸びは小幅なものとなりました。

 

大企業に比べ財務基盤が弱い中小企業が人件費に投下できる資金は限られているため、

賃金向上に期待が持てなくなった社員が退職したり、

採用の優位性を保つことができず人材の確保で難しい状況になり、人手不足の状況となります。

 

 

業務効率化による人手不足対応

 

今のままで仕事は回っているのに、なぜ業務効率化が必要なのでしょうか。

業務効率化は企業活動において必要事項で、これを怠ると徐々に会社の業績が悪化してしまいます。

 

社会や経済は日々動いており、顧客のニーズも速いスピードで変化します。

その変化に対応できる企業が生き残っていき、成長もしていきます。

このような環境下で利益を積み重ねていくためには、現状維持では企業価値が低下していきます。

業務効率化を図ることで、業務効率を最適化し、利益を最大値まで引き上げることができます

最大化された利益を元に資金調達を行い、そのキャッシュを次の投資に回し、

投資回収することで魅力ある企業となり、採用優位性を高めたり、

人材の流出防止につながることが期待できます。

業務効率化に着手する際に効果的なシステムとして「SaaS」や「RPA」などがあります。

 

SaaSは、各業務の作業をシステム化し、人がそのシステムをクラウド上で利用します。

業務領域は業務特化されており、人がシステムに合わせるといった特徴があります。

メンテナンス等は全てSaaS提供会社によるものであるため、

自社でその必要はなく、常に最新の機能を搭載した状態で利用可能です。

 

RPAは、人がマウスやキーボードを使用した作業をRPAに覚えさせて対応させます。

基本的にすべてのオペレーションを自動化できるため、どの業務領域にも適応でき、SaaSに比べ柔軟性は高いです。

大量に同じことを繰り返すPCオペレーション作業についてはコストメリットを享受できます。

ただし、Web上のボタン位置が変更になるなど、

動作ルールが変更になった場合には適宜メンテナンスを行う必要があります

 

中小企業では手作業で行われているアナログ作業もまだまだたくさんあるのが現状です。

SaaSやRPAの特徴を踏まえ自社に最適な業務効率化システムを導入することで、

人材不足への対応を図ることができます。

 

SaaSやRPAなどのITツールの導入に際しては、

経済産業省で行っている「IT補助金」を活用することで、最大50万円が国から補助されます。

IT補助金で、SaaSRPA導入の心理的・資金的ハードルは下がると思いますので活用をおすすめします。

 

人手不足倒産の「求人難」型、「従業員退職」型、「人件費高騰」型は、今後増加していく見込みです。

人手不足によって、徐々に自社の財務内容が棄損し倒産に近づく前に、

RPA等を導入した業務効率化に取り組むことを考えてみてはいかがでしょうか。

 

 

 

 

医療業界におけるBPR機会とRPA活用(製薬業界)<2>

2018.09.06

今回のコラムは、前回の内容を受け、主に製薬業界についてのBPR施策の方向性を事例と一緒に挙げていこうと思います。前回コラムについては下記のリンクをご参照ください。

 

医療業界におけるBPR機会とRPA活用(製薬業界)<1>

 

まず概略から入りますが、業務改善、つまりBPRの施策というものは方向性として以下4つのカテゴリーに集約されます。近年話題になっているRPAは、この中の「自動化」の一施策という位置づけになります。本コラムではこの4つのうち最初の2つについて、具体的な取り組みを順次述べていこうと思います。

BPR(業務改善)の方向性

 

Consolidation(集約化)
前回のコラムでも述べた通り、製薬業界は各事業部の独立性が尊重されやすい傾向にあります。従って、事業部ごとに事務作業をするスタッフを雇用しており、それぞれ独自の業務手順・ルールを敷いているケースが散見されます。そこで、ヘルスケアの業界でBPRをする場合、まず効果的な施策として出て来るのが社内シェアードサービス部門の立ち上げになります。シェアードサービスの概念は古くからあるものですが、要約すると、「各事業部の類似の定型業務を引き剥がし、物理的に一か所に集まっている部門に集約させる」ことにあります。このシェアードサービスの仕方として、事業部側との連携の必要性から、シェアードサービス要員を個々バラバラに事業部フロアに張り付かせるケースもありますが、それはあまりお勧めしません。効率化をまず突き詰めたいのであれば、半ば強制的にシェアードサービス部門を別フロアの一か所に集めるべきです。これにより、今まで馴れ合いで個人間の関係値で行っていた仕事に標準化のメスが入り、かつシェアードサービス要員内でのベストプラクティスの共有(例えばエクセルのマクロによる自動化など)が行われやすくなります。おそらく、それでもどうしても事業部側の近くですべき業務というのが残るかもしれません。そうであれば、一旦集約した後に振り返りを行い、事業部側に業務を戻すか、例外的にシェアードサービス要員を派遣する手立てを講じます。繰り返しになりますが、まず大事なのは、業務整理を行った後、半ば強制的に物理的に一か所にシェアードサービス要員を集めてしまうことです。効果を狙うのであれば、これに尽きます。
それでは、具体的にどのような業務が製薬業界においてシェアードサービス化の対象となるでしょうか。まず一つ挙げられるのは諸々のドキュメンテーション業務です。社内システムの情報から行政への提出資料のフォーマットに合わせて加工する作業であったり、あるシステムから別システムへのデータ加工も入ります。また、グローバル展開している製薬会社の場合、翻訳のドラフト作成業務も入ってくるかもしれません。このような定型業務の多くが実は、各事業部のコア人材の方々、つまり単価の高い方々が行っていたりしています。最終チェックは事業部側に残る可能性はありますが、比較的ノンコアな定型のドキュメンテーション業務は正にシェアードサービス化するのに打ってつけであると言えます。
次にシェアードサービス化の候補としてあるのは、主要取引先との窓口業務です。SMOやCRO、そして各種ベンダーについては既に窓口が集約されている所が多いと思いますが、特に対医療機関についてはまだ事業部側が主導しているケースが多いかと思います。確かに、事業部ごとに対象疾病が異なるため、同じ医療機関であっても診療科や医師は異なり、おいそれと集約化できる領域では無いと思われるかもしれません。しかし、肝となるコミュニケーションが終わった後の、事務的な契約書手続き等は、集約化できると思われます。このような医療機関との窓口業務については、事業部ごとにバラバラにコミュニケーションをとるのではなく、重要アカウントとなる病院ごとに担当者を明確にすべきです。そのように医療機関ごとに担当を集約させてしまったほうが、手続き漏れや記入漏れ、そして個別医療機関ごとの特殊性も配慮も徹底できる等、医療機関側からの信用も増すことも期待できるのです。

集約化の観点で次に挙げられるのは、サプライヤー管理の領域です。製薬会社では、SMOやCROだけでなく様々な協力会社を必要とします。梱包、在庫保管や割付、そして配送等のロジ回りもあり、また投薬に使う機器、什器等多岐に渡ります。それらのサプライヤーが事業部個々の論理により決められているとしたら、其処に潜んでいる効率化機会は非常に大きいと言えます。具体的な取り組みとしては優先サプライヤーリストをコーポレート側で策定し、基本的に各事業部にはその中でサプライヤーを選ばせるようにするか、もしくは購買部側に決定権限を委譲する等考えられます。
このサプライヤーの集約化は、「業務の効率化」以上の効果を期待できます。つまり、それは「コストの低減」に直結するということです。サプライヤーを集約することで、交渉力が増し、ボリュームディスカウントを狙えますし、全社の過去の購買量履歴を抑えることで、単発の発注でなく、年間契約等のより長期的で製薬会社側に有利な条件の締結が望めます。このようなサプライヤーの集約化は非常に経営インパクトの大きい施策ですので、M&Aの後にまだ本格的に取り組めていない企業は優先して検討することをお勧めします。

 

Simplification (簡素化)
このSimplification(簡素化)とは、不必要に複雑であったり、無駄に人的リソースを消費する業務を省力化することを狙った施策になります。この一大分野として、チェック/承認フローの簡素化が挙げられます。製薬業界ではGCP等の規定や、過去のM&A前の個別会社の慣習、そしてグローバルとローカルのフローの混在からか、「よくよく考えるとこんなにチェックを行う必要があるかしら」というケースが散見されます。治験で求められるプロトコル作成等は、確かに何度も修正が発生しがちな業務ではありますが、今一度不必要な確認作業がないか、検討は必要です。また単純な記入チェック等についてはエクセルのマクロやRPA等で自動化してしまうことも考えられます。
実際に、筆者の経験では、製薬開発の承認フローにおいて、治験薬概要書(IB)やプロトコル、同意説明書(ICF)、治験計画といったドキュメントそれぞれにおいて膨大な社内ステークホルダーに対して承認プロセスが発生していました。それらの承認プロセスおよび対象者を一つ一つ紐解いて、必要承認者を厳密に規定することで、不要な承認業務の削減に繋がった例もあります。
次に、この簡素化の施策に入るのが、会議体参加メンバーの限定です。先述の承認フローにも関わりますが、仮に何かの承認のための会議体があったとして、果たして、この場にいる全員が必要なのか、最後の会議体に参加するだけで良い人もいるのではないか、といった視点は重要です。また逆に参加必須のステークホルダーの参加がバラバラで、2回会議体を持たないといけないケースもできれば避けたいところです。出張中が多いのであれば遠隔会議システムを使う等して、会議体の回数低減に努めるべきです

今回のコラムでは、製薬業界におけるBPR主要4方針のうちConsolidation(集約化)とSimplification(簡素化)の2つを取り上げました。次コラムでは、ベストプラクティス分析も含めたStandardization(標準化)と、まさにRPAの対象となるAutomation(自動化)の領域に焦点を当てて、詳述していきたいと思います。乞うご期待ください。

 

医療業界におけるBPR機会とRPA活用(製薬業界)<3>

 

 

 

【RPAは強い味方】士業こそRPAを活用しよう!

2018.09.06

AIにより10年後になくなる職業ランキングなるものが繰り返し報道、SNSシェアされています。

 

しかし、日本のほとんどを占める中小零細企業の社長さんが、

そもそもITリテラシーが低く、いまだにガラケーで電話のコミュニケーションしか取らないと言っている中、

そんな社長さんを相手にする士業がAIにリプレイスメントされるとは、私は思いません

(社長もどんどん若返っているという意見もあると思いますが、

私の周りの40代社長の多くはいまだにオールドファッション側にいます。

と、いうことは20年後くらいまで中小零細企業の社長はITオンチだと思います。)

 

AIを云々言うのは時期尚早かもしれませんが、RPAとなると話は別です。

私は、RPAこそ士業にマッチするテクノロジーだと考えています。

 

税理士の仕事を例に少しシミュレーションしてみましょう。

業界の方からすると「そんなことは分かっている」と言われそうですが、

あえて他の業界の方にも分かるよう、少し初歩的なことから。

 

税理士の仕事において、最もミニマムなのは顧問として、決算申告書を作成し税務署に申告を行うことです。

顧問料として、23万円毎月、決算時期には会社の規模にもよるでしょうが、

30万円程の作業料を取るというのが一社当たりの売上です。

まあ最近はWEB使ったお客さんの獲得なども盛んな為、

顧問料はどんどん安くなっていっている傾向があるようですね。

 

そこに記帳代行や給与計算、振込入力などの毎月のルーチン業務のアウトソーシングが加わり

プラス5万、10万と月々の一社当たりの売上が増えていく構造です。

 

ただ、このアウトソーシング業務は、税理士事務所によって捉え方が違うようで、

大きく3つに分かれるようなイメージです。

 

 

まず一つ目、出来るだけ顧問料だけでやっていきたい税理士事務所。

 

古くからある所長が高齢化している事務所はこのタイプが多いですね。面倒はしたくない。

街に必ず存在する管理物件の管理費だけで存続できるから

無駄なことをしたくない超ヒマそうな不動産屋さんと同じ原理ですね。

わざわざバイト雇ってアウトソーシングするにも、その管理も大変だし。

税理士法人化してない個人事務所の場合がほとんどですね。

まあ彼らは、そもそも成長しようという意欲がないので、あまり新技術の導入にもピンとこないでしょう。

 

残りの二つは、どちらもこれから成長しようという意欲的な税理士さん。

まずはコンサル志向。出来るだけ付加価値の高いサービスを提供したいという税理士法人。

 

コンサルティングとは、月次決算からの、それをベースにした資金繰り、

また事業成長の為の投資余力や、CF経営の意識づけなど、

クラアント企業がそこそこ大きくなってきて、社長が本気で経営したいという意識が芽生えてきてからのお手伝いです。

 

彼らにとっての一番の悩みはアウトソーシングの処理。

まずこれから成長しようという税理士は独立したばかりの方が多く、

クライアント企業も新規創業をとっていかざるを得ません。

そうすると、クライアント側に経理などいるはずもなく、勢い全て税理士事務所へ丸投げという状態になります

 

社長が何も考えずに使った訳のからない領収書、くしゃくしゃの請求書などが渾然一体と封筒に入れられ送られてく。

それを一つずつ社長に確認するが、適当に処理しておいてよという返事。

理想としていたコンサルティング業務からは程遠い作業に追われ、貴重な時間の90%は消えて行く。

コンサルティングやその為の自分の勉強に割ける時間はほとんど無いのが実情です。

 

 

最後が、この面倒なアウトソーシングを全て取っていこうという意欲的な税理士法人。

 

多くは顧問をメインとする税理士法人に加え、記帳代行や振込入力のBPOを別法人として独立させていたりします。

記帳代行、給与計算、振込入力、請求書発行、たくさんある経理業務も、その全ては恐ろしいほどの単純作業です。

 

必然的に規模の経済がものをいう世界。どんどんお客さんを獲得し、

どんどん仕事まわしていこうと考えるも、そこで壁にあたってしまうのが、「人不足」。

 

営業力はまだまだあるのに、人手不足で新規の仕事を全て断っている

という話を何人かのBPOに意欲的な税理士法人から聞きましたが、

 

まさにここが本記事におけるメインターゲット

RPAにより大きく飛躍できる士業だと思います。

 

そもそも士業の先生は、ITリテラシーがそれほど高くない。

これは、致し方ないことであって、

文系の最高分野である士(サムライ)業にとって、自身の分野の知識はまさに剣

昔のサムライが商いを忌避したように、分野以外の知識がなくともこれまで成り立ってきたのだと思います。

 

そんな先生たちにAIというと、自分の仕事を奪うかもしれない不穏な奴と思われるかもしれません。

ですが、RPAは違うんです。

 

RPAこそ、先生たちの強い味方。

 

AIと違って何にも考えないですが、真面目に単純作業を淡々とこなしてくれる可愛い奴なんです。

 

 

じゃあ、RPAで何ができるのか?

当社で開発した「クラウドRPA鉄腕経理」の紹介を兼ねて、お教えしましょう。

 

クラウドRPA鉄腕経理」は、記帳代行と振込入力の二つを行います。

(現在、給与計算や請求書発行など他のサービスも開発検討中ですが、

まずはメジャーなこの二つからローンチしました。)

 

記帳代行機能は、RPAが銀行のシステムから通帳データを自動で取得し会計システムへ入力していきます。

また領収書はデータ化(例えばエクセル)された状態から自動でデータを取得し、自動で会計システムへ入力していきます。

 

他、クレジットカードならば信販会社のシステムへ自動で入りデータを抽出し会計ソフトへ入力するなど、

パソコン内で完結する作業はブラウザでもメーラーでもオフィスでも各種システムでも

横断的にロボットが自由自在にデータを入手、入力できるのです。

 

そして、振込入力機能は、この会計システムに入ったデータを

自動的に銀行システムへ振込入力していき、承認の手前まで終えて承認確認をするという機能

 

これらの機能でどれだけ業務削減できるのか?

企業によって入力の量なども変わりますし一概には言えません。

 

ただ、当社の方で税理士法人の中心的なクライアントである13億円程度の中小企業をベースに試算したところ、

だいたい記帳代行が1日程度、振込入力が2日程度の作業量削減となりました。

経理担当者が3日程度楽になる試算ですね。

 

これが多いか少ないか、一企業にとってはたったの3日?となるかもしれません。

しかし、BPO100とか300社とかやっている会計法人にとっては、100社×3人日、

300社×3人日です。その業務削減効果は小さくはありません

 

またコスト削減効果以上に、このタイミングで業務を標準化し、

RPAによって自動化することの将来的な意味は計り知れません。

新規の業務を何の憂いもなく営業できるトップの安心は、

成長を目指す意欲的な税理士さんにとって最も大切なことでしょう。

 

当社では、この「クラウドRPA鉄腕経理導入費無料で税理士法人へ導入してもらっています。

実は、このRPA、導入が一番大変なんです。

導入の際の各種データの標準化、各社ごとの設定が一番の手間となり、

導入するのに数百万円の投資が必要という事も多くあります。何事も良い事ばかりではないですね。

 

しかし、当社では月々の一社当たりの御社アウトソーシング料の中から、

いくばくかを毎月の払っていただくだけで、初期投資ゼロ円のRPA導入を実現しました。

 

 

 

これからのテクノロジー社会、士業にとっての良質なテクノロジーパートナーでありたいと願って。

 

 

 

医療業界におけるBPR機会とRPA活用(製薬業界)<1>

2018.09.05

今回のコラムでは、医療業界の中でも特に製薬会社における業務改善(BPR)およびそこから浮かび上がってくるRPAの活用機会について述べたいと思います。もともと、製薬業界は外部コンサルタントからすると、BPRの潜在機会が比較的大きいと見なされている業界です。これは、この業界が特に日本において以下の特徴を持っていることがその一因ではないかと考えられます。

 

  • 複数の独立性の高い事業部(対象疾病)で成り立っている
  • 社内に複数のバラバラな独自システムが存在
  • 取引先となる病院がロングテールで独自の業務フローを保持、かつ相対的に病院の力が強い
  • 各種の法規制が厳しくグローバル企業であってもローカライズされた業務が必須
  • 生産性/効率性以外の論理が入りやすい

 

複数の独立性の高い事業部(対象疾病)で成り立っている

製薬会社ごとに得意となる領域は異なりますが、マーケットの規模が患者数に依存する業界のため、畢竟、1つの製剤でリーチできる売上の限界は早期に見通しが立ちます。がん・心疾患・脳卒中といった三大疾病の領域においても競争環境が激しく、価格も固定ですので、自社の技術評価を冷徹に行えば期待できるシェアから売上の上限は自然と決まります。また研究開発するにしても治験計画を綿密に立てねばならず、ジェネリックをするにしても特許切れの45年前から準備を開始していないと間に合いません。つまり、製剤業界というものは「計画が命」の業界であり、天変地異や予測不可能な市況の変動による影響に翻弄されることが比較的少ない業界と言えます。

そのような業界の場合、売上を伸ばしていくためにはどのような思考を持つでしょうか。もちろん1つの疾病領域内でシェアを伸ばしていく考えもあります。例えば糖尿病の治療には注射と経口(タブレット)があります。注射剤においても内訳で見ると今まで主流だったインシュリンもありますし、近年伸びているGLP-1受動体作動薬という分野もあります。研究開発に膨大な金額と時間をかける製薬業界にとっては、同じ糖尿病の治療においてであっても製剤の種類を変えることでシェアアップを狙うことは確かに一番費用対効果の高い戦略です。しかし、1つの対象疾病に会社の運命を託すのは、この業界が各種規制の影響を受けやすいことから、非常にリスクがあることです。ケースは少ないですが仮に何かの疾病の治療薬で上市後に問題が見つかった場合、その疾病領域での製剤の取り扱いは全面的に見直しとなります。そのようなリスクケースを想像すると、必然、製薬会社は一つの籠に卵を盛るような真似はせずに、リスク分散をできればしたいといいうのが心情です。つまり、売り上げを伸ばすために、対象疾病の領域を増やし製剤ラインナップ拡大を目指す。ただし、製薬業界は1製剤の研究開発に多大な投資と時間が必要な業界であり、それが対象疾病の領域を横に拡大する上でのネックともなっています。この二律背反性がこの業界の特徴とも言えます。対象疾病のラインナップ拡大については、自社努力で図るケースもありますが、M&Aを通じて広げていくケースが多いのもこの業界の特徴です。

対象となる疾病が異なれば、同じ病院内であっても担当医師が変わりますし、KOLKey Opinion Leader)ももちろん変わります。取引先となる病院側が変わるだけでなく、製薬会社内のR&D人材も変わり、製剤の種類によってロジ回りの協業相手も変わるケースが出てきます。つまり、製剤ごとの専門性が高すぎるがゆえに、事業部間のシナジー、標準化機会が簡単には生まれず、放っておくと、各事業部が各々の論理に従った業務設計をしてしまいがちになる傾向があります。ベンダー/サプライヤーの選定も事業部独自に行っており、コーポ―レートの視点で集約化することに対して神聖不可侵とされがちです。経営層からしても、各事業部の専門性の壁を越えて効率化を推し進めるのは他の業界に比べて難易度の高い取り組みとなります。これは外部コンサルタントからすると、翻って、潜在的なBPRの機会は大きいと言えます。もちろん事業部間の専門性は十分に配慮しなければいけませんが、過去のプロジェクトの経験からすると、ドキュメンテーションの作業や、社内システム上での作業、そしてサプライヤー管理業務については標準化/効率化の余地が残されているまま放置されていることが多い印象です

 

社内に複数のバラバラな独自システムが存在

この社内システムが乱雑でかつシステム間の連携があまり取られていない傾向については、原因として先述した事業部ごとの独立性が高いことと、あとはM&Aが比較的多い業界であることが挙げられます。これは今までの多くの製薬業界のクライアントを相手にした経験からですが、製薬業界にもSAPを始め業界標準化されたシステムは存在しますが、それとは別に個社ごとに独自に開発したシステムが数多く存在する印象です。例えば、臨床試験フェーズのシステムについても、製剤開発用のシステムもあれば、医療機関側のモニタリングやサンプルデリバリーのシステム、あとはEDC(電子症例報告書)のシステムもあります。あとはCT.govのような行政機関登録用のシステムあるケースがあります。あとは各種ベンダーや協力会社のサプライヤーマネジメント用のシステムも存在します。

これらのシステムが統合されたシステム思想のもとに導入されているのであれば、システム間連携への配慮もなされていると思いますが、ここで問題になるのがM&Aです。先述したように、製剤ポートフォリオの拡大を志向するが故に製薬会社間のM&Aは積極的に行われています。必然、2社それぞれの独自システムが併存する状態となります。もちろん経営層としては最終的に1つの統合システムにまとめてしまいたいところですが、システムの統合は十全な準備が必要であり、かつ両社の事業部の専門性に配慮せねばならず、結果としてかなりの長い期間、各社の既存システムが残ることになります。また一連の業務に関係するシステムが複数存在するため、仮にシステムの統合をするにしても一気に全てを行うことはできず、一つ一つ片付けていくことが求められます。即ち、あるシステムは統合版になったが、別のシステムは過去の各社の既存システムをそのまま使用しているという状態になりがちだという事です

こうなると、そのシステム間の非連携のシワ寄せは、人間である社員の双肩にかかってくることになります。あるシステムから別のシステムにデータを連携させるために、人間側でデータフォーマットの加工・修正をしたり、一部の機能についてはシステムで対応していないので、人間が専用のエクセル管理帳票を作って対応したり、といったケースが頻発します。このあたりの「システムtoシステム」や「システムtoエクセル」と言った領域は正にRPAの得意分野となりますので、RPAロボットの導入により社員の業務負担を大幅に軽減できることが期待されます

 

 

取引先となる病院がロングテールで独自の業務フローを保持、かつ相対的に病院の力が強い

これは特に日本における医療業界についてですが、医療機関側が市場の論理と逆行してフラグメンテッドな状態で成立し、かつ製薬会社との力関係においても医療機関側のパワーが相対的に強い特徴があります。まず、中小病院がフラグメンテッドに存続している背景ですが、それは地域への医療サービスの提供という営利活動とは別の論理が強く働くことが理由です。もちろん、この高齢化社会による医療福祉コストの増大を受け、行政で診療報酬改定や地域医療構想を掲げることで、各地域の医療体制を合併・再編を促したいという意向は垣間見れます。しかし、これは一部の意欲的な地域では進んでおりますが、その進捗は地域によって未だかなり温度差がある状態です。またこの医療機関においては、大学病院の存在も欠かせません。特に地方では、このDPC病院のⅠ群に相当する大学病院が担う役割は大きく、それらの病院は、もともと地域に根差しており、独自の業務を志向、他病院との統合の可能性は限りなく低いです。その他にも地方には県や市レベルの公立病院が多く存在し、これは医療サービス提供における地域格差を是正するためには、必要不可欠であり、今後も継続することは必定です。つまり、他のB2Cの業態、例えばドラッグストアやコンビニといった効率性重視の世界と異なり、大手によりシェアの収斂、寡占化は生まれにくく、あくまで地域に根差した中小規模の病院の存続は今後も粘り強く続くと予想されます

また、製薬会社と病院側の力関係についてですが、これは医師が高度な専門職であり、製剤の採用を決める事実上の意思決定者である以上、どの国においても医師の力は強くなるものです。ただし、この医師側の力が強い傾向が特に顕著なのが日本ではないかという印象です。これは日本の医療業界における電子化の取り組みが遅れ気味になっていることとも関係しています。例えば、治験フェーズにおける製薬会社の業務の中に、CTR(治験依頼書)を治験責任医師(PI)向けに作成し、署名をもらう作業がGCPで義務付けられていますが、これら一連の作業において、製薬会社側は都度病院を訪問し、医師との面談を行っています。これらの作業は実質、書面郵送+メール/テレカンでの補足説明で済む内容なのですが、「直に訪問しないと医師に失礼」といった諸々の理由により、比較的中小の病院であっても製薬会社の社員が訪問しているのが実情ではないでしょうか。このような業界慣習が医療業界では未だ根強く、他業界では効率化の観点から当然のようにしていることも依然として躊躇してるケースがよく散見されます。また、病院からの見積書においても、製薬会社側にとっては自社フォーマットに統一して出して頂きたいところですが、力関係の弱さから病院側の個別フォーマットに従わざるを得ず、その結果、事務員による膨大な集計業務が発生しています。このあたりの事情は業界慣習上、変えることが難しいのは重々承知しておりますが、他業界では効率化されて久しい膨大なBPR機会が野放しにされているのも事実ですので、何かしらの取り組みを検討する価値はあると思います。特に、複数のフォーマットの異なる情報の集計作業は、RPAの得意分野でもあります。ただ、それも数百のフォーマットとなるとRPA開発の手間がかかり費用対効果が合わなくなる恐れがあるので、自社内部での取り組みと並行して、SMOCROといった医療機関と製薬会社の間に入っている仲介事業者に協力を仰ぎ、製薬会社側の非効率な業務を減らすといった工夫もありうるかと思います。

 

 

各種の法規制が厳しくグローバル企業であってもローカライズされた業務が必須

どの業界であっても、PESTで言うところのP(政治)の動向については注視が必要ですが、特にそのドライバーの影響が強いのが医療業界です。近年は、欧米や日本といった先進国における新薬の世界同時開発の取り組みが標準的になりつつあり、各国法規制の標準化整備の流れはあります。しかし、依然として、日本はPMDA、米国はFDAというように、国ごとの独自の規制管轄があります。それは即ち、どのようなグローバル製薬メーカーであっても、少なからずのローカル業務が必ず発生するこということです。このような場合、経理や人事労務と同様、治験や営業業務の一部を各国のアウトソーシング会社に外注することもできると思いますが、製薬会社自社内でもその各国の法規制に対応する部門を持つことは必須となります。

グローバル企業の場合、効率化の観点から、業務フローの標準化は必ず取り上げられるテーマとなりますが、その障壁となるのが、この「各国の法規制対応業務」になります。ここで難しいのは、コーポレートの標準化/効率化推進側の責任者とって、どこまでが本当に法規制上必要なのか否かが容易に判別できないケースです。現場担当者側が言う「日本では●●の工程は必須」という意見も、本当にその全てが必要なのか、それとも解釈次第では変更の余地があるのか、容易には分かりません。筆者の経験では、薬品のパッケージング(包装)や治験薬のランダマイゼーション(割付)と言った業務で、そのような慣習上の独自業務がローカルに残ったままになっていたケースがあります。つまり、もともと各国の法規制の関係上、ローカル業務が残りやすい業界であるために、実はただ単に「慣習上」残っていた独自業務も多分に潜んでいる可能性があるということです

 

 

生産性/効率性以外の論理が入りやすい

最後に、そもそもの業界の志向性です。製薬会社自体は、民間企業であるため、営利活動を目的としておりますが、取引先となる医療機関はそうではありません。社会福祉を担う重要な使命をもっており、そのことが少なからず、民間企業である製薬メーカーにも影響を及ぼします。この無意識下にあるプライド・矜持は文化風土となり、業界特有の考え方を醸成することになります。

例えば、他の業界であれば、顧客との取引規模や重要度によって露骨に対応を変えます。キーアカウントとなる重要顧客については専門チームを設け、個別カスタマイズしたフォローも行いますが、重要でない顧客群に対しては十把一絡げにして、有無を言わさない標準フローで対応します。これは生産性向上、効率化の観点から自ずと導き出される商売鉄則です。もちろん、製薬業界においても同様の考えは出てきます。ただ、他の業界と比べてそこまで露骨に冷徹に徹底しきることが果たしてできるでしょうか。極端なことを言うと、「取引を失ってまで、自社内の業務効率化を優先する」という判断をするか、ということです。これは、「取引先が医療機関のみ」という市場が狭い業界ならではとも言えますし、「そもそも地域医療サービスの一端を担うべき製薬会社がそのようなマインドでいいのか」という自省の念から発する現象とも言えます。

また医療サービス、特に製薬は人命を扱う非常に重要で注意を要する仕事です。PMDAを始めとする規制側だけでなく、マスコミも何か非倫理的な事が起これば非常に敏感に動き、世間の耳目を集めます。これは、製薬会社側の業務で言うと、開発の段階で必要以上のステークホルダーへの承認作業に昇華します。社外の関係者への説明責任は規制に定められていますし必須だと思われますが、社内においても諸々の部署の人間が開発段階から入り、巡回して承認を得ていくことになります。これは、一概に悪いとはなりませんが、この傾向が増長されると「一見、開明的で民主的な承認工程だが、実は責任を曖昧にし『お見合い』による事故を増やす」結果になりかねません。あまりにも多数の社内承認者が必要なワークフローであったり、二重・三重のチェックを要している業務については、今一度その工程が本質的に必要なのか吟味し、場合によっては承認フローの簡素化を検討することをお勧めします

 

 

以上が、医療業界、特に製薬業界においてBPRおよびRPAによる業務改善機会が比較的多く眠っていることの論考となります。次コラムでは具体的にどのようなBPR施策およびRPAのソリューションが適用できるのか、実例を踏まえて述べていきたいと思いますので乞うご期待ください。

 

 

医療業界におけるBPR機会とRPA活用(製薬業界)<2>

 

ERP×RPAで圧倒的な効率化を目指す(上)

2018.09.05

はじめに

昨今実に多くの企業で、業務効率化/スピードアップが喫緊の課題となっていることでしょう。

 

殊に中小企業においては、業務効率化に向けた施策として基幹システムの改修やワークフローの見直しを検討している企業も多いのではないでしょうか?

 

ここで早速RPAを用いたソリューションとそのインパクトをご紹介したいところですが、

今回は既存システムの改良およびIT投資の観点からアプローチしてみたいと思います。

 

 

自社の基幹システムを把握する

大なり小なりもしくは事業内容の違いはあれど、

おそらくどんな企業にもさまざまな主要業務を支える基幹システムが存在しているはずです。

 

生産管理/販売管理/受発注管理/在庫管理/財務・会計/人事・給与等、

各部門が管轄している基幹システムが存在し、それぞれ独立してシステム構築されていることも多いのではないでしょうか。

 

そのためインターフェースはもちろん、データベースや入出力の仕様が異なり、

部門間をまたいだデータのやり取りではシステム間の連携に障壁が生じることも。

 

これは業務の遅滞や部門間コミュニケーションの希薄化・不和を招くこともあるため、

好ましい状態は言えません。(ただし、各部門内でセキュアに管理すべきシステムは例外)

 

 

業務効率化を考える上で、こうした基幹システムの実態を把握する必要があります。

 

  • 自社の業務を構成する情報システムは何か
  • どの部門が管轄し、どのように活用されているか、ブラックボックス化していないか
  • 部門間でのデータのやり取りは発生しているか、障害はないか、
  • システム同士で機能の重複はないか
  • 導入したものの全く機能していないシステムは存在していないか

 

最低限上記5つの観点からシステムを評価し、それぞれ役割を明確化⇒懸案事項の洗い出しを行います。

その後具体的な改善策を検討していくことになります。

 

 

基幹システムの統合

 

 

前段で検討した結果、

各システムが独立しており経営に関する一連の状況をつかみにくい場合は基幹システムの統合を図るケースが存在します。

 

目まぐるしく変化するビジネスシーンでは、リアルタイムで情報を管理し、

必要に応じて可視化/分析することが求められます。

 

こういったニーズに対しては、売上状況や債務状況、在庫などの経営関する情報を一元化し、

全体像を可視化するシステムの導入が効果的です。

 

その際多く用いられるのは、ERPEnterprise Resources Planning)パッケージです。

 

企業経営の基礎である資源を適切に分配し有効利用する考え方を基に、

「情報の一元管理」と「業務効率化」を目指すものです。

 

 

数あるERPパッケージの中でも、とりわけ多くの企業に導入されている“SAPは圧倒的なシェアを誇り、

近年では中小企業へも導入が進んでいます。

 

 

SAPが他のERPパッケージと比べて優位性を有している点として、

 

  • 多様かつ大量のデータを汎用性の高い管理基盤で集約
  • パラメータ設定が豊富であり高い自由度を有している
  • 多言語・多通貨・多拠点での対応が可能
  • 予め効率的な業務プロセスが組み込まれている
  • 豊富な導入事例により導入・運用までのアプローチが洗練されている

 

といった面が挙げられる一方、

 

  • ライセンス料・導入費用が高額
  • 機能が豊富すぎるが故に難解

 

というデメリットも併せて吟味する必要があります。

 

とはいえ中小企業向けの比較的安価なプランも登場しており、また他のERPよりも専門エンジニアが多く、

比較的スムーズに導入できるといった面もあるので、一案として検討してみるのもいいでしょう。

 

 

ERP導入プロセス

 

 

以下に挙げられるのが一般的なERP導入までのプロセスです。

 

特段他のシステム導入時と大枠は変わりませんが、企業活動の根幹を成すシステムを作るため、

より明確にゴールを設定しかつ中長期的なビジネスプランニングの策定に役立つよう、

細部まで吟味する必要があります。

 

ここでは主要なフェーズについてその内容を提示します。

 

 

  • 企画

【導入目的と適用範囲の設定】

 

中長期計画などの経営戦略を参照し、現行システムを分析して課題を抽出することから始めます。

 

そこから導き出される目的には、「業務プロセスの全面刷新」や「内部統制の実現」等が挙げられることでしょう。

 

この目的によって、選定すべきERPパッケージや形態(オンプレミスorクラウド)が変わってきますので、

この部分はかなり時間をかけて取り組むべきフェーズです。

 

この段階で成果として達成しなければならない経営指標もある程度明らかにしておく必要があるでしょう。

 

 

【製品および委託先の選定】

目的と範囲によっては、自社で導入可能なケースもありますが、通常はベンダーを活用するケースがほとんど。

適用範囲についての業務分析がある程度済んだ段階で、ベンダーの選定に入ります。

 

 

あたり前ですが、パッケージ内容だけで判断せず幅広く提案を受け、

導入目的に沿った製品・形態を選択することが肝要です。

 

そのため提案依頼書には、このプロジェクトの目的や背景、予算、スケジュール、

現時点での業務分析結果の詳細を記述しておくことでベンダー側もこちらに寄り添いやすく、

実のある提案を受けることができます。

 

その際デモンストレーションを見せてもらうようにすれば実際のイメージも湧きやすく、判断材料の一つになり得るでしょう。

 

 

  • 要件定義

【新しい業務プロセスの策定】

 

ERP導入で実行すべき業務とERPの機能を比較して、

現行プロセスから変更を要する業務を特定します(フィット&ギャップ分析)。

 

 

変更を要する部分については「業務をシステムに合わせる」、「基本パッケージにアドオンする」、

あるいは「人力でカバーする」といった対応方法が考えられます。

 

いずれの場合においても発注側が主体的に進めることで、

細大漏らさず必要要件が実装されるようにすることが重要です。

 

 

上記を決定したのち、変更を要さなかった部分と併せて新しい業務プロセスを作成しましょう。

 

 

【運用部門への導入計画の策定】

この段階でデータ移行や受入テスト、業務切り替え、運用部門(ユーザー)の教育など、

導入計画をしっかり策定しておきます。

 

これらはデータ移行に関するコストやリードタイムを把握するために必要であり、

同時に遅滞なくリリースをするためにもこのフェーズで熟考すべきでしょう。

 

 

【モニタリング指標と目標値の設定】

ERPは、納期通りにリリースできただけでは導入を成功したとは言えません。

あらかじめ設定した経営指標が目標値を達成して初めて成功したといえるのです。

そのためこの時点で導入後にモニタリングする経営指標と、目標値を設定しておくのが良いでしょう。

 

 

  • 実装

【新しい業務プロセスの実装】

 

前段で検討した新しい業務プロセスに基づいてERPに必要なパラメータを設定します。

適用する業務分野に必要なデータベースを作成していきます。

 

ここで改めて運用部門と調整をし、リリース後にデータベースの抜け漏れが無いよう慎重に設定する必要があります。

 

後々修正できることもありますが、

運用部門と共通理解を持っておくことでリリース後に齟齬が起きないように努めるのが賢明でしょう。

 

こうすることで度重なる修正や例外処理の発生を最小限に留め、

新システムをいち早く標準化することも可能になります。

 

パッケージで対応できず、現行プロセスから変更を要する業務のアドオン開発が発生する際もこのフェーズで実行されます。

 

 

【テスト】

OSやデータベースシステムなどの基本システム、ソフトウェア等それぞれの単体テストが完了後、

ERP全体の結合テストを実施します。

 

結合テストでは、個々の機能を果たすためのプログラム部品(プログラムモジュール)を組み合わせて、

データの受け渡しがうまく行われているか、コードの記述様式は揃っているか、

データを授受するタイミングはずれていないか、といった点を確認します。

 

結合テストで不備が発見された際には、再度コーディングを行います。

 

 

結合テストと併せて負荷テストを実施し、業務ピーク時に遅滞なくシステムが動作するか確認し、

問題があればソフトウェアのチューニングやハードウェアの追加等、必要な措置を講じます。

 

 

  • システム運用

【リリース前準備とリリース判定】

 

リリースを直前に控え、その準備として必要なタスクは以下です。

 

  • データ移行(マスタ&トランザクションデータ)
  • ユーザーのIDPASSの初期設定
  • ユーザーおよび運用部門の権限設定
  • 不正操作や障害発生時の通知機能の設定
  • アクセスログの設定
  • 運用部門受け入れテスト
  • ユーザートレーニング

 

これら準備のためのタスクが完了した段階で、リリース基準に達しているか判定を行います。

全体構成はもちろんのこと、設計・運用ポリシーに準拠しているか、

障害対策は想定しうる範囲で手順が確立されているか等あらゆる観点から審査します。

 

ここで全項目の基準が達成されて初めて、ユーザーへリリースすることが可能になるのです。

 

 

【運用と導入成功判定】

設計書・運用マニュアルに従い、システム運用とサービス提供を実施します。

加えて、前述の通り導入成功判定を実施します。

 

判定タイミングを設定し、経営指標が目標値以上を示せるか確認しましょう。

ERPの安定的な運用までは時間がかかるケースも多いです。

 

そのためリリース後も引き続きベンダーのサポートが得られる体制を構築しておくと良いでしょう。

 

 

ERP導入成功のために

ERPは企業活動の要衝を担う非常に「重い」システムです。

いざ導入してみてもうまくドライブしなかったり、かえって業務負担が増えたりするケースもあるようです。

 

それゆえ導入の企画段階から経営トップや運用部門が参画し、綿密にコミュニケーションをとる必要があります。

 

トップとは達成すべき指標、期待する導入結果と実現可能性を共有し、

運用部門(現場)とはユーザビリティ向上のためにヒアリングやデモンストレーションを繰り返し行います。

 

経営指標と現状の業務課題を常に念頭に置き、プロジェクトを進めること。

そしてベンダーに丸投げせず、自社で主体的にマネージすることで、スムーズな導入と明確な導入結果が得られるはずです。

 

 

ここまでERPシステムの概要、導入プロセスを述べてきました。

次回は親和性の高いRPAソリューションを組み合わせ、更なる効率化を検討していきましょう。

 

 

 

第4次産業革命の潮流の中で-IoT編-

2018.09.04

はじめに

有史以来、ヒトはイノベーションによってもたらされた産業構造の変化により、経済発展を遂げてきました。

 

18世紀後半のイギリスで興った、綿工業での紡績機の発明および蒸気機関によるエネルギーの変革(第1次産業革命)。

 

次にアメリカ・ドイツを中心とした、軽工業から重工業への転換と電力の産業化(第2次)。

 

そして「デジタル革命」と呼ばれるコンピュータの登場(第3次)を経て現代へと至ります。

 

 

これらに続く4番目の産業時代、それが「第4次産業革命」です。

この起点として、ICT領域でのアップデートが期待されています。

 

 

4次産業革命を牽引する技術革新

コアとなる技術革新・領域としては以下のものが挙げられます。

 

 

  • IoTおよびビッグデータ解析

工業機械の稼働率から、交通状況、気象情報、個人の健康状況まで様々な情報をデータ化しネットワークでまとめ、

これを解析・利用することで新たな付加価値をつけることが可能になります。

 

≪関連する技術やサービス≫LPWA通信、データ分析プラットフォーム(可視化・最適化)、BIツール(ビジネスインテリジェンス)

 

 

  • AI(人工知能)

ヒトがコンピュータに対してあらかじめ分析上注目すべき要素を全て与えなくとも、

コンピュータ自らが学習し、一定の判断を行うことを可能にする技術

 

≪関連する技術やサービス≫RPA、ディープラーニング、バイオメトリクス、機械学習プラットフォーム

 

 

これらの技術革新は、現代に山積する多様かつ雑多な課題解決や潜在的ニーズの掘り起こし、

生産性向上や労働の補助・代替に役立てられると見られています。

 

これからの時代、ヒトに替わって機械間通信(M2M)が中心となり、

様々な用途に応用しうる基幹的な汎用技術である ICT の役割が一層重要になることでしょう。

 

 

中小企業こそ「潮流」に乗らなければならない

今日わが国では人口減少、人生100年時代という大きな変化の波が押し寄せており、

働き方を抜本的に改革する必要に迫られています。

 

人口減少による人手不足が深刻化している中で、労働人口の確保および労働の効率化は急務であり、

企業の大多数を占める中小企業は言わずもがなこれに対応していかなければなりません。

 

今後大企業はこぞって次世代技術への投資・開発を続け、生産コストの低減とリードタイム短縮を図ります。

対抗するにせよ協業するにせよ、これらの技術革新への一定の理解は必要です。

また、ある程度自社への導入を検討してみるのもよいでしょう。

 

 

IoTでできること

ここからはそれぞれの技術領域について深掘りしていきます。

 

IoTは“Internet of Things-モノのインターネットと称される通り、

様々な「モノ」がインターネットを通じて接続され、モニタリングやコントロールを可能にする通信技術を指します。

 

 

近年では、低速度のデータ通信向けに低価格での通信を可能にする「LPWA(Low Power Wide Area)通信」が話題を呼び、

各社サービスの提供や対応モジュールの開発が盛んに行われています。

 

代表的なLPWA通信規格として「SIGFOX」、「LoRaWAN」、「NB-IoT」等がすでに実用化されており、

なんといってもその通信距離の長さ、低電力性が最大の魅力。

 

今後これらの通信規格がIoTイノベーションを牽引していくものと思われます。

 

IoT導入事例や展開サービスとして以下が挙げられます。

 

 

  • 見守りサービス

高齢者や子どもを対象とし、ウェアラブル端末からの通信でセンサー情報を取得し、

保護者がスマホなどでモニタリングできるサービスです。

 

ウェアラブル端末から得られる情報は種類により異なりますが、脈拍センサーや温度湿度センサーなどで、

対象者の健康状態をモニタリングしたり、GPSを搭載することで位置情報を取得し居所を特定したりすることも可能です。

 

 

超高齢化社会の時代において、孤独死や認知症患者の徘徊を防止する取組みとして各自治体、

介護領域での活用が期待されています。

 

 

また、ネット越しに離れた場所の映像を伝えることができるWebカメラを用いて、

直接監視や室内の温湿度変化を検知し、熱中症の予防を促すなどの機能も登場してきました。

 

 

  • スマートメーターの検針

電力/ガス/水道メーター等、従来人間が検針していたものも「スマートメーター」の登場によって、

代替されつつあります。

 

これらのデータは低容量かつ通信頻度も高くないため、上記LPWAの通信規格が最も重宝される事例のひとつです。

 

 

  • 工場のIoT

製造業で稼働する生産設備の稼働率やメンテナンス状況を監視し、

集積されたデータを基にオペレーションの効率化/最適化を目指します。

 

生産設備メーカーは、それぞれ自社製生産設備の稼働・生産状況を管理するために独自のソフトウェアを搭載しているものの、

実際の工場は、複数メーカーの生産設備によって構成されているため、機器の一元管理は難しいとされてきました。

 

異なるメーカー間ではデータ内容や通信プロトコルに互換性はなく、メーカー毎に専用ソフトウェアが必要になるためです。

 

そこで、それぞれの生産設備に汎用性のある電力計(通信デバイス)を取り付け、

稼働状況をリアルタイムに把握できるようにします。

 

そうすることで生産設備のデータを一元管理することが可能になり、

設備の予防保全や生産性の向上に活用できるというわけです。

 

 

IoTを導入する際の注意点

今後ますます浸透していくIoTですが、その性質ゆえ注意しなければならない点も多くあります。

 

例えばセキュリティリスク。

あらゆるデータが自動的に取得され、ネットワークを通じて繋がるため、

常にハッキングによる不正操作、情報漏洩やプライバシー侵害などのセキュリティリスクを把握しておく必要があります。

 

 

またIoTに取り組む際に、しっかりゴールを設定することも重要です。

むやみやたらにIoTを導入するのではなく、「何をしたいのか」、

IoTを進めることで得られるものは何か、どんなサービスを創出できるか」といった観点からプロジェクトを立ち上げ、

スモールスタートで始めるのが良いとされています。

 

 

中小企業には大企業と違ってエンジニアが少なく、社内で考えているだけでは対応が難しいことが多いでしょう。

 

ある程度自社内のリソースで骨子を作った後は、外部のインテグレーション企業に相談し、

具現化していくのが、一般的なロードマップだといわれています。

 

 

IoT×RPA

収集された大量のデータを効果的に活用するためによく用いられるのがビッグデータ解析ソリューションです。

 

AI技術を活用したソリューションやBI製品等のプラットフォームが各企業からリリースされ、

データ分析に用いられてきました。

 

しかし、この手のサービスは自社開発にしろシステム導入にしろ初期投資がかさみ、投資回収リスクが付きまといます。

 

そこでRPAの導入を検討してみましょう。

収集データの分析を見据えたデータ整理には比較的安価に導入できるRPAでも対応できる場合もあります。

 

この場合、各デバイスからのデータ整理が主なロボットの役割となり、

膨大なデータの中から任意のデバイス、タイミングのデータを抜き出し分析データの土台を作りだすことができます。

 

 

今日の技術ではロボットが高度な判断を下すことはできませんが、簡易的なデータ分析を人間が行う際は、

最も効率的かつ経済的な方法であるといえます。

 

 

さいごに

日々進化を続けるICT領域は、今後わが国全体で積極的に導入/開発が推し進められることでしょう。

 

この“ブーム”取り残されないために大切なことは、日々アップグレードされる情報に関心を持ち、

それをどう自社で活用していくか思案することです。

 

きっとその取り組みは、新たな経営課題の発見や新規事業の創出を促す土壌づくりに役立つことでしょう。

 

 

 

UiPathを2か月使っての感想と、UiPathの導入をお勧めできる環境について

2018.09.03

業務の効率化のため、RPAツール「UiPath」を2か月使用いたしました。

 

UiPathを使用した上での使用感、感想をとりまとめました。

これからUiPathの導入を検討されている、あるいはRPAの導入を希望されている方々にとって、

RPAツール選定の一助になれば幸いです。

 

 

1、直感的に操作できる

 まず、RPAツールは使用するに当たりプログラミングの知識が不要といわれていますが、

UiPathもほかのRPAツールと同様、プログラミングの知識がない方でもプログラムを組むことができます

 

UiPathの場合、アクティビティと呼ばれる部品を組み合わせることで、プログラムを作成・運用を行うことができます。

 

このアクティビティという部品ですが、多くの種類があり、

組み合わせることで様々なRPAのプログラムを構築することができます。

 

 

 また、基本的な操作を覚えさせたい場合、Recordingという機能を使用することで、

指定の場所のクリック作業や、テキストボックス・セルへの入力作業を覚えさせることができます。

 

エクセルの「マクロの記録」でマクロを作成したことがある人はイメージしやすいかもしれませんが、

「マクロの記録」と同じように、デスクトップ上を選択・入力することで作業を記録させる機能として、

運用することができます。

 

 

 複雑な処理を行いたい場合、あるいは特殊なアクティビティを使用する際に、

プログラミングの知識が必要になる場面がありますが、

アクティビティを組み合わせるだけで基本的なプログラムを作成できるため、

それぞれのアクティビティの動作を知っておけば業務上における有用なRPAは構築できるようになります。

 

 

2、限定的だが、導入コストが0円から運用できる

 UiPathの大きな特徴として、「UiPath Community エディション」をダウンロードして使用することができることがあげられます。

 

 ほかのRPAツールの場合、販売代理店とのライセンス契約を締結する必要があり、

事前に一定のコストを支払わなくては使用できないことが多いです。

 

 その点、UiPath Community エディションは限定的ではありますが、無料でダウンロードでき、

かつライセンス版のUiPath Studioと同等の機能を有しています。

そのため、事前に自社の業務がUiPathに適合するかどうかを確認することができます。

 

 実は、RPA導入の際のトラブルの一つに、

「そのRPAツールで思っていた効果をあげることができなかった」ということがあるそうです。

 

 このようなミスマッチが起こる一つの要因として、RPAを導入する側の、

「事務作業すべてをロボットが代用してくれる」という考えがあるとのことです。

 

 RPAは確かに定型業務を代行するためのシステムです。

ですが、導入に際し現行システムを生かすためのRPAツールを導入しようと考えてしまいます。

 

 実際の導入になった時に、既存のシステムとのリレーションが取れないRPAツールだった、などという事例もあるそうです。

 

 UiPathであれば、Communityエディションを使用することで、事前に適合を確認できるため、

上記のようなミスマッチを事前に防ぐことができます。

 

 

 もし、UiPath Communityエディションでトライアル運用して問題なさそうであれば、

追ってUiPath StudioやUiPath Orchestratorのライセンス契約を結べばよいので、

本格導入前に使用感を確認できるというのはかなり強みだと感じます。

 

 

 会社でライセンスを購入する場合の詳しい料金体系の詳細については、

UiPathの公式サイトをご確認いただきたいのですが、個人でかつ1台で使用する分にはコストがかからないため、

個人で使用感を確認したうえで導入されることをお勧めします。

 

 

3、学習するための環境がほかのツールと比較して多い

 UiPathには、以下の学習環境があります。

  •  UiPathアカデミー
  •  UiPath Communityフォーラム
  •  ユーザーガイド
  •  ナレッジベース

 

 UiPath アカデミーとは、ビデオによるUiPathの学習教材です。

学習フローとしては、ビデオ学習→確認テストを繰り返す方式で、

各設問の確認テストに合格しないと先に進めないようになっています。

 

設問は全14問で、最後に総括としてFinal Testがあります。

Final Testに合格することで、UiPathの基本的な知識を備えたエンジニアになったことの証明が可能です。

(証明書を取るだけでなく、実際に現場での作業や日々の学習を行うことで、よりUiPathを使いこなせるようになります。)

 

 

 UiPath Communityフォーラムとは、定期的に開催されるユーザー間での勉強会のようなものです。

ユーザー同士の発表や、意見交換を通じてよりよい利用方法を検討するといった意見交換の場にもなっています。

 

 ユーザーガイドは、アクティビティの詳細や活用方法がまとめられています。

また、ナレッジベースは、特定の運用方法に関するサンプルがまとめられています。

いずれもより詳細な運用方法を調べるときに活用できるでしょう。

 

 

4、Excelとの親和性が高い

 UiPathは、作業を効率化するためのツールです。

現場で一番活用されているエクセルとの親和性も高いです。

 

エクセルソフトの中でも、最も利用率が高い、Mircosoft Office Excelとの親和性が高いのも、UiPathの特徴です。

 

 Excel関連のアクティビティだけでも20種類以上(2018年7月現在)あり、

ユーザーがエクセル上でも頻繁に使用する作業がアクティビティとして登録されています。

(セルへの代入、シートの移動、マージ等)

 

 

 また、execute macro というアクティビティがあるのですが、

これはExcelに保存されているマクロおよびVBAをUiPath上で起動させることができます。

 

現行システムとして、マクロやVBAで運用している場合、既存のシステムを活用して、RPAを導入することができます。

 

 ですが、もしマクロやVBAと合わせて運用する場合は、それぞれの作業範囲をはっきりさせる必要があるため、

開発する前に効率的な運用について検討する必要があります。

 

 

5、今後のアップデートで使用できるアクティビティが増える

 UiPathのアクティビティは常に増え続けています。

また、外部ツールとの連携を行うためのアクティビティも日々更新されています。

 

そのため、今後のアップデート次第では開発・運用がより楽になる方法が見つかるかもしれません。

 

 

 以上が、Uipathを使用して感じたこととなります。

UiPathの特徴として、やはり導入の敷居がほかのRPAと比べて低く、

あらゆる企業でRPA化を進めやすいということが大きな利点であると思われます。

 

また、学習環境も備えているため、プログラミング未経験でもとっつきやすいという性質があります。

 

 これらの理由から、UiPathを導入する場合、以下の環境で業務をこなしている環境にUiPathが適していると思われます。

 

  • RPAをこれから導入しようと考えているが、何ができるのか確認したい。
  • RPAの開発を自社で検討している。
  • 現状、ExcelマクロやVBAで運用しているシステムがあり、それらの業務システムを活用してRPAを導入したいと考えている。
  • 小規模開発でRPA導入を検討している。

 

 UiPathはプログラミングを学習したことない人から熟練者まで、

幅広い層に向けて開発されたRPAツールであることが窺えます。

 

またRPAの導入方針にもよりますが、自社で新たにRPAを導入する際のトライアルとしても十分なツールであると思います。

 

 また、大規模開発を行いたい場合でも、UiPath Orchestratorを活用したサーバーからの運用と、

UiPath Robotを使った複数台のPCでの運用を行うこともできます。

 

実際に、定型業務に多くの人的リソースを割いている会社ほど、

UiPath Orchestratorを介したロボットの導入により、多大な効果を得ることができます。

 

 今後、RPAの導入を検討するうえで、まずRPAに触れていただき、適切なRPA化を進めていくべきであると、私は考えます。

 

 

topへ
© RPA.biz