T
THINK Business

SAPとIBMの協業関係が実現する“マイグレーションwithイノベーション”によるDXとは

post_thumb

工藤晶 氏

工藤晶 氏
SAPジャパン 常務執行役員
サービス事業本部長

1990年にPwCコンサルタントに入社、翌年に独SAP本社へ出向し、SAP R/3のローカリゼーションを担当、1993年に帰国しSAPジャパンの立ち上げに参加。2002年には、PwCコンサルティング買収に伴い、日本アイ・ビー・エムへ入社、エレクトロニクス事業部⻑、SAP事業部⻑などを歴任。2015年には、デジタル・コンサルティング部門のインタラクティブ・エクスペリエンス事業を新規に立ち上げ、デザイン思考プラクティス、イノベーション・ガレージ・サービスなど、デジタルイノベーションを支援する新サービスを立ち上げ、お客様のDXを支援してきた。2018年10月に、常務執行役員デジタルビジネスサービス事業本部⻑としてSAPジャパン株式会社に入社。

髙井宣行

髙井宣行
日本アイ・ビー・エム株式会社
グローバル・ビジネス・サービス(GBS)
エンタープライズ・アプリケーションズ革新
事業統括
パートナー

日本アイ・ビー・エム株式会社にて、ERPパッケージソリューションを中心に企業の経営変革を支援するエンタープライズ・アプリケーションズ革新の事業を統括。SAP には、1996年から20年以上にわたり従事。コンピューターメーカーを経て、1996年にプライスウォーターハウスコンサルタント株式会社に入社。以来、業務改善およびシステム導入に関するプロジェクトに数多く参画。業務プロセス改善に関するコンサルティングや、 SAP ERP システムの適合性分析から構築・導入までのライフサイクル全般、および大規模プロジェクトの管理経験を有する。

後藤哲二

後藤哲二
日本アイ・ビー・エム株式会社
グローバル・ビジネス・サービス(GBS)
NextGen.エンタープライズ・アプリケーションズ
SAPプラクティスリーダー
パートナー

1996年、プライスウォーターハウスコンサルタント株式会社に入社し、基幹業務を中心とした業務改革コンサルティングおよびシステム化構想から導入までを多数支援。2002年、PwCコンサルティング買収に伴い、日本アイ・ビー・エム株式会社へ入社し、SCM領域を専門領域として、製造業、流通業を中心に多くのSAPプロジェクトを成功裏に導入。2019年からSAPプラクティスリーダーとして、多数のSAP導入プロジェクトを支援。
 

 

デジタルトランスフォーメーション(DX)がさまざまな文脈で語られる中、中核技術の一つとなっているのがSAP S/4HANAへの移行だ。S/4HANA化を支援するIBMグローバル・ビジネス・サービス(GBS)は、企業の状況に合わせて複数のアプローチでサポートする。その際、IBMがSAPのサポートと良好な関係を築いてきたことが、さらなる相乗効果を生んでいる。

SAPジャパン 常務執行役員サービス事業本部長の工藤晶氏、日本アイ・ビー・エム グローバル・ビジネス・サービス(GBS)の髙井宣行氏と後藤哲二氏の3人に、日本におけるDXの課題、SAPとIBMの協業における現在の状況や今後のビジョンなどについて語ってもらった。工藤氏は以前IBMで働いていたこともあり、対談は和やかに進んだ。

ITの潜在性が高まる中、日本企業に求められる“DXの定義”

――最初に日本のデジタルトランスフォーメーション(DX)についてお聞きします。現状をどう見ていらっしゃいますか。課題があるとすれば、どこにあるのでしょうか。

工藤 まず“DX”という言葉の定義がはっきりしていないという問題があります。SAPアプリケーションを使って基幹システムをIT化することを指す人もいれば、モバイルなどの新しい技術を使ってPoC(Proof of Concept=概念実証)を回すことを指す人もいます。また、ITを使った新規事業を立ち上げることを指す人もいます。さまざまな企業がさまざまなことを“DX”という言葉で表現しています。

企業において“我が社のDXはこういうもの”という定義をしっかり持っているところは、それほど多くはないようです。既存のIT部門とは別に、デジタルで新企業を起こすために別のIT部門が立ち上がるというケースも聞きます。そのような状況を考えると、「船頭多くして船山に上る」とことわざがありますが、日本ではまず会社が自社のDXとは何かをきちんと定めることが大切だと個人的に思います。

