スマート給餌器は、ベンチテストをすべて合格しても、数年後に顧客を失望させることがあります。モーターは動き、フタは密閉され、給餌量は正確に出ます。しかし、アプリのアップデート、クラウドポリシーの変更、ライセンスの期限切れによって、正常に動作していた機器がサポート対応件(チケット)に変わることがあります。
ファームウェアは、QCレポートに現れない部分です。ハードウェア発注前に、ファームウェア固有の条件を書面で定めておく必要があります。
サポートの時間は最後の梱包後から始まる
QCは目の前のユニットを検査します。ファームウェアサポートは、ユニットが出荷された後の挙動に関する約束です。リスクは最終生産ロットの後にピークに達します。この時点でエンジニアリングの注意は次のモデルに移り、旧SKUは倉庫や小売店の棚に残ったままだからです。
だからこそ、最初の質問は「アプリは良いか?」ではありません。「最終出荷後、何年間重大なバグを修正するか、何を重大と定義するか?」が質問です。サプライヤーは、年数、重大度の定義、担当者の名前で回答できます。あるいは「当社は製品をサポートしています」と回答しますが、これは強制力を持ちません。
製品は、梱包がまだ流通チャネルにある間に生産終了(EOL)を迎えることもあります。EOL通知は、小売業者に在庫を販売し切る、顧客に警告する、代替品を計画する時間を与える条項です。この条項がなければ、最初の通知は「アプリが接続できない」という形で届くことが多いのです。
コード、アプリ、鍵の所有者は誰か
力関係を決める資産は3つあります。ファームウェアは、バイヤーがライセンスを受けるが決して所有しない工場のコードベースに置かれることがあります。プライベートラベルアプリは通常、期間、更新価格、解約条項を持つライセンスであり、バイヤーが永久に保持できるソフトウェアではありません。OTA署名鍵は、誰がアップデートを配信でき、不良リリースで文鎮化したユニットを誰が復旧できるかを決めます。
着金前に、ライセンス文書と簡潔なIP要約を求めてください。期間満了時に何が起こるかを確認してください:アプリは停止するか、新しい価格で更新されるか、移転するか?鍵を誰が保持するか、工場がプラットフォーム提供者を変更した場合どうなるかを確認してください。購入にソフトウェアが含まれていると想定すると、後でそのギャップに気づくことになります。
6Lスマートペット給餌器(アプリ制御)は、価値が両方の部分に依存する製品の好例です。ホッパーとモーターは目に見えます。アプリ、クラウドアカウント、アップデート経路は見えません。まさにそれが、契約書に盛り込むべき理由です。
1ページの附属書に盛り込むべき5つの条項
ファームウェア附属書はソフトウェアライセンス契約である必要はありません。5つの見出しと、双方が約束が守られたかどうか判断できる程度の具体性があれば十分です。
サポート期間。最終出荷後何年間、サプライヤーがバグ修正とセキュリティパッチを提供するかを明記してください。セキュリティ修正と機能アップデートを分けてください。サプライヤーは一方にのみコミットする場合があります。重大を定義してください。ペアリングできない、給餌できない、復旧できない機器は、外観上のアプリ問題とは重大度が異なります。
バグ修正のサービスレベル。重大度レベルと対応日数または修正日数を明記してください。エンジニアリング作業を誰が負担し、誰がアップデートを配信するかを明記してください。期限のない「バグを修正する」という約束は、感情に過ぎません。
OTA頻度。セキュリティパッチの提供頻度、リリースが顧客に届く前に誰が承認するか、アップデート失敗時の復旧経路について合意してください。アップデートがクラウドサービスに依存する場合、そのサービスを誰が支払うか、請求が未払いの場合どうなるかを明記してください。
データエクスポートと移行。プラットフォームが閉鎖した場合、給餌スケジュール、機器設定、ユーザーアカウントは機械可読形式で取り出せるべきです。移行先と通知期間を明記してください。給餌器が最後のスケジュールで動作し続けるローカルフォールバックにより、シャットダウンが機能低下した製品に変わります。
生産終了通知。サポート終了前の書面通知、最終アップデート日付、オフラインで動作し続ける機能の明示を要求してください。通知期間は、メールを送れる程度ではなく、在庫を販売し切れる程度の長さであるべきです。
サプライヤーがすでに附属書を持っている場合は、ゼロから起案するのではなく修正を加えてください。重要なのは交渉の儀式ではなく、署名された1ページです。
Tuyaは工場クラウドと同じリスクではない
Tuyaベースの製品は、既存のアプリとクラウドを持つ大規模なサードパーティプラットフォーム上で動作します。供給途絶リスクは小規模な単一工場より低いですが、ルール変更リスクは現実です。API価格設定、アプリストアポリシー、機能廃止はすべて、発売後に動く可能性があります。緩和策は契約上のものです:仕様にプラットフォームバージョンとSDKを明記し、破壊的変更の前に書面通知を要求し、移行経路を書面で保持してください。
独自または工場ホストのクラウドは、バイヤーにより多くの制御を与えますが、工場のソフトウェアチームへの依存も生みます。工場がこのカテゴリから撤退したり、アプリを作ったエンジニアを失ったりすると、製品はバックエンドを失う可能性があります。フォールバックとして、ソースコードエスクローまたはビルド引き継ぎを求めてください。どちらの選択肢も自動的に安全なわけではありません。正しい選択は、バイヤーがソフトウェアを運用する能力を持っているかどうか、所有する意欲があるかどうかに依存します。
4L自動給餌器(Tuyaアプリ制御)とカメラ付きWiFi給餌器は、このスペクトラムの異なる位置にあります。スタックが異なっても、問うべき質問は同じです。
附属書はカタログではなく発注書に
附属書をRFQとともに送り、サプライヤーに例外をマークするよう求めてください。ページを編集するサプライヤーは真剣に取り組んでいます。「lifetime(生涯)」という言葉が書かれたカタログを送るサプライヤーは、質問を避けています。双方が合意したら、附属書を発注書に添付し、署名済みコピーをSKUファイルとともに保管してください。
ソフトウェアの質問は、すべての注文規模で当てはまります:OEMは1,000台から、ODMは3,000台から、プライベートラベルトライアルは50台からです。ファームウェア条件は金型とパッケージと一緒に範囲設定してください。発売後に追加されたサポートの約束は、再交渉だからです。
「lifetime(生涯)」という言葉には注意してください。何の生涯かを問うてください:製品、アプリ、プラットフォーム、それとも会社?定義のない用語はコミットメントではありません。年数、重大度表、通知期間がコミットメントです。
サポートが停止したとき小売業者が払うもの
アプリが動かなくなったとき、顧客は工場に電話しません。箱に書かれた小売業者またはサポートラインに電話します。コードは別の誰かのものですが、小売業者は対応件、返品、レビューを吸収します。これこそ、クレーム段階ではなく購買段階でファームウェア条件を交渉する商業的理由です。
附属書は法的な追加費用としてではなく、ランディングコストの一部として価格設定してください。1回のサポートサイクル、1回の返品バッチ、1回の再発売のコストと比較してください。附属書は通常より安い項目であり、プラットフォームが方向転換したときバイヤーが指し示せる文書を与える唯一のものです。
ロードマップは計画であり、附属書がコミットメントです。機能の約束ではなく、サポートのコミットメントを求めてください。質問は、発売日にアプリが良いかどうかではありません。数年後に壊れたとき、誰が答えるかです。
附属書署名前に決めておく質問
OEMプログラムでファームウェアの所有者は誰か?
給餌器ボードのファームウェアは、発注書が権利を定めない限り、通常は工場に留まります。プライベートラベルアプリは通常、期間付きのライセンスであり、OTA署名鍵は工場またはプラットフォームに留まる可能性があります。各資産、所有者、ライセンス期間、移転条件を明記したIP要約を求めてください。
ファームウェアサポート期間はどのくらいにすべきか?
期待するサービスライフと提供する保証に合わせ、対象範囲を定義してください。セキュリティパッチと重大なバグ修正は全期間にわたって実施されるべきです。機能アップデートは早く終了しても構いません。定義と救済措置が、数字よりも重要です。
プラットフォームが閉鎖した場合ユーザーはどうなるか?
条項次第です。データエクスポート条項は、スケジュールとアカウントを使える形式で取り出します。移行条項は移行先を明記します。ローカルフォールバックは、クラウドなしで機器が中核業務を続けられるようにします。通知条項は、小売業者に顧客に伝える時間を与えます。4つすべてを求め、最初の注文が出荷される前にフォールバックをテストしてください。
接続型SKUを調達している場合は、見積りとともにファームウェア附属書を求めてください。当社はハードウェアを見積もり、書面でサポートできるソフトウェア条件を明記します。金型が始動する前に、サポートの質問が解決されるようにするためです。
