GB2554899A

GB2554899A - Data processing system

Info

Publication number: GB2554899A
Application number: GB1617342.9A
Authority: GB
Inventors: Ball Dave; Thurlow Stephen; Thomas Ruth
Original assignee: Curo Compensation Ltd
Current assignee: Curo Compensation Ltd
Priority date: 2016-10-12
Filing date: 2016-10-12
Publication date: 2018-04-18
Also published as: GB201617342D0

Abstract

A data processing system 100 comprises a data store 104 for storing data values related to one or more entities, for example data related to compensation management for employees and staff, and a configuration module 106 for defining a configuration 108, 110, 112 which implements a policy and for applying the configuration to the data values to generate outcomes 114, 116, 118. The outcomes define new values for at least some of said data values relating to one or more entities, and the configuration references a decision tree data structure, which in turn references a matrix data structure. The data values may be received from an enterprise and mapped to a set of properties, which act as references used by nodes of the decision tree and matrix structure. Those properties may act as lookup factors for indexing the data values. A user interface may be used through which a user interacts with decision trees and/or matrices to define a configuration.

Description

(56) Documents Cited:

None (71) Applicant(s):

Curo Compensation Limited

Exchange Tower, 19 Canning Street, Edinburgh,

EH3 8EH, United Kingdom (58) Field of Search:

Other: No search performed - Section 17(5)(b) (72) Inventor(s):

Dave Ball Stephen Thurlow Ruth Thomas (74) Agent and/or Address for Service:

Scintilla Intellectual Property Ltd

The Centrum Building, 38 Queen Street, Glasgow,

G1 3DX, United Kingdom (54) Title of the Invention: Data processing system

Abstract Title: Processing enterprise data using decision tree structures (57) A data processing system 100 comprises a data store 104 for storing data values related to one or more entities, for example data related to compensation management for employees and staff, and a configuration module 106 for defining a configuration 108, 110, 112 which implements a policy and for applying the configuration to the data values to generate outcomes 114, 116, 118. The outcomes define new values for at least some of said data values relating to one or more entities, and the configuration references a decision tree data structure, which in turn references a matrix data structure. The data values may be received from an enterprise and mapped to a set of properties, which act as references used by nodes of the decision tree and matrix structure. Those properties may act as lookup factors for indexing the data values. A user interface may be used through which a user interacts with decision trees and/or matrices to define a configuration.

Fig. 1

At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy.

1/15

12 17

Ό

CM

Fig. 1

CM

Ο

2/15

co ο

C\1

3/15 t^·

Fig. 4

4/15

LO •S>

LL <O •S>

LL

12 17

5/15

12 17

Fig. 7

6/15 t^·

Fig. 8

7/15

ο

-I—» ο

ro ω

ο <C ο

Μ—»

Ο ro

4—

Ο.

ZJ ο

ο

C ω

Ε

Έ ro

ο.

ω

Q ο

Μ—»

Ο

Μ—

Μ—»

Ω

	Μ—» C φ Ε ο.	Max
	Ο
	ω > ω Q	Min
Ο
ο	C0 φ	Max
	ro ω	c

	Μ—» C φ Ε ο.	Max		Γ	O O σ> J
ο C	ο ω > ω Q	Min		Data Item
ο >	co φ	Max
	ro ω	c

	Edinburgh	London	Dallas

Location” lookup factor ο>

δ>

8/15 ο

ro ο

ο ω

ο <

ο ,ro c

ω

Ε

Έ ro

ο.

ω

Q ο

^—1 ο

ro

4— ro

-t—<

ro

Q >3

Ο

Λ t^·

	Μ—» C φ Ε ο.	Max
	Ο
	ω > ω Q	Min
Ο
ο	CO φ	Max
	ro ω	c

	Μ—» C φ Ε ο. ο	X ro
	ω > ω Q	Min
ο C
ο >	CO φ	Max
	ro ω	c

Λ		Φ
1—
V		i—¹
e		Π3
φ		>
+->
1—1		O
Π3		+->
+->		CJ
Π3		Π3
Q		LL·
X		X
•1—		•1—