高井 DXの土台にITがあることは間違いありません。ITもERP(基幹システム)も、1990年代、2000年代、2010年代と時代とともに変遷し、その中で流行語が浮かんでは消えていきました。DXはその一つかもしれません。

ただ根本的にこれまでと違うのは、ITの潜在性、あるいは機能が飛躍的に向上していることです。それに加えて、従来はITと言うとき、コンピューターセンターを中心とした限られた空間でした。ところが昨今は、コンシューマーの方々もスマートフォンなどのデジタル機器を利用しています。ITそのものの発展やITの社会的な広がりがあって、DXで表現されるような新しいビジネスのやり方やあり方の発想ができるようなタイミングに来ているとも感じます。

工藤さんがさきほど「DXという言葉の定義がない」と指摘されましたが、いろいろな潜在性や可能性があるからこそ、企業側もどうやって活用できるのかを試行錯誤しながら進めているという状態にあるのでしょう。そんな中では、目標をしっかり決めて向かっていくというやり方だと、どうしてもその間に技術は進歩するので難しいです。むしろ、走りながら適応していくというやり方で、会社もIT部門も変わっていきます。その点で、現在は過渡期にあるのかもしれません。DXは2020年代に本格化するのかもしれませんね。

DXに向けて、S/4HANA化を実現するための3つのアプローチ

――DX実現に向けたアプローチとして、どのようなものが考えられるのでしょうか。基盤としてのSAP S/4HANAへの移行が大きな課題と言われています。

工藤 DXを実現するために、SAPのようなパッケージソフトウェアを使うことの意味は標準化すること、と考えている人は多いと思います。そうは言っても実は、DXの時代に大切なのは標準化だけではありません。SAPはERPをクラウドでも提供しており、四半期に一度アップデートしています。世界最大のERPベンダーであるSAPは、世界中のさまざまなお客様のニーズやノウハウを吸収した新しい機能をアクティベートすることが可能です。そのようなテクノロジープラットフォームが存在するという点も重要です。

お客様が何か新しいことをやりたいと思った時、これまでなら新しいソフトウェアを購入する必要があったかもしれません。ですが、アクティベートによって使えるという時代に変わっています。S/4HANAはそのための準備でもあるのです。

後藤 DXには答えがない上に、10〜20年前と比べてできることが増えました。これまでは、長い期間をかけて構想を策定することが多かったと思いますが、明確なものがないが、いざやるとなると早くやらないといけないというのが現在だと思います。時代もお客様も変化しています。

早くやる部分と、そうではない部分のメリハリが必要だと思います。早い部分はマイグレーションやテンプレートに合わせてやる部分でしょう。時間をかける部分は差別化部分かもしれません。また、トライ&エラーでやったり、小さく始めるイノベーションの部分と会計など硬い部分の区別をしたりしておくことも必要です。

工藤 そうですね。私はDXを数年がかりでやっていく部分を“Big X”、アジャイルにトランスフォーメーションを進める部分を“Agile X”と称しています。

“PoC疲れ”という言葉が聞かれますが、単にPoCを回すだけでは進みません。すでにSAPを使っているお客様で、デジタルプラットフォームを整備する――つまりS/4HANA に早く移行したい、同時に新しくイノベイティブなこともやりたいというお客様には、S/4HANA にマイグレーションしながら、同時に別に小さなチームをつくってPoCをやることをお勧めしています。PoCを繰り返してある程度の可能性が出てきたら、その中から次に開発するものをつくっておきます。マイグレーションが終わり落ち着いたところで、PoCから少しずつ現場に移していくという流れです。これを“マイグレーションwithイノベーション”として提唱しています。

IBMのお客様はどうですか。規模が大きなお客様が多いので、しっかりDXに取り組もうというところが多いでしょうか。

後藤 大手企業はここ10〜15年で、事業の統廃合や企業合併が進みました。もともと別々の設計思想で似たようなERPを使っているので、きちんとつくり直したいというお話が多いです。一方で、基本的にマイグレーションが中心で、移すべきものを移行しながら不要なものは削除しつつ、追加で新しいことに取り組もうというところもあります。

