Cloud computing gir brukerorganisasjoner og IT både friheten til manøvrering og lang sikt fleksibilitet som aldri var mulig med tradisjonelle bedriftsapplikasjoner. Men gjør at frihet for nye nivåer av uforutsigbarhet når det kommer til store distribusjoner, og noen nye krav til støtte.

Som jeg har skrevet i det uendelige, CRM-applikasjoner er forskjellig fra andre bedriftsapplikasjoner, hovedsakelig på grunn av behov og vaner av sine brukere. Generelt sett, salg og markedsføring folk sette en mye høyere prioritet på suksess (både utseende og virkeligheten) enn de gjør på prosessen disiplin eller små detaljene som datakvalitet. Par som med skiftende sanden på markedet konkurranse og utviklende salgsmodeller, og resultatet er et system som må ofte romme betydelige grader av endring.

Så kombinasjonen av skyen og CRM kan gjøre for noen stressende netter i intern støtte organisasjonen. Når det er salgsdistrikt deler eller omdefinert partner overlegg, vil det haster skyver å endre bly ruting, konto eierskap, og validerings mulighet regler. Disse endringene kan virke til å gli rett inn, men kan så frø av bugs i provisjon eller henvisning avgifter. Nesten uunngåelig, vil disse problemene ikke dukker opp før du har feilaktig behandlet hundrevis av bestillinger.

Den tradisjonelle help desk infrastruktur (og, må jeg si, holdning) virkelig vil ikke klippe det for disse høy -profile problemer. Alt for ofte, er det politiske overtoner som fører til klandre-spill som du ønsker å unngå. Så la oss se på noen beste praksis som er hjørnesteinene i skyen systemstøtte:

• Det hele starter med arkitektur og konfigurasjonskontroll. De virkelig skremmende problemer i skyen CRM ikke skje innen den smale rammen av CRM-systemet. Problemene overflaten på avreise integrasjon med regnskap, ordrebehandling, e-handel, portal, eller andre kunderettede applikasjoner. Selv om det er lett å gjøre endringer - bokstavelig talt i timer - i CRM-systemet, betyr ikke at du bør gjøre det ... eller at dine CRM endringene vil riktig overføres til de andre systemene. Det må være en konfigurasjonskontroll prosess som ser på konsekvensene av en eventuell endring av koden, datamodellen, eller semantikk plukkliste verdier. Virkelig, kan dette drepe deg, fordi det er ingen administrative "sentrum" av en stor sky distribusjon. Hvert program har sitt eget kontrollpanel og dashbord, men konsekvensene av endringer på tvers av grensesnittene og mashups kan bare bli vurdert av et panel av SMB.

• Ditt team vil trenge instrumentering. Under de beste forhold, er feilsøking på tvers av applikasjoner vanskelig nettopp på grunn av den løse kopling som gir fordelene av skyen. Tidlig i utviklingen syklus, sørg for å skrive feilhåndtering og logging klasser som skriver diagnostiske poster under bruk produksjon. Som omtalt her, bør feilloggen selv lagres i en "sentralisert" skytjeneste, å supplere logging tilgjengelig i hvert program.

• få virkelig gode på distribusjon. Som en verden av cloud computing er relativt nytt, er industri-styrke infrastrukturen fortsatt på vei. Distribusjon er en kombinasjon av håndlagde scripts og sjekklister, med detaljer som synes å være alltid være i utvikling. Enten det er en bug patch eller en Agile utgivelsessyklus, må prosessen være repeterbare, pålitelig, og som strømlinjeformet som mulig

Lysbilde. Hva er Cloud Computing Show: 10 Cloud forvaltningsselskaper for å se Anmeldelser

• Det må være et offentlig tilgjengelig informasjon repository om cloud design, implementering og distribusjon problemer. Ingen enkelt cCloud leverandøren vil tilby dette, så det er en DIY element. Som jeg nevnte et par uker siden, "hva er hva" må dokumenteres både i de enkelte sky applikasjoner og i et felles område. I tillegg til beskrivende materialer, vil støtteteam trenger standard testtilfeller, forventede resultater, og work-arounds for kjente problemområder. Enten du bruker en Wiki, et sett med Google Docs, eller delt mappe - alle skal kunne lese disse dokumentene, og alle på IT-teamet skal kunne oppdatere dem i sanntid. Åpenhet er viktig - det er en hjørnestein i samarbeid problemløsning. I tilfelle er det ikke opplagt, glemme papir for disse docs.

• Støtte må være den consummate Agile funksjonen. Siden ting kan gå galt så fort når det er en bug i din CRM konfigurasjon eller data, må support team å jobbe i raske scrums, med daglige triage og prioriteringsmøter. Det er en smart idé å ha din skarpeste QA person i på disse møtene, som de kan feilsøke og de må planlegge for distribusjon av reparasjonen. En veldrevet 10 minutters daglig "stå opp" møtet er et vanskelig krav, spesielt hvis det interne support team opererer i mer enn ett land.

• Prioritering er alt. Siden de verste støtte problemer alltid synes å forekomme i klynger nær forretnings frister, er den første bestillingen av virksomheten for å arbeide på noen problemer som virkelig betyr noe - og unngå støy. I tillegg til de tradisjonelle prioritet og alvorlighetsgrad kategorier for bugs, bruk en pick-liste for organisasjoner påvirket, en plukkliste for cloud systemer berørt, og en beregning for nummeret (eller dollar volum) av ordre som vil kreve omarbeiding.

Mens noen av disse kan representere nye praksiser, de kan vanligvis legges over på en eksisterende supportorganisasjon. Trikset er å bli mer responsiv på de tingene som virkelig betyr noe - selv når de er spredt over flere systemer -. Uten å kjøre opp kostnadene

David Taber er forfatter av den nye Prentice Hall bok, "Salesforce. com Secrets of Success "og er administrerende direktør i SalesLogistix, en sertifisert Salesforce.com rådgiver rettet mot forretningsprosesser forbedring gjennom bruk av CRM-systemer. SalesLogistix klienter er i Nord-Amerika, Europa, Israel og India, og David har over 25 års erfaring i high tech, inkludert 10 år ved VP nivå eller høyere.

Følg alt fra CIO.com på Twitter @ CIOonline.

Les mer om cloud computing i CIO Cloud Computing Drilldown. Anmeldelser