Elektronikus dokumentumkezelés és workflow rendszer (EDE) kialakítása

Pályázat benyújtásának határideje: 2013. szeptember 4. 8:30

Szerencsejáték Zrt. nyilvános pályázatot hirdet elektronikus dokumentumkezelés és workflow rendszer (EDE) kialakítására

A Szerencsejáték Zrt.-nél jelenleg zajlik néhány elektronikus beszerzési rendszer tesztelése.

Annak érdekében, hogy megvizsgáljuk a folyamatot, az Elektronikus Dokumentumkezelés és workflow (EDE) pályázatot is kipróbáljuk az egyik ilyen rendszeren keresztül is.

Amennyiben szívesen közreműködnének a tesztelésben, kérjük, hogy e-mail címüket megadva jelentkezzenek regisztrációért 2013 július 31-éig az alábbi linken keresztül.

A teszt beszerzési rendszeren való jelentkezés sem hátrányosan, sem előnyösen nem befolyásolja a benyújtott pályázat megítélését. A tesztrendszeren beküldött anyagok a pályázatot semmilyen formában nem érintik és nem helyettesítik a papíron, elektronikusan a helyszínre beküldendő anyagokat. 

Köszönjük, hogy segítik a tesztelést!

A pályázattal kapcsolatos kérdések és válaszok

1. kérdés: A szoftver követelményspecifikáció dokumentumban az erre hivatkozott részen (3.3 folyamatirányítás) az található, hogy " a folyamat pontos terjedelme és a támogatás mértéke a folyamat részletes vizsgálatakor az adott szakterülettel egyeztetendő"

A folyamatok részletes vizsgálata a projekt kezdésekor, a kivitelezése alatt történne meg?

Válasz: A folyamatok részletes vizsgálata, feltérképezése még nem került végrehajtásra, a projekt kezdete előtt (a rendszerterv kialakításának kezdetére) fog megtörténni. A részletes feltérképezés elvégzése nem tárgya a beszerzésnek.

Folyamatonként kb. 15-20 lépésből álló workflow kialakítását látjuk szükségesnek, összesen a Szoftver Követelményspecifikáció 3.3 pontjában rögzített 10 folyamatra.

A workflow modul lényege, hogy a Szerencsejáték Zrt. rendelkezésére álljon egy olyan workflow eszköz, amely alkalmazásával a későbbiekben további workflow folyamatokat alakíthat ki – a rögzített 10 folyamat ennek a minden szervezeti egységen való bemutatására szolgál.

2. kérdés: Valamennyi adminisztratív Szerencsejáték Zrt. dolgozónak biztosítani kell a munkafolyamatot támogató informatikai rendszerhez való hozzáférést. Jelenleg ez maximum 700 fő.

A hozzáférés alatt írási, azaz módosítási jogot is kell érteni, vagy a jelenleg maximum 700 fő nagy része csak olvasási, nem módosítási joggal kell rendelkeznie?

Válasz: A 700 főből legfeljebb 150 fő végez jelenleg iratkezeléssel kapcsolatos feladatokat, így a rendszer élesbe állásakor legfeljebb 150 felhasználó írási és olvasási igénye várható. A többi, kezdetben kb. 550 felhasználó számára az Üzleti Követelményspecifikáció 5.2 pontjában rögzített „Lekérdező” jogosultságot kell kiadni, ami kizárólag olvasási jogosultságot jelent. A rendszer használatának kiterjesztése során azonban várható, hogy egyre több felhasználónak lesz szükséges írási jogot adni, így a 150-es létszám reális becslés alapján 400-500 körülre is emelkedhet 2-3 éven belül.

A workflow modul kapcsán a rendszer éles indulásakor az iratkezelési modulhoz hasonlóan kb. 100-150 fő írási-olvasási hozzáférése lesz szükséges, viszont a workflow modul kiterjesztése során a modulnak bírnia kell a 700 fő írási joggal való hozzáférését is, bár a hozzáférések túlnyomó része legfeljebb néhány mező módosítását jelenti.

3. kérdés:

  • Megkaphatjuk-e a pályázatban megjelölt folyamatok munkafolyamat ábráját és a hozzá tartozó leírásokat
  • Megkaphatjuk-e, hogy az ARIS rendszer milyen outputtal rendelkezik ugyanezen ábrákra vonatkozóan, amelyet rendszerünknek fel kell majd dolgozni
  • Lehet-e módosításokat kérni, hogy a rendszerünk által elvárt minimum adatok is majd benne legyenek az ARIS rendszer által előállított kimenetben
  • ARIS rendszernek történő munkafolyamat adatokra vonatkozó adat átadásra milyen lehetőségeket kapunk?

Válasz: A folyamatok részletes vizsgálata, feltérképezése még nem került végrehajtásra, a projekt kezdete előtt (a rendszerterv kialakításának kezdetére) fog megtörténni. A részletes feltérképezés elvégzése nem tárgya a beszerzésnek.

Folyamatonként kb. 15-20 lépésből álló workflow kialakítását látjuk szükségesnek, összesen a Szoftver Követelményspecifikáció 3.3 pontjában rögzített 10 folyamatra.

