おてんば父さんの冒険

とあるITエンジニアが子育てをしながらおてんばな日々を綴るブログです

MENU

19. SAPを外から眺めて思うこと

この記事は SAP Advent Calendar 2023 の12月13日分の記事として執筆しています。

 

こんばんは、「Advent Calendar 2023向けの記事です」と、2024年の元旦に書いているのはもうだいぶNGな気がしますが、そこは懐の深いChillSAPの皆さんなのできっと許していただけるだろうと信じております。(本当にごめんなさい)

 

後段の「Introduction」にも書きますが、SAPの導入や運用プロジェクトの中心から離れた2023年、自社製品・サービスのコンサルティングやカスタマサポートに日々走りまわっています。SAPコンサル業務からは離れた一方で、引き続きS/4HANAやSAP HANAといった製品・サービスと深くかかわる機会も多く、あらためて「SAPを外から眺めて思うこと」について徒然なるままに書きつくってみようと思います。

「あ、そんなSAPとのかかわり方もあるんだな」とSAPというビジネス領域の広さを感じてもらえると嬉しいです。

 

Introduction

私は日系SIerにて2007~2009年、2016~2022年の頃にSAP Basisコンサルとしてアップグレードや新規導入PJTに参画させてもらってきました。直近ではS/4HANAの新規導入やグローバルロールイン、SAP ERP→S/4HANAのアップグレードサービスのアセット化など、様々なプロジェクトを経験できました。

今年(2023年)8月に企業財務パフォーマンスマネジメント(CPM/EPM)ソフトウェアベンダに転職し、現在はテクニカルコンサルタント兼カスタマサポートとしてユーザ、パートナ企業の製品導入や運用をサポートさせていただいています。

弊社製品をほんの少しだけ宣伝させていただくと、「CCH Tagetik」はSAP HANAでの動作がサポートされており、弊社自身もSAPのパートナ企業、かつユーザ企業です。

CPM/EPMというサービスドメインから、ソースデータとしてお客様の既存のSAPシステムからTagetikへデータ連携することが多く、SAPとのデータインタフェースも複数準備されています。

 

Technology

唐突に技術的な、しかも今更感のある提言になってしまい恐縮ですが、「やっぱりS/4HANAに早いとこ乗り換えた方が良いですよ」と最近つとに感じます。ここでは外部システムとのデータ連携の観点でその理由を書きます。

 

SAPのデータを外部システムに連携する時に、S/4HANAにバージョンアップしていないことが原因で、余計な追加費用がかかってしまうことがあります。

もう少し具体的に話す前に、SAPと外部システムとの接続方法を簡単におさらいしておくと、大きく2つに分類できます。

  1. S/4HANAの標準インタフェースを利用する
    (e.g. OData API、Extractor、Business Contents、Smart Data Access、Smart Data Integration(ABAP Adapter))
  2. SAP HANAのデータを直接取得/参照する
    (e.g. 3rd party ETLからのJDBC接続、Smart Data Integration(HANA Adapter))

1.の場合、接続ツールや連携先のシステムが、旧来のSAP ERPのデータ出力技術に対応していない場合があります。その場合、データ連携用途のためだけの目的で既存の連携先を残し使い続けたり、そのデータだけのために個別の仕組みを開発したり、アーキテクチャがいびつになり運用が非効率になる可能性があります。

例えば、SAP ERPSAPIといった旧来の技術を利用してSAP BWにデータ連携している場合、SAP BWを別のDWHや製品に置き換えようとする時にはデータソース側のアプリケーションに大きな回収を加えたり、中間のETLツールで既存のインタフェースを受けられるようなアプリケーションを開発したりといった追加コストが発生することになります。

一方、2.のHANAから直接データを抽出する場合、そもそもHANAでないと利用できない連携方式、ツールがあります。また、そもそも旧来のAnyDB(Oracle、SQLSever、DB2等)の場合、SAPのライセンス制約として、直接DB参照はできません。


今後、DWHやデータ分析基盤等の別のサービスと連携させたい、という需要や機会は増えると思わます。その時、新しい技術やサービスがSAPのデータを利用できるよう、SAP側もやはり最新化(≒S/4HANA化)しておくということは大事なのだとあらためて実感した次第です。

 

Support Service

自分自身が自社製品のカスタマサポートを担当していることもあり、あらためてSAPのSupport Serviceはすごいなと感じる日々です。何かと批判を受けがちな印象のあるSAPのサポートですが、ここ数年の改善、機能拡張は素晴らしいと感じます。

今更外様の私が紹介するまでもありませんが、今一度「ここがすごいよ、SAPのサポート対応」を紹介してみます。

 

Case(サポートチケット)のタイトルを入力すると、入力したキーワードで自動的にSAP Noteが検索される

自動的に検索されたSAP NoteやBlog記事を試しに読んでみたら、意外とそこでほしかった情報が見つかることもあります。(とはいえ直接回答がほしいのだと言ってスルーしてしまうことも多々あるのは内緒です)


Expert Chat大好き

Case起票する以外に、Expert Chatというチャット形式での問合せもとても便利ですね。Caseよりも即座に回答をもらえたり、自分の質問が多少曖昧でも会話の中で修正して、より的確な回答を得られたりする場合もあり、また、SAP技術者としてはSAPのプロフェッショナルと直接会話できる機会というのは結構キュンキュンきます。(日本の日中時間帯はなかなかExpertが捕まらないことでイライラすることもありますがそこはぐっと我慢しましょう)

 

Caseの質問が技術的に詳細であればあるほど、回答から熱を感じられる

もうサポートの本来の用途や目的から離れていることは気にせず続けますが、Caseの回答者はもちろんSAPのディープな技術者の場合が多いため、1回目にもらった回答に対して「それってこういう理解で良い?」、「確かにそれは理解できるけれど、こういうケースでも同様に考えて良いの?」、など追加質問をしてみると、(スルーされて期待していた回答をもらえない場合もあるけれど)場合によっては参照先のNoteのリンクを交えながら非常に事細かに解説してくれたり、「そんな見方もあるのだね、ありがとう」と感謝されたりもします。


数年前に比べてCaseでのレスポンスは確実に速くなったし、日本語での回答もわかりやすくなったし、本来はNGな技術的な質問に対してもわりと快く回答してくれる場合も増えたなという印象もあります。1点だけ他社製品のサポート担当者からもお願いですが、皆さん起票したCaseが解決したら、きちんとCloseしましょう。

 

Community

比較サンプルが弊社製品なので一般論からはだいぶ離れているかもしれませんが、ユーザ企業側のエンジニアやコンサルタントたちが技術の習熟や交流を目的として自分たちで自主的にイベントを企画したり、SNS上で疑問点を質問すると回答してくれたり、本当に素晴らしいプラットフォームだなあと感動します。

このような有機的な、今風に言うと「Ecosystem」が備わっているIT製品・サービスは稀だと思いますし、弊社製品もいつかこのようなステージに辿り着きたいと夢見て頑張りたいところです。

参考:

Chill SAP(Facebookグループ)

SAP Inside Track Tokyo

 

まとめ

途中からただのSAPとChill SAPのヨイショな記事になってしまった感もありますが、何はともあれSAPのど真ん中から離れてみて、SAPの製品・サービスの柔軟性や多様性、広範なSAPビジネスドメイン、そしてベンダやパートナ、ユーザとを相互に繋ぐ活発なコミュニティ活動、などなどに対して「成熟している」と感じることが多くなりました。

私としては、同じEnterprise向けソフトベンダとして、永遠に追いつけない存在でありながら、良き「師範」としてこれからも目標にして頑張っていきたいと思います。