 |
Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com |
|
| Die verzweifelte Suche nach Integrationslösungen - EAI, Workflow, CRM, Integration Server, Middleware...? |
 |
| Abstract |
| Warum Integrationslösungen wieder interessant werden |
| Orientierungsprobleme |
| Worauf es wirklich ankommt |
| Wie Unternehmen dem Dilemma entgehen können |
|
 |
|
| Abstract |
| | | | Immer häufiger stehen Unternehmen vor der Notwendigkeit, ihre heterogenen DV-Lösungen zu optimieren. Da die weitgehende Ablösung durch eine integrierte Gesamtlösung häufig nicht möglich ist, werden Wege zur Integration der bestehenden Applikationen gesucht. Eine Orientierung selbst in bezug auf die benötigte Systemkategorie stellt viele Unternehmen auf Grund des Wildwuchses von Definitionen, Schlagworten und Leistungsbeschreibungen vor erhebliche Probleme und Investitionsrisiken.
| | |
|
|
|
| Warum Integrationslösungen wieder interessant werden |
| | | | Die Beweggründe für eine intensive Beschäftigung mit dem Thema Integrationsanforderungen und mögliche Lösungen sind im wesentlichen die gleichen wie schon vor zehn und mehr Jahren. Da ist zunächst der Leidensdruck in der IT-Abteilung zu nennen. Dieser ist zum einen auf die exponential steigenden Kosten für Pflege und Wartung der bestehenden Applikationen zurückzuführen. Zum anderen sind Change Management-Erfordernisse und Anforderungen der Fachabteilungen zur Realisierung neuer Bearbeitungsabläufe sowie komplett neuer Applikationen die Ursache. Immer öfter müssen zudem bisher getrennte DV-Lösungen im Rahmen von Unternehmensfusionen zusammengeführt werden. Die Realisierung von nur einigen wenigen Schnittstellen zum Austausch von vor allem Buchhaltungsdaten wird dabei immer seltener als ausreichend erachtet. Eine weitere Ausgangssituation stellt die Ausgründung von IT-Abteilungen in eigenständige Dienstleistungsunternehmen dar, die im Rahmen der notwendigen Optimierung der vorhandenen Systemlösungen die Themen Integration und Prozesssteuerung aufgreifen.
| | |
|
| | | | Eine Vielzahl von Unternehmen haben in den vergangenen Jahren bereits weitreichende Umstellungen ihrer DV-Systeme mit der Beschränkung auf möglichst wenig Plattformen und der Einführung integrierter ERP-Lösungen in Verbindung mit einem hohen Maß an Standards durchgeführt. Wenn diese Unternehmen dann noch neue zusätzliche Lösungen wie z.B. die Einführung von DMS/Archivsystemen nicht als Einzel- sondern als Infrastrukturlösungen eingeführt haben, können sich die IT-Leiter bei Schlagworten wie EAI (Enterprise Application Integration) oder noch moderner iEAI (inter Enterprise Application Integration) beruhigt zurücklehnen und den Hype an sich vorüberziehen lassen.
| | |
|
| | | | Allerdings gibt es ebenfalls eine Vielzahl von Unternehmen, die auf die Entwicklung von Individuallösungen angewiesen sind und solche, zu deren „Strategie“ die Einführung möglichst vieler unterschiedlicher (Abteilungs-) Lösungen gehört. In beiden Fällen lassen sich die Entwicklungen, die zu den heute bestehenden Problemen geführt haben, auf gleichartige Ursachen zurückführen. So sehen sich viele IT-Abteilungen von den Anforderungen der Fachabteilungen zu schnellen und damit möglichst abgegrenzten und einfachen Lösungen genötigt, insbesondere wenn ihnen für die Bereitstellung der Lösung nur kurze Zeiträume zur Verfügung stehen. In einigen Fällen sehen die betroffenen IT-Leiter die damit verbundenen (zukünftigen) Probleme, in anderen Fällen sind schlichtweg gravierende Versäumnisse in der IT-Strategie festzustellen. Die Folge sind eine Fülle von Insellösungen mit zahlreichen Schnittstellenproblemen, redundanter Datenhaltung mit Aktualitäts- und nicht selten Konsolidierungsproblemen sowie erhebliche Einschränkungen in der Umsetzung neuer Geschäftserfordernisse. Die entstehenden Kosten zur Sicherstellung des Betriebs und des Change Managements wachsen mittlerweile exponentiell. Gleichzeitig sinkt die Handlungsfähigkeit der IT-Abteilung, und das in einem Umfeld, das immer höhere Anforderungen an Flexibilität und Geschwindigkeit stellt.
| | |
|
|
|
| Orientierungsprobleme |
| | | | Was aber sollen Unternehmen machen, wenn sie ihre Systemlandschaft konsolidieren und vielleicht sogar eine neue IT-Strategie einführen wollen? Welche Themen sind zu berücksichtigen und welche Lösungen am Markt sind geeignet, diese Vorhaben zu unterstützen?
| | |
|
| | | | Fragen, die durch das Angebot und die Vielfalt der Bezeichnungen nicht geklärt werden, sondern häufig genug zu noch mehr Verwirrung führen. Insbesondere der Umstand, dass Anbieter unterschiedlicher Lösungen ihre Produkte zu den gleichen Begriffen wie u.a. EAI anbieten, wird von den Kunden zunehmend als ausgesprochen lästig empfunden. Mittlerweile ist in vielen Unternehmen die Tendenz zu erkennen, „marktübliche“ Bezeichnungen aus dem unternehmensinternen Sprachgebrauch zu verbannen. Zu aufwendig sind inzwischen sogar die internen Versuche geworden, sich mit marktüblichen Begriffen über den eigenen Handlungsbedarf zu verständigen. Statt dessen werden eigene Begriffsdefinitionen vorgenommen, die dann natürlich wieder zu Verständigungsproblemen mit potenziellen Anbietern führen.
| | |
|
| | | | Hinzu kommt, dass bestimmte Themen scheinbar entweder von anderen als Bestandteil mit abgedeckt werden oder aber auf abgegrenzte Einsatzbereiche konzentriert werden. So finden sich im begrifflichen Umfeld von EAI ebenfalls Bezeichnungen wie CRM, SCM, eBusiness, B2B, Workflow, Middleware, Messaging, point-to-point-Verbindungen, CORBA, Publish/Subscribe, Hub and Spoke, Datenintegration, Integration Server, Information Brokering, Adapter, Layer, Schichten- oder Multi-Tiers-Architektur und noch einige andere mehr.
| | |
|
| | | | So verwundert es nicht, dass sich Unternehmen auf einen der angebotenen Hypes wie beispielsweise Middleware stürzen und versuchen, mit oftmals diffusen Anforderungen eine universell einsetzbare und zukunftssichere Lösung mit einem Produktanbieter zu realisieren. Die (fatalen) Ergebnisse solcher Versuche sind in den meisten Fällen vorprogrammiert. Aber auch der Einsatz von externen Beratern bietet nicht automatisch mehr Sicherheit. Zu häufig werden Einzelberater oder Beratungshäuser beauftragt, die entweder bereits im Unternehmen zum Einsatz kamen oder über eine hohe Marktdurchdringung verfügen. Beide Kriterien sind jedoch keine Gewähr dafür, dass auch ausreichende Kenntnisse zu dem Themenbereich vorhanden sind. Gerade produktgebundene Berater kennen oftmals nur einen kleinen Ausschnitt des Anforderungsprofils und des Marktangebots. Andere sind darauf angewiesen, sich im Rahmen des Projekts erstmals mit der Thematik vertraut zu machen. In beiden Fällen sind mitunter gravierende und zahlreiche Fehler in der Vorgehensweise und den aufbereiteten Untersuchungsergebnissen zu beobachten. Diese münden dann in entsprechenden Fehlentscheidungen, die im „günstigsten“ Fall die Auswahl einer überdimensionierten Lösung bewirken. Im Unterschied zu Beratungsanforderungen in Zeiten der Individuallösungen reichen die herkömmlichen Methoden allein heute nicht mehr aus. Nur möglichst breite und technisch versierte Kenntnisse von am Markt erhältlichen Lösungen und ihren Funktionsweisen gewährleisten heute ausreichende Beratungsleistungen. Welches Unternehmen aber kann diesen Hintergrund vorweisen und, genauso wichtig, in Zeiten rasanter Personalfluktuation auch die Personen mit diesem Know How in das Projekt einbringen?
| | |
|
|
|
| Worauf es wirklich ankommt |
| | | | Beobachtet man die Vorgänge in verschiedenen Unternehmen, so lassen sich vereinfacht folgende Bereiche mit Handlungsbedarf lokalisieren:
| | |
|
| | | | | |  | | Festlegung der IT-Strategie
| | |
|
| | | | | | | | Klärung der Anforderungs- bzw. Problembereiche
| | |
|
| | | | | | | | Klärung der technischen Erfordernisse
| | |
|
| | | | | | | | Interner Klärungsprozess von Angeboten und Begrifflichkeiten
| | |
|
| | | | | | | | Evaluierung des Anbietermarktes
| | |
|
| | | | | | | | Bewertungen unter Preis-/Leistungs-Gesichtspunkten
| | |
|
|
| IT-Strategie |
| | | | In der IT-Strategie wird in vielen Unternehmen auf gewohnte Konzepte gesetzt. Hierzu gehören die kurzfristige Umsetzung von fachlichen Anforderungen, erprobte programmiertechnische Methoden, produktorientierte Entscheidungen und Absicherung durch die Entscheidung für sogenannte Marktführer. Zu selten werden für die gesamte IT gültige Modelle für eine einheitliche Systemarchitektur erarbeitet und konsequent umgesetzt. Dort, wo es versucht wird, bleibt der Ansatz oftmals bereits an der Oberfläche stecken, so dass konkrete Realisierungen die ursprünglichen Absichten unterlaufen.
| | |
|
| | | | Im Umfeld von Überlegungen zur Einführung von EAI gehören jedoch grundsätzliche Erörterungen der IT-Infrastruktur, zukunftsweisende Systemarchitekturen mit entsprechenden Integrations- bzw. Ablösungsplänen der vorhandenen Plattformen und Applikationen sowie Richtlinien für zukünftige Anwendungsentwicklungen zwingend in eine allgemeingültige IT-Strategie.
| | |
|
|
| Anforderungs- / Problembereiche |
| | | | Je nach spezifischer Ausgangssituation lassen sich in Unternehmen regelmäßig die Bereiche Geschäftspozesssteuerung, Datenflusssteuerung, Kommunikation und Schnittstellen herauskristallisieren. Häufig werden alle Bereiche als Anforderung in ein Projekt eingebracht.
| | |
|
| | | | So wird z. B. auf Grund allgemeiner Trendthemen wie Kundenorientierung und prozessorientierte Vorgangsbearbeitung die Notwendigkeit eines entsprechenden Systems erst mal wohlwollend vorausgesetzt. Vorgeschaltete Analysen kommen i. d. R. zu einem entsprechenden Ergebnis. Schließlich sollen nach Voruntersuchungen ja auch noch Folgeaufträge generiert werden. Nur selten sind die Ergebnisse, auf denen diese Aussagen beruhen, jedoch fachlich ausreichend fundiert. So werden sogenannte Workflows bis auf Tätigkeitsebene hinunter aufbereitet und nur anhand der Anzahl und Vielfältigkeit von Einzeltätigkeiten bzw. einzugebenden Einzeldaten die Notwendigkeit einer Workflowengine begründet. Was auf dem Papier vielleicht noch imponierend aussieht, verkommt bei der ersten Beispiel-Implementierung dann sehr schnell zu einer Luftblase. Den Hersteller freut`s und der Kunde gesteht sich seine Blamage nicht ein.
| | |
|
| | | | Auch der Begriff Middleware gehört erst mal zu einer modernen IT-Infrastruktur. Leider wissen selbst in der Einführungsphase kaum Unternehmen, was solch eine Middleware eigentlich ausmacht und welche Vorteile man tatsächlich damit realisiert. Die meisten Berater weisen denn auch erst einmal darauf hin, dass eine Middleware ja das Schnittstellenproblem generell erheblich reduziert. Allein durch diesen Umstand (unabhängig der im Einsatz befindlichen Plattformen und Applikationen) soll die Einführung einer Middleware gerechtfertigt werden. Die Frage nach den einzelnen Komponenten und der Bewertung, welche dieser Komponenten denn unter Gesichtspunkten wie Einführungsaufwand, Projektkomplexität und damit Beherrschbarkeit sowie systemtechnischen Ausgangsbedingungen wirklich notwendig sind, wird dagegen nur sehr selten beantwortet.
| | |
|
| | | | Die Schnittstellenproblematik sieht auf grafischen Darstellungen mit den gewachsenen Point-to-Point-Verbindungen zwischen allen vorhandenen Applikationen oftmals dramatisch aus. Hinzu kommen Berechnungsformeln, die allein auf der Anzahl Applikationen beruhen. Nur selten wird dabei der Hinweis gebracht, dass in der Praxis nur sehr selten jede Applikation mit allen anderen verbunden ist und auch nicht sein muss. Entsprechend lohnt sich in vielen Unternehmen ein genauer Blick auf die Schnittstellenlandschaft.
Technische Erfordernisse
| | |
|
| | | | Grundlage einer Bewertung technischer Erfordernisse bilden die klassischen Größen Performanceanforderungen, Transaktionsvolumen, Komplexität der Datenflüsse und Geschäftsprozesse sowie Betriebs- und Backup-Zeiten. Die Gründe für einzelne Problemstellungen können dabei sehr unterschiedlich sein und Maßnahmen sind individuell zu entscheiden. Dabei bilden technische Reaktionen allein ohne begleitende organisatorische Maßnahmen nicht immer einen nachhaltigen Lösungsansatz. Organisatorische Maßnahmen sind nicht auf Änderungen von Prozessen beschränkt, sondern können z. B. auch das Datenmanagement von Dateien (Downloads aus dem Internet) betreffen. Weiterhin spielen insbesondere in Auswahlverfahren für Systemkomponenten sowie kompletter Systeme architektonische Strategien eine wesentliche Rolle.
| | |
|
|
| Interner Klärungsprozess |
| | | | EAI und Workflow werden in vielen Unternehmen als ein zu behandelndes Thema betrachtet. Dabei wird nur selten die Komplexität jedes einzelnen Themas in ausreichender Form erkannt und gewürdigt. Oftmals wird das Thema allerdings auch als zu undurchschaubar bewertet, was ebenfalls dazu führt, dass man sich auf die Aussagen von externen Beratern oder direkt auf einen Anbieter verlässt. Für viele Unternehmen beginnen die Schwierigkeiten bereits bei der Trennung von Geschäftsprozess- und Datenflussregeln. Richtig problematisch wird das Thema EAI spätestens dann, wenn Unternehmen versuchen, die Strukturen und Zusammenhänge der benötigten Komponenten herauszuarbeiten. Hier geht es dann sehr schnell in Fragen der Basistechnologie, wie und wo das Mapping von Formaten erfolgt, ob ein neutrales Format unterstützt wird, ob bei Verwendung von XML auch Blobs versendet werden können, wie die Verbindung zwischen Adaptern, Messagingsystem und Integration Server aussieht, wie die Adressierung erfolgt, durch Auslesen eines Headers oder der Interpretation von Datenstrukturen und Entscheidungen auf Basis vorgegebener Regeln u.v.m.
| | |
|
| | | | In der Praxis neigen die Unternehmen daher zu einer Schwerpunktbetrachtung entweder von EAI oder von Workflow. Ob die gewünschten Ziele durch diese Vorgehensweise erreicht werden, kann in vielen Fällen als fraglich betrachtet werden.
| | |
|
| | | | Notwendige Klärungen von Eigenschaften, Leistungsfähigkeit und Zusammenspiel einzelner Komponenten erfolgen viel zu häufig entweder gar nicht oder nur rudimentär. Damit wird eine wichtige Voraussetzungen für die interne und auch externe Kommunikation nicht erfüllt. Die eigene Definition und Abgrenzung von Begrifflichkeiten und mit ihnen verbundener Produktansätze ist in diesem Umfeld aber sowohl für die spätere erfolgreiche Projektabgrenzung und –durchführung als auch für das Auswahlverfahren und Vertragsverhandlungen ein wesentlicher Erfolgsfaktor.
| | |
|
| | | | Die Anbieter sowohl von EAI-Lösungen als auch von Workflowlösungen tragen von sich aus i. d. R. wenig zum Klärungsprozeß des Kunden bei. Nur bei guter Vorbereitung einer ausreichenden Wissensbasis seitens des Kunden können Herstellerveranstaltungen zur Beantwortung von Detailfragen und Abgrenzungsfragen der Leistungsfähigkeit und Einsatzschwerpunkt von Komponenten eine hilfreiche Informationsquelle darstellen. Zu sehr sind die Anbieter in ihrem Lösungsverständnis auf den eigenen Produktansatz beschränkt. Das hat zum einen sicherlich verkaufstechnische Hintergründe, zum anderen ist aber auch zu beobachten, dass die Mitarbeiter eines Anbieters häufig nur den eigenen Produktansatz kennen. So ist zu beobachten, dass einige Anbieter von EAI-Lösungen zwar von Workflow reden, das Produkt jedoch nur auf die Regelung von Datenflüssen ausgelegt ist. Zum Teil sind die Einschränkungen an zusätzlich verwendeten Begriffen wie Mini-Workflow, Collaborations oder Complex Requests zu erkennen. Auf der anderen Seite halten sich Workflowanbieter zum Thema EAI bedeckt und weisen darauf hin, dass sie über umfangreiche Erfahrungen in der Anbindung von Fremdapplikationen verfügen. Allerdings handelt es sich dabei in der überwiegenden Anzahl der Fälle um projektindivuelle Realisierungen. Kaum ein Anbieter oder Integrator, der sich wirklich in der technischen Tiefe mit der Leistungsfähigkeit und Verwendbarkeit von EAI-Komponenten auseinandergesetzt hat.
| | |
|
|
| Evaluierung des Anbietermarktes |
| | | | Unternehmen, die sich sowohl mit Workflow als auch mit EAI auseinandersetzen, müssen sich darüber bewusst sein, dass es für beide Bereiche einen eigenen Anbietermarkt gibt. Nur in sehr wenigen Fällen gibt es „echte“ Komplettanbieter. Sowohl die unternehmensindividuellen Anforderungen als auch die jeweiligen Leistungsmerkmale der Lösungen sind von ausreichender Komplexität, um getrennte Auswahlverfahren durchzuführen. In jedem der beiden Bereiche gibt es des weiteren zum Teil erhebliche Unterschiede im Aufbau und der Funktionsweise einzelner Lösungen. Gerade EAI-Lösungen, die der Systemintegration dienen und systemarchitektonische Vorstellungen wie ein Dienstekonzept unterstützen (können), sind überwiegend selbst als homogene Lösung konzipiert und lizensiert. Anforderungen an Workflowsysteme unterscheiden sich grundlegend von denen an EAI-Lösungen. Diese Anforderungen sind in ausreichendem Maß herauszuarbeiten und für Produktbewertungen heranzuziehen. Viele Kriterienkataloge, die zwar Unmengen von Daten abfragen aber ohne ein Gesamtverständnis zusammengeschrieben wurden, bringen keine wirkliche Entscheidungshilfe sondern verursachen nur unnötigen Aufwand.
| | |
|
|
| Bewertung unter Preis-/Leistungsgesichtspunkten |
| | | | EAI-Lösungen wie auch Workflowsysteme bieten unbestreitbar eine Reihe an Nutzeneffekten. Damit diese zum tragen kommen, müssen allerdings sowohl die Rahmenbedingungen als auch die Vorstellungen ihres Einsatzes im Unternehmen stimmen. So nutzt es beispielsweise wenig, wenn ein Workflowsystem ausschließlich als Entwicklungsumgebung für neue Applikationen genutzt werden soll, doch eingekauft wird statt eines Toolsets ein Produkt mit möglichst vielen Standardfunktionen, das nur unzureichende Anpassungsmöglichkeiten bietet. Oder halt umgekehrt. Bei der Auswahl von EAI-Komponenten wiederum ist zu prüfen, ob ein Integration Server in einer Systemumgebung sinnvoll ist, die überwiegend aus Eigenentwicklungen mit einem hohen Anteil wiederverwendeter Objekte oder Formaten besteht. Selbst die Adapter können je nach Anbieter ein Volumen erreichen, mit dem Unternehmen in anderen Bereich komplette Projekte abwickeln.
| | |
|
|
|
| Wie Unternehmen dem Dilemma entgehen können |
| | | | EAI und Workflow sind umfangreiche und schwierige Themen. Sie bieten vielfältige Möglichkeiten für Fehler sowohl in der Vorbereitung als auch in der Umsetzung. In der Vergangenheit haben einige Unternehmen versucht, große EAI- und Workflowprojekte durchzuführen. Diese gehörten aus den oben beschriebenen Gründen nicht immer zu den erfolgreichsten Vorhaben. Aus diesem Grund sollten die Notwendigkeiten und alternativen Maßnahmen in ausreichendem Maß geklärt werden. So ist bei Datenredundanz beispielsweise zu prüfen, ob die unterschiedlichen Datenbanken und Files nicht in einer zentralen Datenbank zusammengeführt werden können, vor allem wenn es sich um eigenentwickelte Applikationen handelt. Solange die Potentiale zur Reduzierung von Komplexität nicht ausgeschöpft werden, wird ein Teil dieser Komplexität immer auch in die EAI-Lösung fortgeschrieben und bestimmte Probleme gegebenenfalls nur verlagert.
| | |
|
| | | | Mittlerweile gibt es zumindest im Bereich Workflow Beispiele, die Projekte noch kurz vor der Implementierung gestoppt haben, um zur Grundlagenklärung zurückzukehren. So hatte u. a. ein großer Energieversorger das Projekt so lange auf Eis gelegt, bis mit Hilfe eines Doktoranten eine interne Einigung auf Begrifflichkeiten und Definitionen erfolgt war. Ein anderes Beispiel ist eine Versicherung im deutschsprachigen Ausland, die glücklicherweise noch im Vorbereitungsprozess die Reißleine gezogen und die Themen EAI und Workflow getrennt und in separate Projekte geleitet hat.
| | |
|
| | | | Damit stehen potenzielle Anwender in der Pflicht, sich intensiv mit der jeweiligen Thematik auseinander zu setzen. Das beinhaltet sowohl die Beschäftigung mit Bezeichnungen, da sich hinter diesen Produkte unterschiedlicher Couleur verbergen, die Auseinandersetzung mit Systemarchitekturen und Funktionsweisen sowie die Bildung einer Vorstellung, wie zum einen die Anwender mit dem System arbeiten sollen und wie zum anderen das Gesamtsystem interagieren soll. Hierzu sind in einem gewissen Umfang jedoch bereits Kenntnisse von den Funktionsweisen der Systeme notwendig. Trotzdem, werden diese Aufgaben vernachlässigt, ist weder eine adäquate Vorbereitung für eine solide Systemauswahl noch für ein „Proof of Concept“ noch für eine schnelle Realisierung möglich. Des weiteren kann ein Anbieter so gut wie jede Lösung implementieren, ohne dass der Kunde eine Chance auf Reklamation hat.
| | |
|
| | | | Da viele Unternehmen überfordert sind, diese Aufgaben aus Eigenleistung heraus zu erbringen, ist i. d. R. der Einsatz externer Unterstützung unumgänglich. Hier stehen die Unternehmen jedoch ein weiteres Mal vor der Schwierigkeit, wirklich qualifiziertes Beratungs-Know How zu finden und auszuwählen. Da in der gesamten Beratungsbranche das Personalkarussel heftig am rotieren ist, reicht mittlerweile auch der Nachweis des Beratungshauses nicht mehr aus, dass entsprechende Projekte durchgeführt wurden. Nicht selten sind die an diesem Projekt beteiligten Personen bereits zu einem anderen Unternehmen gewechselt. Daher ist auf entsprechende Erfahrungen im Mitarbeiterprofil zu achten. Zudem sollten Ansprechpartner in Referenzunternehmen eingefordert werden, um die Angaben zu dem oder den Mitarbeitern verifizieren zu lassen. Darüber hinaus sind viele Beratungshäuser an einen oder zwei Produkthersteller gebunden, so dass trotz vorhandener Erfahrungen sowohl die Eigeninteressen des Beratungshauses als auch die eingeschränkten Produktkenntnisse den Anforderungen und Wünschen des Anwenders zu wider laufen können. Um ein möglichst umfassendes und breit fundiertes Wissen einzukaufen, sollten daher möglichst unabhängige Berater gesucht werden. Nur diese sind frei genug, um den Markt und die einzelnen Produkte nach möglichst objektiven Gesichtspunkten zu bewerten. Diese sind unter Umständen auch in der Lage, die Angebote der Anbieter hinsichtlich des Leistungsumfangs zu beurteilen und bei der Aushandlung der Vertragsbedingungen zu unterstützen.
| | |
|
| | | | Wurden die Vorleistungen erbracht sollte spätestens parallel zum Auswahlverfahren eine Einführungsstrategie mit den auf einer Zeitschiene einzubeziehenden Unternehmensbereichen und Einsatzgebieten der Lösung festgeschrieben werden. Diese ist im folgenden Grundlage zur Bestimmung des oder der (Teil-) Projekte, deren Umfang so dimensioniert sein sollte, dass er einerseits den Realisierungsprioritäten entspricht und andererseits steuerbar bleibt. Gerade bei paralleler Einführung mehrerer Systeme oder Systemkomponenten, gegebenenfalls von unterschiedlichen Anbietern und unter Beteiligung von Integratoren neigen die Koordinierungsaufwände dazu, überproportional zu wachsen und an die Grenze ihrer Beherrschbarkeit zu gelangen.
| | |
|
|
| Rechtshinweis |
| | | | © CopyRight PROJECT CONSULT 2001
Autorenrechte Martin Fichter
| | Home/Rechtshinweis
Presse/Autorenrechte
| | | Zum Download sind auschließlich die Beiträge in der Rubrik Download vorgesehen. Als PDF bereitgestellte Beiträge enthalten auch die zugehörigen Grafiken.
| | Wissen/Download
| |
|
|
