SharePoint Community Sverige

En ständigt återkommande fråga är om man skall använda versionshantering på dokument eller inte.

To be!
- Slipper fundera på att göra kopior på utgåvor som man vill spara eller gå tillbaka till.
- Man får en spårbarhet där man kan se vilka förändringar som är gjorda och av vem. Framför allt nyttigt om flera samarbeter i samma dokument.
- Med hjälp av minor/major kan man styra hur arbetsversioner jmf med releasade versioner är synliga.

Not to be!
- Onödigt många kopior skapas av dokumenten
- Databasen växer okontrollerat
- Användarna är vana att kopiera filer vid behov för att skapa delversioner
- Användarna använder ändå pdf-filer som ett sätt att skapa delversioner

Vad är er erfarenhet av detta. Vanligt är kanske att man med goda intentioner slår på versionshanteringen men måste stänga av den för att den ställer till med mer onytta än nytta.

/j

Gör ett inlägg på det här

Inlägg i den här diskussionen

Hejsan,
allt nytt gör alltid lite ont i början :-)
Jag har också sett och hört de argumenten du har för att inte använda versionshantering, men jag tycker att fördelarna överväger nackdelarna.

- Onödigt många kopior skapas av dokumenten
Detta är väl lite av syftet med versionshanteringen, att man skall kunna gå tillbaka och se tidigare versioner. SharePoint har till och med möjligheten att styra detta en del. Till exempel så kan du ju ställa in hur många versioner du vill spara. Jag rekommenderar också att man alltid slår på att man måste checka ut dokumenten innan man redigerar dem, detta gör att man slipper short-term check-outen och på så sätt onödiga versioner. Använder man sig också av de inbyggda quota funktionerna så kan man lägga ansvaret på site collection admin att hantera när det finns för mycket data. Detta underlättar även nästa påstående

- Databasen växer okontrollerat
Om nu databasen skulle växa okontrollerat så beror det på att man inte har etablerat en tillfredställande governence plan för sin SharePoint installation. SharePoint, och tredje partsprodukter, erbjuder en hel del faciliteter för att hantera detta.

- Användarna är vana att kopiera filer vid behov för att skapa delversioner
Detta ser jag som en utbildningsfråga och jag har snarare sett att de flesta ser detta som en lättnad, de slipper skapa flera versioner.

- Användarena använder ändå PDF-filer för att skapa delversioner
Detta är väl inte heller fel. Har man som vana att skapa PDF filer (vi gör det till exempel för de dokument vi skickar till kund) och låter dem leva i SharePoint så har man bra koll på vilka officiella/publika dokument som finns och användarna behöver inte heller lokalt skapa PDFer. Visst kan man tycka att detta då krockar med Major versions av orginaldokumenten, men då kan man ju istället sätta sina policies så att man inte behåller lika många versioner av orginaldokumentet (om man nu vill spara disk).

Summa summarum, jag tycker att man skall börja med verionshantering så tidigt som möjligt, men sätta upp regler för detta som alla är med på. Sedan är det en utbildningsfråga.

Sen kan man faktiskt säga för att citera IDG; det är "Omöjligt att bli av med SharePoint" - och det beror på att användarna inte vill ha något annat :-)

/WW

Gör ett inlägg på det här

Tycker också att fördelarna överväger. Så man vill ha så mycket argument som möjligt!

Om jag inte minns fel så har en viss MVP med versionshantering som punkt nr.5 i sin presentation "10 sätt att driva sina SharePoint användare till vansinne" och jag kan hålla med om att detta kan bli en tröskeleffekt till att införa ett nytt arbetssätt.

Jag har fått rekomendationer att inte slå på tvingande check-out då detta skapar nya versioner av dokumenten trots att man bara skall uppdatera ett metadatafält, stämmer det? Kan du förklara begreppet "short-term check-outen".

Här kommer lite mer funderingar runt ämnet.

Om man skapar kopior eller pdf-er på sitt dokument och sedan fortsätter att redigera dokumentet, hur vet man då vilken utgåva av huvuddokumentet som man utgick ifrån.

Här kommer två olika varianter på detta.

1. Ett sätt skulle kunna vara att döpa pdf-filen till "dokument-1.0.pdf" om man utgick ifrån 1.0 versionen av dokumentet. Då blir det nya dokument av alla pdf'er man skapar som utgår från samma huvuddokument "dokument.doc".

2. Man skulle kunna lägga till ett metadata på pdf-filen som anger ovanstående utgångsversion. Då kan man skapa versioner även av pdf-filerna. Blir mer överskådligt då eftersom endast senaste versionen är synlig i listan.

En annan intressant frågeställning är hur man länkar till dokument. Om man t.ex. skapar en lista i samband med ett utskick av ett antal dokument och att varje objekt i listan i dokumentet länkar till en specifik version av dokumentet i sharepoint så måsta man kunna länka till en äldre version av dokumentet. Går det? Eller måste den gamla versionen lyftas upp till aktiv för att man skall kunna nå den via vanliga dokumentgränssnittet i browsern?

Om man har skapat unika dokument med versionen i filnamnet så slipper detta problem.

Som sagt det finns en hel del att fundera runt detta.

/J

Gör ett inlägg på det här

