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

הפתרון – האם בחרתם נכון?

התשובה המועדפת היא ד'.

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

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

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

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

ואם לא? גם זו תשובה ניהולית חשובה.

כי עסקה טובה היא לא רק עסקה שמצליחים לסגור. היא עסקה שמסוגלים גם לקיים.

למה לא האפשרויות האחרות?

א. חריגה חד-פעמית באישור ההנהלה

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

ב. התעקשות על שישה שבועות

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

ג. התחלה מדורגת והשלמת הבדיקות במקביל

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

ד. תוכנית היערכות מואצת ומבוקרת

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

מה אומר תקן ISO9001?

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

התובנה הניהולית

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

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

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

שאלה למחשבה

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

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

הפתרון – האם בחרתם נכון?

התשובה הנכונה היא ג'.

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

למה לא שלוש התשובות האחרות?

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

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

ב. להודיע מיד לכל הלקוחות והעובדים

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

ד. למנות ממונה על הגנת הפרטיות

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

מה כדאי למנהלים ללמוד מהאירוע?

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

ושאלה אחת לסיום

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

עדיף להיערך לפני האירוע

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

הפתרון – האם בחרתם נכון?

התשובה המועדפת היא ד'.

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

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

מדוע לא שלוש התשובות האחרות?

א. התאמות נוספות למערכת

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

ב. התערבות מנהלי המחלקות

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

ג. התאמת התהליכים למערכת

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

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

ד. הגדרת הפער בין הרצוי למצוי

זו נקודת הפתיחה הנכונה.

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

ומה עושים באירוע הקאיזן?

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

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

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

כך אפשר להתמקד בשיפור התהליך הכולל, ולא רק בשיפור התוכנה.

התובנה הניהולית

אוטומציה אינה תחליף לשיפור תהליכים.

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

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

ושאלה למחשבה

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

הפתרון – האם בחרתם נכון?

התשובה הנכונה היא ד'.

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

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

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

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

א' – לעצור את השימוש ב-AI

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

ב' – להוסיף בדיקה אנושית מחמירה

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

ג' – להגביל את השימוש לדוחות בעייתיים

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

ד' – לבלום את התקלה ולהמשיך באופן מבוקר

זו הבחירה המועדפת.

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

ומה הקשר לתקן ISO/IEC 42001?

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

התובנה הניהולית – הטכנולוגיה השתנתה. האם גם התהליך?

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

שאלה למחשבה

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

הפתרון – האם בחרתם נכון?

התשובה המתאימה ביותר היא ב' – קודם להבין מה גורם לעיכוב.

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

אבל מה?

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

בשלב הזה אנחנו פשוט לא יודעים.
זו בדיוק הבעיה.

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

למה דווקא תשובה ב'?

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

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

ומה לגבי שלוש האפשרויות האחרות?

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

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

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

ג' – להוסיף עובדים. אולי פשוט חסרות ידיים עובדות?

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

ד' – להטמיע אוטומציה. הרי טכנולוגיה אמורה לקצר תהליכים, לא?

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

אז מה אפשר לקחת מהאתגר הזה?

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

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

שאלה למחשבה

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

להרחבה – מצוינות תפעולית ושיפור תהליכים – OK יועצים לניהול