קפיטליזם חברתי - כמה "שווה" הערך החברתי שלכם?

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

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

כמה שווה ה"ערך החברתי" שלי?

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

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


הכותבות הינן אנליסטיות בחברת הייעוץ והמחקר STKI

Back to the Future ... Back to the box!

Oracle's recent announcement of its "Cloud Box" package, as well as IBM's announcement of NETEZZA acquisition and other announcements, are all related to the trend that surely will be one of the most important events in the near future of information technology: the inclusion of various technological elements under a single "umbrella" (or, in other words, back to the Main-Frame era). Many enterprises' CIOs we have talked to recently report that they engage with over 200 (!) IT vendors annually. And this number is only growing year-by-year.
For example, a typical ERP project in an enterprise organization- the organization should get in touch with about 20 different vendors (if not more) to get "One ERP solution" that includes infrastructure support, databases, operating systems, different application providers for each category. Keeping this in mind, the option of receiving an "ERP solution" within one packaged box while working with a single supplier seems very appealing for CIOs who are looking for simplicity and a single "partner" to work with.

So how did we end up getting back to the same architecture we had "ran away" from just recently? Are we not going to encounter the same problems that pushed us to decide to decentralize our computing, and consequently work with different suppliers in each category? A decision that is reflected in the separation we have made between the layers of hardware, storage, operating systems, Data, applications, management, connectivity? Why do we, all of a sudden, want to get the whole stack in one single box, even if this box is now very nicely packaged and wrapped in nice words like "internal cloud" or "Industry in a box"?
Is it really possible to return to a model in which we have one provider that provides us all the services under its responsibility?

The real reason behind this trend is that CIOs are fed up with the high complexity of managing IT and the search for simplicity (even if that means less choice and less open standards). Business have simply become too complex to manage. CIOs are tired of constantly dealing with optimization issues, the endless worry that the new package will not work properly (for one thousand and one reasons), dreading thoese "middle of the night" phone calls that the servers have crashed again /, the site is not in the air / the organization's main application is not functioning, and the engagement with so many different suppliers.

But before we announce the death of the era of decentralization and the return of the
centralized era, is it also well worth exploring the pitfalls and potential risks of this model:

• Creating a dependency on the IT vendor. Just ask your procurement manager how they feel about working with a single vendor instead of an "open market" with many different options of vendors to chose in each category. The "industry in a box" model means that the organization will work with one major supplier or at least one major supplier for each category. For the procurement manager this trend is a real negotiation problem, since the power now moves to the vendor.
• Connectivity and Integration issues. Most organizations have a heterogeneous application environment with 3-4 major applications vendors. The "boxed" model means that each technological environment will now be more closed off, more proprietary in nature, and less open. This means – connectivity issues. Each environment will be optimized and adapted for the application's main purpose, regardless of other applications' need to connect with it. The supplier will want to give the organization with a box that works flawlessly, with all the different parts "talking" to each other in harmony and are controlled best by a single management tool. What will happen when you try to add a new element into that box? Connectivity problems will appear both on the level of business processes and the Data level.
• Difficulty in achieving an overall monitoring and management view. This will also be a challenge because the "box" providers will include complete solutions with a monitoring tool tailored to the application's specific need. Each solution will include, among other things, a security solution, backup solution, a DRP solution and so forth. This means that receiving information about the organization's overall threat situation will be much harder than before, since there will be a need to synchronize with different information security solutions in order to get to this situation.
• Risk of harming the organization's level of flexibility. If there is a need which has not been addressed in advance by the manufacturer of the packaged solution, the organization can't answer this need (it will require greater efforts to address it). In today's reality, there are many cases in which there are non-standard needs that off the shelf packages do not include. In these cases, organizations can and are doing things that are considered non-standard (adding to the system's components, programming in a way that is not 100% recommended by the vendor etc.). This is almost impossible in the "Industry in a box" model. Boxes manufacturers will not allow to perform actions that do not receive prior approval or "certification" which takes a long time. This means that the level of IT's flexibility in tailoring for the organization's needs will be reduced.
• Significant changes in the status of the IT department as we know it today. The traditional structure of IT organizations' infrastructure department currently includes three separate sections – Network, Storage and Servers. The technological change which we have described (inclusion of all these elements under one box) will require a different structure of the IT Infrastructure unit – from 3 different departments to a unified one. This change will also apply to application teams, and their relationship with Infrastructure teams. If the organization acquires a "CRM box", that also includes infrastructure components, who in the organization will be responsible for the operation and maintenance of the entire box? This is not necessarily a disadvantage, but this is a significant change, and any major change is difficult to cope with.

Vendor's perspective:
IT providers will also experience quite a few changes, some are positive but some are very disruptive and will require a change in the overall vendor's business model.

• Change in the vendor's sales processes. The 'cost of selling' for suppliers in various categories (hardware, software etc.) is a fixed cost. If the supplier will now sell the customer "one solution" which includes the same components inside, rather than selling them individually, the relative cost of selling per each component will fall significantly. The expected cost of selling for suppliers will drop (an advantage that we hope will lead to increased profitability as well as reduced pricing for enterprises).
• Should we expect a decrease in revenues for service providers? It remains unclear whether service providers will experience a decrease in revenues from the sale of services as a result of this trend. If we take as an example the SAAS (software as a service) model, then in this field we can clearly see that services revenue for Integrators have indeed decreased significantly compared with the "classic" model in which an organization actually buys the software and customized according to its needs. A SAAS solution implementation project typically takes between several weeks to two months, almost never includes customizationsm and focuses mainly on training and assimilation. As mentioned above, it is still unclear how this field will affect the overall revenue structure of suppliers.
  

