Υπουργείο Εσωτερικών

Δικτυακός Τόπος Διαβουλεύσεων

• 25 Σεπτεμβρίου 2017, 12:54 | COSMOS BUSINESS SYSTEMS SA

  Μόνιμος Σύνδεσμος

  4.1.1.1 Υποσύστημα Συλλογής – Ελέγχου Εγκυρότητας – Αποθήκευσης Δεδομένων – Αναφορών Παρακολούθησης Λειτουργίας

  Κατά τη διάρκεια της λειτουργίας της υπηρεσίας API θα πρέπει να υπάρχει η δυνατότητα προσαρμογής των δεδομένων API (προσθήκη ή αφαίρεση στοιχείων) κατά τις ανάγκες της Διεύθυνσης Προστασίας Συνόρων του Αρχηγείου Ελληνικής Αστυνομίας, χωρίς να απαιτηθεί επιπλέον κόστος υλοποίησης από τον Ανάδοχο.

  Η συγκεκριμένη απαίτηση είναι αόριστη και δεν μπορεί να διαστασιολογηθεί, ιδιίως για το μεγάλο χρονικό διάστημα που ζητείται να καλυφθεί (έως τις 31/12/2022). Προτείνουμε να προβλεφθεί συγκεκριμένος αριθμός ανθρωπομηνών υποστήριξης, οι οποίοι θα καταναλώνονται για θέματα βελτιώσεων ή τροποποιήσεων που μπορεί να απαιτηθούν, καθώς και για συμβουλευτικές υπηρεσίες.

  5.6 Χρονοδιάγραμμα φάσεων Έργου

  Βάση της εμπειρίας μας το προτεινόμενο χρονοδιάγραμμα δεν είναι εφικτό. Επίσης δε λαμβάνει τυχόν απαιτήσεις που θα χρειασθούν ανάπτυξη, καθώς και τα unit tests aυτών. Επισης στη Φάση Β της εγκατάστασης, δε λαμβάνεται υπόψη καθόλου ο χρόνος που θα απαιτηθεί για τη διασύνδεση, δοκιμές και επικύρωση των συναλλαγών με τις αεροπορικές εταιρείες. Επίσης δεν εμφανίζεται πουθενά η Φάση ενσωμάτωσης των δεδομένων (data integration) με τις τοπικές και απομακρυσμένες βάσεις. Κατόπιν των ανωτέρω προτείνουμε η διάρκεια των Φάσεων Β και Ε να γίνει 3 μήνες.

  7.1.2. ΣΥΝΤΗΡΗΣΗ ΣΥΣΤΗΜΑΤΟΣ API

  Απαιτήσεις 8,9,10

  Οι συγκεκριμένες απαιτήσεις είναι αόριστες και δεν μπορούν να διαστασιολογηθούν, ιδίως για το μεγάλο χρονικό διάστημα που ζητείται να καλυφθεί (έως τις 31/12/2022). Προτείνουμε να προβλεφθεί συγκεκριμένος αριθμός ανθρωπομηνών υποστήριξης, οι οποίοι θα καταναλώνονται για θέματα βελτιώσεων ή τροποποιήσεων που μπορεί να απαιτηθούν, καθώς και για συμβουλευτικές υπηρεσίες.

  ΠΙΝΑΚΕΣ ΣΥΜΜΟΡΦΩΣΗΣ

  9.2 Απαιτήσεις Συστήματος

  Απαιτήσεις 1.1, 1.2, 1.3, 1.4

  Οι συγκεκριμένες απαιτήσεις είναι αόριστες και δεν μπορούν να διαστασιολογηθούν, ιδίως για το μεγάλο χρονικό διάστημα που ζητείται να καλυφθεί (έως τις 31/12/2022). Προτείνουμε να προβλεφθεί συγκεκριμένος αριθμός ανθρωπομηνών υποστήριξης, οι οποίοι θα καταναλώνονται για θέματα βελτιώσεων ή τροποποιήσεων που μπορεί να απαιτηθούν, καθώς και για συμβουλευτικές υπηρεσίες.

  Παρακαλούμε όπως αφαιρεθεί η φράση «…. χωρίς να απαιτηθεί επιπλέον κόστος
  υλοποίησης από τον Ανάδοχο….» και να εγκατασταθεί «….μέσω των υπηρεσιών πρόσθετων αλλαγών/βελτιώσεων του έργου….»

  Απαίτηση 1.10

  Δεδομένου ότι η λύση που ζητείται χρησιμοποιεί έτοιμο λογισμικό επώνυμων κατασκευαστών των οποίων το κόστος συντήρησης είναι πολύ μεγαλύτερο , παρακαλούμε το ποσοστό να γίνει τουλάχιστο 40%.

  Απαιτήσεις 1.11, 1.12

  Καμία κατασκευάστρια εταιρεία εξοπλισμού και έτοιμου λογισμικού δε δεσμεύεται για συντήρηση επταετίας. Παρακαλούμε να γίνει μέγιστο 3 χρόνια.

  Απαιτήσεις 1.11, 1.12

  Η συγκεκριμένη απαίτηση είναι αόριστη. Η τεχνική επάρκεια της ομάδας έργου διασφαλίζεται από τα σχετικά ζητούμενα βιογραφικά της παραγράφου .Παρακαλούμε να απαλειφθεί η απαίτηση.

