Einat Shimoni הבלוג של עינת שמעוני

תיעדוף טיפול בלקוחות

2011-05-19T05:07:00.000-07:00

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

"מפלטינום ועד D: מערכות ה-CRM של חברות הסלולר נותנות בכם סימנים

כיום, ישנן מערכות שמזהות את טון הדיבור של הלקוח חברות הסלולר מתעדפות את הטיפול בלקוחות על פי נוסחה מדויקת ומורכבת שבסופה המסקנה - כמה אתם שווים לחברה?
19.05.11 11:16 רותי לוי

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

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

כמה אתם שווים לחברת הסלולר? ממידע שהגיע ל-TheMarker המודל האנליטי לחישוב שווי לקוח פרטי מורכב ממשתנים רבים כמו כמות המכשירים שרכשתם, תקופת המנוי שלכם בחברה, גובה החשבונית ותמהיל השיחות היוצאות והנכנסות. לכל דבר יש משקל ובסופו של דבר כל הציונים שקיבלתם מתרכבים לכדי נוסחה ברורה שמייצרת אותיות. לקוח חדש הוא לקוח N, מעמד זמני למשך שלושה חודשים, עד שהחברה תבין כמה הוא שווה לה. לקוח C הוא לקוח ממוצע. לקוח B שווה מעט יותר, ולקוח A הוא הלקוח מועדף. הנתיב המהיר ביותר לקבלת שירות טלפוני מהיר שמור לבודדים המקוטלגים T/P, מלשון: פלטינום או טופ.

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

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

למאמר באתר דמרקר לחצו כאן.

מגמה חשובה בעולם ה-BI/DW

2011-04-24T03:38:00.000-07:00

מאמר שכתבתי בנושא Big Data ו DW Appliances התפרסם בדמרקר:

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

לתופעת הגדילה האקספוננציאלית של נתונים בארגונים קוראים כיום בספרות "big data" וזהו גם אחד הנושאים במחקר בתחומי ה-BI, למשל. בעקבות זאת, עלה טרנד חדש בעולם ניהול ואחסון הנתונים: קופסאות ענק (Appliances) שמנהלות כמות אדירה של נתונים. קופסאות אלה יחליפו את בסיסי הנתונים הקלאסיים המרכיבים כיום את מחסני המידע. הן מורכבות בתצורת "קופסאות שחורות", שמכילות חומרה, יכולות עיבוד נתונים מתקדמות (in memory processing, parallel computing, column-based computing), רכיבי ETL ואינטגרציית נתונים, וכן יכולות אנליטיות מובנות. הביצועים של קופסאות אלו הם מצויינים (פי 10-עד פי 100 מאלה של DW "קלאסיים").

היתרונות שבאימוץ קופסאות אלה - חוויית משתמש טובה, ביצועים טובים ולכאורה (אם נשארים "בתוך גבולות הקופסה") - עלויות תחזוקה נמוכות ו-time to market מהיר. חשוב לשים לב גם לחסרונות - העיקרית שבהן הגדלת התלות בספק מחשוב. בדומה לעידן ה-MF, בו ארגונים קנו קופסה באופן די דומה, בעידן ה-APPLIANCES אנו קונים הכל מספק אחד. לכן חשוב לנסות ולהגביל תלות זו עד כמה שניתן, לדוגמה - על ידי הכללת סעיפים לגבי רכש עתידי בחוזה.

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

הקופסאות החדשות יהוו גם אתגר עבור החלוקה המבנית של מחלקות ה- IT. עד כה, מחלקות אלו עבדו בראייה של צוותים ולא בצורה רוחבית: צוות תשתיות, צוות אפליקציות, צוות אינטגרציה וכו'. אך מה קורה כשצריך לנהל וליישם קופסה שמכילה את כל שלושת רכיבים אלה? תחת איזה צוות הנושא יושב? האם יהיו צוותים חוצי תחומים שיטפלו ב-DW, ERP, CRM? מה זה אומר לגבי הכישורים הנדרשים מעובדי IT?

בעולם ה-BI, למשל, שבו ישנה הפרדה ברוב הארגונים בין צוות ה-BI ובין ה-DBAs, שיושבים תחת מחלקת התשתיות ומספקים שירותים לצוות ה-BI, כבר יש סימנים של שינוי. אם ניקח, לדוגמה, ספק APPLIANCE ותיק ומוכר - NCR TERADATA, נראה שבארגונים המפעילים טכנולוגיה זו כבר קיים שילוב: בד"כ ה-DBA של DW מבוסס טרהדטה, יושב במחלקת ה-BI ולא במחלקת תשתיות. זאת, לעומת ארגון בו ה-DW מבוסס אורקל/מיקרוסופט, בו ה-DBA יושב במחלקת תשתיות, שכן מדובר ביכולת כלל ארגונית ולא ספציפית לעולם ה-DW.

2011 Enterprise Applications Trends

2011-03-31T06:27:00.001-07:00

Check out my presentation from STKI's summit 2011:

2011 Enterprise Applications Trends

View more presentations from Einat Shimoni.

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

2010-12-02T05:37:00.000-08:00

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

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

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

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

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

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

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

2010-10-19T14:01:00.000-07:00

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

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

2010-10-19T06:17:00.000-07:00

מאמר שכתבנו - צוות האנליסטים של 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

2010-09-23T02:03:00.000-07:00

הוזמנתי להעביר הרצאה בנושא ווב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

2010-09-04T02:14:00.000-07:00

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

2010-07-05T02:44:00.000-07:00

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

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

2010-06-23T08:52:00.000-07:00

מדי פעם אנו עורכים מפגשי סיעור מוחות - מפגשים בנושאים חדשים יחסית בהם אין 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

2010-06-15T03:57:00.000-07:00

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

2010-06-02T05:16:00.000-07:00

לאחרונה ערכנו שולחן עגול בנושא 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?

2010-05-08T06:24:00.000-07:00

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

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

מה התנאים שצריכים להתקיים על מנת ששוק ה-MDM יפרוץ בישראל באותה מידה כמו בשוק הבינלאומי?

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

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

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

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

2010-04-07T07:17:00.000-07:00

מאמר שכתבתי על רשימת הדברים שכדאי לבחון לפני שנכנסים ל- 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

2010-03-18T04:18:00.001-07:00

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.

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

2010-02-22T07:30:00.000-08:00

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

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

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

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

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

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

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

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

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

2010-02-16T10:35:00.000-08:00

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

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

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

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

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

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

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

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

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

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

2010-02-02T12:58:00.000-08:00

מחקר של 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 בישראל סוף סוף מתחיל להפשיר?

2010-01-31T11:10:00.000-08:00

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

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

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

2010-01-27T10:39:00.001-08:00

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

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

2010-01-11T13:24:00.000-08:00

בשולחן עגול בנושא 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.

סיכום העשור

2009-12-31T12:22:00.000-08:00

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

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

סיכום עשור מבחינת תשתיות מחשוב
העשור שהתחיל ב- 2000 התאפיין בעיקר בשינויים טכנולוגיים מהירים. קצב הכניסה והשימוש של טכנולוגיות חדשות היה מסחרר וישנם מקרים שבהם עד שהטכנולוגיה נקלטה כבר נמצאו לה מחליפים לדוגמה טכנולוגיית ה- infiniband שמוחלפת במידה מסוימת על ידי טכנולוגיית ה- IP הסטנדרטית או דוגמה אחרת טכנולוגיית VISTA אשר מוחלפת ב- Windows7.
מאפיין נוסף ודרמטי הוא השימוש ב- Open Source. ממצב שבו Open Source היה נחשב לנחלתם של "תמהוניים" ו-"מבזבזי זמן" עד למצב שבו פתרונות Open Source מהווים נדבך חשוב תעשייה המהווה מקור הכנסה ותעסוקה למגזרים רבים.
מאפיינים נוספים בתחום התשתיות הנם הגידול המדהים באחסון, השימוש הנרחב בשרתים רבים וכעת בשרתים וירטואליים, מעבר מתפיסת client server לתפיסה של WEB כאשר לקח גם זמן להבין את המגבלות של טכנולוגיה זו.
מבחינת תחנות קצה, מחשבי ה- PC והמחשבים הניידים שבתחילת העשור היו בשימוש רק בקרב מתי מעט וכעת מהווים כמעט רוב, היה שיפור גדול בחוזק מבחינת חישוביות אולם במובנים רבים התפיסה של PC (או נייד) נשארה די זהה לכל אורך העשור. יש להניח שבעשור הבא התפיסה תשתנה גם עקב הכניסה של מחשוב מבוסס ענן וגם עקב הכניסה החזקה של מחשבים מתחום ה- smart phones אשר יתפסו נפח יותר ויותר הן בקרב ארגוני ה- IT והן בקרב המשתמשים הסופיים.

איך שגלגל מסתובב
מבחינה מסוימת אנחנו צופים שהעשור הבא יעמוד בסימן של "בחזרה לעתיד" כלומר חזרה לקונספט שהיה בעבר ונזנח. דוגמה אחת היא המעבר למחשוב מבוסס ענן אשר נמצא בשימוש נכון להיום בישראל בעיקר בחברות גלובליות אך בעתיד יחדור גם לארגונים מסורתיים. מדובר בתמצות בחזרה ל"לשכת שירות" – קונספט שרווח בעולם בשנות ה- 80 – מדובר על לשכה אשר מספקת שירות למספר רב של לקוחות תוך שיתוף המשאבים בין הלקוחות. בדיוק המודל של "מחשוב ענן".
תחום נוסף שבו אנו צופים שתהיה "חזרה לעתיד" הוא תחום ה- appliances או industry in a box. עם בעשור האחרון תפסו הטכנולוגיות והפלטפורמות הסטנדרטיות מקום מהותי יותר יותר הרי שכעת מדברים על כך שיצרנים יארזו מספר טכנולוגיות (אומנם סטנדרטיות ברובן) יחדיו. לדוגמה VBLOCK של EMC\VMWARE\CISCO או EXADATA של ORACLE. העובדה שלקוח מקבל פתרון עובד מזכירה גם היא את שנות ה-80 שבה הלקוח קיבל פתרון ייחודי מ- DIGITAL או IBM.

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

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

2000-2010 באפליקציות ארגוניות לארגון ולמחלקת הIT
אפליקציות ארגוניות בתחילת העשור נבנו בראייה מאוד "מונוליטית" בהתאם למחלקות הארגון השונות – כספים, משאבי אנוש, ייצור וכד'. ארגונים עסקו בפרויקטי ERP (המשך המגמה מהעשור הקודם), פרויקטי CRM (ברובם תפעוליים), פרויקטי BI, ניהול ידע, כאשר לרוב השאיפה הייתה לעבוד עם כמה שפחות ספקים (גישת הERP הקלאסית).
כיום ארגונים מתמודדים עם מספר גדול של ספקי אפליקציות, וכבר ברור שמספר ספקי האפליקציות בארגון כנראה ימשיך רק לגדול, ככל שהסביבות הופכות להיות יותר ממוקדות תהליכים/אירועים.
בכל הקשור לאפליקציות המיועדות לניהול מחלקת הIT עצמה, בעבר ארגונים התרכזו יותר בתפעול ומתן תמיכה. אפליקציות בתחום Office of the CIO - המסייעות למחלקת הIT להתנהל כגוף עסקי עם מטרות, יעדים, סיכונים, סדרי עדיפויות וכד', החלו לצוץ רק בשנים האחרונות והם ימשיכו להעסיק ארגוני IT גם בשנים הקרובות.
בתחום ה CRM ראינו התרחבות מתמדת של ערוצים שונים באמצעותם הלקוח מדבר עם הארגון, אתרי אינטרנט זכו להרבה תשומת לב בעשור זה ונראה שהערוץ הבא יהיה המכשיר הסלולרי. להערכתנו, ארגונים יעסקו בחשיבה על מודלים עסקיים חדשים באמצעות Mobile Internet/Apps ומחלקת הIT תצטרך להיערך מבחינת הארכיטקטורה והכנסת כלים מתאימים לפיתוח ולתחזוקה של ערוץ זה.
בתחום ה-DW רמת העדכניות כל פעם נבחנת מחדש, כאשר מתהליכים Batch של שבוע עברנו לתהליכים יומיים וכיום נושא ה Real Time / Near Real Time הנה דרישה אמיתית עמה מתמודדים מנהלי DW/BI לחיות. ובצד הBI – נושאים כדוגמת BI אקטיבי (לעומת פסיבי) ואנליטיקה מתקדמת יותר נכנסים כשלבים מתקדמים יותר המעורבים קשר אדוק יותר לתהליכים התפעוליים.
השפעות Web 2.0 בהחלט הורגשו בארגונים, במיוחד בכל הקשור ליוזמות ניהול ידע. כעת ה HYPE מעט התפזר וארגונים עדיין מתמודדים עם הצורך לנהל "קשרים" בתוך הארגון ברמות שונות, כמו גם קשרים מחוץ לארגון, נושא לחלוטין לא פתור ומאוד מאתגר.

באילו מוצרי קוד פתוח ארגונים עושים שימוש כיום? חלק ב'

2009-12-24T07:23:00.000-08:00

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

בקרב ארגוני Enterprises (לא מדובר על בתי תוכנה המשלבים פתרונות אלה בתוך מוצריהם אלא ארגוני משתמשים), דוגמאות לתחומים בהם ארגונים עושים שימוש כיום בקוד פתוח – כפי שעלה מהמפגש:

שרתי לינוקס – כבר ממש ב Mainstream
APACHE על לינוקסים (APACHE צוין כתחום ה-OS המצליח ביותר)
צוין שימוש בשו"ב מבוסס OS של חברה ישראלית (CENTERITY). צוין כי המחיר נמוך והמוצרים טובים. הגמישות המאפיינת מוצרי OS הנה חשובה מאוד במיוחד בנושא שליטה ובקרה.
שימוש ב OPEN OFFICE: בקרב אחד הארגונים הגדולים בין 20-30% מהמשתמשים עובדים על-OPEN OFFICE. מובן שהכנסה של Open Office לארגון מחייבת הערכות – תאימות אפליקציות, הפצת תוכנה והכשרת גורמי ה- Service Desk.
ProgressSQL - דטהבייס OS ה"כבד" יותר (כלומר, שאפליקציות כבדות יחסית יושבות עליו).
mySQL – דטהבייס OS שנחשב יותר "לייט"/אינטרנטי. כיום חלק מהליך הרכש של אורקל את SUN.
צוין שימוש מעניין במוצר מבוסס קוד פתוח לניהול עבודות והדפסות – ארגון אשר לקח מוצר (CAPS), גייר אותו והוסיף עברית.
שימוש ב Jasper soft (מוצר BI מבוסס OS) לנושא דוחות (למוצר זה קיימת גרסה חינמית וגרסה מסחרית - בתשלום, ארגון זה עושה שימוש בגרסה החינמית).
שרתי APP SERVER – JBOSS מבית REDHAT.
מנוע BPM המבוסס על פרויקט OS – JCAPS Sun, מבוסס על OpenESB.
שימוש ב-BIRT (מיזם OS BI) לנושא דוחות BI
בעולם ה ALM כלי בקרת תצורה – המוצרים הרבה יותר זולים ויש הרבה יותר שימוש ב OS. נזכיר כמה: Bugzila, Subversion , Hibernate , Maven Jmeter, Junit וכד'.
Thunderbird – מוצר דואר אלקטרוני (תחליף לoutlook), מצריך plugin לעברית. אם מתקינים על WIN הם לוקחים את העברית של ה WIN.

דוגמאות נוספות (שלא עלו במפגש אך רלוונטיות למוצרי קוד פתוח קיימים):

שימוש בנושאי Web 2.0 שונים, כאשר הבולט ביניהם – ה MediaWiki לבניית Wikis, וכן Wordpress לבלוגים
שימוש במוצרי WCM (Web content management) – ג'ומלה - Joomla, דרופל - Drupal, דוט נט ניוק – Dot Net Nuke ועוד
מוצר לניהול למידה LMS – Moodle
מוצר לתחום e-Learning מבוסס SPS – Sharepoint Learning Kit - SLK
מוצר OS יחסית בולט בעולם בתחום CRM – SugarCRM
מוצר BI נוסף (בנוסף לJaspersoft ולBIRT אשר עלו במפגש) – Pentaho
מחולל יישומים קוד פתוח פרי פיתוח ישראלי שנקרא Buildagate של חברת AAI
מוצר למסרים מיידיים - Spark
טכנולוגיית חיפוש בולטת בעולם - Lucene
חישובים סטטסטיים ב- http://www.r-project.org/
Quant lib – למתמטיקה פיננסית
ESPER בתחום של CEP - Complex Event Processing
פתרונות TRADE
מוצרי Open source ניתן למצוא כמעט בכל תחום, ודווקא ככל שהתחום יותר חדשני / איזוטרי/ נישתי, כך הסיכוי למצוא חלופת קוד פתוח גדלה (לדוגמה, קיימת גרסת Open Source של 2nd life – בשם OpenSim).

נשמח לשמוע על פתרונות נוספים מעניינים שאינם מוזכרים...

מה ארגונים בישראל חושבים על קוד פתוח? חלק א'

2009-12-24T07:09:00.000-08:00

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

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

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

