乗り換えの検討
Zoho Oneの代替を検討：アプリと管理責任を先に整理する
スイートを一つの切り離せない業務として扱わず、限定した変更を計画します。Tsumiraを試す前に、アプリ、顧客データ、部門の責任を確認します。
製品比較を見るパッケージの判断と日々の問題を分ける
部門ごとにスイートの使い方は異なります。専門アプリへ依存するチームもあれば、顧客情報とプロジェクトの調整を主に必要とするチームもあります。代替を決める前に各部門の問題を記述してください。移行の目的はアプリを多く廃止することではなく、有用な仕事を維持し、依存関係を明確にすることです。
具体的な業務の流れ
組織を整理する
各アプリの責任者と、部門間で受け渡す記録を整理します。試行に適した顧客関連の流れを一つ選びます。
共通モデルを合意する
企業、連絡先、商談を同じ意味で定義します。少量の対応済みデータを取り込み、関係を照合します。
限定した結果を評価する
試行と残るアプリを合わせて評価します。運用範囲が明確になってから契約とアクセスを決めます。
部門とアプリの対応表を作る
各部門が作成、参照、維持する記録を確認します。共通識別子、レポート、アクセス管理など見えにくい依存関係も含めてください。残すアプリ、変える候補、まだ不明なものを分けます。Tsumiraでは顧客関係、案件、会話を評価できますが、人事、商取引、在庫のすべてを置き換えると約束しません。各アプリに業務責任者を置きます。
- すべてのアプリの担当を明確にする。
- 部門を越えて使う顧客識別子を記録する。
正となる顧客モデルを決める
アプリによって顧客、連絡先、プロジェクトの意味が違う場合があります。サンプルの準備前に共通定義を決めてください。Tsumiraの企業、連絡先、商談のCSV経路は、アプリ横断の汎用移行を保証しません。項目、関係、責任者を対応付け、少量で照合します。専門データや過去の参照先は、合意したシステムで利用できるよう残します。
- 取込前に定義の矛盾を解消する。
- 検証済みの取込範囲に含まれないデータを記録する。
利用者と残る環境を評価する
選択的な変更でも、各環境へ誰がアクセスするかは変わります。特定の契約縮小が可能だと考えず、実際の組織と提案を確認してください。入社、責任変更、退社時の権限を管理担当者と試します。Tsumiraの現行財務は整数の日本円と日本の消費税を使い、ドイツ会計の代替は検証されていません。財務は独立した境界として扱います。
- 担当変更後のアクセスを確認する。
- 残すシステムと管理作業を予算に含める。
実務を想定した例
想定例：人事を残して顧客案件を試す
顧客プロジェクトを一か所で扱いたい会社でも、人事部門には既存の専門業務が必要です。試行には顧客情報と一つの案件を含め、従業員管理は対象外にします。最後に、顧客更新の管理元と各部門が使い続けるアプリを記録します。案件の成功をスイート全体の代替完了とは扱いません。
この機能についての質問
すべてのアプリに代替が必要ですか。
必ずしも必要ありません。問題に関係するアプリと、現在も重要な条件を満たすアプリを分けます。依存関係が明確なら限定した変更も可能です。
書き出した表を全部結合すればよいですか。
定義や識別子が異なる場合があります。対応表を作り、重複を整理し、少量の取込でも関係を確認してください。
いつライセンスを見直しますか。
計画の初期に条件を確認し、運用範囲が決まってから対象者とアプリで再確認します。契約変更を提供者の確認なしに想定しないでください。
有用な試行の結果とは何ですか。
チーム間の定義した業務を実証し、対象外を明らかにすることです。残すアプリや未解決の専門要件があっても、無理に全面移行する必要はありません。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
