ITSM EN2

Sehr gute Unternehmen können Beschaffungen direkt Abschreibungen. Dies zeigt, dass das Unternehmen eine gute Ertragslage hat. Durch die sofortige Abschreibung werden stille Reserven gebildet. (Nutzungszeit grösser als Abschreibungszeit). Zusätzlich wird der Aufwand grösser und dadurch einen kleiner Gewinn ausgewiesen (Steueroptimie-
rung).

• Keine Investitionen
• Hardware, Sofare, Betrieb, Wartung ist in der Subscription einkalkuliert
• Hohe Flexibilität, da das Unternehmen Subscription monatlich / jährlich kündigen
  kann

Höhere Anforderungen in SLA und OLA’s führen zu höheren Kosten. Vor allem folgenden Anforderungen sind grosse Kostentreiber:

• Verfügbarkeit der Services (>95% / Jahr)
• Redundanzen (n+ 1, n+ 2)
• Erreichbarkeit des Supports (7x24, NBD)
• Reaktionszeit des Supports (1h, 4h, 8h)
• Anzahl Wartungsfenster pro Jahr
• Anzahl Mitarbeitern (Know-How und Ausbildungsstand)

• Alle Changes sind per Default normale, nicht vorab genehmigte Changes.
• Jeder Change ist ohne Ausnahme zu dokumentieren und zu beantragen.
• Die System- und Applikationsverantwortlichen verantworten alle Changes.
• Jedes System / jede Applikation hat ein jährliches Change Budget ($ & PT).
• Das Change Architecture Board ist alleinverantwortlich für Genehmigungen.
• Emergency Changes setzen eine dokumentierte Zwangslage voraus.
• Emergency Changes werden nachtäglich beantragt und genehmigt.
• Missbräuchliche Verwendung von Emergency Changes wird sanktioniert.

• Wurden alle betroffenen Betriebsmitarbeiter schon migriert?
• Sind alle Betriebsmitarbeiter ausreichend geschult?
• Ist der Helpdesk besonders sensibilisiert und geschult worden?
• Kann der Helpdesk gesonderte Statistiken zu Fehlerfällen mit dieser Migration anlegen,
• die dem Management zur Verfügung steht?
• Kann der Helpdesk auf eine Datenbank mit bekannten Lösungen für diese Migration zurückgreifen oder eine solche Datenbank aufbauen?
• Kann der Helpdesk im Bedarfsfall Support-Mitarbeitende "vor Ort" einsetzen?
• Sind kritische Betriebsprozesse oder Benutzer betroffen und gibt es für diese im Notfall eine Ausweichlösung?
• Ist der Hersteller in die Problemlösung integriert (2nd / 3rd Level Support)?
• Wie lange währt der early life support"?
• Wer trägt die innerbetrieblichen Zusatzkosten?

Zusätzlich Checkliste Verhalten IT-Mitarbeitende:

• Der Change war geplant und getestet!, er wird eingeführt auf Wunsch des Kunden
• Wo liegen allfällige FAQ (wer pflegt diese)?
• Soll man selbst helfen (und in welchem Umfang)?
• Alles Meldungen zum Helpdesk (Trouble Ticket) für Statistiken)
• "Hot Spots" melden (z.B. unzufriedene VIP)
• Zusatzaufwand erfassen
• Diskussionen über Sinn & Zweck vermeiden / weitergeben (an wen?), auch innerhalb
der IT)

• Server & Storage: 90'000
• Neztwerk: 50'000
• ERP System: 40'000
• SW-Subscriptions: 25'000
• Arbeitsplatz Hardware: 42'000 (41,666.6)
• Drucker: 6000 (5600)
• Verbrauchsmaterial: 35'000
• Lohnkosten: 390'000 (2x 120kCHF + 1x 130kCHF)
• Total Budegt pro Jahr: 678'000

