Liiketoiminnan jatkuvuussuunnitelman kehittäminen Salesforcen käyttökatkoksia varten

Kello 9.10 Northstar Office Supplyn myyntitiimi yrittää avata Salesforcea ja saa palveluvirheen. Uusia tilauksia saapuu sähköpostitse, asiakaspalvelun työntekijät eivät näe tilitietoja ja integraatio, joka lähettää tilauspäivityksiä varastoon, yrittää uudelleen taustalla. Kukaan ei vielä tiedä, kestääkö häiriö viisi minuuttia vai loppupäivän.

Havainnollistava skenaario: Northstar Office Supply on kuvitteellinen yritys, jota käytetään koko artikkelissa. Se ei ole asiakaspalaute, tapausraportti tai testitulos. Esimerkki osoittaa, kuinka todellinen organisaatio voisi muuttaa liiketoiminnan jatkuvuuden käsitteet toimintasuunnitelmaksi.

Hyödyllinen Salesforcen seisokkiaikasuunnitelma ei takaa, että kaikki prosessit jatkuvat normaalisti. Se määrittelee, minkä työn on jatkettava, mikä työ voi odottaa, miten ihmiset kommunikoivat, miten integraatioita hallitaan ja miten tietueet täsmäytetään palautumisen jälkeen. Tämä opas käyttää ajantasaista Salesforce-dokumentaatiota, joka on tarkistettu 16. syyskuuta 2026, sekä NIST:n varautumissuunnitteluohjeita. Tuotenimet, ominaisuudet, saatavuus, sopimukset ja palvelusitoumukset voivat muuttua, joten vahvista oma Salesforce-versiosi ja -sopimuksesi.

Mitä on muuttunut Salesforcen jatkuvuussuunnittelussa?

Salesforcen nykyinen liiketoiminnan jatkuvuussuunnitelma tekee tärkeän eron palveluntarjoajan jatkuvuusohjelman ja asiakkaan oman liiketoiminnan jatkuvuussuunnitelman välillä. Salesforcen 23. heinäkuuta 2026 päivitetty Enterprise Resilience/BCP -yhteenveto kuvaa palveluntarjoajatason ohjelmia riskienhallintaa, liiketoiminnan jatkuvuutta, kriisinhallintaa, kolmansien osapuolten riskejä, kyberturvallisuusriskiä, ​​tapausten hallintaa ja katastrofien jälkeistä palautumista varten. Se ei korvaa asiakkaan suunnitelmaa henkilöstöresurssien, manuaalisen työn, asiakasviestinnän, integraatioiden tai tietojen täsmäytyksen osalta.

Toinen ajankohtainen muutos on 9. syyskuuta 2026 julkaistu Salesforce-ohjesivu Advanced Cross-Region Continuity (ACRC) -ratkaisulle. Salesforcen mukaan ACRC on premium-tason Hyperforce-tarjous poikkeuksellisiin alueellisiin katastrofeihin ja että sen nimi on muutettu Out of Region Disaster Recovery -palvelusta. Sivulla luetellaan ACRC:n RTO- ja RPO-tavoitteet 12 tuntia ja 4 tuntia, todetaan, että joitakin palveluita ei vielä tueta, ja todetaan, että sandbox-organisaatioita ei tueta. Näillä tiedoilla voi olla merkitystä, jos vanhempi runbook viittaa aiempaan tuotenimeen tai olettaa, että maksullinen palautusvaihtoehto suojaa kaikkia organisaatioita ja ominaisuuksia.

Useimmille yrityksille käytännön lähtökohtana on asiakkaan omistama suunnitelma, joka toimii tavallisen Salesforce-palveluhäiriön, suunnitellun huoltoikkunan, identiteettivian, verkko-ongelman tai integraatiokatkoksen aikana. Palveluntarjoajan palautusominaisuus voi vähentää riskiä; se ei voi päättää liiketoimintasi prioriteetteja puolestasi.

Mitä suunnitelman tulisi saavuttaa?

