S&A ARIGA S.R.O. Studie a analýzy. Internetové redakční a publikační systémy

Transkript

1 S&A ARIGA S.R.O. Studie a analýzy Internetové redakční a publikační systémy

2 STUDIE A ANALÝZY Internetové redakční a publikační systémy Ariga s.r.o. Bellušova 1861/38, Praha 5, Telefon info@ariga.cz Všechna práva vyhrazena. Publikování celé studie nebo jejích částí není dovoleno bez souhlasu společnosti. Podrobnosti a informace najdete na

3 Obsah Co je to redakční systém? 2 Stručná historie redakčních systémů 3 FTP 3 Archie...3 Gopher 4 VERONICA...4 WAIS 5 Fulltextové vyhledávání...5 WWW 6 HTML...6 Válka prohlížečů...7 Speciální aplikace 7 Aplikace klient-server...8 Vybíráme redakční systém cena a výkon 8 Cena versus výkon...8 Cena náklady spojené s redakčním systémem 9 Výsledek výběrového řízení...11 Technické údaje...12 Cena je orientační vodítko!...12 Seznámení s produkty...13 Testovací provoz...14 Předávací protokol...15 Administrace serveru...16 Upgrade...16 Vyhodnocení cenové nabídky 18 Náklady na pořízení...18 Provozní náklady...18 Firemní specifika...19 Šablony...26 Redakční systémy podle vnitřní architektury 26 Nevýhody...27 Nevýhody...28 Podpora práce redakcí 29 Informovanost o stavu dokumentu...32 Uživatelské role...34 Pozor na práva a role!...35 Jednoduchost obsluhy 36 Práce s články 37 Nahrání článku...37 Klíčová slova...38 Vlastnosti...38 Import dat z jiných zdrojů 39 Personalizace klientské části 40 Uživatelské databáze 41 Výkon 41 Princip zobrazování dokumentu pomocí šablon...44 Nativní jazyk šablon...45 Makrojazyk šablon...45 Příklad šablony...46 Požadavky na jazyk šablon...48 Závěrem k redakčním systémům 49 Přílohy 50 Nejčastější chyby při volbě redakčního systému 19 Podcenění smluvního zajištění...19 Podcenění potřebných funkcí...19 Škálovatelnost řešení...19 Závislost na dodavateli...20 Funkcionality redakčního systému 20 Základní požadavky na funkce redakčního systému 22 Požadavky vznášené na redakční systémy a jejich možnosti 25

4 REDAKČNÍ SYSTÉMY ARIGA S.R.O Redakční systémy na internetu klíč ke zvýšení produktivity Základní úlohou a posláním redakčního a publikačního systému pro internetové server je zjednodušení práce, odstranění rutinních úkonů a tak zvýšení produktivity práce a jejího komfortu, v řadě neposlední pak i zlepšení návštěvníkova prožitku při práci s internetovým serverem. S polu s prudkým rozvojem internetu a potřebou publikovat na něm informace, přišla také potřeba používat k publikaci na internetu nástrojů usnadňujících práci s velkým komplexem informací. Původně vyvinuté protokoly internetu určené pro předávání informací, se ukázaly být pro komfortní práci samostatně nepoužitelné a tak nebylo čemu se divit, že postupně jednotlivé firmy začaly přicházet se servisními programy a aplikacemi, využívajícími standardních, nebo navrhujících proprietární protokoly k publikování informací na internetu. A protože podobné systémy již v médiích existovaly a protože i na internetu bylo jejich původní funkcí podporovat práci redakce, ustálilo se pro tyto systémy název redakční systémy a to ačkoliv dnes již s úspěchem většina těchto aplikací ze svého původního určení vybočuje a bylo by vhodnější nazývat je spíše systémy pro správu informací v IP sítích. Tento pojmologický rozdíl se může stát zanedbatelným, ovšem v uživatelích, kteří potřebují na internetu organizovat svoje informace, vzbuzuje název redakční systém zmatek, neboť tento uživatel nechce mít žádnou redakci, on má pouze své zaměstnance a chce organizovat informace, které tyto zaměstnanci produkují. Přes tento drobný názvoslovný nedostatek se budeme i nadále držet vžitého označení redakční systémy s tou výhradou, že jde o systémy určené obecně k organizování informací publikovaných na internetu, nebo v jakýchkoliv IP sítích. Co se ale ukazuje s postupem času jako podstatné, redakční systémy představují pro servery podnikající na internetu jeden z klíčových faktorů přežití. Výkon a kvalita redakčního systému rozhoduje nejenom o tom, kolik bude třeba investovat do hardware či jaká bude dostupnost server, ale také o tom, jakými funkcemi bude server disponovat a jak se bude lišit od konkurence. 1