そこでIBMは、S/4HANA化に向けたさまざまなニーズを吸収できるアプローチを複数用意しています。既存の資産を流用する“BROWNFIELD”型、アドオンのみS/4HANA化して、データはそのままにして高速にマイグレーションを行う“RAPID MOVE”型、そして新規にS/4HANAを導入するベストプラクティス設計の“GREENFIELD”型です。それぞれに合わせたツールやサービスを使って支援します。

工藤 SAPでもSAP S/4HANAへの移行プログラムを用意しています。

既存の資産を有効活用するのは重要な考え方だと思います。最初は新規導入プロジェクトだったのが、結果的にマイグレーションが半分を占めるなど、BROWNFIELDとまではいかなくても、ハイブリッドの形になっていることが多いです。

後藤 スピードを考えると、ある程度既存のものを活用しないと大変ですよね。

高井 せっかくS/4HANAを導入するのだから、S/4HANAの機能を活かしたいという点は共通しています。それに当たって、従来のシステムはかなり手を入れてしまったので、GREENFIELDのように新しくつくり直したり、ハイブリッドの形を取って使えるものは使ったりするなど、選択肢はいくつかあります。

選択肢はいくつかあっても、ROI(投資対効果)を経営層に説明することを含め、S/4HANAに移行することで、どのように業務が変わっていくのかを入れ込んだ形でプランニングしていく点は共通しています。

“マイグレーションwithイノベーション”を実現した企業事例:トラスコ中山

SAP S/4HANA化に向けたアプローチ -IBM Rapid move
 


後藤
 マイグレーションしながら不要なものを削除しつつ、新しいことにも並行して取り組んだのが、工具卸売業大手のトラスコ中山 (YouTube,3分19秒)さんのプロジェクトです。

IBMがプライムパートナーとしてSAP® ERPからS/4HANAへの移行を支援しながら、高度化や自動化のための新機能や社外との連携機能についてはSAP® Cloud Plat-formを活用しました。“Side-by-Side”拡張というやり方です。

工藤さんのサポートチームには、プレミアムエンゲージメント(PE)という専門家によるサービスを提供いただきました。プロジェクト期間において開発部門と連携した課題解決、さらに、大規模なデータについてはパフォーマンスのチューニングなどで支援をいただきました。IBMだけではすぐに解決できなかったと思います。

おかげさまで、予定通り2020年1月に無事稼働に入りました。在庫40万点とかなりのボリュームで、品数も多く、サプライチェーンも受注と同日もしくは翌日に発送するなど、クリティカルな要件を実現しています。

工藤 トラスコ中山さんのプロジェクトは、IBMがプライムパートナーとなり、SAPはIBMと一緒にイノベーションの部分で、“富山の薬売り”の工具版である「MROストッカー」を構築しました。つまり、顧客の建築現場にトラスコ中山さんの工具を置き、そこから顧客は必要な時に取って使うというというものです。弊社のデザインシンキングチームとトラスコ中山さんが一緒になり、顧客である建設現場の方々に聞き取り調査をして考え至ったアイディアです。アプリの開発はSAP Cloud Platform上で行い、PoCを回しました。

マイグレーションしながらイノベーションになる機能についてはPoCを回し、最後にそれが一緒になりました。MROストッカーは、在庫データがそろっていなければできないサービスです。プラットフォームのS/4HANAがあることで新しいイノベーションが可能になる、そういう意味でも素晴らしい事例になりました。

後藤 トラスコ中山さんのプロジェクトでは、IBM Watsonの自然言語分類API、商品検索システム、チャットボットAPIなどIBM Cloudのコグニティブ機能と、SAP Cloud Platformをつなぐことで、可能性が広がりました。例えば自動化に関しては、1日5万件寄せられるという見積もり依頼に対して10万円以下のものは自動化するなど、いくつかの作業において行いました。人件費を考慮すると、自動化を進めて、人間が注意深くやるべきところでちゃんと作業できる体制を整えることが重要です。一方で、自動化については、不安を拭える状態をつくることも必要でした。やはり、データをちゃんと蓄える仕組みがあることは重要ですね。

 