A workflow modul lényege, hogy a Szerencsejáték Zrt. rendelkezésére álljon egy olyan workflow eszköz, amely alkalmazásával a későbbiekben további workflow folyamatokat alakíthat ki – a rögzített 10 folyamat ennek a minden szervezeti egységen való bemutatására szolgál.

A vállalton belül a folyamatmenedzsment részeként az SZZRT üzleti folyamatai teljes körűen, elemi tevékenység szinten, az egyéb (irányító, támogató) folyamatok pedig részlegesen vannak dokumentálva az ARIS folyamatmenedzsment támogató informatikai rendszerben, a folyamatok gyakorlati végrehajtása viszont nem ARIS workflow támogatással valósul meg.

A belső folyamatok (így az iratkezelő rendszerhez kapcsolódó workflow-ban rögzítendő folyamatok) nincsenek ARIS-ban dokumentálva.

4. kérdés: A Basware rendszernek szükséges lesz-e átadni a kép állományokat is vagy elég adat szinten átadni az adatokat

Válasz: Az iratkezelő rendszernek képesnek kell lennie a csatolt állományok más rendszer (így a BasWare) felé interfészen való átadására. (Az ellenoldali interfészek kialakítása természetesen nem jelen projekt feladata.)

5. kérdés: Mekkora a napi posta állomány amit fel kell majd dolgozni a digitalizálónak?

  • Minden posta feldolgozás központosítva lesz, vagy fel kell készülni telephelyenkénti feldolgozásra?
  • Ha nem központosítva lesz akkor kérjük a napi mennyiséget telephelyenként megadni

Válasz: A két budapesti SZZRT telephelyen levő központi szkennelő és feldolgozó megoldásnak legalább évi 100.000 irat (1.000.000 oldal) feldolgozására kell képesnek lennie, figyelembe véve, hogy az évi iratforgalom időbeli eloszlása nem feltétlenül egyenletes. (Megjegyzés: Szkenner hardver szállítása nem az iratkezelő modul szállítását végző szállító feladata.) (FI44)

Központi digitalizálás bevezetése a jelen projekt részeként a két budapesti telephelyen tervezett. Ugyanakkor az iratkezelő rendszernek a vidéki telephelyek iratforgalmát is kezelnie kell, de ott jóval kevesebb csatolt fájl várható a digitalizálás nem kötelező volta miatt.

A vidéki telephelyek jelenlegi, illetve becsült maximális iratforgalma:

Terület Éves iratforgalom Becsült maximum
Szegedi Értékesítési Régió kb. 13.000 25.000
Miskolci Értékesítési Régió kb. 3.000 25.000
Pécsi Értékesítési Régió kb. 4.900 25.000

 

6. kérdés: A fejezetben lévő 10 darab folyamatról nincs megadva funkcionális specifikáció. Ezek fejlesztése és szállítása is tárgya a jelenlegi beszerzésnek? Vagy a rendszer képességét kell igazolni és a hivatkozott felmérés után kerül sor a konkrét beszerzési kiírásra ezekre vonatkozóan? Ha részei ezek a jelenlegi beszerzésnek, akkor további  információkat kérünk a megvalósítandó folyamatokról, amire az ajánlatot alapozni tudjuk.

Ha ilyen specifikációt jelenleg nem lehet megadni, akkor mik az elbírálás szempontjai?

Válasz: A folyamatok részletes vizsgálata, feltérképezése még nem került végrehajtásra, a projekt kezdete előtt (a rendszerterv kialakításának kezdetére) fog megtörténni. A részletes feltérképezés elvégzése nem tárgya a beszerzésnek.

Folyamatonként kb. 15-20 lépésből álló workflow kialakítását látjuk szükségesnek, összesen a Szoftver Követelményspecifikáció 3.3 pontjában rögzített 10 folyamatra.

A workflow modul lényege, hogy a Szerencsejáték Zrt. rendelkezésére álljon egy olyan workflow eszköz, amely alkalmazásával a későbbiekben további workflow folyamatokat alakíthat ki – a rögzített 10 folyamat ennek a minden szervezeti egységen való bemutatására szolgál.

Az elbírálás szempontja a Szoftver követelményspecifikáció 3.3. pontjában bemutatott funkciók biztosítása, valamint a projekt kezdetére kialakítandó a folyamatok workflow keretrendszerben történő implementálásának vállalása. (Tehát a folyamat feltérképezést az SZZRT végzi el, de a folyamatok workflow rendszerben való implementálása a Vállalkozó feladata.)

7. kérdés: A kiírás alapján az iratkezelő rendszer és az AX partnertörzsek különbözőek. Mit jelent pontosan a két partnertörzs szinkronizálása ebben az esetben?

Válasz: Az iratkezelő rendszer (az AX rendszerből érkező jelzés esetén) képes legyen egyedi partneradat (partnertörzs bejegyzés) átadásra az AX rendszer felé.