Gokväll
Detta är som sagt inte ett lätt ämne och inte lätt att göra en produkt som hanterar det på ett optimalt sätt, kanske därför Documentum kostar lite :-)
Personligen gillar jag enkelheten och möjligheterna med SharePoints sätt att hantera det hela, trots vissa brister, som du nämner ovan.

När det gäller short-term vs long-term check-outer så är en short-term check-out implicit, dvs filen checkas ut när man öppnar filen och checkas-in då man stänger filen. Jämför detta med en long-term där man talar om att nu checkar jag ut den och nu checkar jag in den. Problemet med short-termen är att om man sitter med ett dokument öppet länge så kan Office "tappa anslutningen" till servern och själv checka in dokumentet då den anser att klienten inte längre använder dokumentet. Eller så är ett annat vanligt problem att man öppnar dokumentet och inte är medveten om att man egentligen checkar ut det och "råkar" checka in det.
Därav anser jag att man alltid skall tvinga användaren att göra ett medvetet val när man checkar ut dokumentet.
Har man också bra policies och regler för sparade versioner så behöver det inte växa så mycket, samt att du kan ju skriva över befintlig version.

Angående PDF hanteringen så är det ett problem, däremot kan man ju alltid se till att ha versionsnummret i footern/headern på dokumentet.

Vill du länka till äldre versioner så kan du enkelt gå in i versionshistoriken på dokumentet och hämta länken. Högerklicka och välj kopiera länk och du får en länk som ser ut så här: http://XXX/_vti_history/1025/My%20Documents/Test.docx. Detta är version 2.1 av ett dokument. 1025 = 1024 + 1, där 1024 betyder 2.0 och 1:an 0.1. Version 1.2 har nummer 514: 512 (1.0) + 2 (0.2). Lite bit-hantering så löser man det :-).
SharePoint 2001, om ni kommer ihåg det, hanterade detta riktigt snyggt (inte optimalt dock, men snyggare) - där lade man bara till (x.y) i slutet av filnamnet så fick man rätt version.


/WW

Gör ett inlägg på det här

Jag har jobbat mycket med dokumenthantering i en dedikerad dokumenthanteringsapplikation. Och versionshantering är enligt min mening en av grundstenarna i en fungerande dokumenthanteringslösning. Allt efter principen att information skall bara finnas på ett ställe och där skall den vara aktuell.

Att databasen växer kommer du inte runt då användarna annars skapar delversioner som helt nya dokument och helt okontrollerat. Som Tobias nämner så är det ju möjligt att bestämma hur många versioner man vill spara etc vilket gör att man har bättre kontroll över tillväxten i dbn med versionshanteringen påslagen. Något jag saknar i SharePoint som fans i den applikation jag jobbade med var möjligheten till så kallade "visafiler".

Det va rhelt enkelt en kopia av filen i ett arkivbeständigt format som ex PDF/A. Denna kunde skapas automatiskt när man släppte majorversions av dokumentet (1.2, 2.0). Sedan kan man ställa in hur applikationen skall hantera dessa när en ny version skapas. Skall man bara spara arkivfilen eller själva orginalfilen (.doc eller .xls etc.).

På det viset kan man minska filstorlekar i konverteringen till en så kallad arkivfil och minska db storlek. Dessutom så lär man organisationan hantera officefiler som orginaldokument och inte som distributionsmaterial.

Men ett dokumenthanteringssystem utan versionshantering är bara ett steg på vägen till ett rikitgt dokumenthanteringssystem...

Gör ett inlägg på det här

Håller med om att det är bättre att en applikation håller ordning på versionerna än att användarna gör det på egen hand.

Givetvis är behovet av att spara versioner olika beroende på vilket dokumenttyp samt verksamhet man jobbar med. Man kan som du beskriver spara alla kommunicerade versioner som PDF för att kunna se vad som är publicerat, det är verkligen att rekomendera.

Min fundering just nu är om man behöver spara alla delversioner av originaldokumentet om man som ovan skapar delversioner i t.ex. PDF.

När jag diskuterat med användare hur ofta det är att man behöver gå tillbaka till en tidigare version och jobba vidare från den originalfilen. Det är förvånandsvärt många anser att det inte är något akut behov att spara alla versioner av originaldokumentet under uppbyggnadsperioden.

Många av våra kunder använder CAD och här kan man tycka att delversioner borde vara naturligt. Men även här säger man att det är mycket sällan som man måste gå tillbaka till en tidigare utgåva och fortsätta arbetet ifrån den.

Förmodligen är det så att man oftast förädlar materialet d.v.s. tillför information mellan versionerna och skillnaderna i versionerna är just det att man har tillfört.

Vi jobbar med två applikationer som skapar delversioner i t.ex. PDF baserat på t.ex. versioner, ändring av visst metadata fält eller andra kombinationer.

Dels har Bamboo solutions en applikation som skapar pdf'er från Officedokument.
http://store.bamboosolutions.com/ps-16-5-office-to-pdf-conversion-s...

Sedan jobbar vi även Organice Publisher som gör detta även med CAD-filer samt lite mer.


Intressant diskussion. Fler som har synpunkter?

Gör ett inlägg på det här

RSS

© 2010   Skapad av Andreas Kviby   Powered by .

Emblem  |  Rapportera en händelse  |  Användarvillkor