תכנית עבודה שנתית

מבוא – הגדרה ומטרות

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

תע"ש היא נדבך מרכזי במה שמכונה היום מְשִׁילוּת IT (IT Governance) ואמצעי מרכזי לניהול הדיאלוג בין הנהלת הארגון (החברה) והנהלת IT. לצד תע"ש, נכון לבצע, אחת למספר שנים, גם תכנית אסטרטגית ל- IT (כחלק מתכנית אסטרטגית לארגון כולו), אך נראה שבשנים האחרונות, בפרט בתקופה האחרונה, תע"ש מתגלגלת ורב-שנתית, יכולה לחסוך את ההוצאה על תכנית אסטרטגית או לפחות לדחותה.

תע"ש מנסה לענות על שאלות יסוד בניהול (משילות) IT, כגון:

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

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

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

ד.       מה סך ההוצאה השנתית שלנו (הצפוי, הנמדד) לפי:

             ·         סוג ההוצאה\המשאב: כ"א, תוכנה (רכש ותחזוקה), בינוי, תשתיות מחשוב, ציוד ותקשורת וכו'

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

             ·         בחלוקה למערכות מידע (יישומים) מול תשתיות

             ·         בייחוס, ישיר או עקיף, לתהליכים העסקיים והלקוחות

             ·         בחלוקה של Run the business vs. Grow the business

 

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

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

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

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

פן זה של תע"ש ראוי למעשה להיקרא "ניהול רצפת ייצור IT" (IT Shop Floor Management)

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

ג.        כלפי ה- CFO וההנהלה (של ארגון האם): שמירה על הקשר לתקציב IT:

             ·         תקציב שוטף-קיום: תחזוקת מערכות ותשתיות

             ·         תקציב פיתוח: ניהול פרויקטים ומהדורות חדשות

 

המבחן העליון של מנהל IT בציר זה הוא השמירה על המסגרת התקציבית שיועדה ל- IT.

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

על בסיס חלוקה זו ישאל כל מנהל IT את עצמו מה ההחזר העיקרי שהוא מצפה לקבל מהתע"ש:

א.       לכוונן את פעילויות IT מול התהליכים העסקיים והלקוחות?

ב.       לייעל את ניהול משאבי IT ולמקסם את ניצולם?

ג.        לעמוד ביעדי התקציב ומסגרתו?

 

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

תע"ש סטטי מול תע"ש דינמי

