Opero-Procurement by Agile-ERP
Priority נשארת מערכת הליבה.הרכש עובד לפי הארגון שלכם.
שכבה תפעולית מעל ה-ERP שמנהלת מי רשאי לבקש מה, באיזה תקציב, דרך איזה מסלול אישור ובאיזו רמת סמכות — בזמן שהזמנת הרכש הרשמית נוצרת ב-Priority ונשארת שם.
כבר פועלת בפרודקשן בשני ארגונים.
המשתמשים והתהליך
בקשה, אישור, מעקב, קבלת סחורה
Opero-Procurement
הרשאות · תחומי אחריות · תקציב · מסלולי אישור
Priority ERP
מקור האמת הפיננסי והארגוני
הבעיה
איפה מתנהלת העבודה בפועל?
ה-ERP מחזיק את הנתונים. אבל ברוב הארגונים, הפער בין המערכת לשגרת העבודה היומיומית מתמלא בכלים שקשה לנהל, לבקר ולסנכרן.
היום: עבודה מחוץ למערכת
- גיליונות תקציב
- בקשות במייל
- הודעות
- מעקב טלפוני
- אישורים בעל פה
- הזנה כפולה
Opero-Procurement
Priority — מערכת הליבה
- אקסלים של תקציב שמסתובבים בין מחלקות
- בקשות רכש שמגיעות במייל ובוואטסאפ
- אישורים שנשענים על מי ענה ראשון
- הזנה כפולה של אותה הזמנה — פעם בקובץ ופעם ב-ERP
כל אחד מאלה הוא פתרון זמני. בארגון שגדל, פתרונות זמניים הופכים לצוואר הבקבוק.
לא אב-טיפוס
תוכנה שעובדת בפרודקשן
Opero-Procurement אינה קונספט ואינה מצגת. היא מערכת פעילה, שכבר פועלת בפרודקשן בשני ארגונים ומריצה תהליכי רכש אמיתיים מהתקציב ועד קבלת הסחורה.
מוצר, לא פרויקט התאמה
פלטפורמה רב-ארגונית. מה שנראה כמו התאמה הוא בפועל תצורה: מבנה ההזמנה, רמת התקציב, תוויות ההיררכיה ומסלולי האישור מוגדרים לכל ארגון.
הבדיקות חוסמות, לא ממליצות
תצוגה מייעצת במסך אינה תחליף לבדיקה. הבדיקה המחייבת רצה בשרת, בהגשה ובאישור הסופי.
עברית מלאה, מימין לשמאל
לא ממשק שתורגם — ממשק שנבנה בעברית, כולל בנייד.
ההבדל המהותי
העסקה לעומת ההקשר התפעולי
ה-ERP בנוי סביב המסמך: מי הספק, מה הפריט, מה הסכום. Opero-Procurement היא השכבה שמעליו — זו שקובעת אם המסמך הזה בכלל אמור להיווצר, על ידי מי ובאיזה מסלול.
מה שמסמך רכש מתאר
שכבת העסקה
- ספק
- פריט ותמחור
- סכום ומטבע
- מסמך והזמנה
- רישום חשבונאי
מה שקובע אם ואיך המסמך נוצר
ההקשר התפעולי
- מי המשתמש הזה בארגון
- על איזה תחום אחריות הוא אחראי
- באילו סעיפי תקציב הוא רשאי להשתמש
- מה מותר לו לראות
- מה מותר לו ליזום
- מי אחראי לאשר את הבקשה הזו
- איזה מסלול אישור חל בהקשר הזה
- איזו רמת סמכות נדרשת
Priority לא משתנה. הארגון לא נדרש לשנות את מבנה ה-ERP שלו כדי להפעיל את השכבה התפעולית, ואין ספר הזמנות מקביל: הזמנת הרכש הרשמית נוצרת ב-Priority ונשארת שם.
מנוע האישורים
מסלול אישור לא חייב להיות משתמש ← מנהל ← ERP
מסלול האישור נגזר מההקשר: הסכום, הממדים הארגוניים של הבקשה, רמות הסמכות הרלוונטיות והספק. אותה בקשה בדיוק, בהקשר אחר, תנותב אחרת.
- בדיקת תקציב
- אישור אוטומטי
- בדיקת תקציב
- מאשר ראשון
- בדיקת תקציב
- מאשר ראשון
- מאשר שני
- בדיקת תקציב
- מאשר ייעודי
- המשך לפי סף
התרשים להמחשה בלבד. הספים, הממדים הארגוניים ורמות הסמכות מוגדרים לכל ארגון בנפרד.
ניתוב לפי סכום ולפי מבנה ארגוני
מסלול נבחר לפי סף סכום ולפי הממדים הארגוניים של הבקשה, ולא לפי תפקיד גנרי.
רמות סמכות ותוקף
לכל מאשר רמת סמכות ותחום אחריות, ולסמכות יש תאריכי תוקף — מאשר שתוקפו פג אינו מאשר.
מאשר ייעודי לספק
ספק יכול לשאת מאשר ייעודי שמחליף את המאשר הראשון במסלול.
דחייה עם נימוק
דחייה מחזירה את הבקשה לעריכה אצל המגיש, עם הסיבה שנרשמה.
היסטוריית אישורים מלאה
מי היה אחראי לשלב ומי אישר בפועל נשמרים בנפרד — כי לא תמיד מדובר באותו אדם.
בדיקת מסלול מראש
בודק תרחישים לקריאה בלבד: לראות איזה מסלול יחול, בלי לבצע דבר.
ביטול עם מסלול משלו
בקשת ביטול עוברת מסלול אישור בפני עצמה, ולא נסמכת על האישור המקורי.
לא מנתב מחדש בשקט
מסלול שאינו ניתן לשחזור מוחזר כשגיאת תצורה מפורשת, במקום להיבחר מחדש לבד.
רוצים לראות את זה על תהליך אמיתי שלכם?
לתיאום הדגמההרשאות ותחומי אחריות
לא רק Admin ו-User — הרשאות לפי המבנה הארגוני.
רוב המערכות שואלות איזה תפקיד יש למשתמש. Opero-Procurement שואלת על מה הוא אחראי — ומתוך זה נגזר מה הוא רואה, מה הוא רשאי ליזום ומה מגיע אליו לאישור.
פרופילי הרשאות
פרופיל מגדיר את היקף הפעולה לפי ממדים ארגוניים, ומשויך למשתמשים במקום להיבנות מחדש לכל אחד.
תחום אחריות
המשתמש רואה ופועל רק בתוך התחום שהוגדר לו — התקציבים, היחידות והבקשות שבאחריותו.
שיוך תפעולי
שיוך משתמשים ליחידות, למנהלים ולתקציבים. מכאן נגזרת הנראות התפעולית, ולא מהתפריט.
רמות אישור ותוקף
רמת סמכות לכל משתמש, עם תאריכי תוקף — כדי שסמכות זמנית לא תישאר פתוחה לנצח.
ההרשאות הן תשתית, לא הסתרה: הן נאכפות בשרת ובכל שאילתה, כך שמסך שאינו מוצג בתפריט חסום גם בגישה ישירה. ההפרדה בין ארגונים נשמרת בכל שאילתה ובכל ייצוא.
בקרת תקציב
המשתמש מתחיל מהתקציב — לא מהמסמך
זו לא הצהרת עיצוב אלא סדר הפעולות במערכת. במקום ליצור בקשה ורק אז לגלות שאין כיסוי, המשתמש רואה קודם מה זמין לו בפועל.
רואה את התקציב שלו
רק הסעיפים שבתחום האחריות שלו — הקצאה, ניצול ויתרה זמינה.
בוחר סעיף עם יתרה
סעיף שיש בו סכום זמין בפועל, לפי שנת הסעיף התקציבי ולא לפי שנת הלוח.
יוצר בקשה מתוך הסעיף
הבקשה נולדת בתוך ההקשר התקציבי, ולא מחפשת אותו בדיעבד.
הבדיקה חוסמת
חריגה מהיתרה הזמינה עוצרת את ההגשה. הבדיקה רצה בשרת, לא רק במסך.
הקצאה
יתרה זמינה
חריגה — ההגשה נחסמת
מנגנון שנכשל סגור: סעיף לא פעיל, סעיף שאינו סעיף הוצאה או סעיף ללא נתוני ניצול — חוסם ולא מנחש. ההנהלה מקבלת את אותה תמונה, בלי לבקש דוח מאף אחד.
איך זה עובד
מהתקציב ועד ההזמנה ב-Priority — בתהליך אחד
כל שלב מתועד ומסונכרן. אין הזנה ידנית כפולה, ואין שלב שקורה מחוץ למערכת.
המשתמש יוצר בקשה
Operoמתוך סעיף תקציבי שהוא רשאי להשתמש בו, עם ספק, שורות ותמחור.
המערכת קובעת הרשאה והיקף
Operoפרופיל ההרשאות ותחום האחריות קובעים מה מותר לו ליזום ועל מה.
נבדק התקציב
Operoהיתרה הזמינה נבדקת מול נתוני הניצול המסונכרנים. חריגה חוסמת.
נקבע מסלול האישור
Operoלפי הסכום, הממדים הארגוניים ורמות הסמכות הנדרשות.
האישורים מושלמים
Operoכל שלב נרשם: מי היה אחראי, מי אישר בפועל ומתי.
נוצרת הזמנה מחייבת ב-Priority
Priorityרק לאחר האישור הסופי. מספר ההזמנה הסופי נשמר חזרה במערכת.
מסמך ההזמנה נשלח לספק
Priorityמסמך ה-PDF הרשמי נמשך מ-Priority ונשלח לספק בדוא״ל.
קבלת סחורה וסנכרון
Priorityהקבלה נרשמת מול ההזמנה, נוצרת תעודה ב-Priority, והניצול מתעדכן בסנכרון.
הכשלים לא נבלעים: הזמנה שלא נוצרה, מסמך שלא הופק או סנכרון שנכשל מסומנים במפורש וגלויים למי שאחראי.
האינטגרציה
Priority נשארת מקור האמת
Opero-Procurement אינה מנהלת ספרים משלה. היא קוראת מ-Priority את נתוני האב שהתהליך צריך, וכותבת אליו את המסמכים המחייבים — אחרי שהאישור הושלם.
מגיע מ-Priority
- ספקים ונתוני האב שלהם
- סעיפי תקציב
- ניצול תקציב ויתרות
- שערי חליפין
- מסמך ההזמנה הרשמי (PDF)
נכתב אל Priority
- הזמנות רכש, לאחר אישור סופי
- תעודות קבלת סחורה מספק
- רישום ביטול
העיקרון שמנחה כל פעולה פיננסית
שגיאת תקשורת שאינה ודאית אינה אומרת שהפעולה לא בוצעה. המערכת בודקת מול Priority לפני שהיא כותבת שוב — כי מסמך כפול ב-ERP יקר יותר מניסיון נוסף.
Opero-Procurement מוצעת כיום כמוצר מוכן לאינטגרציה עם Priority ERP. חיבור למערכות ERP נוספות יכול להתבצע במסגרת פרויקט אינטגרציה ייעודי.
שאלות נפוצות
מה שנשאלים לפני הדגמה
האם Opero-Procurement מחליפה את Priority?
לא. Priority נשארת מערכת הליבה ומקור האמת, וכל מסמך פיננסי מחייב נוצר בה. Opero-Procurement היא שכבת העבודה התפעולית שמעליה.
למה לא להשתמש במסכי הרכש הסטנדרטיים של Priority?
אם הם מכסים את התהליך שלכם והמשתמשים עובדים איתם היטב — כדאי להישאר איתם, ואנחנו נגיד את זה גם בפגישה. תוספת שלא פותרת כאב אמיתי היא רק עוד מערכת לתחזק. השכבה משתלמת כשמסלולי האישור, ההרשאות והאחריות הארגונית מורכבים יותר ממה שהתהליך הסטנדרטי נועד לכסות, וכשחלק גדול מהמשתמשים אינם אנשי ERP.
האם מסלולי האישור יכולים לשקף את המבנה הארגוני שלנו?
כן. המסלול נבחר לפי סף סכום ולפי ממדים ארגוניים, עם רמות סמכות ותחומי אחריות. ספק יכול לשאת מאשר ייעודי שמחליף את המאשר הראשון. הספים והממדים מוגדרים לכל ארגון בתצורה.
האם למשתמשים שונים יכולים להיות תקציבים והיקפים שונים?
כן. פרופיל ההרשאות, תחום האחריות והשיוך התפעולי קובעים אילו סעיפי תקציב ואילו יחידות ארגוניות כל משתמש רואה ורשאי לפעול בהם. הכלל נאכף בשרת, לא רק בתפריט.
איפה נשמרת ההזמנה הסופית?
ב-Priority. ההזמנה נוצרת שם רק לאחר האישור הסופי, ומספר ההזמנה נשמר חזרה במערכת. מסמך ההזמנה הרשמי הוא ה-PDF של Priority.
איך מונעים הזמנות כפולות ב-Priority?
כל הזמנה נושאת אסמכתה. ניסיון יצירה חוזר מזהה שכבר קיימת הזמנה לאותה אסמכתה ומחזיר אותה, במקום ליצור מסמך שני. תוצאה לא ודאית נבדקת מול Priority לפני כתיבה נוספת.
האם המערכת מתאימה לעבודה מהנייד?
צפייה בתקציב, מעקב אחרי הזמנות ואישורים עובדים מהנייד. הגשת בקשה חדשה ומסכי הניהול נוחים יותר במסך רחב.
זה פיתוח ייעודי או מוצר?
מוצר. Opero-Procurement היא פלטפורמה רב-ארגונית שכבר פועלת בפרודקשן בשני ארגונים. ההתאמה לארגון נעשית בתצורה — מבנה ההזמנה, רמת התקציב, תוויות ההיררכיה, מסלולי האישור וכללי קבלת הסחורה.
בואו נראה איך תהליך הרכש שלכם יכול לעבוד.
הדגמה קצרה על תהליך אמיתי מהארגון שלכם: מי מבקש, מי מאשר, לפי מה, ואיפה השליטה נשחקת היום. בלי מצגת של 40 שקפים.