Jednym z najważniejszych zadań systemu zarządzania aktami (RM) jest dokumentowanie działalności instytucji czy organizacji, tworzenie zapisanej i niezmienialnej pamięci jej działalności i historii, zapisywanie dowodów które mogą być użyte (np. przez historyka lub sąd) z pewnością, że nie zostały one zmienione czy zafałszowane. W tym aspekcie MoReq2012 jest istotny również dla archiwów, których funkcja pokrywa się w dużym stopniu z tymi zadaniami.
Moduły MoReq2010
MoReq2010 – wymagania sytemu zarządzania aktami – jest podzielone na moduły, które opisują różne działy albo funkcje oprogramowania. Moduły to jednocześnie serwisy, części oprogramowania które te funkcje spełniają. Niektóre rodzaje serwisów są już w powszechnym użyciu w prawie każdym systemie wielo-użytkownikowym, niektóre są specyficzne dla MoReq.
Moduły obsługujące użytkowników to Grupy Użytkowników i modelowy Moduł Ról. Zadaniem modułu użytkowników jest zarządzanie użytkownikami i ich grupami, podobnie do istniejących użytkowników w systemach komputerowych, ale z konkretnymi ograniczeniami (np. nie wolno ponownie używać identyfikatorów itp.). Moduł ról opisuje role jakie moga przyjmować użytkownicy, i możliwości dostępu do przypisane tym rolom. Jan Kowalski może więc na przykład należeć do grupy Działu Handlowego, i posiadać rolę Administratora z prawami dodawania nowych użytkowników, ale tylko w tym dziale.
Moduły dotyczące dokumentów to serwis Klasyfikacji i serwis Rekordów. Nowością MoReq2010 jest stosowanie podwójnej, przenikającej się hierarchii klas (kategorii) i agregacji (teczek). Obie są hierarchiczne, i obie mają możliwość dziedziczenia. Każdy dokument musi należeć do jednej i tylko jednej klasy, i jednej i tylko jednej agregacji, ale duplikaty dokumentów mogą się znajdować w różnych agregacjach, i należeć do różnych klas. Klasy mają określać kontekst biznesowy, a agregacje dziedziczenie metadanych, praw dostępu a także klas. Jeśli to brzmi skomplikowanie to prawdopodobnie jest, ale daje bardzo wiele możliwości dopasowywania systemu do struktury organizacji.
Metadane są tematem trzech modułów: Metadanych (modelowy), Eksportu oraz Przeszukiwania – Sprawozdań. Jak łatwo się domyślić, moduł metadanych pozwala na definicję schematu opisu metadanych (danych o danych) – administracyjnych, kontekstu i dokumentu. Schemat metadanych ma dla każdego pola typowe atrybuty, takie jak jak rodzaj (tekst, liczba, data, itp.), identyfikator języka, czy jest wymagane czy opcjonalne, czy może się powtarzać i ile razy, itp. Metadane będą używane w module eksportu, który ma spełniać wymagania transferu danych do innego systemu, albo w celach archiwalnych. Metadane są tez używane w module przeszukiwania i raportów, który ma w założeniu spełniać typowe zadania przeszukiwarek, z wymaganiem przeszukiwania po wartościach dowolnego pola metadanych, zdarzeniach i datach dotyczących każdej encji w systemie, innymi słowy ma znaleźć każdy bit informacji.
Dwa moduły poświęcone usuwaniu czy likwidacji dokumentów wymagają komentarza. W niektórych ustawodawstwach, szczególnie w amerykańskim, proces sądowy posiada etap odkrywania (discovery) dokumentów. Firma, która w tym momencie rzuca się do niszczenia dokumentów w niszczarkach narażona jest na bardzo duże kary. Moduły Harmonogramu Likwidacji oraz Wstrzymania Likwidacji dokumentów są odpowiedzią na ten proces sądowy. Zwykle nie ma problemu jeśli dokument jest zniszczony zgodnie z oficjalnym harmonogramem, ale niszczenie musi być natychmiast wstrzymane jeśli sąd wydaje nakaz dostarczenia pewnych dokumentów. Likwidacja dokumentów nie musi zresztą oznaczać ich fizycznego niszczenia, mogą one być przenoszone do magazynu czy np. przekazywane jakiemuś archiwum.
Podsumowanie
MoReq2010 wydaje się być dobrze przemyślanym dokumentem. Jest oparty na sprawdzonych i intuicyjnie zrozumiałych konceptach takich jak hierarchia pojęć. Człowiek zupełnie instynktownie grupuje encje (przedmioty, pojęcia, dokumenty) w grupy i podgrupy. Pojęcie dziedziczenia też jest intuicyjnie zrozumiałe, jeśli jakaś grupa posiada pewną cechę, to jej podgrupy też tę cechę mogą posiadać (a więc dziedziczą ją od grupy rodzicielskiej) – zupełnie tak samo jak dzieci od rodziców.
Problem pojawia się dopiero wtedy, kiedy próbujemy zastosować sztywne reguły do sytuacji spotykanych w życiu. Wymaganie, aby każdy dokument należał do klasy i do agregacji ma sens, bo wprowadza dyscyplinę i daje kontekst. Ale zwykle obiekt jest pierwszy, a kategorię tworzy się dopiero wtedy, kiedy pojawi się większa liczba obiektów. Jeśli żyjemy wśród zebr i słoni, naturalnym podziałem może być na zwierzęta w paski i gładkie. Dodanie antylop zmieni nam podział na kopytne i trąbalskie – teraz zebra należeć będzie do innej już kategorii. Tylko organizacje o bardzo sztywnej i dawno ustalonej strukturze mają dobrze zdefiniowane hierarchie; w większości takie hierarchie tworzą się ad-hoc, i podlegają częstym zmianom. Oczywiście zawsze można problem ominąć tworząc kategorię i agregację nazwie “Różne”, ale to jest przegraną systemu.
Podobnym problemem jest zdefiniowanie co w ogóle jest aktem (record), a co nie. Czy brudnopis listu jest już aktem i powinien być wciągnięty do systemu? Druga i trzecia wersja tego dokumentu? Czy konwersacja na korytarzu spełnia takie warunki? Zapis fonograficzny zebrania? Email napisany w pośpiechu i z błędami? Email napisany dokładnie i z przemyśleniem? Czy też aktem jest tylko ostateczny, sprawdzony i podpisany (najlepiej ze stempelkiem) i wciągnięty do dziennika podawczego (dziś do systemu RM) dokument?
MoReq2010 nie odpowiada na te pytania. Nie jest to jego słabością, ale należy traktować tę specyfikację jako projekt w toku, dobry początek. Dalsza praca jest konieczna aby przenieść te wymagania w diałający system czy systemy RM. Należy się mu przyglądać, i za rok czy kilka lat ocenić na nowo przydatność MoReq2010 (czy tez następnych wersji) – również do archiwów.
Marek Zieliński
Artykuł ukazał się 4 listopada 2012 w Blogu archiwistów i bibliotekarzy Instytutu Piłsudskiego
Może Cię też zainteresować: