#BPMSのサブプロセスとしてRPAを考えていく（現在は まとめる段階なので記事は徐々に修正）
#チャット、画像、音声からBPMSを通して動作するまでの流れ
electlon⇒electron(後で修正）
#設計とBPMSとRPAを同時にBPMSの画面内で表示
ばらばらより３つでセットで一元していくと分かり易いとは思う
話しながらその場で繰り返していかないと なかなかエクセルとかだと難しい
#それをそのままGoogleSpreadSheetに反映
簡易的に動作する画面を作成 そこからUIPATHに連携
管理システム自体は業務にあわせたいので１から作成（BPMSのデータベースを元に設定）
検索要件は重要なのでここは柔軟に対応出来るように
#MYSQLとfirabase の連携 MYSQLに登録した内容をFireBaseに送信
MYSQLとFIRABASEを連携して検索は一般的なWebでしてRPAへの動作はfirebase経由で動作させる
DBから各種プログラムが呼べればRPAのDB連携で処理を統一出来る為
DBからプログラムを呼び出せば、RPAのメイン処理をDBの処理に統一出来るため
#Electron でfirebase を取得してRPA（UIPATH)起動
起動情報はカレンダーに追記（googleCalenderなどElectronだとiframe表示が出来ない為）
出来る方法を探す
#構成の変更 レーン追加（BPMは日々考えながら変えていくものなので）
分け方としては今は大枠でこうなるのかなと
BPMS
RPA
GCP
WINDOWS
#管理画面 PHPで作成 （BPMBOXES BPMに関連する箱達という意味にした）
#PROCESSMAKERの検索だと足りない所は作成していく PROCESSMAKERは日本語化完了
#業務フロー（プロセス）は PROCESSMAKERで設定をしていく https://processmaker.com
#RPAはBPMSのサブプロセスとして動作させる（シーケンシャルタスクとして考える）
実行は.NET経由で UIPATHを起動させる
##必要activity
web(REST連携）
database（ODBC連携）
UIPATH 終了後 BPMSのプロセスフローを進める（ルーティング実行）
#GASをESB的に使い APPMAKERをサービスのメインにする
＊）GASはlaravelの構成を元に CLASPでフレームワークを作成(typescript)
BPMSから.NET経由でRPAを実行させる
#実行後 BPMSのケースを進める
BIGQUERYはODBC経由でつなぎ RADツールでシステムを作成して DATASTDIOで分析
機械解析は 都度必要であれば組み込む
#全体は GOOGLE CLOUD PLATFORMで作成
#■必要条件
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を導入など
それらを統合した物で機械解析を適材適所でいれるなど
そうしたら面白いのになと