第三回でクリーニングは完了しました。名称は統一され、日付は一つの形式にそろい、数値は本当の数値になり、以前はセルの色に込められていた意味は書き込まれた項目に変わりました。データは移行できる状態です。残っているのは、移行が静かに終わるか、何週間もの混乱になるかを決める判断です。何から移行するか？

これは導入担当者のための技術的な細部のように見えます。しかし実際には業務上の判断であり、決めるのはあなたです。あなたの会社は移行のために止まってはくれません。顧客は注文し、請求書は発行され、仕入先は納品します。しかもそのすべてが、データの半分がある場所に、残りの半分が別の場所にある状態で行われます。正しい順序こそが、その期間を全員が二度働く期間ではなく、管理可能な期間にするものです。

一括移行がうまくいかない理由

その発想は理解できます。週末にすべてを移し、日曜日に新システムで業務を始めて終わり。このシナリオは、システムの品質とはまったく関係のない三つの理由で、たいてい失敗します。

第一に、移行中には予想以上のことが見つかります。どの移行でも、誰も気づいていなかった欠落データが表に出てきます。税番号のない顧客、単位のない品目、参照番号のない請求書。すべてを一緒に移せば、そうした発見がすべて同時に、最も余裕のないタイミングで押し寄せます。

第二に、チームはシステムを運用しながら学びます。新しいツールを一日で使いこなせる人はいません。一括移行は全員にすべてを同時に覚えることを求めるため、エラーが出たときにその原因が分かりません。データが間違っているのか、システムの設定が間違っているのか、それとも担当者がまだ画面を理解していないだけなのか。

第三に、後戻りの道が残りません。二日後に根本的な欠陥が見つかった場合、選択肢は無理に押し進めるか、完全に元に戻すかしかなく、どちらも高くつきます。段階的な移行なら、業務の一部は常に安定した足場の上にあります。これは行き詰まるシステムプロジェクトに繰り返し見られるパターンの一つです。問題がツールにあることはまれで、たいていは同じ日にすべてを変えようとすることにあります。

トランザクションより先にマスター：順序全体の土台となるルール

データには二種類あります。マスターデータ：顧客、仕入先、品目やサービス、従業員、勘定科目表。そしてトランザクションデータ：請求書、受注、発注書、在庫の移動、入金。

両者の違いは重要度ではなく方向です。トランザクションデータは常にマスターデータを指します。すべての請求書は顧客と品目を指し、すべての発注書は仕入先を指します。その逆は決して成り立ちません。だから順序を決めるのは好みではなく依存関係です。マスターを先に移してください。存在しないものの上にトランザクションを載せることはできないからです。

順序を逆にすると、典型的な失敗が起こります。三千件の請求書を取り込むと、システムは請求書に書かれた名前ごとに新しい顧客を自動作成し、結果として同じ会社が三通りの表記で三回登録された顧客リストができあがります。第三回をまるごと使って片付けたのとまったく同じ混乱を、システムの中で再現したことになります。しかも今度は修正がより困難です。

実際の順序は次のとおりです。

  • 第一：中核となるエンティティ。顧客、仕入先、品目、サービス。短いリストなので、一度移して目で確認します。これが他のすべてを支える層です。
  • 第二：期首残高。各顧客があなたにいくら支払うべきか、あなたが各仕入先にいくら支払うべきか、開始時点の在庫数量、各勘定の残高。これは履歴ではなく、システムが出発するゼロ地点です。そのための特定の日付を一つ決め、それを守ってください。
  • 第三：未完了のトランザクションのみ。今まさに動いているもの。まだ納品していない受注、まだ回収していない請求書、まだ入荷していない発注書。チームが毎日触れるのはこれであり、想像よりはるかに少ない量です。
  • 最後に、あるいは移さなくてもよい：過去のアーカイブ。過年度の完了済み請求書です。

過去のアーカイブ：何週間も節約できる問い

移行で最も多くの時間と費用を消費する単一の要因は、会社の全履歴を新システムに持ち込もうとするこだわりです。その判断の前に置くべき問いはこれです。その履歴で、実際に何をするのか？