5 Právě podcenění významu a úlohy redakčního systému představuje vedle rizika nezvládnutí financování a tedy obchodní stránky projektu, nejvýznamnější riziko internetového projektu. Domnívat se, že rozsáhlý a ambiciozní projekt obslouží hromada perlových skriptů je v podstatě rozsudek smrti pro takový projekt. Tento text nemůže sloužit jako vodítko pro výběr konkrétního redakčního systému, už kvůli rozdílnosti jednotlivých projektů, bude se ale snažit poskytnout obecné vodítko, podle čeho jednotlivé publikační systémy posuzovat. Také vás upozorní na rizika. Může se stát, že pokud je váš projekt v současné době rozsahem malý, budete považovat některé pasáže pro vás za nepodstatné. Přesto doporučujeme pročíst je minimálně v případě, pokud hodláte svůj projekt v budoucnu rozšířit. Autoři tohoto textu čerpají z mnohaleté zkušenosti s vývojem redakčních systémů a s jejich implementací do redakcí všeho typu, jak rozsáhlých zpravodajských redakcí významných firem jako jsou Mobil Media a.s., MojeNoviny VLP a.s., ale také pro firemní zákazníky jako Nokia nebo pro speciální zpravodajské týmy jako TV3. A samozřejmě i pro malé projekty o rozsahu jednoho člověka dělané ve volném čase. Co je to redakční systém? Redakčním systémem se obecně označují programy určené k organizaci informací a především textů v redakcích. Může se zdát, že tím se pole působnosti redakčních systémů nutně omezuje pouze na redakce, proto jsme také uváděli výše uvedenou výtku vůči označení redakční systémy. Faktem ale je, že pokud se kdokoliv rozhodne publikovat určité množství informací na internetu a nebude tak činit sám, tedy s počtem jedné osoby, bude muset záhy institucionalizovat procesy, jaké v běžných redakcích opravdu fungují. A pak je již vcelku lhostejné, zda se rozhodne pro pojmenování těchto procesů, jaké je v redakcích běžné, nebo zda si vytvoří vlastní pojmenování. U redakčního systému se očekává práce se strukturovanými informacemi, tedy možnost jejich vkládání, vyhledávání, třídění a následného publikování na internetu. Podle toho, jak jsou data strukturována, můžeme hovořit například o vkládání článků, zpráv, obrázků a dalších objektů do redakčního systému, přičemž chápeme, že struktura dat pro článek, zprávu nebo obrázek je rozdílná. Schopnost práce redakčního systému s různými datovými strukturami by na první pohled mohla vypadat jako stěžejní informace pro to, k jakému redakčnímu systému se přiklonit a podle čeho jej vybírat. Situace ovšem není zdaleka tak jednoduchá a výkonnostních kritérií, k nimž je vhodné a rozumné přihlížet, je celá řada. Budeme o nich podrobně hovořit v samostatné kapitole. Co je důležité si o redakčním systému pamatovat, je fakt, že by nám měl pomoci s publikováním informací na internetu a že by z nás měl být schopen sejmout rutinní a opakující se práci. 2

6 Stručná historie redakčních systémů Kapitolu věnovanou historii redakčních systémů musíme nutně začít poohlédnutím do fascinující historie internetu. První redakční systémy bychom totiž mohli ztotožnit s prvními internetovými protokoly určenými pro publikování informací. Ostatně, ještě i dnes převažuje publikování informací níže uvedenými protokoly nad skutečnými redakčními systémy, zejména pro jednoduchost jejich nasazení, nízkou obtížnost jejich používání u malého souboru informací a zejména také proto, že jsou k dispozici zdarma a představují standard, nad nímž lze bez problémů stavět vlastní aplikace. Těmito dědečky publikování informací se mimo tuto kapitolu nebudeme více zabývat. Vzhledem k tomu, že jde o standardizované internetové služby nebo protokoly, najdete o nich množství informací v kterékoliv knize o internetu a je tedy zbytečné podrobně se rozepisovat o jejich funkcích a používání. My se podrobněji budeme věnovat systémům druhé a třetí generace, tedy speciálním, nestandardizovaným aplikacím, které nabízejí podstatně více komfortu, podstatně více služeb a také požadují vyšší investice ať již pořizovací, na zaškolení, provozní a udržovací. FTP Za první redakční systémy bychom mohli považovat FTP, tedy protokol určený k přenášení informací v internetových sítích. Samozřejmě jde o redakční systém s velmi limitovaným komfortem práce, dnes ale stále patří mezi nejpoužívanější redakční systémy. Protokol FTP (File Transfer Protocol) vznikl v roce 1973 a jeho hlavním určením bylo přenášení dat z jednoho počítače na druhý. Pro přenášení dat bylo potřeba znát nejenom adresu cílového počítače, ale také přihlašovací jméno uživatele a heslo. Mnoho FTP serverů ale umožňuje používání takzvaného anonymního přihlášení, kdy jako uživatelské jméno se zadává anonymous a jako heslo adresa. Po dlouhou dobu bylo publikování informací na internetu téměř výhradní doménou FTP, velmi často právě ve spojení s anonymním přihlášením. Takto byly publikovány nejenom textové soubory, ale také soubory datové ostatně převážně pro ně se FTP používá podnes. ARCHIE Problémem FTP bylo především nalezení požadovaného dokumentu, souboru. Na statisících FTP serverů existovalo obrovské množství dokumentů a právě to množství činilo jakékoliv vyhledávání bez vyhledávacího nástroje problematické. Problém byl řešen v roce 1990, kdy dva absolventi kanadské McGillovy univerzity Peter Deutsch a Alan Emtage přišli s Archie, tedy programem, jenž se automaticky připojoval k různým FTP serverům a získával informace o souborech na nich uložených. Kdokoliv na internetu se mohl dotázat vyhledávacího programu Archie na název 3

7 soubor, který hledal a obratem získal seznam serverů a jejich adresářů, kde se tento soubor nalézá. Archie ale nevyřešil druhou část problému Archie sám už nezkoumal strukturu souborů a tak, pokud jste hledali soubor, v němž bylo obsaženo určité slovo, nebo o němž jste věděli, co má dělat, ale neznali jste jeho jméno, měli jste smůlu. Uživatel se vždy musel k FTP serveru připojit, vytvořit si lokální kopii souboru a teprve jeho prozkoumáním zjistil, zda skutečně našel, co hledal. Tento problém některé vyhledávače řeší s větším, ale spíše s menším úspěchem tak, že jsou schopny indexovat a později prohledávat i obsahy souborů v FTP serverech, především se to ale týká textových dokumentů uložených ve formátech PDF nebo například DOC. Gopher Malý tým vedený Paulem Lindnerem a Markem P. McCahillem z Minnesotské univerzity navrhl v roce 1991 protokol nazvaný Gopher. Tento protokol měl sloužit pro poskytování informací v rámci univerzity. Požadavky, na základě nichž byl vytvořen, mají obecnou platnost a proto stojí za to si je zrekapitulovat: jednoduše ovladatelné prostředí, aby mohl být používán i začátečníky minimální požadavky na množství přenesených informací, aby nebyla zbytečně vytěžována počítačová síť bezestavové spojení serveru a klienta, aby si server nemusel pamatovat, v jakém stavu se klient nacházel rychlé odbavení klientského požadavku serverem, aby bylo možno přejít k odbavování dalšího požadavku přístup k ostatním internetovým službám jako je FTP, telnet a Usenet News Gopher fungoval jako systém menu, kdy uživatel se mohl vnořovat do podmenu, vybírat a zobrazit si obsah souboru, poslechnout si zvukový záznam nebo obrázek. Oproti dnešnímu webu ale gopher neuměl vytvářet tyto menu odkazy v rámci dokumentů a odkazové menu muselo být od dokumentu odděleno. VERONICA Díky své jednoduchosti se Gopher stal velmi populárním, nejprve v USA a později i ve zbytku světa. Tak jako u FTP serverů ale i u Gopheru vyvstala nutnost indexovat dokumenty jeho prostřednictvím publikované. A protože zde již existoval předobraz ve službě Archie určené pro FTP, bylo snadné tento model aplikovat i na Gopher. 4

