‏הצגת רשומות עם תוויות PPM. הצג את כל הרשומות
‏הצגת רשומות עם תוויות PPM. הצג את כל הרשומות

כמות ההשקעה הנדרשת בשדרוג למיקרוסופט פרוז'קט 2010 - MS Project 2010

לאחרונה עשיתי עבודה עבור אחד הלקוחות שלנו, אשר נמצא במהלך השדרוג של MS PR 2010 . מהו הגדול ההשקעה או אורך הפרויקט מסוג זה? לאחר סקר קצר, יצא כי יש להיערך לפרויקט של  כחצי שנה ומעלה; תלוי, כמובן, בגודל הארגון והשימוש הנוכחי ב Project Server


בעצם, מדובר בפרויקט ב- 2 שלבים: שדרוג ל- 2007 והסבה ל- 2010

גודל הפרויקט תלוי גם באם משדרגים את EPM בלבד או נעשה פרויקט יחד עם PPM

גורמים שחייבים לקחת בחשבון:

• גודל DB

• גודל ומורכבות הפרויקטים המנוהלים בארגון, כמות הגאנטים

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

• מספר אתרי פרויקט ב SP – המרת אתרי פרויקטים כולל מדדים מעל הגאנטים (יכול להיות שיהיה מדובר במיגרציה ידנית)

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

• מוצרי צד שלישי וכמות הממשקים (HD/ TFS/ QC) , האם יש צורך לשדרג את Project party?

• הדרכות – בין MS PR 2003 – 2010 יש הבדלים לא מבוטלים


לצורך השדורג נדרש:

• מנהל פרויקט במשרה מלאה למינימום של 3 חודשים

• מפתחים

• אנשי SharePoint לפיתוח אתרי פרויקטים

• אנשי תשתיות

• DBA

• SQL

• אנשי QA (והרבה!) – שדרוג Project Server טומן בחובו לא מעט סיכונים (אובדן מידע, בעיות גישה, בעיות ביצועים ועוד)

• אנשי הדרכה והטמעה

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

תוכנות PPM לעומת SharePoint חלק 2

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


נתק מס '4: Microsoft Project ו-SharePoint הם כל מה שאתה צריך לניהול יעיל של PPM חברות רבות מנהלות את PPM באמצעות תוכנות חלופות, כגון: Microsoft Project ו-SharePoint, גם כדי לענות על הצרכי תיעדוף של פרויקטי IT שלהם.
לא מעט מנהלי IT מציינים כי הם מרוצים ממערכת SharePoint אחרי שנעשו התאמות הנדרשות. יחד עם זאת, ל- MS project ו- SP חסרות חלק מהפונקציונליות שנמצאות בפתרונות שתוכננו במיוחד עבור PPM. המערכת הייתה יכולה להיות הרבה יותר טובה אם הייתה מקשרת הקצאת משאבים לתוכנית עבודה של צוות IT ומעקב אחרי עלויות. אין ספק כי
המערכת אינה מושלמת, היא מאפשר לבצע רק חלק מהאופציות הקיימות במערכות PPM, אם כסף איננו הפרמטר העיקרי בקבלת החלטות לבחירת המערכת, כלי PPM ייענו בצורה טובה יותר על צרכי החברה.

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

PPM לפי המספרים
על פי הסקר האחרון של SearchCIO 73% של יותר מ 300 ארגונים אמרו כי בארגונם קיים תהליך רשמי של ניהול הדרישות ותיעדוף פרויקטי IT, אבל מעט מאוד משתמשים בתוכנת PPM לניהול תהליך זה.
• 38% מתוך 276 משיבים משתמשים בתוכנה ייעודית ל PPM.
• מתוך הארגונים ללא כלי PPM, 63% לא מתכוונים לקנות פתרון PPM, ועוד 28% לא היו בטוחים.
• 7% מתכננים לקנות תוכנת PPM אבל לא השנה.
• 2% מתכננים לקנות את זה השנה.

תוכנות PPM לעומת SharePoint

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


ארגונים שעדיין לא השקיעו בתוכנה לניהול פרויקטים ופורטפוליו ארגוני - PPM, כלל אינם ממהרים לעשות זאת, כך מראה מחקר חדש של SearchCIO.com. ארגונים אומרים שבדרך כלל מדובר בתוכנות יקרות מידי, אשר לאו דווקא נותנות מענה לנקודה הכי כואבת ב- PPM – הקצאה וניהול משאבים, וניתוח עלות -תועלת. וכך, הרבה מהארגונים ממשיכים להשתמש ב-Microsoft Project ופתרונות המפותחים בבית בעזרת SharePoint כדי לנהל את פרויקטי ה- IT ואת תיקי הפורטפוליו שלהם.


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


נתק מס '1: תוכנת PPM לא נמצאת בהישג ידם של רוב הארגונים. לעיתים עלות התוכנה הינה הגורם המרתיע להשקעה בכלי PPM, במיוחד בתקופת המיתון וצמצום בתקציבי IT. לא מעט חברות לא מוכנות להיכנס לפרויקטי PPM בגלל עלויות גבוהות ופונקציונליות מתוחכמת של כלי PPM הנוקשים.
"אנו פשוט לא יכולים להרשות את זה לעצמנו," אומר Vince Fattore אחד המנמ"רים מארה"ב. "צריך להחזיק צוות שלם על מנת לתחזק את התונכה. זה כמעט וכאילו אתה קונה מערכת ERP חדשה."
Fattore בחן מספר פתרונות PPM והחליט שהם פשוט יקרים מדי ולא גמישים מספיק עבור הצרכים שלו. במקום זאת, הוא השקיע בהתאמה אישית של Microsoft Project ובבניית פתרון PPM על SharePoint. גישה זו היתה פחות יקרה ומוצר השתלב בקלות עם מוצרים אחרים של מיקרוסופט בחברה, הוא אמר.
למרות שפתרון PPM מלא יכול לעלות חצי או מליון דולר, תוכנות PPM זמינות היום באמצעות מודל תוכנה כשירות (SaaS) אצל רוב הספקים, המקל באופן אוטומטי על ההשקעה הראשונית בפתרון מסוג זה.
לפי הסקר של SearchCIO.com 14% של משיבים ציינו, כי שילמו פחות מאשר 50,000 $ עבור מוצרים של מייקרוסופט, אורקל, אינוטאס ועוד; 26% צייני כי שילמו בין 50K –100K$ עבור תוכנות של מיקרוסופט,CA IBM, HP, אורקל, Primavera ועוד. מדובר בפתרונות,אשר נרכשו או אורחו באתרי הספקי כאחד.
"אל תחשבו שפתרונות PPM כבדים מידי", אומרים אנליסטים בינ"ל, "יש הרבה פתרונות ואתם צריכים רק להבין מה אתם יכולים וצריכים לאמץ".


נתק מס '2: התוכנת PPM לא עוזרת לחישוב ההחזר על ההשקעה (ROI) עוד תחום שבו המשתמשים חושבים שתוכנת PPM איננה עונה על צרכיהם הינו חישוב ההחזר על ההשקעה בפרוייקטים וניתוח עלות-תועלת.
רוב הארגונים מחפשים היום דרכים יעילות למדוד את זמן השקעה של הצוות בפרויקט IT תוך כדי חישוב עלויות נוספות, כגון: הדרכות, תשתית חדשה ועוד.
נראה שדעה הרווחת בקרב הלקוחות הינה שתוכנות PPM חסרות בעיקר בתחום מדידת ROI לפר' IT, ולכן הם מנסים לפתח כלים בתוך הבית, למרות שתהליך החישוב ROI הוא תהליך מורכב ודורש התממשקות כמעט לכל הכלים האחרים ב- IT. כלי PPM המובילים עם מנועים חזקים לניהול workflow- מעין כלי BPM- יכולים לעזור בניהול תהליכי לחישוב ROI מסובכים, עם חיזוי ודיווח שוטף מבוססי מתודולוגיות ו- best practices.

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

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

