Aktuality

Krásné Vánoce a šťastný nový rok

22. 12. 2023

ZZS Olomouc

1. 6. 2021

V prvním kvartále roku 2021 byl spuštěn ostrý provoz našeho dispečerského systému operačního řízení pro zdravotnickou záchrannou službu v Olomouckém kraji.

V rámci zakázky „Informační systém ZOS, modernizace, servis a podpora nahrávacího zařízení, ovládání radiostanic a osvětlení heliportu“ v hodnotě cca 25 mil. proběhla dodávka hardware a software pro operační středisko za účelem obnovy technologií a modernizace software.

Provoz byl spuštěn jako víceuzlový, a to jak na úrovni databáze, tak na úrovni aplikací.

Aktuálně tedy společnost RCS Kladno provozuje informační systémy tří zdravotnických operačních středisek – ZZS Středočeského kraje, ZZS Jihočeského kraje a nově ZZS Olomouckého kraje.

Univerzální bezpečnostní platforma pro budovy, infrastrukturu a průmysl

1. 7. 2020

Zapojili jsme se do projektu Univerzální bezpečnostní platformy pro budovy, infrastrukturu a průmysl. Výstupem projektu bude nový software v podobě softwarové platformy. Architektura nové platformy bude poskytovat možnost volby a flexibilitu změny výsledných funkcionalit. To umožní zákazníkovi podrobnou volbu požadované sady funkcionalit včetně např. napojení na systémy operačního řízení HZS ČR, čímž bude platforma přizpůsobena na míru daným podmínkám užití.

Příklady možného rozsahu implementace mohou být následující:

• integrace vstupů (např. PER, EPS, PZTS, CCTV, hladinoměry nebo srážkoměry)
• integrace výstupů (např. varovné, výstražné a informační systémy nebo dohledová pracoviště)
• standardizované připojení do SIEM systému prostřednictvím Cyber Security API
• integrace se systémy operačního řízení HZS ČR

Výzkum a vývoj v uvedených oblastech je nezbytný pro naplnění hlavního cíle projektu, kterým je software v podobě nové univerzální a modulární, bezpečnostní, softwarové platformy umožňující integraci nejrůznějších bezpečnostních technologií, propojení se systémy operačního řízení HZS ČR a implementaci standardů kybernetické bezpečnosti včetně propojení se SIEM.

Naše společnost svým know-how přispěje k volbě optimální architektury platformy a konkrétních funkcionalit systému. V projektu bude RCS Kladno, s.r.o. realizovat mimo jiné tyto činnosti:

• vyhodnocení požadavků na výměnu informací s HZS
• vymezení zadání pro výměnu informací s HZS
• vyhodnocení stavu systému operačního řízení HZS
• testovací scénáře pro bezpečnostní platformu
• rešerše moderních technologií a postupů
• nastudování kandidátních technologií a postupů
• vývoj ověřovacích prototypů, unit testy a revize kódu
• revize zadání projektu
• definice bezpečnostní platformy
• vlastní softwarový vývoj v rozsahu dle vývojových úkolů
• testování a opravy chyb na základě testovacích scénářů pro funkční požadavky
• příprava, nasazení, podpora a vyhodnocení při ověření systémů v pilotním provozu
• technická příprava prezentace výstupu

Schola ludus aneb jak pracuje a vyvíjí se aplikační server

8. 10. 2019

Zaregistrovali jsme nejen v poslední době stesky uživatelů informačního systému operačního řízení nad tím, že „nám nefunguje systém, protože jim nepřijde navigace do auta„. Tyto stesky jsou v případě zařízení jednoho z poskytovatelů navigací namístě – v řadě případů příkazy k jízdě do vozidel opravdu nepřijdou.

Ale co je tím skutečným důvodem, proč „s tím nemůžeme něco udělat“ a jak to vlastně celé funguje, to už je složitější vysvětlení.

Jádrem celého systému je kromě databáze také aplikační server. Aplikační server si můžeme představit jako úřad se spoustou úředníků. Tito úředníci jsou sdružování do odborů, které realizují obsluhu činností podobného typu.

Nejznámější odbor je zodpovědný za styk s veřejností. Na každé směně je v něm připraveno na 200 úředníků, kteří čekají na požadavky, které jim pokládají uživatelské aplikace – Spojaři, IKISové a jim podobní. Aby byla veřejnost spokojena, tak se každý úředník snaží požadavek vyřídit co nejrychleji. Proto sám zařídí jen to, co má být vráceno v odpovědi na požadavek. Všechnu ostatní práci s požadavkem spojenou přenechává druhému velkému odboru – odboru pro zpracování vnitřních událostí. Tam pracuje téměř 100 dalších úředníků.

