tkreutz2

Ich finde es auch besser, wenn man eine Trennung beibehält zwischen Privat und Dienstlich als Grundsatzregel - auch hinsichtlich Worklife Balance. Unabhängig davon kann man natürlich über Nischen nachdenken (z.B. Trends BYOD). Ein interessanter Kompromiss wäre vielleicht, wenn man z.B. einem neuen Mitarbeiter seinen Laptop schenkt (nach Mindestdienstzeit). Ich sehe allerdings auch viele Probleme. Deswegen würde ich den Titel definieren als "Fluch und Segen zugleich". Ich habe schon erlebt, dass Arbeitgeber illegale Tools zur Kontrolle der Mitarbeiter installiert hatten. Ich habe auch schon erlebt, dass Arbeitgeber Mitarbeiter bedroht haben mit Sätzen wie: "Wenn Sie den Aufhebungsvertrag nicht unterschreiben, stellen wir Ihnen kein wohlwollendes Zeugnis aus und lassen den Satz des Bedauerns weg). Viele Dinge in Arbeitsverhältnissen basieren auf Vertrauen. Man darf als AN nie vergessen, dass es auch Unehrlichkeit auf der anderen Seite gibt. Und das sollte man bei solchen Angeboten immer im Auge behalten.

Also ich habe mir jetzt auch noch einmal die Mühe gemacht und einen Blick auf die übrigen Beiträge geworfen (z.B. den mit den "bösen Zahlen") und bin zu folgender Erkenntnis gekommen. Du hast ein dringendes Problem (gesundheitlich), was mit höchster Priorität gelöst werden muss. Ob Du 32, 40 oder 70 Stunden dort wo Du bist oder wo anders arbeitest, löst Dein Problem nicht, solange die Gesundheit nicht wiederhergestellt ist. Also kümmere Dich gefälligst um eine Therapie ! Denn Du hast nur ein Leben und es ist wichtig und wertvoll. Nichts in der Welt - aber auch gar nix - ist so wichtig, wie die eigene Gesundheit. Von daher kann ich Dir auch nur diesen dringenden Rat geben. Alles andere wird die Zeit bringen.

Keine Seiten mit Aufgaben, sondern aktive Mitarbeit in Communitys von konkreten Produkten als Teil des Entwickler-Teams z.B. https://symfony.com/doc/current/contributing/index.html (oder eben https://www.apachefriends.org/de/index.html) Opensourceprodukte suchen immer Unterstützer oder Leute, die mitarbeiten wollen. Einfache Aufgaben fangen z.B. an bei der Hilfe in Form von Bug-Fixing (Ticket-System), Übersetzung, Tests usw. Dabei bekommt man automatisch in Berührung mit den Teilen des Quelltextes, welche die Funktionalität zur Verfügung stellen. Daneben kann man sich selbst mit den Grundlagen beschäftigen, indem man z.B. einfach einen Webserver mit XAMPP einrichtet (einschl. Datenbank), danach z.B. Wordpress usw. Wenn es zu Problemen kommt im Bereich XY und man Probleme finden und lösen kann, versteht man die Zusammenhänge. Darauf aufbauend könnte man dann ein eigenes Produkt entwicklen, sofern man dazu Zeit- und Muse findet.

Dann solltest Du bei den Grundlagen zu allen Einzelthemen anfangen und anschließend erst einmal Erfahrungen mit verschiedenen Produkten sammeln. Viele Produkte im Opensource Bereich besitzen auch eine Community, bei der man aktiv mit arbeiten kann. Das fängt dann mit einfachen Aufgaben an und wird danach komplexer. Vorteil ist, dass meistens ein erfahrener Projektleiter die Entwickler begleitet. Das Verständnis kommt mit der Zeit nach und nach. Ein beliebtes Produkt und eine bekannte Anlaufstelle ist z.B. Apachefriends (XAMPP). https://community.apachefriends.org/f/