כלים לניהול דרישות

בשבוע אחרון קיבלתי מלקוחותינו מספר פניות לקבלת המידע לגבי הכלים לניהול דרישות עסקיות. להלן סקירה קצרה על המצב של כלים אלה בשוק ישראלי:
ל-4 כלי PPM גדולים: CA, HP, CHANGEPOINT(COMPUWARE), IBM יש מודול חזק לניהול דרישות:

  • מודול ניהול דרישות של CA מיושם היום בשירותי בריאות כללית (ביזנס ו-IT), ושל HP בפרטנר ובנק בינ"ל

  • פתרון ישראלי MSP מציע פתרון מעניין לניהול דרישות המיושם היום במנורה, תעשיה אוירית, וסלקום

  • גרסה חדשה של כלי לניהול פרויקטים PS NEXT כולל היום מודול לניהול דרישות, למרות שאני מאמינה כי ארגונים אשר עובדים היום עם MS Project Server יש פחות היגיון לבחון אותו
  • ישנם ארגונים שמנהלים דרישות בעזרת Action Base אך מתלוננים על חוסר ראייה הכוללת של הדרישות
  • שאר הארגונים מנהלים את דרישות העסקיות בעזרת מיילים, אקסלים, ופתרונות בפיתוח עצמי

שלב 7 : קביעת מדדים לבחינת אפקטיביות תיק ההשקעה


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

יש צורך בפיתוח מתמשך של מדדים ארגונים אילו על מנת לשפר את :

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

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

שלב 6 : ניהול השינוי על ידי יצירת ארגון ה- PMO


על מנת להטמיע את מתודולוגיית Project & Portfolio Mngt ל"מחזור הדם " של הארגון יש צורך ביצירת ארגון ותהליכים בעזרת Project Management Office. תפקידי הPMO :

1. הגדרה והובלת מתודולוגית ניהול פרויקטים

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

2. הדרכה וייעוץ

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

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

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

שלב 5: הקמה של מערכות תומכות למעקב וניטור


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

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

שלב 4 : הפעלת תוכנית תקשור לחטיבות


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

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

ועדת היגוי IT - הקמת גוף ברמת הנהלת החברה האחראי על תוכן התיק שמטרותיו העיקריים הם:

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

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

שלב 3 : יצירת קריטריונים לתעדוף פרויקטים

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

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

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

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

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

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

שלב 2 :גזירת תכנית שנתית והתאמתה לצרכים משתנים


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

  • מנדטורי – פרויקטים שחייבים לבצע עקב חוק/ רגולציה/ אילוץ אחר
  • אסטרטגיה ארגונית – מספר קטן מאד של פרויקטים שהחברה מעוניינת לבצע כחלק
    מהאסטרטגיה הכוללת שלה ללא תלות בהחזר על השקעה – ROI
  • פרויקטים מונחי ROI - פרויקטים שיכנסו לביצוע בתלות ביצירת תוכנית עסקית הולמת. פרויקטים אלה צריכים להיות החלק הגדול של הפורטפוליו. חשוב לציין, כי החזר על השקעה ROI אינו מהווה תמיד פרמטר אמין להצדקת ההשקעה בIT. יתירה מזו: אין זו תמיד הדרך הטובה ביותר להקצאת משאבים בין שתי השקעות מתחרות. למעט המקרים בהם ההשקעה נעשית באופן ספציפי לחיסכון בעלויות, מיפוי של תועלות עסקיות עשוי להיות חשוב יותר להחלטה מאשר החיסכון בעלויות.
  • פרויקטי תשתית - הנחה של תשתית לפרויקטים אסטרטגיים עתידיים ותחזוקה שוטפת של המערכות הקיימות.(Keep the lights on)
  • פרויקטים אחרים – אוסף של משימות ופרויקטים קטנים במיוחד לשיפור הקיים.


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

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

