US20050010430A1

US20050010430A1 - Systems, methods, and software applications for modeling the structure of enterprises

Info

Publication number: US20050010430A1
Application number: US10/844,389
Authority: US
Inventors: Holger Gockel; Dirk Henrich; Joachim Puteick; Gregor Rieken; Martin Rogge; Dirk Rohdemann; Reiner Wallmeier; Martin Zielonkowski; Heike Berger; Hendrik Geipel; Matthias Schonecker; Orestis Terzidis
Original assignee: Individual
Current assignee: SAP SE
Priority date: 2003-05-13
Filing date: 2004-05-13
Publication date: 2005-01-13
Also published as: WO2004102436A1; US20050010549A1; EP1625539A1; US7308435B2; WO2004102437A1; EP1625538A1

Abstract

Systems, methods and computer readable media are provided for modeling the structure of an enterprise. A first class of objects may be provided, an object of the class representing an organizational unit of the enterprise, the class comprising a method for assigning and/or deassigning to an object of the class at least one type of at least five types of attributes. The five types of attributes may comprise: a first type describing a work to be performed by the unit, a second type describing a legal entity, which the unit represents, a third type describing a disciplinary or line management properties of the unit, a fourth type describing a financial responsibility of the unit, and a fifth type describing a location, which the unit represents.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 60/535,539, filed Jan. 12; 2004, EP Patent Application No. 04003696.4, filed Feb. 19, 2004, EP Patent Application No. 03010718.9, filed May 13, 2003, and EP Patent Application No. 04008853.6, filed Apr. 14, 2004, the disclosures of which are expressly incorporated herein by reference in their entireties.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The technical field of this invention is in the area of electronic data processing. More particularly, the invention relates to methods, computer program products and systems for modeling the structure of enterprises.
2. Description of the Related Art
Modeling a structure of an enterprise, particularly an extended enterprise, with business software is a critical factor for implementation time and costs and the adequateness of the software implementation itself. An extended enterprise within the concept of this invention is the set of units, which treat a business process as if it would be processed within one company, even if borders of legal entities are crossed. Typically, business applications offer a set of organizational terms driven by software needs and customers have to identify units in their enterprise which come close to the terms the software offers. Unfortunately, this match is rarely very well and, if different applications are to be implemented, interaction between these different applications may become a critical problem. An example of this is outlined in the following paragraph.
In many enterprises, different software applications are installed for performing tasks in certain areas, such as financial accounting, human resources, logistics, strategic enterprise management, and customer relationship management. Although these different software applications may exchange data with each other via interfaces, usually none of these applications contains a complete and true image of the enterprise. Instead, a partial structure of the enterprise is mapped individually to each application according to its specific needs. Such a structure is usually implemented by means of a plurality of data objects. The resulting data may be referred as “master data.” In other words, each application has its own master data of the enterprise. Once installed, such a system may work as long as no changes are made in the master data sets. However, if the structure or organization of the enterprise changes and these changes have to be adapted to the master data sets of the applications, conflicts may arise if the master data sets can not be adequately adapted. This is frequently the case, because each set of master data is only an individual and limited image of the structure of the enterprise. When performing such an adaptation, a lot of conversions have to be made, because interfaces between applications refer on different pools of entities and types of entities.
In addition, a real world unit is frequently mapped to different types of data objects in the business software, e.g., a real world unit “division” is mapped to a data object of type “cost center” and to a type “division”, which is different to “cost center”. From a computer technical point of view, this necessitates the provision of cross references and exception rules.
Thus, there is a need for systems, methods, software applications and/or data processing systems providing a more efficient solution of at least parts of the problems described above. In particular, it is desirable to provide a software application having a mechanism for modeling the structure of enterprises more efficiently.
The above description is based on the knowledge of the present inventors and not necessarily that known in the art.

SUMMARY OF THE INVENTION

In accordance with an aspect of the invention, as embodied and broadly described herein, a computer system for modeling the structure of an enterprise is provided. The computer system comprises a first class of objects, an object of said class representing an organizational unit of the enterprise, said class comprising a method for assigning and/or deassigning to an object of said class at least one type of at least five types of attributes comprising: a first type describing a work to be performed by the unit; a second type describing a legal entity, which said unit represents; a third type describing a disciplinary or line management properties of the unit; a fourth type describing a financial responsibility of the unit; and a fifth type describing a location, which said unit represents.
An object of said class may be suitable to represent each organizational unit of an enterprise. Thus, it is no longer necessary to map a single real world unit to different types of data objects. This avoids, from a technical point of view, the necessity of references and exception mechanisms and, thus, improves the maintainability of the system. The constructive overhead to maintain the integrity of the references is greatly reduced. Additionally, storage space is saved because of the smaller number of data objects necessary for modeling the structure.
Further types of attributes may be provided, as required. However, consistent with one embodiment of the invention, the five types may be considered to be suitable and sufficient to completely model the structure of an enterprise with only one class of objects. An object may only bear a single type of attribute, but it may also bear at least two or at least three or at least four or at least five types of attributes.
Second, third and fourth classes of objects may be provided to represent, for example, positions, persons, moveable or immovable things, respectively.
By using the inventive system in data processing, it is now possible to provide a complete data model even of extended enterprises, which can provide support for cross application business processes. The inventive system allows a streamline implementation of business software and increases the result of the software implementation. The inventive system covers not only the classical company organization structure, i.e. the breakdown of work, but also the aspects of legal split up, financial responsibility, line management and spatial distribution. It introduces the basic notion of the unit, that can be attributed by at least two aspects (types of attributes), which itself can carry individually hierarchies and relations. With the resulting network of first to fourth data objects, which network may as well comprise first class objects bearing only one aspect, business questions can even answer by applying business rules. Integrity and suitability of the structure model can be assured by maintaining business constraints. The invention further has a technical advantage as a lot of conversions can be saved, when changing the structure of the enterprise, because interfaces between different applications can now refer to a common pool of entities and types of entities, thereby reducing the total costs of ownership.
In accordance with another aspect of the invention, as embodied and broadly described herein, a computerized method is provided for modeling the structure of an enterprise, the method comprising: creating an object from a first class of objects; assigning an organizational unit of the enterprise to that object; assigning or deassigning to that object at least one type of at least five types of attributes, the attributes comprising: a first type describing a work to be performed by the unit; a second type describing a legal entity, which said unit represents; a third type describing a disciplinary or line management properties df the unit, a fourth type describing a financial responsibility of the unit; and a fifth type describing a location, which said unit represents.
Further aspects of the invention comprise data structures for the first, second, third and/or fourth data objects, computer programs for performing methods according to the invention and its embodiments, computer readable medium or computer program products comprising instructions for processing the inventive systems and/or data according to the inventive methods and its embodiments, respectively.
Additional objects and advantages of the various embodiments of the invention will be set forth in part in the description, or may be learned by practice of the invention. The objects and advantages of the embodiments of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. Embodiments of the invention are disclosed in the detailed description section and in the appended independent and dependent claims.
The various embodiments can include and/or exclude different aspects, features and/or advantages, where applicable. In addition, various embodiments can combine one or more aspects or features of other embodiments, where applicable.
It is understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the embodiments of the invention, as claimed. The description of aspects, features and/or advantages of particular embodiments should not be construed as limiting other embodiments or the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, explain the principles of the invention. In the drawings:
FIG. 1 is a schematic block diagram for illustrating an implementation of the invention within a computer system;
FIG. 2 is a UML class diagram for illustrating a possible implementation principle of classes of objects, according to an embodiment of the invention;
FIG. 3 is an exemplary block diagram for illustrating the principle of an application of an inventive system on an extended enterprise;
FIG. 4 is a continuation of the example of FIG. 3;
FIG. 5 illustrates an example of an implementation principle of the inventive first class objects with assigned types of attributes;
FIG. 6 illustrates an example of an implementation principle of types of assignments, of assignments and of second and third class objects;
FIG. 7 illustrates an example of an implementation principle of the assignments of second and third class objects;
FIG. 8 illustrates a block diagram of a first class object;
FIG. 9 illustrates a block diagram of a further implementation of a principle of the first class object;
FIG. 10 illustrates a block diagram of a further implementation of a principle of the first class object;
FIG. 11 illustrates a block diagram of a further implementation of a principle of the first class object;
FIG. 12 a illustrates examples of properties and attributes relating to the five types of attributes;
FIG. 12 b illustrates an example of a table by which properties and values of properties referring to the assigned attributes are assigned to a first class object; and
FIG. 12 c illustrates an example of a table by which properties may be assigned properties assigned to first class data objects.

