(hierdie item kruis gepos tussen http://paulgalvin.spaces.live.com/blog/ en http://blogs.conchango.com)

Die plasings op hierdie webtuiste is my eie en verteenwoordig nie noodwendig Conchango se poste, strategieë of menings.

Oorsig:

Hierdie inskrywing beskryf 'n bietjie agtergrond inligting oor 'n groot (3,000 gebruikers) Microsoft Office SharePoint Server (MOSS) rollout and what we did to get the project rolling in such a way that the client is happy and firmly down a path that ends with full adoption of the MOSS feature set. As of the writing of the entry, Ons is ongeveer 50% complete with the first phase of the project. As things progress, Ek sal hierdie item werk en / of skryf nuwe inskrywings.

In hierdie spesifieke geval, the company had already installed SharePoint Portal Server 2003. The IT group installed the product in a sort of "let’s see if anyone cares" fashion. It was quickly adopted by many business users and became quite popular in the enterprise at large. Soos jy kan dink, Dit was nie die beste uitrol strategie (wat die kliënt erken geredelik) en wanneer MOSS op die toneel aangekom, the client resolved to "do it right" en ons gehuur het om hulle te help.

Een van die sentrale vrae waarmee ons toe ons begin die implementering van hierdie projek was: Hoe voer ons MOSS aan hierdie kliënt? Given that the client already had experience with SharePoint, ons het gewonder — do we need to do "differential" opleiding of begin ons van die grond af? After working with key users, we determined that treating this as a green field project made more sense.

That decision gave a starting point but still left us with the major requirement of figuring out a good strategy for rolling MOSS out to the enterprise. MOSS is such a big animal … it includes content management, dokument bestuur, soek, sekuriteit, gehoor fokus, projek bestuur, "fabulous forty" templates, workflow, besigheid data connector, ens.. Couple this with the fact that it’s a large organization that kan werklik gebruik maak van feitlik elke groot MOSS funksie en jy het die bestanddele van 'n groot projek met 'n onderneming te bereik en baie goeie dinge gebeur.

Ons is gekonfronteer met hierdie kwessie keer op keer … Moss het 'n onderneming bereik met sy onderneming funksie-stel, Maar selfs ietwat gesofistikeerde kliënte het 'n harde tyd geestelik absorbeer die eienskappe, laat staan ​​die integrasie van 'n aansienlike gedeelte van hulle in hul daaglikse roetine.

I don’t have a magic solution to the problem. I instead address just the very first steps that we’ve taken with the client to lead them down the path to successful long-term adoption.

Omvang:

As much as I wanted the team to craft a project plan that included such milestones as "PoepleSoft Integration via BDC Completed", "New Cross-Departmental Product Launch Workflow Complete" and "Executive Management KPI’s Accepted", I had to settle for something less. This is not to say that "less" sleg. In werklikheid, the "less" that we decided for the initial rollout was miles ahead of where they were before we started. In ons geval, the "less" verander in:

• Eenvoudige dokument bestuur met behulp van dokument biblioteke, version control and content types.
• Effektiewe soek gebaseer op die inhoud tipes en persoonlike vooraf soek (deur die bestuur van eiendomme, XSLT mooi resultate te lewer, ens.).

In bykomend tot die bogenoemde onderneming breë funksies (wat beteken dat hulle sou word uitgerol na alle departemente en gebruikers), ons ook die volgende Singleton in-omvang mini-projekte:

• Bewys van die konsep BDC integrasie.
• Multi-stap-en multi-tak workflow proses geskep via SPD.
• Komplekse Path vorm.
• Oppervlak KPI's vir 'n paar sake-proses (waarskynlik HR talent verkryging in ons geval, al wat kan verander).

Die omvang hier is nie 100% accurate but representative of our approach and sufficient for my purpose here, which is to explain what I consider to be an "effective" bekendstelling van MOSS wat die kliënt stewig af die goue paaie na volle MOSS aanneming.

I won’t write much more about the singleton in this entry. I do want to point out that these are part of our over-arching strategy. The idea is to implement the core document management and search features to all users yet provide highly functional, high visible and highly representative examples of other core MOSS features which are simply beyond the ability of most users to absorb at this early stage. Egter, they will be "out there" en een hoop dat ander sake-eenhede sal weet of leer oor hulle en wil daardie funksies vir hulself, leading to greater adoption. These singleton success stories also serve to provide our sales team "ammunition" vir die suksesvolle wen tweede, third and n-phase projects.

Wat het Ons stel en hoekom?

Nadat hulle op dokument bestuur en soek as 'n basislyn onderneming breë vereiste, we needed to start gathering details. As a practical matter, hierdie gedraai rondom die begrip van hul dokumente en wat uiteindelik koppel aan die begrip van die inhoud tipes.

I’ve found it’s difficult to explain content types without visual aides. More technical folk can walk away from a discussion about content types when CT’s are described in database terms. "A CT is similar to a database table, dit het kolomme en kolomme word gedefinieer in terme van data tipes, maar CT data tipes sluit in meer as 'n eenvoudige integer / datum, but also "choice" and "lookup" and the like." We can talk about "extending" inhoud tipes, much like one can inherit functionality from a base class in object oriented languages. However this is obviously not helpful for the transportation department admin person who has no technical background. Dws, byna almal wat saak maak in 'n mos uitrol.

Using a white board is iffy. I’ve presented the idea of a content type and drawn brilliant (of so dit lyk asof hulle) foto's van die inhoud tipes en wat hulle doen vir jou in terme van die soektog en hoe hulle kan uitgebrei word, ens.. Op die ou end, dit voel soos 'n paar gloeilampe het aangeskakel, but the resulting white board picture is a mess.

Dit het ons na ons huidige en tot dusver mees doeltreffende landing plek: 'n mos sandbox webwerf ingestel om hierdie eienskappe te toon.

Met behulp van die sandbox webwerf, ons demonstreer:

• Inhoud tipes:
  • Die skep van 'n CT met verskeie tipes data (teks, datum, keuse, boolean, soek, ens.).
  • Uitbreiding van 'n CT deur die skep van 'n nuwe CT gebaseer op 'n ouer.
  • Soek vir dokumente met behulp van CT metadata.
• Dokument biblioteke:
  • Assosieer 'n enkele CT met 'n biblioteek.
  • Wat gebeur wanneer ons laai 'n dokument na daardie biblioteek?
  • Assosieer verskeie CT se met 'n doc biblioteek.
  • Wat gebeur wanneer ons laai 'n dokument na daardie biblioteek?
  • Filter en sorteer via kolomopskrifte in 'n doc lib.
  • Dokument biblioteek uitsig:
    • Sorteer
    • Groepering
    • "Quick entry" (gegewensblad oog)
    • "Untagged data" (om te help met migrasie na MOSS uit ander bronne inhoud; meer inligting oor hierdie hieronder).

Die Sandbox Site:

Ons ontwerp ons sandbox webwerf na 'n permanente kenmerk in die ontwikkeling omgewing gebruik word vir opleiding doeleindes lank nadat ons klaar is met die projek en sluit 'n paar artefakte soos beskryf:

Inhoud tipes:

Ons het die volgende tipes inhoud: Faktuur, Koop Order, Dienste faktuur.

Ons gekies faktuur en bestelling, want hulle is min of meer universeel onder
stood entities. Everyone in business understands that an invoice is a demand for payment to a kliënt vir 'n bedrag uitgereik op 'n sekere datum betaal moet word soos per paar betaling terme. This leads to a natural definition of a CT which we called "Training Invoice" (om dit te onderskei van enige ander soort faktuur). The purchase order is similarly easily defined. We also created a "Training Services Invoice" by creating a new CT based upon the "Training Invoice" CT en bygevoeg net een kolom, "services rendered".

Met die bogenoemde, Ons kan nou demonstreer paar belangrike funksies van CT se sonder om te verval probeer om 'n abstrakte konsep te verduidelik; everyone already understands what we mean by "invoice" and "purchase order" en in plaas daarvan om te fokus op die meganika van die CT self.

Custom Lyste:

CT with columns of type "lookup" point to a custom list or document library. We use this extensively and for the sandbox, we created one supporting custom list that contains customers. We picked customers because it’s an easy concept to understand and easy to demonstrate. The Invoice CT has a column, "Kliënt" that is defined of type "lookup" that points at this list.

We created a similar custom list to manage "vendors" for the "Purchase Order" CT.

Dokument biblioteke:

Ons het twee dokument biblioteke: "Invoices" and "Mixed Documents".

We configured the invoices document library to manage only documents of CT type "Invoice".

We configured the "Mixed Documents" biblioteek al drie CT se bestuur.

Skep verskeie sienings wat wys sorteer, filter, gegewensblad en groepering.

Soek:

Ons gedefinieer twee nuwe bestuur eiendomme en gekarteer om hulle te faktuur nommer en die kliënt.

We created a new customized advance search site and modified it to enable users to search for "invoices" die gebruik van dié twee gekarteerde eiendomme.

Verander die XSLT sodat die faktuur en kliënt nommer, wanneer die huidige, appear in an HTML table in a bright color. The objective here is to demonstrate that such formatting is possible.

Sit alles bymekaar:

Ons reël vir die sleutel gebruikers om deel te neem in 'n demonstrasie.

Ons volg hierdie eenvoudige script:

1. Beskryf die betekenis en doel van 'n CT, gebruik van fakture en die aankoop bestellings as voorbeelde.
2. Wys die faktuur CT definisie terselfdertyd hulle verseker dat hulle nie nodig het om te gebruik daardie skerms hulself, net haal die konsepte.
3. Gaan na die fakture dokument biblioteek.
4. Laai 'n dokument.
5. Demonstreer dat die kliënt drop-down werklik afkomstig van 'n persoonlike lys.
6. Voeg 'n nuwe kliënt aan die kliënt lys en dan werk die onlangs foto faktuur se meta data met die nuutgeskepte kliënt.
7. Switch to the "mixed documents" library and upload a document. Explain how the system prompts for a document type.
8. Go back to invoices document library and show how clicking on a column name changes sort order.
9. Demonstreer kolom-vlak filter.
10. Toon verskillende standpunte demonstreer multi-vlak sortering, filter en groepering.
11. Wys die data vel oog.
12. Explain the purpose of a "untagged documents" sien.
13. Skakel oor na die persoonlike gevorderde soek.
14. Teen hierdie tyd, die onlangs opgelaai dokument moes gewees het gekruip en geïndekseer, so 'n soektog wat demonstreer die vermoë om op die faktuur op te spoor deur middel van die gekarteerde eiendom.
15. Ons demonstreer die verskil tussen soek via gekarteerde eiendomme vs. net 'n teks soek.

Op hierdie punt, we are more or less done with the demo. It seems to take about 30 aan 45 minute, afhangende van hoeveel mense vra vrae.

We then send them back to their desks with "homework". This consists of a simple excel spreadsheet where we ask them to define for us what they think they need in terms of CT’s, beide op 'n hoë vlak (net naam en besigheid gebruik) as well as columns and type of data they would store in the column. We don’t ask them to define column data types in MOSS terms, but business terms.

In Opsomming:

We’ve created a sandbox environment that we can use to demonstrate some core MOSS features whose appeal are enterprise-wide.

We have modeled easily understood and common business entities so that users can focus on MOSS and not get bogged down on the entities / voorbeelde hulself.

Business users walk away from theses sessions with "homework" in die vorm van Excel-dokumente wat hulle nou is bevoeg om in te vul en te gebruik vir die ontwerp van hul eie eerste-cut inhoud tipes.

Ten slotte, as ons doen demos met verloop van tyd, die kliënt se span lede hulself meer in staat om na uit te voer, doen om die demo's om hulself en oor die algemeen vry om die res van ons het om te werk aan meer komplekse kwessies, soos globale taksonomie, komplekse werkstromen, BDC en die soos.