"...Kleinstes Schach-Programm: Rekord nach über 30 Jahren gebrochen..." https://winfuture.de/news,85588.html Also die Demo-Szene bietet schon von jeher die Möglichkeit, interessante Konzepte zu studieren. Einfach mitmachen, sich der Szene anschließen und Erfahrungen sammeln und lernen. Es mag vielleicht ein wenig witzig klingen. Aber ein Lehrer hat in unserer Gruppe (Atari ST Retro Computer) gerade für seine Schulklasse eine virtuelle Gruppe eingerichtet, um dort in GFA Basic zu programmieren. Gerade der Spaß-Faktor kann ein guter Weg sein, um Konzepte zu lernen, die bei der späteren beruflichen Orientierung auch eine Hilfe sein können. Dabei ist es auch wichtig, schon frühzeitig Kontakte zu knüpfen und Erfahrungen untereinander auszutauschen. Ich finde für einen Schüler den Einstieg über ein Spaß-Thema interessant. Einfach mal so eine alte Kiste kaufen und mal schauen, was man so damit machen kann. Dabei lernt man auch etwas über die Anfänge des Computerzeitalters. Wer keine alte Kiste hat, kann natürlich auch andere Konzepte probieren z.B. ein Raspberry Pi, Lego Mindstorms (das ist dann der Weg in die Robotik). Es ist auch gut, wenn man Hardware- und Softwarekonzepte gleichzeitig lernt, z.B. einen Roboter mit Mindstorms bauen (Cube-Solver) und dann an einem Programm arbeiten, um den Zauberwürfel zu lösen. Dabei lernt man dann Optimierungskonzepte kennen (z.B. wie man die Geschwindigkeit des Roboters erhöhen kann). Einige Unis bieten auch Schüler-Camps an.

Von Ian Sommerville ist gerade ein neues Buch erschienen "Modernes Software-Engineering". https://www.pearson-studium.de/modernes-software-engineering.html Hier sind neue Modelle sowie auch der Punkt "Cyber-Crime" und Sicherheit by Design mit verankert. Ich finde auch, dass dieser Punkt in den klassischen Ansätzen zu wenig- oder überhaupt nicht berücksichtigt wurde in der Vergangenheit.

Ich kann die Frustration gut nachvollziehen. Diese Situation findet man oft bei kapitalgeführten Unternehmen, zu denen jeglicher "persönliche" Bezug zu Mitarbeitern scheinbar dem Interesse des Kapitals untergeordnet ist. Viele Mitarbeiter "vergessen" im Eifer ihrer Arbeit, auch einen Blick auf solche Entwicklungen zu werfen und natürlich wissen viele Mitarbeiter überhaupt nicht, wie es im Zahlenwerk dahinter aussieht und was die obersten Entscheider planen. Eine berufliche Umorientierung ist aber auch ein Schritt, der gut geplant und organisiert werden will. Und sicher sind solche Entscheidungen auch keine ad hoc Entscheidungen, die man mal eben zwischen Tür und Angel treffen kann - betreffen sie doch möglicherweise auch die Pläne anderer Familienmitglieder (z.B. durch einen Umzug). Ein fachlicher Wechsel will auch gut überlegt sein, denn schließlich steht man dann in Konkurrenz mit Leuten, die auf dem anderem Fachgebiet schon wesentlich mehr Expertise besitzen, als man selbst. Während bei großen Firmen Umbesetzungen zu anderen Aufgaben oder Abteilungen eher möglich sind (intern), weil das Unternehmen die Mitarbeiter kennt, steht man bei fremden Firmen als "neuer" Mitarbeiter auf der Matte und muss in Sachen Fähigkeiten- und Fertigkeiten sich erst einmal beweisen. Es gibt Checklisten im Netz, die bei beruflicher Umorientierung helfen können. Es gibt auch Coaches oder Berater auf dem Gebiet, die möglicherweise zielgerichteter die persönliche Situation aufarbeiten können. Ich fürchte, dass ein Forum als Außenstehender Ratgeber nicht in der Tiefe und Breite beraten kann, wie es für die konkrete persönliche Situation dann hilfreich wäre. Vielleicht wäre ein interner Stellenwechsel eine Option. Wenn die Entscheidung jedoch in die Richtung einer völlig neuen Orientierung geht, würde ich mir auch durchaus entsprechende Hilfe- und Beratung holen, um auch die persönliche Situation stärker zu berücksichtigt. Den Erhalt des Status quo in Form eines Neustarts in der bestehenden Konstellation sehe ich aus der geschilderten Situation eher als problematisch an (was nicht unmöglich heißen soll ). Die Frage ist dann, ob die Fortsetzung in dieser Konstellation noch die gefühlte Freude am Job vermitteln kann oder ob sich die Stimmung eher in Richtung Steigerung der Frustration entwickelt. Letzteres wäre (leider) auch keine Hilfe für die anderen verbliebenen Mitarbeiter der Abteilung. Ich fürchte, dass eine "Flucht" auf eine fachfremde Stelle, nur um der derzeitigen Situation zu entfliehen, letztendlich nicht die gewünschte Zufriedenheit bringen wird. Und die eigene Zufriedenheit im Job ist doch ein wichtiger Punkt, weswegen man sich einmal für die ein oder andere Richtung entschieden hat. Die Corona Situation ist für alle Menschen schwer, ich würde den Punkt aber auch nicht überbewerten, denn auch zu Corna-Zeiten müssen Produkte- und Dienstleistungen hergestellt und Menschen damit versorgt werden. Bewerbungsprozesse laufen langsamer als normal, aber der Bedarf an Mitarbeitern besteht dennoch. Hier muss man einfach die Geduld haben, auch länger laufende Prozesse aussetzen zu können. Viel Glück !