Takto to vypadalo na začátku

Předvedeme si to na příkladu – obsluha Spojaře posílá techniku k zásahu. Úředník z odboru pro styk s veřejností požadavek přijme a zkontroluje, zda je možné tuto techniku k události odeslat. Pokud ano, tak změní její stav na „Výjezd“, vytvoří o tom vnitřní událost (zprávu pro příslušný odbor) a vrátí zpět Spojaři, že se to podařilo. Tím je zaručena rychlá odezva.

Na odboru pro zpracování vnitřních událostí tuto událost převezmou a nejprve zjistí, kolik činností je třeba pro dokončení operace provést. Každou z nich pak přidělí k vyřízení jinému úředníku – všichni pak pracují současně na co nejrychlejším dokončení zpracování. První z nich třeba najde všechny automatické akce, které se mají spustit (pro výjezd právě této techniky, v tomto čase, v kontextu tohoto typu události …) a požádá o jejich provedení odbor automatických akcí. Druhý aktualizuje počet volných řidičů na stanici. Další zjistí, zda je k této technice přiřazen spojový prostředek typu navigace a pokud ano, tak předá na navigační server, který se o toto zařízení stará, příkaz k výjezdu.

A tak dále, a tak dále, a tak dále …

Úprava první

Po nějaké době provozu se ale ukázalo, že při větším počtu současných výjezdů (živelné pohromy, zátěžové testy, …) server nepracuje tak, jak by měl. Analýzou jsme zjistili, že dochází k zablokování odboru pro zpracování vnitřních událostí – všichni úředníci již vykonávali nějakou činnost a pro obsluhu nově příchozích událostí zde již nebyli žádní volní. Zkoumali jsme tedy, co všichni dělají a ke svému údivu jsme zjistili, že předávají zprávy navigačním serverům.

Dalším měřením jsme zjistili, že některým navigačním serverům trvá převzetí takovéto zprávy (příkaz k výjezdu, změny stavu událostí, polohy vozidel ostatních složek, …) i jednotky sekund (v běžném stavu se jedná nejvýše o stovky milisekund). Pokud bylo v krátkém časovém úseku třeba předat zpráv více, tak všichni úředníci čekali na to, až navigační server jejich zprávu převezme a nemohli tedy začít zpracovávat další čekající události.

Jako řešení jsme vytvořili nový odbor pro komunikaci s navigačními servery a k němu frontu zpráv, které je na ně třeba předat.
Úředníci z odboru vnitřních událostí tak sami zprávy nepředávají, ale jen je zařadí do fronty k odeslání. To je samozřejmě provedeno výrazně rychleji (v řádu milisekund). Tím jsme zachránili tento odbor (který tvoří jádro celého serveru) a problém jsme odsunuli na odbor nově vzniklý.

Při dalším zátěžovém testu se prověřilo, že řešení bylo úspěšné – k zablokování aplikačního serveru již nedocházelo. Objevil se ale nový problém – výrazně se zhoršilo doručování zpráv na navigační servery. V novém odboru byl totiž jen jeden úředník – nechtělo se nám plýtvat silami na tak jednoduchou činnost jakou je předávání zpráv.

Dále byl ve frontě požadavků zaveden čistící mechanizmus – pokud v ní zpráva čeká již déle než 29 sekund, tak je odstraněna jako již neaktuální. Bez tohoto mechanizmu by docházelo k zahlcení fronty již neaktuálními zprávami, zatímco nové by obsluhovány nebyly.

Úprava druhá

Protože úředník na novém odboru byl jeden pro všechny servery, byly pomalou odezvou jednoho ze serverů postiženy i servery ostatní, byť jejich odezva byla v pořádku, ale zprávy pro ně čekaly ve frontě, než se odbaví dříve vzniklé zprávy pro pomaleji pracující navigační server. Jako další krok jsme tedy ten nový odbor rozdělili na tolik nových, kolik bylo navigačních serverů. Každá konkrétní instance navigačního serveru měla svůj vlastní.

Výsledkem bylo, že ti „nevinní“ již netrpěli za ty druhé a mohli normálně pracovat. Tak se nám podařilo původní problém lokalizovat – jeden „líný“ navigační server už nedokázal zablokovat celý aplikační server ani škodit druhým. Všechny následky svého konání nesl pouze on sám.

