Ένα από τα πιο δύσκολα διλήμματα που αντιμετωπίζουν σήμερα οι δημόσιες διοικήσεις στην ψηφιακή τους μετάβαση είναι απλό στη διατύπωση αλλά περίπλοκο στην πράξη: να αναπτύξουν οι ίδιες μια λύση προσαρμοσμένη στις ανάγκες τους ή να δοκιμάσουν ένα έτοιμο προϊόν που υπάρχει ήδη στην αγορά; Το ερώτημα αυτό βρέθηκε στο επίκεντρο συζήτησης που διοργανώθηκε τον Ιούλιο στο πλαίσιο του GovTech4All Café, με ομιλήτρια την Irene Chausse, Senior Product Manager στην Gobe Studio.

Γιατί το «build vs buy» δεν έχει μία απάντηση

Στον κόσμο των startups η λογική είναι σχετικά ξεκάθαρη: φτιάξε μόνος σου ό,τι αποτελεί τον πυρήνα της δουλειάς σου και αγόρασε όλα τα υπόλοιπα. Στον δημόσιο τομέα, όμως, τα πράγματα είναι πιο περίπλοκα, καθώς οι διοικήσεις λειτουργούν μέσα σε ένα πλαίσιο αυστηρών κανόνων προμηθειών, φόβου εγκλωβισμού σε συγκεκριμένο προμηθευτή και, πολλές φορές, πικρών εμπειριών από συμβάσεις που δεν απέδωσαν τα αναμενόμενα. Δεν υπάρχει, εξάλλου, ούτε παγκόσμια συναίνεση: ο Καναδάς ακολουθεί πολιτική «αγοράς πρώτα», ενώ το Ηνωμένο Βασίλειο προτιμά την εσωτερική ανάπτυξη βασικών πλατφορμών και την αγορά μόνο των περιφερειακών λειτουργιών.

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

Το λάθος του «μονόλιθου»

Ένα από τα συχνότερα λάθη είναι η αντιμετώπιση ενός έργου σαν μία ενιαία, αδιαίρετη απόφαση —για παράδειγμα, «να φτιάξουμε ή να αγοράσουμε μια πλατφόρμα επιδοτήσεων;». Στην πραγματικότητα, καμία μεγάλη κυβερνητική πλατφόρμα δεν είναι ένα ενιαίο σύστημα, αλλά ένα σύνολο επιμέρους στοιχείων: σύστημα σύνδεσης χρηστών, αποθήκευση εγγράφων, ειδοποιήσεις, φόρμες, αναφορές, ροές έγκρισης.

Η αντιμετώπιση του έργου ως ενιαίου συνόλου οδηγεί σε δύο τυπικά σφάλματα:

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

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

Ένα φάσμα, όχι μια δυαδική επιλογή

Αντί για ένα δυαδικό ερώτημα «build ή buy», προτείνεται να φανταστούμε ένα φάσμα:

  • Στο ένα άκρο βρίσκονται οι πραγματικά νέες ή πολύ εξειδικευμένες ανάγκες, για τις οποίες δεν υπάρχει έτοιμο προϊόν στην αγορά (build).
  • Στο άλλο άκρο βρίσκονται τα καθαρά εμπορεύματα, που λειτουργούν παντού με τον ίδιο τρόπο, όπως το email ή η φιλοξενία σε cloud (buy/reuse).
  • Στη μέση βρίσκονται προϊόντα που υπάρχουν ήδη αλλά χρειάζονται παραμετροποίηση.

Ένα σημαντικό στοιχείο είναι ότι η τεχνολογία μετατοπίζεται σταδιακά προς τα δεξιά με την πάροδο του χρόνου: αυτό που ήταν εξειδικευμένο πριν από πέντε χρόνια μπορεί σήμερα να είναι εμπόρευμα. Για τον λόγο αυτό, οι αποφάσεις πρέπει να επανεξετάζονται τακτικά, ώστε να μη διατηρείται παρωχημένος, προσαρμοσμένος κώδικας χωρίς λόγο.

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

