# SAP Variant Configuration Model Design Review Checklist > Source: https://netray.co/tools/sap-vc-model-design-review-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A 36-item checklist covering characteristic design, classes, dependencies, super BOM, routing and runtime performance, with critical items flagged. ## Category sap ## Erp SAP S/4HANA ## Audience - SAP VC consultant - Solution architect - Product data owner ## Tool **Kind:** checklist **Groups:** #### Characteristics and classes **Items:** **Text:** Every characteristic follows the agreed naming standard and prefix **Critical:** true **Text:** Data type and length fit the longest value and will not need changing later **Critical:** true Single or multiple value setting is deliberate for each characteristic Allowed values are defined in the characteristic, not hardcoded in dependencies Descriptions exist in every required language Characteristics are grouped in classes of the variant class type Required and optional characteristics are marked correctly Characteristics that should not be shown to users are display-only or hidden **Text:** Where-used list is reviewed before any change to a released characteristic **Critical:** true #### Dependencies **Items:** **Text:** Each dependency has a clear purpose noted in its description **Critical:** true Preconditions, selection conditions and procedures are used for the right job Constraints are used for relationships between several characteristics Variant tables are used instead of long nested conditions where data is tabular **Text:** No dependency refers to a value that does not exist in the characteristic **Critical:** true Dependency status is released only after testing Default values are set by procedures and do not conflict with each other Circular logic between procedures has been checked #### Material, BOM and routing **Items:** **Text:** The configurable material has the correct flag and MRP settings **Critical:** true **Text:** The configuration profile points to the right class and BOM explosion setting **Critical:** true Every super BOM item has a selection condition or is always included on purpose Class items are used where a component is chosen from a group Quantities that depend on characteristics use formulas, not several items Routing operations and components are selected by dependencies where they differ Items with no valid selection condition have been checked and justified BOM usage and plant are correct in the configuration profile #### Change control and documentation **Items:** **Text:** Changes to released BOMs, routings and dependencies run under a change number **Critical:** true The model owner and backup are named The rule catalogue matches what is built Transport order content includes characteristics, classes, dependencies and profile together A rollback approach is written for each release of the model #### Testing and runtime **Items:** **Text:** A test matrix covers each option and each rule, not just typical orders **Critical:** true Invalid combinations are tested and give a clear error message Sales order, MRP and production order are tested end to end Pricing for configured items is tested against the characteristics Performance is checked with the largest realistic configuration Authorizations for model maintenance are restricted **Scoring Note:** Aim to have every critical item checked before transport. A model with unchecked critical items should not be released to production, even if the overall percentage looks high. ## Content **Intro:** Most variant configuration problems found after go-live were visible in design. This checklist gives reviewers a structured pass over characteristics, dependencies, the super BOM, change control and testing before a model is transported. **Sections:** #### How to use the checklist **Body:** Run the review with the model builder and an engineer who knows the product. Go group by group, tick what you can show in the system and not just what you remember. Items marked critical are the ones that most often cause defects, so they must pass before transport. Export the completed list to PDF or Excel as the review record. Run it again at each release of the model, as new options add risk to older logic. #### Why the order of groups matters **Body:** Characteristics and classes come first because everything else refers to them. A late rename or a data type change forces edits in dependencies, the BOM and tests. Dependencies come next because they hold the business rules. Then the material, BOM and routing link those rules to production. Change control and documentation protect the model once it is live, and testing proves it works. Reviewing in this order tends to find the cheapest-to-fix problems first. **Bullets:** - Names and types are hardest to change late - Dependencies hold the rules - BOM and routing apply the rules to production - Testing proves the whole chain #### Typical findings **Body:** Common findings are items in the super BOM with no selection condition that appear in every order, procedures that overwrite each other's defaults, and variant tables that are not maintained after a new option is added. Another frequent one is dependencies released before the test matrix is finished. Reviewers should also look for missing language texts, which show as blanks in the configuration screen for users in other countries. Keep the findings list short and assign each to a person with a date. **Cta:** If you want an outside review of a VC model, Netray can arrange an expert to go through your design against this checklist. **Faq:** #### When should this review happen? **Answer:** Before each transport of a model change to quality and again before production. A final review before go-live is the minimum. Reviewing earlier, after characteristics and classes are drafted, finds naming and data type problems when they are cheap to fix. #### What is the difference between a selection condition and a precondition? **Answer:** A precondition limits which values or characteristics can be chosen, based on what is already selected. A selection condition decides whether a BOM item or operation is included for the chosen configuration. One controls input, the other controls output. #### Why avoid hardcoding values in dependencies? **Answer:** If a dependency names a value that is later renamed or removed in the characteristic, it fails silently or errors at runtime. Keeping allowed values in the characteristic and referencing them carefully reduces that risk and makes where-used checks meaningful. #### Does this apply to advanced variant configuration? **Answer:** Most items, such as naming, ownership, change control and testing, apply to any approach. The dependency syntax and object types differ in advanced variant configuration, so adapt the second and third groups to your tools. ## Search terms sap vc model review checklist, variant configuration design review, sap vc best practices checklist, sap characteristic naming checklist, sap dependency review checklist, sap super bom review, sap vc quality gate, sap configurable material checklist --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json