Obecné programy rozvoja a informačné technológie

Ahojte, som členom mestskej komisie pre IT v Banskej Bystrici. Tento štvrtok bude naša komisia rokovať o dosť zásadnom dokumente, tzv. Programe rozvoja mesta. To je akýsi strategický materiál ktorý musia mať obce zo zákona vypracované.

Ja by som do materiálu chcel prepašovať aj niečo z oblasti IT . Máte prosím nejaké nápady, čo by nemalo chýbať v strategickom dokumente(pre roky 2024 - 2030) na úrovni krajského mesta?

Mňa napadli zatiaľ tieto akčné plány:

  1. Otvorné dáta

Mestský úrad vytvorí zoznam datasetov, ktoré by bolo možné publikovať. Tento zoznam mesto vopred prediskutuje na Komisii MsZ pre modenrú samosprávu. V analýze bude pri každom datasete uvedené

· Odhad časovej náročnosti (napr. v človekohodinách)
· Prekážky, príležitosti daného datasetu (menšia SWOT analýza)
· Poradové číslo priority daného datasetu z pohľadu užitočnosti pre verejnosť.
· Prínosy pre verejnosť (slovné zdôvodnenie tej-ktorej priority)

Zoznam bude priebežne aktualizovaný pričom pri každej aktualizácii bude vopred prekonzultovaný s Komisiou MsZ pre modernú samosprávu. Vždy, keď bude mestský úrad rozhodovať o publikovaní nového datasetu, infromuje dva týždne vopred spomenutú komisiu MsZ o svojom rozhodnutí. Pod pojmom “rozhodovanie” sa má na mysli napr. podanie žiadosti o grant, resp. vypísanie súťaže o vyhotovení datasetu. Názory členov komisie majú každopádne len poradný charakter a samotné rozhodnutie bude napokon v právomoci mestského úradu.

2. Obstarávanie open-source riešení

Pri obstarávaní softvérových riešení sa uprednostnia také typy licencií,ktoré dovolia publikovať zdrojový kód získaný v rámci danej zákazky. Najvhodnejšiou licenciou je pritom GNU/GPL. V prípade, že takýto cieľ nie je v danom obstarávaní vhodné zvoliť ako prioritu, mestský úrad zverejní vysvetlenie, prečo bolo potrebné od tohto cieľa ustúpiť (prečo sa zvolili menej transparentné typy licencií.). Takéto vysvetlenie úrad zverejní aspoň dva týždne pred spustením samotného obstarávania a bezodkladne o ňom infromuje aj Komisiu MsZ pre modernú samosprávu.

3. Komunikácia s odbornou verejnosťou

V prípade, že mestský úrad pripravuje väčšie projekty v oblasti IT, takéto plány vopred oznámi Komisi MsZ pre modernú samosprávu. Pod pojmom “väčšie projekty” sa myslia zákazky v hodnote väčšej ako 30 000 eur. Mestský úrad bude o vážnych rozhodnutiach infomovať spomenutú komisiu MsZ, a to aspoň 2 mesiace pred samotným rozhodnutím (pod pojmom “vážne rozhodnutie” sa myslí napr.podanie žiadosti o grant, vyhlásenie obstarávania a pod.).

4. Zamyslieť sa nad vendor lock-in mestského systému (od Cora -geo)
Do obstarávania na údržbu mestského systému sa naposledy prihlásila len jedna firma, tá ktorá ten systém aj vytvorila. Do roku 2030 sa tento problém vyriešiť nepodarí, ale môžme sa aspoň zamyslieť, aby sme problém aspoň nezhoršovali. Pri pridávaní nových modulov a funkcionalít do programu sa zamyslieť, či sa nebudú obstarávať zvlášť ako exterbé aplikácie, ktoré budú so zvyškom systému komunikovať cez API.


