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

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

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

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

ממתק לסיום,

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

כל הפרטים – עובדים הפוך! הדרך החדשה לשיפור עקבי בארגונים.

אורנה קמין

חזון כמצפן מעורר השראה

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

אפשר גם אחרת. על החזון, כמצפן מעורר השראה קראו – כאן.

המדרשה לדרישות "טובות" – מאמר ראשון בסדרה

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

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

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

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

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

עובדים הפוך! הדרך החדשה לשיפור עקבי בארגונים

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

רקע

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

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

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

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

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

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

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

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

חיונית (Necessary)

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

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

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

דוגמא:

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

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

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

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

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

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

דוגמא:

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

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

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

חד משמעית (Unambiguous)

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

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

דוגמא:

דוגמא:

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

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

לעומת זאת:

להיות:

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

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

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

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

מה למדנו ?

עשינו הכרה עם 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

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

"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

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

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

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

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

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

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

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

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

 וחוץ מזה  ……

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

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

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

אי עמידה בהתחייבויות

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

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

שביעות רצון נמוכה של הלקוחות

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

• תלונות
• נטישה
• נתק

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

ניהול לא אופטימאלי

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

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

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

תהליכים לא מיטביים

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

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

בעיות איכות

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

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

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

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

• תסכול, שחיקה,
• עבודה מסביב לשעון
• אין תחושה שיש יד מכוונת/מנהלת

ספקים לא מרוצים

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

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

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

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

• אחראי – Responsible – בעלי עניין שאחריותם לבצע את המטלה, לייצר את התפוקה, ולדאוג לקבלת משוב על איכות עבודתם משאר בעלי העניין הרלוונטיים;
• נושא באחריות – Accountable – בעל עניין שהוא מקבל את ההחלטות, ובין היתר, אחראי לכך שהתפוקה תהיה איכותית; האדם שנמצא בחזית ואליו פונים בשאלות או אפילו תלונות לגבי איכות התפוקה וזמני האספקה שלה. אותו מנהל דואג למשאבים הנדרשים לביצוע המטלה, ובסמכותו להאציל את ביצועה לאנשים אחרים, אחראי-ביצוע. בסיום המשימה, המנהל הנושא באחריות מאשר (בחתימה או בדרך אחרת) שאכן המשימה בוצעה לשביעות רצונו. לכל משימה חייב להיות אדם אחד שהוא נושא באחריות.
• יועץ – Consulted – אדם מומחה בתחום המשימה עימו מתייעצים לגבי ביצועה ו/או מזמינים אותו לסקירה של התוצר
• דורש דיווח – Informed – בעל עניין שמודיעים לו על מצב המשימה. בדרך כלל, בסיומה.

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

מודל R.A.C.I נבנה כדי להתמודד עם אתגר זה.

להלן דוגמה:

איך בונים את טבלת ה- R.A.C.I?

ראשית, רושמים את רשימת הפעילויות שיש לעשות בפרויקט (שורות). לאחר מכן, רושמים את בעלי התפקידים בעמודות. לאחר שהטבלה מוכנה – כותבים בתאים את הקודים המציינים את תרומת בעלי העניין –  R.A.C.I.  עוברים על התאים הריקים כדי לוודא שאכן לאותם בעלי עניין אין כל תרומה או צורך לידיעה במשימה הספציפית. מאידך, אם שמנו יותר מידי משתתפים לביצוע משימה מסוימת, נוודא שאכן כולם חיוניים. משתתפים רבים מידי יגרמו לסרבול ואפילו להפרעה. מספר קטן מידי של משתתפים, יכול להעיד על בעיות בתקשורת. לסיום – סוקרים את התוצאה ומוודאים שיש לפחות Accountable (A) אחד לכל משימה.

לסיכום, מה היה לנו עד כה ?

תהליך ה-R.A.C.I  מתווסף ליצירת לו"ז הפרויקט, בכך שהוא מזהה מראש את כל השותפים בכל משימה ומשימה ((WBS ואת מידת התרומה של כל בעל עניין להצלחת אותן משימות. כך  תורם התהליך לשיפור התקשורת והאיכות בפרויקט.

בקשה להצעת מחיר בנושאים הקשורים להסמכה לתקני AS9100, IATF-16949
בקשה להצעת מחיר בנושאים הקשורים להסמכה לתקני AS9100, IATF-16949
בבקשה לשלוח למייל של שלומית סעד-נוי – Shlomit_sn@sii.org.il
טלפון: 036467871

2) IQC

http://www.iqc.co.il/?categoryId=87406