יום רביעי, 7 באפריל 2010

מה כדאי לבדוק לפני שנכנסים ל – SaaS?

מאמר שכתבתי על רשימת הדברים שכדאי לבחון לפני שנכנסים ל- SaaS פורסם בדמרקר:

ארגונים מאמצים אפליקציות במודל SaaS (Software as a Service) בקצב הולך וגובר. התחומים הבשלים יותר בתחום ה-SaaS: CRM – ניהול המכירות, אימיילים, ERP, אפליקציות web conferencing, תחום השכר – במיוחד בישראל, ותהליכים סובבי-HR (תמריצים, הדרכה, גיוס, מבחנים וכד').
אולם האימוץ של SAAS בארגונים הנו "בשוליים" ולא בליבה. בסה"כ אחוז השימוש באפליקציות SaaS בארגונים כיום הנו נמוך (2.5% מתוך כלל התהליכים המנוהלים בארגון – מנוהלים ע"י אפליקציות SaaS, על פי מחקר של גולדמן סאקס) אך קצב הגידול הוא הנתון המעניין יותר (יגיע ל8.5% תוך 3 שנים). העובדה היא שארגונים יותר ויותר מכניסים SAAS לארגון (או יותר נכון – מוציאים ל SAAS). מאפיין בולט, בו נתקלתי גם בישראל: ארגונים לרוב מרוצים מאוד מהמודל. ארגון שנכנס ל-SAAS בדרך כלל ירצה להמשיך הלאה ולאמץ SAAS גם לתחומים אחרים, ויספר על יתרונות גדולים בהם נתקל לאחר הכניסה ל-SAAS שכוללים הרבה מעבר לנושא מבנה העלויות.