• 25 Σεπτεμβρίου 2017, 12:14 | ΟΤΕ

  Μόνιμος Σύνδεσμος

  Σελ. 10
  3.1 … περίπου 670 σημεία σε όλη την επικράτεια.
  Παρακαλούμε να επιβεβαιωθεί ότι συμπεριλαμβάνονται στα 670 σημεία οι αρμόδιες υπηρεσίες στα ελληνικά αεροδρόμια.

  Σελ 36
  5.6 Χρονοδιάγραμμα φάσεων Έργου Προτείνεται συνολικά οι φάσεις Α & Β να έχουν διάρκεια 3 μήνες (κάτι που δεν αλλάζει την συνολική διάρκεια του έργου ).

  Σελ 43
  Το σύνολο του ετησίου κόστους συντήρησης (προ ΦΠΑ), δε θα υπερβαίνει το 10%
  του συνολικού κόστους (προ ΦΠΑ) του παρόντος έργου.
  Δεδομένου ότι το κόστος συντήρησης κάποιων λογισμικών υποδομής βρίσκεται στην περιοχή 15-22% του κόστους κτήσης, το όριο θεωρείται περιοριστικό και προτείνεται να επαναξιολογηθεί ‘προς αύξηση’.

  Σελ. 13
  Στο Data Center της Διεύθυνσης Πληροφορικής του A.E.A. …
  Παρακαλούμε να προσδιοριστεί (κατ’ εκτίμηση) εάν υφίσταται επαρκής χώρος στα racks, για την φιλοξενία της υποδομής που θα υποστηρίξει τη λειτουργία των υποσυστημάτων.

  Σελ. 42
  η εργασιακή εμπειρία, … να μην είναι μικρότερη των πέντε (05) ετών, …
  θα αποδεικνύεται με βεβαιώσεις του εκάστοτε εργοδότη, με αναφορά στα έργα στα οποία έχει συμμετάσχει. Παρακαλούμε διευκρινίστε στην περίπτωση που η πρόσφατη ειδικά εμπειρία έχει αποκτηθεί σε ετέρους εργοδότες, εάν θα πρέπει να αναζητηθούν σε αυτούς ανάλογες βεβαιώσεις.

• 25 Σεπτεμβρίου 2017, 11:49 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 9.5, Σελίδα 65, Σημείο 3.1.13
  ———————————————————-
  Παρακαλούμε όπως συμπεριληφθεί η περιγραφή των τεχνικών χαρακτηριστικών της υφιστάμενης υποδομής ούτως ώστε να διασφαλιστεί η προσφορά εξοπλισμού και λογισμικού πλήρως συμβατού με αυτή.

• 25 Σεπτεμβρίου 2017, 11:29 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 2.3, Σελίδα 9
  ————————————-

  Στο σημείο «α) Υποσύστημα Συλλογής Στοιχείων Επιβατών» αναφέρεται πως το εν λόγω υποσύστημα «είναι υπεύθυνο να συλλέξει τα στοιχεία αυτά από κάθε αεροπορική εταιρία.»

  Προκειμένου να είναι εφικτή η συλλογή των απαιτούμενων στοιχείων από κάθε αεροπορική εταιρία, θα πρέπει να καθοριστούν τα πρωτόκολλα επικοινωνίας μεταξύ των πληροφοριακών συστημάτων της κάθε αεροπορικής εταιρίας και του Υποσυστήματος Συλλογής Στοιχείων Επιβατών, μέσω των οποίων θα μεταφέρονται τα μηνύματα UN/EDIFACT (PAXLST).

  Στην Παράγραφο 4 του Άρθρου 4 του Π.Δ. 53/2008 αναφέρονται τα εξής:

  …Με τη λήξη της διαδικασίας του ελέγχου των εισιτηρίων και πριν από την αναχώρηση του αεροσκάφους από χώρα εκτός Ευρωπαϊκής Ένωσης οι αερομεταφορείς διαβιβάζουν τα δεδομένα του άρθρου 3 παράγραφος 1 του παρόντος στην αρμόδια Υπηρεσία Ελέγχου Διαβατηρίων, η οποία είναι ο παραλήπτης των στοιχείων για κάθε σημείο διάβασης των συνόρων της χώρας. Τα εν λόγω δεδομένα διαβιβάζονται με ηλεκτρονική αλληλογραφία, κρυπτογραφημένη και υπογεγραμμένη με ψηφιακό πιστοποιητικό, στη διεύθυνση που αναγράφεται στο έγγραφο της πράξης για την υποβολή των στοιχείων της παραγράφου 1 α) του παρόντος άρθρου. Στο ίδιο έγγραφο θα αναγράφεται και αριθμός τηλεομοιοτυπίας στον οποίο θα διαβιβάζονται τα δεδομένα σε περίπτωση βλάβης του ανωτέρω συστήματος. Ως αποδεικτικό επιβεβαίωσης λήψης των δεδομένων από την αστυνομική αρχή θεωρείται η ηλεκτρονική επιβεβαίωση ανάγνωσης του μηνύματος.

  Αντίληψη της εταιρίας μας είναι πως τα πρωτόκολλα επικοινωνίας (πέραν της ηλεκτρονικής αλληλογραφίας) θα καθοριστούν από τον Ανάδοχο του έργου και θα βασίζονται σε διεθνή, ανοικτά πρότυπα διαλειτουργικότητας τα οποία ήδη χρησιμοποιούνται από την Ελληνική Αστυνομία, όπως για παράδειγμα SOAP Web Services.

  Παρακαλούμε όπως το πιο πάνω διευκρινιστεί στις τεχνικές προδιαγραφές.

• 25 Σεπτεμβρίου 2017, 11:01 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 4.1.1.1, Σελίδα 17
  ——————————————
  Στο σημείο 1 της παραγράφου αναφέρεται πως «Για την επίτευξη της συλλογής των μηνυμάτων API, το Σύστημα API που θα παρέχει ο Ανάδοχος θα διασυνδέεται με τα πληροφοριακά συστήματα των αερομεταφορέων ή με τρίτα συστήματα API τα οποία με τη σειρά τους διασυνδέονται με τα πληροφοριακά συστήματα των αερομεταφορέων.»

  Με βάση τις εμπειρίες από άλλα κράτη μέλη της Ε.Ε. που λαμβάνουν μηνύματα APIS αλλά και την έκθεση αξιολόγησης της Οδηγίας 2004/82 που εκπονήθηκε για λογαριασμό της Γενικής Διεύθυνσης Εσωτερικών Υποθέσεων (Directorate-General for Home Affairs) της Ευρωπαϊκής Επιτροπής, η διασύνδεση με τα πληροφοριακά συστήματα των αερομεταφορέων μπορεί να επιτευχθεί μέσω των ακόλουθων δύο τρόπων (βλ. κεφ. 6):

  Α) Χρήση ιδίας διεπαφής (own interface) για τη συλλογή των δεδομένων (π.χ. μέσω web services).

  Β) Χρήση εξειδικευμένων συστημάτων τα οποία προμηθεύονται από συγκεκριμένες εταιρίες (π.χ. SITA και ARINC).

  Με βάση την εν λόγω έκθεση (βλ. κεφ. 7), ο δεύτερος τρόπος επιβάλλει σαφώς αυξημένο κόστος στην υλοποίηση και λειτουργία ενός συστήματος APIS σε σχέση με την ανάπτυξη ιδίας διεπαφής (own interface). Ενδεικτικά αναφέρεται ως μηνιαίο κόστος λειτουργίας του μηχανισμού συλλογής τα €100,000 για σχετικά μικρό κράτος μέλος με περιορισμένη εναέρια κυκλοφορία.

  Σημειώστε ότι με τον δεύτερο τρόπο το κόστος συλλογής δεδομένων επιβαρύνει το κράτος, ενώ με την πρώτη επιλογή, η ευθύνη και το κόστος επιβαρύνει τους αερομεταφορείς.

  Από τα έγγραφα των τεχνικών προδιαγραφών, δεν προκύπτει ποιος από τους δύο τρόπους θα εφαρμοστεί στο συγκεκριμένο έργο.

  Δεδομένου πως η επιλογή του τρόπου συλλογής επηρεάζει τον προϋπολογισμό του έργου, παρακαλούμε όπως διευκρινιστεί με ποιο εκ των δύο προαναφερόμενων τρόπων αναμένεται να λαμβάνει τα μηνύματα το σύστημα APIS.