DETAILED DESCRIPTION

Within the concept of this specification, the terms used shall have their usual meaning in the context of the field of data processing unless defined otherwise. Particularly, a computer system broadly refers to any stand-alone computer such as a PC or a laptop or a series of computers connected via a network, e.g., a network within a company, or a series of computers connected via the Internet. Computer systems and programs may be closely related. As used herein, phrases, such as “the computer provides”, “the program provides or performs specific actions”, and “a user performs a specific action” are used to express actions by a computer system that may be controlled by a program or to express that the program or program module may be designed to enable the computer system to perform the specific action or to enable a user to perform the specific action by means of a computer system. The term “automatically” is not intended to exclude a user's interactions with the computer system in the course of processing.
Units, as used herein, broadly refer to building blocks of an enterprise or an extended enterprise including a partner structure, respectively. Data objects of the first class (“first class objects”) represent such units. The types of attributes are hereinafter alternatively referred to as aspects. Accordingly, the first aspect is called “work aspect” (W), the second aspect is called “legal aspect” (L), the third aspect is called “people aspect” (P), the fourth aspect is called “money-” or “financial aspect” (F) and the fifth aspect is called “site aspect” (S). The L aspect describes an aspect of legal characteristics. The W aspect describes the distribution of labor (work breakdown). The P aspect describes the assignment of personnel. The F aspect describes the financial responsibility and the S aspect the spatial structure. From that description follows that those five aspects are different and independent of each other. Further, this set of five aspects has the advantage that it covers a vast majority of required areas for modeling enterprises. Therefore, this set may be considered to be complete. The five aspects further carry equal weight and can be treated fully symmetrical. This means that there is basically no leading aspect. The aspects carry each one or more attributes, to which a list of one or more properties is assigned. If one or more attributes is assigned to a first class object, only the properties carried by this attribute may be assigned to the respective unit. In a specific use case, each attribute or property may be used to create a structure. This is one of the advantages of the inventive system that it is not necessary, compared to the state of the art, to define one hierarchy, e.g., a line management hierarchy, as a leading structure for the modeling of the enterprise. The attributes describe more specifically—compared to the aspects—what tasks within the enterprise structure are performed by the unit. By way of non-limiting example, such attributes may be: company group (L), company (L), segment (F), profit center (F), cost center (F), source-of supply (S), target-of-supply (S), ship-of-location (S), ship-from-location (S), production location (S), inventory location (S), reporting line (P), sales (W), service (W), material requirements planning (W), purchasing (W). The related aspect is indicated in brackets.
Assignments between the first class objects (=units) can structure the units hierarchically. To each assignment, an assignment type may be assigned. By way of non-limiting examples, an assignment type may be: standard type, financial type, legal type, location type, reporting line type and work type. In this way a hierarchy may be created between the assigned objects. A rule to perform hierarchical searches within the network of objects may be: if no type of assignment other than standard type is assigned, the assignment is of standard type. So, only exceptions from standard hierarchy need to be assigned. p In computer programming languages, the first, second, third and fourth class (data-) objects of the inventive system may be implemented by means of one or more lines of one or more tables, each line having one or more data fields. In object orientated programming such objects may be implemented by instances of classes. The assignments may be implemented by entries of IDs in tables as well. The assignment of an assignment type may be implemented by an entry in an assignment table. Assignments may be directed or undirected, e.g., by entries in tables like “belongs to”, “receives from” or “reports to”. All assignments within the concept of embodiments of this invention can be descriptive. They can be filled with semantics, which can be interpreted by BAC software.
Accordingly, in one embodiment of the system, one or more attributes of one of said first or second or third or fourth or fifth type may be selected from the group consisting of company group, company, segment, profit center, cost center, source-of supply, target-of-supply, ship-of-location, ship-from-location, production location, inventory location, reporting line, sales, service, material requirements planning, and purchasing.
Further, consistent with embodiments of the invention, one or more attributes may be assigned to each type of attributes. The term “attribute” shall—within the concept of this disclosure—not be interpreted in a technical sense, i.e., as a non-key field in a data base table, but refers to all kinds of information that can be attached to an aspect to enrich the description of its business meaning. The same principle applies to the term “property”.
This enables enterprise modeling. Attributes of the L aspect may bear properties, which contain a description of the legal entity, e.g., by its name or entry in the public register of companies, the sales tax ID, address, etc. Attributes of the W aspect may bear properties, which e.g. contain a description of what has to be done (activity), what objects are to be used to do it (area) or in which system it is to be done. Attributes of the P aspect may bear properties, which contain descriptions of e.g. whether a (or which) manager is responsible for performing tasks, such as salary review, training, performance feedback, and confirmation of leave requests. Attributes of the F aspect may bear properties, which contain descriptions of the financial responsibility by specifying which finance technical key figures should flow into the results definition of the respective unit, e.g., a cost center. Attributes of the S aspect may bear properties, which contain information on the location of the respective unit, e.g., address, geographic coordinates, language specific descriptions, federal state, public holiday calendar, etc. Structuring an enterprise does not just involve the preparation of a simple list of units, but also the documentation of their relationships to each other. Differing attributes and/or properties of the same unit may be entered in the hierarchy differently. It may therefore be advantageous if the hierarchy is carried by the attributes and/or properties and not by the units. Different types of hierarchies may be maintained in parallel.
A delegation of commercial tasks may be described using an explicit hierarchy amongst the attributes or properties of the work aspects. For example, if a company produces goods, it has to buy raw material, and presumably a purchasing division will be responsible.
A particular quantity of legal entities may represent firms. They are on the same level with the same value. Above this level there may be a network of subgroups.
The breakdown of financial responsibility may be made using an explicit hierarchy. It may cross the IAS-segments and the profit centres, and end in the basic units representing cost centers, projects, orders and activities.
The spatial inclusion of sites may be mapped by an explicit hierarchy under attributes of the site aspects. If sub-characteristics are given in the same way as for financial aspects, clear requirements of the type “a warehouse is always at a site” are possible.
The reporting hierarchy may be mapped by an explicit hierarchy, e.g., “is line manager of” between the people aspects.
A further embodiment of the system is characterized by a second class of objects representing positions in the enterprise. The second class objects being assigned to one or more first class objects.
Such second class objects (positions) are useful, because in real life, work breakdown and assignment of people is pragmatic and rapidly changing. But other parts of the enterprise structure are more static and individual persons address well established sets of job responsibilities. In this case, a notion of a “should be” person is useful. The representation of such a “should be” person is a position. The position may be designed to serve as an.indirection between a person and a set of job responsibilities. Since all aspects may be treated symmetrically, positions may substitute persons in all assignments to aspects and/or attributes of units. Positions offer indirection between persons and aspects of units. But this is not exclusively. There is full freedom to use indirection and free assignment on demand. That means that one person may “just do the job” and be assigned to a position that describes all of its assignments to aspects of units. In the same model another person may be assigned directly everywhere and is not assigned to a position at all. And a third person may be assigned to a position and may undertake (be assigned to) an additional job responsibility not included in the position or have an explicitly stated different cost assignment.
Another embodiment of the system is characterized by a third class of objects representing natural persons of the enterprise, said third class objects being assigned to one or more attributes of one or more of the first class objects, and/or to one or more second class objects or to one or more first class objects.
Due to such third class objects (persons) natural persons and their sometimes complex description may be referenced from the model of the enterprise. Persons may have assignments to positions and/or attributes and/or properties of units. Persons may undertake one or more job responsibilities of a work aspect. These job responsibilities may also be connected to several types of work. Persons may belong to a legal entity. A particular affiliation could be a managing director or someone acting on his behalf. Persons may be assigned to an attribute of the F aspect, e.g., a cost center of a unit. Persons may be assigned to an attribute of the S aspect, e.g., a location, what may mean that the default location of the person is the assigned location. Persons may further be assigned to an attribute of the P aspect, e.g., as an employee or as a responsible (disciplinary) manager. The assignments are advantageously drawn to aspects of a unit and not to the unit itself. Then the assignments are free to differ from attribute to attribute. For each attribute or property, a corresponding abstract responsibility may be created, which automatically requires a corresponding person responsible. Hence, no cost center without manager, no division of labor without labor administrator(s) (foreman, manager), no firm without a chairman, etc.
Another embodiment of the system is characterized by a fourth class of objects representing movable or immovable things of the enterprise. The fourth class objects may be assigned to one or more types of attributes of one or more of the first class objects.
The fourth class objects may also be implemented by one or more lines of one or more tables.
Still another embodiment of the system is characterized by one or more rules for defining one or more evaluation algorithms to retrieve attributes or types of attributes or properties of one or more of the first class objects. Such rules are hereinafter referred to as business rules.
In the case of classic organization, a considerable amount of redundancy may arise without additional model elements. Within a classic organization, at least W, P and F aspects fall together and L and S aspects are hierarchically in sync with others. The redundancy may arise when the three hierarchies for W, P and F are stored redundantly. Furthermore, a sales employee, for example, must be assigned five times though this is redundant (at least three times to the same structure element). All legal assignments may be aligned with the P hierarchy, etc.
It is therefore useful to allow more complex rules for evaluating the knowledge contained in the model than the simple access to descriptions or relationships. A suitable means of doing this is a defaulting mechanism in the form of configurable evaluation methods, the business rules. This concept goes beyond the straight inheritance along a hierarchy, to the extent that hierarchies may themselves be transferred.
A business rule may describe a search path through the network of persons, positions, aspects of units and/or the various relationships between them. This includes the assignment of persons to aspects, the hierarchies amongst the aspects and the implicit “identity” relation between different aspects of the same unit.
Business rules may advise to follow another hierarchy, if the desired one is not maintained, to read another assignment of a person, if the assignment asked for is not specified, to follow some hierarchy up to a certain level to find the value of a property, if not assigned locally (this is close to inheritance), to read another property instead, if the information is not provided in the property asked for, etc.
The business rules may be inserted into each other. That means, if they are implemented, e.g., as subprograms, that these subprograms may call each other. For each request to the enterprise structure model by a user a business rule how to find the answer may be created. Examples of business rules include the following.

