Methoden, Verfahren, StandardsIm Gegensatz zu meiner bisherigen Homepage wird nicht mehr das gesamte Handbuch Methoden, Verfahren und Standards gezeigt, sondern je Kapitel ein Ausschnitt

Im Bereich der betriebswirtschaftlichen Datenverarbeitung mangelnd es auch heute noch an Grundlagen, nicht unüblich für eine neue Technologie, zur erfolgreichen Entwicklung und zum Einsatz von IT-Systemen. Durch die PCs und das Internet entstanden zusätzliche Anforderungen. Theoretisch richtig scheinende Lösungen haben sich in der praktischen Anwendung nicht bewährt. So hat sich das Wasserfallmodell für die Entwicklung von individuellen Systemen häufig als untauglich erwiesen. Auch die strukturierte Programmierung war mehr eine theoretische Lösung. In der Praxis wurde der Beweis erbracht, dass mit den richtigen Methoden, Verfahren und Standards individuelle betriebswirtschaftliche Systeme entwickelt und eingesetzt werden können, die für

den Anwender sachlich richtig, verfügbar, schnell und bedienungsfreundlich die Entwicklung konzeptions- und wartungsfreundlich die Abwicklung steuer- und kontrollierbar das Management sicher und wirtschaftlich

sind.

Dabei hilft der Leitsatz von Albert Einstein:“ Man muss die Dinge so einfach wie möglich machen. Aber nicht einfacher“. Über zwei richtungsweisende Projekte habe ich 1985 und 1990 in der Computerwoche berichtet. Wenn Sie meinen, dass das Geschichte ist, so werden Sie feststellen, dass sie auch heute noch brandaktuell sind.

Im ersten Artikel geht es um Probleme in der Dialogverarbeitung in einem deutschen Konzern und die erfolglose Suche nach Lösungen. So war das Unternehmen gezwungen sich selbst zu helfen.

Im zweiten Artikel geht es um Probleme beim Einsatz eines Vertriebs- und Auftragssystems in einem mittelständischen Unternehmen. Bedingt durch die organisatorische und wirtschaftliche Lage war dieser Projekterfolg nur mit "agilem Vorgehen" zu erreichen. Dieses Vorgehen alleine garantiert jedoch nicht den Projekterfolg, sondern es müssen weitere Voraussetzungen gegeben sein.

http://www.computerwoche.de/a/praktiker-fordern-mehr-als-schoene-argumente,1167553 http://www.computerwoche.de/a/als-waffe-im-wettbewerb-taugt-standardsoftware-nicht,1147233

© Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

Methodenberatung für Informationsverarbeitung

Handbuch EDV

Problem

Grundlagen

Daten

Tabellen

Störungen

Stapelverarbeitung

Dialogverarbeitung

Bedienungslogik

Prozessplanung

Prozesssteuerung

Systementwicklung

Über mich Home Impressum

Inhaltsverzeichnis

Ist-Analyse Simulation Konzeption Realisierung

Test

Einsatz

Methoden, Verfahren, Standards

zur Entwicklung und zum Einsatz von

betriebswirtschaftlichen EDV-Systemen

MBI

Lösung

Praxisbeispiele

http://www.computerwoche.de/a/praktiker-fordern-mehr-als-schoene-argumente,1167553

http://www.computerwoche.de/a/als-waffe-im-wettbewerb-taugt-standardsoftware-nicht,1147233

Home

Meine Homepage wurde bereits 2-mal durch meinen Internetdienstleister wegen Malware gesperrt. Ich war daher gezwungen eine andere Lösung zu finden. Ein Schutz meiner Dateien und auch der zur Pflege dieser Daten notwendigen Programme ist nicht möglich. Ich habe daher diesen Weg gewählt. Das Textdokument „HOMEPAGE“ wird in WORD auf meinem PC 1 gepflegt und per USB-Stick auf PC 2 übertragen, in ein PDF-Dokument konvertiert und zum Internetdienstleister übertragen. Der Aufbau des PDF-Dokumentes entspricht meiner vorherigen Homepage. Die Navigation erfolgt über Textmarken und Hyperlinks. Im Gegensatz zu meiner bisherigen Homepage wird nicht mehr das gesamte Handbuch Methoden, Verfahren und Standards gezeigt, sondern je Kapitel ein Ausschnitt. Wer Interesse am gesamten Handbuch hat, kann sich mit mir per Email in Verbindung setzen. Änderungen/Erweiterungen 24.04.2016 Praxisbeispiel A2 - Zahlungsverkehrsunternehmen .

zurück

PC 1

ohne Internet

PC 2

mit Internet

Internet

Dienstleister

U S

B

PDF-

Datei

Problem


Die Systemlandschaft gleicht in vielen Unternehmen dem Turmbau zu Babel und es besteht die permanente Gefahr des Einsturzes. Die Betreuung und notwendigen Instandhaltungen lasten die IT-Abteilungen in großen Unternehmen fast vollständig aus.

Die „Softwarekrise“ bei individueller Systementwicklung ist so alt wie die Datenverarbeitung. Diese Krise wurde durch PCs und Internet noch verschärft. Standardsysteme, insbesondere in den administrativen Bereichen, lösten Eigenentwicklungen ab. Im operativen Bereich, den für den Erfolg des Unternehmens entscheidenden, können Standardsysteme oft nur oberflächlich die Anforderungen abdecken. Auto-, Glas- oder Schlossindustrie haben nur wenig gemeinsam. Um die enormen Vorteile eines, auf die Belange der Branche und des Unternehmens ausgerichteter Software zu erlangen, sind Eigenentwicklungen notwendig um die Marktposition zu sichern und zu verbessern.

Allerdings eignen sich alle heute angewandten Entwicklungsverfahren nur zur Erstellung begrenzter Systeme; bei komplexen betrieblichen Informations- und Abwicklungsprozessen versagen sie. Es ist praktisch nicht möglich, ein gesamtes System – vom Auftragseingang bis zur Warenauslieferung – zu konzipieren und zu realisieren. Selbst Teilabschnitte sind mit den heute üblichen Verfahren kaum realisierbar. Neue Programmiersprachen und mächtige Entwicklungstools haben nicht dazu geführt, dass bessere Systeme entwickelt wurden. Im Gegenteil, die Vielzahl „mächtiger Werkzeuge“ und die Vielzahl der Programmiersprachen behindern die Entwickler bei ihrer eigentlichen Aufgabe, zufriedenstellende Lösungen der Fachprobleme zu finden.

zurück

Lösung

*) Hochschule Coburg, Fach Architektur


zurück

Die betriebswirtschaftlichen DV-Systeme bilden in der Regel den organisatorischen Aufbau des Unternehmens wieder. Die einzelnen Systeme unterstützen Geschäftsprozesse durch Dialog- und/oder Stapelverarbeitungen.

Die Anforderung an diese DV-Infrastruktur ist sehr gut mit dem Städtebau vergleichbar. Es müssen neue Systeme bzw. Geschäftsprozesse gebaut, gewartet oder abgerissen werden. Eine gemeinsame Programmiersprache ist Voraussetzung dafür, dass es nicht zu Verständigungsproblemen kommt. Eine schlüsseltechnische Ordnung, vergleichbar mit Stadtteilnamen, Straßenbezeichnungen und Hausnummern ist notwendig, damit sich die „Systemstadt“ nicht zu einem Irrgarten entwickelt. Allgemein gültige Bauregeln sorgen dafür, dass funktionsgerechte Gebäude gebaut werden. Ein standardisierter Datenzugriff, vergleichbar mit der Energieversorgung eines Hauses, ist bereitzustellen. Teile der „Systemstadt“ müssen unter Quarantäne gestellt werden können, damit sich interne und externe Seuchen nicht verbreiten können. Standardprogramme, vergleichbar mit „kommunalen“ Einrichtungen, lösen allgemeine Aufgaben. Die normierte Logik für Stapel- und Dialogprogramme und die Auslagerung der Systemvariablen in externe Tabellen sichern Wartung und Weiterbau. Eine standardisierte Bedienungslogik, vergleichbar mit einem Schaltgetriebe im Auto, sorgt für einen sicheren und schnellen „Verkehr“. Die Bedienungslogik ist nicht nur ein internes Problem, sondern wird für jeden im Internet nachvollziehbar. Die Internet-Anwendungen bei Banken, Versicherungen, Energieunternehmen usw. haben eine individuelle Bedienungslogik, auch wenn es sich um die gleiche Branche und dem gleichen Geschäftsprozess handelt. Das zieht sich durch den ganzen Dialog, von der Anmeldung bis zur Abmeldung.

Die bestmöglichen Projekterfolge werden mit agilem Vorgehen, selbst mit den hier gezeigten Methoden, Verfahren und Standards nicht erreicht, wenn sich die Lebens- und Arbeitsbedingungen der davon betroffenen Mitarbeiter verschlechtern. Welcher Mitarbeiter, egal in welcher Position, unterstützt vorbehaltlos ein Projekt, wenn es ihm persönlich schadet? Es geht dann nicht mehr um die bestmögliche Lösung für das Unternehmen, sondern um die bestmögliche Lösung für sich selbst.

