השלבים של הטמעת פריוריטי כפי שהם קורים בפועל - בחירת שותף, אפיון, הגדרה מול פיתוח, הסבת נתונים, ממשקים דרך ה-REST API, עלייה לאוויר וסגירת החודש הראשון - ומה כל שלב דורש מהצוות שלכם.
עיקרי הדברים
- הטמעת פריוריטי עוברת שמונה שלבים, מבחירת השותף ועד סגירת החודש הראשון - השותף מגדיר, ואתם מחליטים.
- פיתוח בפריוריטי נעשה ב-SDK ויש לו כללים משלו: סביבות פיתוח, בדיקות וייצור, גרסאות שינוי וקידומת של ארבע אותיות.
- הסבת הנתונים עוברת דרך טעינת טבלה לטבלת ביניים וטעינה למסך שמפעילה את הטריגרים, ולכן נתונים מלוכלכים נכשלים בטעינה.
- ממשקים ניגשים רק למסכים שמנהל המערכת אפשר ל-REST API, ולכן מתכננים אותם בשלב האפיון ולא אחרי העלייה לאוויר.
- סגירת החודש הראשון, ולא העלייה לאוויר, היא המקום שבו הטמעת פריוריטי מוכיחה את עצמה.
הטמעת פריוריטי היא פרויקט שמעביר את העסק לעבודה במערכת פריוריטי בשמונה שלבים: בחירת שותף הטמעה, אפיון, הגדרה ופיתוח, הסבת נתונים מהמערכת הקודמת, ממשקים דרך ה-REST API, בדיקות והדרכה, עלייה לאוויר וסגירת החודש הראשון. הפרויקט מתקדם בקצב שבו אתם מקבלים החלטות ובודקים, לא בקצב שבו השותף עובד.
זה מה שמסביר למה פרויקטים דומים נמשכים זמן שונה לגמרי. השלבים שמשותפים לכל הטמעת מערכת - CRM, ERP או monday - מופיעים במדריך להטמעת מערכות בעסק. כאן נמצא מה שייחודי להטמעת מערכת פריוריטי: איך עובד בה פיתוח, איך טוענים אליה נתונים ומה צריך כדי לחבר אליה ממשקים.
מי עושה מה, ואיך בוחרים שותף הטמעה?
פריוריטי נמכרת ומוטמעת בעיקר דרך שותפי הטמעה, ולכן בפועל תעבדו עם השותף הרבה יותר מאשר עם יצרן התוכנה. החברה מספקת את המוצר, השותף מבצע את ההגדרות והפיתוח, ואתם מספקים את ההחלטות ואת האנשים.
| הצד | מה באחריותו | מה קורה כשהוא לא מספק |
|---|---|---|
| Priority Software | המוצר, העדכונים, התמיכה ברמת המוצר | נדיר שזה צוואר הבקבוק |
| שותף ההטמעה | אפיון, הגדרה, פיתוח, הדרכה | הגדרות חלקיות, התאמות שממשיכות לזלוג |
| אתם | החלטות, נתונים, בדיקות, זמינות | הפרויקט עוצר בשקט ואף אחד לא מדווח |
| מפתח ממשקים | חיבורים למערכות שנשארות | עלייה לאוויר עם עבודה ידנית בצד |
השורה השלישית היא זו שנמדדת הכי פחות ומעכבת הכי הרבה. שלוש שאלות מבדילות בין שותפים: האם הם הטמיעו בענף שלכם - לא כדי שיכירו את המוצר אלא כדי שיכירו את החריגים; מי מגיע בפועל לפגישות - מי שמכר או מי שיבצע; ואיך הם מגיבים לבקשה שלא כלולה - תשובה טובה מתמחרת אותה בנפרד ואומרת מה היא דוחה. בקשו גם שני לקוחות קיימים ושאלו אותם דבר אחד: מה הפתיע אתכם אחרי העלייה לאוויר.
מהם שלבי הטמעת פריוריטי?
- בחירת שותף. ניסיון בענף, צוות הביצוע, ואיך מטפלים בשינויי היקף.
- אפיון. מיפוי התהליכים הקיימים, החלטה מה משתנה, ורשימת פערים. כל פער יהפוך להגדרה או לפיתוח, ולכן כאן נקבע כל מה שבא אחר כך.
- הגדרה ופיתוח. מבנה החברה, הפריטים, ההרשאות והמסמכים מוגדרים במסכים הרגילים; מה שהמסכים לא יודעים לעשות הופך לפיתוח.
- הסבת נתונים. לקוחות, פריטים ויתרות פתוחות מנוקים, ממופים ונטענים מהמערכת הקודמת - יותר מפעם אחת.
- ממשקים. חיבורים לאתר, לחנות, ל-CRM ולכל מערכת שנשארת חיה.
- בדיקות קבלה והדרכה. אתם מריצים תהליכים אמיתיים מקצה לקצה, לא השותף, וההדרכה נעשית לפי תפקיד.
- עלייה לאוויר. יתרות פתיחה, הקפאת המערכת הישנה, ליווי צמוד בימים הראשונים.
- סגירת החודש הראשון. הפעם הראשונה שחודש שלם עובר דרך פריוריטי וצריך להתאים להנהלת החשבונות.
שלב 6 הוא זה שמדלגים עליו כשלוחצים על התאריך, והוא תמיד חוזר בשלב 8 במחיר גבוה בהרבה.
הגדרה או פיתוח: מה ההבדל בפריוריטי?
הגדרה בפריוריטי היא התאמת המערכת דרך המסכים הרגילים שלה. פיתוח (קסטומיזציה) הוא בנייה של טבלאות, מסכים, דוחות, פרוצדורות וטריגרים חדשים בכלי ה-SDK של פריוריטי. ההבדל חשוב, כי כללי הפיתוח של פריוריטי עצמה מחייבים תהליך שהגדרה לא דורשת:
- שלוש התקנות. ה-SDK מחייב סביבת פיתוח, סביבת בדיקות וסביבת ייצור, ומזהיר לעולם לא לפתח ישירות על שרת הייצור.
- גרסאות שינוי. פיתוח עובר בין התקנות כגרסה שמקובצת במסך Version Revisions, ותוכנית Prepare Upgrade מפיקה ממנה קובץ התקנה.
- קידומת של ארבע אותיות. כל ישות שמפתחים חייבת להתחיל בקידומת של ארבע אותיות (הדוגמה ב-SDK היא XXXX_CUSTOMERS), ואותה קידומת משותפת לכל מה שנבנה עבור אותו לקוח. שאלו את השותף מה הקידומת שלכם: כך תדעו מה במערכת שלכם הוא פיתוח ייעודי.
- אין כתיבה ישירה לטבלאות סטנדרטיות. הכללים אוסרים להוסיף או לעדכן נתונים בטבלאות הסטנדרטיות ישירות; הנתונים צריכים לעבור דרך ממשקים שעובדים מול המסך.
כל פיתוח הוא קוד שמישהו יצטרך לתחזק. לפני שמאשרים פיתוח לפער ברשימה, כדאי לשאול אם מסך רגיל כבר יודע לעשות את זה.
איך עוברים הנתונים מהמערכת הישנה לפריוריטי?
נתונים נכנסים לפריוריטי בדרך כלל דרך שני כלים של ה-SDK שעובדים יחד: טעינת טבלה (תוכנית DBLOAD), שמייבאת קובץ טקסט מופרד בטאבים לטבלת ביניים, וטעינה למסך (תוכנית INTERFACE), שמעבירה את הרשומות משם למסך האמיתי. קובצי Excel מומרים קודם לטקסט מופרד בטאבים, ואת הנתונים בטבלת הביניים אפשר לראות ולתקן במסך לפני הטעינה הסופית.
טעינה למסך מדמה משתמש שמקליד את הנתונים, ולכן היא מפעילה את הטריגרים של המסך: רשומה שהייתה נדחית במסך תידחה גם בטעינה, והממשק מדווח אילו שורות נטענו ואילו נכשלו. בפועל זה אומר:
- לנקות לפני הטעינה. פריטים כפולים ותיאורים חופשיים נכשלים בטעינה, או גרוע מזה, נטענים כמו שהם.
- להריץ טעינת ניסיון בסביבת הבדיקות. היא חושפת שדות חובה ובדיקות תקינות שאף אחד לא רשם.
- להחליט איזו היסטוריה עוברת. בדרך כלל מסמכים פתוחים ויתרות; ההיסטוריה המלאה נשארת לצפייה במערכת הישנה.
- להתאים כמויות וסכומים אחרי כל טעינה, מול הייצוא מהמערכת הקודמת.
ממשקים: חיבור המערכות שנשארות דרך ה-REST API
ה-REST API של פריוריטי מבוסס על OData, וממשק יכול לגשת רק למסך שמנהל המערכת אפשר לו במסך API Forms; מסכי המשנה מגיעים יחד עם מסך האב שלהם. אפליקציות שרשומות אצל Priority Software שולחות גם כותרות X-App-Id ו-X-App-Key, ובקשות בלי הכותרות האלה נחשבות רישוי API כללי - שאלת רישוי שכדאי לסגור עם השותף לפני שמתחיל הפיתוח. הפרטים של בנייה מעל ה-API נמצאים במדריך השטח ל-API של פריוריטי.
לאירועים שצריכים לצאת מפריוריטי ברגע שהם קורים, חוק BPM יכול להפעיל webhook, וזה דורש את רישיון מודול ה-Webhooks (ראו Webhooks וטריגרים בפריוריטי). הבקשה הנפוצה ביותר מהסוג הזה היא הודעת WhatsApp ללקוח כשנוצרת תעודת משלוח. היא צריכה שירות ביניים בין פריוריטי ל-Meta, אף פעם לא חיבור ישיר, כפי שמתואר בשליחת עדכוני WhatsApp מפריוריטי. תכננו כל ממשק כבר בשלב האפיון: כל אחד צריך סביבת בדיקות ומשתמש API משלו.
איפה הטמעות פריוריטי נתקעות?
- נתונים. רשימת פריטים עם כפילויות ותיאורים חופשיים היא חודש עבודה שאיש לא תכנן.
- תהליך שלא הוסכם. שני מנהלים מתארים את אותו תהליך אחרת, וההגדרה נעצרת עד שמישהו מכריע.
- בדיקות. "אין לנו זמן לבדוק" הוא המשפט שמייצר את החודש הקשה אחרי העלייה לאוויר.
- התאמות זוחלות. כל בקשה קטנה נראית סבירה; עשרים מהן הן פרויקט שני.
- אדם אחד שיודע הכול ויוצא לחופשה בדיוק ברגע הלא נכון.
לפרויקט שמתנהל טוב יש שלושה סימנים שרואים גם בלי להבין במערכת: פרוטוקול החלטות מעודכן, עם תאריך ושם ליד כל החלטה; רשימת פערים פתוחים שמתקצרת משבוע לשבוע; ובדיקות שמריצים אנשים מהעסק ומתעדים מה נכשל. כשאחד מהם חסר, הכול "בטיפול", שום דבר לא גמור, והתאריך זז בשבוע כל שבוע.
עלייה לאוויר וסגירת החודש הראשון
את העלייה לאוויר קובעים חמישה תנאים שאפשר לסמן, לא התאריך:
- תהליך מכירה מלא רץ מקצה לקצה על נתוני אמת, כולל המסמך והגבייה.
- יתרות הפתיחה הותאמו והוסכמו מול הנהלת החשבונות.
- כל ממשק פעיל נבדק בשני הכיוונים, כולל מקרה כישלון.
- לכל תפקיד יש מסך שהוא יודע לעבוד איתו בלי לשאול.
- קיים נוהל כתוב מה עושים כשמשהו לא עובד ביום הראשון, ומי זמין.
סגירת החודש הראשון היא המבחן האמיתי של הטמעת פריוריטי, כי זו הפעם הראשונה שמכירות, רכש, מלאי וקבלות נפגשים עם הנהלת החשבונות. לפני שסוגרים אותו, השוו את מאזן הבוחן ליתרות הסגירה של המערכת הישנה, בדקו את כמויות המלאי מול ספירה, אשרו את יתרות הלקוחות והספקים, וודאו שהדוחות שרואה החשבון צריך יוצאים מפריוריטי ולא מגיליון צדדי. האטה בעבודה בחודש הראשון היא נורמלית. מסמכים שנוצרים ידנית מחוץ למערכת, גיליון צדדי חדש או תהליך שאנשים עוקפים - לא: כל אחד מהם אומר שההגדרה פספסה משהו אמיתי, וזול יותר לתקן אותו בשבועיים הראשונים מאשר ברבעון הבא.
מה להכין לפני שהפרויקט מתחיל
רוב ההכנה הזו לא עולה כסף ומקצרת את הפרויקט יותר מכל דבר אחר. שבועיים לפני הפגישה הראשונה כדאי שיהיו על השולחן:
- רשימת התהליכים שהעסק מבצע, בשמות שלכם ולא בשמות של המערכת.
- רשימת המערכות שנשארות חיות, עם שם איש קשר לכל אחת.
- ייצוא של הלקוחות והפריטים כמו שהם היום, גם אם הם מלוכלכים.
- חמשת הדוחות שההנהלה באמת פותחת.
- רשימת החריגים - הלקוח שמקבל תנאים אחרים, הפריט שמתומחר אחרת, ההזמנה שעוברת מסלול מיוחד.
מבחינת אנשים נדרשים בעלים אחד לפרויקט עם סמכות להכריע בין מחלקות, איש תוכן לכל תחום - כספים, מלאי, מכירות - שזמין לשאלות, מישהו שמנקה את הנתונים, ובודקים עם זמן ביומן ולא "כשיהיה". רשימת החריגים היא ההפתעה: שותף שמקבל אותה בהתחלה מגדיר סביבה, ושותף שמגלה אותה בשבוע שלפני העלייה לאוויר מייצר פיתוחים דחופים ויקרים.
מקורות
שאלות נפוצות
כמה זמן לוקחת הטמעת פריוריטי?
זה תלוי בכם יותר מאשר בשותף. פרויקט עם תהליכים ברורים, נתונים נקיים וצוות זמין מתקדם מהר; אותו היקף בדיוק, עם החלטות שנדחות, יכול להיות ארוך פי שניים. זו גם הסיבה שהערכות זמן של שותפים שונים נראות כל כך שונות, ושמספר קבוע לפני האפיון הוא ניחוש.
אפשר לעלות לאוויר בפריוריטי בשלבים?
כן, ולרוב זה עדיף. נפוץ להתחיל בכספים ובמכירות ולהוסיף מלאי או ייצור אחר כך. הבעיה היא תקופת הביניים שבה שתי מערכות חיות במקביל, ולכן צריך להחליט מראש איזו מהן היא המאסטר לכל סוג נתון, מי אחראי להתאים ביניהן, ומתי בדיוק המערכת הישנה מפסיקה לקבל נתונים בתחום שעבר.
מה קורה למערכת הישנה אחרי המעבר לפריוריטי?
ברוב המקרים היא נשארת לצפייה בהיסטוריה לתקופה מוסכמת, בלי שמישהו מזין בה נתונים חדשים. כדאי לסגור מראש מי עדיין יכול להיכנס אליה, מתי היא נכבית ומה מייצאים ממנה לפני כן, כי היסטוריה מלאה נטענת לפריוריטי רק לעיתים רחוקות, ובדרך כלל עוברים רק מסמכים פתוחים ויתרות.
האם השותף יכול לפתח ישירות על מערכת הייצור שלנו?
לא. כללי ה-SDK של פריוריטי מחייבים התקנות נפרדות לפיתוח, לבדיקות ולייצור, ומזהירים לא לפתח על שרת הייצור. הפיתוחים עוברים לייצור כגרסאות שינוי אחרי בדיקה. שותף שמציע לפתח ישירות על הייצור כדי לחסוך זמן מדלג על השלב שמגן על הנתונים החיים שלכם.
כדאי לקחת מנהל פרויקט חיצוני?
זה משתלם כשאין אצלכם מישהו שיכול להקדיש לפרויקט זמן אמיתי ולהכריע בין מחלקות. מנהל חיצוני לא מחליף את ההחלטות שלכם, אבל הוא מוודא שהן מתקבלות בזמן, שרשימת הפערים מתקצרת משבוע לשבוע, ושמה שהשותף מסר תואם למה שהוסכם באפיון. הוא גם הצד שבודק את העבודה של השותף בשמכם.
להמשך קריאה
שירות רלוונטי
הסבת נתונים
לעבור מערכת בלי לאבד היסטוריה - מיפוי, פיילוט, דלתא ומעבר.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.