שירות ליבה
פיתוח פריוריטי
מערכת פריוריטי היא ERP גמישה — אך במקרים רבים ההתאמות שנתפרות במיוחד לארגון מביאות לחיסכון ורווח משמעותי. אנחנו מפתחים מודולים שלמים, מייעלים תהליכים עסקיים, ומפתחים גם במערכות עוטפות פריוריטי.
מה זה פיתוח בפריוריטי
התאמות שתופרות את המערכת לתהליך שלכם
התאמות (פיתוחים) נעשות כאשר המערכת הסטנדרטית אינה תומכת בתהליך העסקי כראוי. הפיתוח יכול להיות לצרכים קוסמטיים, אוטומציות בתהליכים עסקיים ועוד. ניתן לפתח כמעט הכל בפריוריטי — אך חשוב לתכנן ולבצע את ההתאמות בצורה נכונה וחכמה.
איך אנחנו עובדים
- אפיון מדוייק של התהליך העסקי והצורך
- פיתוח לפי סטנדרטים הדוקים — חלק אינטגרלי מהתוכנה
- עזרה למשתמש ותיעוד קריא בקוד
- ליווי, תמיכה ועדכוני גרסה לאורך הדרך
הטמעה מקצה לקצה
מחזור חיי פרויקט ההטמעה
אפיון
הכרה לעומק של הארגון והתהליכים, ובניית מסמך אפיון שמרכז את אבני הדרך.
בנייה והסבות
בניית ההתאמות והסבת הנתונים ממערכות קודמות — לקוחות, ספקים, פריטים ותנועות.
הדרכה ועלייה לאוויר
בדיקות, הדרכת משתמשים, התקנה בשרת האמת וליווי צמוד בשבועות הראשונים.
מה נכנס לזה בפועל
מה כולל תכנות פריוריטי
תכנות פריוריטי נעשה בתוך כלי הפיתוח של המערכת עצמה ובשפה הפנימית שלה — לא לצידה. הקוד יושב על אותן טבלאות שהמשתמשים עובדים איתן ורץ באותה טרנזקציה של המסמך, ולכן פיתוח שנכתב נכון מרגיש כמו חלק מהמערכת ולא כמו תוסף שהודבק עליה.
- פרוצדורות ותהליכים אוטומטיים
- מסכים, מסכי-בן וטפסים חדשים
- דוחות ומחוללי דוחות
- טריגרים ובדיקות תקינות על מסכים קיימים
- ממשקים לטעינת נתונים והוצאתם
- עבודה מול ה-REST API של המערכת
- קבצי עדכון להעברת פיתוח בין שרתים
שיקול דעת
מתי כדאי לפתח — ומתי עדיף לא
לא כל צורך מצדיק פיתוח, וחלק מהערך שאנחנו מביאים הוא לומר את זה מראש. שלושה מצבים שבהם פיתוח כמעט תמיד משתלם:
- עבודה ידנית שחוזרת — הקלדה כפולה, אקסלים בין מחלקות, דוח שנבנה ידנית כל חודש
- פער אמיתי בין המערכת לתהליך העסקי שהארגון עובד לפיו
- נקודת כשל שתלויה באדם אחד שזוכר מה לעשות
ושלושה שבהם עדיף לעצור:
- כשקיים במערכת פתרון סטנדרטי שפשוט לא מכירים — עדיף ללמוד אותו
- כשהתהליך העסקי עצמו עוד לא סגור — פיתוח יקבע אותו בטון
- כשמדובר בצורך חד-פעמי שאפשר לפתור בפעולה ידנית אחת
היום שאחרי
איך פיתוח שורד את עדכון הגרסה הבא
פיתוח פרטי, לא דריסה
הפיתוח נכתב כאובייקטים פרטיים בשמות ייעודיים במקום לשנות אובייקטים סטנדרטיים של המערכת. זה מה שמונע מעדכון גרסה למחוק את העבודה.
קבצי עדכון מסודרים
כל פיתוח נארז לקובץ עדכון שמעביר אותו משרת הבדיקות לשרת האמת בסדר הנכון — בלי הפתעות בהתקנה ובלי צעדים ידניים שמישהו שוכח.
תיעוד שנשאר אחרינו
עזרה למשתמש בתוך המסך, ותיעוד קריא בקוד עצמו. גם אם יום אחד תעבדו עם מישהו אחר — יש לו למה להיכנס.
מי עושה את זה
מה מבדיל מתכנת פריוריטי ממתכנת תוכנה
מתכנת תוכנה בונה מערכת מאפס ושולט בכל שכבותיה. מתכנת פריוריטי עובד בתוך מערכת קיימת שיש לה חוקים משלה: מבנה טבלאות נתון, שפת פיתוח פנימית, טרנזקציות של מסמכים, ועדכוני גרסה שמגיעים מהיצרן ועלולים לדרוס עבודה שנכתבה לא נכון. הידע הקריטי הוא לא בשפה — הוא במערכת.
אצלנו אין שרשרת של מי שמאפיין, מי שמפתח ומי שמסביר. אותו אדם שיושב איתכם על התהליך הוא זה שכותב את הקוד — וזה מה שמונע את הפער הקלאסי בין מה שסוכם לבין מה שנמסר.
אם הקוד כבר קיים ואף אחד לא יודע מה הוא עושה, השלב הראשון הוא מיפוי ותיעוד של מה שרץ במערכת — ורק אחריו החלטה מה לתקן ומה לכתוב מחדש. ואם הצורך הוא לחבר את פריוריטי למערכת אחרת — אינטגרציות.
לפני שבוחרים
איך מזהים מתכנת פריוריטי טוב
רוב הנזק במערכות שאנחנו נכנסים אליהן לא נגרם מקוד שלא עבד, אלא מקוד שעבד — ונכתב בלי לחשוב על היום שאחרי. כמה סימנים שכדאי לבדוק מראש:
- מבקש להבין את התהליך העסקי לפני שהוא מדבר על קוד
- יודע להסביר איך הפיתוח ישרוד את עדכון הגרסה הבא
- כותב תיעוד ועזרה למשתמש, לא רק קוד
- מוסר את הפיתוח בצורה שמאפשרת למישהו אחר להיכנס אחריו
- אומר גם מתי לא כדאי לפתח
היתרון שלנו כאן הוא שאנחנו גם מיישמים: מי שכותב את הקוד הוא מי שמכיר את התהליך העסקי שהוא משרת, ולכן יודע גם מתי התשובה הנכונה היא הגדרה במערכת ולא פיתוח.
מתי פונים אלינו
מתי ארגון צריך מתכנת פריוריטי
המערכת לא תומכת בתהליך
יש תהליך עסקי שהארגון עובד לפיו, והמערכת הסטנדרטית פשוט לא יודעת אותו. במקום להתאים את העבודה למערכת — מתאימים את המערכת לעבודה.
עבודה ידנית שחוזרת
הקלדה כפולה, אקסלים שעוברים בין מחלקות, דוח שמישהו בונה ידנית כל חודש. כל אלה הם בדרך כלל פיתוח קצר שמחזיר את עצמו מהר.
פיתוח קיים שנשבר
משהו שעבד שנים הפסיק לעבוד, או תוקע את המערכת, ואין את מי לשאול. צריך מי שיודע לקרוא קוד שלא הוא כתב ולהגיע למקור.
הספק הקודם כבר לא בתמונה
מצב נפוץ יותר משנדמה: מערכת עם פיתוחים משמעותיים, בלי תיעוד ובלי איש קשר. אפשר להיכנס פנימה, למפות מה קיים, ורק אז לגעת.
שאלות נפוצות על פיתוח פריוריטי
מה קובע כמה עולה פיתוח בפריוריטי?
לא היקף הקוד, אלא בהירות האפיון. פיתוח שהוגדר במדויק מראש מתומחר ומבוצע מהר; צורך שמתגלה תוך כדי הוא זה שמייקר. לכן אנחנו מתחילים באפיון כתוב ולא בהערכה בעל פה — כך ברור מראש מה נמסר ובכמה, בלי תוספות שמתגלות באמצע.
כמה זמן לוקח פיתוח בפריוריטי?
תלוי לגמרי בהיקף: התאמה נקודתית במסך היא לרוב עניין של שעות, מודול שלם הוא פרויקט של שבועות. גם כאן מה שקובע את לוח הזמנים הוא בדרך כלל האפיון, לא הכתיבה עצמה.
הפיתוח שלנו ישרוד עדכון גרסה?
פיתוח שנכתב לפי הסטנדרטים של המערכת — כן. פיתוח שעוקף אותם או משנה אובייקטים סטנדרטיים — לא תמיד, וזה מתגלה רק חודשים אחרי שהחשבונית שולמה. זה אחד ההבדלים המשמעותיים בין מי שמכיר את המערכת לעומק לבין מי שגרם לה לעבוד פעם אחת.
אפשר לפתח בלי לפגוע בתהליכים שכבר עובדים?
כן, וזו בדיוק העבודה. לפני שנוגעים בקוד קיים בודקים מה עוד תלוי בו — אילו מסכים, אילו תהליכים ואילו פיתוחים קודמים. בפריוריטי דברים מחוברים זה לזה יותר משנראה מבחוץ, ולכן המיפוי הזה הוא חלק מהפיתוח ולא שלב אופציונלי.
מה ההבדל בין פיתוח פריוריטי ליישום והטמעה?
יישום והטמעה הם התאמת המערכת הקיימת לארגון: הגדרות, מבנה נתונים, תהליכי עבודה והדרכה — בלי לכתוב קוד. פיתוח נכנס לתמונה כשההגדרות כבר לא מספיקות והמערכת צריכה לעשות משהו שהיא לא יודעת מהקופסה. ברוב הפרויקטים שני הדברים משתלבים.
יש לנו פיתוחים ישנים בלי תיעוד ובלי איש קשר — אפשר להמשיך אותם?
כן. אפשר להיכנס למערכת, למפות מה קיים, להבין מה כל פיתוח עושה ואיפה הוא נוגע, ורק אז להחליט מה לתקן, מה להרחיב ומה עדיף לכתוב מחדש. זה מצב נפוץ הרבה יותר משנדמה, ויש לו תהליך מסודר.
האם צריך מתכנת פריוריטי במשרה מלאה?
ברוב הארגונים לא. פיתוח בפריוריטי מגיע בגלים — פרויקט, ואחריו תחזוקה שקטה. מתכנת חיצוני שמכיר את המערכת שלכם נותן זמינות כשצריך בלי עלות קבועה, ובלי הסיכון שכל הידע יושב אצל אדם אחד שיום אחד עוזב.