Zum Inhalt wechseln


Foto

Argumentation hin oder her, aber wie richtig reagieren?


  • Bitte melde dich an um zu Antworten
9 Antworten in diesem Thema

#1 MurdocX

MurdocX

    Board Veteran

  • 584 Beiträge

 

Geschrieben 10. August 2017 - 09:00

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?

Mit freundlicher Unterstützung
Jan


#2 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 10. August 2017 - 09:10

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#3 mwiederkehr

mwiederkehr

    Junior Member

  • 158 Beiträge

 

Geschrieben 10. August 2017 - 09:17

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.



#4 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 10. August 2017 - 09:32

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.


Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#5 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 10. August 2017 - 09:35

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


Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#6 Otaku19

Otaku19

    Expert Member

  • 1.948 Beiträge

 

Geschrieben 10. August 2017 - 10:34

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.


Done: 640-801; 640-553; 642-524; 642-515; 642-892; 642-832; 642-504; 640-863; 642-627; 642-874; 642-785; ITIL v3 Foundation
Enterasys Systems Engineer; CompTIA Sec+; CompTIA Mobility+; CISSP; CISSP-ISSAP; Barracuda NGSE/NGSX; CISM


#7 MurdocX

MurdocX

    Board Veteran

  • 584 Beiträge

 

Geschrieben 10. August 2017 - 10:39

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:


Mit freundlicher Unterstützung
Jan


#8 NilsK

NilsK

    Expert Member

  • 12.401 Beiträge

 

Geschrieben 10. August 2017 - 10:39

Moin,

 

@Otaku: so seh ich das auch. :)

 

Gruß, Nils


Bearbeitet von NilsK, 10. August 2017 - 10:39.

Nils Kaczenski

MVP Cloud and Datacenter Management
... der beste Schritt zur Problemlösung: Anforderungen definieren!

Kostenlosen Support gibt es nur im Forum, nicht privat!


#9 zahni

zahni

    Expert Member

  • 16.474 Beiträge

 

Geschrieben 10. August 2017 - 11:11

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


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#10 lefg

lefg

    Expert Member

  • 20.495 Beiträge

 

Geschrieben 10. August 2017 - 12:25

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, 10. August 2017 - 12:47.

Das Messbare messen, das Nichtmessbare messbar machen. Galilei.

 

Diskutiere nicht mit ***en, denn sie ziehen dich auf ihr Niveau und schlagen dich dort mit Erfahrung! (Hab ich bei Tom abgeguckt)

 

Koinzidenz begründet keine Korrelation und ist kein Beweis für Kausalität. (Hab ich bei Daniel abgeguckt) https://de.wikipedia...rgo_propter_hoc

 

Absolutistischer“ Geschäftsführungs-Dogmatismus, der jedwede Empirie aus der „Werkstatt“ schlichtweg ignoriert , führt eben zumeist früher als später ….  (Hab ich von Klabautermann)