פתרונות Salesforce לפי מצב עסקי
HPI Pro ממפה את התהליך, המידע והמערכות הקיימות — ובונה מסלול Salesforce, Agentforce ו-AI המותאם למצב הארגון, לרמת הבשלות וליעדים העסקיים שלו.
Solution Decision Architecture
ההחלטה על הפתרון אינה מתחילה ברשימת מוצרים אלא בשאלה איפה הארגון נמצא היום, אילו נתונים כבר קיימים ומה צריך להשתנות בתהליך.
Solution Decision Architecture
מצב הארגון
מאיפה מתחילים בפועל
שכבת החלטה ארכיטקטונית
מה נקבע לפני פיתוח
מסלול פתרון
מה מבצעים בפועל
ארבע נקודות התחלה
פתרונות לפי מחלקה
לכל מחלקה יש בעיה טיפוסית משלה, מידע שהיא חייבת כדי לעבוד, ותהליך שצריך לרוץ מקצה לקצה. הדוגמאות להלן כלליות ואינן מייצגות לקוח מסוים.
הבעיה הטיפוסית: לידים נכנסים מכמה מקורות ואינם מטופלים באותו סטנדרט, וה-Pipeline משקף הערכה אישית ולא שלב מדיד.
ארגון שמאחד שלושה מקורות לידים לתהליך הסמכה אחד — דוגמה כללית להמחשה בלבד.
הבעיה הטיפוסית: פניות מגיעות בכמה ערוצים, אין תמונת לקוח אחת ואין אבחנה בין דחיפות טכנית לדחיפות עסקית.
מוקד שמפריד בין פניות ידע לפניות תקלה כדי לקצר תורים — דוגמה כללית להמחשה בלבד.
הבעיה הטיפוסית: תהליכי אישור וביצוע חיים במיילים ובקבצים, ולכן אין מעקב אחר חריגות ואין נתוני עומס אמיתיים.
תהליך אישור הזמנות שמקבל סטטוס אחיד בין מכירות לתפעול — דוגמה כללית להמחשה בלבד.
הבעיה הטיפוסית: כל מחלקה מציגה מספרים אחרים לאותה שאלה, והדיון עוסק במקור הנתון ולא בהחלטה.
הנהלה שמאמצת הגדרת Pipeline אחת לכל היחידות — דוגמה כללית להמחשה בלבד.
הבעיה הטיפוסית: יוזמות רבות רצות במקביל בלי ארכיטקטורה משותפת, וכל אחת מייצרת חוב טכני חדש.
ארגון שמרכז יוזמות CRM תחת מסגרת ממשל אחת — דוגמה כללית להמחשה בלבד.
הבעיה הטיפוסית: אינטגרציות נבנו נקודתית לאורך שנים, ואין מי שיודע להסביר את כיוון הזרימה או את הטיפול בכשל.
מערך IT שמחליף שלושה ממשקים נקודתיים בחוזה ממשק אחד — דוגמה כללית להמחשה בלבד.
פתרונות לפי בעיה
המטריצה מתרגמת כאב עסקי מוכר להחלטה שצריך לקבל לפניו, ורק אחר כך ליכולת המערכתית שמיישמת אותה.
| הבעיה העסקית | ההחלטה שצריך לקבל | היכולת שמיישמת אותה |
|---|---|---|
| מידע מפוזר בין מערכות | לקבוע מקור אמת לכל ישות לפני שמחברים מערכות | מודל נתונים, אינטגרציות, ממשל מידע |
| לידים שהולכים לאיבוד | להגדיר בעלות וזמן תגובה בכל שלב בכניסת ליד | Lead Management, ניתוב, התראות |
| עבודה ידנית וכפולה | לזהות היכן הכפילות נובעת מתהליך ולא ממערכת | אוטומציה, אישורים, סנכרון דו־כיווני |
| חוסר בתמונה ניהולית | להסכים על הגדרת מדידה אחת לכל KPI | דשבורדים, איכות נתונים, מחזור דיווח |
| מערכת שאינה מאומצת | לבדוק אם הבעיה בשימושיות, בתהליך או באמון בנתון | פישוט UX, הדרכה לפי תפקיד, מדדי אימוץ |
| אינטגרציות לא אמינות | לבחור דפוס אינטגרציה לפי סבילות לכשל ולא לפי נוחות | Event-Driven, Retry, ניטור, Reconciliation |
| פרויקט שחרג מהתכנון | לעצור, לאבחן ולתעדף מחדש לפני שממשיכים לפתח | אבחון, Backlog מאומת, Recovery Roadmap |
| AI ללא תשתית נתונים | להכשיר מידע, הרשאות ופעולות לפני הפעלת סוכן | מוכנות Data, Grounding, בקרה ואודיט |
מידע מפוזר בין מערכות
לידים שהולכים לאיבוד
עבודה ידנית וכפולה
חוסר בתמונה ניהולית
מערכת שאינה מאומצת
אינטגרציות לא אמינות
פרויקט שחרג מהתכנון
AI ללא תשתית נתונים
מסגרת בחירה
מהו התהליך העסקי שצריך להשתנות?
בלי תהליך מוגדר, כל בחירת מוצר היא ניחוש יקר.
מי משתמש במערכת ומי מקבל בה החלטות?
משתמש יומיומי ומקבל החלטות צורכים מידע שונה לחלוטין.
מהו מקור האמת לכל נתון?
שדה בלי מקור אמת יהפוך לוויכוח קבוע בין מחלקות.
מהו הערך שנרצה למדוד אחרי ההטמעה?
מדד שנקבע מראש הוא ההגנה הטובה ביותר מפני זחילת היקף.
AI בתוך הפתרון
סוכן AI פועל על אותם נתונים, הרשאות ופעולות של המערכת. אם השדות אינם אמינים, אם אין Knowledge מתוחזק ואם לא הוגדר מה מותר לסוכן לבצע — התוצאה תהיה תשובות שנשמעות טוב ואינן ניתנות לאימות.
לכן ההחלטה על AI מתקבלת אחרי ארבע הגדרות: אילו נתונים הסוכן רשאי לראות, אילו פעולות הוא רשאי לבצע, מתי הוא מעביר לאדם, וכיצד נבדקת איכות התשובות לאורך זמן.
במקרים רבים Flow או אוטומציה רגילה נותנים את אותה תוצאה עסקית בסיכון נמוך יותר ובעלות תחזוקה קטנה יותר. זו מסקנה לגיטימית של תהליך בחינה, ולא כישלון שלו.
להמשיך מכאן
שאלות נפוצות
השלב הבא
שיחה ממוקדת להבנת הצורך, מצב המערכת והיעדים העסקיים.
