Make ή Power Automate: το Microsoft 365 αλλάζει τη σωστή επιλογή

Αν μια μικρή επιχείρηση χειρίζεται εγκρίσεις κυρίως σε Outlook και SharePoint, το Power Automate είναι συνήθως η πιο λογική αφετηρία. Όταν η ίδια εργασία διασχίζει πολλά ανεξάρτητα SaaS, το Make μπαίνει σοβαρά στη σύγκριση. Αυτή τη διάκριση κάνει και ο οδηγός του Collab365 για ομάδες Microsoft 365.

Η συνδρομή Microsoft 365 επηρεάζει την απόφαση, αλλά δεν αρκεί για να υπολογιστεί το κόστος κάθε ροής. Χρειάζεται να γνωρίζετε ποιους connectors χρησιμοποιεί, ποιος την ενεργοποιεί και πόσες φορές εκτελούνται τα βήματά της. Αν η εργασία περιλαμβάνει χειρισμό εφαρμογής desktop, προστίθεται και η αδειοδότηση RPA.

Τι μετρά κάθε πλατφόρμα

Στο Make η βασική μονάδα χρέωσης είναι το credit. Για εφαρμογές χωρίς AI, μία εκτέλεση module αντιστοιχεί κανονικά σε ένα credit, σύμφωνα με την τεκμηρίωση credits του Make. Επομένως, μια αναζήτηση στο CRM και μια ενημέρωση εγγραφής μετρούν ως χωριστές εκτελέσεις. Αν ένα αρχικό γεγονός δημιουργεί περισσότερες εγγραφές, τα επόμενα modules μπορεί να εκτελεστούν για καθεμία. Στις ενσωματωμένες λειτουργίες AI η κατανάλωση μπορεί να εξαρτάται και από tokens ή άλλους παράγοντες· με σύνδεση σε δικό σας πάροχο AI μπορεί να προστεθεί η χρέωση του παρόχου.

Στο Power Automate, η πρώτη οικονομική διάκριση είναι το δικαίωμα χρήσης. Οι διευκρινίσεις αδειοδότησης της Microsoft ορίζουν ότι οι άδειες Microsoft 365 δίνουν πρόσβαση σε standard connectors, ενώ μια γενικής χρήσης ροή με premium ή custom connector απαιτεί κατάλληλη πρόσθετη άδεια. Σε αυτοματοποιημένη ή προγραμματισμένη ροή με premium connector μετρά η άδεια του ιδιοκτήτη. Σε ροή που ξεκινά χειροκίνητα, χρειάζεται Premium για κάθε χρήστη που την εκτελεί ή άδεια Process εκχωρημένη στη ροή. Οι ενέργειες AI Builder χρειάζονται διαθέσιμα AI Builder credits στο περιβάλλον. Πρόκειται για διαφορετικό υπολογισμό από τα credits ανά module του Make.

Έγκριση από email: πού βρίσκεται η απόφαση

Ας υποθέσουμε ότι ένα εισερχόμενο email δημιουργεί εγγραφή στο SharePoint, αποστέλλεται για έγκριση και, μετά την απάντηση, ενημερώνεται η εγγραφή και φεύγει απαντητικό email. Στο Power Automate αυτό αντιστοιχεί, στο απλό σχήμα του παραδείγματος, σε ένα trigger και τέσσερις ενέργειες. Η ενέργεια «Start and wait for an approval» περιμένει την ανθρώπινη απόφαση. Η οδηγία της Microsoft για τις εγκρίσεις κατατάσσει τον connector στις standard συνδέσεις και αναφέρει ότι οι εγκρίσεις αποθηκεύονται στο Dataverse.

Για αυτή την υποθετική ροή, εφόσον και οι υπόλοιποι connectors είναι standard και η άδεια Microsoft 365 παρέχει τα αντίστοιχα δικαιώματα Power Automate, δεν προκύπτει ανάγκη για Premium μόνο από την ενέργεια έγκρισης. Χρειάζεται όμως διαθέσιμο περιβάλλον Dataverse· στην πρώτη χρήση εκτός του προεπιλεγμένου περιβάλλοντος μπορεί να χρειαστούν δικαιώματα διαχειριστή για την αρχική δημιουργία της βάσης.

Στο Make θα μπορούσε να σχεδιαστεί χωριστή διαδρομή για την επιστροφή της απόφασης. Αν εκτελεστούν ακριβώς μία φορά η λήψη email, η δημιουργία εγγραφής, η αποστολή αιτήματος, η λήψη απάντησης μέσω webhook, η ενημέρωση και το τελικό email, η απλουστευμένη μέτρηση είναι έξι εκτελέσεις modules, περίπου έξι credits χωρίς AI. Δεν είναι ισοδύναμη έτοιμη λειτουργία έγκρισης: η ομάδα πρέπει να ορίσει πώς ταυτοποιείται ο εγκρίνων, πού καταγράφεται η απάντηση και τι γίνεται όταν αυτή καθυστερεί.