Ani to ale nebyl samozřejmě stav, kterého bychom chtěli dosáhnout. Tím je bezproblémová spolupráce se všemi spolupracujícími servery. Pokusili jsme se tedy domluvit s výrobcem toho problémového – tato snaha byla ale bohužel pouze jednostranná. Museli jsme tedy i nadále postupovat jednostranně. Cesta prodloužení „čistící“ doby na více než 29 sekund se nám nelíbila – celý mechanizmus čištění by přestal být funkční. Zvolili jsme tedy jedinou zbývající cestu – posílili jsme odbor pro komunikaci s tímto serverem o nové úředníky.

Úprava třetí

V současné době tedy na odboru předávání zpráv pro navigační server jednoho konkrétního výrobce pracuje v potu tváře 10 úředníků. Snad to bude stačit. V bratrských odborech na stejnou práci stačí jeden úředník … který většinu času tráví ve stavu čekání na další činnost. A pak že existuje nějaká spravedlnost … ještě že si ti úředníci nemohou stěžovat – fragmenty programového kódu zatím ještě odborové hnutí nezasáhlo.

Hledáme nové kolegy

3. 9. 2019

Máte-li delší dobu neodbytný pocit, že by Vaše pracovní úsilí potřebovalo získat nějaký další osobní smysl, zkuste přestup k nám 🙂

Programujeme, vyvíjíme, testujeme, podobně jako vy. Námi vytvořené aplikace pomáhají zachraňovat životy a zdraví.

Aktuálně hledáme nové kolegy zejména na pozice:

• Vývojář mobilních aplikací
• Tester aplikací
• Pracovník dohledového centra

Více informací o možnosti stát se členem našeho týmu naleznete v sekci Kariéra.

Nová verze PORT.ALL uvolněna

8. 7. 2019

Děti i učitelé se dočkali, konec školního roku nastal a rozdávalo se vysvědčení. My jsme s vysvědčením na konec školního roku nečekali a nechali uživatele hodnotit PORT.ALL pomocí zpětných vazeb po celý rok. Výsledkem byl seznam nejčastějších přání na zlepšení aplikace. Následovala dohoda s GŘ HZS ČR na rozvoji a zapracování některých zlepšení aplikace a výsledkem je nová verze PORT.ALL, která byla v minulých dnech nasazena do ostrého provozu.

Na co se uživatelé mohou těšit?

V prvé řadě byl celý portál převeden na 64-bitovou architekturu, aby aplikace mohla lépe využít dostupné zdroje a pracovala rychleji a spolehlivěji. Občasná hlášení o nedostatku paměti by tak měla být minulostí.

Z pohledu uživatelů je pak velkým zlepšením rozdělení ZOZ na část společnou a část výhradně pro jednotku SDH. Nově tak můžete za vaši jednotku editovat ZOZ k události, na které spolupracovalo více jednotek, aniž byste si událost navzájem zamykali a museli jste čekat, až jiná JSDH svou zprávu dopíše a událost vám uvolní.

Při vyplňování ZOZ vám napomůže i integrace vyhledávání majitele/uživatele podle IČO nebo názvu z Rejstříku ekonomických subjektů.

Častým přáním byl rovněž násobný výběr činností, který je od nové verze také zprovozněn, stejně jako násobný výběr členů jednotky pro evidenci Odborných příprav.

Důležitou změnou je rozlišení mezi ZOZ a ZOČ, jak při vyplňování, tak v různých přehledech, které lze zobrazit pro ZOZ, ZOČ nebo oboje. ZOČ jsou rozlišeny i barevně v přehledu událostí.

Upraveny byly i funkce pro zobrazení poplachu a tisk mapy, které se v produkčním prostředí nechovaly zcela korektně.

Novou funkcí PORT.ALL je odesílání vzkazů e-mailem. Při zadávání vzkazu můžete zaškrtnout, zda se má poslat i e-mailem a pokud ano, tak komu – buď všem členům s vyplněnou e-mailovou adresou (bez ohledu na to, jestli je tato osoba i uživatelem PORT.ALL), nebo všem portálovým uživatelům.

Drobných změn bylo mnohem více – doplnění textové poznámky u činnosti, přebírání časů techniky z časů události a naopak a další. S celým výčtem rozdílů se setkáte v přehledu Změny ve verzích, dostupném přímo z aplikace PORT.ALL.

Další vývoj aplikace

