Mostantól érhető el egy nagyon szűk, zárt kör számára az Office14 Alpha változata. A további ütemezésről még nincs hivatalos információ.
“Today Microsoft provided a select group of customers early access to an Alpha version of Office server technologies. However, Microsoft is not disclosing information about the timing for a Beta version at this time.”
A szeptemberben Washingtonban tartott SharePoint Best Practices Conference után idén először február elején folytatódik a sorozat, ezúttal San Diegoban. Oda sajnos most nem tudok kiutazni (bár a szervezők ismét hívtak), de amint arról már beszámoltam, a következő állomás április elején Londonban lesz.
This conference goes beyond the how-to’s of SharePoint and delves into real world issues facing successful SharePoint implementations. Learn how to:
- Make consistent, confident decisions at every level, across your enterprise.
- Break the cycle of avoidance, disagreement and ignorance that leads to subpar results.
- Eliminate design, deployment, organizational and administrative confusion.
- Apply effective SharePoint decision-making in any situation and in turn enhance enterprise communication, collaboration and efficiency - while significantly lowering cost.
- Replace disorder with clarity, direction and confidence.
Learn practical and productive SharePoint practices from the industry’s leading authorities. Event speakers include:
- Microsoft MVPs
- Microsoft Product Team Members
- Industry Experts
Nos, örömmel jelentem, hogy az európai állomáson, Londonban is előadóként veszek részt, ráadásul ezúttal két témával is:
Jön valaki esetleg? Regisztráció és bővebb információ az esemény honlapján.
Nemcsak itthon, a nemzetközi piacon is megfigyelhető, hogy ha az ügyfelek "dokumentumkezelő rendszert" (Document Management System) szeretnének, a projekt első (nulladik) lépése elengedhetetlenül egy fogalomegyeztetés kell legyen: pontosan mit is ért az ügyfél "dokumentum" alatt? Talán el sem hinnénk, mekkora a valószínűsége annak, hogy egészen mást, mint mi magunk. S nem azért, mert az ő vagy a mi definíciónk rossz/helytelen/pontatlan, egyszerűen csak azért, mert más környezetben mozgunk, dolgozunk. Kb. olyan ez, mint amikor valaki "jó" szoftvert kér - tiszta filozófia ez, ügyféllélektan…
Gyakran az elsődleges félreértést a dokumentum és az irat fogalmak közötti különbség okozza.
Amíg a végfelhasználó a Word, Excel, Access és egyéb dokumentumait szerkeszti a számítógépén, dokumentumkezelésről beszélünk. A tevékenység kapcsán sok egyéb mellett olyanok kérdések merülnek fel, mint a dokumentumoknak egy központi tárba való mentése, ottani tárolása és nyilvántartása, a felhasználó által onnan való kikölcsönzése és ezen idő alatt mások számára való zárolása, a dokumentum verzióinak kezelése, a dokumentumnak a külvilág számára történő publikációjának támogatása, vagy a jóváhagyási procedúra. E folyamatok közben a dokumentum tartalma megváltozhat.
Az iratkezelés során a dokumentumot nyilvántartásba vesszük, annak tartalmát pedig befagyasztjuk: egy iktatott dokumentum tartalma többet már nem változhat. Ebből következően az előbb említett dokumentumkezelési tevékenységek értelmüket vesztik. A dokumentumot ettől a ponttól tekintjük iratnak, és ettől a ponttól kezdve szükségesek a különböző iratkezelési lépéseket támogató funkciók: sok egyéb mellett az érkeztetést, iktatást, szignálást, vagy átadást-átvételt támogató funkciók.
Mind a dokumentum-, mind az iratkezelés összetett üzleti folyamatot takarhat, melyek a két fogalom határán természetesen összeérnek. Az alábbi ábra például egy iratkezelés folyamatát szemlélteti (elnézést a képminőségért, éles projektterv…):
Nos, ha a fenti két folyamatot jól elkülönítettük, tisztázhatjuk, pontosan mit is szeretne az ügyfél. A SharePoint például tipikus dokumentumkezelési funkciókkal bír, ám megfelelő tervezéssel és architektúrával iratkezelő rendszer alapja is lehet. Ebben azonban most nem mennék bele, maradjunk inkább a dokumentumkezelésnél - önmagában ez is jókora téma…
Annak idején, életem első iratkezelő rendszerének fejlesztésekor kollégám egy, a Gartner által akkoriban készített kimutatást talált, amely a következőt mutatta:
"Egy, a Gartner Group által végzett felmérés szerint dokumentumaink „kezelésére” heti 8 órát (egy teljes munkanapot) fordítunk átlagosan! Ennek fényében könnyű megfogalmazni a legfontosabb célt: a hatékonyság növelésén keresztül a fenti érték drasztikus csökkentése. Ehhez növelni kell az átláthatóságot, csökkenteni kell a dokumentumok elérési idejét, egyszerűsíteni, szabványosítani és automatizálni kell az iratkezelést, szabályozhatóvá tenni az alkalmazottak tevékenységét, és nem utolsó sorban tudásbázisok építésével hatékonyabbá, gyorsabbá kell tenni a döntési mechanizmusokat."
Azóta ugyan eltelt néhány év, és sajnos pontosabb/frissebb információim nincsenek, de érzésem és tapasztalataim szerint az arány hasonló lehet. Nemrégiben például abban a megdöbbentő élményben volt részem, hogy amikor az egyik ügyfelünktől a kezelendő dokumentumok mennyiségére vonatkozóan kértünk becslést, a válasz mértékegysége a “néhány száz folyóméter”(!) volt. Nyomtatva, egymás mellé mappázva, természetesen…
A dokumentumkezelő rendszerekkel támasztott konkrét követelmények tehát projektről projektre eltérnek, eltérhetnek, vannak azonban olyan alapfunkciók, melyekben valamennyi projekt közös.
Először is, természetesen szükség van arra, hogy dokumentumainkat rendszerezetten, hatékonyan, sőt felhasználóbarát módon tároljuk. A dokumentumkezelés első, mindenki által megélt és ismert "lépcsője" az a módszer, amikor valamennyi felhasználó a lokális gépén dolgozik, majd a munka eredményét, a tényleges dokumentumokat e-mailben küldözgetik oda-vissza. Jó esetben bekapcsolt "track changes" mellett, rosszabb esetben anélkül. Jó esetben más épp nem módosít egy dokumentumon, amíg én épp dolgozom rajta, de ezt semmi nem garantálja…
Természetesen ebben az sem feltétlenül egyértelmű, hogy amikor hivatkozunk egy dokumentumra, annak pontosan kinél lévő, melyik verziójára gondolunk.
A központosított, egységesített tárolás magában hordozza annak lehetőségét, hogy a munkatársak valóban ugyanazon dokumentumpéldányokat használják egy-egy időpillanatban, sőt arra is alkalmas kell legyen, hogy további dokumentumkezelési (s nem iratkezelési!) funkciókat ellásson: tárolás, közös szerkesztés megvalósítása, megosztás, verziókezelés, különféle tartalomtípusok kezelése, stb.
Ha valaki csupán olvasásra szeretne megnyitni egy dokumentumot, általában akadály és gond nélkül megteheti azt (természetesen a megfelelő jogosultságokkal – lásd később). Akár többen egyszerre is, hiszen módosítani, visszaírni senki sem szeretne, ezért nem akadályozzák egymást.
Amint azonban valaki szerkesztésre nyitja meg a dokumentumot, fennál az a probléma, hogy elmenti a változásait, majd valaki más újra ment, ugyanezen dokumentumra - s ezúttal ez utóbbi módosítások lesznek érvényben, akár felül is írhatják az első dolgozó munkáját.
A fenti problémára jelent megoldást a check out/check in (magyarul: kivétel/beadás). A szerkesztő munkatárs kiveszi (check out) a dokumentumot, ezáltal a többiek számára csak olvasásra lesz megnyitható (a dokumentum zárolásra kerül), másfelől az is egyértelmű lesz, hogy éppen ki dolgozik rajta. Amikor pedig elkészült a szerkesztési feladatokkal, visszaadja (check in) azt, így a többiek számára ismét teljes egészében hozzáférhető lesz.
A fentiekkel szorosan összefügg a verziókezelés megvalósításának kérdése. Fontosságát nem lehet kellőképpen hangsúlyozni: a korábbi változatok visszaállítása, a módosítások végigkövetése, stb. mind-mind olyan igény, elvárás, melyek a modern dokumentumkezelő rendszerek elengedhetetlen részévé váltak.
A dokumentumok készítése, szerkesztése során úgynevezett verziókat (version) hozunk létre, melyek mentén végigkövethetjük annak életciklusát, szerkesztési menetét. Az egyes verziókat növekvő számozással jelöljük, s a különféle dokumentumkezelő rendszerek a vonatkozó üzleti igényeknek megfelelően többféleképpen valósítják ezt meg. Általában háromféle verziókezelési alapmódot ismerünk:
Szorosan a verziókezeléshez kapcsolódik a tartalom-jóváhagyás folyamata is. A dokumentumnak az a munkaverziója, amely még nem került jóváhagyásra a megfelelő szerepkörrel (Approval) rendelkező jóváhagyó személy(ek) által, függő (Pending) állapotban van, s csak a sikeres jóváhagyás után válik mások számára is elérhetővé. Hogy maga a jóváhagyás hogyan történik pontosan, az függ a dokumentumtár verziókezelési beállításaitól is.
Ugyanakkor a jóváhagyáson túl egyéb kapcsolódó munkafolyamatok (workflow) megvalósítása is igény lehet (sőt, általában szerves része a megvalósítandó alapkövetelményeknek), ezért üzleti szempontból és architekturálisan is fontos kérdés, hogy a megvalósításra kerülő rendszer miképpen, hogyan támogatja különféle workflow-k implementálását.
Az üzleti életben természetesen arra is szigorú keretek között kell ügyelni, hogy mely tartalmakhoz kik és hogyan férnek hozzá: ki olvashatja az adott dokumentumot, ki szerkesztheti, ki hozhat létre új elemeket, sőt az is fontos kritérium, hogy ki törölhet bármit is, sőt, van-e egyáltalán lehetőség már létrehozott tartalmak eltávolítására.
Ráadásul az is elképzelhető (sőt…), hogy egy dokumentum életciklusa során más és más jogosultsági szabályok érvényesek rá: például egy projekt előterjesztéshez kapcsolódó dokumentumok esetében:
Jól látható tehát, hogy már maga a dokumentumkezelés mint üzleti fogalom is igen összetett – konkrét technológiai megvalósítástól függetlenül is. Nem beszélve arról, ha mindezt még iratkezelési funkciókkal is szeretnénk kiegészíteni…
Folyt. köv.
Az Office&SharePoint PRO nemrégiben felkért néhány SharePoint MVP-t, hogy próbáljuk megjósolni, szerintünk mi várható ebben az évben a mi szakterületünkön. Jómagam a Windows Server 2008 és az SQL 2008 elterjedését várom, MOSS 2007 alapként is. Emellett a MOSS további erősödésére számítok, hiszen jól kialakított és megtervezett infrastruktúra esetén jelentős hatékonyság-növelés érhető el, ez pedig a mai világban akár a túlélés feltétele is lehet.
A többiek (Mikhail Dukov, Michael Greth, Robert Bogue, Tobias Zimmergren, Gary Lapointe, Andrew Woodward és John Holiday) előrejelzéseit-jóslatait itt olvashatjátok.
Ez az év is izgalmasan kezdődik: most jelentek meg ugyanis az első olyan ügyfelek, akik Windows Server 2008-ra upgrade-elnek, így a MOSS 2007 is átkerül erre az op.rendszerre. Nyugaton és az USA-ban lassan már az a meglepő, ha valaki Win2003-at használ, itthon úgy tűnik, most indul a hullám.
Szó ami szó, tegnap telepítenem kellett. Az op.rendszer, Windows 2008 frissen telepítve várt rám, ám sem domain nem volt, sem SQL, szóval volt még alapoznivaló bőven, de ha az emberlánya este 10 körül áll neki, időnk mint a tenger… Fél 2 után már készen is állt minden, hogy a MOSS 2007 elkezdjen felkúszni.
A többi SharePoint MVP-től tudom azonban, hogy ez a scenario elég sok “apró” meglepetéseket tartogathat, így aztán előszedtem minden ide vonatkozó korábbi levelezést és blogpostot, s ezekkel az információkkal felvértezve álltam neki a Nagy Feladatnak. Szerencsémre túl sok falba már nem ütköztem, a legfontosabbakat azonban összefoglalnám:
Most jöhetnek az éles telepítések, ügyfeleknél, valódi üzleti környezetben…
A Service Pack 1 nélküli WSS 3.0 és MOSS 2007 hivatalos supportja hamarosan, 2009. január 13-án lejár, érdemes odafigyelni!
Bovebb infó itt.
Nem tudtam,
hogy lehetetlen,
ezért megcsináltam...
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Dec | Feb » | |||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
Powered by WordPress