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

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

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

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

כדי להיות 10 בניהול פרויקטים, עלינו:

  1. להיות 10 בניהול אינטגרציה
  2. להיות 10 בניהול תכולה
  3. להיות 10 בניהול זמן
  4. להיות 10 בניהול עלויות
  5. להיות 10 בניהול איכות
  6. להיות 10 בניהול משאבי אנוש
  7. להיות 10 בניהול תקשורת
  8. להיות 10 בניהול סיכונים
  9. להיות 10 בניהול רכש
  10. להיות 10 בניהול בעלי עניין

בהצלחה לכולנו !

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

בגרסת התקן  9001:2015 ISO.הוחלפה הדרישה לפעולה מונעת לתהליך של ניהול סיכונים.

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

כדי ענות על השאלה, נשווה את שני התהליכים, לפי שלביהם:

זיהוי

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

הערכת נזק

פעולה מונעת: הערכת הצורך בפעולה למניעת הופעתן של אי-התאמות
ניהול סיכונים: הערכת הסיכון (אומדן הנזק)

החלטה על פעולה

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

מעקב ובקרה

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

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

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

סוף מעשה במחשבה תחילה

תהליך ניהול סיכונים מוסיף שתי פעולות חשובות מעבר לפעולה המונעת:

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

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

יש הבדל או אין הבדל?

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

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

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

האם השינוי חשוב?

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

ארגונים רבים בארץ ובעולם עוברים תהליך התעדה לפי תקן 9001 ISO. עד כה, ברוב הארגונים, תהליך ניהול סיכונים שיטתי אינו מוטמע בחלק גדול מהארגונים, במיוחד בארגונים קטנים. הכנסת התהליך לתקן הבסיסי והפופולארי גורמת להרבה מאד ארגונים למסד תהליך שכזה, לתועלתם. עד כה, תהליך ניהול סיכונים היה חובה רק בתקני ISO אחרים יותר כגון: ISO 27001 לבטיחות מידע, ISO 14001 לבטיחות הסביבה ועוד. המלצתי – גם אם הדרישה היא "רק" ל- Risk-Based-Thinking – מסדו תהליך ניהול סיכונים שיטתי. אל תסתפקו בדרישה המנינמלית. שהרי – לא מספיק למסד חשיבה על… מיסוד תהליך שיטתי מביא תועלת רבה.

   

לאחרונה היינו עדים לאירוע מפחיד בכל קנה מידה: שריפה פרצה במפעל פלסטיק בקיסריה. בכתבה של Ynet  מיום 22.6.14 נכתב שעל כיבוי השריפה עמלו 123 לוחמי אש, 69 כבאיות ו-6 מסוקי כיבוי שגויסו מכל הארץ. האש, שהגיעה לגובה 20-25 מטר, התפשטה למפעל שכן וכילתה גם אותו. היה חשש להתפשטות האש למפעלים סמוכים נוספים. עשרות עובדים שהו במפעל ולמרבית המזל רובם חולצו ללא פגע, למעט שני עובדים שנפגעו במצב קל ובינוני. תושבי הסביבה נאלצו להסתגר שעות רבות בבתיהם ללא מזגן ולסגור את כל הפתחים כדי שלא ישאפו עשן רעיל. בהתאם למסקנות ראשוניות מהאירוע, מדובר בהתלקחות באזור אחסון ששופץ לאחרונה וכנראה טרם התקבל אישור שירותי הכבאות להפעלת המקום. המפעל נשרף כליל ואיתו הכסף שהושקע בשיפוץ. מחדל בטיחותי זה הסב לבעלי המפעלים נזקים עסקיים כבדים בעקבות הרס המפעלים ואי יכולתם לעמוד בהתחייבויות לאספקת סחורה. עובדי המפעל נשארו ללא פרנסה לתקופה ממשוכת.

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

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

האם אפשר למנוע התרחשויות שכאלה?

