כותרות TheMarker >
    cafe is going down
    ';

    ניהול פרוייקטים גדולים - הלכה למעשה

    ארכיון

    גורמי הצלחה קריטיים (Key Success Factors) - חלק א'

    0 תגובות   יום שישי , 3/7/09, 12:41

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

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

    כאן נתאר בקצרה את גורמי ההצלחה הקריטיים, בכל אחת מהרמות האלה.


    1. הרמה הממונה/הנהלת החברה

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

     

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

     

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


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

     

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


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


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


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


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

     

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


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

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


    המטרה היא כמובן לבצע Reality Check על המערכת שצפוייה "לנחות עלינו".


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

     

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

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


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


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


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


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

    דרג את התוכן:

      תגובות (0)

      נא להתחבר כדי להגיב

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

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

      /null/text_64k_1#

      אין רשומות לתצוגה

      פרופיל

      Daniel....
      1. שלח הודעה
      2. אוף ליין
      3. אוף ליין

      רשימה

      רשימה