Mezi častá přání patří změna designu aplikace a její přepracování do podoby moderní, responsivní aplikace. Ano, je pravda, že aplikace spatřila světlo světa ve zkušebním provozu už v lednu roku 2012 a dnes může působit zastaralým dojmem. Kdo si už tehdy představoval, že by rád vyplňoval ZOZ na mobilním telefonu přímo z místa zásahu? Komplexnější přepracování aplikace na pořadu dne zatím není.

Avšak i zde situace pomalu dozrává k tomu, že se tato možnost začíná uvažovat a diskutuje se nad možným rozsahem a termíny takové rozsáhlejší úpravy. „Chceš-li Boha rozesmát, sděl mu své plány“, říká Woody Allen. No, nebudeme zatím nikoho rozesmávat.

Krásné prázdniny všem a uživatelům PORT.ALL zvláště.

… a věřte, že vaše dopisy (ani zpětné vazby) v koši nekončí.

Jednotný informační systém prevence

20. 5. 2019

Již po léta dodáváme Hasičskému záchrannému sboru ČR ucelený Informační systém operačního řízení. HZS však plní kromě řešení mimořádných událostí i další významnou roli – a to je role preventivní, kdy se na základě různých kontrol protipožárních opatření snaží vzniku mimořádných událostí předcházet. Jde o činnost administrativní spojenou s činností v terénu a kontrolou provozoven, výrobních hal nebo nově vznikajících objektů. Každý HZS kraje používal dosud pro tuto činnost svou sadu nástrojů, která se ve větší či menší míře snažila naplnit reálné potřeby pracovníků státního požárního dozoru.

GŘ HZS ČR se rozhodlo sjednotit toto programové vybavení a po mnoha měsících vypsalo otevřené výběrové řízení na dodavatele nového systému „Jednotný informační systém prevence“, zkráceně JISP. Jde o kompilát potřeb pracovníků státního požárního dozoru (SPD) napříč jednotlivými kraji s těsnou integrací na modul spisové služby GINIS. Naše firma po pečlivé analýze požadavků podala nabídku na dodávku tohoto systému a následně se díky nejnižší ceně stala vítězem zmíněného výběrového řízení.

Dnes můžeme s radostí oznámit, že smlouva na dodávku JISP byla v minulých dnech oběma stranami podepsána, proběhla první schůzka zástupců řešitelů a objednatelů a naši zaměstnanci již usilovně pracují na prvních modelech nového systému, který by se měl do ostrého provozu spustit již na počátku příštího roku.

Doufáme, že se nám povede synergicky napojit ISOŘ a JISP tak, aby z tohoto spojení profitovali jak pracovníci SPD, tak pracovníci OŘ a my tím posunuli informačnímu systému HZS laťku zase o něco výše.

Setkání uživatelů a vývojářů se blíží

20. 5. 2019

Jako každý rok se i letos chystá „setkání uživatelů a vývojářů ISOŘ“ na Roučmídově Mlýně. Setkání zahájíme v úterý 28. 5. od 9:30 a rozloučíme se v úterý 29. 5. odpoledne. Tato setkání se již stala tradicí a za léta jejich konání jimi prošly desítky směnových techniků a IT pracovníků, operačních a řídících důstojníků a dalších zástupců operačního řízení. Některé „staré tváře“ postupně mizí, jak se jejich nositelé posunují na nové pozice u HZS nebo odcházejí mimo sbor a jejich místa zaujímají tváře nové, jiné patří už řadu let mezi stálice. Každopádně ať stálice, nebo nové tváře, těšíme se na setkání s každým jedním z vás.

Přes den je pro vás až do podvečerních hodin připraven odborný program – přehled nejvýznamnějších realizovaných změn v ISOŘ, výhled na další rozvoj, povídání o Dohledovém centru a novém HelpDesku, který jsme v loňském roce spustili do ostrého provozu nebo třeba dění a předpokládaný další vývoj projektu Jednotného informačního systému prevence (JISP), jehož vývoj a dodávku jsme v letošním roce vysoutěžili v rámci otevřeného výběrového řízení.

Neméně důležitou částí tohoto setkání je potom i neformální večerní část, kdy se na Roučmídě objeví většina klíčových firemních zaměstnanců a bude, tak jako každý rok, probíhat řada neformálních rozhovorů s vámi jako zástupci OŘ a našimi vývojáři. Tyto rozhovory jsou pro nás důležitou součástí celé akce, neboť se z nich dozvídáme přímou zpětnou vazbu na naše produkty a služby a v tom je toto osobní setkání nezastupitelné. Letos se navíc sejdeme v nově zrekonstruovaných konferenčních prostorách, takže věříme, že i z tohoto pohledu bude celé setkání příjemné pro všechny zúčastněné.

