この記事の内容
  1. 困っている条件を特定する
  2. 台帳を置き換える候補
  3. 処理を切り出す候補
  4. 一件ずつ関係を検証する
  5. 三人の編集と一人の承認の例
  6. 移行費を回収する条件
  7. 原価以外の採用理由を残す

困っている条件を特定する

課金対象者の増加、保存量、必要な権限、独自処理のどこが問題かを分けます。現行のプランと権限を見直すだけで解決するものもあるため、全面移行と小さな修正を同じ条件で見積もります。ツールを変えても、曖昧な台帳の項目定義は自動では直りません。

台帳を置き換える候補

Baserowを検討する場合は、行の関係、フォーム、権限を代表データで照合します。自己ホストを選ぶなら、基盤、更新、バックアップを引き受ける担当が必要です。無料のライセンスを、今と同じ運営が費用ゼロになるという意味で扱わないようにします。

処理を切り出す候補

独自の計算や定期処理が主な課題なら、Windmillなどの実行基盤を組み合わせる案を検討できます。ただし、実行基盤は台帳や利用者画面の完全な同等置換ではありません。主な台帳をどこへ置き、誰が例外を修正するかを決めてから、複数サービスの構成を比較します。

一件ずつ関係を検証する

顧客と案件を別表で持つ場合、両方の行数だけが一致しても正しく移ったとは言えません。移行元IDと移行先IDを対応させ、関連する相手が同じかを確認します。添付、複数選択、日付、空欄も、見本を使って表現の違いを確かめてください。

三人の編集と一人の承認の例

三人が編集し一人が承認する台帳を移すなら、承認者が必要な操作をできるかを先に確認します。現行の課金対象から外すためだけに、確認の記録を失う権限へ変えないでください。通常の更新、差し戻し、担当交代を同じ確認項目で比較します。

移行費を回収する条件

再構築、データ整理、検証、社内説明を移行費に含めます。月々の差額と保守時間の変化を別々に置けば、節約がどの程度続けば回収できるかを考えられます。設置や管理の要件を満たすことが目的なら、その理由を短期の費用削減と混ぜずに記録します。

原価以外の採用理由を残す

仮に移行費が月々の差額ではすぐ回収できなくても、必要な配置や権限の条件が理由なら、それを明記します。逆に、現在の構成で必要条件を満たす場合は、見積りの少額差だけで再構築を急がない判断もあります。移行後に増える監視、連携、社内説明を別々に並べると、ライセンスだけでは見えない負担が分かります。採用理由と、確認できた事実を同じ比較表へ残してください。

利用量から費用を確かめる

月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。

費用を試算する

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について