技術関連記事
SAPとSalesforceのノーコード/ローコードを比較
従来、ソフトウェアは開発者が作るものでした。 彼らはソースコードを書き、それをコンパイルして実行しました。 ソフトウェアを作るための技術やツールは年々変化していますが、基本的な原理や要件は変わりません。 ソフトウェアを書くためには、その背後にあるロジックを理解する必要があり、そのためにはITインフラに関する一般的な知識、基盤となるOSやWebブラウザのノウハウ、関数型やオブジェクト指向のプログラミングモデルの理解、データベースのノウハウなど、多くのことが必要とされました。 そのため、何年もかけて学習し、本当に優れた開発者になるためには、長年の経験が必要だったのです。
その為、数十年前は熟練したITリソース、特に経験豊富なソフトウェア開発者が不足していました。 人材不足で企業の業務改善に役立つアプリケーション作成が進まなかったので、業務に必要なツールをビジネスユーザでも作成できるように、コーディングのないアプリケーションであるノーコードツールが登場しました。 そのようなツールの最初の1つがMicrosoft Accessで、1990年代にコーディングなしでデータベースドリブン型のアプリケーションを作成することができました。
同じ原理で動くのがローコードツールで、90%の作業をノーコードで行い、最小限のコーディングと専門知識だけで特定の機能拡張を追加することができるのです。
2020年代に入ると、大手ソフトウェアベンダーやプラットフォームがこぞって何らかのノーコードツールを提供するようになりました(Microsoft Power Appsなど)。 現在では、様々な小会社がノーコードツール(Neptune、Mendixなど)に特化しています。
このブログでは、SAPとSalesforceを管理するためのノーコード・アプローチを比較し、なぜ一方がうまくいき、他方がうまくいかないのかについて説明します。
SAP Build
SAPはAppGyverを買収し、同社のクラウドサービスを統合しました。 現在はSAP Buildと呼ばれ、SAP Business Technologyプラットフォーム(BTP)上で稼働しています。 SAP Buildは、高いレベルで、このように機能します。
- まず、画面上に空のキャンバスを作り、そこにラベル、ボタン、チェックボックス、テーブルなどのUI要素をドラッグ&ドロップします。
- これらのUIエレメントをデータやイベントにバインドします。
- 画面間のナビゲーションを実装します。
- 新しいフロントエンドアプリケーションのバックエンドをSAP BTP上に作成する場合は、別のステップで行う必要があります。 UIに10個のフィールドがある場合、バックエンドのために2回目のモデリングが必要です(データ型とフィールドの長さが一致している必要があることもお忘れなく!)。
- SAP S/4HANAやECC 6.0などの既存のバックエンドと連携したい場合は、OData、REST、またはSAP Integration Suite(SAP以外のシステム用)を活用することができます。 そのためには、利用できる各サービスをよく理解することが必要です。 ニーズを満たすサービスがなければ、それを開発する必要があります。 残念ながら、BAPIや関数モジュールは直接サポートされていません。
SAP Buildのノーコードツール
SAP Buildは、Neptuneのようなソリューションを含め、SAPの領域で使用される多くの類似ツールの一つです。
Salesforce
Salesforceは、ノーコードに対して根本的に異なるアプローチをしています。 その大きなメリットは、ノーコード/ローコードツールがプラットフォームに裏打ちされ、基幹部分であるということです。 簡単なところでは、このようにアプリケーションを作成できます。
- Salesforceの設定から、アプリケーションが表示すべき新しいビジネスオブジェクトを作成します。
- 新しいオブジェクトに項目を追加し、データ型や長さなどを定義します。
- 実行したいアクションを定義し、他のどのオブジェクトが関連しているのかを定義します。
もうできました。 Salesforceが残りを全て行なってくれるので、ユーザは設計を決定する必要がありません。
データモデル、アクション、ユーザインターフェースをSalesforce一箇所で定義
比較
SAP Buildでは、ユーザインターフェイスの定義に関して柔軟性を残していますが、これは一般的に良い方法ではありません。 SAPには本当に優秀なソフトウェア開発者がたくさん働いていますが、彼らでさえ、まともでユーザフレンドリーなUIを作るのに苦労しています(だからUXデザイナーがいるのです!)。 ソフトウェア開発者がすでに困難に直面しているとしたら、ビジネスユーザが基本的な要件を満たすユーザインターフェイスを作ることは難しいでしょう。 また、SAP Buildのドラッグ&ドロップのアプローチでは、見た目や操作性、動作が異なるアプリケーションが多くなり、エンドユーザがそれらを習得し使用することが非常に難しくなります。
一方、Salesforceにはそのような柔軟性はありません。 何を表示させるか、どんなアクションをさせるかを定義すれば、あとはSalesforceが決めてくれます。 リストビューと詳細ダイアログ(オブジェクトの編集用と新規作成用)が作成してくれます。 確実に日付項目に日付選択機能を付け、数字が右寄せにしてくれます。 また、データの保存方法についても心配する必要はなく、Salesforceのプラットフォームが代わりに行ってくれます。 Salesforceはユーザからうまく責任を取り除いて、すべてのリスト、詳細ページ、作成ページが同じように見えるようにします。 ボタンが常に同じ場所にあるため、ユーザが新しいアプリケーションやプロセスを習得するのが容易になります。
Salesforceのプラットフォームを利用すれば、SAP Buildよりも早く新しいビジネスプロセスやアプリケーションを作成することができます。
まとめ
SAPとSalesforceの社内ソリューションの過程を比較することで、2つのプラットフォームの違いを分かりやすく理解できるかと思います。 SAPのFioriベースのアプリケーション(ABAPスタックの上で動作するか、BTP上で動作するかを問わず)は、開発者がODataサービス、JavaScript、XMLをコーディングするという、古典的な方法で書かれています。 一方、Salesforceは、独自のノーコードツールを使ってソリューションを構築しています。 ここに大きな違いがあります。
私たちの意見になりますが、コードを書く必要がなく、新しいユーザフレンドリーなアプリケーションを作成するには、Salesforceがより良いソリューションだと思います。 SAPの上に新しいUIを作るにしても、Salesforceのプラットフォーム上であれば、より簡単に、より良いものを作ることができます。
Vigience Overcastを使用すると、SAP S/4HANA、SAP ERP、またはSAP BTP上で動作するクラウドベースのソリューションに保存されているデータを簡単に統合し、Salesforce UI内で複製またはリアルタイムに表示することができます。 このようにして、SAPのデータとSalesforceまたはサードパーティ製アプリケーションの情報を組み合わせたスタンドアロンアプリやソリューションを作成することができます。 OvercastはSAP Buildが提供するものを超えており、SAPで利用可能な何千ものBAPIのどれでも簡単に統合できます。
コードを1行も書かずにSAPデータをSalesforcedで表示
Salesforceは今日のビジネス市場において最も重要なシステムであり、その上にカスタム・アプリケーションを構築することは理にかなっています。Salesforceのノーコード・インフラを活用し、Overcastを適用してあらゆるバックエンド・システム、特にSAPと統合することができます。
Vigience OvercastとSalesforceプラットフォームの可能性についてもっとお知りになりたい方は、ぜひ弊社にご連絡いただき、ニュースレターをご購読ください。
著者
Alexander Ilg