בוודאי!

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

  • תקן 9001 ISO – תקן ניהול איכות – במסגרת המהדורה החדשה של התקן שצפויה להתפרסם בשנת 2015 צפוי להתווסף פרק שמחייב את הארגון העומד בתקן לבצע סקר סיכונים במקום ההנחיה הקודמת שדיברה על פעילות מונעת בצורה ערטילאית.
  • תקנות ארגון הפיקוח על העבודה (תכנית לניהול הבטיחות), התשע׳׳ג-2013 – במסגרת תכנית בטיחות שכל ארגון מחויב להכין עד אוגוסט 2014 נדרש לבצע הערכה מלאה של כלל סיכוני הבטיחות שיש לארגון.
  • תקן ת"י 18001  או בגרסתו החדש – תקן ISO 45001:2018– מערכת בטיחות וגהות – התקן מחייב ביצוע סקר סיכונים מלא לכל תהליכי עבודה שקשורים לבטיחות.
  • תקן 14001 ISO – מערכת סביבתית – התקן מחייב ביצוע סקר סיכונים מלא לכל ההשפעות הסביבתיות של הארגון.
  • תקן 27001 ISO – תקן אבטחת מידע – התקן מחייב התייחסות לכלל סיכונים שיכולים לפגוע במערכות מידע ומאגרי מידע של הארגון.

איך עושים את זה?

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

OK, מהו סיכון ולמה לנו להתעסק עם זה בכלל?

סיכון הינו הסתברות להפסד כתוצאה מ-:

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

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

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

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

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

מהו תהליך של ניהול סיכונים?

תהליך ניהול סיכונים הוא תהליך של מספר צעדים:

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

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

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

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

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

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

רקע לניהול דרישות

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

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

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

איך יוצרים דרישה מדויקת ? כללי העבודה בקטגורית "דיוק (Precision)" יעזרו לנו ליצור דרישות כאלה.

המסתורין של שמות העצם

