מקור התמונה: הויקיפדיה העברית
בסרט גם הטוב כמו יתר חבריו נטול עכבות מוסריות. רבים משתמשים בשם סרט זה כשהם כותבים על שלושה טיפוסים של אנשים או של מוצרים ומצמידים להם את הכינויים: הטוב, הרע והמכוער.
כך למשל בראשית ימי מתודולוגית ה Object Oriented בתכנות מחשבים ראיתי מאמר שכותרתו התייחסה לטוב הרע והמכוער בשפות תכנות Object Oriented.
כותבי המאמר היו יצרני שפת תכנות בשם SmallTalk (הטוב במאמר). הרע היה שפת התכנות COBOL והמכוער שפת התכנות ++ C.
כמו בחיים לא תמיד הטובים שורדים: מספר שנים מועט אחרי כתיבת המאמר, פיתחו ג'ים גוסלינג וחברת סאן את שפת התכנות Java. כמו SmallTalk האלגנטית ממנה, היא שפת Object Oriented טהורה. השוק העדיף את Java מסיבות של ביצועים טובים יותר ושווק מוצלח יותר ו Java תפסה את מקומה של SmallTalk שנעלמה מהשוק.
השפות ההיברידיות COBOL ו ++ C שרדו עד היום.
גם אני השתמשתי בטוב הרע והמכוער בפוסט שכותרתו
Wikipedia The Good the Bad and the Ugly.
החלטתי לכתוב שלושה פוסטים בסדרת הטיפולוגיה של לקוחות וכמה מפתיע הם יקראו הטוב, הרע והמכוער.
הפוסט הנוכחי הוא אופטימי ולכן מוקדש לטוב.
הטוב
הלקוח הטוב יודע שאינו יודע הכל, בשונה מהלקוח היודע הכל. אבל הוא יודע להגדיר את גבולות הידע שלו: מה הם הדברים שחסר לו בהם ידע וניסיון ומה הם הדברים שבהם דווקא לו יש יתרון ביחס ליועץ.
בגלל שהוא יודע שהוא יודע, הוא אינו מבטל את דעתו בפני היועץ כמו הלקוח המתבטל בפני היועץ ואינו מקבל באופן אוטומטי את דעתו של ספק מסוים, כמו הלקוח השבוי (זה שאינו מקבל באופן אוטומטי את דעתו של ספק אינו מונע ממנו להבין את היתרונות והחסרונות היחסיים של הספק ביחס אליו וליועץ ולתת למידע ולדעה של הספק משקל ראוי).
התוצאה של היכולת של הלקוח הטוב להגדיר את גבולות הידע שלו עשוי להיות הגדרה טובה של תפקידו של היועץ והמשימות שלו: היועץ צריך להשלים ידע וניסיון שחסר ללקוח.
באופן זה הלקוח והיועץ מתפקדים כצוות המכוון למטרה ברורה ומוגדרת.
אבל מיהו הלקוח? האם מדובר במנהל בארגון הלקוח בייעוץ במחשוב? אולי הלקוח הם קבוצה קטנה של מנהלים או אולי כל עובדי המחשוב של הארגון? או אולי גם בעובדים או מנהלים במחלקות העסקיות של הארגון?
האם הלקוח בכלכלת המשפחה הוא אותו בן משפחה שפנה ליועץ? אולי זה בן המשפחה ובן/בת הזוג שלו/שלה? אולי כל בני המשפחה הגרעינית כולל הילדים הם הלקוח?
בייעוץ בכלכלת המשפחה קל יותר לתחם את האנשים הנכללים בהגדרה של לקוח. אין ספק, שגם בן/בת הזוג של הפונה ליועץ נכללים בהגדרה של לקוח וחייבים להיות מעורבים בתהליך הייעוץ. במקרה שרק אחד מבני הזוג מעורב, האחר עשוי לפעול באופן שונה מהמלצות היועץ שלא ידועות לו או שאינו מסכים להן. התוצאות יהיו בהתאם. רצוי שגם ילדים ובפרט ילדים בגיל העשרה ומעלה יכללו בהגדרה של הלקוח, משום שעשויה להיות להם השפעה לא מבוטלת על ההתנהלות הכלכלית של היחידה המשפחתית.
בארגון המקבל ייעוץ קשה יותר לתחם במדויק את האנשים המעורבים, אבל ללא ספק ברוב המקרים המושג לקוח כולל יותר מאדם אחד.
מכאן נובע שהתיאור המתייחס ללקוח הטוב צריך להתייחס לקבוצת האנשים המעורבים ועל מנת שהלקוח יוגדר כטוב, כולם או רובם צריכים לפעול על פי המאפיינים של לקוח טוב.
כך למשל לא אגדיר כלקוח טוב, לקוח בעברי הרחוק, שהמנמ"ר אכן תפקד על פי המאפיינים המתוארים כאן. אחד מהמנהלים הבכירים הכפופים לו, הזמין אותי לשיחה והסביר לי שאין לו שום דבר אישי נגדי אבל הוא לא ישתף איתי פעולה. הסיבה: המנמ"ר הביא אותי והוא לא מוכן לשתף פעולה עם המנמ"ר.
כמובן שהיו לקוחות נוספים בארגונים אחרים שפעלו בדפוס דומה. ההבדל היחיד היה, שאלה שלא שיתפו פעולה לא אמרו זאת באופן גלוי.
הלקוח הטוב מצפה לקבל תוצרים מוגדרים ומתייחס אליהם עניינית. הוא אינו מנתח משותק ולכן להתייחסות מתלווה גם רצף מתוכנן של פעולות ביצוע מעשיות.
הטוב - סיכום נקודות עיקריות
1. מודע ליכולות ולמגבלות שלו
2. משתמש בכישורים, בידע וביכולות של היועץ
3. מקבל החלטות באופן ענייני
4. מסוגל לבצע החלטות
5. שיתוף פעולה של כל המעורבים: אנשים הנכללים בהגדרת הלקוח והיועץ.
אופן בחירת Case Study לדוגמה
למזלי, היו לי לא מעט לקוחות גם בייעוץ במערכות מידע וגם בייעוץ בכלכלת המשפחה, שבמידה רבה עונים על ההגדרה של הלקוח הטוב.
כשכתבתי על לקוחות מסוגים אחרים נמנעתי לציין שמות מהטעם הפשוט שקרוב לוודאי שאותו לקוח יבחר בעתיד לא להסתייע בשירותי הייעוץ שלי. במקרה של הלקוח הטוב עילום השם אינו הכרחי כאשר מדובר על ייעוץ לארגונים.
לעומת זאת בייעוץ ואימון בכלכלת המשפחה היועץ מחויב בסודיות, משום שמדובר בעניינים אישיים רגישים לא סביר להזכיר את שמו של לקוח בדף אינטרנט (לכל היותר ניתן בהסכמתו לתת את מספר הטלפון כממליץ למשפחות השוקלות קבלת ייעוץ ואימון).
לפיכך בחרתי להציג Case Study של לקוח טוב מעולם המחשוב. בחרתי במתכוון מקרה, שכישלוני בייעוץ במקרה של לקוח שאינו מתאים להגדרה של לקוח טוב יהיה ברור ומובן לגמרי (נדמה לי שרוב היועצים האחרים היו נכשלים אף הם בתנאים כאלה).
הלקוח שבחרתי להציג הוא שירות עיבודים ממוכנים (שע"מ) של רשות המיסים במשרד האוצר ותחום הייעוץ עתיק היומין הוא באג 2000.
Case Study : ייעוץ לשע"מ בנושא באג 2000
בסוף שנות ה 90 של המאה הקודמת היה חשש מקריסת מערכות מחשוב בתחילת שנת 2000 בגלל שהשנה בשדות התאריך יוצגה בשתי ספרות. לך תדע האם 00 למשל מייצג את שנת 1900 או שנת 2000.
קוריוז פשוט המדגים זאת הוא מקרה שהיה: קשיש בן 105 קיבל הזמנה ללימודים בגן חובה משום שהמערכת בה יוצגה השנה באמצעות שתי הספרות 05 הניחה שהוא בן 5.
מרבית הארגונים ביצעו פרויקטים של התאמת שדות השנה בתאריך בכל מערכות המחשוב שלהם. זו הייתה היערכות מורכבת ועתירת משאבים וזמן כשברוב המקרים תחילת הפרויקט הייתה מספר שנים לפני תאריך היעד 1.1.2000, שבשונה מפרויקטי מחשוב אחרים לא ניתן לדחותו.
הפנייה אלי לייעץ לשע"מ הייתה באוקטובר 1999. נאמר לי שמבקר המדינה הוציא דוח על פיו עלולה מערכת גביית המיסים של מדינת ישראל להתמוטט ביום הראשון של שנת 2000. הוטל עלי לבדוק האם החשש אמיתי או מופרך.
ההיערכות שלי לביצוע הייעוץ
הבעיה העיקרית בייעוץ זה הייתה הזמן הקצר לביצועו. במשך פחות מחודשיים הייתי צריך להכיר מספר רב של מערכות ותשתיות ולהבין האם ובאיזו מידה הן מוכנות לשנת 2000.
בעיות נוספות ובעיות הנגזרות מבעיה זו והפתרונות שלי לבעיות:
1. ראיתי את התפקיד שלי כיועץ באופן רחב יותר מאשר הצגת דוח.
חשבתי שאין די בדוח האומר שבהסתברות 70% או 30% או כל אחוז אחר שתבחרו יהיו בעיות חמורות במערכות בתחילת שנת 2000. בראייתי תפקידי כלל גם הצבעה על בעיות על מערכות ורכיבים במערכות החשופים לבעיות וגם הכוונת הלקוח לאופן הפתרון (במידה שהוא זקוק לכך).
פתרון: נדרש תכנון פגישות בטווח זמן קצר עם מנהלי המערכות ותכנון הנושאים והשאלות בכל פגישה על מנת שניתן יהיה למפות את הפונקציונליות של המערכות ואת הבעיות בהן.
2. המתודולוגיות והשיטות המקובלות לא ישימות במקרה זה, משום שהן בנויות לעבודה שיטתית ומסודרת האורכת לפחות חצי שנה.
פתרון: בניית מתודולוגיה ייחודית שלי על בסיס שינוי והתאמה של מתודולוגיות ידועות בתחום לאילוצי הזמן הקצר. המתודולוגיה כללה זיהוי מידי של בעיות וייחוס רמת חומרה לבעיה. בעיות ברמות חומרה גבוהות מוצפות מידית לדרגים ניהוליים של הלקוח על מנת שיוכל להיערך במהירות לטיפול בהן.
3. היערכות לתסריט שבו לא ניתן לפתור את כל הבעיות עד תחילת שנת 2000.
פתרון: הגדרת סדרי עדיפויות על פי החשיבות העסקית של המערכות ולא על פי חומרת הבעיות. קיימות שתי גישות לסדר עדיפויות:
א. גישה טכנית המטפלת קודם כל בבעיות הטכנולוגיות החמורות ביותר וביתר הבעיות בסדר יורד על פי רמת החומרה בהיבט הטכנולוגי.
ב. גישה בה בוחנים את החשיבות העסקית ומטפלים קודם במערכות החשובות מבחינה עסקית גם אם הבעיות הטכניות בהן אינן כה חמורות כמו הבעיות במערכות אחרות.
בהקשר הספציפי הנדון, המשמעות של הבחירה שלי בגישה ב' היא המלצה על טיפול בבעיות במערכות כמו: גביית מס הכנסה מחברות, מעצמאיים ומשכירים ומערכת מס ערך מוסף הגובות בסך הכל סכומי מס גבוהים, גם אם המשמעות תהיה שמערכת הגובה מס עלום שם בסכום כולל נמוך עלולה לקרוס בתחילת שנת 2000.
לבחירה בגישה ב' משמעות נוספת בהקשר הספציפי של הלקוח: בלוחות הזמנים הצפופים צריך גם לקבל הערכה גסה לפחות של עדיפות כל מערכת מבחינה עסקית ולהתייחס אליה.
זו כבר נקודה שרלבנטית גם לייעוצים עכשוויים בתחומים כמו SOA, BPM ומחשוב ענן.
גם בנושאים אלה צריך לקבל החלטות של סדרי עדיפויות: האם מתחילים לטפל במה שהכי גרוע טכנולוגית או במקומות שחשוב מבחינה עסקית לטפל קודם?. בתחום של SOA בו עסקתי לא מעט, ההעדפה שלי היא להתחיל במקרים רבים בנקודות הכואבות (Pain Points) לארגון. פוסט זה אינו המקום המתאים להרחבת הדיון בנושא.
4. במקרה של התרחשות תקלה מהותית שאינה קשורה בבאג 2000 בתחילת שנת 2000 ייחסו אותה לחוסר היערכות נאותה לבאג 2000.
לפי חוק מרפי מאד סביר שזה עלול להתרחש.
הפתרון: על אף קוצר הזמן נדרשת התרעה גם על בעיות משמעותיות שמתגלות במהלך העבודה ואינן קשורות לבאג 2000 על מנת שגם הן יטופלו.
ביצוע הייעוץ
הייעוץ בוצע לשביעות רצונו המלאה של הלקוח. קוימו פגישות מסודרות עם כל מנהלי היישומים והתשתיות, שמופו מבחינה טכנולוגית, מבחינה עסקית ומבחינת מוכנות לשנת 200.
במהלך הייעוץ אותרו וטופלו על ידי הלקוח בעיות שהיו עלולות להביא לכשלים במערכות בתחילת שנת 2000. מספר מצומצם של בעיות חמורות חייבו שימוש במנגנון ההתראה המידית שהיה חלק מהמתודולוגיה (ראו סעיף 2 בהיערכות לייעוץ). אותרה גם בעיה
המסקנה העיקרית הייתה שמערכות לא צפויות להתמוטט בתחילת שנת 2000. הדוח כלל ניתוח סיכונים של כל מערכת מבחינת הסתברות לתקלה והמשמעות העסקית של תקלה (רמת החומרה של התקלה). המציאות בשטח בתחילת שנת 2000 תאמה את המסקנה.
גורמי ההצלחה ב Case Study
ללא ספק המפתח העיקרי להצלחה היה שיתוף הפעולה המלא של כל העובדים בארגון מהמנכ"ל ועד אחרון המתכנתים. בפרק זמן כה קצר בנושאים כל כך רגישים וקריטיים יועץ אינו יכול להתמודד לבד עם אוסף של מערכות גדולות ומורכבות.
מישהו מתאר לעצמו שניתן היה לקיים למעלה מ 20 פגישות בפחות מחודש בארגון בו מנהל או עובד לא משתף פעולה עם המנכ"ל?
האם ניתן היה להוציא מהפגישות תמונה כוללת של המערכות והתשתיות המורכבות או מידת המוכנות לשנת 200 ללא שיתוף פעולה מלא?
אין ספק שהלקוח הטוב הוא זה שהביא לטיפול תכליתי ומהיר בבעיות שנמצאו.
כך למשל בראשית ימי מתודולוגית ה Object Oriented בתכנות מחשבים ראיתי מאמר שכותרתו התייחסה לטוב הרע והמכוער בשפות תכנות Object Oriented.
כותבי המאמר היו יצרני שפת תכנות בשם SmallTalk (הטוב במאמר). הרע היה שפת התכנות COBOL והמכוער שפת התכנות ++ C.
כמו בחיים לא תמיד הטובים שורדים: מספר שנים מועט אחרי כתיבת המאמר, פיתחו ג'ים גוסלינג וחברת סאן את שפת התכנות Java. כמו SmallTalk האלגנטית ממנה, היא שפת Object Oriented טהורה. השוק העדיף את Java מסיבות של ביצועים טובים יותר ושווק מוצלח יותר ו Java תפסה את מקומה של SmallTalk שנעלמה מהשוק.
השפות ההיברידיות COBOL ו ++ C שרדו עד היום.
גם אני השתמשתי בטוב הרע והמכוער בפוסט שכותרתו
Wikipedia The Good the Bad and the Ugly.
החלטתי לכתוב שלושה פוסטים בסדרת הטיפולוגיה של לקוחות וכמה מפתיע הם יקראו הטוב, הרע והמכוער.
הפוסט הנוכחי הוא אופטימי ולכן מוקדש לטוב.
הטוב
הלקוח הטוב יודע שאינו יודע הכל, בשונה מהלקוח היודע הכל. אבל הוא יודע להגדיר את גבולות הידע שלו: מה הם הדברים שחסר לו בהם ידע וניסיון ומה הם הדברים שבהם דווקא לו יש יתרון ביחס ליועץ.
בגלל שהוא יודע שהוא יודע, הוא אינו מבטל את דעתו בפני היועץ כמו הלקוח המתבטל בפני היועץ ואינו מקבל באופן אוטומטי את דעתו של ספק מסוים, כמו הלקוח השבוי (זה שאינו מקבל באופן אוטומטי את דעתו של ספק אינו מונע ממנו להבין את היתרונות והחסרונות היחסיים של הספק ביחס אליו וליועץ ולתת למידע ולדעה של הספק משקל ראוי).
התוצאה של היכולת של הלקוח הטוב להגדיר את גבולות הידע שלו עשוי להיות הגדרה טובה של תפקידו של היועץ והמשימות שלו: היועץ צריך להשלים ידע וניסיון שחסר ללקוח.
באופן זה הלקוח והיועץ מתפקדים כצוות המכוון למטרה ברורה ומוגדרת.
אבל מיהו הלקוח? האם מדובר במנהל בארגון הלקוח בייעוץ במחשוב? אולי הלקוח הם קבוצה קטנה של מנהלים או אולי כל עובדי המחשוב של הארגון? או אולי גם בעובדים או מנהלים במחלקות העסקיות של הארגון?
האם הלקוח בכלכלת המשפחה הוא אותו בן משפחה שפנה ליועץ? אולי זה בן המשפחה ובן/בת הזוג שלו/שלה? אולי כל בני המשפחה הגרעינית כולל הילדים הם הלקוח?
בייעוץ בכלכלת המשפחה קל יותר לתחם את האנשים הנכללים בהגדרה של לקוח. אין ספק, שגם בן/בת הזוג של הפונה ליועץ נכללים בהגדרה של לקוח וחייבים להיות מעורבים בתהליך הייעוץ. במקרה שרק אחד מבני הזוג מעורב, האחר עשוי לפעול באופן שונה מהמלצות היועץ שלא ידועות לו או שאינו מסכים להן. התוצאות יהיו בהתאם. רצוי שגם ילדים ובפרט ילדים בגיל העשרה ומעלה יכללו בהגדרה של הלקוח, משום שעשויה להיות להם השפעה לא מבוטלת על ההתנהלות הכלכלית של היחידה המשפחתית.
בארגון המקבל ייעוץ קשה יותר לתחם במדויק את האנשים המעורבים, אבל ללא ספק ברוב המקרים המושג לקוח כולל יותר מאדם אחד.
מכאן נובע שהתיאור המתייחס ללקוח הטוב צריך להתייחס לקבוצת האנשים המעורבים ועל מנת שהלקוח יוגדר כטוב, כולם או רובם צריכים לפעול על פי המאפיינים של לקוח טוב.
כך למשל לא אגדיר כלקוח טוב, לקוח בעברי הרחוק, שהמנמ"ר אכן תפקד על פי המאפיינים המתוארים כאן. אחד מהמנהלים הבכירים הכפופים לו, הזמין אותי לשיחה והסביר לי שאין לו שום דבר אישי נגדי אבל הוא לא ישתף איתי פעולה. הסיבה: המנמ"ר הביא אותי והוא לא מוכן לשתף פעולה עם המנמ"ר.
כמובן שהיו לקוחות נוספים בארגונים אחרים שפעלו בדפוס דומה. ההבדל היחיד היה, שאלה שלא שיתפו פעולה לא אמרו זאת באופן גלוי.
הלקוח הטוב מצפה לקבל תוצרים מוגדרים ומתייחס אליהם עניינית. הוא אינו מנתח משותק ולכן להתייחסות מתלווה גם רצף מתוכנן של פעולות ביצוע מעשיות.
לבסוף, הלקוח הטוב גם דואג לביצוע סביר של הצדדים המנהליים כגון: 1. תשלום ליועץ בזמן ובסכום שסוכם, ללא ביורוקרטיה עודפת.
2. תנאי עבודה בסיסיים נאותים ליועץ, כגון: מקום ישיבה סביר, עזרים כמו מחשב וחיבור לאינטרנט, נגישות לאוכל ולחניה.
הטוב - סיכום נקודות עיקריות
1. מודע ליכולות ולמגבלות שלו
2. משתמש בכישורים, בידע וביכולות של היועץ
3. מקבל החלטות באופן ענייני
4. מסוגל לבצע החלטות
5. שיתוף פעולה של כל המעורבים: אנשים הנכללים בהגדרת הלקוח והיועץ.
אופן בחירת Case Study לדוגמה
למזלי, היו לי לא מעט לקוחות גם בייעוץ במערכות מידע וגם בייעוץ בכלכלת המשפחה, שבמידה רבה עונים על ההגדרה של הלקוח הטוב.
כשכתבתי על לקוחות מסוגים אחרים נמנעתי לציין שמות מהטעם הפשוט שקרוב לוודאי שאותו לקוח יבחר בעתיד לא להסתייע בשירותי הייעוץ שלי. במקרה של הלקוח הטוב עילום השם אינו הכרחי כאשר מדובר על ייעוץ לארגונים.
לעומת זאת בייעוץ ואימון בכלכלת המשפחה היועץ מחויב בסודיות, משום שמדובר בעניינים אישיים רגישים לא סביר להזכיר את שמו של לקוח בדף אינטרנט (לכל היותר ניתן בהסכמתו לתת את מספר הטלפון כממליץ למשפחות השוקלות קבלת ייעוץ ואימון).
לפיכך בחרתי להציג Case Study של לקוח טוב מעולם המחשוב. בחרתי במתכוון מקרה, שכישלוני בייעוץ במקרה של לקוח שאינו מתאים להגדרה של לקוח טוב יהיה ברור ומובן לגמרי (נדמה לי שרוב היועצים האחרים היו נכשלים אף הם בתנאים כאלה).
הלקוח שבחרתי להציג הוא שירות עיבודים ממוכנים (שע"מ) של רשות המיסים במשרד האוצר ותחום הייעוץ עתיק היומין הוא באג 2000.
Case Study : ייעוץ לשע"מ בנושא באג 2000
בסוף שנות ה 90 של המאה הקודמת היה חשש מקריסת מערכות מחשוב בתחילת שנת 2000 בגלל שהשנה בשדות התאריך יוצגה בשתי ספרות. לך תדע האם 00 למשל מייצג את שנת 1900 או שנת 2000.
קוריוז פשוט המדגים זאת הוא מקרה שהיה: קשיש בן 105 קיבל הזמנה ללימודים בגן חובה משום שהמערכת בה יוצגה השנה באמצעות שתי הספרות 05 הניחה שהוא בן 5.
מרבית הארגונים ביצעו פרויקטים של התאמת שדות השנה בתאריך בכל מערכות המחשוב שלהם. זו הייתה היערכות מורכבת ועתירת משאבים וזמן כשברוב המקרים תחילת הפרויקט הייתה מספר שנים לפני תאריך היעד 1.1.2000, שבשונה מפרויקטי מחשוב אחרים לא ניתן לדחותו.
הפנייה אלי לייעץ לשע"מ הייתה באוקטובר 1999. נאמר לי שמבקר המדינה הוציא דוח על פיו עלולה מערכת גביית המיסים של מדינת ישראל להתמוטט ביום הראשון של שנת 2000. הוטל עלי לבדוק האם החשש אמיתי או מופרך.
ההיערכות שלי לביצוע הייעוץ
הבעיה העיקרית בייעוץ זה הייתה הזמן הקצר לביצועו. במשך פחות מחודשיים הייתי צריך להכיר מספר רב של מערכות ותשתיות ולהבין האם ובאיזו מידה הן מוכנות לשנת 2000.
בעיות נוספות ובעיות הנגזרות מבעיה זו והפתרונות שלי לבעיות:
1. ראיתי את התפקיד שלי כיועץ באופן רחב יותר מאשר הצגת דוח.
חשבתי שאין די בדוח האומר שבהסתברות 70% או 30% או כל אחוז אחר שתבחרו יהיו בעיות חמורות במערכות בתחילת שנת 2000. בראייתי תפקידי כלל גם הצבעה על בעיות על מערכות ורכיבים במערכות החשופים לבעיות וגם הכוונת הלקוח לאופן הפתרון (במידה שהוא זקוק לכך).
פתרון: נדרש תכנון פגישות בטווח זמן קצר עם מנהלי המערכות ותכנון הנושאים והשאלות בכל פגישה על מנת שניתן יהיה למפות את הפונקציונליות של המערכות ואת הבעיות בהן.
2. המתודולוגיות והשיטות המקובלות לא ישימות במקרה זה, משום שהן בנויות לעבודה שיטתית ומסודרת האורכת לפחות חצי שנה.
פתרון: בניית מתודולוגיה ייחודית שלי על בסיס שינוי והתאמה של מתודולוגיות ידועות בתחום לאילוצי הזמן הקצר. המתודולוגיה כללה זיהוי מידי של בעיות וייחוס רמת חומרה לבעיה. בעיות ברמות חומרה גבוהות מוצפות מידית לדרגים ניהוליים של הלקוח על מנת שיוכל להיערך במהירות לטיפול בהן.
3. היערכות לתסריט שבו לא ניתן לפתור את כל הבעיות עד תחילת שנת 2000.
פתרון: הגדרת סדרי עדיפויות על פי החשיבות העסקית של המערכות ולא על פי חומרת הבעיות. קיימות שתי גישות לסדר עדיפויות:
א. גישה טכנית המטפלת קודם כל בבעיות הטכנולוגיות החמורות ביותר וביתר הבעיות בסדר יורד על פי רמת החומרה בהיבט הטכנולוגי.
ב. גישה בה בוחנים את החשיבות העסקית ומטפלים קודם במערכות החשובות מבחינה עסקית גם אם הבעיות הטכניות בהן אינן כה חמורות כמו הבעיות במערכות אחרות.
בהקשר הספציפי הנדון, המשמעות של הבחירה שלי בגישה ב' היא המלצה על טיפול בבעיות במערכות כמו: גביית מס הכנסה מחברות, מעצמאיים ומשכירים ומערכת מס ערך מוסף הגובות בסך הכל סכומי מס גבוהים, גם אם המשמעות תהיה שמערכת הגובה מס עלום שם בסכום כולל נמוך עלולה לקרוס בתחילת שנת 2000.
לבחירה בגישה ב' משמעות נוספת בהקשר הספציפי של הלקוח: בלוחות הזמנים הצפופים צריך גם לקבל הערכה גסה לפחות של עדיפות כל מערכת מבחינה עסקית ולהתייחס אליה.
זו כבר נקודה שרלבנטית גם לייעוצים עכשוויים בתחומים כמו SOA, BPM ומחשוב ענן.
גם בנושאים אלה צריך לקבל החלטות של סדרי עדיפויות: האם מתחילים לטפל במה שהכי גרוע טכנולוגית או במקומות שחשוב מבחינה עסקית לטפל קודם?. בתחום של SOA בו עסקתי לא מעט, ההעדפה שלי היא להתחיל במקרים רבים בנקודות הכואבות (Pain Points) לארגון. פוסט זה אינו המקום המתאים להרחבת הדיון בנושא.
4. במקרה של התרחשות תקלה מהותית שאינה קשורה בבאג 2000 בתחילת שנת 2000 ייחסו אותה לחוסר היערכות נאותה לבאג 2000.
לפי חוק מרפי מאד סביר שזה עלול להתרחש.
הפתרון: על אף קוצר הזמן נדרשת התרעה גם על בעיות משמעותיות שמתגלות במהלך העבודה ואינן קשורות לבאג 2000 על מנת שגם הן יטופלו.
ביצוע הייעוץ
הייעוץ בוצע לשביעות רצונו המלאה של הלקוח. קוימו פגישות מסודרות עם כל מנהלי היישומים והתשתיות, שמופו מבחינה טכנולוגית, מבחינה עסקית ומבחינת מוכנות לשנת 200.
במהלך הייעוץ אותרו וטופלו על ידי הלקוח בעיות שהיו עלולות להביא לכשלים במערכות בתחילת שנת 2000. מספר מצומצם של בעיות חמורות חייבו שימוש במנגנון ההתראה המידית שהיה חלק מהמתודולוגיה (ראו סעיף 2 בהיערכות לייעוץ). אותרה גם בעיה
המסקנה העיקרית הייתה שמערכות לא צפויות להתמוטט בתחילת שנת 2000. הדוח כלל ניתוח סיכונים של כל מערכת מבחינת הסתברות לתקלה והמשמעות העסקית של תקלה (רמת החומרה של התקלה). המציאות בשטח בתחילת שנת 2000 תאמה את המסקנה.
גורמי ההצלחה ב Case Study
ללא ספק המפתח העיקרי להצלחה היה שיתוף הפעולה המלא של כל העובדים בארגון מהמנכ"ל ועד אחרון המתכנתים. בפרק זמן כה קצר בנושאים כל כך רגישים וקריטיים יועץ אינו יכול להתמודד לבד עם אוסף של מערכות גדולות ומורכבות.
מישהו מתאר לעצמו שניתן היה לקיים למעלה מ 20 פגישות בפחות מחודש בארגון בו מנהל או עובד לא משתף פעולה עם המנכ"ל?
האם ניתן היה להוציא מהפגישות תמונה כוללת של המערכות והתשתיות המורכבות או מידת המוכנות לשנת 200 ללא שיתוף פעולה מלא?
אין ספק שהלקוח הטוב הוא זה שהביא לטיפול תכליתי ומהיר בבעיות שנמצאו.
