פיתוח סוכן רכש AI (AI Procurement Agent)

הרכש מתעכב באיסוף ידני של מחירים ובאישורים: בקשות הולכות לאיבוד, תשובות ספקים מגיעות אחרי ימים. אנו מפתחים סוכן רכש AI במפתח מלא — הוא מנהל את השגרה מהבקשה ועד להזמנה, וההחלטות נשארות בידי אנשים. זמן הטיפול בבקשה מתקצר פי כמה, והשליטה בהוצאות ובמדיניות נשמרת.

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

סוכן AI לרכש: היכן נשבר תהליך האספקה הנוכחי

בקשת רכש מגיעה לעיתים רחוקות בפורמט אחד: דואר אלקטרוני, צ'אט עבודה, טבלה של המחלקה, הסכמה בעל פה אחרי ישיבת צוות. איש הרכש מאחד את הכול ידנית לרישום מרוכז, מברר את הקטלוג ומשלים שדות חסרים — ועיבוד בקשות הרכש מתארך עוד לפני שמופיעה הצעת הספק הראשונה.

מכאן מתחילות בדיקות ספקים ידניות. מחירים, מועדי משלוח, כמות מינימלית ותנאי תשלום חיים בהתכתבות ולא במסד נתונים משותף: ההשוואה נעשית לפי המכתב האחרון, והיסטוריית המחירים אינה נצברת בשום מקום.

אותו פריט בדיוק מופיע אצל ספקים שונים תחת מקטים ואריזות שונים — ההתאמה נשענת על הזיכרון של אדם מסוים ולא על כללים, ולכן בהיעדרו התהליך נעצר.

צוואר בקבוק נפרד הוא ההמתנה לאישורים. האישור עובר לאפליקציית מסרים, הולך לאיבוד בין דיונים אחרים, והיוזם מברר את הסטטוס שוב ושוב. בזמן שהבקשה ממתינה, תוקף הצעת הספק פג, מועד האספקה נדחה, וחלק מהפריטים עוברים לרכש דחוף בתנאים גרועים יותר.

המחיר של הקטעים האלה אינו בטעות אחת, אלא בהצטברות: חלק ניכר מהבקשות מתנהל מחוץ לרגולציה, משך הזמן מהצורך ועד להזמנה גדל, רכש דחוף הופך לנורמה, והחיסכון בתנאים אובד בלי שמבחינים בכך. צווארי הבקבוק בתהליך הרכש נמצאים כמעט תמיד לא במשא ומתן, אלא בהעברת נתונים ידנית בין אנשים. נבחן כיצד סוכן AI לרכש סוגר כל אחד מהקטעים האלה — מפענוח הבקשה הנכנסת ועד להזמנה מוכנה.

מה משתנה לאחר הטמעת סוכן רכש

השינוי הראשון ניכר במחזור הבקשה. בעבר איסוף הצורך, בדיקה מול הקטלוג, בקשת הצעות ואישור נמשכו ימים, וכמעט כל פעולה בוצעה ידנית.

סוכן AI לרכש אוסף נתונים ממערכת החשבונאות ומהדואר האלקטרוני, בודק מלאי וחוזים בתוקף ומעביר לאיש הרכש בקשה מוכנה עם חישוב — האדם מקבל החלטה ולא מעתיק מספרים.

שיעור הפעולות הידניות יורד לרמה שנראית בעומס המחלקה: רכש שגרתי עובר למסלול אוטומטי, ובאיש המקצוע נשארים פריטים לא שגרתיים, משא ומתן ועבודה עם סיכונים. זמן עיבוד הבקשה מתקצר פי כמה — ההמתנה לתשובת הספק והאישורים הפנימיים מתנהלים במקביל ולא בזה אחר זה.

