תפריט נגישות

ניהול ידע בגופי IT – לעשות יותר בפחות

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

 תקציר

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

מבוא

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

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

והצלחות שהתרחשו ולקחים ותובנות שנרכשו.

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

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

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

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

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

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

נתקלו באותה השאלה, חקרו את הנושא ומצאו את הפתרון.

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

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

האפקטיביות בעבודה ואת הבזבוז הנלווים להעדר ניהול הידע בגופי IT.

 

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

והניסיון הנצבר על ידי העובדים במהלך עבודתם.

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

ידע, המורכבת  מהגדרת תהליכי עבודה מתאימים, הבניית תרבות ארגונית

המעודדת ניהול ושיתוף ידע ומשימוש בטכנולוגיה תומכת. 

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

כ"מכפיל כוח" בפעילות השוטפת.

 

 

 

 

תרשים 1

 

שלושה רבדים לניהול ידע

 

 

 

 

 

 

מדוע לנהל ידע בגופי IT?

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

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

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

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

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

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

מיפוי הידע 

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

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

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

 

תרשים 2 – ישות ידע - מסוג - problem & resolution

 

בתרשים זה אנו רואים כי סוג הידע מסוג - problem & resolution מכיל 8 מאפיינים:

  1. הודעת השגיאה שהתקבלה
  2. "התנהגות" המערכת
  3. גרסה
  4. מודול
  5. סביבת העבודה
  6. קישור לticket רלבנטי במערכת תפעולית כלשהי (מעקב תקלות, ניהול באגים וכו')
  7. הגורם לתקלה
  8. אופן הפתרון

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

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

לא נרחיב על התהליך הספיראלי של הפיכת הידע הסמוי לגלוי, שילובו והפנמתו, אך מומלץ לארגונים להתעמק בו כפי שהוא מתואר בספרם של  [1] Nonaka and Takeuchiבכדי להבין את התהליכים הבסיסיים של זרימת הידע.

 

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

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

 

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

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

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

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

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

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

 תהליכי זרימת הידע

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

בבואנו להגדיר את תהליכי ניהול הידע לגוף IT, אנו בוחנים את זרימת הידע בפרמטרים רבים:

·        מי מקור הידע ומי קהל היעד?

·        מה סוג הידע?

·        לאיזו פעילות מתקשר הידע?

·        אלו מגבלות מופעלות על התהליך?

·        מה הם צמתי הידע?

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

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

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

  1. עובד העושה שימוש בידע שצבר במשימה אחת לשם ביצועה במשימה אחרת – אז יעלו שאלו כמו מידת הרוטיניות של הפעילות, מורכבותה וכדומה.
  2. העברת ידע אופקית מעובד אחד לעובד שני לשם ביצוע משימה דומה– במקרה זה נבחן האם קיים ריחוק גיאוגרפי בין העובדים השונים, האם קיימות מגבלות כאלה ואחרות שעלולות להפריע לזרימת המידע וכדומה.
  3. העברת ידע אנכית בין עובד אחד לשאר העובדים לשם ייעול הטיפול בבעיה/תקלה והקטנת מספר האסקלציות – לדוגמא עובד R&D אשר פתר בעיה שהועברה אליו מעובד בשכבת תמיכה נמוכה יותר (Tier 1, Tier2 וכדומה) יפיץ את הידע בצורה אנכית לעובדים בשכבות השונות.
  4. העברת ידע בין צוות פרויקט אחד לצוותי פרויקט עתידיים בארגון – זהו מקרה מורכב יותר של העברת ידע רב ממדי ובין תחומי. במקרה זה נרצה ללכוד תובנות ולקחים שהופקו כתוצאה מביצוע הפרויקט, אנשי קשר, מומחי ידע ועוד.
  5. ידע של מומחים – מקרים מסוימים מחייבים את הארגון למפות את מומחי הידע (הפורמאליים והבלתי פורמאליים) ולהפוך אותם לנגישים לשאר העובדים באמצעים שונים (פורומים, משובים בצורת one to one וכדומה). לעיתים יוגדרו תהליכי ידע בהם המומחה "ידחוף" ידע בצורה פרו אקטיבית לשאר העובדים.

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

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

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

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

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

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

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

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

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

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

·        הידע שישמר חייב להיות נכון ומדויק כיוון שטעות עלולה לגרום לנזק חמור ללקוחות.

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

·        ההנהלה מעוניינת שפעילויות ניהול הידע יתבססו על עקרונות UGC (user generated content) ותעודדנה השתתפות מקסימאלית של העובדים.

 

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

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

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

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

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

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

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

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

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

מימוש טכנולוגי

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

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

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

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

·        הזנה קלה של structured data ו unstructured data.

·        תמיכה ביצירת טקסונומיות.

·        מנגנון workflow מרובה משתתפים.

·        תמיכה בפורומים.

·        תמיכה ב Blogs

·        ועוד

  התרבות הארגונית

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

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

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

נקבל את הגדרתם של שניים מגדולי החוקרים בתחום-    shaw & perkins[2], אשר מגדירים את המושג למידה ארגונית כיכולתו של ארגון לקבל הארה (insight) מניסיונו העצמי ומניסיונם של אחרים ולשנות את הדרך בה הוא פועל לאור הארה זו. בגופי ה- IT צורך זה, ללמוד מהניסיון העצמי הקולקטיבי לשם ייעול העבודה ושיפור התפוקות, הנו קריטי ואף תנאי להישרדות בשוק התחרותי בו ידע הפך המשאב היקר ביותר.

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

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

מחויבות ההנהלה

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

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

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

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

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

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

סיכום

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

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

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

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

כותב המאמר: עידו נמיר, שותף
Deloitte Knowledge management

ליצירת קשר: inamir@deloitte.co.il

  סימוכין: 

 

1. The Knowledge Creating Company, Ikujiro Nonaka and Hirotaka Takeuchi. New York:   Oxford University Press, 1995.

2. Common Knowledge – How companies thrive by sharing what they know, Nancy M. Dixon. Boston: Harvard business school press, 2000.

3. Shaw, R. & Perkins, D. (1992). ‘Teaching Organizations to Learn’, In D. Nadler (ed.),Organizational Architecture, 175-192