Affärsåtagande inom molnhantering

  • Artikel

Att definiera affärsåtaganden är en övning i att balansera prioriteringar. Målet är att anpassa driftsledningen till en acceptabel driftskostnad. För att hitta den balansen krävs några datapunkter och beräkningar, som vi har beskrivit i den här artikeln.

Balansera kostnader och återhämtning

Åtaganden om affärsstabilitet, via teknisk återhämtning eller andra effekter på servicenivåavtal (SLA), är ett affärsmotiveringsbeslut. För de flesta arbetsbelastningar i en miljö räcker det med en baslinjenivå för molnhantering. För andra är en 2x till 4x kostnadsökning lätt motiverad på grund av den potentiella effekten av eventuella verksamhetsavbrott.

Föregående artiklar i den här serien kan hjälpa dig att förstå klassificeringen och effekten av avbrott i olika arbetsbelastningar. Den här artikeln hjälper dig att beräkna returerna. Som illustreras i föregående bild har varje nivå av molnhantering brytpunkter där kostnaden kan öka snabbare än ökningar av återhämtning. Dessa brytpunkter kommer att leda till detaljerade affärsbeslut och affärsåtaganden.

Fastställ ett korrekt åtagande med verksamheten

För varje arbetsbelastning i portföljen bör molndriftsteamet och molnstrategiteamet anpassa sig till den hanteringsnivå som tillhandahålls direkt av molndriftsteamet.

När du etablerar ett åtagande för verksamheten finns det några viktiga aspekter att anpassa:

  • Krav för IT-åtgärder.
  • Ledningsansvar.
  • Molninnehavare.
  • Faktorer med mjuk kostnad.
  • Förlust undvikande ROI.
  • Validering av hanteringsnivå.

För att underlätta beslutsprocessen beskriver resten av den här artikeln dessa aspekter i detalj.

Krav för IT-åtgärder

Azure-hanteringsguiden beskriver de hanteringsverktyg som är tillgängliga i Azure. Innan du når ett åtagande med verksamheten bör IT fastställa en acceptabel baslinje för hantering på standardnivå som ska tillämpas på alla hanterade arbetsbelastningar. IT skulle sedan beräkna en standardkostnad för hantering för var och en av de hanterade arbetsbelastningarna i IT-portföljen, baserat på antalet PROCESSORkärnor, diskutrymme och andra tillgångsrelaterade variabler. IT skulle också uppskatta ett sammansatt serviceavtal för varje arbetsbelastning baserat på arkitekturen.

Tips

IT-driftsteam använder ofta en standardtid på minst 99,9 procent för det ursprungliga sammansatta serviceavtalet. De kan också välja att normalisera hanteringskostnader baserat på den genomsnittliga arbetsbelastningen, särskilt för lösningar med minimala loggnings- och lagringsbehov. Medelvärdet av kostnaderna för några arbetsbelastningar med medelhög allvarlighetsgrad kan vara en startpunkt för inledande konversationer.

Tips

Om du använder arbetsboken för drifthantering för att planera för molnhantering bör fälten för drifthantering uppdateras för att återspegla dessa krav. Dessa fält omfattar åtagandenivå, sammansatt serviceavtal och månadskostnad. Månadskostnaden bör representera kostnaden för de extra drifthanteringsverktygen månadsvis.

Baslinjen för drifthantering fungerar som en första startpunkt som ska verifieras i vart och ett av följande avsnitt.

Ledningsansvar

I en traditionell lokal miljö antas kostnaden för att hantera miljön vanligtvis vara en lägre kostnad som ägs av IT-driften. I molnet är hantering ett målmedvetet beslut med direkt budgetpåverkan. Kostnaderna för varje hanteringsfunktion kan mer direkt tillskrivas varje arbetsbelastning som distribueras till molnet. Den här metoden ger bättre kontroll, men den skapar ett krav för molndriftsteam och molnstrategiteam att först åta sig ett avtal om ansvarsområden.