סממן נוסף להבשלת השוק בישראל (שהגיעה כשנתיים מאוחר יותר לאחר האימוץ המסיבי בארה"ב ובאירופה) הנו השאלות הפרקטיות שאנו מתחילים לקבל מארגונים, שתיים מהן לדוגמה – מתי כדאי לבחון גם את אופציית SAAS לצד האופציות הרגילות, וכמו כן, מהם השאלות שיש לבחון מול ספק ה-SAAS החיצוני? ובכן, איגדנו כאן מספר נקודות לבדיקה: נקודות לבדיקה פנימית (האם SAAS מתאים?), ונקודות לבדיקה חיצונית – מול ספק ה SAAS.

Checklist פנימי – האם התהליך המדובר מתאים ל SAAS או לא?
  • האם התהליך אותו רוצים לנהל הנו תהליך "כללי", אשר אינו ייחודי לעומת חברות אחרות? לדוגמה, תהליך גיוס בדר"כ דומה במהותו בין חברה לחברה, תהליכי מכירה פשוטים (ליד -> יצירת קשר ראשוני -> שליחת חומרים -> פגישת מכירה -> הצעת מחיר), תהליך הערכת עובדים. אם התשובה היא כן, התהליך יותר יתאים ל-SAAS שכן אפליקציית SaaS משרתת משתמשים רבים מארגונים שונים ואינה בנויה ספציפית לצרכי ארגון מסוים (מודל ה multi tenant). אין זה אומר שלא ניתן לבצע כל שינוי אבל השינויים לא יהיו שינויים מהותיים ברמת קידוד, אלא יותר בצורת התאמות שהספק בנה מראש.
  • האם האפליקציה יחסית "נישתית" ומופרדת מאפליקציות/ תהליכים אחרים? אם התשובה היא כן, התהליך יותר יתאים ל SAAS. בדר"כ אפליקציות SAAS הנפוצות הן אלה אשר לא מצריכות קישורים אדוקים עם הרבה אפליקציות אחרות בארגון, למרות שתמיד יהיה קשר כלשהוא (שכר – קשר ל HR, CRM – קשר ל ERP ולDW וכד').
  • האם יש צורך לגשת לאפליקציה ממיקומים גיאוגרפיים שונים? אין זו דרישה מחייבת, אך אם החברה הנה גלובלית ומבוזרת בהחלט יש יתרון לשימוש ב-SAAS – מודל המותאם מראש לצורך זה. שוחחנו עם מנמ"רים של ארגונים גלובליים שבהחלט ראו את הערך בהורדת "כאב הראש" והצורך לדאוג לביצועים טובים בצורה שווה במשרדי החברה השונים ברחבי העולם.
  • האם מדובר בתהליך חדש אשר לא נוהל קודם לכן בארגון? רוב האפליקציות החדשות נבנות מראש במודל SaaS. פשוט כי יש יותר דרישה בשוק, הסטארטאפים אוהבים את המודל שמאפשר להם להגיע ליותר שווקים שיתר קלות (לעתים גם בלי לעבור דרך המנמ"ר בכלל אלא ישירות מול המשתמש העסקי), והמשקיעים מרימים גבה כשהמוצר אינו במודל SaaS. כך שבאופן טבעי כל התהליכים החדשניים יותר יסופקו באמצעות SaaS, בין אם נרצה זאת או לא. כך, לדוגמה, כלים בתחום Web 2.0 וניתוח מדיה חברתית מסופקים כמעט לחלוטין במודל SaaS.

Checklist חיצוני – מהן השאלות שיש לשאול את ספק ה-SaaS?

  • האם הספק תואם את התקנה החשבונאית SAS70? חשוב במיוחד לחברות הכפופות לרגולציית SOX. למידע נוסף על הבעייתיות ב SAS70 - ראו את הפוסט הבא בבלוג מצוין של דני שומרון על SaaS.
  • חשוב לבדוק מהי רמת ה-SLA שהספק מתחייב אליה, ולבצע התאמות אם צריך (מהו אחוז הזמינות? מה קורה כשהספק חורג מרמה זו?)
  • מהו מיקום מרכזי המחשוב של ספק ה-SAAS? עדיפות לכמה מרכזי מחשוב. יש חברות עבורן הרגולציה מחייבת שמיקום ה- data center לא יהיה מחוץ לגבולות אותה המדינה.
  • תמיכה מקומית. אין מה לעשות, ארגונים בישראל לא אוהבים לדבר עם נציג מכירות של Amazon בחו"ל, ומעדיפים Point of contact מקומי. מיהו הנציג המקומי / החברה שתומכת בתהליך היישום וההטמעה של המוצר בישראל? ובתוך כך, גם נושא העברית – עד כה, נושא בעייתי ביותר. רוב ספקי ה-SAAS הבינלאומיים לא מספקים כיום עברית.
  • תאימות עם רגולציות מקומיות. האם באזל II בישראל מאפשר שימוש ב-SAAS? תחת אילו תנאים?
  • הגדרה דקדקנית של התהליך במקרה והלקוח מעוניין להפסיק את השירות – כיצד הלקוח מקבל את המידע? מה קורה כשלקוח לא משלם? סעיף זה נועד להפחית את רמת ה Lock-in שקיימת באופן טבעי, שכן המידע "יושב" אצל הספק.
  • עריכת תכנית "גיבויים" פרטית של הלקוח. מעבר לגיבוי שהספק מתחייב אליו, אנו ממליצים לשכפל את המידע לתוך הארגון. יש לבדוק מראש האם וכיצד ניתן לבצע זאת.
  • מתי הספק מבצע השבתות שרתים לצורך תחזוקה (רוב הסיכויים שזה ייצא באמצע יום עבודה, שכן הספק משרת מדינות רבות). ולכמה זמן? כמה זמן התראה מראש הלקוח מקבל על השבתות אלה?
  • אילו שירותי BI / דשבורד מובנים מקבלים (אם בכלל) בחבילה. כמו כן, אם הארגון מעוניין לבצע ניתוחים משולבים על נתוני ה SAAS בצירוף עם נתוני הארגון – מהן אפשרויות שכפול ה data לארגון – ל DW? באיזו תצורה ניתן לגשת למידע?
  • בבחינת נושא העלויות – עלות פר משתמש פר חודש תרד ככל שהארגון מתחייב ליותר זמן. קיים כאן כשל שוק מסוים, שכן חלק מהיתרון הגדול של השימוש ב-SAAS הנו הגמישות שהורדת / הוספת משתמשים חדשים ולא להיכבל מראש למספר משתמשים מוחלט.

לתחום ה-SAAS יתרונות רבים וברורים. אולם יש לזכור שבעולם ה-SAAS לא הכל ורוד, ישנן תקלות, ישנן השבתות ארוכות מהמתוכנן, ויש גם חברות ש"נעלמות" (דוגמת LucidEra). לכן, חשוב שארגונים ינהלו תהליך זה בצורה מפוכחת תוך חשיבה ותכנון מראש של החוזה מול הספק, קביעת רמת הזמינות והשירות הרצויה, מדיניות גיבוי, ובחינת רמת התמיכה המקומית.