Hallo, vorab, ich werde die Frage nicht beantworten (können), denn die Thematik sprengt in der Komplexität die Möglichkeiten dieses Fachforums (persönliche Meinung). Ich kann aber einen guten Buch-Tipp hierzu geben. Das Buch ist älter und nennt sich Access 2007 das Praxisbuch für Entwickler ISBN 978-3-8273-2459-7 https://www.pearson.ch/download/media/9783827324597_TC.pdf Konzeptionell an dem Buch fand ich toll, dass es eben auch eine Art praktischen Leitfaden beinhaltete, der zeigt, wie man Anforderungen beim Auftraggeber erkennt und diese Step by Step in ein Produkt umsetzt. Ich vermisse solche Bücher heute sehr, denn viele Bücher sind aus heutiger Sicht entweder extrem technisch lastig oder eben extrem Projekt lastig oder zu sehr theoretischer Natur (akademische Sicht). Der Vorteil in diesem Buch ist es, dass es EINE Anforderung gibt, die sich wie ein roter Faden durch das Buch zieht und die dann stückchenweise weiter spezifiziert und implementiert wird. Dabei werden auch Gespräche zwischen möglicher Projektrollen erläutert und Fehler, die man als Entwickler dabei machen kann (auch im Bereich Kommunikation). Natürlich ist der technische Teil hiervon veraltet und auch in Sachen Projektmanagement gibt es sicher neuere Trends. Aber das kann man ja ggf. anpassen. Wenn man das Buch als praktischen Leitfaden zur Anforderungsanalyse liest, kann es durchaus hilfreich sein. Viel Erfolg ! Gruß Thorsten

Ja, der normale berufliche Weg ist es, zunächst Erfahrungen zu sammeln, bevor man die Zertifizierung anstrebt. Man kann aber auch versuchen, beides miteinander zu verknüpfen und gleichzeitig Wissensbildung- und Zertifizierung zu machen. Der Erfolg davon hängt dann allerdings davon ab, wie fit man in dem ein oder anderem Thema schon ist, oder man noch Grundlagen erarbeiten muss. Daher war mein Vorschlag ja ein "Learning on the Job", als konkreter Einstieg in ein konkretes Thema.