Betriebswirtschaftliche Systeme, die nach den in diesem Handbuch beschriebenen Methoden, Verfahren und Standards entwickelt wurden, waren über viele Jahre fehlerfrei und wartungsarm. Der Wartungsaufwand, überwiegend Pflege von Tabellen, lag unter 5%, so dass die Systementwickler an weiteren Bausteinen für bestehende Systeme arbeiten bzw. neue Systeme entwickeln konnten. Sie haben sich in Service-Rechenzentren und auch bei Firmen mit eigenen Rechenzentren bewährt.

Programmiersprache

. . zurück Lösung


---1----+----2----+----3----+----4----+----Member=Pnnnnn--+----7-

WORKING-STORAGE SECTION.

*---------------------------------------------------------------*

* IA-DATEN

* -SATZZ Satzzähler

* -KKVOR Vortrag Kreditkarten

* -KKNRN Kreditkartennummer

*---------------------------------------------------------------*

01 FILLER PIC X(0016) VALUE “****IA-DATEN****”.

01 IA-DATEN.

05 IA-SATZZ PIC 9(0009) COMP-3 VALUE 0.

05 IA-KKVOR.

10 FILLER PIC X(0004) VALUE SPACES.

10 IA-KKNRN PIC X(0012) VALUE SPACES.

10 FILLER PIC X(0084) VALUE SPACES.

PROCEDURE DIVISION.

.

B1000 SECTION.

*---------------------------------------------------------------*

* B1000 – Lesen Vortrag Kreditkarten

*---------------------------------------------------------------*

01.

MOVE „B1000“ TO YX-ASECT.

* Lesen

MOVE YS-IADAT TO YS-DATEI.

MOVE YS-RESEQ TO YS-BFART.

PERFORM U0004.

IF YK-ABRCH = “E”

GO 99.

* Ende Daten ?

IF YS-DTEOF = “E”

MOVE “1” TO YG-DG101

GO 99.

* Nein: Übernehmen

MOVE YS-DTANW TO IA-KKVOR.

MOVE IA-KKNRN TO YG-DG102.

COMPUTE IA-SATZZ = IA-SATZZ + 1.

99.

EXIT.

zurück

So wie Englisch die globale Wirtschaftssprache ist, so bietet sich COBOL für den betriebswirtschaftlichen Bereich eines Unternehmens als globale Programmiersprache an. COBOL (Common Business Oriented Language) ist stark an die natürliche Sprache angelehnt und wurde speziell zur Lösung kaufmännischer Problemstellungen entwickelt.

Mit den Anweisungen „ IF, MOVE, ADD, SUBTRACT, COMPUTE, GO und PERFORM“ können über 90% aller notwendigen Instruktionen in der betriebswirtschaftlichen Datenverarbeitung abgedeckt werden. Mit der PICTURE-Klausel „X“ und „9“ werden über 99% aller notwendigen Definitionen, Text und Zahlen, abgedeckt. ADD und SUBTRACT können durch COMPUTE ersetzt werden. COBOL wird kontinuierlich den geänderten und gestiegenen Anforderungen angepasst. So hat der Inline-PERFORM dazu geführt, dass so gut wie keine Schleifen mit GO innerhalb einer SECTION programmiert werden, sondern überwiegend nur noch zum SECTION-Ausgang. Die Modifikation der Feldlängen über Längenangaben, wie in Assembler, war die wirkungsvollste Weiterentwicklung von COBOL. Bei Berücksichtigung weniger Aspekte wird COBOL fast 1:1 in Assembler umgesetzt.

Schlüsseltechnische Ordnung


S Der organisatorische Aufbau eines Unternehmens ist nicht fix, sondern muss sich den wirtschaftlichen Rahmenbedingungen anpassen.

Die Verwaltung der Kundendaten kann neu geordnet werden. So wird der Geschäftsprozess „AF01- Pflege Kunden“ von der Auftragsbearbeitung zur Transaktion „VT01“ im Vertrieb und die Transaktion „AF09 – Anzeige Kunde“ zur Transaktion „CS07“ im Callcenter. Die Geschäftsprozesse ändern sich nicht, nur die organisatorische Zuordnung. Diese organisatorischen Änderungen sind rein administrativ und verursachen nur geringen Anpassungsaufwand.

Die fixen Schlüsselbegriffe dienen der eindeutigen Kennung der Systemkomponenten. Sie setzen sich aus einem Kennbuchstaben, wie „P - für Programm“ oder „F - für File/Datei“ und einer laufenden Nummer zusammen. Eine laufende numerische Ordnung bietet sich an, da kaum Verwaltungsaufwand entsteht. Wird ein neuer Ordnungsbegriff benötigt, so wird die nächste freie Nummer belegt. Die Verwendung von variablen Schlüsseln für diese Systemkomponenten führt dazu, dass bei Änderungen der Organisation eine Anpassung der Schlüssel erfolgen müsste, um die Schlüsselsystematik zu erhalten. In der Praxis verzichten selbst wirtschaftlich gesunde Unternehmen auf diesen unnötigen Änderungs- und Testaufwand.

zurück

Daten Da

Betriebswirtschaftliche Systeme

Aufträge AF

Vertrieb

VT Call Center CS

Pflege Kunde AF01

Anzeige Kunde AF09

P00001

P00002

P00003

Anzeige Kunde CS07

Pflege Kunde VT01

P00003

P00001

P00002

Kunden F0001

Aufträge F0002

Systeme Dialog Transaktionen

Daten

Pflege Auftrag AF02

Bauregel - Codierung


---1----+----2----+----3----+----4----+----Member=P00340--+----7-

DATA DIVISION.

WORKING-STORAGE SECTION.

* DTA-Satz Banken

COPY D0026.

*---------------------------------------------------------------*

* LS-DATEN Lastschrift

* -KDBLZ - Kunde Bankleitzahl

* -KDKTO - Kunde Konto

* -BETRG - Betrag

* -VWTX1 - Verwendungstext 1

* . . .

*---------------------------------------------------------------*

01 FILLER PIC X(0016) VALUE „****LS-DATEN****“.

01 LS-DATEN.

05 LS-KDBLZ PIC 9(0008) VALUE ZEROES.

05 LS-KDKTO PIC 9(0010) VALUE ZEROES.

05 LS-BETRG PIC S9(0009)V99 COMP-3 VALUE +0.

05 LS-VWTX1 PIC X(0027) VALUE SPACES.

...

...

PROCEDURE DIVISION.

* Standardlogik

COPY C00002.

C2000 SECTION.

*---------------------------------------------------------------*

* C2000 – Wechsel Kreditkartennummer

*---------------------------------------------------------------*

01.

MOVE „C2000“ TO YX-ASECT.

* Neuer Vortrag

PERFORM C2000A.


GO 99.

* Lastschrift ?

IF LS-BETRG = +0

GO 99.

* Ja: Aufbereiten DTA-Satz

MOVE LS-BETRG TO BETRG0026D.

MOVE LS-KDBLZ TO KDBLZ0026D.

MOVE LS-KDKTO TO KDKTO0026D.

MOVE . . . . TO . . . .

99.

EXIT.

DATA DIVISION.

- COPY-Aufrufe mit Kurztext - Arbeitsbereiche nach Funktionen ordnen - Datenfelder beschreiben

- Lokalisierung Daten für Abbruchbehandlung - Datenfelder Ausprägung

PROCEDURE DIVISION.

- SECTION mit Kurztext - Eingang „01“ - Lokalisierung SECTION für Abbruchbehandlung - Aufruf SECTIONS mit Schlagwort erklären - IF-Anweisungen einrücken mit Schlagwort - Eine Anweisung je Zeile - Anweisung mit „.“ abschließen Ausgang „99“

Das Grundziel der Codierrichtlinien ist: "Der Autor ist nur an der Namenszeile zu erkennen". Die einheitliche Gestaltung und die Namenskonventionen unterstützen das bildhafte Lesen. So ist auf einen Blick zu sehen, dass die Daten für das Aufbereiten des DTA-Satzes vom Arbeitsbereich "LS-" in den Datensatz „D0026“ erfolgt. Ein 5-stelliger Kurzname reicht aus, um die notwendigen Datenfelder zu identifizieren. Dieser Name wird programmintern durch den Präfix und programmextern durch die Datenart- oder Tabellennummer ergänzt. So wird das Feld DT-KDBLZ zur KDBLZ0026D im Datenträgeraustauschsatz „D0026“ der Banken. Es gibt in einer betriebswirtschaftlichen Anwendung nur eine begrenzte Anzahl von Datenfeldern. Die häufig benutzten Felder sind, selbst für Neueinsteiger, bald vertraut. Für die Standardroutinen wird ein Präfix, z.B. „Y.-„, reserviert. Auch diese Anzahl der Felder ist begrenzt und daher allgemein verständlich. Durch Lokalisierung der Daten (LS-Daten) und der SECTION (YX-ASECT) wird die Analyse bei Programmabbrüchen erleichtert. Fast immer ist ein ungültiger Feldinhalt die Ursache. Trat bisher nur in der Funktionstestphase auf, im Abnahmetest und Produktivsystem nie.

Ein Programm besteht ausschließlich aus SECTIONS die mit PERFORM aufgerufen werden. Innerhalb einer SECTION gibt es nur numerische Sprungadressen. Ein Sprung außerhalb der SECTION ist dadurch ausgeschlossen. Die Stigmatisierung der „GO“ bzw. „GO TO“ Anweisung hat nicht dazu beigetragen, dass das Verständnis und die Logik verbessert wurden. Sie hat im Gegenteil dazu geführt, dass in der Praxis häufig kaum durchschaubare Schachtelbedingungen programmiert wurden. Es ist nicht nachvollziehbar, warum ein Sprung zum SECTION-Ausgang nicht sinnvoll ist, wenn die restlichen Anweisungen unter dieser Bedingung nicht ausgeführt werden dürfen. Richtig angewandt, erleichtert die GO-Anweisung dem Systementwickler die Programmierung und führt zu einem besseren Verständnis der Logik und damit zu fehlerfreien Programmen.