• 25 Σεπτεμβρίου 2017, 11:39 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 9.5, Σελίδα 64
  ————————————–

  Όπως αναφέρεται στο σημείο 1.1 του πίνακα συμμόρφωσης της Παραγράφου 9.5 (Σελίδα 64), ο Ανάδοχος πρέπει να προσφέρει έναν εξυπηρετητή για την ενίσχυση υφιστάμενης συστοιχίας υψηλής διαθεσιμότητας και κατανομής φόρτου ως προς τη λειτουργία της βάσης δεδομένων του NSIS II. Μαζί με τον εξυπηρετητή θα πρέπει να προσφερθεί λειτουργικό σύστημα και σχετική αδειοδότηση.

  Δεδομένου ότι ο πιο πάνω εξυπηρετητής θα ενταχθεί στην υφιστάμενη συστοιχία της βάσης δεδομένων του NSIS II, ο επεξεργαστής που θα προσφερθεί θα πρέπει να είναι του ίδιου τύπου / κατασκευαστή με τους υφιστάμενους επεξεργαστές, ενώ το λειτουργικό σύστημα θα πρέπει να είναι το ίδιο με το υφιστάμενο λειτουργικό σύστημα.

  Σε αντίθετη περίπτωση, ο εξυπηρετητής δεν θα μπορεί να ενταχθεί στην υφιστάμενη συστοιχία της βάσης δεδομένων του NSIS II.

  Επομένως, στο σημείο 3.1.1 θα πρέπει να καθοριστεί ο υφιστάμενος επεξεργαστής και στο σημείο 3.7.1 το λειτουργικό σύστημα το οποίο χρησιμοποιείται σήμερα.

• 25 Σεπτεμβρίου 2017, 11:19 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 4.2.3, Σελίδα 26
  —————————————–

  Στην Παράγραφο 8 (Σελίδα 50), αναφέρεται ότι η συντήρηση περιλαμβάνει και τις πιο κάτω περιπτώσεις:

  – Αλλαγής των προδιαγραφών των web services για τις αναζητήσεις στο SIS II, στην Interpol, στο VIS, σε Εθνικές και λοιπές Ευρωπαϊκές ή Διεθνείς Βάσεις Δεδομένων.

  – Τροποποιήσεων λόγω επιχειρησιακών αναγκών.

  Οι προσπάθεια που θα απαιτηθεί για τις πιο πάνω περιπτώσεις κατά την περίοδο ΠΕΣ δεν μπορεί να εκτιμηθεί από τους υποψήφιους Αναδόχους στο στάδιο των προσφορών, αφού δεν εξαρτάται από αυτούς. Γι’ αυτό το λόγο, εισηγούμαστε όπως καθοριστεί όριο, για παράδειγμα μέχρι πέντε (5) ανθρωποημέρες ανά έτος.

• 25 Σεπτεμβρίου 2017, 11:59 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 8, Σελίδα 50
  ————————————–
  Στην Παράγραφο 8 (Σελίδα 50), αναφέρεται ότι η τουλάχιστον δύο (2) εκπαιδευτές θα πρέπει να
  να είναι πιστοποιημένοι συνεργάτες-εκπαιδευτές των επιμέρους κατασκευαστών (vendors) εξοπλισμού και λογισμικού (Certified Learning Partners).

  Εισηγούμαστε όπως η πιο πάνω απαίτηση αφαιρεθεί αφού είναι ιδιαίτερα δύσκολη η εξεύρεση εκπαιδευτών που να είναι πιστοποιημένοι σε όλα τα επιμέρους συστατικά εξοπλισμού και λογισμικού της συγκεκριμένης λύσης. Σημειώστε ότι όσον αφορά τον εξοπλισμό και λογισμικό συστήματος, η απαίτηση αυτή σχετίζεται με ένα (1) εκπαιδευτικό πρόγραμμα (Διαχειριστές του Συστήματος ΑΡΙ από τη Διεύθυνση Πληροφορικής του Αρχηγείου της Ελληνικής Αστυνομίας), διάρκειας 16 ωρών.

  Εναλλακτικά, θα μπορούσε η πιο πάνω απαίτηση να μετατραπεί σε προαιρετική και να δοθεί επιπρόσθετη βαθμολογία στην τεχνική αξιολόγηση.

• 25 Σεπτεμβρίου 2017, 11:15 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 7.1, Σελίδα 43
  ————————————–
  Στην Παράγραφο 7.1, αναφέρεται ότι η Περίοδος Εγγύησης και Συντήρησης (ΠΕΣ) ορίζεται η περίοδος, με έναρξη την οριστική παραλαβή του έργου έως τουλάχιστον και την 31/12/2024.

  Λόγω του ότι η ημερομηνία υπογραφής της σύμβασης και κατ’ επέκταση η ημερομηνία οριστικής παραλαβής του έργου δεν μπορεί να είναι γνωστή σε αυτό το στάδιο, δεν είναι δυνατό να υπολογιστεί ο αριθμός των ετών της ΠΕΣ έτσι ώστε να γίνει η απαιτούμενη κοστολόγηση.

  Γι’ αυτό το λόγο, η ΠΕΣ θα πρέπει να οριστεί σε αριθμό ετών.