איכות הנתונים על הספקים מפסיקה להיות תלויה בזיכרון העובדים: היסטוריית מחירים, מועדים בפועל ותלונות נשמרות ברישום אחד. שיעור האיחורים יורד בזכות התראה מוקדמת — הסוכן משווה את המועד הנוכחי להיסטוריה של הפריט ומעביר את הבקשה הלאה לפני שהאספקה נכשלת.

חלק מהשגיאות נעלמות לא במידה פחותה אלא לחלוטין: כפילויות של פריטים, רכש לפי מחירון מיושן, בקשות שאבדו, אישור תוך עקיפת הרגולציה. הבדיקה מתבצעת לפני השליחה ולא אחריה. הסוכן פועל בתוך 1С:ERP דרך הממשקים המובנים, ולכן הנתונים אינם סותרים בין הטבלאות למערכת החשבונאות.

מצבי העבודה של הסוכן: אוטונומיה ובקרה אנושית

מצב העבודה של הסוכן אינו הגדרה כללית של «הפעל אוטונומיה», אלא מדיניות ברמת קטגוריית הרכש. לכל קטגוריה נקבע בנפרד מה הסוכן סוגר בעצמו, היכן הוא חייב לעצור לאישור אנושי ואילו בקשות עוברות לטיפול בחריגים באופן ידני.

גישה כזו מאפשרת להתחיל מכללים וסקריפטים נוקשים ולהרחיב את גבולות האוטונומיה ככל שנצברת סטטיסטיקה, בלי לשכתב את האינטגרציה.

אפשרות מתי מתאים מגבלות
כללים וסקריפטים רכש חוזר של קטלוג קבוע, הסכמי מסגרת ארוכי טווח אינו עובד בקטגוריות חדשות, נשבר בבקשה לא סטנדרטית
אישור אנושי חודשי ההפעלה הראשונים, קטגוריות חדשות, הזמנות משמעותיות המהירות מוגבלת לזמינות המאשר, מצטבר תור בקשות
אוטונומיה בתוך מגבלות מעגל ספקים מבוסס, נפחים שגרתיים, ספים מוגדרים דורש מגבלות מעודכנות וניטור, יש לעדכן את הספים
טיפול בחריגים לאחר הפעולה זרימה גבוהה של בקשות שגרתיות, כללים מגובשים והיסטוריה מצטברת השגיאה נראית רק לאחר הפעולה, נדרשים יומן החלטות וחזרה מהירה לאחור

גבולות האוטונומיה נבחנים מחדש לפי הנתונים המצטברים: אם בקטגוריה הסוכן פועל זמן רב בלי חזרות לאחור וביטולים, הסף מועלה; לאחר סדרה של דחיות, הקטגוריה מוחזרת לאישור אנושי.

כל החלטה של הסוכן נרשמת ביומן עם הנימוק, התנאים שבשימוש ומקור הנתונים — לכן טיפול בחריגים אורך דקות ולא שעות של בדיקת התכתבות.

שלבי ההטמעה: ביקורת תהליך, תרשים, בדיקה, מסירה

