U.S. patent application number 10/844389 was filed with the patent office on 2005-01-13 for systems, methods, and software applications for modeling the structure of enterprises.
Invention is credited to Berger, Heike, Geipel, Hendrik, Gockel, Holger, Henrich, Dirk, Puteick, Joachim, Rieken, Gregor, Rogge, Martin, Rohdemann, Dirk, Schonecker, Matthias, Terzidis, Orestis, Wallmeier, Reiner, Zielonkowski, Martin.
Application Number | 20050010430 10/844389 |
Document ID | / |
Family ID | 33568867 |
Filed Date | 2005-01-13 |
United States Patent
Application |
20050010430 |
Kind Code |
A1 |
Gockel, Holger ; et
al. |
January 13, 2005 |
Systems, methods, and software applications for modeling the
structure of enterprises
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.
Inventors: |
Gockel, Holger; (Speyer,
DE) ; Henrich, Dirk; (Wiesloch, DE) ; Puteick,
Joachim; (Ubstadt-Weiher, DE) ; Rieken, Gregor;
(Walldorf, DE) ; Rogge, Martin; (Ostringen,
DE) ; Rohdemann, Dirk; (Muhlhausen, DE) ;
Wallmeier, Reiner; (Wiesloch, DE) ; Zielonkowski,
Martin; (Freinsheim, DE) ; Berger, Heike;
(Oberhausen, DE) ; Geipel, Hendrik; (Walldorf,
DE) ; Schonecker, Matthias; (Hambrucken, DE) ;
Terzidis, Orestis; (Schwetzingen, DE) |
Correspondence
Address: |
FINNEGAN, HENDERSON, FARABOW, GARRETT & DUNNER
LLP
1300 I STREET, NW
WASHINGTON
DC
20005
US
|
Family ID: |
33568867 |
Appl. No.: |
10/844389 |
Filed: |
May 13, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60535539 |
Jan 12, 2004 |
|
|
|
Current U.S.
Class: |
705/7.29 ;
705/348 |
Current CPC
Class: |
G06Q 30/0201 20130101;
G06Q 10/067 20130101; Y10S 707/99931 20130101; G06Q 10/06 20130101;
G06Q 10/10 20130101 |
Class at
Publication: |
705/001 |
International
Class: |
G06F 017/60 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 19, 2004 |
EP |
04003696.4 |
May 13, 2003 |
EP |
03010718.9 |
Apr 14, 2004 |
EP |
04008853.6 |
Claims
What is claimed:
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 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.
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: 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.
34. The computer readable medium of claim 28, wherein the method
further comprises: 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.
35. The computer readable medium of claim 28, wherein the method
further comprises: 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.
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 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.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 1. Field of the Invention
[0003] 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.
[0004] 2. Description of the Related Art
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] The above description is based on the knowledge of the
present inventors and not necessarily that known in the art.
SUMMARY OF THE INVENTION
[0010] 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.
[0011] 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.
[0012] 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.
[0013] Second, third and fourth classes of objects may be provided
to represent, for example, positions, persons, moveable or
immovable things, respectively.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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
[0020] 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:
[0021] FIG. 1 is a schematic block diagram for illustrating an
implementation of the invention within a computer system;
[0022] FIG. 2 is a UML class diagram for illustrating a possible
implementation principle of classes of objects, according to an
embodiment of the invention;
[0023] FIG. 3 is an exemplary block diagram for illustrating the
principle of an application of an inventive system on an extended
enterprise;
[0024] FIG. 4 is a continuation of the example of FIG. 3;
[0025] FIG. 5 illustrates an example of an implementation principle
of the inventive first class objects with assigned types of
attributes;
[0026] FIG. 6 illustrates an example of an implementation principle
of types of assignments, of assignments and of second and third
class objects;
[0027] FIG. 7 illustrates an example of an implementation principle
of the assignments of second and third class objects;
[0028] FIG. 8 illustrates a block diagram of a first class
object;
[0029] FIG. 9 illustrates a block diagram of a further
implementation of a principle of the first class object;
[0030] FIG. 10 illustrates a block diagram of a further
implementation of a principle of the first class object;
[0031] FIG. 11 illustrates a block diagram of a further
implementation of a principle of the first class object;
[0032] FIG. 12a illustrates examples of properties and attributes
relating to the five types of attributes;
[0033] FIG. 12b 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
[0034] FIG. 12c illustrates an example of a table by which
properties may be assigned properties assigned to first class data
objects.
DETAILED DESCRIPTION
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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".
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] The reporting hierarchy may be mapped by an explicit
hierarchy, e.g., "is line manager of" between the people
aspects.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] The fourth class objects may also be implemented by one or
more lines of one or more tables.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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
[0058] 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
[0059] 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
[0060] 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
[0061] 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
[0062] 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
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] The usefulness of this embodiment is explained by way of the
following non-limiting exemplary scenario.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] Another embodiment of the inventive method comprises
assigning one or more attributes to each type of attributes.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] Another embodiment is characterized by assigning an
assignment type to an assignment.
[0085] In accordance with another embodiment of the inventive
method, the method is adapted for use in software for supporting
business processes.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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).
[0090] Another embodiment comprises assigning a hierarchy to a
first class object.
[0091] 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.
[0092] 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).
[0093] 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.
[0094] 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.
[0095] 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 112c, a general input/output interface
112b and a terminal interface 112a, 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.
[0096] 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.
[0097] Auxiliary storage interface 112c 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.
[0098] Memory controller 106, through use of a processor is
responsible for moving requested information from main memory 108
and/or through auxiliary storage interface 112c 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
112c.
[0099] Terminal interface 112a 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.
[0100] Input/output interface 112b 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.
[0101] 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.
[0102] 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.
[0103] 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.
[0104] Those skilled in the art will appreciate that more than one
of the mentioned processors may work in parallel in a computer
system.
[0105] 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.
[0106] 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 902a (to W), 903a (to L), 904a (to F), 905a (to S) and
906a (to P) may be assigned to each aspect, respectively. Further,
a third class data object representing a person 902p (to W), a
person 903p (to L), a person 904p (to F), a person 905p (to S) and
a person 906p (to P) may be assigned to each aspect, respectively.
The attributes may be grouped hierarchically.
[0107] Attributes 902a 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 902p may represent a person,
such as a foreman.
[0108] Attributes 903a 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 903p may represent a person, such as a CEO, a procurator, or
the like.
[0109] Attributes 904a 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 904p may represent, for example,
a person in charge.
[0110] Attributes 905a 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.
[0111] Attributes 906a 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 906p may represent a person,
such as a disciplinary manager.
[0112] 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 1002a (to W), 1003a (to L), 1004a (to F),
1005a (to S) and 1006a (to P) may be assigned to each aspect,
respectively. Further, a third class data object representing a
person 1002p (to W), a person 1003p (to L), a person 1004p (to F),
a person 1005p (to S) and a person 1006p (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.
[0113] 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.
[0114] 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.
[0115] 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.
[0116] 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.
[0117] 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 219a. The assignment 220
may mean that the respective person performs the work described in
the respective job responsibility 214.
[0118] 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.
[0119] 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.
[0120] 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.
[0121] 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 2a). 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.
[0122] With reference to unit 12, table 2b 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.
[0123] 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".
[0124] 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.
[0125] 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.
[0126] 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".
[0127] 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.
[0128] A number of attributes 1 to n may be assigned to the W
aspect via table 407, which corresponds to table 2a 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.
[0129] Further, the same rules may apply in principle to the
attributes in table 411, corresponding to table 2b 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.
[0130] 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. 12a-12c described
below, illustrate examples of such further embodiments.
[0131] 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
1102a-1102d (to W), 1103a-1103b (to L), 1104a-1104c (to F),
1105a-1105f (to S) and 1106a (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.
[0132] As shown in FIG. 11, attributes 1102a-1102d 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 1102a-1102d, respectively.
[0133] Attributes 1103a 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 1104a-1104c 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.
[0134] Attributes 1105a-1105f 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 1205a-1205f, respectively.
Further, attributes 1106a 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.
[0135] To provide a further understanding of principles of the
invention, reference is now made to FIGS. 12a-12c. The examples of
FIGS. 12a-12c may be used in combination with the teachings of
FIGS. 3-7, as further detailed below. FIG. 12a illustrates examples
of properties and attributes relating to the five types of
attributes. FIG. 12b 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. 12c
illustrates an example of a table by which properties may be
assigned properties assigned to first class data objects.
[0136] The table in FIG. 12c 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.
[0137] 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.
[0138] 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.
[0139] 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.
[0140] 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.
* * * * *