■サイト内検索:
RPA.biz
RPA Biz > 2019年 > 1月

大手住宅ローン会社がRPA導入 住宅ローン審査の自動化に取り組む 申込書記入項目最大半分減少

2019.01.18

 

 

RPAとはロボットにより業務プロセスを自動化することです。

従来の人力による業務補助に比べ、RPAを活用することで低いコストで業務効率化を実現できます。

 

 

一方、金融機関は正確さを高く求める現場です。

さらに、その一部の業務は定型かつ量が膨大となっているので、標準化がしやすくなっています。

実際に、RPA導入に対するのは非常に適切な現場ですので、その活用効果も期待できます。

 

 

したがって、 最近、金融機関のRPAの導入はよく見られます。

 3大メガバンクはもちろん、各地方銀行も遅れていません。

 

我々はこれまでに多く金融機関の導入事例を紹介しました。以下の記事をご参考にしてください。

 

 

 

ケース1 ゆうちょ銀行、投資信託口座開設業務の効率化にRPAを導入

ゆうちょ銀行、投資信託口座開設業務の効率化にRPAを導入

 

ケース2 京葉銀行、RPA化推進によって営業人員増員

京葉銀行、RPA化推進によって営業人員増員

 

 

 

 

本日は、日本国内最大手住宅ローン業務を行っている専門金融機関アルヒ株式会社のRPA導入事例を紹介したいと思います。

 

アルヒ株式会社は2017年にRPAを住宅ローンの申請業務に導入しました。

従来の住宅ローン審査の申込書と比べ、同時に提出される各確認証明書を記入科目を減らしていました。

 

具体的には、RPAシステムによる各書類のスキャンデータからOCRで直接データを抽出し、内容別に分類して社内の審査システムへ転記・完成していました。

 

 

 

RPAの導入により、アルヒ株式会社は従来の申込書で記入項目の最大半分を減らすことに成功しました。

 

 

今回、アルヒ株式会社以前の導入経験に基づいて、さらなるRPAの活用に進んできます。

 

具体的には、今まで住宅ローンの人力での審査からRPAによる自動判断へ変更しました。

この導入によって、住宅ローンの「簡易事前審査」の時間が、大幅削減しました。

 

 

担当者によると、

「熟練の担当者しかできない業務を経験が浅い担当者でもチェック対応が可能になるほか、チェックの標準化によるオペレーションミスの防止、店舗における人の処理時間を半分に短縮できるといった効果が見込まれる。」とのことで、さらなる業務の効率化を図っています。

 

 

一方、RPA導入で住宅ローン審査を効率化するだけではなく、アヒル株式会社は住宅ローンの進捗プロセスを見える化する「ARUHI navi」も提供し始めました。

 

今後、会社全体は積極的にIT化に進んで、業界トップシェアを目指しています。

 

 

 

 

参考記事:https://headlines.yahoo.co.jp/hl?a=20181227-00000054-impress-sci(リンク切れ)

 

 

 

 

働き方改革の取り組み事例

2019.01.17

 

 

 

 

2019年春に、労働基準法の改定が見込まれていることもあり、社会は働き方改革の必要性に迫られており、企業は自社に具体的な施策を取り入れることが急務となっています。

そこで、今回のブログでは、働き方改革のテーマにフォーカスし、各企業における取り組み事例をご紹介したいと思います。

 

 

 

〇先進企業の取り組み事例

ここからは、実際に働き方改革の取り組みを行っている企業について、経団連が作成した「働き方改革事例集」を元に、

①「長時間労働の是正・休暇取得促進」

②「柔軟な働き方がしやすい環境整備」

③「テクノロジーの活用」

の観点から事例をご紹介したいと思います。

 

 

 

1.長時間労働の是正・休暇取得促進

1-1.フレックスタイム制度

(アシックス)

海外の拠点や取引先とのやり取りに柔軟に対応可能で、労働時間の削減にもつながる柔軟な働き方としてフレックスタイム制度を導入。従来設けていたコアタイムについても撤廃している。単なる適用範囲の拡大ではなく、働きすぎを防止する対策にも取り組んでおり、

①フレックスオフデイ(公休日・年休以外で就労しない特別休暇を1日単位で取得可能とし、清算期間内での時間調整を行う)

②勤務間インターバル制度(前日の勤務終了から翌日の勤務開始まで11時間を確保する)

を設けている。

 

 

(セイコーエプソン)

同社では、フレックスタイムを全社員の9割が利用している。フレックスタイムを活用することで、休暇を取得するまでもない、短時間の用事に対応することができるようになり育児や介護、通院などを理由に業務遂行上、時間的制約がある社員にとっても働きやすい職場環境を整備している。

 

 

1-2.時差出勤

(カゴメ)

本人の希望と上長の承認をベースとして、始業時刻を7時30分から10時までの間で30分刻み(6シフト)で変更できる。一方、選択制時差勤務制度の導入が難しい工場部門は、働きやすさ向上のための取り組みとして時間単位有給休暇制度を導入した。

 

(三井住友銀行)

