問い合わせから、現地対応・交換修理まで。
HPEに見るサポート業務の一体化構想

Cloud & AIのサポートを、
一つの基盤でつなぐ計画。

HPEは、企業のIT基盤を支える会社

HPE（Hewlett Packard Enterprise）は、2015年に旧Hewlett-Packardの分割によって誕生した、米国の企業向けテクノロジー企業です。PC・プリンターを扱うHP Inc.とは別会社で、サーバー、ストレージ、ネットワークなど、企業やデータセンターのIT基盤を支えています。^[6]

Cloud & AI事業とは何か

今回の「Cloud & AI」は、HPEの事業区分の名称です。計算処理を担うサーバー、データを保存するストレージ、クラウド関連ソフトウェアに加え、導入・活用を支える専門サービスや金融サービスなどを含みます。2026年度第3四半期の決算では、同部門の売上をServer、Storage、Financial Servicesに分けて開示しています。^[7][3]

生成AIのアプリケーションを提供するだけの事業ではなく、企業がクラウドやAIを動かすための機器・基盤と、それを支えるサービスを扱う領域です。今回対象となるのは、その顧客向けサポート。問い合わせの回答に加え、機器の調査、技術者の訪問、部品交換・修理が関わることを踏まえると、後述する製品構成を理解しやすくなります。

そのサポート基盤に、ServiceNowを選定

ServiceNowは2026年10月28日、HPEがCloud & AI事業のサポートサービスの基盤に同社を選定したと発表しました。契約期間は5年。顧客・パートナー・従業員の対応をつなぎ、AIと自動化によるサポートの拡大を目指します。^[1]

表：公式発表に記載された導入計画を整理。[1]

既存のSalesforce系基盤から、ServiceNowを中核にする方向へ

既存基盤の背景も押さえておきたいと思います。NERSCがCUG 2024で公開した技術論文は、HPEのサポート基盤「Digital Customer Experience（DCE）」をSalesforceベースの自社開発プラットフォームと説明し、ケースの処理・追跡にSalesforce（SFDC）を使うことを記しています。^[2]

この記録と今回の選定を合わせると、既存のSalesforce系サポート基盤から、ServiceNowを中核とする体制への移行という文脈で読めます。ただし、2024年の論文が扱う環境と今回のCloud & AI事業の導入範囲の対応関係、DCEの全面廃止やSalesforceの全社的な置き換えは、公開情報から確認できません。価格や製品の優劣が選定の決め手だったとも断定できません。

なぜ今か。
事業環境の変化から考える。

今回の導入背景を考える上で、私は、AI・データセンター需要を受けたHPEの事業環境の変化も大きいのではないかと見ています。HPEの2026年度第3四半期決算では、サーバー売上は前年同期比35.3%増、Cloud & AI部門の営業利益率は前年同期の7.0%から17.0%へ改善しています。^[3] また、決算説明会ではAIシステムの受注残の拡大や、CatalystによるAIを使った業務簡素化が説明されています。^[4]

これらは、サポート基盤の選定理由を直接示すものではありません。ただ、成長する事業を支えながら、対応品質と収益性をどう保つか。その課題への備えとして今回の計画を読むと、資産管理、派遣、データ接続、AI統制までを含む構成の意味が見えてくると思います。

① 需要の拡大に、人手だけで備えない

販売や導入が広がれば、設置後の運用・保守を支える仕組みも重要になります。ただし、売上をそのまま機器の台数や問い合わせ件数に置き換えることはできません。実際、HPEはサーバー売上の成長に単価上昇も寄与したと説明しています。^[4]

私は、将来のサポート負荷を見据え、受付から派遣・修理までを、増員や担当者の工夫だけに依存せず回せるようにする投資だと読みます。何年後に何件へ増えるか、現在の体制では処理できなくなるかは、公表情報からは判断できません。

② 複雑な機器ほど、資産と交換・修理の対応付けが効く

HPEの製品には、GPUや液冷に対応するサーバーもあります。^[5] AIインフラを支える保守では、対象機器だけでなく、部品、構成、設置先、保証・契約、交換後の状態を正確に対応付ける重要性が増すと考えます。