Organisationer kan också välja att outsourca några av sina pågående hanteringsfunktioner till en tjänstleverantör. Dessa tjänstleverantörer kan använda Azure Lighthouse för att ge organisationer mer exakt kontroll över att ge åtkomst till sina resurser, tillsammans med bättre insyn i de åtgärder som utförs av tjänstleverantörerna.

  • Delegerat ansvar: Eftersom det inte finns något behov av att centralisera och anta driftshanteringskostnader överväger IT-verksamheten för många organisationer nya metoder. En vanlig metod kallas delegerat ansvar. I en modell för utmärkthet i molnet tillhandahåller plattformsdrift och plattformsautomatisering självbetjäningsverktyg som kan användas av affärsledda driftsteam, oberoende av ett centraliserat IT-driftteam. Den här metoden ger affärsintressenter fullständig kontroll över hanteringsrelaterade budgetar. Det gör det också möjligt för CCoE-teamet (Cloud Center of Excellence) att se till att en minsta uppsättning skyddsräcken har implementerats korrekt. I den här modellen fungerar IT som mäklare och en guide som hjälper företaget att fatta kloka beslut. Verksamheten övervakar den dagliga driften av beroende arbetsbelastningar.

  • Centraliserat ansvar: Efterlevnadskrav, teknisk komplexitet och vissa delade tjänstmodeller kan kräva en central IT-teammodell . I den här modellen fortsätter IT att utöva sitt ansvar för driftshantering. Miljödesign, hanteringskontroller och styrningsverktyg kan hanteras och kontrolleras centralt, vilket begränsar affärsintressenternas roll när det gäller att göra förvaltningsåtaganden. Men insynen i kostnaden och arkitekturen för molnmetoder gör det mycket enklare för centraliserad IT att kommunicera kostnaden och hanteringsnivån för varje arbetsbelastning.

  • Blandad modell: Klassificering är kärnan i en blandad modell för hanteringsansvar. Företag som håller på att transformeras från lokalt till molnet kan behöva en lokal driftsmodell ett tag. Företag med strikta efterlevnadskrav, eller som är beroende av långsiktiga kontrakt med IT-outsourcingleverantörer, kan kräva en centraliserad driftsmodell.

    Oavsett deras begränsningar måste dagens företag förnya sig. När snabb innovation måste blomstra, mitt i en central IT-modell med centraliserat ansvar, kan en metod med blandade modeller ge balans. Med den här metoden tillhandahåller ett centralt IT-team en centraliserad driftsmodell för alla arbetsbelastningar som är verksamhetskritiska eller innehåller känslig information. Samtidigt kan alla andra arbetsbelastningsklassificeringar placeras i en molnmiljö som är utformad för delegerade ansvarsområden. Den centraliserade ansvarsmetoden fungerar som den allmänna driftsmodellen. Företaget har sedan flexibilitet att införa en specialiserad driftsmodell, baserat på den supportnivå och känslighet som krävs.

Det första steget är att åta sig ett ansvarstagande, som sedan formar följande åtaganden.

Vilken organisation ansvarar för den dagliga driftshanteringen för den här arbetsbelastningen?

Molntjänster

För de flesta företag är hantering enklare när alla tillgångar finns i en enda klientorganisation. Vissa organisationer kan dock behöva underhålla flera klientorganisationer. Information om varför ett företag kan kräva en Azure-miljö med flera klientorganisationer finns i Centralisera hanteringsåtgärder med Azure Lighthouse.

Kommer den här arbetsbelastningen att finnas i en enda Azure-klient, tillsammans med alla andra arbetsbelastningar?

Faktorer med mjuk kostnad

I nästa avsnitt beskrivs en metod för jämförande avkastning som är associerad med nivåer av hanteringsprocesser och verktyg. I slutet av avsnittet mäter varje analyserad arbetsbelastning kostnaden för hantering i förhållande till prognosens inverkan av affärsstörningar. Den metoden är ett relativt enkelt sätt att förstå om en investering i rikare förvaltningsmetoder är berättigad.

Innan du kör siffrorna är det viktigt att titta på faktorerna med mjuka kostnader. Mjukt kostnadsfaktorer ger en avkastning, men den avkastningen är svår att mäta genom direkta kostnadsbesparingar som skulle vara synliga i en resultaträkning. Faktorer med mjuka kostnader är viktiga eftersom de kan tyda på ett behov av att investera i en högre förvaltningsnivå än vad som är skattemässigt försiktigt.

Några exempel på faktorer med mjuk kostnad är:

  • Daglig arbetsbelastningsanvändning av styrelsen eller VD.
  • Arbetsbelastningens användning av de översta x % av kunderna som leder till en större intäktspåverkan någon annanstans.
  • Påverkan på medarbetarnas nöjdhet.

Nästa datapunkt som krävs för att göra ett åtagande är en lista över faktorer med mjuka kostnader. Dessa faktorer behöver inte dokumenteras i det här skedet, men affärsintressenter bör vara medvetna om vikten av dessa faktorer och deras exkludering från följande beräkningar.

Beräkna förlust undvikande ROI

När den beräknar den relativa avkastningen på operations management-kostnader bör IT-teamet som ansvarar för molndriften uppfylla de tidigare nämnda förutsättningarna och anta en lägsta hanteringsnivå för alla arbetsbelastningar.

Nästa åtagande som ska göras är att företaget accepterar de kostnader som är kopplade till det baslinjehanterade erbjudandet.

Går företaget med på att investera i baslinjeerbjudandet för att uppfylla minimikraven för molndrift?

