受発注、在庫、現場報告、品質確認、承認、記録、請求前確認、社外連携のうち、先に対応する範囲を扱います。
見積前の確認
費用が動く条件を揃えます
金額を自動算出するのではなく、最初に扱う範囲、既存環境、関係者、データ、保守改善の有無を分けます。
Microsoft 365、kintone、Salesforce、WordPress、Shopify、Azure など、利用中の製品、データ、権限、外部連携、保守状況を把握し、活かすものと作り替えるものを分けます。
緊急対応、現状確認、技術検証、構築、保守改善のどこから入るかを扱います。
不安を減らす
いきなり全体刷新にしないための費用設計です
費用ページの役割は、金額表を置くことではなく、見積前の不安を減らすことです。高くなる理由、抑えられる理由、先に試す範囲を分けます。
Pricing Presentation
大きな投資を、小さく始められる前提へ。
基幹業務システムは範囲を誤ると大きくなります。だからこそ、最初に扱う業務、既存資産、技術検証、保守改善を分けて費用を見ます。
画面数や人月だけでまとめると、既存活用、外部連携、AI利用、保守改善のどこが費用に効くか見えません。
残すもの、つなぐもの、作るもの、先に試すものを分け、段階的に進める費用の前提を作ります。
見積前に分けること
- 最初に扱う業務
- 既存資産を残す範囲
- 外部連携の重さ
- AIやカメラの利用条件
- 保守改善の含め方
- 小さく始める単位
対象業務を送ると、見積前提を分けられます
見積前提を送る金額が動く前提を整理し、見積前に社内で話せる状態にします。
根拠情報を開く
モデル名や数字だけで提案するのではなく、入力量、出力量、リクエスト数、可用性を分けて扱います。
Container Apps、App Service、Static Web Appsなど、ブラウザで触れる業務画面や検証画面を動かす基盤を案件ごとに分けて構築します。
担当者単価、確認時間、差戻し回数、会議、再確認、管理者の催促時間を分けます。見えにくい管理コストを、件数と時間で仮置きします。
費用の考え方
費用が変わる主な条件
開発運用費、技術利用量、クラウドリソース、既存環境、保守改善を分けています。社内で確認したい条件から見られます。
前提費用を動かす条件を分ける緊急性、権限、既存システム、データ量、技術活用の範囲、保守範囲、導入後の運用定着など、見積に影響する条件を扱います。開発運用開発運用費の内訳業務分析、開発オペレーション、技術利用量、クラウド・ハードウェア利用を分けています。実測技術利用量とリソースを見積前提にするモデル利用量、リクエスト数、可用性、DB、ストレージ、認証、外部APIを費用前提として分けます。比較人件費・管理工数と並べて比べる確認時間、差戻し、会議、追跡工数と、開発運用・技術利用量・リソース費用を並べて検討します。見積見積判断へ進む確認順目的、前提、技術利用量、リソース、運用に残す情報、体制、KPIを順に扱います。