הגדרת תהליך היא ארגון כל הידע הארגוני בצורה הגיונית, תבניתית, נוחה לשימוש, ברת חזרה ונוחה להטמעה. למרות שרובנו חכמים ויצירתיים חלק ניכר מהפעולות שלנו חוזרות על עצמן. כאשר אנו רוצים לעשות פעילות חדשה כביכול אנו מחפשים בזיכרוננו מתי עשינו משהו דומה, לאחר מיכן מחפשים בתיקיות, שואלים אנשים ואז לוקחים את הבסיס הקודם, משנים ויוצרים משהו מתאים לצורך הרגעי, וחוזר חלילה.
דמיינו שכל התהליך שלכם מוגדר היטב, סדר הפעילויות ברור, וכל נכסי התהליך שמסייעים לכם – נגישים לכם. כף, נכון? לא רק שנחסך לכם זמן אלא שאיכות העבודה משתפרת: פעם אחת בשל שימוש בתבניות שכוללות את כל הידע הנדרש לעבודה איכותית ופעם שנייה בשל חיסכון זמן שהולך לבלי שוב על חיפושים והמצאת הגלגל מחדש.
מאמר זה מתמקד בניהול ניהול נכסי התהליך הארגוני; הכוונה לבניית כל התשתיות הארגוניות הנדרשות להגדרה ותיאור של התהליכים הסטנדרטים בארגון. התשתית כוללת: נהלים, מדריכים, הנחיות, תבניות, כלים תומכי תהליך, ועוד. הנושא נשמע לחלקנו מאד לא אטרקטיבי, ואוזנינו נוטות להיסתם כשהנושא עולה. כמו כל נושא תשתיתי, למשל כבישים ומדרכות, מה קורה היעדר תשתיות? איננו יכולים לטפל בכל הנושאים המעניינים המסתמכים על תשתיות אלה. נהיה עסוקים כל היום בפילוס דרכנו בסבך הג'ונגל הארגוני.
ניהול שיטתי של הנכסים הארגוניים מהווה את הבסיס לניהול ידע, מאפשר סדר וחוסך בזמן ואנרגיה, המופנים לאפיקי יצירה במקום חיפושים של מסמכים, ויצירת תהליכים יש מאין כל פעם מחדש.
נראה לכם שלבנות תשתית לניהול תהליכים וידע זאת משימה מתישה ו/או גוזלת זמן רב? תיעזרו ביועצים שזאת המומחיות שלהם.
מה איתכם? איך אצלכם בנושא זה? מחכה לשמוע מיכם באחת הרשתות שקישורן להלן
Photo by kira schwarz from Pexels
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
כולנו רוצים להיות משופרים, אך להניע את השיפור דורש מאמץ.
פעמים רבות, ארגונים מתחילים תהליכי שיפור כתוצאה מדרישת לקוחות שרוצים להבטיח את יכולות הספקים שלהם. בתחום מערכות מידע שיפור יכול להגיע מעמידה בתקנים ורגולציה.
אנו נשאלים –
התבקשנו לעמוד בדרישות SOC2– מה עלינו לעשות?
אם יש לנו כבר תקן 27001 ISO? – האם נחסך מאיתנו המאמץ?
המאמר שלהלן מסביר מהו SOC2 לעומת 27001 ISO. נדרש הסבר נוסף? מוזמנים לפנות אלינו ונרחיב.
כוונת מבדקי 27001 ISO ו-SOC2 היא דומה: לעזור לארגונים להגן על המידע והנתונים בתחום אחריותם.
שני סוגי המבדקים, 27001 ISO וגם SOC2 מסייעים לארגון לתת ללקוחות שלהם ביטחון שהמידע והנתונים הרגישים שלהם מוגנים בהתאם לתשומת הלב הנדרשת. מבדקים אלה מושכים לקוחות חדשים שדורשים אותם כדרישות סף, שומרים על הלקוחות הקיימים ומונעים מהארגון לקבל קנסות כתוצאה מאי ציות להוראות.
הסוגייה שמאמר זה דן בה הינה מה השוני בין שני סוגי מבדקים אלה ומה הקריטריונים לפיהם ארגון מחליט באיזה מבדק לבחור?
מבדק SOC2 מעריך את הבקרות הפנימיות, המדיניות והתהליכים. מדובר בבקרות שקשורות ישירות לאבטחה מידע, זמינות, עיבוד, שלמות, סודיות ופרטיות של המידע המנוהל (נתונים) בארגון.
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת פעם בחודש מאמר קצר או טיפ בנושאים הקשורים לאבטחת מידע, אבטחת הפרטיות, מבדקי חדירה, המשכיות עסקית, רגולציות בתחום ועוד. קישור להצטרפות – כאן |
מבדק SOC2 מגדיר חמש קטגוריות שמעידות על יכולת הארגון לשמור את בטיחות ותקינות המידע:
תוצאת מבדק SOC2 הוא דו"ח המאמת את מחויבות הארגון לספק שירותים מאובטחים ואיכותיים ללקוחות.
תאימות זו יכולה להיות יתרון תחרותי משמעותי יחסית למתחרים.
תקן ISO 27001 הוא תקן בינלאומי המקובל בעולם לניהול מערכת ניהול אבטחת המידע בארגון. התקן מוודא שבארגון קיימים ומוטמעים מסמכים מדיניות ותהליכים (כגון ניהול סיכונים) לשמירה על סודיות, שלמות וזמינות המידע.
התקן בנוי במבנה הסטנדרטי של תקני ISO. אישור שהארגון אכן עומד בדרישות התקן ניתן על ידי גוף אקרדיטציה מוסמך. תעודת הסמכה 27001 ISO יכולה לתת יתרון תחרותי כיוון שהדבר מעיד על קיום תהליך מוטמע לניהול מערכת אבטחת מידע.
תהליך הסמכה לתקן 27001 ISO נעשה ברמת ארגון. מעיד על כך שלארגון יש נהלי איכות ואבטחת מידע לניהול מערכת אבטחת המידע שלו.
תהליך הסמכה לתקן SOC2 נעשה ברמת מוצר. מעיד על כך שהמוצר עומד בדרישות אבטחת המידע שהארגון קבע לעצמו. הלקוח הפוטנציאלי מעוניין לדעת שהמוצר שהוא רוכש עומד בדרישות אבטחת המידע בלי קשר לרמת אבטחת המידע והתקנים שיש לארגון. בהחלט ייתכן שארגון יחזור על התהליך פעם נוספת כאשר יש לו מוצרים מגוונים.
הבדל נוסף הוא במיקוד. בעוד שאפשר לקבל תקן 27001 ISO גם אם נהלי אבטחת המידע ממומשים חלקית, אך הארגון מתחייב להטמיעם במהלך השנה, תקן SOC2 מבקש לראות הטמעה לפחות חצי שנה אחורה. כלומר: נדרש להראות עדויות על יישום הפרקטיקות הנדרשות.
מבדק 27001 ISO בודק את מערכת ניהול אבטחת מידע בהיבטי שמירה על סודיות, שלמות וזמינות. בסיומו ניתנת לארגון תעודת הסמכה בינלאומית המוכרת בכל העולם. התעודה ניתנת על ידי סוקר מטעם ארגון מסמיך מוכר לאחר שביצוע בארגון מבדק בלתי תלוי.
מבדק SOC2 מסתיים בדו"ח אשר מסכם את הבקרות הפנימיות שנבדקו, מסמכי מדיניות ונהלים המתייחסים לחמש הקטגוריות שפורטו לעיל אך דו"ח זה אינו הסמכה ואין לו הכרה בינלאומית.
בעוד שמבדק ISO 27001 מתרכז בעיקר בבדיקת מערך מבנה המערכת לניהול איכות אבטחת המידע בחברה (IMQS) וכי כלל הנהלים והתהליכים הנדרשים קיימים, מבדק SOC2 יורד לעומק המערכת הנבדקת, החל מבדיקת תהליכי הפיתוח SDLC ועד לבדיקת סוגי ההתראות הקיימות במערכת.
לקוחות שמיקומם בארה"ב דורשים ציות ל-SOC2. בדרך כלל, ארגונים להם לקוחות בארץ ובחו"ל יעדיפו 27001 ISO בשל ההכרה הבינלאומית של התקן.
ולמרות זאת, חברה אשר חשוב לה להוכיח את אמינות הנתונים במערכת המידע ללא כל צל של ספק, תיגש לשני המבדקים.
למרות כל הנכתב לעיל, ארגונים בדרך כלל מחליטים איזה מבדק לעבור בהתאם לסוגי הלקוחות שלהם, מיקומם הגיאוגרפי, עלויות וההזדמנות העסקית בעקבות המהלך.
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת 1-2 פעמים בחודש מאמר קצר או טיפ בנושאים הקשורים לאבטחת מידע, אבטחת הפרטיות, מבדקי חדירה, המשכיות עסקית, רגולציות בתחום ועוד. קישור להצטרפות – כאן |
אחד האתגרים לעשות שינוי הוא להתמיד בתהליך העבודה החדש, אותו תהליך שהחלטנו שכך אנו רוצים לעבוד, לאחר שהתהליך שבו עבדנו עד כה לא היה מיטבי. מניסיון העבר אנו יודעים ששינויים במקרים רבים נזנחים לאחר תקופת התלהבות התחלתית ואנו חוזרים להרגלים הישנים והמוכרים למרות שהם לא מיטביים.
איך נעבור לתקופה של עבודה רציפה לפי התהליכים החדשים שהטמענו כדי לעמוד ביעדים ובמשימות שלנו?
אחד הגורמים המקשים על הצלחה הוא הקושי לשמור על המשכיות בשיטת העבודה המיטבה שתפרנו לעצמנו על פי מידותינו. אנו מטמיעים תהליך חדש, מחליטים לעבוד לפיו ולאחר זמן מוצאים שהפסקנו להטמיע את התהליך החדש וחזרנו להרגלים הישנים שלנו.
ארגונים קובעים מטרות ויעדים, קובעים להטמיע וליישם תהליכים שעוזרים להגשים את המטרות והיעדים, עובדים במרץ ואז.. קורה אירוע שדורש השקעת מאמץ בנושא מסוים, בעקבותיו אנו מוצאים את עצמינו עושים הנחות בדרך שקבענו שנלך בה עד יעבור זעם. אחרי תקופה אנו רואים שזנחנו את התהליכים המיטביים שהטמענו כדי לעמוד במטרות שלנו.
ההפסקה הזו מאכזבת.
הפסקה היא ההיפך מהצלחה. הצלחה מגיעה מעבודה שיטתית ברצף.
מדוע אנו זונחים פעם אחר פעם את שיטת העבודה המיטבית שקבענו שנלך בה? מדוע כאשר יש קושי אנו בוחרים לחזור לשיטות העבודה הישנות שאנו רגילים אליהן? מדוע שינוי תהליך נתפס כמאמץ גם אם שמירה עליו תגרום לעבודה טובה יותר ומאומצת פחות? מדוע עבודה חוזרת ותיקון תקלות נחשב לעבודה "רגילה"? האם התרגלנו לכך שכיבוי שריפות הוא מציאות שאי אפשר להימנע ממנה?
להלן הצעה לשלוש שאלות שתשובה חיובית עליהן תסייע לשמור על רצף והמשכיות בשיטה המיטבית החדשה. כדי שהתשובה תיספר כ"כן", עליה לשקף את התפיסה של המנהלים והעובדים הנוגעים בדבר, ולא רק תשובה ממנהל בכיר או סוכן שינוי.
האם התהליך החדש מתרכז בעיקר או בטפל? האם הוא "מתיישר" עם הערכים של הארגון?
אם השינוי לא נתפס כמהותי יהיה קשה לשמור עליו לאורך זמן.
דוגמה: חברה שנדרשת ליישם תקן בעקבות דרישה רגולטורית. החברה מתאימה את תהליכי העבודה שלה לפי דרישות התקן. המאמץ הזה נעשה מתוך רצון חיצוני של מוסד ממשלתי כלשהו, כאשר הארגון לא מרגיש שהוא נתרם מכך. השינוי לא נתפס כמהותי וחשוב ונזנח במהרה.
כיצד מתגברים על כך?
באמצעות "מכירה פנימית" שמראה את היתרונות בעבודה שיטתית וגיוס בעלי העניין למטרה זו. לא השתכנעו – לא יהיה שינוי בטווח הארוך, גם אם תוצאה חיצונית מושגת.
האם העובדים / מנהלים מבינים ורוצים לעבוד לפי התהליך המשופר? נכון שיש הנהלה שמחליטה על השינוי, אך ללא חיבור כל בעלי העניין לשינוי, כך שהם ירצו אותו, לא תהיה המשכיות. שינוי (כמו חומוס) עושים באהבה או לא עושים בכלל.
האם המטרות והיעדים שנקבעו הם אפשריים? עוד לא נולד התהליך שיגרום למטרה פנטזיונרית להתגשם.
בעברי, הייתי בארגון שיזם פרויקט "10X" תוך שנה. מטרת התכנית לעשות פי 10 תוך שנה: קיצור לו"ז פי 10 או הורדת עלויות פי 10 וכדומה. במקרים רבים – 0.2X או 2X בשנה זו מטרה מספיק שאפתנית. מטרות שנקבעות בלי הכרת היכולת העכשווית דינן להיעזב. אנרגיה שמושקעת בהשגת מטרה בלתי אפשרית היא אנרגיה מבוזבזת.
בסוגריים אציין שהנטייה לקבוע מטרות בלתי אפשריות יושבת על הרצון שלנו להיות מושלמים ושונים לגמרי ממה שקורה עכשיו.
כדי לעשות את השינוי אפשרי, נבחר מטרות ברות יישום, נגדיר תהליך שמסייע להשגת המטרות בצורה שיטתית ונעשה מכירה פנימית בארגון כדי לגייס את כל הנוגעים בדבר. נבחר במומחים פנימיים או חיצוניים כדי שיסיעו לנו לעשות את השינוי ונצא לדרך.
בהצלחה!
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
השראה למאמר – משיעור ימימה של עידית שלו
Photo by Kulbir from Pexels
פונים אלינו מנהלי מערכות מידע עם בקשות עזרה לנושא SOC2.
הדרישה נופלת עליהם כרעם ביום בהיר כתוצאה מפניית לקוח שדורש הוכחה לעמידתם בדרישות SOC2. מדובר במערכת דרישות לא פשוטות, שעל מנהל המידע לממש, כאשר גם בלי הדרישה החדשה, היומן שלו עמוס לעייפה במטלות.
שאלה נפוצה היא: אם נעבור תהליך הסמכה לתקן 27001 ISO, או יש לנו כבר תקן 27001 ISO, האם הדבר יכול להחליף את הדרישה ל-SOC2?
לפני שנדבר על "איך", נתחיל מ"למה". מדוע לקוחותינו מבקשים שנעמוד בדרישות SOC2 ומדוע כדאי לנו לממש את דרישות SOC2 ?
נזכור שהדרישה לעמוד בדרישות SOC2 חל רק על ארגונים שנותנים שירותי ענן.
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת 1-2 פעמים בחודש מאמר קצר או טיפ בנושאים הקשורים לאבטחת מידע, אבטחת הפרטיות, מבדקי חדירה, המשכיות עסקית, רגולציות בתחום ועוד. קישור להצטרפות – כאן |
הלקוחות רוצים רמת וודאות גבוהה ביכולות של הספקים שלהם לשמור על סודיות, תקינות המידע וזמינותו ברגע האמת, לוודא שלספקים יש מערכת בקרה פנימית אפקטיבית שמוודאות את תקינות המערכות והנתונים.
SOC2 מספק רשימה לא סודית של בקרות שהארגון נדרש להראות שהוא מפעיל. הנחת העבודה היא שביצוע שוטף של הבקרות הפנימיות ברשימה מבטיח את יעילות הביצוע של אבטחת המידע, שלמותו, זמינותו ותקינותו. זהו בעצם תהליך של ניהול סיכונים, כאשר כל סעיף ברשימה הוא סיכון תהליכי, עסקי או תפעולי. ההוכחה של הארגון לכך שהוא מתמודד עם כל סעיף וסעיף ברשימה מהווה התמודדות עם הסיכון והורדת ההסתברות לנזק שעלול להיגרם מאי הפעלה של אותן בקרות.
ארגונים נדרשים להראות הוכחה של קיום מבדק מגוף הסמכה / התעדה חיצוני בלתי תלוי. מבדק SOC2 מאפשר לארגון להראות דו"ח כזה. יתרה מכך, הדבר נותן לארגון ייתרון תחרותי מול ארגונים דומים שאין להם יכולת להראות עמידה בדרישות SOC2.
הידיעה שלארגון מערכת בקרה יעילה ששומרת על אבטחת המידע ותקינות הנתונים בפני כל מיני גורמים עוינים או טעויות אנוש מקנה שקט וביטחון בחוסן מערכת המידע ותקינות הנתונים.
תהליך הסמכה לתקן 27001 ISO נעשה ברמת ארגון. מעיד על כך שלארגון יש נהלי איכות ואבטחת מידע לניהול מערכת אבטחת המידע שלו.
תהליך הסמכה לתקן SOC2 נעשה ברמת מוצר. מעיד על כך שהמוצר עומד בדרישות אבטחת המידע שהארגון קבע לעצמו. הלקוח הפוטנציאלי מעוניין לדעת שהמוצר שהוא רוכש עומד בדרישות אבטחת המידע בלי קשר לרמת אבטחת המידע והתקנים שיש לארגון. בהחלט ייתכן שארגון יחזור על התהליך פעם נוספת כאשר יש לו מוצרים מגוונים.
הבדל נוסף הוא במיקוד. בעוד שאפשר לקבל תקן 27001 ISO גם אם נהלי אבטחת המידע ממומשים חלקית, אך הארגון מתחייב להטמיעם במהלך השנה, תקן SOC2 מבקש לראות הטמעה לפחות חצי שנה אחורה. כלומר: נדרש להראות עדויות על יישום הפרקטיקות הנדרשות.
מבדק SOC2 מעריך את הבקרות הפנימיות, המדיניות והתהליכים. מדובר בבקרות שקשורות ישירות לאבטחה מידע, זמינות, עיבוד, שלמות, סודיות ופרטיות של המידע המנוהל (נתונים) בארגון.
מבדק SOC2 מגדיר חמש קטגוריות שמעידות על יכולת הארגון לשמור את בטיחות ותקינות המידע:
בעידן הדיגיטלי שאנו חיים בו, חובה על ארגונים נותני שירות שיש בידם גישה לנתונים של אנשים, לשמור על חשיפת המידע לגורמים בלתי מורשים או שימוש במידע לשימושים בלתי מורשים. כמו כן הארגון נדרש לוודא את תקינות מערכת הבקרה שלו על בטיחות ותקינות המידע שבאחריותו. יכולת עמידה בדרישות SOC2 מוכיחה שהארגון מחויב לנושא ועומד בדרישות.
Photo by Markus Spiske from Pexels
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת 1-2 פעמים בחודש מאמר קצר או טיפ בנושאים הקשורים לאבטחת מידע, אבטחת הפרטיות, מבדקי חדירה, המשכיות עסקית, רגולציות בתחום ועוד. קישור להצטרפות – כאן |
לקראת ראש השנה, מאמר שונה שמטרתו לחדש את ההסתכלות והגישה לגבי הצורך בראייה תהליכית עמוקה בארגונים.
המאמר דן במספר דפוסי חשיבה מוטעים שמקשים על ארגונים להיכנס לתהליכי שיפור של תהליכי העבודה שלהם.
האם אתם מזהים את הדפוסים שלהלן?
מקווה שהמאמר יעורר בכם רצון לשנות בשנה החדשה שתבוא עלינו לטובה.
הרבה ארגונים מתנהלים בצורה סבירה פחות או יותר על סמך תורה שבעל פה. כיוון שהזמן קצר והמלאכה מרובה לא עולה הצורך לעצור לרגע ולעשות מיפוי של תהליכי העבודה, להסכים על התהליך הארגוני ולהטמיע אותו בארגון.
מדוע חשוב הדבר?
למרות שיש הרגשה שכולנו יודעים ומסכימים על התהליך, יש כתמי עיוורן .כלומר: ראייה שונה כיצד צריך להתנהל במחלקות שונות בארגון, בין צוותים ואפילו בין אנשים באותו הצוות. הראייה השונה הזו היא מקור לחיכוכים ואפילו לעימותים גלויים וסמויים בין עובדים ומנהלים שמוכנים להילחם עד חורמה בצדקת דרכם.
תוך כדי מיפוי תהליכי העבודה וכתיבת הנהלים נוצרות הבנות חדשות. ממשקי עבודה בין מחלקות מוגדרים, אחריות וסמכות של בעלי תפקידים מוגדרים, נקודות בקרה לבדיקת איכות התהליך בדרך מתווספות ועוד. התורה שבעל פה נכתבת ומוגדרת. כאשר התהליך כתוב, ניתן לדון בו ולהגיע להסכמות משותפות בטרם מתחילה ההטמעה.
כל שינוי ארגוני מתחיל מהגדרת הבעיה. עצם הזיהוי של הדבר החסר הוא כבר התקדמות גדולה לעבר הפתרון. תצפיותיי בארגונים מראות שיש נטייה למנהלים להאמין שהמשברים הם דבר מזדמן ויש להם יכולות לפתור אותם. אכן, כשיש בעיה – מתגייסים למציאת הפתרון..עד למשבר הבא.
הרבה קלקולים קורים מהיעדר תהליכים מוגדרים ותפורים לארגון. כמובן שתהליך מוגדר לא מונע קלקולים, אך בהחלט עוזר להפחית את כמותם.
תהליכי הפקת לקחים עוזרים לזהות בעיות, אך במקרים רבים תהליך הפקת הלקחים מסתיים ברשימות של עשה/אל תעשה להבא. כלומר: תמשיכו לעשות את התהליכים שגרמו להצלחה ותפסיקו לעשות את התהליכים שהביאו לתקלות ועיכובים. אבל – אי הטמעת ההבנות בתוך התהליך המוגדר גורם להבנות להתפוגג.
יש נטייה למנהלים בארגונים לחשוב שהארגון שלהם הוא מיוחד במינו. יש להם מוצר או שירות ייחודי, האווירה בצוות ואיכות האנשים שלהם מיוחדים מאד, ולכן האתגרים שלהם מאד מיוחדים.
במקרה הטוב – מחשבה שכזו גורמת להם לחפש את הפתרון אצל אנשים או יועצים כמוהם, או שהם בעלי ניסיון בשטח הצר מאד שלהם.
במקרה הפחות טוב – המנהלים כל כך בטוחים במיוחדות שלהם שאין להם צורך להשקיע בהגדרת תהליכי העבודה שלהם, כיוון שהפתרונות הסטנדרטיים לא יעבדו בסוג הארגון שלהם.
ספוילר– האתגרים שארגונים נתקלים בהם הם מאד דומים, כיוון שבארגונים עובדים אנשים ולכולנו דפוסי חשיבה מאד דומים למרות שכל אחד מאיתנו חושב שיש לו חשיבה שונה. לכן תהליך השיפור שמסתמך על כלים, שיטות וניסיון יכול להועיל גם לארגונים המיוחדים.
לוותיקים שביננו – יש זיכרון שנהלים דורשים תיעוד בקלסרים עם הרבה דפים שאיש לא קורא.
מה שהיה הוא בכלל לא סימן לבאות.
אנו עובדים עם הלקוחות שלנו בגישה המגדירה את התהליך בצורה מתומצתת ובהירה: טבלה של מיפוי תהליך עם הפניות לתבניות תומכות. הגדרת תהליך מתומצתת עוזרת להבנה והטמעה מהירה.
כאשר קורית תקלה, יש נטייה להעריך ולתגמל את הצוות שעובד ימים ולילות כדי לפתור את הבעיה. כיבוי שריפות הוא תהליך שמסית משאבים ואנרגיה מהיצירה לפתרון הבעיה. אנו לא רואים ולא שומעים את המנהלים שמשקיעים בתהליכים טובים ומונעים חלק מהתקלות.
התמודדות עם האתגר הזה יכולה להיות באמצעות זיהוי הנזק שנגרם לכיבוי השריפות והוכחה של שיפור בתוצאות לאחר הטמעת התהליך המשופר.
המציאות המצערת היא שלמרות הנאמר, תשומת הלב הולכת למכבי השריפות ולא לאלה שמונעים אותם.
ישנם מקרים בהם אנו מטמיעים שיפורים ובכל זאת התקלה חוזרת. מחשבה מוטעית היא להניח שרצינו לשנות אבל זה לא עובד. החשיבה הזאת של הכול או לא כלום היא חשיבה מוטעית. כדאי לשים לב לשיפור היחסי. צעד צעד. ככל שעובר הזמן השיפור הולך ומעמיק.
מה אתם אומרים ? נתקלים בדפוסים האלה? משלימים עימם או מנסים לשנות?
במקרים רבים, כדי לעשות שינוי כדאי שמישהו חיצוני יאיר את נקודות העיוורון שלנו. אדם חיצוני, כמו יועץ או מנהל / עובד במיקור חוץ יכול לסייע עם מומחיות וידע רחב אותו רכש מהתבוננות בארגונים אחרים. "אורח לרגע רואה כל פגע".
מחכה למשוב מיכם
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
==
ההשראה לכותרת המאמר הגיעה מהרצאה ששמעתי מעידית שלו המלמדת ימימה.
רוב סוכני השינוי, מתוך הארגון או יועצים חיצוניים, מתכננים פרויקט שינוי, תוך מתן תשומת הלב ל"שילוש הקדוש" של כל פרויקט באשר הוא: לו"ז, תקציב ותכולה.
מדוע זה קורה? התשובה ברורה, הצלחה או כישלון של כל פרויקט נמדדת לפי מידת העמידה בפרמטרים אלה.
אחד המרכיבים החסרים במשולש, הוא ניהול התקשורת בפרויקט השינוי.
נושא ניהול התקשורת נלקח כדבר הברור מאליו. בדרך כלל, פרויקט שינוי מתחיל, מנוהל ומסתיים בלי שנושא תכנון וניהול התקשורת מקבל את תשומת הלב הראויה לו.
מתי נזכרים בנושא התקשורת? כאשר יש כשלים וחוסר הבנות הגורמים לכך שבעלי עניין שונים מפעילים כוחות בכיוונים מנוגדים, או שצוות הפרויקט עובד בדיסהרמוניה, או ש"סתם" קורות תקלות שהיו יכולות להימנע אם רמת התקשורת בפרויקט השינוי הייתה טובה.
התעלמות מנושא ניהול התקשורת היא אחת הטעויות הגדולות ביותר. תכנון ניהול התקשורת בפרויקט השינוי יכול לחסוך זמן רב המושקע אחר כך במהלך הפרויקט בכיבוי שריפות, שיחות הרגעה ומוטיבציה, ומיילים נזעמים הנשלחים מבעלי העניין בפרויקט למנהלים בכירים בארגון בתקווה שאלה יניעו את העגלה השוקעת בבוץ.
ניהול תקשורת כולל את כל התהליכים הקשורים ביצירה, איסוף, הפצה, שמירה, אחזור והשמדה של מידע הקשור בפרויקט, בזמן ובמידה הנכונה. רוב זמנם של מנהלי הפרויקטים מוקדש לתקשורת עם חברי הצוות בפרויקט ושאר בעלי העניין בפרויקט. האתגר הוא להבין את הצרכים והציפיות של כל בעלי העניין, ולתקשר עימם, גם במידה וציפיותיהם לא מושגות בחלקן או במלואן. בעלי עניין שחשים שדברם לא נשמע יכולים להפריע לזרימה החלקה של הפרויקט, בכל האמצעים העומדים לרשותם. לא תמיד ההפרעה תהיה ברורה וקולנית. הפרעה יכולה להתבטא גם באדישות ואי-הושטת יד לעזרה, או עיסוק בנושאים אחרים במקום לתת כתף ולהתגייס למשימות הנדרשות בפרויקט.
טעות בזיהוי כל בעלי העניין בפרויקט אשר יכולים להשפיע על מהלך הפרויקט או להיות מושפעים מתוצאות הפרויקט. הדגש כאן הוא על המילה כל. מנהל פרויקט יכול לחשוב שהוא זיהה את כל בעלי העניין, אך בפועל לשכוח אחד או יותר מבעלי העניין. אותו בעל עניין שנשכח, עלול לעשות צרות ולהפריע בהמשך. לאחר זיהוי כל בעלי העניין נדרש להבין ולתעד את מידת העניין, המעורבות וההשפעה שיש להם על הצלחת הפרויקט.
לאחר שזיהינו והבנו את צרכי המידע ורמת העדכון של כל בעל עניין בפרויקט, עלינו להגדיר את תוכנית התקשורת ומי יהיה שותף בה. מי ישתתף בישיבה, ומי יקבל דוחות. טעויות בתכנון התקשורת יכולות לגרום לאי הכללת בעל עניין מסוים בתהליכים מסוימים, או בהכללת אנשים מיותרים בתהליכים אחרים. עודף השתתפות של אנשים לא רלוונטיים מסרבלת ומאיטה את ההתקדמות ועלולה אף להפריע במילוי הצרכים של בעלי העניין הרלוונטיים.
כמו בכל נושא אחר בניהול פרויקטים, אפשר לתכנן את ניהול התקשורת בפרויקט, לקבל את הסכמת כל בעלי העניין לתוכנית, ובמהלך הפרויקט – לא לעבוד לפי התכנון, ולשכוח לשתף את בעלי העניין בפעילויות הרלוונטיות או להוסיף אנשים מיותרים לתהליכים.
במהלך הפרויקט, צצות בעיות ונושאים לטיפול הקשורים לבעלי עניין מסוימים. אי שיתוף בעלי העניין בזמן ומתן מענה הולם לאתגרים, עלול לגרום להפרעות לפרויקט.
לא דיווחנו, לא עשינו! מנהל פרויקט שמשאיר את בעלי העניין בעלטה, פוגע, בכך שצוות הפרויקט ו/או בעלי העניין עלולים לנקוט בפעולות מזיקות כתוצאה מהנחות שגויות על מצב הפרויקט.
דיווח על מצב הפרויקט כולל שליחת סיכומי ישיבות, איסוף מידע ודיווח על ביצוע הפרויקט, בהתאם לתוכנית או דיווח על סטיות מהתוכנית. דיווחים של הפרויקט כוללים גם מדדים ותחזיות.
עושים כל מה שכתוב למעלה אבל להיפך.
מה דעתכם ? חושבים ששכחתי משהו ?
אשמח שתחלקו עם הקוראים האחרים את התובנות והמחשבות שלכם באחת הרשתות החברתיות שקישורן להלן.
תודה
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
Photo by Tim Gouw from Pexels
מכירים את התופעה שסוכן שינוי, פנימי או חיצוני, עם כוונות טובות, מנסה ליזום שיפור בתהליכי עבודה ו/או בכלים ומתקשה לשכנע בנחיצות מיידית של תהליך השינוי?
במקרים רבים ההנהלה מסכימה עקרונית בנחיצות השינוי, אך יש לה הרגשה שמדובר ב-ירידה לצורך עלייה.
כלומר: אמונה שתהליך השינוי ידרוש האטה זמנית ו/או השקעת משאבים וכרגע זה לא הזמן. מעדיפים לחכות לאירוע כלשהו בזמן, כמו שחרור קרוב של מוצר חדש או סיום טיפול במשבר כלשהו.
יש הרגשה שמה שהיה הוא שיהיה. אנו סומכים על עצמינו שכמו שהתמודדנו עד היום נסחוב עוד קצת ונדחה את השינוי. בקיצור, רוצים אבל לא עכשיו.
נכון, צדקתם, "אחר כך" לא מגיע.
אחרי שחרור המוצר צריך לטפל בנושאים רבים הקשורים לשחרור ובמקביל כבר עובדים על המוצר / גרסה חדשים, עם לו"ז צפוף ומשאבים חסרים, או: המשבר הזמני נפתר, אך נולדו במקומו משברים חדשים.
מסתבר שהתירוץ לא להשתפר עכשיו בגלל הפחד מהירידה שלפני העלייה, עלול לגרום לטוויסט בעלילה: ירידה עוד יותר גדולה. תהליכי עבודה לא מדוייקים, או שינויים שנדחים – יכולים להביא לתוצאות הרסניות. כתוצאה מכך, הירידה היותר גדולה גורמת לארגון להתעשת. למה לחכות לחבלות?
רוצים דוגמה לכך (הפרטים שמורים במערכת) ? להלן דוגמה אחת מיני רבות.
אחד מלקחותינו התמהמה זמן רב עם ההחלטה האם להטמיע את ההמלצות שלנו בעקבות סקר פערים טכנולוגיים ומבדק חדירה תשתיתי חיצוני שבצענו עבורו כדי לשפר את עמידות מערכות המידע שלו בפני האקרים מזיקים. חיכו וחיכו עד ש.. היה להם אירוע סייבר טראומתי. הם נדרשו לבצע בקרת נזקים מיידית ולאחר התאוששות החלו ליישם באיחור את ההמלצות שלנו באופן בהול.
בסוף האירוע, הירידה (אירוע סייבר) הביאה לעלייה (חיזוק מערכות ההגנה על מערכת אבטחת המידע של הארגון), בהשקעה גדולה הרבה יותר ובהפסד שעות עבודה יקרות עקב השבתה זמנית של מערכת לניהול אבטחת המידע שלהם. נכון שלא לכך כיוונו שחשבו על ירידה לצורך עלייה.
עוד דוגמה? את הדוגמה שלהן כולנו מכירים ..
עבודה לפי תהליכים לא מדויקים גורמת במקרים רבים לעבודה חוזרת. משקיעים זמן ומאמץ בתיקונים, או הנדסה הפוכה (Reverse Engineering): מתקנים את הדרישות בסוף הדרך במקום בראשיתה, ובמקום לעבור למשימה הבאה מתחפרים בסיום המשימה הקודמת.
הפחד משינוי גורם להאטה גדולה יותר.
תצפיותיי בארגונים בשנים האחרונות לימדו אותי שיש טוויסט אחר לגמרי בעלילה, וקוראים לו – עלייה לצורך ירידה.
מה? שמעתם טוב.
חיזוק והטמעה של תהליכי עבודה מיטביים מכין אותנו לתקלות שיגיעו עם כלים טובים יותר להתמודד עימם.
תהליכי עבודה מותאמים לארגון יוצרים תשתית טובה ואיתנה והרגלי עבודה משותפים שמסייעים להתמודד עם שינויים בלתי מתוכננים שמקטינים עבודה חוזרת ומסייעים לעמידה במטרות שהארגון קבע לעצמו.
מהו הזמן הטוב ביותר להתאים את תהליכי העבודה שלנו לאתגרים ולמציאות המשתנה?
טוב ששאלתם. התשובה היא – ע כ ש י ו!
כלומר העלייה, במובן הארגוני הכוונה להשקעה בתהליכי שיפור, היא תכלית הירידה. כלומר, העלייה (השקעה בתשתיות תהליכיות) נותנת לנו כלים כדי שבעת ירידה נוכל להתמודד עם המצב הלא רצוי בצורה טובה.
מה ניסיונכם מלמד אתכם?
ירידה לצורך עליה? עליה לצורך ירידה? הימנעות שגורמת לירידה גדולה יותר?
מחכה לשמוע מניסיונכם.
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
Photo by Tima Miroshnichenko from Pexels
איך נראות תמונות במאמרים שנוגעים לאירועי סייבר? תמונה בשחור לבן המראה דמות לא ברורה עם כובע קפוצון ומשקפי שמש כהים. בחיים האמיתיים מומחי סייבר נראים כאחד האדם, למרות פוטנציאל הפגיעה הגבוה שלהם.
ארגונים מטמיעים תקן ISO 27001 כדי לנהל מערכות אבטחת מידע וסייבר (ISMS). תקן 27001 ISO דורש מארגונים להגן על נקודות התורפה במערכות ותשתיות הארגון מפני פגיעה על ידי גורמים עוינים. ראו בתחתית המאמר את הדרישה שמוגדרת ב Annex A.8.8),
אמצעי מעולה לבדיקת פרצות במערכת המידע הוא סקר סיכונים תשתיתי ו/או אפליקטיבי ומבדק חדירה. למרות זאת חלק מהארגונים דוחים אמצעי זה לשלב מאוחר יותר, ולפעמים נמנעים מלבצע מבדק חדירה.
האם זאת חובה לבצע מבדק חדירה לארגונים שמטמיעים תקן 27001 ISO?
מאמר זה מתמקד בקשר שבין תקן 27001 ISO ומבדק חדירה.
ארגון עם פונקציונליות סטנדרטית ו/או ארכיטקטורת מידע בסיסית יכול להסתפק בסקר סיכונים. כאשר לארגון יש מערכות מורכבות יותריידרש מבדק חדירה לאהטחת בטיחות מערכות אבטחת המידע. , דוגמה למערכת מורכבת: קיום אפליקציות Web.
בתחתית המאמר ציטוט מ-.Annex A.8.8.
דרישת התקן היא שחולשות ופגיעות טכניות של מערכות המידע ותשתיות ייחקרו תקופתית, ייעשה ניתוח של פגיעות הארגון, ויינקטו האמצעים כדי להפחית את הסיכון מנקודות התורפה שזוהו.
מבדק חדירה עונה לדרישות אלה בכך שהוא מספק ניתוח סיכונים ופערים באמצעות התקפה זדונית מדומה. שירות זה מבוצע על ידי מקצועני סייבר המציעים שירותי בדיקת חדירה המזהה את החולשות של מערכת המידע. דו"ח פערים הניתן בסיום מבדק החדירה מאפשר לארגון להכין תכנית פעולה לסגירת הממצאים.
מבדק חדירה / Penetration Test / PT / מבדק חוסן הוא מבדק שמדמה תקיפה על מערכות המידע והמיחשוב של הארגון. מטרה המבדק היא לאתר פריצות וסיכונים. בסיום המבדק הארגון מקבל דו"ח המסכם את הממצאים והסיכונים שאותרו. לאחר קבלת הדו"ח הארגון מכין תכנית פעולה על מנת לסגור את הפרצות ולהקטין את סיכוני הכשל הנגרמים מאבטחת מידע לקויה.
מבדק חדירה הוא מרכיב קריטי לכל מערכת מידע המותאמת לדרישות ISO 27001. יש לבצע בדיקות לאורך כל מחזור חיי המערכת של הארגון. החל מתכנון ראשוני של מערכת המידע ועד להרצה שוטפת כחלק מתוכנית התחזוקה הסטנדרטית של מערכות המידע.
למערכות המידע בארגון יש נקודות תורפה טכניות מובנות הדורשות ניטור ושיפור מתמיד. יחד עם החידושים במערכות, נולדות נקודות פגיעות חדשות. יתרה מכך, החדשנות הפלילית של עברייני הסייבר אף היא משתפרת עם הזמן. ייתכן שבמערכות מידע שנמצאו חסינות לאחר תהליך של מבדק חדירה קודם קיימות נקודות חולשה חדשות. הפגיעויות החדשות נוצרו כתוצאה משדרוג מערכות המידע ו/או כתוצאה משדרוג יכולות התוקפים שמחפשים פרצות באופן תדיר.
סוקרי תקן 27001 ISO דורשים מארגונים לבצע מבדק חדירה אחת לשנה וחצי (פלוס-מינוס). מדוע? כדי לוודא שאותם ארגונים משדרגים באופן שוטף את מערכות המידע שלהם מהפרצות החדשות.
במאמר התייחסתי ל Annex A.8.8 להלן דרישת התקן המדויקת
Management of technical vulnerabilities
Information about technical vulnerabilities of information systems in use shall be obtained. The organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.
Photo by ThisIsEngineering from Pexels
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה. בקבוצה אני משתפת תקופתית מאמר קצר בנושאים הקשורים לאבטחת מידע, אבטחת הפרטיות, רגולציות בתחום ועוד. קישור להצטרפות – כאן |
איך עושים שינוי? במקרים רבים לא עושים! מצער אבל … יש שגרה להריץ וסדר העדיפות מחייב טיפול בשוטף. לפעמים יזמת השינוי נופלת רק כי ההנהלה לא גויסה לדבר. נכון שדברים שרואים משם (ראיית הנהלה גלובלית אסטרטגית של כל התמונה) לא רואים מכאן (השטח).
מהם שלושת הגורמים להצלחה של כל יוזמת שינוי?
אל תציצו לשורה למטה ורשמו על דף…
…
…
…
ובכן – שלושת גורמי ההצלחה הם.. (לפי סדר חשיבות):
איך רותמים את ההנהלה ליוזמת השינוי שלנו? איך מעבירים מכאן לשם?
גם בנושא זה יש תהליך שיטתי. רוצים ללמוד כיצד מגייסים הנהלה ליזמת השינוי, מוזמנים לקרוא את המאמר שלהלן.
אחרי שהבנו את הצורך בגיוס תמיכת ההנהלה ליוזמת השינוי שלנו, אנו בונים פתרון כמענה לבעיה כדי להציגו להנהלה.
חזיתי במספר רב של יוזמות לשינוי שנפלו עוד לפני שיצאו לדרך משום שלא הצליחו לגייס את התמיכה המבוקשת.
מובילי השינוי עובדים מסודר. למשל אחת השיטות היא DMAIC:
ולמרות כל ההכנה המקצועית הטובה – ההחלטה הכי נפוצה היא לא לשנות.
מדוע קורה הדבר? הרי ברור שצריך לעשות את השינוי?
התשובה היא שאנשים עושים מה שהם רוצים ולא מה שהם צריכים. זאת תכונה אנושית שכל אחד מאיתנו אם יסתכל בכנות במראה ימצא שלל דוגמאות לכך.
איך משיגים את אותה תמיכה ניהולית הנדרשת כדי שהשינוי יצליח? איך לשכנע את המנכ"ל/ המנהל הבכיר שאכן השינוי נדרש כדי שיכניס יד לכיס וייתן את המשאבים הנדרשים?
למעשה, מדובר כאן בתהליך מכירה. המאמר שלהלן מתמקד באספקטים הספציפיים ל"מכירת" יוזמה של שינוי.
להלן מספר דרכי פעולה אפשריות. למען הגילוי הנאות, אין ערובה להצלחה. בנוסף – שימו לב להתאים את הטקטיקה לאופי המנהל שלכם ולבחירת הכפתור המתאים עליו יש ללחוץ.
בהצלחה!
גישה לא מקדמת – להניח מראש שהשינוי לא אפשרי. כאשר אנו מאמינים בתוכנו שהשינוי לא אפשרי, לא נעשה מספיק כדי שהשינוי יקרה. או: כל העולם נגדינו. המנהלים לא מבינים ..
גישה מקדמת – גישה החושבת מה צריך לעשות או איך צריך לעשות כדי שהשינוי יקרה. אם ננקוט בגישה מקדמת ונשאל שאלות בסגנון של איך ומה לעשות, נמצא את התשובות.
לצערי, אני רואה מקרים רבים של מנהלים שחוששים מכישלון ולכן נמנעים מיוזמות. לפעמים הדבר גם קשור לתרבות ארגונית שמשמרת את הקיים. אל תוותרו! אם צריך השתמשו ביועצים חיצוניים שיעזרו לכם להוציא את הערמונים מהאש.
דברו במונחי תועלות ולא במונחים טכניים.
כדי שהמנכ"ל שלכם ישקיע ברעיון שלכם הוא צריך להבין קודם כל – מה ייצא לו מזה בנוסף לתועלות הארגוניות. כן, כן – גם הוא בן אדם. הבינו מה הכאב שלו, מה הצורך הסמוי והראו כיצד כאבו יופחת כתוצאה מהיוזמה. מה מניע אותו – גאווה? פחד? אגו? מוטיבציה? מבחינתו השיפור יכול להתבטא בתוצאות מספריות, ביוקרה שיזכה בה, התרגשות מיוזמה חדשנית, או מיליון סיבות אחרות. מצאו את הדרך לגייס אותו רגשית לתהליך.
אל תצפו לישיבה עם מצגת עמוסה כדי להציג את הרעיונות שלכם. הכינו "נאום מעלית" קצר כדי שתוכלו למכור את הרעיון כשתפגשו את המנכ"ל פגישה מקרית בחנייה או בקפיטריה. הנועזים שבכם, יארבו למנכ"ל במסלולו מהחנייה כדי לפגוש אותו בפגישה "מקרית". תכננו נאום קצרצר בין 30-60 שניות למכור את הרעיון!
חשבו בכנות את עלות ההישארות במצב הקיים בכל הפרמטרים הרלוונטיים מול ההשקעה בשינוי והתוצאות הצפויות באותם פרמטרים; הכינו תוכנית עסקית לשינוי: הניחו הנחות הגיוניות, אמתו את ההנחות במספרים אמיתיים, ובדקו את כדאיות ההצעה.
עשו שיעורי בית לגבי אופן קבלת ההחלטה. האם יש למנכ"ל אנשי אמון עימם הוא נוהג להתייעץ? האם יש מסננים בדרך שמחליטים עבורו איזה מידע להעביר לו? גייסו אנשים אלה לעזרתכם. למשל: אם אין גישה למנכ"ל, חפשו גישה לסמנכ"ל שיקדם את הנושא משיקוליו הוא. לדוגמה: סמנכ"ל כספים שיתמוך ביוזמה שחוסכת עלויות, סמנכ"ל שיווק שיבין שהיוזמה תביא ליתרון שיגדיל מכירות וכדומה.
שיקלו היטב בטרם תחליטו לקצר את הדרך על ידי ביצוע מחטפים ועקיפות של אנשים אלה.
הראו כיצד יוזמות השיפור "מתיישרות" עם ערכי החברה, או לחילופין, כיצד הישארות במצב הקיים פוגעת בערכי החברה. למדו את הערכים של המנכ"ל או המנהל המחליט. שנו את השפה: במקום לדבר על "בעיות", דברו על "הזדמנויות". זה לא עניין של משחק מילים אלא של גישה.
היו מקצוענים, עם הצלחות מוכחות מהעבר.
כך ידע המנכ"ל שהוא שם את יהבו על סוס מנצח.
הראו תוכנית שמתחשבת בכל הפרטים – מספרים, רגולציות, תרבות ארגונית, שיתוף בעלי עניין,…לשם כך דברו עם בעלי העניין השונים ושמעו את דעתם. השטח יודע מה צריך לעשות. ארגנו את המידע הנאסף ממקורות שונים לתוכנית אינטגרטיבית אחת. תכננו פיילוט כדי לאשרר את התוכנית או לתקן לפי הצורך.
ואם שום דבר לא עובד? כאשר מי שאמור לחתום על הצ'ק לא מעוניין – הסיכויים להמשך קטנים ביותר. בטרם תתייאשו – נסו לשנות את היקף היוזמה ולהתחיל בקטן. זהו את החלק עם הסיכוי להצלחה; חפשו את החלק עם השקעה יחסית נמוכה או סיכון נמוך ועדיין עם החזר משמעותי. אפשר להתחיל במחלקה אחת, למשל, בה יש מנהל קואופרטיבי;
תהיו סובלניים ועקשנים – כמו אנשי מכירות טובים. אחרי זמן מה, תבחינו בהתקדמות כלשהי.
עדיין לא עובד? הרפו וחכו להזדמנות מתאימה.
האם אתם מכירים דרכי פעולה נוספות, אחרות? אשמח אם תשתפו מניסיונכם באחת הרשתות החברתיות שקישורן להלן
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
רובנו הגדול מכיר את הצורך בניהול סיכונים. במקרים מסוימים התהליך נעשה כדי לצאת ידי חובה. תצפיותיי בארגונים מראות שבמקרים רבים התהליך לא מבוצע בצורה שיטתית, ומתקיימת מראית עין של תהליך ניהול סיכונים. כמו ללכת בלי ולהרגיש עם. משתמשים בתבנית של ניהול סיכונים, רושמים בטבלה מספר נושאים, לא עוקבים באופן שוטף אחר התממשות או אי התממשות הסיכון. כתוצאה מסיבות אלה ואחרות התהליך אינו מביא תועלת.
המטרה של תהליך ניהול סיכונים הוא לזהות בעיות פוטנציאליות לפני שהן קורות, כך שאפשר יהיה לתכנן פעילויות שמטרתן למנוע או להפחית את התוצאה השלילית במקרה של התממשות אותן בעיות. זהו תהליך מניעה המטפל בבעיות מוקדם ככל האפשר ובכך מקטין את השפעתן השלילית.
המאמר שלהלן ממפה טעויות נפוצות בתהליך ניהול הסיכונים. הטעויות יכולות לקרות בכל אחד משלושת שלבי התהליך של ניהול סיכונים. שימו לב, מאמר זה מניח שמתקיימים השלבים שלהלן. הנחה שלא תמיד עומדת במבחן המציאות.
להלן שלושה שלבים הכוללים יחדיו שבע שאלות לגבי האופן בו אתם מנהלים סיכונים; קיום או אי קיום של כל אחת מהפרקטיקות המיוצגות בשאלות, משפיע באופן ישיר על הצלחה או סיכון בתהליך ניהול הסיכונים שלכם.
תנו לעצמיכם 15 נקודות על כל שאלה שעניתם בחיוב. יד על הלב – לאיזה ציון הגעתם?
ההכנה כוללת מיסוד אסטרטגיה לזיהוי, ניתוח והפחתת סיכונים. האסטרטגיה בדרך כלל כוללת זיהוי מקורות של סיכון, חלוקת הסיכונים לקטגוריות, ופרמטרים איכותיים וכמותיים המשמשים להעריך, לתחום ולפקח על ניהול יעיל של הסיכונים. השלב הזה הוא שלב מתודי, שנועד לעודד אותנו לחפש סיכונים מסוגים שונים ולארגן אותם מראש.
שאלה ראשונה – האם אתם מחליטים מראש על מקורות וקטגוריות לסיכונים?
מקורות הסיכון הן משפחות ונושאים שעלולים "לייצר" סיכונים. לדוגמא: איחור באספקת תוצר מגורם חיצוני, יישום טכנולוגיות חדשניות, אי זמינות של תשתיות ומשאבי אנוש, ועוד. קטגוריות מאגדות סיכונים בעלי מכנה משותף, לדוגמה: שלבים במחזור חיים של פיתוח מוצר או שירות, סוגי תהליכים ועוד. כל אחד מאלה איננו סיכון, אלא תחום שבו יש לחפש את הסיכונים. ניהול סיכונים בהתאם למקורות וקטגוריות, מאפשר ללמוד מניסיון העבר, ולנקוט בפעילות המתקנת את סיבות השורש.
תשובה שלילית לשאלה הראשונה משמעותה אי הכנת תשתית ארגונית המאפשרת באופן שיטתי לבחון את האירועים המשפיעים על יכולת הארגון/פרויקט לעמוד במשימותיו, וכן לעדכן ולהתעדכן באופן הפעולה לגבי אירועים אלה.
שאלה שנייה – האם אתם מגדירים פרמטרים לניהול כמותי של סיכונים?
פרמטרים מקובלים לניהול כמותי של סיכונים:
Probability (P) – ההסתברות שהסיכון יתממש.
Impact (I) – מידת הבעיה שתיווצר במקרה שהסיכון יתממש.
Threshold (T) – ערך סף שכאשר מגיעים אליו מפעילים את תוכנית המגירה שהוכנה מראש למנוע או להפחית תוצאה שלילית במקרה של הפיכת סיכון לבעיה.
תשובה שלילית לשאלה השנייה משמעותה שלא ניתחתם את חומרת הסיכון ואת הרגע בו יש להפעיל תוכנית המגירה או להבין שהסיכון התממש והפך לבעיה.
שאלה שלישית – האם יש באמתחתכם אסטרטגיות לניהול סיכונים והאם אתם מפעילים שיקול דעת לגבי אופן הטיפול בכל סיכון וסיכון?
אסטרטגיה לניהול סיכונים כוללת נושאים כגון:
מחסור באסטרטגיה לניהול סיכונים עלול לגרום להתבדרות: החל מחוסר מיקוד באילו סיכונים להתמקד ובאיזה אופן לטפל בסיכונים ועד להעדר ניהול סיכונים בכלל.
מצב הסיכון ישפיע על כמות המשאבים שיושקעו בהפחתתו והתזמון שבו תוקדש תשומת לב ניהולית לטיפול בו.
שאלה רביעית – האם אתם מזהים סיכונים בתהליך שיטתי?
תהליך זיהוי הסיכונים מתבסס על האסטרטגיה שנקבעה, ומשתמש במקורות וקטגוריות הסיכונים שהוכנו מראש. חשוב ביותר לזהות את הסיכונים ולתעד אותם בצורה נכונה. לא כל דבר מסוכן הוא סיכון. ראו – מהו סיכון לפרויקט? דוגמאות לשיטות זיהוי סיכונים: ראיונות עם מומחים, למידה משיעורים שנלמדו בפרויקטים קודמים ועוד.
ניהול סיכונים לא שיטתי עלול לגרום לטעות בזיהוי הסיכונים המשמעותיים; סיכונים לא מזוהים הינם בעלי הסתברות גבוהה יותר למימוש מאשר סיכונים מנוהלים לאחר שזוהו. כל מנהל, עורך רשימת סיכונים בהתאם לניסיונו האישי בלבד, במקום לתרום ולהיתרם מהניסיון הארגוני הנצבר.
שאלה חמישית – האם אתם מעריכים ומתעדפים סיכונים (איכותית או כמותית)?
RPN – Risk Priority Number – מכפלה של שני הפרמטרים הסתברות והשפעה; ככל שהמספר גבוה יותר, יש לתת עדיפות לטיפול בסיכון המסוים.
תשובה שלילית לשאלה החמישית משמעותה אי תעדוף של הטיפול בסיכונים שזוהו. חוסר המיקוד יכול לגרום לטיפול בסיכונים שוליים במקום מרכזיים.
ניהול סיכונים כהלכתו כולל בחירה נכונה של אופן הטיפול בסיכון, וכן הוצאה לפועל של תוכנית המגירה ברגע שהתממש הסיכון והפך לבעיה.
שאלה שישית – האם אתם מכינים תוכנית לניהול סיכונים בהלימה עם האסטרטגיה שנקבעה לניהול סיכונים?
האם לכל סיכון מותאמת תוכנית טיפול (מניעה, בקרה, העברה, קבלה) בהתאם למידת ההשפעה שלו אם יתממש?
תשובה שלילית לשאלה השישית משמעותה טיפול שגוי בסיכונים שזוהו. למשל: החלטה על קבלה של סיכון שמשמעותה לא לעשות דבר במודע, כאשר אפשר היה לפעול למניעה באמצעים סבירים.
שאלה שביעית – האם אתם מפעילים את תוכנית השיכוך / מגירה שהכנתם?
האם נעשית בקרה פרו-אקטיבית- תקופתית על מצב הסיכונים? האם מצייתים לאסטרטגיה שקבעה כיצד לנהל, לבקר, לשתף בעלי עניין Iלדווח על מצב הסיכונים? האם היד על הדופק כל הזמן לגבי מצב כל סיכון, למול ערך הסף שנקבע להפעלת תוכנית המגירה?
תשובה שלילית יכולה לגרום לאי זיהוי הרגע להפעיל את תוכנית המגירה או לאי עדכון מצב הסיכון בעקבות שינוי של אחד מהפרמטרים שלו.
כדי לנהל סיכונים כהלכה, ולא לוותר על אף פרקטיקה שתוארה לעיל, מומלץ לפתח אסטרטגיה לניהול התהליך, הנתמכת בתהליך ותבנית (Template) הנותנים מענה לכל השלבים והשאלות.
נזכור ששימוש בתבנית בלבד בלי להבין את כל הסוגיות בתהליך עלולה להיות מראית עין של תהליך ניהול סיכונים.
מה ניסיונכם בתחום? האם הינכם מנהלים על פי כל הפרקטיקות שתוארו לעיל? מה קורה אצלכם בעקבות אי מימוש אחת מהפרקטיקות? אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
Photo by Kammeran Gonzalez-Keola from Pexels