Smart Industry

Im richtigen Fahrwasser

Andreas Schumann, Heidelberg

Foto: iStockphoto
Manchmal erweist sich weniger als mehr – eine Erkenntnis, die nicht nur für Standardsoftware gilt: Ein riesiges Hochseeschiff wie die Queen Mary 2 kann nicht sinnvoll auf den engen Kanälen der Binnenschifffahrt eingesetzt werden – hier ist ein kleineres, wendigeres Gefährt gefragt. Umso erstaunlicher, dass die Softwarebranche trotzdem weiterhin versucht, ihren Luxusliner »Standardsoftware« – wenn auch unter wechselnder Flagge – auf allen Fahrwassern einzusetzen. Auch auf solchen, für die dieser Riese einfach zu groß geraten ist. Eine neue Methode bietet sich als Alternative an.

Insbesondere für den Mittelstand ist eine komplexe Standard-Lösung nur wenig geeignet. Zwar gibt es hier anspruchsvolle Prozesse abzubilden, doch verfügt diese Klientel keineswegs über unendliche Ressourcen. Der Luxusliner Standardsoftware ist aber in Anschaffung und Unterhalt besonders teuer. Darüber hinaus lässt sich mit ihm nicht jedes Ziel erreichen; oft erweist er sich als zu komplex und unflexibel. Der Versuch der Anbieter von Branchen- und Länder-übergreifender Standardsoftware, das ausufernde Angebot an Funktionalität zu verbergen, reduziert nur scheinbar die Komplexität. Auch wenn der Kunde nur die Funktionen nutzt, die er wirklich braucht – ein Ozeanriese ist und bleibt ein Ozeanriese. Was also treibt Softwarehersteller dazu, dem Kunden das zu geben, was er nicht benötigt?

Anzeige

Softwarefirmen haben das Bedürfnis, möglichst alle Anforderungen der verschiedenen Branchen und Länder in einem einzigen Paket abzubilden. So bleiben die Herstellkosten möglichst niedrig. Der Empfänger des komplexen Gebildes ist dagegen deutlich schlechter bedient. Für ihn erweist sich das Mehr an Funktionalität als Ballast, der die Einführung der Software erschwert und die Kosten in die Höhe treibt: Ein Dienstleister benötigt keine Software, die auch Produktions-Prozesse abbildet – im Gegenteil, ein solches System behindert ihn nur. Weder die verschiedenen Programmiersprachen dieser Welt, noch die diversen Methoden der Softwareentwicklung haben bislang einen Ausweg aus diesem Dilemma eröffnet. Im Gegenteil, die Komplexität der Softwarelösungen nimmt immer weiter zu. Heutige Anwendungssoftware ist heute weder qualitativ besser, noch flexibler anpassbar, und sie lässt sich auch nicht schneller und kostengünstiger einführen. Mit XML, MDA, SOA, ESOA werden in immer kürzeren Zyklen Heilslehren angekündigt, die von der Sehnsucht der gesamten Branche nach einem geeigneten Lösungsweg zeugen. Dabei mangelt es nicht an Kuriositäten. So weiß heute zwar noch keiner der SOA-Jünger, wie das angestrebte Ziel erreicht werden soll. Dies hindert sie aber nicht daran, trotzdem jeden aufzufordern, auf ihren Zug mit aufzuspringen – frei nach dem Motto: »Fangt schon mal mit dem Hausbau an, das Fundament wird dann schon noch geliefert.«
Die tangro-Architektur geht daher einen völlig neuen Weg. Im Vordergrund steht hierbei der betriebswirtschaftliche Prozess. Statt in UML, Methoden und Klassen formuliert der Kunde seine Anforderungen so weit wie möglich in der Terminologie der Betriebswirtschaft. Dabei orientiert sich die tangro-Methode ausschließlich an den Bildern und der Sprache der Unternehmen, nicht an denen der IT. Wenn es darum geht, einen betriebswirtschaftlichen Prozess zu beschreiben, wird dieser grafisch in Form von EPK (Ereignis-Prozess-Ketten) dargestellt – eine Methode, die schon längere Zeit zu diesem Zweck von IDS Scheer und anderen erfolgreich eingesetzt wird. Allerdings geht bei tangro mit der Prozessbeschreibung gleichzeitig auch die Implementierung der Software einher.

