ייזום מערכת/פרויקט

כללי – מנהלה

הגדרה

ייזום הוא שלב ראשוני בו מועלה צורך (דרישה ראשונית) למערכת ממוחשבת חדשה או למהדורה חדשה של מערכת קיימת

עקרונות

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

יעדי המערכת ומטרותיה חייבים להיות מוגדרים כבר בשלב הייזום (יעדים הם רכיב מס' 1 בעץ המערכת!).

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

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

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

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

קלט

הקלט לתהליך הייזום יבוא, בד"כ, מהמקורות הבאים:

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

·         מערכות דומות קיימות (כולל בארגונים אחרים)

·         מסמכי ייזום דומים (בפרט כאלה שבוצעו על פי נוהל זה)

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

·         רשימת משתמשים/מרואיינים בארגון ומחוצה לו

·         כל חומר אחר הנראה רלוונטי ליזם

התהליך

ראה פעילויות בשלב הייזום להלן

פלט

(תוצר ראשי) מסמך ייזום, ראה תוצרים מסמך ייזום להלן.

משאבים

1-7 ימי עבודה.

גורם מאשר

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

גורם מבצע

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

גורם אחראי

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

גורם מחליט

על ההמשך (מעבר לאפיון): לפי האלטרנטיבות שבטבלה הבאה:

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

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

מקרא לטבלה:

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

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

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

החלטה

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

·         שיפור מסמך הייזום (החזרתו ל"שולחן השרטוטים")

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

·         המשך לאפיון מלא

·         המשך לאפיון מקוצר (במערכות מסוג ג1 בלבד, ראה פרק האפיון)

·         אין-המשך: הקפאת היוזמה.

תנאים לאי-ביצוע

אין אפשרות לדלג על שלב הייזום.

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

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

פעילויות המסומנות בסוגריים מרובעים [n] הן פעילויות צומת, אבני דרך או שיקופים.

פירוט הפעילויות

[1.] הגדרת הלקוח [אבן דרך]

·         מי הוא הלקוח העיקרי, מחלקה/איש (יכול להיות גם גורם חיצוני)?

·         האם גורם זה יכול גם להיחשב "מומחה היישום"? אם לא אז מי?

·         מי וכמה אנשים/מחלקות בארגון נוגעים ישירות למערכת?

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

פעילות זו מגדירה את רכיב 1.1 וחלק מרכיב 2.2 בעץ המערכת (במסמך הייזום).

2. סקירה כללית של המצב הקיים בארגון

·         האם יש מערכת דומה ממוכנת? אם אין, איך מתנהלת המערכת הידנית?

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

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

פעולה זו מזינה ישירות את רכיב 2.1 בעץ המערכת, אך יש לה כמובן השלכות על עץ המערכת כולו.

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

·         האם יש מערכת דומה בארגון אחר?

·         מה המצב שם, מה ה"היסטוריה", מה ניתן ללמוד מארגון זה?

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

4. סקירה של שוק המחשבים הכללי

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

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

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

5. הגדרת יעדים/מטרות, בעיות, תועלות וחסכונות

פעולה זו מגדירה את רכיבים 1.2, 1.3.

6. כתיבת טיוטה ראשונה של מסמך הייזום

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

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

·         האם זהו רכיב רשות או חובה (הסימון לסעיף חובה בגלופת העבודה הוא "*")

·         סמן ליד הרכיב "???" או "___", אם יש לברר ולהשלים נקודות חסרות או פתוחות.

·         סמן נקודות פתוחות X.98 ודרישות עתידיות X.99.

פעולה זו מגדירה, בפעם הראשונה, את המערכת כולה!

7. בדיקת ישימות (היתכנות) ועלות/תועלת

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

·         מה התועלות שסביר לצפות מהמערכת (שירותים שהמערכת תיתן)?

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

·         האם מדובר בטכנולוגיה חדשה ובלתי מוכרת?

·         האם צפויים קשיים/מגבלות במימוש המערכת?

·         האם יש הערכה כלשהיא לעלות (חסמים?)

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

פעולה זו סוקרת את עץ המערכת כולו ומסוכמת ברכיב 1.6 - בפרט תת-רכיב 1.6.2 - עלות/תועלת -  ישימות עסקית.

8. מינוי ויידוע כל הגורמים המעורבים

·         הקמת ועדת היגוי לפרויקט (הצוות המינהלי)

·         יידוע כל הגורמים המעורבים במישרין ובעקיפין (סיוע טכני?).

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

[9.] דיון פנימי בארגון [שיקוף]

חשוב לקיים שיקוף (דיון פנימי) אחד לפחות.

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

10. חזרה על פעילויות 1-9

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

11. עריכה סופית של מסמך הייזום והגשתו לגורם המאשר

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

[12.] החלטת ה"גורם המחליט" על ההמשך [אבן דרך]

ראה "גורם מחליט" בסעיף כללי - מנהלה לעיל.

13. הפצת מסמך הייזום

אין להתעלם מפעולה חשובה זו אשר עשויה לדרוש:

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

·         ניהול רשימת תפוצה (רשימות תפוצה?) ועדכונה.

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

[14.] בחירת הגורם שיאפיין [צומת]

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

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

·         אם גורם פנימי, "לסמן" אותו ולבדוק את מידת זמינותו

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

סיכום פעילויות הייזום

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

הקשר לתכנית העבודה השנתית

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

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

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

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

 

תוצרים

מסמך ייזום

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

סעיפי מסמך הייזום מדורגים באופן הבא:

·         סעיפי חובה: מסומנים ב- "*" (אם רכיב-אב מסומן, כל תת-הרכיבים שלו הם חובה).

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

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

 

תוצרים נוספים

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

·         נספחים למסמך הייזום

·         בניית דגם או אבטיפוס

 

נספחים

נספחים או הרחבות אפשריים למסמך הייזום, הם:

·         נספח 1.3: ניתוח בעיות

·         נספח 1.6: עלות\תועלת

·         נספח 98: נקודות פתוחות

לפירוט נוסף, ראה גלופת לימוד מסמך ייזום.

דגם \ אבטיפוס

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

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

·         התמקדות ברורה: מה בדיוק חשוב להדגים בשלב כה מוקדם.

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

·         קישור ברור למסמך הייזום. השלמה הדדית.

מסמך ייזום מקוצר

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

·         סעיפי חובה בלבד

·         איחוד רכיבים

·         מבנה של תמצית מנהלים

·         טופס ייזום

·         עמוד שער מורחב

סעיפי חובה בלבד

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

איחוד רכיבים

צירוף של האפשרויות הבאות:

איחוד רכיבים 1.2, 1.3 תחת השם:	בעיות ומטרות
איחוד רכיבים 2.2 ו- 2.3 (ו- 2.5) תחת השם:	תהליכים
איחוד רכיבים 2.10, 2.11, 2.13 תחת השם:	נתונים
התייחסות כוללת לרכיב 3	טכנולוגיה ללא פירוט לרכיבי המשנה (3.X)
איחוד רכיבים 4.2 ו- 4.3 תחת השם:	המשך פיתוח המערכת
איחוד רכיבים 4.4 ו- 4.6 תחת השם:	תפעול המערכת ותחזוקתה.

מבנה של תמצית מנהלים

מסמך ייזום הבנוי רק לפי הרכיבים הראשיים ו/או סעיפי ההבהקים:

1. יעדים

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

2. היישום המוצע

תיאור תמציתי של היישום המוצע.

3. טכנולוגיה

תיאור קצר ותמציתי ביותר של הטכנולוגיה המשוערת \ הקיימת.

4. מימוש המערכת המשוער

תיאור תמציתי של האופן מימוש המערכת המשוער.

5. עלות צפויה

תמצית עלות המערכת המשוערת. חסם עליון \ תחתון.

 

טופס ייזום

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

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

עמוד שער מורחב

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

·         משתמש עיקרי

·         גורמים מעורבים: מיודעים, טרם יודעו

·         אופק הזמן

·         מערכות משיקות

·         עלות כוללת: חסם עליון, חסם תחתון

הערה לסיכום

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

אבטחת איכות ומדדים

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

מומלץ לבדוק את מסמך הייזום לפי רשימת התיוג הבאה:

·         קצר מדי? ארוך מדי? גלישה לאפיון?

·         מי בדיוק היזם? מה מידת מחויבותו?

·         האם מכיל מספיק מידע על מנת לקבל החלטה להמשך?

·         האם ברור מה הצעד הבא ומהן משמעויותיו?

·         האם קשור בתכנית העבודה השנתית או בתכנית אב (תכנון אסטרטגי)?

·         מי אישר את המסמך? האם יש כבר ועדת היגוי? האם יש מומחה יישום?

למידע מפורט יותר, ראה קיט בדיקת תיעוד בכרך איכות.