Who are these providers "Industry in a box"?
NCR have provided a boxed solution long before we called it "Computing in a box" with Teraedta. Among other prominent major manufacturers already offer solutions for Industry in a box we can mention IBM, HP, Oracle, EMC, CISCO, Apple and more. SAP made a major step toward this model recently by acquiring SYBASE.
Take Apple for example. The iphone / ipad industry are actually industries in a box - a box that contains applications, operating system, and hardware. All these parts belong to and are in full control of Apple, which enables it to provide a machine that provides an excellent user experience, optimal performance for applications running on it. But there's no choice, and no openness. The equilibrium exists as long as the box remains closed. Try to open the box and put in elements from the outside - and the balance will be violated.
This example can illustrate pretty well what is expected to happen - as long as consume technology "in the box", we can provide good value. As soon as we try to go out, for example to replace the infrastructure and applications in the box, problems will begin.
This example illustrates one of our essential questions in this area have not yet received an answer: Will manufacturers prefer boxes proprietary technologies, or will they try to adapt to open and common standards?


Recommendations:

• Due to the expected lock-in effect, make an effort to preserve procurement conditions for future deals as well as current deals.
• Organizations should deploy general and flexible monitoring and management consuls that will enable the future connection of "industry in a box" solutions.
• Organizations should start to prepare for the expected organizational changes. For example, measurement of the degree of cooperation between teams and not measurement of each team's performance separately (DBA performance evaluation will be based not by a specific DBMS availability, but according to the overall ERP system availability and performance).
  

בחזרה לעתיד... חוזרים לקופסה!

מאמר שכתבנו - צוות האנליסטים של STKI - על מגמת ה"חזרה לקופסה" (עידן ה-MF?) פורסם בדמרקר:

"הכרזתה של אורקל לאחרונה על חבילת "ענן בקופסה", כמו גם הכרזת IBM על רכישת NETEZZA, קשורות למגמה חשובה בעתיד הטכנולוגי: החזרה לעידן ה-"Main Frame"; מחשוב כולל. ארגוני אנטרפרייז נדרשים לנהל תקשורת עם 200 ספקי מחשוב בשנה, מספר שרק הולך ועולה. כדי להפעיל מערכת ERP אחת– צריך הארגון להתקשר עם כ-20 ספקים שונים כדי לקבל תשתיות תומכות, בסיסי נתונים ומערכות הפעלה. מנמ"רים מחפשים היום פשטות. ספק יחיד שיציע להם את כל שירותים הללו באריזה אחת שפשוט תעבוד. אך לפני שאנחנו מכריזים על מות עידן הביזוריות וחזרה לעידן הריכוזיות, כדאי לבחון טוב גם את החסרונות והסיכונים של מודל זה:

• יצירת תלות בספק. אם עד כה, ה-ERP של החברה הורכב מספקים נפרדים לאפליקציה, מערכת הפעלה, בסיס נתונים, תקשורת וחומרה, עם אפשרות לבחירה והחלפה, הרי שבקרוב נקבל מאותו הספק קופסה אחת שלמה, שמכילה אפליקציה המותאמת לחומרה ולבסיס הנתונים שעובדים באופטימיזציה מלאה. התוצאה: ביצועים טובים בהרבה ופחות כאב ראש בהעלאת הפרויקט. אך החיסרון טמון בגזרת מנהלי הרכש, שיהיו כבולים מול ספק יחיד בעל כוח עצום. שיקול זה עלול לגרום לגפי רכש לעכב קבלת טכנולוגיות חדשות משיקולים פוליטיים פנימיים.
• צרות של קישוריות. מרבית הארגונים מנהלים את היישומים שלהם בשיטה של ריבוי ספקי אפליקציות תוך קישור מתמיד ביניהם. על פי חזון ה"קופסאות" אליו אנחנו צועדים, שיטה זו תהיה קשה הרבה יותר ליישום. כל סביבה תותאם לצורך העיקרי של כל אפליקציה, ללא התחשבות באפליקציות האחרות שנדרשות להתחבר אליה. הספק מעוניין ליצור קופסה שפועלת בהרמוניה ונשלטת בצורה מיטבית על ידי גוף ניהול יחיד. כשננסה להכניס לקופסה מרכיב שלא שייך אליה, נסיט את רוב מאמצי המנמ"רים להתעסקות בקישוריות בין הקופסאות השונות וניסיון ליצור מכנה משותף ל-DATA.
• פגיעה ביכולת הניטור והניהול הכולל של מערכות המידע. כיוון שיצרני ה"קופסאות" יגישו פתרונות מלאים וכוללים, כל פתרון יכלול פתרון אבטחת מידע, פתרון גיבוי, ופתרון DRP משלו. קופסה A תכיל פתרון אבטחת מידע שונה מזה של קופסה B. המשמעות היא קושי לקבל מידע על מצב האיומים הכולל בארגון, בשל הצורך להסתנכרן מול כמה פתרונות אבטחת מידע שונים.
• פגיעה בגמישות של ארגון המערכות. במצב בו מתעורר צורך שלא הוגדר מראש על ידי יצרן ה"קופסה", הארגון ייאלץ להשקיע מאמצים רבים יותר כדי לספקו. בקופסאות המוכנות מראש, הארגון לא מורשה לבצע פעולות שלא קיבלו אישור מראש"certificiation” . תהליך אישור זה אורך זמן רב, מה שעלול לפגוע בגמישות ארגון מערכות המידע ובמענה לצרכי הארגון.
• שינוי משמעותי במבנה ומעמד מחלקת מערכות המידע כפי שאנו מכירים אותה כיום. מבנה מסורתי של גוף תשתיות בארגונים גדולים כולל כיום שלושה מדורים נפרדים לתקשורת, אחסון ושרתים. שינוי התפיסה הטכנולוגית יחייב גם שינוי במבנה הארגוני. כמו כן, אם "קופסת CRM" אחת כוללת בתוכה גם את הרכיבים התשתיתיים, מי בארגון יהא אחראי על תפעולה ותחזוקתה? הקו בין המחלקות האפליקטיביות לתשתיתיות יילך וייטשטש. זהו לא בהכרח חיסרון, אבל מדובר בשינוי משמעותי שיחייב התמודדות שונה לחלוטין.

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

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

מיהם אותם ספקי "Industry in a box"?
על היצרנים שכבר מציעים פתרונות Industry in a box ניתן למצוא את הספקית הוותיקה NCR/ טרהדטה (שכבר הייתה שם מזמן, עוד לפני שתיארנו את התחום בבאזוורדים יפים), IBM, HP, אורקל, EMC, CISCO, Apple ו-SAP שעשתה צעד משמעותי בכיוון כאשר רכשה את SYBASE.