Das Besondere: Im Augenblick der grafischen Modellierung von betriebswirtschaftlichen Prozessen entsteht oder verändert sich die Anwendung. Einzelne Prozessbausteine werden dabei so miteinander kombiniert, dass eine ablauffähige Software entsteht, die betriebswirtschaftliche Vorgänge korrekt abbildet. Jeder Prozessbaustein steht für einen speziellen Teilprozess und enthält wiederum granulare Softwarebausteine, die sich in hohem Maße wieder verwenden lassen. Eine Umsetzung des Prozessmodells in Programmcode nach Abschluss der Prozessmodellierung entfällt. Entscheidend ist somit nicht nur die Einhaltung der betriebswirtschaftlichen Terminologie, sondern vor allem der nahtlose Übergang von einer Ebene in die andere. Die fehleranfällige und unnötige Übertragung eines betriebswirtschaftlichen Prozessmodells in ein IT-spezifisches Modell wird so vermieden.

Keine Schnittstellen-Programmierung

Die einzelnen Bausteine »verstehen« sich bei tangro ohne Zusatzarbeit. Im Gegensatz zu den bisherigen Entwicklungsmethoden, bei denen eine »Verständigung« der Softwarebausteine nur über Schnittstellen möglich ist, genügt hier allein die grafische Anordnung der Symbole und deren Verknüpfung, um den Ablauf eines Prozesses zu definieren.

Ohne das Manko einer zusätzlichen Schnittstellendefinition lassen sich also die Vorteile, die sich durch die Wiederverwendung von Softwarebausteinen ergeben, vollständig nutzen. Die Bedingungen und Variablen, nach denen die einzelnen Bearbeitungsschritte ablaufen sollen, werden im Prozessmodell definiert. Ergänzend formuliert der Anwender diejenigen Bedingungen, die sich durch ihre spezielle Kombinatorik im Prozessmodell nicht sinnvoll abbilden lassen, in der tangro Rule Based Engine (RBE). Mit technischen Details wird er auch dann nicht konfrontiert, denn die RBE übernimmt sämtliche Vorgaben automatisch in die Software.

Der Anwender in der Fachabteilung benötigt also keine Programmierkenntnisse. Die Vorteile einer solchen Architekturansatzes sind immens. Sie verbindet die Vorteile einer Individuallösung mit denen einer Standardsoftware. So sind entsprechende Anwendungen dank der grafischen Darstellung transparent und für jedermann verständlich. Vor allem aber lassen sich durch die einfache Kombinierbarkeit der Prozessbausteine ohne zusätzliche Programmierung maßgeschneiderte Lösungen schnell und kostengünstig erstellen.

Diese stehen Individuallösungen in nichts nach, genügen aber wesentlich höheren Qualitätsansprüchen. Zudem wird die Pflege und Erweiterbarkeit der Anwendungen erheblich vereinfacht. So lassen sich Anpassungen schnell und mit wenig Aufwand realisieren, indem der Nutzer auf vorhandene Bausteine und Prozesse zurückgreift und Überflüssiges entfernt.

Auf diese Weise bekommt der Kunde letztendlich genau das, was er benötigt: Eine Software ohne weiteren Ballast, die exakt den eigenen Anforderungen entspricht: eben Luxusliner, Binnenschiff oder Motor-yacht – ganz nach Wunsch. -sg-

tangro software components gmbh, Heidelberg Tel. 06221/13336-0, http://www.tangro.de

Anzeige

Das könnte Sie auch interessieren

Anzeige
Anzeige

Automationslösungen von item

Erweitern Sie Ihr Wissen innerhalb der Automation und erfahren Sie alles rund um Motoren, Getriebe und Steuerungen im Leitfaden von item Industrietechnik.

mehr...
Anzeige
Anzeige

Highlight der Woche

Interessenten können ab sofort auf der Homepage der ACE Stoßdämpfer GmbH die für Ihre Anwendung maßgeschneiderte Gasfeder berechnen und auslegen. Unter ‚Berechnungen' ist das Gasfeder-Berechnungstool auf der Website ace-ace.de zu finden.

Zum Highlight der Woche...
Anzeige
Anzeige

Highlight der Woche

MES macht Schluss mit Stillstand
Die MES-Software von PROXIA unterstützt die Kieselmann GmbH bei der Herstellung von umfangreichen Leitungs- und Ventilsystemen, den Überblick über eine äußerst komplexe Produktion zu behalten. Das MES ermöglicht, die Fertigung wirtschaftlich zu planen und zu organisieren sowie mit sicheren Kennzahlen Effizienzpotentiale aufzudecken und zu nutzen.
Bericht lesen

Zum Highlight der Woche...

Newsletter bestellen

Immer auf dem Laufenden mit dem SCOPE Newsletter

Aktuelle Unternehmensnachrichten, Produktnews und Innovationen kostenfrei in Ihrer Mailbox.

AGB und Datenschutz gelesen und bestätigt.
Zur Startseite