従来から導入していた時差出勤制度について、これまでは業務都合・介護事由のみで利用を認めていたが、プライベートな事由全般に適用範囲を拡大すべく、20188月~10月まで、約20の部店でのトライアルを実施。

 

 

1-3.スケジューラの徹底活用による仕事の見える化

(カゴメ)

201710月からはスケジューラへの入力ルールを全社で統一した。スケジューラに入力した内容は社内の誰もが見ることができ、各々の繁閑や対応中の業務内容等、仕事の見える化が実現された。この見える化により、部門間での打ち合わせ調整や電話の取次の際の状況確認手間を以前と比べて格段に省くことができている。

 

(コクヨ)

201710月から2か月間、希望部門を対象に時間意識の向上を目的とした「働き方コミュニケーショントライアル」を実施した。この取り組みは、対象者が毎週金曜日に、翌週の残業時間及び出退勤無時間の予定と、業務計画をスケジューラに入力し、チームで共有するというもの。このようにチーム内で業務計画の共有をすることで、管理職はなぜ部下が時間外労働をしているのか一目でわかるようになった。

 

 

1-4.サマータイム/プレミアムフライデーの導入

(アシックス)

グループ全体として海外拠点で働くスタッフが多いことや、退社時間の前倒しによるスポーツを含めたワークライフバランスに資する余暇時間を創出する目的から、サマータイムを導入している(7月~9月に始終業時間を1時間前倒し)。取引先でサマータイムを導入していない企業も多いことから、メールの署名にサマータイム実施中である旨を表記しているほか、グループ製品販売部門では、対応可能な時間帯の理解を求める声掛けを取引先に直接行っているなど、取引先に配慮をもとめる活動も実施している。

 

(アシックス)

サマータイムと同様の目的で、プレミアムフライデーも導入しており、月末最終金曜日は15時に退社することを推奨している。業務の状況で退社することが難しい部署については、退社がしやすい別の曜日に変更して実施するなど、フレキシブルな運用を行っている。

 

 

1-5.サテライトオフィス

(三井住友銀行)

育児と仕事を両立している従業員が多いリテール部門の従業員を対象に、サテライトオフィス制度を設けている。これは所属部店とは異なる自宅や保育所の近隣店舗での勤務を認める制度であり、時間制約のある従業員が移動時間等を効率化できる制度として位置付けている。

 

 

 

2.柔軟な働き方がしやすい環境整備

2-1.「Free Location」制度

(アビームコンサルティング)

20184月から、テレワーク制度「Free Location制度」を導入した。入社時研修期間中や疾病等により就業制限のある社員を除き、原則全社員が利用でき、全国に拠点を持つシェアオフィス事業者が提供するシェアオフィスでの勤務、モバイル勤務もできる。

 

 

2-2.フリーアドレス

(コクヨ)

201710月に品川にオフィスを移転。これまで複数のフロアに分かれていたオフィスを1,500坪の1フロアに集約した。新オフィスでは、部署の垣根を超えたコミュニケーションを活性化する狙いから、部署や打ち合わせスペースを区切る壁を設けず、社員が希望するエリアで働けるフリーアドレスを導入している。また、集中して資料つくり等を行うための作業用ゾーンや、リラックスできるハンモックゾーンのように、ゾーンによってテーマを設けることで、社員は仕事内容に合わせた最適な環境を選べるようになっている。

 

 

2-3.「Happy Sunny Days」制度

(サニーサイドアップ)

月に一度、外出・直帰・在宅ワークを推奨する制度。会社にこもらず外で仕事することでより自由な発想が生まれ、普段なかなか会えない相手とコミュニケーションをとるなど、時間と空間を効率的に、有効に使って業務に取り組むことを目的としている。

 

 

2-4.在宅勤務制度

(ニコン)

集中的かつ効率的な業務遂行によって、生産性向上およびワーク・ライフ・バランスを推進するため、在宅勤務制度の利用を推進している。

 

(三井住友銀行)

2016年から在宅勤務制度を導入し、全従業員の3分の2を占める基幹職約18,000名が対象となっている。20187月~9月まで、制度の浸透を進めるべく「重点推進部署」を設け、頻度高く在宅勤務を活用する前提で、在宅勤務のインフラや同行に根付いた業務プロセスや職場風土等、在宅勤務の浸透に向けた各種課題解決への提言を受け、それらを11つ実行する予定としている。

 

 

 

3.テクノロジーの活用

3-1.RPAの活用

(アビームコンサルティング)

RPAツールの活用により、Webメール、ファイルサーバー、デスクトップ上のExcelなど、アプリケーションをまたいで発生する広範囲業務の自動化が可能となった。

 

(三井住友銀行)

本部業務の生産性向上・業務効率化の観点からRPA2017年度から本格導入している。RPAの導入により、初年度1年間で、約700業務・110万時間分の作業時間を自動化することで、大きな余力を捻出している。具体例として、1日中データの入力・チェック業務を行っていた従業員が、当該業務を自動化したことで、担当業務を俯瞰的・客観的にとらえ、さらなる効率化・高度化や当該業務を管理する立場として業務全体の新緑管理を行うようになったほか、RPAでは代替できない「人ならではの業務」に多くの時間を割くことができるようになった。

 

 

