אסטרטגיה. תכנון. יישום.
יוסי ויזל - יעוץ אסטרטגי למערכות מידע
יישום מערכת NetSuite בחברת הפצה לשוק האמריקאי
חברת הפצה רב ערוצית (omnichannel)
המותג המוביל Doona הוא הסלקל הראשון בעולם, המשלב בצורה אינטגרלית עגלה עם גלגלים ביחד עם סלקל, כך שאין צורך לשאת את הסלקל ביד ואין צורך לחבר את הסלקל לעגלה או לפרקו. (ראה כאן סרטון על צורת ההפעלה שלו)
המוצר הוא פטנט ישראלי ייחודי. מרכז הפיתוח של החברה הוא בישראל, מטה החברה בהונג קונג, המפעלים בסין ובבורמה, וההפצה נעשית לכל העולם ע"י מספר חברות ומפיצים.
חברת SPDistrubtion היא חברת ההפצה לשוק הצפון אמריקאי.
החברה מנהלת את כל ערוצי ההפצה הקלסיים, על מנת למצות את כלל פוטנציאל המכירה שלה בשוק הענק הזה.
-
ערוץ B2B - רשתות retails ענקיות
החברה מוכרת לרשתות מהגדולות בארה"ב (Target, buy buy BABY, Dillards ועוד).
לכל רשת כזו מאות חנויות ברחבי ארה"ב ועשרות מרכזי הפצה לוגיסטיים (Distribution Centers).
כל התקשורת העסקית עם הרשתות (הזמנות, חשבוניות ועוד) מתנהלות בעזרת מערכות EDI של שידור מסמכים הלוך ושוב בין חברות ענק וספקיהן.
הזמנות אלו נוצרות ע"י קניינים במרכזי הרשתות ומכילות כמויות גדולות של פריטים. הזמנה אופיינית כזו יכולה להכיל מאות פריטים המסופקים לכמה חנויות או לכמה מרכזי הפצה (מרלו"גים) של הרשת המפוזרים ברחבי ארה"ב.
-
Drop Shipping
מעבר לחנויות פיזיות, רוב הרשתות מפעילות גם אתרי e-commerce למכירה מקוונת ללקוחותיהן.
כל הזמנה פרטנית שלקוח הרשת מבצע באתר שלה, עוברת אל מערכות המידע של הרשת (back office), משם אל ה EDI ומשם זורמת למערכת המידע של SPD.
להזמנת drop ship יש בחברה תהליך מיוחד. הזמנות אלו נשלחות ישירות ללקוח הסופי (ולא לחנות הרשת או למרכזי ההפצה שלה). ההזמנה מגיעה אל הלקוח הסופי כהזמנה שנשלחה אליו לכאורה ע"י הרשת, למרות שבפועל היא נשלחה ישירות מחברת SPD. חברת SPD היא המנוע מאחורי הקלעים של התהליך, אבל הלקוח הסופי לא רואה שום מסמך המאזכר אותה.
-
FBA - Fulfilled By Amazon
קבוצת חנויות אשר מוכרות את מוצרי החברה דרך אתר Amazon.
הלקוח הסופי קונה את המוצר ב Amazon. בעל החנות קונה כמויות גדולות למלאי שמנוהל אצלו או במחסני Amazon, והוא זה אשר שולח את ההזמנה ללקוח הסופי בשמה של Amazon.
-
ערוץ חנויות פרטיות
החברה מוכרת למאות חנויות פרטיות ברחבי ארה"ב. חנויות אלו קונות למלאי ובזמני אספקה מידיים.
חלק מהחנויות מעבירות גם הזמנות drop ship של לקוחות שלהן. גם כאן המשלוח הוא ישירות ללקוח הסופי.
לטובת חנויות אלו נבנה פורטל הזמנות מתוחכם.
-
ערוץ B2C - E-commerce
במקביל לכל הנ"ל החברה מפעילה גם חנות מקוונת על פלטפורמת Shopify.
כל ההזמנות מעל הערוצים, עוברות בזמן אמת בממשקים שעובדים 24X7 אל מערכת ה ERP של החברה.
לכל ערוץ יש תהליך עבודה שונה לגמרי, כאשר המטרה העסקית היא להפעיל אוטומציות רבות כל האפשר, כך שההזמנה תאושר, תגיע למחסן ותישלח ללקוח - בזמן הקצר ביותר האפשרי.
ניהול אלוקציות ערוצים
אחד האתגרים העסקיים העומדים בפני חברת הפצה רב ערוצית, היא השליטה באלוקציות המכירה לכל אחד מהערוצים, באופן כזה שאף ערוץ לא ייפגע, ולא תהיה קניבליזציה בין הערוצים השונים.
עבור הפריטים העיקריים של החברה החברה מנהלת אלוקציות "רכות" של המלאי הפיסי.
משמעות הדבר היא שבכל רגע נתון כמות היחידות שנמצאת פיזית במחסן החברה, מחולקת (מוקצה) עבור כל אחד מהערוצים. כל הזמנה שמגיעה מערוץ מסוים מאושרת רק אם באלוקציה המתאימה יש מספיק מלאי.
חשוב להדגיש שזו חלוקה וירטואלית ("צובעים" את המלאי). פיסית על המדף אין שום חלוקה וכל המלאי זהה (אין חלוקה למדפים שונים למשל).
כדי לשלוט בצורה עסקית חכמה על האלוקציות נבנה מנגנון שמאפשר להחליט על הקצאה חדשה של המלאי הקיים, בהתאם לנסיבות העסקיות. אם למשל בתקופת קורונה מזהים פחות מכירות בחנויות פיסיות והרבה יותר מכירות מקוונות, מנהל העסקים של החברה יכול בקלות לווסת את האלוקציה ו"להעביר" מלאי מאלוקציה אחת לאחרת.
כל מחסור באלוקציה מסוימת מפעילה התרעות למנהל העסקים של החברה, אשר צריך להחליט על ויסות פנימי של המלאי בין האלוקציות השונות.
היות ולמערכת NetSuite אין פתרון מובנה לניהול אלוקציות, פיתחנו מנגנון די מורכב שינהל בקלות את כל לוגיקת האלוקציות.
(הערה: ל NetSuite קיים מודול בשם Sales Channel Allocation. הוא ניבחן ונמצא לא מתאים לצרכים היעודיים שלנו.
EDI
כל התקשורת העסקית עם רשתות הענק מתבצעת בצורה דיגיטלית דרך מערכות EDI.
כדי לתקשר עם מערכות המידע של הרשתות (או בשפת ה EDI - לשדר "מסמכים") כל ספק חייב לבחור חברת ביניים שתהיה המתווך בין מערכת ה ERP שלו למערכות ה EDI של הרשתות.
אנחנו בחרנו במערכת Lingo של חברת eZCom שלה יש פתרון מובנה (פחות או יותר...) למערכת NetSuite.
התקשורת ("המסמכים") שעוברים בין החברה לרשתות הן:
-
הזמנת רכש מקנייני הרשת (850 document) - אשר הופכת להיות הזמנת לקוח בתוך ה ERP
-
הודעה של החברה על ביצוע משלוח (856) - Advanced Shipping Notice
-
חשבונית לתשלום מהחברה לרשתות (810)
בנוסף, לרשתות אשר מפעילות אתרים מקוונים יש צורך לדעת בזמן אמת את מצב המלאי שמוקצה לרשת, היות וזמינות המלאי האמיתית חייבת להיות חשופה ללקוח שקונה באתר שלהן. החברה מחויבת לכן להודיע לכל אתר מקוון של רשת על שינוי ברמת המלאי שמוקצה לרשת, על מנת שלא יווצר מצב שלקוח ירכוש מוצר באתר, ובדיעבד יתברר שאין מלאי עבורו. (הרשתות קונסות על כל אירוע כזה)
לצורך כך החברה משדרת אחת ליום מסמך Inventory Advice (846) אשר מעדכן את רמות המלאי באתרי הרשתות. כמוסבר לעיל, זהו אינו המלאי הפיסי של החברה, אלא רמת המלאי האלוקציה של הרשת.
בשנת 2023, לצורך התממקשות עם רשת Bloomingdale's הוספנו פתרון בתפישה טכנולוגית שונה לגמרי של חברת Cymbio הישראלית.
אינטגרציה עם Shopify
הזמינות וקצב ההזמנות של Shopify מחייב אינטגרציה אוטומטית מלאה 24X7.
הממשק עובד דו-כוונית:
כל הזמנה של לקוח יוצרת בזnן אמת הזמנה ב ERP
כל הזמנה שמשולחת ללקוח, מסונכרת חזרה אל Shopify עם פרטי המשלוח כפי שהתקבל מחברת השילוח. מערכת Shopify שולחת מייל ללקוח על מועד השילוח עם ה Tracking Number שמאפשר לו מעקב בזמן אמת על מצב המשלוח (לינק ישיר לחברת UPS).
מדיניות החברה היא לאפשר החזרות ולקבל החזר כספי. כל Refund שנעשה ב Shopify מעדכן גם הוא מיידית את מערכת ה ERP.
אחת לזמן חברת Shopify מעבירה את כל התשלומים (בניקוי עמלות) לחברה. מידע זה נבדק ומאומת אוטומטית מול תקבולי ההזמנות בפועל.
לצורך האינטגרציה עם Shopify בחרנו בפתרון של חברת Netscore ההודית (עם הרחבות והתאמות לצרכי לחברה).
בחנות ה Shopify הפעלנו כמה תוספים משלימים.
מעניין להזכיר את התוסף שמאשר אימות של כרטיסי אשראי (fraud detection) כדי למזער חשיפה לסיכונים כספיים לסוחרים הנובעים מהיכולת של רוכש לבטל את הקניה שלו מול חברת כרטיסי האשראי. תופעה זו בה הלקוח קיבל את ההזמנה, ולאחריה ביטל את התשלום, גורמת לנזק אדיר לסוחרים מקוונים.
למנוע זאת אנחנו מפעילים תוסף של Riskified (הישראלית!) אשר בודק את רמת האמינות של הקונה (על בסיס Big data ומודלים של AI) ולמעשה "מבטח" את הסוחר.
רק הזמנות אשר אושרו ע"י Riskified מאושרות ב Shopify ורק אז מוזרמות אל מערכת ה ERP.
מערכת לניהול המשלוחים - ShipStation
משלוחי החברה נעשים בדרכים שונות - בהתאם לערוץ השיווק, לסוג המוצר, ולרשתות הרשתות השונות.
אריזות המשלוחים גם הן נעשים בעזרת לוגיקה מוגדרת מראש הלוקחת בחשבון את ממדי ומשקל המוצרים, האם האריזות הן בקופסאות או על גבי משטחים (pallets), מה ניתן לארוז עם מה וכד'.
זהו עולם ומלואו וחיפשנו Addon ב Suiteapp מהשותפים העסקיים של NetSuite שייתן מענה מספק לכל הצרכים.
לצורך יישום מערך המשלוח בחרנו במערכת ShipStation עם אינטגרציה מקוונת ל NetSuite.
כל הזמנה שעברה את סבב האישורים (שונה מערוץ לערוץ), נדחפת בזמן אמת ל ShipStation לטיפולו המיידי של המחסן.
במערכת ShipStation ניתן להגדיר אוסף רב של Automation Rules אשר עושות את רוב ההחלטות אוטומטיות כמעט לגמרי. לדוגמה:
מיהו המשלח העדיף:
המערכת לוקחת את נתוני המוצרים (מימדים ומשקל) ואת כתובת המשלוח, ומתקשרת ב Online למערכות של UPS ושל FedEx.
לכל משלח יש גם כמה שירותים במחיר שונה, למשל משלוח סטנדרטי, משלוח תוך 2 שעות וכד'.
חוק אוטומטי יאמר לדוגמה: "אם ההזמנה היא מלקוח Shopify בחר את המשלוח הזול ביותר".
או "אם ההזמנה היא של לקוח רשת, בחר את המשלוח של חברת FedEx", וכד'.
הפקה של Shipping labels:
עם בחירת המשלוח הרצוי, המערכת מפיקה את המדבקה של UPS או FedEx עם כל פרטי המשלוח להדבקה על המשלוח, ונתונים אלו משודרים מיידית לחברת השילוח שנבחרה. בהמשך, בעת איסוף המשלוח, עובד חברת השילוח יסרוק את המדבקה ובכך תיווצר, בין השאר, התחייבות עסקית של החברה מול חברת המשלוח.
ניתן גם להגדיר שעלויות המשלוח תהיינה על חשבון חברה צד ג' - למשל הרשת שממנה לקוח ה dropshipping הזמין.
בחירת ביטוח:
ניתן להגדיר שמשלוח מעל סכום מסוים יבוטח ע"י חברת ביטוח מסוימת או אפילו חברת השילוח עצמה.
צורת האריזה:
ניתן להגדיר חוקי אוטומציה שיאמרו למשל "מוצר זה וזה ניתן לארוז יחד בקופסה מסוג כזה וכזה".
ניירת נלוות:
לכל רשת יש הנחיות ספציפיות משלה לגביי הניירת הנלווה כמו Packing list, BOL (Bill Of Lading) , וכד'.
אחד הצרכים המיוחדים במשלוח לערוצי DropShipping הוא הפקה של ניירת שהיא Branded, כלומר מסמך שיגיע ללקוח הסופי יראה בפורמט המדויק שהרשת הגדירה ה רכש ללא אזכור של חברת SPD.
הנחיות מפורטות נוספות:
כמו: נדרשת חתימת המקבל, חייב להיות מקבל מעל גיל מסוים וכד'.
SPS Bundle
חשוב להדגיש שהמערכת ShipStation איננה תומכת במשלוחים של LTL (Less than Truck Load). לצורת משלוח כזו, אנו נעזרים ב SPS bundle, שמייצר את כל הניירת הנדרשת.
בחירת המשלח נעשית ע"י קבלת הצעות מחיר למשלוח ממערכת חיצונית שמתקשרת למערכות המידע של כמה חברות הובלה וברוקרים (נכון לעכשו איננה אינטגרטיבית ל NetSuite).
אינטגרציה עם ShipStation
שני ממשקים רצים מסביב לשעון בין ShipStation ובין NEtSuite:
כל הזמנה שמאושרת ע"י מחלקת המכירות נדחפת אוטומטית ל ShipStation.
כל משלוח שנעשה ב ShipStation נדחף חזרה ל NetSuite ויוצר תנועת fulfillment עם כל נתוני המשלוח (כולל Tracking Number)
האינטגרציה פותחה ע"י חברת Novamodule על בסיס תשתיות של Celigo.
אינטגרציה עם PayPal
ישנם פתרונות רבים לתשלום בעזרת PayPal באתרי סחר אלקטרוני. זו צורת תשלום סינכרונית - הקונה בוחר מוצרים, ובקופה יכול לשלם בעזרת PayPal. הוא נכנס לחשבונו, משלם, ומיד מתעדכן באתר תשלום של הלקוח ואישור ההזמנה.
זהו המודל שמשמש גם אותנו בקניות ב Shopify (אם כי מחשבון Shopify של הלקוח ולא מחשבון ה PayPal שלו).
בכל אופן, עבור ערוץ המכירה לחנויות, מודל התשלום הוא הפוך. קודם כל מקבלים את ההזמנה ומאשרים אותה, ורק אז מבקשים את התשלום מהלקוח. התשלום יכול להעשות בכמה שיטות - אחת מהן היא תשלום ב PayPal.
זו צורת תשלום א-סינכרונית - אנחנו שולחים מייל עם בקשה לתשלום שבה לינק ישיר לתשלום ב PayPal , והלקוח יכול לשלם בכל רגע שירצה (או בכלל לא).
לצורת תשלום א-סינכרונית זו, לא מצאנו מענה ב NetSuite. לצורך הענין פיתחנו במיוחד (ע"י החברה ההודית Netscore), דף תשלום ספציפי להזמנה, בעזרתו הלקוח יכול לשלם בעזרת כרטיס אשראי או בעזרת חשבון PayPal. עם ביצוע התשלום, נוצרת מיידית ב NetSuite תנועת Deposit להזמנה, ואם התשלום בוצע במלואו ההזמנה נדחפת אוטומטית למחסן.
במקביל ובאופן אוטומטי, נרשמות ב Netsuite עמלות הסליקה של PayPal ומשויכות לחשבונות הכספיים בהתאם.
אינטגרציה עם Bill.com
בעוד ש NetSuite תומכת ברישום תשלום לספקים, Bill.com מספקת פתרון מקיף לכל תהליך התשלום לספקים, וגם, כמובן, מבצעת את התשלום בפועל.
קליטת החשבונית:
חשבונית ספק מתקבלת ב Bill.com כקובץ אקרובט, מנותחת מיידית ע"יהמערכת ועוברת אוטומטית למבנה של חשבונית.
המערכת מבצעת OCR חכם על החשבונית, ומנתחת את מבנה תדפיס החשבונית - הספק, הסכום, תאריכים ועוד.
המערכת משתמשת באלכוריתמים של AI כדי ללמוד את החשבונית, וכך למשל, אם בפעם הראשונה לא זיהתה בתדפיס החשבונית את שם ספק, הרי שלאחר שפעם אחת המשתמש יאמר לה מיהו, מכאן ולהבא היא תבצע זאת אוטומטית.
סבב אישורים:
בניית סבב אישורים על בסיס לוגיקה עסקית מגוונת (סוןג הספק,גובה החשבון, פריט החיוב וכד')
קונסולידציה של תשלומים לפי תאריך ה Due date
תמיכה באמצעי תשלום רבים (כ"א, ACH ועוד)
בנוסף הספק יכול להכנס לפורטל הייעודי של החברה ולדווח שם ישירות את החשבוניות לתשלום.
לקראת שנת 2024 החלפנו את היישום למוצר של FISPAN בשם "Treasury Ignition" כדי להשיג אינטגרציה מלאה עם בנק
J.P. Morgan. ראה כאן
ארכיטקטורה טכנולוגית
כל הארכיטקורה שלנו מבוססת אך ורק על מערכות SaaS בענן, מה שעשה את הצד הטכני של היישום יחסית קל.
המורכבות היתה בצד האפליקטיבי - עקב השונות הרבה בין תהליכי העבודה השונים, הצורך בתמיכה בשינויים לאורך כל הדרך (שינוי כמויות, שינוי מועדים, שינוי פריטים וכהנה וכהנה) כך שהתהליך "אינו ליניארי".
מערכת הליבה - ERP:
-
NetSuite one world
מערכות נוספות בשימוש החברה:
-
ShipStation
-
SPS portal
-
Shopify (עם תוספים ל Riskified, Addrexx ועוד)
-
PayPal
-
Bill.com
Bundles שהתקנו:
-
SPS
-
PayPal
-
Shopify
-
Addrexx
-
Celigo Integrator.io
-
Avalara לניהול מסי קניה והתנהלות מול רשויות המס במדינות הפדרליות (קרא כאן עוד בענין מסים בארה"ב)
לצורך היישום נעזרנו במיישמים לוגיסטיים ופיננסיים ובמחלקת הפיתוח (היכן שהיה צריך לפתח קוד ייעודי) של חברת Netcloud.
אתגר ניהולי משמעותי היה הצורך בתיאום בין צוותי פיתוח, יישום ותמיכה גלובליים (ארה"ב, הודו, פיליפינים) כשכל אחד מהם רואה זוית צרה וקטנה מהתמונה הגדולה - למרות שלכל שינוי באחד מהם יש השלכות על כל המערכת.
