A Strategy is associated with a Scorecard containing the Outcomes and Measures that will be used to determine if the implementation of the strategy is producing the desired results. A Strategy can be associated with more than one Scorecard via the binary relation StrategyHasScorecard.
For more information about the Strategy concept, see the Strategy Diagram.
Also shown in this diagram are the four original perspectives of the Balanced Scorecard: Financial, Customer, Internal and LearnGrow (our shortened form for Learning and Growth). There are specific kinds of Outcomes and measures for each of the perspectives. A collection of binary relations such as ScorecardHasFinOutcome and ScorecardHasFinMeasure link the Scorecard to these components. In addition, the Outcomes are linked to their Measures by binary relations such as InternalOutcomeHasInternalMeasure. This is necessary because the semantics of these relations cannot define which Measures are associated with which Outcomes (see the note below for an explanation of this type of diagram).
The perspective components of the Scorecard are not exclusive to it. Outcomes and Measures can be shared with other Scorecards.
In practice, other prespectives are added when required by particular strategies. Some of the original perspectives may not be used, or may be used in a restricted way. Extended perspectives should have their own kinds of Outcomes and Measures and should be associated with the Scorecard. It may be useful to specialize the Scorecard concept to have a particular configuration of perspectives. This is the way to create a particular kind of Scorecard. It is also possible to specialize the binary relations (e.g. ScorecardHasFinOutcome)used to compose the Scorecard so that only a subset of a particular kind of Outcome or Measure is permitted.
Italicized words refer to the named concepts in the diagram above.
This diagram (and the other diagrams in this model) is not a UML diagram. Rather, it is an OWL model defined using UML stereotypes. The rectangles in the diagram are “classes”, but in the logical sense, meaning that they represent a collection of individuals. Unlike UML, they do not constrain the individuals. The associations are binary relations over the classes. The class at the tail of the association defines the “domain” of the relation, and the class at the head defines the “range”. The semantics of this model allow relations to be specialized (i.e. a defined subset of the tuples in the more general relation). For more information, see the OWL Primer. The UML stereotype used is defined in the Ontology Definition Metamodel, an OMG standard.
OWL allows classes to contain individuals, just as in an OO language, classes have instances. It is sometimes difficult to distinguish classes and individuals when extending a metamodel framework such as this. If you are building a tool to support the definition of a Balanced Scorecard, the (extended) metamodel framework will define the data schema of the tool, and the information collected (namely specific Outcomes, Measures and so forth) will be individuals having membership in the classes defined by the metamodel. This is not too different from what one expects in OO programming, but there are some substantial differences, particularly in the role of the binary relations.