Wpływ zmian na funkcjonowanie przedsiębiorstwa
Każde przedsiębiorstwo, wydawnictwa nie są tu wyjątkiem, jest organizmem, przez który płyną procesy, a ich efektem są konkretne usługi lub produkty. Każdy taki proces angażuje pewną liczbę osób i systemów informatycznych (bez których ciężko dzisiaj zrobić cokolwiek). Wdrażanie jakichkolwiek zmian w procesie z reguły wymaga dokonania zasadniczych zmian w obu tych warstwach. O ile instalacja nowego oprogramowania przeważnie jest stosunkowo prosta, o tyle „instalacja” nowych funkcji w warstwie pracowników powoduje znacznie więcej problemów. Rodzi naturalny opór i, przynajmniej przejściowo, powoduje nieład lub przejściowe spowalnianie procesu produkcyjnego. Jest to całkowicie naturalne i, przynajmniej według dzisiejszej wiedzy, nieuniknione. Idealne rozwiązanie tego problemu nie istnieje, ale można przynajmniej zmniejszyć jego wpływ na bieżące funkcjonowanie przedsiębiorstwa.
W niniejszym artykule spróbujemy opisać i wyjaśnić proces wdrożenia XML w warstwie obsługi i przechowywania treści na etapie prac autorskich i redaktorskich. W kolejnych częściach przejdziemy przez następne elementy procesu produkcyjnego, aż do uzyskania końcowego produktu.
W tym artykule przeanalizujemy, zgodnie z zasadami Murphy’ego, najgorsze z możliwych rozwiązań. Wydawnictwo, w którym będzie wdrażany XML, ma ograniczone zasoby, pulę trudnych autorów (na przykład publikuje książki w dziedzinach z ograniczonym dostępem do specjalistów biegłych w obsłudze komputera) i redaktorów, publikuje zarówno proste jak i skomplikowane dzieła oraz bazuje całkowicie na przepływie dokumentów drukowanych. Konieczne jest zatem wdrożenie systemu całkowicie zmieniającego styl produkcji, przy jednoczesnym zachowaniu przynajmniej części elementów starych procesów oraz przekonanie, zarówno autorów jak i redaktorów, do nowych rozwiązań. Na pierwszy rzut oka przypomina to żonglowanie podskakując na jednej nodze na polu minowym. Czy tak jest w istocie? Sprawdźmy.
Analiza
Najważniejszym etapem wdrożenia jakiegokolwiek oprogramowania jest analiza. Wszystko to, czego architekt w tydzień nie zaplanuje, programista będzie musiał pisać sześć miesięcy. Zadaniem architekta jest dogłębne poznanie nie tylko wszystkich procesów, które będzie obsługiwać projektowane oprogramowanie, ale też wszystkich innych, na które te pierwsze będą miały wpływ. W gruncie rzeczy w pierwszej kolejności powinien przeanalizować sposób funkcjonowania firmy, ewentualnie zaproponować optymalizację niektórych procesów i metod, a dopiero potem przejść do fazy projektowania oprogramowania.
W przypadku wdrażania systemu przechowywania treści najważniejsze jest zaprojektowanie bazy danych, tak by zostały uwzględnione dwa podstawowe zadania:
- Ograniczenie zakresu możliwych do wykorzystania elementów przy jednoczesnym
- Udostępnieniu odpowiednio szerokiego zakresu możliwych do wykorzystania elementów.
Celem jest wypracowanie złotego środka, czyli tak skonstruowanej bazy danych, by z jednej strony ograniczyć uprawnienia autorów do tworzenia nowych, unikatowych stylów niewykorzystywanych w innych publikacjach, a z drugiej umożliwić im stworzenie publikacji zawierającej wszystkie istotne informacje. Procedura budowania bazy dająca zbyt dużą swobodę autorom i redaktorom nie ma sensu, ponieważ traci ona wtedy swój wielki atut unifikacji treści. Z kolei zbyt duże ograniczenie uprawnień nadmiernie upraszcza budowaną bazę treści lub wręcz uniemożliwia jej tworzenie.
Przeprowadzenie takiej analizy wymaga nie tylko wnikliwego przyjrzenia się procesom, ale także wszystkim projektom wydawnictwa, zarówno tym produkowanym obecnie, jak również archiwalnym. Należy pamiętać, że przynajmniej część publikacji już zakończonych powinna zostać skonwertowana i włączona do jednorodnego korpusu treści. Dlatego baza musi nie tylko zaspokajać aktualne potrzeby wydawnictwa, ale również umożliwiać wprowadzenie zakończonych projektów przy zachowaniu rozsądnych nakładów pracy.
W efekcie powinna powstać baza danych, czyli tzw. repozytorium treści, standardy komunikacji w obrębie procesów i poza nimi oraz, co najważniejsze, siatka stylów z ewentualnymi przestrzeniami nazw, która będzie stanowić podstawę do tworzenia zarówno każdego nowego dzieła, jak też konwertowania starych wartościowych publikacji.
W poprzednim artykule poruszaliśmy temat wyboru właściwego rozwiązania, ale dla przypomnienia: można wybrać albo oprogramowanie „z półki”, którego funkcjonalność jest określona i ograniczona, stworzyć własne, „uszyte na miarę” lub połączyć obie opcje w postaci zestawu niezależnie stworzonych programów połączonych centralnym systemem wymiany danych. Wybór najlepszej drogi zależy od całego szeregu czynników, na przykład zgodności dostępnych, gotowych produktów z procesami danego wydawnictwa, dostępnych środków czy czasu i poziomu zaawansowania informatycznego istniejących procesów. Drugim ważnym czynnikiem jest kolejność wdrażania. Jasne jest, że w pierwszej kolejności musi zostać wdrożona baza danych wraz z systemami jej obsługi, ponieważ przechowywanie treści to absolutny priorytet. Bez zrealizowania tego etapu, nie da się przejść do następnych.
Kolejnym elementem do wdrożenia jest system wprowadzania treści do bazy, czyli edytor. Mając w tym przypadku ograniczone środki, na razie nie wdrażamy żadnych dodatkowych funkcjonalności. Ideą jest otrzymanie programu, który umożliwia wprowadzanie treści do bazy danych w sposób spójny i nieuciążliwy dla autorów i redaktorów.
Wybór oprogramowania – Edytor XML
Filozofia „XML First”, o której pisaliśmy, zakłada wdrożenie XML do procesu produkcyjnego na jak najwcześniejszym etapie. Idealnym rozwiązaniem, niestety nie zawsze osiągalnym, byłoby wdrożenie go już na etapie pracy autora. Kluczowymi czynnikami przy wyborze edytora są:
- Łatwość obsługi rozumiana nie tylko jako prosty interfejs, ale również podobieństwo do dotychczas stosowanych lub po prostu popularnych rozwiązań, w których tworzone są teksty niestrukturyzowane
- Duże możliwości na etapie edycji i prac redaktorskich, w szczególności w zakresie przesuwania elementów w obrębie publikacji (co nierzadko stanowi problem niektórych baz danych)
- Poziomy dostępu, dzięki którym można np. ograniczyć uprawnienia autorom pozostawiając pełną dowolność tworzenia struktury redakcji
- Obsługa skomplikowanych elementów publikacji – indeksów, przypisów itp.
- Wewnętrzny system komunikacji
Jednak filozofia „business first”, która wydaje się najbardziej zdroworozsądkową, wskazuje na kilka problemów z powyższym rozwiązaniem. Po pierwsze, nie wszyscy autorzy będą chcieli, mogli lub umieli skorzystać z takiego systemu. Po drugie, nie wszystkie publikacje będą kwalifikować się do konwertowania do bazy danych treści lub po prostu umieszczenie ich w repozytorium treści byłoby bezużyteczne. Problem strukturyzowania zasobów wydawnictwa można rozwiązać na dwa sposoby. Pierwszym jest zduplikowanie całego procesu niestrukturyzowanych publikacji „na boku”, który będzie istnieć obok XML. Wszystkie publikacje, które z jakiegoś powodu nie muszą powstawać w strukturze XML, będą przetwarzane po prostu „starym” systemem. Drugim jest wybór takiego edytora, który umożliwi pracę na różnych „poziomach XML” – od pełnego XML aż po tekst nieustrukturyzowany. Przewagą drugiego sposobu jest unifikacja procesu produkcyjnego na wszystkich etapach, tzn. każdy autor pracuje w tym samym oprogramowaniu, a treść trafia do tego samego repozytorium. W zależności od klasyfikacji, publikacja może być tworzona w taki sposób, by trafiała do bazy danych XML lub do archiwum tekstów niestrukturyzowanych. Jeśli weźmie się pod uwagę fakt, że do tego systemu będą dobudowane dodatkowe rozwiązania informatyczne usprawniające prace wydawnictwa, np. systemy organizacji pracy, komunikacja, archiwum czy raporty, drugie rozwiązanie staje się bardziej atrakcyjne.
W sytuacji bardzo trudnych relacji ze współuczestnikami można zastosować bardziej przystępne rozwiązanie, w którym autor tworzy treść w dowolnym, znanym sobie edytorze, a następnie redakcja konwertuje ją do formatu XML po zakończeniu etapu korekt. Tak długo, jak wymagana jest intensywna współpraca na linii redaktor – autor, tekst pozostaje w formie nieustrukturyzowanej, a następnie to redaktor umieszcza plik XML w bazie danych w taki sposób, jak powinien zrobić to autor. Ten system pracy jest w stanie obsłużyć nawet najbardziej „niekompatybilnych” autorów.
Odpowiedni dobór założeń i spokojne, logiczne przyjrzenie się dostępnym na rynku rozwiązaniom pozwala zaoszczędzić czas, środki i przede wszystkim zmniejszyć zgrzyty na etapie wdrożenia. Trzeba jednak pamiętać, że każda tego typu zmiana procesów w przedsiębiorstwie jest pewną formą kompromisu. W którymś momencie trzeba powiedzieć „stop” i przestać optymalizować oprogramowanie pod kątem obsługi archaicznych czy niewykorzystywanych procesów, bo każde wdrożenie to nie tylko przystosowanie oprogramowania do potrzeb przedsiębiorstwa, ale też przystosowanie przedsiębiorstwa do możliwości oprogramowania.
Podsumowanie
Podsumowując należy wymienić kilka najważniejszych zagadnień, o których należy pamiętać przy wyborze oprogramowania:
- Dogłębna analiza procesów istniejących w wydawnictwie
- Najpierw optymalizacja zastanych procesów, a dopiero potem projektowanie nowego oprogramowania
- Efektem analizy musi być kompleksowa koncepcja oprogramowania, a nie okresowo tworzonych elementów
- Najważniejszy etap, to prawidłowe zaprojektowanie bazy danych i arkuszy stylów
- Baza danych może być oparta o XML albo dowolny inny, kompatybilny format
- W drugiej kolejności konieczny jest wybór systemu wprowadzania treści (edytora)
- Nie zawsze rozwiązanie „szyte na miarę” będzie lepsze od tego „z pudełka”
- Wdrażane procesy muszą uwzględniać również pracę poza środowiskiem XML dla szczególnych przypadków
- System musi umożliwiać pracę tym autorom, którzy z trudem obsługują nawet takie programy, jak Open Office czy MS Word;
- Edytor musi mieć możliwość ograniczania uprawnień autorów do poziomu wyznaczonego przez redakcję