Abbilden einer Konzernstruktur - Strategische Empfehlung zur Vorgehensweise

[dabjoern]

Hallo liebe Mitglieder,
ich möchte Unternehmensdokumente anlegen und sie in einer Konzernstruktur abbilden. In einem Feld eines entsprechenden Unternehmensdokuments stände dann (falls ausgefüllt) folgendes "Mutter / Tochter / Enkel / Urenkel".

Dazu will ich im Unternehmensformular ein Feld mit dem Name des Unternehmens angeben und ein Feld mit dem Name der Mutterunternehmung. Das Tochter-Mutter Verhältnis lässt sich ja noch leicht abbilden. Mir fehlt aber gerade eine saubere Idee, wie ich die Enkel/ Urenkel etc. Beziehung hinbekommen kann.

Beispiel:
1. Ich lege Unternehmen 1 mit dem Namen U1 an. U1 hat keine Mutter, dieses Feld bleibt also leer. Der Konzernname wäre also: "U1"
2. Ich lege Unternehmen  2 mit dem Namen U2 an. U2 ist Tocher von U1. Der Konzernname wäre also: "U1 / U2".
3. Ich lege Unternehmen  3 mit dem Namen U3 an. U3 ist Tocher von U2/ Enkel von U1. Der Konzernname wäre also "U1 / U2 / U3".

In jedem Unternehmensdokument soll es also ein computed field geben, was dann bspw. den String "U1 / U2 / U3" anzeigt. Das Feld soll dann auch in einem View verwendet werden.

Danke für je den Hinweis und jede Hilfe. Wie man merkt, bin ich noch blutiger Anfänger und erstelle das ganze für eine Seminararbeit im Laufe meines Studiums.
Gruß
dabjoern

[Marinero Atlántico]

Wie man merkt, bin ich noch blutiger Anfänger und erstelle das ganze für eine Seminararbeit im Laufe meines Studiums.

Ich sag später noch was zu den anderen Sachen.
Aber bzgl. diesem ganzen noob, ich-bin-Anfänger, I am just trying, etc. hat Ted Neward etwas bemerkenswertes geschrieben:
http://www.neward.net/ted/weblog/index.jsp?date=20050414
(der 2. Eintrag: "Is, or is not. There is no should." )

Ich hab zu oft erlebt wie schlechte Systeme ein negatives Eigenleben mit starker Ausstrahlung in einer Organisation entwickelt hat.
Aus diesem Grunde find ich auch das heutzutage so beliebte "Das System soll das und das abbilden" irreführend.
Das System "ist". Es ist das Interface, über das Business Prozesse gesteuert werden. Es ist nix passives, was lediglich etwas "abbildet".
Sowieso: Das, was es angeblich "abbildet", ändert sich sowieso ständig (Business Requirements). Ein Abbild ist etwas einmal gemachtes und statisches. Eine der wichtigsten Anforderungen an heutige Systeme ist aber gerade die Anpassung an sich verändernde Realitäten.

Morgen dann ein paar Sachen aus meiner Sicht, die u.U. auch verwertbar sind.

Gruß Axel

[koehlerbv]

Meinst Du prinzipiell solch eine Darstellung ?

Bernhard

[dabjoern]

@Axel
Der Beitrag von Ted stellt sicherlich eine interessante Sichtweise dar. Jedoch ist es allgemein weit verbreitet zu sagen, das System soll das und das erfüllen, das und das ausgeben, um nicht zu sagen das und das abbilden. Es stimmt, das "abbilden" zeitpunktsbezogen ist, aber sind in dem Moment nicht auch die Daten statisch und absolut zeitpunktbezogen? Meistens muss doch erst die Veränderung der Realität  wieder im System erfasst werden.