התמונה שעלתה במפגש היא שתחום הקוד הפתוח כבר די נפוץ באזורים מסוימים (כדוגמת תחום מערכות הפעלה לשרתים ותחומים תשתיתיים נוספים אותם נפרט בהמשך), לעומת תחומי אפליקציות ארגוניות (ERP, CRM, BI, WCM וכד') בהם עדיין נדיר למצוא כלי קוד פתוח מיושמים בארגוני Enterprises.
מסר חשוב שעלה מהמפגש הוא שלא ניתן ולא כדאי להתעלם מאופציית השימוש בקוד פתוח בהרבה מתחומי העשייה ב-IT (בהמשך הסיכום נתייחס לתחומים בהם ארגונים ציינו כי לא ישתמשו בקוד פתוח והסיבות לכך). מוצרי קוד פתוח בתחומים מסוימים מתחילים להיבחן על אותה סקאלה של בחינת כל מוצר אחר, עם דגשים אופייניים לתחום זה – לדוגמה, סוגיות משפטיות.

עם זאת ברצוננו לציין שרובם המכריע של ארגוני ה- enterprise מתייחסים למוצרים מתחום הקוד הפתוח כמו שהם מתייחסים למוצרים אחרים שאינם מתחום הקוד הפתוח. הארגונים בוחנים את בשלות המוצרים, את מידת התמיכה, מידת ה- certifications השונים , כלי צד שלישי שתומכים במוצר וכד'.
ברוב רובם של הארגונים אין התייחסות למימד ה"פתוח" של מוצרים הן בהקשר של "תמיכה פתוחה" – תמיכה שמסתמכת על הקהילה והן בהקשר של "קוד פתוח" – אפשרות לפתח את המוצר על ידי הוספת קוד המשפר את המוצר ה"פתוח" שהתקבל מהקהילה. פיתוח שבסופו של דבר עשוי לחזור לקהילה. על פי התנהלות המפגש, הגורמים היחידים שמוכנים לשקול את הצד "הפתוח" במוצרים הם ארגונים שהם יצרני תוכנה בעצמם.

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

יתרונות מוצרי קוד פתוח (כפי שעלו מהדיון):
להלן מספר יתרונות כפי שעלו בדיון. מדובר על יתרונות אפשריים בתחום – לא על יתרונות שקיימים בכל המקרים.

חדשנות, גמישות
סקלביליות ומחיר – בניגוד למוצרים מסחריים, הגידול בשימוש אינו מחייב גידול במחיר. במידה וארגון משתמש בפתרון קוד פתוח שהותאם לארגון מבחינה פונקציונלית ומבחינת תמיכה, גם אם יהיה שימוש נרחב יותר לא תידרש תוספת תשלום.
פשטות
נושא השליטה – בעקרון, אין חברה אחת ששולטת בקוד אלה הקהילה. כאשר רוכשים "חברת קוד פתוח" (דבר מאוד פופולארי לאחרונה) רוכשים למעשה את גוף התמיכה. כאשר במקביל יכולים לצוץ גופי תמיכה אחרים, גם אם לא זהים לגמרי. למשל, CENTOS בתחום לינוקס ו- mariaDB בתחום מסדי נתונים. כאשר הקוד ממשיך להיות מפותח לפי ה- open process המקובל.
הסכנה שמוצר OS מצליח ייעלם קטנה. הקוד עצמו שנכתב "נתרם" על ידי אנשים, וזה מעוגן משפטית. אבולוציה – "המוצר החזק שורד". בOS צריך "להמר" על איזה מוצר חזק מספיק כדי לשרוד, איזה מוצרים מקבלים יותר תשומת לב לעומת מוצר ש"נזנחים". אחת מהשיטות המעניינות שצוינו לצורך כך - להתחבר ל mailing list כדי לראות מה פעיל ומה לא פעיל (מה שגם מראה שחשוב להיות מעורבים ו"חלק מהקהילה").
נטען כי כשהפוקוס של ארגון הוא שירות ולא רישוי (כפי שאכן קורה בארגוני קוד פתוח), השירות הנו הרבה יותר טוב. חברות שמוכרות מוצר קנייני - לכאורה פחות אכפת להן לתת שירות טוב.
במוצרי קוד פתוח קיימות בדר"כ 2 גרסאות – גרסת Community שהיא חינמית, וגרסת Commercial שהנה בתשלום. העובדה שלמוצר OS מסחרי קיימת גם גרסת Community מאפשרת תמיד לראות מה יתפתח הלאה בגרסאות הבאות. כמו כן, מאוד קל לבחון את המוצר בפועל, ניתן לעבוד עם המוצר הקהילתי שנה-שנתיים, ואם רוצים - לקנות אח"כ את הגרסה המסחרית.
INNOVATION BY INTEGRATION – לחברה שמפתחת מוצר אין יתרון תחרותי לפתח הכל בעצמה. היא לוקחת רכיבים שונים ומחברת, וזה היתרון / החדשנות שהיא מציעה. כל חברה מתרכזת במה שהיא עושה הכי טוב. (זוהי אחת הסיבות שקוד פתוח הרבה פעמים מוזכר באותה נשימה עם תחום ה Cloud/SaaS שגם כן מאפשרים לחברות להתרכז בmain business שלהן). לדוגמה, צ'קפוינט כוללת הרבה רכיבי OS במוצר, BING של מיקרוסופט מבוסס על תשתית STORAGE OS וכד'.
העובדה כי במודל ה-OS קיימת ליבה וסביבה כל אחד (היצרנים עצמם) מפתחים הרבה דברים משלימים. משמעותה שהמוצר המתקבל הרבה יותר קרוב לצרכים של צרכני הקצה

מהם החסמים שעוצרים את שוק הקוד הפתוח בישראל?

כשל שוק: השוק הישראלי מאוד מושפע מספקי ה-IT, ובמיוחד הספקים הגדולים. ארגונים ישראלים אינם חשופים לפתרונות קוד פתוח במידה רבה משום שאותם ספקים\אינטגרטורים אינם חושפים אותם לפתרונות אלה בתשובות על מכרזים וכד'. הועלתה התלבטות באשר למחויבות של ממשלת ישראל לנושא, והאם עליה לדרוש בחינה של לפחות מוצר קוד פתוח אחד בבחינת כלל מוצרים לתחום מסוים. באופן כללי, האינטגרטורים לא מספיק מכירים את מוצרי קוד פתוח, וכך קורה שאם הארגון לא רואה את הפוטנציאל בעצמו ודוחף זאת אקטיבית, הוא בדר"כ כלל לא חשוף לאופציה – וזו בעיה שעוצרת את השוק מלהתפתח. בעיה נוספת שמקשה ומרתיעה אינטגרטורים היא שבקוד פתוח האינטגרטורים יותר חשופים כי הלקוחות יכולים לבצע code review אמיתי.
מחסור בכ"א – בחלק מעולמות התוכן אין הרבה אנשי קוד פתוח בישראל – לדוגמה, PHP בישראל, וכל מערכי ההכשרה לתחום זה פחות נפוצים.
אחת החששות של ארגוני ENTERPRISE – השקט הנפשי. ארגונים רוצים לדעת שגם אם עוד 7 שנים אני אחפש תמיכה לא תהיה בעיה למצוא אותה. להערכת אותם ארגונים האפשרות לקבל תמיכה בטווח הארוך גדולה יותר במוצרים מסחריים מאשר במוצרי קוד פתוח.
הנושא החוקתי משפטי- מה מותר ומה אסור? איך מעגנים חוזית בצורה הכי בטוחה מבלי לחשוף את עצמם לעניין תביעות? יש חברות שכבר יישמו מדיניות קוד פתוח. במוצרים פנימיים ארגונים ציינו שאין סוגיות בעייתיות, וישנן דוגמאות לחברות שלוקחות אחריות על נושא זה – לדוגמה, RED HAT נותנת לארגון שרוכש לשימוש פנים ארגוני LEGAL ASSURANCE, ואף נותנים ללקוח קוד חליפי אם יש תביעה. אם יש תביעה מגלגלת את האחריות אליה. יש הרבה כסף בצד שמיועד למקרי תביעות. לעומת זאת, במוצרים חיצוניים (המכוונים כלפי לקוחות הארגון) - כדאי להתייעץ עם יועץ משפטי. מסוכן להיכנס לקוד פתוח בלי להתייעץ עם ה LEGAL בייחוד ליצרני תוכנה כי יש חברות שפשוט מעתיקות קוד ומהצד השני יש חברות (בעיקר משפטנים) אשר מחפשים שימוש לא חוקי בקוד פתוח ומבצעות תביעות.
שאלה נוספת שעלתה - איך מנהלים נכסי קוד פתוח שאין להם ערך כספי – בספרים? והאם בכלל מנהלים?

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

What's next for SAAS after CRM? HR related functions

2009-12-14T11:09:00.000-08:00

The Israeli market was slow to adopt SaaS solutions. Slowly but surely, there are several hundred organizations now using SaaS solutions in areas such as CRM, Web 2.0 (Wikis, blogs), and ERP.

So what's the next solution organizations will be willing to consider in SaaS delivery model? I think HR-related processes are a good candidate. The (slow) adoption process taking place in Israel is actually quite similar to the U.S market just a couple of years ago.

Looking at the worldwide market, SaaS or on-demand HR solutions were typically implemented in Small-medium sized organizations (in the past these were more of an ASP model) but are also starting to make an impact in large organizations.

HR functions are often "outsourced" functions, sometimes even used in a BPO model. This is one of the reasons the SaaS delivery model for HR software is appealing even for larger organizations.

At the moment it seems that certain HR functions in particular are being used in the SaaS model (for example, e-recruitement, payroll, employees performance management, e-Learning) as opposed to outsourcing the full set of HR functions.

Traditional HCM vendors are moving more and more into the on-demand space and offering a choice between on and off premise models.
Cutter Consortium's recent SaaS survey clearly shows that organizations of all sizes are taking advantage of a wide array of horizontal (i.e., functional) and vertical (i.e., industry-specific) SaaS applications. The growing interest and adoption of SaaS by corporate users is encouraging SaaS alternatives to traditional packaged applications to emerge in virtually every software category. In this survey, most organizations that were asked what type of horizontal apps they're considering using or already using in the SaaS delivery model, HR functions were quite common (right after CRM, Content Management & collaboration).

Here are some examples of several prominent worldwide SaaS HR vendors (or vendors that most of their income comes from the saas model):

Workday - a relatively new provider of ERP-like on demand solutions, centered around HR, payroll and financials. It's founder was Peoplesoft's leader so this created a "buzz" in the HR space...
Kenexa - e-recruitement and employee performance management
Ultimate Software - is doing well in the large organizations' space, offers both on and off premise models.
Salary.com - for talent management, compensation, payroll
Cornerstone - on demand HCM and Talent management, compliance is considered a strong point in this solution.
Learn.com - mainly SaaS. Learning management and HCM.
Nuview - Not a pure Saas solution but now about half the revenues come from the saas model, mainly aimed at midsized companies
Skillroad - recruitement and skills management, mainlly targeted at midsized organizations
Successfacors - employee performance management in SaaS, have some presence in Israel.
Taleo - erecruitement and talent management, have some presence in Israel.
Authoria - erecruitement, assessment and performance management.

How will these solutions be accepted in Israel? What will be the adoption level? my guess is that the same type of clients that adopted CRM Saas solutions - technological/ global companies and also SMBs will be the more natural candidates. Most companies have "some sort of HR system" in place but the implementation is usually very basic, and doesn't include things like recruitement, incentives management, performance, skills and talent management. So there is a lot of potential for this type of solutions in Israel. Many other factors will affect the Israeli's CIO decision: Hebrew support, localization, price, local support (viable integrators that can support the product for the long run) are just a few of these factors.

אפליקציות Mobile - אין גבול לחדשנות

2009-12-10T12:13:00.000-08:00

אחד התחומים החמים יותר על האג'נדה של מנמ"רים, מנכ"לים ומנהלי פיתוח עסקי לקראת 2010 - עולם ה Mobile, ובתוך כך - אפליקציות סלולריות שהארגון מספק ללקוחותיו החיצוניים. כעת, כאשר הiPhone עושה את כניסת הבכורה שלו לישראל (ועוד חודשים לפני כן...), חלק מהארגונים כבר נערכים ובודקים האם/ואילו אפליקציות כדאי להציע למשתמשי האייפון העתידיים בישראל, שיהוו חלק מלקוחותיהם ולקוחותיהם הפוטנציאליים.

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

המדיה הסלולרית לוקחת את תועלות אתרי האינטרנט באספקת שירותים ממוקדים/פרסונליים ללקוחות, ומוסיפה עוד כמה תועלות חשובות, שהנן ייחודיות להו:
· ניתן לספק ללקוחות אפליקציות מבוססות מקום
· ניתן לספק ללקוחות אפליקציות מבוססות זמן
· המכשיר נמצא עם הלקוח כמעט כל הזמן!
· לקוח שמשתמש באייפון הנו בהגדרתו לקוח שצורך אפליקציות מובייל -השימוש בהן מאוד טבעי עבורו
· מדיה שמספקת חוויית משתמש עשירה
אם נוסיף לכך את העובדה שבשוק הבינלאומי נושא ה Mobile payments – התשלום באמצעות הטלפון הנייד, צובר תאוצה, הרי שמודלים עסקיים חדשים לחלוטין מתאפשרים, כמו location/time based promotions, קבלת מבצעים הרלוונטיים לחנות הקרובה לשעתיים הקרובות בלבד וכד'.

דוגמאות מעניינות, על קצה המזלג:

אפליקציות בנקאיות – מעניין לראות שבתחום זה נוצר מעין "סטנדרט" כאשר הבנקים אשר פיתחו אפליקציות iphone (כדוגמת בנק אוף אמריקה, סיטיבנק וכד') מספקים 4 שירותים בצורה כמעט זהה: בדיקת יתרה, העברת כספים, תשלום חשבונות, ואיתור סניפים / כספומטים קרובים. האפליקציה של בנק אוף אמריקה היא האפליקציה הפיננסית החינמית המורדת ביותר ב Appstore (נכון לנובמבר 2009). בנוסף בדר"כ ישנן אפליקציות למשתמשים "כבדים" - סוחרים בניירות ערך וכד'.

הזמנת מונית באמצעות אפליקציה (אפליקציה מבוססת מקום וזמן - שמזמינה מונית בהתאם למיקום בו אתה נמצא)

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

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

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

אין ספק שמשתמשי Smartphones של היום, אשר עושים שימוש בגלישה ובאפליקציות סלולריות, יתחילו לצפות מהבנק שלהם להציע להם אפשרות לבדיקת חשבון הבנק באמצעות המובייל, יחפשו מידע על מסעדות בעיקר דרך מדיה זו, יתקשרו עם חבריהם ברשתות החברתיות השונות באמצעות המכשיר... והחברות המסחריות שיתעלמו ממדיה זו באספקת מוצריהם/שירותיהם עשויות לפספס לקוחות אלה. על פי מחקר של חברת Celent, כבר כיום אחד הקריטריונים לבחירת בנק בעיני כ50% מאנשים המשתייכים לדור ה-Y הנו היכולת לקבל שירותים מהבנק באמצעות המכשיר הסלולרי (SMSים, גלישה, אפליקציות). כמו כן, על פי Celent, 30% מבתי האב בארה"ב יבצעו פעולות בנקאיות באמצעות הטלפון הנייד עד 2010 (לעומת 10% בלבד ב-2008).

כשה Web 2.0 פגש את ה CRM

2009-11-25T13:41:00.000-08:00

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

לקוחות מקשיבים בעיקר להמלצות חבריהם, וכיום המלצות אלה הרבה יותר זמינות ופתוחות לעיניי כל.
הצד השני של התופעה - לקוחות משתפים הרבה יותר מאשר בעבר, לטוב ולרע. לקוחות לא יהססו לדווח ל100 החברים שלהם ברשת החברתית על איזה שירות גרוע קיבלו מחברה במוקד הטלפוני, או על איזה ארוחה מעולה הם אכלו אתמול במסעדה. לקוחות מדווחים ברמות שונות – אם באמצעות בלוג, טוויטר, רשתות חברתיות שונות, הכנסת המלצה/חוות דעת על מוצר, או אפילו Ranking פשוט, ויש להם רצון / אינטרס לעשות זאת מסיבות שונות.
לקוחות מצפים מארגונים לאפשר להם לצרוך שירותים בכמה שיטות שונות – אתם יכולים להעלות על דעתכם בנק שאינו מאפשר פעילויות אונליין באתר האינטרנט שלו? שלא יכול לשלוח דיווחים על החשבון באמצעות אימייל/אתר ייעודי? הנושא של ריבוי ערוצים הוא משהו שלקוחות מצפים לקבל ומחקרים מראים שלא רק שהדבר מהווה מרכיב בהחלטה על עבודה מול ארגון כדוגמת בנק, אלא שלקוחות שמשתמשים במספר ערוצים שונים "שווים" יותר לארגון מלקוחות שמנצלים רק ערוץ אחד (כלומר, לקוחות יותר פעילים הצורכים יותר שירותים/מוצרים).
לקוחות רוכשים הרבה יותר on-line כיום מאשר בעבר.

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

מה מצב הכלים הטכנולוגיים בתחום זה?
ספקי ה-CRM כוללים יכולות Social CRM בחבילותיהם (בדר"כ לא את כל היכולות, אך חלק מהן), כמה מהן לדוגמה (רשימה חלקית): Siebel, SAP (Sentiment Analysis), Salesforce. וכמובן שיש כאן גם אינסוף סטארטאפים... תחום ה Web 2.0 הנו מונח שה-VCs כנראה מאוד אוהבים לשמוע.

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

ERM - באזוורד קטן לתחום גדול

2009-10-21T10:21:00.000-07:00

מאמר שכתבתי על נושא ניהול סיכונים ארגוניים (Enterprise Risk Management) פורסם בדהמרקר:

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

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

מי פה מנהל את הסיכון? סיכונים תמיד היו ותמיד היה צורך לקחת אותם בחשבון. ההבדל הוא שכיום ארגונים יותר מודעים לצורך לנהל אותם, והבדל נוסף חשוב - בעבר לסיכון לא ממש היה OWNER, כיום מדברים הרבה על ניהול סיכונים / Risk Governance. אבל מי אחראי על תחום כל כך רחב – ניהול סיכונים בכל הארגון שכוללים סיכונים שקשורים בשוק, סיכונים משפטיים, סיכונים פיננסיים, תפעוליים ועוד? בארגונים כמו בנקים שבהם RISK משולב הלכה למעשה כבר בתוך תהליכים התפעוליים יש מנהל מוגדר. בארגונים אחרים אחריות זו משולבת בתוך מחלקות שונות (משפטי, תאימות לרגולציה... עד הרמה האסטרטגית) וברובם אין מנהל סיכונים ארגוני.

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

"איפה הROI?" היום מבקשים ROI גם על יוזמות ERM וכבר לא מסתפקים רק ב risk management for the sake of risk management (כלומר, אין לנו ברירה ואנחנו חייבים לעשות פרויקט ניהול סיכונים). אין ספק שנקודה זו תהיה מאתגרת במיוחד עבור ארגונים ישראליים וייקח זמן עד שנדבר על פרויקטי ERM במונחי ROI.

"החיבור החדש: ניהול סיכונים + ניהול ביצועים". בעולם ניהול הביצועים / balanced scorecard כיום טוענים כי לכל KPI צריך להיות אינדיקטור של סיכון. זה ה balance החדש של עולם ניהול הביצועים.

מסתמן כי תחום ה-ERM (ניהול סיכונים ארגוני) יהפוך להיות באזוורד חשוב לא רק לבנקים/ חברות ביטוח וחברות שעוסקות בRISK בצורה מסודרת, אלא יתרחב גם לתחומים שונים בארגון (שיווק, HR וכד'). השאלה העיקרית תהיה: כיצד מנהלים תחום כ"כ רחב, שאמור להוות מרכיב בכל החלטה אסטרטגית שהארגון לוקח, אמור לעניין כל מנהל מחלקה עסקית בארגון, וצריך להיות משולב הן ברמה האסטרטגית והן ברמה הטאקטית (איך מבטיחים שנושא ניהול הסיכונים נאכף)?

שוק ה-MDM: ההבטחות, הסיכונים, התועלות

2009-10-19T15:32:00.000-07:00

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

כל מי שעוסק בתחום ניהול נתונים / MDM / איכות נתונים נתקל במונח מאוד "אמריקאי" שנקרא Data Governance: התהליך השלם של טיפול במחזור החיים של ניהול נתוני אב לאורך כל הארגון. נתוני האב מתייחסים לישות מסוימת (לקוח/מוצר/ספק/עובד/אחר), והמטרה היא לגרום לכל הארגון להסתכל להתייחס ולטפל בנתוני האב (שם, כתובת, סטטוס וכד') של אותה ישות בצורה מרכזית, אחידה ומנוהלת. לכל "נתון אב" שכזה (לדוגמה, כתובת למשלוח דואר) יש מישהו שאחראי על זמינות אחידות ועקביות אותו נתון לאורך כל הארגון.
בהרצאה מצוינת אותה העביר Aaron Zornes, מומחה מוערך וידוע בתחום, מייסד ומנהל ארגון ה-MDM Institue, עלו כמה מגמות חשובות לשנים הקרובות בתחום MDM ,Data Governance והקשר שביניהם:

בשל המצב הכלכלי בשנה האחרונה 20% מפרויקטי ה-MDM הגדולים בעולם קפאו ונמצאים במצב on hold, אך עדיין מוציאים כסף על data governance כי אין ברירה. ההערכה היא שהתחום יגדל בשנים הקרובות, משום שעכשיו זה זמן טוב לטפל ב-MDM בשל צירוף של הכלכלה המתאוששת עם הרגולציה המתחזקת (במיוחד בתחום השירותים הפיננסים). ארגונים ינסו לשפר את מצב בשלות ה-DG שלהם, רובם יעסקו בנושא הלקוח כנושא עיקרי (תחת ההנחה שרווחת בהרבה ארגונים כי נתוני המוצרים שלהם תחת שליטה).
כיום עדיין קיימת הרבה מאוד בנייה של פתרונות (לעומת אימוץ כלים) על ידי יועצים ובתי תוכנה שונים. אין סטנדרטים. כל אחד עושה את זה שונה. אין ספק שהשוק יבשיל אך זה ייקח זמן עד שהתחום יהפוך להיות Mainstream.
הבנה כי DG (אחריות ניהולית על נתונים) הנה חלק בלתי נפרד מפרויקט MDM ולא משהו שנזכרים בו אחרי שמתחילים. (הדבר קצת מזכיר מה שקרה בישראל בתחום ה-balanced scorecard, כאשר ארגונים מיהרו ליישם טכנולוגיה ונזכרו בתהליך העסקי של הגדרה מסודרת של מטרות הארגון, יעדים וגזירת מדדים כמחשבה שלאחר מעשה). המסר העיקרי הוא שלא ניתן להפריד את נושא ה-Data Governance מנושא ה-MDM.•
MDM טומן בחובו תהליך פוליטי בארגון, במהלכו יש להחליט מהם מקורות הנתונים האמינים עליהם הארגון צריך להישען. יחידות בעלות כוח בארגון בדר"כ לא ירצו לעבוד בשיתוף עם המחלקות האחרות, אין ממש תמריץ לעבוד ביחד. התוצאה היא שמחלקות מסוימות חושבות שהן ה"בעלים" של נתונים, וחלק מהמאמץ בפרויקט MDM הוא לעשות מעבר תפיסתי מגישת ה ownership על נתונים לגישת ה-sterwardship: אף אחד לא ה"בעלים" של המידע ולא משנה כמה כוח יש לו.

בהרצאתו, זיהה זורנס שני סוגים של פתרונות:

פתרונות ניהול נתונים פסיביים (Passive Data Governance): מגיבים לדברים שקרו לא טוב באיכות נתונים, ובונים חוקים בשביל לטפל בזה. רוב השוק נמצא כאן והפתרונות הטכנולוגיים ברובם משתייכים לקטגוריה זו.
פתרונות ניהול נתונים אקטיביים (Active Data Governance): גישה פרואקטיבית - מפעילים חוקים עסקיים שהוגדרו מראש לניהול של מידע עסקי.
מבחינת הספקים, רובם, על פי הגדרתו של זורנס, הנם Passive-Aggressive (אומרים שהם ACTIVE כאשר למעשה הם PASSIVE).אנו אכן רואים שרוב הספקים הולכים לכיוון האקטיבי, אך הלקוחות עדיין לא ממש שם מבחינת הצרכים שהם מביעים. אין ספק שהתועלת העיקרית העסקית האמיתית טמונה בפתרונות אקטיביים עם מעורבות עסקית גבוהה בהגדרת החוקים העסקיים סביב הטיפול בנתונים.

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

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

DG זה לא תהליך BATCHY אלא משהו שצריך לקרות בזמן אמיתי - מי ניגש לנתון? מה הוא עושה איתו? זה לא "הכל או כלום", יש נקודות כניסה שונות.כמעט בכל חברת ייעוץ בתחום MDM תמצאו שקף דומה שמדבר על מצב הבשלות של Data Governance בארגונים: האם קיימת "אנרכיה" (מושכים נתונים כשצריך, ברמת האפליקציה), האם "פדוליזם" (ה IT הנה הגוף שמניע את הנושא), "מונרכיה" (מצב יותר טוב - אנשי הביזנס מניעים את הנושא), "פדרליזם" – הגישה המנצחת, גישת ה SOA. מהניסיון שלנו בשיחות עם ארגונים, לרוב לא ממש קיימת אנרכיה אלא פדוליזם – יש איזו שהיא מדיניות בIT לסינכרון נתונים תפעוליים בשיטות שונות, אך אין שילוב של ראייה עסקית.

בהרצאה, זורנס עקץ את ספקי כלי ה-MDM באומרו כי רובם נבנו בראייה שניהול נתונים הנו מאמץ פרויקטלי שמתבצע בצורה Batchית (כלומר תהליך פסיבי), וכי המתודולוגיות וההתנהלות בתחום הנה פרויקטלית, במקום לגבש ראייה ממוקדת נכסים (נתונים = נכס) שיש לנהל לאורך זמן, לקבוע חוקים עסקיים לטיפול בנתונים בצורה פרואקטיבית ולא לאחר מעשה.ביקורת נוספת היא שאין התייחסות לקהילה הארגונית כאלמנט חשוב בניהול נתונים (לדוגמה, ויקי לבניית מילון ארגוני בארגון גלובלי) אלא תחת ההנחה שמישהו אחד מחליט בעצמו על הנתון.הוא העריך כי נותני השירותים הגדולים - הSIs הגדולים - יתמקדו באספקת מסגרת ל MDM בשנה הקרובה, וכי ספקי החבילות הטכנולוגיות יספקו פתרונות ACTIVE DG אמיתיים ב-2011-12.

בעיית כ"א:

על כל 1$ שארגון מוציא על תוכנה של MDM, הוא יוציא 3-4$ נוספים על מרכיב השירותים בפרויקט (לספק שירותים – SI). כיום קיים מחסור גדול באנשים בעלי ניסיון ממש של ניהול פרויקט MDM מוצלח (קשה למצוא אחד כזה, בלתי אפשרי למצוא שניים). יש הרבה אנשים שהוכשרו אך אין הרבה עם ניסיון ובטח שלא ניסיון בפרויקט מוצלח.

מהו הROI של MDM?

במצגת בנושא MDM ROI, הוצג מודל של אורקל לבחינת ROI של MDM, וגם הוצג Case Study של לקוח. ארגונים נוטים לחשוב ש-MDM ו-ROI לא הולכים ביחד. אולם דווקא בגלל ש-MDM זו טכנולוגיה תומכת, יותר תשתיתית מאשר אפליקטיבית, חוסר היכולת "להראות" למנהלים העסקיים משהו מוחשי רק מדגישים את הצורך לבצע business case ולהציג הצדקות עסקיות.

במצגת, אורקל הציגה תוצאות של בחינת ROI שהיא עשתה בקרב לקוחותיה, שמתרכז בתחומי צמיחה, הגברת אפקטיביות, ושיפור הAgility של מחלקת ה-IT. הנה כמה דוגמאות לתועלות שנמצאו:

הורדת זמן הזמנות ב-2% כתוצאה מיישום MDM לנתוני מוצרים (PIM)
שיפור אחוז ההיענות לקמפיינים ב-15%
הורדת עלות סיכון אשראי ב-2%
הורדת עלויות שנתיות לטיפול בתאימות לרגולציה ב-75%
באופן כללי, החזר השקעה תוך פחות מ-12 חודשים.בנוסף,
הודגש כי MDM לניהול נתוני לקוחות משפר את הROI ממערכות CRM (לדוגמה, שיפור פרודוקטיביות במוקד השירות כתוצאה מיישום CRM בסביבות 13%, שיפור כתוצאה מיישום CRM + MDM: 18%).

בכנס הוצג Case study של חברת Zebra העולמית, שיישמה פיתרון MDM של אורקל (UCM מבית סיבל). בחברה זו לפני הכנסת MDM עבדו 140 (!) מערכות תפעוליות שונות שטיפלו בנתוני לקוחות. כ 90% מתקציב הIT הופנה למאמצי תחזוקה של מערכות legacy, כתוצאה מכך גוף הIT נתפס כגוף טכני בלבד ללא השפעה אמיתית על הביזנס.מצד אחד, במצגת הודגש ההבדל הגדול בין חברות גדולות בינלאומית לחברות ישראליות (בחברה זו בעבר נתוני לקוחות הוכנסו ב 140 מערכות תפעוליות שונות!) ומצד שני תוארו כמה אתגרים עיקריים וניתנו טיפים ליישום שבהחלט ניתן ללמוד מהם:

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

מאמץ עיקרי היה להעביר מנהלי אפליקציות/תחומים עסקיים מהלך רוח של data ownership (בעלות על נתונים) ל data stewardship (נותני שירות - מספקי נתונים לשאר הארגון).

מבנה ארגוני – מצד אחד פונקציה מרכזית גלובלית "Data Governance", מצד שני "Data Stewards" שמשויכים לאזור מסוים ולתחום אפליקטיבי/עסקי מסוים. ה Data Stewards חוטפים על הראש מהDG במקרה שמשהו לא עובד כמו שצריך.בין התועלות שהושגו כתוצאה מיישום MDM (שעדיין ממשיך) בחברה זו כלל גם הפחתה של 60% בעלויות הIT (אשר, כזכור, משקיעה מאמצים רבים – כ90% מכלל המאמצים – בתחזוקת המערכות השונות והאינטגרציה ביניהן).

פרשנות STKI

בתכנון פרויקט MDM צריך לקחת בחשבון מקדמי סיכון ולא להיות מופתעים יותר מדי כשמתעוררים משברים בפרויקט מאתגר זה (במקרה זה תמיכת הנהלה בכירה מאוד תעזור). הסיכונים הכרוכים בפרויקטי MDM: מציאת כ"א (כולל מנהלי פרויקט, יועצים וכד') מנוסה באמת שיכול לחלוק מידע ולדעת ממה להיזהר. השינוי הארגוני שכרוך באימוץ MDM הוא משמעותי, החל מנציג השירות אשר עבורו תהליך פתיחת לקוח/שינוי פרטים ישתנה, דרך מנהלי תחומים שיידרשו להתיישר לפי סטנדרטים של master data כלל ארגוניים, דרך שינויים שצריך להכניס באפליקציות הלגסי שיעבדו מול אותו HUB מרכזי (ולא מול ה-master data שנמצא בבסיס הנתונים של המערכת עצמה). מציאת יועצים ומומחים בתחום שידעו להזהיר מהמכשולים הצפויים או להימנע מהם מראש תהיה משימה כמעט בלתי אפשרית.בנוסף, יש מבנה ארגוני שלם תומך שיש לגבש: אותה ועדת Data Governance אליה ידווחו Data Stewards. סביר להניח שבארגונים ישראליים, בשל העובדה שאין ארגוני ענק בישראל, data stewards יהיו אנשים שיעשו זאת רק כחלק מעבודתם השוטפת. לא ברור האם תהיה ועדת Data Governance ותחת מי היא תשב. כרגע רוב יוזמות ה-MDM שעולות מגיעות ממחלקת הIT ואנו לא רואים עדיין מעורבות עסקית מספקת בתהליך זה. הנחתנו היא שבישראל הגוף העיקרי שיניע פרויקטים כאלה יהיה גוף ה-IT, זה לא אומר שהפרויקט בהכרח נדון לכישלון, אך במצב כזה צריך לעשות מאמצים לגייס כמה שיותר שותפים בכירים בהנהלת הארגון ובמחלקות העסקיות השונות. ואם גופי IT בישראל ירצו לערב יותר את הביזנס (מה שאין ספק שצריך לקרות כדי שפרויקטים אלה יתרוממו) הם חייבים להתחיל לדבר במונחי תועלות עסקיות, כדוגמת אלה שתוארו כאן. בשל חוסר ניסיון בישראל בתחום ה-MDM, כדאי לנסות וליצור קשר עם ארגונים (או באופן עצמאי או באמצעות המיישם/ספק החבילה) שיישמו חבילות MDM בחו"ל וללמוד מניסיונם.בכנס אורקל הוכרזו פתרונות אורקל חדשים בתחום ה-MDM לניהול נתוני ספקים, ניהול נתוני רכש לארגון גלובלי). נראה שמגמה זו של אספקת פתרונות שונים ייעודיים לישויות השונות (MDM לנתוני לקוחות הנו מוצר אחד, MDM לנתוני מוצרים – מוצר שונה) מאוד שכיח בקרב הספקים (לכל סוג של פתרון יש מודל נתונים שונה). אולם לאחרונה ארגונים בחו"ל מתחילים לגבש מחדש ארכיטקטורת MDM, בשל איי ה-MDM שמתחילים להיווצר בארגונים – MDM לנתוני לקוחות, MDM לנתוני מוצרים וכד'. נוצר צורך לקשר בין אותם איים, כך שלמרות שבהחלט מומלץ ליישם כלי MDM בגישה מדורגת, ולטפל בעולם נתונים אחד כהתחלה לפני שעוברים לעולם נתונים שני, אך עדיין צריך לחשוב על היישום הכולל ככזה היאפשר לקשר בעתיד בין האיים השונים.

To ERP or not to ERP?

2009-09-30T13:15:00.000-07:00

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

במקביל, בשנה האחרונה שוחחתי עם שני ארגונים שכבר יישמו ומפעילים מערכות ERP, ושוקלים האם בדיעבד הכניסה של הארגון לתחום ה ERP הייתה כדאית (שאלה שמחלקת הIT קיבלה מההנהלה הבכירה)? מהן התועלות שהתקבלו?

אני מחלקת את פרויקטי ה ERP לשני סוגים (חלוקה הכרחית כדי לענות על שאלות אלה):

ERP 1: זהו הERP הקלאסי שכולל את התחום הפיננסי, הלוגיסטי ומשאבי אנוש. בתחום זה ארגונים מעוניינים להיות "סטנדרטים" ולעבוד בצורה דומה לזו שארגונים אחרים עובדים. עוד לא פגשתי ארגון שראה תועלת בפיתוח של מערכת הנהלת חשבונות ייעודית לצרכיו הספציפיים. להערכתי, כאן אין שאלה וברור שיישום ERP הנו הצעד הנכון – תחום ה ERP מספק את ה best practices / התהליכים הארוזים הג'נריים, שדומים וצריכים להיות דומים לאלו שמנוהלים בחברות אחרות. קטלוג סוג התועלת העסקית המתקבלת ממערכות ERP תחת קטגוריה זו, לדעתי, אינה צריכה להיות "חיסכון בעלויות פיתוח המערכות", או חיסכון בעלות הממשקים בין מערכות שונות, וגם לא בכיוון של התייעלות הארגון וחיסכון בעלויות, אלא לדעתי צריך להסתכל על מערכות ה ERP כמערכות תשתית לכל דבר – תשתית אפליקטיבית הכרחית. לאחר יש פה גם את האלמנט של "יישור קו" עם התעשייה. לדעתי, הערך העסקי עליו ארגונים דיברו בכניסה לפרויקטי ה ERP מגיע אח"כ, בשלבי ה ERP הבאים... אבל כדי להגיע אליהם צריך ליישם את אותה תשתית אפליקטיבית – ה ERP 1 – זהו הבסיס ממנו ניתן לצמוח הלאה.וכאן אני רוצה להדגיש את ההמלצה שכבר הפכה להיות שחוקה, אבל היא כ"כ נכונה, במיוחד לאור זאת שמדובר על תשתית אפליקטיבית שאמורה להיות די דומה מארגון לארגון – להיצמד עד כמה שניתן לחבילה. בישראל אנו נוטים לבצע שינויים רבים בחבילות מדף, ובתוכן גם חבילות ERP (עפ"י נתון באדיבות NessPro– המתבסס על מוצר בשם Intellicorp אותו היא מייצגת בישראל, ארגונים משתמשי SAP מפתחים כ-30% קוד מקוסטם לעומת סטנדרטי! זהו נתון מדהים כשלוקחים בחשבון שההמלצה היא לשקול פיתוח אם מדובר על שינוי של מעבר ל10-15% בחבילת המדף). מבדיקות שעשיתי לאחרונה על יחסי כוח אדם במחלקות ERP ראיתי קשר ברור בין רמת הקיסטום של הERP לגודל מחלקת הERP שתומכת בו לאורך זמן. אין ספק שארגונים שנצמדו לסטנדרט הרבה יותר יעילים ביחסי כ"א שלהם לעומת ארגונים שפיתחו דברים ייחודיים, וגם הרבה יותר גמישים "לשחק" עם נושא ה sourcing (להשתמש בחלקי משרות חיצוניות במקום להחזיק אדם פנימי במשרה מלאה לנושא מסוים פשוט כי הוא "מכיר את הייחודיות של הארגון שלנו").

ERP 2: השלב בו רוב הארגונים הגדולים בישראל נמצאים כיום, לאחר הכנסת ERP 1. כאן מדובר על הכנסת מודולים שכבר יותר מתקרבים לעיסוקו הייחודי של הארגון, והשמים הם הגבול מבחינת הערך העסקי האפשרי. בזכות אותה תשתית אפליקטיבית שיושמה בשלב ה ERP1, הארגון יכול להתרחב לתחומים שונים ולהכניס מודולים חדשים, בהנחה שהספק בדר"כ יקדים את צרכי הארגון (לדוגמה, כאשר נכנסת רגולציה חדשה בשוק וספק ה ERP כבר פיתח/רכש יכולות אלה, כך שהארגון יכול להתמודד עם דרישות אלה ע"י הכנסת אותו מודול, מה שהיה מצריך ממנו מאמץ גדול הרבה יותר בפיתוח היכולות בעצמו). כלומר, ההתקדמות הזו עם צרכי השוק והארגון זהו בעצם הערך האמיתי שמתקבל בסוף הדרך. ההתרחבות כאן היא גם לתחומים ורטיקליים/תחומי ליבה, וגם לתחומים הוריזונטליים (לדוגמה, הכנסת מודול ניהול סיכונים, תכנון תקציב, פורטל משולב, BI משולב וכד'). משלב זה, ה ERP 2, בהחלט ניתן ורצוי לצפות לתועלות עסקיות, שהתקבלו בזכות אותה תשתית אפליקטיבית – ה ERP 1.הבעיה מתחילה כשההנהלה מחליטה לבדוק בסופו של שלב ה ERP 1 (לאחר מאמץ לא מבוטל, בדר"כ, של כל הארגון), מה בעצם קיבלנו מהמאמץ האדיר הזה?

לסיכום, כדי להתחיל להתמודד עם השאלה – To ERP or not to ERP – הארגון צריך לענות על השאלה עד כמה הוא מעוניין לעבוד "סטנדרטי" כמו ששאר התעשייה עובדת? באילו תהליכים כן ובאילו לא?בכל מקרה, בחירה בכיוון ה ERP צריכה לגרור אחריה תהליך תיאום ציפיות עיקש בנוגע לסוג הערך שאמור להתקבל מפרויקט זה. תיאום ציפיות זה עשוי לעזור באותה שאלת הערך והתועלת העסקית, וגם לסייע במיזעור הלחץ מהגורמים העסקיים להתאים את החבילה לצרכיהם הייחודיים. יש להבהיר כי כניסה לעולם הERP משמעותה התיישרות לפי תהליכים עסקיים סטנדרטיים ולשאוף עד כמה שניתן (תחת האילוצים הרבים הקיימים, שבחלקם פוליטיים) לבצע שינויים הכרחיים בשלב השני של הפרויקט, בו המשתמש יותר יודע מה הוא צריך. הארגון גם צריך להבין שהכנסת ERP משמעותה הכנסת תשתית אפליקטיבית שמרגע הכנסתה תהווה מעין "ברירת מחדל" לתחומים אפליקטיביים שונים שהארגון ירצה להיכנס אליהם, והשאלה הראשונה שישאל – "למה שלא ניישם את המודול של ספק הERP שלנו – שהפך להיות ספק האפליקציות שלנו?" ותשובה שלילית לשאלה זו תצטרך להיות מנומקת. כלומר, הארגון בוחר שותף אפליקטיבי שילווה אותו בצרכיו האפליקטיביים העתידיים השונים.

From the diary of a digital immigrant

2009-09-19T00:58:00.000-07:00

I wasn't "born into the facebook revolution, I'm in no way a "generation Y" or a digital native. When I first heard of Twitter I thought it was the most ridiculous concept. I couldn't understand why anyone in their right mind would want to participate in all this social stuff. I'm a pretty private person, so posting so much information about myself and exposing it for the world to see was the most un-natural thing for me.

Actually, it still is.

The only difference is that now I see the value in all of this. I think there are different types of benefit categories to be gained from social media:

Know "what's going on":
Being a research analyst, I have to be updated about my coverage topics (Enterprise applications, Business Intelligence, Knowledge Management, Social tools, MDM, BPM etc.) Staying on top of things means I have to go through about 20-30 websites a day. With 4-5 meetings a day there's very little spare time to read and research. The 70 people/sources I currently follow on Twitter actually provide me with the highlights of what's going on in topics that interest me in a nutshell, and that's pretty cool. This is REAL value for me. It's kind of the same value I would have gotten from RSS but it's all pretty new to me.

Know what people are saying about your brand:
This is something I am, personally, less familiar with. But I think for companies who want to check out their brand impact, the acceptance of new products just released to the market, social media and things like Twitter in particular, can give a real time snapshot that can begin to answer these types of questions. It doesn't replace traditional market research tools but should be looked at as a whole new set of tools that didn't exist so far because people didn't share so much real time data about what they're doing or thinking.

Damage control or crisis management:
Social media is the best platform, in my opinion, to provide instant, personal-like feedback to a crisis.
Of course, it also works the other way around: when your brand "messes-up" something, social media is the quickest way to make sure this mistake will spread around very quickly. Even if it's something very small, for example – 1.3 million (to date) people saw a video of a Comcast technician falling asleep on a customer's couch, while waiting on hold for Comcast call center.
At this stage, if a company's big enough that people will talk about it with their friends, it WILL have presence on social networks, like it or not. If a crisis occurs and is magnified in social media tools, the most effective way would be to reply by using the same social tools and social networks: respond by using the same media. For more – see an interesting post that discusses this "fighting fire with fire" strategy.

These are just a few examples of how social media provides the type of value that didn't exist before. I've been talking to several large companies in Israel lately on how social media applies to their organization. Most of them have no idea, some are actually thinking about it, but most are "brushing this trend away", saying they don't think there's real value.

I think companies should start to think and act quickly. And if most companies are not there yet, there's even a larger advantage to be gained for the early adopters.

Happy new year, Shana Tova!

טיפים ליישום פרויקט ERP

2009-09-07T13:50:00.000-07:00

להלן כמה טיפים שנלמדו כתוצאה מפרויקטי ERP רבים שהתבצעו בישראל:

לבחור היטב את אנשי היישום של הספק (לבדוק המלצות ויישומים קודמים), הדבר במיוחד נחוץ כאשר סוגרים פרויקט ב “Fixed". לדרוש אנשים ספציפיים עד כמה שניתן, גם אם זה אומר עלות גבוהה יותר. ארגונים רבים הדגישו כי איכות וניסיון אנשי היישום מהווים גורם מכריע בהצלחת היישום, ועמידה בלו"ז.
מה שכבר נשמע כמו המלצה שחוקה לחלוטין מוכיח את עצמו - השלב הראשון של היישום צריך להיות כמה שיותר "סטנדרטי" (לנסות להיצמד לחבילה ולא לבצע שינויים רבים). לאחר שימוש של 2-3 שנים במערכת, המשתמשים הרבה יותר יודעים להגיד מה הם רוצים ואיך הם רוצים וצריכים לעבוד. ארגונים רבים נמצאים כעת בשלב זה.
כמו כן, יישום סטנדרטי יסייע משמעותית בהמשך הדרך להוריד עלויות תחזוקה ותמיכה שוטפות. מסקר יחסי כוח אדם שביצענו בישראל עלה בצורה ברורה כי בארגונים בהם נצמדו יותר לסטנדרט, מחלקת ה ERP משמעותית קטנה יותר מארגונים בהם פותחו שינויים רבים והמערכת הותאמה משמעותית לצרכי הארגון. אין זה מפתיע, שכן הדבר משפיע ישירות על יכולת הארגון לעבוד מול ספקי תחזוקה חיצוניים. כשהיישום הנו סטנדרטי אפשר להיעזר בכ"א חיצוני בצורה יותר תכופה, מה שיכול לסייע בעבודה במודל של חלקי משרות במקום החזקת אדם במשרה מלאה לתפקיד ייעודי. בארגונים בהם היישום כ"כ ספציפי לאותו ארגון, אין ברירה אלא להחזיק אדם שמכיר את היישום והארגון ולא ניתן להחזיק אותו ב"רבע / חצי משרה". נציין כי בישראל רמת השינויים שארגונים מבצעים במערכות הERP (ובכלל) הנה גבוהה משמעותית מזו המקבילה בחו"ל. בהמשך אקדיש לכך פוסט מפורט.
תמיכה לאחר עלייה לאוויר – משתמשים ציינו כי זהו נושא בעייתי שלרוב אינו מתוקצב / מוערך באופן מספק. תמיכה של חודש לאחר עלייה לאוויר לא מספיקה! זוהי התקופה שהארגון מתחיל לעכל "מה נחת עליו", משתמשים רק מתחילים להשתמש, ורק אחר כך מתחילות הבעיות והבדיקה בפועל של כל התהליכים שתוכננו. כל דבר שעושים בפעם הראשונה צריך ללוות את המשתמש. למודולים הקשים היו לקוחות שציינו כי היו צריכים ליווי של 4-6 חודשים.
בפרויקטים כיום אני ממליצה בחום לבחון שימוש בכלי EPSS – Electronic performance support system או כלים אחרים המסייעים בתחום של הטמעה ולמידה מתמשכת. כלים אלה יכולים לסייע בהפחתת עלויות הדרכה ראשוניות ושוטפות, והנם כלים יעילים להדרכת והנחיית המשתמשים תוך כדי ביצוע הפעולות ברמה תפעולית.
לתקצב ו/או לפרט בחוזה באופן פרטני את נושא ההדרכה –במיוחד בעייתי כשמדובר במספר גדול של משתמשים. אנחנו כל הזמן שומעים מלקוחות שתקציב ההדרכה היה נמוך מדי ולא נלקח בחשבון. היו מקרים בהם הספקים "ספגו" את רוב הפער אבל לעתים הארגונים עצמם. ישנם לקוחות שציינו כי הם לא חשבו לתקצב דברים כגון עזרים טכניים, הדפסת חומרי הדרכה... ארגונים אחרים הניחו ששיטת ה Train the Trainers תספק אותם ובפועל זה לא הספיק.
ארגונים עמם שוחחתי המליצו כי אותם אנשים שמשמשים חלק מצוות היישום הפנימי בשלב הקמת הפרויקט ישמשו חלק מצוות ה- Center of Excellence של הפרויקט לאחר עלייתו לאוויר.
נושאים שבעבר לא תוקצבו וכיום מקבלים יותר חשיבות: הסבת נתונים, טיוב נתונים ובדיקות. אלה פרויקטים חשובים בפני עצמם.
המלצה חשובה אשר לפני כמה שנים לא ממש הייתה רלוונטית: להתחיל מראש, כבר בשלב הראשוני, עם BI ופורטל. לא לחכות ל"שלב ב". שילוב ה-BI כבר בשלב הראשוני מאפשר לקבל "תוצרים" מהיישום באופן מהיר, והפורטל צריך להיבחן ככלי המאפשר סביבת עבודה יותר נוחה למשתמשים. יש לבדוק אילו רכיבים פורטלים קיימים ניתן לקבל מראש מהספק (לדוגמה, בתחום הרכש וה HR לרוב ישנם "פורטלטים" מוכנים/סביבות עבודה מוכנות). מניסיון לקוחותינו, סביבת פורטל מעל ERP משפרת משמעותית את יכולת העבודה מול המערכת ומקצרת תהליכים "מסורבלים".

המלצות שונות נוספות ניתן למצוא:

1. כאן

2. כאן

3. כאן

מה ה ROI של BPM?

2009-08-26T09:51:00.000-07:00

לא כל תהליך ממוכן מצריך BPM.

הפוסט הבא ב JargonSpy משווה בין BPM ל WIKI – השוואה שעל פניו נראית מאוד משונה – הטענה היא שכשם ש ערך WIKI בנוי מהרבה תתי-ערכים שחלקם מוגדרים וחלקם יוגדרו בהמשך, תהליך ב BPM מסתכל על אוסף של תהליכים אחרים, וחלקי תהליכים שכולם מגדירים תהליך עסקי כולל, כאשר את "אבני הבניין" (=הערכים) ניתן יהיה לבנות אחר כך בהדרגה. אבל יש הסתכלות כוללת על תהליך-על.

לקוח שאל אותי לאחרונה מתי נכון לעשות שימוש בחבילת BPM לעומת שימוש ביכולות הWF שבמערכת תפעולית, לעומת פיתוח סטנדרטי?

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

תהליך גמיש אל מול תהליך נוקשה
ב BPM יש פוטנציאל בשיפור מתמיד של התהליך. אם התהליך הוא די סטטי, אשר לא אמור להשתנות עם הזמן, ואין פוטנציאל לתועלת משמעותית בשיפור התהליך, אזי הרבה פחות מעניין להשתמש בBPM לצורך "מיכון" של אותו תהליך ועדיף לקודד. כאשר מדובר בתהליך שיש לו חשיבות עסקית יחסית גבוהה לארגון, ששיפור שלו יכול לשנות משמעותית (וכמובן גם ליצור אפקט שיווקי מצוין ליוזמת ה BPM באותה ההזדמנות), זהו תהליך מתאים לBPM. לרוע המזל, תהליכים מסוג זה הם גם אלה שהנם בעלי סיכון גבוה יותר, בדר"כ לא ממש מוגדרים והגדרתם אינה עוברת בצורה הכי "חלקה", חוצי מחלקות/תחומים (ואז גם ישנה שאלה מי מנהל אותו), וקשור למספר מערכות שונות. שיפור תהליכים בעלי פוטנציאל ROI גבוה הנו בדר"כ גם יקר יותר למימוש באמצעות BPM וייארך זמן רב.
תהליך בעל השפעה עסקית גדולה מול תהליך אדמיניסטרטיבי ששיפורו אינו משמעותי
כלי BPM עוזרים לקשר בין צרכי המשתמש העסקי לתוצרים הטכנולוגיים, וזה לא רק ברמת הססמה. זה נשמע, כמובן, מצוין ודבר שכל ארגון היה רוצה, אבל לקשר הזה יש מחיר. לדוגמה, אם בעבר לכל שיינוי/תקלה שהייתה מתגלה בתהליך באפליקציה הפיתרון היה ברמה הטכנולוגית, מערכות BPM "מכריחות" לבצע שינוי עסקי לפני השינוי הטכנולוגי. זה יכול בהחלט להציק/להפריע לצד הטכנולוגי של העניין, אך משמר את אותו קשר חשוב בין ביזנס לטכנולוגיה. לדוגמה, BPMN – Business-process-modeling notation - השפה ה"גרפית" לתיאור תהליכים משמשת הן את המשתמש העסקי לצורך תכנון ומידול התהליך והן את המשתמש הטכנולוגי לתרגום אותו תכנון לתהליך ממוכן.
כלי ה BPM, ובתוכם רכיב הניטור והאנליזה (ה-BAM) מאפשרים למנהל העסקי של התהליך לבחון באופן שוטף את התהליך, לאתר בעיות בזרימתו, לתכנן ולבצע סימולציות כדי לשפרו.

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

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

מי פה מנהל את ה-MDM?

2009-08-17T11:31:00.000-07:00

אחריות על נתונים - Data Governance ("ממשל נתונים") - הנו תחום מלא בפוליטיקות, רגישויות, חשיבות עסקית גבוהה, אשר אמור להיות מובל / בבעלות מנהלים מהתחום העסקי בארגון, ולמרבה הצער, ברוב המקרים - משהו שכלל לא קיים בארגון.

בשנים האחרונות עולם ניהול הנתונים מקבל זרקור ותשומת לב מחודשת; הן הנושאים הטכנולוגיים הקשורים בניהול נתונים (וכאן נכנסים תחומים כדוגמת ניהול איכות נתונים, טיוב נתונים, ניהול רשומות אב - Master Data Managemetn, ניהול אינטגרציית נתונים וכד'), והן הנושאים העסקיים - Data Governance, Data Stewardship וכד'.

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

אז מי צריך לנהל מהלך של ניהול נתוני אב (Master Data Management)?
הנה רשימה של בעלי תפקידים שמעוניינים - או צריכים להיות מעוניינים - ב MDM. רשימה זו לקוחה מאתר מצוין, שמהווה מקור מידע עשיר ואיכותי לעוסקים בתחום ה-MDM. האתר שייך ל Aaron Zornes, שהנו אחד מהמומחים הראשונים שהחל לעסוק בתחום הMDM, הקים את ה MDM Institute ומעביר סדנאות בנושא.

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

היבט הניהול העסקי של הנתונים - לאחרונה מדובר רבות על מינוי Data Stewards (אין ספק שתרגום חופשי של המונח - "דיילי מידע" אינו מוצלח במיוחד). אנשים אלה בדר"כ יהיו נציגים ממחלקות עסקיות אשר אחראים על הגדרת "נתון אב" בתחום מסוים, עליהם לדאוג שנתון זה יהיה זמין איכותי ועקבי לכל אורך הארגוןן, הם אחראים על ניהולו השוטף וכד'). צד זה מנוהל ומובל על ידי מחלקות עסקיות בארגון.
היבט ניהול טכנולוגי של הנתונים - הקמת התשתית, חיבורה למערכות השונות, שינוי תהליכי העדכון והעבודה הטכנולוגית פיתוחית. החלק הטכנולוגי יכול להיות מנוהל על ידי אנשים מתחום התשתיות ארכיטקטורה ואינטגרציה (אלה שעוסקים בתחומי תשתיות אפליקטיביות חוצות תחומים), או על ידי אנשים שהתפתחו מתחום הBI/DW. כיום בשוק הבינלאומי מתחיל להסתמן חוסר באנשי MDM. אופציה נוספת לגורם טכני מוביל הנה אנשי אפליקציה תפעולית העיקרית הקשורה לעניין שלשמו מוקם הMDM (לדוגמה, אנשי מערכת ניהול לקוחות אם מדובר בMDM לצורך ניהול נתוני לקוחות).
יוזמת MDM בדר"כ מביאה להקמת "ועדת ניהול נתונים" חדשה, שכלל לא הייתה קיימת לפני כן. ועדה זו עוסקת בתחום הרחב של ניהול נתונים - Data Governance ולרוב תכיל בעיקר אנשי ביזנס אך גם אנשי IT. לכל "תחום עסקי" (לקוח/נתון פיננסי/מוצרים/ספקים). ועדה זו תהיה מעין מטריצה של אנשים שונים מתחום טכנולוגי ועסקי, ולעתים רבות תהיה ועדה וירטואלית (שכן אנשים החברים בוועדה יהיו בעלי תפקידים אחרים בארגון, אשר חוץ מביצוע תפקידם השוטף גם יקחו אחריות ובעלות על נתונים שונים).

ישנם כמה ארגונים (מחלקות IT) שמשוחחים עמנו כיום בהיבט היותר טכני על שיטות שונות לסינכרון נתונים תפעוליים (בין אם מדובר על DW תפעוליים שאחראים לעדכן מערכות תפעוליות, בין אם מדובר על ODS - Operational Data Store שממלאים אותה מטרה, ובין אם מדובר על בחינת תחום ה-MDM על היבטיו הטכנולוגיים בעיקר, ומעט על היבטיו העסקיים).

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

אתר האינטרנט כערוץ שיווקי: פער גדול בין העולם וישראל

2009-08-13T10:39:00.000-07:00

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

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

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

חוזק נוסף של ערוץ האינטרנט שלחלוטין אינו מנוצל בארץ (ובמידה מעטה עדיין בעולם) הנו נושא החדשנות מונעת-לקוחות Customer Centric Innovation. יש חברות שכבר רכבו על גל ה"שיתופיות" הקיים כיום באינטרנט, פנו לצרכנים וביקשו מהם להביע דעתם ובכך להשפיע על מהלכי החברה. 2 דוגמאות בולטות לכך הנן: רשת סטארבאקס עם יוזמה בשם my Starbucks idea (אתר בו גולשים מעלים רעיונות לשיפור מוצרי הקפה של סטארבקס, גולשים אחרים מדרגים אותם בלחיצת כפתור "חיובי" או "שלילי", והדבר החשוב ביותר – ניתן לראות באתר אילו רעיונות התקבלו). מיזם דומה נעשה על ידי חברת DELL – הנקרא Ideastorm. אין כאן איזה מאמץ טכנולוגי מסובך, במקרה גם שתי חברות אלה בנו את אתרי החדשנות שלהן על תשתית מוכנה (של חברת Salesforce), הדבר המעניין הוא שחברות אלה השכילו לנצל את העובדה שאנשים כיום רוצים ומוכנים להיות מעורבים יותר, ויצרו מנגנון אמיתי להקשבה ול"דיון" עם הלקוחות. מעורבות עם הלקוחות הפכה להיות קריטריון שיווקי חשוב ממדרגה ראשונה. אבל לא רק חברות מסחריות מעודדות מעורבות, כך לדוגמה בתוך האתר של ה UK Parliament מעודדים אזרחים להיות מעורבים, להצטרף לדיונים, להציע הצעות והכל בצורה מאוד ידידותית, נגישה ומזמינה.

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

Characteristics of great websites

2009-08-04T12:27:00.000-07:00

Recently more clients have been rethinking their web strategy. Organizations from the financial services, telecom, services, and public sectors are trying to "re-energize" their websites for various reasons, some are just trying to improve the company's image, some are trying to "get involved" in the many conversations taking place now, some are trying to increase self service processes via their website in order to reduce operational costs.

What are the current characteristics of great websites?

Up-to-date, informative, useful dynamic content, user generated content is a big plus
Usability and ease of use (“clean” interface, consistent navigation, effective search)
Collaborative and social tools, web communities (versus mass audience)
Interactive, creates user engagement
Self Service capabilities
Provide an interesting experience, entertaining
Educating
High ranking in search engines (SEO)
Syndication options (RSS, newsletter)

We see the following trends recently in organizations web strategies:

Self Service is a # 1 goal
From mass to individual communities
Mass adoption of collaborative Web 2.0 tools (in Israel it is still quite limited, which means this is the right time for companies to jump in)
The web is adding an “experience” element to a company’s product/service
Accessibility of websites is improving
Need to better analyze web activities and processes

Why is everything becoming so "social"?

That's because the "audience" (clients, citizens, employees, surfers...) is becoming more and more social. The "digital natives" / Generation Y/ Millenials are now such as a substantial part of the population to be ignored. This part of the population is a very HEAVY user of social networks (spends approx. 16 hours a week online, >95% of them are a part of a social network), they communicate, plan, work and learn in a different way, and social tools are very natural for them.

The fact is social network sites are now more popular than other sites and it doesn't look like it's going to change anytime soon.

הרצאה שהעברתי בנושא Web 2.0 לניהול ידע ב-SIGTRS

2009-07-25T02:08:00.000-07:00

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

להלן לינק למאמר /תקציר של הרצאתי אשר פורסם באתר של הקבוצה.

ממצא מפתיע לטובה - מבנה מחלקות הBI בישראל הרבה יותר טוב מאשר בחו"ל

2009-07-19T11:46:00.000-07:00

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

לעומת זאת, בחברות בינלאומיות גדולות קיימת בעייה ידועה של "איי BI" המתקיימים במקביל, צוותי BI שונים ללא תיאום משמעותי ביניהם, וחוסר סטנדרטים. התוצאה הנה חוסר שיתוף בידע לגבי פרויקטי BI דומים, המצאת הגלגל מחדש, וקיומם של כלי BI רבים תחת אותה קטגוריה (סביר מאוד למצוא 3-4 כלי Reporting שונים, 2-3 כלי OLAP, 1-2 כלי Data Mining וכד'). בשנים האחרונות אותם ארגונים בינלאומיים שחיים עם "שגרת איי ה-BI" עוסקים בפרויקטי BI Consolidation שמשמעותם לאו דווקא בניית Enterprise Data Warehouse אחד, אלא בניית ארכיטקטורה, התוויית מדיניות, קביעת סטנדרטים של כלים טכנולוגיים (צמצום מסדר גודל של כ-7 כלים שונים ל-3 כלים שונים), וכן – באזוורד חדש עליו מדובר כמעט בכל מחקר הסוקר מגמות BI: ה-BICC.

BICC – Business Intelligence Competence Center
קיימות מספר הגדרות שונות ל-BICC, אך הרעיון הוא שגוף זה אחראי על הסתכלות מרכזית על תחום ה-BI בארגון, הבנת הדרישות העסקיות, תיעדוף, והעברתם למחלקת הפיתוח של ה-BI שמתקיימת כגוף נפרד. יש הגורסים כי תפקיד ה-BICC ממשיך גם לנושא ההטמעה של יוזמות ה-BI בארגון, וכגוף המרכז את דרישות ה-BI של ההנהלה הבכירה.

בישראל חלק מהארגונים מביעים התעניינות ב-BICC (במיוחד הגדולים יותר, או אלה המקיימים מבנה יותר מבוזר). אולם אנו גם נתקלים לא מעט בארגונים שמרימים גבה לשמע תפקיד מחלקת ה-BICC שזוכה להרבה תשומת לב "באזוורדית" כרגע ולא מבינים על מה ההתלהבות – "הרי זה מה שמחלקת ה-BI שלנו עשתה מאז ומתמיד".

לסיכום, בישראל לפחות ארגונים יש צורך בפונקציית ה-BICC, לרובם קיים סטנדרט מסוים של כלים (לרוב ניתן יהיה למצוא 2-4 כלים שונים בארגון, ולא 7-8), קיים שיתוף ידע בגלל העובדה שצוות/י ה-BI יושב/ים תחת אותה מחלקה, ולרוב מחלקה זו מקיימת קשר הדוק עם המחלקות העסקיות.
כך שבסה"כ ניתן להתנחם בעובדה שלעתים דווקא העובדה שארגונים ישראליים יותר קטנים מאפשרת להם להיות יותר יעילים.

The next big thing in social media: Sentiment Analysis

2009-07-07T00:39:00.000-07:00

(This is a translation of the previous post)

As someone's who's been analyzing the Business Intelligence market for years, I'm very interested in exploring ways to leverage the vast amount of valuable data that is accumulated in social networks sites today, in the same way in which organizations can now leverage business information data that is kept (unlike the web - in a fairly orderly manner) inside their organizational applications and databases. Or perhaps this comparison is not a fair one and we should actually try to look at the content of social networks in a completely different way?

Marketing and PR departments are now trying to figure out "what is being said" about the company / product throughout the web, specifically in websites that are based on user generated content. This information can be extremely valuable, you can understand a lot about how your company / products / services are really perceived, what are the current preferences, trends, and characteristics of cultural consumption relevant to the company.
In order to satisfy exactly this need a new breed of data-mining tools aimed specifically at social networks started to emerge in recent years. These tools have some similarities to "traditional" data-mining tools, and especially to non-structured data mining / Text Mining tools.

The domain of generating insights based on social networks' content is referred to as "Sentiment Analysis": trying to understand what is the writer's attitude towards a particular object.
The purpose of these tools is to allow organizations to "listen" to the conversations taking place of social networks and analyzing these conversations in order to identify some emotion towards the company or product.
This listening is only the first part of the initiative, the second is to actually use this insight as an actionable one and respond in a certain way - act to protect the brand, try to correct, leverage positive blogger review etc.

A new breed of software tools have emerged that try to provide an answer to these needs. These tools provide capabilities that enable text analysis, creating clusters of content that contain positive versus negative sentiments, some of them provide an "overall sentiment score" based on a large group of various content sources about a particular product/campaign etc., and an important capability in these tools is the ability to define specific rules by the marketing department of the organization (for example, a specific word can significantly change the score and this word changed from one organization to the other).
An example of such tools: Umbria (focuses on the social websites - for example, blogs), Biz360, and an example of an Israeli company - Buzzilla.
In this link (Blog of 451 research group) there is a pretty long list of tools for sentiment analysis.

What are the problems currently associated with sentiment analysis of social networks?

Content is highly unstructured, there's no control over the way people express themselves, frequent use shortcuts and slang, language problems, and use of different media types - text, audio, video
Large number of sites to "listen to", the important sites change from industry to industry (On the other hand, this fact only stresses the need to do it in a computerized way rather than manual)
Privacy - currently this is not a problem but in the future it may not be possible to listen to conversations on the network so easily as it is today
Another potential problem that I'm assuming will arise at a certain point once companies start to use this tools will be the potential abuse of the media and tools. Imagine that every time you complain about a service you get a tweet from a service rep checking how they can help, or tweeting about a product you're looking for and getting a promotional message as a result… this has a potential of being over-used to the point of creating a negative association with the company.

There are several levels of tools usage, starting from only listening at a pretty basic level of sophistication (being able to identify content that directly mentions the product name); Through monitoring with a little more sophistication (eg, creating clustered content, while taking into consideration other content that might be of interest – for example, content about competitors etc.); Another level would be listening to content and acting as a response (creating an automatic response sent people complaining about the service, or distribution of a link of a positive review to other relevant sites etc.); Another level can be to connect these insights to other systems (for example, CRM packages are now starting to include, as part of their systems "sentiment score" that appears alongside the client's information. This topic is somewhat similar to sentiment analysis on other channels - for example, "emotion detection" in the call center by use of tools from the speech recognition space. Tools in this area recognize voice tone (and associates it with emotion), specific words ("word spotting") - for example, lawsuit/ name of competitor, and can lead to action such as escalation of the call.

But we should be careful when trying to analyze social websites content in the same way in which we analyze content other conventional content types that are far more organized. This is an entirely different media. Any attempt to try and compare the different media types with Twitter, for example, will be problematic. As of now, Twitter provides the quickest means information transfer "from the field" than any other media (A good example is the transfer of information now taking place regarding what is happening in the streets of Iran). And so, this media can be very useful in trying to get a quick picture of the impact of a particular campaign on the conversations "from the field" almost in real time.

In my opinion, organizations now starting to take advantage of the powerful content hidden in social networks will not only get a better "feel" their market in order to protect their brand images, but if applied with correct use, these tools can also help organizations take advantage of these conversations for the purpose of promoting customer centric innovation.

הדבר הבא במדיה החברתית: Sentiment Analysis

2009-07-04T10:41:00.000-07:00

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

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

מחלקות שיווק ו PR מנסות לפענח מה "נאמר על החברה/המוצרים" ברחבי הרשת באתרים בעלי תוכן הנבנה ע"י אנשים, ובאופן ספציפי – באתרי הרשתות החברתיות. באתרים אלה גלום מידע בעל ערך רב: ניתן להבין הרבה על האופן בו החברה/המוצרים/שירותיה נתפסים, העדפות, מגמות, ועוד מאפיינים של תרבות הצריכה הרלוונטית לחברה.
בדיוק כדי לספק את הרצון הזה צמחו כלי כריית נתוני רשתות חברתיות, הדומים במאפייניהם לכלי כריית מידע קלאסיים ובמיוחד לכלי כריית מידע בלתי מובנה / טקסטואלי (Text Mining). לתחום זה של הפקת תובנות מניתוח מידע באתרי רשתות חברתיות קוראים כיום "Sentiment Analysis": הניסיון להבין מהי הגישה של כותב תוכן כלפי אובייקט מסוים. מטרת כלים אלה לאפשר לארגונים "להאזין" לתוכן של רשתות חברתיות, לנתח את השיחה כדי לזהות איזשהו רגש המתקשר עם החברה. זהו חלק ראשון של היוזמה, החלק השני הוא להשתמש בתובנה הזו כדי להגיב בצורה כלשהיא - לפעול להגן על המותג, לנסות לתקן, למנף ביקורת חיובית של בלוגר וכד'. כיום מתחילים לצוץ כמה ספקים של כלי תוכנה שאמורים לספק מענה לצרכים אלה. כלים אלה מספקים יכולות ניתוח טקסט המאפשרות לדוגמה יצירת clusters של תוכן חיובי לעומת שלילי, חלקם מספקים "ציון כולל" לקבוצה של תכנים לגבי מוצר מסוים, ורכיב חשוב – היכולת להגדיר על ידי מחלקת השיווק של הארגון חוקים ספציפיים עבורו (מילות חיפוש חשובות שמשנות את הציון וכד').

דוגמה של כלים כאלה: Umbria (מתמקדת באתרים חברתיית – לדוגמה, בלוגים), Biz360, ודוגמה לחברה ישראלית בתחום – באזילה.

בלינק הבא (בלוג של חברת המחקר 451 Group) יש רשימה די ארוכה של כלי sentiment analysis.

מהן הבעיות כרגע בניתוח Sentiment של רשתות חברתיות?

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

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

נושא זה מזכיר כלים לניתוח סנטימנטלי בערוצים אחרים – לדוגמה, ניתוח רגשות ("emotion detection") במוקד השירות באמצעות כלים המגיעים מתחום ה-speech recognition. כלים בתחום זה מזהים טונציה, מילים ספציפיות – word spotting (תביעה משפטית/שם המתחרה) ויכולים להוביל לפעולה על סמך התובנות המתגלות.
אך צריך להיזהר לנסות לנתח תוכן באותה הצורה בה אנו מנתחים תכנים אחרים, יותר מסודרים וקונבנציונאליים, המדיה שונה לחלוטין. לראיה, כל ניסיון לנסות ולהשוות את Twitter עם מדיה אחרת יהיה מוטעה. טוויטר מספק כיום אמצעי העברת מידע מהיר מכל מדיה אחרת (דוגמה טובה לכך היא העברת המידע בצורה כל כך חיה על המתחרש ברחובות איראן). כך, לדוגמה, ניתן לנתח בצורה מהירה השפעה של קמפיין מסוים על ה"שיחה" שבשטח כמעט בזמן אמיתי.

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

תובנות משולחן עגול בנושא CRM שיווקי - נושא הערוצים

2009-06-29T08:17:00.000-07:00

במפגש שקיימנו בנושא CRM באוריינטציה שיווקית, בהשתתפות מנהלי מחלקות ב-IT ומנהלים מתחום מחלקת השיווק, עסקנו בסוגיות הקשורות ל-CRM בדגש על פתרונות למחלקת השיווק. בין שאר הסוגיות, משתתפי הדיון דיברו גם על נושא ערוצי ההתקשרות מול הלקוחות. ברוב הארגונים הגדולים העובדים במודל B2C קיימים כיום מספר ערוצים שונים לעבודה מול הלקוחות, והתפלגות האינטראקציות בתהליכים השונים משתנה כל הזמן. עלותו הגבוהה של ערוץ ה Call Center מניעה ארגונים לדחוף את לקוחותיהם לאמץ יותר ערוצי Self Service שונים.

להלן כמה דגשים לגבי ערוצים שניתנו על ידי המשתתפים בדיון:

הערוצים הרלוונטיים העיקריים: מיילים, SMSים, שיחות טלפון יזומות ומגיבות, אינטרנט, עמדת קהל/קיוסק, newsletters (מעבר למוקדים היותר "מאויישים" – CC, נקודת שירות/מכירה)

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

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

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

נושא שצויין כבעייתי על ידי רוב המשתתפים הוא שקיים כיום Abuse של ערוצים ולקוחות מבקשים להתנתק מהם. כמו כן, חוק ה-SPAM מאוד מקשה, ומחייב לבדוק כל הזמן את ה'גבול' הדק שבין שירות רצוי ויעיל לבין 'הצקה'. איך להימנע מ overdoing עם הלקוח? ברגע ש"עוברים את הגבול" עם הלקוח, ובזכות חוק הספאם, הוא יכול מאוד בקלות לבקש להתנתק מערוץ מסוים ואז הסיכוי להחזירו כמעט ולא קיים. צריך להיזהר שלא להציק ללקוח, זהו איזון עדין שכל הזמן צריך לבדוק אותו, והוא שונה מלקוח ללקוח. תחום זה הנו מאוד בעייתי.

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

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

על מה שואלים אותנו לקוחותינו כיום?

2009-06-28T10:09:00.000-07:00

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

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

בתחום חבילות האפליקציות אותו אני מכסה התחומים הבולטים בשאלות שקיבלתי מלקוחות היו בתחומי BI (לא מפתיע), ניהול ידע (מעט יותר מפתיע, בהתחשב בתקופה) ונושאים שונים הקשורים ל-ERP:

בתחום חבילות האפליקציות ראינו עלייה בולטת החודש לעומת חודש שעבר בכמות השאלות על תחום כלי ניהול ידע, ובתוך כך מנועי חיפוש ארגוניים ונושא web 2.0 פנים ארגוני. תחום ה-BI עליו לקוחות שואלים הרבה באופן כללי לאחרונה ממשיך לעניין גם החודש, ארגונים שואלים על כלי BI שונים, דשבורדים, וארכיטקטורת DW. החודש הייתה עליה קלה בשאלות הקשורות ל-ERP כאשר ברובן לא מדובר על בחינת חבילות ERP כוללות אלא על תחומים משיקים – בחינת מודולים מסוימים, כלי צד שלישי הקשורים למערכות ומשפרים תהליכים מסוימים בהן וכד'.

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

תשתיות חומרה ותוכנה: נושא שממשיך להיות דומיננטי בחודשים האחרונים הוא נושאי הרכש. לקוחות מבקשים לקבל מידע על מחירים של פתרונות שונים כמו על מידע עזר למשא ומתן כגון מוצרים תחליפים וכד'. כל זאת עקב המשבר הכלכלי שאותו כולנו מרגישים. עם זאת, ישנם סימנים ראשונים להתאוששות כאשר נושא שעליו שאלו לקוחות בצורה רבה יותר מחודש שעבר הוא נושא האחסון. לקוחות התעניינו במידע של פתרונות אחסון, עלויות וטכנולוגיות מתקדמות כל זאת במקרים רבים בתור הכנה לפרויקטים בתחום. היו גם שאלות שאינן קשורות לפרויקטים כמו שאלות של יחסי כ"א בתחום האחסון.
שאלות רבות התקבלו בנושאי תשתיות כלליים - שימוש בוירטואליזציה, בשלות VDI, העברת וידיאו בפרויקטי VDI או Terminal Services ועוד. בתחום הפיתוח ממשיכה התעניינות בהתייעלות הפיתוח באופן כללי וב-Agile Software Development באופן ספציפי.

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

התפלגות השאלות בתחום ניהול IT: נושא שממשיך להיות דומיננטי בחודש האחרון הנו תחום Office of the CIO, כולל שאלות בנושאי הקמת הגופים לניהול ובקרה תקציבים ומדדים של פרויקטי IT, בניית מערך מדדים ל-IT, dashboard למנמ"ר, וכלים לניהול משרדו של מנמ"ר. לקוחות מבקשים לקבל best practices לכתיבת מפות אסטרטגיות ל-IT, ומתודולוגיות מקובלות להכנת מערך בקרה ל- IT (דוגמת ITIL), ומכן הצורך במדדים ו-dashboards ל-IT על מנת להבין היכן הארגון נמצא היום ולאן הוא שואף להגיע בשנה הקרובה. תחום נוסף, אשר ממשיך לבלוט בהתעניינות הנו תחום הניהול מרכזי השירות בארגוני IT, ארגונים מחפשים לייעל תהליכים הפנימיים ומחפשים להחליף כלים מישונים בתחום זה. שאלות בנושא מיקור החוץ פחתו במידת מה בחודש האחרון, כמו כן בנושא Web 2.0. שני תחומים שממשיכים להיות יציבים ולעניין את לקוחותינו הנם תחום המובייל ותחום של ניהול הסיכונים, במיוחד עבור הארגונים המחויבים בבקרות רגולטוריות שונות.

מצגת בנושא אסטרטגית CRM חוצת ערוצים

2009-06-24T23:29:00.000-07:00

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

מגמות CRM - מטרנזאקציות לאינטראקציות
מיקוד על חווית הלקוח
מהו Multi channel CRM?
מהי תמונת המצב הקיימת בנושא ריבוי ערוצים בארגונים?
מהן הבעיות הקיימות בצורה בה ערוצים אלה מנוהלים?
התמקדות בערוץ הWEB כערוץ עיקרי וחשוב, השפעות web 2.0 על ערוץ ה WEB כערוץ אינטראקטיבי דו-כיווני

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

מצגת בנושא MDM

2009-06-20T13:47:00.000-07:00

הנה לינק למצגת שהעברתי בשבוע שעבר בנושא MDM. נושאי המצגת:

הגדרת המונח MDM - מהן המטרות העסקיות והטכנולוגיות?

תועלות

תצורות היישום השונות של MDM HUB

מודל 5 רמות בשלות של MDM

מציאות הMDM בישראל

המלצות

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

2009-06-15T07:46:00.000-07:00

לאחרונה שוחחתי עם כמה ארגוני enterprise ישראליים שחוזרים לבדוק את נושא החיפוש הארגוני. מי שחיפש לפני כ4-5 שנים פלטפורמה לחיפוש כלל ארגוני קיבל מהוונדורים הצעות מחיר בסדרי גודל של מאות אלפי $, מי שבדק לפני כשנה קיבל הצעות של כ100-200K$ על הרישוי, ולאחרונה ארגונים מתחילים לקבל הצעות בסדר גודל של עשרות אלפי דולרים לרישוי בלבד.

הקונסולידציה בשוק מנועי החיפוש (מיקרוסופט-FAST, אוטונומי-קונברה) וכן כניסת שחקנים יחסית חדשים לשוק הארגוני (מיקרוסופט, גוגל) יצרה שוק הרבה יותר תחרותי, עם רמות התמחות שונות (high end, mid market ורמה בסיסית ביותר – לרוב בחינם), וגם ירידת מחירים בולטת בתחום ה mid market – כלומר חיפוש כלל ארגוני לארגון הממוצע.

שוק החיפוש הפנים ארגוני מושפע, כתמיד, משמעותית משוק החיפוש החיצוני אינטרנטי. ושם מתרחש כיום קרב בין השולטת העיקרית כיום – גוגל, למיקרוסופט שקראה עליה תיגר עם יוזמת BING, שעם השקתה סקרנה כמות יפה של מבקרים, וכן יוזמה נוספת שקיבלה הרבה תשומת לב בשם Wolfram Alpha שלא שואפת (לפחות בגלוי) להחליף את גוגל אלא להכניס מודל חדש לאיתור מידע וקבלת תשובות. גוגל, מצידה, מחזירה מאבק למיקרוסופט, מפתחת יכולות חדשות ונשארת "עירנית".
המאבק הזה שמתחולל בחודשים האחרונים וימשיך גם בחודשים הבאים הוא על ה"עידן הבא של החיפוש". השיטה בה אנחנו מחפשים ומאתרים מידע הולכת להשתנות, בכל מקרה, לא משנה מי יוכתר כמנצח בקרב. לדעתי, אלה חדשות מצוינות, היכולת שלנו לאתר את המידע שאנחנו צריכים הולכת כנראה להשתפר, ובעידן שפע המידע בו אנו חיים כיום דרך איתור המידע חייבת להשתפר. החיפושים יתחילו להיות "יותר חכמים", כבר לא נסתפק רק בחיפוש טקסטואלי בסיסי (ולכן אנחנו מקבלים זאת כיום מהספקים כמעט בחינם) אלא נבקש דרכים לאתר יותר בקלות תשובות לשאלות שלנו. לא רשימת לינקים למקומות שאולי מכילים אותן, אלא משהו יותר ממוקד לשאלה שלנו, להקשר שלה, לזהות שלנו בארגון, לתפקיד, חיפושים קודמים, חיפושי הצוות שלנו וכד'.
הפיתוחים המעניינים בחיפוש האינטרנטי צפויים להשפיע גם על הדרך בה נחפש מידע בתוך הארגון. חיפושי מידע בארגון גוזלים כיום זמן רב (על פי סטטיסטיקות שונות כ-8 שעות בשבוע!) וחציים אינם מסתיימים במציאת המידע הדרוש, כך שכל שיפור ביכולת איתור המידע חשוב לשיפור פרודוקטיביות העובדים.

כלי מעקב אחר משימות - רשמים משולחן עגול

2009-06-09T01:14:00.000-07:00

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

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

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

למה כל כך קשה להטמיע כלי מעקב אחר משימות בארגון?!

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

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

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

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

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

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

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

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

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

רשמים משולחן עגול בנושא Web 2.0 לצורך ניהול ידע ארגוני

2009-05-31T08:44:00.000-07:00

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

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

WIKI הוזכר פעמים רבות במפגש, ככלי יעיל לשיתופיות מצד אחד, אך גם כלי יעיל להבניה של מידע בצורה מאורגנת מצד שני. בלוג הוזכר ככלי יעיל לתקשורת ארגונית, ששימושו הנו Broadcasting (העברת מסר לארגון בעיקר על ידי הנהלה). אולם בהקשר של ניהול ידע נחשב פחות אפקטיבי בגלל חוסר הניהול של מידע. היתרון שבו הנו שהוא "מכניס את העובד לראש של תרבות שיתופית", אפילו אם מדובר טיפים על תאילנד. בעיה נוספת שצוינה בבלוגים, מעבר לחוסר המובנות של המידע, היא שייצור פוסט איכותי יכול לקחת עד כ5 שעות, ומצד שני, יכול לחסוך 500 שעות עבודה עבור עובדים אחרים. במפגש הוזכרו גם כלים נוספים כבעלי פוטנציאל מעניין להגברת שיתוף הידע בתוך הארגון: TWITTER, Podcasting.

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

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

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

לינק למאמר שפורסם בDailyMaily בנושא זה.

הפרדוקס בתחום ה-BI

2009-05-26T04:52:00.005-07:00

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

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

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

עריכת Audits של המשתמשים – בדיקה מי משתמש במה, ובאיזו תכיפות. מנהל שניגש לדוח פעם בכמה חודשים אולי אינו מצדיק רישוי מלא
התחשבנות עם גופים בארגון לצורך מימון הרישוי בעצמם / חלק ממנו
בחינה של כלי BI מבוססי קוד פתוח (דוגמת Pentaho) – שמענו זאת רק אצל מעט ארגונים בינתיים
כמה ארגונים שקלו מחדש האם להישאר בחוזה תחזוקה או לא (בתחום זה לא שמענו על צעד ממשי בנושא, לעומת תחומים אחרים בהם כן שמענו), מתוך מחשבה שאם יצטרכו תמיכה אולי שווה יהיה לשלם תעריף שעה גבוה שעדיין יהיה יותר זול מעלות התחזוקה השנתית
ניסיון לצמצם במספר כלי ה-BI בארגונים בהם נוצרו "איי BI" שונים עם כלים שונים. קונסולידציה בכלי ה-BI הנה מגמה בינלאומית (בשל גודל הארגונים שם והאופי היותר מבוזר של יוזמות BI). ראינו זאת בארגונים היותר גדולים, משום שבתחום זה בישראל מצבנו הרבה יותר טוב מזה של ארגוני ענק בחו"ל שכל רכישת חברה מוסיפה להם עוד אוסף של כלי BI לפורטפוליו. מחלקות הBI בישראל, וכל ארכיטקטורת ה-DW בכלל, הרבה יותר ריכוזית בישראל מאשר ארגונים בינלאומיים, כך שנושא הקונסולידציה של כלים קצת פחות אקוטי.
בחינת הפורטל כאמצעי פוטנציאלי לחסוך בעלות רישוי (לא רק בתחום ה-BI אלא גם בתחום ה-ERP)

היוזמות שמתקיימות כעת אצל ארגונים במטרה להרחיב את שירותי ה-BI:

פרויקטים קטנים שמביאים לתוצאות מהירות – זהו איפיון הפרויקטים בBI וברוב התחומים האפליקטיביים האחרים. אם לפרויקט יש רמת סיכון גבוהה/אין ידע בישראל/הטכנולוגיה אינה בשלה ארגונים נרתעים מהתחום בימים אלה הרבה יותר מאשר בזמנים אחרים, טובים יותר.
פרויקטי BI להנהלה (בעיקר דשבורדים, ופרויקטי מדדים). תחום זה שוב עולם לכותרות, החדשות הטובות הן שכיום הדוחפים הם יותר ההנהלות (ופחות מחלקת ה-IT). יש לציין כי בפרויקטים אלה ארגונים אינם פוסלים שימוש בכלים אחרים (שונים מכלי ה-BI בהם הם משתמשים כיום)
פרויקטי BI פיננסי – כלי BI המיועדים למחלקה הפיננסית, ובראשם – כלי תכנון פיננסי ותכנון תקציב. גם כאן מדובר בכלי Best of breed ייעודיים, ולא דווקא של ספק ה-BI המרכזי של הארגון.
התחום הרגולטיבי (באזל II לבנקים, ובהמשך גם Solvency לביטוח) מייצרים תקציב נוסף, ייעודי, שמתרכז בתחום ה-DW על מנת לייצר פתרונות בתחום זה.

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

BI מבוסס קוד פתוח: העניין גובר אך השימוש עדיין מוגבל

2009-05-18T08:58:00.000-07:00

העניין בכלי BI מבוססי קוד פתוח בעולם גובר בהתמדה, ונוצר דיון סביב המידה בה Open Source BI מהווה או לא מהווה Disruptive Technology לאפליקציות ה-BI הקלאסיות.

למרות שעד כה ארגונים ישראליים נרתעו מאימוץ אפליקציות מבוססות קוד פתוח, אנו רואים שכיום ארגונים בישראל גם הם מביעים התעניינות זהירה בקוד פתוח במספר תחומים, כאשר אחד מהם הנו תחום ה-Business Intelligence, ובאופן יותר ספציפי בכלי Reporting, Dashboarding ו – OLAP Viewers.

באופן כללי, בשוק הבינלאומי רמת השימוש באפליקציות מבוססות קוד פתוח (OSS) גבוהה יותר ועומדת על עשרות אחוזים (מעל 50% מארגונים הנשאלים בסקרים אומרים כי הם משתמשים באפליקצית OS כלשהיא), אך, כשמדובר בתחום ה-BI, גם בחו"ל אחוזי השימוש אינם מאוד גבוהים, רמת השימוש עדיין מאוד מוגבלת אך על פי מחקרים - עולה בהתמדה. לדוגמה, על פי סקר של חברת Cutter שנערך ב2008, רק כ-18% מארגונים בינלאומיים עושים שימוש כלשהוא במוצרי BI מבוססי קוד פתוח (לעומת 11% בלבד ב-2006). 35% מהארגונים הנשאלים מתעניינים ביישום כלים אלה. מחקר זה מראה מגמה יציבה של התעניינות גוברת בקוד פתוח על פני 3 השנים האחרונות.

מאפייני ההתעניינות הזהירה בכלי Open Source BI:

הקטגוריות הפופולאריות ביותר לכלי BI מבוססי קוד פתוח הנם כלי דוחות ודשבורדים. בחו"ל יש גם עניין בולט בכלי ETL מבוססי קוד פתוח.
ברוב הכולל של ארגונים מתעניינים לא מדובר ביישום BI סטנדרטי לכלל הארגון אלא לשימוש נקודתי – לפרויקט ספציפי או למחלקה מסוימת.
רוב הארגונים המיישמים כלי BI בקוד פתוח בחו"ל יישמו זאת בעצמם, ולא באמצעות כ"א חיצוני. זאת משום שרבים מהמאמצים הנם ארגונים טכנולוגיים ובתי תוכנה שמאמצים את הכלים לשילוב במוצרים המסחריים שלהם.
ספקי Open Source BI בולטים שמופיעים על ה"רדאר": Pentaho, Jaspersoft, מיזם BIRT - Eclipse.

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

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

2009-05-09T13:05:00.000-07:00

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

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

מס' החברות הטוענות לכתר האינטליגנציה המלאכותית שתאפשר לנו לאתר את המידע הדרוש תוך שימוש בשפה חופשית גדול, וההצלחות הן מינוריות / נישתיות. למה שהפעם זה יהיה שונה? אולי משום שמדובר בפרסונה מוכרת ומוערכת. הפיסיקאי Dr Stephen Wolfram, גאון שסיים לימודי PhD בגיל 20 הוא גם זה שעומד מאחורי המצאה חשובה ביותר בעולם האקדמיה והמחקר, שכבר הוכיחה עצמה – תוכנת Mathematica הידועה, המשמשת לפתרון בעיות מתמטיות מורכבות (עליה מיזם החיפוש גם מתבסס).

אז מה הגליק הגדול? 3 דברים מעניינים במיוחד:

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

ישנם מיזמים (דוגמת Ask Jeeves) המאפשרים לשאול שאלה בטקסט חופשי, לאחר מכן מבצעות הבניה של ה"שאילתה", מיתרגמות ל String חיפוש, ומחזירות תוצאות חיפוש רלוונטיות. Wolfram Alpha לוקח את זה צעד אחד קדימה – השואל מקבל תשובה ישירה לשאלה (ולא תוצאות חיפוש בהן יצטרך להמשיך ולחפש), וכן מידע רלוונטי נוסף שמתקבל על ידי ביצוע ניתוחים וחיתוכים חדשים (שלא היו קיימים לפני כן). לדוגמה, תארו לעצמכם שהקלדה שלהצירוף "מספר החברות בישראל" יחזיר טבלה עם מספר הארגונים על פי גודל, עם סטטיסטיקות רלוונטיות, חלוקה למגזרים ועוד נתונים שנאספים במיוחד עבור צורך זה, (לא יישאבו ממקור קיים/שאילתה קודמת).

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

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

מקורות נוספים לקריאה על נושא זה:

מאמר בנושא שפורסם בדמרקר

פרסומים בבלוג של ג'ימי (1, 2, 3)

הבלוג של Wolfram Alpha

צו האופנה: פרויקטים המביאים לחיסכון בהוצאות

2009-05-06T00:31:00.000-07:00

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

שירות עצמי – מאוד מאוד חם כרגע, ולא רק בסקטורים ה"ברורים מאליהם" (כדוגמת SELF SERVICE. בבנקאות – העברת פעילויות לכספומטים ו back office בכדי לקיים סניף רזה). גם ארגונים תעשייתיים, הייטקיים, ארגוני שירות וממשלתיים, מחפשים דרכים להוריד עלויות מוקד השירות, ועל הדרך - גם לשפר את רמת השירות הניתנת ללקוח (רוב הלקוחות מעדיפים שתהיה להם האופציה לבצע חלק מהפעולות בשירות עצמי). סוגים שונים של שירות עצמי בחלק מהסקטורים כבר הופכים להיות מרכיב בלתי נפרד במוצר (כמו לדוגמה בתחום הבנקאות, הבנקים כל הזמן מחפשים דרכים חדשות לספק יותר ויותר פעילויות בשירות עצמי באתר האינטרנט/בעמדות השירות ובטלפונים הניידים בצורה שגם תספק להם איזשהוא יתרון תחרותי). מגמת השירות העצמי תימשך, אתר האינטרנט ימשיך להיות הערוץ העיקרי המעניין, אך גם ערוץ המובייל יתחיל לתפוס תאוצה (תחת מגבלה של חוסר בסטנדרטיזציה מבחינת מכשירים/מערכות הפעלה שמאוד מגבילה כעת את השוק), וגם הקיוסקים ועמדות שירות עצמי.
IT ירוק - איך שלא נסובב את זה, כרגע המניע הוא חיסכון בהוצאות. תחום מאוד פופולרי לאחרונה הוא הניסיון להפחית משמעותית את כמות דואר הנייר הפיזי שחברות שולחות ללקוחותיהם ולהעבירם למדיה דיגיטלית שלא רק חוסכת בכמות הנייר אלא מאפשרת מתן שירותי ערך מוסף (על כך תוכלו לקרוא בהרחבה בפוסט מעניין בבלוג של שחר על שימוש בטפסים אינטראקטיביים).
פעילויות במחלקת ה-IT לצמצום ההוצאות השוטפות, לדוגמה: עריכת AUDIT לרשיונות (בתחומי ERP, BI ועוד) וניסיון למצמם מספר רשיונות של משתמשים שאינם עושים שימוש או עושים שימוש מאוד נמוך בכלים. לדוגמה, אחד הארגונים סיפר על בדיקה של מספר הכניסות למערכת BI וביטול הרישיון למשתמשים שאינם עושים שימוש גבוה בכלים אלה. משתמש שיבקש בכל זאת להשתמש יצטרך לממן את רכישת הרישיון מכיסה של המחלקה העסקית אליה הוא משתייך, העברת מידע לפורטל (שוב – כדי להפחית בעלויות רישוי יקר למשתמש "כבד"), פתיחה של חוזים קיימים, מו"מ על תנאי תחזוקה, שקילה מחדש האם כדאי להישאר בחוזה תחזוקה עם ספק מסוים (לעומת העלות המשוערת של פתיחת תקלות מולו), ומשחקי פחת (מה עוד ניתן להגדיר כהשקעה?!)
פרויקטים נוספים הם כאלה שלא מביאים ישירות לחיסכון בעלויות אלא מגדילים פרודוקטיביות ועקב כך עשוים להביא לחיסכון בעלויות בצורה עקיפה. לדוגמה, כלי EPSS אשר מתלבשים על מסך העבודה של העובד/נציג השירות ומנחים אותו לגבי התהליכים אותם הוא מבצע. פרויקט כזה יכול לקצר זמן שיחה (=חיסכון בעלויות), לשפר את ההטמעה של הכלי (=פחות פניות לHD = חיסכון בעלויות, קיצור זמן ההדרכה של נציג שירות חדש = חיסכון בעלויות)

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

הפרויקט: ניהול ידע. הלקוח: מחלקת ה-IT

2009-04-30T09:38:00.000-07:00

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

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

בקרוב אקיים מפגש שולחן עגול ללקוחותינו בנושא שימוש בכלי Web 2.0 לצרכי ניהול ידע. במפגש זה נדבר, בין שאר הנושאים, גם על שימוש בכלי כדוגמת ה Wiki לניהול ידע למחלקת IT (על פי התכנון אמורים להגיע ארגונים שידברו על יישום כזה בארגונם).

אעדכן בהמשך לגבי תובנות ויישומים מעניינים בנושא זה.

רכישת SUN על ידי אורקל - משמעות נוספת

2009-04-20T07:47:00.000-07:00

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

כבר כיום לאורקל יש אוסף גדול של מוצרי BPM בעלי יכולות חופפות, מה שיוצר מעט בלבול של הארגונים בהקשר למפת הדרכים שלה בתחום זה: מוצר הBPM של אורקל - BPEL, מוצרי BEA שנרכשה - WLI, כעת "BPM", וכעת עקב רכישת SUN - גם JCAPS - Java Composite Applications Platform Suite (מוצר BPM-SOA של SUN).
מכיוון שזהו חלק די "קטן" בתמהיל מוצריה של חברת SUN ובוודאי לא המרכיב העיקרי בהחלטה לרכישת SUN על ידי אורקל, יש להניח שגם ייקח זמן לא מבוטל עד אשר נדע מהו מיקומו של מוצר BPM נוסף זה באוסף כלי ה-BPM של אורקל. יש להניח שאורקל תפעל בתחום זה באופן דומה לפעילותה בסדרת רכישות האחרונות שביצעה בהן הבטיחה ללקוחותיה תמיכה "לכל החיים" במערכות שנרכשו. עדיין, ארגונים ירצו לדעת איזה מוצר מבין 3-4 המוצרים שכעת החברה מציעה בנישת הBPM יהיה המוצר היותר "אסטרטגי" ונדחף לאורך זמן, מתוך רצון להפחית סיכון והנחה שלא ניתן להשקיע באותה המידה בכל המוצרים וכי חלקם יזכו ליותר תשומת לב.
זהו חלק נוסף, קטן מאוד יחסית, ברכישה הגדולה והמשמעותית הזאת.

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

נפתחה עונת השולחנות העגולים!

2009-04-18T13:36:00.001-07:00

"גל" חדש של שולחנות עגולים מתוכננים ב STKI (רשימה מלאה של כל המפגשים - תוכלו לראות באתר שלנו כאן). המפגשים שאני מתכננת לזמן הקרוב יהיו בנושא CRM, ניהול ידע בגישת Web 2.0, ומעקב אחר משימות.

מפגשי שולחן עגול מיועדים רק לארגוני משתמשים, ורק ללקוחות STKI. הנה קצת מידע על המפגשים שאערוך:

שימוש ב Web 2.0 לניהול ידע ארגוני:
יום רביעי, 13.5.09
ארגונים שונים בישראל כבר החלו להכניס תפיסות וטכנולוגיות Web 2.0 לתוך הארגון, על מנת לעודד שיתוף מידע וליצור מאגרי ידע אפקטיביים לעובדים. אולם ארגונים רבים גילו כי השימוש ב Web 2.0 בתוך הארגון מצריך היערכות מיוחדת עמה לא התנסו עד כה. בנוסף, מנהלי ידע גילו עד כמה רעיונות Web 2.0 שונים, ולעתים אף סותרים, את הגישות הקלאסיות של ניהול ידע: התכנים נבנים על ידי העובדים ולא "נשלטים" על ידי הארגון; גישת ה"תגיות" אל מול עץ המידע הארגוני; רמת שליטה יותר נמוכה על המידע וכד'. מטרת שולחן עגול זה היא לחשוף best practices של פרויקטי שימוש בויקים/בלוגים/RSS/רשתות חברתיות פנים ארגוניות, להציף את הבעיות והמכשולים הצפויים בפרויקטים אלה, ולגבש טיפים להמשך הדרך.
להלן חלק מהשאלות אותן נעלה בדיון (ייתכן כי לא נגיע לכולן במפגש זה):
· האם ישנם ניסיונות מוצלחים להטמעת Wikis בתוך הארגון? לאיזה צורך?
· האם יש מקום ליישום בלוגים ארגוניים? לאיזה צורך?
· האם ישנם טיפים והמלצות לארגונים שרוצים ליישם בלוגים או ויקים פנים ארגוניים?
· אילו תחומים מועמדים להיות פרויקטים יותר מוצלחים ליישומי Web 2.0 פנים ארגוניים? (לדוגמה, האם בתוך ניהול פרויקטי IT? פרויקטי חדשנות/סיעור מוחות?)
· רעיונות ליישומים (לדוגמה, שימוש בWiki כמילון מונחים, שימוש בבלוג כפלטפורמה להעלאת רעיונות לשיפור תהליכים על ידי העובדים)
· איך ניתן לווסת את רמת השליטה ביוזמות אלה?
· איזה כלי לבחור? האם כלי open source? או כלים המגיעים כחלק מהפורטל הארגוני? או כלים במודל on demand?

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

CRM:
יום רביעי, 17/06/09
תחום ה-CRM אמנם יסבול מהמצב התקציבי הקשה, אך לעומת תחומים אפליקטיביים אחרים (ERP, לדוגמה) הוא דווקא צפוי להיות במצב יותר טוב. פשוט אין ברירה, ארגונים נאלצים להמשיך ולהשקיע בתחום הזה, ולחזק את הקשר מול לקוחותיהם. עיקר הפוקוס בפרויקטי CRM עובר לטרנזאקציות מול הלקוחות בערוצים השונים - חיזוק ערוץ המוקד הטלפוני (ובעיקר ניסיון לחיסכון בעלויות), חיזוק ערוצים המאפשרים שירות עצמי כגון אתר האינטרנט ושירות באמצעות Mobile. מסקר שערכנו עלה כי ארגונים מתכוונים להשקיע יותר מאמצים בתחום ה CRM האנליטי (לעומת הCRM התפעולי).
במפגש זה ננסה לראות מהם התחומים היותר חשובים לארגונים כיום, כיצד מבצעים פרויקטי CRM (קטנים ככל שיהיו) תחת לחצים תקציביים גדולים, ולגבש המלצות וטיפים.

השתתפות במפגשים מותנית בהרשמה מראש ומיועדת ללקוחות STKI בלבד, על מנת להירשם שלחו מייל לאתי ולשמרית או צרו קשר 09-7907000 (אתי או שמרית).
להתראות במפגשים אצלנו במושב!

הפרויקט המושלם ל-2009

2009-04-07T06:24:00.000-07:00

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

כיצד נראה הפרויקט המושלם לשנה תקציבית קשה?
- קצר! (מס' חודשים עד שנה)
- ממשק ידידותי למשתמש (=הפחתת עלויות ההדרכה)
- מוצר גמיש/קל לפיתוח (=הורדת עלויות אנשי תחזוקה חיצוניים)
- ROI מאוד מהיר (מס' חודשים)
- עדיפות לפרויקטים שמסייעים בקיצוץ עלויות (לדוגמה - self service וחיזוק אתר האינטרנט כדרך להפחתת עלויות מוקד התמיכה הטלפוני; חשיפת נתונים בתוך האפליקציות כדרך לקצץ רשיונות תוכנה למשתמשים שרק זקוקים לצפות בנתונים בצורה מוגבלת; EPSS/ הנחיית נציגים במוקד השירות כדרך להפחתת עלות ההדרכה לנציגים)

מה זה אומר? שפרויקטים בתחומים פחות בשלים (לדוגמה, MDM/ Data Governance) יקבלו עדיפות נמוכה יותר. וזו בהחלט בעיה. הרבה מאותן טכנולוגיות בעלי בשלות יותר נמוכה (MDM, BPM...) הם אלה שיכולים לעשות שינוי של ממש כשהארגון יתחיל לדרוש ממחלקת הIT פתרונות ליום שלאחר המשבר.
המלצתי היא לנצל שנה זו על מנת להיערך ארגונית לתחום חדש (הכנה לפרויקט BPM עשויה לקחת כשנה - כולל היערכות תשתיתית וארגונית), ללמוד את הנושא, ואף להתנסות בו בצורה מצומצמת יותר אם הדבר אפשרי.

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

ובינתיים, שיהיה לכולם חג שמח!

ERP בשנת 2009

2009-03-31T05:43:00.000-07:00

ב"גרף הבשלות הטכנולוגית" שלנו ניתן לראות קטלוג רמת הבשלות של הכלים בישראל (ציר X), ומצד שני קטלוג התועלת בעיני המנהלים העסקיים של הארגון מאותם פרויקטים (ציר ה Y). ניתן לראות שבתחום ה-ERP, הפרויקט שאנו מגדירים אותו כERP1 נתפס בעיני מנהלים עסקיים כשירותי - commodity שעל הארגון לספק לו, סוג של תשתית שצריך שתהיה. הערך העסקי הישיר אינו ברור. להערכתנו, מעל 85% מארגוני enterprises בישראל כבר עושים שימוש בחבילות ERP לצרכים גנריים - הנהלת חשבונות, לוגיסטיקה, כוח אדם ("ERP 1"). אולם "פרויקט" ERP אף פעם למעשה לא מסתיים, ולאחר ייצוב המערכת ארגונים בדרך כלל נכנסים ל"שלב ב" (ERP 2). שלב זה של היישום כולל אחד או כמה מהמאמצים הבאים:

שימוש במודולים "מתמחים" / "מתקדמים" – בעוד שבעבר ניתן היה לתחום ביתר קלות את התחום בו מפסיק ה-ERP ומתחילות מערכות ליבה ומערכות אחרות, כיום חבילות ה-ERP כוללות (גם אם לא תמיד באופן המיטבי) יכולות שקשורות לעסק הליבה של הארגון, יכולות CRM, יכולות סביב ניהול שרשרת האספקה, וכן כל מיני מודולים "מיוחדים" שבעבר ארגונים לא שיערו שיוכלו לקבל ממערכות ה ERP, כגון: ניהול נכסים, ניהול פרויקטים וכד'. כאן אנו רואים כוונה של ארגונים להמשיך יישום של מודולים שתוכננו לשלב ב (כל אחד עם תוכנית משלו, לא ראינו מודול ספציפי עליו רוב הארגונים דיברו כשלב ב). תכניות להכנסת מודולים ורטיקלים המטפלים בליבה של הארגון יהיו הרבה פחות נפוצים בשנה בה ארגונים נמנעים מפרויקטים בעלי סיכון גבוה.
שילוב רכיבי תשתית בERP – השימוש ברכיבים אלה (DW משולב, פורטל, מנוע אינטגרציה משולב) הולך וגדל אולם מציב לא מעט שאלות ארכיטקטוריות, כגון: ה-DW הארגוני אל מול ה-DW של ה-ERP? הפורטל הארגוני אל מול פורטל ה-ERP? רוב הארגונים בוחנים (או כבר בחנו) שאלות ארכיטקטוריות אלה, ולרוב התשובה תהיה: גם וגם. ארגונים אלה מנסים לתכנן את הארכיטקטורה הארגונית בהתאם, ולקבוע את ה"גבולות" בין הרכיבים השונים.
ניסיון לייעל תהליכים האופרציית ה-ERP. מחלקות ה ERP הגדולות בקרב ארגונים המשתמשים בחבילות הגדולות (SAP / אורקל) מונות בממוצע 15-20 איש, וארגונים מספרים כי עם העלייה לאוויר וכניסה לשלבים המתקדמים מס' אנשי התמיכה לא יורד ולעתים להיפך. ארגונים כיום מנסים למצוא כל דרך לצמצם עלות התחזוקה, הדרכה, שינויים, להכניס יותר "סדר" בתהליכי הפיתוח, וגם בוחנים כלי צד ג' שיכולים לעזור לעשות כך. ארגונים ציינו כי ככל שהם נכנסים יותר ויותר לארכיטקטורת SOA ולרכיבים חדשים של מערכות ה-ERP (מודולים הכוללים רכיבים תשתיתיים מובנים כגון פורטל כשכבת התצוגה, מנוע BPM מובנים, שירותי BI משולבים) נדרשת עלייה בכוח האדם התומך ומתחזק את המוצר, וגם נדרש כוח אדם ספציפי המתמחה ברכיבים חדשים-יחסית אלה.
ארגונים מנסים לבחון כיום דרכים חדשות לצמצום כ"א הנדרש לתחזוקה השוטפת של ה-ERP, ושוקלים יותר בימים אלה שימוש בכ"א חיצוני מאשר בעבר. שימוש בכ"א חיצוני לתחזוקת ERP נשקל יותר על ידי ארגונים שצריכים "חלקי משרות" ולכן לא שווה להן להחזיק משרה מלאה בשביל כמה שעות בשבוע, וכן על ידי ארגונים בהם היישום די סטטי (לא משתנה בתדירות גבוהה מאוד ולכן גם היישום די סטנדרטי ולא דורש היכרות מוקדמת מעמיקה עם הארגון).

ב-2009 ארגונים ינסו לייעל את התמיכה ולמזער עלויות סביב ה-ERP הקיים, וכן להעמיק את יישום ה ERP לתחומים נוספים בארגון (שכן ברוב הארגונים "תשתית ה ERP" קיימת).

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

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

אתרים תפעוליים ו Self Service - נושא חשוב ל 2009

2009-03-31T04:56:00.000-07:00

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

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

אבל מסתבר שלא מדובר רק בנושא העלויות.

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

גם בתחום ה- CRM העוסקים בתחום מתחילים למקד הרבה מתשומת הלב לאתרי האינטרנט וערוצים נוספים מלבד ערוץ ה call center המסורתי (לדוגמה, תחום ה Mobile, וקיוסקי מידע).

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

תודה ל1200 האורחים שהגיעו לכנס STKI!

2009-03-25T02:18:00.000-07:00

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

לצפייה במצגת שהעברתי בכנס ישנן כמה אופציות:

לצפייה במצגת (ללא הורדה): 2 אפשרויות
1. באתר slideshare:
http://www.slideshare.net/Einats/2009-summit-presenation-on-enterprise-applications-analytics-and-km
2. באתר Scribd
http://www.scribd.com/doc/13580299/Einat2009-Summit-Applications-ion

לצפייה והורדת המצגת - ללקוחות STKI - הצטרפו לקבוצה שלנו באתר: http://www.docsntalks.com/
איך זה עובד? נכנסים, נרשמים, מקבלים במייל אישור עם ססמה, ואז ניתן לצפות ולהוריד מצגות, לשוחח בפורומים עם לקוחות אחרים, וגם לראות חומרים נוספים כמו מועדי שולחנות עגולים ואירועים נוספים.

ומי שמעוניין לראות קצת תמונות של האירוע:
http://picasaweb.google.com/jimmyschwarzkopf/STKISUMMIT2009#

מקווה שנהניתם מהאירוע (לפחות כמונו)
נתראה באירועים הבאים ובשולחנות העגולים
עינת

שוק התכנה בישראל -תוצאות מחקר שנתי 2009

2009-03-19T06:44:00.000-07:00

על פי תוצאות מחקרנו השנתי בקרב ארגוני IT מובילים בשוק הישראלי, שוק המחשוב צפוי להתכווץ משמעותית בשנת 2009 לעומת 2008 בסדר גודל של 13% ויעמוד על כ-4 מיליארד $ לעומת 4.7 מיליארד $ ב-2008.

שוק התוכנה צפוי לרדת ב12% ב 2009 לעומת 2008. אחת מהבעיות הגדולות בתחום זה הנה עודף רישיונות שקיים כיום בקרב ארגונים, עליהם ארגונים משלמים אחוזי תחזוקה גבוהים, ולעתים גם לתוכנות בהן אינם משתמשים / עושים שימוש מוגבל ביותר. מגמה נוספת מעניינת בתחום הנה הסתכלות גם על תוכנות קוד פתוח (דבר עדיין די נדיר בארגוני enterprises בישראל), אך בשוק הישראלי הסתכלות זו תהיה מוגבלת בתחילה לתחומים ספציפיים.
תחום התוכנות הארגוניות (הכולל ERP, CRM, ניהול ידע) צפוי לרדת בכ-20% ברמות שונות (לדוגמה, דווקא שוק ה-CRM צפוי לשמור על יציבות), הפרויקטים "המועדפים" אליהם ארגונים ייכנסו הנם קטנים, ממוקדים, קצרים (עד שנה) בעלי סיכון נמוך והחזר השקעה מהיר (כמה חודשים).
כמו כן, ארגונים מציינים כי חיזוק יכולות SELF SERVICE וריבוי ערוצים (WEB, MOBILE, קיוסקים וכד') הנם פרויקטים אסטרטגיים אשר מונעים הן מרצון לחיסכון עלויות במוקדי המכירה והשירות (עלות שיחה עם מוקדן: 5$ בממוצע, עלות אינטראקציה ב-IVR: 1$, ואילו עלות אינטראקציה בשירות עצמי באתר האינטרנט: כ-20 סנט), והן מרצון למקסם ערך השירות ללקוח (מחקרים בינלאומיים מוכיחים כי שילוב אפקטיבי של יכולת שירות עצמי מעלים את רמת שביעות הרצון של הלקוח).

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

לכתבה בנושא זה שהתפרסמה בדה-מרקר.

כתבה נוספת מורחבת יותר בדה-מרקר.

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

2009-03-10T11:37:00.000-07:00

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

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

תשכחו מ ROI ארוך טווח, תחשבו על PAYBACK מהיר. מנמ"רים רבים עמם שוחחנו כבר פועלים על פי הקו המנחה – נכנסים רק לפרויקטים בהם ניתן להראות החזר השקעה מהיר מאוד (בין חצי שנה לשנה). התוצאה היא – פרויקטים גדולים "מתפרקים" לפרויקטים קטנים (לדוגמה, כבר כמעט שאין יוזמות CRM גדולות, הפרויקטים מנוהלים בצורה של מספר פרויקטים קטנים וממוקדים, כאשר כל פרויקט אורך פחות משנה).
TCO – בתוך העלות הכוללת של הפיתרון ארגונים יבחנו הרבה יותר מאשר בעבר את מאמץ התחזוקה המתמשך שנדרש עבור אפליקציה מסוימת. מנמ"רים כיום מנסים לקצץ עלויות תחזוקה גבוהות ביותר של אפליקציות שרצות ועובדות בארגון, לגביהן אין שום ברירה אלא להמשיך ולתחזקן (אלה הוצאות Non-discretionary, שאינן נתונות לשיקול דעת). לכן, בבואם לבחור אפליקציות חדשות הם ישימו לב הרבה יותר למרכיב התחזוקה השוטפת – האם יש לנו "בבית" את היכולות הנדרשות כדי לתחזק את המערכת? באיזו מידע קיים לרשותנו כ"א חיצוני זמין לתחזוקת המערכת? האם סביבת הפיתוח של המערכת הנה קשיחה או גמישה?
קלות שימוש – מגמה זו החלה כבר לפני כשנה. קלות שימוש/ אינטואיטיביות / ידידותיות הן תכונות מבוקשות באפליקציות וגם לכך יש הצדקה כלכלית: הורדת עלויות ההדרכה. חלק ממגמה זו מיתרגמת לדרישות התחברות לאופיס וגם לאפליקציות אחרות שיהוו ממשק עבודה טבעי במקום ממשק קנייני של המערכת. לדוגמה, אחת מהדרישות החשובות ביותר עבור ארגונים כיום ממערכות מעקב אחר משימות היא ממשק חזק לאאוטלוק בצורה שתאפשר להתנהל מול המערכת ישירות מתוך האאוטלוק.
בחינה של מודל SaaS וקוד פתוח – בעוד שבעבר ארגונים הטילו וטו מוחלט, כיום ישנה סובלנות גבוהה הרבה יותר למודלים אלה בתוך בחינת פרויקטי אפליקציות. המודלים אינם חדשים לגמרי, אבל אם עד היום ארגונים ביטלו אותם ללא כל הסבר, הרי שכיום יש הרבה יותר סיבות להסתכל עליהם, בין השאר בגלל המודל הכלכלי, וצריך להתאמץ קצת יותר כדי לענות על השאלה "למה לא". המודל הכלכלי של SaaS בתקופת המשבר יכול לעשות לפעמים את ההבדל בין "לעשות" ל"לא לעשות". הדבר בולט במיוחד בארגונים קטנים בהם משאבי ה IT קטנים מאוד. אך גם בארגונים גדולים היתרון לגודל חשוב. מחלקת IT גדולה ככל שתהיה לא תוכל להגיע למחירי תוכנות/חומרה, וכן לעלויות שוליות של תחזוקה של חברות כמו אמאזון, גוגל, יבמ, מיקרוסופט, Salesforce.
יש גם שינוי בקטגוריות האפליקציות שיהיו יותר פופולאריות בתקופת המשבר. ארגונים מחפשים כיום כלים שמגדילים יעילות בתהליכי העבודה שלהם ועושים זאת בצורה מאוד ממוקדת.
o לדוגמה, ארגונים שמפעילים אופרציית ERP גדולה מחפשים אפליקציות שיעזרו בעבודה יותר קלה מול המערכת כדי להוריד עלויות תמיכה והדרכה שוטפת, וכן יש עניין רב בכלים שיכולים להוריד עלויות של ביצוע שינויים ושדרוג גרסאות בסביבת ה-ERP.
o דוגמה נוספת מעולם ה-CRM היא אפליקציות שמורידות את העומס ממוקד השירות (שנחשב למרכז עלות מאוד גבוהה עבור הארגון). אפליקציות שמאפשרות שירות עצמי דרך האתר/טל' סלולרי/קיוסקים וכד', ימשיכו להוות מוקד משיכה בשנים הקרובות.
נראה שהאפליקציות הפופולאריות יותר יהיו אלה המסייעות בהקטנת ההוצאות, ומה בקשר לאפליקציות המסייעות בהגדלת ההכנסות? נראה שארגונים ישקיעו פחות בכיוון זה בשל המורכבות הגבוהה יותר של הפרויקטים, חוסר הבשלות, וחוסר המשאבים הפנויים. אך חלק מהארגונים מתכוונים לנסות ולהכין את הקרקע לזמן בו יתאפשר להיכנס לפרויקטים אלה (לדוגמה, ארגון שמתעתד להיכנס לפרויקט BPM שאמור לעזור לארגון להגדיר בצורה מהירה יותר מוצרים אותו הוא מוכר ללקוחות מתכוון להיערך מבחינה תשתיתית למהלך כזה, להיערך מבחינה ארגונית בתוך מחלקת הIT ולהתחיל מהלך חשיבתי, כל זאת במהלך השנה הקרובה).

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

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

איך ייראו פרויקטי CRM ב- 2009?

2009-03-10T07:40:00.000-07:00

איך ייראו פרויקטי CRM במהלך שנה תקציבית כ"כ קשה? לאן הפוקוס יעבור? האם בשנת משבר ניתן להזניח את תחום הCRM שכ"כ חשוב מבחינה עסקית?

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

בתוך כך, כיצד ייראו פרויקטי CRM במהלך 2009?

מספיק התרכזנו בטרנזקציות, עכשיו עוברים לאינטראקציות
ארגונים מחפשים כיום דרכים "לדבר" עם הלקוחות. הערוצים מתרבים, הלקוחות הופכים להיות יותר "דיגיטליים" ומצפים מחברות לספק להם מגוון דרכי התקשרות, בהתאם להעדפות שלהם.
סקטור הבנקאות זו דוגמה מצוינת לתחום בו ריבוי הערוצים כבר הפך להיות הכרח. לכל ערוץ יש יתרון משלו (הסניף – לרכישת מוצרים "מורכבים" לעומת האינטרנט לרכישת מוצרים "פשוטים"), כך שערוץ חדש אינו מחליף ערוץ ישן אלא מתווסף אליו. לקוחות הבנקים כיום מצפים שהבנק יהיה מסוגל לספק שירותים מגוונים בסניף, ב call center, בקיוסקים/ATMים, באתר, ולאחרונה גם בטלפון הנייד. ישנם בנקים שהופכים את נושא הערוצים ליתרון תחרותי בשכבות אוכלוסיה מסוימות (דוגמת בנקים שמפעילים תכניות ממוקדות למשתמשי iphone בלבד, תוך ניצול יכולות אספקת אפליקציות עשירות הממוקדות בערוץ זה).
Self Service: לאחרונה יש הרגשה שכל נותני השירותים מנסים לדחוף אותנו להשתמש באתר האינטרנט במקום במוקד הטלפוני ומוכנים גם לתת תמריצים כדי להרגיל אותנו לערוצים אלה. מניע העלות שלהן ברור, אך לא מדובר רק בעלות האינטראקציה. שימוש במגוון ערוצים יכול משמעותית לשפר את מרכיב החוויה בצריכת המוצר, ולמרכיב זה יש חלק משמעותי בערך הנתפס של מוצר החברה. לכן הבאזוורד החדש בתחום ה-CRM כיום הנו CEM – Customer Experience Management. סיבה נוספת לצמיחה האדירה של ערוץ האינטרנט לאחרונה היא היכולת להתאים באמצעותו את המוצרים ללקוחות – פרסונליזציה.

הפוקוס עובר מתהליכים פנימיים (בתוך הארגון) לתהליכים חיצוניים (לקוחות מול הארגון):
הרבה פחות "תהליכי CRM פנימיים" והרבה יותר שיפור תהליכים חיצוניים אל מול הלקוחות. אנו רואים כרגע הרבה מיני-פרויקטים שאמורים לשפר את אופן העבודה מול הערוצים השונים:
· שילוב יכולות צ'אט עם נציג וירטואלי באתר
· חיזוק ערוץ ה call center עם תיאום תור לשיחה (במקום להמתין על הקו), זיהוי קולי
· בקשת "CALL ME" באתר
· חיזוק ערוץ הטלפון הסלולרי (לדוגמה, אפשרות לבקש שירות באמצעות SMS)

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

SaaS – ימשיך ויגדל
מודל Software as a Service הולך ומתרחב בהתמדה על חשבון המודל ה"קלאסי". בישראל ההתפתחות יותר איטית אך היא קיימת. הגופים שיותר מאמצים SAAS בישראל: ארגונים יותר "טכנולוגיים", ארגוני היי-טק, וארגונים בעלי נוכחות גלובלית במיוחד. הגופים שאינם מאמצים SAAS בישראל: ארגונים מתחום השוק הפיננסי (בין השאר בשל אי-בהירות בנוגע לנושא רגולציות), וכן ארגונים ממשלתיים וארגונים מסקטור הבריאות.
פרויקטי ה SAAS CRM שכבר בוצעו בארץ הנם פרויקטים שמאופיינים בזמן יישום קצר (מספר חודשים בודדים), ממוצע של כמה עשרות משתמשים, תחום ממוקד (ולא CRM כלל ארגוני), ולמרבה ההפתעה לרוב כן יש קישור של האפליקציה ל1-2 אפליקציות ארגוניות. עד כה נראה ששביעות הרצון מהמודל גבוהה. גם בעולם מרוצים – מעל 90% עונים בסקרי שביעות רצון שהם שבעי רצון מהמודל וימשיכו להרחיב את השימוש ב SAAS לתחומים נוספים.

CRM בישראל
מסקר שערכה STKI עולה שהרוב המאמצים בפרויקטי CRM בישראל יתרכזו בניתוח המידע על הלקוחות – CRM אנליטי. במקום השני נושא ה Self Service:

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

נושא זה יכוסה בכנס של STKI ב 24 למרץ 2009.