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

הבעיה בדרך כלל אינה במערכות עצמן.

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

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

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

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

ואז, אחרי כל ההשקעה הזו, מתחילה ההטמעה.

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

מתחילים לעבוד.

ודי מהר מתחילים להגיע הפידבקים מהשטח.

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

וכך נוצרת תחושת תסכול מוכרת מאוד בענף:

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

אבל זו לא בהכרח בעיה של המוצר.

זו הרבה פעמים בעיה של שיטת ההטמעה.

היתרון של עבודה אג'ילית ברשת מלונות

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

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

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

במהלך הפיילוט לא רק “מפעילים מערכת”.

בונים תהליך למידה.

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

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

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

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

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

דוגמה: מוצר צ'ט חכם באתר רשת מלונות

נניח שרשת מלונות רוצה להכניס לאתר שלה מוצר צ'ט חכם.

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

על הנייר, זה נשמע כמו פתרון מצוין.

המערכת יכולה להפחית עומס מהצוות, לשפר את חוויית האורח, לתת מענה מיידי 24/7, להגדיל הזמנות ישירות, ולייצר הכנסות נוספות משדרוגים ושירותים נלווים.

אבל בין ההבטחה לבין המציאות התפעולית יש פער שצריך לנהל.

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

נניח שהמוצר עולה כ-$500 לחודש למלון.

ברשת של 10 מלונות, מדובר בכ-$5,000 לחודש, כלומר כ-$60,000 בשנה – לפני עלויות אפשריות של הטמעה, אינטגרציה, הדרכה, התאמות וניהול פרויקט.

וזה עוד לפני שהרשת יודעת האם המוצר באמת עובד עבורה.

בגישה אג'ילית, לעומת זאת, הרשת מתחילה עם מלון אחד בלבד.

עלות רישוי לשלושה חודשי פיילוט במלון אחד תהיה כ-$1,500 בלבד.

במהלך התקופה הזו אפשר לבדוק:

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

לדוגמה, אם במהלך הפיילוט מתברר שהמערכת חסכה 20 שעות עבודה חודשיות לצוות, יצרה 8 הזמנות ישירות נוספות בחודש, והגדילה הכנסות מ-Upsell ב-$1,200 בחודש – אפשר להתחיל לבנות הצדקה עסקית אמיתית.

לא על בסיס הבטחה שיווקית.

על בסיס נתונים מהמלון עצמו.

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

ההחלטה אחרי הפיילוט

בסוף תקופת הניסיון לא שואלים רק האם המערכת “עובדת”.

שואלים שאלות עמוקות יותר:

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

זו בדיוק הנקודה שבה אג'יליות טכנולוגית הופכת ליתרון תחרותי.

לא כל מערכת צריכה להיכנס לכל הרשת.

לא כל מוצר מתאים לכל מלון.

ולא כל החלטה טכנולוגית צריכה להתחיל בחוזה גדול, תקציב שנתי והתחייבות ארוכת טווח.

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

כך רשת מלונות יכולה להכניס חדשנות בלי לאבד שליטה.

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

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

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

לא על מצגת מכירה.

מתוך נתונים, תפעול, אורחים וצוותים.

רוצים לבחון טכנולוגיה חדשה בצורה חכמה יותר?
דברו איתי.