תחזוקה

כללי

הגדרה

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

עקרונות

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

הפרדה בין סוגי תחזוקה שונים

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

 ·         תיקון שגיאות ותקלות ("בגים"), כולל תחזוקה מונעת

 ·         שינויים חיצוניים כפויים (force majeure)

 ·         שינויים ושיפורים (שו"ש)

 ·         ניהול פניות

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

תיק תחזוקה וניהול שינויים

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

קלט

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

תהליך

ראה סעיף פעילויות – תכנית עבודה להלן

פלט

 ·         תוצר ראשי: מערכת מידע פועלת באופן תקין!

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

משאבים

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

 ·         צוות הבדיקה

 ·         תנאי סף

 ·         משקלות

 ·         קריטריונים וטפסי בדיקה

 ·         יחס עלות/תועלת.

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

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

גורם מאשר

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

גורם מבצע

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

גורם אחראי

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

גורם מחליט

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

היקף משוער של המערכת1	הגורם המחליט
	כשהביצוע הוא פנימי במשרד	כשהביצוע ע"י גורם חיצוני
קטן, ג21	הממונה על ענ"א במשרד	ועדת ענ"א המשרדית
בינוני, ג2	המלצת הצוות המקצועי - אישור הצוות המנהלי	וועדת ענ"א המשרדית - באישור מנכ"ל המשרד
גדול, ג3	המלצת הצוות המקצועי והצוות המנהלי - אישור מנכ"ל המשרד וגם אישור אגף תקציבים3	ועדת ענ"א משרדית באישור מנכ”ל המשרד3

מקרא לטבלה:

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

²           בפרויקטים מסוג ג1- ניתן לבצע אפיון/עיצוב מקוצר של המהדורה הבאה

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

החלטה

אלטרנטיבות להמשך:

 ·         המשך תחזוקה במצב הקיים.

 ·         המשך תחזוקת המערכת במהדורתה הנוכחית והתחלת עבודה על המהדורה הבאה (אפיון) במקביל.

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

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

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

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

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

 ·         תחקור של המערכת.

תנאים לאי-ביצוע תפעול ותחזוקה

המערכת לא עברה מבחני קבלה (ראה אלטרנטיבות 5-6 בסעיף הקודם).

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

מבוא והסבר כללי

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

ניהול משימות

ניהול משימות (task list), היא שיטה לניהול עבודה שוטפת ומתמשכת שקשה (או אין טעם) לארגנה במחזור חיים מלא של ייזום, אפיון וכו' ואין בה פעילויות, לו"ז ואבני דרך מוגדרים מראש. מנקודת הראות של מחזור חיים אפשר לומר שניהול פרויקטים הוא macro life cycleוניהול משימות הוא micro life cycle. ניהול משימות משתלב בשלב התחזוקה של מחזור החיים. ניהול משימות מורכב מהרבה משימות קטנות ובדידות שלא ניתן לארגנן מראש, אך עדיין אין זו סיבה לעבוד בחוסר סדר ולכן יש להשתמש בשיטת ניהול משימות. טכניקה זו מבוססת על ניהול רשימה פשוטה של משימות לביצוע (Action Items) ומעקב אחרי ביצוען. הרשימה כוללת פרמטרים כמו: מועדי ביצוע, גורם מבצע וכו'. בתחילת כל שנה ניתן לארגן את רשימת כל דרישות הלקוח, שהפכו למשימות, או משימות תשתית הנובעות מתחזוקה שוטפת, באוגדן של מהדורות מערכת המתוכננות לצאת במהלך השנה ובכך ליצור תוכנית עבודה שנתית והערכת תקציב לתחזוקת המערכת. כל פעילות להלן, מפעילות 6 עד 28, יכולה להיות משימה בדידה או משימה המאחדת מספר פעילויות ברשימה המשימות לביצוע.

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

 

סוגי הפעילויות וסימולם

פעילויות תפעול ותחזוקה מסווגות ומקובצות באופן הבא:

 ·         תחזוקה – הכנות והתארגנות - פעילויות 1 - 5  מתארות פעולות הכנה כלליות לתחזוקה

 ·         טיפול באירוע תחזוקה מסוג שינוי - פעילויות 6 - 13 מתארות מחזור חיים של אירוע תחזוקה - בקשה לשינוי - המגיע ממקור כלשהו (בארגון) והדורש התייחסות. פעילות 28 מסכמת תקופתית את הטיפול באירועי התחזוקה.

 ·         טיפול באירוע תחזוקה מסוג תקלות - פעילויות 14 - 17 מתארות מחזור חיים של אירוע תחזוקה מסוג תקלה. פעילות 28 מסכמת תקופתית את הטיפול באירועי התחזוקה.

 ·         ניהול פניות - פעילויות 18 - 20  מתארות מחזור חיים של אירוע תחזוקה מסוג פניה. פעילות 28 מסכמת תקופתית את הטיפול באירועי התחזוקה.

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

 ·         ניהול שוטף - פעילויות 25 - 31 הן פעילויות תחזוקה יזומות/תקופתיות המתבצעות בלי קשר ישיר, אך בקשר עקיף עם מחזור החיים של אירועי התחזוקה הנ"ל.

 

התייחסות חלקית לתכנית עבודה לתחזוקה, צריכה להופיע ברכיבים 4.2 ו- 4.3  במסמך (תיק) התחזוקה.

תחזוקה – הכנות והתארגנות

קבוצה זו מכילה פעילויות תשתית של התארגנות והכנה לביצוע שוטף של שלב התחזוקה והיא כוללת את הפעילויות הבאות:

1. החלטה על שיטת התחזוקה

 ·         גיבוש השיטה הכוללת על סמך "הצעת מפת"ח" בפעילויות 6 - 28 להלן.

 ·         החלטה האם התחזוקה תתבצע במהדורות.

 ·         קביעת אמות שירות (SLA).

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

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

             ·         טופס אירוע תחזוקה (בל"ש - RFC).

             ·         טופס אירוע תחזוקה – תקלה.

             ·         טופס אירוע תחזוקה – פניה.

             ·         טופס בדיקות.

             ·         טופס הפקת לקחים.

             ·         רשומות איכות נוספים.

 ·         הגדרת השדות והתהליכים בכלי מיכוני.

 ·         קביעת קריטריונים לביצוע הפקת לקחים על תקלות.

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

2. הקמת ספריות ואינדקסים לשלב התחזוקה

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

 ·         קביעת שיטת (סטנדרטים) התיעוד.

3. הכנת נהלים לשלב התחזוקה ביחידה הארגונית / למערכת

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

 ·         נוהל אירועי תחזוקה (שינויים, תקלות ופניות) – הנוהל צריך להכיל את שיטת התחזוקה, אמות השירות וקריטריונים להפקת לקחים.

 ·         נוהל ניהול תצורה

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

4. ארגון תיק תחזוקה

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

 ·         איסוף תיעוד קיים ומפתוחו.

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

5. התארגנות - תכנית עבודה

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

 ·         הגדרת תוכנית עבודה וסדר עדיפויות של שינויים ושיפורים נדרשים במערכת.

 

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

קבוצה זו היא מעין מחזור חיים קטן (micro life cycle) לטיפול באירועי תחזוקה והיא כוללת את הפעילויות הבאות:

6. טופס אירוע תחזוקה

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

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

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

7. תיבת דואר וניתוב

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

 ·         שליחתו לתיבת דואר מרכזית.

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

 ·         רישום ביומן שינויים (מערכת ממוחשבת לניהול שינויים או יומן מסוג אחר).

 ·         בחינה ראשונית.

 ·         מיון ראשוני: איחוד/פיצול אירועים.

 ·         ניתוב לגורם מקצועי מוסמך לקבלת חוות דעת.

 ·         ניתוב חוזר (אופציונאלי).

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

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

 ·         לימוד חוות הדעת שניתנה, דיון חוזר והחלטה על התיקון.

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

 ·         עדכון סטטוס השינויים ביומן השינויים.

אם כן – הכנסה לתכנית העבודה בסטטוס ב"טיפול".

אם לא – הכנסה ליומן השינויים בסטטוס ב"המתנה" או "נדחה".

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

 ·         ביצוע הערכת עלויות, ווידוא כי קיים תקציב לביצוע השינוי, שיוך השינוי לסעיף התקציבי המתאים.

 ·         קביעת סדרי עדיפויות לביצוע השינוי.

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

 ·         קבלת אישור לקוח/משתמש לביצוע המשך הפעילויות.

9. הכנת התיקון

 ·         עיצוב השינוי

 ·         פיתוח, קידוד השינוי

 ·         בנייה וניסוי ב"מיקרו"

 ·         בדיקות ניהול תצורה: סימון הרכיבים הנוגעים, קשרים ותלויות וכו'.

10. בדיקות השינוי

 ·         תכנון תסריטי בדיקה

 ·         ביצוע בדיקות יחידה ותיעוד תוצאות הבדיקות

 ·         ביצוע בדיקות System ותיעוד תוצאות הבדיקות

 ·         ביצוע בדיקות אינטגרציה ותיעוד תוצאות הבדיקות

 ·         ביצוע בדיקות רגרסיה ותיעוד תוצאות הבדיקות

 ·         בדיקות קבלה ע"י הלקוח ותיעוד תוצאות הבדיקות

11. העברה לייצור

 ·         תכנון קטלוג השינוי (קטלוג במהדורות או קטלוג שינוי בודד)

 ·         יישום הקטלוג

 ·         הודעה לכל המכותבים

 ·         תכנון דרך נסיגה (fallback)

 ·         ביצוע בפועל, כולל עדכון ניהול תצורה: רישום הרכיבים וכו'.

 ·         אחת מפעילויות 21 - 28 להלן.

12. מעקב

 ·         מעקב מיידי צמוד (3-4 ימים).

 ·         הפעלת דרך נסיגה, אם צריך.

 ·         מעקב מתמשך (במשך חודש) אם הגיעו אירועים הקשורים בתיקון זה.

חלק ניכר מפעילות זו מבוצע ב"פורום" כמתואר בפעילות 25.

13. רישום סופי ותיעוד התחזוקה

 ·         רישום ברכיב המתאים בתיק התחזוקה.

 ·         עדכון תיק התפעול (אם נדרש).

 ·         תיוק ברשומות איכות וסגירת האירוע ע"י הוספת הסטטוס.

מס' אירוע	תאריך	תיאור	גורם מטפל	רכיב בעץ המערכת	סטטוס

 

תהליך הטיפול בשינוי

טיפול באירוע תחזוקה מסוג תקלות

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

14. זיהוי התקלה

 ·         קבלת התקלה.

 ·         תיעוד פרטי התקלה ביומן או במערכת ממוכנת.

 ·         בחינת התקלה.

 ·         סיווג התקלה - אבחון דחיפות הטיפול בתקלה.

 ·         דיווח (אסקלציה ) על התקלה.

15. תיקון התקלה

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

 ·         בדיקות ישימות התיקון במערכת כולל בדיקות רגרסיה.

 ·         קבלת אישור לקטלוג.

 ·         קטלוג תיקון התקלה.

16. סגירת התקלה

 ·         רישום ותיעוד התקלה

 ·         השלמת דיווח הנתונים וסגירת התקלה.

17. הפקת לקחים

 ·         ביצוע הפקת לקחים.

 ·         תיעוד הפקת הלקחים בטופס הפקת לקחים.

תרשים טיפול בתקלה

ניהול פניות

סוג אחר של אירוע תחזוקה הוא פנית לקוח/משתמש.

18. זיהוי הפניה

 ·         קבלת הפניה.

 ·         תיעוד הפניה.

19. מענה לפניה

 ·         בחינת הפניה.

 ·         טיפול בפניה.

20. סגירת הפניה

 ·         הפניה טופלה ונסגרה.

 ·         הפניה נדחתה.

 ·         הפניה הועברה לגורם אחר.

 ·         הפניה נסגרה מאחר וזוהתה כשינוי.

 ·         הפניה נסגרה מאחר וזוהתה כתקלה.

ביצוע תחזוקה מונעת ותיעוד

יש להקפיד שפעילויות 21-24 להלן תתבצענה אך ורק דרך מחזור החיים של האירוע. אירועי התחזוקה ילווו באחת או יותר מהפעילויות הבאות:

21. תיקוני תיעוד

תיקונים בתיעוד (מדריך למשתמש, תיק תפעול), מסכי תפריט, כותרות מסכים, כותרות דו"חות וקלטים.

22. תיקוני שגיאות - יוזמה פנימית

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

23. שינויים כפויים force majeure -

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

24. שינויים ושיפורים פשוטים

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

ניהול שוטף

קבוצה זו מכילה פעילויות תחזוקה יזומות \ תקופתיות והיא כוללת:

25. דיון יומי/שבועי

פגישות פורום שינויים ותקלות.

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

26. תחזוקה מונעת

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

27. עדכון יזום (תקופתי) לתיק התחזוקה

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

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

 ·         מעבר כללי על תיק התחזוקה: מה מצבו? האם הוא עדיין תקף ועדכני?

28. ניתוח תקופתי של רשומות האיכות

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

29. התארגנות שנתית

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

 ·         בכל שנה הגדרת תוכנית עבודה של שינויים ושיפורים במערכת.

30. יישום פעולות מונעות/מתקנות

 ·         יישום פעולות מתקנות רוחביות בעקבות הפקת הלקחים.

 ·         מעקב אחר יישום הפעילויות בעקבות הפקת הלקחים.

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

31. מדידה

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

 ·         איסוף וריכוז התקלות.

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

 ·         קביעת רף לכל מדד.

 ·         בחינת התקלות בהתאם לרף.

 ·         בחינה מחודשת של הרף לכל מדד.

פעילויות תחזוקה - סיכום

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

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

תוצרים

תיק תחזוקה

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

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

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

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

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

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

 ·         רכיבים במערכת הפיסית המכילים תיעוד עצמי (built in), מכילים בתיק רק הצבעה ואינדקס ואינם דורשים מאמץ ניכר בעדכונם. רכיבים שצורתם הסופית היא תיעוד, יעדים למשל, מקומם רק בתיק המערכת ואינם משתנים באופן תדיר.

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

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

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

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

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

 ·         תיק התחזוקה נבנה מתוך תיק האפיון או העיצוב.

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

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

הנחיות לשימוש בתיק התחזוקה

תיק תחזוקה - תיק מערכת יכיל התייחסות לכל רכיבי עץ המערכת, בדגשים, רמת פירוט ותדירות עדכון, בהתאם לצורכי המערכת. יש להתרכז ברכיבים המשפיעים במיוחד על התחזוקה. לדוגמא, מערכת שבמרכזה קשרי העברת מידע למערכות אחרות, תתרכז בתיעוד עדכני של רכיבים 2.2 ו- 2.22 בתיק התחזוקה ותטפל בשאר הרכיבים בהדרגה. מערכת שבה יש שינויים תכופים בדו"חות או בטפסים תתרכז ברכיב 2.15 או ברכיב 2.16 וגם ברכיב 2.11 (מודל הנתונים) הנגזר מהם, מערכת הנשענת על טכנולוגיה חדישה תתרכז ברכיבי הטכנולוגיה X.3וגם ברכיבי מימוש המושפעים מכך וכו'.

הנחיות נוספות

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

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

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

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

טופס אירוע תחזוקה – (בל"ש – RFC)

אירוע תחזוקה - טופס בקשה לשינוי/שיפור (בל"ש) הוא טופס מרכזי לניהול תהליך מעקב והכנסת שינויים במערכת. נקרא גם Request For Change (RFC). מרכיבי הטופס הם:

 ·         פרטי השינוי

 ·         ניהול השינוי בהיבט רכיבי המערכת המושפעים

 ·         תכנון הטיפול בשינוי בהיבט כ"א ולו"ז

 ·         תכנון וביצוע בדיקות המערכת

 ·         אישור כל הגורמים המעורבים – המפתח והמשתמש.

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

טופס אירוע תחזוקה – תקלה או בירור

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

טופס הפקת לקחים

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

 ·         בטווח הקצר - האם יש מקום לשפר את המערכת עצמה

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

 ·         בטווח הארוך - האם קיימת בעיה יסודית במערכת/ות החוזרת על עצמה מידי תקופה ויש צורך לשכתב מחדש מודול מסוים או שיש צורך ברכישת חומרה חדשה וכו'.

הפקת הלקחים היא אחת הדרכים לביצוע פעולה מתקנת / מונעת.

יומן שינויים

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

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

 ·         שינוי הנדרש ע"י לקוח

 ·         שינוי כפוי כתוצאה מדרישת רשויות

 ·         שינוי מסוג שיפור פנימי

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

יומן תקלות

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

גאנט הפרויקט

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

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

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

בלשונית תוצרים בקיט זה מופיעים איורים (גלופות לימוד) המציגים את הגאנט בשתי התצורות וקבצים לעבודה ב- MS-Project.

ניהול עפ"י מבנה ארגוני

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

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

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

ניהול עפ"י מערכות

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

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

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

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

בחירת גורם חיצוני לביצוע תחזוקה

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

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

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

המפרט

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

מפ"ל

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

 ·         צוות הבדיקה

 ·         תנאי סף

 ·         משקלות

 ·         קריטריונים וטפסי בדיקה

 ·         יחס עלות/תועלת.

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

ראה הקיט בקשה להצעות - RFP בכרך יסודות \ מחזור חיים

טיפים וכללים מנחים

עלויות תחזוקה

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

פעילות	% מהעלות הכוללת
פיתוח והתקנה של מהדורה מרכזית (ראשונה) עובדת:	50%
תיקון שגיאות ושינויים הכרחיים:	20%
שינויים ושיפורים - 2-3 מהדורות \ י"מ נוספות:	30%
סה"כ עלות כוללת	100%

מקרא והסבר

הנוסחה הבסיסית המקובלת בעולם להתפלגות ההוצאה על מערכת ממוחשבת -  30% פיתוח, 70% תחזוקה – שונתה כאן ל- 50\50, בגלל אופק הזמן המוגבל המקובל במפת"ח 7-5 שנים. ראה רכיב 1.7 בעץ המערכת.

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

2.       20% המוקדשים לתיקון שגיאות ושינויים הכרחיים הם עבור התחזוקה של רכיב 2 – יישום וכוללים ברובם המכריע כוח אדם המטפל ביישום. שירות ותחזוקה לרכיבי הטכנולוגיה (חומרה, תוכנה בסיסית, תקשורת וכו') המוערך ב- 10%-7 לשנה, כלול ב- 50% של פיתוח המהדורה הראשונה והתקנתה וב- 30% של פיתוח המהדורות הבאות (אפשרות אחרת היא שהוא יהיה מחוץ לחשבון ויוסיף לעלות המערכת הכוללת).

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

דוגמא 1

 ·         פרויקט שמוערך ב- 2,000,000 ₪

 ·         אופק זמן כולל של 5 שנים: שנה וחצי פיתוח (עצמי) ושלוש שנים וחצי תחזוקה

 ·         הוספת 2-1 יחידות מסירה (מהדורות) חדשות.

טבלת התפלגות העלויות תהיה כדלהלן:

פעילות	% מהעלות הכוללת	דוגמא מספרית
פיתוח והתקנה של מהדורה ראשונה עובדת:	50%	1,000,000
תיקון שגיאות ושינויים הכרחיים:	20%	400,000
שינויים ושיפורים – 2-1 מהדורות \ י"מ נוספות:	30%	600,000
סה"כ עלות כוללת	100%	2,000,000 ₪

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

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

דוגמא 2

 ·         פרויקט שמוערך ב- 15,000,000 ₪

 ·         אופק זמן כולל של 7 שנים: שלוש שנים פיתוח (ע"י גורם חוץ) וארבע שנים תחזוקה

 ·         הוספת 3-2 יחידות מסירה (מהדורות) חדשות

טבלת התפלגות העלויות תהיה כדלהלן:

פעילות	% מהעלות הכוללת	דוגמא מספרית
פיתוח והתקנה של מהדורה ראשונה עובדת:	50%	7,500,000
תיקון שגיאות ושינויים הכרחיים:	20%	3,000,000
שינויים ושיפורים – 3-2 מהדורות נוספות:	30%	4,500,000
סה"כ עלות כוללת	100%	15,000,000 ₪

בדוגמא זו, תהיה ההוצאה השנתית לתחזוקה 750,000 ₪, היינו כ"א בהיקף של כשלוש משרות המוקדשות לתחזוקה שוטפת של המערכת (בהנחה של 220,000 ש"ח עלות שנתית לעובד ובהנחה שהתחזוקה אכן תתחיל בשנה הרביעית ותימשך 4 שנים. חריגה משמעותית מערך זה היא איתות על בעיות בתחזוקת המערכת: האם מבוצעים שו"ש בתהליך של תחזוקה, האם המערכת זקוקה לשיפוץ\שכתוב רציני, האם יש צורך בתחקור וכו'.

טכניקות ניהול זמן

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

ניהול תצורה – רכיב 4.6

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

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

הפרדה בין תקלות ובין שו"ש

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

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

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

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

אם התחזוקה בעיקר ברכיבים אלה	סביר שסוג התחזוקה הוא
1. יעדים	שו"ש - עדכון תחזוקתי של יעדים הוא נדיר
2. יישום	מותנה בתת-הרכיבים להלן
2.2 משתמשים	שו"ש
2.3 חלוקה לתת-מערכות	שו"ש
2.4.0 הנדסת אנוש	שו"ש
2.4.1 מסכי תפריט	שינויים חיצוניים
2.4.2 מסכי פעולה	שו"ש
2.5 תהליכים	שו"ש
2.6 טרנזקציות	שו"ש
2.7 מודולים	שו"ש או תיקון שגיאות
2.9 שגרות	שו"ש
2.10 טבלאות	שו"ש, להוציא שינוי פרמטרים חיצוני  שתוכנן מראש
2.11 קבצים לוגיים	שו"ש או שינויים כפויים
2.12 קבצים פיסיים	תיקון שגיאות או שינויים כפויים
2.13 מילון שדות	שו"ש או שינויים כפויים
2.15 דו"חות	שו"ש/תיקון שגיאות/שינויים כפויים
2.16 קלטים (טפסים)	שו"ש/תיקון שגיאות/שינויים כפויים
2.19 אבטחת מידע	שו"ש או שינויים כפויים
2.21 עומסים וביצועים	שו"ש
2.22 ממשקים עם מערכות אחרות	שו"ש או שינויים כפויים
2.23 דרישות אחרות	שו"ש
3. טכנולוגיה	יש לבדוק היטב: אם מצד היישום - שו"ש אם מצד התשתית - שינויים כפויים או תיקון תקלות, "תחזוקה מונעת", Upgrades? האמנם נחוצים?
4. מימוש	יש לבדוק היטב: אם מצד היישום - שו"ש אם מצד התשתית - שינויים כפויים או תיקון תקלות בעקבות "תחזוקה מונעת" ו- upgrades?

 

אבטחת איכות

 ·         בדיקת קיום נוהל שינויים, צוות בקרת שינויים, ניהול תצורה

 ·         מעקב אחר שו"ש והצורך במהדורות\גרסאות חדשות

 ·         תיק תחזוקה - תיק מערכת עדכני

 ·         מדריך למשתמש - עדכני

 ·         ביצוע שיקופים (סקרים) על תוכניות חדשות