Datalagring i en krydsvirksomhedsindstilling - dummies

Datalagring er som regel en privat affære. Selv når eksterne data om dine konkurrenter er en del af dit miljø, er det stadig din virksomheds datalager, bygget til din virksomheds fordel og brug.

En interessant tendens - der jo sikkert kan ses på direktionens niveau, primært fordi disse er styringsselskaber i den retning - er at have samarbejde med flere virksomheder.

To eller tre farmaceutiske virksomheder kan dele forsknings- og udviklingsomkostningerne på en ny generation af lægemidler, eller to fremstillingsvirksomheder kan arbejde sammen i et partnerskab for at udvikle et produkt. En handelsbank og en mæglervirksomhed kan arbejde sammen om at tilbyde en række finansielle produkter til massemarkedet, hvor banken administrerer nogle produkter og mæglerne administrerer andre.

Uanset hvad branchen og situationen har, har din virksomhed en god chance for at være involveret i et multiselskabs partnerskab, hvor samarbejde på tværs af virksomheder og informationsdeling er en vigtig del af succesen.

Til dette formål er et interessant spin på temaet datalagring som en barriere af barrierer at have et multifunktionsdatamagasin dedikeret til mere effektive analyse- og informationsleverancer til støtte for en fælles indsats mellem dine to virksomheder.

Som du måske gæt gæt, er et multi-data datalager et lidt mere komplekst væsen end en dedikeret til støtte fra et enkelt firma. Selvom du oplever alle de vidunderlige udfordringer ved dataudvinding og transformation, værktøjsvalg, ydeevne og andre aspekter af datalagring, skal du også overveje disse problemer:

• Virksomhedsstandarder: To (eller flere) sæt Virksomhedsstandarder kan påvirke, hvordan du implementerer dit datalager og dets værktøjer. For eksempel kan et firma være et Business Objects-miljø, og et andet kan være et Cognos-miljø. Hvilke standarder vil du bruge, og hvad har effekten på det andet selskabs brugere?

• Egen og følsom data: Forretningssagen til multibureaudatabutikken og den ledsagende funktionalitet og data, der er nødvendige for at understøtte datalagerets forretningsmission, kan kræve, at salgshistorieoplysninger stilles til rådighed for forudsigende salgsprognoser.

  Oplysninger om salgshistorik indebærer en opdeling efter region, territorium og muligvis endda kunde. Hvad er virkningerne af at afsløre kundelister, og styrker og svagheder i forskellige regioner, til en partner, der også er en konkurrent?

• Sikkerhedsanliggender: Ud over datasikkerhedsproblemer kan enhver sammenkobling mellem to miljøer åbne et miljø for eventuelle sikkerhedssvagheder i den anden, f.eks. Uautoriseret ekstern adgang og hacking.

• Støtteomkostninger: Hvilken organisation har primært supportansvar for datalageret? Bærer den den fulde byrde af støtteomkostninger, eller vil de to organisationer dele disse omkostninger? Hvis organisationerne deler omkostningerne, hvordan beregner de supportomkostninger, og hvordan regner de og betaler disse omkostninger?

• Udviklingsmetode: En organisation kan udvikle sine datalagringsapplikationer og miljøer ved at bruge Kimball-teknikker, men den anden organisation anvender Inmon-teknikker. Hvem styrer udviklingsprocesserne? Skal individer fra en organisation finde ud af og bruge de andre metoder og teknikker?

• Tvistbilæggelse: Det er altid en interessant udfordring at løse enhver form for tvist, hvor parter er fra forskellige virksomheder.

• Løbende forbedringer: Hvilken virksomhedsstruktur skal du etablere for at prioritere og godkende forbedringer af miljøet?