5

Aria/Zuor​​a などの SaaS 課金プラットフォームとの間で事前構築済みのコネクタを使用するメリットはありますか?それらが純粋な CRM および ERP/会計/財務としてそれぞれ使用される Salesforce と Netsuite の間に存在する場合。つまり、Mulesoft や Boomi などの ESB/統合プラットフォームを使用するのとは対照的です。

現在、請求システムと ERP システムを変更し、Salesforce CRM と統合することを検討しています。したがって、チェーンは次のようになります。

CRM -- 請求ソリューション -- ERP

課金システムの多くには、Netsuite や Fusion などの ERP システムと連携する事前構築済みのコネクタと、Salesforce 用のコネクタがあります。Web サービスのエンドポイント/API は言うまでもありません。

しかし、Mulesoft や Boomi (基本的には Enterprise Service Bus PaaS プロバイダー) などの統合ベンダーもあり、サービス間の統合も可能です。

私は SOA のバックグラウンドを持っており、システムを接続するためにスタンドアロンの ESB を好む傾向がありますが、Saas ERP システムに精通していないため、事前に構築されたコネクタと ESB の議論の利点と落とし穴を理解していません。ポイントツーポイント統合を回避することの背後にある概念を理解しています。これは、ESB を使用する利点になります。しかし、SaaS プラットフォーム内で事前に構築されたコネクタを使用する利点はありますか?また、重大な欠点はありますか (私の主な関心事)。

誰かがここでいくつかの洞察を提供できますか? 私は「どれが最適か」を尋ねているのではなく、誰かがこの種の決定を下すのに役立つ可能性のある実世界での良い経験または悪い経験にすぎません.

4

1 に答える 1

3

あなたが使用を計画しているサービスを包括的に比較することはできませんが、あなたの質問は非常に興味深いので、私の考えと経験を共有し、あなたがそれから恩恵を受けることを願っています.

事前構築されたコネクタは新しいものではなく、SaaS や iPaaS が登場するずっと前から存在していました。したがって、それらの長所と短所は同じです。主な問題は、直面する柔軟性の欠如と、もちろん、ポイントツーポイント統合の欠点に非常に関連しています。SaaS/iPaaS のプリズムを介して物事は多少屈折しますが、ほとんどの側面は依然として関連していると思います。

事前構築されたコネクタの機能とサポート

事前構築されたコネクタが 2 つのシステム間の統合を実際にどの程度カバーしているかを評価する必要があります。salesforce のようなサービスは、サードパーティの拡張機能を使用することによるカスタマイズ性と拡張性に誇りを持っています。ほとんどの場合、コネクタは、すべての統合ニーズの中で最も一般的で単純なもののみを満たす万能型のアプローチに従います。何かを変えなければならないまで、それはすべて楽しくゲームです。将来何が必要になるかを事前に知ることはできませんが、それについて考えてみてください。統合することにした場合に備えて、カスタマイズと拡張機能を事前に構築されたコネクタでカバーできると期待できますか?

考慮しなければならないもう 1 つのポイントはサポートです。これらの企業の 1 つが、既に使用している事前構築済みのコネクタを介した将来の統合のサポートを停止すると突然発表した場合はどうなりますか? 保証があるかどうかを確認する必要があります。

密結合とサービス プロバイダー ロックイン

ポイント ツー ポイント コネクタを使用すると、システムが相互に結合されるため、ある時点で必要になった場合にプラットフォームを切り替えるオプションが大幅に制限されます。今はかなり単純な統合シナリオのように思えるかもしれませんが、時間の経過とともにシステムをミックスに追加すると、一般的に事態はさらに悪化します。すでに使用している他のすべてのものと簡単に統合できます。ミドルウェアを使用すると、必要に応じてデータをマッピングおよび変換する貴重な機能が得られます。また、ビジネス ロジックを適用して、作業がはるかに簡単 (かつ安価) になることもあります。また、システムに応じて他のシステムを交換することなく、システムを交換することができます。

シナリオを考えてみましょう。請求システムを変更する場合は、CRM プロバイダーと ERP プロバイダーの両方で適切にサポートされているシステムを見つける必要があります。したがって、これらの 3 つがニーズに合わなくなったり、統合できれば大きな競争上の優位性をもたらすものが市場に出回っていたとしても、これら 3 つをそのまま使用することに縛られたままになる可能性があります。

オーケストレーションと将来の投資

p-2-p シナリオに関する重要な注意点は、必要に応じてすべてのシステムにまたがるプロセス サービスを実装できないことです。単純な形式のオーケストレーション (フル機能のビジネス プロセス管理で達成できることについて話しているわけではありません) を使用することによる追加の柔軟性と利点は、ビジネスにとって手の届かないものになります。市場が変化し、市場投入までの時間が決定的な要因になると、準備ができていない可能性があります。

iPaaSを選んだ理由

長い目で見れば、iPaaS プラットフォームを使用する方がはるかに優れているように見えます。それでも、プラットフォームが一連の事前定義されたコネクタとドラッグ アンド ドロップ機能を提供するだけでなく (それらはすべてそうです)、業界標準をサポートしながら独自の統合をゼロから簡単に実装する機能も備えていることを確認する必要があります。クラウドであろうとオンプレミスであろうと、ESB ソリューションについて語るとき、この種の柔軟性を持つことは絶対に重要だと思います。

iPaaS アプローチの潜在的な短所は次のとおりです。

  • さらに別のサービスプロバイダーに依存するようになり、サービスが無料ではないため、より多くの費用がかかります。
  • データは別のサービス プロバイダーに移動するため、サービス プロバイダーが何を伝えようとしても、セキュリティの面で追加のリスクがあります。
  • 設計と実装に費やされる先行投資の増加。
  • 新しいバージョンが出た場合、統合を維持し、潜在的な変更に対応する必要があることに関連する追加の負担 (ただし、それらはまれかもしれません)。

結論

それはすべて、望ましい柔軟性と、進んで行う投資との間のトレードオフです。あなたの決定は、純粋に技術的な側面ではなく、ビジネスの現在の状態と今後の成長の期待に大きく依存します.

私の考えがあなたに何らかの視点を与えてくれたことを願っています。時が来たら、あなたの決定と理由で質問を更新してください. 幸運を！

于 2015-04-22T19:52:38.177 に答える