8 Stalo se tak v roce 1992, kdy Steve Foster z Nevadské univerzity v Renu vytvořil službu Veronica. Ta umožnovala prohledávat informace o registrovaných Gopher serverech a výsledky vyhledávání zobrazila ve formě menu Gopheru. Veronika ale stejně jako Archie neumožňovala vyhledávat podle obsahu jednotlivých dokumentů, což vzhledem k tomu, že Gopher se používal především pro publikování textových informací (zatímco FTP zejména pro datové soubory, jako jsou spustitelné programy) byl podstatný handicap. Ten překlenula až služba WAIS. WAIS WAIS (Wide Area Information Server) je služba existující na internetu již od roku 1988 a šlo o experimentání projekt vytvořený týmem Brewstera Kahleho z firmy Thinking Machines v kooperaci s Dowem Jonesem z Apple Computers a Peat Marwickem z firmy KPMG. Cílem projektu bylo ulehčení vyhledávání informací publikovaných na počítačové síti v celém světě. Uživatel zadal dotaz, jenž byl převeden do speciálního dotazovacího jazyka WAIS a rozeslán WAIS serverů ma internetu. Každý z těchto serverů prohledal svoje indexy a vrátil podle relevantnosti setříděné výsledky se seznamem nalezených dokumentů. Uživatel si mohl vybrat dokument, který odpovídal jeho požadavkům a WAIS server mu jej odeslal celý. Výhodou WAIS byla schopnost vyhledávat nejenom podle názvu dokumentu, ale i podle jeho obsahu, tedy prakticky fulltextově. FULLTEXTOVÉ VYHLEDÁVÁNÍ CO JE FULLTEXTOVÉ VYHLEDÁVÁNÍ? čeština někdy používá pojem plnotextové vyhledávání při fulltextovém vyhledávání se zjišťuje, zda dokument obsahuje pro vyhledávání zadaná slova. Pokud ano, zobrazí odkaz na dokument. Fulltextové vyhledávače mohou zároveň dávat příznak relevance dokumentu, tedy upozornit na dokumenty, které jsou vyhledávanému tématu zřejmě blíže, než jiné dokumenty. Relevance se vyhodnocuje například podle toho, kolikrát se vyhledávaná slova objevují v kterém dokumentu a předpokládá se, že dokumenty s vícenásobným výskytem těchto slov jsou relevantnější, než ty, kde se tato slova vyskytují méně často. Hlavní výhodou fulltextového vyhledávání je skutečnost, že prohledávání probíhá nejenom ve jméně dokumentu a třeba v jeho nadpisu, ale především v samotném textu dokumentu, například tedy v textu článku. Existují fulltextové vyhledávače určené pro celý internet, ale velké množství informačních serverů má své vlastní fulltextové prohledávání které vám umožní prohledávat komfortně články právě jen na tomto serveru. V dnešní době je možno WAIS považovat za mrtvou technologii, protože WAIS serverů již existuje na internetu jen velmi málo. Na druhou stranu poznatky získané při tvorbě WAIS technologie jsou základem moderních fulltextových vyhledávačů. 5

9 WWW V březnu roku 1989 byl Timem Bernersem Leem navržen World Wide Web, dnes známý pod zkratkou WWW, nebo též již jen web. Původním Leeho záměrem bylo nalezení vhodného způsobu, jak ukládat výzkumná data v Evropské laboratoři částicové fyzicky (CERN) v Ženevě. Berners-Lee navrhoval vytvořit systém, který by umožnil výzkumníkům samostatně publikovat své poznatky a vzájemně mezi sebou dokumenty elektronicky propojovat. Využil konceptu hypertextových odkazů, tedy odkazů, které vedou z jednoho dokumentu přímo do jiného dokumentu, nebo na jiný soubor, obrázek či zvukovou nahrávku. HTML WWW používá k formátování dokumentů (k popisu jejich grafického vzhledu) jazyk HTML (HyperText Markup Language), což je poměrně jednoduchá množina příkazů, pomoci nichž lze vytvářet tabulky, odstavce, měnit velikosti, barvy a typy písma, vkládat obrázky a další objekty do dokumentu a především odkazovat mezi jednotlivými dokumenty. Hlavní výhodou WWW proti Gopheru byla jeho lepší schopnost provazovat mezi sebou jednotlivé dokumenty. Při tvorbě odkazů nebyl uživatel odkázán pouze na vytvoření odkazového menu, ale mohl v kterémkoliv místě dokumentu zadat HTML příkaz pro odkázání na jinou stránku. Takové místo bylo zvýrazněno podtržením a čtenář dokumentu mohl kliknutím přejít na jinou část dokumentu, nebo dokonce na dokument uložený na úplně jiném serveru. HTML kód je oproti požadavku uživatele, tedy klienta, servírován WWW serverem. Klientský počítač používá pro práci s WWW zpravidla speciální aplikaci, WWW prohlížeč. Původní WWW prohlížeče byly výhradně textové (dnes je jím stále například Linx), dnešní moderní prohlížeče mají samozřejmě schopnosti mnohem větší, umí přehrávat videa, zvukové nahrávky, mají mnoho možností jako graficky presentovat podobu dokumentu atd. Používání WWW na internetu z počátku přeci jen neexpandovalo tak rychle, jak by se dalo očekávat při výčtu vlastností. Šlo o evropskou technologii, navíc dlouhou dobu v podstatě nepropagovanou a používanou jen v rámci fyzikálních pracovišť. V roce 1992 existovalo pouhých 26 WWW serverů. Přelom přišel v roce 1994, kdy společnost NCSA (National Center for Supercomputing Applications) veřejnosti představila první grafický prohlížeč Mosaic. S ním se již pracovalo velmi příjemně a navíc nabízel podstatně více možností, než prohlížeče textové jako vůbec první prohlížeč umožňoval vkládání grafických prvků do textu tak, aby v něm byly přímo zobrazitelné a dokonce tak, aby klikem na ně bylo možno odskočit na jinou část dokumentu. Toho Gopher schopen nebyl. Do konce roku 1994 již existovalo více jak 1500 WWW serverů a v roce 1995 již WWW předčilo FTP v počtu přenesených informací po internetu. 6

10 VÁLKA PROHLÍŽEČŮ Dalším impulsem pro rozšíření WWW byla válka prohlížečů, tedy souboj mezi dříve startující firmou Netscape a jejím prohlížečem Netscape Navigator a poději do ringu vkrošivším gigantem Microsoftem s jeho Internet Explorerem. Zatímco Netscape Navigator byl původně placený produkt, z počátku významně horší Internet Explorer byl zdarma a později dokonce byl přímo zakomponován do operačního systému Windows jako jeho součást. Od verze 4 byl Internet Explorer významně lepší produkt než Netscape Navigator a firmu Netscape odkoupil americký AOL. Tím se od roku 1998 stal de faccto standardním internetovým prohlížečem Microsoft Internet Explorer a hegemonii jeho vlády se jen občas pokoušejí prolomit nové verze Nestcape 6 vydávané již pod křídly AOL, okrajově pak placené produkty jakým je Opera a nově také open source projekt Mozilla. Tento projekt sice existuje poměrně dlouho, ale až v roce 2002 přinesl stabilní verzi internetového prohlížeče na jejíž bázi je postaven i Netscape 7. Mozilla dnes nabízí větší podporu standardů, než MSIE. Příjemné v této souvislosti je zmínit výborný WWW prohlížeč Arachne určený pro DOS, jenž je produktem šikovného českého programátora. Díky tomuto prohlížeči je možno k internetu přistupovat i z velmi starých počítačů, na nichž nemůže být provozován grafický operační systém. A jen na okraj připomínáme, že oba prohlížeče sloužily nejenom k prohlížení WWW stránek, ale také pro prohlížení stránek Gopher i k používání služby FTP tím je uspěch WWW cennější, neboť obstál v přímé konkurenci. Kladným rysem války prohlížečů byla neustále se zvyšující kvalita těchto produktů a především fakt, že byly záhy dostupné zdarma. Zároveň předhánění se obou rivalů vedlo k tlakům na standardizaci nových funkcí, které obě firmy překotně implementovaly a je možno se domnívat, že bez tlaku obou významných hráčů by tak rychlé standardizační posuny nebyly možné. WWW se tak rozvinul z graficky chudého prostředí do kreativního a graficky velmi nápaditě použitelného produktu. Díky rozmachu, jenž WWW zažíval po roce 1994 bylo záhy jasné, že jej postihne podobný problém, jako FTP a Gopher službu, tedy zahlcení informacemi, v nichž bude možno jen velmi s obtížemi najít požadovaný dokument. Proto byly založeny vyhledávací služby pracující s velmi přesnými a stále zlepšovanými fulltextovými vyhledávacími algoritmy. Od roku 1995 existuje AltaVista, v roce 1998 byl založen Google. Tyto vyhledávače samozřejmě mají i své odvozeniny a napodobeniny určené pro jednotlivé státy, takové vyhledávače bývají přizpůsobeny regionálním specifikům, například práci s českým kódováním. Speciální aplikace V prvopočátcích publikování informací na internetu byl nejobvyklejší postup publikování takový, že stránka vytvořená v nějakém HTML editoru byla pomocí FTP přístupu odeslána na Gopher nebo WWW server. To sice bylo jednoduché a rychlé, 7

11 ovšem pro správu rozsáhlejších informačních serverů byl tento způsob naprosto nevyhovující, protože nutil uživatele k mnoha rutinním a ubíjejícím činnostem. Například přidání nového článku na server znamenalo mimo nahrání článku na server také editaci a odeslání na server nové verze titulní stránky odkazující na článek a také stránky s archivem článků. To ovšem přidávalo množství práce, které se samotnou tvorbou informací nemělo mnoho společného a uživatele zbytečně zdržovalo. APLIKACE KLIENT- SERVER To byl důvod vzniku prvních speciálních aplikací, prvních skutečných redakčních systémů. Z počátku se zdálo, že bude efektivnější a jednodušší, aby takový redakční systém fungoval převážně na klientské straně, tedy aby na počítači redaktora byl instalován software, pomocí něhož se vytvářely články a struktura serveru a poté aby takto vytvořená data byla odeslána na server a tím publikována. Záhy se ale ukázalo, že takto nemohou být vytvořeny komplexní systémy sloužící pro rozsáhlejší a už vůbec ne pro týmovou práci. Bylo třeba přistoupit k aplikacím typu klient-server, kdy veškerá data jsou ihned ukládána na centrální server a tam k nim mají přístup všichni uživatelé v rámci svých uživatelských práv. V současné době jsou aplikace typu klient-server převažujícími nástroji pro vytváření a správu informací na internetu a je třeba říci, že jsou pro rozsáhlejší projekty vhodnější, než výhradně klientské aplikace. Klientské aplikace jsou na druhou stranu podstatně levnější pro implementaci, vyžadují ale vyšší udržovací a provozní náklady spojené s rutinní prací. Pro amatérské, menší či nadšenecké projekty samozřejmě mají klientské aplikace stále velký smysl zejména vzhledem k ceně, protože takovýto způsob práce s informacemi dnes podporuje většina kvalitnějších HTML editorů, jako je MS-Frontpage nebo Macromedia Dreamweaver. My se ale budeme zaobírat aplikacemi určenými pro rozsáhlejší projekty, tedy redakčními systémy typu klient-server. Vybíráme redakční systém cena a výkon Výběr vhodného redakčního systému není vůbec jednoduchý proces. Zejména pokud jde o větší projekt nebo o větší firmu, kde má být redakční systém nasazen, představuje výběr redakčního systému proces, jemuž by měla být věnována značná péče a pozornost. Ve výsledku totiž bude redakční systém rozhodovat o tom, jaké budou náklady na provoz internetového projektu, jak rychlá a kvalitní bude jeho realizace a jak dobře se bude systém všem uživatelům používat. Nevhodný redakční systém může zhatit značné množství investic a většinou nebývá jiná cesta, než za vysokých nákladů migrovat na jiný systém. CENA VERSUS VÝKON Nejrozšířenější a zřejmě také nejpraktičtější metodou pro výběr redakčního systému je porovnání cenové a výkonnostní složky. Tato metoda je bohužel ale velmi často 8

