ירחון 2Know לניהול ידע
ירחון 2Know לניהול ידע
גיליון פברואר 2009 - מהדורה מס' 113
גיליון פברואר 2009 - מהדורה מס' 113
גיליון:
קורס ניהול ידע - "לדעת יותר"

מחזור 15 של קורס "לדעת יותר" מבית ROM Knowledgeware  יפתח ב 22/4/09

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

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

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

לפרטים נוספים על הקורס לחצו כאן.

 

KM Expert Summit 2009

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

הכנס יתקיים ב-4 במרץ 2009, במרכז הכנסים Avenue ב- Airport City. 

לקראת הכנס אנו מקיימים  את סקר ניהול הידע. הסקר נערך זו השנה החמישית ע"י ROM Knowledgeware ואנשים ומחשבים ומנתח מצב קיים ומגמות בשוק ניהול הידע בישראל.


זוכי IT AWARDS 2008

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

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

 

מונח: Kiwi
נכתב ע"י טל אלון ומוריה לוי ROM

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

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

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

נכתב ע"י נעמה ברקוביץ' ROM

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

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

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

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

 

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


 

נכתב ע"י מוריה לוי ROM

פיתוח מסגרת לניהול ידע לפרוייקטים גלובליים. זה שמו של הספר שכתב Christian Thanner, בחור אוסטרי בן שלושים, המתמחה ב- BI, ו- IT. בעקבות הספר, שהוצא ב- 2008, ניתן ללמוד שהוא מתמחה גם בניהול ידע.
הספר, בעל אוריינטציה אקדמית, מנסה להתמודד עם השאלה, שמטרידה רבים מאיתנו: כיצד ניהול ידע מסייע לניהול פרוייקטים בינלאומיים גלובליים?
הספר, מתבסס בחלקו האקדמי על מודלים ידועים של WIIG, Nonaka, Kerzner, Probst, Prusak & Davenport ונוספים. בחלקו השני, הוא מתאר Case study של פרוייקט גלובלי במסגרת פרוייקטי האיחוד האירופי, פרוייקט שבוצע במסגרת תוכנית INTERREG (תוכנית GILDANET) שחברים בו נציגי ארגונים מיוון, אוסטריה ואיטליה.

הספר כולל:

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

 

 

פרוייקטים גלובליים ומאפייניהם

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


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

 

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

 

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


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

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

 

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


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

ידע וניהול ידע

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