• Es wurd nicht nur der Anschaffungspreis sondern auch die überigen Kosten wie Unterhalt, Wartung, Verbrauch und Support berücksichtigt.
• Bei Anschaffungen die bereits vorhandene Ressourcen nutzen kann auch deren Preis berücksichtig werden.
• Mit einer vorbereiteten TCO kann man auch spielen und schauen wie sich die Kosten bei längeren / kürzeren Laufzeiten verhalten.

• Hardware für Server: Hardware für die VM's muss beschafft oder eingemietet werden -> Anschaffungskosten
• Hardware für Netzwerk: Anschaffungskosten
• Virtualisierungssoftware Lizenz: Hypervisor lösung ist notwendig -> Anschaffungskosten
• Stromkosten der Hardware: Betriebskosten
• Wartungskosten (jährlich): Betriebskosten

Jahres Plus = 3 Mio - 1.8 Mio - 500k = 700k

Zeit bis Zurückerwirtschaftet bei 0% Zins = 1.5 Mio / 700k = ~ 2.14 Jahre

ROI auf 5 Jahre = (700k * 5)  / 1.5 Mio = 2,33

Ein grosser Anteil der Kosten wie Wartung und Beschaffung von Hardware werden nicht mehr Hausintern anfallen. Die Lonkosten werden zu Lizenzgebühren.
Ebenfalls kommt es bei Dingen wie E-Mail Service zu einer Ressourcen bündelung. viele Betriebe zusammen können sich Spezialisten und Know-How leisten welches sie einzeln nicht haben könnten.

• Comliance -> Datenspeicherung separiert Aushandeln oder entsprechende SLAs vereinaberen
• Lizenzkosten steigen aufgrund anstiegs der Anbieter -> Fallback Strategie oder Ausweichplattform definieren. Eine Anwendung sollte nicht zu stark von einem einzelen Anbieter abhängig sein.
• Datenschutz -> Daten nur verschlüsselt in der Cloud halten. Schlüsselmanagement im eigenen Unternehmen.
• Wettbewerbs Nachteile -> Standard Lösungen aus der Cloud reichen nicht zum differenzieren -> selber entwickeln
• Know How Verlust -> Kritische Applikationen in House behalten damit bei Problemen besser reagiert werden kann

• Ressourcen Bündelung
• Konzentration auf Kerngeschäft
• Verteiltes Arbeiten möglich
• Infrastruktur Verlust wir unwahrscheinlich (Feuer im Betrieb)
• Standardlösungen für Branchen -> keine eigen Entwicklung nötig.

Mischung aus Private und Public Clouds. Sie sind sinnvoll, wenn man sowohl Services welche in der Private Cloud sinvoll sind als auch solche welche besser in der Public cloud sind. z.B. Dateiablage auf lokalem Server und E-Mail Anwendung

1. IT-Verantwortlicher Pflichtenheft
2. Starke Passwörter
3. Software aktuell halten
4. Anti-Viren Programm regekmässig Updaten
5. Mobile Geräte schützen
6. IT Nutzungsrichtlinien allen Mitarbeiter bekannt machen.
7. Zugang zu Infrastruktur kontrollieren / einschränken
8. Ordnung halten im Daten Management (klare Struktur)
9. Firewall einsetzen
10. Übersicht über infrastruktur und Datenbestand

Häufig werden Social Engineering attacken eingesetzt. Diese Zielen auf den Mensch als Schwachpunkt und umgehen so die technischen Sicherheitsvorkehrungen.

Geschickte Hackerangriffe setzen Schadsoftware ein die noch keine bekannten Signaturen haben und daher nicht entdeckt werden.

Die Digitalisierung bietet im Detailhandel durch den Einsatz von IT-Technologien die folgenden Chancen:

• Aufbau und Betrieb eines online Shops für die Erschliessung eines zusätzlichen
  Absatzkanals
• Gezielte Verkaufsförderung durch User Tracking in den Läden und präsentieren
  von passenden Angeboten