Takže – na shledanou na Roučmídě.

Inteligentní hlásiče v Brdech

21. 2. 2019

Armádou opuštěný vojenský výcvikový prostor Jince o rozloze 260 km2, který se stal v roce 2016 „Chráněnou krajinnou oblastí Brdy“, je z pohledu GSM sítě územím s žádným, nebo jen okrajovým pokrytím. Tato úžasná krajina se postupně stává zajímavým cílem pěších i cykloturistů. A obě první věty naznačují, že v následujících lze letech očekávat čím dál častější vznik situací, kdy bude třeba na konkrétní lokality, které jsou bez pokrytí operátorů mobilních sítí, přivolat pomoc některé ze složek IZS.

V polovině roku 2017 se objevily první představy o možném řešení výše zmíněného požadavku. RCS Kladno se stala jednou ze stran, která se na technickém návrhu budoucího řešení aktivně podílela. Druhým privátním subjektem pak byla společnost T-Mobile Czech Republic a.s. (dále v textu TMCR). Koordinátorem projektu se stali plzeňští hasiči, roli investora převzal Krajský úřad Plzeňského kraje.

Pro potřebné pokrytí území byla zvolena technologie SIGFOX, která je určena typicky pro sběr občasného, velmi malého množství dat a zároveň se vyznačuje velkým dosahem od přístupového bodu sítě. Inteligentní hlásiče uvažované do prostoru CHKO Brdy jsou pak typickým příkladem takové komunikace. Omezující podmínkou pro návrh vlastního koncového zařízení je schopnost jeho dlouhodobé činnosti bez síťového napájení 230V. Liniové schéma komunikace základních technologických celků lze zjednodušeně popsat následovně: Nouzové tlačítko (přijímač a vysílač sítě SIGFOX) – provozovatel sítě SIGFOX v CHKO Brdy (TMCR) – SIGFOX cloud – datové centrum TMCR – IS OŘ HZS – IS ostatních složek IZS.

Co se tedy děje, pokud turista stiskne nouzové tlačítko? Hlásič se aktivuje a prostřednictvím sítě SIGFOX odešle svou stavovou informaci. Ta je přijata do datového centra TMCR a odtud převzata pro tyto účely speciálně vyvinutým modulem do Informačního systému operačního řízení HZS Plzeňského kraje. Zde se jednak zobrazí operátorovi HZS, jednak je okamžitě předávána na operační středisko PČR Plzeňského kraje. PČR už má v tu chvíli informaci o čase stisku tlačítka, o jeho přesné poloze a může vyjet na místo. Operátor potvrdí příjem nouzového signálu a informace o přijetí proletí zpět na tlačítko, které před opětovným upadnutím do „režimu spánku“ na odpověď nějakou dobu aktivně čeká, takže turista získá zpětnou vazbu v podobě rozsvícení barevné kontrolky.

Komunikace mezi datovým centrem TMCR a IS OŘ Plzeňského kraje je zálohována nezávislou cestou přes GSM modem. V současnosti proběhly úspěšně testy komunikace mezi všemi zapojenými systémy a nasazení systému do ostrého provozu již nic nestojí v cestě.

Související odkazy:
https://cs.wikipedia.org/wiki/Brdy
https://cs.wikipedia.org/wiki/Vojenský_újezd_Brdy
https://www.sigfox.com
https://www.iot-portal.cz/2017/05/29/sigfox-princip-struktura-protokol-pouziti

Portál k registraci táborů

20. 2. 2019

Únor bílý, pole sílí. Tak praví pranostika. Bez ohledu na ni i na počasí v období zejména letních prázdnin, byla právě v tomto měsíci zakoupena a z testovacího do ostrého provozu převedena webová aplikace pro evidenci dětských táborů, škol v přírodě a dalších podobných akcí. Provoz aplikace včetně zabezpečení dat je v gesci Generálního ředitelství HZS ČR. Význam tohoto v pořadí již třetího veřejného portálu je právě v propojení dat. Pokud by došlo např. k požárům lesních porostů, záplavám nebo jiným, bezpečnost či zdraví a životy ohrožujícím okolnostem, má hasičský sbor okamžitý přehled, zda v takto zasažených oblastech neprobíhá ozdravná akce, tábor apod. A pokud ano, mohou neprodleně kontaktovat jejich pořadatele a současně zahájit odpovídající preventivní nebo záchranné akce, a to rovněž v součinnosti s ostatními složkami IZS ČR.

