ההבדל האמיתי בין ריווחית לפריוריטי אינו רשימת פיצ'רים אלא נקודת המעבר: מה נשבר לפניה, מה עולה אחריה, ואיך יודעים שהגעתם אליה.
עיקרי הדברים
- ריווחית נשברת בתפעול לפני שהיא נשברת בכספים - זה הסימן, לא נפח המסמכים.
- פריוריטי אינה "ריווחית גדולה יותר": היא דורשת הגדרת תהליכים לפני ההטמעה.
- המחיר האמיתי של המעבר הוא הליווי והממשקים, לא הרישוי.
- רוב העסקים שעוברים מוקדם מדי משלמים על מערכת שאיש לא מגדיר עד הסוף.
ריווחית ופריוריטי לא מתחרות על אותו עסק. ריווחית מנהלת את הכסף והמסמכים של עסק שרוב התהליכים שלו לינאריים; פריוריטי מנהלת ארגון שבו כמה תהליכים רצים במקביל ומשפיעים זה על זה. המעבר נדרש כשהתפעול, ולא הנהלת החשבונות, הוא מה שנשבר.
מה כל מערכת נבנתה לנהל
ריווחית מציגה את עצמה כתוכנה לניהול עסק שכוללת הנהלת חשבונות חד-צידית או כפולה, כרטסת, מאזנים, התאמות בנקים, תזרים ומודול מלאי עם מעקב תנועות, מחסנים וכמויות מינימום. זו חבילה שלמה לעסק שמוכר, מפיק מסמכים, ומנהל מלאי בסדר גודל שאדם אחד יכול להחזיק בראש.
פריוריטי היא מערכת ERP מודולרית שבה אותו נתון משרת כמה תהליכים: הזמנה שמזינה ייצור, ייצור שמזין רכש, רכש שמזין עלות, ועלות שמזינה תמחור. כשעסק צריך שהמידע יזרום בין המחלקות בלי שמישהו יעתיק אותו - זו נקודת ההתחלה של פריוריטי.
מה נשבר לפני המעבר?
הסימנים אינם "יש לנו הרבה חשבוניות". הם נראים כך:
- מישהו מחזיק גיליון צדדי שבלעדיו התפעול לא עובד - תמחיר, יתרות, סטטוסים.
- אותו לקוח קיים בשלושה מקומות עם שלוש כתובות שונות.
- ההזמנה עוברת ביד מהמכירות לייצור או למחסן.
- אף אחד לא יודע מה הרווחיות של הזמנה מסוימת בלי לעבוד עליה חצי שעה.
- תהליך אישור קיים בראש של אדם ולא במערכת.
- ההנהלה מבקשת דוח ומקבלת אותו בעוד שלושה ימים.
ארבעה מתוך אלה ומעלה - השאלה כבר לא אם לעבור אלא מתי. אחד או שניים - כדאי קודם לתקן את התהליך, כי מערכת חדשה לא מתקנת תהליך שבור, היא מקבעת אותו.
מטריצת ההחלטה
| הממד | ריווחית מתאימה כש- | פריוריטי מתאימה כש- |
|---|---|---|
| מבנה התהליך | מכירה -> מסמך -> גבייה | כמה תהליכים משפיעים זה על זה |
| מלאי | מעקב תנועות ומחסנים | ייצור, עצי מוצר, אצוות, תמחיר |
| משתמשים | צוות קטן, תפקידים חופפים | תפקידים מוגדרים והרשאות שונות |
| התאמות | הגדרות בתוך המוצר | פיתוח והתאמות אצל שותף הטמעה |
| ממשקים | חיבורים נקודתיים | שכבת ממשקים מתוכננת |
| מה נדרש מכם | להתחיל לעבוד | להגדיר תהליכים לפני שמתחילים |
השורה האחרונה היא זו שמפילה פרויקטים. ריווחית מאפשרת להתחיל ולגלות תוך כדי; פריוריטי מחייבת החלטות לפני, ועסק שלא בשל להן משלם על מערכת שמוגדרת חצי.
מה קורה לנתונים במעבר
לא הכול עובר, וכדאי לדעת את זה מראש:
- כרטיסי לקוחות וספקים עוברים, בדרך כלל אחרי ניקוי כפילויות.
- פריטים עוברים, אבל המבנה משתנה - קטגוריות ותכונות נדרשות לעתים מחדש.
- יתרות פתוחות נטענות כיתרות פתיחה, לא כהיסטוריית תנועות.
- היסטוריית מסמכים נשארת ברוב המקרים במערכת הישנה, שנשמרת לצפייה.
- דוחות מותאמים נבנים מחדש - הם לא עוברים.
הסעיף החמישי הוא זה שמפתיע עסקים: הדוח שהמנהל מסתכל עליו כל בוקר במשך שש שנים לא עובר, ומישהו צריך להגדיר אותו מחדש. כדאי לרשום את חמשת הדוחות שבאמת משמשים לפני שמתחילים.
כמה זה עולה באמת?
לא הרישוי. שלושה רכיבים אחרים מכריעים את התקציב: ההטמעה (ניתוח, הגדרה, בדיקות), הממשקים למערכות שנשארות - סליקה, חנות, שילוח, שכר - וזמן הצוות שלכם, שלא מופיע בשום הצעת מחיר. פירוק מלא של הרכיבים נמצא במה באמת מייקר פרויקט ERP.
מה לעשות לפני שמחליטים
- למפות את התהליך שבאמת נשבר, ולא את כל התהליכים.
- לספור את הגיליונות הצדדיים ולשאול מה כל אחד מחזיק.
- לבדוק אם הבעיה בממשק ולא במערכת - לפעמים חיבור אחד פותר את מה שנראה כמו צורך להחליף הכול.
- לבקש הדגמה על התהליך שלכם, לא הדגמה כללית.
- לשאול מי מגדיר את המערכת אצלכם, בשם ובזמן.
השאלה הרביעית מסננת יותר מכל השאר: הדגמה כללית תמיד נראית טוב. הדגמה על ההזמנה המורכבת ביותר שלכם מגלה מה באמת ידרוש התאמה.
מה עולה להישאר יותר מדי זמן
הנטייה הטבעית היא לדחות, וזה נכון עד גבול מסוים. מעבר לגבול הזה העלות של ההישארות מתחילה להצטבר בשלושה מקומות שאיש לא מתקצב: שעות אדם שמתחזקות גיליונות במקום לעשות עבודה, החלטות שמתקבלות על סמך נתון ישן כי הדוח מתעכב, וטעויות שמגיעות ללקוח - הזמנה שנשלחה פעמיים, מלאי שהובטח ולא היה, מחיר שגוי שנרשם בהצעה.
הדרך היחידה למדוד את זה היא לספור שבועיים: כמה שעות בשבוע מושקעות בהעתקת נתון ממקום למקום, וכמה פעמים בחודש מישהו מתקן טעות שנוצרה בהעתקה הזו. שתי המספרים האלה, כפול שכר ממוצע, נותנים את עלות ההישארות. ברוב העסקים שמגיעים לשאלת המעבר, המספר גדול מכפי שהעריכו - ובחלקם הוא עדיין קטן מעלות הפרויקט, וזו תשובה לגיטימית לחלוטין שמצדיקה לחכות עוד שנה.
מה שכן לא כדאי לעשות זה להישאר בלי להחליט. עסק שדוחה בלי מספר מגלה את המעבר ברגע הגרוע ביותר - כשהוא כבר בצמיחה, כשהצוות עמוס, וכשאין זמן לאפיון. לקבוע מראש שני טריגרים מספריים - מספר עובדים או מספר הזמנות בחודש - הופך את ההחלטה מתגובה למשבר לצעד מתוכנן.
מה שתי המערכות לא יפתרו
שתיהן מניחות שמישהו בעסק יודע מה התהליך. אף אחת מהן לא תחליט עבורכם מי מאשר הנחה, מתי הזמנה נחשבת סגורה, או מה קורה כשלקוח מבקש שינוי אחרי שהוזמן חומר. אלה החלטות ניהוליות, והן אותן החלטות בדיוק לפני המעבר ואחריו. עסק שמצפה שמערכת תפתור אותן קונה תסכול יקר.
מקורות
שאלות נפוצות
אפשר להישאר בריווחית ולהוסיף מערכת לתפעול?
כן, וזה לעתים קרובות הפתרון הזול והנכון: ריווחית נשארת בכספים, ומערכת ייעודית או פיתוח מותאם מנהל את התפעול, עם ממשק ביניהם. זה שווה בדיקה לפני החלפה מלאה, במיוחד כשהכספים עצמם עובדים בסדר גמור.
כמה זמן לוקח מעבר לפריוריטי?
זה תלוי בכמות התהליכים והממשקים, לא בגודל העסק. מה שקובע את לוח הזמנים בפועל הוא זמינות האנשים אצלכם להגדרה ולבדיקות - זה הצוואר שמעכב כמעט כל פרויקט, ולכן כדאי להקצות אותו מראש.
פריוריטי מתאימה לעסק שירותים ולא רק לייצור?
כן. יש בה מודולים לפרויקטים, שעות ושירות. עם זאת, החוזק ההיסטורי שלה מורגש בעסקים עם מלאי וייצור, ולכן בעסק שירותים שווה לבחון גם מערכות שנבנו סביב פרויקטים ושעות לפני שמחליטים.
מה קורה לחיבורים הקיימים שלנו?
הם נבנים מחדש. חיבור לסליקה, לחנות או לחברת שילוח שעובד מול ריווחית לא עובר לפריוריטי, וזה רכיב תקציב שכדאי לספור מוקדם. ראו [שילוב פריוריטי עם מערכות דרך ה-API](/he/blog/priority-erp-api-integration).
להמשך קריאה
שירות רלוונטי
מערכות בהתאמה אישית
המערכת הפנימית שמחליפה את הגיליון שגדלתם ממנו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.