Az iratkezelő rendszerbe külső rendszerből partnertörzs adatok átemelhetőek legyenek. (Elegendő egy Excel tábla feltöltésével megvalósítani.)

Automatikus szinkronizáció megvalósítása nem feladat.

8. kérdés: Van e arra lehetőség hogy a pályázati kiírás mellékletében szereplő iratmintákat (18-24. oldal) elektronikusan szerkeszthető módon is megkapjuk?

Válasz: A pályázati kiírás mellékleteként szereplő iratmintákat a holnapon elérhetővé tettük szerkeszthető formában is.

9. kérdés: A Pályázati felhívás 10. pontjának utolsó mondata szerint „Az üzleti- és szoftver követelményspecifikáció, valamint a projekt terv jelen Pályázati felhívás mellékletét képezik. A rendelkezésünkre álló dokumentáció azonban nem tartalmaz projekt tervet.

Válasz: A korábban elkészült projekt ütemezés már elévült, mivel az abban szereplő kezdő időpont nem tartható. Az iratkezelő rendszer SZZRT által tervezett élesbe állási időpontja: 2014. március 3.

10. kérdés: Milyen elvárások vonatkoznak együttes pályázatra, alvállalkozók igénybevételére? Milyen nyilatkozatokat kell az alvállalkozónak beadnia?

Válasz: Egyetlen fővállalkozó vagy alvállalkozó sem szerepelhet más pályázó pályázatában sem fővállalkozóként, sem alvállalkozóként.

Egyebek tekintetében az alvállalkozó teljesítéséért fővállalkozó ugyanúgy felel, mintha az adott feladatot saját munkatársai végezték volna el.

Az alkalmassági feltételeknek a fővállalkozónak és az alvállalkozóknak összesítve kell megfelelnie.

Az alvállalkozóknak az 1. sz. mellékletet szintén ki kell tölteni – az abban foglalt kizáró feltételek fenn nem állásának minden alvállalkozó esetében igaznak kell lennie.

11. kérdés: A Szoftver követelményspecifikáció 7.5 fejezetében megfogalmazott P/22 követelmény esetén az "Iratkezelési feladatokat ellátó ügyintézők (maximum 100 fő)" oktatása az pályázó feladata vagy az SZZRT kulcsfelhasználók oktatnak?

Válasz: Az iratkezelési feladatokat ellátó ügyintézők (max. 100 fő) oktatása a pályázó feladata. Az esetlegesen szükséges további oktatások a kulcsfelhasználók feladatai. Szintén a kulcsfelhasználók feladata lesz a (nem iratkezelési) workflow-k oktatása.

12. kérdés: Kérjük részletezni szoftver köv. specifikáció 5.2 fejezetében megfogalmazott FD/5. igényt: "A dokumentumkezelő modul valósítsa meg a hiteles elektronikus iratok tárolását."

Pontos-e az az értelmezésünk, hogy:

a.) elegendő az elektronikusan aláírt dokumentumok tárolását biztosítani a rendszerben?

VAGY ha nem, akkor

b.) kell-e tudni ellenőrizni az elektronikus aláírás hitelességét, érvényességét a rendszerben?

c.) Kell-e a rendszerben lévő elektronikus iratokat elektronikus aláírással, időbélyeggel ellátni?

d.) ha b.) vagy c.) követelmény, akkor kérjük pontosan megadni milyen elektronikus aláírási infrastruktúrával rendelkezik jelenleg a SZZRT. Tárgya-e az ajánlatnak bármilyen elektronikus aláírást támogató rendszer szállítása, megvalósítása?

Válasz: Elegendő az elektronikusan aláírt dokumentumok tárolását biztosítani a rendszerben – de biztosítani kell, hogy ami joghatás kiváltására alkalmas elektronikus formában érkezett be az SZZRT-hez, az joghatás kiváltására alkalmas maradjon a dokumentumtárban is.

13. kérdés: A pályázati kiírás 9. fejezetében az áll: "Amennyiben a Pályázó Pályázata a Pályázat kiírója számára kitételeket, feltételeket fogalmaz meg, úgy a pályázatot az SZZRT. érvénytelennek nyilvánítja. Helyes-e az az értelmezésünk, hogy ez nem vonatkozik műszaki és a projektben való közreműködés tekintetében tett feltételekre, elvárásokra?

Válasz: Igen, jól értelmezik.

14. kérdés: Milyen elvárások vonatkoznak együttes pályázatra, alvállalkozók igénybevételére? Milyen nyilatkozatokat kell az alvállalkozónak beadnia?

Válasz: Egyetlen fővállalkozó vagy alvállalkozó sem szerepelhet más pályázó pályázatában sem fővállalkozóként, sem alvállalkozóként.

Egyebek tekintetében az alvállalkozó teljesítéséért fővállalkozó ugyanúgy felel, mintha az adott feladatot saját munkatársai végezték volna el.

Az alkalmassági feltételeknek a fővállalkozónak és az alvállalkozóknak összesítve kell megfelelnie.

15. kérdés: A 10 db workflow-nak (amiknek a feltérképezése még nem került végrehajtásra) az implementálására árat kell-e adni az ajánlatban?

