חלק מרכזי בניהול המחשוב וביצירת תשתית אבטחת איכות וניהול פרויקטים מסודר בארגון, הוא הטמעת מפת"ח. הטמעה זו כוללת: לימוד הנוהל ומאגר הידע, קיום הדרכות, התנסות ויישום רצוף ועקבי בכל הפרויקטים המתבצעים בארגון ובפעילויות הנהלת המחשוב עצמה. מדריך זה מכיל את כל ההנחיות הדרושות כולל הנושא של התאמת מפת"ח ושילובו בספר הנהלים הכללי של הארגון (התאמה לצד הטמעה).
מדריך זה הוא "הנוהל המלא" ובסיס הידע הראשי של הטמעת מפת"ח בארגון.
חלק מרכזי בניהול המחשוב הוא גיבוש שיטות ונהלי עבודה, הנחלתם והטמעתם. זו איננה משימה קלה. הדבר כרוך בלמידה, שינוי דפוסי עבודה, שינוי במדדים הנמדדים בארגון והערכה של תפוקות והישגים, שינוי ב"שפה" בה הארגון מתנהל ועוד. אימוץ מפת"ח מקל מאד על משימה זו מעצם העובדה שמדובר בנוהל נפוץ ומוכר אשר בנוי על מודל פשוט ובעל אלמנטים רבים של שימוש חוזר. עם זאת, גם הטמעת מפת"ח היא משימה שיש להיערך אליה בצורה מסודרת.
בהטמעת מפת"ח יש לקחת בחשבון מספר גורמי יסוד:
· מחויבות הנהלה
· גורם מוביל בארגון
· שיטה ופעילויות הטמעה
· שילוב מפת"ח בנהלי הארגון
בתהליך הטמעת מפת"ח יש להיזהר מקיצוניות בשני הכיוונים. יש לראות בנושא זה פרויקט לכל דבר ועניין. אין סיבה מדוע לא לנהל את הטמעת מפת"ח כפרויקט שיש לו התחלה וסוף, שלבים ברורים (ייזום\אפיון, "בנייה", לעתים אפילו בקשה להצעות), מדידה, עלות\תועלת וכו'. מאידך, אין להגזים ולנפח את הנושא, בפרט אם מחליטים ללכת בשיטה של "מלמטה למעלה" ובשלב ראשון מיישמים את מפת"ח על פרויקט(ים) מוביל(ים) על מנת להתנסות בנושא זה. בכל מקרה, כדאי לשים לב לגלופות הלימוד והעבודה שבקיט זה ולהשתמש בהן באופן מושכל כגלופת ייזום, אפיון וכו' או כרשימת תיוג קצרה.
ניהול הטמעת מפת"ח בשיטת מפת"ח הוא תרגיל טוב בניהול פרויקטים לאבטחת איכות עצמה והוכחה ש"הסנדלרים לא הולכים יחפים".
הטמעת מפת"ח היא פעולה רוחבית אשר חוצה את הארגון. גם אם מתמקדים תחילה בפרויקט זה או אחר, הגורמים המעורבים בפרויקט נמצאים במקומות רבים בארגון, לא רק במנהלת הפרויקט. ללא מחויבות הנהלה "וברכתה" יקשה מאד לתאם ביניהם ולקדם את התהליך. מה עוד שההתנסות בפרויקט הראשון תשמש תקדים, לטוב או לרע, להמשך התהליך.
מומלץ למנות נציג הנהלה שיפקח על פרויקט הטמעת מפת"ח בארגון. הגורם המוביל, כפי שיפורט בסעיף הבא, ידווח לנציג ההנהלה על התקדמות הפרויקט בפגישות תקופתיות קבועות. אחת לתקופה מוגדרת תתקיים ישיבת הנהלה לדיון בהתקדמות הפרויקט.
יש לשתף בפרויקט גורמים נוספים בארגון:
· מומחה היישום
· מחלקה משפטית
· מחלקת רכש
· סיוע טכני
· מחלקות נוספות ופרויקטים שכנים לפי הצורך
איכות וסדר הם חלון הראווה של הארגון. בעברית, נוהל וניהול באים מאותו השורש.
לאחר קיום התנאי הראשון להצלחה – מחוייבות הנהלה, יש צורך במינוי גורם מוביל אשר באחריותו תהיה הטמעת מפת"ח. באופן טבעי גורם זה יהיה פונקצית אבטחת איכות בארגון. אם פונקציה זו קיימת כבר, היא צריכה לקבל חיזוק בעקבות הוספת משימת הטמעת מפת"ח. עבודתה של יחידה זו משתנית. לא עוד כתיבת נהלים מהתחלה, אלא לימוד מפת"ח והטמעתו בארגון, כולל עבודה מעשית של אבטחת איכות בפרויקטים. לאחר מכן תהיה פעילות של השלמת נהלים נוספים רלוונטיים לארגון, רכישת כלים וכו'.
אם פונקציה כזו בארגון עדיין אינה קיימת, זו הזדמנות להקימה בצורה מסודרת. הניסיון מוכיח שלעיתים קרובות תהליך הטמעת מפת"ח הסתיים בהקמת גוף א"א. ראה הקיט אבטחת איכותQA - בכרך איכות.
במידה ואין אבטחת איכות או תכניות להקים פונקציה כזו, אפילו לא במשרה חלקית, אין מנוס מלהטיל את המשימה אד-הוק על גורם כלשהו בארגון, או ישירות על "פרויקט מוביל".
אפשר בהחלט להסתייע בגורם חוץ בהטמעת מפת"ח בארגון. לגורם חוץ מספר יתרונות: ניסיון קודם, אי-תלות בפוליטיקה פנימית, הימנעות מהוספת תקנים וכו'.
העובדה שמפת"ח מטפל הן במערכת הבודדת והן בארגון בכללותו, פותחת בפני הנהלת יחידת המחשוב שתי אפשרויות הטמעה שונות :
· מלמטה למעלה (Bottom-up): קודם בפרויקט אחד ואחר הכלה על הארגון כולו.
· מלמעלה למטה (Top-down): החלטה גורפת של מפת"ח כנוהל מחייב בארגון ואז הורדת ההטמעה לכלל הפרויקטים בארגון.
לעיתים הלחץ להטמעת מפת"ח נוצר בשטח, בפרויקט מסויים או לנוכח צורך מקומי מסויים. לחילופין, על מנת להתחיל הטמעה ראשונית בוחרים מערכת מידע מסוימת ומיישמים בה את מפת"ח בהתאם לשלב בו היא נמצאת. רצוי שזו תהיה מערכת חשובה ואופיינית לארגון. בהמשך בוחרים מערכות נוספות. לאחר תקופת מה, בה נרכש ניסיון בעבודה עם הנוהל, יש לבצע עבודת מטה של שילוב מפת"ח בנהלים וכלים קיימים בארגון.
בגישה זו הנהלת הארגון מכירה בצורך של הטמעה רוחבית ומתקיים אקט של הכרזה על מפת"ח כנוהל מוביל. בשלב זה מתחילים בעבודת מטה של שילוב מפת"ח בנהלים וכלים קיימים בארגון. לאחר מכן יש להתחיל בפעולה מקבילה של ביצוע פרויקטים (מערכות מידע ותשתיות). בביצוע הפרויקטים אפשר ללכת בהדרגה ולהתחיל במערכת אחת (רצוי מערכת מידע) ורק אחר כך לעבור למערכות נוספות.
קשה לייעץ באיזו גישה לבחור בלי להכיר את הארגון. הגישה "מלמעלה למטה" מותנית בקיומה של מחויבות הנהלה גבוהה ובקיומו של גורם מוביל דומיננטי. גישה זו גם תועדף במקרה של הסמכה לתקן ISO 9000. הגישה "מלמטה למעלה" תועדף, לעומת זאת, במקרים הבאים: פרויקט גדול שהטיפול בו מיידי וחיוני, מקרה בו הארגון לא משופע בכלים ושיטות או שקיימת עדין חוסר הסכמה לגבי הטמעה רוחבית של מפת"ח.
בשתי הגישות כלולות מספר פעילויות בסיסיות:
· הדרכות
· ליווי פרויקטים ובקרת תיעוד
· שילוב מפת"ח בכלים ונהלים קיימים
· להתחיל באמצע
בכל שיטה ודרך שייבחרו (ראה הסעיף הקודם), פעילויות הטמעת מפת"ח ונהלים משלימים כוללות:
· הדרכות (ימי עיון, סדנאות וכו')
· ליווי פרויקטים ובקרת תיעוד
· שילוב מפת"ח בכלים ונהלים קיימים
· תיקיות הפרויקט
הדרכות לסוגיהן השונים: ימי עיון, הרצאות, סדנאות וכו', נחוצות הן על מנת לקיים רמה התחלתית של ידע והן על מנת להרחיב ולהעמיק לאלה שכבר התנסו ועבדו לפי מפת"ח. כלל ראשון בהדרכה הוא הבחנה בין סוגי אוכלוסייה שונים. היעד העיקרי להדרכות במפת"ח הן קבוצות האוכלוסייה הבאות:
|
אוכלוסייה |
הכשרה נדרשת |
|---|---|
|
מנהלים ביחידת המחשוב |
מפת"ח למנהלים |
|
ראשי צוותים, מנהלי פרויקטים |
סדנא להכרת מפת"ח, מכרזים (בקשה להצעות) |
|
מנתחי מערכות |
סדנא להכרת מפת"ח, מכרזים (בקשה להצעות) |
|
אנשי סיוע טכני |
מפת"ח לאנשי סיוע טכני |
|
מתכנתים |
הכרת מפת"ח |
|
משתמשים |
מפת"ח למשתמשים |
|
מבקרי מ"מ ויועצים משפטיים |
הכרת מפת"ח, הצד המשפטי של מפת"ח, בקשות להצעות |
|
חשבים, אנשי רכש וכלכלנים |
הכרת מפת"ח, מפת"ח ומכרזים (בקשה להצעות) |
לכל סוג אוכלוסייה יש לתת את סוג וכמות ההדרכה המתאימים.
ליווי פרויקטים הוא פעילות מרכזית בהטמעת מפת"ח. לאחר סיום ההדרכות הפרונטאליות, יש צורך להשלים הדרכות אלה בהדרכות אישיות, או במילים אחרות בליווי אישי. הגורמים אותם יש ללוות הם כל אותם גורמים שמשתמשים במפת"ח בפעם הראשונה ומרגישים צורך בליווי אישי וצמוד. תהליך הליווי הוא הדרכתי באופיו, אם כי יש בו גם היבטים של סיוע. לדוגמא מנהל פרויקט שכותב לראשונה מסמך ייזום, הגורם המלווה יסייע לו בכתיבת המסמך. לרוב, הגורמים שאותם יש ללוות הם מנהלי פרויקטים ומנתחי מערכות בארגון.
פעילות משלימה לפעילות הליווי היא בדיקת תיעוד. על מנת לוודא שהטמעת מפת"ח מתבצעת בצורה יעילה יש צורך בתהליך של בקרה על התיעוד שנכתב. בעיקר מדובר על מסמכים במהלך מחזור חיים כגון: ייזום, אפיון, בדיקות ותחזוקה, אם כי אפשר לבקר גם מסמכים אחרים כגון: ניתוח סיכונים, אומדן עלויות, ניתוח חלופות ועוד. פעילות בקרת התיעוד צריכה להתבצע מוקדם ככל האפשר במהלך כתיבת המסמך, על מנת שלא יווצר "צוואר בקבוק" אצל הגוף המבקר. מומלץ שהבקרה תעשה בכתב.
ברוב הארגונים הנוהל הממוחשב ישולב בסביבה הממוחשבת של הארגון. במידה שאין זה כך, יש להתקין את הנוהל הממוחשב בתחנות העבודה של הגורמים שעובדים עם מפת"ח.
מטרה נוספת היא שפרויקטים יעבדו עם סביבת עבודה מוכנה בה מפת"ח משולב בכלים שהם אמונים עליהם.
קיימים בשוק מספר כלים לפיתוח ותחזוקה (CASE), לניהול התיעוד וניהול הפרויקט, המשלבים את מפת"ח בתוכם או שמסוגלים להתקשר למפת"ח בצורה זו או אחרת. הגישה המקובלת היא, שהכלי פועל באופן הטבעי לו והתיעוד המופק הוא במבנה הנדרש ע"י מפת"ח.
שני אמצעים חשובים נוספים הם:
· בניית ספריית גלופות מרכזית בה ירוכזו גלופות מפת"ח, גלופות וטפסים של נהלי הארגון וטפסים ותבניות כלליים.
· אימוץ שיטה תקנית לתיקיית הפרויקט. ראה קיט תיעוד בכרך נושאים תומכים.
תכונה חשובה, המשפיעה על תהליך ההטמעה, היא היכולת להיכנס בכל שלב, היינו, היכולת להחיל את מפת"ח על כל מערכת בכל שלב בו היא נמצאת. אפשר להתחיל לעבוד בשיטת מפת"ח מיידית. גם מערכות הנמצאות בשלבים מאוחרים של מחזור החיים, כגון בדיקות או תחזוקה, יכולות להתחיל להשתמש במפת"ח ואין שום סיבה או צידוק לחכות למערכת חדשה, או אפילו למהדורה חדשה. זאת ועוד, כל התחלה כזו, "מהאמצע", שומרת על ההשקעה במעבר לשלב הבא, שכן במפת"ח כל השלבים מתועדים לפי אותו סרגל.
· עיצוב ובנייה: בניית תיק עיצוב במהלך שלב העיצוב והבנייה, גם בלי תיק אפיון מקדים, כטכניקת ניהול ובקרה (ואבטחת איכות) על התקדמות הפרויקט. התוצאה: תיק מערכת המשמש הן את המבדקים (תרחישים ותסריטים לבדיקה) והן את התחזוקה. מהלך כזה דורש תיאום עם כלי הפיתוח, נושא המוסבר בהרחבה בפרק עיצוב ובנייה.
· בדיקות מערכת: בניית תיק בדיקות ותיק סיכום בדיקות לפי עץ המערכת, גם בלי תיק אפיון או תיק עיצוב. עץ המערכת משמש בסיס להגדרת התרחישים והתסריטים לבדיקה וסיכום ממצאי הבדיקות.
· תחזוקה: החלת ניהול ובקרת שינויים ישירות בשלב התחזוקה. דרך זו אפשרית וכדאית, כפי שהוכח בארגונים רבים. הוספת תיק תחזוקה שהוא נקודת הייחוס לכל שינוי ומתעדכן תקופתית (לא בהכרח בתדירות של בקרת השינויים השוטפת) היא תוספת סבירה שתועלתה לתחזוקה עצמה ולמעבר למהדורות הבאות של המערכת היא חד משמעית. שילוב עם כלים ממוחשבים הוא סיוע חשוב וחיוני.
"התחלה מהאמצע" נעשית ע"י פעולה של "מפתוח" המערכת. מפתוח מערכת הוא התמרה של חומר קיים (תיעוד, חלקי מערכת, סקרים, תוכנית אב וכו'), לרכיבים המתאימים בעץ המערכת. פעולת המפתוח יכולה להיות בדרך של:
· סימון החומר
· העברה פיסית
· תיעוד מחדש
במקרים מסוימים מבוצע המפתוח ע"י בנית אינדקס תיעוד, היינו, תיעוד תמציתי הבנוי לפי עץ המערכת, אך מכיל בעיקר הפניות לחומר קיים. תיעוד כזה מכיל חוצץ וכותרת לכל אחד מרכיבי עץ המערכת (ברמה השניה), אך התוכן שבכל רכיב הוא מצומצם ומכיל בעיקר הפניות לתיעודים אחרים או לחלקי מערכת קיימים. זו שיטה פשוטה וזולה לתיעוד מהיר וממצה של מערכת בכל שלב בו היא נמצאת. לפעולת המפתוח מסייע מאד גם השאלון שבקיט זה.
פשטות המפתוח מקורה בכך שמפת"ח איננו ממציא שום דבר חדש אלא "עושה סדר" במונחים ובמושגים מוכרים וידועים.
התועלת שבמפתוח נובעת מהסיבות הבאות:
· מפתוח הוא פעולת אבטחת איכות מרכזית. רכיבים בסרגל שנשארו ריקים לאחר ההתמרה מעידים על חסר אפשרי במערכת.
· הסרגל עצמו מסייע בהשלמת החסר, היינו, השלמת המערכת.
· המפתוח מוודא את המשכיות המערכת ומעבר מסודר לשלב הבא; וכן את היכולת לעקוב ביתר קלות, מכאן ואילך, אחר התפתחות המערכת.
מפתוח מערכת היא פעולה ראשונה במערכות קיימות (מערכות שכבר הוחל בהגדרתן או בנייתן ברמה כלשהי), עוד לפני קביעת עץ המערכת הפרטי. אדרבא, תוך כדי פעולת המפתוח הולך ומתברר עץ המערכת הפרטי.
ליכולת "להיכנס באמצע" ולפעולת מפתוח המערכת, יש השפעה רבה על החלטת ההנהלה באיזו גישה (מסלול) של הטמעת מפת"ח לבחור.
בעיה מרכזית שנתקלים בה בעת ביצוע מפתוח של מערכות הארגון היא מתן תשובה פשוטה לשאלה:
מה היא בעצם המערכת הנדונה והיכן היא נמצאת ?
לפני שניגשים לפעילות כלשהיא בפרויקט, יש לאבחן ולאתר "באיזו מערכת מדובר והיכן היא נמצאת?" החלק הראשון - באיזו מערכת מדובר (או מה היא בעצם המערכת?) - נקרא זיהוי. החלק השני - היכן נמצאת המערכת - נקרא מיקום. במונחי מפת"ח, זיהוי הוא האבחנה באיזה עץ מערכת להשתמש (ציר ה- Y במטריצה הראשית של מפת"ח) ואילו מיקום הוא האבחנה באיזה שלב במחזור החיים נמצאת - או צריכה להימצא - המערכת (ציר ה- X במטריצה). מטריצת מפת"ח, כפי שהוצגה בפרק מודל מפת"ח, היא אפוא כלי עזר מרכזי הן לזיהוי והן למיקום המערכת (הפרויקט).
בגישת המטריצה של מפת"ח מודגשת עדיפות ציר ה- Y (עץ המערכת) על פני ציר ה- X (מחזור החיים). לפיכך, גם ההנחיות שלהלן דנות ראשית בזיהוי המערכת ושנית במיקומה במחזור החיים. עם זאת, ברור שקיימת גם אפשרות הפוכה:מיקום תחילה ואחר כך זיהוי. כל מערכת ופרויקט ינהגו באופן המתאים להם (מפת"ח הוא נוהל מסגרת!). זאת ועוד, בפועל יש תלות הדדית ברורה בין שני הצירים וקשה לפעול באחד מהם ללא פעולה מקבילה בשני.
לצורך זיהוי המערכת יש לברר האם המערכת הנדונה היא מערכת מידע או מערכת תשתית. להלן הגדרה תמציתית:
מערכות ממוחשבות ייעודיות הבאות לשרת את יחידות הארגון במגוון פעילויותיהן: מתן שירות ללקוחות, תפעול וניהול שוטפים, קבלת החלטות אסטרטגיות וכו'. מערכות מידע הן התכלית - היעד הסופי - של כל המחשוב בארגון. המחשוב עצמו איננו יעד, אלא אמצעי להגשמת יעדי הארגון. התוצר העיקרי של מערכות מידע הוא מידע (אינפורמציה) ומכאן שמן. דוגמאות למערכות מידע: שכר, כ"א, כספים (הנה"ח), מכירות, רכש, מלאי וכו'.
כל המערכות הטכניות אשר תומכות במערכות המידע ומאפשרות את פעילותן. תשתיות כוללות: חומרה, תוכנה בסיסית system, תשתית פיסית כגון: כבלים, חדר מחשב וכו'. תשתיות הן כל המערכות בארגון שלא ניתן לסווגן כמערכת מידע. התוצר הראשי של מערכות תשתית הוא שירות הנמדד ביחידות שירות למערכות מידע או למערכות תשתית אחרות. תשתיות הן מערכת לכל דבר שיש לה עץ מערכת ומחזור חיים. מאידך הן משרתות את מערכות מידע ולא מטרה בפני עצמה. יש לשאוף למצב בו תשתיות הן מינימום, או נבנות כחלק ממערכת מידע
תשתיות הן אמצעי לקידום מערכות מידע - מערכות מידע הן אמצעי לקידום מטרות הארגון.
דרך נוספת לזיהוי המערכת הוא השימוש בשאלון להערכת מערכת ממוכנת, כמפורט בקיט תחקור – הערכת מערכת בכרך יסודות/מחזור חיים.
מעיון שטחי בחלק מחזור חיים, אפשר לנסות ולאתר את השלב בו נמצאת מערכת.
· אם מדובר במערכת קיימת ועובדת, ברור שהיא נמצאת בשלב התחזוקה ויש להחיל עליה את פרק התחזוקה.
· אם מדובר בפרויקט שבו הנושא המרכזי הנדון הוא איך לפנות לספקים ולקבל מהם הצעות, מדובר בשלב הבקשה להצעות, בין אם זה מכרז פורמלי ובין אם זו פנייה ישירה לקבלת הצעות או מו"מ. במקרה זה, יש לבדוק היטב אם בוצע אפיון למערכת בעזרתו ניתן להפיק מפרט ומפ"ל ברורים.
· אם מדובר במערכת שבנייתה הסתיימה ויש להכניסה לפעולה, תיתכנה אחת משתי אפשרויות שיש לבררן היטב: המערכת נמצאת בשלב ההתקנה או שהמערכת נמצאת בשלב הבדיקות.
· Last but not least - בכל המקרים בהם נטען ש: "יש כבר מסמך ראשוני", "המערכת בתכנון", "המערכת בשלבי הגדרה" וכו', סביר שהמערכת נמצאת - או צריכה להימצא - בשלב האפיון.
לגודל (היקף) המערכת יש גם כן השפעה על זיהויה ומיקומה, בפרט במקרים של פיתוח ותחזוקה בעזרת גורמי חוץ. נושא זה מודגש לאורך כל מפת"ח בפרקים המתאימים.
אם לאחר הקריאה בפרק זה, עדיין קשה לזהות ולמקם את הפרויקט, העצה הפשוטה ביותר היא לגשת לשלב הייזום. "ייזום מערכת" איננו רק במקרים של התחלת מערכת חדשה, או מהדורה חדשה למערכת קיימת. ייזום הוא שלב בו משורטטת תמונה כללית של המערכת (חדשה או קיימת!) - לצורך תכנית עבודה שנתית, למשל - ובו נבנה עץ מערכת ראשוני וכללי. אם סוג המערכת ידוע מראש, עץ המערכת הראשוני ייבנה בקלות יחסית מתוך אחת הדוגמאות שבנוהל מפת"ח. אם סוג המערכת איננו ידוע, ייבנה עץ המערכת הראשוני מתוך עץ המערכת האוניברסלי. רכיבי עץ המערכת ילובנו ויתבררו במהלך הייזום ובסוף שלב הייזום נדע "מה היא בעצם המערכת הנדונה". בסוף שלב הייזום נוכל גם לדעת "היכן נמצאת המערכת". זאת נעשה בעזרת תכני מסמך הייזום והשוואתו עם תיעודים אחרים של המערכת ועם המערכת עצמה.
יש לשאוף למצב לפיו יש בארגון ספר נהלים אחד. הכנסת מפת"ח לארגון היא הזדמנות טובה לעריכת "בדק בית" בנושא.
סביר שהארגון ירצה ללכת בדרך של נהלים ממוחשבים, אשר זמינים לאנשי המקצוע בתחנת העבודה שלהם. הנוהל הממוחשב של מפת"ח יכול לשמש דוגמה למיכון נהלים שגם אם לא מאמצים אותה כפי שהיא, היא יכולה להדגים את הרעיון ולסייע ב"מכירתו" בארגון.
הנושאים הבאים במפת"ח מועמדים להתאמה ע"י יצירת נוהל מתאים אשר משנה את ההתייחסויות של מפת"ח או ע"י שילוב מפת"ח בנהלים קיימים.
נושאים כלליים שיש להתאים אותם לנורמה בארגון הם:
· גורמים מעורבים בניהול מערכות מידע או פיתוח פרויקטים, כולל גורמים מחליטים בפרויקט.
· הגדרת גדלי פרויקטים. בהתאמה של נושא זה ישנן מספר אפשרויות:
· להשתמש בסיווג מפת"ח כמו שהוא
· להשתמש בסיווג מפת"ח, אך לשנות את ערכי גודל הפרויקט
· לא להשתמש בסיווג מפת"ח, אלא לייצר סיווג פנימי לארגון
התאמת ההנחיות לנהלים ספציפיים בארגון על בסיס רכיבי נוהל מפת"ח כגון:
|
שם הרכיב |
הנחיה |
|---|---|
|
2.4.0 כללי הנדסת אנוש |
לפי שיטה/נוהל קיים בארגון |
|
2.7 מודולים (תכניות) |
לפי מבנה קיים בארגון, מותאם לשפות תכנות שונות |
|
2.9 שגרות |
קובץ שגרות מרכזי בארגון |
|
2.10 טבלאות קודים |
קובץ טבלאות מרכזי בארגון |
|
2.19 אבטחת מידע |
לפי נהלי אבטחה קיימים בארגון |
|
4.4 תפעול שוטף |
תיק תפעול לפי תקן קיים בארגון |
|
4.6 שירות ותחזוקה |
אם יש בארגון תנאי שירות ותחזוקה תקניים |
|
4.7.4 מדריך למשתמש |
אם יש בארגון מדריך תקני למשתמש |
גלופות שרצוי להתאים אותן, הן:
· פרק המנהלה בבקשה להצעות - התאמה לנוהלי הרכש בארגון
· גלופות חוזים משפטיים
· מינוחי הארגון - התאמת "שפת מפת"ח" לשפה הארגונית (תארים של בעלי תפקידים, זיהוי יחידות ארגוניות וכד')
· התאמה צורנית באמצעות שילוב נייר המכתבים הארגוני בגלופות
כאמור לעיל, דרך מומלצת (בלי להגזים ולנפח) היא לנהל את הטמעת מפת"ח כפרויקט לכל דבר ועניין. פירושו של דבר שיש לפרויקט זה מחזור חיים ועץ מערכת, בדומה לכל פרויקט אחר, אך ייחודיים משלו.
כתיבת מסמך כללי המוגש לאישור ההנהלה.
הגדרה מדויקת של תכנית ההטמעה, איזו גישה נבחרה, פירוט פעילויות.
פניה לגורם חוץ לביצוע ההטמעה או לסיוע.
· הגדרה סופית של תכנית ההטמעה
· שילוב עם כלים ונהלים בארגון
· ביצוע הטמעה בפרויקטים
בדיקה מידת הטמעת מפת"ח בארגון והאם נדרשות פעילויות נוספות.
שילוב הטמעת מפת"ח בתכניות העבודה השוטפות של הארגון.
ראה בקיט זה גלופת לימוד ועבודה - מסמך (תיק) ייזום להטמעת מפת"ח