Nein, Java war für uns als AEler ein Thema. Im Forum findest Du auch Antworten zu allgemeinen Oracle Produkten- und Themen und natürlich Datenbanken. (Java Ranch) Ob die Prüfung schwer ist, hängt von der Zeit ab, die man für eine Vorbereitung hat und in unserem Kurs war diese Zertifizierung nur ein Bonus (Zusatzangebot) des Bildungsträgers. Die meisten Leute waren ausgelastet mit anderen Themen zu diesem Zeitpunkt. Was nützt es, wenn eine Firma "gut" ist aber der Trainer nicht zu einem als Teilnehmer passt, dass ist eine sehr individuelle Geschichte. Die Suche nach einer Firma und einem Trainer kann ja auch ein regionales Thema sein, wenn man nicht wer weiß wie weit pendeln will für einen Kurs. Ich habe leider keine Pool Informationen zu Trainern im Oracle Bereich. Wikipedia bietet auch ein Snippet an auf die Frage "How can I learn Oracle Database?" 1. Step 1: Pick Your Starting Operating System Wisely. 2. Step 2: Consider Oracle Certification (OCP) 3. Step 3: Familiarize Yourself With Virtualization. 4. Step 4: Broaden Your Operating System Knowledge. 5. Step 5: Oracle on Linux. 6. Step 6: Automatic Storage Manager(ASM) usw. Also wäre der Lernpfad OCA durchaus sinnvoll auch zum erlernen der Database Themen. https://www.oracle.com/de/corporate/features/oracle-certification.html

Wir hatten in unserer Umschulung einen Teil mit Vorbereitung auf OCA und OCP Zertifizierung (Java). Erfolgreiche Teilnehmer hatten im Anschluss die Möglichkeit sich an der Prüfung in einem autorisierten Trainingscenter zu versuchen. Als Schulungsunterlagen dazu hatten wir die offiziellen Trainingsunterlagen in englischer Sprache sowie zahlreiche Übungen, die unser Trainer aufbereitet hatte. Als ergänzende Bücher dazu hatten wir das Java Insel Buch, das Einsteigerbuch von Hans-Peter Haberlitz und auch den ein oder anderen Udemy Kurs (Java Programming Master Class). Fragen zu Oracle Zertifizierungen und Weiterbildungen wurden im Java Ranch Forum, welches auch vom offiziellen Zertifizierungsprüfungsbuch empfohlen wird, gestellt und zeitnah beantwortet. Da die gesamte Oracle Landschaft recht komplex ist, würde ich auch empfehlen, zunächst gezielt nach Informationen zu recherchieren. Das Forum dort (englisch), kann eine erste Anlaufstelle sein. Aus deutscher Seite kann ich sagen, dass Prüfungszentren (Pearson Vue) - meist bei Microsoft Partnern, auch die Abnahme solcher Prüfungen anbieten. Als Alternative gibt es noch Boot-Camps. Diese richten sich aber meistens an erfahrene Mitarbeiter. Meine Erfahrung von Boot-Camps ist die, dass Anfänger dort sehr leicht "abgehängt" werden, sobald der Trainer sein Tempo anzieht und zwei oder drei Leute mit im Kurs sitzen, die deutlich weiter sind vom Wissensstand. Viele Oracle Themen kann man im Selbststudium lernen, dafür muss man Zeit einplanen. Ersparnis von Zeit ist meistens mit Kosten verbunden. Ein Einzeltraining dürfte die effektivste Methode sein, aber gleichzeitig auch die Teuerste zur Wissensvermittlung. Die Zertifizierungsprüfung von Oracle ist die härteste Prüfung, die ich jemals gesehen habe. Zwar gibt es Prüfungssimulationen und Braindumps zum Lernen. Erfolg wird man aber nur haben, wenn man die wesentliche Dinge auch begriffen hat. Von zwei Umschulungsklassen in meinem Umschulungszeitraum hat 1 Teilnehmer letztendlich die beiden Prüfungen auch gepackt innerhalb des extrem gestauchten Zeitraums zur Vorbereitung auf die Prüfung. Die meisten Betreiber von Test-Centern bieten auch Trainings an. Ob das Angebot gut ist oder schlecht, hängt vom Trainer und der Chemie zwischen Trainer und Teilnehmer ab. Das ist wie "Schuhe kaufen" - die Information, ob Du gut oder schlecht fährst, kann Dir niemand geben. Ich würde empfehlen, mit kleinem finanziellen Aufwand in ein Thema versuchen einzusteigen und ggf. das ein oder andere ergänzende Buch dazu zu nehmen. Sofern es ein konkretes Produkt gibt, welches vielleicht schon von einem Systemhaus in der Vergangenheit betreut worden ist, wäre eine Einarbeitung von genau dem betreuenden Systemhaus zielführender, als irgend ein x-beliebiges Training.

