דלגו לתוכן
HPI Pro — Salesforce consulting and implementation
שפה

מתודולוגיה

שיטת עבודה עם שערי מעבר — כדי שלא נגלה בעיה בשלב שבו כבר יקר לתקן.

שמונה שלבים, לכל אחד מטרה, תוצרים ותנאי מעבר מפורש. השיטה מותאמת להיקף, אך אף שלב אינו מדולג בשקט.

Enterprise Delivery System

מאפיון ועד ייצוב — עם שער בין שלב לשלב

השערים הם מה שהופך מתודולוגיה מרשימת שלבים למערכת בקרה. כל שער דורש אישור מפורש של הצד העסקי, לא רק של הצוות הטכני.

Enterprise Delivery System

  1. 01

    אפיון והבנת התהליך

    להבין מה צריך להשתנות בעבודה היומיומית, ומי מושפע מכך.

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

    שער מעבר: מסמך אפיון מאושר עם יעדים, משתמשים ותהליכים בהיקף.

  2. 02

    ארכיטקטורה ומודל נתונים

    לקבע את השכבות שיקר לשנות בהמשך.

    מודל ישויות, מקורות אמת, מודל הרשאות ושיתוף, גבולות אינטגרציה, החלטות Org והחלטות פלטפורמה.

    שער מעבר: מודל נתונים והרשאות מאושר בכתב מול בעלי התהליך ו-IT.

  3. 03

    תכנון פתרון והיקף

    לתרגם את האפיון ל-Backlog מוסכם עם קריטריוני קבלה.

    פירוק ליכולות, כתיבת User Stories, הגדרת MVP, תעדוף, זיהוי סיכונים ותלויות.

    שער מעבר: היקף מאושר עם קריטריוני קבלה ומנגנון ניהול שינויים.

  4. 04

    בנייה במחזורים

    לבנות ולהראות בפועל, לא במצגת.

    קונפיגורציה, Flow או Apex לפי החלטה מנומקת, ממשקי משתמש, הדגמה בסוף כל מחזור.

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

  5. 05

    דאטה ומיגרציה

    להעביר מידע שאפשר לסמוך עליו.

    Profiling, כללי ניקוי, Mapping, מפתחות זיהוי, טעינת ניסיון ו-Reconciliation.

    שער מעבר: טעינת ניסיון שעברה השוואה מלאה מול המקור ופערים מאושרים.

  6. 06

    בדיקות קבלה

    לוודא שהתהליך עובד בידי מי שיפעיל אותו.

    תסריטי UAT מבוססי תהליך, בדיקות הרשאות, בדיקות אינטגרציה ובדיקות עומס במידת הצורך.

    שער מעבר: UAT חתום על ידי בעלי התהליך, עם סיווג תקלות ותיקון החוסמות.

  7. 07

    הדרכה ומוכנות

    להביא את הארגון למצב שבו הוא יודע לעבוד ביום הראשון.

    הדרכה לפי תפקיד, חומרי עזר קצרים, רשת Champions, תקשורת פנים־ארגונית ותכנית תמיכה.

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

  8. 08

    עלייה לאוויר ו-Hypercare

    לייצב ולהעביר לניהול שוטף.

    חלון Cutover מתוכנן, ליווי צמוד בשבועות הראשונים, מדידת אימוץ ותיקונים מהירים.

    שער מעבר: יציאה מ-Hypercare לפי מדדי יציבות ואימוץ מוסכמים.

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

תפקידים

מי אחראי על מה

בעל תהליך עסקי

אחריות מרכזית
מגדיר מה צריך לקרות ומאשר קבלה
צד
הארגון

מכריע מוסמך

אחריות מרכזית
מכריע במחלוקות ומאשר שינויי היקף
צד
הארגון

ארכיטקט פתרון

אחריות מרכזית
מודל נתונים, הרשאות והחלטות פלטפורמה
צד
HPI Pro

מנהל Delivery