את העבודה מתחילים לא בהגדרת המודל אלא בפענוח התהליך: מי יוזם את הבקשה, היכן מאשרים, באיזה שלב מצטרף הספק ואילו חריגים מטופלים ידנית. בלי זה הסוכן משחזר לא את הרגולציה אלא את ההרגלים של המחלקה — והפערים צפים כבר ברכש בפועל. להלן סדר שלבי ההטמעה של הסוכן, עם תוצר ונקודת בקרה בכל שלב.

  1. תיאור תהליך הרכש כפי שהוא. ראיונות עם אנשי הרכש, פענוח היסטוריית הבקשות והחוזים, תיעוד נקודות ההסתעפות ומעקפים ידניים. בתוצר — תרשים הזרימה עם ציון היכן ההחלטה ניתנת לפורמליזציה והיכן היא נשארת בידי האדם.
  2. מפת כללי קבלת החלטות. מהתיאור נגזרים התנאים: קטגוריה, מועד, היסטוריית הספק, סטייה של המחיר מהרגיל. כל כלל מקבל עדיפות וסימן שלפיו הסוכן מיישם אותו.
  3. תכנון החלטות הסוכן. מחלקים את הפעולות לשלוש קבוצות: מבצע בעצמו, מציע עם אישור, מעביר לאדם. בנפרד מגדירים את ההתנהגות כשאין מספיק נתונים — הבקשה לא «נתקעת» אלא עוברת לבדיקה ידנית ולחישוב פרטני.
  4. הקשר עם מערכת החשבונאות. מגדירים החלפת קטלוגים, בקשות, סטטוסים ומסמכים, והרשאות הסוכן מוגבלות לפעולות הנדרשות. כל החלטה נרשמת ביומן עם הנימוק וההפניה לכלל.
  5. בדיקה על נתונים היסטוריים. מריצים את הסוכן על רכש קודם ומשווים להחלטות בפועל. מחשבים את שיעור ההתאמות, מנתחים פערים: מדייקים כללים, ומקרים שנויים במחלוקת משאירים לאדם.
  6. קבלת התוצאה ומסירה. תרחישי בקרה במתחם העבודה, רגולציית חריגים, הכשרת אנשי הרכש ומסירת תיעוד עם מפת הכללים ונקודות הבקרה.

הגדרות הסוכן, מדיניות הרשאות ואינטגרציות

סוכן הרכש אינו פועל בוואקום: הוא קורא קטלוג, היסטוריית רכש ומגבלות ממערכת החשבונאות ופועל בשם החברה. לכן יחד עם הפתרון מועבר ללקוח כל המעטפת — מכללי בחירת הספק ועד סדר הפעולות של המהנדס התורן. להלן רשימת מה שנשאר אצל הלקוח ומתקיים ללא מעורבותנו.

  • הגדרות הסוכן — כרטיסים לפי מחלקות רכש: קטגוריות, ספי כמויות, עדיפויות ספקים, כללי בחירת תחליף, תנאי עצירה שבהם הבקשה לא ממשיכה הלאה.
  • מדיניות הרשאות ותפקידים — מי רואה את ההתכתבות, מי מאשר סטייה מהתנאים, מי משנה מגבלות. הסוכן פועל תחת חשבון שירות נפרד עם ההרשאות המינימליות הנדרשות, ולא כסופר-משתמש.
  • אינטגרציה עם מערכת החשבונאות — תרשים ההחלפה: אילו קטלוגים נקראים, באיזו תדירות, לפי איזה סימן מותאמים הפריטים; ההתנהגות כשלא ניתן לגשת למערכת וסדר הניסיונות החוזרים.
  • רגולציית הסלמה — תנאי עצירה והעברת משימה לאדם: פריט לא שגרתי, התנגשות תנאים, מחלוקת על תנאי אספקה, שתיקה של הצד שכנגד מעבר לתקופה שהוגדרה.
  • תבניות הודעות — נוסחי בקשות, תזכורות וסירובים בשפת הצד שכנגד, עם הצבת משתנים וכללי טון.
  • הוראות תחזוקה — היכן לראות את יומן ההחלטות של הסוכן, כיצד לשחזר מקרה מסוים, כיצד לחזור לאחור משינוי בהגדרות ולמי לפנות כשההתנהגות סוטה מהצפוי.

את הערכה מוסרים למאגר שלכם בניהול גרסאות: כל שינוי בהגדרות עובר סקירה ולא מתוקן «במקום». תארו את המשימה — נחזור עם הערכה ותוכנית מסירה.

מקרה בוחן: סוכן באספקה — מדדים לפני ואחרי

מה היה לפני ההטמעה

מחלקת האספקה טיפלה בבקשות ידנית: המהנדס פתח את המכתב, בדק את הפריט מול קטלוג הפריטים ב-1С, בדק מלאי במחסן, בירר מועדים עם היוזם ורק אז הרכיב חבילה לאישור. על כל שורה הושקעו 20–30 דקות, ומחזור אישור הבקשה נמשך עד 4–7 ימי עבודה.

