מערכת בינה מלאכותית לרכש ממשלתי: זיהוי קנוניות וסיכונים

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

תחומי פיתוח AI

שאלות נפוצות

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

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

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

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

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

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

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

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

מה נותנת בינה מלאכותית ברכש ממשלתי: השפעות מדידות של בקרה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מסירת המערכת: מרשם כללים, סכמות נתונים, נהלים

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

לידי המזמין עוברים הדברים הבאים.

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

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

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

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

מה שינינו

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

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

תוצאה

בודקים את כל הזרם, ולא מדגם: כ-1,000 לוטים בחודש. שיעור האותות המאושרים עלה מאחד משמונה לשניים משלושה — מפקחים הפסיקו לבזבז זמן על רעש. ניתוח רכש אחד הצטמצם מ-3–4 שעות ל-25–30 דקות, ועבור אותות קריטיים הכרטיס נבנה אוטומטית: קשרי משתתפים, היסטוריית זכיות, סטיות מהתנהגות אופיינית. ברבעון הראשון הועברו לטיפול 14 חומרים עם מאפיינים של הסדרים כובלים.

במה שונה בדיקה לפי כללים ממודל למידה?

כללים עונים על השאלה «האם קיים מאפיין פורמלי», המודל — «עד כמה ההתנהגות שונה מהאופיינית».

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

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

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

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

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

ספקות טכניים: נתונים, התראות שווא, הרשאות

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

מה לעשות אם ייצוא הנתונים חסר ובפורמטים שונים?

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

באיזו תדירות המודל טועה ומה עם התראות שווא?

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

כיצד להתמודד עם מידע אישי של ספקים?

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

כיצד נשלטת איכות המודל לאחר ההפעלה?

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

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

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

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

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

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