ירחון 2Know לניהול ידע
ירחון 2Know לניהול ידע
גיליון אוגוסט 2004 - מהדורה מס' 59
גיליון אוגוסט 2004 - מהדורה מס' 59
גיליון:

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

 

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

החדשות- מוקדם מדי להרים ידיים ולוותר על החלום. לאחרונה פיתחו חברות כמו HP ,Fujitsu ו- Xerox/Visioneer סורקים (Scanners) מפותחים. ה- Scanners החדשים מאפשרים לסרוק ערימות של נייר משני צידי הדף ולהופכם לקבצי PDF הניתנים לחיפוש, סינון ושליחה. כלומר- לא עוד תמונה אלא קובץ קריא!!!

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

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

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

החדשות מבוססות על כתבה שפורסמה ב-NYT מגזין.



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


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

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

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

 

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

 

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

 

או, בדומה לאימרה המפורסמת (במהופך), איך אפשר ללכת בלי, אך להרגיש עם?

 

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

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

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

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

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

1.      קפיצת חלון התיוג כחלק מפעולת השמירה הרגילה ולא ככפתור נפרד המחייב "לזכור" כדי לשמור במשותף.

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

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

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

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

 

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

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

 

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

 

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

הוא שנאמר- ללכת בלי ולהרגיש עם.

נכתב ע"י סיון הלוי, ROM Knowledgeware

כיצד נפעל להבאת ההנהלה הבכירה ממצב של מודעות למצב של מחויבות אישית?

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

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

ובכן מה עושים?

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

מודעות-->הכרה בצורך--> מעורבות-->שותפות-->מחויבות

 

האם המנהל אכן מודע לנושא?

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

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

ואם הוא חלק מהתהליך, האם הוא שותף פעיל ויוזם?

והאם הגענו לאידיאל: שהמנהל עצמו מרגיש מחוייב לתהליך והוא מוביל אותו מעצמו?

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

 

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

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

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

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

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

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

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

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

נכתב ע"י אורי גינזבורג, ROM Knowledgeware

 

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

 

לקוח מתוך מאמר של גרטנר (http://www.gartner.com)

 

הסבר מפורט:

 

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

  1. פורטלים משווקים כמוצרי OEM יחד עם מערכות חומרה/תוכנה נוספות; 
  2. המריבה הנצחית בין אוהדי פתרונות ה Java לבין השאר (למשל אוהדי .Net).

 

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

 

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

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

    על מנת לממש שיתוף פורטלים כזה, צריך לדעת לשתף את האלמנטים הבאים:

    • מדריך השירותים (Directory)
    • מנגנוני ההרשאות (Security)
    • העדפות המשתמש (Personalization Data)
    • מידע מבני (Metadata)
    • יישומי פורטל (Portlets)

     

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

    פורטל על מינימלי (A Minimalist Uberportal) הינו סוג של פורטל על (Uberportal) אשר משמש כדלת כניסה בלבד לשאר הפורטלים. בפועל הוא מפעיל את הפורטלים הנחותים ממנו בחלון נפרד. כדי שפורטל אכן יהיה פורטל על מינימלי, עליו לממש את האלמנטים הבאים:

    •  מדריך שירותים מאוגד רציונלית (Rationalized directory service).
    • SSO (Single Sign On) – הזדהות לפורטל זה תממש הזדהות לכל שאר הפורטלים ותהיה ההזדהות היחידה במערכת.
    • מימוש העדפות המשתמש ברמת הדפים של פורטל העל (לא נדרש להכיל את ההגדרות שהוגדרו ברמת פורטל העל לפורטלים הנחותים).
    • כניסה לפורטלים תהיה באמצעות קישורים (Hyperlinks) או טאבים (Tabs).
    • עם סגירת החלון בעת סיום הגלישה בפורטל "הנחות" יחזור המשתמש למסך המתאים בפורטל העל.

     

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

     

    תודות: תודה לרנית זקצר על השגת מקורות למידע

Collaborationstorytelling: potent potions for pharmaceutical

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

המאמר הפעם עוסק בתיאור מקרה בו חברות פרמצטיותBristol-Myers Squibb ו - Boehringer Ingelheim Pharmaceuticals משלבות בין גישות לניהול ידע לבין אנשים וטכנולוגיה.

קריאה מהנה.


Knowledge Connections

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

צפייה מהנה.


כנסים קורסים ויתר פורומים בארץ ובעולם.


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

-- חוסה אורטגההרהורים על דון קיחוטה

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



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