どの機器の何を交換し、取り外した部品をどこへ戻し、どの資産記録を更新するか。こうした管理の誤りは、顧客対応の遅れや費用負担につながり得ます。私は、HAMとRMAが今回の計画で独立した項目になっている点を、窓口の使いやすさだけでなく、物理的な資産の処理まで整える投資として見ています。特定のGPU価格や損失額を推計しているわけではありません。

③ 顧客自身の運用基盤とつなぐ必要がある

NERSCの論文は、顧客側のServiceNowとHPE側のサポート基盤を接続し、二重入力や情報共有の課題に対応した実例です。^[2] 顧客が自社の運用システムを持つ場合、ベンダーのポータルで人が情報を転記するだけではなく、ケースと状態をシステム間で連携したいという要求が生じます。

Workflow Data FabricとService Exchangeを含む今回の構成は、こうした企業間・システム間の境界をつなぐ方向として読めます。ただし、NERSC一例から顧客全体の要望を一般化したり、すべての外部システムへ無条件に接続できると捉えたりすることはできません。

④ 成長と収益性を両立させるサポート運用へ

利益率が改善する事業であっても、サポートの手戻り、再訪問、部品手配の誤り、部門間の確認待ちが増えれば、その成長を支える負担は大きくなります。私は、AIによる調査・振り分けの支援や、派遣・資産情報の連携を、顧客対応の品質を保ちながら業務全体の負担を抑える手段として捉えています。

需要の伸びに合わせて人手を足すだけでなく、案件当たりの作業と待ち時間を減らす。そのような経営上の狙いが背景にあるのではないかと考えます。

事業が成長する今、その先のサポートを支える体制も作り直す。私は、今回の計画を、顧客体験の改善と、物量・複雑性・コストへの備えを一緒に進める構想として見ています。資産、現地対応、企業間連携、AI統制までを含む構成は、その視点で読むと理解しやすくなります。

複数の会社で支えるサポートは、
日本企業にも通じる構造。

日本の大手製造業では、サポートを子会社へ分けたり、保守・修理を協力会社へ委託したりする体制を目にします。HPEの構想を読むときも、私は「一社の社員だけでサポートを完結する、海外企業ならではの話」とは捉えていません。

HPEも、パートナーとサービスを届ける

HPEの公式パートナープログラムは、Support Servicesを含むサービス領域を設け、パートナーが自社ブランド、HPEブランド、またはその両方でサービスを提供する枠組みを説明しています。^[8] また、2018年には、HPEが米州のオンサイト保守・設置・予防保守でUnisysと戦略的な関係を結ぶと説明したことが報じられています。^[9]

これらから分かるのは、HPEのサポートにも、自社と外部の専門企業・パートナーで役割を分担する形があるということです。ただし、2018年の報道をそのまま現在の委託体制とみなすことはできず、今回のCloud & AI事業の国別・工程別の分担や委託比率は確認できていません。

組織の細かな切り方は違っても、複数の会社が一つの顧客対応を分担するという基本構造は、日本企業と大きく隔たっていない。私は、その意味で、今回の一体化構想の考え方は日本企業にも十分に応用できると見ています。

組織を一つに戻す前に、仕事をつなげられる

問い合わせ窓口は本体や販売会社、技術判断は専門部門、現地作業は保守子会社や協力会社、修理・部品の処理は別の拠点。こうした分担を維持したまま、顧客のどの問題に対応しているか、誰が次に動くか、何をもって作業を受け渡すかを共有する設計が考えられます。

必要なのは、必ずしも組織の統合ではありません。共通の案件・資産の識別子、状態の対応関係、担当と更新責任、会社間で共有する情報を揃えることです。Service Exchangeで別のServiceNowインスタンスをつなぐ構想や、データ・資産・派遣を組み合わせる計画は、こうした分業体制を前提に読むと、自社への当てはめ方が見えやすくなります。