• 25 Σεπτεμβρίου 2017, 11:50 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 5.6, Σελίδα 36
  ————————————–
  Ενώ η διάρκεια που έχει καθοριστεί για τις Φάσεις Ανάλυσης Απαιτήσεων (Φάση Α) και Υπηρεσίες Δοκιμών (Φάση Γ) είναι επαρκής, ο ένας (1) μήνας που έχει καθοριστεί για την εκτέλεσης της Φάσης Β (Εγκατάσταση και Παραμετροποίηση Συστήματος API) είναι περιορισμένος, με κίνδυνο, τον επηρεασμό της ποιότητας του συστήματος που θα υλοποιηθεί λόγω του χρονικού περιορισμού.

  Εισηγούμαστε όπως η διάρκεια της Φάσης Β αυξηθεί σε τουλάχιστο δύο (2) μήνες έτσι ώστε να διασφαλιστεί η επιτυχής ολοκλήρωση της εγκατάστασης και παραμετροποίηση του συστήματος. Σε περίπτωση που ο συνολικός χρόνος υλοποίησης του έργου δεν μπορεί να υπερβαίνει τους έξι (6) μήνες, θα μπορούσε να μειωθεί η διάρκεια της Φάσης Ε (Πιλοτική Λειτουργία).

• 25 Σεπτεμβρίου 2017, 11:08 | Kyriakos Savvides

  Μόνιμος Σύνδεσμος

  Παράγραφος 4.3, Σελίδα 28
  ————————————–
  Στην Παράγραφο 4.3 (σελίδα 28) αναφέρεται ότι ο υποψήφιος Ανάδοχος θα πρέπει να καταθέσει μαζί με την προσφορά του «καθορισμό σεναρίων ελέγχου λειτουργίας του Συστήματος API».

  Στην παράγραφο 5.1 (σελίδα 30) αναφέρεται ότι τα σενάρια ελέγχου λειτουργίας του Συστήματος API αποτελούν παραδοτέα / αποτελέσματα της Φάσης Α (Ανάλυση Απαιτήσεων).

  Εισηγούμαστε όπως η απαίτηση για κατάθεση μαζί με την προσφορά των σεναρίων ελέγχου λειτουργίας του Συστήματος API αφαιρεθεί.

• 25 Σεπτεμβρίου 2017, 11:10 | Κυριάκος Σαββίδης

  Μόνιμος Σύνδεσμος

  Παράγραφος 8, Σελίδα 49
  ————————————
  Στην παράγραφο 8 (Σελίδα 49) αναφέρεται:

  «Απαραίτητη προϋπόθεση για την κατάθεση προσφοράς από τον Ανάδοχο, είναι η πρότερη εμπειρία, του τελευταίου ή της/των εταιρείας/ειών που συμμετέχουν στο σχήμα του υποψηφίου Αναδόχου, στην επιτυχή υλοποίηση και απρόσκοπτη λειτουργία για τουλάχιστον 3 (τρία) έτη, παρεμφερών έργων για Αρχές επιβολής του Νόμου, στην Ελλάδα ή στο εξωτερικό, στο πλαίσιο των οποίων προσφέρθηκαν υπηρεσίες API. Ειδικότερα, για τις προσφερόμενες υπηρεσίες API, θα πρέπει ο υποψήφιος Ανάδοχος να αποδείξει ότι, διαχειρίστηκε με επιτυχία, όγκο ταξιδιωτικής κίνησης, ανάλογο με αυτόν, που προβλέπεται για τη Χώρα μας, σύμφωνα με την εκτίμηση του κεφ. 2.3 του παρόντος τεύχους. Θα πρέπει ο υποψήφιος να προσκομίσει προς απόδειξη της ανωτέρω απαίτησης, πιστοποιητικά που έχουν εκδοθεί ή θεωρηθεί από την αρμόδια αρχή.»

  Θεωρούμε ότι η πιο πάνω προϋπόθεση είναι περιοριστική.

  Θα θέλαμε να σημειώσουμε ότι εξίσου σημαντικό μέρος του έργου πέραν από τη συλλογή των δεδομένων API, είναι και οι προέλεγχοι / αναζητήσεις στις βάσης δεδομένων Σένγκεν, Interpol και E.K.AN.A, οι οποίες, όπως αναφέρεται στις τεχνικές προδιαγραφές εξυπηρετούνται από το Εθνικό Σύστημα Πληροφοριών Schengen Δεύτερης Γενεάς.

  Εισηγούμαστε επομένως όπως επιτραπεί η συμμετοχή και σε υποψήφιους Αναδόχους οι οποίοι έχουν υλοποιήσει ανάλογης πολυπλοκότητας και μεγέθους έργα σε σχετικούς τομείς όπως συνοριακοί έλεγχοι, ασφάλεια αεροδρομίων, συνθήκη του Σενγκεν, κλπ.

  Θεωρούμε ότι η πιο πάνω τροποποίηση δεν μειώνει τη δυνατότητα του Ανάδοχου να εκτελέσει με επιτυχία τη σύμβαση.

