Comparative Processes
The essential requirement of the comparative process is – although this might sound trivial – the comparability of guarantees. To put it in more colloquial terms, “We don’t want to compare apples with oranges.”
Requirements
For SAP systems, two essential questions have to be answered:
- Is the size being looked at appropriate for a comparison ?
- Are the systems being looked at comparable ?
The second requirement is related to this – we need comparisons of different structures and on differing scales, using the same degree of precision. In concrete terms, this means that we don't just compare one single size, but a specific number of different sizes. We don’t use just one criterion, but several criteria for the comparison.
In addition, the question of whether two systems can be compared cannot be answered with a simple “yes” or “no”. We need a criterion that makes the comparability of two systems quantifiable.
Realization
Comparable yet different systems can be taken into account by introducing weights. For example, weights have a value between “0” and “1”. The weight depends on two systems and describes the similarity between the two systems. A weight of “0” means that both systems cannot be compared and the weight “1” means that the systems are identical.
The main problem is how to define the weights in an appropriate manner; at the same time, the actual problem must be borne in mind. If, for example, we are interested in the back-up costs, we will use other weights than for applications-related costs such as second-level-support. As a rule, the weights will also depend not only on one size, but on several.
Another important point is the scaling of different sizes. Costs typically depend on the size of the systems; however, the size factor is described by different parameters. For SAP systems, size is often shown as the number of users. In almost all cases this is insufficient, since the transaction load, the batch load, the complexity, or the number of different applications are equally important, or even more so.
And the fact that there is usually no simple, linear relationship between “size” and costs also needs to be borne in mind. For one thing, there is a basis, i.e., certain minimum costs, which are necessary in order to operate an ERP system at all. Secondly, small landscapes are often more expensive than larger ones. In addition, the administration costs for very large systems can increase disproportionally. So non-linear scaling functions need to be used in order to describe the relationship between “size” and costs.