クラウドのパワーを最大限に活かしたS/4HANAコンバージョンを実現します。お客様毎に異なるシステム環境に応じた最適なコンバージョンシナリオを提供することで、既存のSAP ERPシステムを効率よくSAP S/4HANAにコンバージョンすることができます。
- サービス詳細
- コンバージョンの要点を見る
クラウドとSAPシステムに精通したエキスパートによる、インフラワンストップサービス
BeeXには、SAPシステムのクラウド化黎明期からこの分野に携わってきた「クラウド」と「SAP」に精通した技術コンサルタントが一堂に集結しています。弊社はSAP BASIS分野に特化しており、アプリケーションベンダーに問わず、移行プロジェクトに参画することができます。特に既存SAP ERPシステムのSAP S/4HANAコンバージョンに関しては、基盤部分に特化することで、クラウドのパワーを最大限生かした効果的な移行シナリオを提供できることが弊社の特徴です。
- 既存のSAP ERPシステムのSPレベルが低い又はユニコード対応がなされてないため、ダイレクトコンバージョンができない状況だが、効果的なインフラ施策を探されているお客様に
- SAP S/4HANAシステムの具体的なシステムや運用イメージがつけられなくて困っているお客様に
- システム稼働後の運用保守までお任せください。
BeeXの強み
- 豊富な
コンバージョンシナリオ - 最新クラウドテクノロジーを最大限活用することで、他社とは異なる効果的なS/4HANAコンバージョンシナリオを提供します。
- クラウドとSAPの
スペシャリスト集団 - SAPシステム基盤とクラウド両方を理解し、かつ運用にも精通したスタッフが、細やかな技術対応を実施。勘所を押さえた提案が特徴です。
- 保守的では無い
攻めの姿勢 - レガシー体質になりがちな基幹システムの運用業務に改革をもたらすべく、裏付けのある一歩踏み込んだ「わくわくする」サービスを提供します。
S/4HANAコンバージョンはなぜ大変と言われるのか
既存SAP ERPシステムのS/4HANA化は、従来の「バージョンアップ」や「アップグレード」ではなく、「コンバージョン」と呼ばれる作業が必要です。データベースをSAP HANAにマイグレーション(移行)するとともに、アプリケーションのシンプル化、アドオンプログラムの改修とともに、ビジネスプロセスの最適化が必要になるため、従来のテクニカルアップグレードと呼ばれるBASISコンサルタント主導の更新プロジェクトと比べて、お客様負荷が高くなるのが特徴です。
SAP BASISに関して豊富な経験を持つBeeXが基盤部分をリードすることで、お客様は業務やアプリケーションの対応に専念頂くことができます。
S/4HANAコンバージョン処理の要点を理解することで、コンバージョンプロジェクト成功の鍵となるアプリケーションの対応方針や対応スコープの精度を高め、盤石なプロジェクト計画を定めることで、S/4HANAコンバージョンプロジェクトの計画リスクを事前に低減します。

S/4HANAコンバージョン後のシステム稼働イメージ
インメモリーデータベースのSAP S/4HANAを運用するためには、これだけのサーバーのを導入検討するとともに、安定運用を実現する必要があります。SAP BASISに関して豊富な経験を持つBeeXは、クラウドパワーを生かすことで、サーバー台数の削減・集約・最適化を行い、長期的な運用コストやインフラコスト低減をお約束します。

クラウドとSAP基盤技術に特化
S/4HANAコンバージョンの場合、アプリケーションの対応負荷が大きいことから、どうしても基盤部分の検討は薄くなりがちです。BeeXは「クラウド」と「SAP BASIS」の技術に特化しているので、基盤部分について要点を絞ったご提案が特徴です。
- パフォーマンスの考慮点例
- マシンの物理的な距離=レイテンシ
- APサーバ/DBサーバ、DBサーバのPrimary/Secondary
- 特にクラウドの場合、レイテンシが大きくなりがち
- クラウドベンダごとに仕様・性能が違う
- 同一ゾーンに配置、ゾーン内でさらに近くするようにする
- 特にバッチ処理はレイテンシーの影響を受けやすい
- どうやってもダメな場合、バッチ処理の削減といった業務改善が必要になる
- 高可用性の考慮点例
- HANA DBはインメモリデータベースのため、再起動後に性能劣化時間がある
- 切り替えにはクラスタソフトやネットワークルーティング変更が必要
- HSRのレプリケーションモードはレイテンシを考慮して選択する
- HSRはレプリケーションのみ
- 切り替えにはクラスタソフトやネットワークルーティング変更が必要
- APサーバをどう配置するか
- シングルゾーンかマルチゾーンか性能要件を勘案し設計が必要
- コスト以外のトレードオフもある
- 費用⇔構成だけではなく、構成⇔性能もある。バランスが難しい
- 運用の考慮点例
- ソフトウェアライフサイクル対応用ランドスケープの整備
- S/4HANAは5年かつ最新から2世代前のSPまでが正式サポートとなっており、HANADBも2年と短く、また新機能の追加も気になる。
- Linuxパッチ管理
- リポジトリ管理ツールなどを検討
- HANA Cockpit
- HANA DBの管理ツール活用
サービス提供の流れ
- ロードマップ
-
- 現行システムのヒアリング
- S/4HANA移行シナリオの検討
- 新システム構成の検討
- 移行概要スケジュールの提示
- アセスメント/PoC
-
- 分析ツールを利用してS/4HANAコンバージョンの影響度の調査
- クラウド上へ環境を移行しS/4HANAコンバージョン検証(PoC)の実施
- サンドボックス環境を利用した新機能デモストレーション
- サイジングおよび新システムイメージ(To-Be)の作成
- 詳細プロジェクトスケジュールの作成
- 実行
-
- クラウド基盤構築
- 移行テスト
- 移行リハーサル
- 本番移行