OK יועצים לניהול

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

חמשת מצוות "עשה" ותיאור הגהנום המצפה למי שלא עושה

1. בניית תהליך ארגוני הנתמך בנכסים ארגוניים מותאמים לארגון ומוטמעים בו

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

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

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

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

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

3. הנחיות וקריטריונים להתאמת התהליך

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

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

4. בניית ספרייה עבור הנכסים הארגוניים

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

• הגהנום המחכה למי שלא עושה
  במילה אחת: בלגן!

5. בניית סביבת עבודה משותפת

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

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

הבסיס לניהול ידע

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

Photo by kira schwarz from Pexels

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

אנו נשאלים –
התבקשנו לעמוד בדרישות SOC2– מה עלינו לעשות?
אם יש לנו כבר תקן 27001 ISO? – האם נחסך מאיתנו המאמץ?

המאמר שלהלן מסביר מהו SOC2 לעומת 27001 ISO. נדרש הסבר נוסף? מוזמנים לפנות אלינו ונרחיב.

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

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

הסוגייה שמאמר זה דן בה הינה מה השוני בין שני סוגי מבדקים אלה ומה הקריטריונים לפיהם ארגון מחליט באיזה מבדק לבחור?

מהו מבדק SOC2?

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

הפסקה לפרסומת חינמית 

חמשת הקטגוריות של SOC2 שמוכיחות את הביטחון ביכולת הארגון לשמור את בטיחות ותקינות המידע

מבדק SOC2 מגדיר חמש קטגוריות שמעידות על יכולת הארגון לשמור את בטיחות ותקינות המידע:

• אבטחה (Security)  – האם מערכת המידע מוגנת בפני חשיפת מידע לגורם בלתי מורשה?
• זמינות (Availability)  – האם מערכת המידע והנתונים זמינים להפעלה ולשימוש לפי הצורך שהוגדר להם.
• שלמות העיבוד (Processing Integrity) – האם עיבוד הנתונים במערכת המידע הינו שלם, תקף ומדויק בעת השימוש בו.
• סודיות (Confidenti­ality) – האם המידע המוגדר כסודי מוגן כפי כמצופה ממנו ?
• פרטיות (Privacy)  – האם מידע אישי שנאסף, משמש, נחשף, נשמר ומושמד בהתאם למדיניות שמירת הפרטיות המצופה מהארגון?

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

מהו מבדק 27001 ISO ?

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

מה ההבדל בין מבדק 27001 ISO למבדק SOC2?

תחום ההתעדה

תהליך הסמכה לתקן 27001 ISO נעשה ברמת ארגון. מעיד על כך שלארגון יש נהלי איכות ואבטחת מידע לניהול מערכת אבטחת המידע שלו.

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

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

סוג ההסמכה

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

בעוד שמבדק ISO 27001 מתרכז בעיקר בבדיקת מערך מבנה המערכת לניהול איכות אבטחת המידע בחברה (IMQS) וכי כלל הנהלים והתהליכים הנדרשים קיימים, מבדק SOC2 יורד לעומק המערכת הנבדקת, החל מבדיקת תהליכי הפיתוח SDLC ועד לבדיקת סוגי ההתראות הקיימות במערכת.

מיקום גיאוגרפי של הלקוחות

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

שורה תחתונה – מה הלקוח רוצה?

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

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

המשכיות – קל או מאתגר?

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

איך קורה הדבר?

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

מדוע זה קורה?

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

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

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

שאלה מס 1 – האם מדובר בשינוי מהותי?

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

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

שאלה מס 2 – האם מדובר בשינוי פנימי?

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

שאלה מס 3 – האם השינוי אפשרי?

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

המשכיות – לדעת איך עושים

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

בהצלחה!

השראה למאמר – משיעור ימימה של עידית שלו
Photo by Kulbir from Pexels

פונים אלינו מנהלי מערכות מידע עם בקשות עזרה לנושא SOC2.

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

שאלה נפוצה היא: אם נעבור תהליך הסמכה לתקן 27001 ISO, או יש לנו כבר תקן 27001 ISO, האם הדבר יכול להחליף את הדרישה ל-SOC2?

לפני שנדבר על "איך", נתחיל מ"למה". מדוע לקוחותינו מבקשים שנעמוד בדרישות SOC2 ומדוע כדאי לנו לממש את דרישות SOC2 ?

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

