ChatGPTでERPのUATスクリプトと移行ランブックを作る方法

結論から言うと： 各業務プロセスを自分の言葉でChatGPTに説明し、前提条件・手順・期待結果、そして皆が飛ばす異常系まで含めたUATスクリプトを起草させます。次に、移行の順序を、担当役割・所要時間・Go/No-Goの判断点・切り戻し条件つきのランブックに変えさせます。書類は数時間で下書きできます。判断を持つことも、移行当日の朝六時に現場にいることもできません。

ERP本番稼働の六週間前、中堅企業の文書の状況はどこも同じです。プロジェクト計画があり、パートナーの標準テンプレートがあり、共有ドライブには、たまたま手の空いた火曜日に誰かが書いた作りかけのテストスクリプトが三本ある。コンサルタントは設定作業中。受注が実際どう流れるかを知っている業務担当者は本業で手一杯。そこへ誰かが尋ねます——移行のランブックは誰が書くのですか。

この作業は知的に難しいわけではありません。量が多く、退屈で、そして時間のない人たちを必要とします。この組み合わせが、いつも遅れ、いつも薄くなる理由であり、同時に言語モデルが得意とする種類の下書き作業である理由でもあります。

以下は、判断を手放さないことが前提です。書類の初版はモデルが書き、正しいかどうかは自社の人が決め、週末を担うのも自社の人です。

本番稼働の文書がいつも遅れ、いつも薄い理由

四つあります。名前をつけておくと段取りが立てやすくなります。

設定作業と時間を奪い合う。 設定が終わるまで完全なテストはできないので、スクリプトを書くのは早すぎるように感じます。そして設定が終わる頃には稼働日が迫り、すべてが緊急になっています。

必要なのはシステム知識ではなく業務知識。 コンサルタントはモジュールを知っていますが、受注途中で与信限度を超えた顧客に何が起きるかを知っているのは自社の与信担当だけです。それを手順として書き出すには彼らの時間が要り、それがプロジェクトで最も希少な資源です。

異常系が飛ばされる。 正常系は誰でも書きます。分割納品、締めた期間に対する赤伝、有効な価格契約を二つ持つ顧客——本番が実際に壊れるのはそこなのに、誰も書きません。

ランブックが順序ではなくチェックリストとして扱われる。 作業の一覧は移行計画ではありません。移行計画には順序、依存関係、時刻、記名された担当役割、そして「続けるかどうかをここで決める」という地点があります。

プロセスの説明からChatGPTが下書きできるもの

入力はERPではありません。業務がどう回っているかについての、知っている人が平易な言葉で書いた説明です。

走らせる価値のあるUATスクリプトを得るには

プロセスを端から端まで説明します。どこから始まり、誰が触り、システムは何をすべきで、例外は何か。そのうえで、固定の構造で出力させます。テストID、プロセス領域、前提条件、関与する役割、番号つきの手順、期待結果、合否欄。

一般的なスクリプトと役に立つスクリプトを分けるのは、二つの指示です。

異常系と境界条件を明示的に求めること。 「初めて導入する人が忘れる失敗経路を出して」と言えば、分割出荷、日付を遡った請求、税コードの例外、承認限度の境界値が出てきます。いくつかは該当せず捨てますが、残るものは本来なら稼働一週目に表面化していた問題です。

置いた前提を列挙させること。 空白を黙って埋めるモデルは負債です。「三点照合が有効であること、与信限度は警告ではなく阻止であることを前提としました」と締めくくるモデルは、確認リストを渡してくれます。その前提はたいてい、プロジェクトが既に答えているべきだった問いです。

データは入れないでください。受注には顧客、価格契約、納期がある——それで十分です。実際の得意先マスタを貼らないこと。テストスクリプトに要るのは形であって、レコードではありません。

移行計画をランブックに変えるには

意図している順序を大枠で渡します。最終バックアップ、旧システムでの取引凍結、残高の抽出、マスタの投入、未消込項目の投入、照合、検証、新システムの開放。加えて、使える役割と作業できる時間枠も。

ランブックは番号つきの一覧として出させます。手順、担当役割、開始時刻、所要時間、依存、検証確認、切り戻し条件。最後の二つは、手書きのランブックで抜け落ちがちで、そして午前四時に効いてくる項目です。