Δύο βασικές ερωτήσεις πριν αποφασιστεί η ανάπτυξη

Πριν μια διοίκηση δεσμευτεί στην ανάπτυξη οποιουδήποτε προσαρμοσμένου στοιχείου, προτείνεται να απαντηθούν δύο βασικές ερωτήσεις:

  1. Είναι πραγματικά μοναδικό ή απλώς περίπλοκο; Η πολυπλοκότητα συχνά συγχέεται με τη μοναδικότητα. Αν μια διαδικασία είναι περίπλοκη επειδή προκύπτει από νόμο ή οδηγία, τότε κάθε άλλη διοίκηση που υπόκειται στον ίδιο νόμο αντιμετωπίζει το ίδιο πρόβλημα — άρα αξίζει να αναζητηθεί ποιος το έχει ήδη λύσει.
  2. Φθηνότερο σήμερα ή φθηνότερο μακροπρόθεσμα; Το προσαρμοσμένο λογισμικό φαίνεται φθηνό αρχικά, αφού δεν υπάρχουν συνδρομές, όμως η διοίκηση αναλαμβάνει ολόκληρο το μακροπρόθεσμο κόστος συντήρησης (σφάλματα, ενημερώσεις ασφαλείας, κανονιστικές αλλαγές). Όταν αγοράζεται ένα προϊόν, το κόστος αυτό μοιράζεται ανάμεσα σε εκατοντάδες οργανισμούς.

Χαρακτηριστικό παράδειγμα που αναφέρθηκε είναι το σύστημα μισθοδοσίας που ανέπτυξε ο Καναδάς με στόχο εξοικονόμηση 70 εκατομμυρίων δολαρίων ετησίως, το οποίο τελικά κόστισε πάνω από 5 δισεκατομμύρια δολάρια.

Ο πιλότος ως εργαλείο μείωσης αβεβαιότητας

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

Διακρίνονται δύο τύποι πειραμάτων:

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

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

Σχεδιασμός με περιθώριο λάθους

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

  • Κυριότητα των δεδομένων: τα δεδομένα πρέπει πάντα να μπορούν να εξαχθούν σε τυποποιημένη, αναγνώσιμη μορφή. Αν δεν μπορούν να εξαχθούν, ουσιαστικά η υπηρεσία δεν ανήκει στον οργανισμό.
  • Ουσιαστική κυριότητα του κώδικα: η κατοχή του πηγαίου κώδικα είναι το ελάχιστο. Πραγματική κυριότητα σημαίνει επίσης τεκμηρίωση και εσωτερική ικανότητα λειτουργίας του συστήματος.
  • Διαχωρισμός κατασκευαστή και κριτή: ο προμηθευτής που κατασκευάζει ένα σύστημα δεν θα πρέπει ποτέ να είναι και αυτός που πιστοποιεί την ποιότητά του ή αποφασίζει τα επόμενα βήματα.
  • Παραμετροποίηση, όχι υπερβολική προσαρμογή: η βαθιά τροποποίηση ενός τυποποιημένου προϊόντος με ειδικό κώδικα δεσμεύει τον οργανισμό σε έναν προμηθευτή και τον αποκόπτει από τις τακτικές ενημερώσεις.

Αναφέρθηκε επίσης ένα αποτρεπτικό παράδειγμα: μια διοίκηση υγείας αγόρασε ένα δοκιμασμένο προϊόν από άλλη περιοχή, αλλά το προσάρμοσε τόσο βαθιά που κατέληξε σε ένα εύθραυστο και δυσλειτουργικό σύστημα, μεγάλης οικονομικής επιβάρυνσης. Το συμπέρασμα ήταν ξεκάθαρο: το γεγονός ότι κάτι έχει αποδειχθεί αλλού δεν σημαίνει ότι θα λειτουργήσει εξίσου καλά τοπικά — γι’ αυτό χρειάζεται πάντα τοπική δοκιμή.

Αλλάζει η τεχνητή νοημοσύνη το πλαίσιο;

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

Πηγή άρθρου: https://interoperable-europe.ec.europa.eu/collection/eugovtech/news/synergies-among-pilots