zurück

Datenzugriff


Datenart File

F0001/Kunden F0002 Aufträge


P00001

P00002

P00003

Anzeige Kunde CS07

Pflege Kunde VT01

P00002

P00001

P00034

000146839801 000146839802 . 0012ABUCH 475867891 0012ABUCH 475867900

000246839801 000246839900 . 002820140503162301

Dialog Transaktionen

File/Datei

Pflege Auftrag AF02

P00020

P00015

P00014

P00016

Ein-/Ausgabeprogramm

000246839801

0012ABUCH

0001 F0001 0002 F0002 .

0012 F0001

000146839801

Das anfordernde Programm übergibt den Zugriffscode und den Schlüssel mit/ohne Daten. Über ein Verzeichnis wird der Speicherort ermittelt. Durch die Datenart in den Stellen 1-4 des Schlüssels wird dieser eindeutig, auch wenn alle anderen Schlüsselfelder gleich sind. Das Ein-/Ausgabeprogramm meldet das Ergebnis des Zugriffes und stellt Schlüssel mit/ohne Daten dem anfordernden Programm zur Verfügung. Diese Zugriffsmethode macht die Programme völlig unabhängig vom Ort und Art der Speicherung der Daten. Es wäre möglich alle Daten eines Unternehmens in einer Datei zu speichern, wenn die Daten im variablen Satzformat und einem 30-stelligem Schlüssel am Satzanfang definiert werden. 30 oder 50 Bytes reichen auch für sehr lange Schlüssel aus, wenn binäre und hexadezimale Speicherung genutzt wird. Die Speicherung der Daten in einer Datei ist sicher nicht sinnvoll. Sinnvoll ist, dass die Speicherung der Daten den variablen Bedingungen, wie Wachstum und Sicherheit, angepasst wird.

zurück

03 07 04

Störungen


XX Daten

Da

Dialog-/Stapelverarbeitung

Aufträge AF

Vertrieb

VT XXXXXXX ZZ

Tagesverarb. JAF001

Pflege Kunde AF01

Pflege Auftrag AF02

P00001

P00002

Pnnnnn

XXXXXXX Ann

Monatsabschl. JAF002

P01004

Pnnnnn

P01003

Kunden F0001

Aufträge F0002

XXXXXX Fnnnn

Systeme Dialog Transaktionen

Stapel Jobs

Daten

XXXXXX JAFnnn

Eine Störung kann in einer Transaktion oder Datei auftreten. Eine 100%ige Dialogverfügbarkeit kann erreicht werden, wenn durch Sperrung des Systems, der Transaktion oder aller Transaktionen, die auf eine Datei zugreifen, die Störung „isoliert“ werden kann. In der Praxis hat sich ein unerwarteter Nebeneffekt eingestellt. Notwendige Anpassungen der Geschäftsprozesse werden von der Systementwicklung stressfreier und daher schneller und sicherer realisiert. Das wiederum führt dazu, dass über Jahre ein störungsfreier Dialog erreicht wurde. Die Störungs- oder Einsatzsteuerung ist trotzdem sehr hilfreich, wenn eine Stapelverarbeitung nicht rechtzeitig zum Dialogstart beendet war oder vor Dialogende gestartet werden sollte.

zurück

Über mich

Ich war 33 Jahre (davon 15 festangestellt) in der betriebswirtschaftlichen Datenverarbeitung tätig. Den Schritt in die Selbständigkeit habe ich 1985 gemacht, weil ich immer weniger Zeit für meine eigentliche Leidenschaft, die Projektarbeit und das Lösen von Problemen hatte. Die Datenverarbeitung steckte Anfang der 70er Jahre noch in den Kinderschuhen und durch die Dynamik der Entwicklung gab es laufend neue Anforderungen. Die dafür angebotenen Lösungen waren daher nur theoretisch und hatten sich in der Praxis noch nicht bewährt. Mir wurde bald bewusst, dass nur eine ganzheitliche Betrachtung zum Erfolg führt. Dieses Buch zu schreiben war mir eine Herzensangelegenheit um die von mir entwickelten Methoden, Verfahren und Standards nicht verloren gehen zu lassen. Es gibt keinen besseren Beweis für deren Richtigkeit, als ein erfolgreiches Projekt, dass die Anforderungen aller Beteiligten erfüllt, eben ganzheitlich.

Arbeitgeber/Auftraggeber mit den wesentlichen Projekten 1971 – 1977 Unternehmensberatung mit Service-Rechenzentrum Organisationsprogrammierer Leiter Organisationsprogrammierung . Methoden/Verfahren/Standards für Batchprogramme . Entwicklung/Einsatz normierte Programmierung für Batchprogramme 1977 – 1981 Unternehmensberatung mit Service-Rechenzentrum Leiter Rechenzentrum und Systemprogrammierung . Methoden/Verfahren/Standards für Systemabwicklung . Entwicklung/Einsatz Planungs-und Steuerungssystem für Rechenzentren 1981 – 1984 Verpackungsindustrie Leiter Organisationsprogrammierung . Methoden/Verfahren/Standards für Dialogprogramme

. Entwicklung/Einsatz normierte Programmierung für Dialogprogramme . Entwicklung/Einsatz Dialogsteuerungssystem 1985 – 1990 Schloss- und Beschlagindustrie Unternehmensberater . Reorganisation Auftragsabwicklung im Geschäftsbereich Schließanlagen

. Vorgehensmodell zur Entwicklung und zum Einsatz komplexer EDV-Systeme . Entwicklung/Einsatz Vertriebs- und Auftragssystem 1991 – 1996 Zahlungsverkehrsunternehmen Unternehmensberater . Entwicklung/Einsatz Verwaltungs- und Abrechnungssystem für den

. Geschäftsbereich electronic cash (ECC, POZ, EDC-Maestro, Geldkarte über Multi CARD Manager), Ablösung Alt-Systeme 1997 – 1998 Telekommunikationsunternehmen Unternehmensberater . RZ-Organisation System PayCard/Basiskarte . Fachlicher/technischer Abnahmetest, Aufnahme Produktion Phase I/Paycard, Phase II/Basiskarte 1999 – 2003 Bankwesen Unternehmensberater . Universelles Replikationssystem zur Übertragung von Daten von einem Quellsystem zu mehreren Empfängersystemen 2004 – heute Allgemein Diverse Tätigkeiten (Unterbrechungen durch Krankheiten) . Handbuch Methoden, Verfahren, Standards für betriebswirtschaftliche Software

zurück

Impressum

MBI Methodenberatung für Informationsverarbeitung Franz Mugrauer Frankfurter Str. 84 D-63110 Rodgau Tel. : 06106/76296 Email: mailto:[email protected]

zurück

mailto:[email protected]

2. Grundlagen 2.1 Organisation 2.2 Operative Systeme 2.2.1 - Schlüsseltechnische Ordnung 2.2.2 - Dokumentation 2.2.3 - Schlüssel- und Nummernkreise 2.2.4 - Programmiersprache 2.2.5 - Codierrichtlinien 2.3 Fazit 3. Daten 3.1 Problem 3.2 Lösung 3.3 Konzeption 3.3.1 Dateiverzeichnis 3.4 Definition Schlüssel/Daten 3.5 Dialogverarbeitung 3.5.1 - Definition Job-Control 3.5.2 - Verständigungsbereich 3.5.3 - Lesen 3.5.4 - Lesen generisch 3.6 Stapelverarbeitung – Zugriff direkt 3.6.1 - Definition Job-Control 3.6.2 - Verständigungsbereich 3.6.3 - Lesen mit Rückschreiben 3.7 Stapelverarbeitung – Zugriff sequentiell 3.7.1 - Definition Job-Control 3.7.2 - Verständigungsbereich 3.7.3 - Lesen 3.7.4 - Schreiben 3.8 Fazit 4. Tabellen 4.1 Problem 4.2 Lösung 4.3 Konzeption 4.3.1 - Pflege Tabellen 4.3.2 - Definition 4.4 Dialogverarbeitung 4.4.1 - Definition Job-Control 4.4.2 - Verständigungsbereich 4.4.3 - Lesen 4.5 Stapelverarbeitung 4.5.1 - Definition Job-Control 4.5.2 - Verständigungsbereich 4.5.3 - Lesen generisch 4.6 Fazit

Methoden, Verfahren, Standards 1 Inhaltsverzeichnis für betriebswirtschaftliche EDV-Systeme Seite 1