12 aplikována pouze tak, že se porovnávají okamžité pořizovací náklady a posuzuje se, zda aplikace poskytuje funkce potřebné ve stávající fázi projektu. Nic není horším omylem, než takto zjednodušené porovnání. Je třeba si uvědomit, že cena redakčního systému zapsaná v ceníku je zhruba desetinou, někdy ale i dvacetinou finanční částky, kterou bude třeba do projektu nasazení redakčního systému investovat. Celková částka se skládá například i z ceny hardware, na kterém bude nutno redakční systém provozovat a kvalitněji naprogramované redakční systémy zde nabídnou podstatnou úsporu při investicích do serverů, zatímco méně kvalitní systémy budou požadovat zvýšené hardwarové nároky. Stejně tak u výkonnostní složky je třeba uvažovat podstatně dále, než jen k okamžitým potřebám projektu. Je nutno si uvědomit, že tyto potřeby se budou dále vyvíjet a že je velmi nepravděpodobné, že po delší dobu ustrnou na původně stanovených pozicích. Naopak ze zkušeností lze vyvozovat, že v případě implementace funkčně bohatých redakčních systémů se do projektu začnou rychle přebírat funkce a myšlenky, které redakční systém nabízí a podporuje, už proto, že taková funkční bohatost je příjemná uživatelům. V následujících kapitolách si řekneme něco o tom, jaké aspekty jsou důležité pro porovnávání cenových a výkonnostních parametrů. A nakonec se také zastavíme u poměrně populární otázky, zda si nenechat vyvinout redakční systém na zakázku, nebo zda si nevytvořit svůj vlastní redakční systém. Cena náklady spojené s redakčním systémem Nasazování redakčního systému lze rozdělit do několika hlavních fází, přičemž každá svoje fáze v sobě již nese nějaké finanční náklady. Provedení těchto kroků pomůže s výběrem kvalitního redakčního software vhodného pro projekt s tím, že budou respektovány a zohledněny všechny firemní zvláštnosti. U každého kroku vyčíslíme, jak se tento krok projevuje na celkové ceně implementace redakčního software. 1) specifikace cílů a požadavků 2) výběrové řízení 3) Implementace a odladění 4) Dokumentace a zaškolení 5) Testování 6) Provoz a údržba 7) Stažení z provozu 9

13 SPECIFIKACE CÍLŮ A POŽADAVKŮ V tomto kroku se posuzují cíle, jichž chce firma dosáhnout. Specifikují se potřeby a problémy, jsou přesně definovány požadavky a termíny včetně přidělení zdrojů, tedy stanovení toho, kdo bude jednotlivé problémy řešit a s jakým vybavením. K takto vytvořené specifikaci je vhodné provést oponenturu v jednotlivých odděleních firmy, u nichž se očekává, že mají přijít s nasazeným redakčním systémem do styku, ať již tak, že jej budou používat, nebo tak, že informace jím publikované ovlivní práci oddělení. Náklady: analýza potřeba a jejich specifikace vyžaduje práci člověka znalého v chodu firmy a jeho spolupráci se zainteresovanými odděleními. Nákladem je v tomto případě ztráta pracovního času těchto lidí. Rizika: tato etapa je často podceňována, výsledkem čehož může být volba částečně nebo zcela nevhodného řešení. Důležité je napsat specifikaci takovým jazykem, aby nevznikala rozepře o faktickém významu napsaného. Rovněž oponenturu je třeba řádně provést a její výsledky zanést do specifikace. VÝBĚROVÉ ŘÍZENÍ Výběrové řízení předpokládá provedení průzkumu trhu a vytipování dodavatelů redakčních systémů, kteří přicházejí v úvahu pro dodávku. Již při vytipování je možné provádět prvotní selekci a vyřadit firmy, jejichž produkty evidentně nenabízejí dostatek funkcí, možností, nebo firmy, které na první pohled nebudí důvěru. Na druhou stranu toto není potřeba a je možné firmy oslovit zasláním poptávky. Součástí poptávky by měla samozřejmě být výše vypracovaná Specifikace cílů a požadavků, ale také dotazník týkající se dodavatelské firmy a obsahující otázky směřující na důvěryhodnost dodavatele a schopnost dostát smluvním závazkům. Je tedy vhodné seznámit se s referencemi dodavatele, ale také s jeho zázemím, protože především u nových internetových společností hrozí riziko toho, že ze dne na den zaniknou a vy náhle používáte redakční software, ke kterému neexistuje žádná podpora. Může být také vhodné předem uzavřít smlouvu zavazující oslovené firmy uchovat vaši poptávku v tajnosti. Ošetří se tak předem případné problémy s tím, že se vaše poptávka obsahující poměrně důvěrné a citlivé informace dostane do nepravých rukou. Specifikace cílů a požadavků by měla obsahovat alespoň: Termíny implementace 10

