5

まず第一に、私はSAPについて非常に表面的な知識を持っています。私の理解によると、それらは多くの業界固有のソリューションを提供します。コンセプトは非常に興味深いようで、私は銀行業界でも同様のことに取り組んでいます。私たちが直面する最大の課題は、さまざまなクライアントに製品をどのように適応させるかです。多くの概念は企業間で非常に似ていますが、構成とカスタマイズを通じて解決する必要のあるクライアント固有の要件が常にいくつかあります。多くの場合、これには顧客固有の機能の再実装と開発が必要です。

この意味でSAP製品はどれほど効率的だろうか。特定の顧客のニーズを満たすように製品を適合させるには、どのくらいの労力を費やす必要がありますか?使用されるメカニズム(構成、プログラミングなど)は何ですか?これは、カスタムソリューションを最初から開発する場合と比べてどうでしょうか。彼らはベストプラクティスを活用して促進することができますか?

4

2 に答える 2

5

免責事項:私はSAPソフトウェアのABAPベースの部分についてのみ話している。

免責事項2、ref PATRYの応答:HRは、他のSAP/ABAPの世界とはかなり異なります。私は汎用ABAP開発者としてはかなり有能だと感じていますが、HRプログラミングは私の個人的なビーコンから遠く離れているため、そこで何をしているのかを理解しようとさえしませんでした。%-|

私の理解によると、それらは多くの業界固有のソリューションを提供します。

彼らはそうします-しかし、あなた自身のプログラムをこれらの解決策と比較するときは注意してください。たとえば、IS-H(SAP for Healthcare)は、SD(Sales&Distribution)システムの拡張として始まりましたが、それ以来、非常に多くなりました。彼らがISに使用するすべての技術を技術的に使用することはできますが、実際に使用する前に、有能な技術コンサルタントに依頼する必要があります。避けるべき非常に多くの落とし穴があります。

コンセプトは非常に興味深いようで、私は銀行業界でも同様のことに取り組んでいます。

SAP forBankingISはすでに存在していることに注意してください。ドキュメントについては、こちらをご覧ください。

私たちが直面する最大の課題は、さまざまなクライアントに製品をどのように適応させるかです。

「最大の課題は、製品がどこに適応する可能性があるかを知り、適応のために製品を構造的に準備することです」と言い換えたいと思います。適応技術は十分に研究されており、顧客が完璧なソリューションのアイデアから逸脱する可能性が高い場所がわかれば、簡単に採用できます。

特定の顧客のニーズを満たすように製品を適合させるには、どのくらいの労力を費やす必要がありますか?

それは明らかに、顧客のニーズが標準パスから逸脱していることに依存しますが、それは役に立ちません。SAPベースのシステムでは、常に3つの選択肢があります。制限内でシステムをカスタマイズしてみることができます。カスタマイズとは、基本的に、設定を微調整し(構成テーブル、数万の構成テーブルを考えてください)、そうすることを目的とした場所に何か(プログラムフラグメント、フォームなど)を追加することを意味します。テクノロジー-以下を参照してください。

カスタマイズだけでは不十分な場合もあります。さらに開発することもできます。非常に頻繁な要件は、いくつかの追加のレポートツールです。SAPシステムを使用すると、開発環境全体を提供できます。これは、すべての標準アプリケーションで作成されたものとまったく同じツールです。プログラムは標準プログラムと平和的に共存でき、共通のルーチンやデータを使用することもできます。もちろん、あなたは本当に物事を台無しにすることができますが、あなたができない実際のプログラミング環境を私に見せてください。

3番目のオプションは、標準の実装を変更することです。改造は本当に鋭い両刃の包丁のようなものです-他の人が必要とする時間の半分で本当にクールなものを調理できるかもしれませんが、自分が何をしているのかわからない場合は本当にひどく傷つくかもしれません。標準プログラムを実際に変更するつもりがない場合でも、変更が可能であり、コーディングに完全にアクセスできることを知っておくと非常に安心です。

(これはアプリケーションプログラムに関するものであることに注意してください。カーネルを微調整する機会はまったくありませんが、幸いなことに、それが必要になることはめったにありません。)

使用されるメカニズム(構成、プログラミングなど)は何ですか?

構成は主に、多かれ少なかれ洗練されたダイアログアプリケーションを備えた構成テーブルに関するものです。カスタマイズのプログラミング部分については、拡張フレームワークがあります。詳細については、 http://help.sap.com/saphelp_nw70ehp1/helpdata/en/35/f9934257a5c86ae10000000a155106/frameset.htmを参照してください。これは基本的に、依存性注入の制御されたバージョンです。ソリューション開発者は、拡張ポイントを予測し、顧客コードによって実装する必要のあるインターフェイスを定義してから、コードに呼び出しを埋め込む必要があります。プロジェクト開発者は、インターフェイスに準拠する実装を作成してアクティブ化する必要があります。基本的なランタイムシステムは、2つのプログラムを結合する処理を行います。これについて心配する必要はありません。

これは、カスタムソリューションを最初から開発する場合と比べてどうでしょうか。

私見これは、ソリューションのどれだけがすべての顧客にとって同じであり、どれだけのソリューションを適応させる必要があるかによって異なります。あなたが何をしたいのかをもっと知らずに、もっと具体的にするのは本当に難しいです。

于 2010-01-18T19:50:28.440 に答える
1

私は人材の構成要素についてしか話すことができませんが、これは共通のニーズに基づいて、顧客間で多くの違いがある構成要素です。

  • まず、ほとんどの場合、グループの値を設定してから、1つまたは2つの値に応じて、オブジェクト(person、location ...)をグループに関連付けます。これは間接参照に似ており、特定の場所の関連付けを他の場所を変更せずに変更できるため、柔軟性が高くなります。いくつかのケースでは、3レベルの間接参照があります...
  • 第二に、プログラミングに近いカスタマイズがたくさんあります。給与または管理業務は、この一流の例です。後のケースでは、操作(たとえば、雇用)、イベント(作成、変更...)、アクションのコード(Iはテスト、Fは関数を呼び出す、Oは標準操作)を含むテーブルを取得します。関数のパラメータを説明するテキストフィールド(デフォルト値で構造P001を作成するための「CP0001、begda、endda」)。
  • 第3に、このようなテーブルを使用して、動的に呼び出される関数またはクラス(ABAP-OO)を示すこともできます。開発者にこの関数またはクラスを作成してもらい、それを表に示します。これは、機能を別の機能に置き換えたり、拡張したりする方法です。これはESS/MSSで広く使用されています。
  • 最後に、変更できる拡張ポイントまたはファイルもあります。これは、変更を示す必要がないことを除いて、前のものとほぼ同じです。ファイルは常に使用されます(インフォタイプのHR変更の場合はZXPADU01 / 02)


これがギヨーム・パトリーに役立つことを願っています

于 2010-01-18T18:31:27.167 に答える