Kirjoita tulos operatiivisesti. Northstarin tavoite voisi olla: ”Salesforcen käyttökatkoksen aikana pitää kiireelliset asiakaspyynnöt, tilaussitoumukset ja varaston luovutukset liikkeessä; estää päällekkäiset toimitukset; tiedottaa tilasta 30 minuutin välein; ja täsmäyttää kaikki väliaikaiset tietueet palveluiden palautusten jälkeen.” Tämä lause on hyödyllisempi kuin ”ylläpitää Salesforcen saatavuus”, koska jälkimmäinen on enimmäkseen asiakkaan hallinnan ulkopuolella.

Jatkuvuussuunnitelman tulisi antaa tiimille mahdollisuus vastata nopeasti viiteen kysymykseen:

• Mitkä liiketoimintatoiminnot ovat kriittisiä seuraavan tunnin, päivän ja viikon aikana?
• Millä tilapäisellä menetelmällä kukin kriittinen toiminto suoritetaan?
• Kuka voi ilmoittaa kiertotavan, hyväksyä poikkeukset ja pysäyttää automaation?
• Mitä tietoja saattaa puuttua, olla vanhentuneita, kopioituja tai epäjärjestyksessä?
• Miten tiimi varmistaa, että normaali toiminta on turvallista jatkaa?

NIST kuvailee varautumissuunnittelua koordinoiduksi strategiaksi, joka koostuu suunnitelmista, menettelyistä ja teknisistä toimenpiteistä tietojärjestelmien, toimintojen ja datan palauttamiseksi häiriön jälkeen. Sen ohjeistuksessa korostetaan järjestelmien ja toimintojen arviointia vaatimusten ja prioriteettien määrittämiseksi. Käytä tätä ajatusta suunnittelukehyksenä, mutta räätälöi kontrollit Salesforce-tuotteidesi, prosessiesi, sopimustesi ja riskinsietokykysi mukaan.

Miten kriittiset Salesforce-prosessit tulisi tunnistaa?

Aloita liiketoimintavaikutusten analyysillä, älä Salesforce-objektien listalla. Haastattele prosessien omistajia myynnistä, palvelusta, talousosastolta, toimitus-, vaatimustenmukaisuus- ja IT-osastolta. Kysy, mikä pysähtyy, jos Salesforce ei ole käytettävissä, mitä voidaan suorittaa olemassa olevasta lähteestä ja mikä muuttuu vaaralliseksi, jos se syötetään myöhemmin ilman kontrollia.

Northstarin ensimmäinen inventaario voisi näyttää tältä:

Älä tallenna arkaluonteisia asiakastietoja improvisoituun henkilökohtaiseen laskentataulukkoon tai keskusteluketjuun. Määritä hyväksytty väliaikainen tallennustila, käyttöoikeusluettelo, säilytysaika ja poistomenettely. Jos manuaalinen lomake on välttämätön, kerää vain tarvittavat tiedot kriittisen prosessin pyörittämiseksi.

Mitkä toipumistavoitteet tulisi kirjata muistiin?

Anna jokaiselle kriittiselle prosessille palautumisaikatavoite (RTO) ja palautumispistetavoite (RPO). RTO tarkoittaa sitä, kuinka nopeasti prosessi tarvitsee käyttökelpoisen kiertotavan tai palautetun palvelun. RPO tarkoittaa sitä, kuinka paljon viimeaikaista dataa yrityksellä on varaa menettää tai luoda uudelleen. Nämä ovat liiketoimintapäätöksiä, eivät arvauksia siitä, kuinka nopeasti Salesforce ratkaisee ongelman.

Northstar saattaa asettaa yhden tunnin palautusajan kiireellisille asiakastapauksille, neljän tunnin palautusajan varaston luovutuksille ja yhden arkipäivän palautusajan rutiininomaisille myyntiputken päivityksille. Se saattaa asettaa maksun valtuutuspäätökselle nollan palautusajan, mutta hyväksyy samalla, että rutiininomaiset myyntilaskut on syötettävä uudelleen aikaleimatusta väliaikaisesta lokista. Luvut ovat kuvitteellisia esimerkkejä; talous-, laki- ja operatiivisten omistajiesi on hyväksyttävä tavoitteet.

