2018.09.28
＜目次＞
「働き方改革」という言葉はニュースでも盛んに流れています。
そして、多くの企業でも「働き方改革」を旗印に、様々な施策が動いています。
某大手外食企業における「働き方改革」プロジェクトの中で、
実際に導入されたRPAの事例を軸に紹介していきたいと思います。
●社会全体が人手不足
2018年現在、社会は空前の人手不足と言われています。その理由の1つに少子高齢化があります。
（出典）国立社会保障・人口問題研究所
図を見ると、2010年以降急速に生産人口が減っていることがわかります。
つまり、働く人が減っているのです。
そして、2018年現在の好景気（諸説ありますが）という要因もあり、
企業は人の採用が難しくなっている現状があります。
●外食ってブラック？
外食業界は、他の業界と比較しても、人手不足感は際立っています。
労働集約型産業の代表的な業界ということもありますが、
「給料が安い」「労働時間が長い」「休めない」
というイメージがあることも原因の1つです。
「給料が安い」ことは、今回のプロジェクトの対応範疇外ですが、
後の2つをどうにか改善する必要があります。
※実際問題、「給料が安い」はイメージ先行かもしれません。
高くはないかもしれませんが、大手外食チェ－ンの正社員であれば、問題なく家族を養えます。
●外食業界のもう１つの問題点
外食業界のもう１つの問題点は、大手含めて利益率が少ない会社が多いということです。
（出典）StockClip「国内外食産業の業績ランキング」
売上高順に並んだランキングですが、
大手外食チェーンは軒並み1桁台の利益率だということがわかります。
この為、社員を安易に増やせる状況ではなく、
その少ない正社員と多くのアルバイトやパートなどの非正規人材によって成り立っている現状の中、
その少ない正社員は、事務作業などの非付加価値業務に追われているという現状があります。
前置きが長くなってしまいましたが、
・外食産業は人手不足だが、給与を高く設定することが困難な為、採用難である。
・社員には仕事の負荷が重くのしかかっている。
上記を改善させるべく、今回のプロジェクトが始まりました。
※このプロジェクトの内、RPA導入に関するシーンを切り取っています。
●店舗はどれだけ事務作業をしているのか？
シフトの作成、レジ締め作業、本部への売上報告書の作成、クレーム報告書、発注作業
など多数の事務作業があります。
1日の内、3割が事務作業という結果でした。
●本社（本部）は売上や入金をどのように確認しているのか？
売上といっても、現金以外に金券（ギフト券、商品券、株主優待券など）・クレジット・電子マネー
といった売掛が多種に渡ります。
専属の社員を多数用いて、既存のシステムとエクセルで日々確認しています。
●業務フローの確認と現場ヒアリング
RPA導入において、大事な点は、業務フローがキチンと整備されていることです。
たとえ整備されていたとしても、業務フローには記載されていない業務は必ずあります。
担当者にヒアリングをして、必ず業務を確認しましょう。
＜注意点＞
RPAは、あらかじめ決めた業務を行ってくれるロボットです。
つまり、臨機応変な対応は出来ません。
イレギュラー業務が発生するのであれば、そのパターンを全て網羅しておく必要があります。
逆に網羅出来ない業務が発生する場合、RPA導入はお勧め出来ません。
●業務改善案を練る（コンサルの方のみ）
たとえ大企業といえども、そもそも必要なの？という非効率な業務は必ずあります。
何のための業務なのか、誰が必要としている業務なのか、
という視点で案を練りましょう。
＜注意点＞
RPAに置き換えるという視点では無く、業務がどうあるべきかという視点を持つことが重要です。
ほとんどの場合RPAは必要ないかもしれません。
●RPA製品を選びます
2018年現在、有料無料含めて10数個のRPAツールが存在しているようです。
最終的には、以下の2つが候補となりました。
国産型RPAツール。デスクトップ型のPRA。フローの作成画面などのUIがわかりやすい。
小規模業務を得意としている為、中小企業でも導入しやすい。
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の障害パターンの把握が深まれば、
より複雑な業務へと拡張させていくことが出来ます。
●結果事例① 【店舗】レジ締作業の時間短縮、【本社（本部）】エラー確認の時間短縮
これまで、店舗はレジ締作業において、1日あたり30分～1時間を擁していました。
その内、売上データの不備確認が多くの時間を占めていました。
売上データは本部へ自動送信されますが、売上データに不備がある場合、
自動送信がエラーとなってしまいます。
本社（本部）は毎日、そのエラーの有無の確認、エラーがあった場合の調査に時間を費やしていました。
店舗、本社（本部）の2重チェック体制となっていました。
RPA導入により、店舗はレジ締作業において、売上データの不備確認を不要とし、
自動送信にエラーが発生した場合は、
その発生と発生理由を本社（本部）の担当者へ自動でメール送信されることになりました。
店舗の作業が大幅に減ると同時に、本社（本部）も、
メールによるアラートにのみ対応すれば良いということになりました。
●結果事例② 【本社（本部）】売掛請求の入金照合を時間短縮
本社（本部）は、金券類やクレジットカード、
そして電子マネーなど多種に渡る売掛の入金確認を行っています。
様々な売掛先からの入金日は1か月の中で十数回もあり、
これまでは、その照合チェックをエクセル上で行っていました。
1年を通してみても、請求額と入金額に相違が発生することは、
まず無い為（金券が偽物だった場合などであり得ますが事前連絡により承知済です）、
内部統制上での必要事項とも言えます。
RPA導入により、入金データと請求データの照合を自動で行い、
相違がある場合のみ、メールで担当者へ自動メール送信されるようになりました。
これは、本来であれば、システム開発によって対応されていても良いかと思うのですが、
対応されていませんでした。
新たにシステム開発した場合との費用検討の結果、RPA導入にメリットがありました。
以下は、検討したが断念した事例
●断念事例①店舗における発注作業のRPA化
店舗では、毎日の作業として、食材や備品（食器など）を、
Web発注システムを使って発注作業を行っています。
これをエクセルに発注内容を記入してメール添付することで、
RPAが自動的に外部のWeb発注システムに登録することで、発注作業の簡易化という検討を行いました。
しかし、食材は結構な頻度で変わる
（例えば、エビでもインドネシア産エビが高騰の為、ベトナム産エビに代わるなど）為、
RPAのメンテナンスが大変だということで、メリットを生み出すことが出来ませんでした。
●断念事例②RPAが印刷を行う
本社（本部）では、毎日の作業として、数百枚にも及ぶ法定帳票を印刷するという作業があります。
それを深夜に自動的に行うことで、日中の印刷作業を無くすよう検討を行いました。
しかし、そもそも法廷帳票を紙で保存では無く、
データ保存とすることで印刷作業を無くすべき姿だという結論に至りました。
単純な話しかと思いますが、
既存業務をRPAに置き換えるという観点だけではいけないということに気が付きました。
●RPAありきではダメ
RPAが出来ることは限られいます。
RPA自体が何か新しい価値を生み出すわけではありません。
あくまでも既に回っている既存業務の改善がメインです。
また、多くの場合、
「既存のシステムを改修すればRPAではなくても対応出来る」
ということです。
既存の業務を改善する上でのソリューションの１メニューとして捉えるべきだと感じました。
●社内コンセンサスの大変さ
「RPA導入によってこれだけの効果が出ます」と言えば、経営層は喜んでくれます。
しかし、RPA導入によって、仕事が無くなってしまう人がいるのも事実です。
または、慣れ親しんだ業務が無くなることが嫌だという人もいるでしょう。
とある店長は閉店後の売上データ不備確認でその日の業務を振り返ると言っていました。
RPA導入は本社（本部）のみならず、店舗を含めた幅広い、且つ、丁寧なコンセンサス形成が必要です。
●RPA導入により属人的な業務が減る
会社の規模に関わらず、会社にはその人しか知らない業務という属人的な仕事があったりします。
また、人によって業務の進め方にクセがあることも多いかと思います。
RPA導入によって、業務が可視化され、
また、業務の進め方もある程度統一されると感じました。
この観点で言うと、効率化もそうですが、内部統制の面でも良い影響があるかと思います。
今回は、大きな流れでRPA導入についての説明をしました。
RPA導入を考えている会社は、
チャットボットなどの簡易AIの導入も同時に検討していることが多いかと思います。
RPA導入担当者は、それらの他のプロジェクトを把握して、
どのような連携が考えられるか、という視点を持っても面白いかもしれません。
いずれにせよ、RPAはこれから発展していくツールです。
RPAに関わることはあなたの社内はもちろん、市場価値が高まることは間違いないと思います。
弊社では、RPA導入のご相談を承っております。
RPA導入についてご検討の方は、東京ビッグサイトで開催されるRPA導入無料相談会に是非ご予約ください。
2018.09.27
企業において、業務効率化は至上命題のひとつではあるものの、
比較的小粒の業務についてはコスト面および対応のしづらさから、人手に頼っている部分が多く残っています。
多くのコンサルティング会社は、
企業のバックオフィス部門の生産性向上と人的資源の有効活用を推進するため、
RPA（Robotic Process Automation）ツールを活用し、
業務自動化を推進する業務改革サービスを提供しています。
大量定型業務はビジネス・プロセス・リエンジニアリングや大規模システムの導入により、
効率化が実現できているものの、
小粒の業務はさまざまな理由によりいまだ人海戦術で対応している企業が散見されます。
RPAツールによって、従来型のシステム開発手法では対応しにくい
「ボリュームが小さい」「変更が多い」「標準化できない」
といった業務であっても、RPAツールを活用することで効率化が可能となります。
数多くの業務改革経験を生かし、現場を巻き込んだスピーディな業務改革を実施するRPA業務改革サービスは、
RPAと、コンサルティングの業務改革ノウハウを組み合わせたサービスです。
RPAの対象業務としては、
これまで自動化できなかったERP、Webメール、ファイルサーバー、デスクトップ上のExcel、
などアプリケーションをまたいで発生する広範囲の業務を自動化することが可能です。
業務の一連の流れと参照情報を整理し、ロボットが記憶し自動化するため、
コーディングなどのシステム開発が不要です。
そのため、従来のシステム開発手法では対応することが難しかった
「業務量が少ない」「変更が多い」「標準化できない」
といった業務でも自動化することができます。
また標準的なアプローチのため、簡易効果診断では、ロボット化する対象業務の洗い出しを行い、
工数削減の効果および開発費用の概算を算定します。
トライアル導入では2～3つのロボットを導入し、実環境におけるロボットの有効性を検証し、
効果の実感を確認した上で本格導入へと進みます。
生産性向上が必要になる中で、企業での積極活用が叫ばれているテクノロジーが、
RPA（Robotic Process Automation：ロボティック・プロセス・オートメーション）です。
去年開催された日本RPA協会の主催セミナー「やらざるを得ないRPAと取り組みの実態」では、
いまITにおいてキーワードになりつつあるRPAについての解説がありました。
今後、日本は労働者人口が大きく落ち込むと予想されています。
内閣府の「平成28年版高齢社会白書」によると、2025年には日本の人口は700万人減少し、
15歳から64歳の人口が約7000万人まで落ち込むと言われています。
そのような日本の労働人口が減少する状況下において、
日本人の働き方を大きく変えるテクノロジーがRPAなのです。
RPAはアプリケーションを使って行うオフィスワークを学習し、それをそのまま実行することができます。
いわば、人が手動で行っていた各種ツールによる事務処理などの
ルーティンな作業を代行してくれるデジタルレイバー（仮想知能労働者）です。
人がやりたくない、やるべきではない作業を人の200倍のスピードで処理してくれます。
そして、365日24時間稼働してくれます。
デジタルレイバーという新しい労働力が活用できるというわけです。
また、RPAは人の操作を記憶させるだけなので、
稼働させるために大規模なシステム導入やプログラムの修正・変更の必要はありません。
ノンプログラミングで容易に構築でき、短期間かつローコストで導入することができる
というメリットも生まれます。
ユーザー部門が対象システムを活用することによって、
どの程度生産性を向上できたか、定量・定性両面から把握します。
これにより、成功事例の全社展開や費用対効果の振り返りなど、
積極的な IT マネジメントを遂行できるようになります。
測定が難しいシステム導入によるホワイトカラーの生産性向上度合いを、
短期間で簡易的に調査して定量的に示します。
さらに、その部門の“業務項目”にブレイクダウンしその効果を示します。
同時に、定性面での特徴も示すことで、数値とその論拠をマネジメント層がわかるような形で表現します。
生産性調査でよくみられる“調整”や“資料作成”といった作業項目での評価のみならず、
“年度計画立案”“市場調査”といった、マネジメント層が理解できる業務項目ベースで効果を示すべきです。
業務の自動化は業務システムの見直しでも実現できますが、RPAは概念が異なります。
例えば、顧客管理業務のケースで考えてみましょう。
顧客管理システムが導入されている企業でも、
顧客データのインポート作業などはたいてい人の手で行ないます。
また、入力作業の報告メールを送ったり、入力作業後に他のスタッフがダブルチェックしたり、
人手による作業はそれなりに発生します。
業務効率化のためにシステム改修を行なったとしても、
システム間のデータ移行やチェック業務などはなかなかシステムに組み込みにくい作業です。
一方RPAの場合、入力作業からチェック、報告までのプロセスすべてをソフトウェアロボットが代行します。
つまり、
システム変更ではカバーしきれない業務範囲でも、RPAでは自動化できる可能性が高い
というのがポイントです。
システム変更ではイレギュラー対応など非定型業務の自動化が難しいケースが多いのですが、
RPAならAIなどの導入で実現できるケースもあります。
とある銀行グループが業務自動化技術を導入して、
約9,500人相当の仕事量を削減する方針を2017年9月に発表したことが大きな話題となりました。
この業務自動化技術のメインとなるのが、
RPA（Robotic Process Automation：ロボットによる業務効率化）です。
もちろん、RPAの導入により、
品質の向上とリードタイムの短縮、労働不足の解消につながっており、効果は出ているそうです。
ロボットによる業務代行というと製造業をイメージしがちですが、
RPAはPCを使った業務などホワイトカラーの業務を代行します。
そのため、仮想労働者（デジタルレイバー）とも呼ばれることもあります。
ロボットによる業務効率化というと、単純作業の代行というイメージを持つ方も多いかもしれません。
RPAでは3つのクラスに分かれていて、最も高度なクラス3になると
AI（人工知能）の学習能力によって分析や業務改善などの複雑な業務ができるものもあります。
＜クラス詳細＞
RPAは2016年以降、働き方改革の手段の1つとして注目を集めている技術です。
自動化技術などの導入により、
人間は人にしかできない仕事や新しい仕事を担当するようになるでしょう。
仕事に必要なスキル向上も合わせて行い、オフィスワーク全体の生産性を高めていきます。
今、人が行なうPC業務をRPAによって自動化することを目指している企業は少なくありません。
2018.09.26
今回のブログでは、オフィスで行われる事務作業について
既にAIの技術が開発され導入していっている事例をご紹介したいと思います。
昨今の電子化の流れを受け、ビジネス上の様々な情報が電子データとして扱えるようになってきました。
これは即ち、AIにとって「教師データ」となるソースが質量ともに高まったことを意味し、
ビジネスシーンにおけるAIの活躍の場を押し広げる事に繋がりました。
「教師データ」というのは、AIが学習する上で必要不可欠な参考データのことですが、
これは端的に言えば、今まで人間様が行っていた判断・意思決定の記録を意味します。
例えば、今まで社員が夜を徹して行っていた文書やメール文などの
チェック業務のレコードを「教師データ」としてAIに学習させれば、
次からはAIが自動で今までの判断基準を参考に人間の代わりにチェックを行ってくれるようになります。
今回のブログでは、AIを使ったユニークなビジネスソリューションを展開している、
FRONTEO社の取り組みをご紹介したいと思います。
FRONTEO社は2003年に設立、現在マザーズに上場しています。
KIBITとという独自の人工知能モデルを活用し、
法律事務所や医療機関、官公庁や民間企業へのサービス展開を行っている企業になります。
特に実績として名高いのは、
法律関係での「ディスカバリ」とよばれる
訴訟案件における証拠の収集や特定、提出にいたるプロセスと、
「フォレンジック」という
情報漏えい、談合・カルテル、横領、労務問題、ハラスメント問題、セキュリティ事案
をはじめとするさまざまな不正調査プロセスへのAI適用です。
これらいずれの業務も、本来人間（調査員）が行う場合は、
膨大な量の文書や電子メールでのやりとりのチェックが発生します。
この膨大な調査業務をAIで効率化するというのが、サービスのコンセプトになります。
参考： FRONTEO ホームページ（http://www.fronteo.com/ ）
FRONTEO社では、Landscapingと行動情報科学を併せた同時の人工知能術を開発しており、
特徴としては少量の教師データで、パターン解析・学習をすることができることを謳っています。
この「教師データ」というものは、AIを実務で活用しようとするときに必ず直面する厄介な問題です。
AIの精度をそれなりのものにするためには、まず実際に人間が行った
評価・判断・意思決定に付随するデータをAIに「喰わせる」必要がありますが、
実際にそのファクトとなるデータがなかなか集まらず、
結果、AIの学習が滞り、「頭の悪い」AIしか育たないケースが散見されます。
これは、AIの一大分野である「画像認識」の技術でも言えることです。
よくIoTとの絡みで、工場内の検品業務にAIを導入するような取り組みが
新聞雑誌で取りざたされることがありますが、
この場合も事前に人間が判別した「不良品」の画像データを相当数AIに喰わせる必要がありますが、
そもそもそれほど不良品率が低い工場だと、教師データ自体が集まりません。
これを改善する方法として「不良品」ではなく「良品」のほうを教師データとしてAIに入れ、
その基準から外れたとAIが判断したものを「不良品」と一次判定するような取り組みが挙げられていたりします。
いずれにせよ、この工場の検品という領域ではまだ大ロット少品種の大量生産品が対象であり、
ジュエリーなどの小ロット多品種のケースではまだまだAIの導入の壁は高い印象です。
この「教師データ」の問題を、FRONTEOが得意とするフォレンジックの領域に当てはめると、
例えばそれは社内の社員の不正の証拠となる電子メールの数々が「教師データ」となります。
FRONTEOでは、おそらく膨大な数のクライアントにおける不正事例をもっており、
それをAIにインプットし学習させているのだと推測されます。
この社員のメール文面から不正示唆を判別する能力ですが、しっかりと学習されたAIであれば、
普通の一般的では見過ごしているような点まで気づいてくれるようになります。
例えば、一見、サプライヤーの担当者と親睦を深めるために飲みに誘うだけにしか見えない
メールであっても、わずかなニュアンスの違いを検知し、
談合の可能性を示唆してくれるようになります。
このような文書やメール文を解析し示唆をだすAI技術ですが、
この効能の潜在的価値はビジネス上で計り知れません。
そう、それは何も法律関係に事象にとどまらず、かなり広範囲に適用できる武器となりえます。
例えば、以下のようなシーンでの活用が見込めます。
ここで挙げた事例は、ほんの一部にしかすぎず、
アイデア次第では様々な用途にこの技術が使われうることは皆さん用意に想像できるかと思います。
要するにこの技術は、
「テキストデータ群から、ある傾向をもつものを自動で抽出する技術」
に他なりません。
我々の日常業務は常にドキュメントやメールといったテキストデータに囲まれています。
また、最近では音声データの自動テキスト化技術も急速に発展していっています。
これは即ち、
コールセンターでの応答や、入社面接での面談応答、会議の討議内容といったことまで自動でテキスト化され、
AIの恩恵に与れるようになるということです。
今まで熟練社員でしか見つけられなかった「気づき」のノウハウを、
入社1日目の新入社員でも享受できるようになる時代が到来しようとしています。
最後に、このKIBITのようなAI技術とRPAの関係について述べたいと思います。
RPAは他のコラムでもご紹介している通り、現在市場で実装されているものは「考える」力は持たず、
「手を動かす」方を中心に自動化するのが主流でした。
つまり、判断や示唆出しといったものではなく、
その後の定型操作・作業の自動化のみに特化しているということです。
一方、AIの技術というものは、まさに今回のコラムでご紹介したFRONTEO社の技術のように、
まさしく人間が「考える」とこであった判断・示唆出しを高度に自動化してくれます。
このAIとRPAが融合できたときに、
「考える」ことと「手を動かす」こと
が同一のPCもしくはサーバ上で行えるようになります。
これこそがロボットワーカーの最終形態とも呼べるものであります。
このAIとRPAの融合というテーマは、昔から様々な識者が唱えている事であり、
近い将来に実際の巷間のオフィスで実現化される可能性が高いと言えます。
そのような世界が到来した時、RPAの活用はさらにもう一段広がることは確実であり、
人間である社員側は今とはまた違う働き方を求められる世界がやってくることになります。
2018.09.25
前回は、UiPath Orchestrator環境を構築するために、ElasticsearchとKibanaをインストールしました。
【前回記事はこちら】
今回は、Orchestratorをインストールします。
今回も、Orchestrator v2018導入ステップバイステップガイドを参考にしながら、インストールしていきます。
OrchestratorはTCP443ポートを使用しますが、インストーラーが設定してくれます。
インストーラーは、UiPathサイトからダウンロードできます。
インストーラー実行後、ライセンス条項に同意して、「Advanced」を選択します。
デフォルトのインストール項目にOrchestratorは含まれていませんので、追加しましょう。
不要な項目を外して、Orchestratorだけをインストールすることもできます。
今回は、Orchestrator Websiteとロボット、ロボット自動起動機能をインストールします。
ホスト名が正しいことを確認して次に進みます。
「Application Pool Identity」を選択して次に進みます。
SQL Server名とuipath_sqlの名前とパスワードを入力して次に進みます。
ElasticsearchのURLを入力して次に進みます。
Windows認証を使用する場合は、チェックを入れて、ADドメイン名を入力します。
今回は、チェックを入れずに進みます。
「Install」をクリックします。
インストールが完了しました。「Launch ～」のチェックを外して終了します。
インストーラーがちゃんとWindowsファイアウォールを設定してくれたか確認します。
TCP443ポートが許可されています。
インストーラーでロボットの自動起動を選択した場合は、サービスも確認しておきます。
IISマネージャーで「UiPathOrchestratorYYYY.X」サイトが作成されていることを確認します。
SSMSでUiPathデータベースにテーブルが作成されていることを確認します。
続いて設定ファイルを確認します。
まず、IISマネージャーでサイトを停止します。
サイトが停止したら、設定ファイル
「C:\Program Files (X86)\UiPath\Orchestrator\Web.config」
をメモ帳で開きます。
組織単位機能を有効にしたい場合は、「OrganizationUnit.Enabled」を検索し、
見つかった行のfalseをtrueに変更します。
Orchestratorガイドには、まだテスト中、と書いてありますが、
この機能を必要とする環境は多いと思います。
Web.config内では、「<!–」と「–>」で囲まれた部分はコメントアウトされます。
続いて、Orchestratorのログの書き込み先を確認します。
「logger name」で検索すると見つかります。
図のように“database, robotElasticBuffer“と書かれている場合は、
SQL ServerとElasticsearchの両方にログが書き込まれます。
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のブラウザでもログイン画面を確認できました。
この時点で、管理用ユーザーの追加等はできますが、ロボットの登録はまだできません。
ロボットを登録するには、ライセンスが必要となります。
ライセンシングについては、次回、説明します。
ブラウザでOrchestratorを見るたびに自己証明書で注意されるのは面倒です。
設定をいくつかいじって試してみたところ、
httpでOrchestratorにアクセスできるようになりましたので、
ここでは、その方法について書きます。
まず、UiPathOrchestratorサイトを停止します。
UiPathOrchestratorサイトのバインドを編集します。
まずhttpを追加します。
種類がhttpになっていることを確認してから、ホスト名を入力し、OKをクリックします。
httpsを選択して削除します。
httpsが削除されたことを確認してから閉じます。
サーバーを選択して、サーバー証明書をダブルクリックします。
サーバー証明書を削除します。
Web.configをテキストエディターで開き、https接続に関する部分を探し出します。
コメントアウトします。
Web.configを上書き保存してから、IISマネージャーでサイトを開始します。
以上で設定は終わりです。
ブラウザで「http://サーバー名」を開いてみましょう。
ブロックされる場合は信頼済みサイトに追加します。
念のため、他のPCのブラウザでも確認しておくとよいでしょう。
今回作成した3サーバーの、Orchestratorのインストールが終わった時点でのディスク使用量を調べました。
Orchestrator用サーバーのディスク使用量：
SQL Server用サーバーのディスク使用量：
Elasticsearch+Kibana用サーバーのディスク使用量；
今後、ロボットを動かしながら、ディスク使用量や、ログやデータベースのサイズの変化を見ていく予定です。
2018.09.21
近年、日本のRPA市場が急速に成長していることは言うまでもない事実ですが、
今回のコラムでは、中国のRPA市場発展を紹介していきたいと思います。
この数年間の中国では、モバイル決済、シェア経済などを始めた
「インタネットプラス」産業が急速に発展し、
いくつかの業界から言うと世界のトップランクになっていると言っても過言ではありません。
Tencent、Baidu、アリババ、Huaweiなどの企業は
最近盛り上がっているAIとビッグデータにも力を入れています。
こんなITが好調に成長している環境のなか、RPAはどのようになっているでしょう。
本文は近年中国国内RPAに関するビッグニュースを基に、中国RPA発展の外観をみていきます。
中国南方航空（以下「南方航空」）は国営大手航空会社です。
2016年の売上は約1148億元（約1.8兆円）、運輸人数は約1.1億人でした。
近年LCCなどの格安航空の参入や燃料費上昇に伴い、コスト削減が大きい問題になっています。
そして、南方航空がRPAに目を付けました。
2018年6月前後から、その第一弾として、Ernst & Youngとコラボをし、
車内の財務システムをRPA化することを図りました。
Ernst & Youngはまず南方航空の財務業務を分析し、重要度の高い業務を180個洗いだしました。
続きまして、最もRPA化に向いている業務を13個選出し、
費用対効果で評価した上で、試験として4つの業務に絞りました。
つまり、「国内昇降費精算」、「銀行決済」、「コスト月報」と「食事費用精算」
を先行業務として開発をし、実装すると同時にその効果を検証していったのです。
具体的な業務内容は公開されていないですが、
南方航空は業務を選定した理由については推測できるでしょう。
航空会社は分社や子会社がとても多いため、財務試算や精算する際に、
各グループ会社のデータを集めて、フォーマット変換などをし、
最終的に社内の会計システムに取り込みます。
作業の量が多く、必要時間が長いです。
銀行決済、食事費用精算なども似たような特徴があります。
当然、これらの業務は費用対効果が大きく、
RPA開発も比較的にしやすいとErnst & Youngが判断したのでしょう。
そして、試験段階の結果について、Ernst & Youngが目安結果を公開して、下記表1になります：
効果は極めて大きいと言えるでしょう。
南方航空は中国航空会社の中ではRPA導入の一番手として、今後とも他の業務をRPA化する予定です。
2018年6月の「CIFI中国保険財務革新会議」では、デロイトは参加者として、
自社の金融・保険会社向けRPAソリューション「小勤人」を披露しました。
デロイトの講演では、自社がRPA導入に成長したA、B、C三社の事例を中心に説明をしました。
大手金融サービス企業A社はデロイトのRPAソリューションを利用し、
ネットバンキング突合業務を自動化しています。
内容として、RPAが毎日ネットバンキングから取引履歴をダウンロードし、
自社会計システムとの履歴を突後します。
とても単純な業務ですが、量が極めて多く、膨大な時間が使われています。
このシステムの導入により、A社グループ全体で約200人の従業員がこの業務から解放されました。
大手外資保険会社B社は近年中国での業務量が急増しているため、
契約書処理と賠償データ処理業務も多くなっています。
それを解消するために、RPAを導入しました。
RPAのメインの業務は新規契約書入力と賠償データ更新になります。
業務内容についてデロイト詳しく語っていなかったですが、
主にシステムの間の転記、または突合業務になります。
それ以外、契約書の標準用語チェックもRPAが実行し、
間違っている言葉が使われたら自動で治すことが可能になっています。
結果として、今まで従業員10名が必要となる作業はRPAが代わりに行い、
処理時間も70％短縮されました。
企業Cは中国国内大手上場保険会社であり、人事業務においてデロイトのRPAシステムを導入しました。
主に新入社員の情報確認などについてつかわれています。
例えば、
政府のサイトに身分証明書ID（マイナンバー相当なもの）により新入社員の個人情報取得や
医療保険番号により医療保険情報の取得
などです。
導入により、該当業務の効率は50％向上しました。
デロイトのRPA「小勤人」はデータ収集、入力、システム間の接続などに得意し、
さらにAIと組み合わせ、データ分析することも可能だと言われます。
アリババは中国ECサイト運営会社最大手として、近年世界中でも活躍しています。
会社が1999年設立以来、高速成長をし、2017年の売上は3.77兆元（約61兆円）に達しました。
規模が大きくなるとともに、各部署の業務量も急増しています。
対策として、2016年にアリババがRPAにたどり着き、自動化によって効率向上を図りました。
最初は問い合わせ対応（チャットボックス）ロボットを実装しました。
お客様から問い合わせがあれば一回ロボットがキーワード検索とナビの形で対応し、
対応しきれない場合従業員に振るという形でした。
実際の効果はとてもよく、アリババ傘下の各グループの各業務に普及してきました。
それが最終的に「アリクラウドRPA」（使用RPAソフトの種類は未公開）となり、
2016年から2017年の間で他社にサービス提供し始めました。
現在アリクラウドRPAはカスタマーサービス以外に、
財務、文書処理などにも対応できるようになり、汎用性の高いロボットを開発しています。
小売、IT、金融、証券以外、自社既存のネットワーク
（地方政府がアリババのクラウドソリューションを採用しているところが多い）を生かし、
政府機関に「アリクラウドRPA」を導入しています。
また、アリババは2018年に中国RPA市場規模が急成長し、60％以上の増加率と信じています。
i-SEARCH（芸賽旗）は2011年上海に設立されたITベンチャー企業です。
主にビッグデータなどのデータ分析に注力しています。
2018年1月、世界中に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種類があるように見えます：
また、今回の事例では、RPAを導入した企業のいずれも大手でした。
原因として、人件費による可能性が高いです。
近年中国の平均人件費は高くなっているとはいえ、日本に比べまだ低いです。
賃金の高い上海でも、現在の最低賃金は4万円弱/月になります。
この環境では、大きい規模でなければ、費用対効果はあまり良くない可能性もあります。
勿論、一概にはいえないですが、これは原因の一つだと考えられます。
逆に言うと、人件費が高い日本では、RPA導入がより多くの中小企業にも有効でしょう。
2018.09.20
前回は、UiPath Orchestrator環境を構築するために、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をインストールします。
【次回記事はこちら】
Hyper-Vの仮想マシンで動的メモリを有効にしている場合、注意が必要です。
動的メモリが有効になっていると、
ウィザードが起動された時点で仮想マシンに割り当てられていたメモリサイズが、
ウィザード上でElasticsearchに割り当てられるメモリサイズの最大値となってしまいます。
動的メモリを無効にしている場合
動的メモリを有効にしている場合
動的メモリを使用する場合は、あらかじめ「この仮想マシンが使用できるメモリの量」、
もしくは、「最小RAM」を大きめに設定しておきましょう。
2018.09.19
【前回記事はこちら】
前回は、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_ownerとpublicの役割を与えたら、
OKをクリックしてユーザーを作成します。
最後に、作成したユーザーに権限を与えるクエリを発行します。
「新しいクエリ」ボタンをクリックします。
以下のクエリを書き込んだら、「実行」ボタンを押します。
|
USE master GO GRANT EXECUTE TO [uipath_sql] GO
USE msdb GO GRANT EXECUTE TO [uipath_sql] GO |
作成したユーザーでログインできることを確認するため、SSMSを終了してから接続しなおします。
終了時にクエリを保存するかどうか尋ねられますが、保存する必要はありません。
以上でSQL Server関連の設定は終わりです。
次回はElasticsearchとKibanaをインストールします。
【次回記事はこちら】
UiPathデータベースの中身が気になる人もいらっしゃると思います。
今回の手順ではデータベースを作成しただけなので、
テーブル一覧を表示させても結果は下図のようになります。
Orchestratorのインストール直後に同じことをすると、以下のような結果が出ます。
58個のテーブルが作成されています。
ときどき中身を確認したくなりそうなテーブルもいくつか作られています。
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導入ステップバイステップガイドを参考にしながら、
以下の順番でインストールしていきます。
１：Windows Serverの設定
２：SQL Serverの設定
３：ElasticsearchとKibanaの設定
４：Orchestratorの設定
今回はWindows Serverの設定をします。
MicrosoftのサイトからWindows Server 2016評価版をダウンロードできます。
まずはOSのインストールやネットワークの設定、Windows Update等を済ませましょう。
準備が終わったら、以下の設定を行っていきます。
１：役割と機能の追加
２：Web Deploy 3.5とURL Rewrite 2.1のインストール
３：自己署名証明書の作成
いずれも、Orchestrator用サーバーに対して行います。
まずは、役割と機能を追加します。
念のため、デフォルトの役割と機能を確認しておきます。
ウィザードをサーバーマネージャーから起動して、役割と機能を追加していきます。
ウィザードが表示されたら、「サーバーの役割の選択」が表示されるまで「次へ」を繰り返します。
「サーバーの役割の選択」が表示されたら、「Webサーバー(IIS)」にチェックを入れます。
たまに、追加しようとしている役割に必要な機能も追加するかどうかを尋ねられるので、
そのときは、追加してあげましょう。
「次へ」をクリックすると、「機能の選択」が表示されます。
ステップバイステップガイド「2.2. 前提条件のコンポーネントのインストール」内の
表に記載されている機能を追加します。
「インストールオプションの確認」に進み、
「必要に応じて対象サーバーを自動的に再起動する」にチェックを入れてから、
インストールをクリックします。
「正常に完了しました」と表示されたら、「閉じる」をクリックして終了します。
役割と機能がちゃんと追加されているか確認します。
問題なさそうです。
次は、Web Deloy 3.5とURL Rewrite 2.1をダウンロードします。
どちらも、x86用ではなくamd64用をダウンロードします。
ダウンロードしたインストーラーを実行します。
Web Deploy 3.5は「標準」セットアップでインストールします。
URL Rewrite 2.1もインストールします。選択する項目が無いので割愛します。
次は、自己署名証明書を作成します。
サーバーマネージャーからIISマネージャーを起動します。
IISマネージャーで、サーバーを選択してから、サーバー証明書をダブルクリックします。
「自己署名入り証明書の作成」をクリックします。
FQDNを入力し、証明書を作成します。
自己署名証明書が作成されたことを確認します。
Orchestrator用サーバーのWindows関連の設定は以上です。
次回は、ElasticsearchとKibanaの設定を行います。
【次回記事はこちら】
UiPath Orchestratorとは直接関係ありませんが、
Windows Serverの設定をするときに手助けになりそうな小ネタを書きます。
おまけ１ コンピューター名の設定方法
コンピューター名の設定方法がわからない方のために。下の画像を参考にしてください。
スタートボタン右クリック→システム→システムの詳細設定→コンピューター名タブ→変更、
とクリックしていくと、コンピューター名の入力欄が表示されます。
新しいコンピューター名を入力してOKボタンを押すと、
再起動を促す表示が出ますので、再起動しましょう。
おまけ２ 役割と機能の一覧
Windowsの役割と機能の一覧をPowerShellで出力する方法です。
Windows ServerのPowerShellで「Get-WindowsFeature」コマンドを実行すると、
役割と機能の一覧を取得できます。
ただし、機能の名前が長いと、省略されてしまいます。
この例ですと、「Active Directoryライトウェイトディレクトリサービス」が省略されています。
省略させずに表示させたい場合は、
「Get-WindowsFeature | Format-Table -Autosize -Wrap」を使用しましょう。
インストールされている機能だけを表示したいときは、
「Get-WindowsFeature | oss | sls \[X」を使用します。
Format-Tableと組み合わせることも可能です。
おまけ２のおまけ
Windows10にはGet-WindowsFeatureコマンドはありませんが、
代わりにGet-WindowsOptionalFeatureコマンドを使用できます。
Windows10で役割と機能の一覧を取得したいときは、
「Get-WindowsOptionalFeature -Online | Format-Table」とすると、見やすくなります。
2018.09.14
弊社のRPA導入の最大の理由は
「事務員の人手不足を解消し、より専門的な知識を必要とする業務に時間を割くこと」です。
人手不足の問題は多くの中小企業が直面していると思います。
弊社の事務員は女性20名ほどで構成されており、仕事内容から3つのグループに分かれています。
産休・育休を積極的に取り入れているため、結婚や出産後も安定して勤めることができる反面、
復職後の席を空けておく必要があるので、安易に新しい社員を採用できないという問題があります。
しかしながら、現場は当然人手不足に陥り、以前よりも残業を強いられることになります。
このような背景の中で、今回、RPAを導入し事務仕事の機械化を進めようというプロジェクトが発足しました。
筆者は、そのプロジェクトチームのメンバーの一人であり、一事務員の立場です。
プロジェクトチームは、3つのグループを束ねるリーダーと
各グループから1名ずつ選出されたメンバーで構成されています。
人手不足はRPAでしか解消されないのか、と問われれば答えはNOです。
弊社でも当初派遣社員の雇用が検討されていました。
説明するまでもないですが、休職者が復職するまでの期間限定で派遣社員を雇い、
事務員の業務の負担を軽減するためです。
比較する際のポイントは下記の2点が挙がりました。
① 費用 ・・・ 経営者サイドで重要な検討事項
② 効果 ・・・ 事務員サイドの要求事項
一つ目の費用については、筆者は一事務員であり具体的な数字は把握していないため割愛しますが、
結論として派遣社員よりもRPAの方が安く済むとのことでした（長期的な目で見た結果かもしれません）。
二つ目の効果については、派遣社員の場合、教育時間を懸念する声が挙がりました。
また、時間を割いて教育したのに関わらず期間限定で辞めてしまうのは非効率であるという意見も挙がりました。
一方、RPAに関しては、最初にシナリオ作成や操作者の教育に時間が必要になりますが、
長く使っていけるという意味では効率的であるという肯定的な意見が多く挙がりました。
こうして、経営側と事務側の意見が一致する形で、弊社ではRPAの導入が決定することになりました。
弊社ではRPAソフトの中でNTT系のWinactorを導入しました。
理由はより感覚的に操作ができるからです。
弊社では、システム担当の社員がRPAの開発に携わるのではなく、
事務員が全て対応するという方法をとりました。
会社によっては情報システム課のような部署がまとめてシナリオ作成をする場合もあれば、
弊社のように現場の社員が作成する場合もあるようです。
事務員は、基本的システム系は弱かったため（筆者も専門知識はない）、
とっつきやすいソフトを選択しました。
下の画像は、Winactorの画面です。
シナリオを作成する画面ですが、ご覧の通りプログラミングのような専門知識は不要で、
必要なパーツが予め用意されています（パーツは表示されている部品は一部です）。
その項目を繋ぎ合わせていくとシナリオが完成するというイメージです。
例えば、エクセルを開いてA２セルの数値をコピーし、A３セルにペーストしたい場合は、
「エクセルを開く」→「A２セルに移動」→「選択中のセルをコピー」
→「A３セルに移動」→「選択中のセルにペースト」
という５つのパーツで表現することができます。
複雑な操作をしたい場合にはパーツを改造する必要が出てきますが、
一般的な事務作業には充分対応できるパーツが揃っています。
上述の通り、プロジェクトは４名で進められましたが、
各チームで仕事内容が異なるため、実際には各々が異なるシナリオ作成を進めることになりました。
弊社は３日間の保証プランに入ったため、
最初の３日間はWinactorの代理人の方にお越しいただきシナリオのベースを作成してもらいました。
（詳しい契約内容は把握しておりませんので割愛します。）
基本的に、Winactorは自分たちでシナリオを作成する（そのためにより感覚的な操作が可能）こと
をコンセプトとして商品を売り出しているため、代理人に作業してもらえる３日間は非常に貴重です。
自分たちでシナリオを作成するためのヒントをどれほどもらえるかが勝負になります。
保証期間に臨む際のポイントは下記の３点です。
① 自動化したい業務のフローを細部まで説明できるようにしておく
② 多くのシナリオに共通する部分を作成してもらう
③ より高度な操作を要するシナリオを作成してもらう
毎日何気なく行っている作業でも、機械にやらせようとすると
一つ一つの作業を順序だてて考える必要が出てきます。（人間がいかに優秀な動物であるかを実感します。）
例えば、Aのときは○をクリックし、Bのときは△をクリックするという簡単な操作も、機械だと次のように認識します。
「Aの場合→true」、「A以外の場合（つまり、ここではB）→false」、
「trueの場合→○をクリック」、「falseの場合→△をクリック」
このように、true/falseの場合分けのような部品が必要になります。
業務フローを細部まで理解しておくことで、代理人に的確な説明をすることができ、
短い保証期間を有効に使うことができます。
また、共通する事務作業の部分を作成してもらうこともおすすめします。
クライアント毎に異なるシステムを使用している場合もあると思いますが、
社内のデータベースの操作等は共通する部分だと思います。
その部分を作成してもらうことで、他のシナリオ作成時にインポートして再利用することができます。
最後に、より複雑なシナリオ作成を依頼することも重要です。
やはり、プロが作成するシナリオと初心者とでは雲泥の差です。
何が違うかというと、運用した際のエラーの数が全然違います。
プロのものは、エラー対策の工程が組まれているためです。
エラーの対策ができるまでにはWinactorの経験が必要となると言えます。
そのため、難関な作業は最初にプロに作成してもらうことが得策です。
実運用から半年以上が経過しましたが、確実に業務負担の軽減が実現しました。
今まで、エクセルに入力し、その情報をクライアントのシステムに入力し、
二つに齟齬がないかダブルチェックをし・・・
と随分無駄なことをしていたと思い知らされる日々です。
現在は、入力箇所が一つとなり、そこから機械が自動で必要な情報をピックアップしてくれます。
弊社では、クライアント毎に異なるシステムやフォーマットを使用しているため、
運用方法を覚えるということも重要な仕事の一つでした。
しかし、現在ではクライアントを意識することなく業務を統一化できています。
作業がより単純になることでミスも大幅に減り、
余った時間をより専門的な知識を要する業務に割くことができています。
残量時間でいうと半分になった人が大半です。
RPA導入により、操作する側の教育は依然として課題が多く残ります。
筆者もなかなか忙しい毎日を過ごしています。
新しいシナリオの作成も必要ですし、運用中のシナリオのエラー対策も欠かせません。
何度やってもエラーがなくならない箇所もあり、素人が操作する限界を感じることもあります。
そこで、RPA教育用の教材や研修の参加を会社から勧められたので受講を検討しているところです。
また、使う側（事務員）の教育も日々進めなければなりません。
事務員は今までとやり方が変わる部分を覚える必要があり、
例えばファイルを格納するフォルダを間違え、機械がファイルを認識しない等、
慣れるまでは人的ミスが発生することがあります。
こうした課題を一つ一つクリアにしていき、安定したRPA運用を実現していくことが、
プロジェクトチーム使命であります。
2018.09.13
RPAツールの提供形態は、大きく分けて「開発型」「オンプレミス型」「クラウド型」の3つに分かれています。
これまで、多くのRPAツールは、オンプレミス型として提供されており、
一部が開発型で提供されていました。
しかし最近では、RPAの機能をクラウドサービスとして提供するクラウド型も増えてきています。
そこで、RPAのクラウド化はどこまで進んでいるのか、
クラウドで提供されるRPAツールにはどのようなものがあるのか、
メリット・デメリットにはなにがあるのか、などを解説していきましょう。
クラウド型RPAの話しをする前に、開発型RPAとオンプレミス型RPAとはどのようなものなのかを説明します。
開発型RPAとは、汎用プログラミング言語とAPIを利用して自動化をしていく形態のことをいいます。
パッケージをそのままインストールしていくのではなく要件定義から設計していきます。
そのため、自社の環境に合わせて柔軟にカスタマイズできますし、
自動化できる業務範囲も広げられるメリットがあります。
一方、高度なプログラミング知識が必要となるほか、ある程度の人員も必要になります。
そのため、導入までの期間が長くなり、コストも高めになるといったデメリットがあります。
この開発型RPAには「ROBOWARE」などのツールが存在します。
オンプレミス型RPAとは、RPAベンダーが用意したパッケージをインストールして使用する形態のツールです。
このタイプは「ルールベース」「マクロ」「スクリプト」など、
ある程度決められたテンプレートをもとに業務の自動化を行っていきます。
そのため、テンプレート型RPAと呼ぶこともあります。
オンプレミス型RPAでは、複雑なプログラミングをする必要がないため、
現場のユーザー自らが業務の自動化を実現できます。
コスト的にも、開発型RPAより安価に導入ができるといったメリットが存在します。
ただし、
テンプレートが提供されている単純作業以外の複雑な作業には対応できない
可能性があるといったデメリットもあります。
また、「どの範囲までRPAを適用できるのか」「どこまでカスタマイズできるか」
といったことはツールに依存することになります。
「UiPath」「WinActor」「BizRobo!」など、
市場に存在する多くのRPAツールは、このオンプレミス型RPAとして提供されています。
クラウド型RPAとは、
インターネット上のサービス（＝クラウドサービス）へとログインして、Webブラウザ上で行える業務を自動化
させるものです。
インターネット上で必要な機能だけを提供しますので、
「SaaS（Software as a Service）型RPA」と呼ばれることもあります。
得意とする業務は、
「Web上のデータ収集やリサーチ、Excel、CSV、Google Spreadsheetsファイルなどへ出力」
「他のクラウドサービスへのデータ入力」
あるいは、その組み合わせになります。
そのため、Web上のデータを取得したり取り扱ったりする定型業務に向いています。
クラウド型RPAのメリットは、クラウド上でサービスが提供されることで
初期導入コストも運用コストも低く抑えられることです。
導入までの期間も短いため、すぐに導入ができるのも特長です。
また、クラウド型RPAで自動化できるのはWebブラウザ上で行う作業ですから、
現場の担当者が日常的に行っている業務をすぐに自動化していくことができます。
担当者レベルでも、導入効果をすぐに感じることができるでしょう。
デスクトップにインストールするタイプのRPAツールの場合、インストールしたパソコン上で動作します。
そのため、ロボットを稼働させている間はパソコンが占有され、他の作業は基本的にできなくなります。
しかしクラウド型RPAの場合、ロボットはクラウド上では稼働していますのでパソコン自体は占有しません。
RPAツールを稼働させていても通常業務を行えるということです。
それだけでなく、サービスからログアウトしたとしても、Webブラウザを閉じたとしても、
さらにパソコンの電源を落としたとしても、
クラウド上で365日24時間ロボットは稼働しているわけです。
したがって、RPAを稼働させるためのパソコンを用意するコストや設置するスペースは必要ありません。
RPAツールをインストールしたパソコンが故障などで使えなくなった場合、
別のパソコンにRPAツールを再度インストールし、環境設定を行う必要があります。
その点、クラウド型RPAなら、インターネットへ接続できる環境さえあれば、
別のパソコンを使うことで作業を継続できます。
（クラウドサービスは全般的に同じだと思いますが）
クラウド型RPAは、端末にサービスが紐付いているのではなく、アカウントにサービスが紐付いています。
そのため、アカウントさえ持っていれば、
異なるパソコンでも、異なる拠点でも、すぐに同じ作業が続けられるわけです。
クラウド型RPAはWebブラウザ上で動作するシステムです。
そのため、他のクラウドサービスを操作したり、Webサイトから情報を取得したりといった、
Web上での作業の自動化が得意領域です。
その反面、パソコン内のファイル閲覧やシステム操作といった
ローカル環境での作業はできませんので、導入にあたって注意は必要です。
クラウド型RPAが登場したのはここ最近のことですが、
“広義のRPA”あるいは“クラウド型RPAのルーツ”
ともいえるWebサービスの連携ツールは数年前から提供されていました。
その代表といえるサービスは、「IFTTT」（イフト）と「Zapier」（ザピア）です。
これらのサービスは、「●●●がされたら、×××をする」というような
「きっかけ」と「行動」のコンビネーションが基本となります。
例えば、
「ツイートしたら、その同じ内容を自動的にEvernoteに保存する」
「●●●（特定の相手）からメールを受信したら、SMSでプッシュ通知する」
というように複数のWebサービスを連携してくれます。
ただ、IFTTTもZapierもインターフェイスが日本語化されていないのはネックです。
日本語化された同種のサービスには、
Yahoo! JAPANの「myThings」、
Microsoftの「Microsoft Flow」
があります。
myThingsは個人ユーザー向けWebサービスとの連携が中心になっていますが、
Microsoft Flowは、Microsoft社製アプリケーション中心に連携できるアプリケーションも増加し、
仕事でも使えるようになってきています。
Webサービス連携ツールと比べ、クラウド型RPAが登場したのはつい最近のとです。
国内で提供されるクラウド型RPAとしては、2017年7月に登場した「BizteX cobit」が初めてとなります。
2018年になってからはBizRobo!を採用したクラウド型RPA「CREO-RPA」や、
BizRobo!をクラウド化したRPAツール「BizRobo! DX Cloud」がサービスをスタートしています。
また、クラウド環境である「AWS」（Amazonウェブサービス）にRPAツール「UiPath Orchestrator」
を導入できるクラウド型RPA導入支援サービス「RPA on AWS」も登場しています。
さらに、2018年9月からは注目に値するクラウド型RPAも登場します。その名は「Robotic Crowd」です。
Robotic Crowdは、UiPathの導入支援やRPAコンサルティングで実績を持つ
株式会社チュートリアルが自社開発したRPAツールです。
クラウド型RPAを前提として開発したツールであるRobotic Crowdは、
ドラッグ・アンド・ドロップで直感的に操作できるほか、テキストベース（YAML）での設定もサポート。
RPA入門者から熟練開発者まで対応しているのが特長です。
また、ディベロッパー向けのコミュニティが提供されているので、
公開されているワークフローを利用したり、わからないことの相談・質問をしたり、
といったことが無料でできるようになっています。
2018年8月まではクローズドβ版として提供されていましたが、
既に大手Web系企業で採用事例もありことから、注目すべきクラウド型RPAといえるでしょう。
クラウド型RPAはWebブラウザ上で動作するシステムです。
そのため、ローカル環境だけで行うファイルの閲覧やシステムの操作などは自動化できません。
当然、基幹システムに入りこんだ作業も不可能です。
そのため、自社の業務内容の棚卸しをしてから導入するかどうか決めることが大事です。
ただ、開発型RPAやオンプレミス型RPAなど、既存RPAツールとの共存も可能ですので、
すでにRPAを導入している企業でもクラウド型RPAを検討する余地はありそうです。
2018.09.12
【前回記事】
これまで、BPOの委託業者と自治体側について述べてきました。
本ブログはRPAに関する情報サイトなので、RPAについて述べていきたいと考えていましたが、
オペレーター側のこともと要望があったため、オペレーター側について述べていきたいと思います。
ネットなどで、「BPO」と検索すると、
Broadcasting Ethics & Program Improvement Organization（放送倫理・番組向上機構）
がヒットし、情報収取するとそちらのBPOの情報がヒットするため、
BPOに関係ない分野の方から『BPOって面倒』とご指摘を受ける場合があります。
BPO関連について検索する際は、【BPO 業務改善】など、単語と組み合わせて検索すると良いでしょう。
そもそもBPOとは、business process outsourcingの頭文字から取っているだけで、
BPO（ビーピーオー）と呼び人もいれば、アウトソーシングと呼ぶ人もいます。
BPOを受託する会社のことをBPO業者とも呼んだり、アウトソーサーなどと呼んだりもします。
業務委託といった方が通用する場合もあります。
中には派遣と勘違いされる方もいますが、派遣と業務委託には大きな壁があり、
実際、働く人にとっては、BPOでも常駐型BPOになると
BPO業者が一切入らない派遣では働き方は大きく異なります。
給与計算代行サービスやNHKの収納代行サービスなどもBPOの一部として以前よりも定着してきましたが、
中々理解を得られないので、経済産業省でもBPOの市場規模が一番大きい
としているコールセンターを例えに説明すると理解を得られやすいかと思います。
BPO業者がBPO業務を分類する際、直接業務や間接業務に分類が一般的ですが、
他にも様々な分類方法があります。
本ブログでは、
フロント業務（受付・窓口）、バックヤード業務（事務）、中間業務（コールセンター・カスタマーセンター）
と分類させていただきます。
確かに営業や研究開発もBPO業務の一種なのですが、雇用形態が正社員をメインとしているため、
BPO関連業務で働くオペレーター目線に立つと、
フロント業務、バックヤード業務（事務）、中間業務（コールセンター）が妥当なところかと思います。
一般的なBPO業務として、コールセンターが代表的なものであるというのは先で述べた通りです。
例えば、コールセンターで想像が付きやすいのは、通販業界の受注センターかと思います。
特にTV通販は電話での受注が多く、TV通販の番組など時間帯に合わせて増員をかけたりする必要があります。
名物社長がよくテレビに出ているような大きな会社はさておき、
中小規模の会社が受注センターを運営しようとするとかなり大変です。
TV通販は扇動的に商品アピールをし、なおかつ購買層が高めなので、
電話注文が多く、コールセンターに頼らなければいけません。
一方、世界的なネット通販の大手などでは、電話での注文を受けることはしません。
その要因としては、注文データのデジタル化までの時間にあります。
電話だと電話を受けたオペレーターが電話で聞いた注文情報を発注システムに登録するまでに10分程度、
短くても登録前のチェックも含めて5分程度かかります。
しかし、ネットだと顧客がデジタル化する作業や確認まで顧客自らがやってくれるため、
通販業者のデジタル化にかかる時間は０分になります。
世界的なネット通販の大手は効率性を重視し、その代わりに安い値段設定をするよう、企業努力をしています。
大企業が本気でやっている効率化というのは見習うべき点も多いと思います。
先ほど述べた世界的な通販サイトだと効率化が図られており、事務系職が極端に少ないと聴いています。
世界的な通販サイトの話は極端すぎますが、中小の通販サイトでも電話での受注を受ける場合、
電話での受注が多ければ受注センターを外部に委託したり、
受注事務があるようであれば、受注事務も合わせてアウトソーシングをしたりしています。
話はそれましたが、
日本のBPO業界というのは特殊なものを除けば、コールセンターを中心として回っていて、
それに付随しバックヤード業務（事務）があるという形態が比較的多いようです。
一方で内閣府から各地方自治体に対し、窓口業務を委託するようにと通達があり、
各地方自治体の担当者はアウトソーシングするにあたり、頭を悩ませているようです。
BPOで働く人達の雇用形態は、パート、派遣、契約、以上の3つの雇用形態に集約されるかと思います。
以前であれば、BPOの雇用形態のメインとなっていたのはパート社員でした。
特に多かったのは育児中の女性でした。
子育てをしているとどうしても時間的な制約があり、
サービス残業も少ない（ないとは言い切れないのが日本の実情です）仕事を探すと、
比較的BPO関連業務になります。
パート社員でも中小企業の直雇用だとサービス残業が多いため、
時間的融通が利く業種や業態を選ぶ傾向があります。
また、配偶者控除が変更され、BPO関連業務に従事する方の中でもフルタイムで働くより、
扶養の範囲内で働きたいという方が以前より増えています。
BPOを運営する事業者にとって、短時間勤務で就労する方をどのように戦力化するかは腕の見せ所となります。
実際、地方自治体BPO関連で応募をかけるとこの数年で応募状況はかなり様変わり
しました。
実際上記添付の資料を見ていただければすぐに分かるかと思いますが、
18歳未満の子供がいる世帯は年間1％ずつ減っています。
追い打ちをかけるように求人倍率がバブル期を超えており、
転職バブルという言葉もあるように求職者と企業のバランスは崩壊しています。
ただし、女性から人気がある事務職の有効求人倍率は0.5以下なので、
事務職に関しては競争率がかなり高いです。
事務系職の少ない地域で事務系の求人を出せば、
応募者が多くてBPO事業者が勘違いし、人が辞めても次に採用すればよいと安直に考えてしまいます。
業務によって数値はかなり異なりますが、BPO関連で働くパート社員1年以内の離職率は3割と言われています。
実際、次のステップに進む人もいれば、職場が嫌になって退職する方もかなりいます。
特に地方自治体BPOだと、BPO業者と自治体の契約が終われば雇用も終わるため、
将来的な雇用状態を考えると退職しやすい環境です。
5．BPO関連で働く人のキャリア
BPO関連で働く人のキャリアモデルとしてコールセンターも事務センターも多くは下記の通りです。
OP（オペレーター）→LD（リーダー）→SSV（サブスーパーバイザー）
→SV（スーパーバイザー）→MGR（マネージャー）
LDかSSVぐらいで契約社員、SVかMGRぐらいで正社員、といった流れでなるのですが、
それはあくまでも民間BPOでかつ長期でセンター運営がなされている場合のみです。
自治体BPOだと委託の契約期間が1年や、中には半年ぐらいもあります。
また数名ぐらいの規模なので、上記のようなキャリアモデルが形成されているとは言い難い状態です。
民間BPOと違い、自治体（市役所内）に入っていることが多く、そのようなキャリアモデルが築くことができません。
怖いSVが圧政を敷いている現場が比較的多いです。
運営能力の低いBPO業者で働くと、すぐにSVになれることはあるかもしれませんが、
基本的にSV教育はほぼないと考えるとよいでしょう。
募集要項などに教育体制が充実していると表現している企業で
本当に教育体制が充実しているところは極稀です。
キャリア形成を考えて、この企業では無理だと判断して辞めるケースが多く、
優秀な人であればあるほど退職までの期間は短くなります。
BPOの目的はあくまでもコストカット目的です。
ノウハウの活用を目的にBPO業者に委託するというのは建前です。
コストカットを目的に委託しているので、教育に費用はかけません。
BPOで教育が充実しているのは、金融業界と生保業界です。
どちらも中途半端な教え方をすると間違った案内や処理をすると後で大問題になるからです。
採用企業もダイバーシティ（多様性）ということで雇用形態を多様化することで、
応募者の掘り起こそうとしていました。
その結果、BPO関連で働く人のメインの雇用形態はパート社員が一時増えました。
最近は地方自治体BPOでも契約社員にするケースが増えましたが、
雇用情勢の変化の波も、遂に地方自治体BPOまで来たかというところだと思います。
最近話題になった2018年問題もあり、有期契約社員（パートや契約）の正社員化が進んでいるようです。
どちらかというと契約社員を採用する企業は、
試用期間という意味合いとキャリアアップ助成金の受給が目的だったりします。
BPO関連でも今後は契約社員から正社員化というキャリアアップが出来るような時代が来るかと思います。
オペレーターで働く人の動向は今後かなりシビアになってきます。
BPO関連業務の市場規模は拡大する一方ですが、その現場で働くオペレーター不足がすでに起こっており、
比較的高収益な専業代行（給与計算代行・経理代行）を除けば、
コールセンターや事務センターなどの人的BPOの運営は過渡期に入ってきています。
次回、RPAについて述べていきたいと思います。
【次回記事】
2018.09.11
今回のコラムでは、RPAを導入した後、運用フェーズを迎える前にどのようなことを
現場の社員に対して教育を行えばよいか、RPA導入プロジェクトの経験から紹介したいと思います。
RPAの運用フェーズを迎えるにあたって考慮すべき点は大きく
「RPA業務全体の運用ルール」、「ヘルプデスク窓口について」、「ID・権限管理のルール」
の3つあります。以下、順番に説明いたします。
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/
RPAで使用するID・Passwordは大きく分けて3つあります。
「RPAツールを使用するためのID・Password」「Windowsアカウント」「社内システムID・Password」です。
まずRPAツールを使用するにあたってユーザ登録を行うと、
RPAツール上でIDとPasswordが発行されます。
これはRPAを初めて使用する際に必要となり、主に新入社員などが申請の対象となるでしょう。
RPAツールによっては、業務担当者のWindowsアカウントと
ロボットの実行端末の紐づけの設定を行う必要があります。
RPAで動かす社内システムのID・Passwordをあらかじめ記憶させることで、
ロボットの起動の都度ID・Passwordを入力するのではなく、自動でID・Passwordを呼び出し、
処理を行うことが可能です。
ここで注意しなければいけないのは、
ある社員が他人の社内ID・Passwordを使ってロボットを起動し、機密情報を得る
等のセキュリティの観点からこのID・権限管理方法について検討する必要があることです。
このあたりの詳しい情報は下記をご参照ください。
＜参考Webサイト＞
KPMG RPA導入に伴う内部統制の整備ポイント～想定されるリスクにどう対応するか？～
https://home.kpmg.com/jp/ja/home/insights/2018/04/rpa-internal-controls.html
Accenture RPAとRPAガバナンス～本格導入に向けてのガバナンス整備の必要性
株式会社イーセクター RPA の盲点 IT ガバナンスの重要性
https://www.esector.co.jp/special/rpa/rpa6.html
いかがでしたでしょうか。
今回はRPAの運用フェーズを迎えるにあたって考慮すべき点といたしまして、
「RPA業務全体の運用ルール」、「ヘルプデスク窓口について」、「ID・権限管理のルール」
の3つを紹介いたしました。
企業の規模や思想等によって運用フェーズで実施する内容は異なりますが、
大きい部分はそれほど変わらないと考えています。
既にRPAを導入し、これから運用を開始される場合はこちらの記事がお役に立てれば幸いです。
2018.09.10
【前回記事】
全国に地方自治体はいくらあるかご存知ですか？
総務省の最新データによると合計で1718（市790町745村183）存在します。
地方自治体の分類で、人口50万人以上の政令指定都市、人口20万人以上の中核市、
人口20万人以上いるが中核市に移行しなかった特例市の３つがあり、
政令指定都市20市、中核市54市、特例市31市、
以上の合計105市が全国的に知名度の高い自治体になっています。
都道府県と市町村の公務員は270万人（都道府県約135万人、市町村135万人）ほどいます。
地方公務員の中には警察や消防を除き、
市役所などに勤務する一般行政に関わる勝因は70万人弱と言われています。
今回のコラムで中心に記述するのは地方自治体に勤務する一般行政職の職員の方です。
発注側でもある地方自治体側では実際どのような問題点があるのかを記述したいと思います。
地方自治体が民間委託をする際に発生する問題の多くは、
短期ジョブローテーションという人事制度が原因だと考えられます。
地方自治体の多くの職員、行政事務という観点では民間人が及びもしない見識がありますが、
人事や広報など特定業務の知識においては民間レベルからすると不足している
と言わざるを得ない職員が多くいます。
それは職員の能力不足が起因しているわけではなく、
地方自治体の人事制度上、必ず発生する問題です。
むしろその短期間で良くそのレベルに達したと驚くこともあります。
地方自治体職員のジョブローテーションは3年ないし５年で異動となります。
私の知る限り、5年よりも3年で異動するケースが多いようです。
3年で異動するジョブローテーションは地方自治体職員が行政事務全般を覚えるためには必要な制度です。
経験を積んだ職員が別の部署に異動し、
その代わりに未経験の職員が新たに入ってくまた一から業務を覚えるということを繰り返す
という制度になっており、入庁し、10年もいれば様々部署を経験することができます。
自治体によって差はありますが、下記の行政組織が人口20万人の中核都市の一般的なモデルとなります。
この行政組織内全てが職員の異動先の対象となります。
「議会事務局」、「総務局」、「企画財政局」、「観光文化スポーツ局」、「市民生活局」、
「福祉保健局」、「こども未来局」、「観光局」、「商業振興局」、「建設局」、「都市整備局」、
「水道局」、「教育委員会」、「選挙管理委員会」、「選挙管理委員会」、「農業委員会」
更にこの局の中でも広報課や人事課などに分かれており、多種多様な部署があります。
例えば、
農業委員会で農地等の政策に関わっていた職員が翌年には秘書課で市長のスケジュール管理をし、
更に4年後には、選挙管理委員会で資料作成をする。
そのようなジョブローテーションが実際に行われています。
そのようなジョブローテーションを行うことで行政事務全般が分かる職員が育成されます。
最近はそのようなゼネラリストではなく、スペシャリスト育成のため、
人事制度を設けている自治体も増えています。
ただし、制度としては機能していないとは聞いていますが。
そのようなジョブローテーションの目的は、
「癒着防止」・「適性の見極め」・「人材育成」
おおよそこの３つの目的に集約されていると言われています。
「癒着防止」については、
東京医科大学の贈賄罪事件でも報道されていたため、ご存知の方もいるかと思いますが、
昔と比べて公務員の収賄起訴件数は減っており、問題ないという風潮になっています。
コンプライアンスなどの整理がなされ、職員も火ないところに煙は立たない、
という風にかなり気を付けているようで、民間の人と飲みに行くのも大変だと言う職員もいます。
民間と比べて、コンプライアンス研修など徹底しているようですが、
公権力をバックに業務を行う地方自治体職員は何かと言動に気を付けなければなりません。
「適性の見極め」については、複数の業務を経験させ、
その中で適性を見極めることは確かに必要ですが、30代以上の職員には異動の必要ないという意見もあります。
地方自治体と同規模の民間企業の場合、総合職で入社し、
入社時に配属された部署を中心に異動となるケースが多く、
どちらが良いのかはその職場の風土によっても変わるかと思います。
3年で異動するジョブローテーションだと上司も異動となりますので、
嫌な上司でも最長3年我慢すれば別になるので、民間と違い、離職率が低めである要因かと考えられます。
「人材育成」については、公文書の作成など様々な業務を経験する必要があると言われてはいます。
公文書の作成などはある程度ノウハウ化出来ており、
ジョブローテーションで習得する必要はないかと考えられます。
ちなみに国の省庁は、地方自治体の局、例えば、「企画財政局」が、国では「財務省」になり、
深度が増しており、専門性が深くなるので、中央と地方で公務員は大きく変わるという意見もあります。
このような目的で短期ジョブローテーションが行われ、
民間委託する際にはマイナスとして作用することが多くなっています。
１.BPO業者の管理
特に問題となるのは、BPO業者の管理面です。
先ほど、記載した通り、職員は知識不足です。またBPO業者のことも詳しくありません。
そのため、BPO業者の管理が不十分な状態に陥ってしまいます。
地方自治体が民間委託をする際、最初に仕様書を作成します。
その仕様書が悪いため、運営管理能力が低いBPO業者でも業務を実施し、
更にBPO業者のやりたい放題にしてしまう結果になることが多々あります。
委託する業務によっても変わりますが、
1人でできる事を4人でやるなど非生産的でも地方自治体側は発注元として、
発注先に何も言わないことがあります。
NHKの集金をやっているBPO業者に聞いたところ、
NHKだと１日60件回るけど、地方自治体で訪問業務をやった場合、1日15件程度で十分だと聞いたこともあります。
特にアウトバウンド系業務の委託でBPO業者は手を抜きます。
そもそもBPOの管理能力が弱い社員が管理して更に手を抜くのでとんでもないことになります。
私自身もそのような現場に入らされることが何度かあり、業務改善で生産性を上げても、
手を抜く体質は変わらないので、人の配置から変える必要があり、業務改革に入るケースが多くなります。
BPO業務では採用も大切な業務であり、問題のある職場は、採用フローにも問題があるため、
業務改革（BPR）は業務全体の見直しが一般的な定義ですが、
BPO業務では採用も大切な業務なので、業務改革の対象となり、見直しを実施します。
もしこのコラムをお読みの地方自治体の委託担当職員の方がいれば、
機会があれば是非どのような面接が行われたかを聞いてみてください。
面接の内容である程度BPO業者のレベルが測ることができます。
BPO業者の面接官によって変わりますが、衝撃的な内容に驚くことになる可能性が高いです。
2.職員側の引継ぎ
地方自治体職員から今まで委託業者が何をやっているのか分からないので
委託業務の「見える化」をして欲しいと要望を受けたことがあります。
なぜこのようなことが生じるかというと委託開始時の担当職員が異動でいなくなり、
引き継ぎがなされていないケースが多いからです。
地方自治体の委託担当職員がそもそもいない場合や
管理職が1名でBPO業者対応をしているところも多くあります。
地方自治体BPOでよく行われる月例報告会に参加する職員が少なければ少ないほど、
BPO業者を野放しにすることになります。
更に毎年異動の時期になると委託担当職員が変更になり、前任者から引継ぎがなされていないことが多く、
どちらかというと地方自治体BPOで手を抜きたいBPO業者にとっては歓迎する状況になります。
基本的に委託担当職員は2名で、異動時期が被らないよう1年目と2年目の職員を組み合わせるなどの工夫が必要です。
地方自治体職員は３年でベテランとなり、4年目にはその部署にはいない。
そしてBPO業者の受託期間は長くなると5年などになり、もはや何を委託しているのかも分からない状態になり、
どちらが発注しているのか分からない状態になるそうです。
今回は発注側である地方自治体について記載しましたが、書けないことも多いのですが、
もう少し発注側が委託のための体制を構築すれば、より良い効果が出ると思います。
前回でお伝えした通り、民間のノウハウでと言って丸投げして、
公にはうまくいっているように謳っていても、実は失敗事例ばかりです。
もし、地方自治体の委託担当者になった場合、
委託検討段階で他の地方自治体への視察を何度もして自分なりの委託モデルを作り、
その上でBPO業者の選定に入るようにするなどした方が良いかと思います。
【次回記事】
2018.09.06
今回のコラムは、前回の内容を受け、主に製薬業界についてのBPR施策の方向性を事例と一緒に挙げていこうと思います。前回コラムについては下記のリンクをご参照ください。
まず概略から入りますが、業務改善、つまりBPRの施策というものは方向性として以下4つのカテゴリーに集約されます。近年話題になっているRPAは、この中の「自動化」の一施策という位置づけになります。本コラムではこの4つのうち最初の２つについて、具体的な取り組みを順次述べていこうと思います。
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（自動化）の領域に焦点を当てて、詳述していきたいと思います。乞うご期待ください。
2018.09.05
昨今実に多くの企業で、業務効率化／スピードアップが喫緊の課題となっていることでしょう。
殊に中小企業においては、業務効率化に向けた施策として基幹システムの改修やワークフローの見直しを検討している企業も多いのではないでしょうか？
ここで早速RPAを用いたソリューションとそのインパクトをご紹介したいところですが、
今回は既存システムの改良およびIT投資の観点からアプローチしてみたいと思います。
大なり小なりもしくは事業内容の違いはあれど、
おそらくどんな企業にもさまざまな主要業務を支える基幹システムが存在しているはずです。
生産管理／販売管理／受発注管理／在庫管理／財務・会計／人事・給与等、
各部門が管轄している基幹システムが存在し、それぞれ独立してシステム構築されていることも多いのではないでしょうか。
そのためインターフェースはもちろん、データベースや入出力の仕様が異なり、
部門間をまたいだデータのやり取りではシステム間の連携に障壁が生じることも。
これは業務の遅滞や部門間コミュニケーションの希薄化・不和を招くこともあるため、
好ましい状態は言えません。（ただし、各部門内でセキュアに管理すべきシステムは例外）
業務効率化を考える上で、こうした基幹システムの実態を把握する必要があります。
最低限上記5つの観点からシステムを評価し、それぞれ役割を明確化⇒懸案事項の洗い出しを行います。
その後具体的な改善策を検討していくことになります。
前段で検討した結果、
各システムが独立しており経営に関する一連の状況をつかみにくい場合は基幹システムの統合を図るケースが存在します。
目まぐるしく変化するビジネスシーンでは、リアルタイムで情報を管理し、
必要に応じて可視化／分析することが求められます。
こういったニーズに対しては、売上状況や債務状況、在庫などの経営関する情報を一元化し、
全体像を可視化するシステムの導入が効果的です。
その際多く用いられるのは、ERP（Enterprise Resources Planning）パッケージです。
企業経営の基礎である資源を適切に分配し有効利用する考え方を基に、
「情報の一元管理」と「業務効率化」を目指すものです。
数あるERPパッケージの中でも、とりわけ多くの企業に導入されている“SAP”は圧倒的なシェアを誇り、
近年では中小企業へも導入が進んでいます。
SAPが他のERPパッケージと比べて優位性を有している点として、
といった面が挙げられる一方、
というデメリットも併せて吟味する必要があります。
とはいえ中小企業向けの比較的安価なプランも登場しており、また他のERPよりも専門エンジニアが多く、
比較的スムーズに導入できるといった面もあるので、一案として検討してみるのもいいでしょう。
以下に挙げられるのが一般的なERP導入までのプロセスです。
特段他のシステム導入時と大枠は変わりませんが、企業活動の根幹を成すシステムを作るため、
より明確にゴールを設定しかつ中長期的なビジネスプランニングの策定に役立つよう、
細部まで吟味する必要があります。
ここでは主要なフェーズについてその内容を提示します。
中長期計画などの経営戦略を参照し、現行システムを分析して課題を抽出することから始めます。
そこから導き出される目的には、「業務プロセスの全面刷新」や「内部統制の実現」等が挙げられることでしょう。
この目的によって、選定すべきERPパッケージや形態（オンプレミスorクラウド）が変わってきますので、
この部分はかなり時間をかけて取り組むべきフェーズです。
この段階で成果として達成しなければならない経営指標もある程度明らかにしておく必要があるでしょう。
目的と範囲によっては、自社で導入可能なケースもありますが、通常はベンダーを活用するケースがほとんど。
適用範囲についての業務分析がある程度済んだ段階で、ベンダーの選定に入ります。
あたり前ですが、パッケージ内容だけで判断せず幅広く提案を受け、
導入目的に沿った製品・形態を選択することが肝要です。
そのため提案依頼書には、このプロジェクトの目的や背景、予算、スケジュール、
現時点での業務分析結果の詳細を記述しておくことでベンダー側もこちらに寄り添いやすく、
実のある提案を受けることができます。
その際デモンストレーションを見せてもらうようにすれば実際のイメージも湧きやすく、判断材料の一つになり得るでしょう。
ERP導入で実行すべき業務とERPの機能を比較して、
現行プロセスから変更を要する業務を特定します（フィット＆ギャップ分析）。
変更を要する部分については「業務をシステムに合わせる」、「基本パッケージにアドオンする」、
あるいは「人力でカバーする」といった対応方法が考えられます。
いずれの場合においても発注側が主体的に進めることで、
細大漏らさず必要要件が実装されるようにすることが重要です。
上記を決定したのち、変更を要さなかった部分と併せて新しい業務プロセスを作成しましょう。
この段階でデータ移行や受入テスト、業務切り替え、運用部門（ユーザー）の教育など、
導入計画をしっかり策定しておきます。
これらはデータ移行に関するコストやリードタイムを把握するために必要であり、
同時に遅滞なくリリースをするためにもこのフェーズで熟考すべきでしょう。
ERPは、納期通りにリリースできただけでは導入を成功したとは言えません。
あらかじめ設定した経営指標が目標値を達成して初めて成功したといえるのです。
そのためこの時点で導入後にモニタリングする経営指標と、目標値を設定しておくのが良いでしょう。
前段で検討した新しい業務プロセスに基づいてERPに必要なパラメータを設定します。
適用する業務分野に必要なデータベースを作成していきます。
ここで改めて運用部門と調整をし、リリース後にデータベースの抜け漏れが無いよう慎重に設定する必要があります。
後々修正できることもありますが、
運用部門と共通理解を持っておくことでリリース後に齟齬が起きないように努めるのが賢明でしょう。
こうすることで度重なる修正や例外処理の発生を最小限に留め、
新システムをいち早く標準化することも可能になります。
パッケージで対応できず、現行プロセスから変更を要する業務のアドオン開発が発生する際もこのフェーズで実行されます。
OSやデータベースシステムなどの基本システム、ソフトウェア等それぞれの単体テストが完了後、
ERP全体の結合テストを実施します。
結合テストでは、個々の機能を果たすためのプログラム部品（プログラムモジュール）を組み合わせて、
データの受け渡しがうまく行われているか、コードの記述様式は揃っているか、
データを授受するタイミングはずれていないか、といった点を確認します。
結合テストで不備が発見された際には、再度コーディングを行います。
結合テストと併せて負荷テストを実施し、業務ピーク時に遅滞なくシステムが動作するか確認し、
問題があればソフトウェアのチューニングやハードウェアの追加等、必要な措置を講じます。
リリースを直前に控え、その準備として必要なタスクは以下です。
これら準備のためのタスクが完了した段階で、リリース基準に達しているか判定を行います。
全体構成はもちろんのこと、設計・運用ポリシーに準拠しているか、
障害対策は想定しうる範囲で手順が確立されているか等あらゆる観点から審査します。
ここで全項目の基準が達成されて初めて、ユーザーへリリースすることが可能になるのです。
設計書・運用マニュアルに従い、システム運用とサービス提供を実施します。
加えて、前述の通り導入成功判定を実施します。
判定タイミングを設定し、経営指標が目標値以上を示せるか確認しましょう。
ERPの安定的な運用までは時間がかかるケースも多いです。
そのためリリース後も引き続きベンダーのサポートが得られる体制を構築しておくと良いでしょう。
ERPは企業活動の要衝を担う非常に「重い」システムです。
いざ導入してみてもうまくドライブしなかったり、かえって業務負担が増えたりするケースもあるようです。
それゆえ導入の企画段階から経営トップや運用部門が参画し、綿密にコミュニケーションをとる必要があります。
トップとは達成すべき指標、期待する導入結果と実現可能性を共有し、
運用部門（現場）とはユーザビリティ向上のためにヒアリングやデモンストレーションを繰り返し行います。
経営指標と現状の業務課題を常に念頭に置き、プロジェクトを進めること。
そしてベンダーに丸投げせず、自社で主体的にマネージすることで、スムーズな導入と明確な導入結果が得られるはずです。
ここまでERPシステムの概要、導入プロセスを述べてきました。
次回は親和性の高いRPAソリューションを組み合わせ、更なる効率化を検討していきましょう。
2018.09.04
有史以来、ヒトはイノベーションによってもたらされた産業構造の変化により、経済発展を遂げてきました。
18世紀後半のイギリスで興った、綿工業での紡績機の発明および蒸気機関によるエネルギーの変革（第1次産業革命）。
次にアメリカ・ドイツを中心とした、軽工業から重工業への転換と電力の産業化（第2次）。
そして「デジタル革命」と呼ばれるコンピュータの登場（第3次）を経て現代へと至ります。
これらに続く4番目の産業時代、それが「第4次産業革命」です。
この起点として、ICT領域でのアップデートが期待されています。
コアとなる技術革新・領域としては以下のものが挙げられます。
工業機械の稼働率から、交通状況、気象情報、個人の健康状況まで様々な情報をデータ化しネットワークでまとめ、
これを解析・利用することで新たな付加価値をつけることが可能になります。
≪関連する技術やサービス≫LPWA通信、データ分析プラットフォーム（可視化・最適化）、BIツール（ビジネスインテリジェンス）
ヒトがコンピュータに対してあらかじめ分析上注目すべき要素を全て与えなくとも、
コンピュータ自らが学習し、一定の判断を行うことを可能にする技術
≪関連する技術やサービス≫RPA、ディープラーニング、バイオメトリクス、機械学習プラットフォーム
これらの技術革新は、現代に山積する多様かつ雑多な課題解決や潜在的ニーズの掘り起こし、
生産性向上や労働の補助・代替に役立てられると見られています。
これからの時代、ヒトに替わって機械間通信（M2M）が中心となり、
様々な用途に応用しうる基幹的な汎用技術である ICT の役割が一層重要になることでしょう。
今日わが国では人口減少、人生100年時代という大きな変化の波が押し寄せており、
働き方を抜本的に改革する必要に迫られています。
人口減少による人手不足が深刻化している中で、労働人口の確保および労働の効率化は急務であり、
企業の大多数を占める中小企業は言わずもがなこれに対応していかなければなりません。
今後大企業はこぞって次世代技術への投資・開発を続け、生産コストの低減とリードタイム短縮を図ります。
対抗するにせよ協業するにせよ、これらの技術革新への一定の理解は必要です。
また、ある程度自社への導入を検討してみるのもよいでしょう。
ここからはそれぞれの技術領域について深掘りしていきます。
IoTは“Internet of Things-モノのインターネット”と称される通り、
様々な「モノ」がインターネットを通じて接続され、モニタリングやコントロールを可能にする通信技術を指します。
近年では、低速度のデータ通信向けに低価格での通信を可能にする「LPWA（Low Power Wide Area）通信」が話題を呼び、
各社サービスの提供や対応モジュールの開発が盛んに行われています。
代表的なLPWA通信規格として「SIGFOX」、「LoRaWAN」、「NB-IoT」等がすでに実用化されており、
なんといってもその通信距離の長さ、低電力性が最大の魅力。
今後これらの通信規格がIoTイノベーションを牽引していくものと思われます。
IoT導入事例や展開サービスとして以下が挙げられます。
高齢者や子どもを対象とし、ウェアラブル端末からの通信でセンサー情報を取得し、
保護者がスマホなどでモニタリングできるサービスです。
ウェアラブル端末から得られる情報は種類により異なりますが、脈拍センサーや温度湿度センサーなどで、
対象者の健康状態をモニタリングしたり、GPSを搭載することで位置情報を取得し居所を特定したりすることも可能です。
超高齢化社会の時代において、孤独死や認知症患者の徘徊を防止する取組みとして各自治体、
介護領域での活用が期待されています。
また、ネット越しに離れた場所の映像を伝えることができるWebカメラを用いて、
直接監視や室内の温湿度変化を検知し、熱中症の予防を促すなどの機能も登場してきました。
電力／ガス／水道メーター等、従来人間が検針していたものも「スマートメーター」の登場によって、
代替されつつあります。
これらのデータは低容量かつ通信頻度も高くないため、上記LPWAの通信規格が最も重宝される事例のひとつです。
製造業で稼働する生産設備の稼働率やメンテナンス状況を監視し、
集積されたデータを基にオペレーションの効率化／最適化を目指します。
生産設備メーカーは、それぞれ自社製生産設備の稼働・生産状況を管理するために独自のソフトウェアを搭載しているものの、
実際の工場は、複数メーカーの生産設備によって構成されているため、機器の一元管理は難しいとされてきました。
異なるメーカー間ではデータ内容や通信プロトコルに互換性はなく、メーカー毎に専用ソフトウェアが必要になるためです。
そこで、それぞれの生産設備に汎用性のある電力計（通信デバイス）を取り付け、
稼働状況をリアルタイムに把握できるようにします。
そうすることで生産設備のデータを一元管理することが可能になり、
設備の予防保全や生産性の向上に活用できるというわけです。
今後ますます浸透していくIoTですが、その性質ゆえ注意しなければならない点も多くあります。
例えばセキュリティリスク。
あらゆるデータが自動的に取得され、ネットワークを通じて繋がるため、
常にハッキングによる不正操作、情報漏洩やプライバシー侵害などのセキュリティリスクを把握しておく必要があります。
またIoTに取り組む際に、しっかりゴールを設定することも重要です。
むやみやたらにIoTを導入するのではなく、「何をしたいのか」、
「IoTを進めることで得られるものは何か、どんなサービスを創出できるか」といった観点からプロジェクトを立ち上げ、
スモールスタートで始めるのが良いとされています。
中小企業には大企業と違ってエンジニアが少なく、社内で考えているだけでは対応が難しいことが多いでしょう。
ある程度自社内のリソースで骨子を作った後は、外部のインテグレーション企業に相談し、
具現化していくのが、一般的なロードマップだといわれています。
収集された大量のデータを効果的に活用するためによく用いられるのがビッグデータ解析ソリューションです。
AI技術を活用したソリューションやBI製品等のプラットフォームが各企業からリリースされ、
データ分析に用いられてきました。
しかし、この手のサービスは自社開発にしろシステム導入にしろ初期投資がかさみ、投資回収リスクが付きまといます。
そこでRPAの導入を検討してみましょう。
収集データの分析を見据えたデータ整理には比較的安価に導入できるRPAでも対応できる場合もあります。
この場合、各デバイスからのデータ整理が主なロボットの役割となり、
膨大なデータの中から任意のデバイス、タイミングのデータを抜き出し分析データの土台を作りだすことができます。
今日の技術ではロボットが高度な判断を下すことはできませんが、簡易的なデータ分析を人間が行う際は、
最も効率的かつ経済的な方法であるといえます。
日々進化を続けるICT領域は、今後わが国全体で積極的に導入／開発が推し進められることでしょう。
この“ブーム”取り残されないために大切なことは、日々アップグレードされる情報に関心を持ち、
それをどう自社で活用していくか思案することです。
きっとその取り組みは、新たな経営課題の発見や新規事業の創出を促す土壌づくりに役立つことでしょう。
2018.09.03
業務の効率化のため、RPAツール「UiPath」を2か月使用いたしました。
UiPathを使用した上での使用感、感想をとりまとめました。
これからUiPathの導入を検討されている、あるいはRPAの導入を希望されている方々にとって、
RPAツール選定の一助になれば幸いです。
まず、RPAツールは使用するに当たりプログラミングの知識が不要といわれていますが、
UiPathもほかのRPAツールと同様、プログラミングの知識がない方でもプログラムを組むことができます。
UiPathの場合、アクティビティと呼ばれる部品を組み合わせることで、プログラムを作成・運用を行うことができます。
このアクティビティという部品ですが、多くの種類があり、
組み合わせることで様々なRPAのプログラムを構築することができます。
また、基本的な操作を覚えさせたい場合、Recordingという機能を使用することで、
指定の場所のクリック作業や、テキストボックス・セルへの入力作業を覚えさせることができます。
エクセルの「マクロの記録」でマクロを作成したことがある人はイメージしやすいかもしれませんが、
「マクロの記録」と同じように、デスクトップ上を選択・入力することで作業を記録させる機能として、
運用することができます。
複雑な処理を行いたい場合、あるいは特殊なアクティビティを使用する際に、
プログラミングの知識が必要になる場面がありますが、
アクティビティを組み合わせるだけで基本的なプログラムを作成できるため、
それぞれのアクティビティの動作を知っておけば業務上における有用なRPAは構築できるようになります。
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台で使用する分にはコストがかからないため、
個人で使用感を確認したうえで導入されることをお勧めします。
UiPathには、以下の学習環境があります。
UiPath アカデミーとは、ビデオによるUiPathの学習教材です。
学習フローとしては、ビデオ学習→確認テストを繰り返す方式で、
各設問の確認テストに合格しないと先に進めないようになっています。
設問は全１４問で、最後に総括としてFinal Testがあります。
Final Testに合格することで、UiPathの基本的な知識を備えたエンジニアになったことの証明が可能です。
（証明書を取るだけでなく、実際に現場での作業や日々の学習を行うことで、よりUiPathを使いこなせるようになります。）
UiPath Communityフォーラムとは、定期的に開催されるユーザー間での勉強会のようなものです。
ユーザー同士の発表や、意見交換を通じてよりよい利用方法を検討するといった意見交換の場にもなっています。
ユーザーガイドは、アクティビティの詳細や活用方法がまとめられています。
また、ナレッジベースは、特定の運用方法に関するサンプルがまとめられています。
いずれもより詳細な運用方法を調べるときに活用できるでしょう。
UiPathは、作業を効率化するためのツールです。
現場で一番活用されているエクセルとの親和性も高いです。
エクセルソフトの中でも、最も利用率が高い、Mircosoft Office Excelとの親和性が高いのも、UiPathの特徴です。
Excel関連のアクティビティだけでも20種類以上（２０１８年７月現在）あり、
ユーザーがエクセル上でも頻繁に使用する作業がアクティビティとして登録されています。
（セルへの代入、シートの移動、マージ等）
また、execute macro というアクティビティがあるのですが、
これはExcelに保存されているマクロおよびVBAをUiPath上で起動させることができます。
現行システムとして、マクロやVBAで運用している場合、既存のシステムを活用して、RPAを導入することができます。
ですが、もしマクロやVBAと合わせて運用する場合は、それぞれの作業範囲をはっきりさせる必要があるため、
開発する前に効率的な運用について検討する必要があります。
UiPathのアクティビティは常に増え続けています。
また、外部ツールとの連携を行うためのアクティビティも日々更新されています。
そのため、今後のアップデート次第では開発・運用がより楽になる方法が見つかるかもしれません。
以上が、Uipathを使用して感じたこととなります。
UiPathの特徴として、やはり導入の敷居がほかのRPAと比べて低く、
あらゆる企業でRPA化を進めやすいということが大きな利点であると思われます。
また、学習環境も備えているため、プログラミング未経験でもとっつきやすいという性質があります。
これらの理由から、UiPathを導入する場合、以下の環境で業務をこなしている環境にUiPathが適していると思われます。
UiPathはプログラミングを学習したことない人から熟練者まで、
幅広い層に向けて開発されたRPAツールであることが窺えます。
またRPAの導入方針にもよりますが、自社で新たにRPAを導入する際のトライアルとしても十分なツールであると思います。
また、大規模開発を行いたい場合でも、UiPath Orchestratorを活用したサーバーからの運用と、
UiPath Robotを使った複数台のPCでの運用を行うこともできます。
実際に、定型業務に多くの人的リソースを割いている会社ほど、
UiPath Orchestratorを介したロボットの導入により、多大な効果を得ることができます。
今後、RPAの導入を検討するうえで、まずRPAに触れていただき、適切なRPA化を進めていくべきであると、私は考えます。