הפסקה לפרסומת חינמית 

מדוע כדאי לארגונים לעמוד בדרישות  SOC2 ?

דרישה מלקוחות / לקוחות פוטנציאליים

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

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

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

שקט נפשי להנהלת הארגון

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

מה ההבדל בין הסמכה לתקן 27001 ISO לתהליך הסמכה ל-SOC2?

תהליך הסמכה לתקן 27001 ISO נעשה ברמת ארגון. מעיד על כך שלארגון יש נהלי איכות ואבטחת מידע לניהול מערכת אבטחת המידע שלו.

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

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

מהו מבדק SOC2?

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

חמשת הקטגוריות של SOC2 שמוכיחות את הביטחון ביכולת הארגון לשמור את בטיחות ותקינות המידע

מבדק SOC2 מגדיר חמש קטגוריות שמעידות על יכולת הארגון לשמור את בטיחות ותקינות המידע:

• אבטחה (Security) – בדיקה תקופתית, פיזית ולוגית, של יעילות המדיניות והנהלים המסדירים את האופן שבו ארגונים מגנים על עצמם מפני גישה בלתי מורשית יחד עם יכולת זיהוי מיידית כאשר יש פגיעה באבטחת מידע שעלולה לגרום לחשיפת מידע לגורם לא מורשה.
• זמינות (Availability) – בדיקה תקופתית המוודאת שמערכת המידע והנתונים זמינים להפעלה ולשימוש לפי הצורך שהוגדר להם.
• סודיות (Confidenti­ality) – בדיקה תקופתית המוודאת שמידע שמוגדר כסודי חייב להיות מוגן מספיק מפני גישה בלתי מורשית של גורם לא מוסמך מתוך או מחוץ לארגון.
• שלמות העיבוד (Processing Integrity) – בדיקה תקופתית המוודאת שעיבוד הנתונים במערכת המידע הינו שלם, תקף ומדויק בעת השימוש בו.
• פרטיות (Privacy) – בדיקה תקופתית המוודאת שימוש במידע פרטי אך ורק על פי התנאים שסוכמו עם הלקוח. כמו כן, ווידוא סילוק עקבות של פרטי מידע אישי שנשאר במערכת כתוצאה מגישה או שימוש במערכת. כלומר: ווידוא שלאחר השימוש במערכת מסולק המידע האישי שנשאר במערכות המידע של הארגון.

לסיכום

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

Photo by Markus Spiske from Pexels

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

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

האם אתם מזהים את הדפוסים שלהלן?

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

מיפוי תהליכים או כתיבת נהלים – מי צריך את זה?

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

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

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

זיהוי הצורך / הגדרת הבעיה

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

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

פוסט מורטם או ביצוע פעולות מתקנות – לא תמיד עוזר

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

אנחנו מיוחדים מאד

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

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

אנחנו לא רוצים לעבוד עם נהלים מרובי מלל

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

מה שהיה הוא בכלל לא סימן לבאות.

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

אנחנו אוהבים גיבורים שמכבים שריפות

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

הכול או לא כלום

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

לסיכום – מזהים את דפוסי המחשבה שתוארו?

מה אתם אומרים ? נתקלים בדפוסים האלה? משלימים עימם או מנסים לשנות?

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

מחכה למשוב מיכם

==
ההשראה לכותרת המאמר הגיעה מהרצאה ששמעתי מעידית שלו המלמדת ימימה.

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

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

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

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

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

מהן חמש הטעויות הנפוצות בניהול התקשורת בפרויקט?

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

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

טעות מספר שתיים – חוסר תכנון התקשורת בפרויקט

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

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

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

טעות מספר ארבע – ניהול לא מיטבי של ציפיות בעלי העניין בפרויקט במהלך הפרויקט

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

טעות מספר חמש – אי דיווח או דיווח חלקי לגבי התקדמות הפרויקט

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

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

עושים כל מה שכתוב למעלה אבל להיפך.

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

Photo by Tim Gouw from Pexels

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

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

מה הבעיה עם הסכמה לשנות, אבל אחר כך?

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

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

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

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

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

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

השקעה בתהליכי עבודה היא מקדמת ולא מעכבת !

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

מהו הזמן הטוב ביותר להתאים את תהליכי העבודה שלנו לאתגרים ולמציאות המשתנה?
טוב ששאלתם. התשובה היא – ע כ ש י ו!