Kann man natürlich machen. Die Frage ist aber immer, ob man in erbitterten Nachbarschaftsstreitigkeiten münden will, die sich über Jahre hinziehen können und nicht selten vor den ohnehin überlasteten Gerichten landen. Meine Erfahrung bei Nachbarschaftsstreitigkeiten (Mietshaus) ist die, dass man Streithähne besser auf Distanz hält, denn man will ja auch noch irgendwie in Ruhe noch nebeneinander leben. Natürlich sollte man sich auch wehren gegen falsche Verdächtigungen. Meine Erfahrung in diesem Zusammenhang ist es, dass ein Schreiben von einem Anwalt (wenn der Nachbar keine Ruhe lässt und mündliche Hinweise bestimmt aber sachlich - keinen Effekt zeigen), effektiver ist.

Ich hatte mal einen Chef in einer ähnlichen Situation, der hat schließlich Magengeschwüre bekommen und ist dann daran auch leider gestorben. Natürlich sollte man nie den Teufel an die Wand malen. Aber in einer solchen Situation sollte man sich ernsthaft die Frage stellen, ob die eigene Gesundheit durch Fortführen der Situation nicht gefährdet ist. In der Situation gefangen - das ist doch nicht glaubwürdig. Denn schließlich liegt es an einem selbst, notwendige Entscheidungen z.B. die Beendigung eines Jobs der krank macht - zu treffen. Sicher - leichter gesagt, als getan. Von dem geschilderten Umfeld scheint es keinen Sinn zu machen, fachliche Veränderungen anzustreben. Aber das kann ein außenstehendes Forum sicher nur bedingt oder überhaupt nicht beurteilen. Ich würde empfehlen, sich ernsthaft Gedanken zu machen. Für mich klingt das geschilderte Umfeld schlicht und einfach krank.

Wir haben bei unserer Umschulung zu dem Thema "Wissensvermittlung" auch einmal Material von YT auf den Prüfstand gestellt und eine Menge Fehler dabei gefunden, denn niemand prüft das Material darauf und man kann sich auch nicht auf Selbstkontrolle verlassen. Das ist auch der Unterschied zwischen Wikipedia und Brockhaus. Neue Medien bedeutet nicht unbedingt besser, richtig, oder Ersatz herkömmlicher Methoden- und Quellen.

Wenn der Nachbar Hilfe braucht, dann soll er sich doch professionelle Hilfe holen, anstatt noch andere Leute zu verdächtigen. Auf gar keinen Fall irgend welche Geräte vom Nachbarn anfassen oder irgend etwas dazu kommentieren. Unabhängig davon sollte man seine eigenen Geräte auch im Auge behalten und sich hierzu ggf. auch Hilfe holen, wenn das denn erforderlich ist. Aber sich zu irgend einem blinden Aktionismus zwingen zu lassen aufgrund "Hörensagen", ist meistens wenig zielführend. Und bei einem Nachbarn, der mit Vorwürfen ins Haus fällt, sollte man die Kommunikation eher minimieren oder komplett einstellen.

Sehe ich ähnlich. Maniska hat ja gerade einen allgemeinen Thread geöffnet zu dem Thema.

