Lesson 3 of 6
Assessing an LO-VC portfolio: complexity, custom code, volume
11 min
Listen to this lesson
A transformation plan starts with an honest inventory. Two portfolios with the same number of configurable materials can differ by a factor of ten in effort, because effort follows dependency count, the use of risky constructs, custom code and how much business flows through each model. The assessment answers three questions: what is in the portfolio, how risky is each model, and in what order should the models move.
Build the inventory
| Item to count | Where to look | Chicago result (illustrative) |
|---|---|---|
| Configurable materials and their profiles | Configuration profiles (CU42/CU43), material type KMAT | 14 materials, 14 profiles, all Classic |
| Variant classes and characteristics | Class type 300 classes and their characteristics (CL03, CT04) | 5 classes, 61 characteristics |
| Object dependencies by type | Dependency where-used and lists (CU06 and related reports), PMEVC | 1,140 dependencies: 210 preconditions, 540 selection conditions, 300 procedures, 90 constraints |
| Variant tables and functions | Table structures (CU61), variant functions (CU65) and their function modules | 38 tables, 9 custom functions |
| Risky constructs | Search of dependency source for EXIT, actions, IF in restrictions, BOM-item procedures | See lesson 2 findings |
| Material variants | Materials that reference a configurable material with fixed values | 60 variants of CMC-ALT-900 |
| Business volume | Configured sales order items per year by model | About 9,000 items; 3 models carry 80% |
Inventory items for an LO-VC portfolio. Transactions shown are classic SAP GUI ones; PMEVC shows most of the same objects per model.
Pull the volume from real order history, not from memory. The models people talk about are not always the models that carry revenue. At Chicago, a model that the engineers considered "the hard one" turned out to have fewer than 100 orders a year, while the simplest-looking model, the 12 V standard family, carried 40% of all configured items.
Score each model
A simple scoring sheet is enough: count dependencies, add weight for each risky construct and custom function, and multiply by a volume band. Do not over-engineer the score; its purpose is to order the work and to show the steering group why some models need far more test effort than others.
Group models into work areas
The transformation tools group models into work areas (workspaces) that move together. The grouping rule is technical before it is organizational: models that share dependencies, constraint nets, variant tables or variant functions should be in the same work area, because transforming a shared object for one model affects the other. Then group by product area so that one business tester can validate a whole work area.
| Work area | Models | Why grouped | Wave |
|---|---|---|---|
| WA-CHI-STD | 12 V standard family, 3 models | Share variant table CMC_VT_PULLEY and two constraint nets | 1 (pilot) |
| WA-CHI-HD | CMC-ALT-900 family, 4 models | Shared procedures and the 3 models with actions | 2 |
| WA-CHI-MARINE | Marine and specialty, 7 models | Low volume; 2 models proposed for retirement | 3 |
Contoso's Chicago work areas (illustrative course data).
Custom code and integrations
- Variant functions: each function module needs a review. Code that reads classic internal configuration structures must move to supported interfaces or the AVC BAdIs.
- User exits and enhancements in sales order configuration, pricing or costing that read configuration values: find them with a where-used search and the ATC or custom code analysis.
- Custom reports that read configuration data directly from tables: they may still work, but test them, because they are often what finance uses for margin analysis.
- Interfaces: EDI orders with configured items, a CPQ or web configurator, and output forms that print characteristic values.
- Is the model still sold?Yes → keep in scope · No → retire it instead of transforming it
- Does it share objects with other models?Yes → same work area as those models · No → can move alone
- Does it use actions, EXIT or BOM-item procedures?Yes → rework time and targeted tests · No → copy and compare
- Does custom code read its configuration?Yes → include the code owner in the work area · No → standard regression only
- Is volume high?Yes → more comparison cases and business validation · No → value and dependency coverage
What would you do?
Grace's PMO wants a single number for the steering group: "How long will the AVC transformation take?" The assessment has scored all 14 Chicago models. What is the most useful answer?
What goes wrong in testing
Assessment errors show up later as test surprises. The usual ones: a model treated as independent turns out to share a variant table with another work area, so the second work area's results change when the first is released; volume taken from opinion leaves a high-volume model in a late wave; and custom code that reads configuration is found only when a margin report breaks in hypercare. Each of these is cheaper to find with a where-used search and an order history query during the assessment than with a defect after release.
- Count dependencies by type, risky constructs, custom functions, material variants and real order volume.
- Score complexity and volume; the quadrant decides treatment and test effort.
- Group models that share objects into one work area.
- Retire models that no longer sell instead of transforming them.
Check your understanding · not graded
Lesson check
1. What is the main technical rule for grouping models into one work area?
2. A model is complex but has very few orders. What does the assessment suggest first?
3. Where should business volume per model come from?
4. Why include custom variant functions in the assessment?