Was ich mit meinem "I'm a fucking newbie" sagen wollte, war lediglich, dass ich die Notes Konstrukte noch nicht tiefgründig genug kenne, um eine leistungsfähige Lösung zu finden. Auch fehlt mir gerade ein netter Denkanstoß für mein Problem. Oder meinst du Axel, ich soll nicht in dieser Richtung denken. Also nicht denken, was es "können soll"? Klär mich auf  (ernst gemeint).

@koehlerbv
Die Abbildung geht sogar noch über meine Anforderungen hinaus. Ich hätte in der View absteigend alphabetisch sortiert und folgende Einträge (Unternehmensdokumente) hätte es, aufbauend auf meinem Beispiel, gegeben:
"U1"
"U1 / U2"
"U1 / U2 / U3"
"U1 / U2 / U3 / U4"
Also ohne Einrückung und immer Anzeige des übergeordneten Unternehmens getrennt durch einen Schrägstrich. Durch alphabetische Sortierung hätten die Einträge ja untereinander so gestanden. Aber deine Abbildung ist eventuell übersichtlicher.
Gruß und danke für Eure (weitere) Hilfe.
Björn

[Marinero Atlántico]

Du kannst diese Darstellung bekommen, indem du in dem Feld, dass in der View angezeigt wird, zwischen den Elementen des Organisationsbaums einen Backslash schreibst (das wars doch oder  ).  Also "U1\U2\U3". Notes macht die von Bernhard gepostete Anzeige in der View dann automatisch.
Vorsicht: In Formelsprache nicht in Skript ist der Backslash auch ein Escape Zeichen. In Formelsprache mußt du also "U1\\U2\\U3" schreiben.

- Gedanken solltest du dir imho auch um das Editieren der Struktur machen. Ein Unternehmen, dass heute unter U2 liegt wird vielleicht morgen unter U7 gehängt.

- Ausserdem sollte das UI sachbearbeiterfreundlich sein. Sachbearbeiter kommen möglicherweise nicht so gut damit klar, wenn sie phonky geek stuff wie solche Strings in Felder eintragen: U1\U2\U3. (mit Backslash).
Das Risiko inkonsistenter Daten ist schon allein dadurch gegeben, wenn einer U1\ U2\U3 in das Feld einträgt (beachte Leerzeichen).
Anfänger neigen gerade bei der Nichtbeachtung von Naturgesetzen wie "Alle Daten, die vom User eingegeben werden, müssen vom System möglichst vollständig validiert werden, bevor sie persistiert werden." zu Fehlern
Eine Struktur "Wert_a\Wert_b\Wert_c" ist nicht so einfach zu validieren. Sie muß extra geparsed werden. Nicht unmöglich aber vielleicht gibt es elegantere Wege.
Eventuell könntest du dir Gedanken darüber machen, dass dieser String mit den Backslashes nur zur Anzeige generiert wird und auf einem Datenmodell beruhen, in dem die einzelnen Werte z.B. als einzelne Elemente eines Arrays gespeichert sind.

[OFFTOPIC]:

aber sind in dem Moment nicht auch die Daten statisch und absolut zeitpunktbezogen?

Boah Ey. Die Aussage Daten sind zeitpunktbezogen hört sich für meine Ohren echt krass an.
Warum speichern wir dann eigentlich Daten in Datenbanken, wenn sie absolut zeitpunktbezogen sind?
Warum lassen wir sie nicht einfach als Objekte im System und geben die Daten jeden Morgen neu ein, wenn wir den Rechner neu starten?
Daten sind Aktivwerte.
Zur Sammlung, Speicherung und Strukturierung der Daten wurde in das System investiert.
Daten werden gesammelt und strukturiert, damit sie in der Zukunft nutzen stiften.
Sammlung und Speicherung von Daten ist imho deshalb alles andere als zeitpunktbezogen, sondern eine Investition in die Zukunft.
Sie stiften Nutzen in t(1...n).