ב-60–80 בקשות בשבוע התור הצטבר, וחלק מהפריטים עברו בעקיפת רגולציה דחופה — דווקא שם נוצרו פערים בקטלוג.

מה שינו ומה קיבלנו

מקרה הבוחן של אוטומציה ברכש נבנה לא על החלפת אנשים אלא על הסרת השגרה. סוכן הרכש מקבל בקשה מהדואר האלקטרוני ומטופס, ממיר את הפריטים לקטלוג, שולף מלאי, היסטוריית מחירים וספקים קודמים, מבקש בעצמו מהיוזם את החסר ושולח את החבילה במסלול האישור. איש הרכש מתערב רק במקום שבו ההחלטה חורגת מהכללים: פריט לא שגרתי, ספק חדש, חריגה מהמגבלה.

מדד לפני אחרי
בקשות ללא התערבות ידנית 0% 74%
מחזור אישור הבקשה 4–7 ימים 1–2 ימים
פערים בקטלוג 12% 1.5%
זמן איש הרכש לשורה 20–30 דק' 4–6 דק'

סוג התקלות שהוסר — פערים בקטלוג, כפילויות של פריטים ובקשות שנשלחו לאישור בלי תקציב מאושר — נסגר כבר בכניסה. העומס שהוסר ממחלקת האספקה לא הלך לזמן מת אלא לעבודה עם ספקים ולרכש דחוף במקום טיפול בתור.

במה הסוכן שונה מכללים וסקריפטים?

כללים וסקריפטים עובדים כל עוד הבקשה מגיעה בטופס מוגדר: הפריט נבחר מהקטלוג, הכמות היא שדה מספרי, הספק מהרשימה. תרחיש כזה ניתן לשחזור: כניסה זהה מניבה יציאה זהה, והתקלה חוזרת על עצמה במערך בדיקות ומתוקנת בעדכון של תנאי אחד.

הדבר נשבר בטקסט חופשי. «אותם מסננים כמו בפעם הקודמת, אבל יותר ובמשלוח למחסן» — על משפט כזה אי אפשר לכתוב כלל: יש עשרות ניסוחים אפשריים, ובקטלוג חמישה פריטים דומים עם מאפיינים שונים. מערך התנאים מתכסה בחריגים, כל חדש פוגע בקודמיו, ושיעור הבקשות שעוברות לבדיקה ידנית גדל.

הסוכן מפענח את הניסוח כולו: מזהה פריטים, מתאים אותם לקטלוג ולהיסטוריית הרכש, משלים תנאים חסרים — יחידת מידה, כפילות אריזה, מועד — ומסמן את מידת הביטחון בכל שורה. כשההתאמה אינה חד-משמעית הוא לא מנחש, אלא מנסח שאלת הבהרה למגיש הבקשה ומתעד את הסיבה.

הגבול עובר לפי מחיר הטעות. מגבלות, אישורים וביקורת נשארים בבדיקות דטרמיניסטיות: הסוכן מכין את הנתונים והנימוק, וההחלטה מתקבלת לפי כלל. זה שומר על עקבה ניתנת לשחזור לכל בקשה ומצמצם את הטיפול הידני בלי לאבד שליטה.

שאלות טכניות נפוצות לפני ההתחלה

לפני ההתחלה בודקים לא אם המערכת יודעת לקרוא מכתבים, אלא כיצד היא מתנהגת במקרים שנויים במחלוקת. להלן תשובות לספקות הנדסיות שלעיתים קרובות מכריעות את גורל הפרויקט.

מה קורה אם הסוכן טועה?