+->		+->
Π3		Π3
ΞΣ		ΞΣ
		V
CO		+->
co	C	Φ
Π3	Π3	CO
i—¹	ΞΣ
CJ	O	Φ
	1—	+->
u	>»	Π3
•1—	c	>
i—¹	Π3	•1—
_Q
		Q_
Q_

Ο

Ο σ>

.s>

Location” lookup factor

9/15 t^·

Fig. 12

10/15 t^·

Fig. 13

11/15 t^·


Female	Value	V £ .00	V £ .00	v £ .00
Male	Value	V £ .00	V £ .00	v £ .00
	Address 1 Π	Value 1	Value 2	Value 3

Fig. 14

12/15 t^·

Female	Value	00' 3 Λ I	v £ .00	v £ .00

Male	Value		v £ .00	v £ .00	v £ .00
	Address 1 Π		Value 1	Value 2	Value 3

Fig. 15

13/15

CD -Q O

CO CO CO .5> .5> .5)

LU LU LU

o w

o ΐΟ .c ω

w ΐΟ .c ω

14/15

N.

•S>

LL

φ >

tn ro o

tn

Φ ro ro >

o

L_ o

E o

φ σ

σ ο

oo •S>

LL

Toggle whether From or To value is inclusive φ

cn c

ro

T3 φ

tn =3

Φ =3 o

15/15

σ>

•8>

LL

Data Processing System

The present disclosure relates to a data processing system and in particular to data processing tools, systems and methods that can be used for enterprise decision management, amongst other things.

The teachings of this disclosure may in general be applied to any type of data including being suitable for any type of enterprise decision management. One example of enterprise decision management is the management of employee compensation. Herein, the term employee is used generally as any individual that is associated with an organisation and so is used in a more general sense than the legal definition of those individuals who have employee status. In other words, the term employee as used herein will for example include legal employees, as well as workers, contractors, directors and other office bearers, agency staff and so on.

Employees may be compensated for their work in many ways. As well as remuneration by a salary or a wage, compensation may take the form of bonus payments, shares or share options of various share types, benefits such as company cars, insurance policies, pensions, and many others.

As the number of employees grows, the complexity of managing compensation quickly escalates. Large organisations face several problems in managing compensation. First of all, basic record keeping of what employees' current compensation packages are and what they should be revised to is difficult. Spreadsheets can be used but these are prone to error, are inefficient and can pose a security risk if they are accessed by unauthorised parties. Typically organisations will create a master compensation spreadsheet and slice sections out for issue to Line Managers who then input their recommendations and email back to a separate human resources (HR) function. This creates massive issues around data integrity and results in compensation reviews which take several back and forward cycles, with little control of spend vs budget. It is also difficult (with spreadsheets) to prevent Line Managers changing underlying data, modifying formulae and embedded rules controlling the allocation of compensation spend. Finally, It is also problematic to model and forecast scenarios to simulate the costs of different compensation proposals.

Accordingly, there is a need for improved data processing tools to provide increased control of compensation management and recommendations as well as other enterprise decision management contexts.

According to a first aspect of the disclosure there is provided a data processing system comprising:

a data store storing data values related to one or more entities; a configuration module for defining a configuration which implements a policy, and for applying the configuration to the data values to generate outcomes, said outcomes defining new values for at least some of said data values relating to one or more entities; and wherein:

a configuration stored by the configuration module references a decision tree data structure; and said decision tree data structure references a matrix data structure.

Optionally, the data processing system comprises an integration module which maps data values to a set of properties, which act as references to the underlying data values.

Optionally, the integration module is arranged to receive data values from an enterprise and to map those data values to said set of properties.

Optionally, the decision tree data structure and matrix data structure refer to properties.

Optionally, the decision tree data structure comprises at least one decision node referencing a property.

Optionally, the matrix data structure comprises properties which act as lookup factors for indexing the data values.

Optionally, the system comprises a user interface through which a user interacts with decision trees and/or matrices to define a configuration.