Dokumentoi jokaisen tavoitteen taustalla oleva oletus. Tunnin mittainen palautus voi vaatia miehitetyn puhelinjonon, koulutetun päivystävän esimiehen ja ennalta hyväksytyn lomakkeen. Jos näitä resursseja ei ole saatavilla viikonloppuisin, tavoite ei ole suunnitelma – se on pyrkimys.

Mitä pitäisi tehdä, kun epäillään seisokkiaikaa?

Määrittele lyhyt aktivointimenettely, jotta työntekijät eivät improvisoi erilaisia ​​​​vastauksia. Ensimmäisen ongelman huomaavan henkilön tulee kirjata UTC-aika, ongelmaan liittyvät käyttäjät, ongelmaan liittyvät tuotteet, virheilmoitus ja liiketoimintaprosessi. Tapauksen johtaja tarkistaa sitten, onko ongelma laaja-alainen vai paikallinen.

Salesforcen Trust-sivusto tarjoaa reaaliaikaista ja historiallista tietoa tuotteiden ja instanssien saatavuudesta ja suorituskyvystä. Sen nykyiset ohjeet selittävät, miten instanssi tunnistetaan kohdasta Asetukset > Yrityksen tiedot tai hakemalla Oma toimialue -etuliitettä, ja miten tilavärit tulkitaan: vihreä tarkoittaa käytettävissä olevaa, keltainen palvelun heikkenemistä, violetti ylläpitoa ja punainen palvelun keskeytystä. Salesforce suosittelee myös Trust-ilmoitusten lähettämistä ja kehottaa ottamaan yhteyttä tukeen, kun ydinongelma on näkynyt sivustolla yli 10 minuuttia.

Luottamus on olennainen todiste, mutta selkeä tilasivu ei todista, että oma verkkosi, identiteetintarjoajasi, selaimesi, API-tunnistetietosi tai integraatiopäätepisteesi on kunnossa. Northstarin tulisi testata toinen käyttäjä, toinen verkko ja matalan riskin vain luku -toiminto, jos käytäntö sen sallii. Jos vain yksi toimisto vaikuttaa, koko yrityksen kattavan manuaalisen prosessin aktivointi voi aiheuttaa tarpeetonta työtä.

Miten tilapäisen käyttötilan tulisi toimia?

Kutsu kiertotapaa nimetyksi tilaksi, kuten ”Salesforcen heikentyneet toiminnot”, ja määritä sen aloitus- ja lopetuskriteerit. Työntekijöiden tulisi tietää, mistä löytää nykyisen lomakkeen, kuka hyväksyy poikkeukset ja mitkä toiminnot ovat kiellettyjä. Hyvä kiertotapa on tarkoituksella suppeampi kuin normaalit toiminnot.

Northstarin heikentyneet toiminnot saattavat sallia kiireelliset tapaukset, hyväksytyt tilaukset ja toimitusten odotukset, mutta samalla alennukset, tilien yhdistämiset, joukkopäivitykset ja ei-välttämättömien tietojen tuonti voidaan keskeyttää. Suunnitelman tulisi määrittää väliaikainen tunniste jokaiselle manuaaliselle tapahtumalle. Hyödyllinen tunniste voi sisältää päivämäärän, tiimikoodin ja järjestysnumeron, mutta organisaation tulisi valita tarkka muoto ja tarkistaa se törmäysten varalta.

Käytä tehtävien erottelua vaikuttavissa toimissa. Tilauksen vastaanottajan ei tulisi olla ainoa, joka hyväksyy arvokkaan lähetyksen. Vaadi toista tarkistusta hyvityksille, pankkitietojen muutoksille tai asiakkaan henkilöllisyyttä koskeville päätöksille. Kirjaa hyväksynnät ajan, nimen ja syyn kera. Nämä kontrollit saattavat tuntua hitaammilta, mutta ne vähentävät riskiä, ​​että lyhyt katkos muuttuu petokseksi, yksityisyyden suojaan tai toimitustapaukseksi.

