יום שבת, 4 בספטמבר 2010

Vanilla - with chocolate chips - an article from Oren Teich

Here is an interesting analysis written not by myself - but by Oren Teich, AVP Application Manager in Comverse, about the "Vanilla versus Tailored" dilemma. I have written and talked about this issue for several times. In this analysis, Oren adressed this dilema and offered an intermediate approach - Vanilla with chocolate chips (but chocolate chips should be used wisely, only when needed and not extensively):

"For years, IT organizations have operated under the assumption that they should develop information systems based only on the requests given by internal customers and believed that this approach will best serve the organization's needs. Companies whose business processes and work-practices are based on non-standard approaches and the whims of managers quickly find themselves developing non-standard enterprise information systems. This approach has led IT organizations into managing Application Portfolios comprising dozens of proprietary systems that contain millions of lines of proprietary code that is based on the wide use of proprietary interfaces.
Many challenges and difficulties have brought IT professionals to look for new strategies that will serve today’s dynamic, global organization in ways that are more extensible, cheaper and less dependent on a specific manager and that will produce higher quality solutions in less time and with less effort. Among those challenges are the high development costs followed by growing support costs of proprietary solutions. Moreover, it takes a long time for organizations to implement changes (Time to Market) in today's dynamic business environment. IT is unable in this complex situation to easily interface to external systems. More and more this situation forces IT to be dependent on specific knowledge and unique resources.
One strategy that addresses these problems is the Vanilla approach. This approach is based on the view that dedicated companies in their respective areas of expertise represent the best practice of their industry and what's good for the entire industry is a good match for any other organization. The Vanilla approach is executed by implementing platforms and systems that provide the organization with a very high percentage of the company’s requirements. This is done without the need to heavily customize the software or engage in massive R&D projects.
These platforms and applications are implemented by field experts that help the IT organization to align with industry standards. Vendors, each in his respective area of expertise, continue to evolve their solutions and their underlying infrastructure while adapting to ever changing technologies. Therefore they reduce the organization's dependence on constantly “running” after issues that are not the organization’s core activity. Implementing these standard solutions significantly reduces the time it takes the IT organization to provide solutions to the business. It reduces support costs, allows flexibility with resources and provides long-term support and up-to-date solutions in each business process area.

The research company “Computer Economics” published a study in 2008 showing that the ratio of support staff for ERP systems versus business customers is 1:28 for environments categorized as “Many/Extensive Customization”. The ratio significantly grows to 1:36 in “None/Low Customized (Vanilla)” ERP implementations. It can be concluded from this study that there is a positive impact on other areas such as infrastructure, quality and availability, and therefore ROI improves respectively. Thereby we can see a significant reduction in the solution’s total cost of ownership (TCO).
The most difficult challenges to implementing enterprise systems based on this Vanilla approach are customer “buy-in” and the acceptance of this approach when the “off-the-shelf” solution does not exactly meet all of the customer's wishes. Moreover, organizations are challenged to overtake new business processes and adopt them as they come with the platform. In order to minimize the risks inherent in these strategic challenges strong support is needed from the organization's management. This should be done by emphasizing the many benefits of this approach vis a vis the approach based on developing and supporting proprietary solutions.
Given all the above, there are some exceptions ("The Chocolate Chips") to the Vanilla approach. The organization should not give up on customization in the areas where such customization provides a significant competitive advantage. “Chocolate Chips” may be added to the Vanilla approach in small and significant areas. “Chocolate Chips” should be used only when they provide significant added-value, are relatively inexpensive to “acquire” and they will not incur disproportional costs as the business processes evolve.
Another "flavor" of the Vanilla approach is the combination of SAAS (“Software As A Service”) solutions and Cloud solutions. These solutions are managed outside the organization by sharing software and hardware resources with many other customers around the world. This makes it difficult (and in some cases impossible) to add. “Chocolate Chips,” i.e., implement enhancements in the application to meet unique requirements.
To conclude, the “Vanilla with Chocolate Chips” approach is an administrative guideline supporting IT’s strategic decision-making process in managing an IT organizations’ application portfolio. This approach counters the "we do things differently here…" and provides solutions with a lower TCO and higher ROI than the current proprietary approach deploying applications. Organizations are learning to live with “out-of-the-box” solutions and on the other hand they are profiting from the many advantages that come with this “Vanilla with Chocolate Chips” approach. "

