Zusammenfassung
Die Bereitsteilbarkeit guter wie auch einfacher und überzeugender Lösungen für komplexe kundenindividuelle Problemstellungen intensiviert die Kundenbeziehungen. Die Erarbeitung von Wettbewerbsvorteilen erfordert hierbei eine intelligente Integration aller Kompetenzpotentiale einer Unternehmung. Da es weder im personellen, noch im informationstechnischen Bereich, den “universellen Problemlöser” gibt, liegt Kompetenz logisch und i.d.R. auch geographisch nach Fachgebieten segmentiert in der Unternehmung vor. Fachgebiete werden im folgenden auch als Fachdomänen bezeichnet.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Abschnitt 1.1.
Vgl. die Abschnitte 2.5, 2.7 und 2.8.
Vgl. Abschnitt 1.1.
Vgl. Abschnitt 1.1.
Vgl. in anderer Form auch [BuWi93, S. 42ff].
Vgl. Abschnitt 1.2.
Vgl. [Savo85],[Savo89],[Wate861,[Pupp88].
Diese führt logische Deduktionen über dem repräsentierten Wissen aus.
Diese erläutert einem menschlichen Benutzer das Zustandekommen einer Expertise.
Vgl. [Reim91],[RiDu88].
Die sukzessive Abarbeitung von Regeln besitzt natürlich auch einen prozeduralen Charakter. Einzelne Regeln sind jedoch als deklarativ anzusehen.
Vgl. die Abschnitte 1.3 und 1.4.
Vgl. Abschnitt 1.5.2.
Auf eine detaillierte Darstellung logischer Probleme im Zusammenhang mit repräsentiertem Wissen wird an dieser Stelle verzichtet.
[BuSa93] wird explizites Wissen über vorteilhafte Kombinationen von Bankleistungen der finanzwirtschaftlichen Fachdomänen Couponanleihe, Lebensversicherung und Zerobond erarbeitet.
Vgl. die Abschnitte 1.1 und 2.4.
For most of this survey, we will rely on a simple and intuitive notion of an agent as a computational process with a single locus of control and/or “intention”. This view, however, is actually very problematic: agents may be implemented using concurrent subprocesses..., they may have multiple and conflicting goals, and the nature and reality of the concepts “goal” and “intention” are unclear... . The process of defining the boundaries of what comprises an agent interacting with a world is also fraught with difficulties, from the standpoint of epistemology, of social psychology, and, we think, of computer science [BoGa88, S. 3].
Vgl. [SmDa81].
Vgl. [LeCo81].
Vgl. [BoGa88].
Vgl. [Nii86],[JaDo89],[EnMo88].
Vgl. [Newe62].
Vgl. [DuLe89].
Diese sind • Unterstützung bei der Lösung komplexer und schlecht strukturierter Probleme. • Unterstützung bei einer verteilten Problemlösung. • Unterstützung einer guten Erweiterbarkeit und Wartbarkeit. • Unterstützung verschiedener Wissensrepräsentationsformen. • Unterstützung der expliziten Kollaboration (unter Ausnutzung von explizitem fachdomänenübergreifendem Wissen). • Unterstützung der impliziten Kollaboration (unter Ausnutzung von implizitem fachdomänenübergreifendem Wissen). • Unterstützung von Konkurrenz (durch gleichzeitige Verfolgung alternativer Lösungspfade). • Unterstützung einer flexiblen und opportunistischen Steuerung des Problemlösungsprozesses. Die Kooperationsformen explizite und implizite Kollaboration werden in Abschnitt 4.4 detaillierter vorgestellt.
Im Sinne einer “nicht flüchtigen”, dauerhaften Speicherung.
Vgl. Abschnitt 2.5.
Vgl. Abschnitt 1.3.
So besteht keine Notwendigkeit, koordinationsrelevante Daten z.B. mit Kundendaten zu vermengen.
Vgl. Abschnitt 2.2.2.
Vgl. Abschnitt 1.5.3.
Vgl. Abschnitt 1.3.
Vgl. Kapitel 3.
Vgl. Abschnitt 2.6.2.
Vgl. Abschnitt 2.6.2.
Z.B. unter Verwendung der in Kapitel 3 vorgestellten Partialmodelle.
Vgl. u.a. [KöRo93, S. 228].
Der Kundenanalyseagent ist z.B. ein Problemlösungsagent, der kein Fachagent ist.
Vgl. auch (KöRo93, S. 228],[Roem94].
Dem verteilten Problemlösungsprozeß von ALLFIWIB liegt aus Kundensicht eine Unterscheidung in drei Problemklassen von Kundenproblemen zugrunde. Dieses sind Anlageprobleme, Finanzierungsprobleme und gemischte Probleme. Die Klasse der Anlageprobleme ist dadurch gekennzeichnet, daß eine Kunde eine anfängliche Auszahlung und spätere Einzahlungen wünscht. Bei Finanzierungsproblemen ist die Zahlungsrichtung der von Anlageproblemen entgegengesetzt. Gemischte Probleme stellen Kombinationen von Anlage- und Finanzierungsproblemen dar. Die zugehörige Zahlungsreihe besitzt mehrere Vorzeichenwechsel. Anlageprobleme, Finanzierungsprobleme wie auch gemischte Probleme werden in ALLFIWIB einheidich durch einen Problemvektor repräsentiert, welcher eine Zahlungsreihe bestehend aus determinierten Zahlungen (z.B. Auszahlung von 100 GE in t = 0) und nicht determinierten Zahlungen (z.B. möglichst hohe konstante Einzahlungen in t = 1,...,T) darstellt. Vgl. [SaWe93]. Siehe auch [KöRo93, S. 224ff.].
In [BuSa93] wird explizites Wissen über vorteilhafte Kombinationen von Bankleistungen der finanzwirtschaftlichen Fachdomänen Couponanleihe, Lebensversicherung und Zerobond erarbeitet.
Eine detaillierte Beschreibung des verteilten Problemlösungsprozesses in ALLFIWIB findet man bei [Roem93] und [KöRo93].
Nach [SaWe92, S. 4ff.]. Siehe auch [KöRo93, S. 224ff.].
Der Leasingagent generiert auf PI eine Lösung S2, die keine vollständige Lösung des Kundenproblems darstellt. Es verbleibt das Restproblem P21 usw.
Z.B. eine Immobilie.
Ein Erarbeiten der Leasingvariante mit anfänglicher Einmalzahlung erfolgt lokal durch den Leasingagenten unter Verwendung leasingspezifischen Wissens. Derartiges fachdomänenspezifisches Wissen wurde z.B. in [BuEr91],[WiBu93] erarbeitet.
Auch die Konfiguration des Kreditvertrags als endfälliger Kredit obliegt der lokalen Probiemiösungskompetenz des Kreditagenten.
Vgl. auch [KöRo93, S. 225].
Vgl. [Mass93, S. 28ff.] sowie die dort angegebene Literatur.
In ALLFIWIB wurde als wissensbasierte Entwicklungsumgebung das Produkt AionDS gewählt. Es unterstützt neben der Funktionalität eines wissensbasierten Systems zusätzlich in integrierter Form auch Objektorientierung und konventionelle prozedurale Programmierung.
Vgl. [Mass93, S. 177ff.].
Zur Repräsentation von prozeduralem Methodenwissen (z.B. Lineare Optimierung) eignen sich jedoch DBMS nicht, da Methodenbanken primär Programmcode dezentral bereitstellen. Derartiges Methodenwissen könnte u.U. als Methoden in objektorientierten Datenbanken zu integrieren sein. Eine objektorientierte Datenbank, die Daten und prozedurales Methodenwissen kapselt, kann als Modellbank dienen.
Diese zukunftsweisende und ressourcenartenübergreifende Integrationsleistung einer FMDBSA ist derzeit im Prototyp von ALLFIWIB jedoch noch nicht realisiert.
Rights and permissions
Copyright information
© 1994 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
König, HJ. (1994). Flexible Datenbankarchitekturen als Integrationsplattform wettbewerbsorientierter Systeme. In: Ökonomische Datenhaltung in der Unternehmung. DUV Wirtschaftsinformatik. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-14578-3_5
Download citation
DOI: https://doi.org/10.1007/978-3-663-14578-3_5
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-2058-2
Online ISBN: 978-3-663-14578-3
eBook Packages: Springer Book Archive