• Optimieren der Logistikprozesse durch den Einsatz von Technologien
• Usw.

Auf den System sammeln sich keine Altlasten durch vorherige Updates und Patches an.
Falls ein Software Update nicht korrekt installiert werden kann, muss der Fehler nicht
aufwendig untersucht und behoben werden.

• Leiter Datacenter Services
  • Network
  • Storage
  • Server
  • Firewalls
• Leiter Business Applikationen
• IT-Leiter (Optional)
• Security Officer
• Compliance Officer

Das Release Management hat das Ziel eine proaktive Release Planung zu implementieren. Dabei geht es darum, dass ein neuer Software Release getestet und eingeführt wird.

Das Change-Management hat das Ziel vor allem Konfigurationsänderungen koordiniert
zu planen und durchzuführen. Zu einer Konfigurationsänderung kann das Anpassen einer Konfiguration gehören, sowie das Aktualisieren von einzelnen Softwarekomponenten.

Das Change-Management wird oft auf dem Incident- und Problem-Management getriggert (reaktiv).

Neue Software Release können mit Hilfe der CI/CD Pipeline automatisiert bereitgestelltwerden. Die Chance ist dabei relativ hoch, dass diese Software Release nicht vollständig getestet werden und «halbfertige» Release in die Produktion überführt werden.

Zudem kann ein Freigabeprozess nur bedingt eingeführt werden. Vor allem im Banken Umfeld muss nachvollziehbar sein, welcher Software Release zu welchem Zeitpunkt auf den produktiven Systemen eingesetzt worden ist.

Für Applikationen, die agil entwickelt und betrieben werden müssen. Vor allem Applikationen die einen hohen Kundenbezug haben, wo rasch und effizient auf neue Marktgegebenheiten reagiert werden muss. (>12 Release pro Jahr)

Incident:

• Eingrenzbarer Vorfall (ein Benutzer betroffen)
• Kann in der Regel durch den 1st Level Support behoben werden
• Dokumentierte Lösungsbehebung vorhanden
• Lösungsbehebungszeit innerhalb eines gewissen Schellwertes

Problem

Ein Incident wird zum Problem, wenn eines der folgenden Kriterien erfüllt ist:

• Incident nicht innerhalb einer gewissen Zeit lösbar
• Kein dokumentierter Lösungsbehebungsprozess vorhanden
• Mehrere Incidents zum gleichen Thema vorhanden
• Grosser Impact für einen Service oder mehrere Benutzer
• Incident kann aktuell nur über einen Workaround behoben werden

• Benutzer (inklusive Kontaktdaten: E-Mail, Telefon)
• Titel des Problems
• Beschreibung des Problems
• Asset oder CI-Informationen, wo das Problem auftritt
• Auswirkung (Service beeinträchtigt, Service nicht mehr nutzbar, komplett Ausfall)

Incident nicht innerhalb von 2h lösbar oder mehrere Incidents zum gleichem Thema
von verschiedenen Benutzer vorhanden

Alle gefunden Lösungen müssen als Change Request (RFC) über den Change-Management Prozess umgesetzt werden. Das CAB priorisiert und beurteilt die einzelnen Change Requests.

CAPEX: Anschaffung Hard- und Software

OPEX: Wartung, Mitarbeiter, laufende Infrastrukturkosten

• who raised it
• for what reason
• what is the return (i.e. why are we doing this?)
• what are the perceived risks
• what resources do we need / have
• who is responsible for building, testing etc.
• what relationship exists to other changes

Einhaltung der Projektziele im vorgegeben Zeit- und Kostenrahmen.

• Usability
• Antwortzeitverhalten
• Einhalten Kosten- und Zeitrahmen
• Sourcecode Qualität
• Fehlerfreie Applikation durch Tests

Anforderungen nicht klar
Wechselnde Anforderungen während dem Projekt
Zu grosse Ziele
Zuständigkeiten nicht klar definiert
Einsatz komplexer und nicht erprobter Technologien