פריוריטי היא ברירת המחדל אצל הרבה מנכ"לים וחשבים בישראל. כשמדברים על ERP, היא השם שעולה קודם. Odoo נכנסת לשיחה כשמישהו רוצה אתר, קופה, ליד והנהלת חשבונות באותה מערכת, בלי עוד מחבר לכל דבר.
זו לא מלחמת מותגים. זו בחירה לפי איך העסק באמת עובד ביום שלישי בבוקר, לא לפי איזה לוגו מוכר יותר בישיבת דירקטוריון.
alt. מטמיעה Odoo בישראל, בשותפות עם דיגי (Digital with an Agenda), שותפת Odoo Ready. אנחנו לא מטמיעי פריוריטי. לכן נכתוב מה אנחנו רואים במעברים, לא טבלת מחיר שהעתקנו מאתר אחר, ולא סיפור שבו כל מעבר מסתיים בחיוך.
פריוריטי וחשבשבת הם לא אותו דבר
במאמרי השוואה בעברית לפעמים כותבים "Priority (חשבשבת)". זה לא נכון. מי שמערבב את השמות מערבב גם את המעבר.
- פריוריטי היא ERP מלאה. יש לה רשת מטמיעים גדולה, מודולי ייצור ושכר, ונוכחות חזקה בארגונים בינוניים. מי שחי שם שנים בדרך כלל חי שם עם התאמות, הרשאות, ומישהו בארגון שכבר יודע לסגור חודש.
- חשבשבת היא בעיקר הנהלת חשבונות, עם הרחבות. היא נפוצה אצל רואי חשבון ועסקים קטנים. מי שבא משם מביא ספרים, לא בהכרח אתר, לא בהכרח קופה, לא בהכרח מלאי חי.
המעבר מחשבשבת הוא סיפור אחד: הספרים כבר יש, וצריך מערכת שתחזיק גם את השאר. המעבר מפריוריטי הוא סיפור אחר: כבר יש מערכת שלמה, ויש לשאול מה בדיוק נשבר. אם אי אפשר להגיד מה נשבר במשפט אחד, עוד לא הגיע הזמן לעבור.
איך זה נשמע בעסק אמיתי
תמונה ראשונה. חנות עם דלפק ואתר. בבוקר יוצאות הזמנות מהאתר. בצהריים מישהו מוכר מעל הדלפק. בערב מנהלת החשבונות מנסה להבין למה המלאי באתר אמר דבר אחד והמחסן אמר דבר אחר. אם פריוריטי רצה בפנים והחנות רצה בחוץ, יש מחבר. המחבר עובד, עד שהוא לא. אז שולחים לספק שמונים מיילים, או מושכים דוח, או מתקנים ידנית "רק להיום".
תמונה שנייה. יצרן קטן. פריוריטי סגורה טוב על פקודות עבודה ועל שכר. האתר הוא סיפור נפרד, או שאין אתר בכלל. החשב מרוצה. הרואה חשבון מכיר את הסביבה. אף אחד לא קם בבוקר עם כאב אמיתי. במצב הזה מעבר ל-Odoo הוא אגו, לא עבודה. אנחנו אומרים להישאר.
תמונה שלישית. עסק שגדל על חשבשבת ואקסלים. ההזמנות בגיליון. הקבלות בתוכנה אחרת. הלקוחות בתיקייה. מישהו אומר "בואו ניקח פריוריטי, זה מה שכולם לוקחים". מישהו אחר אומר "בואו ניקח Odoo, יש גם אתר". שתי השיחות האלה מתחילות מהמקום הלא נכון. השאלה היא לא איזה מותג. השאלה היא איפה נולדת ההזמנה, איפה נולד הכסף, ואיפה נסגר החודש.
אצל אחד זה הזמנות שצריכות לצאת עם בצל. אצל אחר זה רכזת עם שלושה אקסלים. אצל החשב זה דוח שלא יושב על אותם מספרים שהאתר הציג אתמול. הצורך חוזר: מקור אחד להזמנה, למלאי ולמסמך.
יש גם ישיבה שחוזרת כמעט בכל השוואה. מסביב לשולחן: מנכ"ל, חשב, לפעמים רואה חשבון, לפעמים מישהו מהמכירות. על השולחן שני דפים. אחד של מטמיע פריוריטי שהארגון כבר מכיר. אחד של מישהו שמדבר על Odoo. השיחה מתחילה במחיר רישיון ונגמרת בלי שאף אחד תיאר איך נולדת הזמנה באתר. זו ישיבה מבוזבזת. לפני שמדברים על מותג, שואלים שלוש שאלות: מאיפה נכנסת הזמנה, איפה יוצאת הקבלה, ומי סוגר את החודש. בלי שלוש התשובות האלה, הטבלה למטה היא קישוט.
עוד תמונה, קטנה יותר. ספק מבקש העתק חשבונית. בפריוריטי מישהו יודע איפה למצוא אותה, כי ככה עובדים שנים. ב-Odoo בלי שכבה ישראלית הוא מוצא חשבונית, ולא מוצא קבלה, או מוצא קבלה בתוכנה אחרת. אחרי TransparO הוא מוצא את שניהם באותו לקוח. זה לא טיעון ניצחון. זה תיאור של הבוקר. אם הבוקר הזה לא כואב לכם, אל תעברו בשביל הסיפור.
איפה ההבדל בעבודה, לא בברושור
| נושא | פריוריטי | Odoo אצלנו |
|---|---|---|
| אתר ומסחר | בדרך כלל מערכת נפרדת ומחבר | אותו מקור נתונים לחנות, למלאי ולהזמנה |
| קופה וסליקה | חיבור לספק חיצוני | קופה ו-PayPlus על אותה מערכת. פירוט בקופות ואמצעי מכירה |
| הנהלת חשבונות ישראלית | חזקה, מוכרת לרואה החשבון | TransparO: קבלה, חשבונית-קבלה, הקצאה, PCN, שרשרת חתימות. לא רק l10n_il |
| CRM ומכירות | מודולים ותוספים לפי חבילה | ליד, הצעה, הזמנה, חשבונית בשרשרת אחת |
| ענן מול שרת | שני המודלים קיימים | אנחנו מריצים שרת ייעודי או סביבה שמתאימה ללקוח, עם staging ליד production |
| שפה וצוות | עברית מובנית, שוק גדול, הרבה ידיים בשוק | עברית מלאה אחרי הטמעה. הצוות מקומי. נשארים אחרי העלייה |
| גמישות שינוי | חזקה בתוך העולם שלה | מודולים, ופיתוח כשיש פער אמיתי, לא כשיש רעיון חמוד |
אין כאן שורת מחיר הטמעה. טווח בלי הקשר של היקף, מיגרציה ומודולים הוא פרסומת. בשיחת אפיון אפשר לדבר על סדר גודל לפרויקט ספציפי. לא לפני שיש מפה של מה רץ היום.
גם אין כאן שורה שאומרת ש-Odoo "מנצחת". פריוריטי יודעת לעשות עבודה טובה מאוד במקום שהיא כבר יושבת עמוק. Odoo נעשית הבחירה כשהאתר, הקופה, הליד והמסמך הישראלי צריכים לחיות באותה מערכת, ומישהו מוכן ללמוד מסכים חדשים.
שבוע רגיל בפריוריטי, כשהיא מתאימה: הזמנות נכנסות, ייצור או שילוח רצים, החשב סוגר, הרואה חשבון מכיר את הקבצים. האתר, אם יש, הוא ערוץ נפרד. מישהו מעביר הזמנות ביד או במחבר. זה עובד כל עוד נפח האתר קטן, או כל עוד יש אדם אחד שחי על המחבר.
שבוע רגיל ב-Odoo, כשהיא מתאימה: הזמנת אתר והזמנת דלפק נוגעות באותו מלאי. הקופה רושמת תשלום. אם שילמו במקום, יוצאת חשבונית-קבלה. אם שילמו אחר כך, יוצאת חשבונית ואחר כך קבלה. הליד מהאתר לא נשאר בתיבת מייל. החודש נסגר מתוך אותה מערכת. זה לא קורה בשבוע הראשון. זה קורה אחרי אפיון, staging, והדרכה למי שעומד בדלפק.
למי פריוריטי מתאימה יותר, ומתי אומרים להישאר
נשארים בפריוריטי כשהמערכת כבר חיה שנים, עם התאמות כבדות ושכר מובנה, ואין כאב אמיתי באתר או בקופה. נשארים כשהחשב דורש סביבה שהרואה חשבון כבר יודע לסגור עליה, ואין נכונות בארגון ללמוד מערכת חדשה. נשארים כשמכרז קובע פריוריטי במפורש.
במקרים האלה אנחנו לא דוחפים מעבר. לא כי אנחנו מנומסים. כי מעבר בלי כאב אמיתי הוא פרויקט יקר שנגמר בצוות שחוזר למסכים הישנים בראש, גם אם הלוגו על הדלת התחלף.
אבל רגע. "אין כאב" ו"יש הרגל" הם לא אותו דבר. אם כל הזמנת אתר נכנסת ידנית לפריוריטי, יש כאב. אם הקבלה יוצאת ממערכת אחרת, יש כאב. אם המנכ"ל רואה דוח מכירות ביום ראשון ודוח מלאי ביום שני והם לא מדברים, יש כאב. הרגל הוא לא אבחנה.
למי Odoo מתאימה יותר, ומתי שווה לזוז
Odoo מתאימה לעסק שמוכר גם בחנות וגם באתר, ורוצה שמלאי והזמנה לא יתפצלו. מתאימה למי שצריך קופה, סליקה והנהלת חשבונות בלי עוד ספק באמצע. מתאימה למי שיוצא מחשבשבת, מאקסלים, או מ-SAP Business One בקצה התחתון, ורוצה שכבה אחת קדימה. מתאימה לארגון שרוצה שרת ושליטה, לא רק רישיון ענן סגור.
השכבה הישראלית חשובה כאן יותר ממה שכותבים בהשוואות כלליות. l10n_il של Odoo נותן טבלת חשבונות וקודי מס. זה לא קבלה, לא חשבונית-קבלה, לא מספר הקצאה, לא PCN. TransparO היא המוצר שסוגר את זה. מי שמשווה פריוריטי ל-Odoo בלי השכבה הזו משווה ERP שלמה למערכת שנעצרת במס. פירוט: הנהלת חשבונות על Odoo בישראל.
דיגי נמצאת בשיחה כי כך אנחנו עובדים: הרישום בתיקיית Odoo Ready הוא של דיגי. הביצוע, השרתים ו-TransparO אצל alt. הלקוח שומע את זה לפני שהוא בוחר מערכת, לא אחרי שהוא כבר בתוך פרויקט.
מה כואב במעבר, בלי לייפות
המעבר הוא לא לחיצת כפתור. צריך למפות חשבונות, יתרות, פריטים, לקוחות, ומסמכים פתוחים. הצוות צריך ללמוד מסכים חדשים. הרואה חשבון צריך לראות סגירת חודש אחת או שתיים ב-staging לפני ייצור.
מה שכואב בפועל, לא בתיאוריה:
- יתרות שלא יושבות, ואז החודש הראשון נסגר פעמיים.
- פריטים עם שמות כפולים, ואז האתר מוכר דבר והמחסן מוציא דבר אחר.
- מסמכים פתוחים שנשארים במערכת הישנה, ואז יש שני מקורות חוב.
- חשב שצודק כשהוא אומר שהרואה חשבון עוד לא ראה PCN חי מהמערכת החדשה.
מה שחוסך כאב: לא להעביר "הכל" ביום אחד. קודם מסמכים וכסף. אחר כך מלאי ומכירות. אחר כך מה שנשאר. זה הסדר כשהיקף גדול. כשהיקף קטן אפשר לדחוס, אבל אי אפשר לדלג על staging.
סדר העבודה אצלנו, בלי באנר:
- נכנסים ורואים מה רץ: פריוריטי, חשבשבת, אתר, קופה, אקסל.
- מבינים מה נשבר במשפט אחד שאפשר להגיד בקול.
- מתכננים מה עוברים קודם, ומה נשאר ישן לתקופת גשר.
- בונים ב-staging, כולל הפקת מסמך ישראלי אמיתית.
- עולים לייצור עם גיבוי ורצפים.
- נשארים עם שרת, תחזוקה, בנק שעות.
אפשר לחבר Odoo לפריוריטי ולהשאיר את שתיהן. טכנית זה עובד. זה משאיר שני מקורות אמת. אנחנו עושים את זה רק כגשר קצר. גשר שנשאר שלוש שנים הוא לא גשר. הוא העסק החדש, עם עוד מערכת.
איך משווים בלי להפוך את זה למלחמת מותגים
שיטה קצרה שאפשר לקחת לישיבה הבאה, בלי יועץ ובלי טבלת אינטרנט:
- כתבו במשפט אחד מאיזו מערכת באים: פריוריטי, חשבשבת, SAP Business One, אקסל, או תערובת.
- כתבו במשפט אחד מה נשבר. אם אי אפשר, עוד לא משווים. עוד מדברים.
- סמנו איפה נולדת הזמנה, איפה יוצאת קבלה, איפה נסגר החודש. שלושה מקומות שונים הם כבר תשובה.
- שאלו את הרואה חשבון מה הוא חייב לראות בחודש הראשון במערכת חדשה. לא מה הוא רגיל, מה הוא חייב.
- רק אז פותחים דמו. קודם מסמך ישראלי ו-staging, אחר כך אתר מעוצב.
אם אחרי חמש הנקודות האלה פריוריטי עדיין עונה על הכאב, נשארים. אם Odoo עונה, ורק אם השכבה הישראלית מותקנת באמת, ממשיכים לשיחת אפיון. בלי לקפוץ ישר ל"כמה עולה המודול". בלי להחליט לפי מי שהכיר את השם קודם בצבא או אצל הספק.
שכר, מחיר, ומה לא נמדוד כאן
שכר בישראל לרוב נשאר במערכת שכר ייעודית. לא זה הקרב של הדף הזה. מי שבוחר ERP רק כי "יש בה שכר" צריך לבדוק קודם איזו מערכת שכר כבר רצה, ומי מדווח עליה. הרבה פעמים התשובה היא להשאיר את השכר איפה שהוא, ולחבר דיווח. לא להחליף את כל הבית בגלל מודול אחד. אותו כלל חל על מודול שמישהו ראה בדמו והתאהב בו. קודם הכאב, אחר כך המודול.
Odoo זולה יותר מפריוריטי? לפעמים כן בהרשאות ובמודולים. לפעמים לא, אם הפרויקט כולל מיגרציה כבדה ופיתוח. אל תקבלו החלטה לפי טבלת אינטרנט. אין כאן מספר. מי שצריך מספר מביא את היקף העסק לשיחה. מי שמביא צילום מסך מאתר מתחרה עם "החל מ", מביא פרסומת.
עוד טעות נפוצה בהשוואת מחיר: לחשב רק רישיון שנתי ולשכוח מיגרציה, הדרכה, שרת, ואת השכבה הישראלית. בפריוריטי השוק כבר יודע שיש מטמיע ושיש פרויקט. ב-Odoo לפעמים מישהו חושב שאפשר "להדליק מודולים". אי אפשר. בלי staging ובלי מי שסוגר חודש, מחיר הרישיון הוא המספר הכי פחות חשוב בחדר.
שאלות שחוזרות
פריוריטי וחשבשבת זה אותו דבר?
לא. פריוריטי היא ERP. חשבשבת היא בעיקר הנהלת חשבונות. מי שמשווה Odoo ל"פריוריטי" צריך לדעת מאיזו מערכת הוא בא. אחרת משווים תפוח ליומן.
Odoo זולה יותר?
לפעמים. לפעמים לא. ההרשאות והמודולים הם חלק. המיגרציה, ההדרכה והשכבה הישראלית הם חלק אחר. טבלת מחיר בלי היקף היא פרסומת.
אפשר להשאיר פריוריטי ולחבר אליה אתר Odoo?
אפשר לזמן קצר. אחר כך יש שני מקורות להזמנה ולמלאי. אנחנו לא בונים את זה כיעד.
מה עם הנהלת חשבונות ישראלית על Odoo?
בלי TransparO נשארים עם תרשים מסים. עם TransparO יש קבלה, חשבונית-קבלה, הקצאה, PCN ושרשרת חתימות. פריוריטי חזקה כאן כי השוק מכיר אותה. Odoo חזקה כאן רק כשהשכבה הזו מותקנת באמת, לא כסימון בתיבה.
יש לכם מעבר מתועד מפריוריטי או מ-SAP?
מעבר מ-SAP Business One ל-Odoo ביצענו ברשת אופטיקה, כולל היסטוריית מסמכים והנהלת חשבונות ישראלית. שם הלקוח לא נכתב כאן עד אישור. מעבר מפריוריטי: נכתוב סיפור כשיהיה לקוח מאושר לסיפור הזה. בינתיים נשארים עם הכנות, לא עם לוגו בדוי.
הצעד הבא
אם אתם משווים עכשיו: בואו עם מה שרץ היום, פריוריטי או חשבשבת או אחר, ועם מה שנשבר במשפט אחד. נגיד בכנות אם Odoo מתאימה, או אם עדיף להישאר. זו שיחה על עבודה, לא על מותג. מי שבא רק לשמוע ש-Odoo תמיד מנצחת, ישמע מאיתנו לפעמים את ההפך, ויחסוך פרויקט שלא היה צריך להתחיל.