EXAMPLE 1

If a people hierarchy is maintained between two units with P and F aspects attributes or properties, but F aspect type information is required, then the people hierarchy may be used if no other explicit financial assignment is affected.

EXAMPLE 2

If a person undertakes a job responsibility depending on W aspect information (attributes and properties), whose unit also carries F aspect information (such as cost center) or a people aspect (such as department), then this person ought to be assigned to the cost center or department. If this involves a leadership function, this should also affect the financial and people leadership responsibility. This applies if no other explicit financial or people assignment for the person is implemented (which would “overwrite” the default provided by the business rule).

EXAMPLE 3

If different financial and work assignments are affected, then a business rule may be used to determine whether the two assignments can be used as a default for the financial assignment. Alternatively, the model may be flagged as inconsistent or incomplete.

EXAMPLE 4

A business rule may be defined to find the public holiday calendar for a detailed site, utilizing a business rule that implements inheritance of the public holiday calendar downwards along the S-hierarchy.

EXAMPLE 5

A business rule may be defined that lets the employer of an employee object default in the only firm it does work for. Finding the firm, which may be uniquely defined, may be implemented by calling another (presumably already implemented) business rule, that navigates from a job responsibility to a L-aspect property (i.e., the firm that runs the W-aspect).

EXAMPLE 6