יום שני, 5 ביולי 2010

ERP Trends

חלק מהמצגת שהעברתי בכנס השנתי שלנו לגבי מגמות ERP:

יום רביעי, 23 ביוני 2010

רשמים ראשוניים ממפגש סיעור מוחות בנושא Mobile

מדי פעם אנו עורכים מפגשי סיעור מוחות - מפגשים בנושאים חדשים יחסית בהם אין best practices מוכחים וארגונים רק מתחילים ללמוד את התחום (בשונה מהשולחנות העגולים הרבים אותם אנו עורכים על נושאים בשלים/ שהנם ב mainstream). נושאים בהם ערכנו בעבר מפגשים כאלה לדוגמה – Cloud, קוד פתוח.

במפגשי סיעור המוחות משתתפים מנהלי תחומי מערכות מידע שונים, ארכיטקטים, יועצים, מובילי דעה, מנהלים טכנולוגיים בתחומים שונים בארגוני משתמשים ואנליסטים של STKI. שלא כמו במפגשי שולחן עגול שלנו, המיועדים לארגוני משתמשים בלבד, במפגשי סיעור מוחות משתתפים הן ספקי IT והן ארגוני משתמשים בתחום ה-IT.
במפגש סיעור מוחות שערכנו בנושא מובייל, עלו כמה נושאים מהותיים:
  • אחד המאפיינים הבולטים בדיון היה ההסכמה הגורפת כי עולם המובייל מאוד דינמי ולא יציב. לא ברור איזה סוגי מכשירים ואיזה טכנולוגיות יתפסו לטווח הארוך. אופק התכנון ה"ריאלי" עליו דברו רוב המשתתפים כאופק זמן אליו ארגון יכול לשאוף הנו שנתיים ולא יותר. בתהליך התכנון האסטרטגי של מדיניות מובייל, צריך להבין שחלק מההשקעות היום עשויות לרדת לטמיון בהמשך, ויש לקחת זאת בחשבון. יש למצוא את האיזון בין כניסה מוקדמת ומסוכנת לתחום חדש מאוד, ובין כניסה מאוחרת מדי כאשר שאר השוק כבר מזמן שם.
  • נקודה נוספת שעלתה בצורה נרחבת היא שימוש באפליקציה המותקנת על המכשיר החכם מול גלישה וובית. למרות שלא הייתה כל הסכמה גורפת ודעות מאוד שונות הושמעו במפגש, באופן כללי, לדעת משתתפים רבים בעתיד הקרוב עיקר השימוש יהיה באפליקציות המותקנות על המכשיר עצמו (Native application), כאשר בטווח הארוך יותר (בעקבות הבשלת סטנדרטים כדוגמת HTML5 וכד'...) הנושא ייבחן מחדש וייתכן שה"משחק" יחזור לסביבת הגלישה\WEB. אפילו אם נניח שאנו מסכימים על סוגיה זו, נותר סימן שאלה גדול סביב הדילמה – מה לעשות כרגע? האם להיכנס כבר עתה להשקעות באפליקציות WEB תוך ויתור על אלמנטים בחוויית המשתמש אותם ניתן לקבל כרגע באמצעות אפליקציית NATIVE, או לפתח אפליקציות NATIVE מתוך מחשבה שהן ישרתו את הלקוחות לזמן מוגבל, ובבוא העת לבחון את הסוגיה שנית?
  • במפגש הייתה הסכמה די גורפת להבדל הגדול שקיים בין אפליקציות פנימיות (למשתמשים פנימיים) לבין אפליקציות חיצוניות, עד כדי כך שבתהליך התכנון האסטרטגי כדאי לגבש שתי אסטרטגיות שונות – האחת למובייל פנים ארגוני, והשנייה לשירותי מובייל ללקוחות החיצוניים. באפליקציות מובייל פנים ארגוניות הפרויקטים מתבצעים לפי ROI כלכלי ככל פרויקט (אין את המניע השיווקי שנוכחותו כ"כ מורגשת באפליקציות החיצוניות). בפרויקטי מובייל פנים ארגוניים יש שליטה טובה פחות או יותר על המכשירים ועל צורת השימוש בו וכן על נושא אבטחת המידע על המכשירים, ושליטה יותר גדולה על הטכנולוגיות המועדפות. לעומת זאת, באפליקציות חיצוניות ללקוחות חיצוניים שוררת אי ודאות גבוהה וגיוון במכשירים ובמערכות ההפעלה שלא ניתן לשלוט בו כלל. אבטחת המידע בעולם זה שונה מאוד במהותה מאבטחת מידע בפרויקטים של מובייל לעובדים. המניע לפרויקט מובייל ללקוחות הנו הרבה פעמים לא כלכלי במהותו, כאשר המטרה הראשונית הנה "להיות שם".
  • ההרגשה הכללית במפגש הייתה של קושי גדול בלקיחת החלטה לטווח ארוך בשוק זה, ומצד שני חשש להיכנס לפרויקטים קצרי טווח ש"יסבכו" את הארגון מבחינת תחזוקתם השוטפת לאורך זמן. בארגונים הפועלים בשווקים מאוד תחרותיים מונעי לקוחות נושא הערוצים מול הלקוחות ובתוך כך המובייל מהווה מבדל תחרותי של ממש, בארגונים אלה יש לחץ חזק מכיוון מחלקות השיווק לבצע פרויקטי מובייל (בדר"כ – כמעט תמיד – בצורת אפליקציות מובייל) כבר היום, ומצד שני יש רצון של מחלקת ה-IT לגבש אסטרטגיה לתחום זה על מנת להוריד מורכבות של תחזוקה ותמיכה שוטפת ביוזמות אלו. המפגש נגע בשיווי משקל עדין זה והוצגו בו דעות שונות באשר לאסטרטגיה המומלצת לארגונים כיום.
  • אחד הקשיים של ארגונים עם תחום המובייל נובע מהעובדה שמדובר בתחום חדש. הנטייה הטבעית היא לנסות לעשות אותם דברים שעושים בערוצים אחרים (לדוגמה, באתר האינטרנט) גם דרך המובייל. אחד הספקים שהשתתף במפגש התייחס לסוגיה זו והמליץ להסתכל על ערוץ זה כערוץ חדש לגמרי בו הלקוחות משתמשים בדרך שונה לצריכת מידע ושירותים, ולא לנסות לדוגמה להלביש את אתר האינטרנט הרגיל על המובייל.

לסיכום, התובנות העיקריות שעלו מהמפגש:
• כדאי להסתכל על ערוץ המובייל כאל ערוץ חדש לגמרי בו הלקוחות משתמשים בדרך שונה לצריכת מידע ושירותים, ולא לנסות לדוגמה להלביש את אתר האינטרנט הרגיל על המובייל.
• ישנם 3 סוגים של פתרונות מובייל (SMS, WAP, פיתוח אפליקציות) כאשר שלושתם עשויים להיות רלוונטיים לארגון בהתאם לקהל היעד ו/או לשירות שיסופק באמצעותם. יש לבחון את התהליך שהארגון רוצה להציע, ומיהו קהל היעד שיצרוך אותו, ובהתאם לכך להחליט על סוג פיתרון המובייל המתאים ביותר.
• מהמפגש עלה כי במקומות בהם הצורך הנו שיווקי הארגון הולך לכיוון אפליקציות (כיום בעיקר iPhone כאשר ארגונים מתחילים לחשוב על Android).
• יש להפריד בין אסטרטגיה פנים ארגונית לחוץ ארגונית (במובייל פנים ארגוני הרבה יותר קל לבצע סטנדרטיזציה ולגבש מדיניות).
• יש לבצע תכנון מחדש לכל אסטרטגיה שתיבחר כל שנה – שנתיים בערך.

יום שלישי, 15 ביוני 2010

BAM (Business Activity Monitoring) state of the market

We received a question recently from an organization that doesn't have a BPM infrastructure but would like to apply a BAM product that will monitor business events in its operational applications. Here is a Definition of BAM (from Wikipedia).

BAM products are built to work as stand-alone tools that monitor events data regardless of where that data resides (whether the source for this data is BPM, ERP, DW, legacy application or any other sources).

The field of BAM holds a great promise – it can tell us what is going on with our organizational processes (which is one of our more important assets and differentiator). This area has many names – business process intelligence (BPI), some call it operational BI, BAM etc.
However, despite the high potential for business value, only about 30% of organizations who have entered BPM (more "natural" candidates for BAM) have actually implemented the BAM module. In Israel, this percentage is much lower. Organizations who have entered BPM did not include BAM as part of the project, but in a round table we held on BPM, these organizations actually recommended other organizations not to wait with BAM and implement it in the first stage.

The BAM vendor landscape changed dramatically in the past years. Just 5 years ago, the BAM market was dominated by best of breed vendors. Over the years, BAM vendors were acquired by BPM suite vendors. Today, BAM is considered more a part of BPM suite or a BI module than an independent stand alone market. A recent trend is the combination of BAM capabilities with packaged application to increase visibility to processes that are managed in these applications (For example, Pegasystem's [BPM vendor] acquisition of Chordiant [customer experience vendor] will enable ongoing monitoring and improvements of organizations' interactions with customers).

To summarize, BAM can provide high business returns. Organizations entering BPM should consider using BAM in the early stages of the project and not wait for the 2nd phase. Other organizations will find the market vendors map confusing, the main "decision" for these organization would be to decide between BPM vendors that provide BAM module and BI vendors that provide process intelligence capabilities.

יום רביעי, 2 ביוני 2010

BPM בישראל – תמונת מצב ב-2010

לאחרונה ערכנו שולחן עגול בנושא BPM, בו הציגו ארגונים סיפורי לקוח של יישום BPM. מסיפורי הלקוח שהוצגו ניתן לראות כי הכניסה לתחום ה-BPM מציבה "סט חדש" של אתגרים לארגון, וביניהם היערכות ארגונית שונה, שינויים בצורת הניהול השוטף של המערכות/התהליכים - החל בפיתוח, דרך הבדיקות, וכלה בביצועי המערכת:
  • בתור תשתית לפרויקט יש לבנות סביבת ESB חזקה ויציבה
  • אין להיכנס לפרויקט ללא הכנה של תשתית שליטה ובקרה מדויקת לכל רכיבי המערכת
  • ארגונים צריכים לסכם לעצמם איזה סוג לוגיקה תיכנס לשכבת ה- BPM ואיזה תישאר באפליקציות המקוריות, כאשר ההמלצה באופן כללי היא להשאיר כמה שיותר מהלוגיקה העסקית מחוץ ל"קידוד" הפנימי ב- BPM. מה שאומר שסביבת ה BPM הנה סביבת ניהול עוטפת לתהליך ולא סביבת קידוד
  • לעיתים הפרויקט מחייב שיפור הזמינות של מערכות הקשורות לפרויקט, זאת מכיוון שזמינות פרויקט כזה תלויה בחוליה החלשה ביותר ומטבע הדברים הפרויקט מחבר מערכות רבות
  • לעיתים פרויקט BPM מלווה בפרויקט מיפוי תהליכים עסקיים (BPA). האתגר בפרויקטי מיפוי הנו שמירת העדכניות בטווח הארוך (ה"תחזוקה" השוטפת). כל שינוי עתידי בתהליך יש להכניס לסביבת התיעוד – דבר שלא תמיד קורה, וברגע שזה לא קורה – כל סביבת התיעוד בסכנה

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

שאלות והתלבטויות שעלו בדיון:

  • באיזה UI להשתמש? בתוך התהליך יש HUMAN TASK שהמשתמש צריך לאשר... האם להשתמש ב UI של BPM או ב UI שכבר נמצא בשימוש בארגון – הן ב- UI של מערכות קיימות או בנייה של UI באמצעות פיתוח? האם לשלב ביניהם?
  • במסגרת הפרויקט של אחד הארגונים שהציגו סיפור לקוח עלו שאלות בתחום הארכיטקטורה. לדוגמה, כיצד מדווחים על סיום משימה? מי שואל? מי דוגם? האם האפליקציה היא זו שאומרת "גמרתי לעבוד" או שהBPM בודק זאת מיוזמתו? שתי צורות העבודה נתמכות במערכת, אבל מניסיונו של אותו ארגון, הם למדו שבמקרים מסוימים צורה אחת יותר נכונה, ובמקרים אחרים – השנייה יותר נכונה. אם אני כל הזמן דוגם והשרת נפל, אז אני יכול להכניס את כל המערכת ל-LOOP בעייתי ולפגוע בביצועים של כל הארגון. אם שרת נפל (ולאחר כמה זמן יעלה) אז אסקלציה של "מישהו לא שלח מסמך בזמן" יישלחו בטעות למנהל העסקי.

טיפים ותובנות:

  • ניטור עסקי Business Activity Monitoring – לעלות לאוויר מערכת מסוג זה בלי כלי שמאפשר ניטור עסקי ותשתיתי זה לא נכון, כי אין שום דרך לראות באיזה מצב נמצא התהליך. חייב להיות מפותח יחד עם התהליך עצמו. זוהי נקודה חשובה שלרוב, ארגונים נוטים להתעלם ממנה. אנו ממליצים להתחיל עם רכיב ה-BAM ורכיב השו"ב התשתיתי כבר בשלבים ההתחלתיים הן מסיבה "שו"בית" של היכולת לנטר את התהליך, והן מבחינה עסקית – שקיפות של התהליך ומה קורה איתו על מנת לשפר אותו
  • יש לזכור כי BPM הנה סביבה חדשה ולא מוכרת למפתחים – לתכניתן ייקח זמן עד שיידע איך נכון לפתח ב BPM
  • יש סכנה שתמיד צריך להיזהר ממנה - לעשות משהו ב BPM שיביא לתפעול מאוד קשה בארגון. לכן חשוב לרוץ עם פיילוט שניתן ללמוד ממנו כמה שיותר, ולהשקיע (בדר"כ כשנה) בבנייה מתאימה של ארכיטקטורה ותשתיות – בניית שכבת SOA, מיפוי ממשקים שנצרכים לצורך אותה מערכת ראשונה וחשיפתם, מינוי ארכיטקט ועוד
  • לשנות כמה שפחות את סביבת העבודה של המשתמש – אחת מהאפשרויות היא שה BPM יעשה את ניהול התהליכים העסקיים ברקע, והמשתמש ימשיך לעבוד ב UI שאליו הוא רגיל

יום שבת, 8 במאי 2010

עד כמה הארגון שלכם בשל ל-MDM?

שוק ה-MDM התקשה מאוד "לתפוס" בשוק הישראלי ב-3 השנים האחרונות. בפוסט קודם דיברתי על כך שאנו מעריכים שהמגמה מתחילה להשתנות. במהלך 2009 התקיימו מספר פרויקטי MDM בפיתוח עצמי (כלומר, לא נרכשו כלי MDM ייעודיים אלא פותחו פתרונות בתפיסת ה-MDM), הייתה רכישה אחת של כלי, ו2 מכרזים יצאו לדרך. לא נשמע כמו המון פעילות, אבל יחסית לכלום בשנה שעברה, לא רע.
המצב כיום הוא שארגונים מעוניינים ביישום MDM, מביעים רצון להיכנס לתחום בשנה הקרובה, אך נראה שכולם מחכים ש"מישהו אחר כבר יתחיל".
מה התנאים שצריכים להתקיים על מנת ששוק ה-MDM יפרוץ בישראל באותה מידה כמו בשוק הבינלאומי?
  • מספר פרויקטים מוצלחים, שגם יביאו לצבירת ניסיון על ידי מיישמים בשוק המקומי
  • נוכחות ספקים גבוהה יותר. ישנם ספקים ש"הרימו ידיים" כי ראו שארגונים אינם סוגרים עסקאות. צריך לזכור שזהו שוק חדש, תפיסה חדשה שקצת קשה לעיכול, אבל הצורך העסקי קיים, הוא פשוט מטופל בדרכים אחרות במקרה הטוב
  • ספקים צריכים להציע לא רק שירותי יישום טכנולוגיים אלא שירותי ייעוץ אסטרטגי-עסקי מתוך הבנה עמוקה של הסביבה העסקית הורטיקאלית בה הארגון חי, הדרישות הרגולטוריות שחלות עליו, תנאי הסביבה העסקית, ומגמת השוק העסקי. פרויקט MDM אינו רק פרויקט תשתית. זוהי ארכיטקטורת נתונים – אחד הנכסים העסקיים החשובים של הארגון. לא רק שתחום ה-MDM חדש לארגונים, גם כל ההיערכות הארגונית שנדרשת ממנו, המשמעויות העסקיות והרגולטוריות שיש לפרויקט כזה, נושאים אלה גם כן צריכים להיות חלק מהנושאים אותם ה service provider צריך להכיר לעומק [בנקודה זו לספקים בעלי נוכחות בינלאומית יש יתרון – ידע ורטיקלי מחו"ל שניתן למנף לפרויקטים הראשונים].

מה אפשר לעשות כדי להקל על הכניסה לתחום ה-MDM?

  1. גישה מדורגת (כאשר כל שלב לוקח 6-8 חודשים)
  2. להתחיל בקטן – ליישם בשלב ראשון מילון נתונים עסקי בארגון, כדי להכניס את כולם ל"שפה" משותפת, אפילו אם בצורה מעט מלאכותית. שכולם לפחות יתכוונו לאותו הפירוש כשהם משתמשים במונח מסוים.
  3. כיצד "לדבר ROI" עם ההנהלה? בעייתי. פרויקטי MDM הנם פרויקטי תשתית, להנהלה קשה לראות בעיניים איזשהוא ערך מוחשי ולהבין למה בכלל צריך פרויקט כזה שלא קל להסבירו. ולכן הצדקת תועלות של פרויקטים כאלה ניתן להצמיד לפרויקטים אחרים – לדוגמה, פרויקט CRM חדש. אם ארגון נכנס כיום ל-CRM ובארגון זה קשה לקבל תמונת לקוח אחידה, תשתית MDM/CDI תומכת ליוזמת ה-CRM עשויה להאיץ במידה רבה את הערך שיתקבל מפרויקט זה. כלומר, MDM יכול להוות מאיץ ROI עבור פרויקטים ויוזמות אחרות.
  4. אני מאוד ממליצה לעשות שימוש במודל בשלות כלשהוא. לא חסרות דוגמאות ל MDM Maturity models, נראה שלכל חברת מחקר יש איזו וריאציה משלה על מודל שכזה. הרעיון הוא לדרג רמת בשלות של ארגון בתחום ה MDM, החל מרמה 0 (אין כלל שום שיטה לסינכרון נתונים בארגון) ועד הרמה הגבוהה ביותר: קיימת תפיסה מושרשת של MDM בארגון כאשר הבעלות על הנתונים הנה עסקית ומתקיימים תהליכי Data Governance עם מבנה ארגוני תומך. רוב הארגונים נמצאים בשלבים 1-4, כאשר בישראל להערכתנו ארגונים נמצאים בין רמה 1-2 (הקפיצה מ 1 ל 2 אינה טריוויאלית). הסיכוי שארגון שנמצא ברמה 1 יקפוץ לרמה 5 הנו אפסי. יש לגבש תכנית של קפיצות קטנות, בשלבים. קפיצה משלב 1 (בו ישנן שיטות, אדהוקיות למדי, בהן מסנכרנים נתונים בין המערכות התפעוליות השונות) לשלב 2 (בו המערכות התפעוליות כבר מוכנות למודל עבודה בו הנתונים מתקבלים ממקור חיצוני, ולא יושבים פיזית במערכות אלה) – הנה קפיצה שאינה טריוויאלית אך היא בהחלט אפשרית. כבר הקפיצה הזו יכולה לשפר משמעותית את רמת הסינכרון. אך עדיין אין נגיעה באחריות עסקית על נתונים – מה שמגיע בשלבים הבאים.מודל בשלות זה ממחיש את העובדה שאין כזה דבר "יש לנו כבר MDM" או "אין לנו כלל MDM", רוב הארגונים נמצאים איפשהוא באמצע. שימוש במודל כזה יכול לעזור לארגון לזהות היכן הוא נמצא ולאיזה שלב הוא רוצה להתקדם.

יום רביעי, 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). לכן, חשוב שארגונים ינהלו תהליך זה בצורה מפוכחת תוך חשיבה ותכנון מראש של החוזה מול הספק, קביעת רמת הזמינות והשירות הרצויה, מדיניות גיבוי, ובחינת רמת התמיכה המקומית.