Unternehmenssoftware

Unternehmenssoftware umfasst alle betriebswirtschaftliche Software, die ein Unternehmen zur Bewältigung seines Geschäftsbetriebes einsetzt. Sie bildet die reale Welt des Unternehmens als Datenmodell ab. Den Mitarbeitern des Unternehmens dient sie zur Information, Verwaltung, Organisation, Planung.

Bestandteile

Unternehmenssoftware gliedert sich grob in die Material- und die Werteseite. Auf der Materialseite werden die tatsächlichen Wirtschaftsgüter und Produktionsfaktoren abgebildet.

Die Werteseite umfasst Finanzbuchhaltung, Lohnbuchhaltung, Kalkulation, Bilanzierung.

Kernbestandteil der Materialseite ist die Warenwirtschaft. Dazu gehören Lagerwirtschaft, Einkauf, Disposition, Auftragsabwicklung mit Angebotsschreibung, Gutschriften, Rechnungsstellung. Wird auch produziert, kommt Produktionsplanung (PPS bzw. ERP) hinzu. Für die Produktionsplanung sind Stücklisten, Arbeitspläne und Fertigungskapazitäten (Personal und Maschinen) erforderlich.

Darumherum gruppieren sich Informationssysteme (EIS, MIS, Datawarehouse, Statistiken, Datamining), Simulationssysteme, Planungssysteme (Grobplanung, Jahresplan, Planvorgaben, rollierende Planung, Tourenplanung), Internet-Shop, Customer Relationship Management (CRM), Dokumentenmanagement (DMS), Personalverwaltung, Contentmanagement (CMS), Projektsteuerung, Groupware, Kommunikationssysteme, Human Resources Management (HRM), Qualitätsmanagementsysteme.

Systemübergreifende Funktionalitäten wie Variantentechnik, Versionierung, Druckgenerator, Batch-Verarbeitung, Administration und Schnittstellen ziehen sich durch alle Bereiche.

Nicht zur Unternehmenssoftware zählen Spezialwerkzeuge wie z.B. CAD.

Historische Entwicklung

Fibu

Begonnen hat alles mit der Finanzbuchhaltung. Das Modell der Konten und Buchungen ließ sich mit den damaligen beschränkten Hardwaremöglichkeiten am besten abbilden. Die Banken hatten es schon länger vorgemacht. Ein Band mit den Buchungsdaten wurde gegen das Band mit den Bestandskonten gelesen und verbucht. Statt Bändern gingen auch Lochkarten, das hiess dann Buchungsstapel. Heraus kamen zwei Listen: das Buchungsjournal und die neuen Bestände. Die damit erreichte Rationalisierung überstieg wohl die Kosten des Rechenzentrums. Vielleicht war aber auch damals schon mehr die Technikverliebtheit die eigentliche Motivation.

MRP

Was mit Geldkonten geht, geht auch mit Lagerbeständen. Damit war die Lagerverwaltung geboren. Der nächste Schritt war die Stücklistenauflösung. In der Stückliste wird hinterlegt, aus welchen Bestandteilen in welchen Mengen ein Produkt gefertigt wird. Soll es dann gefertigt werden, löst ein Sücklistenprozessor die Stückliste in die sog. Sekundärbedarfe auf. Diese können wiederum Stücklisten haben usw. Dieses Prinzip wurde als MRP (Material Requirements Planning) bekannt und heißt heute noch so.

PPS

Ein Produkt besteht jedoch nicht nur aus seinen Bauteilen, man muss auch einen Plan haben, wie man es zusammenbaut. Das ist der Arbeitsplan mit seinen Arbeitsfolgen. So eine Arbeitsfolge sagt einem, was zu tun ist, welche Maschinen und welche Personen mit welchen Qualifikationen wie lange dazu brauchen. Weiss man dann noch, wieviele Maschinen und Menschen wann wie lange zur Verfügung stehen, könnte man planen. Dies ist die Produktionsplanung (PPS). Kapazitäten werden Bedarfen gegenübergestellt und möglichst zur Deckung gebracht. Kernstück des PPS ist die Terminierung. Es gibt die Vorwärts-, Mittelpunkts-, Engpass- und Rückwärtsterminierung und sicher noch weitere. Bei der Vorwärtsterminierung wird ein Fertigungsauftrag (die Summe aller Arbeitsfolgen) ab einem Zeitpunkt versucht in die freien Kapazitäten der Fertigung zu legen und heraus kommt der Endezeitpunkt. Bei der Rückwärtsterminierung legt man fest, wann der Auftrag fertig sein soll und bekommt heraus, wann man spätestens anfangen muss. Es handelt sich in beiden Fällen um eine Art Simulation. Soweit die Theorie. Zu ihrer Blütezeit wurde der Begriff CIM (Computer integrated Manufacturing) geprägt. Alles schien möglich, Optimierungsverfahren nach Belieben, je nach Strategie.

