Mein Name ist Ulrich Fuchs, ich unterstütze als freier Berater Anwenderunternehmen und Beratungshäuser in allem, was im Umgang mit dem ERP-System "Infor LN" und seinen Vorgängerversionen (Baan IV, Baan V) so an Aufgaben anfällt. Ich bin Projektleiter, Berater und Softwareentwickler, und weil ich alle drei Rollen tatsächlich beherrsche, bin ich der Joker immer dann, wenn's anspruchsvoll wird.

Weil Neuigkeiten, über die ich so stolpere, vielleicht auch für andere interessant sind, gibt's dieses Blog. Meine Kontaktdaten finden Sie unter
www.ulrich-fuchs.de.



Donnerstag, 12. November 2015

Standard-Tabellen anpassen?

Ein Kollege hat mich vor ein paar Tagen nach meinem "Königsweg" gefragt, wenn es um Anpassungen im Bereich des Data Dictionaries geht. Angenommen, man braucht weitere Felder im Artikel- oder Kundenstamm, dann hat man heute drei Alternativen:

a) Standard-Tabelle in die Anpassungs-VRC ziehen und erweitern

b) Zusatztabelle definieren und dazu lesen

c) Customer defined fields nutzen.


Hier meine Strategie:

Wenn ich Development auf dem Kundensystem habe, ziehe ich die Tabellen hoch und erweitere sie. Wenn nicht, sollte man customer defined fields nutzen, in der neuesten Version tun dies wohl ausreichend gut (habe sie aber selbst noch nicht genutzt, weil meine Kunden in der Regel eine Development-Umgebung haben. Die gehört für mich ohnehin zur Grundausstattung).

Customer Defined Fields haben zwar den Vorteil, bei Featurepack-Wechseln keine Arbeit zu machen. Aber so viel Arbeit sind geänderte Standardtabellen auch nicht, und man hat die bessere Administrationsumgebung (kann die Tabellen mit PMC vom Test- auf den Echtrechner kontrolliert ausliefern, hat nicht noch eine zweite Stelle, an der Anpassungen verborgen sind, an die man denken muss, etc).

Früher (zu Baan-IV-Zeiten) hatten wir alle ja panische Angst vor einem "Reconfigure Table". Noch vor zehn Jahren war das furchtbar instabil, und wenn einem der Reconfigure auf dem Kundenstamm oder Artikelstamm abgeschmiert ist, war der gemütliche Abend gelaufen. Daher kommt glaube ich bei vielen Beratern, gerade bei denen, die länger dabei sind, das Zögern und Zaudern, solchen Standardtabellen kundenspezifische Felder hinzuzufügen. Weil man immer auf den Reconfigure angewiesen ist.

Nur zwei Bemerkungen dazu: Erstens: Der Reconfigure-Lauf ist heute wesentlich stabiler und in der Regel über ein ALTER-TABLE-Statement an die Datenbank ausgelagert. Da bleibt man nicht mehr mit ner halb vollständigen ASCII-Datei und ner gedroppten Tabelle liegen. Und zweitens: Auch Cutsomer Defined Fields benötigen einen Reconfigure. Sie sind zur Laufzeit nichts anderes als normale Tabellenfelder in der Kunden-VRC, sie werden nur in einem zweiten Topf verwaltet.

Aber ich behaupte, dieser zweite Topf ist eigentlich nicht notwendig. Eine auf herkömmliche Weise geänderte Tabelle ist im Data Dictionary explizit kommentiert. Man kann ein diff machen und sieht, welche Felder ggf. ergänzt werden müssen, wenn eine neue Solution kommt. Ich hab mal bei einem Kunden alle Data-Dictionary-Anpassungen (ca 20 geänderte Tabellen) im Rahmen eines Featurepackwechsels in ca 1,5 Stunden mit dem neuen Standard zusammengefahren. Das geht wirklich schnell von der Hand.

Auf keinen Fall sollte man Zusatztabellen definieren ("Rucksacktabellen" oder "Huckepacktabellen", wie wir die Dinger früher nannten), die den Primärschlüssel irgendeiner Standardtabelle haben und dann die Zusatzfelder, die man da gerne noch hätte. Die muss man nämlich mit Programmcode in die normalen Sessions reinhängen. Früher war das richtig Hölle. Inzwischen gibt es zwar die Funktionalität der "Secondary Tables", das macht's einfacher, aber man muss dennoch Standard-Skripte anpassen. Und das ist eben ziemlich wartungsunfreundlich, insbesondere was das Einspielen von Solutions angeht (die ja selten neue/geänderte Tabellendefinitionen, aber häufig geänderte Programmskripte mit sich bringen). Und man braucht ne Sourcecodelizenz. Auch zu der rate ich ja aus diversen Gründen immer ganz dringend, aber ne Auster kann im Hinblick auf Verschlossenheit diesbezüglich von Infor noch viel lernen.

Mittwoch, 4. November 2015

Journalisten.

Man wundert sich ja schon, was so manche Schreiberlinge sich aus den Fingern saugen. Infor ein skandinavisches Unternehmen? Ich find's schön, dass Infor beim "Clash of the Titans" dabei ist.

Der Artikel referiert eine Studie, die ein paar Vergleiche zwischen den Systemen vornimmt. Allzuviel würd ich auf solche "Studien" ja nie geben, zu oberflächlich sind sie gemacht, und zu sehr sind die Kennzahlen durch's Marketing gedreht, als dass man sie für bare Münze nehmen sollte. 24% der Infor-Kunden nutzen "ERP-Module" aus der Cloud? Ein "ERP-Modul" ist viel, ERP aus der Cloud ist's jedenfalls nicht. Dennoch freut's mich, dass Infor insgesamt ziemlich gut abschneidet.

Die mit einem Körnchen Salz zu genießende Abhandlung kann hier bei Panorama Consulting angefordert werden.