Wie organisiert bzw. nummeriert/benennt ihr eure Jobs?

[Microboy]

Wir überlegen ob wir unsere Agentursoftware wechseln – von QuoJob zu HQ. Allerdings bietet HQ bei der Nummerierung der Jobs nur einen fortlaufenden Nummernkreis an. In QuoJob nutzen wir bisher einen Nummernkreis pro Kunden da auch alle Jobs eines Kunden in dem jeweiligen Kundenordner liegen. In QuoJob können auch Unterjobs angelegt werden was in HQ nur über Umwege möglich ist ... Wir müssen nun abwägen ob wir mit der kompletten Neuorganisation unserer Jobs leben könnten oder nicht.

 

Hier zur Verdeutlichung mal Beispiele ...

 

QuoJob

Kundenkürzel_fortlaufende Nummer_Jobname

AA_0001_Website

AA_0002_Kampagne_XYZ

AA_0002-1_Kampagne_XYZ_Konzeption

AA_0002-2_Kampagne_XYZ_Broschüre

BB_0001_Postkarte

FF_0001_DVD_XYZ

 

HQ

fortlaufende Nummer_Kundenkürzel_Jobname

0001_AA_Website

0002_BB_Postkarte

0003_AA_Kampagne_XYZ

0004_AA_Kampagne_XYZ_Konzeption

0005_FF_DVD_XYZ

0006_AA_Kampagne_XYZ_Broschüre

 

In meiner Zeit als Freelancer habe ich in verschiedenen Agenturen mit beiden Ordungsstrukturen gearbeitet und beides hat seine Vorteile. Wie organisiert ihr eure Jobs und weshalb?

 

[Gast bertel]

Wir machen das so wie ihr bisher auch: Kundenkürzel_fortlaufende Nummer_Jobname

Unterjobs werden nur als Ablage auf dem Server angelegt, um den Überblick zu behalten. In der Agentursoftware wird die Nummer pro Job vergeben.

 

Eine Nummerierung wie in HQ würde uns in den Wahnsinn treiben, weil Kunden durchmischt werden.

[Microboy]

vor 38 Minuten schrieb bertel:

Eine Nummerierung wie in HQ würde uns in den Wahnsinn treiben, weil Kunden durchmischt werden.

Das ist auch unser Problem. Mich wunder nur, dass HQ diese Funktion nicht anbietet. Die Nachfrage ist anscheinend nicht groß genug ...

 

[Gast bertel]

Dann wär das für uns ein klares Ausschlusskriterium.

[Microboy]

Problem ist, dass QuoJob an vielen Stellen nicht gut funktioniert oder Funktionen gar nicht vorhanden sind. Dazu kommt der miese Support und relativ hohe Kosten. Wir wägen deshalb gerade ab und das ist leider nicht leicht. Nimmt man ein Manko wie die Nummernkreise in Kauf, ändert die eigene Datenstruktur und bekommt dafür im Gegenzug wichtige andere Features und spart die Hälfte der Kosten.

 

[Microboy]

In der Abstimmung gibt es 3 Stimmen die eine komplett andere Struktur nutzen! Sagt doch mal welche?

 

[phph]

Wir legen die Daten unabhängig von der Nummerierung in der Agentursoftware (CRACK – macht auch eher keine Freude) ab:

 

Kundenname / [YYYY]-[MM]-Jobname

 

Manchmal auch ohne Jahres- und Monats-Angabe, das kommt ein bisschen auf den Job an. Aber wir sind auch ein kleines Team mit vier Leuten (ohne Wechsel in den letzten x Jahren), da ist es vielleicht nicht so wichtig wie in einem größeren Team, bei dem auch mal Leute wechseln.

[Microboy]

vor 28 Minuten schrieb phph:

Kundenname / [YYYY]-[MM]-Jobname

Nach Jahr und Monat kannte ich noch gar nicht ... und unser Team ist mit 5 Personen auch recht überschaubar.

[Sebastian Nagel]

Hier (in revolver office):

• Die Projektnummer ist nur eine fortlaufende globale Nummer (jedes Jahr von vorne), mehr Information enthält sie nicht. P202012345
• Projekte haben einen Projekttitel der halbwegs(!) konsistent nach "Art" und Inhalt benannt ist.  Broschüre - Produkt XY ...
• Projekte sind Kunden zugeordnet.  Max Mustermann AG
• Wollen wir alle Projekte eines Kunden solo sehen, sortieren oder filtern wir nach Kunden

(die Software funktioniert mäßig gut, aber das liegt nicht am Sortierprinzip, sondern an der Umsetzung / Tempo. Wir wären nicht sehr loyal, aber ein Wechsel bedeutet halt Wechselaufwand, und die Alternative hat dann halt andere Schwächen ...)

 

Am Datenspeicher:

• Ein Ordner pro Kunde
• Darin haben wir (neben Ordnern wie _Logos, _Bilder, ...) jeweils Ordner nach "Art", also Broschüren, Einladungen, ... ... und den berüchtigten "Diverses"-Ordner
• Darin sind dann jeweils Ordner die mit der Projektnummer und Projekttitel benannt sind (Durch die fortlaufende Projektnummer ergibt sich eine chronologische Sortierung aller Broschüren, aller Einladungen, aller ...)
• In jedem Ordner sind dann noch Strukturodner wie PM, PDF, Grafik, ... 

 

Verstehe ich richtig, dass ihr in der Jobnummer/Bezeichnung/... alle relevanten "Infopakete" zusammenzuführen versucht? Mir erschließt sich grade nicht, warum das nicht über Datenbank-Felder und Unterordner gelöst wird?

 

Unser "System" ist aber auch nur hinreichend praktikabel und ganz sicher nicht perfekt. In der Regel finden aber die 16 Leute, was sie suchen.

[Microboy]

vor 8 Minuten schrieb Sebastian Nagel:

Verstehe ich richtig, dass ihr in der Jobnummer/Bezeichnung/... alle relevanten "Infopakete" zusammenzuführen versucht?

Ich weiß nicht genau was du mit zusammenführen meinst. Die Jobbezeichnungen spiegeln sich bei uns in den Dateinamen wieder. Die Struktur haben wir so bereits genutzt als wir die Jobs noch nicht per Software verwaltet haben ... wir haben also die Dateistruktur in die Software übernommen.

 

QuoJob

AA_001 Broschüre XYZ

 

Server

AA_AberAber (Kundenordner) > 

AA_001_Broschuere_XYZ (Jobordner) >

AA_001_Broschuere_XYZ_Inhalt_01.indd

AA_001_Broschuere_XYZ_Inhalt_RZ.indd

AA_001_Broschuere_XYZ_Inhalt_Preview.indd

 

Durch die Kundenkürzel und Nummern sind mehrer Auflagen eines Produktes klar unterscheidbar. Will ich Zeit auf einen Job buchen kann ich diesen mit AA_001 sehr schnell in QuoJob finden.

[Þorsten]

vor 50 Minuten schrieb Microboy:

In der Abstimmung gibt es 3 Stimmen die eine komplett andere Struktur nutzen! Sagt doch mal welche?

 

Ich hätte fast auch Option 3 gewählt, dann aber doch #1 genommen, weil das einzige unumstößliche Kriterium bei uns ist, dass das Kundenkürzel zuerst kommen muss. (Das sehe ich ganz wie bertel.) Danach kann, wenn es sich anbietet, gern eine Projekt- oder Abteilungs-Kürzel kommen, also noch vor Jahreszahlen (die bei uns gern die Basis laufender Nummern bilden).

 

Generell ist es ein bei uns oft wiederholtes Mantra (wir beraten Kunden ja auch oft bei der Auswahl von Software), dass die in den Daten eines Kunden enthaltene business logic dessen wichtigstes Kapital ist.  Und da sollte es nach Möglichkeit keinen oder so wenig vendor/software lock-in geben wie möglich. (Ich hoffe, ihr seht mir das Denglisch nach. Es ist hier noch früh und wir reden da ja immer nur auf Englisch drüber.) Und Projektorganisation gehört für eben zu diesen Kern-Daten. Wenn du die nur mit spezieller Software nach Kunde organisieren/sortieren kannst, ist das blöd und krezugefährlich. Wie leicht könnte da mal eine Datei zu Kunde ZZ auf einem Datenträger landen, der an Kunden AA geht!

[Sebastian Nagel]

ok, jetzt verstehe ich - es geht dann drum was auch "raus geht" und wie diese Dateien heißen.

 

Die heißen bei uns z.B. P202012345_Broschüre_ProduktXY_DE_RZ.pdf

 

Wir finden das zugehörige Projekt über die Projektnummer wieder (in der Datenbank, wie auf dem Datenspeicher).  Wir verzichten aber tatsächlich auf einen Kundenkürzel, das ist jetzt nicht unbedingt eine bewusste Entscheidung, ist nur noch niemandem eingefallen.

Zusätzlich ist auf der letzten Seite irgendwo klein die Projektnummer, Sprache und meist noch ein Monat/Jahr aufgedruckt, wenn man was aus Papier in der Hand hat.

Sprachvarianten der selben Broschüre laufen unter der selben Projektnummer (das sind dann Unterpunkte innerhalb des Projekts).

Eine neue, veränderte Auflage der Broschüre bekommt eine neue Projektnummer in der Datenbank, und einen neuen Ordner (die alte Auflage wird also nicht mehr angefasst).

Bei unveränderten Nachdrucken ... scheiden sich die Geister. Der Producer will eine neue Nummer, die Grafiker nicht

[Þorsten]

vor 21 Minuten schrieb Sebastian Nagel:

Verstehe ich richtig, dass ihr in der Jobnummer/Bezeichnung/... alle relevanten "Infopakete" zusammenzuführen versucht? Mir erschließt sich grade nicht, warum das nicht über Datenbank-Felder und Unterordner gelöst wird?

Weil es ein nach unseren Erfahrungen nicht unrealistisches Szenario ist, dass in 10 oder 20 Jahren die Projektdateien noch existieren, die Projektverwaltungs-Datenbank aber nicht mehr.

 

(Ob man die jederzeit sortierbare Zuordnung jetzt in Ordner- oder Dateinamen abbildet, ist weit weniger wichtig. Dateiname ist nach unseren Erfahrungen aber einen Tuck sicherer, weil Kunden und andere Andere Ordnerstrukturen gern mal über den Haufen werfen, sich aber fast nie die Mühe machen, Dateinamen zu ändern. Aber wenn dich halt ein alter Kunde [oder Kunde eines Kunden] anruft und sagt: »Ich habe da diese Datei, die mal von Ihnen kam«, ist es halt praktisch, wenn du schon am Dateinamen sehen kannst, worum es geht.)

[Sebastian Nagel]

vor 13 Minuten schrieb Þorsten:

Weil es ein nach unseren Erfahrungen nicht unrealistisches Szenario ist, dass in 10 oder 20 Jahren die Projektdateien noch existieren, die Projektverwaltungs-Datenbank aber nicht mehr.

 

(Ob man die jederzeit sortierbare Zuordnung jetzt in Ordner- oder Dateinamen abbildet, ist weit weniger wichtig. Dateiname ist nach unseren Erfahrungen aber einen Tuck sicherer, weil Kunden und andere Andere Ordnerstrukturen gern mal über den Haufen werfen, sich aber fast nie die Mühe machen, Dateinamen zu ändern. Aber wenn dich halt ein alter Kunde [oder Kunde eines Kunden] anruft und sagt: »Ich habe da diese Datei, die mal von ihnen kam«, da ist es halt praktisch, wenn du schon am Dateinamen sehen kannst, worum es da geht.)

Volle Zustimmung. Aber ich glaube da sind wir eh fast "konform", nur das wir den Kundenkürzel nicht auch noch in den Namen mit aufnehmen.

 

(wir hatten parallel geantwortet, unsere Dateien heißen etwa so: P202012345_Broschüre_ProduktXY_DE_RZ.pdf )

 

 

Kleine Folgefrage: 

wie habt ihrs so mit Dateinamen- und Pfadlängen? je mehr man da reinpackt, desto länger werden die ja. 
Fängt man dann an, alles möglichst kurz zu halten, wird's eher kryptisch und kompliziert – auch nicht unbedingt in 20 Jahren sofort rekonstruierbar.

Bleibt man ausführlich, dann hätten wir bei uns wohl mindestens 2 lange "Infodumps" in jedem Dateipfad, 1x für den Ordner, 1x für die Dateinamen selbst:

Daten/Kundenname/Art/Kundenkürzel_Projektnummer_Art_Projektbeschreibung/Grafik/Kundenkürzel_Projektnummer_Art_Projektbeschreibung_Sprache_Status_etcetc.pdf 

Wir rennen jetzt schon ab und zu in irgendwelche Legacy-Limits rein (Pfade nicht länger als 256 Zeichen ... im Netzwerk / bei Plattform-Gemischen / bei Backups / in Archiv-Dateien spätestens beim Entpacken beim Kunden in irgend einen Unter-Unter-Unterordner der das lokale Limit dann endgültig sprengt / ...; auch bei Dateinamenlängen bei E-Mails, ...)

[Microboy]

vor 24 Minuten schrieb Sebastian Nagel:

Wir finden das zugehörige Projekt über die Projektnummer wieder (in der Datenbank, wie auf dem Datenspeicher).  Wir verzichten aber tatsächlich auf einen Kundenkürzel, das ist jetzt nicht unbedingt eine bewusste Entscheidung, ist nur noch niemandem eingefallen.

Dann liegen bei euch alle aktuellen Jobs unabhängig von den Kunden in einem Ordner?

[Microboy]

vor 8 Stunden schrieb Sebastian Nagel:

Kleine Folgefrage: 

wie habt ihrs so mit Dateinamen- und Pfadlängen?

Wir versuchen die Sachen so knapp wie möglich zu benennen. Da wir selten verschieden Sprachversionen oder sonstige Varianten eines Projektes haben funktioniert das auch ganz gut. Ab und an werden Sachen abgekürzt und wir nutzen natürlich auch klassische Zusätze wie »RZ« für die finalen Daten. Dazu kommt noch das jeweilige Mitarbeiterkürzel damit man sofort weiß von dem die Datei kommt ...

 

Früher habe ich viel für einen Filmverleih gearbeitet und längere Titel wurden schon intern vom Verleih abgekürzt. Da gab dann Sachen wie »GNAGL« ...