3-2.自律型ロボットの開発による生産性の向上

(清水建設)

同社では、最先端技術を搭載した自律型ロボットが連携するシステム「シミズ・スマート・サイト」を現場に展開し、省人化に挑戦している。シミズ・スマート・サイトは、建物の三次元モデルであるBIMBuilding Information Modeling)とAIを搭載した自律型ロボットが連携し、現場で人と一緒に作業をするというものであり、繰り返し作業をできるだけ軽減して生産性を向上させることを目指している。

 

 

 

 

〇まとめ

いかがでしたでしょうか。今回は働き方改革の先進事例についてご紹介いたしました。今年はますます働き方改革の取り組みは活発になっていくことが想定されます。まずは先進企業の事例を参考に、自社に合う取り組みについてご検討してみてはいかがでしょうか。

 

 

 

<参考Webサイト>

「働き方改革事例集」(経団連)

https://www.keidanren.or.jp/policy/2018/104.pdf

 

 

 

さくら情報システム、「秘書ロボ」「さくっとロボ」をそれぞれリリース

2019.01.16

 

 

さくら情報システム株式会社(代表取締役社長:小西池 透、本社:東京都港区、以下:さくら情報システム)は2019年1月9日に新たに2つのRPAソフトウェアを発表した。

 

今回発表された、ソフトウェアは米UiPathが提供しているRPAソフトウェアである、UiPathを簡単に扱えるようにするためのソフトウェアである。

 

一つ目のソフトウェアは「秘書ロボ」と呼ばれるソフトウェアで、メールを介してロボットに指示を出すことが出来る。

このソフトウェアの利点は、使用するすべてのパソコンに対するライセンスを購入する必要がなくなることである。

 

従来では、使用するごとにライセンスが必要となっていたが、「秘書ロボ」を使用することでメールを介して指示ができるようになるため、ライセンス費用を抑えることができる。

これらは、交通費申請のような不特定多数が使用するような場面で有効的な手段である。

 

 

 

二つ目のソフトウェアは「さくっとロボ」と呼ばれるソフトウェアで、UiPathを簡単に使用できる。

利点としては、Excelを利用して開発・設定を行うことができることである。

 

これにより、開発が容易になることで開発期間が短くなり、導入後のメンテナンスも容易になる。

 

従来では、IDやパスワードのような操作のすべてのをUiPathでおこなってきたが、「さくっとロボ」を使用することにより、一連の作業において簡単な操作はUiPathで設定し、比較的煩雑な計算などはExcelの関数やマクロを使用することができる。

 

また、不具合が発生した場合でも、どこで停止したかどうかを簡単に確認することが出来る。

 

 

 

それぞれのリリース価格はライセンス数に応じての個別見積もりのようだ。

 

 

 

 

参考記事:さくら情報システムがUiPath導入を支援する簡易ロボット設定ツール「さくっとロボ」と自動メール応答ロボット「秘書ロボ」を1月9日から提供開始

 

医療業界におけるBPR機会とRPA活用(製薬業界)<1>

2019.01.15

 

 

