מטרת מדריך זה להסביר, באופן כללי, את ההיבטים המיוחדים של פרויקט המבוסס על חבילות תוכנה, במסגרת המודל הכללי של מפת"ח. במדריך מודגשים היבטים רלוונטיים ליישום חבילת תוכנה, תוך התאמה של עץ המערכת האוניברסלי לעץ מערכת לחבילות תוכנה (Packages) ושל מחזור החיים הגנרי למחזור חיים מתמחה לחבילות תוכנה. יש לשים לב שמדובר כאן בחבילות תוכנה יישומיות מקיפות ולא בחבילות תוכנה קטנות מהמדף. אלה האחרונות נדונות בקיט מערכות קטנות.
מערכות מידע מבוססות חבילות תוכנה הן מערכות ייעודיות שמטרתן לשרת את הארגון ולסייע באופן ישיר למהלך תפקודו השוטף:
· כספים
· רכש
· מלאי
· משאבי אנוש
· שיווק
· ניהול פרויקטים
· ייצור וכו'
מערכות המידע מצדן נשענות על מערכות תשתית. מערכות מידע צריכות להציג תועלת ישירה שניתן למדוד אותה במדדים הלקוחים מפעילותו העסקית של הארגון: מס' חשבוניות שהופקו, מס' פניות ציבור שטופלו וכו'.
רכיב מרכזי בעץ המערכת של מערכות מידע המבוססות חבילת תוכנה הוא כמובן רכיב 2 יישום, אך יש לשים לב גם לרכיב 3 טכנולוגיה. במקרים לא מעטים, נבנית התשתית הטכנולוגית כחלק מיישום החבילה, בפרט חבילת תוכנה גדולה ומרכזית בארגון. בנקודה זו צריכים אנשי מערכות מידע להיות "על המשמר". מחד גיסא, חובתם לטפל בתשתית ובטכנולוגיה של מערכת המידע שבאחריותם ולוודא קיומה. הטכנולוגיה היא חלק בלתי נפרד מהמערכת! מאידך גיסא, ברגע שרכיב הטכנולוגיה "מתנפח" וצומח לכדי מערכת בפני עצמה, יש להתריע על כך בפני ההנהלה. ייתכן מאד שהארגון צריך לפתוח פרויקט תשתית מיוחד ולא להעמיס על יישום חבילת תוכנה מסוימת (או לפחות לתמחר ולנהל אותה בהתאם). נקודת המבחן להפיכת רכיב 3 טכנולוגיה למערכת תשתית נפרדת, היא ברגע שמסתבר שהוא משרת גם מערכות מידע נוספות וברגע שניתן בעצם לתאר אותו עם עץ מערכת מלא ומחזור חיים משלו.
בסה"כ, אין הגדרה מדויקת לקו העובר בין מערכת מידע ומערכת תשתית. מקרים בהם מערכת מידע "מולידה" מערכת תשתית מקבילה, או הופכת בעצמה ממידע לתשתית בהחלט ייתכנו. ראה קיט תכנית עבודה שנתית בכרך ניהול.
מטרת מדריך זה היא להסביר, באופן כללי, את ההיבטים המיוחדים בעץ המערכת ובמחזור החיים של מערכות מידע המבוססת על חבילת תוכנה. זאת, מבלי לפגוע בכלליות עץ המערכת ומחזור החיים האוניברסליים המוצגים בכרך יסודות. מעיון במדריך יכול הקורא לאמת אם אמנם מערכת נתונה היא מערכת מידע המבוססת חבילת תוכנה ובמידה שכן, גם לדעת את ההדגשים בעץ המערכת ובמחזור החיים עליהם יש לעמוד. הדגשת ייחודיות מערכת מידע המבוססת חבילת תוכנה - כסוג מסוים של מערכת ממוחשבת - נעשית בהדרגה. במדריך זה מודגשים ההיבטים הנכונים לכל סוג של מערכת מידע, תוך התאמה (קסטומיזציה) של עץ המערכת האוניברסלי לעץ מערכת מידע המבוססת חבילת תוכנה. בקיטים אחרים קיימות התאמות נוספות לסוגים ספציפיים ושכיחים של חבילות תוכנה (כגון ERP, משרד ממוחשב ואחרים).
סעיף זה איננו תחליף לקיטים בכרך יסודות/מחזור חיים. יש לעיין תחילה היטב שם ולהכיר באופן מפורט את מחזור החיים האוניברסלי אשר מתאים לרוב הדרישות של מערכות מידע. סעיף זה בא להדגיש היבטים מסוימים במחזור החיים המיוחדים למערכות מידע המבוססות חבילות תוכנה.
אין היבטים מיוחדים, ייזום רגיל לכל דבר ועניין. חלק מתכנית העבודה השנתית. בשלב זה מתבצעת הגדרת הצורך העסקי, נבחנות העלות מול התועלת של המערכת וסקירת דרישות ראשונית.
רכישה של חבילות תוכנה אינה פותרת את הצורך באפיון - בוודאי לא את הצורך בייזום. ראשית, משום שאין כמעט חבילות תוכנה שמתאימות בדיוק וללא צורך בהתאמות. שנית, סביר שיש בשוק מספר חבילות הבאות בחשבון והדרך היחידה לבחור ביניהן היא ע"י הגדרה ברורה "מה בדיוק רוצים", קרי אפיון. אין אפוא מנוס מאפיון גם במקרה של חבילות תוכנה (ליתר דיוק, מקרה שבו סבורים שהפתרון הוא באמצעות חבילות תוכנה). עם זאת, נכון שיש למצוא את שביל הזהב בין אפיון עודף לבין אפיון חסר. נקודת המבחן היא פשוטה. אם אכן ניתן לקצר באפיון, ע"י אזכור תמציתי של תקן (פורמלי, או דה-פקטו) ברכיבים רבים, סימן שהסבירות לפתרון חבילה (פתרון סטנדרטי) היא גבוהה והאפיון יהיה באופן טבעי קצר. אם אין תקנים ואי אפשר לתמצת את האפיון - אפשר שההנחה הבסיסית של פתרון באמצעות חבילה היא מוטעית.
בדרך כלל ניתן להסתפק באפיון-על אשר מגדיר את הצרכים ברמה כללית תוך התמקדות בתהליכים נדרשים. היות וחבילת התוכנה יכולה לעבוד מיידית בארגון המוכן להתגמש ולעבוד על פי התהליכים המוגדרים בה, יש לכתוב אפיון-על אשר בעזרתו ניתן יהיה לאחר מכן לבדוק את מידת התאמת חבילת התוכנה לצורכי הארגון.
לעיתים חבילות תוכנה הקיימות בשוק מתחרות בפתרון של פיתוח עצמי בתוך הארגון. מצב זה מחייב אפיון יותר מפורט מאשר במקרה של בחירה בין חבילות תוכנה.
כחלק מתהליך כתיבת האפיון ניתן לבצע פניה למספר ספקי חבילה באמצעות מסמך RFI – בקשה למידע, או לבצע חיפושים באינטרנט בכדי ללמוד מה מקובל לכלול בחבילות מן הסוג המבוקש. בדרך זו ניתן לאפיין בצורה טובה יותר את הצרכים של הארגון. ניתן להיעזר בקיט בקשה להצעות RFP בכרך מחזור חיים.
בקשה לקבלת מידע (RFI: Request For Information) היא פניה בלתי פורמלית לספקים לצורך קבלת מידע. במפת"ח, אין תהליך מיוחד ל- RFI. בקשה לקבלת מידע יכולה להיעשות באחד משני אופנים:
· במהלך האפיון נבדק "מצב השוק" ע"י הגורם המאפיין כחלק מעבודתו ובאופן דומה לפעילויות לימודיות אחרות: ראיון המשתמשים, לימוד המצב הקיים, בניית אבטיפוס, קריאת ספרות מקצועית ועוד. כל מידע שנאסף בשלב זה הוא באחריות הגורם המאפיין.
· ע"י שלב בקשה להצעות מלא ומסודר. בקשה להצעות מסודרת. אלא שכאן הדגש הוא יותר על סעיפי היישום והטכנולוגיה (ואף הם "לידיעה בלבד" ואינם מחייבים) ופחות על העלות ומנהלה.
ההחלטה באיזה אופן לנהוג היא בידי הארגון והפרויקט ויש להיזהר מלחצות את הגבול הדק העובר ביניהם.
אין היבטים מיוחדים בשלב זה בהשוואה עם המודל האוניברסלי של מפת"ח. יש לנהל מכרז לכל דבר ועניין, אך ייתכן מכרז מוגבל לספקים מתמחים. בשלב זה ייבדקו חבילות תוכנה שונות אל מול ההגדרות הכלליות, באופן יחסי, המופיעות במפרט הבקשה להצעות. יינתן דגש בתשובות המציעים למידה ולכמות ההתאמות הנדרשות בחבילה, על מנת לענות לצרכים המצוינים במסמך הבקשה להצעות. זאת ניתן לקבל על ידי צירוף של טבלאות בסעיפים הרלוונטיים ובהן הספק יצטרך לציין האם הפתרון המוצע מכיל בדיוק את הנדרש. אם אין פתרון בגרסת החבילה הרלוונטית אזי האם הפתרון הנדרש יופיע בגרסה הבאה של החבילה. כמו כן, האם ניתן לבצע התאמה לחבילה בכדי להגיע לפתרון הנדרש. בפרק העלות, כמובן תהיה התייחסות לכל אחת מן ההתאמות אותן הספק הציע.
אם קיימות חבילות רבות בתחום המבוקש, ניתן להגדיר תנאי סף או מספר תנאים אשר מצמצמים את מרחב הפתרונות ומתמקדים מראש במספר מצומצם של חבילות המתאימות יותר לצרכים המוגדרים.
במכרזים לחבילות תוכנה מומלץ להבנות את המסמך ולהשתמש יותר בטבלאות (שרבות מהן יכולות להילקח מרכיבי 0.Y.X כמו 2.5.0) בהן יש טור לדרוג הפתרון: קיים, דורש התאמות קלות, דורש התאמות יסודית, ייכתב מן היסוד וכו'.
כמו כן צריך להתמודד עם הבעיה שהסרגל של המפרט (מפת"ח) איננו בהכרח הסרגל של החבילה. צריך להקל על הספקים עד כמה שאפשר בהתאמה לוגית זו, למשל, ע"י טור מיוחד בו הם יכולים לסמן את סימון המודול שלהם, או אפילו שיגישו טבלה משלהם שבה יש טור לדרישה במפרט.
פירוט סופי ומדויק של המודולים שיותקנו וההתאמות שיבוצעו. בשלב זה ייכתב מסמך המגדיר פערים בין הנדרש לקיים בחבילה (מסמך Gap analysis). עבור כל דרישה במסמך האפיון יוגדר האם היא מקבלת פתרון בחבילה, האם יש לבצע התאמות ומה פירוט ההתאמות אותן יש לבצע. לעיתים, למרות שבאפיון צוינה דרישה, מתבצעת פשרה ומקבלים את הקיים בחבילה על פני הצורך הראשוני. מצב זה מחייב את הלקוח לעדכן את תהליכי העבודה אותם אפיין על פי הפשרות המתקבלות. זהו בעצם חלק ממסמך המגדיר פערים בין החבילה לבין הנדרש באפיון. כל תהליך או רכיב המתקבל בחבילה על פני מה שהוגדר מחייב לאחר מכן שינוי נהלים בארגון ודגש על הטמעה נוספת.
טופס ובו פירוט הדרישות וקיומן או אי קיומן בחבילה מופיע בלשונית תוצרים בקיט זה.
כל ההתאמות הנדרשות בחבילה ומחייבות פיתוח אמורות להיות מוגדרות בשלב זה הן ברמת אפיון והן ברמת עיצוב (מסכים, דוחות, ממשקים ועוד).
שלב זה כולל את ביצוע כל ההתאמות הנדרשות בחבילה בכדי להתאים את פעילותה לנדרש על ידי הארגון. התאמות אלה כוללות פיתוח מיוחד מעבר לקיים בחבילה וכן הגדרת ברירות מחדל והגדרת פרמטרים שונים ומסלולי העבודה כך שיתאימו לצורכי הארגון. התאמות והגדרות אלה יבדקו בשלב זה ברמה של בדיקות יחידה.
התקנה ניסיונית ובדיקה איך חלקי החבילה השונים ותהליכיה עובדים ביחד – בדיקות אינטגרציה.
מומלץ שימוש בתיק הבדיקות של מפת"ח בשיטת הקופסה השחורה: יותר בדיקות חיצוניות ותפעוליות ופחות פנימיות ומבניות. לכל ההתאמות שבוצעו בחבילה יש לבצע בדיקות מקיפות יותר כיוון שאילו הם פיתוחים רגילים כמו במערכת שפותחה בתוך הארגון. גם את הממשקים בין החבילה ליתר המערכות בארגון יש לבדוק בדיקה מקיפה.
דגש על התקנות במספר אתרים: תכנית התקנה ומעקב הרצה. לעיתים מסתייעים בתכנון פיילוט על קבוצת משתמשים הומוגנית אשר ממנה משליכים על המשך הטמעת המערכת: חזרה על שלבים קודמים כדי לבצע התאמה טובה יותר לתהליכי הארגון או המשך ההטמעה לכלל המשתמשים על פי תוכנית מוכנה מראש.
בשלב זה יש חשיבות לכתיבה ועדכון נהלי עבודה, חלוקת מדריך למשתמשים הרלוונטיים וליווי ראשוני של הספק.
צוותים טכנולוגיים אמורים לקבל הדרכה מהספק אודות צורת ההתקנה וסיוע במתן תמיכה ראשונית.
· סיוע שוטף למשתמשים – Helpdesk.
· חוזה שירות ותחזוקה עם הספק/יצרן.
· ניהול גרסאות של חבילת התוכנה תוך דגש על התאמת השינויים שבוצעו ביישום הראשוני. יש לשים לב כי ככל שבוצעו התאמות רבות יותר בחבילה כך יקשה על המעבר לגרסה חדשה.
· בכל פעם שמופצת גרסה חדשה לחבילה יש לחשוב האם כדאי להטמיעה בארגון. יש לבצע בדיקת עלות/תועלת בכדי לראות מהם היתרונות שבשילוב החבילה לעומת חסרונותיה. לעיתים נוהגים לדלג על גרסה מסוימת ולעדכן גרסאות אחת לכמה זמן. נושא זה חייב להיות מעוגן בחוזה כך שלא ייוצר מצב בו הספק יחייב את הארגון לעדכן את גרסת החבילה שברשותו בכל פעם שזו מופצת.
להבנת המוסבר להלן, חובה לעיין תחילה בקיט עץ מערכת אוניברסלי
להלן ריכוז הדגשים והשינויים בעץ המערכת עבור מערכות מידע המבוססת חבילת תוכנה. כיוון שעץ המערכת האוניברסלי בנוי באוריינטציה בסיסית למערכות מידע, יודגשו להלן רק רכיבים בולטים במיוחד. מידע מפורט הקשור בשימוש בעץ המערכת עבור מערכות מידע נמצא בקיטים הבאים:
· קיט אפיון - תוצר ראשי: תיק אפיון
· קיימים קיטים בהם מוצגים עצי מערכת מיוחדים לחבילות תוכנה ספציפיות: קיט מערכות Lotus Notes, מערכות ERP, קיט משרד ממוחשב, קיט מערכות BPM ועוד.
ב"מטרות", "בעיות" ו"תועלות" חובה לציין מטרות/בעיות/תועלות ישירות (מדרגה ראשונה), היינו, הקשורות באופן ישיר ליעדי הארגון ולתפקודן של יחידות הארגון.
רכיב זה הוא הרכיב העיקרי במערכות מידע מבוססת חבילת תוכנה. במסגרת רכיב זה יש לתת דגש על עקרונות של תהליכים בארגון ודרישות אותם יש לבדוק במסגרת החבילות הקיימות. אין צורך בשום מקרה לרדת לפרטי פרטים בנוגע למסכים, תפריטים, דוחות ומבנה בסיס הנתונים. בכל אחד מהרכיבים הרלוונטיים יש להגדיר את הצרכים ברמה הכללית ביותר האפשרית תוך מתן גמישות ליישום הדרישות בחבילה. ככל שהארגון יהיה פחות גמיש כך ירבו ההתאמות בחבילה, העלות תגדל ויכולת התחזוקה תהיה קשה יותר. ככל שהארגון יהיה פתוח יותר לתהליכים בחבילה (אשר בדרך כלל יושמו על בסיס רחב של צרכי לקוחות) כך מימוש החבילה יהיה קצר יותר ויתרון השימוש בחבילת תוכנה יגבר.
רכיב זה מיועד לטכנולוגיה שמלווה מערכת מידע, לא לטכנולוגית תשתית בארגון. אם החבילה משתלבת בטכנולוגיה הקיימת ניתן להיעזר בפרק סטנדרטי הקיים בארגון. אם החבילה גורמת ליישום טכנולוגיה חדשה יש לתאר אותה ולתת דגש לשילובה בטכנולוגיה הקיימת.
מימוש הוא רכיב מרכזי בכל מערכת. יש צורך בבקרה ואבטחת איכות צמודה על עבודת הספק כולל ביצוע ההתאמות המבוצעות בתוך הארגון ואצל הספק.
יש לוודא שמחיר חבילה התחלתי נמוך לא ייגמר במחיר גבוה בגלל תוספות למיניהם שלא נלקחו בחשבון בהערכה הראשונית. יש לוודא גם עלויות פנימיות של הארגון הכרוכות בלימוד, הטמעה וכו' וכן עלויות צד שלישי.
טבלה המגדירה פערים בין הנדרש בתיק המערכת לקיים בחבילה (מסמך Gap analysis). עבור כל דרישה במסמך האפיון יוגדר האם היא מקבלת פתרון בחבילה, האם יש לבצע התאמות ומה פירוט ההתאמות אותן יש לבצע. כל שינוי שיוגדר יקבל תג מחיר שיצטרף בסופו של דבר למחיר הכללי של הפרויקט. ניתן להשתמש בטופס זה בכל אחד מסעיפי עץ המערכת המגדיר דרישות (כגון: תהליכים, תיחום פנימי, אבטחת מידע) ובכך לקבל תמונה מלאה על הקיים בחבילה ועל היקף ההתאמות הנדרשות. לעיתים, הנתונים בטבלאות אלה יגרמו לארגון להגיע להבנה להגמיש עמדותיו ולהתאים עצמו לתהליכי החבילה.
בדיקת היתכנות היא למקרים קיצוניים: האם בכלל ניתן לבנות את המערכת. הבדיקה היא ברמה פרטנית של רכיבים (או קבוצת רכיבים) ויכולה להיעשות לכל הרכיבים, או רק לרכיבים קריטיים -CSF גורמים קריטיים במערכת, אשר עיכובים בהם עלולים לגרום לעיכוב במערכת כולה.
CSF (Critical Success Factors) אלו רכיבים בעץ המערכת או שלבים ופעילויות במחזור החיים אשר יש להם השפעה מכרעת, חיובית או שלילית, על פיתוח המערכת ותחזוקתה. גורמי CSF נקראים גם "חוק ה- 20/80" (20% מהרכיבים מבצעים 80% מהעבודה וכו'). השפעה חיובית פירושה שהצלחה בגורמים אלה מספקת ליישום ראשוני מוצלח של המערכת. השפעה שלילית פירושה שעיכובים ובעיות בגורמים אלה עלולים לגרום לעיכובים משמעותיים במערכת כולה או אף לכישלונה.
עקב התבגרות עולם המחשוב ומגוון הפתרונות האפשריים, ההתמקדות היא יותר בהיבטים ארגוניים ואנושיים והיא משיקה לתחום בדיקת טיב. היתכנות, היום, איננה במובן של האם הדבר בכלל ניתן לביצוע (feasible) אלא האם הוא סביר.
פעילות אבטחת איכות בפרויקטים המיישמים חבילה תשים דגש רב על עבודת הספק ויכולתו לעמוד בהגדרות החוזה ובמסמך הדרישות. רבות המחלוקות הקיימות בעת מימוש חבילת תוכנה בארגון בין הלקוח לספק על הקו העובר בין הקיים בחבילה לבין מה שהוגדר כהתאמה ובמצבים רבים הספק דורש עלות כספית נוספת על התאמות בחבילה שלא הוגדרו מראש.
בכדי להימנע ממצבים אלה ואחרים יש צורך בסקירת מסמך האפיון ולאחריו מסמך הבקשה להצעות. יש לוודא כי קיים מבנה מוגדר למנהלת הפרויקט תוך מחויבות מלאה של מומחה היישום ומשתמשים ראשיים המכירים ומוסמכים להגדיר ולשנות תהליכים בארגון. במקרים אלה אבטחת איכות תדאג לשילוב יחידות ארגון ושיטות בתהליך ההגדרה.
יש לבצע תהליך בחירת ספק חבילת תוכנה בצורה מסודרת על פי קריטריונים מוגדרים מראש ויש להגדיר בצורה מפורטת את החוזה כולל כל אותם פרטים קטנים הרלוונטיים למימוש. גוף אבטחת איכות יוודא כי הספק מתעד את כל השינויים המבוצעים בחבילה בצורה בה הארגון יוכל לתפעל את החבילה ללא תלות בספק לאורך זמן.
כמו כן, פעילות אבטחת איכות תתמקד גם בהכנת הארגון לקליטת החבילה תוך דגש על עדכון נהלים על פי הצורך והטמעה מסודרת של החבילה לפי סוגי המשתמשים השונים.