Συγχρονισμός SaaS: πότε πολλαπλασιάζονται τα βήματα

Σε δεύτερο υποθετικό σενάριο, αίτημα από εξωτερική φόρμα αναζητά πελάτη σε CRM, δημιουργεί ή ενημερώνει την εγγραφή του, γράφει αποτέλεσμα στο SharePoint και ειδοποιεί ομάδα στο Teams. Αν κάθε στάδιο εκτελεστεί μία φορά, η διαδρομή στο Make περιλαμβάνει πέντε εκτελέσεις modules: παραλαβή, αναζήτηση, εγγραφή στο CRM, εγγραφή στο SharePoint και ειδοποίηση. Η εκτίμηση αφορά ένα αίτημα με έναν πελάτη και επιτυχημένη εκτέλεση χωρίς πρόσθετα βήματα.

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

Στο Power Automate, ελέγξτε την ακριβή ενέργεια του connector για τη φόρμα και το συγκεκριμένο CRM. Η παρουσία μιας υπηρεσίας στον κατάλογο δεν λέει από μόνη της αν η απαιτούμενη ενέργεια είναι standard, premium ή χρειάζεται custom connector. Αν η ροή χρησιμοποιεί premium σύνδεση, η ήδη πληρωμένη συνδρομή Microsoft 365 δεν καθιστά αυτόματα τη ροή διαθέσιμη. Αντίστοιχα, το Make είναι ελκυστικό όταν τα έτοιμα modules καλύπτουν τα εξωτερικά SaaS και ο αναμενόμενος όγκος χωρά στο σχέδιο credits της ομάδας. Η εσωτερική σύνδεση για τη σύγκριση χρέωσης του Make με το n8n βοηθά όταν εξετάζεται και τρίτη πλατφόρμα.

Εφαρμογή desktop: άλλο δικαίωμα για attended και unattended RPA

Ας υποθέσουμε ότι μια παλαιότερη εφαρμογή δέχεται δεδομένα μόνο με χειρισμό των ορατών πεδίων της. Εδώ το κρίσιμο ερώτημα είναι αν ένας υπάλληλος ξεκινά και επιβλέπει τη ροή ή αν μια μηχανή την εκτελεί χωρίς παρόντα χρήστη. Η περιγραφή αδειών του Power Automate περιλαμβάνει attended RPA στην άδεια Premium χρήστη. Για unattended εκτέλεση, άδεια Process εκχωρείται στη μηχανή ως unattended bot· η καταχώριση της μηχανής απαιτεί επίσης χρήστη με κατάλληλο δικαίωμα Premium.

Άρα το υποθετικό νυχτερινό πέρασμα μιας εγγραφής από την εφαρμογή desktop δεν κοστολογείται σαν μια απλή ροή SaaS. Πρέπει να μετρηθούν η μηχανή, οι ταυτόχρονες εκτελέσεις που απαιτούνται και ο άνθρωπος που δημιουργεί και υποστηρίζει τη ροή. Το Make μπορεί να χειριστεί τα δεδομένα πριν ή μετά την εργασία, αλλά τα credits αυτών των βημάτων δεν καλύπτουν από μόνα τους τον χειρισμό της εφαρμογής desktop. Αν χρησιμοποιηθεί μαζί με χωριστή λύση RPA, η λύση αυτή χρειάζεται δική της εκτίμηση κόστους και ευθύνης.

Η διακυβέρνηση κρίνει ποιος θα τη συντηρεί

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

Για καθένα από τα τρία σενάρια, μια χρήσιμη ελάχιστη καταγραφή περιλαμβάνει:

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

Για εσωτερική έγκριση με standard συνδέσεις, η αφετηρία παραμένει το Power Automate. Για συγχρονισμό πολλών SaaS, η απόφαση εξαρτάται από τις συγκεκριμένες ενέργειες των connectors και τις εκτελέσεις ανά πραγματική εγγραφή. Όπου υπάρχει εφαρμογή desktop, τα δικαιώματα RPA και η υποστήριξη της μηχανής γίνονται μέρος της ίδιας επιλογής.

Διαβάστε επίσης:

• n8n ή Make: ο τρόπος χρέωσης αλλάζει τον φθηνότερο αυτοματισμό
• RAG ή fine-tuning: λάθος επιλογή αυξάνει και κόστος και λάθη
• Slack ή Microsoft Teams: τα 500 εργασιακά σενάρια δεν έβγαλαν έναν νικητή