הצעת ערך ותוכנית פעולה: מעבר למערכת פעולה מרכזית ב-monday.com עבור OK Media
מומחה לארכיטקטורת monday.com, אוטומציות ואופטימיזציה עסקית.
1. תקציר מנהלים
הפרויקט שלפנינו אינו מסתכם בהעברת נתונים טכנית ממערכת MyBusiness ל-monday.com. מדובר במהלך אסטרטגי לבניית מערכת ההפעלה המרכזית של OK Media – תשתית שתרכז את הלידים, הפרויקטים, הלקוחות והבקרה התקציבית במקום אחד.
הגישה המומלצת לפרויקט מסוג זה היא מעבר מדורג. אין צורך לאשר מראש מעבר מלא או תהליך רחב מדי. האישור הראשון יכול להיות קטן, מבוקר ובטוח. המטרה היא לבנות מודל עובד (POC) שאינו עבודה שתיזרק לפח – אלא הופך לבסיס היציב שעליו תיבנה המערכת כולה.
2. לפניכם שלוש אפשרויות לבחירתכם
אפשר להתחיל בצורה מדורגת ומבוקרת. במקום לאשר מראש מעבר מלא, ניתן להתחיל בשלב אפיון קצר שמטרתו לייצר תוכנית עבודה סדורה. לאחר מכן ניתן להמשיך ל-POC תפעולי מתוך בסיס מדויק יותר.
למי זה מתאים: התחלה זהירה
מה מקבלים בסוף: מפת מערכת, מפת מיגרציה, סקירת Make ותכולת POC מדויקת.
למי זה מתאים: התחלה פרקטית
מה מקבלים בסוף: כל תוצרי A + מודל עובד ללקוח מורכב, תהליך ליד, דשבורד בסיסי ואוטומציית Make אחת.
למי זה מתאים: מומנטום מהיר
מה מקבלים בסוף: מודל רחב יותר הכולל CRM, פרויקט, ריטיינר, זמן, תקציב, דשבורדים ומספר אוטומציות.
ההמלצה שלי: אם רוצים להתקדם בזהירות מירבית — בחרו באפשרות A. אם רוצים להתחיל לקבל ערך תפעולי מהר ולהרגיש את המערכת בידיים — בחרו באפשרות B או C.
3. ארכיטקטורה תפעולית: מעבר למערכת מרכזית
מצב קיים (מפוזר)
מצב עתידי (אחוד)
4. תרשים זרימה תפעולי
5. מפת דרכים: למה גישה מדורגת?
6. מה מקבלים בסוף כל שלב?
הפרויקט אינו נמדד בשעות פיתוח בלבד, אלא בתוצאות עסקיות ברורות שמועברות אליכם.
| שלב | תוצרים |
|---|---|
| אפיון | ארכיטקטורה מוגדרת, מפת הגירת נתונים, מפת אוטומציות דרך Make ותוכנית תכולה מדויקת ל-POC. |
| Operational POC | לקוח מורכב אחד (למשל מדרשת הגולן) מנוהל במלואו מא’ ועד ת’ בתוך monday.com. |
| פיילוט חי | 3-5 לקוחות אמיתיים המנוהלים על ידי צוות עובדים נבחר שעובד במערכת באופן יומיומי. |
| מיגרציה (העברת נתונים) | הנתונים התפעוליים הפעילים הועברו מ-MyBusiness וזמינים לעבודה רציפה. |
| עלייה לאוויר | monday.com הופכת באופן רשמי למערכת העבודה היומיומית והמרכזית של כלל החברה. |
| תחזוקה ואופטימיזציה | שיפורים מתמידים, תיקונים, דשבורדים מעמיקים, אוטומציות חדשות ותמיכה מלאה באימוץ מצד העובדים. |
7. נקודות החלטה ובקרה לאורך הדרך
הפרויקט מתוכנן עם נקודות עצירה. כך שאינכם מחויבים לכל תהליך המיגרציה בבת אחת ומראש. בסוף כל שלב נבדוק את התהליך לפני החלטה על המשך.
| נקודת בקרה | ההחלטה המתקבלת |
|---|---|
| לאחר שלב האפיון | אישור ארכיטקטורת monday.com ואישור תכולת ה-POC המדויקת שנבנה. |
| לאחר שלב ה-POC | החלטה אילו התאמות ושינויים נדרשים לפני שמרחיבים את המודל לפיילוט. |
| לאחר הפיילוט | החלטה האם monday.com בשלה ומוכנה להפוך למערכת ההפעלה המרכזית. |
| לאחר המיגרציה | החלטה האם מערכת MyBusiness הופכת באופן רשמי לארכיון קריאה בלבד. |
| לאחר העלייה לאוויר | בחירת מסלול תחזוקה ואימוץ חודשי התואם לצרכי החברה. |
8. תוכנית עבודה מוצעת ל-30 הימים הראשונים
| שבוע | מיקוד העבודה | תוצר מוגדר בסוף השבוע |
|---|---|---|
| שבוע 1 | פגישת התנעה, ייצוא נתונים מ-MyBusiness, סקירת סביבת ה-Make הנוכחית. | מיפוי מלא של נתונים, אוטומציות ותהליכים קיימים. |
| שבוע 2 | תכנון מבנה הלוחות ב-monday.com ועיצוב תהליכי העבודה במוצר. | מסמך ארכיטקטורה מאופיין לאישור. |
| שבוע 3 | בנייה והקמה של לוחות ה-POC והטמעת תהליכי הליבה עבור לקוח נבחר. | מודל עבודה ראשוני ללקוח מרכזי אחד עומד ומוכן לבדיקה. |
| שבוע 4 | בדיקות (Testing), התאמות דיוק, הדרכה בסיסית וסקירה משותפת. | סיכום שלב ה-POC וקבלת החלטה על המשך לשלב הפיילוט. |
9. גבולות ה-POC — על מנת לשמור על יעילות ושליטה
ה-POC חייב להיות תפעולי תחת בקרה. מטרתו להוכיח שהמודל עובד, מבלי לנסות לבנות את כל המערכת בבת אחת. כל דרישה מעבר להגדרות האלו אלו תיושם בשלבי הפיילוט והמיגרציה.
- ניהול של לקוח קיים אחד בלבד (מורכב ככל הניתן).
- מקור לידים אחד בלבד (קמפיין ספציפי או טופס באתר).
- אוטומציה אחת להעברת ליד לסטטוס לקוח.
- הקמת תהליך עבודה (Workflow) אחד לריטיינר.
- הקמת תהליך עבודה אחד לפרויקט חד-פעמי.
- דשבורד בסיסי אחד לבקרה על זמן מול תקציב.
- תהליך אוטומציה אחד פעיל דרך Make.
- ריכוז עבודה בכלי אחד לניהול מסמכים וקישור לסיסמאות.
10. מדיניות מומלצת להעברת נתונים
כדי למנוע בזבוז זמן וכסף, בתהליך המיגרציה תועדף העברת נתונים תפעוליים פעילים. נתונים היסטוריים יכולים להישאר בשלב הראשון בארכיון MyBusiness, אלא אם ישנה סיבה עסקית מובהקת להעבירם.
| סוג הנתונים מ-MyBusiness | מדיניות טיפול מומלצת |
|---|---|
| לקוחות פעילים | העברה ל-monday.com. |
| פרויקטים פעילים | העברה ל-monday.com. |
| ריטיינרים פעילים | העברה ל-monday.com. |
| לידים פתוחים | העברה ל-monday.com. |
| לקוחות היסטוריים (לא פעילים) | השארה בארכיון MyBusiness בשלב הראשון. |
| חוזים וקבצים מצורפים | העברה או קישור מתוך ארכיון קבצים מסודר (Google Drive, SharePoint וכד’). |
| היסטוריית פעילות מלאה (לוגים) | העברה רק במידה והוגדר כקריטי עסקית. |
| סיסמאות ופרטי גישה | העברה למנהל סיסמאות מאובטח; שמירת קישור/הפניה בלבד ב-monday.com. |
11. תחומי אחריות — כדי למנוע עיכובים
| תחום הפעילות | Peace of Mind (שאול זיו) | OK Media |
|---|---|---|
| ארכיטקטורת מערכת | אחריות על התכנון והעיצוב | ביקורת ואישור האפיון |
| ייצוא מ-MyBusiness | הנחיה טכנית ובקרת איכות נתונים | ביצוע הייצוא ואספקת צילומי מסך |
| הקמה ב-monday.com | פיתוח והגדרת המערכת בפועל | מתן משוב ופידבק שוטף |
| אוטומציות (Make) | ביצוע סקר (Audit) ובניית התהליכים | הקצאת הרשאות והסבר על ההיגיון העסקי |
| העברת ידע ונהלים | תרגום התהליכים לזרימת עבודה מובנית | הסבר כיצד העבודה מתבצעת כיום בפועל |
| בדיקות (Testing) | הובלת תוכנית הבדיקות | בדיקה באמצעות מקרי אמת מהשטח |
| עלייה לאוויר | תמיכה וייצוב המערכת | אימוץ פנימי ודחיפת העובדים לשימוש |
12. הגדרת מדדים לפני בניית דשבורדים
דשבורדים אינם אמורים רק להיראות טוב – הם נועדו לספק תשובות לשאלות ניהוליות. להלן דוגמאות למדדים שניישם:
| דשבורד | דוגמאות למדדי מפתח (KPIs) |
|---|---|
| מכירות (Sales) | כמות לידים לפי מקור הגעה, לידים פתוחים, עסקאות שנסגרו/אבדו, ופולו-אפים שחורגים מהזמן. |
| פרויקטים | כמות פרויקטים פעילים, פרויקטים תקועים (צווארי בקבוק), ומשימות באיחור. |
| ריטיינרים | תוצרים חודשיים שהושלמו אל מול המתוכנן, ומשימות הממתינות לאישור לקוח. |
| זמן עבודה | שעות עבודה מתוכננות מול שעות בפועל, פילוח שעות לפי לקוח או שירות. |
| תקציב | תקציב שנוצל, יתרת תקציב ללקוח, והתראות לפני חריגות תקציב. |
| מבט הנהלה | לקוחות בסיכון (חורגים מתקציב/זמן עבודה), עומס משאבים על הצוות, וסטטוס תפעולי חודשי. |
13. אימוץ, שיפור ואופטימיזציה לאחר העלייה לאוויר
החודשים הראשונים מיד לאחר העליה לאוויר הם הזמן שבו מתבצעת האופטימיזציה האמיתית. המערכת כבר תעבוד, אך השימוש היום יומי יעזור מאוד בדיוק של סטטוסים, אוטומציות, תבניות ודשבורדים. שלב זה חיוני בהפיכת המערכת החדשה לחלק אינטגרלי מהעבודה השוטפת .
| חבילת ליווי | מיקוד הפעילות |
|---|---|
| Light Support 5–8 שעות / חודש |
תחזוקה בסיסית, פתרון תקלות נקודתיות ושינויים קטנים במערכת. |
| Standard Support 10–15 שעות / חודש |
מומלץ ל-3 החודשים הראשונים: תמיכה שוטפת, ליווי צוות לאימוץ המערכת, שיפור תהליכי עבודה ושדרוג אוטומציות. |
| Growth Support 20–30 שעות / חודש |
להתרחבות מערכתית: בניית דשבורדים מתקדמים, הוספת מחלקות נוספות ואוטומציות Make מורכבות. |
14. המלצה לאישור
ההמלצה שלי היא לאשר כעת את שלב האפיון (אפשרות A) ונתחיל לאט ובטוח, או לחלופין לאשר מראש אפיון + POC (אפשרות B) אם ברצונכם להתקדם מהר יותר לשלב היישומי.
בכל בחירה, התהליך יהיה מדורג, שקוף ובשליטה מלאה — וללא התחייבות למעבר מלא לפני שהמודל מוכיח את עצמו בשטח.
לקראת יציאה לדרך, אשמח לאישור המסלול הנבחר.
שאול זיו – Peace of Mind