14 Požadavky na workflow tedy kdo a jak schvaluje publikované informace Požadavky na design uživatelské části a administrace Požadavky pro napojení na specifické zdroje dat (vnitrofiremní informační systémy atd) VÝSLEDEK VÝBĚROVÉHO Ř ÍZENÍ Výsledkem výběrového řízení by měla být jasná a precizně formulovaná odpověď nabízejících firem, v níž budou uvedeny jasné odpovědi na to, zda a případně s jakými výhradami jsou tyto společnosti schopny řešit požadavky vašeho projektu. Vhodné tedy je připravit přímo dotazník, v němž budou kladeny jasné otázky vyžadující jasné odpovědi. Tento dotazník bude obsahovat klíčové požadavky pro vaše rozhodnutí, například Schopnost publikovat data ve WAPu, Obsahuje systém fulltextové prohledávání ale i technické otázky typu Podporuje systém clusterování, nebo jiné rozložení zátěže, případně jak se vyrovnává s vzrůstem zátěže? Je nutno pamatovat na fakt, že kladné zodpovězení otázky, zda redakční systém obsahuje fulltextové vyhledávání neznamená vždy rovnocennou implementaci a tak je vhodné u důležitých otázek podrobněji přezkoumat, do jaké míry systém tuto funkci podporuje, jak pohodlně je možné ji používat a zda způsob práce s ní koresponduje s představou vašeho projektu. Samozřejmou součástí odpovědi by měla být i cena. Pro snazší porovnání cenové nabídky je opět vhodnější předem připravit položky dotazníku týkající se ceny. Zde velmi záleží na kvalitě specifikace požadavků, protože podle toho, nakolik je přesná a kvalitní, je pro nabízející firmy možné specifikovat cenu implementace redakčního systému. Za důležité otázky týkající se ceny by měly být považovány minimálně tyto: Cena redakčního systému včetně instalace Cena za upgrade na nové verze a očekávaná rychlost tvorby upgrade Cena za měsíční podporu v případě administrace systému dodavatelem Cena za řešení nestandardních situací v případě, že není požadována administrace dodavatelem Sazba za školení uživatelů a za školení administrátorů systému 11

15 Sazba za programování speciálních aplikací. Dlužno jest nyní zdůraznit, že pro vyhodnocování by v této fázi výběru neměla být uvedená cena příliš směrodatná, už proto, že ve většině případů nebude specifikace natolik podrobná, aby podle ní firmy mohly stanovit přesnou cenu. Navíc již bylo řečeno, že například cena redakčního systému představuje zhruba desetinu ceny celé implementace, takže porovnávat jen podle ní není příliš smysluplné. TECHNICKÉ ÚDAJE Důležité jsou také otázky technického charakteru. Je třeba bedlivě zvážit především náklady na zajištění potřebného výkonu systému. Některé redakční systémy není možno instalovat na více serverů najednou a v takovém případě je problematické zvyšování výkonu. Stejně tak některé systémy vyžadují rychlejší servery, než jiné a zde je nepříjemné, že výkon redakčních systémů v podstatě nelze korektně porovnat. A do třetice, je třeba uvážit, jaký podpůrný software potřebují redakční systémy, protože tento software je třeba také zvláště platit. O tom všem bude podrobněji řečeno v části věnované výkonu. Vyhodnocení podkladů, jež firmy zašlou, by mělo být provedeno bez zbytečného odkladu a především na základě splnění podmínek v dotazníku. Je třeba vyřadit firmy, které nesplnily základní podmínky specifikace, nebo vykazují nejistotu ohledně možností splnění těchto podmínek. Také je vhodné porovnat seznam referencí a zaměřit se na dodavatele, v jejichž referencích jsou projekty podobné tomu vašemu. V takovém případě se dá očekávat dostatek zkušeností s realizací podobného projektu a obejití nutných dětských nemocí. CENA JE ORIENTAČNÍ VODÍTKO! Cena by v této fázi rozhodování měla být spíše orientačním vodítkem a vyřazování by v této fázi mělo fungovat spíše tak, že jsou vyřazeny i dle vašeho odhadu příliš levné nabídky zejména v případech, kdy nabízející firma nemá dostatek zkušeností a referencí a budí dojem amatérské firmičky, one-man show. U firem, jejichž nabídky splňují zadané parametry, je vhodné požádat o osobní demonstraci produktu, na níž by měli být přítomni lidé, kteří budou s redakčním systémem pracovat. V této fázi totiž opouštíme výhradně faktograficky orientovanou část výběrového řízení a přesouváme se do fáze pocitové, kdy je třeba zhodnotit, zda filosofie práce systému a snadnost jeho používání je vhodná pro nasazení ve vaší společnosti. V tomto případě jde již většinou o subjektivní záležitosti. Je třeba se je nicméně objektivně pokusit posoudit a rozdělit na podstatné a nepodstatné a následně znovu vytřídit dodavatele podle toho, jak jsou jejich produkty vhodné pro nasazení ve vaší firmě. 12