Schneller organisatorischer, strategischer und prozessmässiger Wandel ist aus meiner Realitätswahrnehmung zur Zeit keine Schlagwörter sondern Realität. Um Risiken, dass Daten und Syteme in Folge des Wandels wertlos werden vorzubeugen, ist es imho wichtig, dass sich Systeme mit geringen Aufwand an diese anpassen lassen. Datenstrukturen sollten auch so designed sein, dass sie ihren Wert behalten.

Meistens muss doch erst die Veränderung der Realität  wieder im System erfasst werden.

Es gibt da von System zu System große Unterschiede, inwieweit sie an veränderte Realitäten adaptiert werden können.
Natürlich kann man nicht jeden Wandel voraussehen, aber das Potential der Möglichkeiten zur Minimierung von Kostenrisiken ist größer als oft genutzt.

[/OFFTOPIC]
Ich weiss, dass das Offtopic ist. Mir fällt das nur auf und ich bin gegen dieses Wort.

[Marinero Atlántico]

Also nicht denken, was es "können soll"? Klär mich auf  (ernst gemeint).

Ich schreib in Requirements auch nicht "Das System soll ...".
Das hört sich so nach "Die Steuern sollen gesenkt werden... . ", "Die Bürokratie soll gesenkt werden..." oder "Die Aktien sollen steigen...". Ich schreibe: "Das System macht...".
Was bedeutet dieses "soll". Ich habe die besten Intentitionen, aber über das was schliesslich rauskommt, hab ich im Grunde weder Kontrolle noch Verantwortung. Mehr so postmodernistische Beliebigkeit.
Wenn ich mich recht erinnere, soll man so auch nach der Theorie Requirements formulieren.
Schlag heute abend bei Larman nach.

Axel

[animate]

Passt jetzt nicht in das Domino-Entwicklungsforum, ich sehe aber Aufklärungsbedarf, deswegen poste ich das hier jetzt mal.

Ich habe ja mal in einer Firma gearbeitet, die auf Anforderungen und alles drum rum spezialisiert ist. Aus meiner Erfahrung von dort kann ich sagen, dass eine Standardanforderung wie folgt lautet:

Das System soll dem Benutzer x die Möglichkeit bieten, y zu tun.
The system shall provide the user x the possibility to do y.

Das "soll"/"shall" klassifiziert dabei die Anforderung als Pflicht-Anforderung, die auf jeden Fall realisiert werden muss.
Im Gegensatz dazu stehen z.B. sollte/should für eine Empfehlung, die unter Umständen ignoriert werden kann, oder kann/may als Kennzeichnung für ein optionales Requirement.

Das soll ist also als Forderung zu sehen - wir sind ja schließlich auch bei einer Anforderung an das System, das gebaut werden soll.

@Axel: falls du dich für diese Thema interessierst, empfehle ich statt Larmans Buch (ich vermute das OO Buch) das meiner Ex-Chefin & Co-Autoren. Die sind ziemlich anerkannte Spezialisten auf dem Gebiet.

[Semeaphoros]

Ich kann da Thomas nur zustimmen, in jeder Hinsicht, einerseits gehört das Thema hier nicht hin, andererseits ist es sprachlich tatsächlich so, wie Thomas das formuliert. "Soll" im Zusammenhang einer Anforderung sagt genau das aus, man erwartert vom System, dass es diese Bedingung erfüllt, da man aber nicht genau weiss, wie die Realisation ausschaut, wird das in einer konjunktivistischen Umschreibung angedeutet, und das ist sprachlich korrekt. Der mitschwingene Konjunktiv, und damit der Ausdruck der Unsicherheit macht Dich, Axel, wohl stutzig. Problem ist, wogegen die Unsicherheit ausgedrückt wird, und da hast Du, Axel, wohl eine falsche Interpretation im Kopf.

[animate]

Ich sehe bei einem Satz wie "Du sollst..." keinen Konjunktiv mitschwingen. Das ist für mich Imperativ. Oder?

[Marinero Atlántico]