According to a second aspect of the disclosure there is provided a method of processing data, storing data values related to one or more entities; defining a configuration which implements a policy;

applying the configuration to the data values to generate outcomes, said outcomes defining new values for at least some of said data values relating to one or more entities; and wherein:

According to a third aspect of the disclosure there is provided a computer program product, comprising instructions that, when run on a computer, enable that computer to carry out a method comprising:

storing data values related to one or more entities; defining a configuration which implements a policy;

The computer program product may be stored on or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fibre optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infra-red, radio, and microwave, then the coaxial cable, fibre optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. The instructions or code associated with a computerreadable medium of the computer program product may be executed by a computer, e.g., by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, ASICs, FPGAs, or other equivalent integrated or discrete logic circuitry.

The disclosure will be described below, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows an overview of a system providing a data processing tool according to an embodiment of the disclosure;

Figures 2 to 8 illustrate various aspects of decision tree data structures which can be used in the system of figure 1;

Figures 9 to 15 illustrate various aspects of reference matrix data structures which can be used in the system of figure 1;

Figure 16 shows an example of an aspect of an interface for setting a configuration for a compensation policy; and

Figures 17 to 19 show examples of how a node within a decision tree can be configured.

Figure 1 shows an overview of an embodiment of a data processing tool 100 according to the present disclosure. This embodiment shows a data processing tool 100 that is suitable for enterprise decision management and in particular for managing an employee compensation program.

An integration hub 102 is provided which takes data from an enterprise's records (for example, human resources (HR) and/ or payroll records) and maps the data to a set of properties. The data from the enterprise's records may generally be in any format, including for example CSV, XLS, XLSX, XML, JSON or other webservices protocols, and generally any other format including future data formats. The integration hub performs a mapping from the structure of the received format into properties.

The properties act as references to the underlying employee data, functioning like pointers although not having the same properties as a pointer defined for example in the programming language C. The raw data imported from an enterprise's system is stored in employee data store 104. The properties provide a means of accessing per-employee values (so when we discuss modifying or resolving a property value it is for a specific employee). Properties do track additional metadata, such as which Review, Award or Benchmark etc. defines or owns the Property. For example, for each Bonus Award in a specific implementation, there is a Bonus Plan property, and that property references which Award and which Review it is part of.

Compensation schemes can be managed via a configuration module 106, which may generate one or more configurations 108,110,112. Multiple configurations may be generated and stored for comparison or for archiving.

The configuration module 106 uses employee data 104, processes it according to a configuration 108, 110, 112 as generated by the module, and produces an outcome 114 which in this case comprises review data showing the new compensation packages for the employees. The system 100 may store multiple outcomes 114,116,118, which may for example comprise historical reviews from previous years or reviews generated from different configurations 108,110,112 which are generated for modelling or testing purposes. The results of past reviews may also be fed back to the configuration module and used as part of the modelling for successive configurations. The employee values (also referred to as employee data values) referred to herein include the raw employee data stored in the employee data store 104 and in the review data stored at each outcome 114, 116,118.

The configuration module can be operated via a user interface 120 which can for example be used by a manager to interact with the configuration module 106. Through the user interface 120, a user can define configurations and can also apply them to the employee data 104 to produce outcomes 114, 116, 118.

An enterprise uses the configuration module 106 to define its own compensation process, for example, how many different bonus plans they operate. In that case, each plan exposes its own set of properties. In the same way, other variables can be set up to define the structure of an enterprise's compensation and award arrangements.

The configuration module 106 provides data structures which can manipulate the employee data, and the user interface 120 provides a graphical user interface for visualising and modifying the data structures.

Properties

Underlying the data structures is the ability to expose disparate data in a common API. This is achieved through properties. Properties act as pointers to the underlying employee data, which is stored in employee data store 104, and they allow the employee values to be consumed in data structures which may comprise decision trees and matrices as discussed in more detail below.

Each component of the system 100 exposes properties, and the set of properties exposed varies based on how the system is configured. For example, the Compa-Ratio property is exposed by defining a Benchmark within the product, with each subsequent Benchmark exposing an additional Compa-Ratio property. So if the product is configured with three Benchmarks, it will expose three Compa-Ratio properties, one for each Benchmark.

