Orgmanagement Transportieren - Sinnvoll?

Re: Orgmanagement Transportieren - Sinnvoll?

Es kommt darauf an... ;)
Die Orgeinheiten werden nicht transportiert in dem Sinne, sondern über ALE verteilt.
Und ja, kann man machen, wenn man das möchte. Zum Verteilen gibt es die Transaktion PFAL.

Bedenken muss man dabei, glaube ich, dass die IDs nicht 1:1 übertragen werden, sondern anhand des Nummernkreises entsprechend neu angelegt werden.
Dabei muss man aufpassen, dass sich die Nummernkreise der Systeme nicht überschneiden, bzw. muss man sich einigen, wo die Orgstruktur gepflegt wird.
Ich meine, es gibt einen Exit, wo man die zu vergebende Nummer beeinflussen kann.

Zusätzlich sind Orgstrukturen u.U. nur sinnvoll, wenn auch Mitarbeiter an den Stellen eingesetzt sind. Das heißt, diese müssen auch repliziert werden. und dann wird es evtl. schon wieder kompliziert (Datenschutz etc.)

Ist alles nicht ganz ohne. Lohnt sich aber, wenn man die Orgstrukturen ausgiebig nutzt.

Re: Orgmanagement Transportieren - Sinnvoll?

Das mit dem Report ist doch eine gute Idee! Ich wusste nicht, dass es den gibt.
Sinnvoller fände ich in dem Fall, dass die Orgstruktur im P definiert und dann von dort ins Q und E transportiert wird.
Was spricht denn aus deiner Sicht gegen den Transport?

Re: Orgmanagement Transportieren - Sinnvoll?

Also ganz ehrlich - ich finde den Transport des Orgmanagements über den normalen Transportweg aus dem Dev widersinnig.

Orgmanagementdaten sind eine Form von Stammdaten und sollten als solche von den entsprechenden Sachbearbeitern im Prod gepflegt werden. Sachbearbeiter ins Dev zu schicken, damit sie dort die OM-Pflege erledigen und womöglich noch mit Transportaufträgen hantieren, widerspricht den Prinzipien eines vernünftigen Produktivbetriebs.

Den Report RHMOVE30 kenne ich auch. Sowas nimmt man, wenn man beispielsweise den Qualikatalog im D pflegt. Das finde ich schon bedeutend sinnvoller, denn den Qualikatalog kann man durchaus als eine Form von Customizing betrachten. (Je nach Firmengegebenheiten kann man aber auch vertreten, ihn im Prod zu pflegen.)

Den Wunsch, das Orgmanagement auch im Q - eventuell auch im Dev - vorzuhalten, um besser testen zu können, kann ich nachvollziehen. Dafür gibt es IDOCs, die man entsprechend verteilen kann. Die andere, weit verbreitete Alternative, um sowas zu erledigen, ist Clone&Test von Accenture (was allerdings nicht ganz billig, aber sehr nützlich ist).

Transportwege zu vergewaltigen und aus dem Prod in die vorgelagerten Systeme zu transportieren bin ich kein Fan von. Das sollte auf seltene Ausnahmefälle beschränkt bleiben.

Re: Orgmanagement Transportieren - Sinnvoll?

Orgdaten und Klassifizierung sind für mich ein Zwischending aus "Stammdaten" und "Customizing". Vom Typ her sind es Stammdaten, weil diese in jedem System separat gepflegt werden können müssen. Von der Anwendung her sind sie jedoch eher starr

In größeren Unternehmen (jedenfalls in denen, in denen ich gearbeitet habe) sind Orgdaten alles andere als starr. Da werden alle Augenblicke Abteilungen eröffnet, andere geschlossen und wieder andere im Rahmen innerbetrieblicher Reorganisation umgehängt. Damit sind das für mich lupenreine produktive Stammdaten. Von Planstellen ganz zu schweigen.

Das Einrichten der ALE Verteilung ist, wie gesagt, nicht ganz ohne. Der Aufwand für die Einrichtung steht in kaum einem Verhältnis dazu, zweimal im Jahr Orgdaten aus dem Prod ins Q zu transportieren.

Das macht man einmal und hat es dann ordentlich. Einen zweiten Transportweg in inverser Richtung einzurichten oder alternativ Transportdateien auf Unix-Ebene durch die Gegend zu kopieren und in Transportqueues einzuhängen ist auch nicht ganz ohne. Und wenn man PY macht, dann braucht man tendenziell die Orgdaten sogar - wenigstens - monatlich frisch. Ich kenne das so, dass man dann jeden Monat den ganzen Datenbestand ins Q klont und dort die Abrechnung laufen lässt. Dann bekommt man immer eine Liste mit Fehlern, aufgrund derer die Abrechnung auf die Nase gefallen ist, fixt diese im P und rechnet den Monat dort dann aalglatt ab. An der Stelle bewährt sich dann Clone&Test.