16 SEZNÁMENÍ S PRODUKTY Na osobním setkání je také nutno detailně probrat představy o realizaci jednotlivých částí vašeho projektu a zaměřit se na silné a slabé stránky nabízených redakčních systémů. O tom, kde taková úskalí můžete najít, se podrobněji zmíníme v části věnované výkonnosti redakčních systémů. Po takovémto setkání by dodavatelské firmy měly dodat přesnou cenovou nabídku, která vznikne jako reakce na vámi písemně dodané zadání a ústní upřesnění sporných či nejasná a podrobněji nerozvedených bodů. Výběr nyní může přikročit k porovnání splnění nabízených podmínek a ceny, je už jen na vybírajících, zda se přikloní k řešení slibujícímu splnit všechny podmínky, nebo zda zvolí řešení levnější a s kompromisy. Výsledkem výběrového řízení by měl být podepsaný kontrakt, smlouva s dodavatelskou firmou na dodávku redakčního systému. Smlouva by měla obsahovat jak přesné stanovení termínů, tak sankce za jejich nedodržení, je ale třeba také dbát na to, aby byly včas dodavateli dodány všechny podklady. Náklady: I v této fázi jde zejména o náklady na čas lidí, kteří se výběrovému řízení věnují. Rizika: pokud jsou připraveny kvalitní specifikace a je výběrové řízení provedeno pečlivě a rovněž smluvní stránka věci je dobře ošetřena, bude výsledkem nákup vyhovujícího systému. Podcenění této fáze rovněž může vést k nákupu systému, do něhož bude třeba investovat nad rámec předpokladů. IMPLEMENTACE A ODLADĚNÍ Implementace systému představuje první dražší etapu nasazování vybraného redakčního systému. V rámci implementace je potřeba propojit firemní informační systémy s redakčním software, tedy vytvořit interface mezi firemními systémy, případně intranetem a internetem. Moderní redakční systémy takové propojení podporují a dodavatelská firma je schopna vám jej vytvořit. Je třeba počítat s tím, že bude nutno jej většinou zaplatit zvláště. Takové interface jsou schopné potom automaticky přejímat data z firemních systému, například z účetnictví a vhodným způsobem je publikovat na webu. Je důležité přitom mít na paměti zásady bezpečnosti, tedy že redakční systém nemůže modifikovat přímo data ve firemních systémech. Implementace také logicky zahrnuje instalaci serverů a spuštění redakčního software, případně instalaci klientského software na stanice jednotlivých klientů. Pokud je součástí dodávky také implementace zakázkově dodávaných součástí redakčního systému, zakázkových modulů nebo aplikací, je nutné provést jejich odladění a odstranění chyb. Podkladem je zde analýza, případně zadání a zde se také pozná kvalitní analýza a zadání, protože zde bude dodavatelská firma velmi vážně 13

17 rozlišovat mezi odstraněním chyb a mezi rozšířením zadání. Podkladem pro toto rozlišení je pak právě analýza zadání práce vše, co v této analýze není uvedeno, bude dodavatelská firma fakturovat jako vícepráce a bude plně v právu. TESTOVACÍ PROVOZ Poté, co je redakční systém plně funkční tak, jak bylo objednáno, může následovat samotné zprovoznění projektu do testovacího a později ostrého provozu. Zde hodně záleží na tom, jak byl projekt realizován. Moderní redakční systémy, jako i nejrozšířenější český systém Genesis 2 mají vlastní programovací jazyky, pomoci nichž si mohou sami uživatelé redakčního systému vytvářet vlastní aplikace nebo vzhled stránek. Proto je třeba rozlišit, zda tyto stránky nebo aplikace vytváří dodavatel, nebo zda si je zákazník vytváří sám. V každém případě se zprovozněním projektu myslí jeho finální zprovoznění tak, jak má být na webu k vidění, tedy naplnění redakčního systému relevantními daty, vytvoření designu stránek a případně dotvoření aplikací, které neměl vytvářet dodavatel. Náklady: naprogramování vstupně výstupních filtrů a migrace dat z firemních systémů do redakčního systému Instalace a odladění serverů Instalace a odladění zakázkových modulů Zprovoznění projektu (vytvoření grafického vzhledu, naplnění daty, vytvoření vlastních aplikací) Rizika: samotná implementace je pro koncové uživatele nejviditelnější částí celé práce a na její kvalitní realizaci závisí první dojem a v praxi tedy i úspěch celého projektu. DOKUMENTACE A ZAŠKOLENÍ Poté, co je celý projekt implementován podle zadání, je třeba provést zaškolení uživatelů i administrátorů systému. To zpravidla provádí dodavatelská firma a právě školení je částí, kde může utéci velké množství peněz. Při nákupu některých systémů je školení i dodání dokumentace v určitém množství již v ceně, zatímco jinde je účtováno zvláště a může stát mnoho peněz. Školení je zpravidla dvojího druhu, tedy školení pro uživatele systému, kteří budou do redakčního systému vkládat data a pak školení administrátorů systému, kteří jej budou spravovat a vytvářet v něm nové aplikace nebo udržovat aplikace již vytvořené. Je ovšem možné od dodavatelské firmy nechat proškolit pouze několik pracovníků a ty 14

18 posléze určit k proškolení dalších pracovníků, nicméně tato metoda není vhodná z počátku projektu. Je třeba si uvědomit, že ke školení je třeba mít dlouhodobé zkušenosti s produktem a těch se nově proškoleným pracovníkům nebude dostávat a na mnoho otázek budou obtížně hledat odpovědi. Dokumentace dodaná dodavatelskou firmou by měla představovat kompletní návod k práci a používání s redakčním software, především pak v oblasti administrace systému. Zatímco například vkládání článků do systému bývá většinou velmi intuitivní a není třeba bazírovat na tom, aby bylo podrobně zdokumentováno, vlastní administrace systému a tvorba aplikací je naopak o to náročnější a podrobná dokumentace v takovém případě je více než nutná. Náklady: školení administátorů Školení pracovníků Tvorba a dodání dokumentace Rizika: pokud se budete muset obejít bez dokumentace, nebo dokumentace bude nekvalitní, počítejte se zvýšenými náklady za školení případně za pozdější konzultace s dodavatelskou firmou. Naopak kvalitní dokumentace vám takové výdaje ušetří. Pokud podceníte školení, nenaučíte se zase využívat všech schopností dodaného systému a je pravděpodobné, že některé vlastnosti nebudete využívat vůbec a jiné neefektivně. TESTOVÁNÍ Testováním systému se rozumí již vlastně ostrý běh všech částí s tím, že přístup k serveru je omezen pro uzavřenou uživatelskou skupinu, která hlásí všechny problémy a nefunkčnosti. Ty jsou následně odstraňovány. Dále je nutno zkontrolovat, zda dodaná dokumentace a souhlasí se stavem systému. P Ř EDÁVACÍ PROTOKOL Po dokončení těchto testovacích prací bude dodavatelská firma chtít podepsat předávací protokol, jenž stvrdí skutečnost, že práci odvedla řádně a včas a tedy má právo podle smlouvy fakturovat provedené práce. Náklady: čas lidí pověřených testováním Rizika: pokud nebude testování provedeno pečlivě, je možné, že budou opomenuty problémy a chyby, které později dodavatelská firma nebude chtít odstranit v rámci záruky. Navíc existuje možnost ostudy po ukončení testování přechází systém do ostrého provozu a pokud v něm selže, nebude to mít příznivý dopad na pověst projektu. 15

