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

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

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

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

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

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

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

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

בקרב ארגוני 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מהם הפתרונות שה-CFO צריך? רשמים משולחן עגול

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

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

המצב הקיים לעומת המצב הרצוי:

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

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

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

• נושא תכנון תקציב (Budget Planning) כתחום אליו ארגונים כבר נכנסו או לחילופין מעוניינים להיכנס בקרוב. הכלים העיקריים שהוזכרו בהקשר זה: הייפריון, פתרונות SAP. כל הארגונים שהשתתפו בדיון סיפרו על רצונם להיכנס למערכות תכנון ובקרה (חלקם כבר עושים זאת כיום), ורובם הביעו רצון שמערכת זו תתממשק בצורה טובה עם מערכת ה-ERP שלהם. יש לציין כי למרות דרישת התממשקות זו, כמחצית ממשתתפי הדיון מסתכלים על הכלים בתחום זה ככלי best of breed (מה שאומר שאם המערכת המוצעת מספק הERP אינה מספיק טובה, הם יסתכלו על כלים אחרים). ארגונים מאוד מוטי מערכת ERP ספציפית סיפרו כי לא היה הרבה ספק בשלב בחירת המערכת שכן היא צריכה להתממשק בצורה הדוקה ל-ERP כדי לספק סגירות ותאימות חשבואנית, ולכן, גם אם המודול הרלוונטי אינו הטוב בשוק, הם יבחרו לעשות בו שימוש.
• תחום נוסף שהוזכר כחשוב הנו תחום המדידה / Balanced Scorecard. במקרה זה, מעטים הם הארגונים שכבר מיישמים שיטות מדידה באמצעות כלי מדף, אך חלקם כבר עובדים בצורה כזו עם כלים בפיתוח עצמי, ואחרים הביעו רצון להיכנס לתחום.
• מערכות המנהלות את תהליך הזמנת נסיעות – מערכות Travel שלכאורה אינה קשורה למחלקה הפיננסית, הנה מערכת שהוזכרה כמה פעמים בדיון, כאשר התועלת מהכנסת מערכת המנהלת את תהליך הזמנת הנסיעות של העובדים הנה כספית ודי ברורה – ארגונים שכבר יישמו מערכת זו סיפרו שחסכו חיסכון משמעותי והצליחו ליישם יותר בקלות מדיניות נסיעות באמצעות המערכת. המערכת מאפשרת בקרה על תהליך הנסיעות מבחינת התקציב, כולל התממשקות למערכת ה-ERP לצורך רישום חשבונאי.

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

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

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

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

ניתן לצפות בסיכום הדיון המלא כאן.

שולחן העבודה של נציג השירות - סיכום שולחן עגול

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

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

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

מפגש זה עסק בניהול, עיצוב, תכנון, ותפעול שולחן העבודה של נציג השירות. התחומים שהוזכרו בדיון:
EPSS - Electronic Performance Support Systems
Unified Desktop
כלי- Interaction Management לצורך שיפור וייעול התהליכים המתבצעים מול הלקוחות במוקדי שירות הטלפוניים.

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

• מהן הבעיות הקיימות כיום במוקד השירות?
• EPSS - מה התועלות וממה להיזהר? למי זה מתאים?
• Unified desktop - האם יש מספיק ניסיון, ובמיוחד בארץ, בתחום זה?
• מה הגבול בין מערכות תפעוליות ל-CRM?

תובנות ממפגש שולחן עגול בנושא Business Intelligence

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

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

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

קחו לדוגמה את תחום חבילות האפליקציות – מערכות ERP ו CRM כיום כוללות שירותי-BI/DW/אפליקציות אנליטיות מובנים. לא אחת אנחנו נשאלים שאלות אשר בבסיסן הן שאלות של מדיניות – מי בארגון אחראי על פרויקטים מסוג זה? מתי לאפשר את ביזוריות ה-BI הזו ומתי לא?

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

כמה מאפיינים מעניינים שעלו באשר למאפייני מחלקת ה-BI בדיון:
אצל 75% ממשתתפי הדיון קיימת יחידת BI מרכזית (אולם במספר ארגונים קטן קיים ביזור של נושא ה-BI למרות שבדרך כלל יש איזה גוף שאחראי על מדיניות ה-BI והפיתוח עצמו מבוזר)
בעלי התפקידים הכלולים במחלקת ה-BI/DW: מנתחי מערכות, מנהלי פרויקטים, אנשי DW – נתונים שעוסקים ב ETL, מודל נתונים וכד', אנשי פיתוח ובדיקות.
לרוב מחלקות ה-BI אין DBAs משלהם (זאת למעט ארגוני Teradata) אלא הם צורכים שירותי DBAות ממחלקת תשתיות.

יחסי כוח אדם
מסקר שערכתי בין המשתתפים על נושא יחסי כוח אדם עלתה שונות גדולה. מספר העובדים במחלקת ה-BI נע מ 4-6 במחלקות הקטנות יותר, ועד 60< במחלקות הגדולות יותר. המספר הממוצע של מספר עובדי ה-BI בארגונים ישראליים גדולים הוא 10-15 עובדים (נתון זה מסתמך על סקרים נוספים שביצעתי מול חברות רבות). ניסינו למצוא יחס בין מספר עובדי ה-BI למספר המשתמשים שעושים שימוש בשירותי ה-BI אולם גילינו כי מדד זה מאוד בעייתי בשל השונות בהגדרה "משתמש BI”, ובשל המגמה של מערכות תפעוליות שהופכות להיות משתמשים הצורכים שירותי BI בעצמם. הייתה שונות גבוהה מאוד בין היחסים שציינו הארגונים: החל מעובד BI אחד לכל 6 משתמשי BI, ועד לעובד BI אחד לכל 185 משתמשים. שיטת מדידה נוספת ויותר מוצלחת הנה גודל מחלקת ה-DW/BI (או מספר העובדים הכולל בתחומים אלה) ביחס לכלל מחלקת ה-IT. מהנתונים שאספתי, הנתון הממוצע של עובדי מחלקת ה-BI/DW מתוך כלל מחלקת ה-IT (תשתיות + פיתוח): 6.5%. יש לציין שהאחוזים שקיבלתי נעו בין 3% לבין12%. מספר ארגונים אחדים עמם שוחחתי ציינו כי תחת מחלקת ה-BI יושבים גם אנליסטים, רוב המשתתפים (כ-80%) ציינו כי האנליסטים יושבים במחלקות העסקיות. בדיון עלה גם נושא ה"גבולות" – נושא מעניין בפני עצמו. מה מחלקת ה-BI צריכה לעשות ומה לא? בארגון אחד שהשתתף מחלקת ה-BI כמדיניות שקבעה לעצמה עקב משאבים מוגבלים נותנת שירותים רק במקרים בהם יש להם ערך מוסף (כלומר אינה מוכנה להעביר נתונים ממקום למקום איפה שאין לה ערך מוסף). ארגונים אחרים ציינו כי נושא הגבולות נבדק כל הזמן ואחד מהארגונים חלק מניסיונו כשסיפר שכל גבול אדום שמחלקת ה-BI הציבה לעצמה בסופו של דבר נפרץ. באופן כללי הוסכם כי מחלקת ה-BI צריכה להתמקד בפעילויות בהם יש לה ערך מוסף, ולבחון האם לא כדאי לבצע בקשות מסוימות דווקא ברמת המערכת התפעולית ולא ב-DW.