みなさんこんにちは。SAPジャパン出嶋です。今回は、デジタルスレッドを実現する上で必要となるPLMとERPの連携についてご紹介させていただきます。
デジタルスレッドの実現にむけたパートナーシップの発表
2020年7月14日に、SAPとSiemens社はインダストリー4.0に対応した包括的なソリューションを提供するというアライアンスについて発表を行いました。（詳細はこちらの プレスリリース）
このアライアンスでのポイントは、従来からTeamcenterやWindchill、3DExperienceといった主要なPDM/PLMアプリケーションとの連携機能についても提供しておりましたが、このアライアンスでは互いの製品アプリケーションをお互いが再販していくというポイントの他に、両社の現場でのナレッジや製品アプリケーション開発部門も巻き込んで新しいソリューションを開発し、デジタルスレッドを実現していくという、一歩踏み込んだアライアンス内容となっています。
なぜPLMアプリケーションとERPの連携が必要なのか？
ではなぜPLMアプリケーションとERPの連携が必要なのでしょうか。
業務上の観点では、製品差別化やマスカスタマイゼーション対応により、設計変更数が増えているというポイントがあります。この変更数の増大により、下流部門への情報伝播の工数が飛躍的に増え、それにともない伝達ミスやロスも増えていくことで品質問題につながりかねません。
特に最近は、天災による調達や地政学的な問題が起こった場合にも生産の柔軟性を確保して顧客の供給ニーズに応えるということで、複数の生産拠点での生産や調達を志向される製造業のお客様も出てきています。複数拠点で生産する場合においては、設計の変更情報を上流側のPLMシステムからERP側にミス・ロスなく伝達することが必須となります。またその情報を各拠点に伝達・反映させるためには現行のERPにあるトランザクション情報（在庫や製造指図など）を確認した上で、適切な切り替え内容やタイミングを考慮する必要もあります。
その一方で技術的な観点では、PLM(製品ライフサイクル管理)のアプリケーションは、その文字から想像するに「製品ライフサイクル全体にわたるデータ管理」、すなわち「設計」「生産技術」「製造」「保守」「廃棄」にわたるすべてのデータを管理するためのアプリケーションと捉えられがちですが、多くのPLMアプリケーションベンダーが、もともとCADを提供しているベンダーだったこともあり、実質「設計」領域を中心とした仕掛中のCADデータやその構成情報をハンドリングする狭義の意味でのPLM実装を行っているケースが多いのではと想像されます。
もちろんこれらの領域の仕掛中のデータ管理は非常に重要であり、特にCADのデータ管理に関しては、単なる単体ファイルの管理だけにとどまらず、CAD上で定義する親子関係のファイル間には複雑な参照関係を持っていたり、図面や3Dモデルの間にも参照関係をもっており、これらの関係性をしっかり理解した上でのデータ管理機能が求められてきます。
またそのCAD構成から部品構成を作成する際にも、単純なCADと部品の1:1の関連付け以外にも、3D形状は一緒ですが、部品番号は別にしたいケース（例：塗装色品番など）やその逆で実際は形状としては複数存在するが、１つの部品として扱いたいケース(例：バネやホースのような柔らかモノの表現)なども存在し、こういったケースにも適切にデータ管理できる必要があります。その意味においてはこのようなツールやアプリケーションの存在は必須のものとなります。
しかしこの一般的なPLMのアプリケーションでは、実際にモノを手配・計画し、実際に製造のための指示を起こしたり、その作業にかかったコスト（材料費や労務費）などを収集するような、いわゆるトランザクション処理を行うことはできません。というのもトランザクション処理を行うための必要な情報やパラメータが存在しておらず、またそういった処理を行う機能自身も実装されていないからです。極論すると一般的なPLMでは、ERPに連携するまでの仕掛中のデータ管理を任せ、その中で確定されたデータをERP側に連携し、そのデータをERP上にのみ定義されているそのほかのマスタデータや必要なパラメータを使って、トランザクション処理を行っていくということになります。
こういった業務的、技術的な観点からも一般的なPLMアプリケーションとトランザクションを実行するERPアプリケーションとの連携が必要となる理由が明確になるかと思います。
実は大変な連携IFの開発
PLMとERPの連携が必要というのは、前のセクションでご説明させていただいた通りですが、いざこの連携機能を構築しようとするといろいろなことを考慮しなければいけません。
前セクションでも記述していますとおり、PLMとERPでは同じような重複する情報を扱う一方で、お互いのデータモデルが異なっているため以下のような点を連携機能構築時に考慮しなくてはなりません。
- 互いのデータ(オブジェクト)がどのデータ（オブジェクト）にマッピングできるのか
- 上記が決まったとして、それぞれのオブジェクトの項目・属性をどうマッピングできるのか
- 項目・属性をマッピングする際のクロスリファレンス値をどう扱うのか（例：PLM側では数量単位の値をeachで表現するが、ERP側ではST(個)とする）
- 他方のデータ登録時の必須入力項目値が存在しないような場合の扱いをどうするのか
- データを連携登録・更新するトリガイベントは何か
- 各データを連携登録する際の、順番はどうするか
- 連携登録するためのAPIが用意されているか
- エラーが発生した際のエラーハンドリングはどうするのか
- 将来の機能拡張時にどう対応できるのか
このように連携機能開発時に考慮すべきポイントは沢山あり、これらをクリアにした上で連携機能を構築していかなくてはいけません。そのため手組みでの連携機能の構築・開発にはそれなりの工数やコストがかかり、各アプリケーションがバージョンアップするケースではもともと構築した連携機能の仕様を熟知しているリソースが必要となり、メンテナンスコストもかかり続けます。
Siemens社とSAPの開発部門も関わって開発されたTeamcenterとの連携機能の登場
このような連携機能開発によるコストや工数の課題を解決するための1つの方法として今回のSiemens社とSAPのアライアンスによって提供されている「SAP Teamcenter Integration to S/4HANA(通称:TCI)」を活用することができるのではと考えております。
このTCIでは、互いの開発部門が関わって開発・提供しているということで、予めこの２社の開発部門の開発作業の中で定義した共通の「メタ・ドメインモデル」（図3）を介して連携を行います。この「メタ・ドメインモデル」とは、Siemens社のTeamcenterのデータ構造とSAPのS/4HANAのデータモデル構造を両方取り入れたデータモデルとなっていまして、これからどんどんいろんな情報をやり取りするにあたって、いきなりAS-ISのオブジェクトベースで連携IFをつくるのではなく、両者をいかにうまく合わせれば将来の変更対応や拡張を含めて互いのシステムに影響を与えることなく、効率的に連携できるかを考えて定義しているものとなります。
これによりベースとなる連携機能の提供はもちろんのことですが、先ほど連携構築時の考慮ポイントにもあった、将来のバージョンアップや機能改善・拡張に対しても柔軟に対応することができるようになります。
このTCI機能については、1stリリースの機能が2021年の年末に提供されており、そこから約半年のスパンで追加機能の提供が予定されております。
結び
Siemens社とSAPによる共同開発連携機能により、技術的に確立された方法で確実な連携を行うことで、製品競争力強化を設計部門だけでなく他部門も含め行い、生産性の柔軟性を高め顧客への供給責任を果たすことで顧客満足度を高めることにつなげることができるようになるではないでしょうか。
こちらのTCI機能にご興味を持たれた方は、ぜひSAPの担当者までご連絡いただければと思います。