5. Störungen 5.1 Konzeption 5.2 Dialogverarbeitung 5.2.1 - Verständigungsbereich 5.2.2 - Störungen - allgemein 5.2.3 - Störungen – individuell 5.2.4 - Beispiel 5.3 Stapelverarbeitung 5.3.1 - Verständigungsbereich 5.3.2 - Störungen – allgemein 5.3.3 - Störungen – individuell 5.3.4 Beispiel 5.4 Internet 5.4.1 - Traditionelle Auftragsabwicklung 5.4.2 - Moderne Auftragsabwicklung 5.4.3 - Traditionelle/moderne Auftragsabwicklung 5.4.4 - Beispiel 5.5 Fazit 6. Stapelverarbeitung 6.1 Job 6.1.1 - Problemstellung 6.1.2 - Lösung 6.1.3 - Beispiel 6.1.4 - Jobsteuerung 6.1.5 - Dateiverzeichnis 6.1.6 - JCL (Job Control Language) 6.1.7 - Dokumentation 6.2 Programm 6.2.1 - Problemstellung 6.2.2 - Standardlogik 6.2.3 - Standardstruktur 6.2.4 - Beispiel 6.2.5 - Codierung 6.2.6 - Dokumentation 6.3 Fazit 7. Dialogverarbeitung 7.1 Transaktion 7.1.1 - Problemstellung 7.1.2 - Lösung 7.1.3 - Beispiel 7.1.4 - Dokumentation 7.2 Programm 7.2.1 - Problemstellung 7.2.2 - Standardlogik 7.2.3 - Standardstruktur 7.2.4 - Standardmaske 7.2.5 - Standardbedienung 7.2.6 - Aktionslogik 7.2.7 - Beispiel 7.2.8 - Codierung 7.2.9 - Dokumentation 7.3 Fazit

Methoden, Verfahren, Standards 1 - Inhaltsverzeichnis für betriebswirtschaftliche EDV-Systeme Seite 2

8. Bedienungslogik 8.1 Anmeldeverfahren 8.2 Bildschirmsteuerung 8.2.1 - OK-Code „J“ 8.2.2 - OK-Code „N“ 8.2.3 - OK-Code „O“ und „R“ 8.2.4 - OK-Code „?“ und „R“ 8.2.5 - Seitenbehandlung 8.3 Suchverfahren 8.4 Mehrsprachigkeit 8.5 Fazit 9. Prozessplanung 9.1 Anforderung 9.2 Operationsfluss 9.3 Terminplanung 9.3.1 Jahreskalender 9.4 Basistermine 9.4.1 Basis Wochentag 9.4.2 Basis Monatsdatum 9.4.3 Basis Jahresdatum 9.5 Terminplan Abteilungen 9.6 Fazit 10. Prozesssteuerung 10.1 Steuerung Stapelverarbeitung 10.1.1 - Jobsteuerung 10.1.2 - RZ-Auftrag 10.2 Steuerung Dialogverarbeitung 10.2.1 - Start Dialog 10.2.2. - Ende Dialog 10.2.3 - Start/Ende Systeme 10.2.4 - Anzeige Störungen 10.2.5 - Sperren/Freigabe 10.2.6 - Aufgabe Nachrichten 10.2.7 - Anzeige Nachrichten 10.2.8 - Pflege Systeme 10.2.9 - Pflege Transaktionen 10.2.10 - Pflege Dateien 10.2.11 - Pflege Anwender 10.2.12 - Pflege Dateizugriffe 10.2.13 - Pflege Berechtigungen 10.2.14 - Anzeige Dokumentation 10.2.15 - Druck Dokumentation 10.3 Datenmodell Dialogsteuerung 10.4 Datenmodell Dokumentation 10.5 Datenmodell Tabellen 10.6 Fazit



11. Systementwicklung 11.1 Vorgehensmodell 11.2 Bauabschnitt 11.3 Konzeption 11.3.1 - Beispiel 11.4 Simulation 11.4.1 - Anmeldung 11.4.2 - Programm-/Maskenbeschreibung 11.4.3 - Schlüsselmodell 11.4.4 - Suchverfahren 11.4.5 - Datenmodell 11.4.6 - Systemvariable 11.5 Realisierung 11.5.1 - Schlüssel/Daten 11.5.2 - Systemvariable 11.5.3 - Programmlogik 11.5.4 - Zugriff Daten 11.5.5 - Zugriff Tabellen 11.5.6 - Basissoftware und Werkzeuge 11.6 Einsatz 11.6.1 - Abnahmetest 11.6.2 - Verzeichnisse/Referenzen 11.7 Fazit Anhang Praxisbeispiele A1 Schloss- und Beschlagindustrie A2 Zahlungsverkehrsunternehmen

zurück

COBOL

---1----+----2----+----3----+----4----+----Member=P00340--+----7-

C2000 SECTION.

*---------------------------------------------------------------*


*---------------------------------------------------------------*

01.

MOVE “C2000“ TO YX-ASECT.

* Neuer Vortrag

PERFORM C2000A.


GO 99.

* Lastschrift ?

IF LS-BETRG = +0

GO 99.

* Ja: Aufbereiten DTA-Satz

MOVE LS-BETRG TO DT-BETRG.

MOVE LS-KDBLZ TO DT-KDBLZ.

MOVE LS-KDKTO TO DT-KDKTO.

MOVE . . . . TO . . . .

99.

EXIT.

Assembler

---1----+----2----+----3----+----4----+----Member=P00340--+----7-

*---------------------------------------------------------------*


*---------------------------------------------------------------*

C2000RG DS 1F

*

C2000 ST 14,C2000RG

MVC XYASECT,=CL5‘C2000‘

* Neuer Vortrag

BAL 14,C2000A

CLI YKABRCH,C’E’

BE C2000EX

* Lastschrift ?

CP LSBETRG,=P’0’ BE C2000EX * Ja: Aufbereiten DTA-Satz

ZAP DTBETRG,LSBETRG

MVC DTKDBLZ,LSKDBLZ

MVC DTKDKTO,LSKDKTO

MVC ……………………,………………

*

C2000EX L 14,C2000RG

BR 14

Methoden, Verfahren, Standards 2. Grundlagen für betriebswirtschaftliche EDV-Systeme 2.2.5 Codierrichtlinien

Anhand dieser Gegenüberstellung ist ersichtlich, dass diese Standards der Codierungen für beide Programmiersprachen sinnvoll sind. So war es auch mit Assembler richtig, dass das Programm aus diversen Unterroutinen bestand, die mit BAL (branch and link) anstatt PERFORM aufgerufen wurden. Diese Routinen hatten einen Eingang und einen Ausgang. Eine Verzweigung war nur innerhalb der Routine erlaubt. Da Assembler eindeutige Sprungadressen benötigt, wurden die Anschlusspunkte innerhalb der Routine mit C200010 bis C200090 adressiert. Die hier gezeigten Richtlinien wurden in den 70iger für COBOL und Assembler festgelegt und sie sind heute genauso notwendig, wie damals. Sie sind auch für jede andere Programmiersprache unabdingbar. Es beweist auch, dass Assembler für betriebswirtschaftliche Problemstellungen durchaus geeignet war und ist. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

Vergleich COBOL/Assembler

zurück

Methoden, Verfahren, Standards 3. Daten für betriebswirtschaftliche EDV-Systeme 3.2 Lösung

Schließanlagen Kreditkarten

Ve

Bis


Geschäftsprozess 1

Stapelverarbeitung

Geschäftsprozess 2

Dialogverarbeitung

Geschäftsprozess n

Dialogverarbeitung

Key 1 – 30 Daten 31 – 3600 var.

--------------------------------------------------

0001748321 Hans Berger 0001748324 Karl Holz 0001 800201 Tilo Koch 0002CAABC HS-Anlage 0002CAABE GHS-Anlage 0002GDDBA Z-Anlage 0007 777239 14.03.2012 0007 777240 14.03.2012 0007 779781 15.07.2012

Key 1 – 30 Daten 31 – 3600 var.

--------------------------------------------------

0001 934671 Hotel Atlantis 0001 934672 Kosmetik Bila 0001 978231 RixAir 00025232….3910 Martin 00025232….3922 Loser 00025232….9932 Winner 00365232.. 934671 972,12 € 00365232.. 934672 88,99 € 00366030.. 978231 80,70 €

0001 Fachhändler

0002 Anlagen

0007 Aufträge

0002 Karteninhaber

0001 V-Unternehmen

0036 Transaktionen

Die Lösung des Problems ist einfach. Alle Daten werden mit einem 30-stelligen Primärschlüssel am Satzanfang und einem variablen Datenteil von maximal 3570 Bytes gespeichert. Durch die Erweiterung des Primärschlüssels um eine 4-stellige Datenart wird dieser eindeutig, auch wenn der Restschlüssel, z.B. gleiche Kunden-/Lieferantennummer, dies nicht ist. Die Programme greifen nicht direkt zu, sondern geben einen Auftrag an ein standardisiertes Ein-/Ausgabeprogramm, Daten anzulegen, zu ändern, zu löschen oder eine Datenkette zu lesen. Dabei ist es völlig unerheblich, ob es sich Kunden, Aufträge, Schließanlagen, Vertragsunternehmen, Transaktionen usw. handelt. Diese Zugriffsvarianten müssen nur einmalig programmiert und getestet werden und sind daher logisch fehlerfrei. Alle anderen Lösungsansätze, wie SQL, haben in der Praxis nicht zu dem erwarteten Erfolg geführt. Mit SQL wurde das Problem verlagert, aber nicht gelöst. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

T0002 *0100 Systemsprachen

T0002 *0110 --------------

T0002 *0120 Spalte 1 = Code Sprache

T0002 *0130

T0002 *0140 System = „ „ Standardsprache

T0002 *0150 „X“ Sprachkennzeichen im System

T0002 *0160

T0002 *0170 System Bezeichnung