Grenzen des PPS

In der Praxis gab es jedoch Probleme. Die Planung war sehr anfällig für Änderungen. Ungeplante Ereignisse (Maschinenbruch, Materialengpass, Personalausfall, Änderungswünsche des Kunden, Eilauftrag) erzeugten durch Neuplanung eine komplett andere Situation. Allein die Vielzahl der Verfahren, mit denen versucht wurde, diesem Problem (Netchange) zu begegnen, zeigt die Hilflosigkeit der Wissenschaft. Durch Einführung von Puffern und eine Frozen Zone versuchte eine gewisse Stabilität hineinzubringen, verschenkte damit aber Kapazität und Flexibilität. Ein anderes Problem war die exakte Abbildung der Fertigungsresourcen und Bedarfe und die richtige Konfiguration der Planungsverfahren (insbes. Prioritäten der verschiedenen Decker- und Bedarfsarten). Die ganze Komplexität und der Detailreichtum, was bis dato nur die Mitarbeiter in der Fertigung wussten, musste herausgearbeitet und abstrahiert werden, nur damit die Planung im günstigsten Fall ein Ergebnis lieferte, das der Werkstattmeister ohnehin schon vorher wusste. Der reine Selbstzweck also. Das wertvolle Improvisationsvermögen wurde ganz außer Acht gelassen. In den meisten Fällen wurde die Planung somit nicht ihrem Anspruch gerecht, eine hohe Kapazitätsauslastung und niedrige Lagerbestände zu erreichen. Außerdem gab es durch die stupide Planerfüllung Qualitätsprobleme. Mit Grobplanung und lokalen Leitständen wurde das zentralistische System wieder abgeschwächt. Das Ziehprinzip (Kanban) und Total Quality Management (TQM) waren die nächsten Ansätze.

Verschiebung des Fokus

Mit der Zeit verlor das Lieblingsargument für PPS, nämlich Reduzierung der Lagerhaltung (weniger Kapitalbindung) und optimale Auslastung der Fertigung an Zugkraft. Qualität, Liefertreue, Flexibilität und Realisierung individueller Kundenwünsche gewannen an Bedeutung. Die Zeiten der absoluten Arbeitsteilung neigten sich dem Ende zu, Gruppenarbeit und Eigenverantwortung schien den neuen Produktionsprozessen angemessener. Der Wertschöpfungsprozess verlagerte sich in die Bereiche um die eigentliche Produktion herum.

Vom PPS zum ERP

Die Software machte diese Entwicklung mit. So siedelten sich um das PPS herum vor- und nachgelagerte Funktionskomplexe an als logische Erweiterungen. Im Vorfeld kam der Einkauf mit Lieferantenstamm dazu. Der Einkauf muss das beschaffen, was am Ende der Stücklistenauflösung übrig bleibt, nämlich Kaufteile und Rohmaterial. Das soll natürlich möglichst günstig geschehen, weshalb man Einkaufskonditionen, Einkaufshistorie führt, Mengen zusammenfasst, das richtige Bestellverfahren wählt, Lieferantenbeziehungen pflegt. Zu entscheiden, was man wann kauft oder selbst fertigt, ist Aufgabe der Disposition. Nachgelagerte Funktionen betreffen den Vertrieb und die Kundenbeziehungen. In diesem Komplexitätsgrad bürgerte sich der Begriff ERP (Enterprise Resource Planning) ein. Damit soll zum Ausdruck gebracht werden, dass die Software die Kombination der Produktionsfaktoren Arbeit, Kapital, Material plant.

Vom ERP zur Unternehmenssoftware

Spezialanbieter erfanden dann immer weitere 3-Buchstaben Kürzel für ihre Produkte, die weitere Teilbereiche der Unternehmenssoftware abdeckten: MIS, CRM, EIS, CMS, DMS u.v.m. Jedes hatte seinen Hype und fand umgehend Einzug in die Pflichtenhefte und infolgedessen in die Produkte der Standardsoftware Anbieter. Da es lästig ist, eine Latte dieser Kürzel aufzuzählen, sagt man heute einfach "Unternehmenssoftware".

Best of Breed

Bis vor kurzem galt die "best of breed" Strategie als der Königsweg, sich seine Unternehmenssoftware zusammenzustückeln. Sie besagt, für jeden Teilbereich den jeweils besten Anbieter zu wählen und die Produkte mit Schnittstellen zu verbinden. Mittlerweile kommt man wieder davon ab, weil das Operating eines solchen Flickenteppichs zu komplex und teuer ist, zuviele Beziehungen zu den Anbietern unterhalten werden müssen, zuviel Spezial-Know How benötigt wird.

