במהלך השבועות האחרונים הייתי צריך לבצע "רה-אורגניזציה" עם חשבונות הסלולר שלי, ומטבע הדברים הייתי צריך לכתת את רגליי לנקודות שרות של סלקום ואורנג', לשוחח בטלפון עם נציגי שרות ולחוות כמה דברים לא נעימים שאליהם תיכף ארחיב. אם יש משהו אחד שלמדתי מכל המבצע הזה, הוא כמה חברות הסלולר, כשזה מגיע לתחום ה-Call Center מפגרות מאחור בענק בהשוואה לחברות בחו"ל.
יצא לי לדוגמא השבוע למצוא שאחד מהקווים הסלולריים שלי לא פועלים. מדוע? שאלה טובה. חוב לא היה כי הוא שולם יום לפני כן, ולכן הייתי צריך למצוא קו טלפון אחר (סוף סוף מצאתי שימוש למס' 078 שלי) כדי להרים טלפון לאורנג' ולצעוק שיחזירו לי את הקו. עד שהגעתי לנציגה, היא ביקשה את מס' הטלפון שלי. נתתי. הפקידה מתקתקת את המס' ו…בום, "המחשב קרס" (אני חושב שהתוכנה נפלה ולא כל מערכת ההפעלה אבל ניחא). הבחורה אמרה שהיא צריכה להפעיל את המחשב מחדש. המתנתי שתפעיל מחדש, שתתחבר למערכות שלה ושוב נתתי לה את הפרטי קו שלי. מהרגע שנתתי תיזמנתי כמה זמן יקח למערכת להציג את הפרטים שלי. התוצאה? 28 שניות.
דוגמא אחרת: חידשתי את קו ה-DATA שלי בסלקום. לשם כך הייתי צריך להגיע לנקודת שרות. ישבתי מול מיכל, היא תקתקה את מס' הזהות שלי (כן, לא קל להסביר שיש לי רק קו DATA בלי טלפון של סלקום, כך שאין לי מושג מהו המספר הסלולרי שלי בסלקום) וקיבלה את הפרטים. זמן קבלת הפרטים היה יותר מרשים: 9 שניות. לאחר כל הבירורים היה צריך לשנות סטטוס של הקו שלי. האם יש לסלקום מערכת IM בין המחלקות השונות? כמובן שלא (גם לא באורנג'). מיכל היתה צריכה לחייג למחלקה בנתניה. היה תפוס, המתנתי. שוב חייגה, שוב תפוס. המתנה של עוד רבע שעה והופ – הפעם לא תפוס. היא ביקשה לשנות את הסטטוס ו…הופ, המחשב אצל ולדימיר, זה שאמור לשנות את הסטטוס על הקו שלי – קרס.
את הקריסות האלו אפשר לראות במקרים רבים גם בנקודות מכירה שונות המפוזרות בארץ ומחוברות לחברות הסלולר, וראיתי לא מעט מקרים כאלו.
אחד הדברים הידועים על חברות סלולר, זה שבניגוד לחברות סטארט-אפ, הן אינן מתקמצנות ברכישת ציוד. צריך שרת עם 4 מעבדים? מריצים פרוצדורה ורוכשים. צריך רשיונות לתוכנה מסויימת? אם יש הצדקה, מריצים פרוצדורה דרך מחלקת הרכש ורוכשים, כך שמבחינת "ברזלים" ותוכנה, אין בעיה לקנות ציוד, אבל השאלה היא: מדוע חוויית המשתמש היא בעצם כזו גרועה ואיטית?
גם בסלקום וגם באורנג' (ואני יכול לנחש שגם במירס ובפלאפון) נמצאת השיטה הידועה לעבודה בכל הקשור למכונות מחוברות מרחוק ו-Call Center: עבודה ב-RDP: המחשב מתחבר לשרת Windows, המשתמש מקבל סשן וכך הוא עובד ויש "מיפוי" של הציוד הפיזי (קוראי כרטיסים שונים, Tablet פשוט לחתימת לקוח וכו') דרך כניסות USB וכניסות אחרות לסשן RDP.
הבעיה בשיטה הזו? שהשיטה ישנה, בזבזנית משאבים, ולא יציבה (כל אותן קריסות).
נתחיל בעניין העבודה עם האפליקציות שהנציג צריך לעבוד איתן: הבעיה במקרים רבים שאלו אפליקציות שאינן ווביות וצריכות לרוץ על מכונת Windows כלשהי, מה שאומר שהשרת שמתחבר למכונה צריך שוב ושוב לעדכן את המסך בכל פעם שהמשתמש מזיז את העכבר ולהעביר בכל שניה מס' קילובייטים רק בגלל שהמשתמש לחץ לדוגמא Page Down או גלל את המסך עם העכבר. מה יוצא מכך? קילובייטים על קילובייטים של מידע שצריך הלוך ושוב לעבור בין שרת לתחנה רק בשביל לגלול את מסך האפליקציה. אם נשווה את העניין לכך שתחנה מריצה דפדפן והמשתמש מתחבר לדפדפן, הרי כמות המידע שצריכה לעבור תהיה פחות מעשירית ממה שעובר ב-RDP, כלומר אם נתרגם את זה מבחינת עומס, תהיה לנו ירידה מאוד משמעותית הן מבחינת כמות תעבורה, הן מבחינת עומס על השרת, ושיפור משמעותי מאוד בחוויית המשתמש עצמה: עלה הדף, הוא יכול לגלול כרצונו, השרת לא צריך לעדכן כל פיקסל בזמן העבודה מול הסשן RDP.
מדוע בעצם כדאי לחברות המחזיקות מרכזי תמיכה לעבור לאפליקציות ווביות? יש לכך מס' סיבות:
- תחזוקת תחנות קצה זולה בהרבה. כשהתומך צריך רק דפדפן (ואולי תוכנת RDP לתוכנות קנייניות), הרי שאז אפשר להתקין מערכות הפעלה אלטרנטיביות (כמו Linux) שאותן קל מאוד לתחזק מרחוק, להשתלט מרחוק ויש את כל מה שצריך בחינם. אין צורך לגשת לתומך אם יש לו בעיה: מתחברים אל התחנה שלו ואפשר להציג לו ישירות על המסך את הפתרון.
- מסלול הלימוד יותר קצר לתומכים חדשים: אפליקציות ווב עם ממשק ברור מאוד קלות ללימוד. הבה ניקח דוגמא מוכרת כמ פייסבוק. כל מפתח יכול לאמר שכתיבה של דבר כמו פייסבוק זה משהו לא קל וענק, אולם כמה אנשים אתם מכירים שיש להם חשבון בפייסבוק מתקשרים בהפעלה של השרות? לא הרבה.
- אין צורך בעדכון אפליקציות ווב לתחנות: עדכנת בשרת? התומך צריך ללחוץ F5 וברוב המקרים הוא יראה מיד את העדכון, כך שאם מתכנת מתקן משהו ומעלה זאת, העדכון מופיע מיידית, וזה פתרון מעולה למצב שבאמצע היום מאובחן באג נדיר והמכתנת יכול לתקן והמשתמש עושה Refresh ונגמרת הבעיה.
- פתיחות: אחד היתרונות המוחצים של אפליקציות ווב שהן ניתנות להרחבה די בקלות (יחסית), כך שניתן בקלות להרחיב את האפליקציה היעודית לחברה בתוספים ושרותים שונים. לדוגמא: אם תומך א' במכירות רוצה לשוחח עם תומך ב' בכספים, אפשר להוסיף בדף עצמו שרואה התומך את האפשרות לפתוח IM (נניח Jabber) ואז השניים יכולים לשוחח מבלי צורך להתחיל לחפש מס' טלפון, לחייג, לקבל תפוס ושאר בלבולים. במקרים רבים, התוספת קוד לאפליקציית ווב היא תוספת קצרה (לדוגמא: בבלוג זה, התוספת לצ'אט היא 4 שורות קוד פשוטות). אגב, קיימים מס' שרתי IM שהם בקוד פתוח ובחינם.
- עלות נמוכה: אין צורך בשרת חזק מאוד לשרת את כל התומכים והמוכרים (גם חיצונית וגם פנימית). שרת ווב עם מעבד Dual Core יספיק בהחלט לתת שרות למאות תומכים והמהדרין יכולים להוסיף שרת ווב נוסף (כמו אפאצ'י) וניתן גם להוסיף מכונה פשוטה שתריץ LVS לחלוקת עומסים אם יש צורך בכך. אם יש שרתי אפליקציות נוספים, ניתן לעבוד בשיטה של Back end Front End כאשר המשתמשים גולשים ל-Front End.
- יציבות: מערכת לינוקס מינימלית לתומכים הכוללת דפדפן ו-rdesktop להתממשקות עם RDP ו-KDE (או GNOME או Fluxbox) יספקו מערכת יציבה מאוד למשתמשים וניתן בקלות להתאים את המערכת שתיראה כאילו זה Windows רגיל. כל הפצת Linux מוכרת כבר תומכת בשאר הציודים אוטומטית (אם אלו נקודות מכירה לדוגמא) כך שאין צורך בחיפוש דרייברים, התקנה והגדרה.
לסיכום: אפשר לשפר בעלות לא גדולה מרכזי Call Center הן מבחינת ביצועים, יציבות וביחוד מבחינת מחיר התחזוקה השוטפת של התחנות והתומכים. אפשר להטמיע טכנולוגיות ווביות חדשות עם מערכות ווביות קיימותת מבלי לחשוש שיצרן תוכנה מסוים (SAP לדוגמא) לא תומך בתוסף זה או אחר. מבחינת פיתוח, לא חסרות שפות פיתוח שתומכות בשרותי ווב שונים ושרתי אפאצ'י (או IIS) תומכים כמעט בכל שפה. ההשקעה הראשונית למעבר לאפליקציות ווב אולי יקרה קצת (מבחינת המרה של דברים לווב) אך לטווח הארוך השקעה כזו מחזירה את עצמה מהרגע שמתחילים להוסיף דברים לאפליקציות ווב, דברים שיכולים לקצר את זמן העבודה והפתרונות של התומכים, והחסכון גם מתבטא בהדרכות. נקודה אחרונה שחשוב לזכור: ההגירה עצמה יכולה להיות בקצב שרוצים לעבור מכיוון שעדיין אפשר להשתמש באפליקציות קודמות דרך RDP.
הכל טוב ויפה, השאלה מתי חברות כמו סלקום ואורנג' יתחילו לחשוב על דברים כאלו ברצינות.