• 25 Σεπτεμβρίου 2017, 11:59 | Γιάννης Πουρναράς

  Μόνιμος Σύνδεσμος

  4.1.1.1 Υποσύστημα Συλλογής – Ελέγχου Εγκυρότητας – Αποθήκευσης Δεδομένων – Αναφορών Παρακολούθησης Λειτουργίας

  1) «Κατά τη διάρκεια της λειτουργίας της υπηρεσίας API θα πρέπει να υπάρχει η δυνατότητα προσαρμογής των δεδομένων API (προσθήκη ή αφαίρεση στοιχείων) κατά τις ανάγκες της Διεύθυνσης Προστασίας Συνόρων του Αρχηγείου Ελληνικής Αστυνομίας, χωρίς να απαιτηθεί επιπλέον κόστος υλοποίησης από τον Ανάδοχο.»

  Η συγκεκριμένη απαίτηση είναι αόριστη και δεν μπορεί να διαστασιολογηθεί, ιδίως για το μεγάλο χρονικό διάστημα που ζητείται να καλυφθεί (έως τις 31/12/2022). Προτείνουμε να προβλεφθεί συγκεκριμένος αριθμός ανθρωπομηνών υποστήριξης, οι οποίοι θα καταναλώνονται όποτε ζητούνται βελτιώσεις, τροποποιήσεις ή αλλαγες, καθώς και για επιπρόσθετες συμβουλευτικές υπηρεσίες, εκπαίδευση κλπ.

  2) «Το Σύστημα API, σε όλες τις επιμέρους του λειτουργίες από τη συλλογή των δεδομένων API από τους αερομεταφορείς, έως και την καταχώρησή τους στην Εθνική Βάση Δεδομένων API θα πρέπει να είναι διαθέσιμο και λειτουργικό όλες τις ώρες της ημερολογιακές ημέρες, καθ’ όλη τη διάρκεια του έτους. Η ανάγκη για την υψηλή διαθεσιμότητα της υπηρεσίας API επιβάλλεται από την ανάγκη άσκησης προελέγχου επιβατών για πτήσεις όλες τις ώρες της ημέρας, καθ’ όλη τη διάρκεια του χρόνου.»

  Θα πρέπει να είναι ξεκάθαρο ότι η υποχρέωση αυτή ισχύει από τη στιγμή που θα γίνει λήψη των API δεδομένων. Δεν μπορεί να υπάρχει έλεγχος πόσος χρόνος απαιτείται από τους αερομεταφορείς να στείλουν τα δεδομένα στη βάση του API.

  5.6 Χρονοδιάγραμμα φάσεων Έργου

  3) Βάση της εμπειρίας μας το προτεινόμενο χρονοδιάγραμμα δεν είναι εφικτό. Επίσης δε λαμβάνει τυχόν απαιτήσεις που θα χρειασθούν ανάπτυξη, καθώς και τα unit tests aυτών. Επίσης στη Φάση Β της εγκατάστασης, δε λαμβάνεται υπόψη καθόλου ο χρόνος που θα απαιτηθεί για τη διασύνδεση, δοκιμές και επικύρωση των συναλλαγών με τις αεροπορικές εταιρείες. Επίσης δεν εμφανίζεται πουθενά η Φάση ενσωμάτωσης των δεδομένων (data integration) με τις τοπικές και απομακρυσμένες βάσεις. Κατόπιν των ανωτέρω προτείνουμε η διάρκεια των Φάσεων Β και Ε να γίνουν από 3 μήνες η καθεμία.

  7.1.2. ΣΥΝΤΗΡΗΣΗ ΣΥΣΤΗΜΑΤΟΣ API

  4) Απαιτήσεις 8,9,10

  Οι συγκεκριμένες απαιτήσεις είναι αόριστες και δεν μπορούν να διαστασιολογηθούν, ιδίως για το μεγάλο χρονικό διάστημα που ζητείται να καλυφθεί (έως τις 31/12/2022). Προτείνουμε να προβλεφθεί συγκεκριμένος αριθμός ανθρωπομηνών υποστήριξης, οι οποίοι θα καταναλώνονται για θέματα βελτιώσεων, τροποποιήσεων και αλλαγών που μπορεί να απαιτηθούν, καθώς και για παροχή συμβουλευτικών υπηρεσιών, εκπαίδευσης κλπ.

  5) 8 Ειδικές απαιτήσεις

  Τουλάχιστον δύο (02) εκπαιδευτές οι οποίοι θα πρέπει να έχουν τουλάχιστον τριετή (3ετή) επαγγελματική εμπειρία στην εκπαίδευση και να είναι πιστοποιημένοι συνεργάτες-εκπαιδευτές των επιμέρους κατασκευαστών (vendors) εξοπλισμού και λογισμικού (Certified Learning Partners).

  Η συγκεκριμένη ορολογία δεν υιοθετείται από όλους τους κατασκευαστές. Επίσης το συγκεκριμένο έργο αφορά την υλοποίηση ενός customized συστήματος , πάνω στο οποίο θα γίνει και η εκπαίδευση. Παρακαλούμε όπως αφαιρεθεί η συγκεκριμένη παράγραφος

  9. ΠΙΝΑΚΕΣ ΣΥΜΜΟΡΦΩΣΗΣ

  9.1 Απαιτήσεις Συστήματος

  6) 2.1.5 Οι αεροπορικές εταιρείες αποστέλλουν συνήθως 1 set ΑΡΙ δεδομένων. Κρίνουμε ότι η απαίτηση αυτή μπορεί να απαλειφθεί.

  7) 2.1.7 Το Σύστημα API θα πραγματοποιεί μετασχηματισμό των δεδομένων API σε κανονικοποιημένη μορφή.

  Προτείνουμε να αναφερθεί το XML ως παράδειγμα που είναι και το πλέον σύνηθες.

  8) 2.1.8 Θα πρέπει να είναι ξεκάθαρο ότι η υποχρέωση αυτή ισχύει από τη στιγμή που θα γίνει λήψη των API δεδομένων. Δεν μπορεί να υπάρχει έλεγχος πόσος χρόνος απαιτείται από τους αερομεταφορείς να στείλουν τα δεδομένα στη βάση του API.

  Προτείνουμε να διαμορφωθεί ως: «Το συνολικό χρονικό διάστημα από τη στιγμή που τα δεδομένα API φτάνουν στο υποσύστημα συλλογής δεδομένων από τους ορισμένους αερομεταφορείς…….»

  9) Βάση της εμπειρίας μας και των πρότερων εγκαταστάσεων και λειτουργίας του συστήματος API, προτείνουμε την εισαγωγή των κάτωθι επιπρόσθετων απαιτήσεων:

  2.1.12 Αυτόματη ανίχνευση σφαλμάτων καθυστερημένων μηνυμάτων και μηνυμάτων κακής ποιότητας. Το σύστημα θα πρέπει να προειδοποιεί εάν τα δεδομένα δεν έχουν φτάσει στον απαιτούμενο χρόνο, για να επιτρέψουν την εκτίμηση κινδύνου πριν από την άφιξη του αεροσκάφους. Ο έλεγχος εγκυρότητας πρέπει επίσης να περιλαμβάνει τους λόγους για τους οποίους ένα μήνυμα δεν είναι έγκυρο.

  2.1.13 Ολοκληρωμένο σύστημα διαχείρισης υποθέσεων (case management) που να επιτρέπει την ανίχνευση των υποθέσεων από το έναρξη έως το τέλος των ειδοποιήσεων που εγείρονται στο κέντρο στόχευσης.

  Όταν εμφανίζεται ένα ύποπτο άτομο για έλεγχο, είναι σημαντικό μόνο ένας αναλυτής του κέντρου στόχευσης να χρεώνεται και να διερευνά την υπόθεση. Ο αναλυτής θα πρέπει να γνωρίζει ακριβώς τι συμβαίνει με το συγκεκριμένο περιστατικό, ότι ο σωστός οργανισμός έχει ειδοποιηθεί με επαρκείς πληροφορίες για να ενεργήσει, ώστε να μπορέσει ο οργανισμός να απαντήσεις, κλείνοντας την υπόθεση. Με τον τρόπο αυτό υπάρχει άμεση ενημέρωση για την παροχή ανατροφοδότησης καθώς και το στάδιο που βρίσκονται οι εκκρεμείς υποθέσεις. Θα πρέπει να υπάρχει δυνατότητα οι προηγούμενες υποθέσεις να αναζητούνται με βάση το όνομα και τον αριθμό πτήσης.

  2.1.14 Να υπάρχει γραφική ένδειξη για οποιεσδήποτε αλλαγές στην εκτίμηση κινδύνου λόγω αλλαγών στα δεδομένα API.

  Αν υπάρχουν πολλαπλές αποστολές δεδομένων API, θα πρέπει να ενοποιούνται σε ένα και κάθε ένα sετ αποστολής να μπορεί να προβληθεί χωριστά και να υπάρχει χρωματική αλλαγή των διαφορών τους.

  2.1.15 Τα εισερχόμενα μηνύματα EDIFACT να μπορούν να μετατραπούν σε ένα τυπικό έγγραφο XML για περαιτέρω ανάλυση

  2.1.16 Να υπάρχει δυνατότητα να γίνονται αποδεκτές και να αναλύονται από το σύστημα θαλάσσιες μετακινήσεις σε μορφή UN EDIFACT PAXLST.

  2.1.17 Το γραφικό περιβάλλον του συστήματος (GUI) θα πρέπει να είναι προσβάσιμο από σταθερά και κινητά τερματικά (smartphones, tablets).

  2.1.18 Το γραφικό περιβάλλον θα πρέπει να επιτρέπει στον αναλυτή να έχει πλήρη εικόνα των αξιολογήσεων κινδύνου επιβατών για κάθε αεροσκάφος. Το γραφικό περιβάλλον θα πρέπει να εμφανίζει ένα σχέδιο καθισμάτων του κάθε αεροσκάφους, επισημαίνοντας εκείνες τις θέσεις που κρατήθηκαν από τους επιβάτες που είχαν υψηλή, μεσαία και χαμηλή ένδειξη ρίσκου. Η τοποθέτηση πάνω από το κάθισμα θα πρέπει να εμφανίζει λεπτομέρειες του κάθε επιβάτη, καθώς και τις αιτίες επισήμανσής του.

  2.1.19 Δυνατότητα μελλοντικής ενσωμάτωσης των δεδομένων PNR για την έγκαιρη προειδοποίηση των κινήσεων επικίνδυνων ταξιδιωτών. Η συλλογή δεδομένων και το σύστημα αναλυτών θα πρέπει επίσης να είναι σε θέση να συλλέγουν και να επεξεργάζονται προαιρετικά δεδομένα PNR σε μορφές EDIFACT PNRGOV, να μετασχηματίζουν τα δεδομένα και να τα συγχωνεύουν σε ένα όταν γίνεται λήψη δεδομένων PNR.

  9.2 Απαιτήσεις Συστήματος

  9) Απαιτήσεις 1.1, 1.2, 1.3, 1.4

  Οι συγκεκριμένες απαιτήσεις είναι αόριστες και δεν μπορούν να διαστασιολογηθούν, ιδίως για το μεγάλο χρονικό διάστημα που ζητείται να καλυφθεί (έως τις 31/12/2022). Προτείνουμε να προβλεφθεί συγκεκριμένος αριθμός ανθρωπομηνών υποστήριξης, οι οποίοι θα καταναλώνονται για θέματα βελτιώσεων ή τροποποιήσεων που μπορεί να απαιτηθούν, καθώς και για συμβουλευτικές υπηρεσίες.

  Παρακαλούμε όπως αφαιρεθεί η φράση «…. χωρίς να απαιτηθεί επιπλέον κόστος υλοποίησης από τον Ανάδοχο….» και να εγκατασταθεί «….μέσω των υπηρεσιών πρόσθετων αλλαγών/βελτιώσεων του έργου….»

  10) Απαίτηση 1.10

  Δεδομένου ότι η λύση που ζητείται χρησιμοποιεί έτοιμο λογισμικό επώνυμων κατασκευαστών των οποίων το κόστος συντήρησης είναι πολύ μεγαλύτερο , παρακαλούμε το ποσοστό να γίνει τουλάχιστο 20%.

  11) Απαιτήσεις 1.11, 1.12

  Καμία κατασκευάστρια εταιρεία εξοπλισμού και έτοιμου λογισμικού δε δεσμεύεται για συντήρηση επταετίας. Παρακαλούμε να γίνει μέγιστο τέσσερα (4) χρόνια.

  12) Απαιτήσεις 1.11, 1.12

  Η συγκεκριμένη απαίτηση είναι αόριστη. Η τεχνική επάρκεια της ομάδας έργου διασφαλίζεται από τα σχετικά ζητούμενα βιογραφικά της παραγράφου .Παρακαλούμε να απαλειφθεί η απαίτηση.

  13) Απαιτήσεις 2.1, 2.2

  Εκτιμούμε ότι οι υπηρεσίες εκπαίδευσης θα πρέπει να κοστολογηθούν ξεχωριστά στην οικονομική προσφορά , ώστε να υπάρχει δυνατότητα επιπρόσθετης εκπαίδευσης εάν απαιτηθεί ΄λόγω νέου προσωπικού, μετακινήσεων κλπ.

