(ამ ჩანაწერში ჯვარი გამოქვეყნდა შორის http://paulgalvin.spaces.live.com/blog/ და http://blogs.conchango.com)

გზავნილები ამ საიტზე არის საკუთარი და არ ასახავს Conchango პოზიციები, სტრატეგიების ან მოსაზრებები.

მიმოხილვა:

ამ ჩანაწერში ასახავს ზოგიერთ ფონზე ინფორმაციას დიდი (3,000 მომხმარებელი) 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, ჩვენ დაახლოებით 50% complete with the first phase of the project. As things progress, მე განაახლებს ამ ჩანაწერში და / ან ჩაწერის ახალი ჩანაწერების.

ამ კონკრეტულ შემთხვევაში, 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. As you can imagine, ეს არ იყო საუკეთესო rollout სტრატეგია (რაც კლიენტს ადვილად აღიარებს) და როდესაც MOSS მოვიდნენ, the client resolved to "do it right" და დაქირავებული us მათ დახმარებას.

ერთი ცენტრალური კითხვებს ჩვენს წინაშე მდგარ როცა დავიწყეთ ამ პროექტის განსახორციელებლად იყო: როგორ უნდა გააცნოს MOSS რომ ამ ორგანიზაციის? Given that the client already had experience with SharePoint, ჩვენ გვაინტერესებდა — do we need to do "differential" სასწავლო ან არ დავიწყებთ მიწიდან მდე? 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, დოკუმენტის მართვა, ძებნის, უსაფრთხოების, აუდიტორიის გათვლილი, პროექტის მართვა, "fabulous forty" თარგები, workflow, ბიზნეს მონაცემები შემაერთებელი, და ა.შ.. Couple this with the fact that it’s a large organization that შეიძლება მართლაც გამოიყენოს პრაქტიკულად ყველა ძირითადი MOSS ფუნქცია და თქვენ საქმე დიდი პროექტი საწარმოს მიღწევა და ბევრი კარგი რამ ხდება.

ჩვენ თვალწინ ეს საკითხი დრო და დრო ისევ … MOSS აქვს საწარმოს მდიდარი თავისი საწარმოს მხატვრული კომპლექტი, ჯერჯერობით კი გარკვეულწილად დახვეწილი კლიენტებს რთული გონებრივი შთამნთქმელი იმ თვისებები, რომ აღარაფერი ვთქვათ, რომელიც შეიცავს საგრძნობ ფრაქცია თავიანთ ყოველდღიური.

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.

სფერო:

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" ცუდი. სინამდვილეში, the "less" that we decided for the initial rollout was miles ahead of where they were before we started. ჩვენს შემთხვევაში, the "less" გადაიქცა:

• მარტივი დოკუმენტის მართვა გამოყენებით დოკუმენტის ბიბლიოთეკების, version control and content types.
• ეფექტური ძიების საფუძველზე შინაარსი ტიპის და ადრინდელს წინასწარ ძებნა (მეშვეობით მოახერხა თვისებები, XSLT წარმოების საკმაოდ შედეგები, და ა.შ.).

გარდა ზემოთ საწარმოს მასშტაბით თვისებები (რაც იმას ნიშნავს, რომ ისინი უნდა შემოვიდა out ყველა დეპარტამენტებისა და წევრებს), ჩვენ დასძინა შემდეგ სინგლეტონი in-ფარგლებს მინი პროექტები:

• მტკიცებულება კონცეფციის BDC ინტეგრაციის.
• მრავალფუნქციური ნაბიჯი და მრავალ ფილიალში workflow პროცესის შექმნა მეშვეობით SPD.
• კომპლექსი InfoPath ფორმა.
• მოპირკეთება KPI-ს გარკვეული ბიზნეს პროცესის (ალბათ HR ნიჭი შეძენის ჩვენს შემთხვევაში, მიუხედავად იმისა, რომ შეიძლება შეიცვალოს).

ფარგლებს აქ არ არის 100% accurate but representative of our approach and sufficient for my purpose here, which is to explain what I consider to be an "effective" დანერგვა MOSS რომ იქნება კლიენტს მტკიცედ ქვემოთ ოქროს გეზი სრული MOSS მიღებას.

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. თუმცა, they will be "out there" და ერთი იმედოვნებს, რომ სხვა ბიზნეს ერთეულების ეცოდინებათ ან გაეცნონ მათ და სურვილია, რომ ეს თვისებები თავს, leading to greater adoption. These singleton success stories also serve to provide our sales team "ammunition" წარმატებით გამარჯვების მეორე, third and n-phase projects.

რა მივიღეთ დანერგვა და რატომ?

რა ჩამოსახლების დოკუმენტის მართვა და ძებნა როგორც საბაზისო საწარმოს მასშტაბით მოთხოვნა, we needed to start gathering details. As a practical matter, ამ ტრიალებს ირგვლივ გაგება საბუთები და რომ საბოლოო ჯამში mapped იმის გასაგებად შინაარსი ტიპის.

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, მას სვეტები და სვეტების განისაზღვრება მონაცემთა ტიპები, მაგრამ CT მონაცემთა ტიპები ზე მეტ მარტივი რიცხვი / თარიღი, but also "choice" and "lookup" and the like." We can talk about "extending" შინაარსი ტიპის, 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. ანუ, თითქმის ყველას, რომ საკითხების MOSS rollout.

Using a white board is iffy. I’ve presented the idea of a content type and drawn brilliant (ან, რათა მათ, როგორც ჩანს,) სურათები შინაარსი ტიპის და რას აკეთებს თქვენთვის თვალსაზრისით ძებნის და როგორ შეიძლება გაფართოვდა, და ა.შ.. და ბოლოს, ეს იმას გრძნობს, როგორც ზოგიერთი ნათურები არ ჩართეს, but the resulting white board picture is a mess.

ეს მიგვიყვანა ჩვენი დღევანდელი და ჯერჯერობით ყველაზე ეფექტური სადესანტო ადგილი: MOSS სავარჯიშოში საიტი კონფიგურაცია ნახოთ ეს თვისებები.

გამოყენება სავარჯიშოში საიტი, ჩვენ დემონსტრირება:

• ინფორმაციის სახეები:
  • შექმნა CT მრავალი მონაცემთა ტიპები (ტექსტი, თარიღი, არჩევანი, ლოგიკური, საძიებელი, და ა.შ.).
  • გაფართოება CT შექმნის ახალ CT საფუძველზე მშობელს.
  • ეძებს დოკუმენტების გამოყენებით CT მეტადატის.
• დოკუმენტი ბიბლიოთეკების:
  • ასოცირების ერთ CT ერთად ბიბლიოთეკაში.
  • რა ხდება, როდესაც ჩვენ ატვირთეთ დოკუმენტი, რომელიც ბიბლიოთეკაში?
  • ასოცირების შესახებ მრავალჯერადი CT-ს ერთად doc ბიბლიოთეკა.
  • რა ხდება, როდესაც ჩვენ ატვირთეთ დოკუმენტი, რომელიც ბიბლიოთეკაში?
  • ფილტრაცია და დახარისხება მეშვეობით სვეტი სასაქონლო in doc lib.
  • დოკუმენტის ბიბლიოთეკა ჩვენებები:
    • დახარისხება
    • დაჯგუფება
    • "Quick entry" (მონაცემების ფურცელი ხედვა)
    • "Untagged data" (დახმარება გაუწიოს მიგრაციის MOSS, სხვა შინაარსის წყაროები; მეტი ამ ქვემოთ).

Sandbox საიტის:

ჩვენ შემუშავებული ჩვენი სავარჯიშოში საიტი უნდა იყოს მუდმივად ფუნქცია განვითარების გარემო, რომელიც გამოიყენება სასწავლო მიზნებისთვის დიდი ხნის შემდეგ ჩვენ დასრულდება პროექტი და შედის რამდენიმე ნივთები, როგორც ეს აღწერილია:

ინფორმაციის სახეები:

ჩვენ განსაზღვრული შემდეგი შინაარსის ტიპის: ფაქტურა, შესყიდვის მიზნით, მომსახურება ფაქტურა.

ჩვენ შევარჩიეთ ანგარიშს და შესყიდვის მიზნით, რადგან ისინი მეტნაკლებად საყოველთაოდ ქვეშ
stood entities. Everyone in business understands that an invoice is a demand for payment to a დამკვეთის ამისთვის თანხა გაცემული გარკვეული თარიღი გადახდა თითო ზოგიერთი გადახდის პირობები. This leads to a natural definition of a CT which we called "Training Invoice" (ზღვარის მას რაიმე სხვა სახის ფაქტურის). The purchase order is similarly easily defined. We also created a "Training Services Invoice" by creating a new CT based upon the "Training Invoice" კომპიუტერული და დასძინა, მხოლოდ ერთი სვეტი, "services rendered".

აღნიშნული, ჩვენ ახლა დემონსტრირება რამოდენიმე ძირითადი მახასიათებლები CT-ის მიღების გარეშე bogged ქვემოთ ცდილობს ახსნას აბსტრაქტული ცნება პირველი; everyone already understands what we mean by "invoice" and "purchase order" და არიან ნაცვლად შეუძლია ფოკუსირება მექანიკის CT თავად.

საბაჟო სიები:

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, "customer" that is defined of type "lookup" that points at this list.

We created a similar custom list to manage "vendors" for the "Purchase Order" კომპიუტერული.

დოკუმენტი ბიბლიოთეკების:

ჩვენ შევქმენით ორი დოკუმენტი ბიბლიოთეკების: "Invoices" and "Mixed Documents".

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

We configured the "Mixed Documents" ბიბლიოთეკის მართვის ყველა სამი CT ნახვა.

შექმნა რამდენიმე ჩვენებები, რომ ნახოთ დახარისხება, ფილტრაცია, მონაცემთა ფურცელი და დაჯგუფება.

ძიება:

ჩვენ განსაზღვრული ორი ახალი მოახერხა თვისებები და mapped მათ ინვოისის ნომერი და მომხმარებელთა.

We created a new customized advance search site and modified it to enable users to search for "invoices" გამოყენებით ამ ორი mapped თვისებები.

შეცვლა XSLT ისე, რომ ანგარიშფაქტურა და მომხმარებელთა რაოდენობის, როდესაც წინამდებარე, appear in an HTML table in a bright color. The objective here is to demonstrate that such formatting is possible.

ჩვენ ყველა ერთად:

ჩვენ მოვაწყოთ გასაღები წევრებს მონაწილეობა დემო.

ჩვენ დაიცვას მარტივი script:

1. აღწერეთ მნიშვნელობა და მიზანი CT, გამოყენებით ანგარიშფაქტურების და შეძენა ბრძანებებს როგორც მაგალითი.
2. ჩვენება ფაქტურის CT განმარტება ამავდროულად არწმუნებს მათ, რომ ისინი არ უნდა გამოვიყენოთ იმ ეკრანებზე თავად, უბრალოდ გააშუქა ცნებები.
3. გადასვლა ანგარიშფაქტურების დოკუმენტის ბიბლიოთეკა.
4. ატვირთე დოკუმენტი.
5. დემონსტრირება, რომ მომხმარებელს ჩამოსაშლელი მართლაც sourced საწყისი საბაჟო სია.
6. დამატება ახალი მომხმარებელი მომხმარებელს სიაში და შემდეგ განაახლებს აქაჩული ფაქტურის ნახვა მეტა მონაცემების ახლად შექმნილი დამკვეთის.
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. აქციას სვეტი დონის ფილტრაცია.
10. ჩვენება განსხვავებული შეხედულებები, რომ ვაჩვენოთ მრავალ დონის დახარისხება, ფილტრაცია და დაჯგუფება.
11. ჩვენება მონაცემების ფურცელი ხედვა.
12. Explain the purpose of a "untagged documents" სანახავად.
13. შეცვლა ადრინდელს გაფართოებული ძიება.
14. ახლა, ახალი აქაჩული დოკუმენტი უნდა crawled და ინდექსირებული, ასე ასრულებს ძებნის იმაზე უნარი იქნებიან, რომ ანგარიშფაქტურა მეშვეობით mapped ქონება.
15. ჩვენ დემონსტრირება სხვაობა ეძებს მეშვეობით mapped თვისებები vs. მხოლოდ ტექსტი.

ამ ეტაპზე, we are more or less done with the demo. It seems to take about 30 to 45 წუთი, დამოკიდებულია რამდენი კითხვა ხალხი ითხოვს.

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, ორივე მაღალ დონეზე (უბრალოდ სახელი და ბიზნეს მიზნით) 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.

შემაჯამებელ:

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 / მაგალითები თავს.

Business users walk away from theses sessions with "homework" სახით Excel დოკუმენტები, რომელიც მათ ახლა კომპეტენტური შევსება და გამოიყენოს შემოთავაზებული საკუთარი პირველი დაჭრილი შინაარსი ტიპის.

და ბოლოს, როგორც ჩვენ შეასრულოს demos დროთა, კლიენტების გუნდის წევრები საკუთარ თავს კიდევ უფრო შეუძლია, განავითაროს, გავაკეთოთ დემო ნახვა თავს და ზოგადად უფასოა დანარჩენ ჩვენს მუშაობას უფრო რთული საკითხები, როგორიცაა გლობალური ტაქსონომიის, კომპლექსი workflows, BDC და ანალოგიური.