Bruce Bookbinder 17 Nov 2021
今日のほとんどの企業は、数多く利用しているアプリケーションのどれかで、サービスとしてのソフトウェア（SaaS：Software-as-a-Service）のソリューションをすでに利用していると言っても過言ではありません。例えば、SaaS ソリューションは、顧客管理（CRM）システムとして非常に多く利用されています。2019年の Gartner 社の調査では、SaaS によるソフトウェア販売が CRM の総売上の 84％ を占めると予測しました。ほとんどの企業が CRM システムとしてかなり早くから SaaS を採用していたにもかかわらず、その同じ企業は製品ライフサイクル管理（PLM）システムの SaaS への移行に非常に時間がかかっています。SaaS ベースの PLM を早くから採用している企業のほとんどは、SaaS のプロバイダーが提供している標準アプリケーションに簡単に適応できた中小企業から始まりましたが、企業特有の要件が強い大企業は SaaS とクラウドへの適応に時間がかかりました。しかし、いま、コロナ禍を経験して、この状況は急速に変化しています。
初めてSaaSソリューションに移行する場合、一部の IT 専門家はカルチャーショックを起こすかもしれません。（IT 部門が創設された）当初から、ITのプロたちは、物理的なデータセンターやインフラストラクチャから、ネットワーク、ソフトウェア、セキュリティ、その展開に至るまで、アプリケーション配信のあらゆる側面を管理してきました。企業の資産（IP）の保護と、製品を開発するシステムのパフォーマンスを確保するための標準規格、プロセス、および手順の開発に何年も費やしてきました。企業が SaaS の契約書に署名するということは、これらの業務のほとんどすべてが外部のサービスパートナーに渡されることになるのです。署名のインクが乾けば、サービスプロバイダーは、サービスレベルアグリーメント（SLA）で謳われているサービスすべてを提供します。サービスベンダーが SLA 契約を満たしている限り、これが内部でどのように行われるかは、IT 部門の関心事ではなくなります。これは、システム配信のあらゆる側面をコントロールしてきた人にとって調整が必要もしれませんが、SaaS ソリューションは、最終的にはすべての関係者にとってより効果的であることが証明されているのです。ユーザー企業は IT メンテナンスの日常業務から解放され、社外ベンダーは複数の顧客にソリューションを提供するため、スケールメリットによって効率化することに集中できます。
ほとんどの大企業では、すでにエンタープライズアプリケーションの少なくとも 1つには SaaS を採用しているため、これらの企業においては日常業務をサービスプロバイダーに引き継ぐことの効果について企業として理解しているはずです。しかし、PLM を SaaS に移行しようとする企業にとって少し驚くことになるかもしれないのは、オンプレミスで使用している PLM ソフトウェアがクラウドで使用する製品と同じではない可能性があることです。したがって、SaaS PLMの契約書に署名する前に知っておくべきことを、以下に 3つ挙げます。
1. SaaS PLM では、カスタマイズや新しいソリューションを作成できますか？
これが最初にする質問になるはずです。希望する答えが得られない場合は、そこで会話を中止し、次に進むべきです。SaaS ソリューションを提供するビジネスケースはスケールメリットに依存します。一般的に SaaS のサービスは、最小限のリソースを使用して複数の顧客に同じシステムと環境を提供できるため、サプライヤーにとって有益です。しかし、SaaS で提供されるサービスが、ユーザーの将来の要件を満たすためのカスタマイズや新機能によって企業固有の要件を戦略的にサポートできるようになっていない場合、問題が発生します。大企業の方であれば誰もがご存知のように、OOTB（out-of-the-box：すぐに使える）ソリューションがそのまま稼働してすぐに使えるようなことはありません。PLM がカスタマイズをサポートできない場合は、要件を満たすための複雑な回避策、つまり「開発」をしなければならない状況に戻ります。SaaS のメリットが消えていくのを見ることになります。
最初の質問に対する答えが 「もちろん、SaaS PLM をカスタマイズできますよ」 であった場合、最初の質問の続きは 「では、どのように？」 です。SaaS 環境において、将来のアップグレードに影響を与えたり、技術的負債を発生させたりすることなく、戦略的にカスタマイズ可能ですか？ もしその回答が、カスタマイズは別の開発アプリケーションで構築する必要があり、それは PLM と 「シームレスに機能しますよ」 という答えだった場合、それは危険信号です。そして、システムの回避策を探し回る業務に後戻りしかねません。
最初の 2つの質問をクリアできた場合、3つ目は大きな質問になります。サービスプロバイダーはどのようにカスタマイズを管理していますか？ カスタマイズをサポートするための柔軟な展開モデルがありますか？ 新しい拡張機能の継続的な展開をサポートできますか？ ビジネスの頻繁な要求にPLM システムが対応していくことを期待する場合は、ユーザー固有のアプリケーションの変更をサポートするだけでなく、DevOpsプロセスを使用して管理し、テストと展開を自動化する必要があります。 将来のSaaS PLM のサービスが、システムの変更を管理するために必要なすべてを提供していない場合は、システムの変更が期待されていないことがわかります。
2. 都合が悪い場合、アップグレードのタイミングを遅らせることはできますか？
前述したように、SaaS のビジネスケースは、プロバイダーが同じリソースのセットで、ソフトウェアの同一のインスタンスを管理できるかどうかに依存します。多くの SaaS ソリューションでは、プロバイダーが更新を送信する準備ができたら、それがユーザーの都合の如何にかかわらず、更新が行われてしまいます。一般的に、企業には厳格なスケジュールがあり、諸々の依存関係やタイミングがしっかりしているため、アプリケーションを一定期間変更できない 「コードフリーズ」 が発生することがよくあります。年度末や四半期末の決算がその典型的な例です。データの不整合のリスクを避けるために、帳簿を締めるプロセスが開始すると、他のすべてのプロセスが停止します。PLMシステムの更新を停止する方法がなく、財務部門が帳簿を閉めているときにデータに問題が発生した場合はどうなるでしょう？ その会話には参加したくないですね。
3. 私が利用する SaaS ソフトウェアはオンプレミスのシステムと同じですか？
PLM ベンダーが主力製品を SaaS サービスとして提供しているからといって、同じアプリケーションと機能が利用可能になるとは限りません。多くのメジャー PLM ベンダーは、既存製品を SaaS 製品として利用できるように開発する（作り替える）ことに苦労しています。通常のオンプレミス版と SaaS 版で機能は完全に同一かどうかを尋ねてみてください。繰り返しますが、答えが 「いいえ」 の場合は、会話を中止して、次に進みましょう。
もし、今ちょうどレガシー PLM をクラウドに移行しようとしていて、オンプレミス版の展開のパワーと柔軟性を犠牲にしたくないとお考えの場合は、ぜひ Aras Enterprise SaaS をご確認ください。上記の難しい質問への回答をきっと気にいると思います。