答えが参照するため、あるいは法定の確認のために必要というものであれば、アーカイブはすでにそのままでその役割を果たしています。元の形式のまま、既知で検索可能な場所に保存されているからです。あなたの法定義務は、ザカート・税関総局（ZATCA）が定めるとおり、請求書と記録を保存し、求められたときに提出できることであり、そのすべてが新システムの中にあることではありません。

答えが今年と過去の年を比較するレポートが欲しいというものであれば、必要なのは履歴の全部ではなく一部であり、たいていは請求書の明細行ごとではなく集計レベルで足ります。この二つの移行の違いは、作業量でも費用でも大きなものです。

実務上のルールはこうです。意思決定の基礎にする履歴を移し、残りはアーカイブとして保管する。アーカイブの移行を本番稼働の前提条件にしないでください。それは後からプレッシャーなしで行えますが、本番稼働は無期限に先延ばしできません。

並行稼働：必要だが、開いたままにすると危険

並行稼働とは、決められた期間、取引を新システムと古いファイルの両方に同時に記録することです。その目的はただ一つ、システムがすでに把握している結果と同じものを出すことを確認することです。その週の売上合計、顧客残高、一つか二つの品目の数量を比較します。数字が一致すればシステムは正しく動いており、食い違えば、誰かが誤った数字に基づいて判断を下す前にそれに気づけます。

しかし並行稼働には現実のコストがあります。チームが二度働くことです。そのコストは二週間なら許容できますが、三か月続けば破壊的です。危険は労力だけではありません。しばらくすると二重入力は崩れ始めます。誰かが一方に記録して、もう一方を後回しにする。こうして二つの記録はずれていき、どちらが正しいのか分からなくなるため、この取り組みは完全に意味を失います。

だからここで重要なルールは一つだけです。初日から全員に終了日を宣言した並行稼働です。日付を書き留め、チームに伝え、延長するのは書面の理由を伴う明確な判断によってのみ。なし崩しには決して延ばさないでください。期限のない期間は慎重さではなく、先送りされた判断であり、新しいシステムが丸一年、中途半端にしか使われない最もよくある原因です。これは、システムを段階的に導入するガイドで詳しく取り上げたチェンジマネジメントの取り組みの一部です。

Origami の視点

スプレッドシートで業務を回している会社のためにカスタムシステムを構築するとき、私たちは移行計画をプロジェクトの最後の実行ステップではなく、設計の一部として扱います。なぜなら、移行の順序はシステム自体の構造に関する判断を迫るからです。どのエンティティが単独で成り立たなければならないか、どの項目が一時的に不完全であることを許容しなければならないか、そしてどこで記録を重複させない繰り返し実行可能なインポートが必要か。

また、開始前に古いファイルを閉じる日付をクライアントと決めておきます。その日付こそが、プロジェクトを並行実験から実際の移行へと変えるものだからです。これは段階的なデジタル化のロードマップで取っているのと同じアプローチであり、私たちのサービス全体に及びます。各フェーズは、最後にはすべてが動くという約束ではなく、実際に動くものを届けます。

移行の成功を教えてくれるサイン

移行がうまくいったかどうかは、完了報告や移行率からは分かりません。誰も求めていない行動から分かります。従業員が、言われてもいないのに古いファイルを開かなくなることです。必要なものにたどり着く最も速い道だからという理由で、システムが朝一番に開くものになったとき、移行は本当に実現しています。すべてが移されているのに毎朝ファイルを開き続けているなら、進捗の数字が何を示していようと、移行はまだ実現していません。

数字よりもそのサインを見てください。そして人々が古いファイルに戻っていると分かったら、その理由はたいてい抵抗ではありません。システムが彼らに必要なものを提供していないか、提供が遅いか、手順が多いのです。それは解決できる原因ですが、早く気づいて尋ねた場合に限ります。

この先の回では

データは正しい順序で移行され、ファイルの世界にはなかった問いが現れます。ファイルを開いた人はその中のすべてを見られますが、システムは誰が何を見るかを決めます。次回は権限について。給与、利益率、顧客データ、そしてそれぞれを誰が見られるか。その後、毎月手作業で作っていたレポートに進み、移行後の最初の三十日でシリーズを締めくくります。

出典