קמעונאות · מוצרי חשמל אבי סופר
PrestaShop / Priority / Fireberry רשת סניפים ומכירה אונליין כשנה בפרודקשן
רשת מוצרי החשמל והאלקטרוניקה אבי סופר מוכרת גם אונליין, עובדת מול מגוון רחב של ספקים ומחזיקה כמה מחסנים. היא הפסיקה להקליד הזמנות. היום כל הזמנה שנסגרת באתר נכתבת אוטומטית בשתי המערכות התפעוליות, ואיתה נוצר כל מה שעוד לא היה קיים בהן: הלקוח, המוצר, הקטגוריה, המותג, היבואן ומחירון הספק.
ריצות רצופות ללא כשל, בחלון מדידה של יומיים
שניות, חציון זמן ריצה מקצה לקצה
אנחנו מספרים כל מקרה באותה צורה: לא רק מה היה האתגר ומה הייתה התוצאה, אלא איך תכננו את הזרימה ופתרנו אותה שלב-שלב. באוטומציה, ה"איך" הוא מה שמחזיק בפרודקשן. זה החלק ששווה לקרוא.
ברשת שמוכרת ממגוון רחב של ספקים נכנסים מוצרים חדשים כל יום. Priority ו-Fireberry לא ידעו עליהם. הזמנה שנסגרה באתר נעצרה כי המוצר לא היה קיים באף אחת מהן, ולפני שאפשר היה לפתוח אותו היה צריך לפתוח מעליו את הקטגוריה הראשית, את קטגוריית המשנה, את המותג ואת היבואן.
בפועל מישהו ישב והקליד. אותה הזמנה נרשמה פעמיים, בשתי מערכות, ידנית. שגיאת הקלדה אחת התגלתה רק במחסן או בגבייה, אחרי שהלקוח כבר שילם.
התהליך לא מעביר נתונים בין מערכות, הוא בונה בהן את מה שחסר לפני שהוא כותב. בכל הזמנה הוא יורד לרמת המוצר הבודד, בודק בכל מערכת בנפרד אם הוא קיים, ואם לא - מטפס בהיררכיה כלפי מעלה ופותח בדרך כל רשומה שנדרשת. רק כשהתשתית מוכנה נפתחות ההזמנה ושורותיה.
הכל פוצל לתרחיש ראשי ולארבעה תרחישי משנה: אחד אחראי על המוצרים, אחד על ההזמנה ב-Priority, אחד על ההזמנה ב-Fireberry, ואחד על המלאי. כל אחד מהם עומד בפני עצמו, נבדק בפני עצמו, ומוחלף בלי לגעת באחרים.
העברת הזמנה ממערכת למערכת היא חיבור פשוט. מה שקורה כאן אינו העברה. לפני כל כתיבה צריך להכריע מה כבר קיים, מה חסר, ובאיזה סדר לפתוח אותו, כי מוצר לא יכול להיווצר לפני המותג שמעליו, ושורת הזמנה לא יכולה להיווצר לפני המוצר. חיבור מוכן מראש לא מחזיק סדר תלויות ולא מחזיק מצב בין קריאה לקריאה.
פיתוח ייעודי כן היה יודע לעשות את זה. אבל אז כל ספק חדש, כל שדה חדש וכל שינוי בהיררכיית הקטגוריות היה חוזר לתור של צוות הפיתוח ומחכה שם.
ההקלדה הכפולה נעלמה. הזמנה שנסגרת באתר מופיעה ב-Priority וב-Fireberry עם כל שורותיה ועם כל רשומות הרקע שלה, בלי שאיש נגע בה. מוצר חדש מספק חדש כבר לא עוצר הזמנה, והוא לא מחכה למי שיפתח אותו ידנית.
בחלון המדידה האחרון, על פני יומיים, התהליך רץ 317 פעמים ברצף בלי כשל אחד. ביום הפעילות המלא שבתוכו נפתחו דרכו 183 הזמנות. חציון הזמן מרגע שהזמנה נסגרת באתר ועד שהיא קיימת בשתי המערכות עומד על 2.7 שניות.
בצד המכירות: יתרת המלאי של כל פריט, פר מחסן, יושבת ב-Fireberry. אין צורך להיכנס ל-Priority כדי לענות ללקוח אם משהו זמין.
שתיים מהמערכות בתהליך הזה, Priority ו-Fireberry, עובדות מול אפליקציות שאנחנו פיתחנו לפלטפורמה של Make, ולכן העומק שאפשר להגיע אליו בהן אינו העומק של חיבור סטנדרטי.
מעבר לזה, מה שהחזיק את התהליך לאורך זמן הוא היכולת לפרק אותו לחמישה תרחישים שקוראים זה לזה, לראות כל ריצה וכל שגיאה ברמת השלב הבודד, ולשנות חלק אחד בלי לגעת בשאר. זו עבודה שאנשי התפעול עושים בעצמם.
התהליך רץ בפרודקשן כשנה. בזמן הזה המערכות שהוא עובד מולן עברו שינויים ושדרוגים, והוא המשיך לרוץ.
תהליך שגוזל זמן לאנשים אבל אין לו בעלים מובהק לפיתוח. זה בדיוק מה ש-Make Enterprise פותר.