המונח תכנית עבודה שנתית (תע"ש) הוא מורכב ולא תמיד ברור, לעתים אפילו מטעה, משום שתחתיו עומדות לפחות שתי מערכות שונות מאד, אם לא בתכלית ומטרה, אזי לפחות במורכבות ובהיקף:

 ·         תע"ש סטאטי-מקרו ברמה שנתית-רבעונית

 ·         תע"ש דינמי-מיקרו ברמה שוטפת יום-יומית,

 

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

תע"ש דינמי-מיקרו מנהל את התנועות היום-יומיות של יחידת IT: את זרם הבקשות המגיע באופן שוטף מהלקוחות וממערכות תפעוליות, את הקצאת המשימות וחלוקת העבודה בין העובדים, את דיווחי השעות וכו'. תע"ש דינמי הוא בעצם 'ניהול רצפת הייצור' של יחידת המחשוב, שהכינוי הטוב ביותר באנגלית הוא IT Shop Floor Management ולא IT Annual Work Plan. תע"ש דינמי הוא למעשה מערכת המידע המרכזית הפנימית של יחידת IT!

בניית תכנית עבודה שנתית סטטית

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

תע"ש מחולקת לשני סוגי תקציב:

 ·         תקציב פיתוח לפי מערכות

 ·         תקציב תחזוקה לפי נושאים

 

דגש מרכזי בתע"ש הוא על ראייה כוללת של המחשוב בארגון וחלוקתו ל:

 ·         מערכות מידע

 ·         מערכות תשתית

 

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

 

	תפעול ותחזוקה  תקציב רגיל	פיתוח תקציב פיתוח
מערכות מידע	ü	ü
מערכות תשתית	ü	ü
סיכום	סה"כ תקציב רגיל	סה"כ תקציב פיתוח

 

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

כל מנמ"ר (מנהל מערכות מידע ראשי) בארגון פועל לבניית תכנית עבודה שנתית משני כיוונים:

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

 ·         מלמטה למעלה – קבלת דרישות ובקשות המשתמשים או הלקוחות לפיתוח מערכות מידע ותשתית ומחויבויות היחידה לפעילויות תחזוקה ושינויים.

 ·          

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

 ·         דרישות הנהלת הארגון והלקוחות (בין אם הם פנימיים או חיצוניים) לדיווחי תכנית העבודה השנתית של יחידת ה- IT

 ·         בניית תכנית עבודה מתוך דרישות המשתמשים ואילוצי כוח אדם ביחידת הפיתוח

 

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

סיווג המערכות

מערכות IT של הארגון מוצגות בחלוקה "מרובעת":

 ·         מערכות מידע מול מערכות תשתית

 ·         מערכות בתחזוקה מול מערכות בפיתוח

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

 

להלן מספר הנחיות לסיווג המערכות בארגון:

תיחום המערכת

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

מהדורות וגרסאות

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

היקף המערכת

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

 ·         ג0 - רכיבי מדף

 ·         ג1 - מערכות קטנות

 ·         ג2 - מערכות בינוניות

 ·         ג3 - מערכות גדולות

 

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

להגדרה מלאה של גדלי המערכת ראה מודל מפת"ח בלשונית הכרת מפת"ח.

יש לרכז מספר מערכות קטנות (ג0) למערכת אחת. למשל, רכישת חמש תחנות עבודה (PC), ארבעה מעבדי תמלילים וכו'. מאידך, מערכות גדולות מאד רצוי לפרק לתת-מערכות בגודל מקביל ל-ג1  או ג2. בכל מקרה חלוקה זו לא תהיה מלאכותית לצורך התע"ש אלא החלוקה הטבעית המקובלת בעבודה השוטפת בארגון ולפי מכנה משותף טכנולוגי ויישומי. אפשר גם להיעזר בהנחיה מספרית פשוטה, הסך הכולל של מספר המערכות צריך שיהיה סביר. פחות מ- 6 או יותר מ- 50 מערכות - אינם סבירים.

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

 

מערכות מידע מול מערכות תשתית

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

מערכות מידע

מערכות ממוחשבות ייעודיות הבאות לשרת את הארגון במגוון פעילויותיו. מתן שירות לציבור (ללקוחות), תפעול וניהול שוטפים, קבלת החלטות אסטרטגיות וכו'. מערכות מידע הן התכלית, היעד הסופי, של המחשוב בארגון. המונח הלועזי הוא IS או MIS Information Systems / Management Information Systems. דוגמאות למערכות מידע כלליות, שכר, כ"א, הנה"ח, מכירות, רכש, מלאי וכו'. 

תשתיות

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

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

מערכות בתחזוקה מול מערכות בפיתוח

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

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

 

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

 

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

 

ניהול תכנית העבודה

פעילויות

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

תכנון תכנית העבודה

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

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

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

תפעול תכנית העבודה

פעילויות 7-11. פעילויות אלה כוללות את שלבי  מימוש תע"ש, דיווח ביצועים, מעקב ביצוע, הצגת מידע ניהולי ובקרות והתראות.

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

סגירה וסיכומים

 פעילויות 12-13 העוסקות בסגירת הפעילות השנתית וריכוז המידע לגורמי הנהלה.

תכנון תכנית העבודה

0. סקירת המערכות בארגון

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

1. ריכוז דרישות הלקוח לפיתוח

שלב זה מתנהל ברבעון האחרון של שנת העבודה וכולל שתי פעילויות מרכזיות:

 ·         פניה ללקוחות להגיש בקשות לשנת העבודה החדשה,

 ·         ראה טפסים מתאימים בלשונית תוצרים בקיט זה

 ·         איסוף הדרישות, אימות והשלמת פרטים.

 

2. תמחור הדרישות שהוגשו ע"י הלקוחות

בתחילת תהליך בניית תע"ש יש לבצע את הפעילויות הבאות:

 ·         ריכוז דרישות לפי לקוח,

 ·         הגדרת גורם פיתוח האחראי לביצוע הדרישה,

 ·         ביצוע הערכות תקציביות ברמת דרישה,

 ·         ריכוז הערכות תקציביות ללקוח,

 ·         השוואה בין ההערכה התקציבית, לתקציב שאושר ללקוח,

 ·         איזון בין הערכה התקציבית לתקציב הלקוח.

 

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

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

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

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

 

3. הקמת מסגרת תקציבית לגורמי הפיתוח

מסגרת תקציבית

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

 

מס' מזהה	שם ותיאור הדרישה	פירוט המוצר והשירות	שם הלקוח	תקציב גג	תאריך הקמה	לו"ז לסיום	איש קשר /מומחה יישום

 

תכנון ברמת הדרישה

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

 

מס' דרישה	מס' מזהה משימה	שם ותיאור המשימה	גוף אחראי לפיתוח	גורם מבצע	תקציב (ח"א/$)	תאריך התחלה	תאריך סיום

 

ריכוז משימות

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

 

גורם מבצע	גוף אחראי לפיתוח	מס' דרישה	מס' מזהה משימה	שם ותיאור המשימה	תקציב (ח"א/$)	תאריך התחלה	תאריך סיום

 

4. תחזית עומס משימות לפי גורמי פיתוח

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

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

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

 

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

 

	ינואר	פברואר	מרץ	...
דרישות לכוח אדם מגורם הפיתוח	10	12	12	15
פוטנציאל כוח אדם ביחידה	9	13	13	10
פער בין דרישה לפוטנציאל	(1)	1	1	(5)

 

*5. אישור תכנית העבודה

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

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

 

6. הצגת Views שונים של תכנית העבודה

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

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

תפעול תכנית העבודה

7. מעבר מתכנון תקציבי לתכנית עבודה לביצוע

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

 ·          הקצאת עובדים/צוותים למשימות - פתיחת פעילויות למשימה ושיבוץ עובדים לפעילויות

 ·         תקצוב פעילות וקביעת לו"ז לביצוע

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

 

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

 

8. קליטת דיווחים

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

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

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

 ·         דיווח גמר ביצוע המשימות הקשורות לדרישה אינו סוגר את הדרישה. הגורם האחראי על ביצוע הדרישה הוא זה המדווח על גמר ביצוע דרישה.

9. מעקב ביצוע

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

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

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

10. הצגת Views שונים

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

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

             ·         מידע פרטני לפי סטטוס משימות ודרישות ליחידה ארגונית או ללקוח

             ·         מידע מסוכם ליחידה ארגונית או ללקוח

             ·         מידע ניהולי מסוכם לגורמי הנהלה - ריכוז לכלל הלקוחות ולכלל היחידות המפתחות

 

11. בקרות והתראות

 ·         ריכוז המידע מדיווחי הפעילויות ברמת משימות אל הדרישות ועפ"י ההיררכיה הארגונית. (מותנה באיכות הכלים הניהוליים)

 ·         קביעת קריטריונים לבקרה והתראה על חריגות ותצוגת התראות ותחקור עפ"י לו"ז, תקציב וסטטוס מוצרים ותוצרים.

סגירה וסיכומים

12. סגירת תע"ש

·         השלמת דיווחי ביצוע לכל המשימות ודיווח סיום ביצוע לכל הפעילויות, המשימות והדרישות שבוצעו בפועל עד לתאריך מוגדר (לדוגמה עד ל- 15 בדצמבר).

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

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

 ·         הערכת המשאבים הנדרשים לסיום דרישות בסטטוס המתנה/ ביצוע.

 ·         הגדרת משאבים נדרשים להמשך ביצוע דרישה בשנה הבאה.

 ·         ריכוז הערכות נדרשות לסיום דרישות ברמת הלקוח.

 ·         העברת ההערכות ללקוח עפ"י נוהלי יחידת הפיתוח.

13. סיכום תע"ש

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

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

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

 

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

תוצרים

טופס ייזום למשימה

הטופס מיועד להגשת בקשה לביצוע משימה חדשה לתע"ש. הבקשה מיועדת למילוי ע"י המשתמש.

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

 ·         0. כללי - פרטי המבקש, סוג ועדיפות המשימה

 ·         1. יעדים - פירוט בעיות במצב הקיים ומטרות המשימה, הצגת עלות/תועלת של המשימה

 ·         2. יישום - תפיסה כללית של המשימה, משתמשים צפויים וממשקים למערכות אחרות

 ·         4. מימוש – מי מעורב בפיתוח, לוחות זמנים לביצוע ודרכי הטמעה

 ·         5. עלות – מקור תקציבי לביצוע המשימה

ניתוח טופס ייזום משימה

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

 ·         0. כללי - פרטי המנתח

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

 ·         2. יישום - התייחסות לסעיף זה בבקשה

 ·         3. טכנולוגיה - ארכיטקטורה כללית, סוג הטכנולוגיה הנדרשת / קיימת, הערות כלליות

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

 ·         5. עלות –הערכה מפורטת של עלויות ההקמה והתחזוקה של המשימה

בניית תכנית עבודה

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

סטטוס משימה

כלי עבודה לתפעול שוטף של תכנית העבודה ולדיווח לגורמי ניהול בארגון. כולל שני גיליונות:

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

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

תע"ש כמערכת מידע

תע"ש היא מערכת מידע לכל עניין ודבר שמחייבת אפיון מסודר ומלא. כאן, נציג בתמצית את דיאגרמת ישויות המידע – ERD (Entity Relationship Diagram) - שהיא רכיב מרכזי באפיון.

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

 

ישויות ראשיות

·         לקוחות במבנה ארגוני של ארגון האם

 ·         עובדים במבנה ארגוני של יחידת IT

 ·         דרישות ובקשות לשינוי (CR's)

 ·         משימות

 ·         מערכות מידע ותשתית

 ·         פרויקטים (כולל עדכוני מהדורות וגרסאות)

 ·         משאבים: כ"א פנימי וחיצוני, הוצאה כספית.

מבנה ארגוני (OBS)

OBS (Organization Breakdown Structure) – מבנה ארגוני. הכוונה ליכולת להציג משימות, דרישות וכו' בייחוס לעובדים ולקוחות בכל מבנה, סיכום וחתך ארגוני נדרש (של יחידת IT או ארגון האם), כגון: הצג את הדרישות של יחידה ארגונית מסוימת מ- IT לפי מדורים, ענפים, מחלקות וכו', בסיווגים ומיונים שונים.

OBS של יחידת IT מאפשר הצגה של כל המשימות ש IT מטפל בכל רגע נתון (+צפי): איזו יחידה מבצעת אילו משימות העונות על אילו דרישות של הלקוחות. בכל ישות בה לא מצוין "עץ", הכוונה למבנה שטוח.

 

ישויות משניות

·         ספר התקציב – חיבור ל (במבנה שטוח או עץ קטן בתוך עץ התקציב הכללי)

 ·         קבלני משנה – כ"א חיצוני

 ·         ספקים וחוזים – רכש ציוד ותוכנות

 ·         מימד הזמן – שנה נוכחית, הרשאה להתחייבות

קודים וטבלאות מרכזיים

·         פיתוח\תחזוקה (שוטף), Run/Grow, חשוב לספר התקציב

 ·         סוג פרויקט מערכת: מידע, תשתית

 ·         היקפי פרויקט: קטן (רבעון), בינוני (שנה), גדול (רב-שנתי)

 ·         עדיפויות \ חשיבות (החזר השקעה, ROI)

 ·         לוח שנה \ שנתי\חודשי\יומי

 ·         יחידות דורשות (לעיל בלקוחות)

 ·         יחידות מבצעות (לעיל בעובדים ומבנה ארגוני פנימי)

 ·         קודים למצבת עובדים: חלקי משרה, התמחויות, קודי מקצוע, דיווחי שעות

 ·         סטאטוס (לדרישות, משימות וכו'): מוצע, בתכנון, בביצוע, מושהה, בוטל, הסתיים

 

מערכות משיקות

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

 ·         מערכת CRM ומערכת ניהול תקלות אשר "מייצרות" דרישות פיתוח, שו"ש ותחזוקה לתע"ש

 ·         משאבי אנוש ודיווחי שעות (שעון נוכחות)

 ·         מערכות רכש, חוזים, מכרזים (בקשות להצעות מחיר) והתקשרויות

 ·         חיבור לדוא"ל ולמשרד הממוחשב, טיפול בכלל משימות העובד (המנהל שלי)

 ·         חיבור לסיכומי דיון ומעקב החלטות (בעיקר של ניהול המשימות)

 ·         משימות "סתם" (לא דרישות לפיתוח)

יישומי תע"ש

ניהול דרישות

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

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

 ·         דרישות לתיקוני תקלות ושינויים דחופים הכרחיים (Force Majeure). חלק נכבד מדרישות אלה נוצר במערכות CRM או ניהול תקלות ולא אצל הלקוח, אשר לעיתים קרובות גם לא מודע להם. במערכות תע"ש מסוימות מתבצע קיצור דרך ודרישות אלה מוגדרות מיד כ"משימות", אך הן בעיקרון דרישות לכל דבר.

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

 ·         דרישות "שינויים ושיפורים" (שו"שים) שניתן לאגד בשינוי גרסה תקופתי (רבעוני למשל)

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

 

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

ניהול דרישות (צרכים) מתבצע בשני צירים עיקריים:

1.       בתכנון שנתי מרכזי. לקראת בניית תקציב היחידה – תכנית העבודה השנתית – מתבצע סקר מעמיק בו כל יחידה בארגון האם – בצד הלקוחות, מגדירה מהן דרישותיה לשנת העבודה הקרובה. בהערכת המשאבים הנדרשים וישימות הדרישה, עשויות יחידות אלה, קרי הלקוחות, להיעזר באנשי IT מולם הם עובדים, אשר מכירים את המערכות, משלימים, משנים ומוסיפים מצידם דרישות 'ברורות מאליהן', גם אם הלקוח לא דרש זאת. לכך יש להוסיף דרישות תפעול, תשתיות ותקורה של יחידת IT, מה שמכונה Keep-the-lights-on.

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

 

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

 

ניהול משימות

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

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

ניהול דרישות ומשימות

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

ההפרדה בין דרישות למשימות והקישור ביניהן ניתנים להמחשה טובה במיסוד של פונקציה ישנה\חדשה שלאחרונה, תופסת תאוצה בארגונים רבים והיא: רפרנט הלקוח או נציג הלקוח / מומחה המערכת שהוא רכיב 1.1 בעץ המערכת של מפת"ח. רפרנטים אלה משמשים 'ראש גשר' בין יחידת IT ובין הלקוחות ומסייעים בייזום ואפיון דרישות, הבאתם ליחידת IT בצורה מסודרת ואחראית, כולל מיצוע בין המשתמשים השונים, הערכת עלות, תקצוב וקביעת סדרי עדיפויות. הרפרנטים משתתפים גם בבדיקות ובהטמעת המערכת ומייצגים את הלקוח (המשתמש העיקרי) כלפי יחידת IT ואת יחידת IT כלפי הלקוח, אבל אינם מתערבים בניהול המשימות! שדרוג תפקיד הרפרנט מאפשר שכלול הקשר בין דרישות למשימות, ייעול עבודת יחידת IT ומתן תשובות זריזות ואפקטיביות לדרישות המשתמש.

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

 

פורטפוליו מערכות תחילה

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

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

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

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

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

 ·         מי שמתחיל בפורטפוליו פרויקטים (Projects Portfolio) ימצא את עצמו מהר מאד בתהליך של הרחבה לפורטפוליו מערכות (Systems Portfolio). זו הרחבה משמעותית במהות ובכמות. במהות, אנשים מבינים שפרויקט הוא 'מקרה פרטי' של מערכת. כמותית, במקום כמה יחידות או עשרות פרויקטים, מכיל כעת הפורטפוליו עשרות ומאות מערכות. כל עולם התפעול והתחזוקה נכנס פנימה.

 ·         מחשוב הפורטפוליו ניתן להיעשות במגוון רחב של פתרונות וכלים, החל מאקסל חכם, דרך תוכנות פורטלים וכלה בתוכנות מתקדמות ואף שרתים ייעודיים. פורטפוליו ממוחשב הוא מודול מרכזי בתוכנות מְשִׁילוּת IT (IT Governance).

 

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

ניהול אישי – Personal Management

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

בניהול האישי – Personal Management – מוצב העובד במרכז ונבנה עבורו כלי מעקב משימות ודיווח פעילות אישי המאפשר לו לדווח על כל הפעילויות שהוא עושה, מנקודת המבט שלו, כולל היעדרויות, חופשות, מחלה וכו'. הניהול האישי מורכב משלוש קבוצות מידע חשובות:

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

 ·         מעקב משימות: תכנון, ביצוע, סטאטוס, דיווחים  

 ·         דיווחי שעות (חיבור למערכת דיווחי שעות)

 

להלן דוגמה למבנה גליון עבודה לניהול האישי:

הניהול האישי מכונה לפעמים גם 'ה- PM השלישי' משום שבראייה הכוללת של תע"ש וניהול IT, יש שלושה PM:

 ·         Portfolio Management

 ·         Project Management

 ·         Personal Management

 

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

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

תע"ש לתפעול וייצור

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

תע"ש מתגלגלת במקום תכנית אסטרטגית

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

רזולוציה, מימד הזמן ומעקב ביצוע

שלושה פרמטרים מרכזיים קובעים את מהותו של תע"ש ומידת מורכבותו:

א.       הרזולוציה של הדרישות והמשימות

ב.       מימד הזמן

ג.        מעקב ביצוע פרטני (קשור ב- א לעיל) או רק תכנון.

 

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

שילוב עם ניהול פרויקטים

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

חיבור לספר התקציב

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