Om företaget inte accepterar den nivån av hantering måste en lösning utformas som gör det möjligt för företaget att fortsätta, utan att väsentligen påverka molndriften för andra arbetsbelastningar.

Om företaget vill ha mer än standardhanteringsnivån hjälper resten av det här avsnittet till att verifiera investeringen och tillhörande avkastning (i form av undvikande av förlust).

Ökad hanteringsnivå: Designprinciper och tjänstkatalog

För hanterade lösningar kan flera designprinciper och malllösningar tillämpas utöver baslinjen för hantering. Var och en av designprinciperna för tillförlitlighet och återhämtning ökar driftskostnaden för arbetsbelastningen. För att IT och företaget ska komma överens om dessa ytterligare åtaganden är det viktigt att förstå potentiella förluster som kan undvikas genom den ökade investeringen.

Följande beräkningar går igenom formler som hjälper dig att bättre förstå skillnaderna mellan förluster och ökade förvaltningsinvesteringar. Vägledning om hur du beräknar kostnaden för ökad hantering finns i Arbetsbelastningsautomatisering och Plattformsautomatisering.

Tips

Om du använder arbetsboken för drifthantering för att planera för molnhantering uppdaterar du fälten för drifthantering så att de återspeglar varje konversation. Dessa fält omfattar åtagandenivå, sammansatt serviceavtal och månadskostnad. Månadskostnaden bör representera månadskostnaden för de extra verktygen för driftshantering. När de har uppdaterats uppdaterar fälten ROI-formler och vart och ett av följande fält.

Uppskatta avbrott (timmar per år)

Sammansatt serviceavtal är det serviceavtal som baseras på distributionen av varje tillgång i arbetsbelastningen. Det fältet kör uppskattat avbrott (märkt Est.Outage i arbetsboken). Använd följande formel för att beräkna uppskattat avbrott i timmar per år utan att använda arbetsboken:

Uppskattat avbrott = (1 – sammansatt SLA-procent) × antal timmar under ett år

Arbetsboken använder standardvärdet 8 760 timmar per år.

Standardförlustpåverkan

Standardförlustpåverkan (märkt Standard Impact i arbetsboken) förutser den ekonomiska effekten av eventuella avbrott, förutsatt att den uppskattade avbrottets förutsägelse visar sig vara korrekt. Använd följande formel för att beräkna den här prognosen utan att använda arbetsboken:

Standardeffekt = uppskattat avbrott vid tre 9-dagars drifttid × tidsvärdepåverkan

Detta fungerar som baslinje för kostnader om affärsintressenterna väljer att investera i en högre hanteringsnivå.

Påverkan på sammansatt serviceavtal

Komposit-SLA-påverkan (märkt Commitment level impact i arbetsboken) ger uppdaterad skattepåverkan, baserat på ändringarna i serviceavtalet för drifttid. Med den här beräkningen kan du jämföra de beräknade ekonomiska effekterna av båda alternativen. Använd följande formel för att beräkna prognoseffekten utan kalkylbladet:

Påverkan på sammansatt serviceavtal = uppskattat avbrott × tidsvärdespåverkan

Värdet representerar de potentiella förluster som kan undvikas av den ändrade åtagandenivån och det nya sammansatta serviceavtalet.

Jämförelsebas

Jämförelsebasen utvärderar standardpåverkan och sammansatt SLA-påverkan för att avgöra vilken som är lämpligast i returkolumnen.

Retur vid förlustundandragande

Om kostnaden för att hantera en arbetsbelastning överskrider de potentiella förlusterna är den föreslagna investeringen i molnhantering kanske inte givande. Om du vill jämföra Return on Loss Avoidance(Returnera vid förlustundandragande) läser du kolumnen med etiketten Årlig ROI****. Om du vill beräkna den här kolumnen på egen hand använder du följande formel:

Avkastning på förlustundandragande = (jämförelsebas - (månadskostnad × 12) ) ÷ (månadskostnad × 12) )

Om det inte finns andra faktorer för mjuk kostnad att tänka på kan den här jämförelsen snabbt föreslå om det ska finnas en djupare investering i molndrift, återhämtning, tillförlitlighet eller andra områden.

Verifiera åtagandet

Vid den här tidpunkten i processen har åtaganden gjorts: centraliserat eller delegerat ansvar, Azure-innehav och åtagandenivå. Varje åtagande bör verifieras och dokumenteras för att säkerställa att molndriftsteamet, molnstrategiteamet och affärsintressenterna är anpassade efter det här åtagandet för att hantera arbetsbelastningen.

Nästa steg

När åtagandena har gjorts kan de ansvariga åtgärdsteamen börja konfigurera arbetsbelastningen i fråga. Kom igång genom att utvärdera olika metoder för inventering och synlighet.

Alternativ för inventering och synlighet