MurdocX 949 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Servus Kollegen, folgende Situation die Ihr sicher auch schon mal erlebt oder so ähnlich mit Kollegen/Kunden hattet: -- Ihr sollt euch um einen neuen Server bemühen und darauf soll nichts anderes laufen als nur die Anwendung. Beispielsweise (in meinem Fall) ein DC. DC = unternehmenskritische Infrastruktur sollte für sich laufen. Klingt logisch, sollte auch nmM. so sein. Nun wird auf der Gegenseite "Argumentiert" das kein zweiter Server (in diesem Fall neue virtuelle Instanz, die eh lizenziert wäre) notwendig sei, man spare sich die Wartung (Updates, Backup u. etwaige Checks) . Auf diese Maschine sollen noch andere Anwendungen wie DHCP-Rolle, Print-Rolle, AntiVirus-Verwaltung (IIS), Dateifreigaben u. etc. ausgeführt werden. -- Meine Frage nun wie Ihr das handelt, wenn Single-Point-of-Failure und evtl. "nicht supportet" nicht zieht, weil ja noch nie etwas passiert sei? Versucht weiterhin eure Meinung durchzubringen und verweigert das Konstrukt, verdeutlicht Ihr, dass Ihr auf die Konsequenzen hingewiesen habt und geht dem Kunden/Kollegen trotzdem Wunsch nach oder gibt es andere Handlungen die Ihr dann macht/sagt/handhabt? Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Moin, Kunde oder intern? Neben aller Schönheit ist ja durchaus entscheidend, wer die Brötchen bezahlen soll. Wenn "nur so, sonst gar nicht" dazu führt, dass man den Auftrag nicht bekommt, dann hat ja auch niemand was davon. Ich würde da also eine Weile argumentieren und auf Einsicht hoffen, zumal "Wartung" ja nun keinen messbaren Unterschied bringt - wenn ich auf einem Server 12 Anwendungen warten muss oder auf einem Server 10 und auf dem anderen 2, dann ist das gehupft wie gesprungen. Wenn ich so nicht weiterkomme, würde ich schauen, ob es "echte" No-gos gibt (wahrscheinlich nicht). Dass es nicht supported sei, trifft ja so nicht zu, es ist nur nicht schön. Gruß, Nils Zitieren Link zu diesem Kommentar
mwiederkehr 373 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Ob ein DC für sich laufen soll, hängt von der Grösse der Organisation ab. In kleineren Umgebungen stören zusätzliche Rollen wie DHCP oder Print nicht. Wenn es gar nur einen Server gibt, würde es auch nicht helfen, wenn der DC noch verfügbar wäre, der ganze Rest aber nicht. Wichtig: "zusätzliche Rollen", nicht "zusätzliche Software", die man dann irgendwie zurechtbiegt, dass sie auf dem DC läuft. Ich versuche die Sachen immer praktisch und nicht dogmatisch zu sehen. Meist findet man dann eine Lösung, die für beide Seiten einigermassen stimmt. Ansonsten kommt entweder Variante 1 oder 2 zum Zug, je nach Kunde: - Konstrukt verweigern: Bei Kunden, die bei Problemen gerne "vergessen", dass sie auf der Bastellösung bestanden haben. Häufig Leute ohne Entscheidungskompetenz, die sich dann gegenüber ihrem Vorgesetzten raus reden müssen. Also meist bei grösseren Firmen, bei denen man einen schlechten Ruf als Dienstleister bekommt. - Wunsch erfüllen: Bei Kunden, die bei Problemen zu ihrem Wort stehen. Will der Kunde das Admin-PW seines Rechners, damit sein Sohn ein Spiel installieren kann, gebe ich es raus. Zwar ungerne, aber allzu arrogant kann ich nicht sein, schliesslich bezahlt der Kunde mein Gehalt. Dies sind meist kleine Firmen, bei denen der Chef auch Eigentümer ist und somit tun und lassen kann, was er will. Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Ganz klar, Risikoanlyse, business impact analyse und mit mindestens 2 Varianten ab zu den Stakholdern. Man lässt sämtliche "emotionale Bindung" zu dem Thema außen vor, technische Details ebenfalls und lässt diejenigen die das Risiko auch schlussendlich tragen müssen entscheiden. Ist ein Business Case wie fast jede andere Entscheidung in einem Unternhmen auch. Es empfihelt sich das ganze schriftlich festzuhalten, der Schrieb hilft einem dann zwar im Fall eines Incident nicht wahnsinnig viel weiter (da muss Feuer gelöscht werden), aber in der "lessons learned" Phase zaubert man den dann aus dem Hut und lässt das Risiko neu bewerten bzw macht man das ohnehin periodisch. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Moin, lass mich raten, du bewegst dich hauptsächlich im oberen Enterprise-Segment? :D Da mag das durchaus richtig sein. Bei SMB-Kunden wird der prozessuale Aufwand nicht wirtschaftlich sein, da muss dann das Ergebnis reichen (das ja dasselbe ist). Gruß, Nils Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Das ist ein Vorgehen das ich auch privat so verwende, ich wüsste also nicht warum der Einsatz nicht für die One Man Show bis zur globalen Supermacht gelten sollte. Man muss natürlich sein Zielpublikum und das Thema kennen, niemand sagt das diese Analysen hundert Seiten lang sind und man eine wisssenschaftliche Arbeit schreiben muss. Man beschreibt den aktuellen Status, welche Risiken damit verbunden sind, was man empfehlen würde und was da ca an Aufwand reinfließen wird. Das gegenüber muss ehen das man weiß von was man da spricht und wo die Vorteile für das business sind, alles andere kann funktionieren, hat aber keine hohe erfolgsquote, da bräuchte man schon ein sehr technikaffines Publikum das jetzt eben fürs Geld zuständig ist. Zitieren Link zu diesem Kommentar
MurdocX 949 Geschrieben 10. August 2017 Autor Melden Teilen Geschrieben 10. August 2017 Danke schon mal für eure Antworten. Das war schon mal sehr aufschlussreich. Ich denke das ein oder Andere werde ich so oder so ähnlich übernehmen. @Nils Intern ist das manchmal noch mehr ein Kampf wie mit dem Kunden. Diesmal betrifft es beides :rolleyes: Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 (bearbeitet) Moin, @Otaku: so seh ich das auch. :) Gruß, Nils bearbeitet 10. August 2017 von NilsK Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 Wichtig ist, dass KMU-Kunden bei Problemen nicht die Schuld beim IT-Unternehmen suchen. Ich hatte es früher auch mal im Außendienst mit KMU-Kunden zu tun. Kleines Beispiel: Kunde bekam ein kleines Netz, dass in der Werkstatt aufgebaut wurde (die hatten da Plotter und solches Zeug) Der Server stand für jeden zugänglich rum (wir wiesen auf den ungeeigneten Standort hin). Datensicherung haben wir damals nach dem Großvater-Vater-Sohn-Prinzip eingerichtet. Es lief also Montag-Freitag jeweils auf einem neuen Band eine Sicherung. Davon sollten dann div. Bänder im Zyklus aufbewahrt werden. Der Vertrieb hat "erstmal" 5 Bänder verkauft. Ich habe explizit den Kunden darauf hingewiesen, dass er noch weitere Bänder bestellen muss. Ein paar Monate später war neue FIBU derartig verwurschtelt, dass eine 6 Monate alte Sicherung benötigt wurde. 3x dürft Ihr raten, was nicht da war und wer Schuld hatte, dass Montag bis Freitag immer auf die gleichen 5 Bänder gesichert wurde... ;) Heute würde ich alles schriftlich niederlegen und dem Kunden übergeben. -Zahni Zitieren Link zu diesem Kommentar
lefg 276 Geschrieben 10. August 2017 Melden Teilen Geschrieben 10. August 2017 (bearbeitet) Moin Wie der Kunde es wünscht. Das war ein Motto im Vertrieb der alten AEG-Telefunken. Und was der Kunde wünschte, war schriftlich zu vereinbaren. Auch Abweichungen, Änderungs-, Sonderwünsche vor Ort auf der Wartungsreise waren schriftlich niederzulegen und von beiden Seiten zu unterzeichnen. Kinkerlitzschen ausgenommen. Ein SBS mit DC u.v.m. funktioniert doch. Und falls das Blech ausfällt, dann braucht man auch so dringend keinen DC mehr, ein Anmelden am PC auf zugewiesenen Arbeitsplätzen funktioniert dann cached. Ich nervte einen Kunden, dessen Beauftragten oder auch einen internen Leiter/Entscheider nicht in rabulistischer Manier. Ich äusserte auf Meetings nicht immer wieder die selben Warnhinweise. bearbeitet 10. August 2017 von lefg Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.