T0002 *0180 ------ ------------------------------------------------

T0002 D Deutsch (Standard)

T0002 E E Englisch

T0002 F F Französisch

T0002 S S Spanisch

Laden Tabellen

----+----1----+----2----+----3----+----4----+----Member=T0002---+----7----+----8

START-MEMBER=T0002

*0100 Systemsprachen

*0110 --------------

*0120 Spalte 1 = Code Sprache

*0130

*0140 System = „ „ Standardsprache

*0150 „X“ Sprachkennzeichen im System

*0160

*0170 System Bezeichnung

*0180 ------ ------------------------------------------------

D Deutsch (Standard)

E E Englisch

F F Französisch

S S Spanisch

END-MEMBER-T0002

Primärschlüssel Daten

Tabelle Diverse Tabelleninhalt

Methoden, Verfahren, Standards 4. Tabellen für betriebswirtschaftliche EDV-Systeme 4.3.1 Pflege

Es gibt nur wenige Einschränkungen, die bei der Erstellung einer Tabelle zu beachten sind, ansonsten sind der Kreativität keine Grenzen gesetzt. Eine Tabelle besteht aus der Dokumentation und dem eigentlichen Tabelleninhalt. Die Tabelle wird durch eine Start- und Endeanweisung eingegrenzt. Der Primärschlüssel der Tabellen setzt sich aus der maximal 8stelligen Tabellennummer und einem 12stelligen individuellen Schlüsselbegriff zusammen. Für den Tabelleninhalt sind 80 Bytes vorgesehen. Sollten größere Schlüssel und/oder Daten benötigt werden, sind diese Tabellen in einer eigenen Datei/Tabelle zu speichern. Die sequentiellen Texttabellen werden für den direkten Zugriff in eine Datei/Tabelle geladen. Zuerst wird die alte Tabelle gelöscht und wieder angelegt. Besteht die neue Tabelle nur aus Start-/Endeanweisung führt das zwangsläufig zur Entfernung der Tabelle. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Traditionell Auftrag Bestätigung

K U N D

E

Terminal Rechner

Unternehmen

K U N D

E

Post, Fax, Telefon Eingabe Verarbeitung Post, Fax, Telefon

Modern Auftrag Bestätigung

K U N D

E

PC Rechner

Unternehmen

K U N D

E

Eingabe Internet Verarbeitung Internet

PC PC PC

Methoden, Verfahren, Standards 5. Störungen für betriebswirtschaftliche EDV-Systeme 5.4 Internet

Die dargestellten Auftragsabwicklungen zeigen nur Teile eines Auftragsprozesses. Sie reichen aus, um die Störanfälligkeit zu demonstrieren. Die traditionellen Verfahren waren, selbst bei Verbindung von Computer zu Computer, Stand- und Wählleitungen, Datenfernübertragung, bis ca. 1992 kaum Störangriffen ausgesetzt Die moderne Auftragsabwicklung ist ein offenes Scheunentor für Störangriffe von außen. Fast täglich wird berichtet, dass wieder eine Sicherheitslücke entdeckt wurde und vom Anbieter X geschlossen wurde. Firewalls und Antivirenprogramme sind nicht in der Lage, diese Angriffe abzuwehren. Die erkennbaren Angriffe auf PC-Systeme können abgewehrt werden. Viel tückischer sind „Schläferprogramme“, die auf ihren Einsatz warten.

Jeder Einzel- oder Server-PC, der die externe Pflege und Wartung der Programme über das Internet zulässt, kann an jedem Ort und zu jeder Zeit, durch Viren- und Schadprogramme außer Betrieb gesetzt werden. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Methoden, Verfahren, Standards 6. Stapelverarbeitung für betriebswirtschaftliche EDV-Systeme 6.1.2 Lösung

Abschnitt

A

Datei 1 Datei n

Auftrag

Job

Abschnitt

B

Abschnitt

C

Abschnitt

D

Abschnitt

E

Abschnitt

F

Datei 1 Datei n

Ende

System- parameter

Stammdaten

Vorträge

Änderungen/ Bewegungen

Protokolle Abrechnungen Auswertungen

Protokoll-daten

Abrechnungs- daten

A Der Auftrag wird geprüft und alle Stamm- und Vortragsdateien als Arbeitsdateien geladen. B Aus der Bewegungsdatei werden die Änderungen für die Parameter selektiert. In den Protokollen wird die Aktualisierung der Systemparameter dokumentiert. C Aus der Bewegungsdatei werden die Änderungen für die Stammdaten selektiert. In den Protokollen wird die Aktualisierung der Stammdaten dokumentiert. D Die Bewegungen werden geprüft, Vortragsdateien fortgeschrieben und die Abrechungs- und Auswertungsdaten bereitgestellt. In Protokollen werden die Prüfungen, die Fortschreibungen der Vorträge und das Erstellen der Abrechnungs- und Auswertungsdaten dokumentiert. E In diesem Abschnitt werden Abrechnungen und Auswertungen erstellt. F Die Stamm- und Vortragsdateien werden gesichert.

Vor dem Einsatz der Dialogverarbeitung setzte sich die Stapelverarbeitung aus diesen Bearbeitungsschritten zusammen. Diese Verarbeitungsfolge konnte in einem oder mehreren Jobs durchgeführt werden. In der Praxis hat sich die Methode, alle Bearbeitungsschritte in einem Job zusammenzufassen, als die Beste erwiesen. Der Ablauf und der Umfang der Abrechnungen und Auswertungen werden über einen Auftrag direkt vom Anwender gesteuert. Prinzipiell sollten alle Programme, die zu einem bestimmten Zeitpunkt, in einer vorgegeben Reihenfolge durchzuführen sind, in einem Verfahren zusammengefasst werden. Durch die Möglichkeiten des Dialoges wird der Auftrag nicht mehr über ein Formular, sondern über Bildschirm erteilt. Die Pflege der Systemparameter und Stammdaten sind typische Dialoganwendungen, während alle anderen Bearbeitungsschritte weiterhin im Stapel laufen können. So lange Abrechnungen und Auswertungen sicher und richtig zum erforderlichen Zeitpunkt zur Verfügung stehen, können Stapelverarbeitungen durchaus geeigneter sein. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Methoden, Verfahren, Standards 7. Dialogverarbeitung für betriebswirtschaftliche EDV-Systeme 7.2.4 Standardmaske

Anwender: TRCD: Datum : Uhrz : A – richtet sich nach der Kapazität des Bildschirms OK Seite: von: OK Seite: von:

1 3 4 5 5 6 7 2

9

8

10 11 12

Informationen 1 - Systemtext 2 - Transaktionstext 3 - Anwenderkennung 4 - Transaktionscode 5 - Programmkennung 6 - Datum in Form TT.MM.JJJJ 7 - Uhrzeit in Form SS.MM A - zur freien Verfügung

Steuerung und Nachrichten

8 - Programmnachrichten 9 - OK-Code/Kommandofeld 10 - Aktuelle und 11 - maximale Seitenanzahl (nur bei mehrseitigen Masken) 12 - Systemnachrichten

Dieser Maskenvorschlag zeigt, welche Teile einer Maske standardisiert werden können. Es ist für alle Beteiligten vorteilhaft, wenn Informationen immer an der gleichen Stelle der Maske zu finden sind. So führen Schlüsselbegriffe, wie Transaktionscode und Programmkennung, zu einer eindeutigen Identifizierung der Maske. Anwender, Datum und Uhrzeit sind für Problembehandlung und Recherche sehr hilfreich. Eine standardisierte Maskensteuerung, vergleichbar mit einer Gangschaltung im Auto, führt zu einer sicheren, schnellen und daher wirtschaftlichen Bearbeitung von Geschäftsprozessen. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Die

Methoden, Verfahren, Standards 8. Bedienungslogik für betriebswirtschaftliche EDV-Systeme 8.1 Anmeldeverfahren

ADAM

Anwender: TRCD: Datum : Uhrz :

Bitte Anwender-ID und Passwort eingeben Anwender-ID : Passwort : Sprache : Ändern Password Password-Neu: Bestätigen :

OK

ADAM AD03 00004 5 12.03.2011 08.12 Berechtigungsprüfung

J

PA4576901 ********

D

********

********

Anwender: TRCD: Datum : Uhrz :

Bitte Transaktionscode eingeben TRCD: OK

ADAM PA4576901 AD03 00005 5 12.03.2011 08.12 Transaktionsverteilung

J

Anwender: TRCD: Datum : Uhrz : Bitte Transaktionscode auswählen Status TRCD Transaktionstext AF01 Pflege Auftragskopf AF02 Auftragspositionen AF03 Auftragsbestätigung S AF04 Formbriefe KD01 Pflege Kundendaten KD02 Anzeige Kundendaten KD03 Batch-Input Kundendaten KK01 Pflege Vertragsunternehmen KK02 Pflege Kreditkarte KK03 Umsatz Vertragsunternehmen TRCD: OK Seite: von:

ADAM PA4576901 AD03 00006 5 12.03.2011 08.12 Anwendermenü

J

KD01

001 002

? 1. Bildschirmmaske

KD01 haben Sie zuletzt durchgeführt – Auf Wiedersehen

Mit der Eingabe ADAM startet der Anwender die Dialogsitzung. In der ersten Bildschirmmaske wird die Berechtigung geprüft, die Sprache gewählt und das Passwort kann geändert werden.

