香港のHypercare ITサポート：ERP本稼働の計画

本稼働初日の月曜朝に起きる問題の多くは、ERPの不具合ではありません。ラベルプリンター、スキャナーのドライバー、権限設定、そして新しい画面が見つからない社員です。香港のHypercare ITサポート（本稼働直後の集中サポート）は、一定期間エンジニアを現場に常駐させ、モニタリングを強化し、専用のエスカレーションラインを用意し、書面での引き継ぎをもって通常のサポートへ移行します。

会社と、すべてが切り替わる週末

香港にある従業員約90名の貿易・卸売会社を思い浮かべてください。中国本土や東南アジアの仕入先から消費財や軽工業品を輸入し、小売店、工事業者、ネット販売事業者に販売しています。社員は3か所に分かれています。営業と経理のオフィスは商業ビルの1フロア、倉庫は九龍東または葵涌の工業ビルの一角にあり、数名のバイヤーは国境を越えて仕入先の工場へ出向き、ノートPCとスマートフォンで仕事をしています。

この11年間、会社は古い会計パッケージと、いつのまにか「正式な記録」になった在庫管理のスプレッドシート、共有メールボックスに散らばった注文書で動いてきました。経理チームは月次決算に1週間近くかかります。すべての数字を手作業で突き合わせなければならないからです。経理部長は、受注、在庫、購買、総勘定元帳を一か所で扱う統合基盤として、新しいERPの導入をようやく承認しました。導入パートナーとも契約済みです。切り替えは週末に予定されています。金曜の夜に凍結し、夜通しでデータを移行し、日曜に検証し、月曜の朝に全員が新システムへログインします。

この記事は、このプロジェクトのスポンサー、つまり多くの場合は経理部長、場合によっては業務担当役員に向けて書いています。最初にお断りします。これは実在の顧客ではなく、説明のための複合的なシナリオです。香港の貿易・卸売企業によくある状況の形を元にしており、会社に関する数字はすべて、計算を分かりやすくするために置いた仮定です。

社内IT担当者は1名です。ここでは「IT主任」と呼びます。有能で、すべてのPCとパスワードを把握していますが、普段の1週間でもすでに手一杯です。プロジェクト計画には、月曜に誰が彼を手伝うのか、誰も書いていません。

この抜けこそが本稿のテーマです。ERPはおおむね動くでしょう。問題は、90人が同時に新しい仕事の進め方を覚えていく間、ERPの周りのすべてを誰が見るのか、という点です。

ERPの本稼働で、誰が何を直すのか

まず単純な事実から始めます。本稼働は一つの出来事ではありません。同じ数日間に起きる小さな出来事の長いリストであり、それぞれ担当者が違います。

ERP導入パートナーの責任範囲

導入パートナーが責任を持つのはERPそのものです。設定、データ移行、勘定科目の正確さ、ワークフロー、レポート、キーユーザーの研修、そしてアプリケーションの不具合が含まれます。発注書の税額が間違っている、在庫移動が転記されない、といった問題は導入パートナーの仕事であり、良いパートナーはそのための人員を用意しています。

契約は通常この範囲で書かれており、それには理由があります。導入パートナーは、会社のノートPC、倉庫のWi-Fi、5年前に買ったラベルプリンターに責任を負えません。それらを選んだのは彼らではなく、見ることもできず、本稼働の期間中は香港にいないことも多いからです。

現場で誰の担当でもないこと

次に、実際の月曜朝の倉庫とオフィスで起きることを挙げます。たとえば次のようなものです。

新しいラベルテンプレートに合わせてドライバーが更新されておらず、倉庫のラベルプリンターが旧形式で印刷する。
ハンディスキャナーはWi-Fiに接続できるのに新システムに届かない。ファイアウォールのルールや証明書がプロジェクトのチェックリストに入っていなかった。
経理の6人は新システムを開けるが、元帳の画面が見えない。ロールのマッピングが古い表を元にしていた。
営業チームのノートPCが習慣で古い共有ドライブを開き、ファイルが違う場所に保存され続ける。
あるユーザーのシングルサインオンの画面がブラウザー設定のせいでループし、ログインページにすら入れない。
これまで裏で動いていた銀行接続や宅配便との連携に新しい認証情報が必要になったが、持ち主が休暇中。
古いショートカットをクリックしても何も出ず、総務担当に「システムが止まっている」と伝える。