אחריות מרכזית
תכנון, תעדוף, סיכונים ותקשורת
צד
HPI Pro

מפתח ו-Admin

אחריות מרכזית
בנייה, אוטומציה, פיתוח ובדיקות
צד
HPI Pro

מומחה דאטה

אחריות מרכזית
Profiling, מיגרציה, איכות ו-Reconciliation
צד
HPI Pro

נציג IT ואבטחה

אחריות מרכזית
תשתיות, זהויות, הרשאות ורגולציה
צד
הארגון

קבוצת משתמשים בודקת

אחריות מרכזית
UAT ומשוב על שימושיות
צד
הארגון

ניהול סיכונים

ארבעה סיכונים שמטופלים מראש

דאטה גרועה מהצפוי

Profiling מוקדם לפני קביעת לוח זמנים, וכללי החלטה מוסכמים לרשומות שאינן עומדות בסף.

זחילת היקף

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

התנגדות משתמשים

מעורבות מוקדמת של משתמשי מפתח, בדיקות קבלה אמיתיות והדרכה לפי תפקיד ולא לפי מסך.

תלות באדם יחיד

תיעוד החלטות והעברת ידע שוטפת, כדי שהפרויקט לא ייעצר בגלל חופשה או עזיבה.

שאלות נפוצות

מתודולוגיה — שאלות שחוזרות

כמה זמן לוקח פרויקט Salesforce טיפוסי?
המשך נגזר מהיקף התהליכים, ממצב הנתונים וממספר האינטגרציות — לא מגודל הארגון. תהליך מכירה אחד עם מיגרציה נקייה נראה אחרת לגמרי משלושה תהליכים חוצי מחלקות עם חיבור ל-ERP. אנחנו נותנים טווח זמן רק אחרי שלב האפיון, כי לפניו זה ניחוש.
מהו שער מעבר ולמה הוא נדרש?
שער מעבר הוא תנאי מפורש שחייב להתקיים לפני שממשיכים לשלב הבא — למשל אישור מודל נתונים, או Reconciliation מוצלח של טעינת ניסיון. שערים מונעים את התופעה הנפוצה שבה פרויקט ממשיך לרוץ קדימה מעל בסיס שלא אושר, ומגלה זאת רק בבדיקות הקבלה.
האם אתם עובדים ב-Agile או ב-Waterfall?
בשילוב מבוקר. הארכיטקטורה, מודל הנתונים ומיגרציית הנתונים דורשים תכנון מקדים, כי שינוי שלהם באמצע יקר מאוד. הבנייה, השיפורים והתעדוף רצים במחזורים קצרים עם הדגמה קבועה. הגישה נקבעת לפי הרכיב ולא לפי אידאולוגיה.
מי מהארגון צריך להיות מעורב?
בעל תהליך עסקי לכל תחום, נציג IT או דאטה, מקבל החלטות שיכול להכריע במחלוקת, וקבוצת משתמשים שתשתתף בבדיקות הקבלה. היעדר מכריע מוסמך הוא אחת הסיבות הנפוצות ביותר לעיכובים.
מה קורה כשהדרישות משתנות באמצע?
שינוי הוא חלק טבעי מפרויקט. מה שאסור הוא שינוי לא מתועד. כל בקשה נבחנת מול ההיקף המאושר, מקבלת הערכת השפעה על זמן ותקציב, ונכנסת או נדחית בהחלטה מפורשת. כך נמנעת זחילת היקף שקטה.
מה נשאר בידי הארגון בסיום?
מסמכי ארכיטקטורה ומודל נתונים, מפת אינטגרציות, יומן החלטות, תסריטי בדיקות, חומרי הדרכה לפי תפקיד ונהלי תפעול. המטרה היא שהארגון יוכל להמשיך לתחזק ולהתפתח גם בלעדינו.

השלב הבא

נתאים את השיטה להיקף שלכם

לא כל פרויקט צריך את כל השלבים באותו עומק — אבל כל פרויקט צריך לדעת אילו שערים הוא עובר.