מהצעות מפוזרות להשוואה מנומקת: בנו אב־טיפוס לצוות הרכש עם Lovable

1לפני שמתחילים: מגדירים תוצר, לא מערכת רכש מלאה

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

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

2שלב 1: מנסחים את גבולות התהליך

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

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

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

3שלב 2: מגדירים שדות אחידים וכללי השוואה

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

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

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

4שלב 3: שומרים את כללי העבודה ב־Project knowledge

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

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

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

5שלב 4: בוחרים היכן יישמרו הנתונים

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

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

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

6שלב 5: בונים טופס שמאפשר לתעד חוסרים

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

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

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

7שלב 6: מגדירים קריטריונים שהצוות יכול להסביר

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

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

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

8שלב 7: בונים מסך השוואה שלא מסתיר פערים

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

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

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

9שלב 8: מוסיפים נימוק מתועד לבחירה

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

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

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

10שלב 9: מריצים תרחיש קבלה מקצה לקצה

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

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

11טעויות נפוצות שכדאי לעצור בזמן

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

12צ'קליסט לסיום האב־טיפוס

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

13כאן עוצרים: מאב־טיפוס לשימוש ארגוני

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

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