ここにかかれている情報は
ちゃんとチェックしているわけではないので
誤りがあるかもしれません。
もし誤りを発見された方は
コメント欄にご指摘いただけると
私もほかの参照されている方も
うれしいとおもいますので、
よろしくです。
Salesforceの無料トライアルへ登録して
カスタマイズを一切しない状態での
Salesforce CRMを調べ始めた。
こういう業務アプリ系は
組織構造やユーザとの関係を把握しておかないと
ビジビリティとかアクセス権とかでやっかいなので
まずそこだけのぞいてみた。
Salesforceではテーブルに相当するものを
オブジェクトとよんでいるようで、
このオブジェクトの関係を把握してみようと
クラス図もどきを書いてみた。
Salesforce契約すると
組織という単一唯一のインスタンスができるようだ。
休日、営業時間、会計年度が紐づいているかは
正確に設定画面からはわからなかったけど、
おそらく規定関係があるのだと思う。
ユーザはメールアドレスが必須だけれど、
ユーザアカウントにもアドレスを使う。
ユーザアカウントは全世界で１つの
Salesforce CRMというシステムインスタンスへ
ログインするので、
世界で単一である必要がある。
便宜上一人の人が複数アカウントを
持てるようにユーザアカウントには
・メールアドレス形式であること
・異なるアカウントで同一のメールアドレスでもよいこと
となるようだ。
chatter使いなら
メールアドレスの先頭に
chatter-をつけるなどすればよいらしい。
でも無料お試し登録時に
そんなことはわからないから
会社のアドレスで登録してしまった..
ちょっと気になる..
Chatterでつかっている「グループ」と
「公開グループ」というやつは異なるようだ。
公開グループはいわゆるPartyオブジェクトなのだとおもう。
１名以上複数名をあらわすオブジェクト
というやつだ。
ロールは組織名をそのまま使うことが前提っぽいが
組織名をユーザオブジェクトの属性として
別途文字列で持っていて、
これがロールとは別に書き込めるようになっている。
とすると、組織改編の激しい会社などでは
ロールを会社内の役割として使えるようにしているのだろう。
組織は
無料登録した時の組織名がそのまま入っていた。
ディビジョンも属性にあるから..
会社＝Salesforceの組織、にしないで
会社の１組織＝Salesforceの組織、にもできるような
配慮かな。
Onyxのように部署単位でSFAを入れることが多い
業務アプリもあるからだとおもう。
キュー..というのはアプリ側のビューからは
見えていなかったので使い方はわからない。
MLなどの同報通信を表しているのかな..
やはりSiebelとくらべて、
（..といっても2000(Ver6)の知識だけど..）
オブジェクトの数がSalesforceのほうがシンプルだ。
Siebelの組織なんか
完全なCompositeパターンで構成されているから
どんな組織でもアプリ上で実現できたけど、
Salesforceはそれよりはフラットな構造をしているので
拡張性は多少無視してシンプルさをとったって感じか。
Siebelは、システムの設計上
なんでもかんでもできまっせ、を実現するために
ほぼすべてのエンティティを事前に定義していた。
カスタマイズ担当者にはよけいなエンティティを
作らせない、
カスタマイズする奴はみんな悪さをるという性悪説ベース
の設計なのだろう。
今になって考えると、
あの時代のERPも似たような思想なので
対抗させるにはそういった設計を採用したのかもしれない。
だから複雑になりすぎて
使いこなせるカスタマイズ担当者、ユーザがいなかったのだとおもう。
Salesforceはシンプルな構造のみを提供して、
必要があればユーザがオブジェクトを新たに作ったりできる
ようにしたのか。
PaaS環境提供も想定されていたのだとおもうので
オブジェクトをユーザに自由に作らせないと対応できないし。
Siebel勉強してた時はいやいやでしょうがなかったけど、
同一業務の複数のアプリケーションを知る機会ができて
いまはラッキーだったなと
ちょっと思った。
0 件のコメント:
コメントを投稿