BPMS RPA


#BPMSのサブプロセスとしてRPAを考えていく（現在は　まとめる段階なので記事は徐々に修正）
#チャット、画像、音声からBPMSを通して動作するまでの流れ
![キャプチャ.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37985/174d56a8-e3cd-9459-bee8-bcc989c431e6.jpeg)
electlon⇒electron(後で修正）
#設計とBPMSとRPAを同時にBPMSの画面内で表示
ばらばらより３つでセットで一元していくと分かり易いとは思う
話しながらその場で繰り返していかないと　なかなかエクセルとかだと難しい
![1580841744387.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37985/ed952f65-6af5-ba8c-6d73-d921a231db25.jpeg)
#それをそのままGoogleSpreadSheetに反映
簡易的に動作する画面を作成　そこからUIPATHに連携
![1580842018102.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37985/2cb15310-b2ab-0047-404c-022cc8d249fc.jpeg)


管理システム自体は業務にあわせたいので１から作成（BPMSのデータベースを元に設定）
検索要件は重要なのでここは柔軟に対応出来るように

#MYSQLとfirabase の連携 MYSQLに登録した内容をFireBaseに送信
MYSQLとFIRABASEを連携して検索は一般的なWebでしてRPAへの動作はfirebase経由で動作させる
DBから各種プログラムが呼べればRPAのDB連携で処理を統一出来る為
DBからプログラムを呼び出せば、RPAのメイン処理をDBの処理に統一出来るため

![DBからfirebase.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37985/80711389-54d5-ad92-309e-d33035a7cdbe.jpeg)

#Electron でfirebase を取得してRPA（UIPATH)起動
起動情報はカレンダーに追記（googleCalenderなどElectronだとiframe表示が出来ない為）
出来る方法を探す
![electron.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37985/94ca00d5-2144-80b0-290e-b5f28ddf7362.jpeg)


#構成の変更　レーン追加（BPMは日々考えながら変えていくものなので）
分け方としては今は大枠でこうなるのかなと
BPMS
RPA
GCP
WINDOWS
![bpms3.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/0b744df6-6804-9017-6323-1180642c677a.jpeg)
#管理画面　PHPで作成　（BPMBOXES　BPMに関連する箱達という意味にした）
![BPMS1.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/f0fd0e9d-6f91-0376-1fb3-1b90e3187c52.jpeg)
#PROCESSMAKERの検索だと足りない所は作成していく　PROCESSMAKERは日本語化完了
![processmaker.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/b11ea04e-b59b-339c-c92b-5440f94baf70.jpeg)

#業務フロー（プロセス）は　PROCESSMAKERで設定をしていく　https://processmaker.com
![RPA.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/e93a8238-f51a-b867-f46a-4d0649233522.jpeg)
#RPAはBPMSのサブプロセスとして動作させる（シーケンシャルタスクとして考える）
実行は.NET経由で　UIPATHを起動させる
##必要activity
 web(REST連携）
 database（ODBC連携）
UIPATH　終了後　BPMSのプロセスフローを進める（ルーティング実行）
![RPA1.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/13809b05-cd7b-ee9f-3fa8-c149bc9bc1bd.jpeg)

#GASをESB的に使い　APPMAKERをサービスのメインにする
　＊）GASはlaravelの構成を元に　CLASPでフレームワークを作成(typescript)
BPMSから.NET経由でRPAを実行させる
#実行後　BPMSのケースを進める
BIGQUERYはODBC経由でつなぎ　RADツールでシステムを作成して　DATASTDIOで分析
機械解析は　都度必要であれば組み込む
![BPMSGAS.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/a9ca3d86-55bc-62ae-b990-bb9a3de2a035.jpeg)
#全体は　GOOGLE　CLOUD　PLATFORMで作成
![kubernetes.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/8e46ccfa-3b25-d1c0-1b5b-3e2f2446440d.jpeg)


![bpms.JPG](https://qiita-image-store.s3.amazonaws.com/0/37985/f7d12051-c9bc-c9b9-25e8-5d61790da5d9.jpeg)

#■必要条件
REST　OR　SOAP

#■サブプロセスとRPA

サブプロセス（メイン業務の各種　部署業務　のような物）（部分的な業務KGI)
　⇒メインプロセス（会社全体の物　KGI)

RPAをBPMSのバッチ処理（シーケンシャルな自動処理）と思うと
BRMS（ビジネスマネージメントルール）と同じで成り立つと思うが

BRMSは実際目に見えない
　⇒そこにUIPATHを連携する

#■今までの問題
BRMS　ETLはそこまで必要なく　まずみえる物が必要⇒RPA（UIPATH)

　BPMSだけでは実際の効率　結果はみえない
　　それに対してRPAで　BPMSのルーティング部分（自動判定部分）で実際の業務部分を作る事が必要

　⇒ルーティング　業務の変更の査定（フローを分岐する物）
　　＊）BRMSがここに本来はいるが　技術者がつくるのでなく　業務で見えるかがが
　　　　本当はこれが重要だったなと思う

　⇒デシジョンルール（OPENRULES的な物もユーザーよりではない）

■GOOGLE連動
GAS(GOOGLE APPS SCRIPT)をESB的に考えれば　業務の基幹としてよい

■思う事

大事なのは目に見える事で
その後　裏側で自動化が良いかなと

目に見えた後　それに対応する会社　技術は多々あるけど
重要な事は

BPMSが会社の　動く資料だという事だと思う
　⇒エクセルなど動かない資料でなく　実際すぐに　動きを見れる資料として意味もある
　　⇒大事なのは　実際の登録画面など　その場でつくりながら流れを見た方が　よりよい

動かない業務フローより　その場で動く業務フローからの
KPI　KGIを予測して　RPAを導入など

それらを統合した物で機械解析を適材適所でいれるなど

そうしたら面白いのになと