プラットフォーム活用に際して重要となる、アーキテクチャーのデザイン

――プラットフォームの整備という点で、ポイントや勘所はありますか。

工藤 S/4HANAの設計思想に沿ってデザインをすることは重要なポイントだと思います。SAPに限らずどんな会社にも製品に関して設計思想があり、それに相入れないつくり方をすると矛盾が生じてしまいます。

SAPのソリューションを完全にそのまま受け入れる必要はありません。競争優位の源泉となるような差別化のための機能を外につくることもかまいませんが、どのようにつくるのかについては考える必要があります。プラットフォームの機能を最大限活かしてつくるのか、思想が違うから完全に外につくるのか。アーキテクチャーのデザインは重要です。そこがきちんとしていないと、パフォーマンス上の問題をはじめ、いろいろな問題が出てくる可能性があるからです。

後藤 結局、20年前と変わらないのですけどね。ただ、自由度が増した分、正しくデザインしなければなりません。

工藤 そうですよね。変わったところは、できることがより広く、深くなった点です。自由度という点では、どこまで自由にするのかという問題が大きくなってきました。

加えて、日本企業もグローバル化が進んでおり、世界でどのようにビジネスを展開するのかをシステム面でも考える必要があります。また、調達・購買のSAP® Ariba®(※1)、人事のSAP® SuccessFactors®(※2)などのLoB(Line of Business)ソリューション、クラウドも含めて全体のアーキテクチャーをどうしていくのか。自由になった分、考えなければならない部分も増えています。

※1:バイヤーとサプライヤーの連携を促し、各企業の支出管理とコスト削減の実現を支援する、調達・購買およびサプライチェーンコラボレーション用のソリューション

※2:クラウド方式で提供されるタレントマネジメントソリューション

 
そこで重要になるのは、ある程度痛みを伴うことを承知で意思決定できるかです。この点も変わりませんね。トランスフォーメーションなので、それなりの覚悟のようなものが必要です。

高井 SAP Cloud Platformもあれば、IBMにもPaaS(プラットフォーム・アズ・ア・サービス)のRed Hat OpenShiftがあります。これまでのように単一のOSとアプリケーションが結びついたプラットフォーム環境から、活用したり統合したりすることができるプラットフォームへと変化しています。

SAPの土台として、UNIX系ではSUSEが選ばれることが多いですが、IBMにはRed Hat Enterprise Linux(RHEL)もあります。基幹となるS/4HANAにのらないものは、RHELの上で独自に開発することも可能です。

工藤 コアの部分はSAPのERPで標準化し、できるだけ小さくする。差別化の部分は外でアジャイルにつくって試し、うまくいかないなら壊してつくり直す。そんなことができる環境は技術的に構築可能です。日本のお客様は完全じゃないものをつくり出すことに抵抗感があるところが多く、そこの兼ね合いをどうするかが課題と感じます。

後藤 そうですね。変化を前向きに受け入れられるかどうか。以前は、一度構築したシステムをずっと使わなければなりませんでしたが、これからはシステムも変化します。SAPが四半期ごとに新機能をリリースする。つまりシステムが育つことを認識できれば、発想が変わるかもしれません。

――そのほかに、成功するプロジェクトに共通点はありますか。

高井 うまくいくプロジェクトは、お客様、IBM(SAPのアプリケーションを導入するサービスを提供)、SAPの3社がきちんと連携し、同じベクトルで進めることができています。

導入ベンダーが全体を進めすぎてしまう、お客様の関与が低い、SAPとの連携をあまりせずに進めるなど、何かが欠けているとほころびが出てきます。小さいプロジェクトなら“力技”でなんとかなるかもしれませんが、大きなプロジェクトだとそうはいきません。

お客様も、IBMも、SAPの製品も、完璧なわけではない。どうやってコミュニケーションを取りながらコラボレーションをして、一つのソリューションに持っていけるかが重要だと思います。

30年以上協業して良い補完関係にある、SAPとIBMに共通の価値観

――SAPとIBMの協業関係についてお聞かせください。長く良好な協業関係の背景には、どのような共通の価値観があるのでしょうか。

