Ceterum censeo ...  

Ceterum censeo Carthaginem esse delendam.

Im Übrigen bin ich der Meinung, dass Karthago zerstört werden muss.)

Ausspruch von Cato Censorius im römischen Parlament am Ende jeder seiner Reden.

Zur aktuellen Diskussion...   Managergehälter

Hat jemand, der durch falsches Handeln eine Bank in den Ruin, d.h. an den Tropf des Rettungsfonds bringt, Anspruch auf weiteres Gehalt (und seien es "nur" 500 K€) ?
Oder hat dieser Jemand dann nicht verdient, ohne Abfindung und ohne weitere Gehaltszahlung bzw. ohne Ruhestandsbezüge sofort abtreten zu müssen ?

LSA Datenqualität  

Logistic Support Analysis
ist ein Prozess, der viel Zeit und Manpower, d.h. Geld kostet.
In der ganzen Prozesskette sind viele Stolpersteine und Lücken, die zu Fehlern führen und letztendlich einen sinnvollen Gebrauch der mühsam erarbeiteten Informationen (Daten) verhindern.

Wir sind der Meinung, daß ein Qualitätssicherungsprozess notwendig ist, der mit einem Qualitätssiegel oder Zertifikat abgeschlossen wird.

Bei Fragen dazu oder Beratungsbedarf senden Sie uns bitte eine eMail.

Cancellation der MIL-Standards  

Es gibt immer noch eine weit verbreitete Verwirrung zu diesem Thema.
Nach langen Recherchen und Nachfragen zeichnet sich folgendes Bild ab:

Mit dem Perry Memorandum von 1994 wurde die Cancellation der MIL-STDs ausgesprochen.

Grund: Änderung der Beschaffungspolitik

Neu: DoD gibt keine Anleitung für die Industrie heraus, wie die Entwicklung laufen soll
Bsp: JSF, zwei konkurrierende Konsortien entwickeln jeweils einen Prototypen, einer davon wird ausgewählt.

Früher: DoD ist durch permanenten Datenaustausch im iterativen Vorgehen („Cycles“) am Entwicklungsprozess beteiligt. (Mitverantwortung, Einschränkung der Produkthaftpflicht des Herstellers, weil durch ständige Mitprüfung der Entwicklungsdaten (LSA) auch immer wieder Genehmigungen erteilt werden zur Fortsetzung des Entwicklungsprozesses im nächsten Schritt.

Wichtig:
Die MIL-STDs waren automatisch mitgeltende Unterlagen im Beschaffungsvertrag.
Dieser Automatismus wurde mit der Cancellation aufgehoben.

Das bedeutet, daß die MIL-STDs inhaltlich und in ihrer Anwendbarkeit nicht in Frage gestellt sind.

Aus diesem Grund werden die MIL-STDs nach wie vor in Beschaffungsverträgen und in großen internationalen Projekten (z.B. NATO ACCS) weiter als Arbeitsgrundlage vertraglich vereinbart.


Wer ist von der Cancellation betroffen ?
Nur die Vertragspartner des DoD.
DoD Department of Defense, amerikanisches Verteidigungsministerium)

Kann man trotzdem MIL-STDs anwenden?
JA, freiwillig oder durch Vertrag vereinbart.

Zum Thema Kaufpreis  

Zitat
(Es wird allgemein dem englischen Sozialkritiker und -reformer John Ruskin, 1819 bis 1900, zugeschrieben).

Es gibt kaum etwas auf der der Welt, das nicht irgend jemand ein wenig schlechter machen und ein wenig billiger verkaufen könnte. Die Menschen, die sich nur am Preis orientieren, werden die gerechte Beute solcher Machenschaften.

Es ist unklug, zu viel zu zahlen, aber es ist schlimmer, zu wenig zu zahlen.
Wenn man zu viel zahlt, verliert man ein wenig Geld - das ist alles.
Wenn man zu wenig zahlt, verliert man manchmal alles, weil das, was man gekauft hat, nicht in der Lage ist, das zu tun, wofür es gekauft wurde.

