Τρεις φορές άλλαξα την αρχιτεκτονική των metrics. Να γιατί.

Αν το report σου θέλει λεπτά για να ανοίξει, αν δύο αναφορές δίνουν διαφορετικό νούμερο για το ίδιο πράγμα, ή αν κάθε νέα ερώτηση της διοίκησης καταλήγει σε ένα ακόμη Excel, το πρόβλημα σπάνια είναι το Power BI. Είναι ο τρόπος που είναι στημένα τα δεδομένα από κάτω.

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

Μια απλή ερώτηση με πολλές διαστάσεις

«Πού πάει ο χρόνος;» ακούγεται σαν ερώτηση για ένα report. Στην πράξη η διοίκηση ήθελε να τον βλέπει ανά σύμβουλο, ανά θεματική ενότητα, ανά πελάτη και ανά project, να ξεχωρίζει την πρώτη γραμμή υποστήριξης από τις πιο σύνθετες υποθέσεις, να συγκρίνει τρίμηνα και να παρακολουθεί SLAs. Κάθε μήνα, με ιστορικό πάνω από δέκα ετών.

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

Πρώτη προσπάθεια: όλα μέσα στο Power BI

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

Με δεδομένα λίγων μηνών ήταν μια χαρά. Με όλο το ιστορικό, κοντά σε ένα εκατομμύριο εγγραφές, κάθε ανανέωση κρατούσε γύρω στα δέκα λεπτά, το Power Query κατέρρεε, και το API απλώς δεν άντεχε τόσα αιτήματα.

Εκεί κατάλαβα το πρώτο: το Power BI είναι εξαιρετικό στο να δείχνει δεδομένα. Δεν είναι φτιαγμένο για να τα μαζεύει από ένα API κάθε φορά που κάποιος πατάει refresh.

Δεύτερη προσπάθεια: έβγαλα τα δεδομένα έξω

Έγραψα ένα ETL σε .NET που τραβούσε τα δεδομένα με πρόγραμμα και τα αποθήκευε σε δική μας βάση SQL. Το Power BI διάβαζε πλέον από εκεί.

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

Είχα μετακινήσει τα δεδομένα. Δεν τα είχα οργανώσει.

Τρίτη προσπάθεια: οι υπολογισμοί πήγαν στη θέση τους

Η λύση ήταν ένα μοντέλο δεδομένων στο SQL Server Analysis Services. Εκεί ορίζονται μία φορά οι σχέσεις, οι ιεραρχίες και οι υπολογισμοί, και το Power BI απλώς ρωτάει.

Τα reports άνοιγαν και απαντούσαν. Και κάτι εξίσου σημαντικό: ο ορισμός κάθε μέτρησης ζούσε πλέον σε ένα σημείο. Όταν κάποιος ρωτούσε «πώς ακριβώς μετράμε τον χρόνο επίλυσης;», υπήρχε μία απάντηση, όχι μία ανά report.

Και μετά άλλαξε το σύστημα

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

Αυτή τη φορά δεν το μπάλωσα. Το ξανάστησα ώστε να μην εξαρτάται από καμία πηγή. Ένα pipeline σε Python μαζεύει πλέον τα δεδομένα από το Jira και από τις υπόλοιπες πηγές σε μία αποθήκη δεδομένων, και η ομάδα το διαχειρίζεται από μια εσωτερική πλατφόρμα.

Το αποτέλεσμα; Η ομάδα βλέπει καθαρά πού πηγαίνει ο χρόνος της, ανά πελάτη και ανά project. Και όταν κάποιος αμφισβητεί πόσος χρόνος αφιερώθηκε σε μια υπόθεση, η απάντηση είναι στοιχεία, όχι εκτίμηση.

Πώς μοιάζει όταν είναι σωστά στημένο

Αν ξεκινούσα σήμερα από το μηδέν, θα πήγαινα κατευθείαν σε αυτή τη μορφή:

Σε μια μικρή ή μεσαία επιχείρηση αυτό δεν χρειάζεται να είναι βαρύ. Συνήθως αρκούν μια μικρή βάση SQL, ένα ETL που τρέχει με πρόγραμμα, και ένα καλά στημένο μοντέλο μέσα στο ίδιο το Power BI, που δουλεύει με την ίδια μηχανή με το Analysis Services. Το ETL θα το κρατούσα ως ανεξάρτητη υπηρεσία, για παράδειγμα ένα μικρό .NET Web API, με δική του διαχείριση και σωστά δικαιώματα πρόσβασης.

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

Σε ποιο σημείο είσαι εσύ;

Τα συμπτώματα συνήθως δείχνουν ποιο επίπεδο λείπει:

• Το report αργεί να ανοίξει ή η ανανέωση «κολλάει». Τα δεδομένα τραβιούνται απευθείας από το ERP σε κάθε ανανέωση. Λείπει η εξαγωγή.
• Δύο reports δίνουν διαφορετικό νούμερο για το ίδιο πράγμα. Κάθε report έχει τους δικούς του υπολογισμούς. Λείπει το κοινό μοντέλο.
• Κάθε νέα ερώτηση της διοίκησης σημαίνει νέο Excel. Τα δεδομένα δεν είναι οργανωμένα ώστε να συνδυάζονται ελεύθερα: πελάτης με προϊόν, προϊόν με περίοδο, περίοδος με πωλητή.
• Φοβάσαι να αλλάξεις ERP γιατί «θα χαθούν οι αναφορές». Οι αναφορές είναι δεμένες με τη δομή της πηγής. Λείπει η αποθήκη δεδομένων.

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

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