Nein, das war nicht der Ansatz, auf den ich hinaus wollte. Ich nutze Intranets und Wikis schon sehr lange und bin immer ein Verfechter von guter Dokumentationen gewesen. Meine Erfahrung aus dem realen Leben sah jedoch beispielsweise so aus, dass ein Abteilungsleiter die Nutzung eines Repositorys vom Quellcode "untersagt" hatte, zu dem ein Berater zuvor sagte, dass dieses Werkzeug absolut "lebenswichtig" ist. Es gibt Leute mit Verantwortung, die eine solche "Entscheidungsmacht" im Unternehmen haben. Also bitte mich jetzt nicht so hinstellen, als ob ich gegen Dokumentation wäre, wenn ich organisatorische Schwierigkeiten aus dem wirklichen Leben einmal thematisiere. Man kann natürlich auch seine Augen vor der Realität verschließen und Erfahrungen anderer einfach mal abtun. Ich finde es übrigens, dass dieses Forum bisher beispielhaft daran vorbei geht, was vermutlich der eigentliche Kern der Frage war. Der Kern der Frage war nämlich nicht was das 23ste Tool zur Dokumentation ist, nämlich genau die ganze Palette an menschlichen und zwischenmenschlichen Dingen, die auch dazu beitragen können, ob überhaupt dokumentiert wird oder nicht. Selbstverständlich gehören in dieses Thema auch Verhaltensmuster von Vorgesetzten. Und wenn es Prüfer hier in dem Forum gibt, die es nicht schaffen, dieses schwierige Thema auch einmal zu thematisieren, sollten sie sich schämen. Das ist meine Meinung und das wollte ich an dieser Stelle auch mal sagen.

Dann werde ich das mal etwas spezifizieren. Das Thema Wissensdokumentation kann man doch nicht ohne das Thema Kommunikation betrachten. Die "Erfahrungen", zu denen ich etwas geschrieben habe sind auch Erfahrungen aus gescheiterten Dokumentationsprozessen in Form von Intranets, die nie mit Leben gefüllt worden sind oder Prozessen, die zu Überorganisation geführt haben. Ein Thema kritisch zu betrachten, bedeutet nicht, dass man es für unwichtig hält, sondern dass man mehr als eine Seite zu einem Thema betrachtet. Um wieder zu dem eigentlichen Thema zurück zu kommen. Ein guter Ansatz zu Dokumentationen sind ja Intranets, Prozesslandkarten und Organigramme (elektronisch), bei denen man sowohl Zuständigkeiten, als auch Aufbau- und Ablaufprozesse dokumentieren kann. Wenn jetzt ein solches Instrument nicht richtig genutzt wird, sollte man doch auch kritische Fragen einmal zu diesem Thema erlauben. Das Problem vieler Organisationen ist, dass Stellenbeschreibungen schwammig sind und Kompetenzen nicht eindeutig, es gar zu Überschneidungen kommen kann, die aus organisatorischer Sicht sogar Probleme verursachen.

Kein Mensch ist unverzichtbar und unersetzlich. Unternehmen werden verkauft, Veränderungsprozesse sind Teil unseres Lebens. Im Prinzip müssten wir uns dann hier einmal über das Thema interne- und externe Kommunikation unterhalten - sicher auch ein nicht unwichtiges Thema, was vieles zu einem guten oder schlechtem Betriebsklima beitragen kann. Wie ein Unternehmen funktioniert hängt nicht nur vom Organigramm ab. Es gibt viele Prozesse, die auch auf kurzen Wegen kommuniziert werden. Das ist auch ein wichtiger Punkt. Wenn man erkennt, dass etwas schief läuft, sollte man auch selbst handeln und nicht warten, dass andere das Eisen aus dem Feuer holen. Außerdem ist ein Unternehmen auch ein Geflecht aus Beziehungen, die nunmal auch aus menschlichen Stärken- und Schwächen bestehen. Trotzdem ist bei dem Thema Kommunikation auch eine gewisse Vorsicht geboten. Als ITler - und da zähle ich einfach mal alle dazu, unabhängig ihrer Profession- Position- oder ihrer Rolle, ist man sicher gut beraten, wenn man erst mal zuhört. Eine voreilige Information gegenüber einem Kunden (egal ob intern- oder extern), kann auch fatale Folgen haben. Das ist in dem Sinne kein zurückhalten von Wissen, sondern eine gut überlegte Abwägung und Prüfung. Eine gute Kommunikation im Team setzt einfach bestimmte Abstimmungsprozesse voraus.

