You can test prices that are based on variant conditions. For a calculation schema / cost accounting scheme that you may specify separately in each test case the Model Tester determines and tests all condition records in all relevant accesses of all relevant access sequences.

No. For two reasons:

• For a configuration model with 100 single valued characteristics you need to test 10 to the power of 100 variants. These are
  
  10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
  
  variants. If your VC needs about one second to test one single variant / test case, you would have to wait pretty long. Precisely
  
  325 114 440 282 979 608 822 305 451 518 934 665 002 080 732 417 811 069 496 462 754 889 721 181 856 013 316 687 473 990 844
  
  years. And that is approximately
  
  23 730 981 042 553 256 118 416 456 315 250 705 474 604 433 023 197 888 284 413 339 772 972 349 040 584 913 626
  
  times the age of our universe.
  
  
• Even if you don't test all variants - e.g. since you are interested in a combination of certain characteristics only - the problem remains that for each variant you would have to specify your desired result. I.e. for each combination of characteristic values you need to specify conflicts, characteristic values set by the system, bom explosion and prices if required. We think that this implies a huge effort that pays off only in special cases. If you are one of these cases, please contact us.

No. The Sybit Model Tester runs inside the NetWeaver Abap and, hence, can be installed on any existing ERP system. However, you may also run it inside its own NetWeaver.

Certainly not!

• No integration risks: The Sybit Model Tester is and ABAP Add On certified by SAP.
• No data risks: The Sybit Model Tester only reads SAP and customer data.
• No migration risk: The Sybit Model Tester does not require any modification on SAP source code.
• No security risk: All development objects are contained in a namespace that is registered at SAP. This effectively prevents collisions with development objects in your system.

The installation effort increases with the number of systems you want to integrate into your test scenarios. For an installation with 2 - 3 connected systems installation requires between one and two hours.

In a world without variant configuration, selling multi-variant products is not only expensive, but at the same time prone to errors and slow. Endless material masters must be redundantly maintained, small changes to products cause a great deal of work. Sales cannot decide whether an unforeseen variant may be sold or not.

Variant configuration solves these problems elegantly by central modeling of complex interrelationships. Multiple maintenance of material masters is dispensed with, changes to the product are maintained centrally, and the sales department has binding knowledge as to which variants may be sold.

Variant configuration enables the complexity of a product range to be raised and costs to be saved at the same time. Configuration models are integrated into many core processes.

Despite the complexity and importance of configuration models, their quality control plays a subordinate role in many companies. The following scenarios are a direct result of this:

• The configuration model wrongly enables an unforeseen variant. At the worst, additional development work will be incurred to enable the required variant to be delivered.
• The configuration model prevents a certain variant, which at the worst, would have been more useful to the customer, and at the same time, would have generated more turnover.
• The configuration model generates an inaccurate parts list. At the worst, the wrong parts are purchased which is only discovered during assembly. Delivering according to schedule is, therefore, not possible.

The list of these scenarios can be lengthened indefinitely. The one thing they all have in common is a potentially large amount of financial damage. Although systematic tests cannot rule out this risk, it can, however, be minimized considerably.

Configuration models are complex. In plant and mechanical engineering, configuration models can easily contain several hundred degrees of freedom (i.e. characteristics). It is impossible to test all possible configurations in such a scenario. However, this is normally also not required, as the risks can be reduced as follows.

• Product knowledge: Product management knows the variants of a configurable product that is frequently ordered (so-called bestseller). It is precisely these variants that have to be primarily tested.
• Modeling knowledge: The programmer of the configuration model knows the critical places of a model, and therefore, those that are prone to errors. It is precisely these points have to be primarily tested.  

If product knowledge and modeling knowledge are combined, the number of tests can be significantly reduced. Testing should therefore uncover errors. It cannot prove the absence of errors. In practice, the number of tests is often reduced too far, resulting in incalculable risks.

The main reasons for insufficient testing can be attributed to tests being carried out manually:

• High costs: Testing configuration models is carried out, or at least specified, by product and modeling experts. The large number of tests necessary for good model quality leads to an explosion in test costs.  For more information read the cost-benefit analysis page.
• Inadequate quality: As manual testing is a tiring activity, errors creep in. Performing the tests is not subject to any quality control. 
• Greater amount of time required:  In the case of manual tests, each test case has to be entered by hand into the system at each period of testing. Result evaluation is carried out by a visual check. This process is not only strenuous and requires a high degree of concentration, it is primarily time-consuming. For more information refer to our time to market page

Automatic testing removes these aspects simultaneously:

• Low costs: In the case of automatic testing, test cases are specified once and then stored in the system. They can be carried out at any time at the press of a button. Expert knowledge is then only necessary to rectify errors.
• High quality: Automatic testing does not know any careless errors. Test runs are documented in the system and can be traced at any time.
• Process acceleration: In automatic testing, all the relevant tests can be carried out overnight at the push of a button. A report, which is clear and understandable at all times, documents the results of each test run and forms the basis for rectifying any possible errors.

The general answer is: Everybody who has an interest in results of a configuration model. Most often, this includes:

• Modelers: People who are responsible to create, i.e. model, configuration models test those parts of the configuration model that are tricky or complex from an implementation point of view.
• Sales: People from the sales department test if they get the correct system set values.
• Product management: Product managers typically test if the variety of variations is supported by the configuration model and also prices.
• R&D department: People from the R&D department typically test if variants that can / can not be built are permitted / forbidden by the configuration model.