ניהול מערכות

‫‪Thinking before Computing‬‬
‫מחשבה לפני מחשב‬
‫ניהול מערכות‬
‫‪SYSTEMS MANAGEMENT‬‬
‫אשר יובל‪ ,‬מנכ"ל ומנהל הידע‪ ,‬מתודה‬
‫אוקטובר ‪2010‬‬
‫מבוא‬
‫מרכיב משמעותי בעולם ‪ - IT‬בסדר יומם של רוב מנהלי ‪ - IT‬הוא העיסוק בניהול פרויקטים‪ ,‬אם‬
‫במסגרת של תכנית עבודה )רב( שנתית מתגלגלת ואם כחלק מתכנית אב למחשוב ותכנון אסטרטגי‬
‫ארוך טווח ומקיף של ‪ 1.IT‬ניהול פרויקטים נחשב לעשייה המאתגרת של ‪ .IT‬פרויקטים חדשים‬
‫"צובעים למעננו את העתיד" ומבטאים את השאיפה הטבעית של כולנו להתעורר בוקר אחד ל"עולם‬
‫חדש"‪ ,‬עולם בו פועלות מערכות ממוחשבות מודרניות הבנויות על פלטפורמות חדישות‪ ,‬קלות‬
‫לתחזוקה ולשדרוגים‪ ,‬גמישות לצרכיי הארגון המשתנים‪ ,‬עמידות ויציבות‪ ,‬בעלות החזר השקעה )‪(ROI‬‬
‫משופר וכו'‪ .‬ואם תשאלו את אנשי הפיתוח ואת אנשי "החזון והאסטרטגיה"‪ :‬מה בינתיים? מה עם‬
‫ניהול המערכות הקיימות? מה עם התחזוקה וזרם הדרישות השוטפות והשו"שים שמציף אותנו יום‬
‫יום? סביר שהתשובה תהיה‪ :‬אלה ישתנו וישתפרו בקרוב עם כניסת המערכות החדשות‪ ,‬שכמובן‬
‫"תהיינה קלות יותר לתחזוקה"‪ ,‬וכל מה שצריך הוא להחזיק מעמד‪ ,‬למשוך )רגליים( ולנשוך )שפתיים(‬
‫עד שהמערכות החדשות ייכנסו לפעולה‪.‬‬
‫נראה שכבר היינו בסרט הזה ועם כל ההשקעות וההתקדמות של המערכות והפרויקטים החדשים ‪-‬‬
‫ויש בהחלט התקדמות כל הזמן ‪ -‬תמיד נשארנו‪ ,‬בסופו של יום‪ ,‬עם ניהול מערכות; עם זרם הבקשות‬
‫והדרישות השוטפות לשיפורים ושינויים )‪ , CR's (Change Requests‬עם מערכות מידע ותשתית שצריך‬
‫לתחזק אותן‪ ,‬לתפעל אותן ולהתאימן יום יום‪ ,‬הן לדרישות הארגון הדינאמיות והמשתנות והן‬
‫לדרישות חיצוניות הנכפות על הארגון‪ 2.‬כל פרויקט נגמר )אלה שנגמרים( במערכת חיה שיש לתפעל‪,‬‬
‫לתחזק ולשדרג אותה לאורך זמן‪ .‬מנקודת מבט המפתחים‪ ,‬מחזור החיים של הפרויקט מסתיים "אי‬
‫שם" ב"שלב קטן" של תפעול ותחזוקה‪ ,‬אך אנחנו יודעים שחוק ה‪ ,70/30 -‬הקובע ש‪ 30% -‬מהוצאות‬
‫‪ IT‬מוקדשות לפיתוח ו‪ 70% -‬לתחזוקה‪ ,‬היה ונשאר חוק הברזל של עולם המחשבים‪ 3.‬מרוב דגש על‬
‫עולם הפיתוח‪ ,‬על מתודולוגיות ושיטות פיתוח חדישות כגון ‪ ,Agile‬מחזורי חיים דינאמיים‪ ,‬כלי פיתוח‬
‫)‪ ,(CASE‬כלים לניהול פרויקטים וכו'; נראה ששכחנו את המקצוע המשלים‪ ,‬את האח הבוגר שמחכה‬
‫‪ 1‬לעתים קרובות גם בחלק מתכנון אסטרטגי רחב יותר וחשיבה עסקית כוללת של ארגון האם אליו שייכת מחלקת ‪.IT‬‬
‫‪ 2‬מה שנקרא ‪ Force Majeures‬למיניהם וכמובן באגים ותקלות שיש פשוט לתקן‪.‬‬
‫‪ 3‬למען הדיוק‪ ,‬צריך להודות שחוק )כלל( זה אובחן )התגלה( בשנות ה‪ 90 -‬ואף נמדד בשעתו; ומאז לא מצאנו מחקר שיטתי המאשר אותו‬
‫או שטוען למספרים אחרים‪ .‬נראה שכולם מצטטים את כולם; ועם זאת‪ ,‬הרגשתנו‪ ,‬המבוססת על שיחות עם מספר רב של מנהלי ‪ ,IT‬לא‬
‫על ממצאים סטטיסטיים שיטתיים‪ ,‬היא שחוק ה‪ 70/30 -‬עדיין בעינו קיים‪ .‬מספר מנהלים טענו שהוא אפילו החמיר לרעת הפיתוח‪ ,‬בשל‬
‫ההשקעה המצטברת במערכות קיימות‪ .‬אין להשוות את כמות היישומים ומערכות התשתית של ימינו עם אלה של שנות ה‪.90 -‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 2‬מתוך ‪14‬‬
‫לנו בפינה‪ ,‬את ניהול המערכת ‪ .System Management -‬שכחנו שהיעד המרכזי של פרויקט הוא‬
‫המערכת ובקצה מנהרת הפיתוח מחכה לנו המשימה האמיתית והמתמשכת של ניהול מערכת!‬
‫במאמר זה‪ ,‬ננסה להציע שינוי תפיסה‪ ,‬לפיו יש להעמיד את ניהול המערכות במרכז המחשבה והעשייה‬
‫של תחום ‪ IT‬ולהפוך את עולם החשיבה שלנו‪ .‬לא עוד ניהול פרויקטים במרכז‪ ,‬אלא ניהול מערכות‪ .‬לא‬
‫לצאת מנקודת המחשבה של ניהול פרויקטים‪ ,‬לפיה מחזור החיים של הפרויקט מסתיים בשלב תפעול‬
‫ותחזוקה; אלא ההפך‪ ,‬להעמיד את מחזור חיי המערכת במרכז העשייה‪" ,‬ולהכפיף" אליו את מחזור‬
‫חיי הפרויקט‪ .‬ניהול פרויקטים הוא "מקרה פרטי" של ניהול מערכות ‪ -‬אירוע אחד‪ ,‬חשוב ונכבד ככל‬
‫שיהיה‪ ,‬במכלול האירועים והפעולות המתבצעים סביב המערכת‪ .‬רוב המנהלים בדרג הביניים בתחום‬
‫‪ ,IT‬אינם בעצם מנהלי פרויקטים‪ ,‬אלא מנהלי מערכות שתפקידם לשמר מערכות קיימות ולוודא את‬
‫תקינותן הפונקציונאלית והמבנית ורלבנטיותן למטרות הארגון‪ .‬האם אנשים אלה הוכשרו לכך? האם‬
‫נתנו בידיהם את הכלים והאמצעים המיטביים? האם אנחנו מכירים במקצוע ובתפקיד של מנהל‬
‫‪4‬‬
‫מערכת‪ ,‬כמו שאנחנו מכירים ומשקיעים במקצוע ובתואר של מנהל פרויקטים?‬
‫המונח "תפיסה מערכתית"‪ ,‬מקבל‪ ,‬לפי הצעתנו‪ ,‬משמעות מעשית ומחודשת‪ .‬מנהל ‪ IT‬צריך לקום כל‬
‫בוקר ולשאול את עצמו‪ :‬מה מצב המערכות שלי? האם אני יודע מה ייעודה של כל מערכת ואיך היא‬
‫מתחברת ליעדי הארגון ותורמת למטרותיו? כיצד היא מתפקדת בייצור השוטף? מה מידת הקריטיות‬
‫שלה‪ ,‬יציבותה ויכולתה לצמוח? מה הצפי למשך חייה? מי מנהל אותה )אחראי עליה( ומה מידת‬
‫תלותה בגורמי חוץ? מה מצבה ההנדסי? אילו פעילויות מתרחשות מול המערכת הזו‪ :‬שו"שים שוטפים‬
‫או פרויקט? מענה לחלק נכבד של שאלות אלה ניתן באמצעות פורטפוליו מערכות עדכני‪ ,‬אשר הופך‬
‫בגישה החדשה למשימה עליונה של משילות ‪ 5.(ITGC) IT‬בתוך פורטפוליו המערכות‪ ,‬ניתן לזהות‬
‫קבוצה נכבדה וחשובה של פרויקטים‪ ,‬שמטרתם לשדרג‪ ,‬ברמה זו או אחרת‪ ,‬מערכות ספציפיות או‬
‫אפילו קבוצת מערכות‪ ,‬או אפילו לשנות את החלוקה הנוכחית למערכות‪ ,‬היינו את התפיסה‬
‫המערכתית שלנו‪ .‬קבוצה זו היא חלק חשוב בעשייה האסטרטגית של ‪ IT‬ויש לבחון אותה ולנהל אותה‬
‫בכלים ושיטות חשיבה של עולם ניהול הפרויקטים‪ ,‬כולל בניית פורטפוליו ייעודי משלה – פורטפוליו‬
‫פרויקטים‪ .‬אך עדיין המטרה הסופית היא המערכת ולא הפרויקט‪ 6.‬פרויקטים נוצרים על מנת לבנות‬
‫או לשדרג מערכת; הם יוצאים ובסופו של יום חוזרים לעולם המערכות‪ .‬השירותים ש ‪ IT‬נותן לארגון‬
‫‪7‬‬
‫האם ולקוחותיו הם באמצעות מערכות עובדות ומתפקדות ולא ביצוע פרויקטים‪.‬‬
‫למהפך מחשבתי‪-‬ניהולי זה מוקדש מאמר זה‪ .‬אולי נחדש דבר או שניים‪ ,‬אך סביר שעיקר "המהפך"‬
‫יהיה ע"י מבט מחודש‪ ,‬הצפה‪ ,‬ארגון ושידוד של דברים שכולנו כבר מכירים‪ .‬ככלל‪ ,‬כותב מאמר זה‬
‫‪8‬‬
‫מאמין שעולם המחשבים‪ ,‬בדומה לטכנולוגיות חדישות אחרות‪ ,‬מתפתח בשיטת ‪.(R)Evolution‬‬
‫‪ 4‬האם מישהו מכיר מוסד בשם )‪ ,SMI (System Management Institute‬בדומה למוסד המכובד ‪PMI (Project Management‬‬
‫)‪ ?Institute‬האם לצד פונקצית ה‪ PMO -‬המוכרת כ"כ‪ ,‬אנחנו מודעים לצורך באחיה הוותיק והבוגר חסר השם – ‪?SMO‬‬
‫‪ 5‬המונח ‪ ITG‬הורחב לאחרונה ל‪ ,ITGC – IT Governance & Control -‬כשהוא נתמך בפונקצית ‪.OCIO – Office of the CIO‬‬
‫אך גם פונקציה זו מתמקדת בעיקר בפיתוח והופכת להיות מעין הרחבה של פונקצית ה‪.PMO -‬‬
‫‪ 6‬כמה אנרגיה מושקעת‪ ,‬לעיתים קרובות‪ ,‬בתיאור "יעדי הפרויקט"‪ ,‬בתיעוד המלווה את הפרויקט‪ ,‬וחבל‪ .‬הדגש העיקרי‪ ,‬צריך להיות על‬
‫"יעדי המערכת" ומטרותיה‪ ,‬כפי שמודגש בנוהל מפת"ח למשל‪ .‬יעדי הפרויקט הם ברורים ומובנים מאליהם ונגזרים מיעדי המערכת‪.‬‬
‫אמור מה הם יעדי המערכת בכפוף ללוחות זמנים ומשאבים ברורים ונבין כולנו מה הם יעדי הפרויקט‪ :‬לבצע את זה בהצלחה‪.‬‬
‫‪ 7‬יש ארגונים‪ ,‬בעיקר גופי פיתוח‪ ,‬שאכן נמדדים על השלמת פרויקטים ולא על תפעול מערכות‪ .‬אנחנו מכוונים ליחידת ‪ IT‬קלאסית ולמנהל‬
‫‪ IT‬בתוך ארגון עסקי או ציבורי שעיקר ייעודו הוא לספק שירותי ‪ IT‬לארגון האם או ללקוחות חיצוניים‪ .‬בארגונים אלה היעד העיקרי‬
‫הוא מתן שירותים עסקיים כפי שמדגישות מתודולוגיות ‪ ITIL SOA ,BPM‬ואחרים‪ .‬זו הליבה העסקית‪-‬ארגונית‪ .‬הקשר בין שירותים‬
‫ומערכות מידע הוא הדוק ומיידי‪ ,‬בעוד שהקשר עם פרויקטים הוא משני ועתידי‪.‬‬
‫‪ 8‬לאמור‪ ,‬מדברים הרבה בעולם ‪ ,IT‬על שיטות חדשניות ומהפכות טכנולוגיות‪ ,‬מלווים בזימזומילים )‪ (Buzzwords‬המבשרים לנו‪ ,‬אחת‬
‫לשנתיים‪-‬שלוש‪ ,‬על סיומו של עידן ישן ותחילתו של עידן חדש; אבל בראייה ארוכת טווח‪ ,‬עולם ‪ IT‬מתפתח בשיטות אבולוציוניות לא‬
‫רבולוציוניות‪ .‬הזימזומילים ברי המזל והתוכן משתקעים בהדרגה בתהליך האבולוציוני ותורמים את חלקם; בעוד שהאחרים‪ ,‬נמוגים‬
‫ונעלמים )ומוחלפים בזימזומילים חדשות ‪.(...‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 2‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 3‬מתוך ‪14‬‬
‫איור מס' ‪ :1‬מניהול פרויקטים לניהול מערכות‬
‫ניה ול ה מערכת – תפעול ותחזוקה‬
‫על מנת להבין במה בעצם מדובר‪ ,‬ומה החידוש של מאמר זה‪ ,‬חשוב לדמיין מערכת ‪ IT‬עובדת ולתאר‬
‫את מכלול הפעילויות‪ ,‬האירועים והתהליכים המתבצעים סביבה‪:‬‬
‫‪ .1‬ייצור ותפעול שוטף‪ ,‬כולל בזמני חירום ואירועים חריגים‪:‬‬
‫•‬
‫ניהול הייצור עפ"י מהלכים ברורים כולל ריצות חוזרות‪ ,‬התניות‪ ,‬התגברות על תקלות וכו'‪,‬‬
‫•‬
‫ניהול המשתמשים‪ ,‬כולל מתן הרשאות‪ ,‬פעולות חריגות ואבטחת מידע‪,‬‬
‫•‬
‫זמינות‪ ,‬שרידות ועמידות‪ :‬תהליכי גיבוי והתאוששות ושחזורים‪,‬‬
‫•‬
‫המשכיות עסקית ‪ BCP/DRP -‬למקרים קיצוניים‪,‬‬
‫‪ .2‬ניהול ומעקב תקלות ובעיות‪ :‬ניטור‪ ,‬טיפול‪ ,‬ניתוח והפקת לקחים‪,‬‬
‫‪ .3‬דוחות ביצועים‪ ,‬נפחים ועומסים‪ ,‬מעקב ותכנון קיבולת‪,‬‬
‫‪ .4‬ניהול מרכז תמיכה ושירות‪,‬‬
‫‪ .5‬תחזוקה ‪ -‬ניהול דרישות ושינויים‪ .‬צבירת כל הדרישות לשיפורים ושינויים פונקציונאליים‬
‫)שו"שים( וניתובם בהתאם‪:‬‬
‫•‬
‫תחזוקה הכרחית‪ :‬הכנסת שינויים חיוניים ודחופים ביישום או בתשתית‪,‬‬
‫•‬
‫תחזוקה מונעת‪ :‬הכנסת עדכונים בתשתית )וביישום( למניעת תקלות והשבתות‪,‬‬
‫•‬
‫עדכונים תקופתיים‪ :‬הכנסת שיפורים ושינויים באמצעות גרסאות מסודרות‪,‬‬
‫•‬
‫העברה לתהליכי פיתוח של מהדורה חדשה‪,‬‬
‫‪ .6‬תיעוד‪ ,‬ניהול תצורה ומעקב ‪,Baseline‬‬
‫‪ .7‬רה‪-‬ארגון וטיוב נתונים‪,‬‬
‫‪ .8‬הדרכות והטמעות שוטפות‪:‬‬
‫•‬
‫העצמת השימוש במערכת‪,‬‬
‫•‬
‫טיפול בתחלופת משתמשים‪,‬‬
‫•‬
‫טיפוח ושימור משאבי אנוש המתחזקים‪ ,‬טיפול בתחלופת המתחזקים‪,‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 3‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 4‬מתוך ‪14‬‬
‫‪ .9‬אמידת עלויות שוטפות‪ :‬תחזית שנתית‪,‬‬
‫‪ .10‬שמירה שוטפת על הקשר עסקי – )‪,Business Alignment (Relevance‬‬
‫‪ – System Assessment .11‬הערכה תקופתית של רלוונטיות המערכת מההיבט העסקי וההנדסי‪.‬‬
‫ולא הזכרנו‪ :‬אבטחת מידע‪ ,‬מדדים וכו'‪ .‬על מנת להשתלט על רשימה מפורטת זו )שאינה מלאה( ולנהל‬
‫אותה באופן מסודר‪ ,‬מקובל להפריד בין פונקצית הייצור והתפעול השוטף )‪ (Data Center‬ובין פונקצית‬
‫התחזוקה‪ .‬הראשונה כוללת את רוב הפעילויות המוזכרות לעיל‪ .‬השנייה מתמקדת במס' ‪ ,5-7‬אך‬
‫מסייעת באופן הדוק לכל שאר הפעילויות‪ .‬אנו נתמקד יותר בפונקציה השנייה – קרי ניהול ותחזוקת‬
‫‪9‬‬
‫מערכות ‪ .IT‬נושא התפעול והייצור‪ ,‬יהיה‪ ,‬בעיקרו‪ ,‬מחוץ לתחום מאמר זה‪.‬‬
‫פעילויות ניהול מערכת שוטפות אלה נדרשות בתקני איכות ורגולציה מתקדמים דוגמת‬
‫‪ ITIL ,ISO9000:2008‬ו‪.COBIT-‬‬
‫הנדסת מערכות ‪I T S y s t e m E n g i n e e r i n g – I T‬‬
‫ניהול מערכות טכנולוגיות בכלל‪ ,‬מערכות ‪ IT‬בפרט‪ ,‬נשען על רובד הנדסי שתפקידו להבין ולשמר את‬
‫המערכת‪ :‬החל מארכיטקטורה ומבנה כללי – ארכיטקטורת היישום וארכיטקטורת התשתית‬
‫הטכנולוגית – דרך החלוקה לתת מערכות ומודולים ראשיים וכלה באובייקטי קוד ומבני נתונים‬
‫הפרטניים ביותר‪ .‬במילים אחרות‪ ,‬מאילו רכיבים ומאפיינים בנויה המערכת‪ ,‬אילו תהליכים וזרימת‬
‫מידע מתרחשים בה‪ ,‬אילו תלויות וקשרים חיצוניים יש לה‪ ,‬אילו אירועים מפעילים אותה‪ ,‬מה רמת‬
‫סיבוכיותה‪ ,‬איכותה ועמידותה‪ ,‬יכולתה להשתדרג וכו'‪ .‬מדובר לא רק בהנדסת תוכנה הכוללת נושאים‬
‫כמו‪ :‬שפות תכנות‪ ,‬מבני נתונים‪ ,‬מבניות תוכנה ואלגוריתמים; אלא גם הנדסת מערכת ממוחשבת‬
‫הכוללת נושאים כגון‪ :‬חומרה‪ ,‬ארכיטקטורת מחשוב‪ ,‬תקשורת‪ ,‬ניהול תצורה‪ ,‬ממשקים‪ ,‬אמינות‬
‫ושרידות‪ ,‬עומסים ותכנון קיבולת וכו'‪ .‬לכל אלה יש התייחסות מרובה בעולם הפיתוח וניהול‬
‫פרויקטים‪ .‬מהנדס המערכת הוא פונקציה שהולכת ותופסת את מקומה בעולם הפיתוח‪ ,‬לצד מנהל‬
‫הפרויקט ומנתח המערכת‪ 10.‬טענתנו היא‪ ,‬שתפקיד זה חיוני לא פחות‪ ,‬אולי אפילו יותר‪ ,‬בעולם ניהול‬
‫המערכות והתחזוקה‪ .‬כל נגיעה והכנסת שינוי במערכת חיה ומתפקדת‪ ,‬ללא הבנה בסיסית של המבנה‬
‫ההנדסי שלה‪ ,‬היא מסוכנת למדי‪ .‬האם מישהו היה מכניס את המכונית שלו לטיפול במוסך שאין לו‬
‫את ספר המכונית? האם מישהו היה משפץ את הבית שלו בלי שרטוטים וחוות דעת של מהנדס?‬
‫הנדסת מערכות )תוכנה( היא הבסיס לניהול מערכת ‪.IT‬‬
‫ההיבט התיא ורטי‪ -‬אקדמאי‬
‫הפער בין ניהול פרויקטים לניהול מערכות‪ ,‬נראה בולט במיוחד באקדמיה ובמכונים בהם מכשירים את‬
‫אנשי המקצוע שלנו‪ .‬תשומת לב רבה ניתנת‪ ,‬בתוכנית הלימודים‪ ,‬למתודולוגיות פיתוח ופרדיגמות‬
‫‪ 9‬למרות ההפרדה הנכונה בין תפעול ותחזוקה‪ ,‬ורצוננו להתמקד בתחזוקה‪ ,‬יש לזכור ש"ניהול מערכת" במשמעותו הרחבה כולל את‬
‫שניהם‪ .‬מנקודת ראות הנהלת הארגון שניהם כלולים ב"שוטף" לעומת "הפיתוח"‪ ,‬מה שנקרא גם ‪Run the business vs. Grow the‬‬
‫‪ business.‬שניהם שייכים ל‪ .Run the business -‬למרות שנתמקד רק בתחזוקה ובשיפור המערכות‪ ,‬טענתנו העקרונית נכונה לגבי‬
‫שניהם‪ ,‬היינו שבהשקעה נכונה ותשומת לב רבה יותר ל‪ ,Run -‬ולשיפור ניהול המערכות‪ ,‬אפשר להפיק ערך רב לארגון ולתעל חלק‬
‫ניכר מהגידול )‪ ,(Grow‬לאפיקי התפתחות אורגניים ואבולוציוניים ופחות מהפכניים‪.‬‬
‫‪ 10‬יש כאן אתגר מרכזי ביותר למקצוע מנתחי המערכות להשתדרג למהנדסי מערכות ‪ IT‬או שנצטרך לצוות מקצוען נוסף לתהליך –‬
‫מהנדס מערכת – כפי שעושים כבר גופים מסוימים‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 4‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 5‬מתוך ‪14‬‬
‫מחזורי חיים‪ ,‬לכלי פיתוח )‪ ,(CASE‬כלים לניהול פרויקטים‪ ,‬לשיטות פיתוח חדישות כגון אג'ייל‪,‬‬
‫למחזורי חיים דינאמיים וכו'‪ .‬מרוב דגש על עולם הפיתוח נראה ששכחנו את המקצוע המשלים‪ ,‬את‬
‫ניהול המערכת ‪ .System Management -‬שכחנו שהיעד המרכזי של פרויקט הוא המערכת ולפיכך‬
‫תפקידנו להכשיר מנהלי מערכות‪ ,‬לא פחות ואפילו יותר‪ ,‬מאשר מנהלי פרויקטים‪.‬‬
‫ושכחנו אולי גם את הנדסת התוכנה שהיא הבסיס המשותף לשניהם – לניהול פרויקטים ולניהול‬
‫מערכות‪ .‬הנדסת תוכנה‪ ,‬או הנדסת מערכת ‪ ,IT‬צריכה להיות מקצוע עצמאי ובסיסי‪ ,‬שמשרת הן את‬
‫עולם פיתוח התוכנה והן את עולם התחזוקה וניהול מערכות תוכנה קיימות‪ .‬טכניקה כמו ‪ERD (Entity‬‬
‫)‪ Relationship Diagram‬המיועדת להבנת מודל הנתונים הלוגי של המערכת‪ ,‬צריכה להילמד לא רק‬
‫מנקודת ראות עיני מנתח המערכות המאפיין מערכת חדשה‪ ,‬אלא גם ואולי עוד יותר‪ ,‬מנקודת ראות‬
‫התחזוקה וניהול מערכת קיימת‪ ,‬היינו‪ ,‬איך "תופסים" את ה‪ ERD -‬של מערכת קיימת‪ ,‬מתעדים‪,‬‬
‫משמרים ומתחשבים בו בכל שינוי שמוכנס למערכת‪ .‬ובאופן דומה‪ :‬הנדסת תהליכים‪ ,‬הנדסת‬
‫ממשקים‪ ,‬הנדסת נפחים ועומסים‪ ,‬תורת האובייקטים‪ ,‬הנדסת אמינות ושרידות וכו'; ואולי מעל לכל‪,‬‬
‫סיבוכיות ומורכבות תוכנה‪ .‬איך "משתלטים" על תוכנה קיימת‪ ,‬איך "מבינים" ומתעדים תוכנה‪ ,‬איך‬
‫מכניסים בה פונקציונאליות חדשה ושינויים‪ ,‬תוך שמירה על יציבותה וחוסנה‪ .‬מהו בכלל חוסן תוכנה‬
‫וגמישות תוכנה? מעט הנדסת תוכנה שנלמדת‪ ,‬נעשית כאמור בהקשר עם עולם הפיתוח בלבד‪ .‬אין‬
‫‪11‬‬
‫הנדסת תוכנה לעולם התחזוקה‪ ,‬כי לא מלמדים את מקצוע התחזוקה וניהול מערכות‪.‬‬
‫איור מס'‪ : 2‬הנדסת תוכנה והנדסת מערכות ‪ – IT‬הבסיס לניהול פרויקטים וניהול מערכות‬
‫יישום שיטות וכלים מתקדמ ים‬
‫בנוסף לשינויים בהכשרת אנשי ‪ ,IT‬אנו מציעים לשנות כיוון מעשי ומיידי בשטח ולהחיל את השיטות‬
‫והכלים המתקדמים‪ ,‬בעולם התחזוקה וניהול המערכות תחילה )או לפחות לצד עולם הפיתוח ובמקביל‬
‫לו(‪ .‬אין שום סיבה בעולם שטכניקות וכלים מתקדמים דוגמת‪ :‬ניהול דרישות‪ ,‬פיתוח בסבבים ויחידות‬
‫מסירה‪ ,‬שערי איכות‪ ,‬ניהול סיכונים‪ ,‬בחינת חלופות‪ ,‬סקרי קוד‪ ,‬מדדים‪ ,‬ניהול תצורה‪ ,‬אמידת עלויות‬
‫ואפילו שיטות חדישות כמו אג'ייל‪ ,‬לא ייושמו בעולם התחזוקה וניהול המערכות כאן ועכשיו! אין שום‬
‫סיבה מוצדקת להשקעה המאסיבית של טכנולוגיות מתקדמות אלה בעולם הפיתוח‪ ,‬בלי לנסות להיעזר‬
‫בהן גם בתחזוקת המערכות הקיימות‪ .‬למה לא לדרוש תיעוד של מודל הנתונים של מערכת קיימת?‬
‫למה שלא ניישם את טכניקת שערי האיכות בתהליכי התחזוקה? למה שלא נשתמש בכלי ‪BPM‬‬
‫‪ 11‬ההשלכות על מקצוע מנתחי המערכות‪ ,‬כפי שכבר הערנו לעיל‪ ,‬הן משמעותיות ביותר ואפשר שהגיע הזמן להגדיר מקצוע זה מחדש‪.‬‬
‫עכ"פ‪ ,‬המצב בו אין מנתח מערכות בתחזוקה איננו סביר‪ .‬מקומו של מנתח‪/‬מהנדס מערכת בתחזוקה ובניהול השוטף הוא חיוני ביותר‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 5‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 6‬מתוך ‪14‬‬
‫מודרניים למיפוי תהליכים במערכות קנייניות?‪ 12‬ובאופן דומה‪ :‬שיטות ניהול תצורה‪ ,‬מיפוי ממשקים‪,‬‬
‫מדידת נפחים‪ ,‬עומסים וביצועים‪ ,‬תיעוד תהליכים‪ ,‬התאמה לתקני אבטחת מידע וכו'‪ .‬בודאי ובוודאי‬
‫כלים לסקירת קוד קיים ו‪.Reverse Engineering -‬‬
‫לשינוי גישה זה יש השלכות חשובות שרק חלק מהן נוכל לפרט במאמר זה‪ .‬השינוי הוא לא במהות‬
‫הנושאים‪ ,‬שהרי הנדסת תוכנה היא הנדסת תוכנה כאמור‪ ,‬אלא באופן בו אנחנו מסתכלים עליהם‬
‫ומיישמים אותם; בעצם "הכפפתם" לעולם ניהול המערכות תחילה‪ .‬הנושאים שבחרנו לתאר בקצרה‬
‫הם‪:‬‬
‫•‬
‫השלכות על משאבי אנוש‬
‫•‬
‫תיעוד מערכות‬
‫•‬
‫מחזור חיי המערכת‬
‫•‬
‫פורטפוליו מערכות‬
‫השלכות על משאבי אנוש ‪ -‬צוותי התחזוקה‬
‫השינוי‪ ,‬אולי המרכזי בהצעתנו‪ ,‬הוא לבחון מחדש את כל הגישה הניהולית והארגונית של צוותי‬
‫התחזוקה‪ .‬לראות בהם גורם חדשני ומוביל בארגון ולא משני או נחות ביחס לצוותי הפיתוח‪ .‬לשדרג‬
‫באופן משמעותי את הרמה המקצועית והמיומנות שלהם‪ ,‬להעלות את המורל שלהם‪ ,‬לתת בידם את‬
‫הכלים החדשניים ביותר ולדרוש מהם בהתאם‪ :‬תיעוד‪ ,‬ניהול תצורה‪ ,‬ניהול ידע‪ ,‬שימוש חוזר‪ ,‬ניהול‬
‫סיכונים‪ ,‬אמידת עלויות‪ ,‬ניהול שינויים‪ ,‬ניהול גרסאות‪ ,‬ערנות עסקית וכו'‪ .‬לשים על הראש שלהם את‬
‫הכובע של מנהלי מערכות‪ ,‬לתת להם את התואר הזה‪ ,‬להכשיר אותם לתפקיד הזה‪ ,‬לטעת בהם את‬
‫האחריות הגדולה שיש להם לגבי תפקודו העסקי של הארגון וחוסנו‪ ,‬יחד עם מתן הרגשה וטפיחה על‬
‫השכם‪ ,‬שהם בעצם נושאים את הארגון על כתפיהם‪.‬‬
‫מסלול קליטת אנשים חדשים בחברה יהיה‪ ,‬עד כמה שניתן‪ ,‬בניהול מערכות תחילה ולא בפיתוח! שם‬
‫הם יכירו מקרוב את הארגון ומטרותיו‪ ,‬שם הם ייחשפו לתהליכים העסקיים של הארגון‪ ,‬לשיטות‬
‫ולכלים המתקדמים של הנדסת תוכנה וניהול מערכות‪ .‬חלק מתפקיד מנהלי המערכות הוא לחנוך את‬
‫העובדים החדשים )הצעירים(‪ .‬על אלה האחרונים‪ ,‬אפשר להטיל את משימות התיעוד‪ ,‬שהעובדים‬
‫הוותיקים אולי לא תמיד אוהבים‪ ,‬כחלק מהכשרתם ולימוד המערכת‪ .‬מנהלי המערכות יימדדו‪ ,‬בין‬
‫השאר‪ ,‬על קיום תיעוד מינימאלי )כפי שדורשים היום כל תקני האיכות והרגולציות(‪ ,‬ויטילו זאת על‬
‫"צעירי הצאן"‪.‬‬
‫תיעוד מערכות‬
‫בהמשך לנושא הקודם‪ ,‬תיעוד הוא כידוע נושא כאוב‪ ,‬בפרט בישראל‪ .‬בעולם הפיתוח וניהול‬
‫הפרויקטים המצב לכאורה קצת יותר טוב‪ ,‬משום שבעצם תהליך הפיתוח נדרש תיעוד כגון‪ :‬מסמך‬
‫ייזום‪ ,‬מסמך אפיון‪ ,RFP ,‬ניתוח סיכונים‪ ,‬השוואת חלופות‪ ,‬ניהול שיקופים וסקרים‪ ,‬תרחישי בדיקות‬
‫וכו'‪ 13.‬אלא שהניסיון מלמד‪ ,‬ולא רק בישראל‪ ,‬שלעיתים קרובות‪ ,‬הגולם קם על יוצרו‪ ,‬ואנחנו טובעים‬
‫בעודף תיעוד ובעודף פירוט; במסמכים עבי כרס שאין שכרם בצידם‪ .‬גם כאן‪ ,‬אפשר לצפות לשינוי כיוון‬
‫‪ 12‬המונח מערכות קנייניות )‪ (Legacy‬הפך בשנים האחרונות "לשק החבטות" של הענף‪ .‬כשם נרדף למערכות מיושנות‪" ,‬דינוזאוריות"‪.‬‬
‫כדאי לזכור שני דברים‪ :‬א‪ ,‬במקרים רבים אלה המערכות שעדיין נותנות את "הלחם והחמאה" של כולנו‪ .‬ב‪ ,‬סביר שמערכות האג'ייל‪,‬‬
‫ה‪ Web -‬ובוודאי ה‪ ERP -‬המודרניים של היום‪ ,‬יהפכו למערכות הקנייניות של מחר‪ ,‬אז כדאי שנזדרז כולנו ונלמד מהר איך מנהלים‬
‫מערכות קנייניות‪.‬‬
‫‪ 13‬האמריקאים קוראים לתיעוד מסוג זה‪.The system-to-be documentation :‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 6‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 7‬מתוך ‪14‬‬
‫שיתחיל דווקא בעולם ניהול מערכות ותחזוקה‪ .‬ע"י שימוש בכלים וטכניקות חדשות‪ ,‬ניתן לבנות‪,‬‬
‫בקלות יחסית‪ ,‬תיעוד מודולארי וקומפוננטיאלי )מרוכבב( המתמקד ברכיבים החשובים ביותר‪ ,‬כל‬
‫רכיב בנפרד‪ ,‬ובהדרגה; יחד עם יכולת לחבר ולשזור הכל ל"ספר המערכת" אם וכאשר זה נדרש‪ .‬מצב‬
‫של "אפס תיעוד" הוא לעתים בסיס טוב יותר להכנסת טכניקות‪ ,‬כלים ומתעדים )אנשי טכמרקום(‪,‬‬
‫מאשר "עודף תיעוד" כפי שיש בפיתוח‪ .‬תרשים ארכיטקטורה כללי‪ ,‬תרשים ישויות המידע ‪,ERD‬‬
‫טבלת ממשקים‪ ,‬רשימת הדו"חות‪ ,‬טבלת משתמשים והרשאותיהם‪ ,‬טבלת נפחים ועומסים‪ ,‬מנגנון‬
‫אבטחת המידע וכו'‪ ,‬הם דוגמאות לתיעוד מודולארי וקומפוננטיאלי‪ .‬כל אחד מהם ייבנה בעזרת גלופה‬
‫)תבנית( ייעודית ופשוטה; כל אחד מהם משקף באופן ברור חלק פעיל במערכת חיה ועובדת המשרתת‬
‫את הארגון; לכל אחד מהם יש החזר השקעה ברור ומיידי בשיפור תהליכי התחזוקה והנצלת ידע‪.‬‬
‫איור מס'‪ : 3‬ערכה לתיעוד מערכות קיימות – ‪MSD Modular System Documentation‬‬
‫מחזור חיי מערכת‬
‫הנושא אולי המדובר ביותר בניהול פרויקטים והנדסת תוכנה הוא מחזור חיים – ‪ ,Life Cycle‬נכון יותר‬
‫מחזור חיי הפרויקט )‪ ,PLC (Project Life Cycle‬או בשם שהיה מקובל בעבר ‪SDLC (System‬‬
‫)‪ .Development Life Cycle‬מונח זה מקבל מקום של כבוד בכל קורס של הנדסת תוכנה ובכל‬
‫מתודולוגיה שמכבדת את עצמה‪ .‬מתודולוגיות שונות מציגות‪ ,‬כל אחת בתורה‪ ,‬מחזור חיים כזה או‬
‫אחר‪ ,‬כאשר ההבדל ביניהם הוא שולי‪.‬‬
‫איור מס' ‪ 4‬מציג מחזור חיים קלאסי של מערכת ‪.IT‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 7‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 8‬מתוך ‪14‬‬
‫איור מס'‪ : 4‬מחזור חיים קלאסי‪ ,‬כולל הוספת גרסאות ומהדורות‪ ,‬חיבור לתכנית עבודה שנתית ותחקור‬
‫מערכות‪.‬‬
‫מחזור חיים זה‪ ,‬כשמו כן הוא‪ ,‬חושב "פיתוח"‪ ,‬חושב "פרויקט"‪ .‬הוספנו לו מצד אחד )צד שמאל‬
‫למעלה( את הקשר לתכנית העבודה השנתית‪ ,‬ומהצד השני )ימין למטה( את שלב תחקור והערכת‬
‫מערכת )הפקת לקחים(‪ .‬דגש חזק במחזור חיים זה מושם על שלבי התכנון )האפיון( והפיתוח )עיצוב‬
‫ובנייה(‪ .‬ואחריהם כמובן בדיקות והעברה לייצור‪ .‬בקצה המנהרה יש שלב של "תפעול ותחזוקה"‬
‫שבעצם איננו חלק מהותי של מחזור החיים‪ .‬אין הגדרה ברורה מה בדיוק מצופה שיקרה שם‪ ,‬אין‬
‫הנחיות ברורות ו\או גלופות עבודה‪ ,‬כפי שיש בשלבי הפיתוח‪ .‬עצם ההכלה של תפעול ותחזוקה‬
‫במשבצת אחת ואמירתם "בנשימה אחת"‪ .‬ממחיש עד כמה עולם הפיתוח מנותק מעולם העשייה‬
‫השוטפת‪.‬‬
‫איור מס' ‪ 5‬מציג מחזור חיים של פיתוח בסבבים )יחידות מסירה(‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 8‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 9‬מתוך ‪14‬‬
‫איור מס'‪ : 5‬מחזור חיים של פיתוח בסבבים ויחידות מסירה‬
‫מחזור חיים של פיתוח בסבבים הוא היום המודל הנפוץ והמקובל‪ ,‬בשל מספר גורמים כבדי משקל‪,‬‬
‫ביניהם‪ :‬הצורך בהיענות עסקית מהירה )‪ ,(Time to market‬תקציבים מדודים‪ ,‬הימנעות מהסתבכות‬
‫בפרויקטים גדולים‪ ,‬קבלת משוב מהשטח ועוד‪ 14.‬אך יש לכך גם מחיר‪ ,‬והוא‪ ,‬הכנסת שלב התפעול‬
‫והתחזוקה באופן הרבה יותר ברור אל תוך מחזור החיים של הפרויקט‪ .‬שים לב לכל החיצים הנכנסים‬
‫והיוצאים משלב זה ולקריטיות של בדיקות הרגרסיה! המחיר הוא בסיבוכיות של החזקת גרסה אחת‬
‫בתפעול ובייצור‪ ,‬יחד עם המשך הפיתוח במקביל‪ .‬יד אחת מתפעלת ומתחזקת את המערכת‪ ,‬כולל‬
‫טיפול בתקלות‪ ,‬הכנסת שינויים חיוניים וכו'‪ ,‬בעוד היד השנייה מפתחת את יחידת המסירה הבאה‬
‫שמהר מאד מתברר שאיננה המשך רציף ופשוט של יחידת המסירה הקודמת )יחידות המסירה‬
‫הקודמות(‪ .‬יש כאן משימה לא פשוטה של ניהול תצורה ותיאום בין התפעול והתחזוקה והמשך‬
‫הפיתוח‪ .‬תיקונים שהוכנסו ליחידת המסירה שבתפעול חייבים להיות מדווחים לצוותי הפיתוח‬
‫העובדים על יחידת המסירה הבאה‪ .‬אבל מבחינתנו‪ ,‬זהו צעד גדול לכיוון התפיסה של ניהול מערכת‬
‫כמשלימה לניהול פרויקטים‪ .‬מבט ממוקד על המלבן התחתון שבאיור מס'‪ , 5‬תפעול ותחזוקה‪ ,‬יגלה‬
‫לנו מחזור חיים חדש ושונה – מחזור חיים של מערכת‪ .‬אבל אין צורך בזום או זכוכית מגדלת‪ ,‬איור‬
‫מס' ‪ 6‬מראה לנו את זה בבירור‪.‬‬
‫‪ 14‬ראה איור מס' ‪ 4‬לעיל שגם מודל פיתוח סדרתי \ קלאסי כולל תמיכה בגרסאות ומהדורות‪ ,‬כך שההבדלים ביניהם הולכים ומטשטשים‪.‬‬
‫מודל מפל המים )או מודל ‪ ,V‬מודל ‪ W‬אם משולב אבטיפוס( כבר מזמן אינו מקובל‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 9‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 10‬מתוך ‪14‬‬
‫איור מס'‪ : 6‬מחזור חיים של מערכת – ‪SLC System Life Cycle‬‬
‫התהפכה התמונה! המבט כעת הוא על מחזור חיי מערכת ‪ IT System Life Cycle -‬שכולל תחזוקה‬
‫שוטפת ועדכונים תקופתיים‪ ,‬לצד "יציאה" לעולם ניהול הפרויקטים לצורך הוספת יחידות מסירה‬
‫)מהדורה( או אפילו פיתוח דור חדש לגמרי של המערכת‪ .‬כולל אפשרות שפיתוח זה מתבצע על מספר‬
‫מערכות במקביל ועתיד לשנות את עצם הגדרתן‪ .‬ראייה זו של ניהול פרויקטים כנובע מניהול מערכות‪,‬‬
‫תגרום‪ ,‬כך אנו מקווים‪ ,‬לבחינה מתמדת של חלופות פשוטות וזולות יותר‪ ,‬כולל תהליכי ‪Reengineering‬‬
‫והנצלת מערכות‪ .‬ובמקרה של החלטה בכ"ז על פיתוח דור חדש‪ ,‬תגרום להנצלת ידע ומיצוי התובנה‬
‫והניסיון המצטבר במערכת הקיימת‪ .‬נדירים המקרים בימינו שארגון מפתח מערכת חדשה מהיסוד‪,‬‬
‫מסוג ואופי שלא היו מוכרים מקודם‪.‬‬
‫"אין צורך להמציא את הגלגל‪ ,‬צריך רק לשייף ולשמן גלגלים קיימים" )משה‬
‫המוסכניק(‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 10‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 11‬מתוך ‪14‬‬
‫פורטפוליו פרויקטים או מערכות‬
‫כלי מרכזי בניהול מערכות הוא הפורטפוליו – ‪ .Systems Portfolio Management‬פורטפוליו הוא בעצם‬
‫רשימה פשוטה של כל המערכות בארגון שניתן למיינה בחתכים שונים ועל פי מאפיינים כגון‪:‬‬
‫•‬
‫זיהוי ושם המערכת‪ ,‬מהדורה\גרסה‬
‫•‬
‫לקוח עיקרי )בעל המידע(‬
‫•‬
‫מנהל אחראי )ביחידת ‪(IT‬‬
‫•‬
‫משאבי אנוש – מתחזקים ומומחים‬
‫•‬
‫טכנולוגיה ותשתיות‬
‫•‬
‫תקציב‪ :‬הקצאה‪ ,‬ניצול‬
‫•‬
‫מידע לניהול התחזוקה‪ :‬לוג שינויים‪ ,‬לוג תקלות‪ ,‬לוג דרישות‬
‫•‬
‫מדדים ומחוונים )אינדיקאטורים( ‪Dashboard -‬‬
‫פורטפוליו בנוי בהיררכיה דו‪-‬כיוונית‪" .‬כלפי מעלה" ‪ -‬סיכום מידע ו"תמונת מצב" למנהלים; "כלפי‬
‫מטה" ‪ -‬אפשרות ‪ Drill-down‬למידע פרטני ומקצועי‪ .‬מהרשימה הכללית‪ ,‬תהיה בד"כ הפניה לסטאטוס‬
‫מורחב של המערכת ומשם‪ ,‬בהתאם לצורך‪ ,‬לתיקיית )פורטל( המערכת המכילה את כל מידע הקשור‬
‫במערכת‪ :‬תיעוד‪ ,‬נהלים‪ ,‬אירועים‪ ,‬כלים‪ ,‬צוותים‪ ,‬ספקים חיצוניים‪ ,‬היסטוריה וכו'‪ .‬פורטפוליו‬
‫מערכות מתחבר היטב לנושא ניהול נכסים ושירותים‪ ,‬כמוגדר‪ ,‬למשל‪ ,‬במסגרת ‪ .ITIL‬ניתן להחיל את‬
‫השימוש בפורטפוליו בעזרת כלי האופיס )אקסל הוא כלי מעולה לניהול פורטפוליו( וליישם כלים‬
‫מתקדמים יותר בהדרגה ולפי הצורך ובשלות הארגון‪ .‬פורטפוליו המערכות ינוהל בנפרד‪ ,‬אך בקשר‬
‫הדוק עם פורטפוליו הפרויקטים בפיתוח – ‪ ,Projects Portfolio Management‬כמוצג באיור מס' ‪.7‬‬
‫איור מס' ‪ :7‬פורטפוליו מערכות ופורטפוליו פרויקטים‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 11‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 12‬מתוך ‪14‬‬
‫נושא חשוב ומעניין שלא נוכל להתייחס אליו במאמר זה‪ ,‬רק להזכירו‪ ,‬הוא נושא התשתיות – מערכות‬
‫התשתית כמשלימות למערכות המידע‪ .‬במילים אחרות‪ ,‬איך מנהלים פורטפוליו מערכות תשתית לצד‬
‫פורטפוליו מערכות המידע )ושניהם‪ ,‬לצד פורטפוליו הפרויקטים‪ :‬מידע ותשתית(‪.‬‬
‫איור מס' ‪ :8‬חיתוך מערכות מידע ותשתיות‬
‫ניהול פורטפוליו היא משימה מרכזית של פונקצית ‪ (Office of the CIO) OCIO‬ושל‬
‫מנהל ‪ IT‬בארגון‪.‬‬
‫נושאים משלימים‬
‫לגישת ניהול מערכות המוצעת במאמר זה‪ ,‬יש השלכות על תחומים ונושאים רבים שלא נוכל לפרט‬
‫כאן‪ .‬נזכיר רק כמה מהם בקיצור רב‪.‬‬
‫‪ – SOA‬תהליכים חוצי ארגון‬
‫שיטת‪/‬טכנולוגיית ‪ (Service Oriented Architecture) SOA‬היא ללא ספק בשורה חשובה שתופסת‬
‫בהדרגה את מקומה בעולם ‪ IT‬והניהול העסקי ובצמידות ביניהם‪ .‬ה"בשורה" החשובה של ‪ SOA‬היא‬
‫ביסוס מערכות ‪ IT‬על תהליכי שירות חוצי ארגון המותאמים לפעילות הארגון ולתהליכים העסקיים‬
‫שלו ולא למבנה ההיסטורי והקשוח של מערכות מידע הקיימות‪ .‬הדרך "הטבעית" למימוש‬
‫ארכיטקטורת ‪ SOA‬היא בנייה של מערכות מידע חדשות המבוססות על ארכיטקטורה זו ועל גישת‬
‫‪ (Business Process Management) BPM‬המשלימה וכן טכנולוגיית ‪ .(Enterprise Service Bus) ESB‬עם‬
‫זאת‪ ,‬הניסיון שנצבר עד כה‪ ,‬מראה שביסוסה של ארכיטקטורת ‪ SOA‬על עולם הפיתוח וניהול‬
‫הפרויקטים אינו מספק‪ .‬חשיבה מחודשת של ‪ SOA‬כמחוברת לעולם ניהול המערכות‪ ,‬תוך הסתמכות‬
‫רבה על תהליכי ‪ ,Reengineering‬שיפור ממשקים והנצלת מערכות קיימות‪ ,‬עשויה לקדם את הנושא‬
‫בצורה הרבה יותר מהירה ומעשית‪ ,‬גם אם לא אופטימאלית‪.‬‬
‫מבט חדש על ניהול דרישות‬
‫נושא זה נזכר כבר בעקיפין‪ ,‬בפיסקה לעיל על שינוי התפיסה של מחזור חיי מערכת מול מחזור חיי‬
‫הפרויקט‪ .‬חלק ניכר מעולם "ניהול הדרישות" מוכוון פיתוח ומסייע בעצם בתהליכי האפיון‪ .‬יש‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 12‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 13‬מתוך ‪14‬‬
‫התייחסות מתודולוגית נרחבת לנושא‪ ,‬בעולם הפיתוח‪ ,‬כולל חלוקה לדרישות משתמש‪ ,‬דרישות‬
‫פונקציונאליות ודרישות מערכת ומעקב אחריהם לאורך שלבי הפרויקט‪ .‬ארגונים משקיעים לא מעט‬
‫בהטמעת שיטות‪ ,‬כלים והדרכות בנושא חשוב זה‪ ,‬לצד יצירת ציפיות גבוהות מהמשתמשים )הלקוחות(‬
‫לגבי יכולות המערכות החדשות‪ .‬לדעתנו‪ ,‬כדאי לשקול להנחיל תהליכי ניהול דרישות בעולם ניהול‬
‫המערכות תחילה‪ ,‬או לפחות במקביל לעולם הפיתוח‪ ,‬כפי שאכן קורה בפועל בארגונים רבים‪ .‬לנושא זה‬
‫יש קשר הדוק עם הנושא הבא‪.‬‬
‫רת"ק ‪ITBR -‬‬
‫רת"ק )רפרנט תקשוב( או )‪ ITBR (IT Business Representative‬הוא נציג המשתמשים או מומחה‬
‫היישום‪ ,‬ומשמש איש קשר דו‪-‬צדדי בין הלקוח )אגף בארגון הנעזר בשירותי מחלקת ‪ ,IT‬אליו הוא‬
‫שייך במבנה הארגוני( ובין מחלקת ‪ 15.IT‬תפקידו לרכז את כל דרישות הלקוח )המשתמשים(‪ ,‬לתעדף‬
‫אותם‪ ,‬לעקוב אחר הביצוע‪ ,‬לאשר אפיונים‪ ,‬לתעדף ולאשר שינויים‪ ,‬להשתתף בבדיקות‪ ,‬לסייע‬
‫בהטמעת המערכת וכו'‪ .‬ארגונים רבים מכירים יותר ויותר בנחיצות פונקציה זו‪ ,‬הן בפיתוח והן‬
‫בתחזוקה השוטפת‪ ,‬אך מתקשים באשר לאופן מימושה‪ .‬לדעתנו‪ ,‬כדאי לשקול לממש פונקציה זו‬
‫בעולם ניהול המערכות תחילה‪ ,‬או לפחות במקביל לעולם הפיתוח‪ ,‬כפי שאכן קורה בפועל בארגונים‬
‫רבים‪.‬‬
‫הערכת מערכות – ‪System Assessment‬‬
‫הערכה תקופתית של מערכת היא תהליך מרכזי בניהול מערכות‪ .‬גם כאן‪ ,‬חשוב להדגיש שלא מדובר‬
‫בהערכת הפרויקט )תחקור( המתבצעת‪ ,‬בארגונים רבים‪ X ,‬שבועות או חודשים לאחר סיום הפרויקט‬
‫במטרה להפיק לקחים וללמוד ממנו לטוב או לרע‪ ,‬לגבי ניהול פרויקטים בארגון‪ .‬מדובר בהערכת‬
‫המערכת‪ ,‬היינו בדיקה תקופתית של עמידתה בארבעת מדדי האיכות העליונים‪ ,‬כולם או חלקם‪:‬‬
‫‪ .1‬רלוונטיות עסקית – פונקציונאלית‬
‫‪ .2‬טכנולוגיה והנדסיות‬
‫‪ .3‬כלכליות‪ ,‬עלויות‪ROI ,‬‬
‫‪ .4‬מינהל וחוקתיות‬
‫תוצאות הערכת המערכת תקבע אם יש תוחלת בהמשך ניהול המערכת בשיטות שציינו לעיל‪ ,‬או שיש‬
‫לבצע פעולה יסודית יותר של שידוד מערכות‪ :‬איחוד מערכות‪ ,‬פיצול המערכת‪ ,‬התמרת הטכנולוגיה \או‬
‫היישום‪ ,‬היינו מעבר לניהול פרויקט‪.‬‬
‫בתהליך הערכת מערכת באה לידי ביטוי בצורה מיטבית טכניקת התיעוד‬
‫הקומפוננטיאלי‪ .‬תיעוד זה ישרת את תהליך ניהול הפרויקט אם וכאשר יוחלט עליו‪.‬‬
‫סיכום‬
‫במאמר זה‪ ,‬ניסינו להעמיד את עולם "ניהול המערכות" כשווה ערך )לפחות( לעולם ניהול הפרויקטים‬
‫ולטעון שבהסטת תשומת לב הנהלת ‪ IT‬והנהלת ארגון האם לכיוון של ניהול מערכות‪ ,‬עשוי הארגון‬
‫‪ 15‬לפונקציה זו יש שמות רבים‪ ,IT Business Coordinator ,BRM (Business Representative Manager) :‬מת"ק )מתאם‬
‫תקשוב(‪ ,‬משתמש מוביל ואולי גם מה שמתודולוגיית אג'ייל מכנה ‪ .Product Owner‬במפת"ח הוא נקרא‪ :‬לקוח – מומחה היישום‪.‬‬
‫אנחנו בחרנו ברת"ק – ‪ ITBR‬כשם זמני‪ .‬מדהים לגלות שלפונקציה כ"כ חשובה ומרכזית‪ ,‬אין שם מוסכם!‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 13‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬
‫ניהול מערכות‬
‫עמ' ‪ 14‬מתוך ‪14‬‬
‫לקבל תשואה משמעותית על נכסיו הקיימים והחזר השקעה מיידי על הכנסת תכנים‪ ,‬כלים‬
‫וטכנולוגיות חדשות‪ .‬התשואה הכפולה של ניהול מערכות נובעת מהגורמים הבאים‪:‬‬
‫‪ .1‬ייצוב הקיים וסיוע לתפעול העסקי השוטף‪ .‬השקעה במה שמביא לארגון את ההכנסות היום‪ ,‬לא‬
‫מחר‪,‬‬
‫‪ .2‬שיפור מיידי של יכולת תגובה עסקית מהירה –‪ – Time to market‬בלי לחכות לפרויקטים גדולים‬
‫חדשים‪,‬‬
‫‪ .3‬שדרוג והנצלת מערכות קיימות‪ .‬חיסכון בפיתוחים מיותרים‪,‬‬
‫‪ .4‬סיוע לפיתוחים חדשים ע"י הנצלת ידע‪ ,‬שימוש חוזר ותהליכי ‪,Reengineering‬‬
‫‪ .5‬שילוב טכנולוגיות וכלים חדישים באופן מדוד והדרגתי הנותן החזר השקעה קצר טווח‪,‬‬
‫‪ .6‬ניצול מיטבי של משאבי אנוש של הארגון‪ ,‬שדרוג כח האדם שבתחזוקה‪ ,‬העלאת המורל‬
‫והמוטיבציה‪ ,‬הגדרה מחודשת של מסלול הכניסה של עובדים חדשים לארגון‪.‬‬
‫הדגש על ניהול מערכות אינו פוגע בניהול פרויקטים ולא בא במקומו‪ .‬לזה האחרון‪ ,‬שמור מקום של‬
‫כבוד בעולם ניהול ‪ IT‬ותחומים אחרים‪ .‬השמת הדגש על ניהול מערכות‪ ,‬מלבד היתרונות המיידיים‬
‫שהיא נותנת לארגון כאמור‪ ,‬גורמת לניהול פרויקטים להיות בוגר ואחראי יותר‪ .‬כל פרויקט נולד‬
‫מצורך אמיתי כאשר ניהול מערכות מיצה את עצמו‪ .‬כל פרויקט בא מעולם העשייה של הארגון וחוזר‬
‫אליו ולא מתיימר ליצור "עולם חדש" מן היסוד‪ .‬המשותף בין שני העולמות רב מהמפריד כפי שמוצגת‬
‫באיור מ' ‪ 9‬המסכם‪.‬‬
‫איור מס' ‪ :9‬בין ניהול מערכות וניהול פרויקטים – רב השווה מהמפריד‪.‬‬
‫העלייה השנייה ‪ ,43‬אזור ‪58002‬‬
‫ת‪.‬ד‪ 122 .‬אזור ‪58190‬‬
‫‪www.methoda.co.il‬‬
‫עמ' ‪ 14‬מתוך ‪14‬‬
‫טל‪03-6133336 :‬‬
‫פקס‪03-6133435 :‬‬