Pour une commande d’équipement de stationnement OEM, approuvez plus que le logo. Définissez les modifications, les logiciels et les documents à livrer, les utilisations pour lesquelles votre entreprise a besoin d’autorisation et la configuration exacte des échantillons de produits physiques que la production en masse doit suivre. Convenez ensuite de la manière dont les substitutions et mises à jour logicielles ultérieures seront examinées.
Une armoire peut sembler identique tout en transportant un contrôleur, une version de micrologiciel ou un comportement d’interface différent. Un compte de démonstration peut fonctionner sans résoudre la distribution de marque ou la maintenance indépendante. Une approbation OEM utile relie donc trois éléments : une portée définie, un échantillon de référence de produit physique identifiable et un itinéraire contrôlé pour les modifications.
Transformez la personnalisation en une liste de livrables
Commencez par le produit de base et les marchés où il sera vendu. Précisez si la demande concerne une barrière, une caméra ANPR, un afficheur, une borne de paiement ou une combinaison. Séparez les options existantes des nouveaux développements et demandez au fournisseur de marquer chaque élément comme inclus, facultatif, indisponible ou fourni par un tiers.
Utilisez cette matrice comme point de départ. Ajoutez un fichier de référence ou une révision, un propriétaire d’approbation et un statut de devis à chaque modification demandée.
| Portée | Définir avant la production d’échantillons de produits physiques | Preuve d’approbation |
|---|---|---|
| Armoire et image de marque | Modèle, référence de couleur, traitement de surface, illustration, position du logo et utilisation autorisée des actifs de la marque | Révision approuvée du dessin ou de l’illustration et échantillon de produit physique identifié |
| Écran et langue | Fichier de traduction, polices, états d’écran, messages d’erreur, unités et qui fournit le texte | Fichiers approuvés et captures d’écran de la version logicielle convenue |
| Comportement fonctionnel | Flux de travail, paramètres et exceptions requis ; distinguer une fonction modifiée d’une étiquette modifiée | Scénarios convenus, résultats attendus et résultats d’échantillons de produits physiques enregistrés |
| Interfaces | Version du protocole, de l’API ou du SDK, champs d’événement, configuration prise en charge et propriétaire de l’intégration | Documents versionnés et résultats avec le système homologue prévu |
| Emballages et étiquettes | Illustration du carton, dénomination du modèle, traçabilité des séries, contenu et responsabilités en matière d’étiquette spécifiques à la destination | Illustrations approuvées, liste de colisage et emballage physique des échantillons de produits |
| Documents et prestations | Langue du manuel, diagrammes, références de pièces de rechange, informations de mise à jour et transfert de support | Une liste de fichiers de livraison versionnée avec un propriétaire nommé pour les éléments manquants |
Enregistrez l’outillage, le développement unique, les frais d’échantillons de produits physiques, les frais de licence récurrents, les quantités minimales et les délais de livraison par rapport à la portée convenue. Demandez qui contrôle les fichiers d’outillage et de conception, si une exclusivité est offerte et quels produits, marchés ou périodes elle couvre. Ne laissez pas ces décisions dans une phrase générale telle que « Service OEM inclus ».
Convenez séparément des livrables logiciels et des usages autorisés
Un fichier logiciel, un compte administrateur et une autorisation de distribuer un logiciel répondent à différentes questions. Pour chaque application, progiciel, SDK et runtime requis, demandez les conditions applicables et les livrables nécessaires à votre propre équipe et aux clients en aval.
- Utiliser et installer : Quels produits, clients et modalités de déploiement peuvent utiliser la version livrée ? Qui fournit l’accès à l’activation, à la récupération et au remplacement des appareils ?
- Marquer et distribuer : pouvez-vous utiliser votre nom dans l’interface, l’installateur, les manuels et le package client ? Quels fichiers peuvent être transmis aux clients ou aux installateurs locaux ?
- Intégrer : Quels SDK, documentation API, exemples et fichiers d’exécution sont fournis, et lesquels d’entre eux peuvent être redistribués ? Qui maintient l’intégration lorsque l’un ou l’autre côté change ?
- Modifier et maintenir : Le code source est-il inclus, qu’est-ce qui peut être modifié et qui peut créer et prendre en charge la version modifiée ? Si une maintenance indépendante est requise, identifiez les instructions de construction convenues, les dépendances et les matériaux de transfert.
- Composants tiers : demandez les informations sur les composants, leurs versions et licences, les mentions requises, ainsi que le code source ou une offre écrite de le fournir lorsque les conditions applicables l’exigent. Confirmez les restrictions et les obligations de fourniture des éléments requis pour les composants réellement utilisés.
La réception du code source ne rend pas en soi un produit open source. Le Définition de l’Open Source Initiative traite également des autorisations de redistribution et de modification. Établissez les conditions réelles du package livré plutôt que de supposer qu’un paiement de personnalisation, un accès au code source du logiciel ou un nouveau logo règle chaque autorisation.
Distinguez dans l’accord la technologie préexistante du fournisseur, les créations graphiques apportées par l’acheteur et les nouveaux travaux de développement commandés pour le projet. Si la propriété des droits, l’exclusivité ou un développement indépendant ultérieur sont importants, définissez les livrables et les droits envisagés avant d’autoriser le développement. Pour les limites de licence, mises à niveau et frais récurrents, consultez la liste de contrôle pour les licences de logiciels de stationnement.
Approuver un ensemble de référence, et pas seulement un échantillon de produit physique de salle d’exposition
Donnez à l’échantillon physique du produit une référence unique et enregistrez son identité physique. Liez-le aux dessins, illustrations, configuration matérielle, version et paramètres du micrologiciel/logiciel approuvés. Incluez les versions des documents d’interface, des manuels, des étiquettes et des emballages qui lui appartiennent. Conservez un dossier d’approbation daté reliant ces fichiers à l’identifiant physique de l’échantillon de produit. Lorsqu’une nomenclature détaillée ne peut pas être partagée, convenez quels identifiants de composants critiques et modifications doivent rester traçables.
Conservez les résultats à côté de cette configuration. Une vidéo montrant l’ouverture d’une armoire ou un écran traduit est une preuve utile de cette démonstration, mais elle ne décrit pas tous les flux de travail requis ni ne prouve que chaque unité de production correspondra. Sélectionnez les contrôles parmi la personnalisation convenue : par exemple, les longs messages traduits sur l’écran réel, les champs d’événement spécifiés avec le logiciel prévu et la dénomination du modèle approuvé sur les étiquettes et les manuels.
Explicitez la décision : approuvé pour production, approuvé avec les conditions énumérées, ou non approuvé. Chaque point non résolu exige un responsable, des preuves attendues et un point de clôture. Un écart d’aspect accepté pour un échantillon ne permet pas de modifier toute la commande.
Ce dossier compact peut être ajouté à la documentation d’achat. Les entrées ci-dessous sont des champs à remplir, et non une approbation terminée.
Fiche d’approbation d’échantillon OEM Commande / produit / identifiant d’échantillon : Matériel et composants critiques : Micrologiciel / version de l’application / réglages : Révisions graphiques / documents d’interface / manuel / emballage : Vérifications convenues et références aux fichiers de résultats : Points non résolus / écarts permis / responsables de clôture : Décision de production / approbateurs / date : Commande en série ou lots couverts par cette approbation :
Définissez le parcours du changement jusqu’à l’autorisation de production
Figer une version de référence consiste à conserver la configuration convenue tout en gérant les mises à jour suivantes. Cela ne doit empêcher ni les correctifs de sécurité nécessaires ni le remplacement d’un composant indisponible. Convenez des changements à notifier, de ceux à approuver avant production et du traitement des mises à jour urgentes.
Pour une modification proposée, enregistrez la raison, les anciens et nouveaux identifiants, les produits ou lots de production concernés, ainsi que l’effet sur la fonction, l’ajustement, les interfaces, la marque, les documents et le service. Nommez la personne qui décide si un nouvel échantillon physique de produit ou un contrôle plus approfondi est nécessaire. Enregistrez la décision qui en résulte et la première livraison à laquelle elle s’applique.
Par exemple, un contrôleur de remplacement proposé peut laisser l’apparence de l’armoire inchangée tout en affectant la synchronisation des événements, la récupération de la configuration ou une procédure de service. Vérifiez les comportements concernés avec la configuration prévue avant de l’accepter comme équivalent. Une correction orthographique d’un carton nécessite généralement une révision des illustrations et des documents d’emballage, plutôt que de répéter des tests fonctionnels sans rapport. Les preuves doivent suivre les conséquences du changement.
Enregistrez un écart accepté avec sa portée spécifique, la quantité affectée ou les lots et conditions de production. Gardez-le séparé d’une révision de référence permanente. Sinon, une exception sur une commande peut devenir une norme non documentée lors de la prochaine expédition.
Reliez la livraison en série à la version approuvée
Convenez de la manière dont les unités entrantes seront retracées jusqu’à la configuration approuvée pour la production. Faites correspondre les références de commande, les enregistrements de lots de série ou de production, les identifiants matériels/logiciels pertinents, les étiquettes et les fichiers livrés. Définir le plan de contrôle à réception ou d’échantillonnage avec le fournisseur en fonction de la commande et de ses risques ; un échantillon de produit physique approuvé ne remplace pas ce plan.
En cas de divergence, identifiez et conservez le périmètre concerné pendant que les parties responsables décident de le corriger, de le remplacer ou de l’accepter en vertu d’un écart documenté. Enregistrez ce qui a été réellement livré et approuvé avant d’approuver ces unités d’équipement pour l’étape suivante. Conservez les informations de configuration finale à la disposition de l’équipe de service, y compris les pièces de rechange compatibles et l’itinéraire pour les futures mises à jour logicielles.
Préparer une demande OEM ciblée
SHUNJIE propose publiquement une personnalisation OEM/ODM en termes d’apparence, de fonctions, de langue, de logiciels et d’intégration de systèmes. Traitez cette offre comme le point de départ d’une discussion spécifique au produit : le Gamme de caméras ANPR, par exemple, mentionne la personnalisation du boîtier de caméra et de la couleur. Les livrables logiciels, permissions, procédure d’échantillon, coûts et calendrier demandés restent à convenir pour la commande.
Envoyez le produit de base, les marchés de vente, les quantités, les fichiers de marque, les langues, les flux de travail requis et les versions d’intégration, ainsi que les utilisations que votre contrat logiciel doit couvrir. Demandez une réponse par rapport à la matrice de portée et à un processus proposé d’approbation et de modification des échantillons de produits physiques. Vous pouvez alors discuter d’un projet OEM avec SHUNJIE en utilisant une référence définie pour le devis, l’échantillon physique du produit et la livraison en gros.
Image présentée : scène de planification OEM générée par l’IA. L’équipement générique et les documents d’examen ne représentent pas une usine SHUNJIE, un échantillon de produit physique approuvé, un audit ou un test.
Image principale : Scène de planification OEM générée par l’IA. L’équipement générique et les documents d’examen ne représentent pas une usine SHUNJIE, un échantillon de produit physique approuvé, un audit ou un test.