A business rule may be defined that finds the “federal state” of the official residence (“office”) of an employee by first looking directly to the employee (“contract”) if anything is specified. If not, the rule may navigate from employee to person (one way is the newly introduced relation above) further to a W-aspect property for which the person undertakes a job responsibility (the path may possible branch here). Then the rule may apply another rule to find the site of a W-aspect property utilizing various hierarchies and identification via unit identity. If the investigation of the network described above results in a unique “federal state”, then the rule may deliver this “federal state” as its result. Otherwise, it may throw an exception because the structure model may be inconsistent.
Another embodiment of the system is characterized by one or more rules for the limitation of the assignments and of relations amongst first, second, third and fourth class objects. Such rules are hereinafter referred to as business constraints.
It may be advantageous to limit freedom of modelling by placing rules, the business constraints. Such rules may be of general business meaning and introduce restrictions of possible “real worlds” into the modelling activity. For example, a business constraint may be to place a profit center not below a cost center in the financials responsibility hierarchy.
On the other hand, a given business software working on a data model based on the inventive system may have functional limitations (intended or grown) that may require assumptions about what the model contains. For example, a site object that keeps stock may need a unique assignment to an owning firm.
A straightforward special case will be the constraint: “Business Rule XY should always terminate returning a unique result”. There may be, however, more intricate limitations that will need more language elements to be described.
Another embodiment comprises a system, in which one or more first class objects are assigned to an object of a fifth class and wherein a one or more rules are assigned to that fifth class object. The rules may be rules defining business processes of the enterprise.
The usefulness of this embodiment is explained by way of the following non-limiting exemplary scenario.
By means of business software systems according to the state of the art, an extended enterprise comprising a set of legally independent companies may be modeled in a computer system by assigning a plurality of different data objects to each of the companies. Each of the companies may have a data object “financial accounting”, by means of which the financial bookkeeping of the respective company is modeled. One of the tasks of the companies which are to be modeled in the software system may be, for example, the process of dunning customers. This process may be implemented according to the state of the art by defining one or more rules and assigning such rules to each of the respective data objects. An example of such a rule may be: automatically sending a dunning letter to the customer if the invoice has not been paid after four weeks. A variation of that rule may be to send the dunning letter after two weeks or, if the company is located in country A, apply procedure A1, or if located in B, apply procedure B1. Further, a set of companies may apply the first rule, and another set the second rule. The implementation in the business software system is to assign to each financial accounting data object the rule that applies to the respective company.
This procedure has two disadvantages. The first one appears when operating the system and when the rules are to be adapted according to changes in enterprise policy. Then, the rules may have to be adapted for each data object. The second disadvantage appears when installing the business software. The software supplier may not know the structure of the enterprise and consequently can not supply the structure of the financial accounting data objects. These objects have to be customized. This in turn has the consequence that the set of rules, which determine the dunning behavior of the system, may not be supplied as well and may have to be customized.
This situation may change when using the embodiment described above. Since a set of rules may be assigned to a (fifth) data object and that data object may be assigned to one or more of the first class data objects, it may be possible to change the (dunning) behavior of a plurality of financial accounting data objects by only amending one set of rules. Furthermore, it may be possible for the software supplier to predefine one or more (fifth) data objects and one or more sets of one or more rules and to provide these predefined data together with the software to the customer. When installing the software and customizing first class data objects, one or more of these first class data objects may be assigned to a predefined fifth data object thereby being provided with a predefined set of rules. This reduces the complexity of the data structure and saves installation and maintenance time and costs. It is clear to one of ordinary skill that this preferred embodiment can be applied to any type of business process.
Another embodiment comprises a system, in which a hierarchy is assigned to a first class data object. This hierarchy may reflect the organizational structure of the enterprise. The hierarchy may alternatively or additionally reflect the distribution of work within the enterprise.
This embodiment can provide the advantage that one hierarchy may be applied to all attributes and properties. Exceptions from the hierarchy in specific aspects may be defined separately.
Another embodiment of the invention comprises a system with a plurality of electronic data objects for modeling the structure of an enterprise, each electronic data object representing a unit of the enterprise and having one or more data fields. In the system, each electronic data object may have at least five data fields for assigning at least one type of the five types of attributes to the data object.
In accordance with another embodiment of the invention, a method for modeling the structure of an enterprise may be provided. The method may include the step of assigning at least two types of attributes to one or more of the first class objects.
Another embodiment of the inventive method is characterized in that the method further comprises assigning a first class object to one or more other first class objects.
Another embodiment of the inventive method comprises assigning one or more attributes to each type of attributes.
In accordance with yet another embodiment of the invention, the method may comprise creating one or more second class objects representing positions in the enterprise, the second class objects being assignable to one or more types of attributes of one or more first class objects.
Another embodiment of the invention is characterized by creating one or more third class objects representing natural persons of the enterprise, the third class objects being assignable to one or more types of attributes of one or more of the first class objects and/or to one or more second class objects.
Another embodiment of the invention comprises creating one or more fourth class objects representing movable or immovable things of the enterprise, the fourth class objects being assignable to one or more types of attributes of one or more of the first class objects.
In accordance with another embodiment the invention, a method is provided that comprises creating one or more rules for defining one or more evaluation algorithms to retrieve properties and/or attributes and/or types of attributes of one or more of the first class objects.
Additionally, another embodiment of the invention comprises creating one or more rules for the limitation of the assignments and of relations amongst first, second, third and/or fourth class objects.
Another embodiment is characterized by assigning an assignment type to an assignment.
In accordance with another embodiment of the inventive method, the method is adapted for use in software for supporting business processes.
According to another embodiment, an inheritance type is assigned to one or more of the properties. By way of non-limiting example, the inheritance type may be selected from the group comprising: local overrides inherited, inherited overrides local, additive, and no inheritance. If, for example, the inheritance type of the property “country” is “local overrides inherited”, then the value of the property “country” in first class objects in lower levels of the hierarchy may have the value of the object of the next higher level, unless it is specifically entered.
In yet another embodiment, the method comprises prompting a user whether a template should be used as the basis for creating a first or second or third or fourth class object.
Another embodiment the invention comprises, when having chosen a template, providing a wizard-like input assistant to allow the custom parameters to be filled, and then branching direct to person assignment.
These embodiments are useful if, for example, a user wishes that a sales office is represented by a unit with properties including: it (the unit) has exactly the work, financial, site and people aspect properties; it always belongs to our sales company (legal); the following responsibilities may depend on the work aspects attributes: (i) sale of products from the division <listen-variable> to customers in the federal state <festwert-variable>, (ii) organization of the sale for this work, and (iii) carrying out clerical work for all employees working at this site; the financial aspect attribute is a cost center managed by the same person who organizes the sale (work or responsibility; the people aspect has full responsibility for personnel for employees who depend on the sales responsibility (work or responsibility); the personnel responsibility for the clerical staff falls to the head office of the company for a service department; and/or the employees who assume responsibility for the sales office all have their administrative office there (site).
Another embodiment comprises assigning a hierarchy to a first class object.
Another embodiment comprises assigning one or more first class objects to an object of a fifth class and assigning a set of rules to that fifth class object.
Processors suitable for the execution of a computer program consistent with embodiments of the invention include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices (storage means) for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
To provide for interaction with a user, embodiments of the invention can be implemented on a computer system having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or haptic feedback; and input from the user can be received in any form, including acoustic, speech, or haptic input.
Reference will now be made in detail to the principles of the invention by explaining the invention on the basis of a data processing process, examples of which are illustrated in the accompanying drawings. Examples, mentioned therein, are intended to explain the invention and not to limit the invention in any manner or way.
Referring now to FIG. 1, an exemplary computer system 101 is illustrated that comprises a computer 102 and operating means 103, 104. Those skilled in the art will appreciate that methods and apparatus consistent with embodiments of the present invention apply equally to any computer system, regardless of whether the computer system is a complicated multi-user computing apparatus or a single user device such as a personal computer or workstation. In the exemplary embodiment of FIG. 1, computer 102 suitably comprises a processor 105, main memory 108, a memory controller 106, an auxiliary storage interface 112 c, a general input/output interface 112 b and a terminal interface 112 a, all of which are interconnected via a system bus 114. Note that various modifications, additions, or deletions may be made to computer system 101 illustrated in FIG. 1 within the scope of the present invention such as the addition of cache memory or other peripheral devices. FIG. 1 is presented to simply illustrate some of the salient features of computer system 101.
Processor 105 performs computation and control functions of computer system 101, and comprises a suitable central processing unit (CPU). Processor 105 may comprise a single integrated circuit, such as a microprocessor, or may comprise any suitable number of integrated circuit devices and/or circuit boards working in cooperation to accomplish the functions of a processor. Processor 105 may suitably execute (object-oriented) computer programs within main memory 108.
Auxiliary storage interface 112 c allows computer system 101 to store and retrieve information from auxiliary storage devices, such as a magnetic disk (e.g., hard disks or floppy diskettes) or optical storage devices (e.g., CD-ROM). One suitable storage device is a direct access storage device (DASD) 107. As shown in FIG. 1, DASD 107 may be a hard disk drive which may read programs and data from a hard disk. It is important to note that while embodiments of the present invention are described in the context of a fully functional computer system, those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media to actually carry out the distribution. Further examples of signal bearing media include: recordable type media such as floppy disks and CD ROMS, and transmission type media such as digital and analogous communication links, including wireless communication links.
Memory controller 106, through use of a processor is responsible for moving requested information from main memory 108 and/or through auxiliary storage interface 112 c to processor 105. While for the purposes of explanation, memory controller 106 is shown as a separate entity, those skilled in the art understand that, in practice, portions of the function provided by memory controller 106 may actually reside in the circuitry associated with processor 105, main memory 108, and/or auxiliary storage interface 112 c.
Terminal interface 112 a allows system administrators and computer programmers to communicate with computer system 101, normally through monitor 104, keyboard 103, mouse, trackball and the like or through programmable workstations. Although the system 101 depicted in FIG. 1 contains only a single main processor 105 and a single system bus 114, it should be understood that the present invention applies equally to computer systems having multiple processors and multiple system buses. Similarly, although the system bus 114 of the preferred embodiment is a typical hardwired, multidrop bus, any connection means that supports directional communication in a computer-related environment could be used.
Input/output interface 112 b allows computer system 101 via processor 105 to communicate with general input/output means 109, including a net connection 110, for sending and/or receiving data, e.g. for a net connection with one or more further computer systems 111, or for sending or receiving of data to or from other parties. A plurality of computer systems like computer system 101, can be connected via the net connection 110 in the form of a network. In such a case, the network computers 111 can be used as further input/output means, including the use as further storage locations.
In a preferred embodiment, memory 108 suitably includes an operating system, programs and data, particularly a software application 113, a system 114 of (data) objects comprising a plurality of first class objects 115, one or more second class objects 116, one or more third class objects 117, one or more fourth class objects 118, a set of business rules 119 and a set of business constraints 120, which all may be held in memory 108 for being accessed or applied by program 113.
It should be understood that for purposes of this application, memory 108 is used in its broadest sense, and may include Dynamic Random Access Memory (DRAM), Static RAM (SRAM), flash memory, cache memory, etc. While not explicitly shown in FIG. 1, memory 108 may be a single type of memory component or may be composed of many different types of memory components. For example, memory 108 and CPU 105 may be distributed across several different computers that collectively comprise system 101. It should also be understood that programs in memory 108 can include any and all forms of computer programs, including source code, intermediate code, machine code, and any other representation of a computer program.
The operating system provides the basic functionality that controls the computer system 101. Operating system can comprise any suitable operating system, such as IBM's OS/400, OS/2, Microsoft's Windows, Java and the various flavours of UNIX. The database 117 provides the mechanism for persistently storing object data in the computer system 101, and can be any suitable, preferably relational database such as those available from IBM, Oracle or Microsoft.
Those skilled in the art will appreciate that more than one of the mentioned processors may work in parallel in a computer system.
For purposes of illustration, FIG. 8 shows a general example of a first class object 801 to which attributes of five types of attributes (aspects) are assigned, consistent with an embodiment of the invention. In the exemplary embodiment of FIG. 8, attributes 802 (W), 803 (L), 804 (F), 805 (S) and 806 (P) are assigned to first class object 801. The assignment may be implemented by, for example, a screen mask, which allows selecting one or more of the five aspects by clicking boxes and which is presented to the user when the first class object is created. FIG. 8 may also be interpreted as to show a class of objects 801 comprising a method for assigning and/or deassigning to an object of said class at least one of at least five types of the attributes (aspects) 802 (W), 803 (L), 804 (F), 805 (S) and 806 (P). The assignment and deassignment of the attributes may be carried out using a screen mask or other suitable screen display or user-controlled method.
FIG. 9 illustrates further principles of the invention by way of a non-limiting, more detailed example of a first class object 901 to which five types of attributes (aspects) 902 (W), 903 (L), 904 (F), 905 (S) and 906 (P) are assigned. A plurality of attributes 902 a (to W), 903 a (to L), 904 a (to F), 905 a (to S) and 906 a (to P) may be assigned to each aspect, respectively. Further, a third class data object representing a person 902 p (to W), a person 903 p (to L), a person 904 p (to F), a person 905 p (to S) and a person 906 p (to P) may be assigned to each aspect, respectively. The attributes may be grouped hierarchically.
Attributes 902 a may describe the work to be performed by the unit, which is represented by first class object 901. Single attributes may describe an activity, a work area, responsibilities or the like. Third class data object 902 p may represent a person, such as a foreman.
Attributes 903 a may describe the legal entity to which the unit, which is represented by first class object 901, belongs. Single attributes may describe a corporation, an entry in a (trade) register, address information, tax ID or the like. Third class data object 903 p may represent a person, such as a CEO, a procurator, or the like.
Attributes 904 a describe the financial responsibility to which the unit, which is represented by first class object 901, belongs. Single attributes may describe cost centers and their hierarchy. Third class data object 904 p may represent, for example, a person in charge.
Attributes 905 a may provide a location description of the unit, which may be represented by first class object 901, belongs. Single attributes may describe address information, geographical coordinates, language-specifics or the like.
Attributes 906 a may describe the disciplinary responsibility of the unit, which is represented by first class object 901, belongs. Single attributes may describe a line management hierarchy. Third class data object 906 p may represent a person, such as a disciplinary manager.
FIG. 10 illustrates principles of the invention by way of a non-limiting, more detailed further example of a first class object 1001. In the embodiment of FIG. 10, five types of attributes (aspects) 1002 (W), 1003 (L), 1004 (F), 1005 (S) and 1006 (P) are assigned to first class object 1001. The assignments in FIG. 10 may be implemented in a similar to that in the embodiment of FIG. 9. In such a case, the numbering in FIG. 10 corresponds to that in FIG. 9, “9” being replaced by “10”. As illustrated in FIG. 10, a plurality of attributes 1002 a (to W), 1003 a (to L), 1004 a (to F), 1005 a (to S) and 1006 a (to P) may be assigned to each aspect, respectively. Further, a third class data object representing a person 1002 p (to W), a person 1003 p (to L), a person 1004 p (to F), a person 1005 p (to S) and a person 1006 p (to P) may be assigned to each aspect, respectively. In this embodiment, a hierarchy 1007 may be assigned to first class object 1001. This hierarchy may be applied to all aspects. Exceptions from the hierarchy, which may appear in all aspects, may be defined within the attributes, as is shown exemplary for the money aspect.
Referring now to FIG. 2, a UML class diagram is shown that describes a possible implementation of the first to third class data objects and their assignments, consistent with an embodiment of the invention. FIG. 2 shows a class of first class objects 201 (unit) comprising data fields for an identifier (id) 228 and a name 229. At least two, in the example at least 5 further data fields are available for the assignment of types of attributes. A unit 201 may be assigned to one or more of the types of attributes (aspects) 203, 204, 205, 206, 207, which are shown—and may be implemented—as classes in the UML diagram. As shown in FIG. 2, aspect class 203 may be the legal (L) aspect class, aspect class 204 may be the financial or money (M) aspect class, aspect class 205 may be the site (S) aspect class, aspect class 206 may be the people (P) aspect class, and aspect class 207 may be the work (W) aspect class.
Legal aspect 203 may comprise one or more attributes 1 to n, which describe the legal entity represented by the respective unit 201, for example, the name, the entry in the list of companies, etc. The financial aspect 204 may comprise one or more attributes 1 to n, which describe what types of finance technical indexes are to be continued to one of respective units 201, for instance, costs, revenues, reliabilities, debts, etc. Site aspect (class 205) may comprise one or more attributes 1 to n, which describe the properties of the spatial structuring contained in the respective unit 201, for example, geographic, coordinates, address, opening hours, language characteristics, etc. Instances of the people aspect class 206 may comprise one or more attributes 1 to n, which describe which measures of personal management are applied on the respective unit by a responsible manager, for example, performance feedback, salary dispute, leave requests, etc. The work aspects (class 207) may comprise links 1 to n to data objects 214, which represent job responsibilities of the respective unit 201.
The job responsibilities 214 may differ in so far from the attributes of the other aspects mentioned above as they are itself structured data objects. In a job responsibilities object 214, it may be described what has to be done and on what objects the respective work has to be performed. A connection 213 from aspect 207 to job responsibility 214 may indicate by the filled rhombus that a job responsibility 214 may exist in the context with a work aspect 207 and the “1” may indicate that it exists only in the context of a single work aspect 207. The “*” at the connection line 213 indicates that any number of job responsibilities 214 may be assigned to one work aspect 207.
As already mentioned, aspects may be assigned to units. These assignments 208, 209, 210, 211 and 212 are now described in more detail. The composition 202 from the class of units 201 to the classes of aspects 203 to 207 may indicate that one unit may have assigned five attributes. The filled rhombus may indicate that an aspect exists only in the context with a unit. The “0 . . . 1” may indicate that either one aspect of a class of aspects 203 to 207 may be assigned to one unit 201. The assignment 208 may describe a line management hierarchy in that any number (*) of units 201 may report to one people aspect. The combination of the composition 202 and the assignment 208 means that in the case of an instance diagram a people aspect may be assigned to a unit (202) and a further unit may be assigned to that people aspect via an assignment (208) to the respective unit which has that people aspect assigned. A hierarchy is created by the assignment 208 in combination with assignment 202 because the assignment 208 is directed to the people aspect via its property “reports to”. The same principles may apply with respect to the creation of hierarchies relating to the other aspects by using combinations of the relations 202 and 209, 210, 211 and 212, respectively. However, the assignment 211 may differ from the other assignments, because an “*” is attached to both ends of the connection line. This reflects the fact that one company may belong to a plurality of other companies and each company may be a partial owner of the other companies.
FIG. 2 further shows a class of third class objects 215 (persons), which may represent persons of a unit or enterprise. These third class objects may comprise data fields 1 to n, for describing properties of the persons like name, address, etc. These third class objects 215 may be assigned to aspects of the classes 203 to 207, whereby the attributes of the aspects of class 207 are the data objects 214, the job responsibilities. These assignments are represented by the connection line from 216 to 220. Further, a type of assignment is assigned to each of these assignments. The assignment 216 may be of the type “belongs to”, assignment 217 may be the type “accounts to”, assignment 218 may be the type “works at”, assignment 219 may be the type “reports to” and assignment 220 may be the type “undertakes”. These assignments may be analyzed by business rules. The assignment 216 may mean that the respective person is an employee of the respective company were legal entity. So, a business rule analyzing the data may retrieve the company a special person belongs to. The assignment 217 may describe the cost center to which the person accounts. The assignment 218 may mean that the person is considered to work at a specific place, for example, his/her normal office. The assignment 219 may mean that the person reports to another person who is assigned to the same people aspect 207 by another assignment 219 a. The assignment 220 may mean that the respective person performs the work described in the respective job responsibility 214.
FIG. 2 further shows a class of second class objects 221, which may represent positions of a unit or enterprise, for instance, the position of a housekeeper. Persons 215 may be assigned to positions 221 by assignments 222, which are of the type “occupies”. Such positions 221 may be assigned to aspects (classes 203 to 207) by assignments 223, 224, 225, 226 and 227 in the same way as described for the persons 215. The advantage of the concept of the positions may be that in case a specific person leaves its position and another person occupies that positions, only one assignment may be drawn, namely from the other person to the respective positions. In the case of “without position”, all assignments of the leaving person would have to be reassigned to the other person.
FIGS. 3 to 7 illustrate an example of an application of the invention for an enterprise group, which sells and repairs certain goods. FIGS. 3 and 4 show the structure of the enterprise group in the form of a block diagram containing first class objects representing the units of the enterprise group, as well as their relationships. FIGS. 5 to 7 show an example of an implementation of the data model of that enterprise group by means of tables 1 to 9, which tables may be implemented by.means of a database system, particularly a relational database system.
The enterprise group may be represented by a first class object 301 (FIG. 3), the structure of which is shown in table 1 of FIG. 5. Each line of table 1 may represent a first class object, abbreviated as unit in the following section. Each unit has a data field for an identifier (UnitID) and a name (Unit Name). Further, five data fields L, W, F, P, S may be available for assigning the respective type of attributes (aspect) to the unit. Such an assignment is given, if a Y is entered in the respective data field. Unit 301 has the ID 1, the name N1 and a L aspect.
Unit 301 may represent the leading entity of the enterprise group. Each unit further has a data field “Attr.”, which may contain a reference to a further table, in which the attributes of the respective aspect of the respective unit may be defined. In the example of unit 11 the Attr. field references to a table ATTID11 (table 2 a). By means of such a table attributes 1 to N may be assigned to each type of aspects. The number N may be different for each aspect. In this specific example a first attribute “work organization” and a second attribute “repair order” are assigned to the W aspect of unit 11.
With reference to unit 12, table 2 b shows that a first attribute “work organization” and a second attribute “customer order” may be assigned to the W aspect of unit 12. The units as defined by table 1 further compromise a data field “Assignm.” by means of which are the units may be assigned to the respective unit. The Assignm. field references to a table, in which the assignments of a specific unit to other units are contained. An example of such an assignment table is table 4.
Table 4 of FIG. 6 shows exemplary assignments of unit 4. The assignment field of unit 4 references to the assignment table ASMID4 shown in table 4. Each line of table 4 may contain one assignment. An assignment consists of an assignment number AsmNo, the identifier of the assigned unit and a type of assignment. In case of the system having N units, N-1 assignments may be established to other units. In the example of table 4 unit 4 has four assignments and is assigned to units 2, 7, 8 and 9. The first assignment is of a type L1, the second to fourth assignments are of a type S1. The types of assignments are described by means of table 3. Each line of table 3 defines one type of assignment. An assignment comprises a type name data field “type” and a description data field “description”. Accordingly, the first assignment of unit 4 is of the type “belongs to”.
As shown in FIG. 3, units 302 and 303 may be assigned. to unit 301 by assignments 311, 310. Both assignments are of the type “belongs to.” Units 302 and 303 may represent subsidiaries named N2 and N3 belonging to the enterprise group. named N1. Depending on the properties of the respective subsidiaries, unit 303 may have all five aspects assigned and unit 302 may have four aspects assigned. Starting from unit 302, the structure of the enterprise further branches to units 304, 305 and 306. These three units may be assigned to unit 302 by assignments 312, 313 and 314, each of the type “belongs to.” Units 305 and 306 represent branches of the legal entity represented by unit 302 and therefore have no own legal (L) aspect. Unit 304 represents a location of unit 302 at a specific place and therefore may have only a site (S) aspect.
Starting from unit 304, the structure of the enterprise further branches to units 307, 308 and 309, which may be assigned to units 304 by assignments 315, 316 and 317. These assignments are all of the type S1, “works at” (compare table 3), what may mean that they are located at the site defined in unit 304. Units 307 and 308 may represent depots of unit 302 and therefore have only an “S” aspect. Units 309 may represent a branch of unit 302 having own work organization, line management hierarchy, financial responsibility and location and may therefore have the respective four aspects.
In FIG. 4, unit 309 of FIG. 3 is explained in more detail as unit 401. The branch 401 of the subsidiary 302 may have three units 402, 403 and 404 assigned. Unit 404 may represent a repair division, and unit 403 may represent a purchasing division. Both units may be assigned to unit 401 by an assignment of type W1, “undertakes something”, and attribute of the W aspect, which may mean that both units are part of the work organization of unit 401. Both units may further have financial responsibility and, therefore, carry additionally an F aspect. Unit 402 only represents a depot of unit 401 and therefore carries only an S aspect. Its connection to unit 401 is of a type “works at”.
In FIG. 4, position 405 is assigned to the P aspect of unit 401. A position is a data object, which may be implemented as a line of a table as described in table 5 of FIG. 6. A position may comprise a data field for an ID, a data field for a description and, optionally, further data fields. The assignment of a position to an aspect of a unit may be implemented by means of a table as shown in table 8 of FIG. 7. Therein, one line may represent one assignment. A first data field “PosID” may contain the ID of the position to be assigned. A second data field “UnitID” may contain the ID of the unit which carries the aspect to which the position is to be assigned. A third data field “ToAtt” may contain the aspect to which the position is assigned. A fourth data field “ToAsm” may contain the type of assignment, which may be taken from table 3 of FIG. 6. As can be seen from table 8, a single position may be assigned to different aspects of different units and one aspect of a unit may have a different position assigned. This is shown by a position 416, which is assigned to the F aspect of units 404 and 403. The assignment type of position 405 to unit 401 is P1, “manages company”, which may mean that the position is for a person who manages the unit of the enterprise represented by unit 401. The assignment of position 416 is of type F1, “accounts to”, which may mean that position 416 is financed by units 404 and 403. Consequently, a person 406 may be assigned to position 405. A person is a data object representing a natural person. Again, such data object may be implemented as a line of a table as described in table 6 of FIG. 6. Therein a person comprises a data field “PersID” for an ID, a data field “name” for the name of the respective person and, optionally, further data fields for further information about the person. The assignment of persons to positions may be implemented by means of a table as shown in table 7 of FIG. 7. One person may be assigned to one or more positions and one position may have one or more persons assigned. Additionally, a type of assignment may be assigned to the assignment of persons to positions in the same way as pointed out above. In FIG. 4, the assignment of person 406 (e.g., “Steve Miller”) to position 405 (e.g., company manager) is type W2 (e.g., fulfills), which may mean that Steve Miller is the manager of the unit of the enterprise represented by unit 401. Further, a person 415 may be assigned to position 416 by a type W2 assignment as well.
A number of attributes 1 to n may be assigned to the W aspect via table 407, which corresponds to table 2 a of FIG. 5. As shown in FIG. 4, a second person 408 may be assigned to the first and to the second attribute of the W aspect of unit 404. A third person 409 and a fourth person 410 may be assigned to the second attribute of said W aspect. These assignments of persons to attributes may be implemented by means of a table as shown in table 9 of FIG. 7. Therein, one line represents one assignment. A first data field “PersID” may contain the ID of the person to be assigned. A second data field, “UnitID”, may contain the ID of the unit, which may carry the respective aspect. A third data field “Attr” may contain a link to the data field in which the target attribute of the assignment may be stored. In the example of Pers3, there may be the second attribute of the W aspect of unit 404, “repair order.” Additionally, a type of assignment may be assigned to the assignment of persons to attributes in the same way as discussed above. In table 9, this may be implemented by a data field “ToAsm”. In addition, the assignment of person 409 may be of a type “fulfills”, which may mean that person 409 performs repair orders in the repair division.
Further, the same rules may apply in principle to the attributes in table 411, corresponding to table 2 b of FIG. 5. Persons 412, 413, and 414 may be assigned to attributes of the W aspect of unit 403 in the same way as pointed out in the preceding paragraph.
As will be appreciated by those skilled in the art, the embodiments of FIGS. 3-7 are merely examples, and other database models and structures may be utilized for modeling an enterprise, consistent with the present invention. FIGS. 12 a-12 c described below, illustrate examples of such further embodiments.
For purposes of further illustration, FIG. 11 shows another embodiment of the present invention by way of a non-limiting, example of a first class object 1101 to which attributes 110Xa-n of five types of attributes (aspects) 1102 (W) 1103 (L), 1104 (F), 1105 (S) and 1106 (P) are assigned. One or more attributes 1102 a-1102 d (to W), 1103 a-1103 b (to L), 1104 a-1104 c (to F), 1105 a-1105 f (to S) and 1106 a (to P) is assigned to each aspect, respectively. Further, a second class data object 1109 representing a position is assigned to unit 1101. Position 1109 may bear a list 1108 of one or more properties depending on the attributes assigned to unit 1101. A third class data object 1110 may also be provided. Third class data object 1110 may represent a person is assigned to position 1109.
As shown in FIG. 11, attributes 1102 a-1102 d describe the work to be performed by the unit, which is represented by first class object 1101. Single attributes may describe an activity, a work area, responsibilities or the like. In the example of FIG. 11, sales, service, material requirements planning (MRP) and purchasing are illustrated for attributed 1102 a-1102 d, respectively.
Attributes 1103 a describe the legal entity to which the unit, which is represented by first class object 801. Single attributes may describe, for example, a corporation, an entry in a (trade) register, address information, tax ID or the like. Further, attributes 1104 a-1104 c may describe the financial responsibility to which the unit, which is represented by first class object 1101, belongs. Single attributes may describe cost centers, profit centers, segments, etc. and their hierarchy.
Attributes 1105 a-1105 f may provide a location description of the unit, which is represented by first class object 1101. Single attributes may describe address information, geographical coordinates, language-specifics or the like. In the example of FIG. 11, source-of-supply, target-of-supply, ship-to-location, ship-from-location, production-location and inventory-location are illustrated as examples of attributes 1205 a-1205 f, respectively. Further, attributes 1106 a describe the disciplinary responsibility of the unit, which is represented by first class object 1101. Single attributes may describe a reporting line or line management hierarchy.
To provide a further understanding of principles of the invention, reference is now made to FIGS. 12 a-12 c. The examples of FIGS. 12 a-12 c may be used in combination with the teachings of FIGS. 3-7, as further detailed below. FIG. 12 a illustrates examples of properties and attributes relating to the five types of attributes. FIG. 12 b illustrates an example of a table by which properties and values of properties referring to the assigned attributes are assigned to a first class object. FIG. 12 c illustrates an example of a table by which properties may be assigned properties assigned to first class data objects.
The table in FIG. 12 c shows how further properties like hierarchy types or inheritance types or other properties can be assigned to the properties defined by the attributes. Such a table may be queried by applications, which operate on the properties, e.g., business rules or constraints.
Modifications and adaptations of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments of the invention disclosed herein. The foregoing description of implementations of the invention has been presented for purposes of illustration and description. It is not exhaustive and does not limit the invention to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing embodiments of the invention. For example, the described implementations include software, but systems and methods consistent with the present invention may be implemented as a combination of hardware and software or in hardware alone. Additionally, although aspects of the present invention are described for being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on other types of computer-readable media, such as secondary storage devices, for example, hard disks, floppy disks, or CD-ROM; the Internet or other propagation medium; or other forms of RAM or ROM.
Computer programs based on the written description and flow charts of this invention are within the skill of an experienced developer. The various programs or program modules can be created using any of the techniques known to one skilled in the art or can be designed in connection with existing software. For example, programs or program modules can be designed in or by means of Java, C++, HTML, XML, or HTML with included Java applets or in SAP R/3 or ABAP. One or more of such modules can be integrated in existing e-mail or browser software.
While illustrative embodiments of the invention have been described herein, the present invention is not limited to the various preferred embodiments described herein, but includes any and all embodiments having equivalent elements, modifications, omissions, combinations (e.g., of aspects across various embodiments), adaptations and/or alterations as would be appreciated by those in the art based on the present disclosure. The limitations in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application, which examples are to be construed as non-exclusive. For example, in the present disclosure, the term “preferably” is non-exclusive and means “preferably, but not limited to.” Means-plus-function or step-plus-function limitations will only be employed where for a specific claim limitation all of the following conditions are present in that limitation: a) “means for” or “step for” is expressly recited; b) a corresponding function is expressly recited; and c) structure, material or acts that support that structure are not recited.
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