אם ניקח את Apple כדוגמה, ה iphone / ipad הנם למעשה industry in a box – קופסה שמכילה אפליקציות, מערכת הפעלה וחומרה. כל החלקים האלה מצויים בשליטה מלאה של אפל, מה שמאפשר לה לספק ביצועים אופטימליים. אולם שיווי המשקל מתקיים כל עוד הקופסה נשארת סגורה. נסה לפתוח את הקופסה ולהכניס פנימה רכיבים מבחוץ – ושיווי המשקל יופר. דוגמא זו יכולה להמחיש מה צפוי לנו במקרים אחרים של ספקי-על שיציעו תעשייה בקופסה. כל עוד נצרוך טכנולוגיה "בתחומי הקופסה", נקבל תמורה מספקת וטובה. כשננסה להחליף את האפליקציה מעל התשתית הקופסתית, ניתקל בבעיה
.
האם יצרני קופסאות יעדיפו עבודה בטכנולוגיות קנייניות או שישמרו על סטנדרטים משותפים?

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

המלצות לארגונים:
1. כל כניסה לטכנולוגיית מחשוב מבוסס-קופסה מחייבת התייחסות משמעותית לסוגיית הרכש, ודגש על קיבוע אחוזי הנחה ממחיר רכש לקניות עתידיות ולפריטים שייווצרו בעתיד. כלומר, לנסות להפחית את רמת ה lock-in לספק עד כמה שניתן מראש.
2. ארגונים צריכים להטמיע כבר כעת קונסולות כלליות וגמישות של ניטור וניהול, כדי שיוכלו לחבר בעתיד קופסאות “industry in a box” שונות.
3. ארגונים צריכים להתכונן כבר כעת לתמורות הצפויות בארגון; התייחסות ומדידה של מידת שיתוף הפעולה בין הצוותים ולהנהיג תגמול DBA לא לפי זמינות DBMS ספציפי, אלא לפי זמינות וביצועי כלל מערכת ה- ERP."

רשמים ממרתון של חברת לוטם בנושא ווב2

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

הנה סיכום ההרצאה שלי מתוך הבלוג (שהייתה יותר טכנולוגית באופייה):

"עינת שמעוני, אנליסטית מחברת STKI בהרצאה על יישומי ווב 2.0 בארגונים: ויקי, רשתות חברתיות ארגוניות, בלוגים, טוויטר, social bookmarking, RSS, תגיות, יישומים מבוססי מקום (למשל Four square)

כמה תובנות מההרצאה:

ויקי: ויקי מאפשר להקטין את תעבורת המיילים השוטפים בארגון. ישנם יישומי ויקי שוני כמו אנטרפדיה (ויקי ארגוני), user manuals. בויקי עדיף לפנות לקהל יעד עם מכנה משותף ולא ברמה ארגונית. נשאלת שאלה עד כמה הארגון מאפשר להעלות תוכן באופן חופשי לויקי ללא בקרה? הגישה הרווחת היא לאפשר עדכונים חופשיים ולעשות סוג של בקרה.

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

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