Outsourcing

Zur Zeit ist das Outsourcing ein Trend. Man beauftragt ein Unternehmen wie z.B. IBM oder T-Systems, sich um den ganzen Kram zu kümmern, sprich Hardware betreiben, Operating durchzuführen, Software auswählen, beschaffen, einführen, warten, anpassen. Die Hoffnung ist, dass das beauftragte Unternehmen die ganze Sache besser im Griff hat. Oft geht die IT-Abteilung zum Outsourcing Dienstleister, d.h. die gleichen Menschen machen die gleiche Arbeit wie früher.

Migration und Evolution

Unternehmen, die schon länger mit dabei sind, haben aus alten Zeiten oft noch Software, welche die Kernbereiche abdeckt, aber längst veraltet ist. In den 90er Jahren wurden gerne komplette Neueinführungen gemacht, lange, große und teure Projekte, welche die alte Software durch ein neues System ablösten. Leider stellte sich die Ernüchterung ein, wenn bemerkt wurde, dass Funktionen der alten Software nicht in der neuen zu finden sind und auch niemand davon wusste. Regelmäßig wurde also nachgebessert um am Ende wenigstens das zu haben, was man früher sowieso schon hatte. Seit einigen Jahren tut man das nicht mehr, sondern lässt die alte Software laufen. Man nennt sie einfach "Legacy System" oder "backend", betrachtet sie als black box, baut Konnektoren (Schnittstellen) daran und lässt sie ansonsten unbehelligt weiterlaufen. Das klingt dann viel besser wie "Altlast" und ist auch billiger und bringt keine unangenehmen Überraschungen. Allerdings muss dazugesagt werden, dass dies erst neuerdings praktikabel ist mit der Verfügbarkeit von XML und einfacher Interprozesskommunikation z.B. mit Java. Frühere Techniken für Schnittstellen waren kompliziert, z.B. MQSeries, DataQueues, handprogrammierte TCP/IP Kommunikation, CORBA etc.

Standard- und Individualsoftware

Vor 1972 baute jedes Unternehmen seine Software selbst von Grund auf. Das geschah im Allgemeinen in Assembler oder COBOL oder einer speziellen problemorientierten Sprache. Dabei wurde das Rad öfters neu erfunden. Dies erkannten 4 IBM-Mitarbeiter und programmierten eine Software, die für alle Unternehmen passen müsste und nannten sie SAP R/2. Die Standardsoftware war geboren. Standardsoftware hat erstmal diese Vorteile:

- sie wird von einer Gruppe entwickelt, die mehr Know How hat als die Programmierer eines einzelnen Unternehmens, dessen Kerngeschäft ein ganz anderes ist. Es besteht eine bessere Chance, dass die Standardsoftware die bewährtesten Verfahren in den besten Algorithmen implementiert

- da Standardsoftware von mehreren Abnehmern identisch eingesetzt wird, verteilen sich die Kosten. Die Software wird für den einzelnen Abnehmer billiger.

- Standardsoftware entwickelt sich schneller weiter; die Erfahrungen aller Anwender fließen ein und kommen jedem Anwender zu gute;

Dem stehen diese Nachteile gegenüber:

- jeder Anwender braucht immer auch individuelle Funktionalität, die nicht im Standard ist; diese muss dazu programmiert werden, was u.U. intime Kenntnisse der Standardsoftware erfordert und die Kosten der Standardsoftware übersteigen kann

- der Standardsoftwarehersteller lebt von den verkauften Lizenzen und versucht mit technischen Mitteln seine Lizenzpolitik zu sichern. Regelmäßig geht dies einher mit der Versperrung des Zugangs zum Quellcode, Datenmodell, Unternehmensdaten. Der Anwender wird an den Hersteller gekettet.

- um attraktiv zu sein, baut der Hersteller möglichst viel in den Standard ein; bis der Anwender mit der Software arbeiten kann, geht ein Einführungsprojekt über die Bühne, wo aus dem Berg der Funktionen das zusammenkonfiguriert wird, was der Anwender braucht; dies beinhaltet einen Lernprozess beider Seiten und übersteigt leicht die Kosten der Standardsoftware;

Hybrid-Ansatz