これらはどれもERPの不具合ではありません。しかし、固まった画面の前に立っている本人にはほとんどがERPの不具合に見えるので、区別のない苦情の洪水として届きます。経理部長に見えるのは「ERPが止まった」で、導入パートナーに電話すると、パートナーはそれが自分たちの問題ではないことを証明するために時間を使うことになります。

損害を生む隙間

これが、導入パートナーの責任範囲と、現場のそれ以外のすべてとの間にある隙間です。誰の落ち度でもありません。プロジェクトの組み立て方（一つのシステムを軸にする）と、本稼働の体感（仕事を終わらせようとする一人の人を軸にする）とのずれです。

社内ITは両方にまたがる唯一のチームですが、余力は最も小さいチームでもあります。IT主任は、プロジェクトの技術窓口であり、ユーザーが困ったときに最初に呼ばれる人であり、残りの業務を止めない責任者であり、何が起きているかを取締役会に説明する人でもあります。このシナリオの会社のIT主任は、2か月間、夜に切り替えチェックリストを書き続けてきました。月曜の午前10時までに、彼は40回中断されるでしょう。

もしこれがあなたのプロジェクトに似ているなら、有益な問い方は「ITがもっと必要か」ではありません。「限られた期間、現場に実際に立ち、直す権限を持つのは誰か。IT主任がもう一組の手を必要としたとき、誰に電話するのか」です。

Hypercare ITサポートとは何か

Hypercareは、ERPの本稼働、大規模なテクノロジー導入、新オフィスの開設など、失敗の許されない出来事を包み込む、短期集中型のサポートです。BrocentはHypercare ITサポートのサービスページで、重要な期間中に経験豊富なエンジニアが現場に常駐するサービスとして説明しています。ここでは、そのサービスページに書かれている内容を平易に整理します。

ユーザーの隣で働くオンサイトエンジニア

エンジニアは本稼働期間中、社員と同じフロアで作業し、問題が本稼働を遅らせるインシデントに育つ前に、その場でリアルタイムに解決します。このシナリオでは、ラベルプリンターとスキャナーの問題がそれにあたります。困っている人のすぐ隣に誰かが立っているので、チケットが待ち行列を回るのを待たず、数分で直ります。

期間中のモニタリング強化

Hypercare期間中は、モニタリングの閾値が厳格化されます。サービスページによると、ポーリング間隔の短縮、CPUとメモリの基準値の引き下げ、重大なものだけでなくあらゆる異常への即時アラートです。理屈は単純です。通常運用なら、高負荷が10分続いてからのアラートで妥当です。本稼働中は、全員が同時に新システムを試すので、10分の遅延こそが問題のすべてなのです。

専用のエスカレーションライン

専用の電話とチャットのラインが、貴社の運用チームとBrocentのシニアエンジニア・マネジメント層を直接つなぎます。待ち行列も音声ガイダンスもありません。サービスページでは、Hypercare期間中は24時間利用できると説明されています。厄介な問題は、一日の端に出がちなので、これは重要です。日曜夜の検証中や、オフィスにまだ人がそろっていない月曜朝7時などです。

ウォールーム

Brocentは本稼働中に、仮想またはオンサイトのウォールームを設置し、関係するエンジニアと貴社の関係者を一つのコミュニケーションチャネルに集めて、調整と意思決定を一か所で行います。海外の導入パートナー、経理部長、倉庫責任者、IT主任がいる会社にとって、単一のチャネルは聞こえる以上に価値があります。同じ障害が三通りの言い方で三人に報告されることを防げるからです。

日次ブリーフィングと、きちんとした終わり方

日次のHypercareブリーフィングは、発生、解決、対応中のインシデントを網羅し、プロジェクトスポンサーは尋ねなくても本稼働の健全性を把握できます。そしてHypercareは正式な引き継ぎで終わります。完全なインシデントログ、教訓のまとめ、既知課題の一覧、そして通常運用のモニタリングとエスカレーション経路が稼働・検証済みであることの確認です。この終わり方は最も省略されやすい部分なので、後で改めて触れます。

サービスページに書かれていないこと

ページには、日額料金、パッケージ価格、標準的な期間は書かれていません。書かれているのは4つのステップ、すなわちスコープ策定と事前ブリーフィング、エンジニア配置、Hypercare実施、BAUへの移行であり、期間、対象システム、ユーザー数、リスク領域は最初のステップで定めると説明されています。本稿もこの考え方に従います。以下で示す人数や期間は、この説明用の会社の仮定であり、Brocentが公表している数字ではありません。