הסוכן אינו כותב ישירות למערכת החשבונאות: הוא מכין טיוטה עם נימוק והפניה למקור, והרישום עובר אישור לפי סף הביטחון. כל מה שמתחת לסף עובר לאדם בתור הטיפול, וההחלטות נרשמות ביומן — גרסת הכללים, נתוני הקלט, התוצאה.

כיצד המערכת מטפלת בבקשות לא שגרתיות?

הסטייה מזוהה לפי המבנה: קטגוריה חדשה, שילוב שדות לא אופייני, ניסוח לא מוכר. בקשות כאלה הסוכן לא משלים מדעתו, אלא מסמן ומעביר לאחראי בציון מה היה חסר להחלטה.

האם נדרשים שינויים במערכת החשבונאות?

בהתחלה די בקריאת קטלוגים והיסטוריית בקשות — העיבוד מתבצע במתחם נפרד עם השוואה. אם מערכת החשבונאות מוסרת נתונים דרך הממשקים המובנים, כמעט אין צורך בהתאמות, והכתיבה מופעלת לאחר עבודה במקביל.

האם יש מגבלות לפי קטגוריות ותפקידים?

את הגבולות קובע הלקוח: קטגוריות, צדדים שכנגד זמינים, תפקידים, מעגל המאשרים. קטגוריות עם תנאים לא פורמליים נשארות בידי האדם — הסוכן מכין סיכום אך אינו מקבל החלטה.

מי אחראי להחלטות הסוכן?

את הכללים והספים מאשר הלקוח, ומקרים שנויים במחלוקת תמיד בידי האדם: הסוכן מיישם את הרגולציה ולא מקבל החלטות. היומן מראה מדוע הוצע הפתרון, ועל הבקשה הסופית אחראי העובד שאישר אותה.

נדון במשימה: ממה נתחיל

השיחה הראשונה אינה מצגת של פתרון אלא פענוח של תהליך הרכש: מי יוזם את הבקשה, היכן היא מאושרת, באיזה שלב מופיע הספק ואילו חריגים שוברים את הרגולציה.

נדרש כל המסלול בשלמותו, כולל מעקפים ידניים וטבלאות שחיות מחוץ למערכת החשבונאות — דווקא שם הסוכן לרוב מניב תוצאה, ולא בחלק הייצוגי של התהליך.

ההכנה להתחלה מצד הלקוח היא מינימלית אך ממוקדת:

  • מדגם של רכש שהסתיים: בקשות, הצעות שהתקבלו, תנאים סופיים — בכל פורמט שבו הם קיימים;
  • קטלוגי ספקים ופריטים כפי שהם, בלי ניקוי מקדים: את איכות הנתונים נעריך בעצמנו;
  • מסלולי אישור ומטריצת אחראים — לפי קטגוריות, סכומים ויחידות;
  • הרשאות ונתונים למתחם הראשון: חשבון לקריאה בלבד, עותק של מסד הנתונים או סביבת בדיקות, ערוץ החלפה;
  • מגבלות על נתונים: מה אסור להוציא מחוץ להיקף ומה יש לאנונם לפני ההתחלה;
  • קריטריוני קבלה: מדדים שנקבעים לפני תחילת העבודה, כדי שיהיה עם מה להשוות את התוצאה בהמשך;
  • אחראי מצדכם, שמאשר את ההיגיון ומקבל את העבודה לפי שלבים.

עם נתוני הפתיחה האלה נכין תוכנית עבודה לסוכן: היקף המתחם הראשון, שלבים, הרכב הצוות, תלות הלוחות במידת מוכנות הנתונים ונקודות שבהן יידרש אישורכם. נחזור עם תוכנית והערכה במועד שסוכם, עם הנחות מפורשות — כדי שבהמשך נדון לא בציפיות אלא בצעדים ממוקדים.

תארו את המשימה בהודעה: אילו מערכות מעורבות, אילו נתונים זמינים ומה תרצו לקבל בסוף. נתקשר, נבהיר פרטים ונחזור עם הערכה ותוכנית הפעלה.