今回のコラムでは、医療業界の中でも特に製薬会社における業務改善(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>

 

不動産会社のRPA導入事例

2019.01.11

 

 

今まで紹介したRPA導入事例に、金融機関が大半を占めています。

それは、金融機関の業務には高精度と大量の作業量が要求され、RPAの導入に適するためです。

 

 

しかし、実際には、RPAシステムは、低コストで業務効率化を達成でき、労働力を節約させるために、さまざまな業界の企業に取り組んでいます。

 

今日は、2つ不動産会社の導入事例を紹介したいと思います。

 

 

 

 

ケース1 レオパレス21、業務自動化RPAソリューションを導入 過去73.1%の業務効率化を達成


 

 

昨年83日、レオパレス21は業務の自動化、効率化を目的としたRPA導入の一環として、NECRPAソリューションを本社の8業務に導入することを発表しました。 

 

実際に、レオパレス21は、今まで各部門の各種システムへのデータ入出力、集計など業務に月間1612時間の作業時間がかかりました。

RPA活用による導入済の8業務が73.1%の業務効率化を達成しました。

 

今後は、さらなるの作業自動化を図る、月間1,000時間の作業時間削減を目指します。

 

 

 

 

 

ケース2 アパマンショップ 55店舗にRPAを導入 店舗あたり3.2時間作業時間を短縮


 

 

APAMAN子会社アパマンショップリーシングは、昨年4月10日から業務処理にRPAソリューション「Uipath」を導入すると発表しました。

 

今まで人工入力をしていた不動産情報の11のうち6ステップがRPAシステムで行うようになりました。

その結果、毎日1店舗平均あたり8時間程度かかる仕事を3.2時間の作業時間を短縮することを見込まれます。

40%の業務効率化を達成しました。

 

今後も、フランチャイズ加盟店にもRPAの利用を拡大していく意向です。

 

 

 

 

いかがでしょうか。不動産仲介は非常に競争が激しい業界です。

今のうちに、RPAシステムを活用して業務効率化を果たします。

 

その削減した事務作業時間を使って接客時間などにあて顧客対応力を高め、将来の人手不足に備えるようになるのは生き残るやり方かもしれません。

 

 

 

 

 

参考記事:https://www.leopalace21.co.jp/news/2018/08

     https://www.re-port.net/article/news/0000055031/

 

 

 

 

 

 

 

Web-EDIの受注業務を自動化するRPAソフトがインターコムから販売

2019.01.10

参考記事:インターコム、Web-EDIの受注業務を自動化するRPAソフトを販売

 

 

 

 

株式会社インターコム(本社:東京都台東区、代表取締役会長 CEO:高橋 啓介、以下:インターコム)は2018年12月20日、Web-EDIの受注業務を自動化する「Biware EDI Station Auto Webオプション」を発表した。

 

「Biware EDI Station Auto Webオプション」は様々な業界における企業間取引を手助けするEDIソフトウェア「Biware EDI Station  2」のオプション機能として発表された。

 

 

「Biware EDI Station  2」とは、インターコムが提供するEDI(オンライン電子データ交換)サーバーソフトの一つである。

インターネットEDIプロトコルとレガシーEDIプロトコルを利用することが出来、これらを用いての企業間取引も可能である。

 

これらはEDIプロトコルを用いたEDIであり、このほかにもWeb-EDIを用いたEDIも存在する。

Web-EDIはWEbブラウザを通じて企業ごとに専用のシステムを構築している。

この場合、それぞれのシステムの管理に関する手作業での業務が多くなる。

 

そんな中、今回発表されたオプションはその上記の業務をRPAによって自動化しようとするものである。

 

今回の「Auto Webオプション」は、Web-EDI、すなわち、発注企業がEDI取引のために用意しているWebアプリケーション画面の操作を、RPA(ロボットによる業務自動化)機能によって自動化するソフトである。EDI Station 2とAuto Webオプションを併用することで、通信手順を使ったEDIからWeb-EDIまで、各種の受注業務を自動化できる。

(インターコム、Web-EDIの受注業務を自動化するRPAソフトを販売  IT Leaders)

 

 

ここでの特徴は、取引先ごとのレイアウト変更に影響されない言語解析構造型によるロボット操作が出来ることである。

さらに、セキュリティロックの状態でも処理を実行することが可能である。

 

これらにより従来人間が行っていた業務をミスなく正確に自動化することが可能になるだろう。

 

 

 

 

 

 

 

 

 

 

UiPath OrchestratorのQueue(キュー)とTransaction(トランザクション)について

2019.01.09

 

 

今回は、Orchestrator Queue(キュー)Transaction(トランザクション)のご紹介前に、UiPath Orchestratorの登録方法をご説明します。

 

 

◆体験版なら無料で使える!!Orchestratorの登録方法について

 

① Webサイトに「https://platform.uipath.com/」と入力し検索すると、下の画面が表示されます。

 

日本語に変更したい場合は、“English”の「▼」から“日本語”を選択し、“Become a tenant(テナントを作る)”をクリックして、テナントを作成します。

 

 

 

② この画面でテナントの情報を設定します。

テナント名(任意の名前)、名、姓、メールアドレス、管理者パスワードを入力し、“利用規約に同意します”にチェックを入れて、“テナントを作成”をクリック。

 

※ユーザー名は変更不可のため、“admin”となります。

 

2回目以降、ログイン時に必要な情報は、テナント名、ユーザー名、パスワードです。

 

 

 

③ 作成されたテナントのOrchestratorページで、キューとトランザクションの機能を使うために必要な設定を行いましょう。

 

まず、一番右上にあるアルファベット2つ書かれたアイコンをクリックします。

 

 

 

選択画面が表示されるので、“ユーザー”をクリックしてください。

 

 

 

 ④ 登録したユーザー情報が表示されます。

デフォルトでは、“ロール”に“ロボット”が追加されていないので、“アクティブ”の右側にカーソルを持っていき、“編集”をクリックします。

 

 

⑤ ユーザーの編集画面が表示されるので、“ロール”の“Administrator”をクリックし、“Robot”にチェックを入れて、“更新”をクリック。

 

④と同じ画面で、“ロール”に“Robot”が追加されていることを確認してください。

これでadminユーザーにRobotの機能の権限も付与したことになります。

 

 

 

⑥ ④のページに戻ったら、左上の“ロール”をクリックし、“Robot”の行の右にカーソルを持っていき、“編集”をクリックします。

 

 

⑦ Robotロールの更新画面で、下の図のようにチェックを追加し、“更新”をクリックして、Robotにキューとトランザクションの権限を付与します。

 

 

⑧ 画面左上の“マシン”と表示されているアイコンをクリックして、下の画面に切り替わったら、右上の“+”のアイコンをクリックして、マシンを登録します。

 

 

新たに3つのアイコンが表示されるため、一番左の“標準マシン”というアイコンをクリックして、新規マシンの設定を行います。

 

 

⑨ マシンの名前を設定します。

今回は、自分のPCで動かすため、PCのコンピューター名を設定し、“プロビジョン”をクリック。

また、仮想環境を追加したい場合には、サーバー名を設定します。

 

※コントロールパネルから“システム”で、“コンピュータ名”を参照してください。

 

 

プロビジョンすると、下の画面になります。

 

 

 

➉ 次はOrchestrator上で動かすRobotを設定して、マシンと紐づけます。

画面左上の“ロボット”と表示されているアイコンをクリックします。

 

 

新たに3つのアイコンが表示されるため、一番左の“標準マシン”というアイコンをクリックして、新規ロボットの設定を行います。

 

 

⑪ “マシン”の欄の右の矢印アイコンをクリックして、先ほど登録したマシンを選択します。

 

マシンが複数ある場合は、新規ロボットを動かしたいマシン名を選択してください。

名前:任意のロボット名

ドメイン名\ユーザー名:マシンで設定したマシン名\そのマシンのユーザー名

 

※マシンのユーザー名は、“コマンドプロンプト”を起動して、“set”と入力して表示される“C:\Users\〇〇”の○○の部分の名前です。

 

パスワード:設定したマシンを使用する際に使うパスワード。

タイプ:“Development

 

ここまで設定したら、“作成”をクリック。

 

 

⑫ これで新規作成したロボットが追加出来たので、次は作成したロボットを起動させます。

※ロボットを起動させる前に、UiPath Robotがインストール済みであることを確認してください。(UiPath Robotのインストール方法は別途記載します。)

 

 

⑬ UiPath Robotのアプリケーションを起動させると、2つ目の画像のアイコンが表示されます。

 

 

アイコンを右クリックして、“設定”を選択します。

 

マシン名:Orchestratorの使用するマシン名

 Orchestrator URLhttps://platform.uipath.com/

 

マシンキー:Orchestratorの“マシン”画面で、該当マシンの欄の表示をクリックして、マシンキーをコピーしたものをペースト。

 

 

マシンキーの右のコピーアイコンをクリックして閉じる。

 

 

全て設定したら、“接続”をクリック。

 

 

“ステータス”が“接続中”に変更されたかを確認する。

 

 

⑭ UiPath Orchestratorの“ロボット”画面に移動して、“ステータス”が“利用可”に変更されていれば、マシンとロボットの接続完了です。

また、“マシン”画面では、“インストールされたバージョン”が記載されます。

 

 

⑮ ロボットのグループを設定します。

“ロボットグループ”は、複数のロボットを一つのグループにまとめて、同一処理を実行させることができます。

“ロボット”画面の“ロボットグループ”ページを開き、右上の“追加”アイコンをクリックします。

 

 

 

“ロボットグループ”の名前を設定して、“作成”をクリック。

 

 

作成したグループに、ロボットにチェックを入れて追加し、“更新”をクリックします。

これで、RobotGroop1Robotが追加されました。

 

 

⑯ UiPath Studioで実行したいファイルを開き、

デザイン>パブリッシュ をクリックして、Orchestratorに最新のプロジェクトファイルを送ります。

 

 

⑰ ⑯のプロジェクトが、パブリッシュされると、Orchestratorの“パッケージ”画面にプロジェクトが表示されます。

 

 

“プロセス”画面に移動して、実行したいプロセスを追加します。

 

 

パッケージ名:右の矢印アイコンから先ほど追加したパッケージを選択。

パッケージのバージョン:パッケージ名を選択すると自動でパブリッシュされた最新バージョンが入力されます。

 

 

“作成”をクリックすると、“プロセス”に新しく追加されていることが確認できます。

 

 

 

⑱ これで、自分のPCマシンを使って、ロボットが作成したプロジェクトを処理することが可能になりました。

プロジェクトを実行する際には、“ジョブ”画面の“スタート”アイコンをクリック。

 

 

“プロセス”の右の矢印より、実行したい“プロセス”を選択して、プロセスを実行させるロボットにチェックを入れて、“開始”を選択すると、ロボットが処理を開始します。

 ※ロボットの処理実行の状態は、“ジョブ”画面で確認することができます。

 

 

 

以上で、Orchestrator登録からプロセス実行までの一連の流れが完了になります。

 

 

では続いて、Orchestratorの機能であるキューとトランザクションについてご説明します。

 

 

 

◆Queue(キュー)とTransaction(トランザクション)とは?

“キュー”とは、ひとつまたは複数の箱を収納する場所のことで、“キューアイテム“は、その場所(キュー)に収納されている、値の入った箱のことを呼びます。

 

”トランザクション“とは、キューアイテムの「処理」のことで、Orchestratorのトランザクションページでは、処理を実行したロボットや、現在の状況(ステータス)、指定された優先度などの情報を確認することができます。

 

また、Orchestrator上に収納された“キューアイテム”は、トランザクションが開始されると、“トランザクションアイテム”という呼び方に変わるため注意が必要です。

 

 

 

◆Queue(キュー)のメリットとは?

キューは、あるデータテーブルのデータを、複数のロボットが並行して処理する際に適した機能です。

 

ロボットAが処理したデータを、ロボットBが処理しないために、キューアイテムには“トランザクションステータス“が設けられており、複数のロボットで並行した処理を行うことができます。

 

 

UiPath Studioのアクティビティ “キューアイテムを追加”を実行すると、アイテムは“New(新規)”というステータスになり、トランザクションアイテムとして処理が可能になります。

 

 

その後、追加したアイテムを取得するなどの処理を行うことにより、ステータスは“InProgress(実行中)”となります。

 

 

しかし、アクティビティの “トランザクションアイテムを追加”を実行すると、(キューにアイテムを追加しただけですが)処理を実行しているアイテムが追加されたと認識されるため、トランザクションアイテムの“ステータス”は“InProgress(実行中)”となり、その後そのアイテムへの処理ができなくなってしまいます。

 

そのため、キューにアイテムを追加する際は、“トランザクションアイテムを追加”アクティビティではなく、“キューアイテムを追加”アクティビティを使用してください。

 

 

PC2台(2つのロボット)で並行処理した場合、キュー内にあるトランザクションアイテムごとに順番に処理される。

 

例)PC①→No1のトランザクションアイテム

