レンタルソフトウェアのデモンストレーションは、実際のフリート（保有機器）を反映するよう求めない限り、説得力があるように見えるかもしれません。貴社のカタログには、複数の同一のバウンサー、共有アイテムを使用する組み合わせパッケージ、およびメンテナンス待ちの機器が含まれている場合があります。重要な疑問は、システムがそれらの手配を貴社のチームが理解し、維持できる方法で処理できるかどうかです。
インフレータブルレンタルソフトウェアの選択は、購入プロジェクトです。ビジネスのニーズを定義し、ベンダーにデモンストレーションを依頼し、各システムを導入し、最終的に移行するために必要な作業を比較します。機能リストはその議論の出発点となり、記録された試用版は意思決定に役立ちます。
ソフトウェアが今日サポートすべきビジネスを記述してください。いくつの拠点、人員、販売チャネルがアクセスを必要とするか、既に利用しているツール、そしてどの記録を移行する必要があるかを記録します。ベンダーが宣伝するすべての機能から始めるのではなく、繰り返される手動入力や数量に関する不確実性など、システム変更を正当化する問題を特定します。
製品と個々の資産をどのように区別するかを説明してください。複数の商業用バウンサーモデルは、それぞれ複数の物理的なユニットを持つことができますが、パッケージは個別に利用可能なアイテムを組み合わせる場合があります。プロバイダーに、その製品がどのような手配をサポートしているか、そしてそれらの手配が可用性にどのように影響するかを尋ねてください。
各要件を「必須」、「有用」、または「初期導入範囲外」としてマークします。それを評価する担当者の名前を挙げてください。予約管理者は明確な空き状況表示を必要とするかもしれませんが、管理者は利用可能な支払い記録を必要とします。営業担当者が一人の問題に対するソリューションを提示する前に、相反する期待を解決してください。
既存の手順が要件を提供します。完全な予約期間と予約の競合に関する当社のガイドは、基盤となるスケジューリング制御について説明しています。ソフトウェア評価では、提案されたシステムがその制御を一貫して表現できるかどうかを問いかけます。
架空の顧客詳細と明確にラベル付けされたテスト記録を使用して、試用シナリオの小さなセットを準備します。各シナリオの期待される結果を含め、その後、ベンダーに、既に成功した予約が入力された準備済みの画面ではなく、完全なシーケンスを表示するよう依頼します。
数量の可用性から始めます。カタログに含まれるよりも多くのユニットを重複する問い合わせが要求した場合に何が起こるかを尋ねます。一時的な保留が期限切れになるか確認されるまで追跡し、その後、イベントの日付を変更し、結果として生じる可用性を検査します。各段階でスタッフが何を見るか、そしてどの設定が結果を決定するかを確認します。
次に、メンテナンスのために利用できないユニット、および他のオファーとコンポーネントを共有するパッケージをテストします。商業用コンボインフレータブルの場合、物理的な製品とそれを含む販売パッケージを区別してください。プロバイダーに、どのアイテムが予約されているか、そしてチームがジョブに割り当てられた機器をどのように識別するかを説明するよう依頼します。
変更またはキャンセルされた予約で締めくくり、それを処理するために必要なスタッフの役割を確認します。必要な動作がデモンストレーションされたか、ベンダーによって説明されたか、または未解決のままであるかを記録します。これらは提案された受け入れテストであり、特定の製品がすべてのシナリオをサポートするという主張ではありません。
サポートされているインポート形式と、それが受け入れるフィールドを尋ねます。その形式を、既存の製品、顧客、および将来の予約記録の小さなサンプルと比較します。何がインポート可能か、何がマッピングを必要とするか、そして何が手動入力を必要とするかを特定します。
識別子、数量、日付、タイムゾーン、および予約状態に注意してください。プロバイダーが、インポートされた記録が既存の予約の2番目のコピーを作成するのをどのように防ぐかを尋ねます。インポートされた結果を、作業記録として受け入れる前にレビューする方法を要求します。
ユニットIDと資産ステータス記録を使用して、移行後も保持する必要がある情報を定義します。新しいシステムが個々のユニット、製品数量、または別の構造を表しているかを確認します。「在庫」という名前の項目が、既存のメンテナンス履歴や割り当てを保持すると仮定しないでください。
試用インポートを誰が実行し、誰がチェックし、エラーがどのように修正されるかを合意します。スタッフが古いシステムでの新しい作業の入力を停止し、新しいシステムの使用を開始する時点を計画します。転送が意図したとおりに完了できない場合に備えて、日付付きのベースラインと合意された回復アプローチを保持します。
実際に使用する構成について書面でのオファーを要求します。どの機能が基本サブスクリプションに属し、どの機能が別のモジュール、サービス、またはプロバイダーを必要とするかを尋ねます。その会話に、オンボーディング、ウェブサイト作業、支払い手配、スタッフアクセス、およびサポートを含めます。
製品カテゴリは重複する可能性がありますが、同等ではありません。InflatableOfficeは、予約、配送、在庫、顧客管理の機能が挙げられています。InflateMateは、予約管理、数量管理、メンテナンス関連のアイテムステータスについて説明しています。プロバイダーの説明を使用して質問を準備し、その後、提供された特定の構成を確認します。
製品、ユーザー、または拠点を追加した場合に料金がどのように変化するかを尋ねます。オプションサービスおよび支払い処理に関する条件を、担当プロバイダーと確認します。安価なサブスクリプションは、より多くの設定や継続的な手作業を必要とする場合があります。想定される節約ではなく、自社の人員配置の期待値を使用してそれらの要求を比較してください。
各統合について、他のアプリケーションと、それらの間で移動する必要がある情報を挙げてください。方向、タイミング、エラー、およびサポートの責任について尋ねます。統合ページ上のロゴは、必要な記録が正確に必要なワークフローを通じて移動することを保証するものではありません。
各スタッフの役割に、試用に必要なアクセス権を与えます。その役割を持つユーザーに重要な変更を試みさせ、その後、システムが何を許可し、何を記録するかを確認します。管理者の視点に頼るのではなく、スタッフが実際に使用するアカウントでテストしてください。
サポートリクエストがどのように提出されるか、いつ支援が利用可能か、そしてオンボーディングに何が含まれるかを確認します。初期設定後に誰が設定を維持するかを特定します。構成を理解している唯一の担当者が退職した場合でも、チームはそれを管理するための実用的な方法を必要とします。
契約する前に、解約した場合にどのようなデータを取得できるかを尋ねます。利用可能な形式、含まれる記録、料金、タイミングを要求し、可能であれば代表的なエクスポートをテストします。履歴文書および契約に基づいて提供されたウェブサイト資産へのアクセスを明確にします。プロバイダーの回答をオファーと一緒に保管し、将来の移行が緊急になるまで、出口に関する議論を放置しないでください。
すべての候補者に対して1つのスコアカードを使用します。必須のギャップはオプションの利点とは別に記録し、長い機能リストが不足している要件を隠すことがないようにします。
| レビュー項目 | 記録すべき内容 |
|---|---|
| 要件 | ビジネス課題、期待される結果、必須またはオプションのステータス |
| 証拠 | 文書参照または試用日と観察された動作 |
| 確認状況 | デモンストレーション済み、ベンダー説明済み、または未解決 |
| 導入作業 | データ準備、構成、トレーニング、担当者 |
| 商用条件 | 提供範囲、定期的な料金、オプションサービス |
| 未決定事項 | ギャップ、フォローアップ担当者、受け入れ条件 |
確認された機能と導入作業が自社の運用に合致するオファーを選択します。必須の疑問が未解決のままである場合は、コミットする前に回答または別のデモンストレーションを入手してください。導入のために合意された構成とテスト記録を保持します。
フリートに機器を追加する際は、サプライヤーに、カタログ用にどのようなモデル、構成、梱包情報を提供できるかを尋ねてください。正確な機器データは、管理する製品に対してシステムを評価するのに役立ちます。ソフトウェアの選択は、提案されたサービスがビジネス要件をどのように処理するかに依然として依存します。