Na, wenn man das richtige Buch kauft, bekommt man auch eine passendere Einführung z.B. Grundlagen und OOP vor GUI-Themen. https://www.rheinwerk-verlag.de/c-8-mit-visual-studio-2019_4699/ Aber an ein Fertiggericht für 3.40 EUR darf man auch nicht die gleichen Anforderungen stellen, als an das Stück Fleisch in einem guten Restaurant auf dem Teller. Deswegen ist das Thema "Arbeitsmethoden" ja wohl auch ein Bestandteil einer Ausbildung - würde ich vermuten. https://www.hanser-fachbuch.de/buch/Visual+C+2019+Grundlagen+Profiwissen+und+Rezepte/9783446458024 Unbedingt die englischen Titel durchstöbern, die sind meistens besser also im Pearson Verlag z.B. https://bookshop.pearson.de/starting-out-with-visual-c-global-edition.html https://bookshop.pearson.de/visual-c-2014-how-to-program-global-edition.html

Also Bewerbungen schreiben kann man immer. Man kann dies auch in der Form argumentieren, dass man seinen Marktwert testet. Das ist zwar nicht schön für die Sachbearbeiter im HR-Bereich, aber die machen es ja teilweise genauso - Stellen ausschreiben, obwohl die Stelle längst intern vergeben sind oder es die Stellen überhaupt nicht gibt, nur eine entsprechende "Präsenz" zu generieren in den Medien oder um gesetzliche Vorschriften zu erfüllen. Außerdem sollte man immer in erster Linie an sich selbst und seine eigene Situation denken. Kein Unternehmen der Welt ist Loyal gegenüber Mitarbeitern, wenn es hart auf hart kommt. Ich würde allerdings die Stelle auch erst kündigen, wenn definitiv ein neuer Vertrag unterschrieben ist. Denn dass es Stellen gibt, heißt ja noch nicht, dass man eine von den genannten Stellen tatsächlich auch in der Tasche hat. Außerdem sollte man berücksichtigen, dass man sich in dem Umfeld auch wohl fühlt. Was nützt es, wenn Eckdaten von einer Stelle noch so toll sind, aber man sich überhaupt nicht wohl fühlt. Das ist ein Punkt, den viele Leute unterschätzen und deswegen voreilig Entscheidungen treffen. Natürlich sieht man als Außenstehender zunächst einmal nie hinter die Kulissen. Die Ernüchterung kann dann auch sehr schnell kommen. Aber nichts im Leben ist auch ohne Risiko und wer nichts riskiert, kann auch nichts gewinnen.

Mir ist auch nicht ganz klar, ob die Fragestellung in technische Richtung geht, oder ob es eigentlich um informelle Strukturen geht, die es in jeder Organisation gibt. Wäre gut, wenn man dass etwas konkretisieren könnte. Denn entsprechend unterschiedlich sind auch mögliche Lösungsansätze bei Problemen. Und die Diskussion geht sonst an der Problemstellung vorbei. Ich fürchte, dass wir nur helfen können, wenn mal auf den Tisch kommt, worum es eigentlich geht. Also Butter bei die Fisch bitte.