1. A computer system for modeling the structure of an enterprise comprising a first class of objects, an object of said class representing an organizational unit of the enterprise, said class comprising a method for assigning and/or deassigning to an object of said class at least one type of at least five types of attributes comprising:

a first type describing a work to be performed by the unit;

a second type describing a legal entity, which said unit represents;

a third type describing a disciplinary or line management properties of the unit;

a fourth type describing a financial responsibility of the unit; and

a fifth type describing a location, which said unit represents.

2. The system of claim 1, wherein a first class object is assigned to one or more other first class objects.

3. The system of claim 1, wherein one or more attributes are assigned to each type of attribute.

4. The system of claim 3, wherein one or more attributes of one of said first or second or third or fourth or fifth type are selected from the group comprising of company group, company, segment, profit center, cost center, source-of supply, target-of-supply, ship-of-location, ship-from-location, production location, inventory location, reporting line, sales, service, material requirements planning (MRP), and purchasing.

5. The system of claim 1, further comprising a second class of objects representing positions in the enterprise, said second class objects being assigned to one or more types of attributes of one or more first class objects.

6. The system of claim 1, further comprising a third class of objects representing persons of the enterprise, one or more third class objects being assigned to one or more tyeps of attributes of one or more of the first class objects and/or to one or more second class objects.

