Po pierwsze PRZEMYŚLANE WDRAŻANIE
Każde oprogramowanie jest dokładnie tak skuteczne, jak potrafią je wykorzystać użytkownicy. Wdrażany system zawsze powinien mieć dokładną specyfikację zarówno samego oprogramowania (zwłaszcza jeśli licencja dopuszcza własne modyfikacje), jak też API oraz instrukcje obsługi (liczba mnoga jest tu kluczowa). Instrukcje będą istotne nie tylko na etapie wdrażania oprogramowania, ale również przez cały okres jego wykorzystania. Na ich podstawie należy stworzyć „łańcuch kompetencji”, według którego wiedza będzie dystrybuowana. Nie ma konieczności ponoszenia kosztów np. szkoleń zakupionych u dostawcy, jeśli można przeszkolić jedną grupę pracowników, którzy potem przekażą swoją wiedzę dalej. Najlepiej, jeśli na szkolenie zostaną wytypowani Ci, którzy posiadają szerokie kompetencje w systemie.
W przypadku wdrażania centralnego modułu repozytorium tekstu oraz edytora XML kluczowe grupy, które będą korzystać z systemu to:
- Administratorzy – każdy program, niezależnie od stopnia skomplikowania, wymaga ponoszenia nakładów na administrację. Zwłaszcza, jeśli taki program obsługuje i przechowuje najcenniejszą wartość wydawnictwa – treść.
- Redakcja i dział produkcji – redaktorzy i koordynatorzy projektów, to najważniejsze ogniwa w całym procesie produkcji, ponieważ pełnią funkcję strażników systemu. To oni będą dobierać elementy struktury dla danej publikacji, które w procesie jej tworzenia będą stosowane. To oni będą decydować, w jaki sposób przełożyć treść do bazy danych, by miała jak największą wartość.
- Autorzy – wbrew pozorom, poprawnie zaprojektowany system pozwala niemal całkowicie wyeliminować problemy związane z autorami. Jeśli proces będzie uwzględniać procedury dla tych wyjątkowo opornych, a redakcja będzie stała na straży spójności wprowadzanych danych, to ich rola nie powinna znacząco wykraczać poza standardowe metody tworzenie treści.
Proces szkolenia powinien odbywać się w sposób ciągły i być stałym elementem każdej nowej publikacji, równie ważnym co numer ISBN. Czy w projekcie będzie brał udział nowy autor? Czy będzie to autor „na stałe” czy jedynie incydentalny? Czy w efekcie ma powstać publikacja w XML? Czy autor tworzył już wcześniej takie publikacje? Odpowiedź na te wszystkie pytania jest kluczowa dla płynnego działania wdrożonego systemu.
Zaniedbania w warstwie szkolenia mogą być bardzo kosztowne. Wystarczy, że autor źle otaguje elementy tekstu, to redakcja będzie musiała powtórzyć całą jego pracę. Jeśli natomiast redakcja nie będzie miała świadomości wymogów, które musi spełnić tworzone dzieło, by trafić do założonych kanałów dystrybucji, to tagowanie trzeba będzie poprawiać na dalszych etapach, po zakończeniu procesu tworzenia i redagowania.
Po drugie WIEDZA
Częstym problemem złożonych systemów informatycznych, niezależnie od tego, w jakiego rodzaju przedsiębiorstwie czy projekcie funkcjonują, jest brak wiedzy poszczególnych uczestników co do potrzeb innych osób działających w tym samym środowisku. Na przykład, jeśli redaktor nie wie, jaki ma być efekt końcowy i jakie są wymogi np. systemu dla publikacji na stronie internetowej, to nie będzie w stanie odpowiednio zaprojektować struktury tego projektu. Dlatego, przynajmniej od etapu prac redakcyjnych, wszyscy uczestnicy powinni wiedzieć, do której bramki strzelają, tzn. jaki ma być końcowy efekt ich pracy. W ten sposób można wyeliminować błędy, które wymagałyby niezbędnych poprawek na dalszych etapach, by dany projekt w efekcie był przystosowany do konkretnej metody publikacji.
Złotą zasadą, którą powinni kierować się wszyscy jest reguła, że zbyt skomplikowana struktura jest zawsze lepsza od zbyt prostej. Dwa różne elementy, nawet jeśli w ostatecznym rozrachunku powinny być tak samo otagowane, łatwo sprowadzić do wspólnego mianownika. Wydzielenie rozdzielnych elementów, które zostały omyłkowo tak samo otagowane, to już w stu procentach praca ręczna.
Po trzecie PROCEDURY
Podstawowym założeniem każdego oprogramowania jest uporządkowanie i uproszczenie procesów, które to oprogramowanie ma obsługiwać. W związku z tym konieczne jest wdrożenie odpowiednich procedur dookoła tych procesów, żeby oprogramowanie po pierwsze, odpowiadało stanowi faktycznemu, czyli pokrywało się z metodami pracy danego przedsiębiorstwa, a po drugie, mogło funkcjonować wydajnie. Procedury są jak alkohol – stosowane z umiarem nie szkodzą nawet w dużych ilościach. Trzeba jednak pamiętać o tym, że nie każda publikacja złapie się w opracowane procedury i nie każdy autor będzie z nimi kompatybilny. Dlatego, podobnie jak oprogramowanie, procedury muszą uwzględniać wyjątki.
Bardzo dobrym zwyczajem jest zaszywanie procedur we wdrażanym oprogramowaniu. Na przykład, w edytorze można dodać system tworzenia harmonogramów, dzięki którym praca będzie przebiegać według ustalonych założeń. W przypadku ograniczeń finansowych lub możliwości wybranego oprogramowania, nie pozostaje nic innego jak pilnowanie przestrzegania procedur „manualnie”.
Po czwarte BUSINESS FIRST
Nowe technologie, oprogramowanie czy procedury potrafią zakręcić w głowie. Nierzadko sami użytkownicy, pod wpływem uproszczeń i narzędzi oferowanych przez system, starają się na siłę zmieścić w nim każdy projekt. Dlatego kluczowe jest takie rozłożenie kompetencji, by produkcja przebiegała w sposób racjonalny. Redaktor nie koniecznie jest najlepszą osobą do decydowania, czy dany projekt powinien być procedowany jako pełny XML, częściowy XML czy w ogóle poza systemem. Taką decyzję powinny podejmować osoby bliższe finansom, które są w stanie wyliczyć różnicę w kosztach produkcji, jak również marketingu, które decydują o drogach dystrybucji. Z biznesowego punktu widzenia, nie stosuje się droższego, wolniejszego i trudniejszego procesu tworzenia skomplikowanych publikacji w XML, jeśli jej jedynym przeznaczeniem jest tradycyjny wydruk. Dlatego zawsze należy zachować zdrowy rozsądek i korzystać z ulepszeń i możliwości danego rozwiązania wtedy, kiedy ma to uzasadnienie finansowe lub technologiczne.
Po piąte KROK PO KROKU
Istnieje wiele metod wdrażania oprogramowania krok po kroku. W przypadku edytora, można to zrobić na kilka sposobów. Po pierwsze, można zacząć wdrożenie od projektów, które nie będą procedowane do pełnego XML po to, żeby przystosować pracę redakcji do wszystkich innych funkcji systemu. Można też ograniczyć liczbę pierwszych użytkowników systemu do kilku wyznaczonych redaktorów, a dopiero potem ta wybrana grupa będzie przekazywać wiedzę dalej. Innym sposobem jest wdrażanie dział po dziale, czyli najpierw redaktorów, którzy na pierwszym etapie wdrożenia sami tagują teksty, a dopiero w dalszej kolejności autorów.
Kompleksowe wdrożenie i zatrzymanie całego procesu produkcji na czas niezbędnych szkoleń nigdy nie jest idealnym rozwiązaniem. Termin przeprowadzenia takiej rewolucji należy starannie zaplanować. Na przykład, w wydawnictwach, w których proces produkcji charakteryzuje się sezonowością, można zaplanować wdrożenie w spokojniejszym okresie, kiedy terminy nie są tak napięte.
Przykładowa publikacja
Spróbujmy umieścić w procesie produkcji przykładową, raczej standardową publikację o szerokim zastosowaniu.
- Akceptacja projektu i przekazanie go do publikacji
- Czy produkcja w pełnym XML ma sens? Tak.
- Czy autorzy są incydentalni czy stali? Stali.
- Czy jest sens szkolić autorów tak, by byli w stanie samodzielnie pracować w systemie? Tak.
- Przekazanie publikacji do redakcji
- Wybór makiety, dobór styli (przestrzeni nazw)
- Utworzenie projektu w systemie
- Uzupełnienie danych niezbędnych np. do archiwizacji, jeśli system to przewiduje
- Dodanie odpowiednich użytkowników w systemie (autorów, redakcji, nadzoru);
- Utworzenie harmonogramu (jeśli system ma takie możliwości)
- Prace autorskie i redakcja
- Szkolenie autorów, praca na projekcie testowym
- Współpraca redakcji z autorami, w szczególności na pierwszych etapach. Najlepiej, jeśli nadzór nad pracą autorów będzie stały, by jak najszybciej wyeliminować błędy, które potencjalnie mogą być powielane wielokrotnie
- Korekta i redakcja na bieżąco, jeśli system umożliwia taki tryb pracy
- Korekty językowe, merytoryczne i wszelkie inne, wyłączając typowe dla danych formatów błędy (np. przeniesienia dla wersji drukowanej), prowadzone są na tym etapie
- Produkcja
- Wygenerowanie wersji elektronicznej – z poprawnej bazy danych pliki epub i mobi powinny generować się w sposób całkowicie automatyczny, z minimalnym nakładem pracy ręcznej w przypadku bardziej skomplikowanych publikacji
- Eksport do DTP – większość programów DTP dostępnych na rynku radzi sobie z XML słabo albo wcale. W zdecydowanej większości przypadków taka obsługa nie ma żadnego sensu i tylko spowalnia pracę oraz ewentualny import tekstu. Dlatego wszystkie korekty powinny zostać wprowadzone w systemie edycji, na etapie redakcji i prac autorskich.
- Eksport do strony internetowej – ta forma eksportu jest zdecydowanie najprostsza, z reguły odbywa się w pełni automatycznie przez system API centralnego modułu repozytorium
Podsumowanie
W procesie wdrażania jakiegokolwiek oprogramowania kluczowe jest zrozumienie procesów, które będą obsługiwane, jak również tych, które zostaną przez nie dotknięte. Dlatego tak ważnym elementem jest dogłębna analiza i rozbicie całego procesu na etapy, które przedsiębiorstwo będzie w stanie „strawić”. Czasem lepiej w pierwszej kolejności poprawić nieskuteczne lub nieoptymalne procesy, zaczekać, aż się przyjmą i dopiero wtedy zacząć wdrażać oprogramowanie, które będzie je obsługiwać.
Drugim aspektem jest projektowanie samego systemu, zwłaszcza centralnego repozytorium treści w taki sposób, by stanowiło złoty środek między procedurami a wyjątkami. Jeśli oprogramowanie nie będzie obsługiwało wyjątków, to nie będzie można w ramach procesu wyprodukować niczego ponadstandardowego. Jeśli będzie obsługiwało za dużo wyjątków, to każdy projekt będzie unikatowy, w związku z czym korzystanie z oprogramowania może stracić sens. Nie ma uzasadnienia organizowanie procesu, który nigdy się nie powtórzy.
Wydawnictwa ukierunkowane na produkcję skomplikowanych i wymagających treści, muszą zwrócić szczególną uwagę na element standaryzacji. Każde oprogramowanie będzie wymagało ograniczenia liczby stosowanych makiet czy wdrożenia np. standardów serii. W efekcie procesu opartego o XML (czy dowolny inny język znakowany) powstaje treść, która jest w równym stopniu dziełem co bazą danych. Niesie to za sobą konkretne możliwości, ale też ograniczenia, zwłaszcza w warstwie graficznej. Odpowiednio zaprojektowany proces produkcji i oprogramowanie pozwalają te ograniczenia zminimalizować, ale nie całkowicie usunąć.
Naszym zdaniem w większości wydawnictw korzyści płynące z XML i odpowiednich systemów do jego obsługi, pomimo wszystkich ograniczeń samego XML i strukturyzowania treści do bazy danych, wielokrotnie przewyższają koszty niezbędne do poniesienia przy jego wdrożeniu.