Válasz: A 10 db workflow implementálása az Ajánlattevő feladatai közé tartozik. (A 10 workflow feltérképezése ugyanakkor nem képezi az Ajánlattevő feladatainak részét. )

16. kérdés: A központi iratkezelőben hány személy foglalkozik a kimenő postázási feladatokkal?

Válasz: Jelenleg 2 fő dolgozik a központi iratkezelőben, akik (többek között) a kimenő postázási feladatok ellátásáért is felelnek. A központi iratkezelő létszáma az iratkezelés központosításával várhatóan nőni fog.

17. kérdés: A lenti követelmény megfogalmazója az utolsó iktatott iraton az adott felhasználó (aktív felhasználó) által utoljára iktatott (akár több nappal korábban) iratot értette?

FI/25 Előzmények megadása találati listából Keresés eredményeképpen megadott találati listából, illetve megnyitott iratból legyen lehetőség közvetlenül az utolsó iktatott irattal való iratkapcsolat létrehozására.

 

Válasz: Az utolsó iratot elegendő azonban cache-ben tárolni, tehát nem szükséges az előző munkamenetben utoljára iktatott irat megjegyzése.Igen, a követelmény az adott felhasználó által utoljára iktatott irattal való iratkapcsolat lehetőségét érti.

18. kérdés: A lenti követelmény megfogalmazója érkeztetési bejegyzésként egy postakönyvi tétel / küldemény rendszerben történő reprezentációjára gondolt?

FI/30 Egybevont iktatás és érkeztetés A korábban nem érkeztetett iratok (pl. közvetlen a szervezeti egységhez érkezett iratok) esetében legyen lehetséges az iktatást és az érkeztetést (valamint a bontást) egyben, egyetlen felületen elvégezni. Egy érkeztetési bejegyzés alapján több iktatás is legyen lehetséges.

 

Válasz: Az „egy érkeztetési bejegyzés alapján több iktatás is legyen lehetséges” követelmény azt jelenti, hogy egy küldemény bejegyzés (érkeztetési azonosító) alapján több iktatás is lehetséges legyen.

19. kérdés: A lenti követelmény megfogalmazója érkeztetőkönyvön a küldemények átadás-átvételét tényének rögzítésére szolgáló megoldást érti?

FI/34 Érkeztetőkönyv, iktatókönyv lezárása A sorszámozás megadott időközönként (alapértelmezetten évente) legyen újraindítható. Az újraindított érkeztetőkönyv, illetve iktatókönyv ugyanakkor kerüljön lezárásra, abba további új érkeztetési/iktatási bejegyzés már ne legyen felvehető.

 

Válasz: Az érkeztetőkönyv a küldemények SZZRT-hez való beérkezésének tényét rögzíti, a beérkező küldemények egyedi azonosítására szolgál. Nem az érkeztetőkönyv rögzíti viszont a belső átadás-átvételi folyamatot.

(335/2005: „17. érkeztetés: a beérkezett küldemény érkeztetési azonosítóval, valamint beérkezési dátummal történő ellátása és nyilvántartásba vétele; […] 40. papír alapú érkeztető könyv: hitelesített iratkezelési segédeszköz, amelyben a küldemények közfeladatot ellátó szervhez történő beérkezésének a nyilvántartásba vétele megtörténik;”).

20. kérdés: Fájl csatoláson az irat iratképének (papír alapú irat) és (vegyes irat esetén) / vagy az eredeti elektronikus irat csatolását értjük?

FI/38 Fájl csatolása Az iratkezelő modul felületről fájlok csatolhatóak mind az érkeztetési, mind az iktatási bejegyzésekhez - főszámokhoz, illetve alszámokhoz is. A csatolás történhet manuálisan, illetve interfészen (pl. szkennelő modul, folyamatkezelő modul) is.

 

Válasz: Fájl csatolásán elektronikusan (akár hitelesen, akár nem hiteles csatornán) érkezett irat esetében az eredeti elektronikus irat, papíron érkezett irat esetében az irat digitalizált képének csatolását értjük. (Természetesen extrém méretű fájloknál el lehet tekinteni a workflow rendszerbe való csatolástól.)

21. kérdés: Jól gondoljuk, hogy a lenti kérdés a kiadmányozási szerepkör / jog átruházás megvalósításának módját firtatja?

FI/62 Papíralapú kiadmányozás támogatása Az iratkezelő modul támogassa az elektronikus jóváhagyáson túl a vezetői jóváhagyás alapján az asszisztensek által végzett papíralapú kiadmányozási folyamat végrehajtását is.

 

Válasz: Igen.

22. kérdés: Az SZZRT saját ragszám tartománnyal rendelkezik?

FI/66 Boríték nyomtatása A megadott postázási adatok alapján az iratkezelő modul az SZZRT által alkalmazott Ricoh Aficio MP C3001 hálózati nyomtatókon borítékot kell, hogy tudjon nyomtatni. Az iratkezelő rendszernek képesnek kell lenni a borítékra megadott formátumú vonalkód (egyedi azonosító, valamint ragszám) nyomtatására is.

 