7. The system of claim 1, further comprising a fourth class of objects representing movable or immovable things of the enterprise, one or more fourth class objects being assigned to one or more types of attributes of one or more first class objects.

8. The system of claim 1, further comprising one or more rules for defining one or more evaluation algorithms to retrieve attributes and/or types of attributes of one or more of the first class objects.

9. The system of claim 1, further comprising one or more rules for the limitation of assignments and of relations amongst first, second, third, and/or fourth class objects.

10. The system of claim 9, wherein an assignment type is assigned to an assignment.

11. The system of claim 10, wherein the assignment type is selected from the group comprising of standard type, financial type, legal type, location type, reporting line type and work type.

12. The system of claim 1, wherein one or more first class objects are assigned to an object of a fifth class and wherein one or more rules are assigned to that fifth class object.

13. The system of claim 1, wherein a hierarchy is assigned to a first class object.

14. A computerized method for modeling the structure of an enterprise, the method comprising:

creating an object from a first class of objects;

assigning an organizational unit of the enterprise to that object; and

assigning or deassigning to that object at least one type of at least five types of attributes comprising:

a first type describing a work to be performed by the unit,

a second type describing a legal entity, which said unit represents,

a third type describing a disciplinary or line management properties of the unit,

a fourth type describing a financial responsibility of the unit, and

a fifth type describing a location, which said unit represents.

15. The method of claim 14, further comprising assigning at least two types of attributes to one or more of said first class objects.

16. The method of claim 14, further comprising assigning a first class object to one or more other first class objects.

17. The method of claim 14, further comprising assigning one or more attributes to each type of attribute.

18. The method of claim 17, wherein one or more attributes of one of said first or second or third or fourth or fifth type are selected from the group comprising of company group, company, segment, profit center, cost center, source-of supply, target-of-supply, ship-of-location, ship-from-location, production location, inventory location, reporting line, sales, service, material requirements planning (MRP), and purchasing.

19. The method of claim 14, further comprising:

creating one or more objects of a second class representing positions in the enterprise; and

assigning said second class objects to one or more types of attributes of one or more first class objects.

20. The method of claim 14, further comprising:

creating one or more objects of a third class representing natural persons of the enterprise; and

assigning said third class objects to one or more types of attributes of one or more of the first class objects and/or to one or more second class objects.

21. The method of claim 14, further comprising:

creating one or more objects of a fourth class representing movable or immovable things of the enterprise; and

assigning said fourth class objects to one or more types of attributes of one or more of the first class objects.

22. The method of claim 14, further comprising creating one or more rules for defining one or more evaluation algorithms to retrieve attributes or types of attributes of one or more of the first class objects.

