BWL & Fernstudium: Einsendeaufgaben-Hilfe

Sitze gerade an einer Fallstudie zum Thema Fertigungstiefe und komme an einer Stelle nicht so recht weiter. Die Aufgabe ist, zu beurteilen, ob ein Unternehmen seine Fertigungstiefe erhöhen (also mehr selbst machen) oder senken sollte (mehr outsourcen an Zulieferer).

Ich habe mir schon einiges an Pro- und Contra-Argumenten rausgeschrieben, z. B. Kostenaspekte, Flexibilität, Abhängigkeit von Lieferanten, Know-how-Schutz usw. Aber mir fehlt eine saubere Systematik, mit der ich das Ganze strukturiert herleite, statt nur eine Liste von Argumenten aneinanderzureihen.

Gibt es da ein bewährtes Vorgehen oder ein Rahmenwerk, mit dem man sowas in einer Fallstudie sauber begründet? Also quasi:

• Welche Kriterien sollte man zuerst prüfen (Kosten, strategische Relevanz, Kapazitäten...)?
• Gibt es eine Reihenfolge, in der man die Faktoren abarbeitet?
• Wie gewichtet man am Ende, wenn die Argumente in unterschiedliche Richtungen zeigen?

Freue mich über Tipps, wie ihr sowas angeht, gerne auch mit

Sitz gerade an einer Einsendeaufgabe und komme nicht weiter. Rechnen kann ich beides, linear und degressiv, das ist nicht das Problem. Aber die Aufgabe will, dass ich mich für eine Methode entscheide und das begründe, und genau da hänge ich.

Bei der Maschine ist nix weiter angegeben außer Anschaffungskosten, Nutzungsdauer und Restwert. Ich hab mir überlegt, dass degressiv ja am Anfang mehr Aufwand bringt und damit die Steuerlast am Anfang drückt, aber ist das schon ein ausreichendes Argument für so eine Aufgabe?

Gibt's da irgendwelche typischen Kriterien, an denen man sich orientiert, also sowas wie:

• wie stark nutzt sich das Ding am Anfang ab vs. später
• Liquidität/Steuer am Anfang schonen
• was sagt das Handels- oder Steuerrecht dazu

Oder übersehe ich einen ganz anderen Denkansatz, auf den die Aufgabe eigentlich hinaus will? Würde mich freuen, wenn jemand kurz erklärt, wie man da strukturiert rangeht.

Ich sitze gerade an meinem Studienprojekt und grüble über die Datenbankfrage. Mein Datenmodell ändert sich ziemlich häufig, weil ich noch nicht alle Anforderungen final definiert habe und im Laufe des Projekts immer wieder neue Attribute dazukommen. Jetzt frage ich mich, ob ich deswegen komplett auf eine NoSQL-Lösung wie MongoDB umsteigen sollte, oder ob das bei einer relationalen DB mit sauberem Schema-Design (z. B. über Migrationen) auch gut handhabbar wäre.

Ich habe bisher verstanden, dass NoSQL vor allem bei großen, unstrukturierten Datenmengen und horizontaler Skalierung Vorteile bringt, aber mein Projekt ist eher klein und die Beziehungen zwischen den Daten sind schon relevant (also eigentlich klassisches Terrain für relational). Trotzdem nervt mich das ständige Anpassen der Tabellenstruktur.

Wie geht ihr in der Praxis an so eine Entscheidung ran? Gibt es klare Kriterien, an denen man sich orientieren kann, statt nur nach Bauchgefühl zu wählen? Und ganz wichtig für mich:

Sitze gerade an einer Übungsaufgabe zu Wohlfahrtsökonomik und komme bei der Berechnung von Konsumenten- und Produzentenrente nicht weiter. In der Vorlesung wurde das immer nur als Dreiecksfläche im Preis-Mengen-Diagramm gezeigt, aber in der Klausur haben wir ja oft nur Angebots- und Nachfragefunktion gegeben und keine Zeichnung.

Ich weiß, dass KR = 0,5 * Menge * (Prohibitivpreis - Gleichgewichtspreis) sein müsste, bin mir aber unsicher, ob das immer so einfach geht, vor allem wenn die Angebotskurve nicht bei 0 anfängt. Bei PR hab ich komplett den Faden verloren.

Hat jemand eine Vorgehensweise, wie man das Schritt für Schritt aus den Funktionen berechnet, ohne sich an der Zeichnung zu orientieren? Oder rechnet ihr das generell über Integrale aus?