そのうえで難しい問いを投げます。「この順序の中で、きれいに中止できる最後の地点はどこか」。それがGo/No-Goの判断点で、モデルに案を出させれば、プロジェクトマネージャーは白紙ではなく具体案に反論できます。同じ「構造を下書きさせ、人が直す」型はSOPと入社時ドキュメントの生成でも成り立ち、その「直す」工程こそが双方を安全にしています。

実例——受注から入金までの一プロセスを、スクリプトと移行枠に変える

社員350人の卸売企業が、三連休で新ERPへ移行します。財務システム責任者が受注から入金までを約600語で説明します。EDIとメールからの受注、与信確認、二拠点の倉庫からの引当、分割出荷可、出荷時請求、顧客グループごとに異なる支払条件、欠品時の赤伝。

この説明から一度の生成で、標準受注、与信超過、分割出荷と欠品、価格契約の優先順位、赤伝の経路を覆う25本ほどのUATスクリプトが出てきます。あわせて、置かざるを得なかった前提が五つ示されます。そのうち三つは誤りでしたが、これは失敗ではなく発見です。直すのに二十分、そして引当ルールの仕様に本当の抜けがあったことが分かります。

業務担当者のレビューが、価値の出るところです。下書き25本を読んで直す時間は、ゼロから書く時間のごく一部で、しかも「読む」は忙しい人が夕方五時に実際にやってくれる作業です。二本は該当せず削除、六本は実質的に書き直し、与信担当しか知らなかった事例で四本が追加されます。

移行枠も同じ手順で下書きします。順序は週末にまたがる40の番号つき手順になり、各手順に担当役割、所要時間、検証確認、切り戻し条件が付きます。加えて、土曜14時にGo/No-Goの判断点が提案されます。残高を投入し照合した後、最初の実取引の前です。プロジェクトマネージャーはこれを二時間前倒しします。理由はモデルには知りようがないもので、財務責任者が日曜朝の便で発つからです。

この作業が生むのは完成した計画ではありません。一日で作られた完全な初版であり、重要な人たちがそれに反応できる状態です。ゼロから作り出すのとは、まったく別の問題になります。

AIによる下書き vs パートナーのテンプレート vs 白紙から

• 自社業務への適合 — AIの下書きが有利。テンプレートは一般的な受注プロセスを述べ、あなたが書いた説明は自社のそれを述べます。
• 異常系の網羅 — AIの下書きが有利。ただし明示的に求めた場合に限ります。実務上いちばん大きな利得です。
• 初版までの速さ — AIの下書きが明確に有利。数週間ではなく数時間で、しかもその数週間は他人の会議でできています。
• 実証された構造と網羅性 — テンプレートが有利。他社の導入で何が起きたかが織り込まれており、それは自社にもモデルにもない知識です。
• 間違っていたときの責任 — テンプレートが有利。契約を持つ相手が背後にいることは、稼働前に多くのチームが認める以上に重い意味を持ちます。
• 組織としての学び — 白紙から書くことが、狭い意味で有利です。書けば考えざるを得ません。その効用は本物ですが、六週間の価値はありません。

最も強い組み合わせは明白です。パートナーのテンプレートを骨格にし、AIの下書きで自社のプロセスと例外を埋め、自社の人が直す。導入パートナーを外すべきだという話はどこにもありません。

本番稼働でAIにできないこと

三つあり、それが週末の成否を決めます。

Go/No-Goの判断を担えない。 その判断はデータ品質、業務リスク、要員、顧客への約束、そして全員の疲労度を天秤にかけます。権限を持つ記名の人のもので、しかも誰も追い詰められていない時期に合意した基準に照らして下されるべきです。

自社のデータを知らない。 深刻な稼働トラブルはたいていデータに行き着きます。重複した得意先、合わない未消込、本来の用途ではないものを入れられた旧項目。モデルにはどれも見えず、マスタが綺麗である前提のテストスクリプトを平然と書きます。

現場にいられない。 午前二時に投入が失敗したとき、月曜の朝に最初の請求が起票できないとき、照合が誰にも説明できない金額でずれているとき、そこに人がいなければなりません。それは重要な期間に現場に入り、手を動かす体制であり、まさにハイパーケア支援が提供するものです。稼働とその後の脆い数週間、技術者が常駐します。

ここを外さない——業務情報の扱い、APIキー、そしてITに相談すべき時

