【デコのDX日記 #5】『Dynamics』＆『Salesforce』連携システム の RFP、作りました！（その２）
こんにちは！もう6月も2週目だというのに晴天続きですね！
そろそろ梅雨入りでしょうか！？
外出するときは晴れて欲しいですけど、雨の音も心が落ち着く感じがしていいですよね！
今回もRFPの中身ご紹介！前回のつづきです！
■目次
●『プロジェクトS』とは
● 業務要件
（↑前回はここまで。）
（↓今回はここから。）
● 業務の流れ
● 全体システム構成
● 機能一覧
● データエンティティモデル
● 機能詳細
● ご提案いただくにあたって
前回と同じく、「デコ：」で始まる文章はデコのひとりごと。RFPには書いてません！笑
RFPの細かい中身にご興味ない方は、小難しい部分は読み飛ばしてデコのひとりごとだけ読んでいただくことをおススメしております～笑
●業務の流れ
デコ：↓この「営業活動」からはじまるフローが、「検収」までつづく。長いので冒頭だけご紹介！
デコ：目指す業務の流れが順番にキレイに見える化され、これだけでもスッキリ。でもここで終わっちゃいけません。実現しないと！
●全体システム構成
デコ：うーん、青枠と紫枠、1つだったらすごくシンプルな気が。。。でも『Salesforce』は残すの必須だから、『Dynamics』ベンダーさん向けRFPだとこうなっちゃいますよね。『Salesforce』と『Dynamics』でまったく同じデータ持ち合うために、システム連携ツールを使ってリアルタイムに同期するって、、、連携部分かなり開発大変そう。。。そして運用入ってからトラブりそう。やな予感しかしないんですけど・・・笑
●機能一覧
１．顧客管理
取引先（法人）とそこに所属する取引先担当者（個人）に関する情報を管理する。営業はSalesforceから、技術はDynamicsから登録・更新するものとし、その内容がお互いに同期されるものとする。（取引先についてはDynamics側でのユーザーによる新規登録は行わない。Salesforce実装済。）
２．案件管理
取引先との取引の単位となる案件を管理する。営業においてSalesforceに見込段階から案件登録され、受注、納品、検収まで管理される。技術ではDynamics上でSalesforceから同期された案件情報を参照・更新できるものとする。（案件についてはDynamics側でのユーザーによる新規登録は行わない。Salesforce実装済。）
３．見積依頼
営業から技術に対して見積依頼を行う。営業はSalesforceの案件レコードに紐付く見積レコードを作成し、そこから依頼操作を行う。データ連携によりDynamics側に見積レコードが作成され、技術に通知がなされる。
・・・
デコ：こんな感じで19の機能について説明。もうこの説明見てると、いやいや連携要りますー？って、改めてなる。。。（＾＾；）
●データエンティティモデル
デコ：なんとなくちょっとマスキング笑
【データエンティティ一覧】
１．取引先
見込顧客および取引顧客の法人に関する情報を管理する。
２．取引先担当者
取引先に所属する担当者個人に関する情報を管理する。
３．案件
取引先との取引の単位となる案件を見込段階から受注、納品までを管理する。
４．見積
各案件において顧客に提示する見積の情報。1案件において複数パターンや、複数分割が想定される。
５．明細(SI)
見積を構成する要素。SIにおいては各作業の単位となり、受注後にはこの単位で稼働を管理する。
・・・
デコ：こんな感じで各エンティティの概要説明。ここはフツーですね（＾＾）/ 連携でも単体でも同じです！
【データCRUD概要】デコ：こっちもなんとなくぼかす。
デコ：連携しなければ役割別のCRUDだけ定義すればいいんですけどね。。。「システム別データ操作」のとこが連携システムならでは。同期の方向も細かく定義しないと。。。このエンティティごとのCRUDだけでもオエって感じですが、実際には各エンティティの項目ごとにCRUDと同期方向を決める必要があります。。。（ーー|||）
●機能詳細
デコ：ここはえげつなく詳細な説明が大量に書かれているので割愛します。あしからず。。。と思いましたが、せっかくなので顧客管理の部分だけご紹介。
顧客管理
■概要：取引先（法人）とそこに所属する取引先担当者（個人）に関する情報を管理する。営業ではSalesforceから、技術ではDynamicsから登録・更新するものとし、その内容がお互いに同期されるものとする。
■詳細要件
・取引先法人の情報を「取引先」エンティティで管理する。Dynamics側ではユーザーが新規登録することはなく、Salesforce側で新規登録されたレコードをデータ連携ツールでのみ新規登録される。レコードの更新については双方向で同期する。
・取引先個人の情報を「取引先担当者」エンティティで管理する。営業のSalesforceおよび技術のDynamicsの両方から登録・更新されるものとし、双方向で同期する。
●ご提案いただくにあたって
【ご提案内容について】
・今回ご提案いただきたい範囲は、本資料内のDynamicsで実現すると記載している部分と、Salesforceとのデータ連携部分になります。これらについてその実現案をご提案ください。
・Dynamicsで実現する部分については、Dynamicsのどのモジュールを利用するかや、PowerAppsやPowerBI等の周辺ソリューションを利用するかどうかについての制限はございませんので、適切と考えられる組み合わせでご提案ください。
・SalesforceとDynamicsとのデータ連携において、既存資産として保有するツールが利用可能ですが、その他に良い案があればご提案に盛り込んでください。
・本資料に記載しております「データエンティティモデル」はあくまでも論理的な構造のため、Dynamicsで利用する物理的なエンティティがこれと同一である必要はございません。より適したデータ構造がございましたら、その内容でご提案ください。
・本資料内で図説しております部分において、図はあくまでも現時点で想定するイメージとなっています。これを忠実に再現していただく必要はなく、Dynamicsの標準のユーザーインターフェースを用いることで同等の機能が実現できるのであればそれで問題ございません。
・その他、記載しております機能要件につきましても、Dynamicsがパッケージとして標準で用意している機能を用いることが適切と考えられる場合には、一部の要件を満たせない部分が発生するとしても、その点に触れていただいた上でご提案に盛り込んでください。
デコ：そうそう、あまりゴリゴリの開発はやらず、できるだけ標準機能でやれたほうがメンテナンス性とか考えるといいんですよね。ただでさえ連携部分が心配ですからねぇ。。。とはいえ、利用者が使いづらくても困るので、そのバランスを取るのが重要になりそうですね。
【スケジュール】
本日：本資料提示
mm月dd日：提案依頼書説明会・質疑応答(各社1時間、時間帯は別途調整)
mm月dd日：提案・プレゼンテーション(各社1時間、時間帯は別途調整)
mm月dd日：選考結果通知
【お問合せ先】
不明点等がございましたら、以下の担当者宛にご連絡ください。
・『プロジェクトS』プロマネ（デコの上司）
・A社さん（神）
ふー、かなり割愛しましたが、RFPの中身はざっくりこんな感じです。・・・めっちゃ疲れたので今日もまた唐揚げとハイボールになりそうです～笑
〜 デコとは？
■著者紹介 ■
DX推進活動をやっているってことと、おでこを出ししているってことからデコという名前になりました。
会社では社内業務改善関連の仕事をやっています。
趣味は唐揚げ＆ハイボール。以前は週2回10キロのランニング＆ウォーキングをしていましたが、最近は外出自粛でランニング回数が減り、唐揚げ側がプラス傾向です（＾＾;）