"הירידה היא תכלית העלייה" רבי נחמן

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

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

Photo by Tima Miroshnichenko from Pexels

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

ארגונים מטמיעים תקן ISO 27001 כדי לנהל מערכות אבטחת מידע וסייבר (ISMS).  תקן 27001 ISO דורש מארגונים להגן על נקודות התורפה במערכות ותשתיות הארגון מפני פגיעה על ידי גורמים עוינים. ראו בתחתית המאמר את הדרישה שמוגדרת ב Annex A.8.8),

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

האם זאת חובה לבצע מבדק חדירה לארגונים שמטמיעים תקן 27001 ISO?

מאמר זה מתמקד בקשר שבין תקן 27001 ISO ומבדק חדירה.

האם תקן 27001 ISO דורש מבדק חדירה?

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

מהן הדרישות של תקן ISO 27001 ממבדק חדירה?

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

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

מה זה בעצם מבדק חדירה?

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

מתי ארגון שעושה 27001 ISO צריך לעשות מבדק חדירה?

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

נספח – ציטוט, מ-Annex A.8.8

במאמר התייחסתי ל 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

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

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

ובכן – שלושת גורמי ההצלחה הם.. (לפי סדר חשיבות):

1. תמיכת הנהלה;
2. תמיכת הנהלה;
3. תמיכת הנהלה

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

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

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

מובילי השינוי עובדים מסודר. למשל אחת השיטות היא DMAIC:

1. Define – הגדרת ההזדמנות – מה חשוב לנו לשפר?
2. Measure – מדידת הביצועים הנוכחיים;
3. Analyze – אנליזה של ההזדמנות – מה בדיוק לא עובד?
4. Improve – שיפור התהליך ע"י תיקון שורש הבעיה;
5. Control – בקרת ביצועים: מיסוד תהליכי מניעה שיבטיחו את אי-הישנות הבעיה.

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

מדוע קורה הדבר? הרי ברור שצריך לעשות את השינוי?

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

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

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

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

בהצלחה!

האם הגישה שלכם מקדמת או לא?

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

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

מה יוצא לי מזה?

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

נאום המעלית

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

כמה יעלה להישאר במצב הקיים?

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

פוליטיקה זו לא מילה גסה

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

ערכים

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

השטן נמצא בפרטים הקטנים

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

התחילו בקטן

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

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

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

ניהול סיכונים (תזכורת)

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

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

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

תנו לעצמיכם 15 נקודות על כל שאלה שעניתם בחיוב. יד על הלב – לאיזה ציון הגעתם?

שלב ראשון –  הכנה לתהליך ניהול הסיכונים

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

שאלה ראשונה – האם אתם מחליטים מראש על מקורות וקטגוריות לסיכונים?

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

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

שאלה שנייה – האם אתם מגדירים פרמטרים לניהול כמותי של סיכונים?

פרמטרים מקובלים לניהול כמותי של סיכונים:

Probability (P) – ההסתברות שהסיכון יתממש.
Impact (I) – מידת הבעיה שתיווצר במקרה שהסיכון יתממש.
Threshold (T) – ערך סף שכאשר מגיעים אליו מפעילים את תוכנית המגירה שהוכנה מראש למנוע או להפחית תוצאה שלילית במקרה של הפיכת סיכון לבעיה.

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

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

אסטרטגיה לניהול סיכונים כוללת נושאים כגון:

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

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

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

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

שאלה רביעית – האם אתם מזהים סיכונים בתהליך שיטתי?

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

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

שאלה חמישית – האם אתם מעריכים ומתעדפים סיכונים (איכותית או כמותית)?

RPN – Risk Priority Number – מכפלה של שני הפרמטרים הסתברות והשפעה; ככל שהמספר גבוה יותר, יש לתת עדיפות לטיפול בסיכון המסוים.

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

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

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

שאלה שישית – האם אתם מכינים תוכנית לניהול סיכונים בהלימה עם האסטרטגיה שנקבעה לניהול סיכונים?

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

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

שאלה שביעית – האם אתם מפעילים את תוכנית השיכוך / מגירה שהכנתם?

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

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

ניהול סיכונים – סוף דבר

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

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

Photo by Kammeran Gonzalez-Keola from Pexels