プロセスの説明をチャット窓に貼り始める前に、実務上の三点です。

実際に何を開示しているのか。 詳細なプロセスの説明は商業的に意味を持ちます。価格構造、承認の閾値、顧客の取引条件、統制の弱い箇所。構造として説明し、実データ、顧客名、具体的な金額は外に置いてください。ビジネス版やエンタープライズ版を使い、自分が実際に使っている階層のデータ取り扱いと学習の条件を「たぶん」で済ませず読むこと。消費者向けは条件が異なることが多く、条件は変わります。

成果物の置き場所。 UATスクリプトと移行ランブックはプロジェクトの記録です。チャット履歴でも、コンサルタント個人のドライブでもなく、版管理と持ち主のあるプロジェクトのリポジトリに置いてください。次のフェーズ、次の法人への展開、そして「この移行はどう統制されたのか」を問う監査で、また必要になります。

モデルが書き終えたあと、誰が持つのか。 下書きは安いほうの仕事です。業務担当とスクリプトを突き合わせ、データを照合し、週末の要員を組み、稼働後二週間の問題を吸収することが本体で、まさにこの種のプロジェクトのためにAI+サポートとマネージドITサポートがあります。Brocentは2007年の北京での創業以来アジアでマネージドITを提供しており、本社はシンガポール、2016年から香港にも拠点があります。複数法人にまたがるアジア太平洋の展開は、私たちの通常の領域です。

よくある質問

自社の業務プロセスをAIに説明しても安全ですか

説明の仕方と使う階層によります。「受注は分割出荷でき、出荷時に請求する」といった構造の説明は、価格表や取引条件や実レコードを貼ることに比べればはるかに低リスクです。ビジネス版かエンタープライズ版を使い、現在のデータ取り扱い条件を確認し、実データは外に置いてください。契約や規制が許さないなら、自社設置のモデルでも同じ手順が成り立ちます。

導入パートナーが用意してくれるのでは

テンプレートと方法論は用意してくれますし、どちらも使うべきです。パートナーが用意しにくいのは、自社業務固有の例外です。それは社員の中にあります。AIの下書きは、そこを速く埋める手段です。もし業務に即した完全なUATスクリプトを既に出してくれているなら、良いパートナーであり、この話の緊急度は下がります。

AIが書いたテストスクリプトの網羅性はどう確認しますか

スクリプトだけでは確認できません。プロセスに照らして確認します。各プロセスの業務責任者に読ませて足りないものを挙げてもらい、モデルには置いた前提を列挙させ、直近四半期に実際に発生した取引種別と突き合わせます。発生した取引種別を覆うスクリプトがなければ、そこが抜けです。

切り戻し計画には何を書きますか

最後に正常だった状態、そこへ戻す方法、誰が決めるか、どれだけ時間がかかるか、そして「どこを過ぎたら切り戻しは現実的でなくなるか」。最後の項目こそチームが書きたがらず、最も重要です。最初の実取引が計上された後の「切り戻し」は、たいてい「取り消す」ではなく「照合を二回走らせる」を意味します。

Go/No-Goは誰のものですか

記名された一人、多くはプロジェクトオーナーかステアリング委員会の議長が、事前に合意した基準に照らして決めます。基準は週末の数週間前、誰も疲れておらず待機要員に費用も使っていない時期に書いてください。移行当日の土曜14時に会議室で基準を決めることこそ、準備できていないシステムで稼働してしまう道筋です。

他の法人への段階展開にも同じ方法が使えますか

使えますし、そこで二度目の回収が起きます。最初の法人のスクリプトとランブックができていれば、次の国や法人向けに直す作業はずっと小さくなります。差分を説明してモデルに調整させ、現地チームがレビューする。効いてくる差分はたいてい税制、法定報告、承認階層です。

まずどこから

最も件数の多いプロセスを選び、500語で説明し、異常系と前提の一覧を含むUATスクリプトを求めてください。出力をそのプロセスの業務責任者に渡し、どこを消すかを見ます。その反応は初版そのものより価値があり、自社の稼働リスクのうちどれだけが文書の問題で、どれだけがデータの問題かを教えてくれます。「書類は何とかなるが、週末とその後の二週間を担える人がいない」という答えなら、それは早めに始める価値のある要員の話です。お問い合わせください。