Ja ok. Ich sehe es ein, dass man das so interpretieren kann. Trotzdem ist bei vielen Requirements, Problem-Ticket-Einträgen, Meeting-Berichten, etc. meiner Meinung nach sprachlich etwas im argen.
Und aus meinem Erleben wird das "soll" oft im Sinne einer Art des "keine klaren Aussagen treffen" benutzt. Ich bemühe mich in diesem Jahr ganz bewußt in projektbezogenen Texten um sprachliche Einfachheit und Klarheit (auch wenn klare Aussagen gegen mich verwendet werden können). Es haben sich schon Leute positiv geäußert. Und zwar der First Level Support.
Ich find schon das dies in ein Entwicklungsforum gehört, aber man kann das unterschiedlich sehen. Ich lösche Postings, wenn ihr das wollt.

Gruß Axel

[Semeaphoros]

Thomas, formal ist das Indikativ (nicht Imperativ), da hast Du Recht, der "mitschwingende Konjunktiv" (eine von mir gebildete Bezeichnung) kommt durch die Semantik des Wortes "sollen" zustande. Sprache ist vielseitig und hat fast immer mehrere Wege ans Ziel, so kann das Verb "sein" einen Konjunktiv oder Imperativ auch umschreiben mit "soll sein" oder gar "muss sein". In dieser Art der Verwendung werden sollen und müssen ja dann auch als "Modalverben" bezeichnet, sie verändern die Modalität des Hauptverbes, ohne dass dieses in seiner Form den Modus wechselt. (Wow, eine so klare Erklärung, was ein Modalverb ist, hatte ich bisher noch nie gehabt  )

Axel: Stimmt, dass die Sprache in den von Dir aufgezählten Textbereichen häufig völlig vernachlässigt wird. Und es stimmt auch, dass sich viele Menschen (auch in anderen Texten) gerne hinter unklaren und unscharfen Formulierungen versuchen zu verstecken. Wie das funktioniert und wieso das (unter anderem) mit dem Verb "sollen" funktioniert, lässt sich aus obiger Antwort an Thomas ableiten, trifft aber im hier diskutierten Fall tatsächlich nicht zu. Konjunktiv oder seine Umschreibung hat in Requirements durchaus seine Berechtigung, da man ja über etwas nicht existierendes spricht und daher ausdrücken darf, dass man nicht weiss, ob sich das so realisieren lässt oder nicht. Die Unschärfe ist hier also durchaus angebracht.

[eknori]

  wie lautete noch gleich das Thema ?? Möglicherweise weiß es der Eine oder Andere und kann dorthin zurückkehren ...

[Mandalor]

@dabjoern:

sollen die Firmen nur einmal angelegt werden, oder soll es auch möglich sein, Firmen umzuhängen?

[dabjoern]

Hallo liebe Leute,
irgendwie bekomme ich keine Benachrichtigung, wenn Antworten gepostet werden (obwohl ich es eingeschaltet habe). Landen auch nicht im Spam. Sehr komisch. Sonst hätte ich mich hier auch mal ein wenig beteiligt.

Ich äußere mich jetzt nicht zu dem Off-Topic, habe aber euere Diskussion gelesen und mir den ein oder anderen Punkt vermerkt.

Ich möchte mal kurz den Ablauf darstellen:
(1) Der Nutzer legt ein neues Unternehmensdokument an und vergibt eine Kurzbezeichnung, z.B. U1.
(2) Er legt ein weiteres Unternehmen (U2) an und vergibt wieder eine Kurzbezeichung. Diesmal möchte er jedoch diesem neuen Unternehmen das Unternehmen aus Schritt 1 als Mutter zuordnen. Dazu habe ich eine Dialogbox angelegt, die alle Kurzbezeichnungen der angelegten Unternehmen enthält. Keine Mehrfachauswahl, nur Vorgabewerte zulässig. Ich wähle also als Mutter U1
(3) Wenn ich jetzt in die View schaue, sehe ich einen Eintrag für U1 und einen weiteren für U2 in der Form: "U1 / U2" oder halt verschachtelt, so wie oben vorgeschlagen.
(4) Ich lege ein neues Unternehmen an (U3). Es soll Tochter von U2 und Enkel von U1 sein. Ich wähle also in der Dialogbox U2 als Mutter. In der View steht dann folgendes:
U1
U1 / U2
U2 / U3