Moderne Unternehmenssoftware wie z.B. das Produkt IntarS versucht einen Hybrid-Ansatz zwischen Standard- und Individualsoftware, um die Vorteile beider Verfahren zu kombinieren. Sie geht aus von der Prämisse, dass es einen Break-Even Point gibt zwischen der Zeitersparnis, einen grösseren Vorrat von Funktionen zu haben und dem erhöhten Zeitaufwand, diese Funktionen zu lokalisieren, zu verstehen und zu konfigurieren. Ab da lohnt es sich, die benötigte Funktionalität nicht im Standard vorzusehen, sondern bei Bedarf individuell zu programmieren. Typische Bereiche sind dafür Preis-, Rabatt-, Provisionssteuerung, Druckausgabenerzeugung. Desweiteren wird die Individualisierung als wesentlicher Schritt akzeptiert und vorausschauend adressiert. In der Praxis sieht das so aus, dass der Standard die technische Infrastruktur, ein betriebswirtschaftliches Kernsystem, editierbares offenes Datenmodell, Events, UserExits, Konnektoren, Schnittstellen für geplante Erweiterungen, ein öffentliches Programmiermodell, eine problemorientierte Scriptingsprache und eine Workbench zur strukturierten Durchführung der Individualisierung bereitstellt. Damit die Release- und Updatefähigkeit gewahrt bleibt, werden alle Individualisierungen in einem mandantenspezifischen Bereich durchgeführt. Das Standardsystem kann jederzeit auf den neuesten Stand angehoben werden, ohne individuelle Änderungen zu verlieren. Mit dem Hybrid-Ansatz lassen sich sehr kurze Projekteinführungen realisieren. Das System wächst mit dem Kenntnisstand des Anwenders mit. Gefahrlos können verschiedene Verfahren versucht und auch wieder verworfen werden. Iterative Verfahren und Moving Targets sind kein Problem.

Technik

Unternehmenssoftware ist Datenbanksoftware. Das virtuelle Abbild des Unternehmens findet seinen Niederschlag in Tabellen und Datenfeldern. Material-, Geld- und Informationsbewegungen werden laufend nachgehalten. Wie das von statten geht, hat sich im Laufe der Zeit verändert. Angefangen hat es mit transaktionsorientierter Verarbeitung. In SAP R/2 gibt es ein kleines Feld oben am Bildschirm, wo der Transaktionscode eingegeben wird. Daraufhin erscheint eine Bildschirmmaske, deren Felder man ausfüllt und mit "Datenfreigabe" abschickt. Die Daten werden daraufhin verarbeitet und führen unmittelbar zu Änderungen in der Datenbank. Diese Echtzeit Online Verarbeitung war ein enormer Fortschritt gegenüber der früheren Stapel-Verarbeitung.

Weil die Transaktionscodes aber so schwer zu merken waren, ging die Entwicklung zu menu- und dialoggeführten Systemen. Ein Terminal am Arbeitsplatz diente der Anzeige der Bildschirmmaske, die Verarbeitung wurde zentral im Rechenzentrum durchgeführt. Vorherrschend wurden hierarchische Datenbanken eingesetzt, insbesondere IMS und CICS. Die relationalen Datenbanken kamen erst später.

Als die PCs aufkamen, waren die textbasierten Masken nicht mehr schick. Farbe, Maus und Grafik mussten her. So wurden grafische Oberflächen darübergestülpt. Diese taten zwar das gleiche, waren nur nicht so effizient zu bedienen, sahen aber besser aus. Die Funktionstasten wurden zu Buttons, zum Anklicken. Die Software dahinter blieb erstmal auf dem Mainframe.

Dann kam man auf die Idee, auch die Softwarearchitektur zu verbessern. Das war auch dringend nötig, die Rede war vom Anwendungsstau. Die Programmierwerkzeuge und -Modelle waren von der zunehmenden Komplexität überfordert. Rettung erhoffte man sich von der Objektorientierung, versprach sie doch Wiederverwendung durch Vererbung, Komplexitätsreduzierung durch Trennung von Interface und Implementierung, sowie eine wirklichkeitsnähere Modellierung durch aktiv mittels Nachrichten interagierender Objekte. Auch Mainframes waren nicht mehr in, Client-Server Computing musste es sein. Es war die Zeit, wo jeder Hardware-Hersteller noch sein Unix-Derivat pflegte und ein eigenes Interprozess-Kommunikations-Protokoll anpries. Letztendlich setzte sich C++ durch, die Entwicklerwerkzeuge wurden besser, das Betriebssystem trat in den Hintergrund, Client-Server Computing ebbte ab. TCP/IP setzte sich gegen SNA durch, die Methoden-Päpste vereinigten sich oder versanken in Vergessenheit, das Wasserfall-Modell samt seinen Verfeinerungen wurde allenthalben zu Grabe getragen um dem iterativen Ansatz und extreme Programming, ansonsten UML 2 Platz zu machen. Java zeigte einen Ausweg aus den C++ Qualen, HTML beendete die Querelen um die richtige grafische Oberfläche.

Produkte

Für kleine Unternehmen

KHK Lexware

Für mittlere Unternehmen

abas-Business-Software Infor Navision IntarS ProAlpha

Für grosse Unternehmen

SAP BAAN SSA