Válasz: Az SZZRT jelenleg nem rendelkezik saját ragszám tartománnyal, (jelenleg Posta által dedikált értékkészletű) de az iratkezelő rendszernek a ragszám tartomány paraméterként való megadásával ettől függetlenül képesnek kell lennie ragszám nyomtatásra is.

23. kérdés: Megajánlható-e olyan rendszer, mely a „Szoftver követelményspecifikáció a Szerencsejáték Zrt. irat- és dokumentumkezelést, valamint folyamatirányítást támogató szoftveres megoldására” elnevezésű dokumentum 2.1._A/1 pontjában megfogalmazott jogszabályi megfelelésnek a beadás pillanatában még nem felel meg, de a tanúsítása folyamatban van.

Válasz: 2.1. A/1 pontjában megfogalmazott jogszabályi megfelelés a pályázat beküldési határidejéig meg kell hogy valósuljon.

24. kérdés: A pályázatok bontása nyilvános-e a pályázók számára?

Válasz: Nem nyilvános.

25. kérdés: Van-e lehetősége a hat legalkalmasabbnak ítélt pályázónak a bemutató után végső ajánlatadásra?

Válasz: Nincs.

26. kérdés: Ajánlhatjuk-e a magyar nyelvű felhasználói felülettel rendelkező rendszerünket a fenti – széles körben elfogadott, piacvezető, angol nyelvű - „szkennelés, karakterfelismerés” komponenssel?

Válasz: Amennyiben kizárólag a szkennelő, illetve a karakterfelismerő program felülete nem magyar nyelvű, a szoftver alkalmas – a megvalósítás során azonban olyan szintű magyar nyelvű dokumentációt kell a szállítónak biztosítania, amely alapján a vonatkozó szkennelési és OCR vezérlési feladatok elvégezhetőek.

27. kérdés: A rendszernek képesnek kell lennie más, külsőrendszerekkel (például a specifikáció alatt levő új HR rendszerrel) folyatott szabványos adatcserére. Az ehhez szükséges adatkommunikációt webservice alapú üzeneteken keresztül kell megvalósítani. Ez alatt hány rendszert értenek, számszerűen megadva?

Válasz: A követelmény azt jelenti, hogy a rendszernek rendelkeznie kell egy olyan általános interfésszel (valamint interfész specifikációval), amin keresztül a később kialakításra kerülő (jelenleg még csak távlati tervekben szereplő) Szerencsejáték Zrt. oldali rendszerek csatlakozni tudnak. Ezen új rendszerek száma egyelőre nincs definiálva.

28. kérdés: Hány felhasználóra adjuk meg a licenszeket? Egyidőben hány felhasználó csatlakozik a rendszer szolgáltatásaihoz közvetlenül illetve interface-en keresztül?

Válasz: Egyidőben az összes írási és olvasási felhasználó rendszerelérésével számolni kell, ez alapján a rendszer elindulásakor 150 írási, és 550 olvasási igényére kell méretezni a rendszert, licencelési szempontból is.

Interface-en keresztül ugyanezen felhasználók fogják elérni a rendszert, de csak közvetetten – közvetlenül természetesen az interfészelt rendszer fogja megszólítani a rendszert. (Külső hozzáférések viszont nem várhatóak.)

29. kérdés: Migrálandó adatmennyiséggel kapcsolatban: darabszám, teljes adatmennyiség mérete. Hogyan és milyen formában nyerhetőek ki az index adatok illetve objektumok?

Válasz: A migrálandó adatokat az SZZRT egységesen strukturált Excel táblában fogja átadni, tehát a nyertes Pályázónak nem kell azokat más iratkezelő rendszerekből kinyerni.

30. kérdés: Kezelendő dokumentumok számossága (típusonként, éves darabszám, várható növekmény) Dokumentumok jellemzői (átlagos oldalszám, szkennelés minősége, átlagos fájlméret)

Válasz: Kezelendő iratok reális mennyisége: 100.000 főszám / év, főszámonként átlagosan 5 alszámmal.

Egy szkennelendő dokumentum átlagosan 10 oldalas, szkennelés minősége 240 DPI/BW. Kimenet kétrétegű PDF, fájlméret ennek megfelelő.

31. Kérdés: Folyamatok számossága (éves mennyiség, jellemző átfutási idő, résztvevők átlagos száma)

Válasz: Amennyiben a workflow folyamatokra kérdeznek, a választ tartalmazza a 3. sz. válasz a korábban feltett kérdések között:

A folyamatok részletes vizsgálata, feltérképezése még nem került végrehajtásra, a projekt kezdete előtt (a rendszerterv kialakításának kezdetére) fog megtörténni. A részletes feltérképezés elvégzése nem tárgya a beszerzésnek.

Folyamatonként kb. 15-20 lépésből álló workflow kialakítását látjuk szükségesnek, összesen a Szoftver Követelményspecifikáció 3.3 pontjában rögzített 10 folyamatra.