PC②→No.2のトランザクションアイテム

PC①→No.3のトランザクションアイテム

PC②…

 

 

 

◆まとめ

 

今回は、UiPath Orchestratorを実行するまでの流れと、Orchestratorで使えるキューとトランザクションの概念についてご紹介しました。

 

 

次回は、Orchestratorのキューとトランザクションについて、実践を交えてご紹介していきますので、お楽しみに!!

 

 

 

 

 

RPAサービスACALLが神戸市内の区役所にて本格導入か

2019.01.08

参考記事:来客対応RPAサービスACALL(アコール)の窓口案内向けアプリ「ACALL FRONT」が神戸市東灘区役所に本格導入

 

 

 

 

ACALL株式会社(本社:兵庫県神戸市、代表取締役:長沼斉寿、以下:アコール)は2018年12月から、神戸市東灘区役所にRPAを用いたアプリ「ACALL FRONT(アコールフロント)」を本格導入を開始したと発表した。

 

アプリ「ACALL FRONT」は、アコールが提供する来客対応RPAサービスであり、神戸市東灘区との実証実験を経て開発されたサービスである。

これにより窓口の案内が従来以上にスムーズになる見込みだ。

 

 

従来の区役所では、来庁者を適切な窓口に案内するために、案内係を配置している。

しかし、現状では様々な地域のイベントなどがその時々に存在し、来庁者の問い合わせに対する業務は多岐にわたる。

実際、マニュアルの作成などもおこなっているとはいえ、現実は案内係個人のスキルに頼っている状況であるようだ。

そのため、サービスの均一化やコスト面などからも課題が出ていた。

 

この状況にメスを入れたのが来客対応RPAアプリである「ACALL FRONT(アコールフロント)」である。

「ACALL FRONT」はどの職員が担当した場合でも均一なサービスが提供できるようにマニュアルを日々蓄積し、誰でも検索可能にできるツールとして開発された。

 

実際に実証実験を行うことにより、効果の確認や昨日のブラッシュアップを行うことが可能であったようだ。

実証実験では、職員の案内不可件数は61.7%減少し、1件当たりの平均案内時間は36.9%減少することが可能であった。

 

 

ACALL株式会社については以下に実績などを引用しておく。

 

 ACALL株式会社は、来客対応RPAサービス ACALL(アコール・https://www.acall.jp)を提供しております。ACALLは、アポイントから入館・受付・会議・退館に至る一連の来訪者応対の流れをクラウドで一元化します。それにより、受付業務や入退館管理業務、会議室管理業務における無駄を省いて生産性の向上を図るとともに、来訪者に新しいおもてなし体験を提供することで顧客とのリレーション強化に貢献するソリューションを提供しております。

【ACALL導入実績例】
株式会社三菱東京UFJ銀行様、東急不動産株式会社様、Sansan株式会社様、学校法人近畿大学様、トレンドマイクロ株式会社様、コニカミノルタ株式会社様、株式会社Francfranc様、C Channel株式会社様、スマートニュース株式会社様、freee株式会社様、さくらインターネット株式会社様、他多数

(来客対応RPAサービスACALL(アコール)の窓口案内向けアプリ「ACALL FRONT」が神戸市東灘区役所に本格導入  PRTIMES)

 

 

今後本格導入後、統計的な課題解決がなされていくのかが問題になりそうだ。

また、市民の反応も大事にして開発していくべきだろう。

 

 

 

 

 

 

 

 

【プログラミング初心者向け】「変数」ってなんだろう?

2019.01.07

 

 

開発を進めていく中で、必ず登場する「変数」ってどういうものかご存知でしょうか?

 

おそらくプログラミング未経験の方にとっては聞きなじみのない言葉だと思います。

 

私自身も開発を始めるまでは聞いたことすら無かった言葉でした。

 

 

今回は未経験でIT業界に入った自分が初期の段階でつまずいた「変数」について、UiPathを使いながらご紹介していこうと思います。

 

1.変数とは?

プログラミング言語において、「値を入れておく入れ物」です。

処理の中で

        ・値をいれる

        ・値の取り出し

が行えます。

 

変数に値を格納することを「代入」といいます。

 

 

代入にはある決まりがあります。

それは、変数を作成したとき(変数の宣言)に指定したデータ型に対応したものしか代入できません。

 

 

?データ型とは?

String型⇒文字列

              例:Hello、トマト、花、あいうえお 等

Integer型⇒桁数が大きくない整数

              例:11000 等

double型⇒小数点

              例:3.1420.5891.0 等

boolean型⇒真(True)または偽(False)の真偽値

              例:Ture または、False

など上記のもの以外にもたくさんあります。

 

 

 

実際にUiPathで変数を作成してみましょう。

 

 

 

2. String型の変数

最初に「text」という名前のString型の変数を作成(宣言)します。

 

アクティビティパネルから「シーケンスアクティビティ」をドラッグします。

 

次に「変数」をクリックし、「text」という名前のString型の変数を作成します。

 

 

 

 

先ほど作成したString型の変数 text に「Hello」を代入します。

 

値の代入には、「Assin(代入)アクティビティ」を使用します。

 

文字列は “”(ダブルコーテーション)で囲む決まりなので、右辺値の部分に「“Hello”」と入力します。

 

 

 

 

それでは変数textの中身を実際に確認してみましょう。

メッセージボックスアクティビティに変数名「text」を入力し、実行します。 

 

 

 

 

Hello」と入力されたメッセージボックスが表示されました。

この時点で変数textは「Hello」が代入されていることがわかります。 

 

 

 

すでに「Hello」が代入されている変数 text にさらに「World」を代入したらどうなるでしょう。

 

次は、すでに値を保持している変数に対しての代入について説明していきたいと思います。

 

先ほどは空の変数に値「Hello」を代入したのですが、今度はすでに値が代入されている変数に対して代入を行うとどのような結果になるのか試してみます。

 

先ほどの変数textに「World」を代入し、実行してみましょう。

 

 

 

 

World」と入力されたメッセージボックスが表示されました。

このように、同じ変数に対して新しい値を代入すると、古い値は削除され新しい値のみ保持されることがわかりました。

 

 

 

ここまではプログラミングを行っていく中でよく使用されるString型の変数について、実際にUiPathを使用してご紹介しました。

 

 

次にString型の変数と同じくらい使用する機会が多い、Integer型(数値)の変数についてご紹介したいと思います。

 

 

 

3.Integer型の変数

まず初めに、「2.String型の変数」と同様に、Integer型の変数を作成します。 

 

 

 

 

新しく作成したInteger型の変数 numberに「1」を代入します。

 

先ほど文字列である「Hello」や「World」を代入する際に、“”(ダブルコーテーション)で値を囲んでいましたが、文字列以外の場合は何も囲まずに代入したい数値や真偽値などを右辺値に入力します。

 

今回の場合、代入する値は数値なのでそのまま代入したい「1」を右辺値に入力します。

 

 

 

String型の変数の時と同様に、メッセージボックスに今回作成した変数 number を表示させてみましょう。

 

 

 

 

メッセージボックスに変数名 number を入力したところ、エラー発生してしまいました。

 

「式 numberの処理中にコンパイルエラーが発生しました。Option Strict OnIntegerからStringへの暗黙の型変換はできません。」

 

これは、メッセージボックスがString型(文字列)しか受け付けていないのに、Integer型(数値)の変数 number が設定されてしまったために発生したエラーです。

 

 

String型以外の変数は扱えないの・・・?

 

 

そんなことはありません。

こうした場合は、Integer型の変数を一時的にString型に変換することで解決できます。

 

変数名である「number」の後ろに、「.ToString」と入力してください。

先ほどまでのエラーが解決されました。

 

これはInteger型の変数であるnumberを「ToStringメソッド」を使用して、一時的にString型へ変換したためです。

 

 

String型にしたい変数名.ToString

 

 

それでは実行してみましょう。

 

 

 

変数numberに代入した「1」が表示されました。

 

 

 

 

次に計算式や変数と変数の計算について説明していきたいと思います。 

 

 

 

4.計算結果を求める

変数には「Hello」や「1」などの値だけではなく、計算結果を代入したり、変数同士で計算したりと様々な値を代入できます。

 

イメージてきには、数学で登場した「x」や「y」と同じ意味です。

 

それでは先ほど作成したInteger型の変数numberに計算式「1+1」を代入し、実行してみましょう。

 

 

 

 

1+1の和が変数numberに代入されました。

 

 

 

 

5.変数を使用した計算

4.計算結果を求める」では、数値同士の計算結果をInteger型の変数numberに代入しました。

今回はInteger型の変数同士を計算し、その結果をさらに変数に代入してみましょう。

 

 

新たに計算用のInteger型の変数と、計算結果を代入するためのInteger型の変数を用意します。

 

さらに今回は変数numbernumber2に初期値を設定してみます。

 

初期値とは、変数が宣言されたときにここで設定した値が代入されます。 

 

 

 

 

今回はInteger型の変数answerに「number + 10 」の結果を代入しているので、メッセージボックスに「answer.ToString」と入力し、実行してみましょう。

 

 

 

 

変数numberに「1」が代入されているため、今回の場合は1+10の和である「11」が変数answerに代入されました。 

 

 

 

 

次に変数と変数の計算結果をさらに変数に代入してみようと思います。

変数answerに「number + number2」を代入して、実行してみましょう。

 

 

 

 

変数numberには「1」が、変数number2には「5」が代入されているため、「1+5」の和である「6」が変数answerに代入されました。

 

 

 

先ほど変数answerには「number + 10」の和である「11」代入されていましたが、今回新しく「number + number2」の和「6」が代入されたため、古い値は削除され新しく「6」が代入されていることがわかります。

 

2.String型の変数」でご紹介した、すでに値が代入されている変数に対して代入を行ったときと同様に、Integer型の変数でも同様のことが起こります。

 

 

これは、変数は新しい値を保持するようになっているため、変数の型が何であれ新しく代入された値を保持します。

 

 

 

6.おまけ

画面から入力された文字列に文字列を連結してメッセージを表示するロボットを作成してみましょう。

 

 

アクティビティをパネルより、「シーケンス」をドラッグします。

 

 

「変数」をクリックし、

 

・入力された文字列を格納する、String型の変数 inputText

・表示用の文字列を格納する、String型の変数outputText

を作成します。

 

 

 

 

ユーザーに入力してもらうための「入力ダイアログアクティビティ」をアクティビティパネルからシーケンス内にドラッグしてください。

 

 

 

 

入力ダイアログアクティビティをクリックし、プロパティを開きます。

 

タイトルに「タイトル」、ラベルに「ラベル」、結果にString型の変数「inputText」を入力します。

 

 

 

 

入力ダイアログに入力された値と文字列「が入力されました!」を連結し、表示用のString型変数に代入します。

まず、代入アクティビティをシーケンスにドラッグしてください。

 

 

 

 

・左辺値(代入したい変数名)に、表示用のString型変数outputTextを入力

・右辺値(代入する値)に、inputText(入力した値を格納したString型変数) + “が入力されました! を入力

 

 

 

 

それでは先ほど作成した表示用のString型の変数outputTextをメッセージボックスに設定し、実行してみましょう。

 

 

 

 

入力ダイアログが表示され、任意のメッセージを入力してください。

 

 

 

 

OK」ボタンを押すと、入力した値が表示されます。

 

 

 

このように、「文字列 + 文字列」をString型の変数に代入すると、前後の文字列が連結されることがわかります。

 

 

 

7.おわりに

変数はUiPpathにかぎらず、様々なプログラミング言語において重要な要素だと思うので、しっかり理解して開発を進めていくことが大切だと実際に業務を通して実感しました。

 

また、代入された変数の動きを想像することで、データの流れや処理の流れの理解がスムーズに進められるようになるかと思います。

 

 

これからプログラミングを始める方は変数と代入を理解しておくことをお勧めします。

 

 

 

 

 

WinActor、認定研修制度開始か

2019.01.04

参考記事:RPAツール「WinActor」の認定研修制度を運用開始

 

 

 

NTTアドバンステクノロジ株式会社(本社:神奈川県川崎市、代表取締役社長:木村 丈治、以下NTT-AT)は2019年1月から、NTT-AT認定「WinActor」研修制度の運用を開始すると発表した。

 

この認定研修制度は、各ユーザーがWinActorを業務フローに応じて操作・運用する技術を身に着けることが可能である講習であることをNTT-ATが証明するものであるようだ。

それらは、各代理店等が開催しているWinActorの研修に与えられるものであり、この認定によってWinactorを扱う現場においてのトラブルに対する対応や効率的なRPAの運用が可能な技術者を育成することが可能である事を示す。

 

 

 

ではどのような試験によって研修制度が認定されるのか。

 

認定を得るためには、NTT-ATの提供している「Certification of Winactor(以下CWA)」という試験に合格する必要があるようだ。

 

このCWAは2018年8月から販売代理店向けに提供されているサービスで、理解度に応じて3つの認定を受けることが出来る。

 

以下が3つの認定コースである。

 

1.「Certified」

WinActor、RPAの基礎知識を習得している。

 

2.「Sales Certified」

Winactorの操作を熟知している。

 

3.「Technical Certified」

Winactor導入支援に向けた説明が出来る。

 

 

この中でも、三つ目の「Technical Certified」を取得した者のみがNTT-AT認定の講師として、研修を行える資格が与えられる。

 

上記の「Technical Certified」を取得した者が講師を務めるNTT-ATによって認定された研修についてはWinactor公式ページに今後記載予定であるようだ。

 

 

 

 

 

topへ
© RPA.biz