יידוע שמות עצם: השתמש אך ורק בשמות עצם מיוּדעים (מלווים בה"א הידיעה). שימוש במונחים ללא יידוע מוביל לריבוי משמעויות.

דוגמה:

המערכת תספק תצוגת זמן

מושא הדרישה (תצוגת זמן) צריך להיות מיודע כדי שיהיה חד-משמעי:

המערכת תציג את השעה-הנוכחית

חיים ומוות ביד הלשון

לשון פעיל: השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה. שימוש בלשון סביל מקשה על אימות הדרישה.

דוגמה:

זהות הלקוח תיבדק

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

מערכת-ניהול-החשבונות תוודא את זהות-הלקוח

מי הנושא בעול?

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

כבודו במקומו מונח

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

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

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

כמה ? שבע ! מה שבע ? מה כמה !

כַּמָּתים: המנע מכַּמָּתים (Quantifiers) לא מדויקים. דרישה צריכה להיות מכומתת במדויק.
דוגמה:
המאזניים הביתיים יציגו את המשקל עד לדיוק של בערך 10 גרם.
דוגמאות לכַּמָּתים מעורפלים שמהם יש להימנע: הרבה, בערך, כמעט תמיד, גמיש, משמעותי, יעיל, הגיוני, טיפוסי, מתאים, קרוב ל, בקירוב.
לכן:
המאזניים הביתיים יציגו את המשקל ± 10 גרם.

גאוות יחידה

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

לכל מספר יש לציין במפורש את היחידות בהן הוא נמדד:

למעגל-המודפס תהיה טמפרטורת אחסנה של לא יותר מ-30 מעלות צלזיוס

פועלי כל העולם…

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

תארי פועל מעורפלים עלולים להוביל לדרישות רב משמעיות, שלא ניתן לאמת:

"בדרך כלל", "בערך", "מספיק", "באופן טיפוסי"

למערכת-נתוני-הטיסה תהיה זמינות של לפחות xx% במשך של לפחות yy שעות ברציפות

בעזרת השם

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

טעם לוואי

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

גילויי פתיחות

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

Sוגמה:

הכספומט יציג את מספר חשבון הלקוח, היתרה וכן הלאה
פסוקיות פתוחות עלולות להוביל לדרישות רב משמעיות, שאינן ברות-אימות ושאינן משקפות את צרכי בעלי העניין:
"כולל, אבל לא מוגבל ל…", "וכו'", "וכן הלאה", "וכדומה"
  1. הכספומט יציג את מספר החשבון של הלקוח
  2. הכספומט יציג את היתרה של הלקוח
  3. הכספומט יציג את סוג חשבון הלקוח
  4. הכספומט יציג את מסגרת משיכת היתר של הלקוח
  5. הכספומט יציג….

עשרת הכללים לכתיבת דרישה טובה בקטגוריית הדיוק

הכרנו מספר כללים לכתיבת דרישה "טובה" שהם בקטגורית "דיוק":
#
שם הכלל
הסבר
1
יידוע שמות עצם
השתמש בשמות עצם מיוּדעים (מלווים בה"א הידיעה)
2
לשון פעיל
השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה
3
נושא הדרישה
הקפד שנושא הדרישה יהיה תואם לרמה המוצר או השירות אליה הדרישה מתייחסת
4
מונחים מוגדרים
השתמש אך ורק במונחים המוגדרים במילון (Glossary)
5
כַּמָּתים
המנע מכַּמָּתים (Quantifiers) לא מדויקים
6
יחידות
השתמש ביחידות מוגדרות ומפורשות לציון כמויות
7
תואר הפועל
המנע משימוש בתארי פועל מעורפלים
8
תואר השם
המנע משימוש בתארי שם
9
פסוקיות לוואי
המנע משימוש בפסוקיות לוואי מעורפלות
10
פסוקיות פתוחות
המנע משימוש בפסוקיות פתוחות

לסיום: נקודה למחשבה

אם כל דרישה באוסף הדרישות מקיימת את כל התכונות המאפיינות דרישה "טובה" – האם זה אומר שאוסף הדרישות כולו הוא "טוב" ? נשמח לתשובה בתיבה למטה

 

על המחבר, אלון מודעי

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

רקע

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

 

 

 

 

 

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

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

 

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

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

תכונות של דרישה "טובה" (המשך)

דרישה "טובה" מוגדרת ע"י התכונות הבאות:

ברת-אימות

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

במקום זאת נציע למזמין ניסוח כדלקמן:

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

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

נכונה

דרישה צריכה להיות ביטוי נכון ומדויק של צרכי בעלי העניין.
הרציונל: ביטוי נכון ומדויק מאפשר ביתר קלות לתקף את המוצר/שירות מול צרכי בעלי העניין וציפיותיהם.
תזכורת: תיקוף היא פעולה המתבצעת בתנאים הייעודיים של המוצר או השרות, ומוכיחה שהמוצר או השרות עונה לצרכים.
דוגמא:
תחנת השאיבה תשמור על זרם מים בעוצמה של 120  ליטר לשנייה למשך 30 דקות.
מהו טווח הקבילות ?
  • עד כמה להיצמד לכמות המצויינת?
    • כמה מעל 120 ליטר לשנייה יהיה קביל?
    • כמה מתחת ל- 120 ליטר לשנייה יהיה קביל?
  • עד כמה להיצמד לטווח המצויין?
    • כמה מעל 30 דקות יהיה קביל?
    • כמה מתחת ל- 30 דקות יהיה קביל?
"נכונות" של גדלים בדרישות באה לידי ביטוי בכך שלכל גודל מציינים את הטווח הקביל שלו:
תחנת השאיבה תשמור על זרם מים בעוצמה של ±10120 ליטר לשנייה למשך לפחות 30 דקות.
כעת ברור:
  • שהטווח הקביל של הביצועים מבחינת הזרימה הוא 10± ליטר לשנייה
  • ש-30 דקות הוא מינימום הביצועים הקביל מבחינת משך הזמן

תואמת למוסכמות

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

סיכום: תכונות של דרישה "טובה"

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

מה למדנו ?

עשינו הכרה עם 3 מאפיינים נוספים של דרישה "טובה" והם: שהדרישה תהיה ברת-אימות, נכונה, ותואמת למוסכמות. כמו כן העפנו מבט מסכם באוסף התכונות המלא.

מה הלאה ?

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

על המחבר, אלון מודעי

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

רקע

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

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

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

מה בכלל עושים עם דרישות?

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

תכונות של דרישה "טובה" (המשך)

דרישה "טובה" מוגדרת ע"י התכונות הבאות:

שלמה (Complete)

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

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

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

יחודית (Singular)

דרישה צריכה לבטא רעיון יחיד וברור.
הרציונאל: האפקטיביות של מספר פעילויות הקשורות לדרישות, כגון: גזירה, הקצאה, עקיבות, אימות ותיקוף, תלויה ביכולת לזהות מסרים יחידים. כל שימוש בו"ו החיבור בתוך דרישה צריך לאותת לנו לבדוק אם אכן יש בה מסר יחיד.
דוגמא:
מערכת הבקרה תסגור את שסתום כניסת המים עד שהטמפרטורה תרד ל-850 צלזיוס ואז תפתח אותו.
זה לא קביל מכיוון שהמשפט מכיל שתי דרישות (יש כאן חריגות מכללים נוספים של כתיבת דרישות, שאליהם נגיע בהמשך). כדי שיהיה קביל – צריך לפצל את המשפט לשתי הדרישות. באותה ההזדמנות גם נכמת את הביצועים הנדרשים:
1. מערכת_הבקרה תסגור את שסתום_כניסת_המים, בתוך פחות מ-3 שניות, כאשר טמפרטורת המים בדוד גבוהה מ-85צלזיוס.
2. מערכת_הבקרה תפתח את שסתום_כניסת_המים, בתוך פחות מ-3 שניות, כאשר טמפרטורת המים בדוד נמוכה מ-85צלזיוס.
שימו לב לערכי המילון המשולבים בדרישות.

ישימה (Feasible)

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

אמינות של 100% כמעט שאיננה ברת-השגה. אם נחשוב קדימה לאימות הדרישות – איך נוכיח אמינות של 100% ? וגם לו יכולנו לבנות מערכת כזאת – האם נוכל להרשות זאת לעצמנו מבחינת העלות ?

השוו לעומת זאת את הדרישה שלהלן:

למוצר תהיה אמינות גדולה או שווה ל-98%.
שימו לב שאמינות הוא מונח המוגדר במילון.

כללים לכתיבת דרישה "טובה" (המשך)

זה הזמן לציין עוד כלל חשוב לכתיבת דרישות:

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

תנאי + נושא + נשוא + מושא [ + סייג]

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

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

מה למדנו ?

אוסף התכונות של דרישה "טובה" שבנינו עד עתה הוא:

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

צברנו גם שני כללים לכתיבת דרישה "טובה", והם:

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

מה הלאה ?

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

הערה לפני סיום

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

על המחבר, אלון מודעי

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

רקע

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

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

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

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

משתמשי כללי "המדרשה לדרישות טובות" חווים:

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

תכונות של דרישה "טובה"

דרישה "טובה" מוגדרת ע"י התכונות הבאות:

חיונית (Necessary)

כל דרישה צריכה להיות חיונית.

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

  • אם ניתן לפתור את הבעיה / לענות על הצורך ללא הדרישה – הדרישה לא חיונית.
  • אם לא ניתן להסביר את הסיבה לדרישה – הדרישה לא חיונית.

דוגמא:

המוצר המסופק יצרוך חשמל בכל מהלך פעולתו

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

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

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

זוהי דרישה המגבילה את המוצר להשתמש באנרגיה חשמלית (ולא, למשל, באנרגיה סולארית).

בלתי תלויה ביישום (Implementation-Independent)

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

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

דוגמא:

להכוונת התנועה בצומת יש להשתמש במערכת רמזורים

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

צורך הוא משהו מעולם הבעיה. להלן דוגמא של צורך:

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

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

חד משמעית (Unambiguous)

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

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

דוגמא:

דוגמא:

בפאנל הקדמי תהיה תצוגת זמן

הדרישה היא רב משמעית: האם כל זמן שהוא יהיה קביל ? האם הבהוב רגעי של השעה יהיה מספק ?

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

לעומת זאת:

להיות:

בפאנל הקדמי יוצג באופן רציף הזמן_הנוכחי

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

מונח
הסבר המונח
הזמן_הנוכחי
השעה הנוכחית לפי שעון ירושלים, בפורמט "HH:MM 24 שעות"

כללים לכתיבת דרישה "טובה"

זה הזמן לציין כלל חשוב לכתיבת דרישות:

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

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

מה למדנו ?

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

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

מה הלאה ?

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

על המחבר, אלון מודעי

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

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

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

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

1. גוגל – לארגן את כל המידע בעולם כך שיהיה נגיש ושימושי לכל

“To organize the world‘s information and make it universally accessible and useful.” — Google

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

"To be earth’s most customer centric company; to build a place where people can come to find and discover anything they might want to buy online.  "— Amazon

  1. פייסבוק – לאפשר לאנשים לחלוק חוויות ולהפוך את העולם למקום פתוח ומקושר

"Facebook's mission is to give people the power to share and make the world more open and connected." —Facebook

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

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

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

חלחול החזון מהמנכ"ל עד אחרון העובדים

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

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

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

נכתב בהשראת :

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

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

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

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

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

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

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

המאמר פורסם בגיליון אפריל 2014 של עיתון Information World

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

 

כנגד ארבעה בנים דברה תורת הניהול, אחד חכם, ואחד רשע, ואחד תם, ואחד שאינו יודע לשאול.

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

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

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

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

ואיזה מנהל/ת את/ה ??

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

 

 

אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן.

להרשמה השאירו פרטים

    x