• 25 Σεπτεμβρίου 2017, 11:17 | SPACE HELLAS S.A.

  Μόνιμος Σύνδεσμος

  1. Στην παράγραφο 8. Ειδικές απαιτήσεις ζητείται απαραιτήτως η πρότερη
  εμπειρία του Υποψήφιου Αναδόχου ή της / των εταιρείας / ειδών που
  συμμετέχουν στο σχήμα του υποψηφίου Αναδόχου στην επιτυχή υλοποίηση και
  απρόσκοπτη λειτουργία για τουλάχιστον τρία (3) έτη, παρεμφερών έργων για
  Αρχές επιβολής Νόμου στην Ελλάδα ή τον εξωτερικό, στο πλαίσιο των οποίων
  προσφέρθηκαν υπηρεσίες API. Ειδικότερα για τις προσφερόμενες υπηρεσίες
  API, θα πρέπει ο υποψήφιος Ανάδοχος να αποδείξει ότι διαχειρίστηκε με
  επιτυχία, όγκο ταξιδιωτικής κίνησης, ανάλογο με αυτόν, που προβλέπεται
  για την Χώρα μας, σύμφωνα με την εκτίμηση του κεφ. 2.3 του παρόντος
  τεύχους. Θα πρέπει ο υποψήφιος να προσκομίσει προς απόδειξη της ανωτέρω
  απαίτησης πιστοποιητικά που έχουν εκδοθεί ή θεωρηθεί από την αρμόδια
  αρχή.
  Επειδή η έννοια της υπηρεσίας API είναι σχετικά καινούργια στους κόλπους
  της ΕΕ, πόσο μάλλον στην Ελλάδα, και μόνο λίγες χώρες έχουν υλοποιήσει
  ένα τέτοιο σύστημα, προτείνεται στο τελικό τεύχος της διακήρυξης η
  απαίτηση σε ότι αφορά την πρότερη εμπειρία του Υποψηφίου Αναδόχου να
  αντικατασταθεί με κάτι πιο γενικό, όπως είναι π.χ. η παροχή υπηρεσιών
  σχετικών με τη διεξαγωγή ελέγχων στα εξωτερικά σύνορα με τη χρήση
  εθνικών και διεθνών βάσεων δεδομένων. Για παράδειγμα, μία προτεινόμενη
  διατύπωση για το θέμα της πρότερης εμπειρίας και ικανότητας των
  Υποψηφίων Αναδόχων θα μπορούσε να είναι η ακόλουθη:
  Να έχει ολοκληρώσει επιτυχώς κατά τα τελευταία πέντε (5) έτη,
  τουλάχιστον ένα (1) έργο με αντικείμενο την προμήθεια/εφαρμογή/συντήρηση
  συστημάτων συνοριακού ελέγχου με τη χρήση εθνικών και διεθνών βάσεων
  δεδομένων.

  2. Στη σελίδα 34 στην παράγραφο 5.4 Φάση Δ: Εκπαίδευση αναφέρεται:
  «ΑΝΤΙΚΕΙΜΕΝΟ / ΠΕΡΙΕΧΟΜΕΝΟ ΦΑΣΗΣ: Στην φάση αυτή θα παρασχεθούν οι
  υπηρεσίες Εκπαίδευσης στους Χρήστες της Υπηρεσίας. Η έναρξη της
  Εκπαίδευσης προϋποθέτει την ολοκλήρωση της Φάσης των Δοκιμών.».
  Αντίθετα, στην σελίδα 37 της παραγράφου 5.6 Χρονοδιάγραμμα Φάσεων Έργου,
  αναφέρεται: «Η φάση Φ-Δ, ξεκινά τρεις (3) μήνες μετά την υπογραφή της
  σύμβασης και θα ολοκληρωθεί σε χρονικό διάστημα επτά (7) ημερολογιακών
  ημερών από την έναρξή της. Επισημαίνεται ότι, η υπόψη Φάση θα
  υλοποιείται ταυτόχρονα με τη Φάση Γ.».
  Παρακαλούμε όπως διευκρινιστεί στο τελικό τεύχος της διακήρυξης εάν
  τελικά η έναρξη της Φάσης Δ προϋποθέτει την ολοκλήρωση της Φάσης Γ των
  Δοκιμών ή εάν θα υλοποιείται ταυτόχρονα με αυτή.

  3. Το χρονοδιάγραμμα υλοποίησης έχει οριστεί σε μόλις έξι (6) μήνες, εκ των
  οποίων μόλις ένας (1) μήνας για την εγκατάσταση και παραμετροποίηση του
  συστήματος, χρονικό διάστημα που κρίνεται εξαιρετικά μικρό για την
  ανάπτυξη ενός τέτοιου συστήματος και τη διασύνδεση του με εθνικές και
  διεθνείς βάσεις δεδομένων. Προτείνεται η επέκταση του χρονοδιαγράμματος
  για τουλάχιστον 6 μήνες ακόμα, δηλαδή το συνολικό χρονοδιάγραμμα του
  έργου να οριστεί στους 12 μήνες.

  4. Στη σελίδα 37 της παραγράφου 5.6 Χρονοδιάγραμμα Φάσεων Έργου αναφέρεται
  ότι η εκκίνηση των εργασιών της Φάσης Β: Εγκατάσταση και Παραμετροποίηση
  Συστήματος API δεν προϋποθέτει την ολοκλήρωση της Φάσης Α: Ανάλυση
  Απαιτήσεων Έργου, γεγονός που εγκυμονεί πολλούς κινδύνους, καθώς εάν δεν
  έχει ολοκληρωθεί η Φάση Α ενώ έχει ήδη ξεκινήσει η υλοποίηση της Φάσης
  Β, τότε υπάρχει σοβαρό ενδεχόμενο να αρχίσει να υλοποιείται ένα σύστημα,
  το οποίο θα χρειαστεί να τροποποιηθεί άμεσα λόγω αλλαγών που μπορεί να
  προκύψουν στο τέλος της ανάλυσης των απαιτήσεων. Προτείνεται η έναρξη
  της Φάσης Β να προϋποθέτει την ολοκλήρωση της Φάσης Α.

  5. Στην σελίδα 37 στην παράγραφο 5.6 Χρονοδιάγραμμα Φάσεων Έργου
  αναφέρεται: «Η φάση Φ-Δ, ξεκινά τρεις (3) μήνες μετά την υπογραφή της
  σύμβασης και θα ολοκληρωθεί σε χρονικό διάστημα επτά (7) ημερολογιακών
  ημερών από την έναρξή της. Επισημαίνεται ότι, η υπόψη Φάση θα
  υλοποιείται ταυτόχρονα με τη Φάση Γ.».
  Δεδομένου του μεγάλου αριθμού των εκπαιδευομένων (67 συνολικά ατόμων, εκ
  των οποίων 4 διαχειριστές, 3 επιτελικοί χειριστές και 60 επιχειρησιακοί
  χειριστές), της διάρκειας εκπαίδευσης που έχει καθοριστεί στις 16 ώρες
  για κάθε κατηγορία εκπαιδευόμενων, του μέγιστου αριθμού ωρών εκπαίδευσης
  ανά ημέρα (8 ώρες), καθώς και του ότι ένας λογικός μέγιστος αριθμός
  ομάδας εκπαιδευόμενων δε θα πρέπει να ξεπερνά τα 15 άτομα, εκτιμούμε ότι
  το χρονικό διάστημα των επτά (7) ημερολογιακών ημερών δεν επαρκεί για να
  καλύψει το πρόγραμμα της εκπαίδευσης. Προτείνεται να επεκταθεί το
  συνολικό χρονικό διάστημα ημερών εκπαίδευσης σε 22 εργάσιμες ημέρες,
  ήτοι έναν (1) ημερολογιακό μήνα.

  6. Στην σελίδα 50 της παράγραφο 8. Ειδικές απαιτήσεις αναφέρεται:
  «Τουλάχιστον δύο (02) εκπαιδευτές οι οποίοι θα πρέπει να έχουν
  τουλάχιστον τριετή (3ετή) επαγγελματική εμπειρία στην εκπαίδευση και να
  είναι πιστοποιημένη συνεργάτες – εκπαιδευτές των επιμέρους κατασκευαστών
  (vendors) εξοπλισμού και λογισμικού (Certified Learning Partners).
  Δεδομένου ότι τα αντικείμενα εκπαίδευσης, όπως περιγράφονται στην
  παράγραφο 4.2.5, περιλαμβάνουν τη χρήση και διαχείριση της νέας
  εφαρμογής API, η οποία δεν αποτελεί COTS προϊόν (έτοιμο από το ράφι)
  αλλά μία custom εφαρμογή, παρακαλούμε όπως αφαιρεθεί η εν λόγω απαίτηση.
  Αντίθετα, σε περίπτωση που πράγματι απαιτείται εκπαίδευση διαχειριστών
  στον προσφερόμενο εξοπλισμό κι έτοιμο/συστημικό λογισμικό, παρακαλούμε
  όπως αναφερθούν σαφώς τα σχετικά αντικείμενα εκπαίδευσης στο τελικό
  τεύχος της διακήρυξης, έτσι ώστε να μπορούν να βρεθούν κι οι αντίστοιχοι
  πιστοποιημένοι συνεργάτες – εκπαιδευτές των επιμέρους κατασκευαστών
  (vendors) εξοπλισμού και λογισμικού (Certified Learning Partners).

  7. Στη σελίδα 47 της παραγράφου 7.2.1 Τήρηση Εγγυημένου Επιπέδου Υπηρεσιών
  αναφέρεται ότι «ο μέγιστος ανεκτός χρόνος αποκατάστασης της λειτουργίας
  του συστήματος είναι το μέγιστο επιτρεπόμενο χρονικό διάστημα από την
  αναγγελία βλάβης μέχρι και τη διόρθωσή της. Ο χρόνος αυτός ορίζεται σε
  μισή (1/2) ώρα από τη στιγμή της ανακοίνωσης της εμφάνισης της βλάβης/
  δυσλειτουργίας, είτε αφορά σφάλμα εξοπλισμού, είτε γενικότερο σφάλμα του
  Συστήματος API.».
  Επειδή πρόκειται για ένα εξαιρετικά αυστηρό SLA, το οποίο δύσκολα
  καλύπτεται εάν δεν υπάρχει επιτόπια παρουσία προσωπικού του Αναδόχου
  στις εγκαταστάσεις της Υπηρεσίας σας, παρακαλούμε όπως απαιτηθεί από
  τους Υποψηφίους Αναδόχους να συμπεριλάβουν ρητώς στην προσφορά τους τη
  σχετική υπηρεσία επιτόπιας υποστήριξης, η οποία και θα πρέπει να
  υπολογισθεί ως κομμάτι του διαθέσιμου προϋπολογισμού του έργου.

  8. Αναφέρεται στη σελίδα 6 της παραγράφου 2.2 Περιγραφή Φυσικού
  Αντικειμένου – Επιχειρησιακές Διαδικασίες, ότι σε περίπτωση που δεν
  ληφθεί κάποιο αρχείο από μία αεροπορική εταιρεία θα πρέπει να το
  γνωρίζει η εφαρμογή, ώστε να ενημερώνεται ο υπεύθυνος αστυνομικός στο
  αεροδρόμιο και να ξεκινήσει η διαδικασία επιβολής ποινών στην αεροπορική
  εταιρεία. Για να είναι αυτό εφικτό, δε θα πρέπει ο Ανάδοχος με κάποιο
  τρόπο να λαμβάνει γνώση για όλες τις πτήσεις που αφορούν το αεροδρόμια τ
  της Ελλάδος, ώστε να κάνει έναν έλεγχο με τα στοιχεία των επιβατών των
  πτήσεων που λαμβάνονται από το σύστημα; Ποια είναι η διαδικασία
  ενημέρωσης του Αναδόχου για τα στοιχεία αυτά;