במאמר: למה פיתוח דשבורדים מסורתי התמקד בעיקר בקריאה? · היתרון של פיתוח דשבורדים עם AI: יותר גמישות לאורך התהליך · מה הופך דשבורד לאפליקציית דאטה? · דוגמה: עדכון יעדי מכירות מתוך הדשבורד · דוגמה: מאישור ניתוח רכש ו־MRP ליצירת הזמנות ספק · איך מחברים את האפליקציה ל־ERP? · שליטה בתהליך היא חלק מחוויית העבודה · איך מתחילים בלי להחליף את כל מערכת ה־BI? · שאלות נפוצות על אפליקציות דאטה עם AI · מהדשבורד שלכם לתהליך עסקי שעובד
פיתוח דשבורדים עם AI פותח הזדמנות להרחיב את מערכת הבינה העסקית לאפליקציית דאטה: מקום שבו המנהל רואה נתונים, מזין החלטות, מאשר שינויים ומעדכן את ה־ERP מתוך אותו ממשק.
מנהל המכירות מסתכל על הביצועים ומחליט לעדכן את יעדי החודש הבא. מנהלת הרכש בוחנת חוסרים צפויים ומאשרת רכישה. בשני המקרים, הגרף הוא רק תחילת העבודה. הערך העסקי מגיע כאשר ההחלטה הופכת לעדכון מסודר במערכת שמנהלת את הפעילות.
במשך שנים בנינו דשבורדים שעזרו לארגונים להבין מה קורה. כדי לפעול בעקבות המידע, המשתמש עבר לאקסל, שלח הודעה או פתח מסך אחר ב־ERP. שילוב של פיתוח בעזרת AI, ניתוח נתונים ותהליכי אינטגרציה מאפשר לתכנן חוויית עבודה רציפה יותר. זהו המעבר מצפייה בנתונים לניהול תהליך עסקי באמצעותם.
למה פיתוח דשבורדים מסורתי התמקד בעיקר בקריאה?
דשבורד קלאסי מרכז מדדים, מציג מגמות ומאפשר לסנן ולחקור. צוות הנתונים מחבר את המקורות, מגדיר חישובים ובונה תצוגה ניהולית. הזרימה הטיפוסית מתחילה במערכות התפעוליות ומסתיימת במסך של המשתמש.
נניח שהדשבורד מציג פער בין יעד המכירות לתוצאה בפועל. המנהל מבין שיש בעיה, אבל כדי לשנות את היעד הוא צריך למצוא את קובץ התכנון, לעדכן אותו ולוודא שמישהו מעביר את השינוי למערכת המתאימה. אם כמה מנהלים עובדים במקביל, מתחילות גם שאלות על גרסאות ואישורים.
כבר בעבר היה אפשר לבנות טפסים, להוסיף יכולות Write-back ולחבר מערכות BI לפעולות. הקושי היה בהיקף העבודה: מסכי הזנה, שירותי עדכון, הרשאות, בדיקות, טיפול בתקלות ותיאום בין צוותי BI, פיתוח ו־ERP. עבור צורך ממוקד, הארגון התקשה לעיתים להצדיק פרויקט נוסף.
חשוב לשמור על הדיוק הזה: AI לא המציא את היכולת לכתוב חזרה למערכת. הוא יכול לסייע לצוות לפתח ולהתאים את החלקים שמרכיבים את הפתרון, וכך לפתוח אפשרויות שהארגון דחה בעבר בגלל מאמץ הפיתוח.
היתרון של פיתוח דשבורדים עם AI: יותר גמישות לאורך התהליך
היתרון המשמעותי הוא האפשרות לבנות סביב הנתונים את דרך העבודה שהעסק צריך. במקום להסתפק בתצוגה שמציע כלי מסוים, אפשר לתכנן יחד גרפים, טבלאות עריכה, הערות, סימולציות וכפתורי אישור.
AI יכול לסייע בפיתוח טפסים, רכיבי ממשק, קוד חיבור ובדיקות. צוות מקצועי עדיין מגדיר את הדרישות, בוחן את הקוד ובודק את התהליך מול המערכת האמיתית. היקף החיסכון תלוי במורכבות, באיכות הממשקים ובמידת ההתאמה שנדרשת.
בתוך האפליקציה עצמה, AI יכול לעזור למשתמש להבין חריגה, לסכם נתונים או לנסח הצעה. לדוגמה: להסביר אילו מוצרים תרמו לפער מהיעד, או לרכז את הפריטים שדורשים בדיקת רכש. ההצעה צריכה להציג על אילו נתונים והנחות היא נשענת.
החיבור בין שתי היכולות חשוב במיוחד: AI מסייע לצוות לבנות את סביבת העבודה, ובהמשך יכול לסייע למשתמש לעבוד בתוכה. גם אפליקציה שפיתחו בעזרת AI יכולה לפעול בשגרה באמצעות כללים וחישובים מוגדרים, בלי לקרוא למודל בכל לחיצה.
מה הופך דשבורד לאפליקציית דאטה?
אפליקציית דאטה מחברת בין תמונת המצב לבין הפעולה הבאה. המשתמש יכול לבחור שורות, להזין ערך, לבחון את ההשפעה, לצרף הסבר ולהעביר את הבקשה לאישור. האפליקציה מציגה גם את סטטוס הביצוע ואת תשובת מערכת המקור.
יכולת כזאת משנה את משמעות המסך. למשל, טבלת מכירות יכולה להפוך למסך תכנון יעדים. דוח חוסרים יכול להפוך לתור עבודה לרכש. ולצוות שמטפל בחריגות, הדוח יכול לשמש רשימת משימות עם אחראי, החלטה ומעקב.
יש כאן גם הבדל בין אינטראקטיביות לבין פעולה: סינון גרף משנה את מה שהמשתמש רואה; אישור הזמנה יוצר מסמך עסקי. לכן אפיון אפליקציית דאטה כולל גם את האחריות על הפעולה, התנאים לביצועה ואופן הטיפול בשינוי שלא הצליח.
שתי דרכי עבודה מול אותו נתון
דשבורד לצפייה: זיהוי פער, ייצוא לקובץ, העברת בקשה והקלדה במערכת אחרת.
אפליקציית דאטה: זיהוי פער, הזנת שינוי, בדיקת השפעה, אישור ועדכון מתועד ב־ERP.
דוגמה: עדכון יעדי מכירות מתוך הדשבורד
הדוגמאות והמספרים במאמר נועדו להמחשה, ואינם מתארים פרויקט לקוח.
מנהלת המכירות פותחת מסך שמציג מכירות בפועל, יעדים, רווחיות וצבר הזמנות לפי סוכן ואזור. לצד המדדים, היא רואה עמודה לעריכת יעד החודש הבא. אפשר לעדכן כמה שורות ולהוסיף נימוק, בלי לייצא את הטבלה לקובץ חיצוני.
נניח שיעד אזור הצפון עומד על 500,000 שקלים. המנהלת מציעה להעלות אותו ל־550,000 שקלים בעקבות צבר הזמנות חדש. האפליקציה מציגה תוספת של 50,000 שקלים, כלומר 10%, ואת השפעתה על היעד הכולל. AI יכול לסכם את ההקשר העסקי; מנגנון חישוב מוגדר מחשב את הסכומים.
לפני השמירה, האפליקציה בודקת שהמשתמשת רשאית לשנות את יעדי האזור, שהתקופה פתוחה ושסך יעדי הסוכנים תואם ליעד האזורי. אם מדיניות החברה דורשת אישור סמנכ״ל, היא מעבירה אליו את הבקשה עם ההסבר והערכים לפני השינוי ואחריו.
לאחר האישור, שירות האינטגרציה מעדכן את היעדים דרך הממשק המתאים. אם הארגון מנהל יעדים ב־ERP, השירות מעדכן שם את הישות המתאימה. לעומת זאת, יעדים במערכת תכנון נפרדת דורשים עדכון באותה מערכת. לא מניחים שבכל ERP קיימת אותה טבלת יעדים או אותה יכולת עדכון.
המשתמשת מקבלת חיווי ברור: הבקשה ממתינה לאישור, העדכון הצליח או המערכת החזירה שגיאה. הדשבורד ממשיך להציג את הנתון המאושר, ומסמן הצעות שעדיין לא נכנסו לתוקף. כך כולם מבינים מול איזה יעד הם עובדים.
דוגמה: מאישור ניתוח רכש ו־MRP ליצירת הזמנות ספק
בתהליך רכש, הפער בין זיהוי הבעיה לבין הפעולה יכול להיות משמעותי במיוחד. דוח מציג חוסר צפוי, אבל הקניין עדיין צריך לבדוק הזמנות פתוחות, לעדכן כמויות, לבחור ספק ולהקליד הזמנה. אפליקציית דאטה יכולה לרכז את העבודה הזאת סביב המלצת הרכש.
MRP הוא תכנון דרישות חומרים. מנגנון התכנון מביא בחשבון נתונים כמו ביקושים, מלאי, הזמנות אספקה, זמני רכש ועצי מוצר כשיש ייצור. איכות ההמלצה תלויה גם בהגדרות העסקיות: מלאי ביטחון, כמויות מינימום ומועדי הצורך. מודל שפה לבדו אינו תחליף למנוע החישוב.
נניח שהחברה צריכה 1,000 יחידות בתקופת התכנון. במלאי יש 300 יחידות זמינות. עוד 200 יחידות צפויות להגיע לפני מועד הצורך. אם היא מבקשת להישאר עם מלאי ביטחון של 100 יחידות, דרישת הרכש היא 600 יחידות: 1,000 ועוד 100, פחות 300 ופחות 200. בדוגמה זו מניחים שאין אילוצים נוספים.
במערכת אמיתית, התזמון חשוב לא פחות מהסכום הכולל. אספקה שמגיעה אחרי מועד החוסר לא פותרת אותו. האפליקציה צריכה להציג את מועדי הצורך והאספקה, ולאפשר לקניין לראות מדוע מנוע התכנון מציע כמות מסוימת.
הקניין בוחן את ההמלצות בטבלה, משנה כמות או תאריך, בוחר ספק מתוך רשימה מורשית ומוסיף הערה. AI יכול לסכם את החריגים ולהבליט שאלות לבדיקה, למשל המלצה שחורגת מדפוס הרכש הרגיל. חישובי הכמות והמחיר נשענים על נתונים וכללים שהארגון אישר.
אחרי שהקניין מאשר את השורות, האפליקציה בודקת מחירים, מטבע, יחידות מידה, ספק פעיל והרשאות. היא מקבצת שורות להזמנות לפי הכללים שהארגון הגדיר ומעבירה אותן ל־ERP. בהתאם לתהליך המקומי, היא יוצרת טיוטות, בקשות רכש או הזמנות ספק ומפעילה את מסלול האישור המתאים.
כל שורה מקבלת סטטוס ומספר מסמך כאשר ה־ERP מאשר את היצירה. אם חלק מההזמנות הצליחו וחלק נכשלו, הקניין רואה את ההבדל ויכול לטפל רק בשורות הרלוונטיות. לחיצה חוזרת לא אמורה ליצור הזמנה נוספת לאותה בקשה.
תהליך רכש לדוגמה
- מנוע התכנון מחשב דרישה ומציג את ההנחות.
- הקניין בוחן שורות, כמויות, ספקים ותאריכים.
- בעל הסמכות מאשר את ההצעה המדויקת.
- שירות האינטגרציה בודק ויוצר מסמכים ב־ERP.
- האפליקציה מחזירה סטטוס ומספר הזמנה לכל בקשה.
איך מחברים את האפליקציה ל־ERP?
שכבת הנתונים מספקת תמונה לניתוח, ושירות אינטגרציה מנהל את הפעולות מול מערכת המקור. המשתמש עובד באותו מסך, אבל מאחוריו כל רכיב ממלא תפקיד ברור. הדוח יכול להישען על מחסן נתונים, בעוד ששירות הפעולה בודק נתונים עדכניים מול ה־ERP לפני יצירת מסמך.
למשל, מלאי שהדשבורד קרא בבוקר עשוי להשתנות עד הצהריים. לפני שהמשתמש מאשר רכש, השירות צריך לבדוק אם הזמנה חדשה כבר כיסתה את החוסר. האפליקציה מציגה מועד רענון ומתריעה כאשר שינוי במקור מחייב בדיקה מחדש.
דרך החיבור תלויה במערכת ובסביבה. SAP Business One מציעה Service Layer לעבודה עם נתונים ושירותים; ב־Priority ובמערכות אחרות בודקים את הממשקים, ההרשאות, הרישוי וההתאמות בהתקנה המסוימת. עדכון דרך ממשק נתמך מאפשר לשלב את כללי המערכת בתהליך.
התכנון כולל גם תיעוד של המשתמש המאשר, גרסת הנתונים, השינוי ותשובת ה־ERP. אם בקשה נתקעה לאחר שליחתה, השירות בודק מה קרה לפני ניסיון נוסף. זהו חלק מההבדל בין הדגמה שעובדת פעם אחת לבין כלי שהצוות יכול להפעיל מדי יום.
שליטה בתהליך היא חלק מחוויית העבודה
הרשאת צפייה אינה מעניקה אוטומטית הרשאת עדכון. מנהל יכול לראות את כל האזורים ולשנות רק את האזור שלו. קניין יכול להכין הזמנה, בעוד שמנהל רכש מאשר אותה מעל סכום מסוים. שירות הפעולה צריך לאכוף את הכללים גם אם מישהו שולח בקשה מחוץ למסך.
לפני פעולה, המשתמש רואה סיכום ברור: אילו רשומות ישתנו, מה הכמויות, מה הסכום ולאיזו מערכת תגיע הבקשה. כשהצעה כוללת שינוי מהותי מאז האישור, האפליקציה מבקשת אישור מחודש. התהליך מקשר בין מה שהאדם בדק לבין מה שהשירות מבצע.
כדאי לאפשר טיפול מסודר בתיקונים. לעיתים אפשר לבטל טיוטה; לעיתים מסמך שכבר התקדם דורש תהליך ביטול או תיקון ב־ERP. הצוות מגדיר מראש את ההתנהגות לכל מצב ומציג אותה למשתמש בשפה עסקית ברורה.
איך מתחילים בלי להחליף את כל מערכת ה־BI?
אפשר להתחיל מתהליך אחד שכבר יוצר עבודה ידנית חוזרת. עדכון יעדי מכירות הוא מועמד טוב כאשר הנתונים והאחריות ברורים. אישור המלצות רכש מתאים כאשר הארגון כבר מחזיק חישוב אמין ורוצה לקצר את הדרך ממנו להזמנה.
ממפים את המסך הקיים, מקורות הנתונים, הפעולה הרצויה והאישורים. לאחר מכן בונים תרחיש ממוקד ובודקים אותו בסביבת בדיקות: משתמש ללא הרשאה, ערך לא תקין, שינוי מקביל, תקלה בחיבור ולחיצה כפולה. משווים גם את התוצאה למסמך שנוצר בפועל במערכת.
את ההצלחה מודדים לאורך התהליך: כמה זמן עובר מהמלצה לפעולה, כמה הקלדות חוזרות נחסכו, כמה בקשות דרשו תיקון והאם המשתמשים חוזרים למסך. כך אפשר להחליט על הרחבה לפי תוצאה עסקית, במקום לפי מספר הגרפים או מסכי ה־AI.
הדשבורדים הקיימים ממשיכים לשרת מעקב ניהולי. הארגון מוסיף יכולות פעולה במקומות שבהם הן מועילות, ומשתמש במודלים ובחיבורים שכבר בנה ככל שהם מתאימים.
שאלות נפוצות על אפליקציות דאטה עם AI
האם כל כלי BI מאפשר להזין נתונים ולעדכן ERP?
לא. יש כלים עם יכולות מתאימות, ויש מקרים שדורשים הרחבה או אפליקציה ייעודית. בודקים את המסך ואת דרך החיבור למערכת המקור לפני שבוחרים פתרון.
האם חייבים צ׳אט כדי להשתמש ב־AI?
המשתמשים יכולים לעבוד עם טבלה, טופס וכפתורי אישור. AI יכול לסייע בפיתוח או להוסיף הסברים נקודתיים. בוחרים את הממשק לפי המשימה והמשתמשים.
האם AI יכול לאשר הזמנת ספק באופן עצמאי?
הצוות יכול לתכנן אוטומציה בגבולות מוגדרים. הארגון צריך לקבוע סמכויות ותנאים. התחלה מעשית היא המלצה עם אישור אנושי ומעקב אחר הביצוע.
מהדשבורד שלכם לתהליך עסקי שעובד
ב־Inflow אנחנו מחברים בין הבנה עסקית, הנדסת נתונים, אינטגרציה, בינה עסקית ו־AI. כדי לבחון אפליקציית דאטה, מתחילים בהחלטה שהעובד צריך לקבל ובפעולה שצריכה להגיע בעקבותיה. משם מאפיינים את הנתונים, המסך, החיבור והבקרה.
להרחבה על בסיס הנתונים וההגדרות, קראו את המדריך שלנו לניתוח נתונים עם AI. על השינוי הרחב באופן העבודה אפשר לקרוא במאמר דאטה AI והמגמות בעולם הנתונים.
יש לכם דשבורד שמסתיים בייצוא לאקסל ובהקלדה חוזרת ל־ERP? הביאו דוגמה אחת: עדכון יעדים, אישור רכש או טיפול בחריגה. צרו קשר עם Inflow ונבחן יחד איך להפוך את המידע לתהליך עבודה שמחבר בין ניתוח, החלטה וביצוע.
מקורות להרחבה
SAP: פעולות דרך Service Layer · Anthropic: שימושי AI בסביבת פיתוח