Der Anwender kennt die Codes der Transaktionen, die er regelmäßig ansteuert. In dieser Bildschirmmaske wird die Berechtigung des Anwenders für diese Transaktion geprüft. Bei positiver Prüfung wird direkt die 1. Bildschirmmaske der Transaktion aufgerufen. Bei negativer Prüfung oder fehlender Eingabe wird das Anwendermenü aufgerufen.

In diesem Menü werden dem Anwender die Transaktionen gezeigt, für die er berechtigt ist. Im Feld Status wird angezeigt, welche Transaktionen gesperrt oder noch in der Entwicklung sind. . Nach Auswahl einer Transaktion aus seinem Menü wird in die Transaktionsverteilung verzweigt. Der Transaktionscode wird mitgegeben und das Senden/Lesen dieser Bildschirmmaske wird dann unterdrückt. Mit der ESC-Taste kann die Dialogsitzung jederzeit beendet werden.


zurück

Rückwärtsplanung Vorwärtsplanung

Methoden, Verfahren, Standards 9. Prozessplanung für betriebswirtschaftliche EDV-Systeme 9.2 Operationsfluss

Abteilung 1 TT.MM.JJJJ

HH.MM


HH.MM


HH.MM


HH.MM


HH.MM


HH.MM


HH.MM

Termin – n Tage 0-----------12-----------0

Termin – 3 Tage 0-----------12-----------0

Termin – 2 Tage 0-----------12-----------0

Termin – 1 Tag 0-----------12-----------0

End- Termin


HH.MM


HH.MM


HH.MM


HH.MM


HH.MM


HH.MM

Termin +2 Tage 0-----------12-----------0

Termin + n Tage 0-----------12-----------0

Termin +1 Tag 0-----------12-----------0

Termin +3 Tage 0-----------12-----------0

Start- Termin

Mit allen beteiligten Abteilungen/Arbeitsstationen werden Endtermine vereinbart, bis wann eine Tätigkeit erledigt sein muss, damit das Operationsziel erreicht wird. Alle weiteren Planungsaspekte, wie Dauer der Tätigkeiten, Kapazitätsberechnungen, Starttermine usw. werden bei der Festlegung der Endtermine berücksichtigt, aber führen nicht zu automatischen Terminverschiebungen. Die Praxis hat bewiesen, dass der Mensch bei der Lösung von Problemen, wie Kapazitätsüberschreitungen, unschlagbar ist. Die Endtermine können fast immer gehalten werden, obwohl dies rein „rechnerisch“ unmöglich scheint. Voraussetzung dafür ist, dass die Engpässe frühzeitig erkannt werden. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

fddddddddddddddddddddddddddddddd

Methoden, Verfahren, Standards 10. Prozesssteuerung für betriebswirtschaftliche EDV-Systeme 10.1.2 RZ-Auftrag

Anwender: TRCD: Datum : Uhrz : Aktion : Abrechnungsdatum: Abrechnungskreis : Text 1 Lastschrift : Jahreswechsel : Umsatzanalyse : Letzte Änderung: durch: OK

Kreditkarten PA4298523

KK21 00443 5 19.01.2012 14.25 RZ-Auftrag Abrechnung KI

J

19.01.2012

Ändern

J

15

N

19.01.2012 12.20 PA4298523

Abrechnung Kreditkarte

Anwender: TRCD: Datum : Uhrz : Abteilung : Aktion: Planungsjahr : Datum von/bis: Hin- Statusmeldung Z Termin F Aktivität Bezeichnung weis Art Datum/Uhrzeit

Z(eile): OK Seite: von:

Operationsplanung PA4298523

OP14 00711 5 19.01.2012 14.30 Terminplan Abteilung

J

19.01/08.00 – 20.01/20.00

0027 FBKI-Betreuung

19.01/09.00

Fertigmelden

001 001

Prüfen Tagesverarb. KI esverabeituuftrag Abr. KI

19.01/18.00

2012

TKK21 RZ-Auftrag Abr. KI

20.01/09.00

A

20.01/18.00

B

19.01/08.45

C1

Prüfen Tagesverarb.KI

D1

RZ-Auftrag Abr. KI

TKK21

Normal

N N

Die Laufvariablen werden vom Kunden/Anwender über eine/mehrere Dialogtransaktion(en) vorgegeben.

Der Fachbereich KI wird im Terminplan auf diese Aktivität hingewiesen.

Diese Form der Stapelsteuerung hat sich bereits vor dem Einsatz von Dialogsystemen in Rechenzentren mit hunderten von Firmenkunden hervorragend bewährt. Die Anforderungen und die Variablen wurden über ein Auftragsformular, Spalteneinteilung im Lochkartenformat, vorgegeben, erfasst und steuerten die Verarbeitung. Die Methode ist weiterhin richtig. Die Änderungen bestehen nur darin, dass das Auftragsformular und der schriftliche Terminplan durch Dialoge ersetzt werden. Der RZ-/Prozessauftrag ist Voraussetzung für eine sichere und kundenorientierte Auftragsabwicklung. Der Kunde/Anwender steuert seine Stapelverarbeitungen. Der einzige Unterschied zur reinen Dialogverarbeitung für den Anwender besteht darin, dass die Ergebnisse zeitverzögert geliefert werden. Alle anderen Jobsteuerungen erreichen nicht diese Zuverlässigkeit. Jede zwischengeschaltete Aktivität ist eine potentielle Störungsquelle. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Methoden, Verfahren, Standards 11. Systementwicklung für betriebswirtschaftliche EDV-Systeme 11.1 Vorgehensmodell

Nein Ja

Bauabschnitt

Ist-Analyse mit

Schwachstellen

Konzeption mit

Simulation

Realisierung

Einsatz

Erfolg

eingetreten

?

Vorgehen - Abgrenzung des Bauabschnittes

- In der Ist-Analyse werden die Stärken und

Schwächen der vorhandenen Verfahren

dargestellt.

- In der Konzeption werden die zukünftigen

Verfahren simuliert und der zu erwartende

Erfolg vorhergesagt

- Nach Präsentation von Problem (IST) und

Lösung (Soll) wird der Bauabschnitt

realisiert und eingesetzt

- Nach Einsatz der Verfahren wird der

angekündigte Erfolg auf den realen Eintritt

kontrolliert

Die Entwicklung von Systemen bei komplexen Informations- und Abwicklungsprozessen ist nur möglich, wenn die Realisierung in Bauabschnitten erfolgt. Der Umfang der Bauabschnitte richtet sich nach der Problematik der Aufgabenstellung und den Auswirkungen auf das Unternehmen. Dieses Vorgehen gewährleistet, dass sich die Prozesse friedlich – evolutionär - verändern. Bereits in der Konzeption kann festgestellt werden, ob die vorhandenen Schwachstellen konzeptionell beseitigt wurden. Die zu erwartenden Erfolge werden vorhergesagt und nach Einsatz auf ihren realen Eintritt kontrolliert. In der Praxis ist es meistens so, dass die einzelnen Bauabschnitte sich überlappen. So befindet sich der eine Bauabschnitt in der Realisierung, während der nächste sich in der Ist-Analyse/Konzeption befindet. Auch können mehrere Projektteams parallel an verschiedenen Bauabschnitten arbeiten. Durch die gezeigten Methoden, Verfahren und Standards ist dies kein Problem. So kann beispielsweise jedes Dialogprogramm an ein anderes Programm „andocken“, da die Programmkommunikation einheitlich geregelt ist. Dieses Vorgehen macht es möglich, dass die Bauabschnitte von kleinen Projektteams realisiert werden können. Großprojekte führen dazu, dass die eigene Projektorganisation und –verwaltung ein Großteil der Kapazitäten bindet und wenig für die eigentliche Aufgabe übrig bleibt. Der Aufwand ist auch nicht von der Anzahl der Kunden, Aufträge, Konten, Kreditkarten, Krankenkarten und Zahlungsterminals abhängig. Die Entwicklung einer Telefonabrechnung für 50 Millionen Kunden muss nicht zwangsläufig aufwendiger sein, als eine für 1 Million Kunden. Ein Projektteam sollte mindestens 2 und möglichst nicht mehr als 4 Mitarbeiter umfassen. Ein erfahrener Entwickler leitet das Team. Er verteilt die Geschäftsprozesse des Bauabschnittes auf seine Mitarbeiter. Dieser Mitarbeiter ist für alle Arbeiten zuständig, von der Analyse bis zum Einsatz. Das heißt nicht, dass er alle Arbeiten selbst ausführen muss. So kann selbst der Projektleiter ein Programm für einen seiner „Untergebenen“ schreiben. Für Geschäftsprozessübergreifende Aufgaben, wie Datenmodell, ist in der Regel der Projektleiter zuständig. Alle Tätigkeiten sollten so zugeordnet werden, dass das bestmögliche Teamergebnis erzielt wird. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Methoden, Verfahren, Standards Praxisbeispiele für betriebswirtschaftliche EDV-Systeme A1 Schloss- und Beschlagindustrie

