SAP R1/R2/R3とHANAの違いは？SAPの歴史を知ろう
INDEX LINK
はじめに
SAP ERPは、1973年にリリースされた「R/1」から現在の「S/4 HANA」まで、実に50年もの歴史を持つシステムです。
これだけの規模と歴史を持つパッケージは、国内外を探してもほとんどありません。
最先端のS/4 HANAが普及期を迎える直前の今だからこそ、SAP ERPの歴史をもう一度おさらいしておきましょう。
1. 原初のSAP ERP「R/1」の成り立ち
SAP ERPの歴史は、1972年に初めてのERP「R/1」を開発したことから始まります。R/1は、主に財務会計や資材管理などの業務プロセスを統合的に管理するために開発されました。
R/1の特徴は、中央のメインフレームコンピュータ上で実行され、主にバッチ処理形式でのデータ処理が行われたことです。
また、R/1はオンプレミスベースのシステムであり、企業内の専用ハードウェアやネットワーク環境が必要でした。
さらに、R/1は主に財務や会計、資材管理などのバックオフィス業務を対象としており、企業の業務プロセスを統合して効率化することができました。
ちなみにR/1はアセンブリ言語で記述されていたそうです。
2.クライアント/サーバーに対応した「R/2」
1980年代になると、SAPはR/1の後継として「R/2」を開発しました。R/2はR/1からの進化版であり、主に生産管理や販売管理などの業務領域をカバーするために開発されました。
R/2の特徴は、分散型のクライアントサーバーアーキテクチャを採用していたことです。
これにより、クライアント端末とサーバーがネットワーク経由で通信し、リアルタイムなデータの入力や表示が可能になりました。
また、R/2は現在のようにモジュールベースの構造を持ち、企業のさまざまな業務領域に対応する機能が提供されました。
これにより、業界や企業規模に対応する柔軟性も持ちはじめ、企業の成長や変化にフィットするシステムになっていったのです。
3.日本でもブームを起こした「R/3」
1990年代になると、SAPはR/3という新たなERPシステムを開発しました。R/3はR/2からさらなる進化を遂げたシステムであり、より包括的かつ柔軟な業務プロセスの管理を可能にしました。
R/3の特徴は、クライアントサーバーアーキテクチャを基盤としており、3つのレイヤー（プレゼンテーション、アプリケーション、データベース）から構成されていたことです。
これにより、ユーザーインターフェースと業務ロジック、データベースが分離され、柔軟なシステム構築が可能となりました。日本でよく知られるSAP ERPはこのR/3がベースとなっています。
R/3はR/2に引き続きモジュールベースの構造を継承しており、さまざまな機能が提供されました。企業は自社の業務に必要なモジュールを選択して導入できるようになったわけです。
さらに個々の業務プロセスを変化させつつ、それに対応するようにR/3をカスタマイズすることで、システムと業務をフィットさせることもできるようになりました。
4.R/3が日本国内で受け入れられた理由
このようにSAP ERPは、
・アセンブラで記述されたメインフレーム用のR/1
・サーバー、クライアントに対応しモジュール構造を持つR/2
・モジュール構造＋3階層（UI、アプリ、DB）のR/3
といった具合に進化を続け、R/3の時点で日本に上陸したのです。
R/3は日本でもブームを巻き起こし、大企業がこぞって導入を始めました。日本国内での受け入れが進んだ理由はいくつかあります。
4-1. グローバル化の影響
まず、当時（1990年代）の日本は業務プロセスの効率化と情報システムの一元管理を目指す動きが活発化していました。
ちょうどグローバル競争が激化し始めたころで、日本企業も海外展開を進めることになり、業務プロセスの最適化と効率化が求められたのです。
また、1990年代にはコンピュータ技術やデータベース管理システムの進歩が顕著であり、これらの技術を活用した統合的な業務管理システムへの期待が高まりまった時期でもあります。
R/3はグローバルな標準化を重視していたため、日本企業が海外展開を進める際に利用しやすい環境を提供していました。さらに多言語・多通貨に対応しており、日本企業のグローバルな業務ニーズに対応することができたのです。
4-2. カスタマイズとアドオンで日本独自の商慣習に対応
2つ目の理由は、「日本企業のビジネスプロセスに合わせたカスタマイズが可能であった」ことでしょう。
R/3にはすでに世界中の企業から集められた経営のベストプラクティスが集約されていましたが、すべてを網羅していたわけではありません。
しかし、標準機能で対応できないビジネスプロセスに対しては、カスタマイズやモディフィケーション、ABAPによるアドオン開発での対応が可能でした。
これにより、日本企業の独自なビジネスルールにも対応することができました。R/3の持つ柔軟性とカスタマイズ性は、日本企業の経営幹部にとって魅力的な要素として映ったようで、R/3の受け入れを促進しました。
5. S/4 HANAとR/1、R/2、R/3との違い
現在はR/3の終焉が近づいており、すでにS/4 HANAへの移行が始まっています。
S/4 HANAは、従来のR/1・R/2・R/3と比べていくつかの重要な違いがあります。
・インメモリデーベースの採用
S/4 HANAはインメモリーデータベース技術を活用しています。これにより、大量のデータを高速に処理し、リアルタイムな分析や予測を行うことが可能となりました。
・クラウドベースかつオンプレミスにも対応
S/4 HANAはクラウドベースのシステムとして提供されており、オンプレミス環境への依存度を低くすることができます。
これにより、システムの柔軟性や拡張性が向上し、迅速なシステム導入やアップグレードが可能になりました。
・機能の統廃合
さらにS/4 HANAでは、機能の簡素化や統合が進められています。複数のモジュールが統合され、よりシンプルなインターフェースとなっています。
R/3は巨大で複雑なシステム群であり、ユーザーの大半が全体像を把握できないという課題がありました。この点に配慮したのがS/4 HANAの特徴のひとつです。
UIも刷新され、ユーザーはより直感的に操作することができるようになりました。
6. 改めて知っておきたいS/4 HANAの特徴
ここで、改めてS/4 HANAの特徴を整理しておきましょう。
6-1. インメモリーテクノロジー
SAP S/4 HANAでは、インメモリーテクノロジーを採用しています。
これにより、大量のデータを高速に処理し、リアルタイムな情報を提供することが可能です。
高速なデータ処理と応答性能の向上が同時に得られるため、開発・運用の両面でさまざまなメリットがあります。
例えばMRP計算のリアルタイム化などは、インメモリーテクノロジーの恩恵を多分に受けていると言えます。
6-2. 統合プロセスフロー
SAP S/4 HANAでは、業務プロセスの統合化が強化されています。
従来のSAP ERPでは個別に設定や連携が必要だった機能やデータが、統合プロセスフローによって一元化されました。
異なるモジュール間のデータのやり取りや処理がスムーズになり、開発やシステムのカスタマイズが容易になるという利点があります。
6-3. クラウドネイティブアーキテクチャ
SAP S/4 HANAは、クラウドネイティブなアーキテクチャに基づいて設計されています。
これにより、クラウド環境でのスケーラビリティや柔軟性が向上し、クラウド上での展開や管理が容易になりました。
6-4. AIと機械学習の統合
SAP S/4 HANAでは、AI（人工知能）と機械学習の機能が統合されています。これにより、大量のデータから洞察を得たり、予測分析を行ったりすることが可能になりました。
6-5. R/1・R/2・R/3とは一線を画すS/4 HANA
このようにSAP S/4 HANAの新機能は、効率的な開発とシステム運用を可能にするものばかりです。
正直なところを言えば「できること」の数はそれほど変わっていませんが、「できること」の程度が著しく向上するというイメージでしょうか。
高速なデータ処理、統合プロセスフロー、クラウドネイティブなアーキテクチャ、AIと機械学習の統合といった機能により、単なる業務効率化のみならずDXへの足掛かりになるシステムへと進化しました。
7. S/4 HANAへの最適化を進めよう
繰り返すようですが、すでにSAP ERP業界はS/4 HANAに向かって突き進んでいます。
R/3（ECC6.0）時代の情報資産を取り込みつつ、いかにS/4 HANAへ移行するかを本気で検討している企業が増えています。
コンサルタント/エンジニア側も時代の流れに乗り、スキルを磨いていきましょう。できるだけ多くのプロジェクトを経験しながら、S/4 HANAへの最適化を進めていきたいですね。