A workflow modul lényege, hogy a Szerencsejáték Zrt. rendelkezésére álljon egy olyan workflow eszköz, amely alkalmazásával a későbbiekben további workflow folyamatokat alakíthat ki – a rögzített 10 folyamat ennek a minden szervezeti egységen való bemutatására szolgál.

A vállalaton belül a folyamatmenedzsment részeként a Szerencsejáték Zrt. üzleti folyamatai teljes körűen, elemi tevékenység szinten, az egyéb (irányító, támogató) folyamatok pedig részlegesen vannak dokumentálva az ARIS folyamatmenedzsment támogató informatikai rendszerben, a folyamatok gyakorlati végrehajtása viszont nem ARIS workflow támogatással valósul meg.

A belső folyamatok (így az iratkezelő rendszerhez kapcsolódó workflow-ban rögzítendő folyamatok) nincsenek ARIS-ban dokumentálva.

Egyéb WF folyamatok megvalósítása jelenleg nem feladata a Pályázónak, de az FF/14 szerint követelmény: „A rendszerben legyen lehetőség programozási nyelvek ismerete, illetve a Szállító közreműködése nélkül is folyamatokat megtervezni, definiálni. Pl. grafikus felületen.”

32. kérdés: Fejlesztés, telepítés, support során biztosítható-e a távoli hozzáférés?

Válasz: A távoli elérésben rejlő kockázatok miatt a telepítés és fejlesztés nem, csak a support tevékenység engedélyezett.

33. kérdés: A kiírás nem tartalmaz kellő részletességű leírást az egyes (FF/3.-FF/12.) munkafolyamatokkal kapcsolatban (pl: Belső ellenőrzések lebonyolítása; Szerződéskészítés, Panaszkezelés, …) ezért pontos ajánlatot ezek megvalósítására nem lehet felelősséggel adni. Ezeknél a tételeknél hogyan, milyen formában adja meg az Ajánlattevő az ajánlatot?

Válasz: A választ tartalmazza a 3. sz. válasz a korábban feltett kérdések között:

A folyamatok részletes vizsgálata, feltérképezése még nem került végrehajtásra, a projekt kezdete előtt (a rendszerterv kialakításának kezdetére) fog megtörténni. 
A részletes feltérképezés elvégzése nem tárgya a beszerzésnek.

Folyamatonként kb. 15-20 lépésből álló workflow kialakítását látjuk szükségesnek, összesen a Szoftver Követelményspecifikáció 3.3 pontjában rögzített 10 folyamatra.

A workflow modul lényege, hogy a Szerencsejáték Zrt. rendelkezésére álljon egy olyan workflow eszköz, amely alkalmazásával a későbbiekben további workflow folyamatokat alakíthat ki – a rögzített 10 folyamat ennek a minden szervezeti egységen való bemutatására szolgál.

A vállalton belül a folyamatmenedzsment részeként az SZZRT üzleti folyamatai teljes körűen, elemi tevékenység szinten, az egyéb (irányító, támogató) folyamatok pedig részlegesen vannak dokumentálva az ARIS folyamatmenedzsment támogató informatikai rendszerben, a folyamatok gyakorlati végrehajtása viszont nem ARIS workflow támogatással valósul meg.

A belső folyamatok (így az iratkezelő rendszerhez kapcsolódó workflow-ban rögzítendő folyamatok) nincsenek ARIS-ban dokumentálva.

34. kérdés: Kérjük megadni az archív média típusát? (pl: NAS, netApp, Centera,…)

Válasz: DPM mentőrendszert tudunk biztosítani. NetApp tárolja a diszk alapú mentéseket, és kazettára csak archiválás történik. D2D2T.

35. kérdés: A Szoftverkövetelmény specifikáció ÜZ/4 - ÜZ/5 - ÜZ/6 pontja foglalkozik az adatmentés, archiválás kérdéseivel. Milyen mentőszoftvert használnak?

Válasz: DPM mentőrendszert tudunk biztosítani. NetApp tárolja a diszk alapú mentéseket, és kazettára csak archiválás történik. D2D2T.

36. kérdés: A Szoftverkövetelmény specifikáció I/8 pontja említi a Szerencsejáték Zrt. bejelentés kezelő rendszerét (BENYIL). E rendszer szintén MS SQL alapon működik?

Válasz: Igen, de az Szerencsejáték Zrt. ugyanakkor jelzi, hogy csak interfészen való kommunikáció lehetséges, adatbázis szintű hozzáférés nem, valamint az interfészelendő rendszerek oldalán szükséges módosítások elvégzése nem a Pályázó feladata, így az interfészelendő rendszerek adatbázisa ilyen szempontból irreleváns.

37. kérdés: A pályázati felhívás 11. pontja [A pályázat gazdasági ajánlata] rögzíti, hogy "Ajánlati árként a használat első 5 évére várható költségeket vesszük figyelembe. (Évi 12 nap üzemeltetés, fejlesztés beszámításával.)".