למשל מה המוטיבציה לכתוב בויקי ארגוני ולקחת חלק ברשתות חברתיות ארגוניות? הרבה ארגונים מקימים אוטומטית לכל עובד עמוד ברשת החברתית עם מידע בסיסי והעובד בוחר איזה מידע להוסיף. דגש נוסף הוא לקשר את השימוש לתהליכי עבודה ותהליכים ארגוניים יומיומיים, למשל קישור לתהליכי הערכת ביצועים בארגון (דוגמא לארגונים שמודדים תרומת ערך של רעיונות שעלו בויקי וקושרים ישירות להערכת ביצועים וכו').

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

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

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

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

הפוסט המלא באתר של לוטם - כאן.

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. "

ERP Trends

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

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

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

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

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

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

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.

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 שאליו הוא רגיל

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

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

Presenation from STKI Summit 2010

Thanks for everyone who came to our summit. It was a great event!

And a big thank you to STKI clients and everyone who assisted us in conducting our annual research (answering surveys, brainstorming with us...)

I've uploaded my presentation to slideshare, you can take a look at it here:

2010 Enterprise Applications, BI & KM Trends

View more presentations from Einat Shimoni.

ההכנות לכנס השנתי בעיצומן

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

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

הססמה שבחרנו לכנס השנה מדברת על הצורך לאזן בין סטנדרטיזציה לבין חדשנות. למה הכוונה?

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

מצד שני עם שנת 2010 מגיעה גם אווירה קצת אופטימית, וזו מחזירה לשולחן את הפוקוס בפרויקטים חדשים, בהבאת ערכים מסוג חדש, בתמיכה בתהליכי חדשנות שמתחוללים כיום בארגונים. יש לא מעט פרויקטים שנדחו ב 2009 (עד שיגיעו ימים טובים יותר) ואלה חוזרים כיום לסדר היום, בתוכם גם פרויקטי ליבה משמעותיים וגדולים. בתחומי ה-CRM נדרשת חשיבה חדשה, הסתכלות על השכבות הבאות שניתן לספק מעל ה"תשתית" שכבר נבנתה. נושא של ריבוי ערוצים יהווה אתגר עיקרי.מה כבר ניתן לחדש בתחום ה-BI? מסתבר שהרבה, התחום לא מפסיק לחדש ולהתחדש ובכנס נדבר על מגמות מעניינות חדשות בתחום שעדיין ממשיך לככב כאחד מהתחומים החשובים ביותר לארגון גם בשנה הקרובה.

הכנס יעסוק באיזון העדין שבין שתי מטרות אלה - סטנדרטיזציה אל מול הצורך בחדשנות.

נושאים נוספים שנכסה בתחום האפליקציות - SaaS, אפליקציות "ניידות", מגמות בתחום ניהול הידע, טשטוש הגבולות בין עבודה - חיים בקרב העובדים והלקוחות שהנם כיום הרבה יותר דיגיטליים, פעילים במדיות חברתיות, ומשתמשים במכשירי טלפון ניידים חכמים - מה כל זה אומר מבחינת אספקת שירותי IT לעובדים? ללקוחות? בתחום ה ERP נדבר על השלבים הבאים הצפויים - ERP 2 ו ERP 3, ונציג תוצאות סקר יחסי כ"א בתחומים אפליקטיביים שונים.

את האג'נדה של הכנס אפשר למצוא כאן.

רשמים משולחן עגול - כלי ניהול למידה והטמעה

שוק הכלים הטכנולוגיים ללמידה והטמעה כולל הרבה תתי-תחומים (אשר אליהם מתווספות קטגוריות חדשות כל הזמן). אימוץ כלים אלה בארגונים הנו לרוב מוגבל וחלקי. שוק הספקים כבכל שוק שבשל, כולל ספקי best of breed וכן ספקי סוויטות אפליקציות ארגוניות (HR, ERP) שהתרחבו גם לתחומים אלה, וכן כלי קצה מאוד ממוקדים (הרבה סטארטאפים).

התחומים הנכללים בשוק כלי ניהול למידה והטמעה (רשימה חלקית):

• כלים לניהול האדמיניסטרציה של הלמידה – LMS - learning management systems
• כלים לחילול לומדות וחומרי הדרכה
• מבחני ידע, בדיקת אפקטיביות
• ניהול תכני למידה – LCMS
• כלים להעברת קורסים מתוקשבים (e-Learning)
• ניהול Skills / Talent
• "מעטפת" ל- delivery של שירותי הלמידה – פורטל הדרכה לדוגמה
• כלים המאפשרים למידה "אד-הוקית" תוך כדי העבודה התפעולית (לדוגמה, EPSS) - קטגוריה יחסית חדשה
• ממש לאחרונה אנו רואים גם כלי מדידת הטמעה, הדוגמים ברמת תחנת העבודה של המשתמשים תוך כדי עבודתם את צורת העבודה כך שניתן לראות היכן צריך לחזק הטמעה (מעט מאוד יישומים בפועל בישראל

ארגונים כעת שואלים אותנו יותר על מפת הספקים, אשר בעבר הייתה מצומצמת הרבה יותר בישראל. כמו כן, שנת 2009 (שהייתה לוחצת מבחינה תקציבית) הביאה עמה יותר עניין בכלים התומכים בלמידה תוך הפחתת עלויות הטמעה (לדוגמה, כלי EPSS המשולבים במערכות התפעוליות, כלי חילול תכני למידה באופן אוטומטי ועוד). במקביל, מתחילות להופיע אופציות מבוססות קוד-פתוח (דוגמה בולטת – Moodle לתחום LMS).

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

Blended Learning – כ Best practice
במפגש הייתה הסכמה כללית (הרווחת כבר שנים) כי הקורסים המקוונים והלמידה העצמאית אינם מחליפים לחלוטין את הלמידה הפרונטאלית. ההמלצה השחוקה כמעט לשלב צורות למידה שונות אכן מוכיחה את עצמה. ה – Blended learning (שילוב מספר שיטות למידה) כשילוב הממקסם את הערך מהלמידה אכן עלה כ- Best practice אצל כל המשתתפים. כמו כן, האווירה שעלתה מהדיון באופן כללי היא שכאשר מדובר במיומנויות רכות – ישנה העדפה ברורה להשתמש בקורסים פרונטאליים.
חלק מהמשתתפים הדגישו כי המעבר מלמידה פרונטלית לעצמאית/מתוקשבת הנו מעבר שקשה לארגון לעכל ושבחלק מהמקרים אין תחליף מספיק אפקטיבי והם יישארו עם למידה פרונטאלית (מיומנויות רכות, הנהלה בכירה, משתמשים לא טכנולוגיים).

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

אתגרים נוספים שהוזכרו בדיון

• יוזמות למידה שונות בארגון ללא תיאום. בחלק מהארגונים קיימים כלים טכנולוגיים נפרדים - הלקוחות החיצוניים משתמשים בכלי אחד, והעובדים - בכלי אחר, והתכנים המיוצרים לקהלי יעד אלה שונים. אחד הארגונים ציין כי גם התפיסות שגובשו שונות – לעובדים פנימיים יותר למידה פרונטאלית, ולחיצוניים – למידה מתוקשבת יותר (שילוב של לומדות + כלי EPSS).
• ארגון מתחום הטכנולוגיה ציין כי צריך לקבל את העובדה שכיום קיים טשטוש בין עבודה -> למידה -> חיים. הלמידה צריכה להשתלב בעבודה היום יומית, וזהו אתגר משמעותי. איך מביאים את הלמידה לתוך סביבת העבודה (שאלה שעולה לרוב ביוזמות ניהול ידע כיום)? רוצים לייצר learning services. גם שיטות הגישה לנתונים משתנות והן כיום מגוונות, לא רק מחשב במשרד אלא גם עובדים שניגשים דרך smartphone (אייפון/בלקברי).
• טשטוש בין עולם הלמידה - לעולם ניהול ידע - לעולם הקולבורציה. למידה לא מתרחשת רק בקורסים רשמיים אלא היא מתרחשת כל הזמן בתהליכי ניהול ידע ושיתוף ידע בין העובדים. ולכן השאלה - איך נראית כיום תכנית למידה? הנה שאלה לגיטימית. האם זו סביבה חדשה שמשלבת תהליכים, למידה וקהילה?
• נושא Social Learning – למידה באמצעות מודלים חדשים מעולם המדיה החברתית שמציב אתגרים רבים לעומת המודלים המסורתיים המוכרים – על כך פירוט בהמשך.
• צוינו אתגרים טכנולוגיים סביב יישום גלובלי בו העובדים צריכים להתחבר למערכת ממקומות גיאוגרפים שונים – איך לאפשר התחברות רציפה ובאותה רמה לכל העובדים (כאן פתרון במודל SaaS חיצוני יכול לסייע).
• אחד הארגונים ציין הצגת סרטוני Flash על גבי Citrix קשה/עובד בצורה איטית.
• חסרה כיום אינטגרציה המאפשרת קישור אמיתי בין מערכות: LMS + משובים + משאבים, לרוב תחומים אלה נבנים כ"איים" עם כלים שונים.
• רוב הלומדות המוצעות "מהמדף" הנן באנגלית.

מודל פנימי (in-house) או חיצוני (Hosted או SaaS)
אחת מהשאלות שעלו במפגש – האם ליישם כלי במודל חיצוני, אשר יושב אצל הספק, או ליישם את הכלי פנימית בתוך הארגון.יש לכך מספר שיקולים:
· אם צרכי החברה הנם דומים למדי לצרכי ארגונים אחרים, ההעדפה להשתמש בכלי חיצוני גדלה. [הערת STKI: היתרון הבולט בתחום ה-SaaS כפי שעולה משיחותינו עם לקוחות שיישמו הוא היכולת להתרכז בתהליכים העסקיים במקום להתעסק בטכנולוגיה – איזון עומסים, גיבוי, אבטחה וכד'. עם זאת, תחום ה-SaaS רלוונטי ביותר כאשר מדובר בצרכים כלליים ולא ייחודיים, שכן ה"אפליקציה" במודל SaaS מתוחזקת פעם אחת עבור כל המשתמשים בה (multi-tenant), כל שדרוג בחבילה יתבצע לכולם ביחד. לכן, אם נדרשים שינויים מהותיים באפליקציה מודל זה פחות מתאים].
· אם הארגון הנו גלובלי, קיים יתרון בהליכה לפיתרון SaaS שכן השירות הניתן למשתמשים אמור להיות זהה ללא תלות במיקום הגיאוגרפי. ארגונים גלובליים נתקלים בבעיות ביצועים במיקומים שונים – בהודו זמני התגובה יהיו יותר נמוכים מאשר ארה"ב. מודל ה-SaaS אמור להקל על "כאב ראש" זה. חלק מהארגונים הגלובליים מתמודדים בבעיית הביצועים על ידי אפשרת הורדת קורסים וביצועם באופליין.

תועלות ו-ROI

1. הקטנת תלות במוקד התמיכה (הרבה מהפניות הנפתחות – בגלל חוסר היכרות עם התהליכים ופחות בעיות טכנולוגיות אמיתיות).
2. שימוש בכלי EPSS – הטמעה בזמן אמת – יכולים לחסוך הן בזמן המדריכים והן בהורדה משמעותית בצורך לפתח סביבות הדרכה על ידי ה-IT
3. כלי המאפשר לארגון לקצץ בעלויות (תקציב נסיעות לדוגמה בארגון גלובלי)

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

בשולחן עגול אחר שערכנו בנושא Web 2.0 לשימושי ניהול ידע פנים ארגוניים, דובר על אחת הבעיות הכאובות בהכנסת כלי ווב2 לארגון – היעדר היכולת למדוד ולהראות ROI שניתן להציג להנהלה בכירה. הגישה שגם עלתה בדיון זה בהקשר של ROI בלמידה באמצעות תפיסות web 2.0 - להראות ניצחונות קטנים.

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

אתגר נוסף - מיהם האנשים שמנהלים בלוגים וקהילות? עד היום יוזמו ונוהלו על ידי אנשי IT. התוצר – הרבה כלים ותשתיות בלי הצד של הניהול.

טיפים והמלצות שהעלו המשתתפים במפגש

• כדאי להשתמש באותו כלי הדרכה ללמידה עצמית גם בהדרכות הפרונטאליות. כך המשתמשים ייחשפו לאותו הכלי בו הם ישתמשו אח"כ בעצמם, כך שזה לא יהיה להם זר. המדריך מראה להם איך זה עובד, אח"כ מנתק והם מנסים בעצמם.
• E-learning לא בהכרח אומר שהמשתמש לומד בעצמו. ניתן ליצור קהילות ואינטראקציה בין משתמשים שתחזק את הלמידה.
• לקשר בין יוזמות הדרכה חיצוניות ללקוחות ופנימיות לעובדים
• לחזק את הקשר / שיתוף בין יוזמות ניהול ידע, פורטלים ושיתופיות, ותחום הלמידה וההטמעה.

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

הרשתות החברתיות בסכנה אם לא יספקו שירותי ערך מוסף

מחקר של eMarketer ו-Deloitte חשף נתון מעניין מאוד לאחרונה: במהלך 2009 46% מה"baby boomers" (פלח באוכלוסיה של בני 44-62) פעילים ברשת חברתית. נתון לא כ"כ מעניין כשלעצמו, אבל מה שמעניין במחקר הוא אחוז הגידול המרשים לעומת 2008 (במהלכה רק 31% מהם השתמשו ברשתות חברתיות). במילים אחרות – רשתות חברתיות אינן רק לבני עשרים ומשהו או לאנשים משועממים עם יותר מדי זמן פנוי. יותר ויותר אנשים, משכבות שונות באוכלוסיה, מצטרפים לחגיגה. באופן כללי, כשמתסכלים על כל האוכלוסייה על פלחיה השונים, כמעט 60% פעילים ברשת חברתית.

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

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

אז אחרי ההצלחה המסחררת של פייסבוק וטוויטר, יש מקום לבדוק מהו הערך העיקרי שתחום זה מספק כיום לארגונים וללקוחותיהם, ויש בעיקר מקום לבדוק מה יהיו הערכים העתידיים שנוכל להפיק מהתחום הזה. לדעתי אנו נמצאים בשלב בו הרשתות החברתיות צריכות "להמציא את עצמן מחדש". הערך המוסף העיקרי שניתן לקבל כיום מרשתות חברתיות היא היכולת לדעת "מה קורה כרגע"? זהו ערך גדול מאוד עבור פונקציית שיווק בארגון מסחרי (איך אני ממוצב כרגע? מיהם הלקוחות שמתלוננים עלי / או משבחים אותי? איך המתחרים שלי ממוצבים כרגע? מה השוק רוצה לקבל כרגע? איך הקמפיין שהפצנו הבוקר מתקבל? וכו').
השאלה הבלתי נמנעת עכשיו - מה הלאה? מהם הערכים המוספים החדשים שנוכל לקבל מתחומי הרשתות החברתיות וה Real Time Web? כיום ארגונים מסתכלים על התחום כ- Best practice לשיתופיות ויצירת בסיס ידע קולקטיבי ומנסים להכניסם לתוך חומות הארגון (כרגע בהצלחה מאוד מוגבלת). במקביל, ה Web 3.0 כבר מבטיח לעשות סדר בבלאגן המידע שיצר ה Web 2.0 ולנסות להוסיף אינטליגנציה (בצורה מלאכותית) ל"שיחות" הרבות, באמצעות Semantic web. אבל מבחינת האינטראקציות עצמן, השיחות שמתנהלות כיום ברשתות השונות, המידע שעובר (שמחקר לאחרונה הגדיר 94% מתוכו כ"קשקוש חסר מטרה"), אין ספק שיש צורך בדבר הבא. הרשתות החברתיות במודל הנוכחי שלהן לא יוכלו להתקיים עוד שנים רבות, ואם לא יתווספו ערכים מוספים מעליהן (כדוגמת BI, רשתות חברתיות בתוך הקשר מסוים) רובן יתמוססו או יישארו בגדר "שעשוע" לצעירים.

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

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

האם שוק ה-MDM בישראל סוף סוף מתחיל להפשיר?

אנו ב-STKI עוקבים אחר שוק ה-MDM בדריכות כבר כ-3 שנים, מאז החל ה"באז" בשוק העולמי. עד השנה האחרונה, שוק ה-MDM בישראל היה די רדום, מעט מאוד ניסיון והתעניינות מאוד זהירה של ארגונים (על הפער הגדול בין השוק המקומי לבינלאומי דיברתי בפוסט קודם).
אז עדיין לא מדובר על פריצה משמעותית, אבל ניתן להגיד בצורה זהירה שהשוק בהחלט מתחיל להפשיר ושב-2010 צפויים מספר פרויקטים בתחום. חשוב לציין כי עדיין מדובר על פרויקטים אחדים (ולא עשרות) המתוכננים לשנה הקרובה, אך אנו בהחלט רואים מגמת עלייה ברמת ההתעניינות והשאלות שאנו מקבלים על התחום. בחלק מהמקרים ההתעניינות שמתחילה כעת לא תסתיים ברכישת מוצר מדף "MDM" אלא בפרויקט המערב תפיסה MDMית (התסכלות מרכזית על נושא הנתונים, עם מעורבות מסוימת של המחלקות העסקיות).
ארגונים כבר מדברים יותר ב"שפה" ה MDMית. התוצאה הרצויה אצל רוב הארגונים - יצירת בסיס משותף לנתונים תפעוליים שישרתו את המחלקות והמערכות התפעוליות בכל הארגון, מעין גישת "SOA" לנתונים. חלק מהארגונים מתכננים לממש פיתרון טכנולוגי שישמש את מחלקת ה-IT בלבד, וחלקם אף מעיזים לדבר על רצון לממש פיתרון עסקי - טכנולוגי שיכלול אחריות עסקית על נתונים בארגון ("קפיצה" משמעותית, שלא פשוט כלל לבצע בארגון).
במקביל, גם הספקים בישראל מתחילים להראות יותר נוכחות ויותר מאמצים שיווקיים, מה שמאוד יסייע ב"התחממות השוק". ישנם לא מעט מוצרי MDM המשווקים בישראל וגם מוצרים בינלאומיים נוספים שאינם מיוצגים (אך אם רמת ההתעניינות תעלה - בהחלט ייתכן ונראה שחקנים נוספים כאן).
בשוק העולמי יש כמה התפתחויות שמצביעות על המשך תהליך ההבשלה של השוק, לאחרונה התבשרנו על רכישה מעניינת בתחום - חברת אינטגרציית הנתונים - אינפורמטיקה - רוכשת את חברת Siperian - ספקית בתחום MDM. כמו כן, מיקרוסופט אשר רכשה לפני כשנתיים את חברת Stratature מתחילה לשווק את הפיתרון תחת ה-SQL.

לא ניתן להגיד שתחום ה-MDM נכנס ל-mainstream. זהו תחום שנחשב עדיין יחסית חדש, לארגונים לא פשוט "לעכל" את השינויים הנדרשים על מנת להיכנס לתפיסה ה MDMית, וייקח זמן עד שהשוק יבשיל והידע ייצבר. אולם אין ספק שהצורך בניהול הרבה יותר טוב של נתונים נדרש, חברות נתקלות כל הזמן בבעיות שמקורן בניהול נתונים בגישת "איים" ולא בגישת "שירותים". האתגרים כאן הם בעיקר פוליטיים, מבנים של מחלקות ארגוניות נפרדות, איי מערכות תפעוליות שכל אחד מהם רוצה לשמור את הנתונים אצלו, ואף אתגרים טכנולוגיים באפליקציות עצמן - שאינן בנויות באופן טבעי לעבוד מול Hub חיצוני של נתונים.
לסיכום, אנו ב-STKI ממליצים להתחיל להתכונן למצב בו הארגון יכניס "פיתרון בתפיסה MDMית" - כלומר, HUB מרכזי של נתונים שינוהלו ממקום אחד. לדוגמה, אחת ההמלצות הנה בעת הכנסת אפליקציה חדשה לארגון, מראש "להכין" את האפליקציה למצב בו היא צריכה לקבל נתוני אב (על לקוח/מוצר) ממקור חיצוני. צעד זה יעזור גם בהחלת הלך רוח ארגוני של אנשי האפליקציות / DATA וכד' שלא כל אחד שומר את הנתון בסביבתו התפעולית מטעמי נוחות. כמו בכל תחום בשנים האחרונות, גישת הפרויקטים הממוקדים/מדורגים מומלצת כאן על מנת להוריד את הסיכון, תוך ביצוע מינימום שינויים בכלים הטכנולוגיים (שמתפתחים בקצב מהיר מאוד).

ניהול ידע במוקד השירות - האתגרים, הפתרונות והטיפים

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

• ארגונים שעובדים עם מוקדים מבוזרים סיפרו על הבעייתיות שבשיתוף מידע בין המוקדים השונים. האתגר – כיצד ליצור בסיס ידע משותף?
• שאלה שהעלו ארגונים שכבר עברו את השלב הראשוני של יישום מנהלת ידע פנימית לנציגים - כיצד לפתוח את בסיס המידע שנצבר החוצה ל WEB, על מנת לאפשר שירות עצמי של לקוחות הקצה באמצעות אתר האינטרנט?
• בעיה מוכרת בשנים האחרונות - סביבת העבודה של נציג השירות הפכה להיות מסורבלת מדי. גם כך נציג השירות צריך להתמודד עם מספר מערכות שונות, והדבר כואב במיוחד כאשר מדובר במוקד שירות חיצוני כלפי הלקוחות החיצוניים. הוספת אלמנט ניהול הידע עלול לעכב עוד יותר את עבודת הנציג. האתגר הוא לחשוף אותו לידע הרלוונטי בצורה המהירה ביותר.
• במוקד שירות פנימי ל-IT האתגר העיקרי עמו הארגון מעוניין להתמודד הנו ניהול ה"בעיות" (השורש) ולא "קריאות" (התוצאה).
• התמודדות עם "מידע שמשתנה כל הזמן" – לדוגמה, ארגון מהתחום הפיננסי סיפר על שינויים המגיעים מהרגולטור כל הזמן, מה שגורם למידע שנציגי השירות צריכים להתעדכן לגביו להשתנות ולהתעדכן כל הזמן. התוצאה - גם נציגים ה"ותיקים" (שנה וחצי - נחשב לעובד ותיק) לא מעודכנים. אי ידיעה שכזו עלולה לעלות לארגון ביוקר. לדוגמה, בתחום הביטוח כל טעות יכולה להצטבר לסכומים גדולים בעתיד, ולכן קיימת רגישות גדולה לנושא.
• אחד המשתתפים בדיון סיפר כי בארגונו קיימת מערכת KM מסודרת לנציגים, ובארגון עצמו – לשאר העובדים - קיימת מערכת ניהול ידע אחרת, ואין חיבור בין המערכות השונות. להערכתו, קשה מאוד להוכיח הצדקה לאינטגרציה כזו של ניהול ידע לכל אורך הארגון, ולא רק ברמת השיחה עם לקוח.
• איך להציף את המידע הרלוונטי לנציג השירות בצורה המהירה ביותר, וכיצד לאתר את המידע הממוקד והרלוונטי ביותר?

הפתרונות הקיימים בהם ארגונים משתמשים כיום:
הדרך הבולטת ביותר שעלתה בדיון - "שלשות" – פיתרון לסיווג קריאות. רוב הארגונים שנכחו בדיון ניצלו דרך סיווג זו לצורך הצפת פריטי תוכן וקישור בין הKM ל CRM (כ"כיבוי שריפה" שאפשר לחיות איתו בינתיים). 'שלשה' – מושג בתחום השירות שמשמעותו סיווג פניות של לקוחות. בעזרת היררכיה של שלוש רמות (סוג, קטגוריה, ותת-קטגוריה) מגדירים סיווג של תקלה. ניתן להשתמש בנושא השלשות על מנת לקשר תקלה לתחום תוכן רלוונטי ברמת URL (לדוגמה, קישור בין הCRM לתחום הידע הרלוונטי המנוהל במערכת ניהול מסמכים).
בנוסף, ארגונים משתמשים במערכות מדף שונות, כדוגמת מערכות ייעודיות ל- Knowledgebases או כאלה הכלולות במודול השירות של ה-CRM, מערכות שפותחו על גבי פורטל, שימוש במוצרי Rich Client / שולחן עבודה להצפת המידע הרלוונטי, כלי למידה/ "בועיות" שקופצות במערכת.

טיפים שניתנו במפגש לארגונים שנכנסים לתחום:

• אי אפשר לנהל הכל. כדאי לנסות להבין מה המידע הכי יקר לארגון, ואותו לנסות לנהל. מה הידע שהכי משתמשים בו? אם מצליחים להוריד שם את השיחות ההשפעה תהיה גדולה יותר.
• בדר"כ אחוז גדול מהפניות הנן פניות "תהליכיות" ולא טכניות (לדוגמה, באחד הארגונים ב 95% מהמקרים התמיכה היא תוכנית תהליכית - המשתמשים לא יודעים מה התהליך), במקרה והרבה תקלות הנן תקלות חוזרות, זמני השיחה במקרה זה ארוכים וזה בסדר כי משתמש שמקבל הסבר מקיף על הבעיה לומד ואז לא יפתח תקלה פעם הבאה. רואים את זה כסוג של הדרכה שיאפשר ירידה בבעיות חוזרות. במקרה זה שיטת המדידה של הנציגים צריכה לשקף זאת.
• לדעתי האישית, באופן כללי, ארגונים כיום לא מספיק שמים דגש על נושא פתיחת בסיס הידע החוצה ללקוחות חיצוניים - על מנת לאפשר גישה למידע בשיטת Self Service. ארגונים המתכננים לרוב מחפשים פיתרון טאקטי לצרכים פנים ארגוניים ולא מתכננים מראש את הצעד הבא – חשיפת אותו בסיס ידע לערוצים נוספים (האינטרנט הנו רק אחד מהם, בקרוב מאוד גם המובייל יהווה ערוץ חשוב לפחות לחלק ממידע זה). כלומר, בעתיד ייווצרו באותו ארגון "איים" של בסיסי מידע שונים לצרכים שונים שעלולים להיות לא מסונכרנים. במפגש שקיימנו, רוב הארגונים שנכחו במפגש לא הגיעו לשלב פתיחת בסיס הידע החוצה לWEB, והאווירה שעלתה היא שארגונים מעוניינים עד כמה שניתן לאפשר שירות עצמי בעיקר בשל מניע חיסכון בעלויות מוקד השירות, אך יחד עם זאת - קיימת זהירות רבה בנושא זה: ארגונים מעוניינים להגיע לשלב זה רק לאחר הטמעה מוצלחת ומוכחת של ניהול ידע פנים ארגוני (לנציגי השירות).
• במפגש עלתה דוגמה למתודולוגיה עולמית בתחום - KCS – Knowledge centered support, מתודולוגיה שלמה לאופן שבו מנהלים ידע במוקד שירות (נושא זה עלה בהקשר של מרכז שירות פנים ארגוני בתחום ה-IT). על פי מתודולוגיה זו התוכן נוצר תוך כדי פיתרון תקלות ומתפתח כל הזמן באופן שיתופי. פתרונות לבעיות יתועדו על ידי הנציגים, יש תהליך שנועד לאשר. לפי מתודולוגיה זו, יש בסיס של הדרכה אבל בשיטת המנהלת הרגילה (בה קיים גוף מרכזי שמעדכן את התכנים) הזמן שעובר מרגע שבעיה מופיעה עד שהיא מתועדת במלואה ארוך מדי. מתחילים למדוד את הרווח מהפיתרון בשלב מאוד מאוחר כי רק אז הוא מגיע למערכת. ואילו במתודולוגיה – KCS - הנציג אמור לחפש את הפיתרון במערכת ואם הוא לא מוצא – אמור למצוא פיתרון בעצמו, ותיעוד הפיתרון מחויב - אי אפשר לסגור קריאה עד שלא מתועד. צריך כתב טכני שמאשר את הפיתרון. זוהי מעין גישת "Web 2.0" של ניהול ידע (יותר ביזורי מאשר ריכוזי) – נותנים "בסיס" ומשחררים את התמיכה לשטח.
  

BI לנתוני SAP - רשמים משולחן עגול

בשולחן עגול בנושא BI לנתוני SAP בו השתתפו ארגונים משתמשי SAP, עלו הנושאים הבאים:

• שימוש ב-BW של SAP כ ETL מובנה לנתוני SAP: במפגש הייתה הסכמה כללית על השימוש הרצוי ב-BW כ'שער' לנתוני SAP. כלומר, גישה לנתוני SAP לא תתבצע ישירות מול ה-SAP התפעולי, אלא בכל מקרה הנתון יילקח מה-BW (עד כמה שניתן). השימוש ב-BW כשער גישה לנתונים הוגדר כ- Best practice. גם במקרה של ניתוח הנתונים שלא באמצעות כלי האחזור של BW, עדיין משתמשים ב-BW כמעין ETL מובנה. כמה ארגונים סיפרו כי הם מוציאים מידע מה-BW החוצה (באמצעות שימוש בכלי מובנה ב-SAP בשם Open Hub) בצורת קבצים שטוחים לדטהבייס חיצוני (אורקל, טרהדטה...) על מנת לנתח נתונים שם עם כלי אחזור שונים אליהם הארגון רגיל.
• סוגיה מרכזית שעלתה: היכן לבצע ניתוחים משולבים המשלבים בין נתוני SAP ונתוני Non-SAP? בשנים האחרונות מגמת שילוב כלי BI / DW / ETL מובנים בתוך חבילות אפליקטיביות (ERP, CRM, ניהול קמפיינים, תכנון תקציב וכד') הולכת וגדלה, מה שמכתיב ארכיטקטורת DW יותר מבוזרת (על פי סקר שערכנו, לכ75% מהארגונים קיים DW מרכזי, ולצידו – מספר דטה מרטים ייעודיים ל ERP וכד'). אולם מה קורה כאשר צריך לבצע ניתוחים משולבים, תוך שימוש בנתונים המגיעים מהDW המרכזי והן מהדטה מרטים הייעודיים? במפגש עלתה שאלה זו כסוגיה מרכזית – היכן מבצעים ניתוחים משולבים? שתי הדרכים האפשריות לניתוח משולב של נתוני SAP בשילוב עם נתונים ממערכות תפעוליות אחרות: העברת נתוני NON SAP ל BW; והעברת נתוני SAP ל-DW הארגוני. במפגש עלו דוגמאות לכאן ולכאן ולא הייתה המלצה חותכת לדרך נכונה אחת, משום שהדבר תלוי בארגון, באופן יישום ה-SAP ובמידת מרכזיותו בארגון. שני פרמטרים עיקריים היוו קוים מנחים לבחירה:
  1. המידה בה הארגון מבוסס SAP (בארגונים מבוססי SAP בהם % הכיסוי של האפליקציות על ידי SAP היה גבוה, הנתונים הועברו ל-BW). אם ה-SAP מהווה רק סביבה לניהול תהליכים אדמיניסטרטיביים ומכסה רק עשרות % בודדים מתהליכי הארגון, בדר"כ בארגונים אלה קיים DW אחר, ולרוב - ביצוע ניתוחים 'משולבים' יבוצעו שם (למעט מקרי קצה בודדים בהם ה-BW מהווה המרכיב העיקרי בניתוח).
  2. שיקול נוסף מוביל – היכן המסה העיקרית של הנתונים? אם רוב הנתונים לצורך הניתוח המשולב נמצאים ב-SAP ורק מעט מגיעים מה-DW הארגוני, הם יועברו ל-BW ושם ייעשה הדיווח, ולהיפך. איפה שהמסה של הנתונים יותר גדולה – שם הם יישארו ויתוחקרו.
  אם אין צורך לניתוחים משולבים, משאירים את נתוני SAP ב-BW (משתדלים לא לשכפל).

נושאים נוספים שעלו:

• ארגונים סיפרו ניסיונות לשימוש בכלי אחזור צד-שלישי מעל סביבת ה-BW.
• במפגש עלו כמה טיפים ושיטות עבודה עליהן ארגונים המליצו. בין ההמלצות שעלו: שימוש ב SAP Portal ושימוש בסביבות עבודה מוכנות (Business packages) של SAP.
• במפגש עלו גם יחסי כ"א ומיקומם הארגוני של אנשי הBW / SAP BI.