Properties all expose employee values which form the employee data 104, but different properties will expose different types of value. For example, a CompaRatio property defining a percentage salary increase to be applied exposes a value which is a percentage value, of type percentage, but a Salarylncrease property exposes a value which is an integer, of type Money.

Property data types may include one or more of a date, a duration (time period in years or months, etc), a flag (true/false), manager (the identity of an employee's manager), money (including different currencies), percentage, text.

The specific properties that can be used will depend on each individual enterprise that uses the system and is virtually unlimited. It will be appreciated that the present disclosure is not limited to any particular set of properties, but to give an example of the types of properties that could apply, the following list is provided:

Bonus end date, Bonus plan, Bonus salary, Bonus start date, Discretionary Pay actual bonus, Discretionary bonus (%), Discretionary bonus, Maximum discretionary bonus (%), Maximum discretionary bonus, Minimum discretionary bonus (%), Minimum discretionary bonus, Service pro-ration factor, Total actual bonus as % of salary, Total actual bonus, Address 1, Address 2, Address 3, Address 4, Country, Date of birth, Email, First Name (Forename), Gender, ID (Staff number), Joiner Start Date, Full Name, Last Name, Leaver Flag, National Insurance number, Payroll ID, Postcode, Rehire date, Start date (Hire date), Termination Date (Leave date), Town, Communication Manager, Country (Location), Decision Maker, ESignature, Employer, Employment Status (Job grade), Exec flag, full time equivalent (FTE) Fixed Pay FTE, Function or Project, Job band, Job title, Line Manager, Local HR

Local, Regional, Group, Monthly Fixed Pay, Office location, Pay frequency, Position In Office, Region, Regional HR Director, Role end date, Role start date, Salary - actual, Service Line (Business unit), Staff Status (Department), Sub-Region (Cost centre), Sub-Regional HR

Director 1, Sub-Regional HR Director 2, Weekly rate, Working time - employee, Working time - standard, 70.00% of benchmark value (raw data), Benchmark - compa-ratio (existing salary), Benchmark - compa-ratio (new salary), Benchmark - compa-ratio calculation value, Benchmark - position to market (existing salary), Benchmark - position to market (new salary), Actual salary inc recommended increase, Appraisal Rating, Bonus Budget budget pot, Bonus Budget budget value, Current actual salary, Salary Budget budget pot, Salary Budget budget value, Award eligibility, Guideline increase (%), Guideline increase - FTE, Guideline increase - actual, New salary - FTE, New salary - actual, Salary increase (%), Salary increase - FTE, Salary increase - actual.

Decision Trees

One of the data structures that is provided by the configuration module 106 is a decision tree. The decision tree is also in preferred embodiments represented graphically for presentation and manipulation by a user via the user interface 120.

A decision tree is a representation of processing that will be performed to reach a decision forming an outcome. The graphical representation of the decision tree provides a user with an intuitive interface and allows him to make changes without being exposed to the complexity involved in processing the decision. The user can construct or modify a decision tree data structure simply by dragging and dropping objects into the graphical representation of the tree.

The decision tree data structure also allows a detailed (per-node) audit of how a decision was made. The path through a tree that results in an outcome can be recorded and reviewed later on for auditing or reporting purposes. Alternatively, instead of recording the path, simply the individual decisions and the net outcome can be recorded.

The processing involved in evaluating a tree consists of three steps at each node: Retrieve, Classify and Traverse. Each node in the tree is based on an existing value associated with an employee. This can be a value imported directly against the employee, or a value previously calculated for the employee.

For the retrieve step; a common interface is used to present employee values across all different types of data or entity within the system. Properties expose the available employee values, and provide the consistent interface for retrieving those values. Depending on various facets of the relevant property, a node within the tree will be configured differently. For example (and as shown in figures 17 to 19), properties that expose a date are treated differently to properties that expose a numerical money value such as requiring exchange rate data for nodes that reference a money value. As further examples, a date value may be allocated to a bucket/branch in the tree through the definition of multiple date-ranges, and a text value may use wild-card matching rather than ranges.

For the classify step; the overall tree decision is segmented into a decision at each node. Each node defines two or more onward paths, and must specify the criteria for passing an employee down one path or another. Generally, this is achieved through the definition of data buckets, and depending on the data-type of the property, criteria are defined for each bucket.

For the traverse step; the decision at each node defines the next node to be evaluated, and the retrieve and classify steps are repeated until a leaf node is reached. Leaf nodes represent the outcome from the tree, and the end of processing.

Trees are used throughout the system, and support various types of outcome depending on where they are used. For example, the outcome might be which bonus plan to use for an employee, which budget pot, or a constraint behaviour (such as allow or reject)

Different types of tree outcome may be supported. The disclosure is not limited to a particular set of outcomes, and an enterprise or system provider may define additional new types of outcome to suit their purposes, but as an example, supported outcomes may comprise one or more of the following: Flag (boolean), Budget pot, Review / recommendation Constraint, Matrix (as discussed in more detail below), Bonus Plan, Review Access group.

Figures 2-8 show aspects of the graphical representation of a decision tree, which may be provided via the user interface 120. Figure 2 shows part of an initial set-up screen, starting with an empty tree. A user is presented with a set of properties 200 and a set of outcomes 202. A search tool 204 can also be provided to accept a text input so that the user can type some text to filter the list of properties that are displayed, in order to assist in searching through a large list of properties.

An initial placeholder graphical object 206 is displayed on an otherwise blank screen which provides an indicator for the user to guide their input to the system. In this example, the placeholder object 206 includes text with the instruction drop here, so that the user is prompted to take the first step to build a decision tree. To create the first part of the tree, the user selects a property from the list 200 and drags it so that it overlaps with the onscreen position of the placeholder object 206. The drag and drop operation may be accomplished using a pointing device such as a mouse or trackpad, in which case a cursor can be moved to the object representing the property, a button of the pointing device can be pressed or held to select the property object, which then can be moved with the cursor and is dropped when the property object overlaps with the area of the placeholder object 206, and/or when the button is released. Equivalent actions could be carried out via touchscreen interfaces where a long press by a finger acts to select and object and the release of the pressing action acts to drop the object.

This is shown in figure 3, where the property 208 called Function or Project is dragged and dropped to the positon of the placeholder 206. This is a text property that defines a decision node. A visual indicator may be provided to a user once the object is in the correct position to be dropped, which in this case comprises a highlighted border 300 of the placeholder.

Once the property 208 is dropped to the initial placeholder position 206, a dialog box may be displayed so that the user can configure the decision node for the property. An example of such a dialog box 400 is shown in figure 4. Here, the user can define different decisions based on different criteria. If the property matches project A, then decision 1 is made;

and if the property matches project B, then decision 2 is made. Text input boxes 402, 404 may be provided which provide the functionality to add conditions. Further decisions may be added, that is, the decision tree is not limited to making a selection between just two decisions, it may also make a selection between more than two.

Once the decision node has been configured via the dialog 400, it is then placed into the decision tree, as shown in figure 5. The selected property now shows as a node 500 of the tree, and the decisions 502, 504 are represented at the branches of the tree. Now that two possible decisions have been defined, further placeholder objects 506, 508 are provided at the end of each branch. These placeholder objects 506, 508 act as guides for a user to show them that further action is needed to complete the tree, and to guide the user where to place further items.

The user may choose to add further properties to the placeholder objects 506, 508 via similar drag and drop operations as mentioned above. When adding further properties, further branches are defined. To terminate the decision tree, a user must select an outcome which then defines a leaf node of the tree. Figure 6 shows a continuation of the process of figures 2 through 5, where a user selects a True outcome 600 for one decision branch of the tree shown in figure 5, and a False outcome 602 for the other decision branch of figure 5. The tree is then complete once all branches reach an outcome. It will be appreciated that this is a very simple tree and in reality more complex trees will be built. For illustration, figure 7 shows a decision tree where a true or false outcome is selected based on an office location, and figure 8 shows a decision tree where a true or false outcome is selected based on an office location where the quantum of a salary increase is either allowed, refused or sent for further review depending on its value.

Reference Matrices

Another of the data structures that is provided by the configuration module 106 is a reference matrix. The full set of employee data comprises a very large number of data items, and a reference matrix provides lookup table of the data items for efficient processing and ease of use. Reference matrices are very useful in a compensation review process:

• They are fully configurable • They are the basis of controlling minima, maxima and recommended levels comp award (bonus payment or salary increase) • They are used in the calibration process within budget setting ie a combination of total budget, distribution of performance management scores and reference matrices are the basis of modelling the profile of budget spend an organisation desires.

• They are multi-dimensional, le are used to control comp recommendation levels by for example, business unit, function, country, cost centre etc - any number of dimensions.

No two enterprises use the same rule for defining the constant values (such as [salary increase percentage]). Reference Matrices solve this conundrum for us by abstracting resolving what [salary increase percentage] to use into a lookup table where the factors can be defined on an enterprise-by-enterprise basis.

Matrices provide reference data that can vary by employee, and make use of employee values exposed in a consistent manner through properties.

Reference matrices are structured using properties to define factors (dimensions) that are relevant for looking up this data. Matrix data items are persisted against a key that references a value for each Factor (dimension); for example:

Male, London -> iteml Male, Edinburgh -> item2 Female, London -> item3 Female, Edinburgh -> item4

An item here is This is an individual value that is the output from the matrix - the matrix is a tool to lookup and return the relevant Item for an employee. E.g. if the Matrix was to return a Money range then there would be 4 Items for Min and 4 Items for Max.

This supports a number of factors, or dimensions, for a multi-dimensional lookup. Each factor can have an arbitrary number of buckets that classify the employee based on criteria such as ranges. This may be in a similar manner to the classify step of a decision tree as mentioned above. For example, length of service might be classified into a bucket for < 12 months, a bucket for 1 to 3 years, and a bucket for >3 years.

Reference matrices also support one-to-one mapping where buckets aren't appropriate. With one-to-one mapping the employee's value is expected to match one of the matrix values for the factor being evaluated.

Storing data items (Dataltems) in this way delivers a number of benefits:

• Data items are modelled using simple entities and DB table, and can therefore scale to large numbers. This could easily be millions of data items in a RDBMS, or could scale further using a document/hash based data store (S3 / NoSQL).

• Data items can be displayed in a Tabular format, and can be loaded from the DB as needed. E.g. the user interface may display this data in a tabular format, and provide scrolling for large datasets. This requires loading data items incrementally as the user scrolls new rows into view, to avoid the UI becoming unresponsive when loading large datasets.

• Tabular layouts can be reconfigured, by e.g. changing the order of Factors (dimensions) or moving dimensions from left to top & vice-versa.

Also, the key used for referencing each data item may also allow mutating the dataset as new factors (dimensions) are added / removed. E.g. removing the gender dimension from the above example could be achieved while retaining either the Male or the Female data.

Similarly, when adding new factors, the existing dataset could be duplicated for each bucket in a new factor.

The reference matrices can be further understood with reference to figures 9 through 15.

As shown in figure 9, lookup factors can be defined by a user. In this example, a data item 900 from the employee data is indexed by various lookup factors; location, age, department and a data factor defined by the matrix (for example, a MoneyRangeMatrix factor has a minimum value Min and a maximum value Max.

Below the top level factor (age in this example), data items are displayed in multiple columns to achieve a 'flat' presentation which is easy to comprehend - so for instance in this example there is only one min MatrixFactorValue but this is rendered four times.

The data items are keyed by the lookup factors, as shown in figure 10, which shows an example where a data item 900 is used for processing an employee who is a young member of a development team based in London who is on a low salary. The item doesn't identify an individual. The relevant item which should be used when processing an employee is looked up in the reference matrix. The reference matrix contains numbers that are used in compensation calculations, and data about the employee (such as their department / age).

The lookup factors can be either mapped-by-buckets or mapped one-to-one. The mapping controls how values are defined for the factor. Buckets may be defined by ranges, and a value is created for each bucket. For example, an age of up to 35 can be defined as belonging to a young bucket and an age of 35 or more can be defined as belonging to an old bucket.

To support very large matrices, the matrix structure does not reference any data directly, as shown in figure 11. The reference matrix structure 1100 comprising the matrix, factors and buckets interfaces with the data 1102 which comprises the values and data items.

One-To-One factors do not specify buckets, and instead allow creating new Values in the Data view, as shown in figure 12. The reference matrix structure 1200 comprising the matrix, and one-to-one (121) factors interfaces with the data 1202 which comprises the one-to-one (121) values and data items.

Matrices are never referenced directly, but are mapped via a decision tree and are configured using a matrix selection field. Figure 13 shows an example screenshot of data in a matrix builder screen, comprising a Matrix with a Gender factor and an Addressl factor. In this matrix, the Gender factor comprises two buckets (Male and Female) and the Addressl factor is a one-t-one factor. As a one-to-one factor, the FactorValues (in this instance Value 1, Value 2, Value 3) can be expanded by clicking the + icon indicated.

Matrices evaluate to a Matrix Result object that contains a value for each of the Matrix's Data columns. E.g. a Matrix Result for a Money Range Matrix would have two items, one for Min and one for Max.

As discussed, MatrixDataltems are persisted individually with a ManyToMany references to relevant FactorValues, but when displaying the data view, we need MatrixDataRow objects that represent a number of Dataltems — we display and provide paging ofthe Matrix data view based on these rows.

The data in a Row varies with how the matrix structure has been configured — i.e. moving existing factors from the LEFT factor panel to the TOP factor panel (or vice-versa) changes which items are displayed in each row, but the actual Dataltems do not change in any way — the change is in the MatrixStructure, not in the Dataltems.

Therefore, when viewing a matrix, we assemble rows based on the CURRENT structure (i.e. the current arrangement of factors.) The MatrixDataRow object wraps all the cells in a a row, including cells for LHS (lookup) columns, see figure 14.

Items must be displayed in the correct column, but we don't have a guarantee that they are built in the correct order. Therefore, cells are fetched from a MatrixDataRow using a ColumnKey. ColumnKeys are based on the same data that appears in the Column header. E.g. the FactorValues that identify the column, see figure 15.

Figure 16 illustrates the operation of an interface provided to a user for applying a salary increase. A drop down box is presented (figure 16a) and when selected shows various options (figure 16b) such as the options to use a fixed amount, a matrix, or a tree. Figure 16c shows the example where a fixed amount is chosen and an increase amount of 3% can be input.

Reference Matrices and Decision Trees Combined

The disclosure provides for the combination of reference trees and matrices in a way which achieves flexibility for data processing for any general purpose but again illustrated herewith for the example of managing employee compensation.

As described above, much of the configuration data is stored in reference matrices. For example, each employees' on-target bonus amount might be stored in a reference matrix as a percentage of salary. This allows the on-target bonus amount to vary based on any criteria an enterprise chooses by defining a matrix using relevant factors - e.g. by job-grade. So the configuration for each bonus award must link to a reference matrix which defines the ontarget bonus amount values to use by each employee.

In some cases, presenting a matrix to a user is overly complex, for example if all employees should have the same on-target percentage of salary. In this instance the value is stored as a single cell in a matrix (so all employees use the same value). To aid configuring, we do not require the user to create such a single cell matrix themselves, or even know that there is a matrix configured, but we just display the single cell. The user can be presented with a drop-down or equivalent menu that offers the entry of a fixed value for a minimum and a maximum salary, but this is then equivalent to a matrix with column headers of minimum and maximum and a single row with values input for one minimum value and one maximum value.

(This example uses a matrix where each cell defines both a range minimum/maximum). Fixed value means a value which does not vary by employee - it is the same for all employees.

This provides that the data is in a matrix, but if an enterprise doesn't need variation by employee for this value, then the simpler case is easy to configure without requiring the user to knowingly create a Matrix. They can enter the Fixed Values immediately.

The more complex case is if the enterprise has values that vary by different factors for different areas of the organisation. E.g. the Marketing department set their bonus by Job Grade, but the Engineering department set their bonus by Office Location. It would be possible to construct a single matrix containing Department, Job Grade and Office Location, but this would contain duplication (the engineering department don't care what their JobGrade is, so would need values duplicated per-JobGrade, and the Marketing department don't care about OfficeLocation, so would need their values duplicated per-OfficeLocation.)

In this situation it is more efficient to have a Matrix for the engineering department (varying per Office Location), a second Matrix for the Marketing department, and a decision tree that defines which matrix to use based on Department. A decision node of the decision tree could be for selecting which department an employee is in, and then the outcome for Engineering could be a reference matrix that defines Bonus % By Job Grade, and the outcome for Marketing could be a reference matrix that defines Bonus % By Office Location.

This allows each matrix to be simpler than trying to define all scenarios in a single matrix.

In the more complex case we have a Tree, and the Tree directs us to a Matrix, and the Matrix provides the values per-employee. This combination of tree and Matrix provides vast flexibility.

In a preferred embodiment, each configuration always references a tree, and the tree always references at least one matrix. This keeps code and evaluating a value simple always tree and matrix. However, as with the SingleCeII matrix, unless the user chooses to use the tree we hide the tree from the user interface, and just use a single-node tree that always evaluates to the same matrix. The tree can be hidden from the user, but its flexibility is available if needed.

So we have three scenarios:

• Use decision tree: The user must define a decision tree, with e.g. two branches that each define a different Matrix.

• Use Matrix: A single node tree is created and hidden from the user, and the user must create a single Matrix • Fixed Value: A Single node tree is created and hidden from the user linked to a Single cell matrix which is created and hidden from the user. That single-cell is exposed for the user to enter the fixed values.

An example of how these are presented to a user is shown in figure 16.

Various modifications and improvements can be made to the above without departing from the scope of the disclosure.

It should be understood that the logic code, programs, modules, processes, methods, and the order in which the respective elements of each method are performed are purely exemplary. Depending on the implementation, they may be performed in any order or in parallel, unless indicated otherwise in the present disclosure. Further, the logic code is not related, or limited to any particular programming language, and may comprise one or more modules that execute on one or more processors in a distributed, non-distributed, or multiprocessing environment.

While aspects of the invention have been described with reference to at least one exemplary embodiment, it is to be clearly understood by those skilled in the art that the invention is not limited thereto. Rather, the scope of the invention is to be interpreted only in conjunction with the appended claims and it is made clear, here, that the inventor(s) believe that the claimed subject matter is the invention.

Claims

1. A data processing system comprising:

2. The data processing system of claim 1, comprising an integration module which maps data values to a set of properties, which act as references to the underlying data values.

3. The data processing system of claim 2, wherein the integration module is arranged to receive data values from an enterprise and to map those data values to said set of properties.

4. The data processing system of any preceding claim, wherein the decision tree data structure and matrix data structure refer to properties.

5. The data processing system of any preceding claim, wherein the decision tree data structure comprises at least one decision node referencing a property.

6. The data processing system of any preceding claim, wherein the matrix data structure comprises properties which act as lookup factors for indexing the data values.

7. The data processing system of any preceding claim, comprising a user interface through which a user interacts with decision trees and/or matrices to define a configuration.

8. A method of processing data, comprising:

storing data values related to one or more entities;

defining a configuration which implements a policy;

5 a configuration stored by the configuration module references a decision tree data structure; and said decision tree data structure references a matrix data structure.

9. A computer program product, comprising instructions that, when run on a computer, enable that computer to carry out a method comprising:

10 storing data values related to one or more entities;

defining a configuration which implements a policy;

15 a configuration stored by the configuration module references a decision tree data structure; and said decision tree data structure references a matrix data structure.