Čo si o takýchto bodov myslíte, máte nejaké návrhy, čo by ešte v stratégii na 6 rokov dopredu nemalo chýbať? Prípadne jestvuje nejaký vypracovaný zoznam odporúčaní, od ktorého by sa samosprávy mohli odraziť?

Nejde ani tak o to, aby boli tieto akčné body nejako právnicky nepriestrelne formulované, ale aby sa dalo na verejnosti skontrolovať, či mal úrad záujem tieto body dodržiavať.

Ďakujem za všetky rady

3 Likes

Tomáš,

podľa mňa ťah správnym smerom. K návrhu, čo si poslal, mám len jednu pripomienku: bod 4 by sa skôr ako riešenie konkrétneho problému mohol tiež preformulovať na všeobecné pravidlo (ako body 1-3), napr. Nahradiť všetky uzamknuté riešenia (vendor lock-in) otvorenými pre integráciu.

Ďalšie poznámky:

  • Pre mesto je dôležitá Koncepcia rozvoja IT (KRIT), ten treba vypracovať, mal by reagovať na plán rozvoja mesta.
  • Na jeho základe zadefinujte projekty podľa priorít, ktoré vám pomôžu najviac posunúť mesto v IT.
  • Pri riešení projektov zapojte odbornú verejnosť.

V Žiline máme INOVIA, ktorá spolupracuje s mestom intenzívne na digitalizačných projektoch. Cez túto inovačnú sieť sa zapájajú dôležití hráči zo súkromného sektora. Taktiež sa boríme s vendor lock-inom od CORAgeo a diskutujeme o možnostiach agendového systému novej generácie.

Ak by bolo treba, podelíme sa o skúsenosti.

Držím palce!

3 Likes

Len pár poznámok. 25 rokov robím dodávateľa (od programátora až po enterprise architekta).
Treba vysvetliť niektoré mýty:

  1. (Free) Open Source Software - (F)OSS - nie je všeliek, ani cieľ. Je to jeden zo spôsobov dosiahnutia cieľa. Ale treba mať podmienky na jeho využitie. Nie je to bezodná truhlica, odkiaľ sa len berie ale nič nevkladá. Toto je zásadný omyl mnohých manažérov. OSS sa aplikuje od najmenších knižníc až po nohutné (ERP/CRM) systémy. Ak však ani dodávateľ, ani prevádzkovateľ nemá skúsenosti s prácou v OSS skupinách, neprispeva k vývoju produktu, odhaleniu a pretestovaniu bugov, nevie sa zmieriť s tým, že dokumentácia je proti komerčnému svetu výrazne chufobnejšia, nepočíta s tým, že záruku de facto nik nenesie, nie je pripravený na alternatívu, že pôvodne OSS kúpi nadnárodná korporácia a do dvoch rokov to už OSS nebude, alebo sa jeho funkcionalita výrazne okreše a zbytok bude licencovaný, že sa vytvorí klon (MySQL/MariaDB) na ktorý to bude treba upraviť … tak si treba dobre premyslieť použitie a využitie.

  2. Zrušenie vendor-locku je tiež skoro mýtus. To sa treba sústrediť len na jeho elimináci, “V NAJHORŠÍCH SCENÁRCH”. Aj keď budeš mať zdrojáky otvorené, vždy budeš závislý na dodávateľovi. Nik tie zdrojáky tak nepozná, a nepomôže lepšie ako pôvodný autor (inak to je aj vysvetlenie prečo do súťaže na SLA máte len jedného súťažiaceho - upísať sa na prísne reakčné časy ak máš pol miliona riadkov neznámeho zdrojáku, ešte povedzme bez zdokumentovaného modelu, alebo zadania je sebevražda kvoli pokutám). Vendor lock a jeho elimináciu je treba chápať iba v zmysle poistky, že v prípade najhoršieho scenára (dodávateľ skrachuje, rozpadne sa, alebo mu odídu kľúčoví ľudia a servis trvá neúmerne dlho, alebo sa jednoducho budete stále hádať, či nekontrolovane bude dvíhať ceny) vieš nájsť cestu ako niekomu inému či už dať podporovať pôvodné riešenie, aby v ňom pokračoval, alebo ako zmigrovať na iné (na to potrebuješ poznať detailne to pôvodné aj to nov) … štandardné prevádzkové scenére sú vždy o závislosti na dodávateľovi… a je to jedno či si úrad, alebo súkromná firma. Napr. SAP vám zdrojáky nikdy nedá (max. ku časti, ktorá bola robená na mieru) a aj tak ho má každá poriadna firma, a aj štát práve implementuje CES na SAPe… A nik si nemyslí že je to nejaká zásaná chyba.

