Suchen und Finden

Titel

Autor/Verlag

Inhaltsverzeichnis

Nur eBooks für mein Endgerät anzeigen:

 

Newsletter

Enterprise Architecture, BPM und SOA für Business-Analysten - Leitfaden für die Praxis

von: Dirk Stähler, Ingo Meier, Rolf Scheuch, Christian Schmülling, Daniel Somssich

Carl Hanser Fachbuchverlag, 2009

ISBN: 9783446421431, 280 Seiten

Format: PDF, OL

Mac OSX,Windows PC,Mac OSX,Windows PC Bookeen Cybook Orizon,Ectaco Lite,Aluratek Libre,eLyricon EBX-500.TFT,PocketBook 302,FlatReader,BeBook 'One',iRiver Story,Sony Reader PRS-3xx,Bookeen CyBook Opus,Hanvon/Hexaglot N518,PocketBook 301+,COOL-ER eReader,Inves-Book 600,eLyricon EBX-600.E-Ink, Bookeen CyBook Gen3 ab Rev: 1.9,Italica Reader,Sony Reader PRS-505, -6xx, -7xx,Pocketbook 360,Hanvon N516 Weltbild Apple iPad, Android Tablet PC's Online-Lesen für: Linux,Mac OSX,Windows PC

Preis: 39,90 EUR

  • Modellgetriebene Softwareentwicklung - MDA und MDSD in der Praxis
    Java EE 5 Architekturen. Java Patterns und Idiome
    UML 2 - Zertifizierung: Test-Vorbereitung zum OMG Certified UML Professional (Fundamental)
    Spring und Hibernate - Eine praxisbezogene Einführung
    Fortgeschrittene Programmierung mit Java 5 - Generics, Annotations, Concurrency und Reflection – mit allen wesentlichen Neuerungen des J2SE 5.0
    JAXB 2.0 - Ein Programmiertutorial für die Java Architecture for XML Binding
    UML@Work - Objektorientierte Modellierung mit UML2
    Hibernate und das Java Persistence API
  • Business Engineering
    Java EE 5
    Java Server Faces - Ein Arbeitsbuch für die Praxis
    SOA goes real - Service-orientierte Architekturen erfolgreich planen und einführen
    Java 5-Programmierhandbuch - Einstieg und professioneller Einsatz
    Enterprise JavaBeans - Die 3. Generation
    Selbstmotivation - FLOW - statt Streß oder Langeweile

     

     

 

Mehr zum Inhalt

Enterprise Architecture, BPM und SOA für Business-Analysten - Leitfaden für die Praxis


 

6 Modellgestützte fachliche Konzeption individueller IT-Systeme (S. 117-118)

6.1 Fragen, die dieses Kapitel beantwortet

- Warum sollte die IT in der Regel den Geschäftsprozessen folgen und nicht umgekehrt?
- Welche Vorteile bringt eine strukturierte Anforderungserhebung auf Basis eines durchgängigen Fachprozesses?
- Wie nehme ich am besten Fachprozesse im Rahmen einer Fachkonzepterstellung auf?
- Wie stelle ich Fachprozesse, Systemverhalten und statische Systemkomponenten im Modell dar?
- Welche Teile eines Fachkonzepts sollte ich im Modell darstellen und welche nicht?
- Wie funktioniert eine modellgestützte Fachkonzeption mit der Oracle BPA Suite?

6.2 Die Bedeutung fachlicher Anforderungen

Es existieren zahlreiche Studien zu den Gründen des Scheiterns von IT-Projekten. Dabei kann mit dem Begriff „Scheitern“ sowohl gemeint sein, dass ein IT-Projekt abgebrochen wird, als auch, dass der Projektzeitplan nicht eingehalten oder das finanzielle Budget überzogen worden ist. Auch die Realisierung eines Systems, das sich anschließend in der Praxis als untauglich herausstellt, muss als gescheitertes IT-Projekt angesehen werden. Die große Anzahl solcher Studien lässt bereits vermuten, dass das Scheitern von IT-Projekten ein häufiges Problem in Unternehmen darstellt. Dies wiederum ist für den Business-Analysten eine große Chance, Unternehmen einen Mehrwert anzubieten, indem ein Vorgehen entwickelt wird, das dem Scheitern von IT-Projekten entgegenwirkt.

Ein solches Vorgehen zur fachlichen Konzeption individueller IT-Systeme wird in diesem Kapitel vorgestellt. Nicht nur die Anzahl der Studien, auch ihr Inhalt bietet eine interessante Erkenntnis: Als wichtigster Grund für das Scheitern von IT-Projekten wird fast durchgehend die unklare Definition bzw. das unzureichende Verständnis der fachlichen Anforderungen identifiziert. Dies wiederum resultiert aus der in Kapitel 2 beschriebenen Problematik der unterschiedlichen Sichten, die die verschiedenen an einem IT-Projekt beteiligten Personenkreise haben. Das in diesem Kapitel vorgestellte Vorgehen sieht diese fachlichen Anforderungen als Basis für die Konzeption eines IT-Systems und hilft bei deren Identifikation, Beschreibung und Kommunikation zwischen allen an einem IT-Projekt Beteiligten.

Unternehmen haben über die letzten Jahre hinweg gelernt, dass ihre Geschäftsprozesse und deren Qualität entscheidenden Einfluss auf den Unternehmenserfolg haben. Die eigentlich logische Konsequenz aus dieser Erkenntnis, auch die IT nach den Geschäftsprozessen auszurichten, ist dagegen noch nicht sehr verbreitet. Besonders in der Vergangenheit wurde häufig der Fehler gemacht, Systeme einzuführen, die bestimmte Arbeitsabläufe (Fachprozesse) vorgeben. An dieser Stelle sei zunächst gesagt, dass ein solches Vorgehen nicht immer falsch sein muss. Je standardisierter die Prozesse sind, um die es geht, desto sinnvoller kann die Einführung einer Standardsoftware sein. Für Standardprozesse wie Rechnungsprüfung oder Finanzbuchhaltung wird es in den wenigsten Fällen sinnvoll sein, eine vollständige Individuallösung zu entwickeln. In solchen Fällen ist der Aufwand, der bei der Einführung einer Standardsoftware anfällt, sicherlich geringer als der Entwicklungsaufwand einer neuen Lösung.

Dennoch ist es wichtig zu wissen, dass eine Softwareeinführung, durch die neue Fachprozesse vorgegeben werden, bestimmte Konsequenzen für alle am Projekt Beteiligten und darüber hinaus mit sich bringt: Ein solches Vorgehen hat zur Folge, dass die Mitarbeiter in der Fachabteilung ihre ggf. seit Jahren praktizierten und bis ins kleinste Detail beherrschten Abläufe aufgrund einer neuen Standardsoftware grundlegend ändern müssen. Dies erhöht nicht gerade die Akzeptanz der neuen Lösung. Tatsächlich unterschätzen Unternehmen den enormen Aufwand einer solchen organisatorischen Veränderung. Organisatorische Veränderungen stellen in sich eigene Change-Management- Projekte dar, deren Umsetzung über die technischen Aspekte einer Systemeinführung weit hinausgeht.