Das ist mein Problem. Ich hätte gerne, dass es so aussieht:
U1
U1 / U2
U1 / U2 / U3

Ich will einfach nur, dass die Infos über übergeordnete Unternehmen im Moment der Auswahl zur Verfügung stehen. Quasi sobald ich U2 als Mutter von U3 wähle, soll die Info zur Verfügung stehen, dass U1 die Muter von U2 ist.

Ich hoffe , ich hab das jetzt einigermaßen klar ausgedrückt.

@Mandalor
Ich will die Unternehmen nur einmal anlegen. Ich dachte, es wäre gut, nur die Mutter jeweils anzugeben. So kann man IMO recht einfach Strukturänderungen im Konzern aktualisieren.

Gruß
Björn

[Mandalor]

wenn du U3 unter U2 unterordnest, dann lies doch einfach das Feld in U2 aus, indem drin steht U1/U2 und schreib /U3 dahinter --> u1/u2/u3

Wenn du aber Firmen auch umhängen möchtest wird komplizierter (habe das selbe schon mal gemacht)

[Marinero Atlántico]

Das ist eigentlich mit einer ganz einfachen Map* in Form einer (versteckten) Ansicht zu erreichen.
Du hast eine View mit:
1. Spalte sortiert: Bezeichner des Unternehmens
2. Spalte: Struktur-Feld

z.B. stände in dieser Ansicht dann für U2::

1. Spalte: U2 (Bezeichner)
2. Spalte: U1/U2 (Strukturwert).

Du kannst den Wert der 2. Spalte über den Key des Unterzeichners per simplen DB-Lookup herausbekommen.

Also: versteckte Ansicht mit Viewauswahl der entsprechenden Form (die Unternehmensdaten) und die Spalten wie oben beschrieben. Sortierung in erster Spalte ist wichtig. Dann darauf ein @DBLookup oder ein view.getDocumentByKey (String keyErsteSpalte).


Gruß Axel

[dabjoern]

Hallo,
ich habe es jetzt hinbekommen. Ich habe es wie vorgeschlagen mit einer unsichtbaren View gemacht. 2 Spalten: Parent und Consolidated Name (Strukturname). Im Company Form habe ich ein Feld, dass berechnet wird und folgende Formel enthält:

Code

query := ParentCompany;
@If( query = "" ; ConsolidatedCompanyName := CompanyName ; ConsolidatedCompanyName := @DbLookup("":"NoCache" ; "" ; "($ConsolidatedCompany)" ; query ; "ConsolidatedCompanyName") + "\\" + CompanyName )

Das Feld ParentCompany wird per DialogList ausgefüllt. Siehe oben.

@Mandalor
Jetzt verstehe ich auch deinen Einwand bzgl. des Umhängens. Verschiebe ich eine Tochter an die Spitze, werden erst deren Töchter aktualisiert, wenn man deren Unternehmensdokument editiert. Was wäre denn da eine Lösung für (nur Interessehalber - hat keine Priorität)? Macht man solche Jobs mit einem Agent?

MfG
Björn

[koehlerbv]

Das gebräuchliche Verfahren ist folgendes: Nach dem Öffnen (PostOpen) "merkt" man sich den Status der Hierarchiepfades. Vor dem Speichern (QuerySave) prüft man, ob der Hierarchiepfad verändert wurde. Wenn ja, werden sofort alle abhängigen Dokumente durchlaufen und auch dort der Hierarchiepfad angepasst.
Dieses Verfahren setzt natürlich voraus, dass zumindest innerhalb eines Hierarchiepfades alle Benutzer gleiche (Schreib-)Rechte haben.

Bernhard