エンジニアは何名、何日、どの時間帯に必要か

規模の見積もりは、Hypercareの判断が最も誤りやすいところです。恐れから買いすぎるか、予算を小さく見せるために買い足りないかのどちらかになります。より良い方法は、需要の形から考えることです。

人と場所から始める

需要は均等には分布しません。集中するのは二か所です。人が新システムを初めて使う場所と、ハードウェアが新システムに触れる場所です。この会社では、スキャナー、ラベルプリンター、共用端末を、デスクワークに慣れていない人が使う倉庫の現場と、権限や元帳を、デスクワークに慣れた人が使い、どんな誤りにも気づく経理オフィスです。

会社は約90名で、そのうち60名が毎日システムを使い、30名が時々使うと仮定します。これらが、この例を通して使う仮定です。

仮定と明記した計算例

以下の人員配置は、この説明用の会社のものであり、Brocentのルールではありません。2拠点、90名の会社であれば、計画はこのような形になり得るという例です。

倉庫：最初の3営業日は1名のエンジニア。機器が最も多く、停止への許容度が最も低い拠点だからです。その後は、毎日短時間の訪問に切り替えます。
オフィス：最初の3営業日は1名のエンジニアが、経理、営業、共用機器を担当します。その後は、オフィスと倉庫に時間を分けます。
エスカレーションラインとモニタリング：期間全体を通して稼働させ、現場のエンジニアが異例の事態でシニアエンジニアを呼べるようにします。
IT主任：守られます。会社のシステムの責任者であり続け、現場の運営を任されません。エンジニアが待ち行列を引き受け、彼は判断を下します。

つまり最初の3営業日は2名、その後は1名で、期間中ずっとシニアエンジニアが遠隔で支える形です。これは議論の出発点であり、推奨ではありません。実際の人数は、拠点数、初日に仕事の進め方が変わるユーザー数、新システムに依存する物理的な機器の数、すでに持っているリモート対応力によって決まります。

期間はどのくらいが適切か

長さを決めるのは二つです。一つは習熟曲線です。サポート需要は初日が最も高く、画面に慣れるにつれて下がります。もう一つは最初の月次決算で、ERPが本当に試される瞬間です。最初の決算より前に期間が終わると、経理チームは最も助けが必要なときに支えを失います。

このシナリオでは、最初の3営業日は手厚く常駐し、最初の2週間の残りは軽めの常駐とし、モニタリングとエスカレーションラインは最初の決算が終わるまで続ける計画が妥当です。これはこの架空の会社についての判断です。貴社の場合、スコープ策定のステップは、この決定を推測ではなく根拠で行うためにあります。

どの時間帯か

時間帯は、人が実際に働く時間に合わせます。朝7時に積み込みを始める倉庫には、9時ではなく、その前に現場にエンジニアが必要です。最初の決算の夜に残業する経理チームには、夜に連絡のつくエンジニアが必要です。エンジニアが現場にいない時間は、エスカレーションラインが埋めます。

香港にはもう一つ考慮点があります。複数言語での対応です。倉庫の責任者は広東語のほうが話しやすく、導入パートナーのコンサルタントは英語で仕事をし、中国本土の仕入先の担当者は北京語を使います。これらを滑らかに行き来できるエンジニアは、測りにくいけれど実感しやすい時間を節約します。

最初の72時間はどう進むか

このシナリオでの、時間を追った計画です。細部はこの説明用の会社のものですが、作業の順序は、週末に切り替えが重なる場合の典型です。

金曜夜から土曜：誰もログインする前

エンジニアは凍結前に到着するか、この段階で遠隔の場合はウォールームのチャネルに入ります。切り替え計画と対象システムの一覧について説明を受けます。モニタリングの閾値を厳格化します。エスカレーションラインはテスト通話で確認し、導入パートナー、経理部長、倉庫責任者、IT主任が入ったウォールームのチャネルを作ります。

最初の有益な作業は、新システムに触れるすべてのものの現物棚卸しです。すべてのスキャナー、ラベルプリンター、共用端末、キーユーザーに割り当てたノートPCを確認します。地味な作業ですが、プロジェクト計画が「誰かがやったはず」と思い込んでいたまさにその作業です。

土曜：移行の夜と最初のテスト

導入パートナーがデータを移行する間、オンサイトのエンジニアはテスト環境を相手にデバイスを一台ずつ確認します。各スキャナーがシステムに届くか、各プリンターが新しいラベルを印刷するか、各キーユーザーがサインインできるかです。失敗はすべて記録し、修正し、再テストします。土曜に接続できないスキャナーは不便で済みます。同じスキャナーが月曜朝7時、荷受け場でトラックが待つ中で失敗すれば、インシデントです。

