Jump to content

Argumentation hin oder her, aber wie richtig reagieren?


MurdocX
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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?
Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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 von lefg
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...