19 PROVOZ A ÚDRŽBA Tato fáze je nejdelší a také finančně nejnákladnější, ačkoliv bývá při zpracování projektů velmi podceňována a při výběru redakčního systému podle ceny se trestuhodně často opomíjí její zhodnocení. V této fázi probíhá odstraňování chyb zjištěných již za běhu systému a zde velmi záleží na smlouvě, jak se přistupuje k nákladům vzniklým při odstraňování těchto chyb. Dále je třeba redakční systém upravovat i ve výkonnostních parametrech, tedy zpravidla upgradem hardware a je tedy třeba zajistit jeho běh na upravené hardwarové konfiguraci. I tato část bývá podceňována. Je třeba si uvědomit, že při stanovování cílů projektu je právě návštěvnost projektu velmi obtížně odhadnutelná. Ve skutečnosti může být jak řádově vyšší, tak řádově nižší a úkolem dodaného redakčního systému je, aby byl schopen jak pružně, tak s přijatelnými náklady reagovat na vzrůst návštěvnosti. Nejmodernější redakční systémy, jako Genesis 2, podporují provoz na více počítačích, takže v případě nárůstu návštěvnosti stačí dokoupit další server. O tom bude ale blíže pojednáno v části věnované výkonu redakčního systému. ADMINISTRACE SERVERU Je také třeba dořešit otázku administrace serveru jako takového. Pokud nedisponujete kvalitními odborníky na provoz serverů, je vhodnější si administraci serveru zaplatit u dodavatelské firmy, která s tím bude mít nepochybně zkušenosti a bude schopna nabídnout i dozor nad jeho zabezpečením. Za to bude třeba platit měsíční poplatek, zpravidla ale je takový poplatek přijatelnější, než placení vlastního odborníka. Vaši zaměstnanci by v tomto případě pouze administrovali redakční systém a nikoliv samotný server. Je třeba si uvědomit, že ne každý odborník na počítače musí nutně rozumět serverům a ačkoliv váš správce sítě si umí poradit s nastavením bubnového scanneru, detailní administrace Linuxového nebo NT serveru bude pravděpodobně nad jeho síly. Pokud chcete předejít rizikům jako průnik hackera nebo ztráta dat, je lepší obrátit se na odborníky. UPGRADE V rámci běžného provozu je také třeba dořešit s dodavatelskou firmou upgrade redakčního software. Počítejte totiž s tím, že redakční software se stejně jako jakýkoliv jiný software vyvíjí a dodavatelská firma připravuje nové a nové verze. Pokud to nedělá, je to velká chyba a mínus pro její volbu. Měli byste tedy mít hned z kraje jasno, jakým způsobem můžete na vyšší verzi přejít a především, kolik vás tento přechod bude stát. Pokud nebudete mít nárok na upgrade, snadno se váš projekt dostane do problémů proto, že za každé rozšíření systému budete muset platit. Přitom mnoho z těchto rozšíření a praktických úprav dodavatelská firma vytvoří v rámci update. Například redakční software Genesis 2 ve své licenční politice zahrnuje upgrade na nové verze zdarma v případě, že máte od dodavatele zakoupenou administraci serveru. 16

20 Bez administrace serveru si musíte instalaci každého jednotlivého upgrade zaplatit zvláště, samotný upgrade je ale zdarma. Náklady: Lidé a technika určení pro administraci redakčního systému Lidé a technika určení pro práci s redakčním systémem Lidé a technika určení pro správu serveru Technika určená pro provoz serveru Náklady na zvýšení výkonu serveru Poplatky za upgrade Poplatky za vývoj dalších modulů a dalších rozšiřujících aplikací Náklady na zaškolení pracovníků pracujících s upgradovanými funkcemi a novými moduly Rizika: Především hrozí riziko podcenění výše uvedených nákladů. Pamatujte na to, že jakákoliv ruční práce, kterou by mohl nahradit dobře naprogramovaný program, představuje zbytečný náklad a vynásobte si plat člověka provádějícího tuto práci předpokládanou dobou provádění takové ruční práce. Další rizika jsou již provozního charakteru samozřejmě můžete podcenit počet lidí nutných pro obsluhu redakčního systému a pro jeho administraci, čímž projekt nebude postupovat kupředu dostatečně rychle a náklady na něj vzrostou. Vyplatí se tuto část již konzultovat s dodavatelem redakčního systému, který bude mít dostatek zkušeností s nároky, jaké jeho systém klade. Dalším rizikem je podcenění návštěvnosti, nebo naopak její přecenění. Při přecenění budete mít zbytečně vysoké náklady na provoz systému díky nákupu zbytečně výkonného hardware (jehož cena stále klesá). Při podcenění návštěvnosti bude problém s tím, že musíte provést upgrade serverů, tedy dále investovat a navíc vaše servery na jistou dobu odstavit. Redakční systém by se měl umět s nárůstem návštěvnosti umět vyrovnat nejlépe metodou clusteringu, tedy spojení více serverů dohromady pro zajištění vyššího výkonu. 17