DE10150391A1 - Objektmodell und Verfahren zum Erfassen von Informationen - Google Patents
Objektmodell und Verfahren zum Erfassen von InformationenInfo
- Publication number
- DE10150391A1 DE10150391A1 DE10150391A DE10150391A DE10150391A1 DE 10150391 A1 DE10150391 A1 DE 10150391A1 DE 10150391 A DE10150391 A DE 10150391A DE 10150391 A DE10150391 A DE 10150391A DE 10150391 A1 DE10150391 A1 DE 10150391A1
- Authority
- DE
- Germany
- Prior art keywords
- product
- design
- idea
- interface
- requirement
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
Abstract
Objektmodell zum Erfassen von Informationen, die produktinnovationsbezogene Daten betreffen, mit einer Produktideeschnittstelle zum Erfassen einer Idee für ein Produkt in einem Produktideeobjekt und einer Gestaltungsalternativenschnittstelle zum Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von jeweiligen Gestaltungsalternative-Objekten.
Description
Die vorliegende Erfindung betrifft allgemein die Informati
onsverwaltung und im besonderen ein System bzw. Objektmo
dell und ein Verfahren zum Erfassen und Speichern von und
Zugreifen auf Informationen, die während der Innovation ei
nes Produktes in einer beständigen und werkzeugneutralen
Form verwendet werden.
Produktentwicklung wird heutzutage von computerbasierten
Anwendungen unterstützt, u. a. durch Textverarbeitungs- und
Grafikwerkzeuge, Abwicklungswerkzeuge (Terminkoordinierung/
Ablaufsteuerung) und Produktdatenverwaltungswerkzeuge. Der
typische Produktentwicklungszyklus beginnt mit einer Idee
für ein Produkt oder einer Verbesserung für ein Produkt,
das ein Bedürfnis in der Industrie betrifft oder eine Lö
sung für ein Problem darstellt. Ausgehend von der Produkt
idee können unterschiedliche Entwürfe (Alternativgestaltun
gen) untersucht werden und schließlich wird ein Entwurf
bzw. eine Gestaltung ausgewählt, entwickelt/umgesetzt und
implementiert. Während der Anfangsphasen des Produktent
wicklungszyklus werden Textverarbeitungs-, Grafik- und Ab
laufwerkzeuge oft verwendet, um Informationen wie Marketin
ganalysen, projektierte Entwicklungsabläufe und Beschrei
bungen und Begründungen, die bestimmten ausgewählten Ent
würfen zugrunde liegen, zu erfassen. Während der Entwurfs-
bzw. Gestaltungsphase werden die Gestaltung betreffende In
formationen, wie die Gestaltungsspezifikationen und 3-D-
Modelldaten, üblicherweise unter Verwendung eines CAD-
Werkzeugs erfaßt. Während der Herstellung des Produkts wer
den Informationen zur Teileverfolgung üblicherweise unter
Verwendung eines PDM-Werkzeugs (PDM: Product Data Manage
ment, Produktdatenverwaltung) erfaßt. Zur Veranschaulichung
soll davon ausgegangen werden, daß ein Entwickler/Gestalter
eine Idee für ein neues Produkt hat. Der Entwickler ist
sich dabei mehrerer Anforderungen bewußt, die das Produkt
erfüllen muß und hat einige Lösungsideen. Der Entwickler
muß mehrere unterschiedliche Werkzeuge benutzen, um Dar
stellungen unterschiedlicher Teile der Lösung zu erzeugen.
Beispielsweise benutzt der Entwickler Microsoft Excel zum
Erzeugen einer Kostenanalyse, Corel zur graphischen Dar
stellung, SolidDesigner für ein erstes Raumbudget und Work-
Manager von CoCreate zur Erzeugung einer ersten Funktion
sorganisation.
Während es klar ist, daß unterschiedliche computerbasierte
Werkzeuge die Erfassung von Informationen und das Verfolgen
des Fortschritts eines Produktes unterstützen, weist der
Stand der Technik einige Nachteile auf. Erstens existiert
derzeit kein Werkzeug, das konkret zur Erfassung und Ver
folgung von Ideen und Entscheidungen zu diesen Ideen wäh
rend der Anfangsphasen der Produktentwicklung dient. Die
Untersuchung von Ideen ist häufig eine Situation, in der
viel Empirie bzw. Regula falsi (trial and error) betrieben
wird. Um eine derartige Untersuchung erfolgreich verfolgen
zu können, ist es notwendig, viele nur teilweise vollstän
digen Informationsstrukturen, die Entscheidungen, einen Un
tersuchungsweg weiterzuverfolgen oder aufzugeben, und die
Erklärungen/Begründungen hinter diesen Entscheidungen zu
erfassen. Es ist auch nützlich, die Absicht bzw. den Zweck
einer bestimmten Lösungsalternative zu erfassen. Im Stand
der Technik existiert kein einzelnes Werkzeug zum Erfassen
und Verfolgen derartiger wichtiger Informationen ein
schließlich der Beweggründe und Ziele eines Entwurfs, Fra
gen, Ideen und Antworten, die während der Untersuchung des
Entwurfs gestellt werden, und der gleichen Informationen
bezüglich ebenfalls untersuchter Gestaltungsalternativen.
Selbst wenn einige der Informationen unter Verwendung eines
oder mehrerer unterschiedlicher Werkzeuge erfaßt wird, weil
die Informationen nicht integriert oder einfach zugänglich
sind, außer das bestimmte Werkzeug, das zur Erfassung der
Informationen benutzt wurde, wird verwendet, werden des
weiteren viele der anfänglichen Gestaltungsabsichten und
Erklärungen/Beweggründe von Gestaltungsentscheidungen sowie
die untersuchten Gestaltungsalternativen üblicherweise
nicht effektiv erfaßt oder gehen mit Fortschreiten des Ent
wicklungszyklus des Produkts verloren.
Zusätzlich werden im Stand der Technik alle entwurfsbezoge
nen Informationen, die unter Verwendung eines bestimmten
computerbasierten Werkzeugs erfaßt werden, üblicherweise
nur über das zur Erzeugung der Daten verwendete Werkzeug
gespeichert, verwaltet und abgerufen. Es gibt mehrere Grün
de, warum die Möglichkeit, auf Daten, die von einem Werk
zeug erzeugt wurden, unter Verwendung anderer Werkzeuge zu
greifen zu können, vorteilhaft wäre. Insbesondere können
die Informationen, die unter Verwendung eines Werkzeugs er
faßt wurden, für unterschiedliche Menschen von unterschied
lichen Einheiten, die unterschiedliche Aufgaben wahrnehmen,
interessant sein. So können beispielsweise Informationen,
die während des Entwurfs bzw. der Gestaltung eines Produkts
erfaßt wurden, nicht nur für die Gestaltungsingenieure,
sondern auch für die Herstellungs- und Testingenieure, Füh
rungskräfte im Produktentwicklungsprozeß, Wartungstechni
ker, Marketing- und Verkaufspersonal, Disponenten, Personal
in der Auftragsverarbeitung, Website-Entwickler und -ver
walter, Kunden, Zulieferer usw. nützlich sein.
Es existiert demnach ein Bedürfnis, Informationen zur Pro
duktentwicklung, nachfolgend als "Innovationsinformationen"
bezeichnet, einschließlich Produktideen, Gestaltungsalter
nativen, Fragen und Antworten, die während des Innovations
prozesses untersucht wurden, Entwurfsentscheidungen usw. zu
erfassen, zu speichern und abzurufen. Es besteht auch ein
Bedürfnis, die Innovationsinformation in einer werkzeugneu
tralen Form zu erfassen, die jedem Werkzeug einen Zugriff
auf die (und ggf. auch eine Modifikation der) Innovati
onsinformationen gestattet. Ein derartiges Werkzeug würde
die Verfolgung der graduellen Entwicklung vom Entwurf und
Entscheidungen über den Entwurf über die Evolution des Pro
dukts gestatten und dabei die funktionalen entwurfsbezoge
nen Aspekte eines Produkts (anstatt wie im Stand der Tech
nik lediglich die realisierten Konfigurationen des endgül
tigen Produkts) erfassen und ein Verfolgen und Nachvollzie
hen deren Entwicklung gestatten.
Demgegenüber wird erfindungsgemäß ein Objektmodell zum Er
fassen von Informationen mit den Merkmalen des Anspruchs 1,
ein Verfahren zum Erfassen von Informationen mit den Merk
malen des Anspruchs 10 sowie ein Computerprogramm mit den
Merkmalen des Anspruchs 18 vorgeschlagen.
Die vorliegende Erfindung besteht demnach aus einem System
und einem Verfahren zum Erfassen und Speichern von und Zu
greifen auf Innovationsinformationsdaten in einer beständi
gen und werkzeugneutralen Form, die einen Datenzugriff
durch jedes Werkzeug über eine öffentlich definierte
Schnittstelle gestattet. Die Erfindung erfaßt den klaren
inkrementalen Aufbau von Innovationsinformationen ein
schließlich Produktideen, Gestaltungs- bzw. Entwurfsalter
nativen, Fragen und Antworten, die während des Innovations
prozesses untersucht wurden, Entwurfsentscheidungen usw.
Die Innovationsinformationen sind in einer Form darge
stellt, die unter Verwendung unterschiedlicher computerba
sierter Anwendungen abgefragt und auf verschiedene Weisen
wiedergegeben werden kann.
Die Erfindung erfaßt den evolutionären Aufbau von Informa
tionen, die die Ausgangsidee und die Untersuchung eines
Produkts über die Zeit betreffen. Während der Untersuchung
eines Produkts werden viele Alternativen vorgeschlagen und
erforscht. Es werden Entscheidungen gefällt, die Möglich
keiten ausschließen. Mit Fortschreiten der Gestaltung und
der Entwicklung ändern sich die gestellten Fragen und zuge
hörigen Antworten unter dem Einfluß von umfassenden Ent
scheidungen und dem Aufkommen von mehr ins Detail gehenden
Fragestellungen. Teile der Produktdefinition bewegen sich
mit unterschiedlicher Geschwindigkeit von der Idee zur
vollständigen Definition. Das Innovationsinformationen-
Objektmodell der Erfindung unterstützt das Verfolgen bzw.
Nachvollziehen der funktionalen gestaltungsorientierten
Aspekte des Produkts. Das gestaltungsorientierte Verfolgen
stellt somit ein Zeitspektrum vom Untersuchen von Produkti
deen bis zur vollständigen und für die Produktion freigege
benen Produktdefinition bereit. Die Informationen entwic
keln und gestalten sich graduell und werden mit fortschrei
tendem Gestaltungsprozeß immer detaillierter. Die Möglich
keit für Innovation ist gegeben, solange Fragen offen sind,
die kreative Antworten erfordern. Die Auswirkung von Inno
vation bewegt sich von global zu lokal, wenn Entscheidungen
gefällt und Detailfragen angegangen werden.
Die vorliegende Erfindung umfaßt vorzugsweise ein Objektmo
dell zur Verwaltung von Innovationsinformationen (nachfol
gend kurz als IIM-Objektmodell bezeichnet), das unter
schiedliche Objektmodelle erfaßt und speichert, die Infor
mationsartikel und deren zugehörige Beziehungen in einer
Objektmodelldatenbank umfassen. Jedes Objektmodell beinhal
tet Informationen und Beziehungen, die über eine öffentlich
definierte Schnittstelle zugänglich sind. In einer Ausfüh
rungsform werden beim Speichern eines Objektmodells in die
Objektmodelldatenbank unterschiedliche Typen von Informati
onsartikeln bzw. Einzelinformationen, die in dem Objektmo
dell zusammen mit ihren Beziehungen zu anderen Informati
onsartikeln bzw. Einzelinformationen enthalten sind, in un
terschiedlichen relationalen Datenbankdateien, die mit den
Informationsartikeln verknüpft sind, gespeichert. Anwendun
gen, die auf die Objektmodelldatenbank zugreifen, verwenden
lediglich die definierte Objektmodellschnittstelle, was zu
einer automatischen Trennung und Speicherung von Datenty
pobjekten in einer beständigen werkzeugneutralen Form
führt.
Die Erfindung erleichtert den Zugriff auf Informationen
mittels jeglicher Anwendung über die definierten Objektmo
dellschnittstellen, unabhängig davon, durch welche Anwen
dung die Objekte erzeugt wurden. Dadurch entsteht kein "Be
sitz" an den Daten durch eine Anwendung oder durch das
Werkzeug, das die Daten erzeugt hat.
Die Erfindung erleichtert auch anspruchsvolle Suchen in den
Objektmodellen, um interessierende Informationen aus der
Gesamtheit der gespeicherten Informationen herauszuziehen.
Die Erfindung ist in vielerlei Hinsicht vorteilhaft, ein
schließlich der Möglichkeit für eine Mehrzahl von Menschen
mit unterschiedlichen Aufgaben und Posten, auf die Informa
tionen zuzugreifen und diejenigen Informationen herauszu
ziehen, die ihrer Aufgabe bzw. ihrer Position entsprechen.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben
sich aus der Beschreibung und der beiliegenden Zeichnung.
Es versteht sich, daß die vorstehend genannten und die
nachstehend noch zu erläuternden Merkmale nicht nur in der
jeweils angegebenen Kombination, sondern auch in anderen
Kombinationen oder in Alleinstellung verwendbar sind, ohne
den Rahmen der vorliegenden Erfindung zu verlassen.
Die Erfindung ist anhand von Ausführungsbeispielen in der
Zeichnung schematisch dargestellt und wird im folgenden un
ter Bezugnahme auf die Zeichnung ausführlich beschrieben.
Fig. 1 zeigt ein konzeptionelles Objektmodelldia
gramm, das die Trennung von Informationsar
tikeln und ihrer zugeordneten Beziehungen zu
anderen Informationsartikeln darstellt.
Fig. 2 zeigt ein Blockdiagramm eines erfindungsge
mäßen Objektmodells zur Verwaltung von Inno
vationsinformationen.
Fig. 3 zeigt ein UML-Schnittstellendiagramm (UML:
Unified Modelling Language), das eine bevor
zugte Ausführungsform der Schnittstelle für
das Objektmodell zur Verwaltung von Innova
tionsinformationen (IIM-Objektmodell) für
das in Fig. 2 gezeigte IIM-Objektmodell
darstellt.
Fig. 4 zeigt ein Blockdiagramm der von dem IIM-
Objektmodell der Fig. 2 unter Verwendung
der in Fig. 3 definierten Schnittstellen
erzeugten und unterhaltenen beständigen
Speichereinheiten bzw. -entitäten.
Fig. 5 zeigt ein Anschauungsbeispiel einer relatio
nalen Datenbankdatei, mit der eine erfin
dungsgemäße Produktidee-Tabelle umgesetzt
wird.
Fig. 6 zeigt ein Anschauungsbeispiel einer relatio
nalen Datenbankdatei, mit der eine erfin
dungsgemäße Produktanforderungen-Tabelle um
gesetzt wird.
Fig. 7 zeigt ein Anschauungsbeispiel einer relatio
nalen Datenbankdatei, mit der eine erfin
dungsgemäße Gestaltungsalternativen-Tabelle
umgesetzt wird.
Fig. 8 zeigt ein Anschauungsbeispiel einer relatio
nalen Datenbankdatei, mit der eine erfin
dungsgemäße Produktfunktion-Tabelle umge
setzt wird.
Fig. 9 zeigt ein Anschauungsbeispiel einer relatio
nalen Datenbankdatei, mit der eine erfin
dungsgemäße Anforderungserfüllung-Tabelle
umgesetzt wird.
Fig. 10 zeigt einen Produktidee-Dialog für eine er
findungsgemäß umgesetzte grafische Benutzer
schnittstelle.
Fig. 11 zeigt einen Produktanforderung-Dialog für
eine erfindungsgemäß umgesetzte grafische
Benutzerschnittstelle.
Fig. 12 zeigt einen Produktfunktion-Dialog für eine
erfindungsgemäß umgesetzte grafische Benut
zerschnittstelle.
Fig. 13 zeigt einen Gestaltungsalternativen-Dialog
für eine erfindungsgemäß umgesetzte grafi
sche Benutzerschnittstelle.
Fig. 1 zeigt ein konzeptionelles Blockdiagramm, das die
Trennung von Informationsartikeln bzw. Informationsgegen
ständen bzw. Einzelinformationen und deren zugehörigen Be
ziehungen zu anderen Informationsartikeln sowie die Zu
greifbarkeit auf die Informationen mittels unterschiedli
cher Werkzeuge darstellt. Insbesondere sind eine Ansammlung
von Objektmodellen 10a, 10b, 10c, 10d, 10e und 10f, die In
formationen und von einer Anzahl unterschiedlicher Werkzeu
ge 20a, 20b, 20c, . . ., 20n während der Entwicklung eines
Produktes erzeugte Objektbeziehungen beschreiben, in werk
zeugneutraler Form in einem beständigen Speicher 30 gespei
chert. Dabei ist es wichtig, daß die Objektmodelle 10a,
10b, 10c, 10d, 10e und 10f nicht einem bestimmten Werkzeug
"gehören", insbesondere nicht den Werkzeugen 20a, 20b, 20c,
20n, von denen sie erzeugt wurden. Jedes Objektmodell
10a, 10b, 10c, 10d, 10e und 10f enthält Objekte, die höchst
abhängige Objektbeziehungen aufweisen.
Die Objektmodelle 10a, 10b, 10c, 10d, 10e und 10f verfügen
jeweils über eine definierte öffentliche Schnittstelle, die
es einem jeden die Schnittstellendefinition verstehenden
Werkzeug 20a, 20b, 20c, . . ., 20n gestattet, zulässige Daten
in den entsprechenden Satz von Objekten zu schreiben und
herauszulesen. Auch wenn die Situation eintreten kann, daß
lediglich ein Anwendungswerkzeug ein einzelnes Attribut
vollständig versteht (wie ein CAD-Werkzeug, das eine 3D-
Geometrie und -topologie versteht), gestattet es die öf
fentliche Schnittstellendefinition im Grunde genommen jedem
Werkzeug, auf Teile des Objekts, das es versteht, ein
schließlich dessen Beziehungen zu anderen Objekten, zuzu
greifen. Beispielsweise erzeugt das CAD-Werkzeug (CAD TOOL)
20a (bspw. SolidDesigner von CoCreate) Daten, die teilweise
in dem Objektmodell "CAD-Modell" (CAD MODEL) 10a und teil
weise in dem Objektmodell "Produktstruktur" (PRODUCT
STRUCTURE) 10b gespeichert werden. Es ist wichtig festzu
halten, daß das CAD-Werkzeug 20a seine interne Datenstruk
tur oder seine Benutzerschnittstelle nicht ändern muß.
Vielmehr muß das CAD-Werkzeug 20a lediglich die Fähigkeit
besitzen, nur diejenigen Objekte und Strukturen zu verste
hen, die es schreibt und liest, was durch Verwenden einer
Erweiterung erreicht werden kann, die eine Im
port/Exportfähigkeit gestattet; derartige Techniken sind im
Stand der Technik gut bekannt. In dem vorliegenden Beispiel
greift ein PDM-Werkzeug (PDM TOOL) 20b (PDM: Product Data
Management; bspw. WorkManager von CoCreate) auf das Modell
"Produktstruktur" 10b und das Modell "Gestaltungsalternati
ve" (DESIGN ALTERNATIVE) 10c zu. Entsprechend muß das PDM-
Werkzeug 20b die Fähigkeit besitzen, an dem Modell "Pro
duktstruktur" 10b von dem CAD-Werkzeug 20a vorgenommenen
Änderungen handhaben zu können, und entsprechend muß das
CAD-Werkzeug 20a die Fähigkeit besitzen, von dem PDM-
Werkzeug 20b an dem Modell "Produktstruktur" 10b vorgenom
menen Änderungen handhaben zu können. Das gemeinsame Ob
jektmodell (d. h. das Modell "Produktstruktur" 10b), das
beide verstehen, unterstützt und verbessert dabei die Kol
laboration zwischen dem CAD-Werkzeug 20a und dem PDM-
Werkzeug 20b.
Es ist auch wichtig festzuhalten, daß anderen Werkzeuge
(bspw. 20n) auch jederzeit auf die Objektmodelle 10a, 10b,
10c, 10d, 10e und 10f zugreifen können und die Anzahl von
Objektmodellen 10a, 10b, 10c, 10d, 10e und 10f jederzeit
erweitert werden kann. So erweitert und entwickelt sich die
Sammlung von Informationen und Beziehungen mit anderen Ob
jekten entsprechend während des Fortgangs des Produktzy
klus, wobei die Entwicklungs- und Gestaltungsaspekte des
Produkts festgehalten werden. Zudem gestattet die werkzeug
neutrale beständige Form der Objektmodelle sowohl synchrone
als auch asynchrone Kollaboration bei der Produktentwick
lung, indem vielen unterschiedlichen Benutzern (bspw. Inge
nieure, Entscheidungsebene, Verwaltungspersonal und sogar
Kunden) mit entsprechender Berechtigung zum Zugriff auf die
in den Objektmodellen enthaltenen Daten, die den derzeiti
gen Stand des Produkts darstellen, gestattet ist.
Unter den Objektmodellen in der Objektmodelldatenbank 30
befindet sich ein Objektmodell "Verwaltung von Innovati
onsinformationen" (INNOVATION INFORMATION MANAGEMENT) 10e
(kurz: IIM-Objektmodell), das all diejenigen Innovationsin
formationen einschließt bzw. zusammenfaßt, die mit der Ent
wicklung und Gestaltung eines Produkts, einschließlich Pro
duktideen, Gestaltungsalternativen, Fragen und Antworten,
die während des Innovationsprozesses untersucht wurden, Ge
staltungsentscheidungen usw., verbunden sind sowie ihre Be
ziehungen zu anderen Objekten in dem IIM-Objektmodell 10e
und zu Objekten in anderen Objektmodellen 10a, 10b, 10c,
10c, 10d und 10f.
Objekte in dem IIM-Objektmodell 10e können automatisch von
einem oder mehreren der Werkzeuge 20a, 20b, 20c, ..., 20n
erzeugt werden, oder sie können konkret von Nutzern über
spezifische IIM-Dialoge (IIM: Innovationsinformationen-
Management/Innovation Information Management) erzeugt wer
den, auf den über die Benutzerschnittstelle der Werkzeuge
zugegriffen wird. Zusätzlich kann ein IIM-Werkzeug (TOOL)
20c zur konkreten Eingabe von Innovationsinformationsdaten
entwickelt werden. Wie jedoch schon vorstehend angemerkt
wurde, "gehören" keinem Werkzeug die Daten in dem IIM-
Objektmodell 10e und jedes Werkzeug kann auf die Daten in
dem IIM-Objektmodell 10e über öffentlich definierte
Schnittstellen, die mit dem IIM-Objektmodell 10e in Verbin
dung stehen, zugreifen. Diese öffentlich definierten
Schnittstellen werden nachfolgend noch ausführlich erläu
tert.
Fig. 2 zeigt ein Blockdiagramm, das eine bevorzugte Aus
führungsform 100 des IIM-Objektmodells der Fig. 1 dar
stellt, durch das ein Objektmodell zum Erfassen und Spei
chern der einzelnen Informationen und deren Struktur, wie
sie während der Untersuchungsphase der Entwicklung und Ge
staltung eines Produkts in einer werkzeugneutralen bestän
digen Form entwickelt wurden, bereitstellt.
Wie in Fig. 2 dargestellt umfassen die hauptsächlichen In
formationsgegenstände in dem IIM-Objektmodell 100 die fol
genden Objekte: Produktidee (PRODUCT IDEA) 110, Produktan
forderung (PRODUCT REQUIREMENT) 120, Gestaltungsalternative
(DESIGN ALTERNATIVE) 130, Gestaltungsdarstellung (DESIGN
REPRESENTATION) 140, Produktfunktion (PRODUCT FUNCTION)
150, Durchführungsbeschränkung (REGULATORY CONSTRAINT) 160,
Gestaltungsabsicht (DESIGN INTENT) 170, Gestaltungsmerkmal
bzw. Gestaltungsbedeutung bzw. Gestaltungsanmerkung (DESIGN
NOTE) 180, Gestaltungsproblem (DESIGN ISSUE) 190 und Ge
staltungsbeschränkung (DESIGN CONSTRAINT) 195.
Ein Informationsgegenstand (oder Informationsobjekt) "Pro
duktidee" 110 schließt eine Idee betreffend ein Produkt
ein. Eine Produktidee kann eine Idee für ein neues Produkt,
eine Steigerung oder Verbesserung eines bestehenden Pro
dukts oder die Lösung eines bekannten Problems (wie eine
technische Änderung) für ein bestehendes Produkt sein.
Ein Objekt "Produktanforderung" 120 beinhaltet eine Anfor
derung, die das Produkt erfüllen muß, soll oder kann. Für
ein gegebenes Produkt gibt es üblicherweise viele Anforde
rungen von vielen verschiedenen Quellen (bspw. Marketing,
Kunden, Entwicklung, Herstellung).
Ein Objekt "Gestaltungsalternative" 130 faßt Informationen
zusammen, die eine mögliche Lösung oder Gestaltung für eine
Idee darstellen, die in einem Objekt "Produktidee" 110 zu
sammengefaßt ist. Ein Objekt "Gestaltungsdarstellung" 140
beinhaltet eine Möglichkeit, die in einem Objekt "Gestal
tungsalternative" 130 dargestellte vorgeschlagene Lösung
oder Gestaltung umsetzen bzw. herstellen.
Ein Objekt "Produktfunktion" 150 beinhaltet eine Funktion
zum Lösen einer Produktanforderung.
Ein Objekt "Durchführungsbeschränkung" 160 beinhaltet eine
Beschränkung, die dem Produkt auferlegt ist und sich außer
halb der Kontrolle der Entwickler/Gestalter befindet. Als
Beispiel seien hier gesetzlich festgelegte Kommunikations
frequenzen im Funkbereich genannt.
Ein Objekt "Gestaltungsabsicht" 170 beinhaltet eine konkrete
Absicht oder Zielsetzung der Gestaltung.
Ein Objekt "Gestaltungsmerkmal" 180 beinhaltet ein die Ge
staltung betreffendes Merkmal.
Ein Objekt "Gestaltungsproblem" 190 ist mit einer Gestal
tungsdarstellung verbunden. Das in einem Gestaltungspro
blem-Objekt enthaltene bzw. zusammengefaßte Problem be
trifft Bedenken oder eine offene Frage, die nach Betrachten
der Darstellung der Gestaltungsalternative aufgekommen
sind.
Ein Objekt "Gestaltungsbeschränkung" 195 faßt eine Be
schränkung zusammen, die der Gestaltungsalternative aufer
legt ist und über die Kontrolle besteht.
Innerhalb des IIM-Objektmodells 100 existieren Beziehungen
zwischen den Datenobjekten, wie dies durch die Verbindungs
linien zwischen den Objekten dargestellt ist. Z. B. kann je
de Produktidee 110 mit verschiedene Produktanforderungen
120 (wie sie von den Entwicklern und anderen die Gestaltung
beeinflussenden Personen definiert werden) verbunden sein,
die wiederum keine oder mehrere zugeordnete Produktfunkti
onsobjekte 150 aufweisen können, die vollständig oder teil
weise die in ihrem zugeordneten Produktanforderungsobjekt
120 niedergelegten bzw. zusammengefaßten Anforderungen er
füllen. Jede Produktidee 110 kann auch mit einigen Durch
führungsbeschränkungen 160 (wie sie bspw. durch die Indu
strie oder den Gesetzgeber definiert sein können) verbunden
sein, die wiederum durch eine Produktanforderung 120 wie
vorstehend beschrieben dargestellt sein können. Jede Pro
duktidee 110 kann auch mit mehreren Gestaltungsalternativ
objekten 130 verbunden sein, die wiederum mit Gestaltungs
absichtsobjekten 170 und zugeordneten Produktfunktionsob
jekten 150 verbunden sein können. Außerdem kann jede Ge
staltungsalternative zugeordnete Gestaltungsbeschränkungen
195 und/oder zugeordnete Gestaltungsdarstellungen 140 auf
weisen. Jede Gestaltungsdarstellung 140 kann zugeordnete
Gestaltungsbemerkungen 180 und/oder Gestaltungsprobleme 190
aufweisen.
Fig. 3 zeigt ein UML-Schnittstellendiagramm, das eine be
vorzugte Ausführungsform der IIM-Objektmodellschnittstelle
für das IIM-Objektmodell 100 der Fig. 2 darstellt. Wie in
Fig. 3 dargestellt umfassen die für das IIM-Objektmodell
200 der Fig. 2 definierten öffentlichen Schnittstellen
folgendes: Produktidee (ProductIdea) 210, Produktanforde
rung (ProductRequirement) 220, Gestaltungsalternative (De
signAlternative) 230, Gestaltungsdarstellung (DesignRepre
sentation) 240, Produktfunktion (ProductFunction) 250,
Durchführungsbeschränkung (Regulatoryconstraint) 260, Ge
staltungsabsicht (DesignIntent) 270, Gestaltungsbemerkung
(DesignNote) 280, Gestaltungsproblem (DesignIssue) 290, Ge
staltungsbeschränkung (DesignConstraint) 295 und Pro
duktspezifikation (ProductSpecification) 225. Die Attribute
für jede Schnittstelle sind wie in Fig. 3 dargestellt. In
der IIM-Schnittstellendefinition werden Informationen über
jede Produktidee in einem Objekt "Produktidee" 110 (Fig.
2) zusammengefaßt, auf das von der Schnittstelle ProductI
dea 210 zugegriffen wird. In dieser Ausgestaltung hat die
Schnittstelle ProductIdea 210 keine oder mehrere Schnitt
stellen RegulatoryConstraint 260, von denen jede mit keiner
oder mehreren Schnittstellen ProductRequirement 220 verbun
den sein kann. Die Schnittstelle ProductIdea 210 kann auch
eine Zuordnung zu keiner oder mehreren Schnittstellen Pro
ductRequirement 220 aufweisen, die aus verschiedenen Quel
len stammen können und eine angehängte Beziehung, die über
die Schnittstelle RequirementRelationship 222 definiert
ist, aufweisen können. Eine Schnittstelle ProductSpecifica
tion 225 ist eine Erweiterung der Schnittstelle ProductRequirement
220 und wird dazu verwendet, Spezifikationen
für die Anforderungen genauer zu definieren. Jede Schnitt
stelle ProductRequirement 220 kann auch keiner oder mehre
ren Schnittstellen ProductFunction 250 zugeordnet sein, die
eine Lösung zum teilweisen oder vollständigen Erfüllen ei
ner Produktanforderung bereitstellen. Die Schnittstelle
ProductFunction 250 ist in der standardisierten Schnitt
stelle PDMConfigurationManagement der "Object Management
Group (OMG) PDM Enablers" definiert, die aus dem Stand der
Technik bekannt und in "PDM Enablers: Joint Proposal to the
OMG in Response to OMG Manufacturing Domain Task Force RFP
1", Paper mfg/98-02-02 of der Object Management Group
(OMG), ausführlich beschrieben ist. Die Schnittstelle
PDMConfigurationManagement erweitert den Produktstruktur-
Enabler zur Unterstützung von Unternehmen, in denen ein
Produkt zum Verkauf in vielen unterschiedlichen Komponen
tenkonfigurationen angeboten werden kann. Das Konfiguratio
nenverwaltungsmodul erlaubt eine Spezifikation von Produkt
klassen und unterscheidenden Produktkonfigurationen. Ent
sprechend ist das IIM-Objektmodell der Erfindung kompatibel
mit den standardisierten PDM-Enabler-Schnittstellen.
Wie ebenfalls dargestellt kann die Schnittstelle Product
Idea 210 keiner oder mehreren Schnittstellen DesignAlterna
tive 230 zugeordnet sein, die einen Zugriff auf keine oder
mehrere Objekte "Gestaltungsalternative" 130, die einem be
stimmten Objekt "Produktidee" 110 zugeordnet sind, gestat
ten. Jede Schnittstelle DesignAlternative 230 hat keine
oder mehrere Schnittstellen DesignConstraint 295 und keine
oder mehrere Schnittstellen DesignRepresentation 240, die
jeweils Zugriff auf ein verbundenes Objekt "Gestaltungsein
schränkung" 195 und/oder ein zugehöriges Objekt "Gestal
tungsdarstellung" 140 gestatten. Jede Schnittstelle De
signRepresentation 240 ist keiner oder mehreren Schnitt
stellen DesignNote 280 zugeordnet, die Zugriff auf ein Ob
jekt "Gestaltungsbemerkung" 180 gestatten, und mit keiner
oder mehreren Schnittstellen DesignIssue 290, die Zugriff
auf ein Objekt "Gestaltungsproblem" 190 gestatten.
Eine Schnittstelle RequirementFulfillment 255 gestattet,
auf den Grad der Erfüllung der Produktanforderungen, die
die Produktfunktion erfüllt, zuzugreifen. Dies gestattet
einem Benutzer, das IIM-Objektmodell später im Hinblick auf
diejenigen Gestaltungsalternativen, die bestimmte ggf.
prioritätsgewichtete Anforderungen erfüllen, zu untersu
chen, um zu ermitteln, welche Gestaltungsalternative einer
Erfüllung der Anforderungen mit den höchsten Prioritäten am
nächsten kommt.
Diese Fähigkeit, das System abzufragen, indem wichtige Fra
gen gestellt werden, und eine automatische Antwort von dem
IIM-Objektmodell zu erhalten, ist ein äußerst wichtiger
Aspekt, der durch die Erfindung bereitgestellt wird.
Ein Satz von Entscheidungsschnittstellen gestatten einem
Benutzer, unterschiedliche Entscheidungen, die während der
Untersuchungsphase des Produkts getroffen wurden, zu erfas
sen und aufzufinden. Bspw. gestattet eine Schnittstelle
ProductRequirementDecision 215 das Auffinden von Fragen,
Antworten und daraus resultierenden Entscheidungen, die mit
Produktanforderungen verbunden sind. Eine Schnittstelle
ProductFunctionDecision 235 gestattet das Auffinden von
Fragen, Antworten und daraus resultierenden Entscheidungen,
die mit der Verwendung von vorgeschlagenen Produktfunkti
onslösungen in einer bestimmten Gestaltungsalternative ver
bunden sind. Eine Schnittstelle DesignAlternativeDecision
275 gestattet das Auffinden von Fragen, Antworten und dar
aus resultierenden Entscheidungen, die mit der Auswahl von
Gestaltungsalternativen verbunden sind. Eine Schnittstelle
DesignRepresentationDecision 245 gestattet das Auffinden
von Fragen, Antworten und daraus resultierenden Entschei
dungen, die mit der Auswahl in der Implementierung einer
bestimmten Gestaltungsalternative verbunden sind.
Die in dem UML-Diagramm der Fig. 3 definierten Schnitt
stellen sind vorzugsweise in einer objektorientierten Spra
che wie C++ oder Java2 implementiert. Die tatsächliche
Klassenimplementierung kann von System zu System variieren,
da es häufig sinnvoll sein wird, einige der Schnittstellen
aus Gründen einer effizienten Implementierung und/oder Lei
stung (Performance) in einer einzelnen Klasse zusammenzu
fassen.
Fig. 4 zeigt ein Blockdiagramm, das eine Ausführungsform
der beständigen Speicherentitäten darstellt, die von dem
IIM-Objektmodell 100 der Fig. 2 unter Verwendung der in
Fig. 3 definierten Schnittstellen erzeugt und unterhalten
werden. In dieser Ausführungsform ist mit jeder Schnitt
stelle eine beständige Speicherdatei, vorzugsweise in Form
einer relationalen Datenbank, verbunden. Die von der jewei
ligen Schnittstelle eingeschlossenen Daten sind in der je
weiligen zugehörigen relationalen Datenbankdatei gespei
chert. Entsprechend gibt es eine separate relationale Da
tenbankdatei für jede definierte Schnittstelle. In dem dar
gestellten Ausführungsbeispiel speichert eine Tabelle "Pro
duktidee" (PRODUCT IDEA TABLE) 310 alle verfügbaren Daten,
die die Schnittstelle Productldea 210 verwenden, eine Ta
belle "Produktanforderung" (PRODUCT REQUIREMENT TABLE) 320
speichert alle zugegriffenen Daten, die die Schnittstelle
ProductRequirement 220 verwenden, eine Tabelle "Gestal
tungsalternativen" (DESIGN ALTERNATIVE TABLE) 330 speichert
alle zugegriffenen Daten, die die Schnittstelle DesignAl
ternative 230 verwenden, eine Tabelle "Gestaltungsdarstel
lung" (DESIGN REPRESENTATION TABLE) 340 speichert alle zu
gegriffenen Daten, die die Schnittstelle DesignRepresenta
tion 240 verwenden, eine Tabelle "Produktfunktion" (PRODUCT
FUNCTION TABLE) 350 speichert alle zugegriffenen Daten, die
die Schnittstelle ProductFunction 250 benutzen, eine Tabel
le "Durchführungsbeschränkung" (REGULATORY CONSTRAINT
TABLE) 360 speichert alle zugegriffenen Daten, die die
Schnittstelle RegulatoryConstraint 260 verwenden, eine Ta
belle "Gestaltungsabsicht" (DESIGN INTENT TABLE) 370 spei
chert alle zugegriffenen Daten, die die Schnittstelle Desi
gnIntent 270 benutzen, eine Tabelle "Gestaltungsbemerkung"
(DESING NOTE TABLE) 380 speichert alle zugegriffenen Daten,
die die Schnittstelle DesignNote 280 benutzen, eine Tabelle
"Gestaltungsproblem" (DESIGN ISSUE TABLE) 390 speichert al
le zugegriffenen Daten, die die Schnittstelle DesignIssue
290 verwenden. Zusätzlich speichern die Entscheidungstabel
len "Produktanforderungsentscheidung" (PRODUCT REQUIREMENT
DECISION TABLE) 315, "Produktfunktionsentscheidung"
(PRODUCT FUNCTION DECISION TABLE) 335, "Gestaltungsdarstel
lungsentscheidung" (DESIGN REPRESENTATION DECISION TABLE)
345, "Gestaltungsalternativenentscheidung" (DESIGN ALTER
NATIVE DECISION TABLE) 375 jeweils die zugegriffenen Daten,
die die Schnittstellen ProductRequirementDecision 215, Pro
ductFunctionDecision 235, DesignRepresentationDecision 245
und DesignAlternativeDecision 275 benutzen. Eine Tabelle
"Anforderungserfüllung" (REQUIREMENT FULFILLMENT TABLE) 355
speichert die zugegriffenen Daten, die die Schnittstelle
RequirementFulfillment 255 benutzen. Die gestrichelten Li
nien, die die unterschiedlichen Tabellen miteinander ver
binden, stellen einen fremden Schlüssel (foreign key) dar
(d. h. eine gemeinsame Spalte in jeder verbundenen relatio
nalen Datenbank), der zur Darstellung der Beziehungen in
den Tabellen gespeicherten Daten verwendet wird.
Fig. 5 ist ein Anschauungsbeispiel einer relationalen Da
tenbankdatei 410, die eine Tabelle "Produktidee" 310 dar
stellt. Wie dargestellt, bildet jede Spalte "Beschreibung"
(Description) 501 und "Name" 502 auf ein in der Schnitt
stelle ProductIdea 210 eingeschlossenes bzw. enthaltenes
Attribut ab bzw. verweist auf dieses, und jede Reihe bildet
auf ein unterschiedliches Objekt "Produktidee" 110 ab.
Fig. 6 zeigt ein Anschauungsbeispiel einer relationalen
Datenbankdatei 420, die eine Tabelle "Produktanforderung"
320 umsetzt. Wiederum bildet jede Spalte "Produktideenname"
(Product Idea Name) 601, "Beschreibung" (Description) 602,
"Name" 603, "Kennung" (ID) 604, "Priorität" (Priority) 605
und "Gewichtung" (Weight) 606 jeweils auf ein in der
Schnittstelle ProductRequirement 220 eingeschlossenes bzw.
enthaltenes Attribut ab bzw. verweist auf dieses, und jede
Reihe bildet ein unterschiedliches Objekt "Produktanforde
rung" 120 ab. In diesem Beispiel ist der Primärschlüssel
(d. h. ein einziges Schlüsselfeld (Identifier) für die ge
samte Datei) für jedes Objekt "Produktanforderung" 320 des
sen Produktanforderungserkennung (in dieser Ausführungsform
in Spalte 603 gespeichert). Das Attribut "Produktideename"
des Objekts "Produktidee", mit dem das Objekt "Produktanfor
derung" 120 verbunden ist, wird als fremder Schlüssel bzw.
Kennbegriff verwendet. Entsprechend wird eine Spalte "Frem
der Schlüssel" 601 bereitgestellt, um jeweilige Objekte
"Produktanforderung" auf die zugeordneten Objekte "Produk
tidee" abzubilden.
Fig. 7 zeigt ein Anschauungsbeispiel einer relationalen
Datenbankdatei 430, die eine Tabelle "Gestaltungsalternati
ve" 330 umsetzt. Die Tabelle umfaßt die Spalten ("Produkt
ideenname" (Product Idea Name) 701, "Beschreibung" (Descrip
tion) 702, "Name" 703, "Status" 704, "Statusgrund" (Status
Reason) 705 und "Geschichte" (History) 706. In diesem Bei
spiel wird das Attribut "Produktideenname" des Objekts "Pro
duktidee", dem das Objekt "Gestaltungsalternative" 130 zu
geordnet ist, als fremder Schlüssel verwendet. Entsprechend
wird eine Spalte "Fremder Schlüssel" 701 bereitgestellt, um
jeweilige Objekte "Gestaltungsalternative" auf die zugeord
neten Objekte "Produktidee" abzubilden.
Fig. 8 ist ein Anschauungsbeispiel einer relationalen Da
tenbankdatei 450, die eine Tabelle "Produktfunktion" 350
umsetzt. Die Tabelle umfaßt die Spalten "Produktanforde
rungskennung" (Product Requirement ID) 801, "Gestaltungsal
ternativenname" (Design Alternative Name) 802, "Beschrei
bung" (Description) 803, "Name" 804, "Relevanz"
(is_relevant_for) 805. In diesem Beispiel wird das Attribut
"Produktanforderungskennung" des Objekts "Produktanforde
rung", dem das Objekt "Produktfunktion" 150 zugeordnet ist,
als ein fremder Schlüssel und das Attribut "Gestaltungsal
ternativenname" des Objekts "Gestaltungsalternative", dem
das Objekt "Produktfunktion" 150 zugeordnet ist, als ande
rer fremder Schlüssel verwendet. Entsprechend werden jewei
lige Spalten "Fremder Schlüssel" 801 und 802 bereitge
stellt, um Objekte "Produktfunktion" 150 auf ihre jeweili
gen zugeordneten Objekte "Produktanforderung" 120 und "Ge
staltungsalternative" 130 abzubilden.
Fig. 9 ist ein Anschauungsbeispiel einer relationalen Da
tenbankdatei 455, die eine Tabelle "Anforderungserfüllung"
355 umsetzt. Die Tabelle umfaßt die Spalten "Produktfunkti
onsname" (Product Function Name) 901 und "Prozent" (Per
cent) 902. Wie dargestellt, bildet die Spalte 902 auf das
Attribut "Prozent" ab, das über die Schnittstelle Require
mentFulfillment" 255 eingeschlossen ist, und jede Reihe
bildet auf ein anderes Objekt "Produktfunktion" ab. In die
sem Beispiel wird das Attribut "Produktfunktionsname" des
Objekts "Produktfunktion" 150 als fremder Schlüssel verwen
det, entsprechend wird eine Spalte "Fremder Schlüssel" 901
bereitgestellt, um ein Objekt "Anforderungserfüllung" auf
sein zugeordnetes Objekt "Produktfunktion" 150 abzubilden.
Die anderen in Fig. 4 dargestellten Tabellen sind in rela
tionalen Datenbankdateien umgesetzt, die den in den Fig.
5 bis 9 dargestellten ähnlich sind.
Die Abläufe, durch die bestimmte IIM-Daten erfaßt werden,
unterscheiden sich und sind abhängig davon, welcher Typ von
Daten erfaßt wird. Daten können erfaßt werden, wenn ein Be
nutzer Daten über eine Dialogschnittstelle manuell eingibt
(bspw. wenn ein Benutzer eine Produktidee und zugeordnete
vorgeschlagene Gestaltungsalternativen, Produktanforderun
gen und/oder Produktfunktionen unter Verwendung eines Pro
duktideedialogs in der Benutzerschnittstelle der Anwendung
eingibt), oder können von einer Anwendung automatisch er
zeugt werden (bspw. können Attribute wie Objektkennzeichner
(Identifiers), Erzeugungszeit oder Datum der letzen Ände
rung von der Anwendung zu dem Zeitpunkt, an dem eine Infor
mation erfaßt oder geändert wird, automatisch erzeugt oder
erfaßt werden). Fig. 10 zeigt beispielhaft einen Produkt
ideedialog "Product Idea" 1000 einer grafischen Benutzer
schnittstelle für eine allgemeine Anwendung, die die Fähig
keit hat, auf ein erfindungsgemäßes IIM-Objektmodell 10e
zuzugreifen und ein solches zu erzeugen. Wie dargestellt
umfaßt der Produktideedialog 1000 Benutzermöglichkeiten zum
Eingeben einer Beschreibung "Description" 1002 einer Pro
duktidee und eines Namens "Name" 1004 für die Produktidee.
Der Produktideedialog 1000 umfaßt auch Benutzermöglichkei
ten (bspw. Knöpfe 1006 und 1008) zum Eingeben vorgeschlage
ner Produktanforderungen ("Requirement" 1006) und Gestal
tungsalternativen ("Design Alternative" 1008) für die Pro
duktidee. Insbesondere wird ein in Fig. 11 dargestellter
Produktanforderung-Dialog 1010 geöffnet bzw. eingeblendet,
wenn der Benutzer auf den Knopf "Requirement" 1006 klickt.
Wie in Fig. 11 dargestellt gestattet der Produktanforde
rungdialog "ProductRequirement" 1010 dem Benutzer, eine Be
schreibung ("Description") 1012 der Produktanforderung, ei
nen Namen 1014 für die Produktanforderung und eine der Pro
duktanforderung zugewiesene Priorität ("Priority Level")
1016 einzugeben.
Auf die Benutzermöglichkeit zum Eingeben einer oder mehre
rer vorgeschlagener Produktfunktionen zum teilweisen oder
vollständigen Erfüllen der Produktanforderung kann durch
Klicken eines Knopfes "Function" 1018 zugegriffen werden,
wodurch ein in Fig. 12 dargestellter Dialog "Product Func
tion" 1020 geöffnet bzw. eingeblendet wird. Wie in Fig. 12
dargestellt, kann der Benutzer die Felder "Description"
1022 und "Name" 1024 der Funktion ausfüllen und wahlweise
an das Funktionsobjekt einen definierten Abschnitt (der dem
System bekannt ist) anhängen, der der Anwendung gestattet,
automatisch ein Objekt "Anforderungserfüllung" 255 zu er
zeugen, das angibt, wie gut die Produktfunktion die Produk
tanforderung erfüllt. Unter "Function Definition" 1026 kann
eine Funktionsdefinition eingegeben werden.
Fig. 13 zeigt beispielhaft einen Gestaltungsalternative-
Dialog "Design Alternative" 1030, der von dem Dialog "Pro
ductIdea" 1000 durch Klicken auf den Knopf "Gestaltungsal
ternative" (Design Alternative) 1008 erreicht werden kann.
Wie dargestellt, gestattet der Dialog "Design Alternative"
1030 einem Benutzer, eine Beschreibung ("Description") 1032
einen Namen 1034, einen Status 1036 und einen Grund
("Reason") 1038 für den Status 1036 einzugeben. Der Dialog
"Design Alternative" 1030 kann auch einen Knopf "Produkt
funktion" (Funktion) 1040 umfassen, der den Benutzer zu dem
Produktfunktions-Dialog 1020 der Fig. 12 führt, sowie ei
nen Knopf "Produktfunktionsentscheidung" (FunktionDecision)
1042, der einen (nicht dargestellten) Dialog öffnet bzw.
einblendet, der dem Benutzer gestattet, eine Entscheidung
über jede den Gestaltungsentwurf zugeordnete Produktfunkti
on einzugeben.
Wie vorstehend ausführlich beschrieben wurde, stellt die
Erfindung einen neuen Weg des Erfassens und Speicherns von
sowie des Zugriffs auf Daten im Zusammenhang mit der Ver
waltung von Innovationsinformationen dar, einschließlich
dem inkrementalen Aufbau von Innovationsinformationen ein
schließlich Produktideen, Gestaltungsalternativen, Fragen
und Antworten, die während des Innovationsprozesses unter
sucht wurden, Gestaltungsentscheidungen usw. Die Innovati
onsinformationen werden in einer Form dargestellt, auf die
in unterschiedlicher Weise zugegriffen werden kann und die
auf unterschiedliche Weise darstellbar ist, unter Verwen
dung von computerbasierten Anwendungen.
Die Erfindung erfaßt den evulotionären Aufbau von Informa
tionen, die die ursprüngliche Idee (Ausgangsidee) und die
Untersuchung eines Produkts über die Zeit betreffen. Wäh
rend der Untersuchung eines Produkts werden viele Alterna
tiven vorgeschlagen und erforscht. Entscheidungen werden
gefällt, die Möglichkeiten ausräumen bzw. ausschließen. Mit
fortschreitender Gestaltung ändern sich die gestellten Fra
gen und zugehörigen Antworten, da umfassende Entscheidungen
gefällt werden und detailliertere Fragestellungen auftre
ten. Teile der Produktdefinition bewegen sich von dem Sta
tus der Idee zu der fertigen Definition mit unterschiedli
cher Geschwindigkeit. Das erfindungsgemäße Objektmodell zur
Verwaltung von Innovationsinformationen unterstützt dabei
das Auffinden bzw. Nachvollziehen der funktionalen Wie-
Ausgeführt-Aspekte des Produkts. Dieses Auffinden stellt
somit ein Zeitspektrum von der Untersuchung von Produktide
en zu der vollständigen und für die Produktion freigegebe
nen Produktdefinition bereit. Die Informationen entwickeln
sich dabei graduell und werden mit fortschreitendem Gestal
tungsprozeß detaillierter. Die Möglichkeit für Innovation
ist so lang gegeben, so lange Fragen offen bleiben, die
kreative Antworten benötigen. Die Auswirkung von Innovation
bewegt sich von der umfassenden Ebene auf detailliertere
Ebenen, wenn Entscheidungen gefällt werden und Details be
rücksichtigt werden.
Die Erfindung vereinfacht den Zugriff auf Informationen
durch jede Anwendung über die definierten Objektmodell
schnittstellen, unabhängig davon, welche Anwendung die Ob
jekte erzeugt hat. Somit "gehören" die Daten keiner Anwen
dung und auch keinem Werkzeug, das die Daten erzeugt hat.
Die Erfindung vereinfacht auch anspruchsvolle Suchen in den
Objektmodellen, um interessierende Informationen aus der
Gesamtheit der gespeicherten Informationen herausfinden.
Die Erfindung ist aus vielen Gründen vorteilhaft, ein
schließlich der Tatsache, daß viele Benutzer mit unter
schiedlichen Aufgaben auf eine Art und Weise, die ihrer je
weiligen Aufgabe bzw. Bedeutung gerecht wird, auf die In
formationen zuzugreifen und Informationen herauszuziehen.
Wie nach der Lektüre der vorstehenden ausführliche Be
schreibung offensichtlich wird, verfügt die Erfindung über
einige Vorteile gegenüber dem Stand der Technik. Das erfin
dungsgemäße IIM-Objektmodell erhöht die Effizienz beim
Nachvollziehen und Verstehen, wie und warum eine Produktge
staltung eine derzeitige Konfiguration aufweist. Das erfin
dungsgemäße IIM-Objektmodell gestattet das Erfassen und
Nachvollziehen von funktionalen Wie-Gestaltet-Aspekten des
Produkts anstelle der Wie-Ausgeführt-Konfiguration des end
gültigen Produkts und stellt dadurch ein Zeitspektrum von
der anfänglichen Untersuchung von Produktideen bis zu der
vollständigen und zur Produktion freigegebenen Produktdefi
nition bereit. Die Informationen entwickeln sich graduell
und werden mit fortschreitendem Gestaltungsprozeß immer de
taillierter.
Claims (20)
1. Objektmodell zum Erfassen von Informationen, die pro
duktinnovationsbezogene Daten betreffen, mit einer Produkt
ideeschnittstelle zum Erfassen einer Idee für ein Produkt
in einem Produktideeobjekt und einer Gestaltungsalternati
venschnittstelle zum Erfassen einer Vielzahl von Gestal
tungsalternativen für das Produkt in einer Vielzahl von je
weiligen Gestaltungsalternative-Objekten.
2. Objektmodell nach Anspruch 1, mit einer Produktanfor
derungsschnittstelle zum Erfassen einer Anforderung für die
Produktidee in einem Produktanforderungsobjekt.
3. Objektmodell nach Anspruch 2, mit einer Produktfunkti
onsschnittstelle zum Erfassen einer Funktion zum Erfüllen
der Produktanforderung in einem Produktfunktionsobjekt.
4. Objektmodell nach Anspruch 3, mit einer Produkterfül
lungsschnittstelle, die erfaßt, wie gut die Produktfunktion
die Produktanforderung erfüllt.
5. Objektmodell nach Anspruch 1, mit einer Gestaltungs
darstellungsschnittstelle zum Erfassen einer Darstellung
der Gestaltungsalternative in einem Gestaltungsdarstel
lungsobjekt.
6. Objektmodell nach Anspruch 1, mit einer Entscheidungs
schnittstelle zum Erfassen einer Entscheidung in einem Pro
duktanforderungsobjekt, wobei diese Entscheidung entweder
die Produktidee oder die Gestaltungsalternative betrifft.
7. Objektmodell nach Anspruch 1, bei dem Produktideeob
jekt und jedes Gestaltungsalternative-Objekt in einer werk
zeugneutralen beständigen Form gespeichert werden.
8. Objektmodell nach Anspruch 2, bei dem Produktideeob
jekt, jedes Gestaltungsalternative-Objekt und jedes Produk
tanforderungsobjekt in einer werkzeugneutralen beständigen
Form gespeichert werden.
9. Objektmodell nach Anspruch 5, bei dem Produktideeob
jekt, jedes Gestaltungsalternative-Objekt und jedes Gestal
tungsdarstellungsobjekt in einer werkzeugneutralen bestän
digen Form gespeichert werden.
10. Verfahren zum Erfassen von Informationen, die produkt
innovationsbezogene Daten betreffen, mit den folgenden
Schritten:
Erfassen einer Idee für ein Produkt in einem Produktideeob jekt, und
Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von entsprechenden Gestaltungsal ternative-Objekten.
Erfassen einer Idee für ein Produkt in einem Produktideeob jekt, und
Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von entsprechenden Gestaltungsal ternative-Objekten.
11. Verfahren nach Anspruch 10, mit dem Schritt des Erfas
sens einer Anforderung für die Produktidee in einem Pro
duktanforderungsobjekt.
12. Verfahren nach Anspruch 11, mit dem Schritt des Erfas
sens eine Funktion zum Erfüllen der Produktanforderung in
einem Produktfunktionsobjekt.
13. Verfahren nach Anspruch 10, mit dem Schritt des Erfas
sens einer Darstellung der Gestaltungsalternative in einem
Gestaltungsdarstellungsobjekt.
14. Verfahren nach Anspruch 10, mit dem Schritt des Erfas
sens einer Entscheidung in einem Entscheidungsobjekt, wobei
die Entscheidung entweder die Produktidee oder die Gestal
tungsalternative betrifft.
15. Verfahren nach Anspruch 1, mit dem Schritt des Spei
cherns des Produktideeobjekts und jedes Gestaltungsalterna
tive-Objekts in einer werkzeugneutralen beständigen Form.
16. Verfahren nach Anspruch 10, mit dem Schritt des Spei
cherns des Produktideeobjekts, jedes Gestaltungsalternati
ve-Objekts und des Produktanforderungsobjekts in einer
werkzeugneutralen beständigen Form.
17. Verfahren nach Anspruch 13, mit dem Schritt des Spei
cherns des Produktideeobjekts, jedes Gestaltungsalternati
ve-Objekts und jedes Gestaltungsdarstellungsobjekts in ei
ner werkzeugneutralen beständigen Form.
18. Computerprogramm mit Programmanweisungen, die ein Ver
fahren zum Erfassen von Informationen, die produktinnovati
onsbezogene Daten betreffen, umsetzen, wobei das Verfahren
die folgenden Schritte umfaßt:
Erfassen einer Idee für ein Produkt in einem Produktideeob jekt, und
Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von jeweiligen Gestaltungsalter native-Objekten.
Erfassen einer Idee für ein Produkt in einem Produktideeob jekt, und
Erfassen einer Vielzahl von Gestaltungsalternativen für das Produkt in einer Vielzahl von jeweiligen Gestaltungsalter native-Objekten.
19. Computerprogramm nach Anspruch 18, bei dem das Verfah
ren den Schritt des Speicherns des Produktideeobjekts und
jedes Gestaltungsalternative-Objekts in einer werkzeugneu
tralen beständigen Form umfaßt.
20. Computerprogramm nach Anspruch 18, wobei das Verfahren
die folgenden Schritte umfaßt:
Erfassen einer Anforderung für die Produktidee in einem Produktanforderungsobjekt,
Erfassen einer Darstellung der Gestaltungsalternative in einem Gestaltungsdarstellungsobjekt, und
Speichern des Produktideeobjekts, jedes Gestaltungsalterna tive-Objekts, des Produktanforderungsobjekts und jedes Ge staltungsdarstellungsobjekts in einer separaten relationa len Datenbank, wobei Verknüpfungen zwischen den einzelnen Objekten unter Verwendung fremder Schlüssel erfaßt werden.
Erfassen einer Anforderung für die Produktidee in einem Produktanforderungsobjekt,
Erfassen einer Darstellung der Gestaltungsalternative in einem Gestaltungsdarstellungsobjekt, und
Speichern des Produktideeobjekts, jedes Gestaltungsalterna tive-Objekts, des Produktanforderungsobjekts und jedes Ge staltungsdarstellungsobjekts in einer separaten relationa len Datenbank, wobei Verknüpfungen zwischen den einzelnen Objekten unter Verwendung fremder Schlüssel erfaßt werden.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/680,751 US6944514B1 (en) | 2000-10-06 | 2000-10-06 | Innovation information management model |
Publications (1)
Publication Number | Publication Date |
---|---|
DE10150391A1 true DE10150391A1 (de) | 2002-05-08 |
Family
ID=24732367
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10150391A Ceased DE10150391A1 (de) | 2000-10-06 | 2001-10-08 | Objektmodell und Verfahren zum Erfassen von Informationen |
Country Status (2)
Country | Link |
---|---|
US (2) | US6944514B1 (de) |
DE (1) | DE10150391A1 (de) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1609080A2 (de) * | 2003-03-24 | 2005-12-28 | Siebel Systems, Inc. | Gemeinsames objekt für produkte |
US7711680B2 (en) | 2003-03-24 | 2010-05-04 | Siebel Systems, Inc. | Common common object |
US7865390B2 (en) | 2004-05-21 | 2011-01-04 | Siebel Systems, Inc. | Modeling of employee performance result data |
US7912932B2 (en) | 2003-03-24 | 2011-03-22 | Siebel Systems, Inc. | Service request common object |
US8489470B2 (en) | 2003-03-24 | 2013-07-16 | Siebel Systems, Inc. | Inventory location common object |
US9704120B2 (en) | 2003-03-24 | 2017-07-11 | Oracle International Corporation | Inventory balance common object |
Families Citing this family (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004529406A (ja) | 2000-11-10 | 2004-09-24 | アフィノバ, インコーポレイテッド | 動的なリアルタイムマーケットセグメンテーションのための方法および装置 |
US7925513B2 (en) * | 2001-03-15 | 2011-04-12 | Versata Development Group, Inc. | Framework for processing sales transaction data |
US7958024B2 (en) | 2001-03-15 | 2011-06-07 | Versata Development Group, Inc. | Method and apparatus for processing sales transaction data |
US7908304B2 (en) * | 2001-03-15 | 2011-03-15 | Versata Development Group, Inc. | Method and system for managing distributor information |
US7043481B2 (en) * | 2001-06-01 | 2006-05-09 | Thought, Inc. | System, method and software for creating, maintaining, navigating or manipulating complex data objects and their data relationships |
US7904326B2 (en) * | 2001-06-29 | 2011-03-08 | Versata Development Group, Inc. | Method and apparatus for performing collective validation of credential information |
US8538840B2 (en) * | 2002-12-20 | 2013-09-17 | Siebel Systems, Inc. | Financial services data model |
US7856454B2 (en) | 2002-12-20 | 2010-12-21 | Siebel Systems, Inc. | Data model for business relationships |
US8392298B2 (en) * | 2003-03-04 | 2013-03-05 | Siebel Systems, Inc. | Invoice adjustment data object for a common data object format |
US8473399B2 (en) * | 2003-03-04 | 2013-06-25 | Siebel Systems, Inc. | Invoice data object for a common data object format |
US20070208577A1 (en) * | 2003-03-24 | 2007-09-06 | Leon Maria T B | Position common object |
US8510179B2 (en) | 2003-03-24 | 2013-08-13 | Siebel Systems, Inc. | Inventory transaction common object |
US20070226037A1 (en) * | 2003-03-25 | 2007-09-27 | Shailendra Garg | Modeling of opportunity data |
US20040250236A1 (en) * | 2003-04-30 | 2004-12-09 | O'malley Austin | Establishing and maintaining a relationship between a three-dimensional model and related data |
US20050022156A1 (en) * | 2003-07-22 | 2005-01-27 | Joerg Schwan | Management of changes to objects |
US8112296B2 (en) * | 2004-05-21 | 2012-02-07 | Siebel Systems, Inc. | Modeling of job profile data |
US20060178928A1 (en) * | 2005-02-10 | 2006-08-10 | International Business Machines Corporation | Innovation capture system |
US20060200386A1 (en) * | 2005-03-07 | 2006-09-07 | Hartman Dorothy M | Accessing accessibility process |
US20060225047A1 (en) * | 2005-04-05 | 2006-10-05 | William Brothers | Generic software requirements analyzer |
US20070006130A1 (en) * | 2005-06-02 | 2007-01-04 | Arnold Stamler | Model oriented method of automatically detecting alterations in the design of a software system |
WO2007038770A1 (en) * | 2005-09-28 | 2007-04-05 | Michael Ira Markowitz | Inventive process documentation, management, and stimulation system |
US9235909B2 (en) | 2008-05-06 | 2016-01-12 | International Business Machines Corporation | Simplifying the presentation of a visually complex semantic model within a graphical modeling application |
US20090319239A1 (en) * | 2008-06-18 | 2009-12-24 | International Business Machines Corporation | Topology modeling application that handles abstract entities through the realization of conceptual objects |
US8849987B2 (en) * | 2008-07-29 | 2014-09-30 | International Business Machines Corporation | Automated discovery of a topology of a distributed computing environment |
US8291378B2 (en) | 2008-07-29 | 2012-10-16 | International Business Machines Corporation | Simplified deployment modeling |
US8302093B2 (en) * | 2008-08-28 | 2012-10-30 | International Business Machines Corporation | Automated deployment of defined topology in distributed computing environment |
US9280335B2 (en) | 2010-09-30 | 2016-03-08 | International Business Machines Corporation | Semantically rich composable software image bundles |
US8417658B2 (en) | 2008-09-12 | 2013-04-09 | International Business Machines Corporation | Deployment pattern realization with models of computing environments |
US8793652B2 (en) | 2012-06-07 | 2014-07-29 | International Business Machines Corporation | Designing and cross-configuring software |
DE102008047578A1 (de) * | 2008-09-17 | 2010-04-15 | Siemens Aktiengesellschaft | Verfahren und Vorrichtung zum Nachverfolgen von Anforderungen in einer Anzahl von Modellen eines Systems |
US8402381B2 (en) * | 2008-09-23 | 2013-03-19 | International Business Machines Corporation | Automatically arranging widgets of a model within a canvas using iterative region based widget relative adjustments |
US9015593B2 (en) | 2008-12-01 | 2015-04-21 | International Business Machines Corporation | Managing advisories for complex model nodes in a graphical modeling application |
US9047575B2 (en) * | 2009-05-04 | 2015-06-02 | Oracle International Corporation | Creative process modeling and tracking system |
US8799203B2 (en) * | 2009-07-16 | 2014-08-05 | International Business Machines Corporation | Method and system for encapsulation and re-use of models |
US8868446B2 (en) | 2011-03-08 | 2014-10-21 | Affinnova, Inc. | System and method for concept development |
US9208132B2 (en) | 2011-03-08 | 2015-12-08 | The Nielsen Company (Us), Llc | System and method for concept development with content aware text editor |
US20120259676A1 (en) | 2011-04-07 | 2012-10-11 | Wagner John G | Methods and apparatus to model consumer choice sourcing |
US9311383B1 (en) | 2012-01-13 | 2016-04-12 | The Nielsen Company (Us), Llc | Optimal solution identification system and method |
WO2014143729A1 (en) | 2013-03-15 | 2014-09-18 | Affinnova, Inc. | Method and apparatus for interactive evolutionary optimization of concepts |
WO2014152010A1 (en) | 2013-03-15 | 2014-09-25 | Affinnova, Inc. | Method and apparatus for interactive evolutionary algorithms with respondent directed breeding |
US10147108B2 (en) | 2015-04-02 | 2018-12-04 | The Nielsen Company (Us), Llc | Methods and apparatus to identify affinity between segment attributes and product characteristics |
EP3928269A1 (de) | 2019-02-23 | 2021-12-29 | Mezher, Maher G. | Innovationsverfahren |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5109337A (en) | 1987-10-28 | 1992-04-28 | Ibm Corporation | Conceptual design tool |
US5355317A (en) | 1991-02-26 | 1994-10-11 | Texas Instruments Incorporated | Method and apparatus for system design |
US5552995A (en) * | 1993-11-24 | 1996-09-03 | The Trustees Of The Stevens Institute Of Technology | Concurrent engineering design tool and method |
US5646862A (en) * | 1994-09-29 | 1997-07-08 | Ford Motor Company | Vendor-neutral integrated vehicle electrical design and analysis system and method |
US5754738A (en) | 1996-06-07 | 1998-05-19 | Camc Corporation | Computerized prototyping system employing virtual system design enviroment |
US6445974B1 (en) * | 1998-12-30 | 2002-09-03 | Intergraph Corporation | CAD-neutral application programming interface |
-
2000
- 2000-10-06 US US09/680,751 patent/US6944514B1/en not_active Expired - Fee Related
-
2001
- 2001-10-08 DE DE10150391A patent/DE10150391A1/de not_active Ceased
-
2005
- 2005-06-10 US US11/149,700 patent/US7050872B2/en not_active Expired - Fee Related
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1609080A2 (de) * | 2003-03-24 | 2005-12-28 | Siebel Systems, Inc. | Gemeinsames objekt für produkte |
EP1609080A4 (de) * | 2003-03-24 | 2006-11-08 | Siebel Systems Inc | Gemeinsames objekt für produkte |
US7711680B2 (en) | 2003-03-24 | 2010-05-04 | Siebel Systems, Inc. | Common common object |
US7904340B2 (en) | 2003-03-24 | 2011-03-08 | Siebel Systems, Inc. | Methods and computer-readable medium for defining a product model |
US7912932B2 (en) | 2003-03-24 | 2011-03-22 | Siebel Systems, Inc. | Service request common object |
US7962372B2 (en) | 2003-03-24 | 2011-06-14 | Siebel Systems, Inc. | Product common object |
US8200539B2 (en) | 2003-03-24 | 2012-06-12 | Siebel Systems, Inc. | Product common object |
US8489470B2 (en) | 2003-03-24 | 2013-07-16 | Siebel Systems, Inc. | Inventory location common object |
US9704120B2 (en) | 2003-03-24 | 2017-07-11 | Oracle International Corporation | Inventory balance common object |
US7865390B2 (en) | 2004-05-21 | 2011-01-04 | Siebel Systems, Inc. | Modeling of employee performance result data |
Also Published As
Publication number | Publication date |
---|---|
US20050228522A1 (en) | 2005-10-13 |
US7050872B2 (en) | 2006-05-23 |
US6944514B1 (en) | 2005-09-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10150391A1 (de) | Objektmodell und Verfahren zum Erfassen von Informationen | |
DE60311805T2 (de) | Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Merkmalen von Architekturen | |
von der Maßen et al. | Requiline: A requirements engineering tool for software product lines | |
DE602004003361T2 (de) | System und verfahren zur erzeugung von verfeinerungskategorien für eine gruppe von suchergebnissen | |
DE60002876T2 (de) | Darstellung, verwaltung und synthese von technischen inhalten | |
DE10150387A1 (de) | CAD-Datenmodell mit Entwurfsnotizen | |
DE10150388A1 (de) | Kollaborationssitzungs-Aufnahmemodell | |
EP2425331A1 (de) | Verfahren zur erzeugung mindestens einer anwendungsbeschreibung | |
DE19712946A1 (de) | Methode zum Generieren einer Implementierung wiederverwendbarer Teile von Containern eines Workflow-Prozessmodells | |
DE19955718A1 (de) | Paralleler Datenbank-Support für Workflow-Management-Systeme | |
DE10120869A1 (de) | Verwendung eines Index für den Zugriff auf eine mehrdimensionale Subjektdatenbank | |
DE10348337A1 (de) | Inhaltsverwaltungsportal und Verfahren zum Kommunizieren von Informationen | |
DE19538240A1 (de) | Informationssystem und Verfahren zur Speicherung von Daten in einem Informationssystem | |
DE112005003157T5 (de) | Domainspezifisches Datenelement-Mappingverfahren- und System | |
DE10149693A1 (de) | Objekte in einem Computersystem | |
DE60310881T2 (de) | Methode und Benutzerschnittstelle für das Bilden einer Darstellung von Daten mit Meta-morphing | |
DE112020001874T5 (de) | Datenextraktionssystem | |
DE102004043788A1 (de) | Programm Generator | |
DE19947892C2 (de) | Verfahren zur Umsetzung von Schnittstellendefinitionen und Zwischenformattabelle dafür | |
WO2007025557A1 (de) | Migration und transformation von datenstrukturen | |
DE102019220056A1 (de) | Domänenwissensinjektion in halb-schwarmausgelagerte unstrukturierte datenzusammenfassung für diagnose und reparatur | |
DE19962787A1 (de) | Verfahren zur Behandlung von Datenobjekten | |
DE602005002846T2 (de) | Verfahren zur Datenverarbeitung und assoziiertes Softwareprogramm | |
WO2021104608A1 (de) | Verfahren zum erzeugen eines engineering-vorschlags für eine vorrichtung oder anlage | |
US7574329B1 (en) | Object model for decision and issue tracking |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8131 | Rejection |