Ist-Zustand In einem mittelständischen Unternehmen dieser Branche sollte die Auftragsabwicklung für den Geschäftsbereich Schließanlagen wegen mangelnder Rentabilität reorganisiert werden. Täglich mussten ca. 250 Aufträge bearbeitet werden. Ein Auftrag wurde zuerst kaufmännisch geprüft/korrigiert, die Artikelpreise ermittelt und von der Datenerfassung für die maschinelle Verarbeitung in einem Batchverfahren vorbereitet. Die Berechnung neuer Schließanlagen bzw. die Erweiterung erfolgte durch die technische Abteilung. Die technischen Daten der Schließanlagen wurden handschriftlich auf Schließplänen mit verschiedenen Anlagen, wie Schließtabellen, geführt. Diese Verfahren sollten im kaufmännischen Bereich durch ein Standardvertriebssystem und im technischen Bereich durch ein individuelles Berechnungssystem für Schließanlagen optimiert werden. Die Vorstellung war, dass durch Einsatz des Vertriebssystems die Mitarbeiter im Preisbüro und in der Datenerfassung nicht mehr benötigt werden, da die kfm. Sachbearbeiter den Auftrag erfassen und die Preise im System gespeichert sind. Durch das individuelle Berechnungssystem sollte die technische Bearbeitung vereinfacht werden. Die Installation des Vertriebssystems war problemlos, während schon mehrere Versuche ein funktionierendes Berechnungssystem für Schließanlagen zu programmieren gescheitert waren. Ich bekam den Auftrag das Berechnungssystem fertigzustellen. Nach Analyse des Systems habe ich es abgelehnt es zur Produktionsreife weiterzuentwickeln. Ich habe der Geschäftsführung einen anderen Weg vorgeschlagen und die Konzeption für den 1. Bauabschnitt, Speicherung Schließplandaten und Drucken Schließpläne, vorgestellt. Diesem Vorschlag hat die Geschäftsführung zugestimmt. Der Einsatz des Vertriebssystems war eine organisatorische Katastrophe. Die langjährigen Mitarbeiter in der Datenerfassung waren nicht nur schneller bei der Eingabe der Daten, sondern haben auch die Aufträge korrigiert. Die Preisermittlung für Schießzylinder war nicht so einfach wie gedacht. Dies führte dazu, dass täglich nur ca. 180 von 250 Aufträgen bearbeitet wurden. Wegen fehlerhafter Aufträge gab es immer mehr Reklamationen. Die Situation schien schier aussichtslos, als sich herausstellte, dass es ca. 5000 unbearbeitete Aufträge gab. Dieser Rückstand wurde nicht bemerkt, weil Aufträge, die bereits einem Sachbearbeiter zugeteilt waren, nicht als Rückständ gemeldet wurden. Stapelweise bunkerten die Sachbearbeiter diese Aufträge in ihren Schränken. Die Vielzahl der unbearbeiteten Aufträge führte zu steigenden Kundenrückfragen. Die Suche nach Aufträgen war aufwendig weil sie in irgendeinen Stapel schlummerten. Die Mitarbeiter der Datenerfassung waren bereits entlassen und die Mitarbeiter im Preisbüro hatten schon ihre Kündigung in der Tasche. Ich arbeitete mit 2 Mitarbeitern an dem von mir neu konzipierten individuellen Berechnungssystem. Im ersten Bauabschnitt wollten wir die Schließplandaten maschinell verwalten. Auf Wunsch der Unternehmensführung haben wir diese Arbeit unterbrochen, eine Ist-Analyse durchgeführt und eine „Notoperation“ vorgeschlagen.

Realisierung Im 1. Bauabschnitt haben wir in wenigen Tagen eine Auftragserfassung und ein Formbriefprogramm entwickelt und eingesetzt. Alle Aufträge wurden nach Auftragsdatum sortiert, erfasst und ein Formbrief an die Kunden geschickt, mit der Ankündigung einer Lieferzeit von 6 Wochen nach Erfassungsdatum. Die Kundendaten wurden über eine Schnittstelle aus dem Vertriebssystem übernommen. Wir wussten nicht wie die Kunden reagieren. Die meisten Kunden haben die lange Lieferzeit hingenommen und nur wenige wollten einen früheren Termin. Es gab kaum noch Rückfragen und die Auskunftsfähigkeit haben wir gravierend verbessert, indem wir Sachbearbeiter und Status (ERO=eröffnet, RUE=Rückfrage, LAG=Lager, VER=Versand usw.) vermerkten. Im 2.Bauabschnitt wollten wir erreichen, dass unser Auftragsrückstand nicht weiter wächst. Im Schließplan werden die technischen Daten gespeichert, aus denen sich die kfm. Daten ableiten lassen. Die einzelnen Positionen im Schließplan haben wir nach kfm. Gesichtspunkten verdichtet, die erste einfache Preisfindung programmiert und per Batch-Input in das Vertriebssystem eingespielt. So mussten nur noch ca. 20% der Aufträge, später weniger als 1%, von den Mitarbeitern des ehemaligen Preisbüros bearbeitet werden. Dadurch konnten wir erreichen, dass der Rückstand nicht weiter anwächst. © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

Methoden, Verfahren, Standards Praxisbeispiele für betriebswirtschaftliche EDV-Systeme A1 Schloss- und Beschlagindustrie

Im 3. Bauabschnitt wollten wir den Rückstand abarbeiten. Eine Analyse der Aufträge ergab, dass ein hoher Prozentsatz der Aufträge sehr einfach war. Der Kunde bestellt vorhandene Schließzylinder nach oder aus einer Schließtabelle wird eine neue Schließung entnommen. Die Berechnung oder Erweiterung von Schießanlagen kann ansonsten sehr schwierig sein. Ein Test ergab, dass ein neuer Mitarbeiter, ohne Vorkenntnisse, nach kurzer Schulung mindestens 25 Aufträge dieser Art pro Tag bearbeiten kann. Wir haben 4 junge Mitarbeiter(innen) eingestellt und diese haben unsere Annahmen noch überboten. Durch diese Maßnahme und Erweiterung der Systemfunktionalitäten konnten wir in wenigen Monaten den Auftragsstau abarbeiten. Noch während der Abarbeitungsphase haben wir die regelmäßigen Überstunden am Samstag abgeschafft. Entgegen unserer Erwartung stieg die Durchschnittsleistung der Abteilung, insbesondere am Montag. . Während wir die ersten 3 Bauabschnitte, unter hohen Arbeitseinsatz, in wenigen Wochen realisierten, haben wir in den folgenden Jahren Bauabschnitt für Bauabschnitt in kurzen Intervallen, analysiert, konzipiert, realisiert und eingesetzt. Alle konzeptionell prognostizierten Erfolge wurden durch die Praxis bestätigt. Der Geschäftsbereich Schließanlagen war wieder profitabel und wir produzierten schließtechnisch fehlerfreie Anlagen und die Termintreue lag bei über 98%, trotz drastisch verkürzter Lieferzeiten. Zwei Bauabschnitte trugen im besonderen Maße dazu bei, dass die Qualität und Wirtschaftlichkeit erheblich gesteigert wurde. Schließanlagen werden nach pantentierten Verfahren berechnet. Patentiert ist das Profil (seitliche Rillen, Einschnitte usw.), während die Schlüsseleinschnitte allgemein gültig sind, in der Regel 1 bis 9. Bei Berechnung der Anlage kann dem Schließplanrechner ein Fehler unterlaufen. Um diese Fehler zu erkennen wurden die Schließfunktionen jedes Zylinders kontrolliert. Er musste vom eigenen Schlüssel geschlossen werden und von den Gruppenschlüsseln die, laut Schließplan, den Zylinder ebenfalls schließen sollten. Alle anderen dürfen den Zylinder nicht schließen. Je später ein Schließfehler erkannt wird, umso aufwendiger ist die Reparatur. Der größte Aufwand entsteht, wenn der Schließfehler bei der Montage der Schließanlage oder später erkannt wird. Zu den hohen Kosten entsteht auch ein Vertrauensverlust, dessen langfristige Folgen kaum berechnet werden können. Auch wenn der Fehler bei der Kontrolle erkannt wird sind die Kosten sehr hoch. Der Zylinder und die Schlüssel sind Schrott, die Schließung muss neu berechnet werden. Das führt zu Auftragsverzögerung oder der Zylinder muss nachgeliefert werden. Fehler dieser Art stören durch Sonderbehandlung massiv den Betriebsablauf. Die Anregung, ob wir die Schließfunktionen nicht maschinell prüfen könnten, kam von einem besonders fähigen Meister in der Fertigung. Die Schlüsseleinschnitte 1 bis 9 waren kein Problem. Nachdem wir festgestellt haben, dass alle patentierten Profile in ein allgemein gültiges Profil konvertiert werden können, war die Realisierung problemlos. Die Kontrolle haben wir dahingehend erweitert, dass auch alle Einzelschlüssel gegengeprüft haben. Manuell ist es unmöglich, jeden Zylinder dahingehend zu prüfen, ob ein anderer Einzelschlüssel ebenfalls schließt. Die Montage von Schließzylindern erfordert, insbesondere bei mehreren übergeordneten Schlüsseln, eine besondere Begabung. Der Montierer musste anhand der Schlüsseltiefen berechnen, welche Stifte und Plättchen er einsetzen muss, damit alle Schlüssel den Zylinder schließen. Nachdem der Einsatz eines Montageropoters sich als ungeeignet erwiesen hat, haben wir, auf Anregung des gleichen Meisters, den Fertigungsplan für die Montage geändert. Wir haben maschinell die Stifte und Plättchen berechnet, die eingesetzt werden müssen. Vor Realisierung wurde vereinbart, dass die Arbeitsplätze der Montierer(innen) bei gleichem Tariflohn erhalten bleiben.