日曜：セーフティネット付きの検証

キーユーザーが自分の画面を検証します。権限の問題が表面化するのはここです。経理チームが元帳の画面を見られない。倉庫責任者が在庫移動を承認できない。それぞれウォールームに記録し、適切な担当（ロールのマッピングは導入パートナー、デバイスとアクセスはエンジニア）に割り当て、その日のうちに完了させます。

日曜の夜には、エンジニアとプロジェクトスポンサーが短い準備状況レビューを行います。準備できたもの、既知の未解決事項、それぞれの暫定対応を一覧にします。ルールは「不意打ちを作らない」ことです。

月曜朝7時から10時：ピーク

計画が試される時間です。エンジニアは最初のシフトの前に現場にいます。倉庫のエンジニアは荷受け場のそばに、オフィスのエンジニアは経理エリアにおり、二人ともウォールームのチャネルにいます。

この時間帯に最も多いのは、先ほどのリストにある問い合わせです。画面が見つからない、デバイスが切断された、権限が違う。これらはその場で直ります。本当にERPの不具合であるものは、証拠を集めた状態で導入パートナーへ渡されるので、導入パートナーはネットワーク障害ではないことの証明ではなく、不具合そのものに時間を使えます。

月曜昼から火曜：ロングテール

最初の朝のラッシュが過ぎると、別のパターンが現れます。勘で朝を乗り切った人が、第二の層の問題に当たります。出力できないレポート。違うレコードに添付されたスキャン文書。新しい認証情報が必要な宅配便との連携。その日の終わりの日次ブリーフィングには、発生、解決、未解決の件数が並びます。経理部長は、心配する同僚から聞くのではなく、未解決の数が減っていることを自分で読みます。

火曜の夜までには、全体の輪郭が見えてくるのが普通です。計画が正しければ、需要はすでに下がり始め、エンジニアは火消しが減って指導が増え、未解決事項は短く、よく理解された一覧になっています。

導入パートナーのサポート、社内IT単独、Hypercare：どれを選ぶか

本稼働をカバーする現実的な方法は三つあります。スポンサーにとって大事な問い、つまり誰が何を直すのか、どのくらいの期間か、終わった時に何が残るのか、で比較します。

ERP導入パートナーの稼働後サポート

誰が何を直すか：ERPアプリケーション。設定、データの不具合、ワークフロー、レポートです。デバイス、ネットワーク、プリンター、アプリ外のユーザーアクセスは、通常は契約の範囲外です。
期間：契約の定めるとおりで、稼働後の一定期間であることが多く、通常は遠隔で提供され、現地での時間は限られます。
終了時に残るもの：安定したアプリケーションと、未解決の不具合の一覧です。導入パートナーの記録はERPだけを対象としており、ほかには何もありません。
最も適した場面：アプリケーションの問題です。この種の問題の正しい担当であり、どの選択肢でも連絡の輪に残しておくべきです。

社内IT単独

誰が何を直すか：理論上はすべて。実際には、IT主任が最初に手が届いたもので、声の大きい人の順です。
期間：かかるだけ。つまりIT主任の夜と週末です。
終了時に残るもの：非常に疲れたIT主任、独立した記録の欠如、そして彼が退職したときに知識が一緒に去っていくリスクです。
最も適した場面：ユーザーが少数の小さな切り替えで、IT主任に本当に余力があり、本稼働が物理的な機器をあまり巻き込まない場合です。

Hypercareサービス

誰が何を直すか：現場、つまりデバイス、プリンター、スキャナー、アクセス、接続、ユーザーへの案内、モニタリングです。アプリケーションの不具合については、導入パートナーへの明確な経路があります。
期間：スコープ策定で合意した、明確な終わりのある期間です。
終了時に残るもの：インシデントログ、既知課題の一覧、教訓のまとめを含む正式な引き継ぎ資料と、通常運用のモニタリングとエスカレーション経路が機能していることの確認です。
最も適した場面：多数のユーザーと多数のデバイスに同時に影響する本稼働で、社内ITがすでに余力を失っている場合です。

この三つは互いに代替というより、三つの層です。導入パートナーがアプリケーションを持ち、社内ITが会社のシステムを持ち、Hypercareは負荷が最も高い数週間、両者が本来の仕事を続けられるようにする一時的な追加の手です。