Sitze gerade an einer Übungsaufgabe zur Klausurvorbereitung und komme bei der Parameterdiskussion eines LGS nicht weiter. Konkret habe ich ein 3x3-System, bei dem in einer Gleichung ein Parameter a auftaucht (sowohl in der Koeffizientenmatrix als auch mit Einfluss auf die rechte Seite). Gefragt ist, für welche a das System eindeutig lösbar ist, für welche es unendlich viele Lösungen gibt und für welche es gar keine Lösung hat.

Mein Ansatz bisher:

• Ich forme das System per Gauß-Algorithmus um, wobei a als Platzhalter stehen bleibt.
• Bei der Zeilenstufenform komme ich an eine Stelle, wo ich durch einen Term mit a teilen müsste – und genau da weiß ich nicht, wie ich das sauber behandle, ohne durch 0 zu teilen oder einen Fall zu übersehen.

Wie geht ihr systematisch vor, um alle Fälle (eindeutig, unendlich viele, keine Lösung) in Abhängigkeit von a zu bestimmen? Reicht es, die Determinante der Koeffizientenmatrix in Abhängigkeit von a zu berechnen und deren Nullstellen zu bestimmen,

Sitze gerade an meinem Praxisprojekt und habe ein nerviges Problem: Ich binde eine REST-API an, die vom Anbieter laufend weiterentwickelt wird. Jedes Mal wenn sich dort was ändert (neue Pflichtfelder, umbenannte Attribute, geänderte Response-Struktur), bricht mein Client. Ich flicke das dann immer notdürftig, aber das kann ja keine Dauerlösung sein.

Ich habe mich etwas eingelesen und finde in der Theorie ganz unterschiedliche Ansätze zur Versionierung:

• Versionsnummer in der URL (z. B. /v1/, /v2/)
• Versionierung über Header (z. B. Accept-Header mit Version)
• Versionierung über Query-Parameter

Was mich interessiert: Wie macht man das in der Praxis, wenn man selbst nicht der API-Anbieter ist, sondern nur Konsument? Baut man sich eine Art Adapter-Schicht, die die verschiedenen Versionen abfängt und intern normalisiert? Oder pinnt man sich einfach stur auf eine Version fest und ignoriert Updates, solange es geht?

Und für alle, die das auch klausurtechnisch brauchen: Ist das Thema

Ich sitze gerade an einer Aufgabe, bei der eine Rückstellung aus dem Vorjahr aufgelöst werden soll, weil der Grund dafür (z.B. drohender Prozess o.ä.) weggefallen ist. Mein Gedanke war erstmal simpel: Rückstellung stand ja auf der Passivseite, und wenn sie nicht mehr gebraucht wird, muss sie ja irgendwie "verschwinden".

Ich hab im Skript was zu "Auflösung erfolgswirksam" gefunden, aber so richtig blick ich den Buchungssatz nicht. Ist das wirklich einfach:

• Rückstellung an sonstige betriebliche Erträge

Oder muss man da unterscheiden, ob die Rückstellung ursprünglich mal als Aufwand gebucht wurde und jetzt quasi "rückgängig" gemacht wird? Und wie wirkt sich das konkret auf den Gewinn in der Periode der Auflösung aus - zählt das als normaler Ertrag in der GuV oder gibt's da eine Sonderstellung?

Falls jemand ein kleines Beispiel mit Zahlen hat, wäre das super, damit ich das mal nachvollziehen kann.

Ich stecke gerade in meinem Praxisprojekt (Wirtschaftsinformatik) und bin etwas verunsichert. Wir sollen eine Datenbank mit echten Kundendaten testen, weil die synthetischen Testdaten laut Projektleitung zu unrealistisch sind und Fehler bei komplexeren Abfragen nicht aufdecken würden. Klingt fachlich nachvollziehbar, aber bei mir schrillen innerlich alle Alarmglocken wegen DSGVO.

Ich hab schon gelesen, dass es wohl einen Unterschied zwischen Anonymisierung und Pseudonymisierung gibt und dass bei Pseudonymisierung die DSGVO trotzdem greift, weil die Daten theoretisch wieder zuordenbar sind. Aber wie sieht das konkret bei Testsystemen in der Praxis aus? Reicht es, wenn man z. B. Namen und Adressen austauscht, aber Kaufverhalten oder sonstige Muster original lässt? Oder ist das schon rechtlich heikel, weil im Zweifel doch Rückschlüsse möglich sind?

Hat jemand von euch das in einem Unternehmen oder Praxisprojekt schon mal erlebt und kann sagen, wie das normalerweise gehandhabt wird?