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

באחד הארגונים עימם עבדתי בעבר – היה נהוג לפתח על פי מודל מפל המים (Waterfall). לפי מודל זה, בדיקות המערכת (QA) מתחילות בסוף הפיתוח. פיתוח מוצרים לפי מודל זה גרם לתסכול רב עקב הבעיות הבאות בתחום הבדיקות:

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

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

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

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

תהליך בדיקות הדרגתי

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

בסבב קטן נבדקו:

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

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

ניהול תהליך השינוי

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

1. קבלת מוצרים לבדיקות במצב יציב;
2. תהליך בדיקות מתוכנן ומנוהל;
3. גילוי "הפתעות" / באגים בשלב מוקדם של תהליך הפיתוח;
4. ביצוע בדיקות במקביל לפיתוח – מקצר את לו"ז הפרויקט ומשפר את איכות המוצר.

תוצאות /מדדים – תהליך בדיקות הדרגתי מול סדרתי

כתוצאה מהכנסת השינוי, נמצאו ונמדדו התוצאות הבאות

1. משך זמן מחזור חיי פיתוח כולל בדיקות התקצר ב- 5%;
2. דיוק תהליך הערכת הזמנים (ביצוע מול תכנון) – עלה ב- 15%;
3. כמות התקלות הקריטיות שהתגלו בסבב האחרון ותוקנו – ירדה ב60%;
4. זמן הבדיקות מסיום הפיתוח – התקצר ב-70%;
5. כמות התקלות הקריטיות שהתגלו אצל לקוחות – ירדה ב-8%.

 בנוסף – נצפו התועלות האיכותיות הבאות:

1. שיתוף הפעולה בין צוות הפיתוח לצוות הבדיקות – עלתה;
2. אחריות צוות הפיתוח על איכות המוצר הנמסר לבדיקות – עלתה!
3. רמת הידע של צוות הבדיקות במוצר הנבדק – השתפרה.

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

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

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

מהו מודל CMMI –  Capability Maturity Model Integration לשירות?

מודל שיטתי ל שיפור תהליכי השירות!

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

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

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

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

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

….. ולפרטים בהרחבה

מודל ה- CMMI פותח על ידי  SEI לפני כ- 30 שנה. גרסתו הראשונה (CMM), פותחה על פי דרישת משרד ההגנה האמריקאי (DOD) שחיפש מודל להערכת ספקים, כדי לבחור ספקים על פי רמת התהליכים שלהם. הנחת העבודה, שבהמשך הוכחה כנכונה בשטח, הייתה שאיכות המערכת/מוצר/שירות מושפעת באופן ישיר ומובהק על ידי איכות התהליך שיצר אותם. המודל השתכלל והתרחב במהלך השנים, והינו בשימוש אלפי חברות בארץ ובחו"ל.

מסגרת ה- CMMI כוללת שיטת מבדק לקביעת רמת התהליכים (קיימות 5 רמות), וכן הדרכות. כיוון שהמודל והמבדקים מתבצעים באותה צורה קפדנית בכל העולם, משמשים הציונים המתקבלים במבדק להשוואת (Benchmarking) איכות התהליכים בין הארגונים. כמו כן, מכיל המודל תהליכים מיטביים (Best Practices) מהניסיון שהצטבר בשימוש בו.

למודל ה- CMMI שלושה מופעים ליישומים שונים: 1) פיתוח מוצרים ומערכות; 2) רכש; 3) שירות. מודל  CMMI לשירות נולד בתחילת 2009. הוא מדריך את הגופים בתוך הארגונים הנותנים שירות ללקוחות פנימיים או חיצוניים.

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

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

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

מדוע נדרש מודל CMMI לשירות?

המודל נדרש כיוון שהצורך בשיפור תהליכי שירות הולך וגדל. ארגונים נותני שירות מהווים כ- 80% מהכלכלה הגלובלית העולמית. מודל CMMI לשירות עונה לצרכים ומאפיינים משותפים של ארגונים נותני שירות מתחומים מגוונים:

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

יישום מודל CMMI  לשירות

קיימות שתי אפשריות ליישום מודל CMMI: מדורג ורציף.

המודל המדורג (Staged)

המודל הרציף (Continuous)

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

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

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

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

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

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

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

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

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

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

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