פיתוח פלטפורמת מכרזים: היכן נשברת לוגיקת המכרז
פיתוח פלטפורמת מכרזים הוא בראש ובראשונה עבודה עם מצב תחרותי, ולא עם טפסים ואזורים אישיים.
הצעות על לוט מגיעות מעשרות משתתפים באותה שנייה ממש, ואם רישום ההצעה וחישוב מחדש של המוביל הנוכחי אינם ארוזים בטרנזקציה אחת עם נעילת שורת הלוט, תקבלו בהכרח אי-סנכרון: שני משתתפים רואים את עצמם כמנצחים, והפרוטוקול מתעד שלישי.
במכרזים אלקטרוניים אמיתיים כשל כזה בהצעות הוא היקר מכל — הוא שובר את האמון בפלטפורמה ופותח את הדרך לתלונות ולבחינה מחדש של התוצאות.
הכשל הטיפוסי השני — לוטים תקועים. התקנון קובע חלון לקבלת הצעות, הארכה אוטומטית עם קבלת הצעה בדקות האחרונות וסגירה קשיחה. אם הטיימר חי בדפדפן של המשתתף או בשירות נפרד ללא מקור זמן אחיד, הלוט או לא נסגר בזמן, או נסגר פעמיים, או מקבל הצעה לאחר המועד האחרון.
זה מטופל באמצעות מתזמן בצד השרת עם מעברי סטטוס אידמפוטנטיים: הרצה חוזרת של המשימה לא אמורה לשנות את התוצאה.
האזור השלישי — עקיפת כללי הקבלה. משתתף ללא הסמכה, עם הסמכה שפגה או בניגוד עניינים לא אמור פיזית להגיע לשלב הגשת ההצעה. בדיקות שמפוזרות על פני הממשק נעקפות בקריאה ישירה למתודה; בדיקות שמרוכזות בשכבת כללים אחת לפני רישום ההצעה — לא. בנפרד אנו מתכננים ביקורת: מי, מתי ועל איזה בסיס התקבל או נדחה.
מפרקים כיצד זה נסגר: מודל טרנזקציוני של הצעות, טיימרים בצד השרת, שכבת קבלה אחידה ויומן שלפיו תוצאות המכרז משוחזרות באופן חד-משמעי.
מה נותנת פלטפורמת מסחר מנוהלת
מהירות המסחר וסגירת הלוט
הפלטפורמה מחזיקה את הלוט במצב אחד: הצעה, אישור, פרוטוקול — בלי העברה ידנית בין טבלאות לדואר אלקטרוני. צעד ההצעה וכלל ההארכה נקבעים במדיניות, ולכן המסחר מתנהל בצורה צפויה ולא תלוי במי מהמפעילים נמצא במשמרת.
בעומס של סיבובים בשיא, הזמן מהגשת ההצעה ועד פרסום הפרוטוקול מתקצר פי כמה — הודות לכך שחישוב המקומות ובדיקת הזכאות מתבצעים בצד השירות ולא ידנית.
עמידות ושיעור העסקאות המוצלחות
העמידות לתקלות נבנית סביב אידמפוטנטיות של פעולות: הצעה חוזרת אינה יוצרת כפילות, וניתוק הקשר אינו מאבד את ההצעה שהוגשה. שכפול בסיס הנתונים ותור האירועים מאפשרים שחזור בלי אובדן פרוטוקולים — סוג התקלה "ההצעה נשלחה אך לא נשמרה" נעלם לחלוטין.
שיעור העסקאות המגיעות לחתימה עולה, מפני שהמשתתף רואה את הסטטוס ואת היסטוריית פעולותיו, והמארגן — תמונה מלאה על הלוט.
שקיפות ובירור מצבים שנויים במחלוקת
כל פעולה מתועדת ביומן בלתי ניתן לשינוי: מי, מתי, מכתובת איזו ומה שינה. הדבר מסיר את רוב המחלוקות לאחר המסחר — ניתן להעלות את ההיסטוריה לפי לוט מסוים, ולא לשחזר אותה מהתכתבות. התפקידים וההרשאות מופרדים, ולכן הגישה להצעות של מתחרים חסומה ברמת מודל הנתונים ולא ברמת הממשק.
מה זה נותן לתחום
פלטפורמת מכרזים בפיתוח מלא מחזירה את ההשקעה לא ב"קבינט יפה", אלא ביכולת ניהול: פחות פעולות ידניות, לוחות זמנים צפויים לסיבוב, ביקורת ניתנת לשחזור. אנו מתכננים כך שהעומס יגדל בלי לכתוב מחדש את הליבה, וסוגי נהלים חדשים יתווספו בהגדרה ולא בהתאמה אישית לכל לקוח.
דרכים למימוש ליבת מכרזים
ליבת המסחר היא כללי הקבלה, צעד ההצעה, אנטי-צלף, פרוטוקולים וחיבור לשערי ЭТП. דווקא כאן הגישה למימוש קובעת מה ניתן לשפר ומה יצטרכו לעקוף. להלן שלוש אפשרויות אמיתיות שביניהן בוחרים בהתחלה.
| אפשרות | מתי מתאימה | מגבלות הגישה |
|---|---|---|
| פלטפורמה מוכנה | נדרש הפעלה בלוח זמנים מהודק, התקנון תואם לסטנדרטי | לוגיקת המסחר סגורה, לא ניתן להטמיע כללי קבלה וצעד הצעה משלך; אינטגרציות רק דרך מחברים תקניים |
| מודול מעל מערכת קיימת | כבר קיימת מערכת חשבונאית, נדרש רק קווי מתאר של מסחר | הליבה יורשת את מגבלות הבסיס: סכימת נתונים, הרשאות, פרופיל עומסים; תרחישים מורכבים של מסחר חוזר נתקלים בארכיטקטורה |
| פיתוח בהזמנה | התקנון ייחודי, נדרשים כללים משלך, ביקורת ודיווח | זמן ארוך יותר עד להשקה ראשונה, נדרש ליווי ותקנון שחרורים |
היכן נשברת פתרון מוכן
פלטפורמה סטנדרטית מכסה מכרז סטנדרטי, אך ברגע שמופיע הורדה עם צעד מההתחלתי, סינון מוקדמות או קבלה דו-שלבית — מתחילים תרחישי עקיפה. חלק מהלוגיקה עובר לפעולות ידניות, והפרוטוקול מפסיק להיות משוחזר.
מה נותנת ליבה בהזמנה
מודול מסחר משלך מאפשר לקבע כללים בקוד ולכסות אותם בבדיקות: חישוב הצעד, חיתוך הצעות מחוץ לחלון, קיבוע זמן השרת ולא הלקוח. התקנון משתנה בעריכת קונפיגורציה, ולא בשכתוב המעטפת.
את הבחירה יש לעשות מהתקנון: אם הוא סטנדרטי — מהיר יותר להתאים פלטפורמה מוכנה, אם הוא ייחודי — ליבה בהזמנה מחזירה את ההשקעה כבר בהליך הלא-סטנדרטי הראשון.
איך אנחנו מנהלים את הפרויקט: מהביקורת ועד למסירה
העבודה על פלטפורמת מכרזים מתחילה לא בקוד, אלא בתקנון: מי ועל בסיס מה מורשה להשתתף בהליך, מה הם מועדי הפרסום וההגשה, וכיצד נקבע הזוכה. כל עוד הכללים הללו לא מגובשים, כל סכימת נתונים תהיה שרירותית ותצטרך להיבנות מחדש. לכן השלב הראשון הוא ניתוח מסמכי הלקוח וההליכים הקיימים יחד עם הצוות שלכם.
- ביקורת התקנון. מנתחים את ההליכים, תפקידי המשתתפים, המועדים והעילות לדחייה. התוצר — מודל תהליכים מוסכם, שממנו נגזרים כל הכללים בהמשך.
- סכימת נתונים. מתכננים לוטים, בקשות, הצעות מחיר, מסמכים והיסטוריית שינויים. מטמיעים יומן פעולות בלתי ניתן לשינוי: עבור כל לוט ניתן לראות מי שינה מה ומתי.
- הגדרת כללים. מיישמים הרשאות השתתפות, שלבי ההליך, קביעת הזוכה אוטומטית והתראות. הכללים מוצאים אל מחוץ לקוד — שינוי בתקנון אינו מחייב כתיבה מחדש של הלוגיקה.
- בדיקת עומס. משחזרים את שיא הגשת הבקשות בדקות האחרונות: בודקים שהפלטפורמה עומדת בעומס בו-זמני ואינה מאבדת בקשות. בנפרד בוחנים תרחיש שבו כמה משתתפים מגישים הצעה באותה שנייה.
- בדיקת עמידות לתקלות. מתרגלים הפעלה מחדש של צמתים ושחזור מגיבויים, ומודדים את זמן החזרה לפעילות.
- מסירת המערכת. פורסים על התשתית שלכם, מוסרים תיעוד, תקנון תמיכה והרשאות גישה. מאמנים את מנהלי הפלטפורמה.
- תמיכה שוטפת. לאחר ההשקה מבצעים ניטור, מטפלים באירועים ומעדכנים את ההליכים בהתאם לשינויים בתקנון.
כל שלב מסתיים בתוצר שניתן לבדוק: סכימה מוסכמת, כללים מוגדרים, פרוטוקול בדיקת עומס, הנחיות למנהלים. אתם רואים את מצב הפרויקט בכל שלב, ולא רק בקבלה.
כללי הרשאה, תפקידים ויומן פעולות
תפקידים והרשאה מתוארים באופן הצהרתי: הלקוח מנהל ספר ארגונים, עבור כל אחד מגדיר סטטוס (לקוח, ספק, מארגן ההליך), סט פעולות מותרות ותחום נראות — אילו רכש ומסמכים המשתתף רואה.
כללי ההרשאה מעוצבים כמערכת תנאים שהמערכת בודקת לפני פתיחת הגישה: פרטים מאומתים והסמכה, היעדרות מפנקס הספקים הלא-הוגנים, תוקף תעודות ורישיונות. תנאי אינו מתקיים — המשתתף אינו מקבל גישה להליך, וביומן נרשמת סיבת הסירוב, ולא רק עצם העובדה.
הזכויות מופרדות לפי עקרון המינימום ההכרחי: המארגן מפרסם הודעה ושינויים, חבר הוועדה רואה הצעות ומתעד החלטה, אך אינו יכול לערוך תנאים לאחר הפתיחה, הספק עובד רק עם הצעתו שלו.
פעולות קריטיות — הרשאה, דחייה, שינוי מועדים — דורשות אישור של תפקיד שני, ולכן עובד אחד אינו יכול לבצע הליך לבדו.
יומן הפעולות — append-only: כל רשומה מכילה את המחבר, הזמן, האובייקט והתוצאה, רשומות קודמות אינן נערכות ואינן נמחקות. גיבוב שרשרת הרשומות מראה אם נעשה ניסיון לשנות נתונים בעקיפין למערכת, — זהו הבסיס לביקורת מכרזים. ייצוא היומן לפי הליך אורך שניות ומתקבל על ידי גופי בקרה כראיה.
מתאר כזה מכסה את הדרישות הטיפוסיות של החוק הפדרלי מס' 223-FZ ותקנות פנימיות של הלקוח: הפרדת גישה, עקיבות החלטות והגנה מפני החלפת נתונים לאחר סיום המכרז.
מה הלקוח מקבל לאחר ההשקה
השקה היא לא "מסרנו את האתר ונפרדנו לשלום". לאחר הכנסת הפלטפורמה לפעולה, הלקוח נשאר עם סט מלא של ארטיפקטים: לפיהם מהנדס חדש נכנס לפרויקט, התמיכה מטפלת בפניות בלי שיחות למפתח, ומשתתפי המכרזים עצמם מוצאים תשובות לשאלות טיפוסיות.
- קונפיגורציות סביבות — תיאורים של סביבות, פרמטרים של חיבור לרשמים ולשירותים חיצוניים, הגדרות של תפקידים והרשאות. פריסת סביבה חדשה מפסיקה להיות עבודה ידנית "לפי הזיכרון".
- תרשימי מערכת — מפה ארכיטקטונית: רכיבים, זרימות נתונים בין האזור האישי, חלק ההגשות ומאגר המסמכים, נקודות אינטגרציה. לפיהם ניתן לראות מה יקרוס בעת כשל של צומת ומה צריך להעלות ראשון.
- נהלי תמיכה — סדר העדכונים, חלונות עבודה, כללים של גיבוי ושחזור, פעולות בעת תקרית. התורן מבין מה לעשות לפני שמשהו נשבר.
- הוראות למשתתפים — מדריכים שלב-אחר-שלב לרישום, הסמכה, הגשה וחזרה של בקשה, עבודה עם חתימה אלקטרונית. מפחיתים את זרימת הפניות לתמיכה בתחילת המכרזים.
- הוראות לשירות התמיכה — תרחישים לטיפול במצבים טיפוסיים: הבקשה לא עוברת, המסמך לא נטען, הסטטוס של ההליך תקוע. עם תשובות מוכנות וגבול שבו מתחבר המהנדס.
- מודל תפקידים ומטריצת הרשאות — מי מהעובדים מה רואה ומה משנה: מארגן, מפעיל, מודרטור, צופה. ההרשאה נשללת כאשר אדם עוזב, ולא נשארת "ליתר ביטחון".
- רשימת אינטגרציות ותלויות חיצוניות — עם אילו מערכות הפלטפורמה מקושרת, מי אחראי על כל צד, מה לעשות כאשר שירות סמוך אינו זמין.
- יומן מסירה ותוכנית פיתוח — מה נכלל בגרסה הנוכחית, אילו שיפורים סוכמו כבאים בתור, אילו מגבלות ידועות. הלקוח רואה את גבול מה שנעשה ולא מצפה לניסים ממה שלא הוזמן.
סט כזה מסיר את הסיכון העיקרי של התמיכה — תלות באדם אחד ש"זוכר הכול". תארו את המשימה — נחזור עם הערכה ותוכנית, כולל הרכב התיעוד במסירה.
במה שונה מכרז סגור ממכרז פתוח?
מכרז פתוח הוא מצב שבו ההודעה, התיעוד והפרוטוקולים נגישים למעגל בלתי מוגבל של משתתפים, והגשת ההצעה מסתכמת ברישום ואישור כשירות. מכרז סגור, לעומת זאת, מניח סינון מוקדם: המארגן בונה מאגר של ספקים מאושרים, ורק הם רואים את התנאים ויכולים להגיש הצעה.
מנקודת המבט של הפלטפורמה מדובר בשני מעגלי גישה נפרדים, ולא בטופס אחד עם תיבת סימון של "פרטיות".
ההבדל מתבטא במודל הנתונים. במצב פתוח כרטיס המכרז ציבורי, ההצעות נראות בזמן אמת, והעומס על הקריאה גדול פי כמה מהכתיבה — לכאן מגיעים רובוטים של מנועי חיפוש, כלי אנליטיקה ומצרמים חיצוניים.
במצב סגור כל אובייקט קשור לרשימת משתתפים, ובדיקת ההרשאות מתבצעת בכל בקשה: לפני מסירת מסמך, לפני הצגת הצעה, לפני הורדת פרוטוקול. טעות בבדיקה זו משמעה דליפת מידע מסחרי, ולכן הגישה נשלטת ברמת הרשומות, ולא רק בכניסה למערכת.
מצבי הגישה קובעים גם את מחזור החיים של המכרז. הליך פתוח מאפשר הארכה, הבהרות ועדכונים פומביים — כל אלה נרשמים ביומן בלתי ניתן לשינוי. הליך סגור דורש מעגל נפרד של הזמנות, אישור השתתפות ולעיתים קרובות — הסכם סודיות לפני חשיפת התיעוד.
מכאן נובעות דרישות שונות לביקורת: במצב סגור חשוב להוכיח מי ומתי קיבל גישה, במצב פתוח — שהתנאים שפורסמו לא שונו בדיעבד.
בפועל הפלטפורמה כמעט תמיד תומכת בשני המצבים ועוברת ביניהם ברמת ההליך, ולא בהרכבה נפרדת. זה מאפשר לקיים סינון מוקדם, ולאחר מכן חלק סגור עם מעגל מוגבל — בלי כפילות של מכרזים והעברה ידנית של נתונים.
מקרה בוחן: פלטפורמה לרכש עם 40,000 מכרזים בשנה
הלקוח הגיע עם פלטפורמת מכרזים פעילה בפורמט חילופי נתונים תואם Сбербанк-АСТ: המכרזים פורסמו, אך בימי רכש גדולים המערכת לא עמדה בהגשת הצעות בו-זמנית.
עומס השיא חל ב-30 הדקות האחרונות לפני סגירת קבלת ההצעות — המשתתפים שלחו מסמכים בהמוניהם, התור גדל, חלק מההצעות נדחו עקב פסק זמן, ומקרים שנויים במחלוקת נבדקו ידנית ביומנים במשך כמה ימים.
מה שינו
פיצלו את המונוליט לשירותים של פרסום מכרזים, קבלת הצעות ובדיקת כשירות, והציבו ביניהם תור עם אספקה מובטחת ועיבוד אידמפוטנטי — שליחה חוזרת של הצעה כבר לא יוצרת כפילות. הוציאו את בדיקת החתימות ואימות חבילות המסמכים למתחם נפרד, כדי שפעולות כבדות לא יחסמו את הקבלה.
הגדירו התכווננות אוטומטית לפי פרופיל העומס: 10 דקות לפני סגירת המכרז עולים מעבדי הצעות נוספים, ולאחר מכן מתקפלים.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן פרסום מכרז | 40-60 שניות | 3-5 שניות |
| שיעור הכשלים בעומס שיא | 8-12% מההצעות | פחות מ-0.3% |
| בירור מקרה שנוי במחלוקת | 2-3 ימים ידנית | 2-4 שעות לפי יומן אירועים |
| הגשות הצעות בו-זמניות | ~1,200 | 15,000+ |
בנפרד סגרו את נושא הביקורת: כל פעולה עם מכרז והצעה נרשמת ביומן בלתי ניתן לשינוי עם חתימת זמן ומשתתף — בעת בירור תלונה רואים את כל השרשרת, כולל ניסיונות שליחה חוזרת.
מהירות בירור המקרים השנויים במחלוקת עלתה לא בזכות אנשים, אלא בזכות העובדה שהנתונים הפסיקו להיאסף בחלקים מיומנים שונים.
חצי שנה לאחר ההשקה הפלטפורמה מקבלת באופן יציב 40,000 מכרזים בשנה, וימי השיא הפסיקו להיות מצבי חירום — צוות הלקוח תורן לפי לוח זמנים, ולא לפי עובדת נפילה.
נדון במשימה שלכם ונחזור עם תוכנית
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם מילים כלליות, אנחנו צריכים מכם מינימום של הקשר: אילו נהלים מפעילה הפלטפורמה (מכרז, מכרז פומבי, בקשת הצעות), מי המשתתפים והמזמינים, כיצד מוגשות ההצעות כיום והיכן נשמרים המסמכים. זה מספיק כדי לפרק את ההיקף לשלבים ולהבין מה נעשה שימוש חוזר ומה מתכננים מאפס.
לאחר מכן אנחנו מקבעים את גבולות הגרסה הראשונה ואת הסיכונים: אינטגרציות עם מערכות חיצוניות, דרישות לחתימה ולתוקף משפטי, עומס בחלונות שיא של הגשת הצעות.
עבור כל סעיף אנחנו נותנים אפשרות פתרון ואת מחירה בלוחות זמנים — אתם רואים ממה מורכבת הערכת הפרויקט, ויכולים לקצץ או לדחות חלק מההיקף.
- ניתוח הנהלים והתפקידים שלכם: מי מגיש הצעות, מי מאשר, מי מסכם תוצאות.
- סכימת נתונים: לוטים, הצעות, מסמכים, פרוטוקולים, היסטוריית שינויים.
- תוכנית עבודה לפי שלבים עם סדר ותלויות.
- הערכת לוחות זמנים והרכב צוות לכל שלב.
- רשימת אינטגרציות ושירותים חיצוניים שיידרשו.
- אפשרויות השקה: היקף מלא או הכנסה מדורגת של מודולים.
- רשימת סיכונים ופתרונות שסוגרים אותם.
- פורמט תמיכה לאחר ההשקה ותקנון השיפורים.
תארו את המשימה בצורה חופשית — מהי הפלטפורמה, אילו נהלים, מה כבר קיים. נחזור עם הערכה ותוכנית עבודה שלפיה אפשר לקבל החלטה.