Das Gesetz vom Gleichgewicht der Wirtschaft untersagt es, wenig zu zahlen und viel zu bekommen. Das ist nicht möglich.

Wenn Sie mit dem niedrigsten Anbieter Geschäfte machen, ist es ratsam, etwas für das Risiko aufzuschlagen, das Sie eingehen.
Wenn Sie das tun, haben Sie genug, um für etwas Besseres zu zahlen.

Zitat Ende.

Kommentar:
Wie sieht es mit der Anwendung dieser Erkenntnis auf Preise für Dienstleistungen (Beratung) aus ?

Standardsoftware versus Eigenprogrammierung  

Die Frage bezieht sich auf vielfach in der Praxis anzutreffende Programmierungen, meist mit Excel oder Access/VB oder dBase, zu Themen wie Ersatzteilmengenberechnung oder Level-of-Repair-Berechnung.

Dabei wird behauptet, daß diese Eigenprogrammierung besser und billiger wäre.
Stimmt das ?

Die Antwort ist schlicht:

Nein.

Diese einfache Antwort beruht auf folgender Überlegung und auch auf Fakten aus der Praxis:

a) Der Lösungsansatz muß aus Zeitmangel einfach und schnell sein. Ungenauigkeiten werden in Kauf genommen.

b) Die Berücksichtigung komplexerer Zusammenhänge ist relativ aufwendig. In einem Praxisbeispiel wurde der Programmieraufwand mit mindestens zwei Monaten angegeben, ohne daß der gewünschte Detaillierungs- und Genauigkeitsgrad schon erreicht worden wäre.

c) Der Lösungsweg bzw. das Programm wird aus Zeitmangel nicht dokumentiert, nur der Erzeuger des Programmes kennt sich damit aus und weiß auch, welche Annahmen er bei der Programmmerstellung getroffen hat.

d) Aus c) folgt, daß eine Weitergabe an andere Nutzer, speziell bei Partnerfirmen, so gut wie unmöglich ist.

e) Der Aufwand der Eigenprogrammierung wird in aller Regel unterschätzt, er verteilt sich auf Monate und Arbeitsstunden werden dafür eingesetzt, die der eigentlichen Projektarbeit entzogen werden.
Wegen der stundenweisen Arbeit an der Eigenprogrammierung über einen längeren Zeitraum geht der Überblick über den Gesamtaufwand verloren.
Die Annahme, daß über Stunden mal Stundensatz (der bei über 100 EUR liegt als firmeninterner Verrechnungssatz) mindestens soviel Geld verbraucht wird, wie der Kaufpreis eines professionellen Tools beträgt, ist durchaus berechtigt (im Einzelfall nachweisbar).

f) Das selbst entwickelte Programm ist in keiner Weise validiert.

Demgegenüber sind bei einer Standardsoftware folgende Vorteile festzustellen:

- Es gibt eine Dokumentation.
- Es gibt eine Anwenderschulung.
- Es gibt eine standardisierte Vorgehensweise für alle Benutzer, es gibt standardisierte Outputs, die für alle gleich verständlich sind.

- Die Modellierung komplexer Scenarien ist möglich.
- Hoher Detaillierungs- und Genauigkeitsgrad.

- Der Kaufpreis ist niedriger als bei entsprechender Eigenprogrammierung
(Eine zur Standardsoftware vergleichbare Leistungsfähigkeit der Eigenprogrammierung kann nicht zu dem Preis erreicht werden.)

- Die Standard-Software ist validiert und durch den Einsatz bei vielen Anwendern geprüft. Die Wahrscheinlichkeit der Fehlerentdeckung ist durch den vielseitigen Gebrauch höher und infolge der permanenten Softwarepflege/Korrektur/Verbesserung ergibt sich eine dauerhafte Produktverbesserung.