חברת STKI ערכה מחקר בנושא "פיתוח מערכות תוכנה בארגוני IT". תוצאות המחקר התפרסמו בכנס השנתי שלנו והיוו מחקר ראשון בתחום זה בישראל.
בעקבות שאלות של לקוחות להלן התייחסותנו למאמץ המושקע בניתוח מערכות למול המאמץ המושקע בפיתוח (החל משקף 8) . על פי שאלות של מספר לקוחות, החלק של מנתחי המערכות (ניתוח ועיצוב) במחקרים אחרים גדול יותר מחלקם כפי שהתקבל במחקר STKI. להלן התייחסותנו לשאלה זו:
לקוחות STKI נתבקשו למלא כיצד מתחלק תקציב הפיתוח ב- IT בין מנתחי מערכות, מפתחים, שלב בדיקות וכד'.
ניסוח זה דומה אך לא זהה לשאלה של "כיצד מתחלק תקציב הפיתוח בין שלבי הפיתוח השונים" זאת מכיוון שעל פי הבירור שערכנו בארגונים רבים (למעשה כל הארגונים אתם בצעם את הבירור הנוסף) מסתבר שהחלקים היותר טכניים של העיצוב - Low level detailed design - מתבצעים על ידי צוותי הפיתוח ולא מוגשים על ידי צוותי המנתחים כמקשה אחת. במיוחד בפרוייקטים הקטנים שבהם לא בונים בנפרד אפיון מפורט אלא מעבירים לפיתוח באופן מיידי (לא נתייחס במקום זה האם תופעה זו מבורכת...).
כלומר חלק מפעולות ה"עיצוב" מתבצעות על ידי המפתחים.
נקודה נוספת היא שהחלקים העליונים של האפיון מתבצעים לעיתים על ידי הגוף הדורש שמכיל רפרנטים ברמה גבוהה, תחום BRM – Business Relationship Management, או גוף או"ש (לעיתים אכן יהיו שם מנתחי מערכות אך לא חלק מה- IT) ולכן נקודה זו מעצימה את ההשקעה בפיתוח לעומת הניתוח שמתבצע בגוף ה- IT.
באופן כללי העלו לקוחות את הטענה שתחום ניתוח המערכות בישראל הוא יותר "עסקי" מאשר "טכני" – המפתחים עוסקים בסוגיות עסקיות - איזה value יתבצע על ידי המערכת וכד' - כאשר לטענת חלק מהלקוחות מנתחי מערכות אצלהם לא מגיעם לנושאים טכניים של ERD, שכבת ארכיטקטורה, אפיון אנטגרציה, מה יבצע כל CLASS וכד'. כל זאת מתבצע אצל אותם לקוחות על ידי המפתחים.
נקודה רלוונטית נוספת היא התייחסות ארגונים בישראל ל"הוצאות OPEX " למול "השקעות CAPEX". ישנם ארגונים שבהם פיתוח נחשב כ"השקעה CAPEX" לעומת ניתוח שנחשב "OPEX – הוצאה" . זאת מן הטעם שפיתוח תורם לנכס בחברה – הקוד שמפותח - לעומת הניתוח שלא תמיד מגיע למימוש בפועל ולכן נחשב שהוצאה. לכן יש נטיה בארגונים שמתנהלים באופן זה להגדיל את המשימות שמתבצעות על ידי המפתחים לעומת המשימות שמתבצעות על ידי מנתחי המערכות.
לסיכום, על פי הבירור שערכנו עולה שחלק מפעולות הניתוח מתבצעות בפועל על ידי המפתחים ולכן לא ניתן להשליך מכך שתוצאות המחקר שלנו כפי שנוסח שונות מהותית מתוצאות המחקרים שהצגת בפנינו.
שאלות אלו ואחריות מביאות אותנו למסקנה שיש טעם בעריכת מחקר המשך - מחקר בו נבדוק מהי ההשקעה שמתבצעת בפרוייקט לפי שלבי הפיתוח השונים ולא רק תחת "זכוכית המגדלת" של ה- IT והמבנה הארגוני והפונקציונלי הספציפי ב – IT.
כלומר נשאל על סה"כ התקציב שמושקע בפרוייקט, לפי שלבי הפרוייקט המקצועיים ולא רק על התקציב שיוצא מכיסו של ה- IT.
בעקבות שאלות של לקוחות להלן התייחסותנו למאמץ המושקע בניתוח מערכות למול המאמץ המושקע בפיתוח (החל משקף 8) . על פי שאלות של מספר לקוחות, החלק של מנתחי המערכות (ניתוח ועיצוב) במחקרים אחרים גדול יותר מחלקם כפי שהתקבל במחקר STKI. להלן התייחסותנו לשאלה זו:
לקוחות STKI נתבקשו למלא כיצד מתחלק תקציב הפיתוח ב- IT בין מנתחי מערכות, מפתחים, שלב בדיקות וכד'.
ניסוח זה דומה אך לא זהה לשאלה של "כיצד מתחלק תקציב הפיתוח בין שלבי הפיתוח השונים" זאת מכיוון שעל פי הבירור שערכנו בארגונים רבים (למעשה כל הארגונים אתם בצעם את הבירור הנוסף) מסתבר שהחלקים היותר טכניים של העיצוב - Low level detailed design - מתבצעים על ידי צוותי הפיתוח ולא מוגשים על ידי צוותי המנתחים כמקשה אחת. במיוחד בפרוייקטים הקטנים שבהם לא בונים בנפרד אפיון מפורט אלא מעבירים לפיתוח באופן מיידי (לא נתייחס במקום זה האם תופעה זו מבורכת...).
כלומר חלק מפעולות ה"עיצוב" מתבצעות על ידי המפתחים.
נקודה נוספת היא שהחלקים העליונים של האפיון מתבצעים לעיתים על ידי הגוף הדורש שמכיל רפרנטים ברמה גבוהה, תחום BRM – Business Relationship Management, או גוף או"ש (לעיתים אכן יהיו שם מנתחי מערכות אך לא חלק מה- IT) ולכן נקודה זו מעצימה את ההשקעה בפיתוח לעומת הניתוח שמתבצע בגוף ה- IT.
באופן כללי העלו לקוחות את הטענה שתחום ניתוח המערכות בישראל הוא יותר "עסקי" מאשר "טכני" – המפתחים עוסקים בסוגיות עסקיות - איזה value יתבצע על ידי המערכת וכד' - כאשר לטענת חלק מהלקוחות מנתחי מערכות אצלהם לא מגיעם לנושאים טכניים של ERD, שכבת ארכיטקטורה, אפיון אנטגרציה, מה יבצע כל CLASS וכד'. כל זאת מתבצע אצל אותם לקוחות על ידי המפתחים.
נקודה רלוונטית נוספת היא התייחסות ארגונים בישראל ל"הוצאות OPEX " למול "השקעות CAPEX". ישנם ארגונים שבהם פיתוח נחשב כ"השקעה CAPEX" לעומת ניתוח שנחשב "OPEX – הוצאה" . זאת מן הטעם שפיתוח תורם לנכס בחברה – הקוד שמפותח - לעומת הניתוח שלא תמיד מגיע למימוש בפועל ולכן נחשב שהוצאה. לכן יש נטיה בארגונים שמתנהלים באופן זה להגדיל את המשימות שמתבצעות על ידי המפתחים לעומת המשימות שמתבצעות על ידי מנתחי המערכות.
לסיכום, על פי הבירור שערכנו עולה שחלק מפעולות הניתוח מתבצעות בפועל על ידי המפתחים ולכן לא ניתן להשליך מכך שתוצאות המחקר שלנו כפי שנוסח שונות מהותית מתוצאות המחקרים שהצגת בפנינו.
שאלות אלו ואחריות מביאות אותנו למסקנה שיש טעם בעריכת מחקר המשך - מחקר בו נבדוק מהי ההשקעה שמתבצעת בפרוייקט לפי שלבי הפיתוח השונים ולא רק תחת "זכוכית המגדלת" של ה- IT והמבנה הארגוני והפונקציונלי הספציפי ב – IT.
כלומר נשאל על סה"כ התקציב שמושקע בפרוייקט, לפי שלבי הפרוייקט המקצועיים ולא רק על התקציב שיוצא מכיסו של ה- IT.
אין תגובות:
הוסף רשומת תגובה