ただし、どの委託先や物流企業が今回の接続対象になるか、各社がどのシステムを利用するかは発表されていません。製品を導入すれば自動的に全取引先がつながるわけではなく、契約・責任分界・接続方式・公開範囲の合意が必要です。

会社ごとの完了を、顧客の解決までつなぐ

窓口が委託先へ依頼を出して処理済みにしても、訪問日が決まっていなければ、顧客はまだ待っています。現地作業が終わっても、結果が窓口へ戻らなければ、説明や次の判断は止まります。私は、分社化や委託そのものより、この境界で全体の状態が見えなくなることを課題と捉えています。

組織の分担は残しながら、顧客対応の流れは途切れさせない。そのために、顧客対応全体の責任者を置き、受付から解決確認までの時間、会社間の引き継ぎ待ち、再訪問や手戻りを、同じ案件に沿って見ます。これらは本稿の設計上の提案であり、HPEが公表したKPIではありません。

日本企業も、保守子会社や協力会社を含む体制を前提に、どこを共通化し、どの違いを契約や担当領域ごとに残すかを考えられます。私は、HPEの構想を、既存の分業を生かしながらサポート全体を作り直すための参考にしたいと考えています。

自社で運用するために、
まず整えること。

今回の構想を自社へ引き寄せるなら、私は最初にこう問い掛けたいと思います。「売上や導入先が増えたとき、いまのサポートは、どこから回らなくなるか。」必要な機能を並べる前に、成長したときの業務を、過去案件で試してみることが出発点です。

① 「問い合わせが増えたら」を、過去案件で試す

対象の製品・サービスを一つ選び、過去の対応を、窓口で完結した案件、現地対応を伴う案件、交換・修理を伴う案件に分けます。その構成を使い、例えば案件数が1.5倍、2倍になった場合を仮定して、担当者の作業、訪問枠、部品手配、承認、委託先との調整を机上で追います。これは需要予測やHPEの計画ではなく、自社の弱点を探すための負荷テストです。

件数だけでなく、遠隔地の顧客が増える、高額な部品を扱う、厳しい契約条件の顧客が加わるといった変化も試します。受付は回っても、技術者の日程や部品の判断で止まるかもしれません。成長によって最初に詰まる工程を見つけます。

② 顧客が待つ時間と、利益を削る作業を同時に見る

各案件について、実際に作業した時間と、確認・引き継ぎ・部品到着などを待った時間を分けます。再訪問、重複入力、記録不足による聞き直し、契約確認の手戻りも拾います。可能な範囲で作業・移動・部品・委託の費用を対応付け、どの案件で顧客の待ち時間と自社の負担が大きくなっているかを確認します。

窓口だけの応答時間を短くしても、その後の待ちが残れば、顧客の問題は解決しません。私は、対応全体の時間と負担を並べることで、優先して直すべき境界が見えてくると考えます。

③ 最も詰まる工程に、先行導入の範囲を絞る

対象資産や保証の確認が詰まるなら、顧客・契約・資産の対応付けから。訪問調整が詰まるなら、技術者のスキル・空き状況・部品情報と作業指示から。顧客や委託先との転記が詰まるなら、案件番号と状態の連携から始める。こうして、導入対象を実際のボトルネックから決めます。

選んだ範囲に必要なマスタ、担当者、更新責任、引き継ぎ条件を整えた上で、AIや自動化が担う操作を決めます。契約上の約束、費用、訪問・交換の確定に関わる判断は、権限と承認条件を明確にします。利用する製品・連携の対応範囲は個別に検証します。

④ 「増えても回るか」を、品質と採算で確かめる

先行導入後は、受付から解決確認までの時間、再訪問や手戻り、案件当たりの作業負担・費用を見直します。仕事が隣の部署や委託先へ移っただけになっていないか、顧客の待ち時間が減ったかも確認します。品質と採算を保って扱える範囲が広がったかを見て、次の工程へ展開します。

成長してから人が頑張って埋め合わせる前に、成長すると詰まる場所を見つけて変える。私は、この順序でサポートを見直すことが、HPEの一体化構想から自社が学べる、実践的な一歩だと考えています。