A követelmény alapján nem egyértelmű, hogy évi 12 nap üzemeltetés és 12 nap fejlesztés (összesen évi 24 nap) költségét kell figyelembe venni, vagy évi 12 nap olyan szolgáltatásét, mely üzemeltetésre és fejlesztésre egyaránt felhasználható?

Válasz: A support szerződésben 12 lehívható nap üzemeltetés támogatás vagy fejlesztői nap (összesen tehát évi 12 lehívható nap) költségét kell beleszámítani.

38. kérdés: A pályázattal kapcsolatos kérdések és válaszok közt a 2. kérdésre adott válaszban szerepel, hogy "... 150 felhasználó írási és olvasási igénye várható. A többi, kezdetben kb. 550 felhasználó számára ... „Lekérdező” jogosultságot kell kiadni, ami kizárólag olvasási jogosultságot jelent ... A rendszer használatának kiterjesztése során azonban várható, hogy egyre több felhasználónak lesz szükséges írási jogot adni, így a 150-es létszám reális becslés alapján 400-500 körülre is emelkedhet 2-3 éven belül."  A pályázati felhívás 11. pontja [A pályázat gazdasági ajánlata] rögzíti, hogy "Az ajánlatnak tartalmaznia kell a bevezetéssel kapcsolatos valamennyi szoftver licensz árát", továbbá hogy "Ajánlati árként a használat első 5 évére várható költségeket vesszük figyelembe. (Évi 12 nap üzemeltetés, fejlesztés beszámításával.)".

Az 5 évre várható költségek tervezésekor számolni kell-e a lekérdező jogosultság írási jogúvá bővítésével? (Ha igen, úgy a költségek számításhoz kérjük megadni ennek ütemezését: pl 1. év - 100 felhasználó, 2. év - 250 felhasználó stb.).

Válasz: Igen, számolni kell a lekérdezői jogosultságok bővítésével, az alábbi szkenárió szerint:

-          1. év: 150 írási, 550 csak olvasási felhasználó

-          2. év: 200 írási, 500 csak olvasási felhasználó

-          3. év: 250 írási, 450 csak olvasási felhasználó

-          4. év: 300 írási, 400 csak olvasási felhasználó

-          5. év: 350 írási, 350 csak olvasási felhasználó

Amennyiben a licencet felhasználó számra adják meg, a bővítésnek opcionálisnak kell lennie – azaz beárazni a fent írt növekményt kell, de annak tényleges kifizetésére csak tényleges felhasználó szám növekedés esetén kerül sor.

A tényleges licencelés a fent írtnál magasabb és alacsonyabb is lehet – a tényleges kifizetésre a tényleges felhasználó szám szerint kerül sor, az ár értékelése viszont a fent megadott szkenárió szerint történik.

A Szerencsejáték Zrt. jelzi ugyanakkor, hogy korlátlan (max. 700) felhasználószám szervezeten belüli szabad felhasználását egyszerűbb megoldásnak találja,mintsem az évenkénti külön elszámolást (már csak belső erőforrás gazdálkodási okokból is), így egyértelműen a 700-as felhasználószámon belüli szabad felhasználó-kezelést preferál, ami az értékelés során is szempont lehet. Az írt felhasználó mennyiség a maximális egyidejű felhasználószám megadása a rendszer terhelés méretezésének céljából.

---------------------------------------------------------------------------------

A kiegészítő kérdésekre adott válaszokban közzétételre került a projektterv (Gantt ábra). Ebben az látható, hogy az „Élesbe állás” task kezdete a „környezet kialakítása”, vége a „szoftver élesbe állása”, időtartama pedig 1 hónap.

A szoftver követelményspecifikáció P/23 pontja a „Próbaüzem” követelményével foglalkozik. A próbaüzem feladadatai közt az első az éles infrastruktúrán történő telepítés. A „Próbaüzem” – mint tétel – nem került feltüntetésre a projektterv Gantt diagramon, azonban vélelmezzük, hogy mivel ez is, illetve az „Élesbe állás” kezdete is a „éles telepítés”, így mindkettő azonos időszakot fed le.

A P/24 pont az élesbe állással, stabilizációval foglalkozik. A követelmény szerint az élesbe állást követően 1 hónap stabilizációs időszak kezdődik, melynek során folyamatos helyszíni támogatást kell nyújtani. A Gantt ábrán az 1 hónapos „Élesbe állás” task utolsó feladata a „szoftver élesbeállás”. Ebből az következik, hogy az 1 hónapos „Élesbe állás” után jön az 1 hónap stabilizációs időszak.

A szoftver követelményspecifikáció T/3 pontja a Poszt-implementációs támogatásról ír, mely szerint a rendszer átadását követően 1 hónap helyszíni támogatás szükséges.

Sem a dokumentáció, sem a Gantt nem tartalmazza, hogy a rendszer átadása (végátadása) mikor történik meg, milyen eseményhez rögzítsük. Feltételezve, hogy a végátadás a „szoftver élesbeállás” napján – tehát az „Élesbe állás” task utolsó napján – történik meg, úgy ebből az következik, hogy mind a „stabilizációs időszak”, mind a „poszt implementációs időszak" ugyanarra az időszakra ugyanazt a szolgáltatást nyújta. A Gantt ábra utolsó taskja sem nyújt segítséget annak eldöntésében, hogy ez azonos vagy két különböző szolgáltatás, mivel csak annyi került feltüntetésre, hogy „Helyszíni támogatás – éles indulás helyszíni támogatása”.

