(denne post cross bogført mellem http://paulgalvin.spaces.live.com/blog/ og http://blogs.conchango.com)

Opslag på dette site er mine egne og repræsenterer ikke nødvendigvis Conchangos holdninger, strategier eller udtalelser.

Oversigt:

Dette indlæg beskriver nogle baggrundsoplysninger om en stor (3,000 brugere) Microsoft Office SharePoint Server (MOSS) udrulningen, og hvad vi gjorde for at få projektet rullende på en sådan måde, at kunden er tilfreds og fast ned en sti der slutter med fuld vedtagelsen af MOSS feature sæt. Som for skrivning af posten, Vi er ca. 50% komplet med første fase af projektet. Som tingene skrider frem, Jeg vil opdatere denne post og/eller skrive nye poster.

I dette specifikke tilfælde, virksomheden havde allerede installeret SharePoint Portal Server 2003. IT gruppen har installeret produktet i en slags "Lad os se, hvis nogen bekymrer sig" mode. Det blev hurtigt vedtaget af mange professionelle brugere og blev ganske populær i virksomheden som helhed. Som du kan forestille dig, Dette var ikke den bedste udrulning strategi (som klienten let indrømmer) og når MOSS ankom på scenen, klienten er besluttet på at "gøre det rigtigt" og hyret os til at hjælpe dem.

Et af de centrale spørgsmål står over for os, da vi begyndte at gennemføre dette projekt blev: Hvordan vi introducere MOSS til denne klient? Givet at klienten allerede havde erfaring med SharePoint, vi spekulerede på — skal vi gøre "differentieret" træning eller skal vi starte fra jorden op? Efter at have arbejdet med vigtige brugere, Vi har besluttet at behandle dette som et grønt felt projekt givet mere mening.

Denne beslutning gav et udgangspunkt, men stadig efterlod os med det store krav at finde ud af en god strategi for rullende MOSS ud til virksomheden. MOSS er sådan en stor dyr … Det omfatter indholdsstyring, dokumentstyring, Søg, sikkerhed, målgrupper, projektledelse, "fabelagtig fyrre" skabeloner, arbejdsproces, Business data connector, osv. Par dette med, at det er en stor organisation, kan virkelig gøre brug af stort set alle større MOSS funktion, og du har makings af et stort projekt med en enterprise reach og mange gode ting sker.

Vi er konfronteret med dette spørgsmål igen og igen … MOSS har en enterprise nå med dets enterprise feature-sæt, endnu har engang noget sofistikeret klienter svært ved at mentalt absorbere disse funktioner, Lad alene indarbejde en mærkbar brøkdel af dem i deres daglige rutine.

Jeg har ikke en magisk løsning på problemet. I stedet henvender jeg bare de første skridt, som vi har taget med klienten til at føre dem ned stien til vellykket langsigtet vedtagelse.

Anvendelsesområde:

Så meget som jeg ønskede holdet til at udforme en projektplan, der indeholdt sådanne milepæle som "PoepleSoft Integration via BDC afsluttet", "Nye Cross-departementets produkt lancering arbejdsproces komplet" og "Direktionen KPI accepteret", Jeg måtte nøjes med noget mindre. Dette er ikke til at sige, at "under" er dårlig. Faktisk, "mindre" at vi besluttede for den indledende udrulningen var miles foran hvor de var før vi begyndte. I vores tilfælde, "mindre" forvandlet til:

• Enkle dokumenthåndtering bruge dokumentbiblioteker, version kontrol og indhold, typer.
• Effektiv søgning baseret på indholdstyper og tilpasset advance søgning (via administrerede egenskaber, XSLT til at producere smukke resultater, osv).

Ud over de ovennævnte virksomhedsdækkende funktioner (hvilket betyder, at de skulle blive rullet ud til alle afdelinger og brugere), vi tilføjet følgende singleton i anvendelsesområdet mini-projekter:

• Påvisning i id BDC-integration.
• Flere trin og flergrenet arbejdsgangsprocessen skabt via SPD.
• Komplekse InfoPath-formular.
• Surfacing Nøgletallene for nogle business proces (sandsynligvis HR talent erhvervelse i vores tilfælde, selv om der kan ændre).

Mulighederne her er ikke 100% præcis men repræsentant for vores tilgang og tilstrækkelige for mit formål her, som er at forklare, hvad jeg anser for at være en "effektiv" indførelsen af mos, som indstiller klienten fast den gyldne vej til fuld MOSS vedtagelse.

Jeg vil ikke skrive meget mere om singleton i denne post. Jeg ønsker at påpege, at disse er en del af vores overordnede strategi. Ideen er at gennemføre core dokument management og Søg funktioner til alle brugere endnu giver yderst funktionelt, høj synlige og meget repræsentative eksempler på andre MOSS kernefunktioner, som er simpelthen ud over de fleste brugere evne til at absorbere på dette tidlige stadium. Dog, de vil være "derude" og man håber at andre afdelinger vil vide af eller lære om dem og ønsker disse funktioner for sig selv, fører til større vedtagelse. Disse singleton succeshistorier også tjene til at give vores salgsteam "ammunition" for med held at vinde det andet, tredje og n-fase projekter.

Hvad gjorde vi introducere og hvorfor?

At have afgjort på dokumenthåndtering og Søg som en baseline virksomhedsdækkende krav, Vi havde brug at starte indsamling af oplysninger. Som et praktisk spørgsmål, det drejede sig om forståelse af deres dokumenter og, i sidste ende knyttet til forståelse indholdstyper.

Jeg har fundet det vanskeligt at forklare indholdstyper uden visuelle hjælpere. Mere tekniske folk kan gå væk fra en diskussion om indholdstyper, når CTS er beskrevet i databaseterminologi kaldes. "En CT er svarende til en databasetabel, Det har kolonner og kolonner defineres i form af datatyper, men CT datatyper omfatter mere end simple heltal/dato, men også "choice" og "opslag" og lignende." Vi kan tale om "strækker sig" indholdstyper, ligesom man kan arve funktionalitet fra en basisklasse i objektorienteret sprog. Men det er naturligvis ikke nyttigt for transport department admin person, der har ingen teknisk baggrund. Dvs., næsten alle, der betyder noget i en Mos udrulningen.

Ved hjælp af et hvidt bord er usikker. Jeg har præsenteret tanken om en indholdstype og trukket strålende (eller så de synes) billeder af indholdstyper og hvad de gør for dig med hensyn til søgning og hvordan de kan udvides, osv. I sidste ende, det føles som om nogle pærer har slået, men den resulterende skrivetavle billede er en rod.

Dette førte os til vores nuværende og så langt mest effektive landingspladsen: en Mos sandkasse websted er konfigureret til at vise disse funktioner.

Ved hjælp af sandbox-webstedet, Vi demonstrere:

• Indholdstyper:
  • At skabe en CT med flere datatyper (tekst, dato, valg, Boolesk værdi, opslag, osv).
  • Udvide en CT ved at oprette en ny CT baseret på en overordnet.
  • Søger efter dokumenter ved hjælp af CT metadata.
• Dokumentbiblioteker:
  • Knytte en enkelt CT med et bibliotek.
  • Hvad sker der når vi overfører et dokument til biblioteket?
  • Knytte flere CT med en doc bibliotek.
  • Hvad sker der når vi overfører et dokument til biblioteket?
  • Filtrering og sortering via kolonneoverskrifter i en doc lib.
  • Dokument bibliotek visninger:
    • Sortering
    • Gruppering
    • "Hurtig løsning" (visning af data)
    • "Ukodet data" (at hjælpe med migrationen til mos fra andre indholdskilder; mere om dette nedenfor).

Sandbox-webstedet:

Vi designet vores sandkasse site at være en fast bestanddel i udviklingsmiljøet bruges til træningsformål lang, når vi er færdig med projektet og inkluderet adskillige artefakter som beskrevet:

Indholdstyper:

Vi defineret følgende indholdstyperne: Faktura, Indkøbsordre, Tjenester faktura.

Vi valgte faktura og Køb orden, fordi de er mere eller mindre universelt under
stod enheder. Alle i virksomheden forstår at en faktura er en anmodning om betaling for en kunde for en beløb udstedt på en bestemt dato der skal betales ifølge nogle betalingsbetingelser. Dette fører til en naturlig definition af en CT, som vi kaldte "uddannelse faktura" (at skelne den fra andre former for faktura). Indkøbsordren er ligeledes let defineret. Vi skabte også en "uddannelse tjenester faktura" ved at oprette en ny CT baseret på "uddannelse fakturaen" CT og tilføjede bare én kolonne, "tjenesteydelser".

Med ovenstående, Vi kan nu påvise nogle nøglefunktioner i CTS uden at blive kørt ned forsøger at forklare et abstrakt begreb først; alle forstår allerede, hvad vi forstår ved "faktura" og "indkøbsordre" og er i stedet at fokusere på mekanik af CT selv.

Brugerdefinerede lister:

CT med kolonner af typen "opslag" Peg på en brugerdefineret liste eller et dokumentbibliotek. Vi bruger dette flittigt og for sandkassen, Vi har oprettet en støtte brugerdefinerede liste, der indeholder kunder. Vi tog kunder, fordi det er en let koncept til at forstå og let at påvise. Faktura CT har en kolonne, "kunde" der er defineret af typen "opslag" der peger på denne liste.

Vi lavet en tilsvarende brugerdefinerede liste for at administrere "leverandører" for indkøbsordren"" CT.

Dokumentbiblioteker:

Vi lavet to dokumentbiblioteker: "Fakturaer" og "Blandet dokumenter".

Vi konfigureret fakturaer dokumentbibliotek for at styre kun dokumenter af CT type "Faktura".

Vi konfigureret "blandet-dokumenter" biblioteket til at administrere alle tre CT.

Oprette flere visninger, der viser sortering, filtrering, på data-ark og gruppering.

Søg:

Vi defineret to nye administrerede egenskaber og knyttet dem til fakturanummer og kunde.

Vi lavet en ny tilpasset advance søgning site og forandret sig for at give brugerne mulighed at søge efter "fakturaer" ved hjælp af disse to tilknyttede egenskaber.

Ændre XSLT så faktura og kunde antallet, Når præsenterer, vises i en HTML-tabel i en lys farve. Målet her er at vise, at sådanne formatering er muligt.

At sætte det hele sammen:

Vi arrangere nøglebrugere til at deltage i en demo.

Vi følger denne simple script:

1. Beskrive formålet af en CT, ved hjælp af fakturaer og indkøbsordrer som eksempler.
2. Vis faktura CT definitionen samtidig samtidig sikrer dem, at de ikke behøver at bruge disse skærme, selv, bare afhente begreberne.
3. Gå til dokumentbiblioteket fakturaer.
4. Uploade et dokument.
5. Påvise, at den kunde drop-down virkelig stammer fra en brugerdefineret liste.
6. Tilføje en ny kunde til kundeliste og derefter opdatere den nyligt uploadet faktura metadata med de nyoprettede kunde.
7. Skift til "blandet-dokumenter" bibliotek og uploade et dokument. Forklare hvordan systemet beder om for en dokumenttype.
8. Gå tilbage til fakturaer dokumentbibliotek og viser hvordan at klikke på et kolonnenavn ændrer sorteringsrækkefølgen.
9. Vise kolonnen-niveau filtrering.
10. Vise forskellige visninger, der viser multi-level sortering, filtrering og gruppering.
11. Vis ark datavisning.
12. Forklare formålet med et "ukodede dokumenter" Se.
13. Skifte til den tilpassede avanceret søgning.
14. Nu, de nyligt uploadet dokument skal have gennemgået og indekseret, så udføre en søgning, der viser evne til at lokalisere denne faktura via egenskaben tilknyttede.
15. Vi demonstrere forskellen mellem søgning via tilknyttede egenskaber vs. bare en tekstsøgning.

På dette punkt, Vi er mere eller mindre færdig med demo. Det synes at tage om 30 til 45 minutter, afhængigt af hvor mange spørgsmål spørger.

Derefter sender vi dem tilbage til deres skriveborde med "hjemmearbejde". Denne består af en simpel excel-regneark hvor vi bede dem om at definere for os hvad de tror, de har brug for med hensyn til CT'S, både på et højt niveau (kun navn og forretningsadresse formål) kolonner og datatype ville de gemme i kolonnen. Vi bede ikke dem om at definere kolonnedatatyper i MOSS vilkår, men forretningsbetingelser.

I Resumé:

Vi har oprettet en sandkasse miljø, som vi kan bruge til at vise nogle kernefunktioner til MOSS Hvis appellen er hele virksomheden.

Vi har modelleret let forståelig og fælles forretningsenheder, således at brugerne kan fokusere på MOSS og ikke forsumpe på enhederne / eksempler, selv.

Business-brugere gå væk fra afhandlinger sessioner med "hjemmearbejde" i form af excel-dokumenter, som de nu er kompetente til at udfylde og bruge til at designe deres egen første-cut indholdstyper.

Endelig, Når vi udfører demoer over tid, klientens teammedlemmer, selv blive bedre i stand til at videreføre, demo's selv og generelt gratis op resten af os op til at arbejde på mere komplekse problemstillinger, som global taksonomi, komplekse arbejdsprocesser, BDC- og lignende.