So, dieses Blog zieht zum Jahreswechsel um! Diese von google bereitgestellte Plattform nervte mich schon länger mit eingeschränkten Möglichkeiten, und ich habe noch ein bisschen mehr vor als hier.
Ab sofort finden Sie Nachrichten, Tips und Wissenswertes rund um Infor LN im neuen Blog
unter http://all-in-for-erp.com/de/blog/
Es gibt einen sauberen RSS-Feed zum Abonnieren, und auch einen Newsletter, in den Sie sich gerne eintragen dürfen. Über den kommen dann Hinweise zu wichtigen neuen Artikeln, und diverse andere Informationen rund um All in for ERP. Insbesondere ist da gerade ein Podcast zum Thema ERP und ERP-Beratung in der Entstehung. Sobald die ersten Folgen online gehen, wäre das zum Beispiel eine Information, die ich über den Newsletter verteilen würde. Schauen Sie sich's an, bookmarken Sie's, abonnieren Sie's, es lohnt sich!
Es dankt für Ihre treue Leserschaft an dieser Stelle
Ihr
Ulrich Fuchs
Sonntag, 3. Januar 2016
Sonntag, 13. Dezember 2015
Und gleich noch ein paar Jobangebote
Jetzt drubbelt sich's gerade:
Die IKS sucht einen Inhouse-Infor-LN Berater/Softwarentwickler nach Filderstadt.
Und Pharmatechnik dito einen Inhouse-Berater ERP/CRM nach Starnberg.
Und Messer Information Services einen Anwendungsbetreuer Controlling/Finance nach Groß-Umstadt.
Die IKS sucht einen Inhouse-Infor-LN Berater/Softwarentwickler nach Filderstadt.
Und Pharmatechnik dito einen Inhouse-Berater ERP/CRM nach Starnberg.
Und Messer Information Services einen Anwendungsbetreuer Controlling/Finance nach Groß-Umstadt.
Und noch ein Stellenangebot für Infor ERP LN
Diesmal von der Physik-Instrumente GmbH, als Infor LN Anwendungsbetreuer in Karlsruhe.
Dienstag, 8. Dezember 2015
Diverse Leute mit Infor-LN/-Baan-Kenntnissen von Liebherr gesucht
Liebherr sucht momentan ganz kräftig,
einen Anwendungsentwickler nach Ochsenhausen
einen Juniorberater Logistik nach Oberopfingen
und einen Logistik-Berater nach Oberopfingen
und einen Sales-Berater nach Oberopfingen
einen Anwendungsentwickler nach Ochsenhausen
einen Juniorberater Logistik nach Oberopfingen
und einen Logistik-Berater nach Oberopfingen
und einen Sales-Berater nach Oberopfingen
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.
a) Standard-Tabelle in die Anpassungs-VRC ziehen und erweitern
b) Zusatztabelle definieren und dazu lesen
c) Customer defined fields nutzen.
Hier meine Strategie:
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.
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.
Freitag, 30. Oktober 2015
Infor's Online-Hilfe online
Infor hat schon vor einigen Monaten still und leise einen Schritt gemacht, den die anderen großen ERP-Anbieter auch schon getan haben: Nämlich die Anwenderdokumentation der Software frei zugänglich ins Web zu stellen.
Ich kann gar nicht sagen, wie sehr mich dieser Schritt gefreut hat. Erstens, weil damit die leidigen Fragen auf Baanboard aufhören, bitte irgendwelche urheberrechtliche geschützen Unterlagen zugeschickt zu bekommen. Zweitens aber vor allem, weil es ein weiterer Schritt weg von der sinnosen Geheimniskrämerei um "intellectual property" ist, den Infor irgendwie aus der Baan-Ära mit übernommen hat.
Ich bin ja sehr der Meinung, dass in der IT der möglichst großherzige Austausch von Information mit allen Stakeholdern zentral ist, um Marktanteile wenigstens zu halten. Und das sind eben nicht nur die Herstellermitarbeiter und die Kunden, sondern alle, die mit und an und rund um das Produkt beruflich zu gange sind. Ich bin felsenfest überzeugt, dass sich Marktanteile dann vergrößern, wenn man es schafft, ein "Ökosystem" rund ums eigene Produkt aufzubauen, weil einem dieses Ökosystem im Vertieb hilft zu zeigen, dass man zu den großen Mitspielern gehört. Das ist leider der Punkt, an dem Infor im Gegensatz zu anderen Anbietern bis heute stark hinterher hinkt. Aber, wie gesagt, die Dokus mal frei auszuteilen, ist schon mal ein weiterer Schritt in die richtige Richtung.
Insofern, für alle, die diesen Link noch nicht in den Bookmarks haben, nehmt ihn da rein. Und RTFM, bei Gelegenheit.
docs.infor.com
Dort auf Infor LN, und man hat die Online-Dokus zu 10.3, 10.4 und der aktuell nur als Cloudversion verfügbaren 10.4.1.
Leider nicht für alle Versionen in allen Sprachen, aber das, was da ist, ist in der Praxis wirklich ausreichend: Für 10.3 gibt es die Online-Hilfe auf Deutsch, Englisch und eine Reihe weiterer Sprachen, für 10.4 nur auf englisch. Für 10.4.1., zwar auch nur auf englisch, aber immerhin, zusätzlich den kompletten Satz der pdf-Anwenderhandbücher.
Ich kann gar nicht sagen, wie sehr mich dieser Schritt gefreut hat. Erstens, weil damit die leidigen Fragen auf Baanboard aufhören, bitte irgendwelche urheberrechtliche geschützen Unterlagen zugeschickt zu bekommen. Zweitens aber vor allem, weil es ein weiterer Schritt weg von der sinnosen Geheimniskrämerei um "intellectual property" ist, den Infor irgendwie aus der Baan-Ära mit übernommen hat.
Ich bin ja sehr der Meinung, dass in der IT der möglichst großherzige Austausch von Information mit allen Stakeholdern zentral ist, um Marktanteile wenigstens zu halten. Und das sind eben nicht nur die Herstellermitarbeiter und die Kunden, sondern alle, die mit und an und rund um das Produkt beruflich zu gange sind. Ich bin felsenfest überzeugt, dass sich Marktanteile dann vergrößern, wenn man es schafft, ein "Ökosystem" rund ums eigene Produkt aufzubauen, weil einem dieses Ökosystem im Vertieb hilft zu zeigen, dass man zu den großen Mitspielern gehört. Das ist leider der Punkt, an dem Infor im Gegensatz zu anderen Anbietern bis heute stark hinterher hinkt. Aber, wie gesagt, die Dokus mal frei auszuteilen, ist schon mal ein weiterer Schritt in die richtige Richtung.
Insofern, für alle, die diesen Link noch nicht in den Bookmarks haben, nehmt ihn da rein. Und RTFM, bei Gelegenheit.
docs.infor.com
Dort auf Infor LN, und man hat die Online-Dokus zu 10.3, 10.4 und der aktuell nur als Cloudversion verfügbaren 10.4.1.
Leider nicht für alle Versionen in allen Sprachen, aber das, was da ist, ist in der Praxis wirklich ausreichend: Für 10.3 gibt es die Online-Hilfe auf Deutsch, Englisch und eine Reihe weiterer Sprachen, für 10.4 nur auf englisch. Für 10.4.1., zwar auch nur auf englisch, aber immerhin, zusätzlich den kompletten Satz der pdf-Anwenderhandbücher.
Abonnieren
Posts (Atom)
Posts