Hypercareはいつ終わるのか

終わりのないサポート期間はHypercareではありません。計画されていない外部委託であり、通常は計画されたものより高くつきます。本稼働の前に終了基準を合意しておくことが、この契約を短く、誠実に保ちます。

書き残しておく価値のある終了基準

基準は会社ごとに異なりますが、良い一覧は次のようなものです。

合意した重大度を超える未解決のインシデントがなく、業務プロセスを止める未解決の問題もない。
1日あたりのインシデント数が、数営業日連続して合意した水準を下回っている。
最初の月次決算、または同等の最初の完全な業務サイクルが、現場レベルの障害なく完了している。
通常のモニタリングが稼働し、アラートの閾値が標準値に戻り、テストアラートが正しい担当者に届いている。
BAU（通常運用）のエスカレーション経路が、文書に書かれているだけでなく、端から端までテストされている。
スポンサーが最終ブリーフィングを読み、残りの事項を許容できると認めている。

一覧は書面で合意すべきです。そうすれば、終了の判断は交渉ではなく、基準に照らした確認になります。

引き継ぎ資料

サービスページには、BAUへの移行に含まれる内容が列挙されています。チェックリストとして使う価値があります。

インシデントログ：発生したすべての問題、どう解決したか、どれだけかかったか。1年後に、ある設定がなぜそうなっているのかを説明してくれます。
既知課題の一覧：まだ未解決のもの、担当者、暫定対応。
教訓のまとめ：本稼働で環境、研修、プロセスについて分かったことを、記憶が新しいうちに書き留めたもの。
BAUサポートの確認：モニタリングとエスカレーション経路が稼働・検証済みであり、エンジニアが去った翌日に、誰に電話すべきかが分かる状態。

資料の目的は、知識を会社のものにすることです。半年後にIT主任が退職しても、本稼働中に何があったかが、彼の頭の中だけにあるわけではありません。

Hypercareの費用は、月次決算の遅れと比べてどうか

価格はお示ししません。BrocentのHypercareのページには価格が公表されておらず、価格はスコープによるからです。スコープ策定の相談で見積もりを得られます。Brocentの料金ページは、料金を公開しているサービスでの掲載の仕方を示しています。ここでより有益なのは、この費用をどう秤にかけるかです。

ひどい最初の1か月のコストと、自社の数字で比べてください。五つの問いを立てます。

倉庫が半日出荷できなかったら、遅れる注文の金額はいくらか。
最初の月次決算が1週間でなく2週間かかったら、経理の工数のコストはいくらで、その数字を待つ意思決定は何か。
経理部長が最初の1週間、経理を回す代わりにプロジェクトの苦情窓口になったら、何が手つかずになるか。
IT主任が本稼働後に燃え尽きて辞めたら、後任の採用と、彼が持っていた知識の復元にいくらかかるか。
最初の週に、お客様へ遅れた、あるいは誤った納品をしたら、取引関係へのコストはどれほどか。

正確な答えは出ませんし、必要もありません。いずれか一つでも、短期でスコープを絞った契約より大きそうなら、判断はすでに明らかです。どれもそうでないなら、Hypercareはおそらく必要なく、より軽い仕組みで足りるでしょう。

この第二の可能性は真剣に受け止める価値があります。ユーザー15名、物理的な機器なし、社内ITの人員が十分という本稼働なら、常駐エンジニアは不要かもしれません。Hypercareは、負荷が高く、誤りへの余裕が小さい場面のためのものです。

Hypercareは「瞬間的な山」。その後、現場は何で回るのか

引き継ぎで最も重要な一文は、エンジニアが去ることについてではありません。彼らが去った翌日に何が稼働しているか、についてです。

Hypercareは意図的に一時的です。数週間だけサポートの水準を引き上げます。その後、現場には、会社が実際に使うIT量に見合った安定した仕組みが必要で、この本稼働は、それに関する良い証拠を提供してくれます。インシデントログは、どの問題が繰り返し起きるか、どの拠点からの連絡が多いか、需要がどの時間帯に落ちるかを示します。

よくある行き先は三つです。