23. The method of claim 14, further comprising creating one or more rules for the limitation of assignments and of relations amongst first, second, third and fourth class objects.

24. The method of claim 14, further comprising assigning an assignment type to an assignment.

25. The method of claim 24, wherein the assignment type is selected from the group comprising of standard type, financial type, legal type, location type, reporting line type and work type.

26. The method of claim 14, further comprising assigning one or more first class objects to an object of a fifth class and assigning one or more rules to that fifth class object.

27. The method of claim 14, further comprising assigning a hierarchy to a first class object.

28. A computer readable medium comprising instructions for causing a processor to perform a method for modeling the structure of an enterprise comprising a first class of objects, an object of said class representing an organizational unit of the enterprise, said class comprising a method for assigning and/or deassigning to an object of said class at least one type of at least five types of attributes comprising:

a first type describing a work to be performed by the unit;

a second type describing a legal entity, which said unit represents;

a fourth type describing a financial responsibility of the unit; and

a fifth type describing a location, which said unit represents.

29. The computer readable medium of claim 28, wherein the method further comprises assigning at least two types of attributes to one or more of said first class objects.

30. The computer readable medium of claim 28, wherein the method further comprises assigning a first class object to one or more other first class objects.

31. The computer readable medium of claim 28, wherein the method further comprises assigning one or more attributes to each type of attribute.

32. The computer readable medium of claim 31, wherein one or more attributes of one of said first or second or third or fourth or fifth type are selected from the group comprising of company group, company, segment, profit center, cost center, source-of supply, target-of-supply, ship-of-location, ship-from-location, production location, inventory location, reporting line, sales, service, material requirements planning (MRP), and purchasing.

33. The computer readable medium of claim 28, wherein the method further comprises:

34. The computer readable medium of claim 28, wherein the method further comprises:

35. The computer readable medium of claim 28, wherein the method further comprises:

36. The computer readable medium of claim 28, wherein the method further comprises creating one or more rules for defining one or more evaluation algorithms to retrieve attributes or types of attributes of one or more of the first class objects.

37. The computer readable medium of claim 28, wherein the method further comprises creating one or more rules for the limitation of assignments and of relations amongst first, second, third and fourth class objects.

38. The computer readable medium of claim 28, wherein the method further comprises assigning an assignment type to an assignment.

39. The computer readable medium of claim 38, wherein the assignment type is selected from the group comprising of standard type, financial type, legal type, location type, reporting line type and work type.

40. The computer readable medium of claim 28, wherein the method further comprises assigning one or more first class objects to an object of a fifth class and assigning one or more rules to that fifth class object.

41. The computer readable medium of claim 28, wherein the method further comprises assigning a hierarchy to a first class object.

42. An electronic data structure for modeling the structure of an enterprise, comprising a first class of objects, an object of said class representing an organizational unit of the enterprise, said class comprising a method for assigning and/or deassigning to an object of said class at least one type of at least five types of attributes comprising:

a first type describing a work to be performed by the unit;

a second type describing a legal entity, which said unit represents;

a fourth type describing a financial responsibility of the unit; and

a fifth type describing a location, which said unit represents.