39. kérdés:

a.        Jól gondoljuk, hogy „Élesbe állás” során zajlik a „Próbaüzem”?

b.        A rendszer végátadása mikor történik meg?

c.        A „stabilizációs időszak” és a „poszt implementációs időszak” 1 hónapos helyszíni támogatása egyugyanazon szolgáltatást jelöli?

d.        Ha a „c” kérdésre a válasz „nem”, akkor helyes-e az alábbi menetrend: 1. szoftver élesbeállás, 2. stabilizációs időszak (1 hó), 3. rendszer végátadása, 4. poszt implementációs időszak (1 hó)?

Válasz: A rendszer átvétele a sikeres tesztelés után történik meg. (53-as sor)

A T/3 pontban rögzített „Poszt implementációs időszak” és a „Stabilizációs időszak” ugyanazt az egy hónapot jelöli, ami az éles indulás során szükséges kiemelt támogatást takarja.

Az „élesbe állás” (63-as sor) a teljes projekt feladatcsoport a szoftver élesítéséhez szükséges „végső simítások” elvégzését, valamint az éles indítást jelenti. A „Szoftver pilot élesítés” és a „Szoftver élesbeállás” egy napra esése azt jelenti, hogy az első éles indulási napon nem az egész szervezet, csak egyes szervezeti egységek indulnak el, amelyeket (sikeres indulás esetén) egy-két munkanapon belül követ az összes szervezeti egység éles indulása. A 68-as sort tényleg inkább egy egy hetes időszaknak kell jelölni, nem egy 0 napos mérföldkőnek. A végátadás időpontja az, amikor az összes szervezeti egység élesben használja a rendszert.

------------------------------------------------------------------------------------

A pályázati dokumentáció 14. pontja szerint:

14. A szerződésre vonatkozó feltételek
A Pályázó a pályázatának aláírásával tudomásul veszi, és elfogadja különösen az alábbi szerződési feltételeket:

1. kérdés: Szerződést biztosító mellékkötelezettség kikötése (kötbér, jótállás)?

Mi az előírt kötbér mérték, és a jótállás?

2. kérdés: Az SZZRT. kiköti az elállási, valamint a rendes és rendkívüli felmondás jogát.

Szerződéskötés esetén miként fogalmazza meg és köti ki Pályázat kiíró az elállási és felmondási jogokat?

3. kérdés:

6. Az SZZRT. kiköti a szerzői jogi, publikálási és továbbfejlesztési lehetőségek szabályozását.
Szerződéskötés esetén miként fogalmazza meg és köti ki Pályázat kiíró a szerzői jogi, publikálási és továbbfejlesztési lehetőség szabályozását?

VÁLASZ: A nyilvános pályázati felhívásnak nem része a szerződéstervezet, a pályázat összeállítását végzők úgy határoztak, hogy csak azokat a főbb szempontokat, kritériumokat említik, illetve emelik ki a megkötendő szerződésből és egyúttal fogadtatják el a pályázókkal, melyek majdan a szerződésben hangsúlyos elemként kerülnek beépítésre. Az SzZrt. az ilyen módon kiírt pályázatok esetében a nyertes pályázóval közvetlenül, tárgyalásos úton egyeztet és állapodik meg ezekről a kérdésekről.

40. kérdés: Mi a rendszer elvárt rendelkezésre állása?

Válasz: A kiírás mellékletét képező szoftver követelményspecifikáció ÜZ/11. követelménye értelmében „Az elektronikus iratkezelő rendszernek képesnek kell lennie a 7x24 üzemelésre, ugyanakkor az elvárt rendelkezésre állás 5x10 óra (munkanapokon 07.00-17.00).”

41. kérdés: Az A/1 követelményhez kapcsolódóan jól értjük-e, hogy a bevezetendő rendszernek a 24/2006. BM-IHM-NKÖM együttes rendelet (a közfeladatot ellátó szerveknél alkalmazható iratkezelési szoftverekkel szemben támasztott követelményekről) szerint tanúsítottnak kell lennie?

Válasz: Igen, a rendszernek érvényes tanúsítvánnyal kell rendelkeznie a 24/2006. BM-IHM-NKÖM együttes rendeletben foglalt követelmények megfelelőségéről.

Pályázat benyújtásának határideje: 2013. szeptember 4. 8:30 óráig.

Eredményhirdetés: Várhatóan 2013. szeptember 30.

Letölthető dokumentumok

Ez a honlap sütiket használ. A sütik elfogadásával kényelmesebbé teheted a böngészést. A honlap további használatával hozzájárulsz a sütik használatához. További információkat a cookie-k használatáról a „Részletek” gombra kattintva tudhat meg.

Részletek