Wir haben ja noch nicht darüber gesprochen, was "Wissen" alles beinhalten kann. Dieser Begriff muss in Organisationen ja durchaus weitläufiger betrachtet werden. Geht es nur um technische Dokumentation, fehlt die organisatorische Komponente. Aus dem Grund setzen Berater gerne Tools ein, die nicht nur technische sondern auch organisatorische Sachverhalte sowie Geschäftsprozesse dokumentieren. Die Einführung solcher Tools ist ein komplexes Thema, kann aber Kommunikationsprozesse verbessern (z.B. viflow). Ein ehemaliger Chef von mir sagte immer, dass Wissen immer auch eine Holschuld Komponente beinhaltet. Meine Erfahrung ist, dass regelmäßige Abteilungsbesprechungen ein wichtiges organisatorisches Element sein können. Man muss bei dem Thema immer darauf achten, dass es ein gesundes Verhältnis zwischen Team-Meetings, Tools und der eigentlichen Kernarbeit gibt. Zu wenig Absprachen kann genauso schädlich sein, wie zu viel davon. Ich hatte im Laufe meiner Erfahrung in der Produktion schon Kontakt mit sehr vielen Prozessen und Tools. Das Modell der High Speed Lean Autofabrik (Toyota-Modell, später auch bei Ford eingesetzt) bündelt einen ganzen Katalog von Tools- und Maßnahmen, die in diese Richtung gehen. Ab einem gewissen Punkt besteht aber die Gefahr einer Überorganisation. Dann geht die Produktivität eines Betriebes deutlich zurück, weil die Leute nur noch mit Dokumentationsaufgaben beschäftigt sind, anstatt sich um die eigentlichen Kernaufgaben zu kümmern. Was das Ergebnis unserer super organisierten High-Speed Lean Autofabrik ist, haben wir gesehen bei dem Zusammenbruch von Lieferketten. Unter hohem Kostendruck wurde immer weiter optimiert und heute steht die gesamte Autoindustrie vor einem sehr großen Kahlschlag, weil man nicht rechtzeitig genügend "Brain" in zukunftsfähige Konzepte gesteckt hat. Na, der eigentlich Punkt, auf den ich hinaus wollte ist doch der, dass zu dem Thema mehr als eine technische Dokumentation zählt und in diesem Zusammenhang wird immer gern vergessen, dass eine Organisationsstruktur ein lebendes Gebilde ist, dass auch aus unterschiedlichen Typen von Individuen besteht. Diesen Punkt darf man - glaub ich - nicht vernachlässigen.

Schwierige Frage, die man sicher aus unterschiedlichen "Perspektiven" beleuchten muss und bei der es auch um so etwas wie Loyalität, Kollegialität, Betriebsklima, Ehrlichkeit, Umgang Mit- und Untereinander geht. Leider kann der Faktor Mensch ein sehr großes Enttäuschungspotential mitbringen. Meine Eltern hatten diesbzgl. immer die Kernaussage, dass niemand in den Kopf seines Gegenübers "sehen" kann. Man muss ein "Gefühl" für sein Umfeld entwickeln und daraus entscheiden, was passend oder angemessen oder was falsch oder unangemessen sein kann. Wenn man merkt, dass ein Gegenüber einen betrügt oder nicht ehrlich ist, sollte man Vorsicht walten lassen. Es wäre natürlich schön, wenn es immer offene und ehrliche Strukturen geben würde. Aber leider wissen wir ja von der Realität, dass dem nicht immer so ist und in diesem Fall sollte man sich angepasst verhalten. Na wenn der Kollege sich mit den Erfolgen brüstet, die er nicht erzielt hat, braucht er auch kein kollegiales Verhalten seiner Mitkollegen erwarten. Für das Arbeitsklima sind solche Situationen Katastrophal und auch für einen persönlich kann dass zu einer psychischen Belastung werden. Deswegen sollte man sich in betroffenen Personen rechtzeitig Rat holen und ggf. auch schnell Entscheidungen treffen können, ob man in einem solchem Umfeld Weiterarbeiten kann oder will. Was die reine technische Dokumentation angeht, denke ich dass es hierzu vielfältige Möglichkeiten gibt, angefangen vom Intranet über Ticketsysteme bis zu speziellen Lösungen.

Ja, ich glaube, in diesen Punkt können sehr viele individuelle Entscheidungen eine Rolle spielen. Der beste Weg ist es natürlich, eine Wahl zu treffen (Arbeitgeber / Technologie), die einem auch immer langfristige Perspektiven öffnet - wie auch immer das dann im Einzelfall ausgeprägt ist.