9 Likes

K otvoreným dátam by som zvážil nejakú formu prieskumu čo miestne firmy/univerzity/ngo by mohli využiť, aké údaje sú žiadané.

1 Like

Zdravím Tomáš, et.al.

trochu som pogooglil a vyzerá to tak, že mesto BB už svoju Koncepciu rozvoja informačných systémov mesta má

Vyzerá byt ale staršieho dátumu (2009) + je tam aj nejaká aktualizácia z roku 2013 (v rámci projektu Projekt - Elektronizácia služieb mesta Banská Bystrica), ale len na úrovni tabulárneho prehľadu:

  • Informačných systémov,
  • Životných situácií
  • eGov služieb

Každopádne by vo väzbe na ten program rozvoja mesta v časti 10. Digitalizácia mohol obsahovať úvodný bod “Aktualizácia koncepcie rozvoja informačných technologií”.

Takisto by bolo fajn prehodnotiť tie aktuálne navrhnuté body a podbody. (Digitálne dvojča a AI bude isto dobre podrobiť spresneniu, čo nimi v podmienkach BB autor/ka mali na mysli).
Keďže je tam priestor na cca 3-4 hlavné body a 1-2 podbody, bude dobré pozrieť si, kde chcela byť BB v roku 2013 a k tomu prvému bodu doplniť tie, ktoré by mali byť dôležité v oblasti IT podpory mesta do toho roku 2030 aj so zohľadnením prekryvu s inými témami, prípadne úplne “rozpustiť tú IT časť 10” v nich.

Tvoju (spravnu) uvaju mierne zjednodusim. Vendor lock si treba premietnut na exit costs + ocakavany rozvoj. Ak je to nieco s cim vieme zit, tak sa vendor locku bat netreba. Dokonca pri takomto vypocte moze vyjst, ze je ovela drahsie nieco vyvijat na zelenej luke (viac krat asi je ako nie je).

Uz som to sem daval, ale stale je to relevantne.

2 Likes

Technicka poznamka: praveze SAP zdrojaky dava automaticky so systemom kazdemu zakaznikovi, je to interpretovany system, obsahuje dictionary vsetkych objektov, kde su aj vsetky zdrojaky od funkcnych modulov apod. Kod sa da do znacnej hlbky debugovat a v debugeri su zdrojaky tiez viditelne. Vynimku tvoria skutocne low level funkcie. Problem je skor giganticke mnozstvo zdrojakov, prepojenie zdanlivo nesuvisiacich objektov a obrovsky, necitatelny databazovy model.

ok, dik za info. Tu nešlo presne o SAP, to mi len ako prvé napadlo :slight_smile:
Nevie či tak bolo vždy, ten nový HANA som ja v praxi ešte nevidel. Osobnú skúsenosť som mal skôr s CRM Siebel, kde zdrojáky aplikačných serverov si nevidel, ale repozitár samorejme obsahoval niektoré backendové / frontendové funkcionality + samorejme vlastné vyvinuté na mieru … všetko spolu s finálnou aplikáciou rozbité asi v 2600+ DB tabuľkách … Ani 5 rokov ti nestačilo na to aby si to dobre poznal :slight_smile: