התקנה והרצה

כללי

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

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

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

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

להלן פירוט פעילויות (תכנית עבודה) לביצוע שלב התקנה והרצה בחלוקה לקבוצות פעילויות:

 ·         בדיקות התקנה

 ·         הסבות למערכת החדשה

 ·         הדרכה והטמעה

 ·         הרצת המערכת

 ·        סיום פרוייקט הפיתוח

 ·        תחילת פרוייקט התחזוקה

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

בדיקות התקנה

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

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

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

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

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

 ·         גורמים אחרים: היקף המערכת, מידת הקריטיות לפעילות הארגון ועוד.

להלן תיאור של שני מקרי קצה:

 ·         בדיקות התקנה בסיסיות בהתקנת תוכנת מדף או התקנה חוזרת.

 ·         בדיקות התקנה מורחבות בהתקנת תוכנה ייעודית או ייחודית)

בדיקות התקנה בסיסיות

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

הפעילויות בשלב זה:

1.       קיומה של רשימת תכולה מסודרת, הכוללת:

             ·         הנחיות ודברי הסבר כלליים

             ·         ציוד

             ·         מדיה מגנטית

             ·         תיעוד נלווה

             ·         דפי עבודה: יומן, רשימות איכות

2.       התאמה בין הרשימה לפריטים שהתקבלו

3.       הוראות התקנה

             ·         תנאים מקדימים: קונפיגורציה וסביבה נדרשת

             ·         Install (Setup)

             ·         יכולת נסיגה: Uninstall

4.       בדיקה פרטנית לקיומם של:

             ·         מדריך למשתמש

             ·         תעודת אחריות

             ·         כתובת/טלפון של הספק (למי לפנות אם מתגלות בעיות)

5.       ביצוע ההתקנה

לאחר ההתקנה רצוי לבדוק:

             ·         פתיחת/סגירת המערכת

             ·         דפדוף באופציות התפריט הראשי

             ·         ביצוע מס' פעולות אקראיות

             ·         בדיקה אקראית של מסכי העזרה (Help)

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

בדיקות התקנה מלאות

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

בדיקות התקנה יכללו את כל הבדיקות המופיעות בסעיף לעיל, ובנוסף:

1.       זיהוי המהדורה המותקנת:

             ·         בתיעוד,

             ·         במסכים,

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

2.       בדיקה של כל התיעוד התפעולי:

             ·         תיק מערכת מסודר,

             ·         תיק תפעול עדכני,

             ·         כל התיעוד בסעיף 4.5.1 בתיק המערכת.

3.       תשתית לקליטת המערכת:

             ·         תשתית פיסית/סביבתית - אם נדרשה?

             ·         רכיבים שהם באחריות המתקין (המשרד/הארגון).

4.       פתיחת (העלאת) המערכת במספר אופנים:

             ·         לאחר סגירה מסודרת (בבוקר),

             ·         לאחר סגירת חירום: עם/בלי שיחזור,

             ·         לאחר נפילה: עם/בלי שיחזור.

5.       כניסת משתמש למערכת:

             ·         הרשאות: אבטחת מידע.

             ·         חשבונאות: תמחיר

6.       ניסוי הממשק התפעולי (מסכים):

             ·         ניסוי עץ התפריטים ברמה שנייה (לפחות),

             ·         ניסוי מספר טרנזקציות המכילות הקשת נתונים (Data entry).

7.       סגירת המערכת במספר אופנים:

             ·         עם/בלי גיבוי,

             ·         סגירה הדרגתית וסגירה מידית (חירום).

8.       הפקה נסיונית של דוחות ייצוגיים:

             ·         2 דוחות שכיחים,

             ·         2 דוחות תקופתיים.

9.       הרצת 2-3 מהלכי Batch אופייניים:

             ·         2 דוחות שכיחים.

             ·         מהלך קלט/ממשק ממערכת אחרת

             ·         מהלך עדכון

 

הסבות למערכת החדשה

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

 ·         רכיב 2.1 מאפיינים כלליים,

 ·         הרכיב הקונקרטי השייך להסבה, כגון:12 - 2.11 קבצים, 2.10 טבלאות,

 ·         רכיב 3.13 כלי פיתוח ותחזוקה,

 ·         רכיב 3.15 כלי תפעול וייצור,

 ·         רכיב 4.7  השתלבות בארגון (תת-רכיב 4.7.2).

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

הסבות חד-פעמיות

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

 ·         הסבת קבצים מהמערכת הקיימת

 ·         קליטת נתונים חד-פעמית ממקורות חיצוניים

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

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

הסבות שוטפות

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

הדרכה והטמעה

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

הדרכה

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

יש לארגן הדרכות שונות בהתאם לסוגי האוכלוסיות להדרכה. סוגי ההדרכות השכיחים הם:

 ·         Overview של המערכת

 ·         תפעול ע"י משתמש קצה (לפי בעלי תפקידים שונים; לפי תת-מערכות)

 ·         תפעול מרכזי (Housekeeping)

 ·         הדרכה תוך-כדי-עבודה (On the job training)

 ·         הדרכה מקצועית לאנשי ענ"א.

הטמעה

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

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

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

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

 ·         הערכת מידת שביעות הרצון של המשתמשים מהמערכת.

 ·         ריכוז וניתוח משוב מהמשתמשים, קיום שיחות משוב קבוצתיות.

 ·         מתן תשובות מהירות לבעיות אמיתיות, תוך יידוע המשתמשים.

 ·         מתן תמיכה צמודה ומהירה למתקשים ע"י מדריך או מרכז סיוע.

הרצת המערכת

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

קיימות שתי גישות בסיסיות להרצת מערכת:

 ·         הרצה במקביל

 ·         קפיצה למים עם דרך נסיגה – בהרצה מלאה או כפרויקט פיילוט.

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

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

 ·         היא עצמה בודקת את המערכת בצורה יסודית ועל אמת.

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

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

 ·         שמירה על המערכת הישנה במצב תקין,

 ·         הסבה נגדית של נתונים,

 ·         כפילויות שונות כגון: ציוד, תוכנות, הוראות הפעלה,

 ·         מערכות מיתוג שונות.

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

פרויקט פיילוט

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

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

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

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

שיקולים לביצוע פיילוט לפרויקט

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

יש לאמת כי:

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

 ·         המשתמש יקבל את ממשק המשתמש החדש - במקרים של מערכות שמשנות מהותית את ממשק המשתמש המקובל

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

שיקולים לוויתור על ביצוע פיילוט לפרויקט

 ·         הנחיית הנהלה לפריסת מערכת בשטח "בכל מקרה" (מערכת קריטית, time to market ועוד)

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

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

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

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

פעילויות לביצוע לפני תחילת הפיילוט

 ·         קבלת אישור המשתמש למערכת

 ·         כינוס צוות הפיילוט: הגדרת נציג מכל יחידה ארגונית הרלוונטי לשלב הפיילוט

 ·         כתיבת תוכנית עבודה (גאנט) לתקופת הפיילוט

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

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

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

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

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

 ·         מתי אין צורך עוד בפיילוט, וניתן לבצע העברה לייצור

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

פעילויות לביצוע עם סיום הפיילוט

 ·         דיון בועדת היגוי בו יציג צוות הפיילוט את הממצאים וההמלצה לסיום הפיילוט

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

הפקת לקחים

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

 ·         עידון ועדכון ציון סופי של פיילוט

 ·         משך זמן לפיילוט – מניעת פיילוטים מתמשכים, והגברת המוטיבציה של מנהלי הפרויקטים

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

 ·         וידוא עמידה ברווחיות המתוכננת של הפרויקט (עלות/תועלת > 0)

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

 

סיום פיתוח והעברה לייצור

מחזור חיים מלא של מערכת מידע נחלק לשני חלקים עיקריים: פיתוח ותחזוקה.

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

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

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

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

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

 ·         השלמת תיעוד

 ·         סגירת מסגרות הפיתוח

 ·         קביעת כלים ונהלי עבודה

לשלבים אלה מספר מטרות חשובות:

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

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

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

בחינה והשלמת תיעוד

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

המסמכים שיש לבחון ולעדכן:

 ·         תיק מערכת (תחזוקה)

 ·         תיקי תכנות

 ·         תיק בדיקות מערכת, תיק סיכום בדיקות

 ·         מדריך למשתמש

 ·         תיק ייצור/תפעול

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

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

סגירת מסגרת הפיתוח

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

 ·         קיטלוג מלא של כל רכיבי המערכת בסביבת הייצור, כולל רכיבי תיעוד

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

 ·         מחיקת גיבויים של רכיבי הפיתוח, החזרה או ביטול גיבויים במתקן גיבוי מרוחק

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

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

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

 ·         פיזור צוות הפיתוח

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

ראה דיון מפורט בקיט תחזוקה בכרך מחזור חיים.

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

 ·         נוהל ניהול תצורה - מומלץ להשתמש בכלי ממוכן התומך בניהול תצורה. בהעדר כלי ממוכן יש לקבוע  נוהל לניהול ידני של תצורת המערכת ע"י הפרדה מינימלית בספריות שונות.

 ·         נוהל פיתוח מהדורות המשך /יחידות מסירה.

עבור מהדורות (כאשר יש שינויים משמעותיים במערכת) הנוהל יתייחס לשלבי העבודה הבאים:

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

 ·         תכנון מהדורה ספציפית

 ·         פיתוח מהדורה

 ·         בדיקות תקינות ע"י צוותי פיתוח ומשתמשים

 ·         התקנה והפצה

 ·         כימות איכות מהדורה

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

 ·         תכנון מהדורה ספציפית

 ·         פיתוח מהדורה

 ·         בדיקות תקינות ע"י צוותי פיתוח ומשתמשים

 ·         התקנה והפצה

תחילת פרויקט התחזוקה

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

כינוס ועדת היגוי/גוף משתמשים של המערכת לצורך קבלת החלטות בנושאים הבאים:

1.       הגדרת הגורם המתחזק ותחומי אחריות של כל הגורמים המעורבים:

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

             ·         אילו צוותי פיתוח רלוונטים לביצוע השינויים שידרשו בעתיד?

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

3.       החלטה על אופן קביעת גרסה/מהדורה למערכת:

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

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

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

4.       קביעת אבני דרך לתקופת הייצור ותפעול שוטף - מועד פרסום מהדורות המשך.

בניית מסגרות לתחזוקה

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

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

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

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

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

תיעוד ונהלים למערכת

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

 ·         משתמשים ומערכות משיקות (סעיף 2.2)

 ·         קבצים פיזיים (סעיף 2.12)

 ·         תפעול שוטף (סעיף 4.4)

 ·         אינדקס תיעוד (סעיף 4.5)

 ·         שירות ותחזוקה (סעיף 4.6)

 ·         תצורות (סעיף 4.9)

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

קיומם של מערכי הדרכה מסודרים למערכת (סעיף 4.7.1).

תוצרים

תוכנית התקנה וקליטה

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

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

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

תכנון ההיערכות

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

מימוש התכנון

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

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

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

בדיקות התקנה - רשימת תיוג

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

רשימת התיוג כוללת הנחיות לבדיקות בשני מקרי הקצה המתוארים לעיל:

 ·         בדיקות התקנה בסיסיות בהתקנת תוכנת מדף או התקנה חוזרת.

 ·         בדיקות התקנה מורחבות בהתקנת תוכנה ייעודית או ייחודית)

התקנת מערכת – רשימת תיוג

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

העברה לייצור – רשימת תיוג

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

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

אבטחת איכות

 ·         בדיקת קיום תכנון בדיקות התקנה באתר הניסוי על המערכת בייצור, כולל תיק בדיקות התקנה ותיק סיכום בדיקות התקנה

 ·         בדיקת קיום מדדי הצלחה לניסוי ועמידה בהם

 ·         הפקת לקחים מתהליך הפיילוט ויישומם במערכות בארגון

 ·         בדיקת קיום מנגנון ניהול שינויים מסודר

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

 ·         בדיקת קיום תיק תפעול

 ·         בדיקת קיום הדרכות לגורם המתפעל

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

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

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