פונים אלינו מנהלי מערכות מידע עם בקשות עזרה לנושא 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 ומבדק חדירה.
ארגון עם פונקציונליות סטנדרטית ו/או ארכיטקטורת מידע בסיסית יכול להסתפק בסקר סיכונים. כאשר לארגון יש מערכות מורכבות יותר, יידרש מבדק חדירה לאCטחת בטיחות מערכות אבטחת המידע. דוגמה למערכת מורכבת: קיום אפליקציות 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
את ההבדל בין חכם לפיקח אנו יודעים: חכם לא נכנס למצבים שפיקח יודע לצאת מהם.
מה אנו יותר, חכמים או פקחים?
איך נדע?
פשוט נסתכל על העבר שלנו: האם מצבי הכשל שאנו נתקלים בהם הם חדשים או חוזרים על עצמם בווריאציה כזו או אחרת?
יד על הלב – מצבי הכשל ברובם חוזרים על עצמם. באמצעות פקחותנו, ניסיוננו וחריצותנו אנו מגייסים כל פעם מחדש את המשאבים שלנו ופותרים את התקלות שאנו פוגשים שוב ושוב. אנו אפילו מתגאים שיכולת אלתור היא בDNA שלנו.
בכל ארגון שתולים מחוללי תקלות בלתי נראים, המפריעים לנו להתקדם בדרכנו. כל פעם שאנו נתקלים ונופלים כתוצאה מאותם מכשולים, אנו מזיזים הצידה את המכשול וממשיכים. דרכנו אצה לנו. המטרה חשובה לנו. לכן, מיד לאחר שנפלנו כתוצאה מהמכשול, אנו קמים מיד, עושים תיקון שפותר את התקלה הספציפית וממשיכים בריצתנו. הגענו למטרתנו, ומיד אנו יוצאים לדרך חדשה (פרויקט חדש? מוצר חדש?). שוב אנו הולכים באותם המשעולים ונופלים באותן מהמורות. לפעמים, המהמורות נראות קצת שונות ולפעמים יש לנו תחושת דז'ה-וו: האם כבר נפלנו לבור הזה? שוב, אין זמן – קדימה! המטרה מחכה.
הגיוני? אולי כדאי לחשוב לפני שמתחילים שוב את הריצה המטורפת, האם נגיע יותר מהר, או בפחות מאמץ אם נטפל באותם מחוללי תקלות בלתי נראים המכשילים אותנו?
טיפול כזה הוא בעצם תהליך של מניעת הישנות התקלות, שמשמעותו – ניתוח סיבות השורש שגרמו לתקלות שקרו ותיקון סיבת השורש, כדי למנוע את הישנות התקלות שהן גורמות.
במקרים רבים, גם כאשר אנו עושים תחקירים ומזהים את סיבות השורש ואפילו יודעים מה לעשות כדי שהתקלה לא תחזור על עצמה, עדיין חסר לנו מנגנון מסודר של הטמעת הידע החדש בתהליכי העבודה הקיימים.
בסיום תחקירים אנו רושמים רשימת נושאים ומסקנות – עשה ואל תעשה, אך לא מטמיעים את הידע החדש, ובכך הניסיון הארגוני לא גדל. במקרה הטוב, האנשים הספציפיים שקרתה להם התקלה מחכימים ולא עושים אותה שוב. במקרה הפחות טוב, גם הם חוזרים שוב ושוב על אותן התקלות.
מדוע קורה הדבר, למרות שיש לנו כלים טובים כמו ביצוע פעולות מתקנות, תחקירים ועוד?
הסיבה לכך היא שכדי שהתקלות לא יחזרו על עצמן בואריאציה כזו או אחרת, אנו צריכים לשנות את דרכנו. נודה שהדבר מאתגר, למרות שהוא חשוב.
שינוי תהליכי עבודה כמו כל תהליך שינוי הוא לא פשוט.
לפעמים השינוי דורש סטייה מהדרך שתכננו, כדי לפתח תהליך חדש ולהטמיע אותו. הדבר מאתגר כיוון שהוא דורש משאבים שונים ונוספים מהמשאבים הרגילים שהוקצו לנו. מאתגר לרוץ קדימה כדי להגיע לדד ליין ותוך כדי ריצה לשנות את הדרך ו/או שיטת העבודה.
סוג המאמץ הוא שונה. מנהל פרויקט שיש לו פרויקט להוביל לקו הסיום, ממוקד במשימה שלו. אין לו את משאבי הזמן והסבלנות להטמיע שינויים.
איך בכל זאת אפשר לעשות זאת?
באמצעות סוכני שינוי פנימיים / אנשי ארגון ושיטות או באמצעות יועצים חיצוניים שהמיקוד שלהם הוא בהובלת השינוי, כך שהניסיון שנצבר יהיה ידע בר קיימא. אנשים אלה ממוקדים בשינוי, יש להם ניסיון וידע בהובלת שינויים, ויש להם גם משאבים לעשות זאת, כיוון שזה ה-פרויקט שלהם.
האם אתם מסכימים לנאמר עד כה?
האם אתם מתנהגים בחוכמה או בפקחות?
אשמח לשיתופים כנים על מקרים שבהם הייתם חכמים ובאחרים שבהם הייתם פקחים באחת הרשתות החברתיות שקישורן להלן.
כדי לשבור את מעגל אי-שיפור המתמיד מישהו צריך לקחת אחריות על תהליך השינוי.
מזמינה אותך לדבר איתי ישירות על מחוללי התקלות שלכם :-),
להלן פרטי הקשר שלי: Orna@ok-consulting.co.il, 0537739018
| מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
Photo by Anete Lusina from Pexels
כידוע לרבים מאיתנו, פוסט מורטם הוא תהליך שעושים לחולה לאחר שהוא מת כדי להבין את סיבת המוות. בהשאלה, משתמשים במושג כדי לבצע הפקת לקחים בסוף שלב, או בסוף הפרויקט. תהליך פוסט-מורטם מאפשר להפיק לקחים וללמוד שיעורים מפרויקט אחד וליישמם בפרויקטים אחרים.
האם לא עדיף לקיים את דיון הפקת לקחי הפרויקט, לפני שהוא נכשל בהשגת חלק מיעדיו, ובכך למנוע כישלונות אלה?
יד על הלב, כמה מאיתנו באמת חוקרים בהתחלת פרויקט את השיעורים שנלמדו בתהליכי פוסט-מורטם שבוצעו בפרויקטים דומים, ומנסים בצורה פרו-אקטיבית למנוע את הישנותם?
מאמר זה מציע טכניקה שונה לביצוע התהליך, Pre-Mortem, לפני שהחולה/הפרויקט מת, כדי לזהות כשלים לפני שהם קורים. טכניקה זו פורסמה לראשונה על ידי גרי קליין (Gary Klien) ופורסמה בשנת 2007 ב- Harvard Business Review במאמר בשם "Performing a Project Pre-mortem".
לעומת פוסט-מורטם, תהליך של Pre-Mortem חוקר סיבות עתידיות לכישלון הפרויקט טרם סיומו. את ה- Pre-Mortem מבצעים לאחר שכבר הוכנה תוכנית לפרויקט. ה-Pre-Mortem מציע לנוכחים במפגש סיעור המוחות, שידמיינו שהפרויקט כבר הגיע לסיומו, ומה הם יגידו בישיבת ה-Post-Mortem של אותו הפרויקט. מסתבר ששינוי מחשבתי קטן כזה, עוזר לאנשים להשתחרר מההגנות על התכנון שלהם. בישיבות פוסט-מורטם, במקרים בהם הפרויקט לא עמד ביעדיו, לא תמיד אנשים מוכנים לשתף את הסיבות האמיתיות לאי-ההצלחה, ונכנסים למגננה. לעומת זאת, דיון "פוסט מורטם" בטרם עת, מאפשר בקלות יתרה לחפש גורמים פוטנציאלים לאי-הצלחה.
בנוסף, תהליך הpre-mortem מתגבר על הקשיים הבאים, הקורים בתהליך post-mortem:
הכנה
חברי הצוות מתכנסים, לאחר שקראו את תכנון הפרויקט, או שתכנון הפרויקט מוצג בפניהם; על מנת למקד את סיעור המוחות, הצוות מסכם מהם יעדי הפרויקט, שאי השגתם מהווה סיכון:
"מסע בזמן"
המשתתפים מתבקשים לדמיין שבידם כדור בדולח בו ניתן לראות את העתיד. כרגע הם בישיבת Post-Mortem בסוף הפרויקט. חברי הצוות מתבקשים לחשוב מה יגידו בישיבת פוסט-מורטם של הפרויקט שלהם. כל אחד מהמשתתפים רושם על מדבקות צהובות את הסיבות שלדעתו "גרמו" לכשלים או הצלחות. המקור לסיבות לכשלים של כל אחד הוא חששות מכל נושא אפשרי בפרויקט, ולא רק הנושאים שבתחום אחריותו. במידת האפשר, מתארים על ציר הזמן של הפרויקט – מתי קרו האירועים.
הכנת רשימת סיבות לכישלון או הצלחה
כל אחד מהמשתתפים רושם את הסיבות לכישלון, לדעתו. כאן באה לידי ביטוי האינטואיציה של כל אחד מחברי הצוות. כל חבר צוות מדמיין אירועים אחרים.
איחוד הרשימות האישיות לרשימה אחת
הרשימה המאוחדת כולל את כל הסיכונים שזוהו בפרויקט. מוביל סיעור המוחות מסתובב בין שולחנות המשתתפים, מבקש מכל אחד מהמשתתפים, להצהיר בכל רם על סיבה אחת לכישלון או הצלחה; הסיבות נרשמות על הלוח, או שמדביקים את המדבקות הצהובות. עוברים בתור במספר סיבובים – כל משתתף בתורו מצביע על סיבה אחרת לכישלון. בסוף התהליך, יש רשימה מקיפה של סיבות וחששות לפרויקט. מקבצים את הסיבות לקטגוריות, על ידי הזזת המדבקות וקיבוצן לפי קטגוריות.
דיון
בוחרים 2-3 סיבות שזוהו כגורמות לכישלון גדול. מגדירים במשותף מהו החשש בדיוק, ומה ניתן לעשות כדי לשכך את עוצמתו, או למנוע את היווצרותו.
תודה
מודים למשתתפים ומתפזרים.
מה בין pre-mortem לניהול סיכונים?
פרה מורטם היא טכניקה מקורית לזיהוי סיכונים. לאחר שהסיכונים זוהו הם מטופלים בטכניקות הידועות של ניהול סיכונים. הטכניקה מזהה סיכונים באופן שיטתי ומעמיק יותר מהטכניקות השגורות של ניהול סיכונים. עצם ה"טקס" של הפרה-מורטם גורם למשתתפים לחשוב לעומק ולזהות סיכונים אופציונאליים.
וכמובן הטקס יכול גם לכלול פרק דומה על ניהול הזדמנויות בפרויקט, כגון: הטמעת שיעורים ולקחים מפרויקטים קודמים.
מוכנים ליישום הטכניקה?
מוזמנים לספר ולשתף באחד הקישורים שלהלן (דוא"ל או רשת חברתית)
| מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
Photo by Polina Zimmerman from Pexels
