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

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

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

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

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

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

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

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

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

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

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

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

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

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