אחד המרכיבים החשובים בהתוויה של מדיניות יעילה ואפקטיבית של מערכות מידע בארגונים גדולים הוא Office of the CIO או Project & Portfolio Office. גוף זה אחראי לקביעה ולמעקב לאחר פורטפוליו ארגונים – סך כל הפרויקטים ומשימות שרצים בארגון ותקשורת ללקוחות פנים ארגוניים.

תקשור ושקיפות של המדיניות,של התוכניות לביצוע ומצב עדכני של הפרויקטים בביצוע ללקוחות פנים ארגוניים הם נקודות מפתח במיצוב של מערכות מידע כשותף אמיתי וכגוף שירותי אשר תורם באופן ישיר להצלחת הארגון. שיקוף המדיניות באמצעות מודל של PPM- Project & Portfolio Management הכולל תועלות וסיכונים היא דרך להציג ולשתף את הלקוחות בסדרי העדיפויות מנקודת ראות הוליסטית ואחידה, כמו גם מאפשרת השוואה מול "פורטפוליו של השוק", כלומר השקעות מקובלות באותה תעשייה בה הארגון נמצא.

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

מערכות מידע בארגון

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

שלב 1 : הקמת מפת דרכים רב שנתית

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

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

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

PPM & App. Development round table summary

סיכום מנהלים:

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

מטרת הדיון: (1) לשמוע מהמשתתפים, מהם ה- best practices להערכת גודל הפרויקטים, תקצוב פרויקטים ודרישות, ובקרה תקציבית של פורטפוליו ארגוני; (2) לחלוק את הניסיון הקיים בתחום זה;

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

· רוב הלקוחות ציינו, כי לא נאלצו, עד עכשיו, לשנות את תכולת הפרויקטים, עקב המשבר הכלכלי. גופי PMO אינם נערכים שונה לתוכנית העבודה של 2009; גם אם תקציב ה-IT ירד - תהליך בחינת הפרויקטים והתיעדופם איננו משתנה, אלא מקבל מיקוד קפדני יותר.
· הערכת פרויקטים מתבצעת בארגונים על ידי מנהלי לקוח/גוף ה-PMO /Office of the CIO לפי ניסיון קודם בלבד תוך בקשה מהגורמים הרלוונטיים להעריך את חלקם, ללא מתודולוגיות מובנות (כ-Function Points או Cocomo). ארגון מוביל תאר תהליך מובנה יחסית להערכת מאמץ הפיתוח המתבסס על מילוי טפסים מוגדרים מראש.
· ברוב הארגונים לא מודדים את טיב הערכת הפרויקט בדיעבד.
· המונחים Reuse ו- SOA הנם מונחים שמוכרים לצוותי ה- PMO, אולם נכון להיום אין דגש רב על יישום מתודולוגיות אלו, וכמו כן, אין מדידה של מידת ה- Reuse כחלק מהערכת הפרויקט.
· מדידת ROI בפוסט פרויקט לא נעשה
· רוב הלקוחות ציינו, כי ניהול הפרויקטים מתבצע באמצעות כלים שחייבים להחליף! (או לשדרג), אבל מחוסר תקציב ובלית ברירה הולכים במקרים רבים על פיתוחים מקומיים פנימיים.
· מתודולוגית Agile מוכרת, אולם לדעת רבים מהמשתתפים אינה מתאימה נכון להיום לארגונים גדולים.
· ישנם מקרים בהם לקוחות אשר ביקשו פיתוחים ולא משתמשים בהם – נענשים!


לסיכום, היה זה מפגש מעניין ופורה. להערכת STKI שנת 2009 הנה שנת מפתח בכל מה שקשור לניהול פרויקטים ול- alignment של ה- IT עם הדרישות העסקיות של הארגון. לסכיום המלא נא לחצו: http://www.scribd.com/doc/10728942/RT-Final-Summary-PPM-and-App-Develop