定期訪問とオンデマンドの組み合わせ。ITの利用が控えめな会社には、定期訪問とリモートの支援で足りるかもしれません。別の記事香港におけるオンサイトITサポートのモデルは、常駐型、定期訪問型、都度派遣型を比較しています。
専任エンジニア。インシデントログから、倉庫とオフィスで一人が手一杯になる仕事量があると分かるなら、Brocentの常駐型ITサポート（フルタイムオンサイト）が、休暇時の代替要員とBrocent全体のバックアップ付きで、名前の決まったエンジニアを提供します。
IT主任の後ろにあるヘルプデスク。負荷が通常の時間外に出るなら、24×7ヘルプデスクが北京語、広東語、英語で対応します。Brocentが公表している数字は、年間約15,000件のインシデント処理と、90%の電話を40秒以内に応答というものです。

これらは排他的ではありません。マネージドITサポートの下で一つの仕組みにまとめることができ、Hypercare期間を経験した多くの会社が最終的にここへ行き着きます。唯一のIT担当者がどれだけ目に見えない仕事をしていたかに、気づいたばかりだからです。Brocentは2007年創業、本社はシンガポールにあり、2016年から香港・観塘に常設のエンジニアリングオフィスを置いています。

よくある質問

Hypercareはどのくらいの期間続けるべきですか。

公表された標準はなく、Brocentのサービスページにも記載はありません。期間は、本稼働の計画に基づいてスコープ策定で決めるためです。通常、長さを決めるのは二つです。最初の数日の後に需要がどれだけ早く下がるか、そして最初の完全な業務サイクル、たとえば最初の月次決算がいつ完了するかです。この説明用の会社では、最初の3営業日は手厚く常駐し、2週間の残りは軽めに常駐し、モニタリングとエスカレーションラインは最初の決算が終わるまで続ける、という計画でした。終了基準は本稼働の前に書面で合意してください。

HypercareはERPプロジェクト専用ですか。

いいえ。BrocentはHypercareを、ERPの本稼働、大規模なテクノロジー導入、新オフィスの開設、重要な事業イベントに適したものとして説明しており、サービスページの対象にはERP、Microsoft 365、新オフィス開設、クラウド移行が挙げられています。共通点は、短期間に多くの人とシステムが同時に変わり、失敗のコストが高いことです。

ERPベンダーや導入パートナーはこれを提供しますか。

現場の層については、通常は提供しません。導入パートナーが担当するのはアプリケーションで、設定、データ、ワークフロー、不具合です。デバイス、プリンター、スキャナー、ネットワーク、アプリ外のアクセスは、一般にその範囲外であり、自社の契約で確認できます。パートナーを推薦したり調整したりできる導入パートナーもあります。実務的には、導入パートナーに、稼働後サポートに何が含まれ、何が含まれないかを書面で尋ねてください。

100名のユーザーなら、エンジニアは何名必要ですか。

人数よりも、拠点と機器によって決まります。デスクワーク中心の一つのオフィスにいる100名と、オフィスとスキャナーやプリンターだらけの倉庫に分かれた100名とは、別の問題です。この説明用の約90名の会社では、計画は最初の3営業日が2名、その後は1名で、全期間にわたりシニアエンジニアが遠隔で支援するというものでした。これは例の仮定であり、ルールではありません。人数は、スコープ策定のステップで、ユーザー数、拠点、リスク領域に基づいて決めるものです。

Hypercareはリモートでもできますか。

一部は可能です。サービスページには、エンジニアはオンサイトで、または仮想チャネルに接続して対応し、ウォールームは仮想でもオンサイトでもよいと書かれています。リモートのモニタリング、エスカレーションライン、ウォールームは遠隔でも十分に機能します。遠隔のエンジニアにできないのは、デバイスの差し直し、ケーブルの交換、ユーザーの隣に立って画面を示すこと、荷受け場でスキャナーを直すことです。物理的な機器がある本稼働では、最初の数日のオンサイト常駐が通常は価値があり、その後はリモートのサポートに切り替えます。

Hypercareの終了時に未解決の問題はどうなりますか。

引き継ぎの一部である既知課題の一覧に入ります。各項目には担当者と暫定対応があり、一覧はBAUサポートを担う側に渡されます。期間の終了時に未解決の問題は、スポンサーにとって不意打ちであってはなりません。日次ブリーフィングが何日も前からそれを挙げているはずだからです。

Hypercareを延長できますか。

はい、合意のうえで可能で、成り行きに任せるのではなく、終了基準に照らして決めるのが望ましいです。基準が満たされていない場合、たとえば最初の決算が終わっていない、根強い問題が残っているなどの場合は、期間を区切った延長に合意するのが妥当です。終わりの日付のない延長は、適切な答えが別の安定したサポートの仕組みであることを示すサインです。