Schlussbemerkung Die Beschreibung dieses Projektes zeigt, dass nur durch agiles Vorgehen diese Aufgaben gemeistert werden konnten. Ohne die hier im Handbuch beschriebenen Methoden, Verfahren und Standards wäre das notwendige schnelle und sichere Handeln jedoch nicht möglich gewesen. Es zeigt auch, wie Standardsoftware durch individuelle Bausteine effektiv ergänzt werden kann. Es ist in der Regel nicht sinnvoll und auch nicht wirtschaftlich, administrative Bausteine, wie Mahnwesen, selbst zu entwickeln. Wunsch des Eigentümers habe ich, obwohl wirtschaftlich nicht notwendig, die automatische Berechnung von Schließanlagen, wie zuerst geplant, bis zum mittleren Schwierigkeitsgrad programmiert. Diese anspruchsvolle Aufgabe konnte ich nur bewältigen, weil ich inzwischen ein Schließanlagenexperte und das Vertrauen der besonders fähigen Mitarbeiter in der Auftragsabwicklung, insbesondere in der Fertigung, gewonnen hatte. Weitere Fertigungsprozesse hätten automatisiert werden können. Warum sollte man aber gut bezahlte Arbeitsplätze vernichten, wenn es wirtschaftlich nicht notwendig ist? © Franz Mugrauer, D-63110 Rodgau, Germany. All rights reserved

zurück

Methoden, Verfahren, Standards Praxisbeispiele für betriebswirtschaftliche EDV-Systeme A2 Zahlungsverkehrsunternehmen

Ist-Zustand In diesem Unternehmen wurde die Kreditkartenbearbeitung für alle deutschen Banken durchgeführt. Neben dem Geschäftsbereich „Kreditkarte“ wurde das neue Zahlungsverfahren „electronic cash“ aufgebaut. Bei diesem Verfahren kann über ein POS-Terminal (POS = Point of Sale) der Zahlungsverkehr (Gutschrift Händler, Lastschrift Kunde) online abgewickelt werden und sollte das Bezahlen per Scheck und Scheckkarte ersetzen. Bedingt durch die dynamische Marktentwicklung sollten beide Geschäftsbereiche reorganisiert werden. Der Auftrag zur Reorganisation des Kreditkartenbereichs wurde an eine der weltweit führenden Beratungsunternehmen vergeben. Ich bekam den Auftrag mit 2 Mitarbeitern das stark wachsende POS-Geschäft zu reorganisieren. POS-Verfahren 1992 Vom POS-Terminal werden Terminaldaten, Betrag, Bankverbindung, Geheimnummer und weitere Daten an den Autorisierungsrechner geschickt. Nach Genehmigung durch die Bank des Karteninhabers wurde die Zahlung freigegeben. Die Transaktionsdaten wurden gesammelt und einmal täglich über das standardisierte DTA-Verfahren (DTA = Datenträgeraustausch) an die Rechenzentren der Bankenverbände weitergeleitet. Monatlich wurden die Händler mit den angefallenen Gebühren belastet und die Autorisierungsentgelte den Banken gut geschrieben. Für den Kauf oder Miete der POS-Terminals stand ein PC-Verwaltungsprogramm zur Verfügung.

Realisierung Im 1. Bauabschnitt haben wir die Online- und Batchverfahren, außer der Autorisierung, auf einem IBM-Großrechner realisiert. Es wurden nur die vorhandenen Funktionalitäten entwickelt und keine zukünftigen Anforderungen berücksichtigt. Nach den Funktionstests der Programme haben wir die Verarbeitung einen Monat parallel gefahren. Die Stammdatenpflege wurde täglich vor Erstellung der DTA-Daten im Batch-Input-Verfahren nachvollzogen. Bei diesem Verfahren werden alle Programmschritte vollzogen, außer das Senden und Lesen der Bildschirmdaten. So wird gewährleistet, dass die Prüfung und Verarbeitung der Stammdaten identisch mit der manuellen Eingabe ist. Nachdem es bei allen Tagesverarbeitungen keine Abweichungen gab, haben wir die neue Gebührenabrechnung erstellt. Zu unserer Überraschung gab es bei den Gesamtsummen eine geringfügige Abweichung. Wir planten bei einem positiven Test die neue Gebührenabrechnung zu versenden. Auch wenn die Gesamtsummen nur um wenige DM abweichen, können die Einzelabweichungen weitaus höher sein. Wir konnten den Fehler schnell lokalisieren. Beim Abgleich der Stammdaten war ein Gebührenfeld vergessen worden. Nach Korrektur der Stammdaten und Wiederholung der Verarbeitung war der reibungslose Systemwechsel vollzogen. Parallelverarbeitung ist, wenn möglich, die sicherste Methode bei einem Systemwechsel. Anschließend haben wir in wenigen Wochen die Online-Auskunftsfähigkeit verbessert und u.a. ein Formbriefprogramm entwickelt. Im 2. Bauabschnitt wollten wir das PC-Verwaltungsprogramm für Miete und Kauf ablösen, indem wir wiederum im Batch-Input-Verfahren die Vertragsdaten übernahmen. Zu unserer Überraschung fehlten für eine hohe Anzahl von Terminals die Vertragsdaten. Es stellte sich heraus, dass diese Terminals auf dem PC-System nicht erfasst wurden. Nach Erfassung der Vertragsdaten wurden die davon betroffenen Kunden per Serienbrief mit Angabe des Mietrückstandes informiert. Unser Formbriefprogramm haben wir in wenigen Tagen um die Serienbrieffunktion erweitert, indem über diverse Auswahlkriterien Kunden selektiert werden konnten. Die Bearbeitung dieser Rückstände war eine schwere Belastung für die Sachbearbeiter, weil viele Kunden annahmen, dass diese Kosten in den Transaktionsgebühren enthalten sind. Im Rahmen dieser Operation mussten wir mehrfach sehr schnell reagieren. So benötigte der Fachbereich kurzfristig eine Gut-/Lastschrifttransaktion, weil Kunden die Zahlung verweigerten oder Teilbeträge zahlten. Nach Ablösung der Altsysteme haben wir in den folgenden Jahren Bauabschnitt für Bauabschnitt in kurzen Intervallen, analysiert, konzipiert, realisiert und eingesetzt. So wurde das POS- um das POZ-Verfahren (ohne Zahlungsgarantie) erweitert. Wir hatten zeitweise unseren Arbeitsplatz in die Fachabteilung verlegt. So konnte die Zusammenarbeit noch effizienter gestaltet werden. Die Optimierung der Geschäftsprozesse war auch dringend notwendig, denn der Geschäftsbereich wuchs jährlich um mehr als 100%.


Methoden, Verfahren, Standards Praxisbeispiele

für betriebswirtschaftliche EDV-Systeme A2 Zahlungsverkehrsunternehmen

Schlussbemerkung Auch die Beschreibung dieses Projektes zeigt, wie effektiv das agile Vorgehen ist und wie auf ad-hoc auftauchende Probleme reagiert werden kann. Ohne die hier im Handbuch beschriebenen Methoden, Verfahren und Standards wäre das notwendige schnelle und sichere Handeln jedoch auch hier nicht möglich gewesen.

Wir hatten im Laufe der Jahre nebenher wirtschaftlich sehr erfolgreiche und dringend benötigte Geschäftsprozesse im Kreditkartenbereich realisiert. In der Projektsitzung, bei der über die Auftragsvergabe zur Reorganisation der Geschäftsprozesse für die Vertragsunternehmen entschieden werden sollte, haben sich alle Fachabteilungen dafür ausgesprochen, dass wir das Projekt realisieren sollten. Der verantwortliche Geschäftsführer hat sich jedoch für die Unternehmensberatung entschieden, welches den Geschäftsbereich Kreditkarte reorganisiert hatte.

Zukunft Wir hatten im Rahmen der Systemerweiterung um das POZ-Verfahren auf diversen Bildschirmen das KK-Verfahren (KK-Kreditkarte) vorgesehen und die Anzeige vorerst unterdrückt. Zur Auskunft und zur Bearbeitung einer Transaktion ist es unerheblich, ob es sich um eine POS-, POZ-, KK- oder sonstige Zahlungsart handelt. Dahinter verbirgt sich letztendlich immer eine Gutschrift für das Vertragsunternehmen und eine Belastung des Kunden. Das kann heute auch ein Handybesitzer sein. Es macht keinen Sinn, dafür eigenständige Verwaltungssysteme einzusetzen. Für das Vertragsunternehmen wäre es sehr von Vorteil, wenn es immer den gleichen Dienstleister hätte, egal welche Zahlungsart der Kunde nutzt. So wäre es für Karteninhaber von Vorteil, wenn Kreditkartenumsätze sofort auf dem Kontoauszug angezeigt würden. So könnte er Überziehungen vorzeitig erkennen und Missbrauchsfälle schneller entdeckt und weitere vermieden werden. Diese Umsätze werden einfach bei der Berechnung der Kontoüberziehung nicht berücksichtigt. Die Belastung erfolgt, wie heute üblich, erst bei der Kreditkartenabrechnung.


zurück

Documents

Methoden, Verfahren, StandardsIm Gegensatz zu meiner bisherigen Homepage wird nicht mehr das gesamte Handbuch Methoden, Verfahren und Standards gezeigt, sondern je Kapitel ein Ausschnitt