ידע מוגדר כיכולת לפעול, ולהפוך מידע לבר-פעולה (לייבוביץ' ומגלולוגב).

 

ממדים רבים לידע. חמישה ממדים על פיהם ניתן להתייחס לידע ולהבינו:
    ידע סמוי אל מול ידע גלוי.  Explicit Knowledge vs. Tacit Knowledge.
    ידע פרטי אל מול ידע ארגוני.  Individual Knowledge vs. Organizational Knowledge.
    ידע פנים ארגוני אל מול ידע חיצוני. Internal Knowledge vs. External Knowledge.
    ידע עבר אל מול ידע הווה אל מול ידע עתיד. Historical, Future and Present Knowledge.
    ידע מבני אל מול ידע אישי.  Structural Knowledge vs. Personal Knowledge.

 

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


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

 

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

 

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

ניהול הידע בתוכנית INTERREG

INTERREG הנה יוזמה קהילתית בתחום המדיניות האזורית, כחלק מפעילות
האיחוד האירופי, שמטרתה לסייע למדינות ולארגונים שבהם להיערך ולהרוויח מתהליך האיחוד האירופי. התוכנית הספציפית, עליה נלמד ה- Case study, הנה חלק מ-11 תוכניות INTERREG III B, תוכנית GILDANET המסייעת ליעילות ויציבות מערכות תעבורה וגישה לחברת הידע. מדובר בתוכנית עם תקציב של 4,363,150 אירו בה שותפות 5 ארגונים מאיטליה, יוון ואוסטריה (שלושה ארגונים ושתי חברות ייעוץ).

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

 

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

 

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

המלצות איך לנהל ידע בפרוייקט גלובלי

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

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

 

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

 

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


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

נכתב ע"י ענת קוסיאק ROM
קצת תיאוריה..

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


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

 

והלכה למעשה...

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

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

ולסיכום...

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

 

נכתב ע"י נ. קמינקא. עיבוד ותמצות: טל אלון ROM

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

עולמנו דינאמי ומשתנה, וארגונים מתחדשים ומשתנים גם הם, בין היתר בכדי להתאים את אופן פעילותם ואת ‏אופייה למציאות המשתנה. ניתן לחלק את השינויים החלים בארגון לשלוש רמות, מהבסיסית ביותר למורכבת ‏ביותר:‏
 ‏1.‏ רמה ראשונה: שינויים ה"נראים לעין" – פעילות למען יציבות כלכלית על ידי שינוי מוצרים, שיטות ‏עבודה, ציוד וייעול תהליכים. ‏
 ‏2.‏ רמה שנייה: שינויים המצריכים פריצת דרך בחשיבה – חשיבה "‏out of the box‏" מובילה לדריסת ‏רגל בתחומים חדשים, לשינוי כיוון ואסטרטגיה ולפריצות דרך ארגוניות משמעותיות.‏
 ‏3.‏ רמה שלישית: שינויים המצריכים הן חשיבה שיטתית והן תפקוד שיטתי מסוג אחר – כאלו ‏המלבים באופן מתמיד התחדשות ארגונית.‏

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

רמה ראשונה: שינויים הנראים לעין

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

 

רמה שנייה: פריצת דרך בחשיבה

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

 

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

 

רמה 1 – שינויים נראים לעין

רמה 2 – פריצת דרך בחשיבה

רמה 3 -  שינויים שיטתיים בחשיבה ובתפקוד

מקור השינוי

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

חשיבתי

קוגניטיבי, חשיבתי, התנהגותי, פסיכולוגי וניהולי

אופי השינוי

מגמתי, מונחה חתירה לשמירה על היכולת התחרותית של הארגון

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

לאחר הטמעה נכונה – תמידי

תוצאות השינוי

שיפורים בתהליכים, במוצר, בשירות, וכד'; יציבות כלכלית

מוצרים חדשים, שירותים חדשים ולעיתים פריצות דרך ארגוניות

פריצות דרך משמעותיות, "הברקות"

עיתוי השינוי

נקודתי, חל בעת משבר או צפי למשבר

נקודתי ולעיתים מקרי

בעל תדירות גבוהה

גורמים מחוללי שינוי ("סוכני השינוי")

המייעלים הארגוניים

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

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

טווח זמן של השפעת השינוי ("תהודת השינוי")

עד תום חיי המוצר ו/או השירות החדש

עד תום חיי המוצר ו/או השירות החדש ולעיתים בעל השפעה לטווח ארוך יותר

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

אז כיצד נחד"ש (קרי, נפעיל חדשנות שיטתית) בארגונינו?‏

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

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

 

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

 

‏* להרחבה:  ‏http://www.bt-center.co.il/webPageHeb/page_5B6%20chadshanut%20.htm


 

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

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

ידע צריך לשתף!

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

 

 

כנסים בארץ

שם הארוע מקום הארוע ת. התחלה ת. סיום פרטים
KM Expert Summit 09 Avenue, קרית שדה התעופה 04/03/2009 --- לחצו
מפגש מועדון KMI קראון פלאזה, ת"א 26/1/2009 --- לחצו

 

 

 

 

 

כנסים בחול

 

 

שם הארוע מקום הארוע ת. התחלה ת. סיום פרטים
The Second Annual Global Learning Summit Singapore City, Singapore 24/2/2009 27/2/2009 לחצו
Knowledge Management Africa 2009 Dakar, Senegal 04/05/2009 07/05/2009  
APQC Knowledge Management Conference 2009 Houston, United States 14/5/2009 15/5/2009 לחצו
ירחון 2Know-BI
נכתב ע"י מוריה לוי ROM Knowledgeware

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

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

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

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

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

 

סקר נוסף שערכו גרטנר בקרב CIO's מדבר על חמשת הנושאים בעדיפות עליונה להשקעה טכנולוגית. החמישה שנבחרו הנם:

business intelligence; enterprise applications; server/storage/virtualization; legacy app modernization; collaboration technologies.

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

 

נקווה שאכן יצדקו.

לעיון מעמיק יותר: http://www.echannelline.com/usa/story.cfm?item=24021 

http://www.insurancenetworking.com/news/data_management_BPM_business_intelligence_BI_Gartner11724-1.html

נכתב ע"י מוריה לוי, ROM Knowledgeware

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

PCWORLD פרסם בסוף 2008 את עשרת הסיפורים המשמעותיים ביותר בעולם התוכנה לשנה שהסתיימה. בצד פרישתו של ביל גייטס מ- MICROSOFT ורכישת HP את EDS, מופיע גם סיפור זכייתו של אובהמה וחלקם של מערכות המידע בזכייה זו.

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

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

ימים יגידו. בינתיים, נתאזר בסבלנות.

נכתב ע"י מוריה לוי, ROM Knowledgeware

סיכומים רבים הופיעו בסוף שנת 2008 ובתחילת שנת 2009, בנושא הבינה העסקית.

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

להלן עיקרי הדברים:

ראשית, שנת 2008 היתה שנה רגועה לעומת השנה שקדמה לה, 2007, בה שלוש חברות התוכנה העיקריות בתחום ה- BI (Hyperion, Business Objects, and Cognos) נרכשו, כל אחת, ע"י ענקית תוכנה שאינה בתחום ה- BI.

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

  1. ההתעניינות בכלי מחסני נתונים (DW Appliances) גדלה. כמובן שבראש צועדת Microsoft עם רכישת DATAllegro, אולם היא רק דוגמא. מעניין לציין, שלחברה, טרם נרכשה ע"י MS, היו כנראה פחות מחמישה לקוחות, למרות שלוש שנות פעילות. כאמור, מתחילה התעניינות, שצופים שתלך ותגבר גם בהמשך.
  2. Microsoft משחררת מספר הצהרות לגבי פרוייקטים / פיתוחים / כלים ופתרונות שלה בתחום הבינה העסקית. במשפט אחד המסכם את הכל: Microsoft רצינית לגבי התחום.אחד הפרוייקטים המעניינים יותר שכדאי לעקוב אחריו הוא ה- Kilimijaro.
  3. ריבוי עיסוק בניתוחי נתונים (Analystics). ניתן להסביר זאת בכך שלמרות הגידול במספר המשתמשים, הגידול בכמות הנתונים עצומה עוד יותר, מה שמוביל באופן טבעי ליכולת לעסוק בניתוח מעמיק יותר. דודמאות לחברות שמציעות פתרונות בתחום כוללות את SAS, Teradata, Sybase ואפילו את Microsoft.
  4. חברות קטנות שעד עכשיו כמעט והיו בלתי מורגשות, פרצו לתודעה. דוגמאות לחברות כאלו כוללות את Aster Data, ParAccel, Vertica, InfoBright ו- Kognitio.

מקווים שהשנה תהיה לא פחות מעניינת.

לקריאת הכתבה המקורית במלואה: http://www.tdwi.org/News/display.aspx?ID=9260

 

 

 

נכתב ע"י מוריה לוי, ROM Knowledgeware

Juiceanalytics  הנו אתר שתמיד יש בו הפתעות מעניינות. לאחרונה נתקלנו בכתבה המסייעת בפיתוח Realtime Dashboards מוצלחים. שמונה המאפיינים העיקריים של Dashboards כאלו הנם:

  1. שורה תחתונה מסכמת בולטת הנותנת מענה לשאלתנו העיקרית. הרעיו: שאנשים יוכלו להציץ באתר ולדעת היכן נמצאים.
  2. שיקוף של המבנה העסקי ויחסים בין מרכיביו השונים. אל תקימו Dashboard זמן אמת, אם לא עמדתם על טיבו של הארגון והבנתם אותו היטב!
  3. הצבעה מהירה לצעדים לאבחון הבעיה.. חשוב מאד להצביע בפתרונות זמן אמת, באופן מיידי לצעדים המסייעים למשתמש לאבחן מהו מקור הבעיה בה הוא צופה.
  4. פשטות. המחישו את הנתונים באופן פשוט. במערכות זמן אמת, פחות מתאים לייצר גרפים מתוחכמים, אלא יש לכלול אמצעים ממחישים פשוטים ודרכי ייצוג מופשטים להעברת המסר.
  5. הצגה עיתית של פריט המידע הבסיסי ביותר. לכל Dashboard סמן אמת יש פריט עיקרי אחד לפחות אותו הוא דוגם. בנו את הדיווח והכניסה על פי פריטים אלו.
  6. הגדרת חלון זמן מתאים. בנתוני זמן אמת כדאי לנתח מהו חלון הזמן הנכון והראוי ביותר אליו יתייחסו הנתונים ולא להמעיט מכך, וגם (וזה יותר מפתה כמובן)- לא להרבות.
  7. התרעות מאוזנות. Dashboards זמן אמת, הנם מועמדים טבעיים להתרעות. יש לחשוב ולתכנן את האיזון בין הודעות היסטריות להודעות יבשות. יש להדגיש נכון את חשיבות ההודעה.
  8. הצבעה למקור הבעיה. על כל בעיה שמוצפת, כדאי להפנות למקום ממנו ניתן לטפל בבעיה, ואם אין אפשרות לכך, לפחות לידיעה על הצעדים הבאים הדרושים לתחילת טיפול בה.

מומלץ להעמיק ולקרוא דוגמאות באתר עצמו. כתובתו:

http://www.juiceanalytics.com/writing/8-features-successful-real-time-dashboards/

 

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

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

אגרגציה הנה למעשה דרך לממש בפועל קבוצות חלקיות של קוביות רב ממדיות.

 

בהכללה ניתן לומר שהיתרון המרכזי של טבלאות מסוכמות הנו שיפור ברמת ביצועים;

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

 

מתי כדאי בכל זאת לעשות שימוש באגרגציה? (כמה המלצות התקבלו על סמך הרצאה של SAP):

 

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

 

יש לתת את הדעת גם על ההיבטים העסקיים:

עד כמה יהיה צורך לגשת לנתוני משנה לצורך קבלת החלטות?

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

ומאידך-

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

 

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

בלוג זה הנקרא DASHBOARDS BY EXAMPLE הוא בלוג שימושי מאד לכל העוסקים בהקמת לוחות מחוונים בארגונים.

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

מומלץ בחום!

כתובת הבלוג- http://www.enterprise-dashboard.com/  

נכתב ע"י מוריה לוי, ROM Knowledgeware

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

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

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

1. הוא מקיף באופן מרשים ביותר.

2. הוא כתוב באופן מקצועי.

3. למרות שהוא מתוארך, התאריכים הנם משניים, והתגיות מאפשרות הצגה לפי נושא. וכאמור הנושאים רבים.

בין היתר הוא כולל גם הפניות לאתרים רבים אחרים, וכמובן לתוכנות ה- BI השונות.

מומלץ.

כתובתו: http://businessintelligencesoftware.blogspot.com/2008_10_01_archive.html  

נכתב ע"י מוריה לוי ROM Knowledgeware

אין ספק שהספר Business Intelligence Roadmap, שנכתב בשנת 2003 ע"י שתי נשים Larissa T. Moss ו- Shaku Atre, הנו ללא ספק אחד הספרים המקיפים ביותר שנכתבו בתחום הבינה העסקית. הספר עוסק בהקמת פרוייקטי בינה עסקית וסוקר לא פחות מ- 920 פעיליות שיש לבצע במהלך פעילות זו.
הספר, בעל אוריינטציה טכנולוגית, יותר מאשר עסקית, וניכר שנכתב ע"י אנשי מערכות מידע, אך בהחלט כאלו מנוסים שעסקו בעשרות פרוייקטים לפחות, אם לא למעלה מכך. בנוסף ל-16 פרקים המתארים כל אחד את שלבי הפעילות השונים, ישנם פרקים נוספים הסוקרים את הפעילות מנקודות מבט שונות: מיהם השותפים ובאילו שלבים הם לוקחים חלק; רשימת טיפים וכללי עשה ואל תעשה לכל שלב; נקודות כניסה ויציאה לכל שלב, המלמדים, מעבר לתוצאות המתקבלות מביצוע השלב, מתי לא כדאי לבצע את השלב (כאשר נקודת הכניסה לא מתקיימת, או לחילופין, כאשר נקודת היציאה כבר הושגה בארגון); תכנית עבודה מפורטת, ועוד.
ששה עשר השלבים מאורגנים בששה שלבי על  להקמת סביבת הבינה העסקית. לא נראה לי שרבים ידבקו ברמת תשומה ורמת פירוט זו. ועם זאת, יש מה ללמוד מהבנת המודל המוצע:

 

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

 

הצדקת הפעילות
הערכת המקרה העסקי Business Case Assesment

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

 

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


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


 

תכנון
ניתוח תשתיתי Enterprise Infrastructure Evaluation

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

הניתוח הטכנולוגי:
בוחן את-
1. החומרה (Hardware), ביזורה ורמת הבקרה של ביזור זה וחלוקת הנתונים בתוכו.
2. התווכה (Middleware) והעברת המידע והנתונים הקיימת כיום בין המערכות והיחידות השונות.
3. מסד הנתונים (DBMS) רמת השונות שבו (למספר סוגי מסדים שונים), והרמה הטכנולוגית של המסדים המובילים.
כולל את הפעילויות הבאות:
הערכת הפלטפורמה הקיימת; הערכה ובחירה של מוצרי שתית נוספים; דו"ח תשתיתי; רכישה והרחבה.

 הניתוח הארגוני:
בוחן מצב נוכחי של-
1. פעילויות הארגון הפונקציונליות.
2. תהליכי עבודה.
3. ישויות ונתונים.
4. שימוש מערכות תפעוליות במידע. מידע חוצה ארגון.
5. מילון נתונים תשתיתי.
6. עבודה לפי סטנדרטים, וסטנדרטים אחידים.
כולל את הפעילויות הבאות:
הערכת התשתית הארגונית; דו"ח מצב; שיפור

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

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


 

תכנון הפרוייקט Project Planning

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

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

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


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


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

ניתוח עסקי:
הגדרת דרישות Project Requirements Definition

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

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

ניתוח נתונים Data Analysis

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

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

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

כאשר אנו מדברים על מודל שלם, אנו מגדירים:
  • חוקי הסבה טכניים בין המערכות. מתקיימים תמיד.
  • חוקים עסקיים הקשורים בתוכן הנתון. פירוט להלן.
  • חוקי שלמות נתונים. פירוט להלן.
         הפרות של חוקים עסקיים:
     ערכי נתונים חסרים.
     שימוש בערכי ברירת מחדל (0,999, FF וכו').
     ערכי dummy בעלי משמעות עסקית ייחודית (שימוש בת.ז. 888 כדי לציין תושב זר וכו').
     לוגיקה הכלולה בתוך ערכי הנתון: מיקודים נמוכים מעידים על אזור היישוב בארץ.
     שימוש מרובה בשדה אחד: ערכים בטווח מסוים מדברים על סוג הלקוח, בטווח אחר על מיקומו וכו'.
     שימוש מרובה על ציר הזמן באותו נתון למטרות שונות (redefine בשפת COBOL).
     נתונים המתפרשים על יותר משדה אחד (כתובת ב- 5 שורות המהוות 5 שדות).
         הפרות של חוקי שלמות נתונים:
     סתירות בין נתונים הקשורים לישות משותפת. למשל: לונדון, צרפת.
     הפרות של חוקים עסקיים מוגדרים לאותה ישות. למשל: אדם שתאריך לידתו אחר תאריך פטירתו.
     ערכים שונים בעלי מפתח אחיד (שני אנשים עם אותה ת.ז.).
     חסר במפתח ייחודי (לקוח אחד עם מספר קודי לקוח שונים).
     ישויות ללא ישות אב. למשל- עובד עם קוד מנהל שאינו קיים.

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

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

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

טיפים:
 • טריוויאלי, אך לא תמיד מבוצע: שילוב DBA בביצוע שלב זה.
 • בתוך תיחום הפרוייקט- שימוש בטכניקת Top-Down  להגדרת החוקים העסקיים וב- Bottom-Up לאיתור הפרות.
 • למנהלים שטרם ניהלו שלב כזה בעבר: הכפילו כל הערכת זמנים פי 4 !!!!

 

אבטיפוס ליישום Application Prototyping

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

         נקודות מומלצות בעת קביעת אבטיפוס:
 • צוות אבטיפוס קטן.
 • ניהול הדוק של deadline.
 • תיחום. עשו שימוש במונח- slimware.
 • תוצרים מוגדרים היטב.
 • תכולה: כללו בדיקה של GUI, ממשקים ושיטות הבאת תוצרים נוספות.
 • המעיטו בהגדרות שלמות נתונים לאבטיפוס.
 • שתפו עד 5 (ובמקרים חריגים עד 8) בעלי תפקידים עסקיים באבטיפוס. לא יותר.
 • עודדו את בעלי התפקידים העסקיים להגדיר מדדי הצלחה.

סוגי אבי-טופס מוכרים קיימים:
Show & Tell (מוכוון הנהלה); Mock-up (להבנת דרכי גישה וניתוח נתונים); Proof-of-Concept (לבירור נקודות מימוש לא סגורות); Visual-Design (כמו Mock-up, אך מעמיק יותר ); Demo (מראה ופונקציונאליות חלקית); Operational (בוחן סוגיות תפעול. רחב).
את האבטיפוס מומלץ ללוות במסמך מגדיר הכולל הגדרת סוג, מטרות, בעלי תפקיד עסקיים מעורבים, חומרה ותכנה, הגדרת דרישות להבטחת סטנדרטים, ידע ומיומנויות של הצוות ושימושיות.

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

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


 

ניתוח מילון נתונים תשתיתי Meta Data Repository Analysis

ניתוח מילון נתונים תשתיתי  Meta Data Repository Analysisמילון נתונים תשתיתי הוא גם מסד, אלא שמטרתו להכיל מידע על הנתונים הקיימים.
המידע משמש גם להבנה (כוללת של המערך ופרטנית של מצב נתון); גם ככלי לניהול וגם ככלי לניווט בתכנים. קיומו של מילון נתונים עוזר לקידום הסטנדרטיזציה.
המידע המומלץ הכלול מסווג לארבע קבוצות:
 1. בעלות (על נתונים ועל יישומים).
 2. מאפיינים תיאוריים (לתהליכים עסקיים; לנתונים עסקיים): שם, תיאור, הגדרה, ערכים מותרים, הערות.
 3. חוקים ומדיניות עסקיים: קשרים, מדיניות עסקית, אבטחת מידע, טיוב, תוקף, עדכניות.
 4. מאפיינים פיזיים (לנתונים ויישומים): מקור, מיקום פיזי, הסבות, חישובים למיניהם, היקף, צמיחה.

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

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

 

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

עיצוב
עיצוב מסד Database Design

מסדי נתונים התומכים בפעילות בינה עסקית שונים מאלו התומכים במערכות תפעוליות.
עיקרי ההבדלים:
 • מוכוונים כלפי משתמשים שונים, בעלי צרכים שונים. מותר לאפשר כפילויות.
 • זמני התגובה נמדדים על פי רוב בשניות, דקות ושעות (ולא תת שניות).
 • לא מנורמלים!
 • מכילים מידע רב מחושב, ולא רק נתונים גולמיים.
 • מכילים מידע היסטורי ולא רק תמונת מצב עכשווית.
 • כוללים רמות רבות של מידע סיכומי.
סוגי העיצוב העיקריים של מסדי נתונים כוללים:
 • -Star Schema לאחסון טבלאי של נתונים קובייתיים.
 • -Snowflake Schema כנ"ל, אך תוך יצירת היררכיה למאפייני הגישה (למשל ארץ> עיר> שכונה).

         עיצוב פיזי חשוב להבטחת זמני תגובה סבירים. אפשרויות לזירוז זמני תגובה:
 • אחסון נתונים תדירים בגישה על התקנים מהירים.
 • אחסון רמות שונות של סיכום על פלטפורמות שונות.
 • Stripping של הדיסקים (לדיסקים פיזית קטנים) להשגת אופטימיזציה של פעילות הקלט-פלט.
 • מיקום ה datasets כך שחיפושים ארוכים נמנעים ככל האפשר.
 • בחירת כתובת וסכמות אחזור במקצרות את כמות ה- seeks. המטרה- seek  אחד לכל אחזור.
 • הרצת פעילויות רבות ככל הניתן במקביל.
 • הפרדת אינדקסים מנתונים. הפרדת האינדקסים עצמם בין הדיסקים השונים.
עיצוב פיזי כולל התייחסות לפרמטרים הבאים:
 Partitioning, Clustering, Indexing, Reorganizations, Backup & Recovery.

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

טיפים:
 • תנו לאנשי ה DBA לעצב את מסד הנתונים. אל תחליטו לבד ותשאירו להם רק את הבניה.
 • הטמיעו את ההבנה שמסדי הבינה העסקית ענקיים (VLDB). אלו שלא- יהיו כאלו. תכננו בהתאם.
 • Clustering משפר ביצועים באופן ניכר ביותר. נצלו אותו.
 •  אל תבנו אינדקסים כאשר ישנם ערכים שמתייחסים ליותר מ- 15% מהנתונים (מין).
 • ארגנו מחדש את המסד לאחר 5% תוספות /ביטולים.

עיצוב ETL ETL Design

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

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

ההיערכות לתהליך ETL כוללת:
 • Reformatting- פרמוט מחדש, היות ומקורות המידע מסוגים מגוונים.
 • Reconciling- יישוב סתירות בין מגוון המקורות המשולבים יחד.
 • Cleansing- היערכות לטיוב: הגדרת הצרכים.

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

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

הפעילויות העסקיות הכלולות בשלב זה: כתיבת דו"ח מיפוי מקור-מטרה; בחינת יכולות כלי ה ETL; עיצוב תהליך ה ETL; עיצוב תוכניות ה ETL; הכנת אזור עבודה ל ETL.

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

עיצוב מילון תשתיתי Meta Data Repository Design

עיצוב מילון נתונים אינה סוגיה חדשה והיא מקובלת מתחילת שנות ה- 80. עם זאת,
תמיד היא היתה מאופיינת בבעיות רבות החל מהזנה ידנית, דרך טכנולוגיות לא בשלות ועד כשל ביצירת מילון משותף, חוצה יחידות בעל הבנה והערכה ארגונית.
לא נאמר שהמצב התהפך, אך יש בהחלט שיפור, לפחות בחלק מהממדים, והיכולת לשקול מילון נתונים תשתיתי בהחלט אפשרית וישימה.
סוגיות מרכזית בעיצוב מילון נתונים:
 1. מילון ריכוזי / מבוזר (מודל משותף, המידע מבוזר) / מבוסס XML (מודלים שונים במילונים שונים, כאשר התיוג המשותף XML).
שיקולים להחלטה- נוחות ממשק, שליטה על התכנים, אמינות ועדכון אוטומטי, בעלות, כפילות נתונים.
 2. רכישה / פיתוח עצמי:
שיקולים להחלטה- התאמה לצרכים, חסכון במשאבי פיתוח.
 3. מבנה ERD (Entity Relational Diagram) / OO (Object Oriented) :
שיקולים להחלטה- קלות קריאה והבנה, גמישות מבנית, פשטות שליפה, פשטות מימוש.

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

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

בנייה:
פיתוח ETL ETL Development

הרבה מהשלבים הקודמים כללו איסוף של חוקים עסקיים. אלו באים לידי ביטוי
בשלב זה של בניית ההסבה בפועל.
ההסבה כוללת את הרכיבים הבאים:
 1. טיוב.
 2. סיכומים (בעיקר סכומים או כמויות).
 3. נתונים מחושבים.
 4. אגרגציה של נתונים ממקורות שונים.
 5. שילוב של נתונים והחלטה על מפתחו ושמות יחידים.

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

הפעילויות העסקיות הכלולות בשלב זה: בנייה ובדיקה יחידנית (Unit test) של תהליך ה ETL; בדיקות אינטגרציה או רגרסיה של התהליך; בדיקות ביצועים של התהליך (!!!); בדיקות איכות; בדיקות קבלה.

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

פיתוח יישום Application Development

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

הפונקציונאליות הנלווית לכלי OLAP:
 • מייצגים את המידע והגישה אליו באופן רב ממדי.
 • נותנים סיכום ואגרגציה.
 • נותנים יכולות שאילתא וניתוח אינטראקטיביים.
 • תומכים מנתחים עסקיים הבונים שאילתות משתנות.
 • תומכים בפעולות drill-down, roll-up, drill-across.
 • כוללים מודלים אנליטיים.
 • כוללים מודלים לניתוח מגמות.
 • מציגים מידע בדו"חות ובגרפים.
תשתית OLAP כוללת שלושה מרכיבים: שירותי תצוגה; שירותי OLAP; ושירותי מסד נתונים.

ארגונים רבים עוסקים במערך בינה עסקית בלקוחות. שמונת הממדים הקשורים ללקוחות ולמידע עליהם, הנם:
 1. סוג לקוח.
 2. התנהגות רכישות.
 3. דירוג אשרי.
 4. תחום.
 5. דמוגרפיה.
 6. פסיכוגרפיה (פילוח שוק על-פי מאפייני אישיות של קהלי יעד).
 7. היסטורית רכישות.
 8. קטגורית מוצרים.

הפעילויות העסקיות הכלולות בשלב זה: החלטה סופית על הדרישות; עיצוב תוכניות יישומיות; בניה ובדיקה יחידנית של התוכניות; בדיקה כוללת של התוכניות; הדרכות לגישה למידע.

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


 • קל להבין 2-3 ממדים; 5-6 ממדים קשים לתפיסה; 7 ממדים הם המקסימום.
 • כדי לאפשר ביצועים סבירים הכינו מידע סיכומי לשאילתות שכיחות. יותר אפקטיבי מאשר להסביר למה זמני התגובה מתארכים.

כריית נתונים Data Mining

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

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

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

טכניקות כריית נתונים:
 1. Associations Discovery- זיהוי התנהגות של מאורעות/תהליכים בדידים (רכישה בסופרמרקט).
 2. Sequential Pattern Discovery- זיהוי התנהגות לאורך זמן של מאורע / תהליך (רכישות בסופרמרקט).
 3. Classification- זיהוי מאפיינים של קבוצות שהוגדרו מראש (מאפייני נוסעים מתמידים).
 4. Clustering- ארגון פריטים בקבוצות; זיהוי הקבוצה אליה משויך כל פריט.
 5. Forecasting- ניתוח רגרסיה בכלל וניתוח רגרסיה תלוי זמן בפרט.

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

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

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

פיתוח מילון תשתיתי Meta Data Repository Development

מילון נתונים תשתיתי משרת אנשים טכניים, אך הרבה יותר מכך בעלי תפקידים.
במידה ולא רוכשים אחד כזה, יש לבנותו לבד. מעבר לכך, יש לתכנן את איסוף המידע לתוכו ממקורות מגוונים:
  מסמכים- נהלים, מדריכים ומסמכים נוספים המתארים חוקיים עסקיים.
  גיליונות נתונים (Excel)- למידע על חישובים, macros ועוד.
  כלי CASE- הכוללים הגדרות של הנתונים הנשמרים במסדים.
  מילוני DBMS- כנ"ל.
  כלי ETL- הכוללים מידע על ההעברות.
  כלי OLAP- הכוללים מידע על חישובים וסיכומים.
  כלי כריית נתונים- הכוללים מידע תיאורי על המודלים האנליטיים בשימוש.

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

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

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

פריסה:
מימוש Implementation

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

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

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

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

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

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

הפעילויות העסקיות הכלולות בשלב זה: תכנון המימוש; הקמת סביבת ייצור; התקנת כלל מרכיבי היישום; העלאת תוכניות ETL למסלול תוכניות המורצות באופן קבוע; טעינת נתוני הייצור; היערכות לתמיכה.

טיפים:
• מינוני נתונים: 30% נתונים עסקיים; 30% אינדקסים; 30% סיכומים; 10%- אחר.

הערכת גרסא Release Evaluation

תפיסת הגרסאות גורסת חלוקת כל פרויקט בינה עסקית למידע שמביאים עכשיו ולמידע
שיובא בעתיד. תפיסה זו מאפשרת העלאת פתרונות, שכן אחרת, יותר מידי פעמים נדחה את ההעלאה, ויותר מידי פעמים נשקיע 20:80 שדברים שאולי לא תמיד נדרשים, ובטח לא נדרשים עכשיו.
עקרונות להגדרת גרסא:
  מומלץ לנפק גרסא חדשה כל 3-6 חודשים (חוץ מהראשונה שמשכה אורך יותר).
  תוצרי גרסא צריכים להיות קטנים וברי ניהול.
  יש לנהל ציפיות ביחס למה מקבלים בגרסא נוכחית ומה לא.
  גרסא לא חייבת לכלול יישום שלם.
  הגרסא הראשונה – עדיף שתתן רק יסודות.
  על ההנהלה להיות מוכנה לקבל מידע בגרסאות.
  הכל בר משא ומתן. אין כלום שהנו בגדר "חובה".
  על התשתית התומכת להיות יציבה.
  Meta data הנו חלק מכל גרסא, אחרת לא ניתן לנהלן.
  תהליך הפיתוח צריך להיות בעל נראות.
  על הכלים לתמוך בגמישות הנדרשת מעבודה בגרסאות (פיתוח מדורג).
  יש לתעדף צרכים חדשים ולא למלאם דווקא לפי סדר הגעתם.
  שגיאות קטנות יש לתקן גם בין הגרסאות ללא עיכוב עד הגרסא הבאה; שגיאות גדולות תחכינה, ואם יש צורך, יש להסיר את המידע / פונקציונאליות שגויה עד אז.

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

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

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

המגזין נכתב ע"י חברת Rom Knowledgeware
Fax 077-5020772 * Tel 077-5020771/3 * רח' בר כוכבא 23, בני ברק מיקוד 67135