לחבר את פריוריטי (Priority) לקלוד (Claude): מדריך לדשבורדים פיננסיים

הדרך הנכונה לחבר את פריוריטי (Priority) לקלוד (Claude) היא לא לחבר אותם ישירות, אלא דרך שכבת ביניים קטנה: שרת שמדבר עם פריוריטי (דרך ה-API או SQL לקריאה בלבד) וחושף לקלוד כלים שמחזירים נתונים מצרפיים. כך קלוד יכול להפיק דוחות רווח והפסד דינמיים, תקציב מול ביצוע, תזרים מזומנים ו-KPIs פיננסיים, ואף לבנות דשבורדים אינטראקטיביים ברמת BI, בלי לחשוף את מסד הנתונים הגולמי ובלי לסכן מידע רגיש. הנה איך עושים את זה נכון.

שלוש דרכי החיבור (וההבדל ביניהן)

לפריוריטי יש כמה "דלתות". חשוב להבין שהן לא מתחרות, אלא משלימות:

MCP הוא לא חלופה ל-API או ל-SQL, הוא שכבת העטיפה שמעליהם. בונים שרת MCP שחושף כלים כמו get_pnl(period) או get_cashflow(from,to), ומאחורי כל כלי יש קריאה ל-REST API או שאילתת SQL. קלוד (Claude) קורא לכלי, לא לבסיס הנתונים.

הארכיטקטורה הנכונה

קלוד (Claude) / קלוד קוד (Claude Code)
        │  קורא ל-tools (MCP) — לא רואה סיסמאות
        ▼
שכבת ביניים (Middleware / שרת MCP)
        │  הרשאות קריאה-בלבד · מחזיר נתונים מצרפיים · מתעד · מטמון
        ├──► Priority REST API   (טרנזקציות, נתונים "חיים")
        └──► SQL Views (read-only) (אגרגציות BI כבדות)
        ▼
    פריוריטי (Priority ERP)

למה שכבת ביניים ולא חיבור ישיר? שלוש סיבות: (1) אבטחה, המודל אף פעם לא מקבל את פרטי ההתחברות; (2) גבול נתונים, מחזירים אגרגציות ולא שורות גולמיות, כך שאין דליפת PII ואין הצפה של חלון ההקשר; (3) שליטה, כל שאילתה עוברת מקום אחד שאפשר לתעד, להגביל ולמטמן.

איזה חיבור לבחור לכל מטרה

• דוחות רווח והפסד, תקציב מול ביצוע, KPIs → אגרגציות על היסטוריה. עדיף SQL Views לקריאה בלבד (מהיר), עטוף ב-MCP.
• נתונים "חיים" (יתרות, מסמכים פתוחים, סטטוסים) → REST API של פריוריטי, שמכבד הרשאות ולוגיקה.
• Drill Down אינטראקטיבי → כלי MCP שמקבל פרמטר (למשל מחלקה/חודש) ומחזיר את הפירוט לרמה הבאה, על אותה שכבת ביניים.

אבטחה: ה-Best Practices שאסור לוותר עליהם

1. הרשאות מינימליות וקריאה-בלבד. משתמש DB/טוקן API ייעודי שרואה רק את מה שצריך. לעולם לא משתמש אדמין.
2. המודל לא מקבל credentials. פרטי ההתחברות יושבים בשכבת הביניים בלבד (משתני סביבה), לא בפרומפט ולא בקוד שהמודל רואה.
3. מחזירים מצרפי, לא גולמי. כלי מחזיר "סה״כ הכנסות לפי חודש", לא 40,000 שורות תנועה. זה מגן על מידע רגיש וגם חוסך טוקנים.
4. סינון PII. אם לא צריך שמות ספקים/לקוחות לניתוח, לא שולחים אותם.
5. תיעוד (audit) של כל שאילתה + הגבלת קצב. יודעים בדיוק מה נשאל ומתי.
6. מטמון (cache) לדוחות כבדים, גם ביצועים וגם פחות עומס על פריוריטי.

איך בונים את הדשבורדים בפועל

כאן קלוד קוד (Claude Code) עושה את העבודה הכבדה. התהליך:

1. בונים את שכבת הביניים: שרת קטן (Node/Python) עם כמה endpoints/כלי MCP: get_pnl, get_budget_vs_actual, get_cashflow, get_kpis, drill_down.
2. קלוד קוד בונה אפליקציית דשבורד: למשל Next.js עם ספריית גרפים, שמושכת מהשכבה הזו, עם פילטרים, Drill Down וכרטיסי KPI. חוויית BI אמיתית, בלי רישוי כלי BI יקר.
3. מחברים תזמון: רענון אוטומטי של הדוחות, והתראות (מייל/וואטסאפ/טלגרם) כשמדד חורג, בדיוק כמו במדריך חיבור קלוד קוד לטלגרם.

הגישה הזו זהה בעיקרון למה שהראינו במערכת תיאום הפגישות: שכבת ביניים מסודרת מול מערכת חיצונית, וקלוד בונה מעליה.

איך מתחילים: צעד אחר צעד

1. פיילוט ממוקד: בוחרים דוח אחד כואב (למשל רווח והפסד לפי מחלקה), לא עשרה.
2. פותחים גישה קריאה-בלבד בפריוריטי: טוקן API ייעודי, או משתמש SQL עם View אחד.
3. בונים כלי MCP אחד שמחזיר את הדוח כמצרפי.
4. קלוד קוד בונה דשבורד מעל הכלי הזה.
5. מודדים, מאבטחים, מרחיבים: עוד דוח, עוד מדד, תזמון.

שורה תחתונה

לחבר את פריוריטי (Priority) לקלוד (Claude) זה בהחלט אפשרי ומאוד משתלם, אבל לא בחיבור ישיר. שכבת ביניים קטנה + MCP מעל REST API ו-SQL Views לקריאה בלבד נותנת אבטחה, שליטה, וחוויית BI מלאה: דוחות דינמיים, תקציב מול ביצוע, תזרים, KPIs ו-Drill Down. מתחילים מפיילוט אחד ומרחיבים.

רוצים ליישם את זה בארגון שלכם? זה בדיוק סוג הפרויקט שאנחנו מלווים בהטמעת AI בארגונים ובייעוץ AI, ואפשר גם להתחיל משיעור פרטי 1-על-1 שבו נתכנן את הארכיטקטורה על המערכת שלכם. דברו איתנו.