工藤 SAPは今年創業48周年を迎えますが、そもそもSAPの5人の創業者はIBM社員であり、IBM勤務時にお客様向けのアプリケーションをつくったという経緯があります。日本でも30年以上の協業関係にあり、IBM自身がSAPのアプリケーションを利用する最大のユーザーの1社でもあります。

高井 最近は2社ともに、ソリューションの幅が広がってきたので競合する部分も出てきましたが、これまでSAPは基幹業務系のアプリケーション、IBMはサーバーなどのシステムと、良い補完関係を続けてきました。補完関係からスタートしているという点は大きな意味があると思います。

後藤 協業も進化しており、最近では調達・購買のSAP Aribaの提供を開始し、すでにかなりの事業規模に育っています。このように新しい取り組みもやらせていただいています。

工藤 私自身は元IBMで、両方の企業を知っている立場から見て、似ているところと違うところがあります。SAPは“パーパス(purpose)”という言葉で表現しますが、世の中に貢献することを大事にしていますし、IBMも“世界のためのイノベーション”を目指していらっしゃいます。ここは似ていますね。逆に違いを感じるのは、ドイツ(SAP)と米国(IBM)で、考え方が少し異なるところがあると思います。

――IBMから見たときに、SAPに共感する部分はありますか。

高井 ドイツと米国の比較では、日本人からするとドイツの価値観はなじみやすいですね。進め方がきちんとしているし、それがプロダクトの性質そのものにも反映されている。ドイツ発の製品と米国発の製品は違うと感じます。

SAPとIBMが未来において目指す“1+1=3”という関係性

――SAPとIBMの協業関係は今後どのように発展していくのでしょうか。中長期的なビジョンをお聞かせください。

高井 2社の協業関係は長く、これまでの歴史や基盤は今後も継続していきます。これまでは、SAPがアプリケーションを供給し、それをお客様が導入するに当たってIBMがサービスを提供する、あるいはIBMが持っているソフトウェアやソリューションを付加してやっていくという関係でした。

今後は、トラスコ中山さんの例のように、2社が一緒にお客様のDXをどう実現していくかというところで、より深い協業や関係を進めていきたいと思っています。そういう意味で、中長期的に発展させたい部分は、工藤さんが率いるSAPのサービス部門とIBMのグローバル・ビジネス・サービス(GBS)チームが、今までにない形でコラボレーションをしたり、役割分担をしたりしながらお客様にソリューションをお届けすることです。

工藤 SAPのサービス部門は、コンサル会社やシステムインテーグレーターのコンサル部門とは性質が違います。SAPはエンジニアリングの会社なので、SAPについて比類ない知識を持ったエンジニアがそろっています。一方で、大規模なプロジェクトや、開発も含んだプロジェクトマネジメントは、必ずしも得意ではありません。協業にあたって、それぞれの得意分野を持ち寄ることが重要ではないでしょうか。

よく感じるのですが、SAPとIBMがそろってお互いの得意なところをやると、2社以上のことが可能になるはずです。2社で多くの日本のお客様をS/4HANAに移行し、デジタルのプラットフォームをつくり、進化していただく。きっちり・かっちりで時間をかけるやり方でもいいし、小さく始めて大きく育てるやり方でもいい。それをやるときに、2社が一緒に組むことによって、より効率よく、より優れたものができる。そこが我々の目指すべきところではないかと思います。

高井 SAPのサービス部門のトップに工藤さんが就任されてすぐに、どのような支援をするのかを明確にしていただきました。ともすれば競合になりかねないのですが、従来と違う視点で協業していこうというのが伝わってきました。

工藤 今の時代、競合すること自体は価値を持ちません。得意領域が違うのだから、得意なところをうまくやることが重要です。

S/4HANAに移行したいお客様はたくさんいらっしゃいます。お互いの得意領域をうまく持ち寄って、お客様のDXを支援できれば全員がハッピーになれると思います。
 

*本鼎談は2020年3月24日に実施したものです。鼎談関係者に関しては、取材前14日間における新型コロナウイルス感染症発生国への渡航歴、また、咳、くしゃみ、鼻水、発熱などの症状がないことを確認した上で、新型コロナウイルス感染症の拡大防止に最大限配慮して行いました

*SAP、SAPロゴ、記載されているすべてのSAP製品およびサービス名はドイツにあるSAP SEやその他世界各国における登録商標または商標です