Pořadatelé mají zákonnou povinnost hlásit zotavovací akce orgánu ochrany veřejného zdraví, což činí ohlášením na Krajskou hygienickou stanici. Hasičský záchranný sbor těmito informacemi disponuje a může je pro výše uvedené účely využít. Tato povinnost však neplatí pro akce, které charakter zotavovací akce nesplňují. Zotavovací akce (dle § 8 ZoVZ ) je organizovaný pobyt 30 a více dětí ve věku do 15 let na dobu delší než 5 dnů. Akce kratší, pro menší počet dětí nebo pro dospělé účastníky jsou tedy z povinnosti ohlášení na KHS vyjmuti. Pokud ale pořadatel takovou akci na KHS neohlásí, hasiči o ní neví – ale i takové akce se mohou ocitnout v ohrožení. Je proto v zájmu pořadatelů, aby jejich akce byla z preventivních důvodů u složek IZS evidována. Zejména na takové typy akcí proto cílí tento nový portál.

Veřejný portál naleznete na adrese tabory.izscr.cz. Pro správu informací o táborech je nezbytná bezplatná registrace uživatele. Registrací získáváte nejen přístup k Vámi zadaným informacím o táborech, ale portál je úzce propojen i na portál paleni.izscr.cz, takže například ohlásit hasičskému sboru konání táborového ohně v místě tábora je potom otázkou několika kliknutí. Tím, že s registrací na „Táborech“ máte přímý přístup i do „Pálení“, můžete využívat možnost ohlašování pálení i v jiných termínech a lokalitách, například v rámci „pálení čarodějnic“, připadající každoročně na 30. dubna. Více informací naleznete zde.

HZSp Třinecké železárny

19. 2. 2019

V srpnu roku 2018 byla se společností Master IT Technologies, a.s. podepsána smlouva na dodávku řešení pro operační středisko HZS podniku Třinecké železárny.

Spolupráce s firmou Master IT Technologies (mající mj. sídlo nedaleko Třince), byla zvolena zejména pro geografickou vzdálenost místa dodávky od sídla RCS Kladno a dále pro dobrou místní znalost podmínek podniku. Třinečtí podnikoví hasiči se rozhodli pro komplexní řešení, které je zcela nezávislé na okolí a pro budoucí provoz i rozvoj řídícího centra přináší všechny základní technologie: databázi Oracle, aplikační, technologický i vyrozumívací server.

Novou částí ISV 6.0 je v případě této akce integrace rádiové sítě Hytera provozované v režimu TIER III. Významně se po spuštění centra povýšila úroveň komunikace s IBC Ostrava – nejde jen o obousměrný přenos stavových informací, ale i vzájemné vkládání požadavků na součinnost mezi oběma zmíněnými centry do vstupních front událostí.

Do ostrého provozu byl systém nasazen v listopadu 2018.

Nový web

18. 2. 2019

Vítáme Vás na nových www stránkách společnosti RCS Kladno.

S úsměvem lze konstatovat, že vůbec první vystavená verze našeho webu www.rcs-kladno.net má blíže k samotným počátkům internetu (např. teprve v roce 1992 bylo ke globální síti připojeno ČVUT v pražských Dejvicích a tím potažmo Československo, náš první web spuštěn 2001) než k současnosti 🙂

Po šestnácti letech provozu bylo třeba inovovat. A to i přesto, že pořekadlo „každá změna je k horšímu“, se (historicky) ukazuje jako často oprávněné. Při přípravě záměru i jeho následné realizaci se ukázalo, že největší nejistota a pochybnosti panují kolem úrovně detailu, s jakým má návštěvníky web seznamovat s tím, co tvoříme, co je základním předmětem naší podnikatelské aktivity. Ani jedna z krajních možností – strohá fakta na straně jedné a detailní popis všech našich aktivit a produktů na straně druhé – se nezdála být vhodnou. Kompromisní řešení, které bylo nakonec zvoleno, snad řekne dost těm, kteří o nás niky neslyšeli a nebude připadat jako zcela zbytečné plýtvání času a kapacitou linek té skupině uživatelů a správců, kteří s našimi programy denně pracují nebo kteří je spravují.

Přivítáme jakékoli Vaše připomínky k obsahu i formě, které byly zvoleny a po více než roce příprav i spuštěny.