Mitä integraatioille ja automaatiolle pitäisi tapahtua?

Tee integraatioista osa jatkuvuussuunnitelmaa, äläkä liite, joka on vain kehittäjien oma. Listaa jokainen saapuva ja lähtevä työnkulku, sen käynnistin, tiedon omistaja, jono- tai uudelleenyrityskäyttäytyminen, kaksoiskappaleiden riski ja liiketoimintavaikutukset. Sisällytä aikataulutetut työt, webhookit, väliohjelmistot, tapahtumavirrat, identiteetintarjoajat, raporttien otteet ja ihmisten lataamat tiedot.

Salesforcen käyttökatkoksen aikana automaattiset uudelleenyritykset voivat olla hyödyllisiä tai haitallisia. Jos kohde ei ole käytettävissä, rajoitetut uudelleenyritykset ja varautuminen voivat olla sopivia. Jos lähde hyväksyy viestejä, mutta Salesforce ei, aseta viestit jonoon kestävällä aikaleimalla ja idempotenssiavaimella. Jos kumpikaan osapuoli ei voi vahvistaa, onnistuiko kirjoitus, lopeta toisto, kunnes tila on tiedossa. Älä koskaan oleta, että aikakatkaisu tarkoittaa, että tapahtumaa ei vahvistettu.

Northstarin runbook saattaa ohjeistaa integraation omistajaa keskeyttämään lähtevät työt kolmen epäonnistuneen yrityksen jälkeen, säilyttämään alkuperäisen hyötykuorman, tallentamaan viimeisen vahvistetun Salesforce-aikaleiman ja estämään manuaalisen uudelleensyötön, kunnes jono on luokiteltu. Tarkka kynnysarvo on kuvitteellinen esimerkki. Aseta se havaitun käyttäytymisen, palveluntarjoajan ohjeiden ja liiketoimintariskin perusteella.

Miten tietojen varmuuskopioinnin ja palautuksen tulisi sopia suunnitelmaan?

Jatkuvuus ja varmuuskopiointi ratkaisevat toisiinsa liittyviä, mutta erilaisia ​​ongelmia. Jatkuvuusmenettely pitää yrityksen toiminnassa keskeytyksen aikana. Varmuuskopio auttaa palauttamaan tietoja poiston, vioittumisen tai muun menetystapahtuman jälkeen. Varmuuskopio ei automaattisesti tarjoa reaaliaikaista korvaajaa Salesforce-sovellukselle, sen käyttöoikeuksille, automaatioille tai integraatioille.

Salesforcen tietojen varmuuskopiointiohjeistus kuvaa varmuuskopioita erikseen palautettaviksi kopioiksi ja suosittelee säännöllisiä varmuuskopioita, useita sijainteja ja testattua palautusta. Päätä, mitkä tietueet, metatiedot, tiedostot ja tarkastustiedot yrityksen on palautettava, kuinka kauan niitä on säilytettävä ja kuka voi valtuuttaa palautuksen. Testaa, voidaanko palautetut tiedot yhdistää seisokkien aikana luotuihin väliaikaisiin tietueisiin.

Jos organisaatiosi harkitsee edistynyttä alueiden välistä jatkuvuutta, lue Salesforcen ajankohtaiset usein kysytyt kysymykset huolellisesti. Salesforcen mukaan tarjous rajoittuu Hyperforceen, joitakin palveluita ei vielä tueta ja palautustapahtuma estää organisaation toiminnan katastrofipalautustoimintojen aikana. Siinä myös todetaan, että maakohtaiset tiedontallennussitoumukset voivat muuttua, jos ensisijaiset ja toissijaiset alueet sijaitsevat eri maissa. Nämä ovat suunnittelurajoituksia, eivät alaviitteitä.

Ketkä viestivät ja mitä heidän tulisi sanoa?

Määritä yksi tapausvastaava, yksi tekninen johtaja, yksi liiketoiminnan johtaja ja yksi viestintävastaava. Määritä varahenkilöt kullekin roolille. Pidä viesti asiallisena: mihin se vaikuttaa, milloin se alkoi, mitä käyttäjien tulisi tehdä, mitä heidän ei tule tehdä, milloin seuraava päivitys saapuu ja missä hyväksytyt ohjeet ovat.

Älä ilmoita palautumisaikaa, jota Salesforce ei ole vahvistanut. Älä pyydä asiakkaita lähettämään tietoja uudelleen toistuvasti, jos alkuperäinen pyyntö saattaa jo olla jonossa. Northstarin tapauksessa asiakasviestissä voi olla mainittu, että tilausten vastaanotto tapahtuu väliaikaisen kanavan kautta, että asiakkaiden tulisi käyttää yhtä tiettyä yhteydenottotapaa ja että seuraava tilannepäivitys julkaistaan ​​tiettyyn aikaan.

Sisällytä sisäiset eskalointikynnykset. Esimerkiksi kriittinen, asiakkaaseen vaikuttava prosessi voi lähettää tapausliidille välittömästi viestin, kun taas vanhentunut raportti voi odottaa seuraavaa aikataulun mukaista tarkistusta. Linkitä suunnitelma nykyisiin Salesforce Trust -ilmoituksiin ja organisaation tukioikeuksiin. Puhelinnumeropuu, joka ei enää vastaa työvoimaa, ei ole viestintäsuunnitelma.

Miten tiimin tulisi testata suunnitelmaa?

Aloita pöytätehtävällä. Anna Northstarin tiimille kuvitteellinen tehtävä, kuten: ”Klo 9.10 Salesforce ei ole käytettävissä palvelu- ja myyntitiimeille; varastointegraatiotyöt osoittavat toistuvia virheitä; Trust raportoi palveluhäiriöstä.” Pyydä jokaista roolia suorittamaan suunnitelman ensimmäiset 30 minuuttia käyttäen vain dokumentoituja materiaaleja.

Mittaa havaittavia tuloksia:

• Kuinka kauan kestää, ennen kuin tapaus tunnistetaan ja luokitellaan?
• Kuinka kauan kestää, kunnes hyväksytty kiertotie on saatavilla?
• Löytääkö jokainen tiimin jäsen ajantasaisen lomakkeen ja yhteystietoluettelon?
• Estettiinkö päällekkäisiä, luvattomia tai liiallisia tiedonsyöttöjä?
• Pysyivätkö integraatioiden uudelleenyritykset rajoitettuina ja jäljitettävinä?
• Pystyykö tiimi tunnistamaan kaikki väliaikaiset tietueet, jotka tarvitsevat täsmäytystä?

Suorita pöytätestin jälkeen kontrolloitu tekninen testi hiekkalaatikko- tai ei-tuotantoympäristössä, jossa skenaario on turvallinen ja tuettu. Älä väitä, että hiekkalaatikkoharjoitus todistaa tuotantoympäristön vikasietoisuuden. Salesforcen ACRC-dokumentaatio toteaa nimenomaisesti, että sandbox-organisaatiot eivät kuulu ACRC:n piiriin. Tämä muistuttaa testaamaan todellista palautuksen laajuutta sen sijaan, että päättelemme sen alemman tason ympäristöstä.

Mikä on takaisinperintä- ja sovittelumenettely?

Toipuminen alkaa, kun tapauksen asiantuntijalla on luotettavaa näyttöä siitä, että kyseinen Salesforce-palvelu on käytettävissä – ei pelkästään silloin, kun käyttäjä voi ladata kirjautumissivun. Vahvista tilasivu, testaa pienellä valtuutetulla toiminnolla, tarkista integraatiot ja ilmoita hallitusta paluusta normaaliin toimintaan.

Täsmäytä järjestyksessä, joka suojaa tallennusjärjestelmää:

1. Jäädytä uudet manuaaliset merkinnät hetkeksi, jotta lopullinen väliaikainen jono voidaan laskea.
2. Vie tai säilytä hyväksytty manuaalinen rekisteri ja sen lokitiedot.
3. Yhdistä jokainen väliaikainen tunnus Salesforce-tietueeseen, olemassa olevaan tietueeseen tai dokumentoituun poikkeukseen.
4. Tarkista ennen käyttökatkosta luodut tietueet, jotka viivästyivät, monistuivat tai käsiteltiin osittain.
5. Toista integrointiviestit vasta idempotenssin ja viimeisen onnistuneen tarkastuspisteen vahvistamisen jälkeen.
6. Pyydä yrityksen omistajaa tarkistamaan merkittävät tapahtumat, kokonaissummat, hyväksynnät ja asiakassitoumukset.
7. Sulje vajaatoimintatila, säilytä tarvittavat todisteet ja poista väliaikaiset kopiot käytännön mukaisesti.

Mitkä ovat Salesforcen seisokkiaikasuunnitelman rajoitukset?

Suunnitelma ei voi pakottaa Salesforcea toipumaan nopeammin, taata integraation kirjoittamisen valmistumista tai saada tukematonta tuotetta toimimaan tuetun tuotteen tavoin. Se ei voi korvata sopimustarkastusta, tietosuoja-analyysia, varmuuskopiotestausta tai tietoturvahäiriöihin reagointia. Manuaalinen kiertotapa voi myös aiheuttaa transkriptiovirheitä, käyttöoikeusongelmia, viivästynyttä tuottojen kirjaamista ja hämmennystä asiakkaille.

Suunnitelman tulisi siksi sisältää päätös pysäyttämisestä. Jos tiimi ei pysty varmistamaan asiakkaan henkilöllisyyttä, maksutoimeksiannon eheyttä, lähetyksen tilaa tai tiedonsiirron kohdetta, toimenpide keskeytetään valtuutettua tarkistusta varten. Jatkuvuus ei ole sama asia kuin jokaisen tapahtuman jatkaminen hinnalla millä hyvänsä.

Northstarin suunnitelman lopullinen tarkistuslista

• Kriittiset prosessit, omistajat, vaikutukset, RTO ja RPO dokumentoidaan.
• Salesforce-instanssin, tuotteiden, tukipolun ja luotettavuusilmoitusten asetukset ovat ajan tasalla.
• Manuaaliset lomakkeet, väliaikainen tallennus, käyttöoikeussäännöt, säilytys- ja poistovaiheet hyväksytään.
• Integraatioiden uudelleenyritykset, jonot, tarkistuspisteet, kaksoiskappaleiden hallinta ja taukosäännöt ovat eksplisiittisiä.
• Asiakas-, työntekijä-, toimittaja- ja johdon viestit laaditaan päivitysvälein.
• Varmuuskopiointi, palautus, tietojen säilytys ja mahdollinen premium-jatkuvuuden laajuus varmennetaan käytetyille palveluille.
• Pöytäharjoituksella ja turvallisella teknisellä testillä on omistajat, päivämäärät, onnistumiskriteerit ja jatkotoimenpiteet.
• Toipumiseen kuuluu sovinto, liiketoiminnan hyväksyntä, todisteiden säilyttäminen ja tapahtuman jälkeinen arviointi.

Northstarille menestys ei ole sitä, että ”Salesforce ei koskaan kaadu”. Menestys tarkoittaa sitä, että tiimi tunnistaa häiriöt, suojaa kriittisen työn, välttää vaarallisia improvisaatioita, pitää jäljitettävää kirjaa väliaikaisista toimista ja palaa normaaliin toimintaan ilman piilotettuja kaksoiskappaleita tai puuttuvia sitoumuksia. Tämä on standardi, joka käytännöllisen Salesforcen liiketoiminnan jatkuvuussuunnitelman tulisi täyttää.

Viralliset viitteet

• Salesforce Enterprisen vikasietoisuuden/BCP-yhteenveto
• Salesforce Trust -sivuston ohjeet
• Salesforcen edistyneen alueidenvälisen jatkuvuuden usein kysytyt kysymykset
• Salesforce-tietojen varmuuskopiointi- ja palautusohjeet
• NIST SP 800-34 Rev. 1 varautumissuunnitelma