IS The Influence of Analyst Communication in IS Projects

השפעת התקשרות של אנליסט בפרויקטים IS

Shadi Shuraida & Henri Barka

הקדמה

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

מלות מפתח: פיתוח IS, יישום IS, פרויקט IS, תקשורת משתמש-אנליסט, למידה של אנליסט IS, מקרה בוחן

השפעת תקשורת של אנליסט בפרויקטים IS

השפעת תקשורת של אנליסט בפרויקטים IS

פיתוח ויישום מערכות מידע (IS) בארגונים ממשיך להיות מאתגר, כאשר כמעט שני שלישים של פרויקטים נתקלים במכשולים או כושלים (Nelson, 2007; Standish Group, 2009). מכיוון שדרישות מידע לא מדויקות או לא מלאות עלולים להשפיע לרעה על פיתוח מערכות IS (ISD) רבות

(Bostrom, 1989; Browne & Rogich, 2001; Byrd, Cossick, & Zmud, 1992; Marakas & Elam, 1998; Pitts & Browne, 2007)

מוסכם בדרך כלל כי אנליסטים IS צריכים לרכוש מידע הולם ותקף לגבי הצרכים הארגוניים והמשתמשים, אם הם רוצים לפתח מערכות איכותיות (Browne & Ramesh, 2002, Byrd et al, 1992, Marakas & Elam, 1998 Mathiassen, Saarinen, Tuunanen, & Rossi, 2007).

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

(Curtis, Krasner, & Iscoe, 1988; Keil & Carmel, 1995; Neill & Laplante, 2003; Watson & Frolick, 1993)

וחוקרים למדו תקשורת משתמש-אנליסט ותפקידה בפרויקטים ISD (למשל, Hartwick & Barki, 2001; Joshi, סארקר, & Sarker, 2007; Ko, Kirsch, & King, 2005; Lind & Zmud, 1991). הנחת היסוד בעבודות רבות היא כי אנליסטים אשר משיגים דרישות מידע מדויקות יפתחו מערכות באיכות גבוהה. עם זאת, אנליסטים שסופקו עם דרישות משתמש מדויקות עדיין יכולים לא להצליח להבין בבירור אותן עקב תקשורת לא יעילה שיכול לנבוע מגורמים שונים, כגון הבדלים משתמש-אנליסט במודלים מנטליים (Boland & Tenkasi, 1995, Bostrom, 1989, Orlikowski & Gash, 1994) או שפות (Appan & Browne, 2001, Browne & Ramesh, 2002, Byrd et al., 1992),

וכתוצאה מכך, הם עשויים לספק מערכות שאינן עומדות בדרישות המשתמשים (Edstrom, 1977; Gallivan & Keil, 2003; Newman & Noble, 1990).

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

להשתמש כדי ללמוד על צרכי המידע של המשתמשים (למשל, Boland, 1978, Majchrzak, Beath & Lim, 2005; Salaway, 1987; Walz, Elam, & Curtis, 1993). כיוון ש- ISD היא פעילות עתירת ידע שבו האנליסטים צריכים לרכוש מידע ולתרגם אותו למאפייני עיצוב המערכת (Churchman &

Schainblatt, 1965; Markus & Mao, 2004), חקר פעילויות תקשורת של אנליסטים באמצעות פרספקטיבה של למידה יכולה להיות גישה פורייה והיא יכולה לעזור לשפוך אור על ההתנהגויות הספציפיות אשר מביאות לתקשורת יעילה ורכישת ידע מדויק ותקף על דרישות המשתמש. עם זאת, המחקר בעבר על תקשורת אנליסטים התמקד בעיקר על תפיסות רחבות יחסית של גישות ואסטרטגיות בתקשורת כגון חילופי תקשורת דיאלקטיות (Boland, 1978) והרחבה קוגניטיבית (Majchrzak et al., 2005), והשאיר את תוכן המידע בחילופי התקשורת של האנליסטים במידה רבה לא נחקרו. מחקר אחד יוצא דופן הוא של Salway (1987), אשר מצא כי האנליסטים אשר השתמשו בהתנהגויות למידה כפי שצוין ב- Argyris and Schon’s (1974, 1978) גישת הלמידה הארגונית קיבלו יותר מידע מאשר אלה אשר השתמשו בגישה אינטראקציה מסורתית (התוכן של אלה התנהגויות תקשורת והשפעתן על תוצאות הפרויקט לא נבדקו).

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

(Churchman & Schainblatt 1965; Byrd et al., 1992; Markus & Mao, 2004).

עם זאת, כרגע אנו חסרים הן את התיאוריה והן ראיות אמפיריות כדי להבין טוב יותר את הקשר בין תקשורת האנליסטים התנהגויות ותוצאות הפרויקט. במאמץ להתמודד עם הפער הזה, אנו נותנים את היסודות של המסגרת התיאורטית ומביאים ראיות אמפיריות ראשוניות ביחס זה. כדי לעשות את זה, בסעיף 2, המאמר קודם מחבר מחקר אמפירי מהעבר על תקשורת אנליסטים עם קביעת דרישות על בסיס מסגרת התקשורת של Berlo’s (1960). בסעיף 3, אנו יוצאים מתוך תיאוריות למידה ארגוניות (Argyris & Schon, 1974, 1978, Salaway, 1987), וחוקרים באופן אמפירי כיצד פעילויות העברת מידע של האנליסטים ותוכן המידע שהם משדרים, משפיע על הידע שלהם על צרכי המידע של המשתמשים ותוצאות הפרויקט IS. הגישה של מחקר מקרי בוחן – המתוארת בסעיף 4 – אומצה על מנת לבחון שני פרויקטים של IS. הניתוח (סעיף 5) והממצאים (סעיף 6) של שני המקרים מצביעים על כך שאנליסטים המעודדים שימוש בדוגמאות, בדיקות ותיקונים קונקרטיים, ואשר מבקשים משוב על התהליכים העסקיים של המשתמשים, עשויים להבין טוב יותר את המטלות של המשתמשים, וכן, בתורו, עיצוב מערכות אשר עונה טוב יותר על הצרכים של המשתמשים מאשר אנליסטים שאינם. יתר על כן, בהתבסס על ראיות משני המקרים, הצעות ושאלות מחקר מוצעות גם למחקר עתידי בסעיף 6.

2. הפקת דרישות ותקשורת אנליסטים

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

על ידי שיטות שונות וכיצד פעולות אלה צריכות להתבצע (Beath & Orlikowski, 1994; Keil &

Carmel, 1995; Marakas & Elam, 1998; Mathiassen et al., 2007; Robertson & Robertson, 2006). בנוסף, גישות רבות של ISD התמקדו בזיהוי מידע והוצאת דרישות למידע מבלי להיות מפורש על אילו פעולות ספציפיות IS אנליסטים צריכים לבצע על מנת להבין את צרכי המידע של הארגון ואנשיו (Galliers & Swan, 1997; Patnayakuni, Ruppel, & Rai, 2005; Robertson & Robertson, 2006; Stein & Vandenbosch, 1996). תשובות חלקיות המתייחסות לנושא זה נמצאות במחקר על תקשורת של משתמש-אנליסט

(Boland, 1978; Bostrom, 1989; Gallivan & Keil, 2003; Hartwick & Barki, 2001; Kirsch & Beath, 1996; Lind & Zmud, 1991; Marakas & Elam, 1998; Markus & Mao, 2004; Newman & Noble, 1990)

איפה הוצע כי “צורות מסוימות של תקשורת הם […] טובות יותר מאחרים”

(Gallivan & Keil, 2003, p. 41; Boland, 1978; Kraut & Streeter, 1995; Lind & Zmud, 1990;

Marakas & Elam, 1998; Majchrzak et al., 2005; Newman & Noble, 1990; Salaway, 1987). לדוגמה, במחקר הקודם על זה נמצא כי השימוש בדיאלוג דיאלקטי(Boland, 1978; Salaway, 1987) ותהליכים ושיטות ספציפיות (Bostrom, 1989; Majchrzak et al., 2005) משפיעים חיובית על תוצאות פרויקטים ISD. כדי לסנתז מחקרים הקשורים לפעילות התקשורת של האנליסטים של IS, סקרנו מחקרים קודמים בנושא תקשורת משתמש-אנליסט וקביעת דרישות (RD). זרם ה- RD נכלל כי נמצא כי אנליסטים עוררו את דרישות המערכת בעיקר על ידי תקשורת עם משתמשי מערכת

(Curtis et al., 1988; Keil & Carmel, 1995; Neil & Laplante, 2003; Watson & Frolick, 1993).

נספח A כולל תיאור מפורט של התהליך, הקריטריונים, והתוצאות של הסקירה.

הסקירה שלנו הניבה מדגם של 49 מחקרים אמפיריים ב -90 מאמרים שחקרו את פעילויות התקשורת של אנליסטים IS. אלה היו מסווגים בטבלה 1 לאורך מרכז Berlo’s (1960) רכיבי תקשורת: הודעת התקשורת המציינת את הקוד או השפה בשימוש, תוכן המידע המועבר וצורת הטיפול או השידור; ערוץ תקשורת המתייחס למדיום של תקשורת בשימוש; ואת מקור / מקלט התקשורת אשר מתייחס למאפיינים של אנשים מתקשרים. המחקר הנוכחי מתמקד במרכיב “הודעת המסר”; כלומר, תקשורת “התנהגות זמינה בצורה פיזית” (Berlo, 1960, עמ ’30), המשקף את העברת המידע של האנליסטים, את השפה שבה הם משתמשים, ואת התוכן של המידע המועבר.

טבלה 1. סינתזה של מחקר אמפירי על משתמש-אנליסט תקשורת

        פער                        מוקד                        מחקר              פרספקטיבה של תקשורת

טבלה 1 (המשך).

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

(e.g. Agarwal & Tanniru, 1990; Duggan & Thachenkary, 2003, 2004)

סוגי שאלות מסויימים

(e.g. Marakas & Elam, 1988; Moody, Blanton, & Cheney, 1998; Browne & Rogich, 2001; Pitts & Browne, 2007)

וכלים וטכניקות המשפרים תקשורת

(e.g., Lichter, Schneider-Hufschmidt, & Zullighoven, 1994; Kaiya, Shinbara, Kawano, & Motoshi, 2005; Maiden & Hare, 1998; Potts, Takahashi, & Antón, 1994; Darke & Shanks, 1997)

צוינו כמובילים להפקה יעילה ואפקטיבית יותר של דרישות. מחקרים אחרים בתוך הזרם הזה מצאו כי תבניות תקשורת דיאלקטית הובילו ליצירת מידע אמין (Salaway, 1987) ותוצאות למידה של המשתמש ועיצוב המערכת טובות יותר (Boland, 1978; Majchrzak et al., 2005), ולאספקת הנחיות כלליות לאנליסטים לגבי השימוש בדפוסי תקשורת דיאלקטיים שונים, כגון פרוטוקולים של אינטראקציות למידה הדדיות (Boland, 1978), הרחבת אסטרטגיות קוגניטיביות(Majchrzak  et al., 2005) , וגישות למידה ארגוניות (Salaway, 1987).

הזרם השני התמקד על הערכת ההיקף

(e.g., Butler & Fitzgerald, 2001; Hartwick &

Barki, 2001; Joshi et al., 2007; Lind & Zmud, 1991; McKeen et al., 2007)

ואת ההשפעה של ערוצי תקשורת משתמש-אנליסט שונים על פרויקטים ISD

(Kraut & Streeter, 1995; Keil & Carmel, 1995; Watson & Frolick, 1993).

למשל, מחקר מצא כי תקשורת תכופה יותר

(Hartwick & Barki, 2001; Joshi et al., 2007; Lind & Zmud, 1991; Sawyer & Guinan, 1998)

שימוש בערוצי תקשורת עשירים יותר (Gallivan & Keil, 2003; Lind & Zmud, 1991), פחות פורמליים (Kraut & Streeter, 1995) וישירים(Keil & Carmel, 1995) השפיעו חיובית על תוצאות פרויקטים ISD. לבסוף, המחקרים בזרם השלישי והרביעי חקרו גורמים קונטקסטואליים כגון יכולת התקשורת של המומחים וכישוריהם (למשל, Ko et al, 2005; Guimaraes et al, 2003; McKeen et al., 1994; Saleem et al. 2006) או מודלים כלליים המאפשרים תקשורת (למשל, Arthur & Groner, 2005; Bostrom, 1989).

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

(e.g., Agarwal & Tanniru, 1990; Marakas & Elam, 1988; Moody et al., 1998; Browne & Rogich, 2001; Pitts & Browne, 2007)

רק מעטים בדקו שידור מידע על ידי אנליסטים, וכיצד הוא יכול לעזור להם לרכוש את הידע וההבנה הדרושים לתכנון מערכות טובות יותר (e.g., Majchrzak et al., 2005; Salaway, 1987). לפיכך, למרות החשיבות של פעילות העברת המידע של האנליסטים ושל תוכן המידע של התקשורת בפרויקטים של ISD, מחקרים אמפיריים מבוססי תיאוריה שחקרו את ההשפעה על פרויקטים ISD, עדיין חסרים. מחקר כזה יכול לעזור לספק לאנליסטים הנחיות התנהגות ספציפית בתקשורת

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

3. למידה של אנליסטים בפרויקטים IS

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

(Hartwick & Barki, 2001; McKeen & Guimaraes, 1997; Lind & Zmud, 1991).

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

(Byrd et al., 1992; Chakraborty, Sarker, & Sarker, 2010; Joshi et al., 2007; Markus & Mao, 2004).

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

(e.g. Argyris & Schon, 1974; Edmondson, 1999; Huber, 1991; Weick & Ashford, 2001),

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

(Boland, 1978; Curtis et al., 1988; Gallivan & Keil, 2003; Walz et al., 1993).

טבלה 2. דוגמאות מחקר ארגוני (על בסיס Argyris and Schon, 1974, 1978).

נושא שנחקר                              שימוש במושגים                מחקר                רמת ניתוח

מ- Argyris and Schon

מודל למידה ידוע הוא של Argyris and Schon (1974, 1978). המודל מקובל במידה רבה (Arthur & Aiman-Smith, 2001) וייושם בהקשרים ארגוניים שונים. הוא מתאר למידה כמו איתור ותיקון של טעויות, שבו טעויות הן “כל תכונה של ידע או של ידיעה שעושה פעולה בלתי יעיל”(Argyris, 1976, p. 365) כפי שמוצג בטבלה 2, על פי מודל זה, למידה לוקחת אחת משתי צורות (איור 1) כאשר אנשים מנסים לתקן את ה”טעויות” האלה. הראשונה הוא למידה בלולאה יחידה שבה תקשורת בין אישית מוגבלת לשיטות הפעולה, בעוד השניה היא למידה בלולאה כפולה שבה המשתנים השולטים (כלומר, הנחות היסוד, נורמות וערכים) נבחנים. לפי Argyris and Schon, הלמידה בלולאה כפולה היא יותר יעילה מאשר למידה בלולאה אחת, כי כאשר אנשים חוקרים את המטרות שלהם ואת הפעילויות, יצירת מידע תקף וקבלת משוב – עוזר, ואילו בלמידה בלולאה יחידה חיפוש מידע מוגבל לפעילויות משימה.

איור 1. מרכיבי תהליך למידה

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

(Argyris, Putnam, & McLain Smith, 1985; Argyris & Schon, 1974, 1978; Salaway, 1987)

על בסיס מדלים של למידה Argyris and Schon’s (1974, 1978), Salaway (1987) זיהה ארבע פעילויות של העברה (טבלה 3): תמיכה (תמיכה או הגנה על עמדה, רעיון או פעולה), חקירה (מעשה של הפקת ידע), עימות (האופן שבו אנשים מאתגרים רעיונותיהם של אחרים), ויכולת לדון (דנים במחשבות רלוונטיות לגבי הבעיה). לסיכום, בעוד שפעילויות תקשורת של מודל 2 מקדמות בדיקת דוגמאות ספציפיות ומקבלות משוב כאשר מחפשים מידע או מביעים רעיונות של מישהו

(Argyris, 2002; Argyris & Schon, 1996; Bolman & Deal, 2008)

אנשים המשתמשים במודל 1 של פעילויות תקשורת, אינם ממחישים את רעיונותיהם או מעודדים משוב עליהם, ולא מעודדים בדיקת הטענות שנעשו (Argyris, 2002).

תורת הלמידה של Argyris and Schon’s (1974) מבוססת על ההנחה כי פרטים מתכננים אינטראקציות שלהם כדי לקבל החלטות ולהשיג את התוצאות המיועדות שלהם. כך שהמודל יכול להיות שימושי בהקשרים של ISD שבהם אנליסטים צריכים לבצע פעילויות תקשורת כדי לרכוש את הידע הדרוש להם לצורך אספקת מערכות העונות על צרכי המשתמש והארגון

(Byrd et al., 1992; Curtis et al., 1988; Chakraborty et al., 2010; Gallivan & Keil, 2003; Joshi et al., 2007; Walz et al., 1993). לפיכך, המאמר הנוכחי מאמץ את הגדרת הלמידה של Argyris and Schon’s  (1974, 1978) כביטוי לפעילות התקשורת של האנליסטים כגורם מרכזי ברכישת מידע תוקף על דרישות, בידע מוגבר, ובביצוע טוב יותר של מערכות ופרויקטים.

טבלה 3. מאפייני מודל 1 ומודל 2 של פעילויות העברת תקשורת        

(Argyris, 2002; Argyris & Schon 1974, 1978; Salaway, 1987)

גישה של מודל 2           גישה של מודל 1                הגדרה של התנהגות העברה            התנהגות העברה

מעניין לציין, כי בעוד מודל 1 של פעילויות תקשורת עשוי להיות יעיל יותר עבור טיפול בבעיות שגרתיות, מודל 2 של פעילויות צפוי לגרום לייצור של “מידע תקף המלא ביותר” וידע ההכרחי לקבלת פעולה יעילה (Argyris, 1976, p. 369). אם פרטים מחפשים מידע תקף ומשוב (כלומר, פעילויות תקשורת של מודל 2), הם יכולים לטפל ביעילות רבה יותר בבעיות טכניות או בינאישיות. לדוגמה, פעילויות במודל 2 נמצאו כמייצרות מידע תקף יותר מאשר פעילויות במודל 1 (Salaway, 1987), משפרות ביצועים של צוותים ארגוניים (Edmondson, 1999), ומונעות הישנות של בעיות (Tucker et al, 2002). פעילויות תקשורת של מודל 2 עשויות להיות חשובות במיוחד עבור מערכות מורכבות ולא מובנות שבהן הקשר בין פעולות לתוצאות מעוכב או מעורפל (Bolman & Deal, 2008), כגון בפרויקטים של IS שבהם האנליסטים צריכים לתקשר בצורה יעילה עם המשתמשים לאסוף מידע תקף ולרכוש ידע (Argyris & Schon, 1978, Browne & Rogich, 2001). למשל, האנליסטים בדרך כלל אוספים דרישות מערכת די קצרות על ידי ראיון או סקר משתמשים (Neill & Laplante, 2003, Watson & Frolick, 1993) ולא בהכרח מחפשים נתונים כדי לבסס את תוקף הדרישות שנאספו, המשקפות התנהגויות תקשורת במודל 1. בעוד שגישה זו עלולה להביא למערכות העונות על כל הדרישות שזוהו על ידי אנליסטים, עדיין היא יכולה לא לענות על צרכי המשתמשים (Arthur & Gröner, 2005, Gallivan & Keil, 2003) בשל זיהוי חלקי או אי הבנה של האנליסטים לגבי דרישות המשתמש (Appan & Browne, 2010; Browne & Ramesh, 2002; Byrd et al., 1992). לעומת זאת, על ידי חיפוש והצגת מידע הנצפה, ובדיקה פומבית שלו, פעילויות תקשורת במודל 2 עשויות להניב ידע תקף, אשר, בתורו, יכול להוביל למערכות העונות טוב יותר על דרישות משתמשים.

תמיכה ראשונית בנימוק הנ”ל בהקשרים של ISD סופקה על ידי Salaway (1987) אשר בחן קלטות של אינטראקציות האנליסטים עם משתמשים, ומצא כי אנליסטים שהשתמשו בפעולות שידור מהמודל 2 זיהו טעויות נוספות במידע שנמסר להם, מאשר אלו שהשתמשו בפעילויות מהמודל 1. עם זאת, Salaway (1987) לא בחן את תוכן המידע המועבר ולא קישר בין פעילויות העברת המידע במודל 2 לתוצאות הפרויקט. יתר על כן, כפי שצוין גם ב- Salaway (1987), קטעים של חמש דקות של יחסי גומלין בין המשתמש לאנליסט לא היו מתאימים לקביעת טעויות גדולות יותר (עמ ‘261) בהקשר לפרויקט ISD. העבודה הנוכחית מרחיבה את המחקר הזה על ידי בחינת מקרים של שני פרויקטים ISD, האם אנליסטים של IS המשתמשים במודל 2 של פעילויות העברה, דורשים ידע רב יותר על צרכי משתמשים של מערכות המידע מאשר אנליסטים המשתמשים בפעילויות של המודל 1, והאם ידע זה משפיע על תוצאות הפרויקט.

4. שיטה

המחקר הנוכחי אימץ את הגישה לניתוח מקרי בוחן (Lee, 1989, Yin, 2003) לבחון פעילויות תקשורת של אנליסטים IS, והשפעתן על תוצאות הפרויקט IS. גישה זו מתאימה במיוחד ללימוד תהליכים חברתיים מורכבים בהקשרים של עולם אמיתי שלהם (Dubé & Paré, 2003; Eisenhardt, 1989; Eisenhardt & Graebner, 2007; Yin, 2003). לאור מורכבות התקשורת משתמש-אנליסט והיחס שלה לפעילויות ארגוניות, גישת של מחקר מקרי בוחן היא יעילה במיוחד לבחינת שאלות המחקר במאמר הנוכחי.

4.1. בחירת מקרים

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

(Marakas & Elam, 1998; Pitts & Browne, 2004; Vitalari, 1985)

ערוצי תקשורת שהשתמשו בהם (Gallivan & Keil, 2003), וסיכוני הפרויקט (Barki, Rivard, & Talbot, 1993) . בנוסף, פרויקטים עם תוכנות שהוכנו מראש גם לא נכללו כי התוצאות שלהם יכלו לסמוך על גורמים אחרים מאשר פעילויות התקשורת של האנליסטים, כמו החלטות שנעשו לפני תחילת הפרויקט (Soh, Kien, & Tay-Yap, 2000; Wu & Shen, 2006). לפיכך, כדי למזער את ההשפעה הפוטנציאלית של גורמים אחרים מאשר פעילויות התקשורת, המקרים נבחרו מתוך מערכות גדולות יחסית שפותחו לאחרונה. כמו כן, נראה כי פרויקטים גדולים, ארגוניים, פנימיים עשויים להיות כרוכים באינטראקציות נרחבות של משתמשים-אנליסטים (Argyris, 1976, Salaway, 1987), המאפשרות מיקוד ברור יותר על הנושאים המרכזיים של המחקר.

על מנת לזהות פרויקטים שעמדו בקריטריונים לעיל, התקשרנו לכמה מנהלי IT ומבצעים ושאלו על מאמצי הפיתוח והיישום האחרונים בארגון שלהם, (טבלה 4): אחת מהחברות LifeSci, חברה בת של חברת תרופות מובילה בתעשייה, והשניה היא Regional Insurer, גם חברה בת אזורית של חברת ביטוח מובילה. לכל ארגון היו כ -2000 עובדים, והם ראו את הפרויקטים כעדיפות להחלפה של מערכות קיימות באמצעות שימוש במתודולוגיה של Agile, אשר סייעה לשליטה נוספת בהשפעת גורמים חיצוניים על תוצאות הפרויקט.

4.2. איסוף נתונים

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

על ידי המנהלים, המשתמשים המרכזיים והאנליסטים, או במהלך הראיונות, או הוצעו על ידם כאשר נשאלו על מרואיינים פוטנציאליים אחרים בין המשתתפים בפרויקט. פרוטוקול הראיון מובא בנספח B, והוא משתנה במקצת בהתאם לתפקיד המודיע בפרויקט. מעקב אחר ראיונות טלפוניים עזר להבהיר או להשלים את המידע מהראיונות, שנמשכו בין 30 דקות לשעתיים כל אחד. כל הראיונות מלבד שלושה הוקלטו, ובשלושה ראיונות שלא נרשמו השתמשו בהערות שנעשו בכל מקרה ספציפי. הראיונות הוקלטו ותומללו במלואה לפני שהשתמשו בניתוח ותיעוד הפרויקט (למשל, הודעות דוא”ל, זמן פגישה, תרשימי זרימת נתונים ונתונים, מסכי הדפסה של המערכת ודוחות פלט של המערכת) לשליפת נתוני הראיון (Dubé & Paré, 2003; Eisenhardt, 1989; Yin, 2003).

טבלה 4. סיכום תיאור לשני המקרים

החברה Regional Insurer                החברה LifeSci

5. ניתוח

המקרים נבדקו באמצעות גישה של אינדוקציה אנליטית שמתחילה בבדיקת יחסים בין הנושאים המרכזיים של המחקר, ולאחר מכן בחינה מחודשת של הנתונים כדי לגלות דפוסים שעשויים להוביל לממצאים יוצאי דופן או לשינויים במבנה המחקר או בהצעות שלו (Patton, 2002, p. 454). לפיכך, התחלנו עם ניתוח מעמיק של כל מקרה כדי לקבוע האם התצפיות שלנו תמכו ביחסים התיאורטיים בין נושאי המחקר (Lee, 1989 Patton, 2002), וכן לאפשר ניתוח והשוואה בין המקרים. במטרה זו, התמלילים מסמכי המקרים נבדקו והנתונים קודדו ואורגנו לפי ארבע מבנים מהמסגרת של  Chakraborty et al. (2010) אשר מאפיינת אינטראקציות בין קבוצות בפרויקטים: בחינה, מתן משמעות, עמות, וסיום. הבא, את הנושאים חולקו לשתי קבוצות, תקשורת אנליסטים

ותוצאות הפרויקט, וכן תהליך קידוד עדין יותר בוצע עבור כל מבנה. לדוגמה, ציטוטים המשויכים להודעות תקשורת הורחבו ונבדקו לזיהוי פעילויות התקשורת הספציפיות שנעשה בהן שימוש, ומאפיינים שלהן, תוכן המידע שלהן, ואת הידע שנרכש על ידי האנליסט; תוצאות הפרויקט סווגו עוד יותר לתוצאות הקשורות לתהליך או למוצר של ISD. בעוד שתוצאות התהליך מתייחסות לאיכות הפרויקט, כולל עמידה בלוחות זמנים ותקציבי הפרויקט, תוצאות המוצר משקפות את המאפיינים של המערכת שפותחה, כמו גם עמדות ואמונות בעלי העניין לגבי הפרויקט והמערכת, והשימוש בה (Barki et al, 1993) . כדי לאמת את הנתונים שנאספו ואת פרשנות שלהם, תיאורי המקרים נקראו על ידי מנהלי IT של שני הארגונים לאימות ולאישור כי האירועים שתוארו התרחשו כמתואר בכתב. לאחר מכן, ממצאים של המקרים הושוו ונעשה ניתוח השוואתי כדי להבין טוב יותר את התהליכים השונים בכל פרויקט, וכן לבחון את היחסים התיאורטיים, ואם יש צורך, לעדכן את מבנה המחקר וההצעות לפי נתוני המקרה.

5.1. סקירה של מקרה 1: LifeSci

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

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

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

5.1.1. תקשורת של LifeSci אנליסט

כפי שניתן לראות בטבלאות 5 ו -6, אנליסט LifeSci רכש מידע ממקורות שונים לרבות המשתמשים (טכנאי מעבדה) ועמיתיו בתחום ה- IT. התוכן של מידע זה היה על התהליכים העסקיים של המשתמשים ועל משימותיהם, תכונות הנדרשות מה- IS החדש, מערכות קיימות שמהן ניתן לחלץ נתונים עבור קלט לתוך ה- IS החדש, וכן טכנאי המערכות הרלוונטיים המשמשים כיום. בהתבסס על Byrd et al. (1992), אלה מסווגים (בעמודה האחרונה של הטבלאות) כמידע על 1) דרישות המשתמש ועיצוב ממשק, 2) תהליכים עסקיים ומשימות, 3) מסגרת הבעיה (כלומר, מטרות ISD וסביבת התמיכה הקיימת) .

5.1.2. שלב בחינה

לאחר שהוקצה לביצוע פרויקט, למידה של האנליסט של LifeSci החלה מהתקשורת עם ITPM אשר נתן לו סקירה כללית של מטרות הפרויקט. IPTM ציין כי במשך חודשיים הראשונים הוא השקיע בממוצע 8-10 שעות בשבוע בעבודה עם האנליסט, ו- 4-5 שעות בשבוע בחודשיים הבאות, בהסברים על תפקוד מערכות של LifeSci הרלוונטיות ובמצב העתידי הרצוי של המערכת החדשה. כמו כן, IPTM ראה את הפרויקט כ-“חוויית למידה עבור [האנליסט החדש שהתקבל לעבודה] כדי להכיר את המערכות ב [LifeSci]”.

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

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

ניתן לאפיין את פעילויות התקשורת בין האנליסט של ה- IT לבין עמיתיו בתחום ה- IT כחקירה כאשר האנליסט רוצה לגלות את סביבת התמיכה הקיימת (כלומר, מסגרת הבעיה בתחום החברה) (Byrd et al., 1992) על מנת לבצע את עבודתו. כפי שניתן לראות בטבלה 5, האנליסט עוסק במשך כ- 170 שעות בפעילויות בשלב של סקירה ובחינה.

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

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

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

ואז, מספר הממשקים הדרושים לחלץ נתונים […] כל חתיכה בודדת הייתה קטנה אבל כולן ביחד זה כבר היה מורכב (מתכנת IT).

אני לא מאמין כמה מהר הוא הבין את זה, לגבי מורכבות המערכת, ונכנס לזה. זה היה מדהים (טכנאי 2).

5.1.3. שלב מתן משמעות

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

ובכן, אנו [הטכנאים שנבחרו] נראה [לאנליסט IT] את הקובץ אקסל […]. הרבה שאלות ותשובות, ופשוט נשב ונעשה את העבודה שלנו, והוא יתערב וישאל כאשר זה צריך (טכנאי 2).

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

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

וזה שונה ממה שעשתה IT בעבר. […] הם היו מבלים חודש לבקר אנשים או לדבר ולקבל דרישות ואז הם סוגרים את הדלת במשך שישה חודשים […]. אני חושב שטוב היה כי [לפסיכולוגית ה- IS] ערך את הפגישות הסדירות האלה … (טכנאי 1).

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

במשך שעה [של הפגישה] – [אנליסט IS היה אומר] הני הדבר, הני השדות בהם אני מסתכל, מה אני יכול לקבל, מה אני יכול לקבל, ואז כאשר [א IS] היה משהו שעבד באופן איטרטיבי, הוא היה משתמש במערכת נתונים מדומים, מביא אותם ואומר, “בסדר, זה מה שאתם אמורים לראות”, ואז אנשים היו אומרים “הייתי רוצה שזה יהיה שם, והאם את יכול להפעיל את זה ולאפשר גישה לאנשים אלה ולא להם”. […] כן, הייתה אינטראקציה די טובה בהקשר לכלי (טכנאי 1).

[המפגשים האלה] רק סוג של בסיס למגע – משהו כמו ‘מה אם [המערכת] נראית כך’ (טכנאי בכיר).

היו מפגשים שבועיים [עם אנליסט IS]. […] רוב המפגשים היו רק לעבודה עם הכלי הזה עצמו – אין יראו הממשקים למשתמש (מתכנת IT).

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

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

איכות שלה [ממשק המערכת] טובה. אנשים [משתמשים] אוהבים את זה, זה גמיש מאוד. […] יש סדרה שלמה של שדות מידע, […] הערות וכל סוגי של מידע אחר. ואתם יכולים לבדוק – להשתמש בפונקציונליות של SharePoint במסך – כך שאתם יכולים לקבוע אישית איזה עמודות אתם רוצים לראות. כל אחד [טכנאי] יכול לומר, “אני לא מעוניין בזה, אני מעוניין בזה”, כך שהם יכולים לשנות את הדו”ח (טכנאי בכיר).

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

זיהינו כי [פונקציונליות של ניתוח רגישות] זה לה היה. באחת מההערות מהמפגשים […] רשום כי, אתם יודעים – נושא 9 מתוך 12, לא יהיה לנו [ניתוח רגישות] שם […]. [אנליסט IS] לא שלח את ההערות אלינו, ואמר כי זה מה שהועלה בדיון בנושאים, וכי אנחנו לא מתקנים משהו (ספציפי) (טכנאי 1).

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

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

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

טבלה 5. תקשורת של אנליסט IS ופעילויות למידה ב- LifeSci במשך שלב בחינה

תוכן המידע                    מאפייני התנהגויות תקשורת (מודל 1 / מודל 2)  התנהגות תקשורת אנליסט   התנהגות תקשורת

טבלה 6. תקשורת של אנליסט IS ופעילויות למידה ב- LifeSci במשך שלב מתן משמעות

תוכן המידע                    מאפייני התנהגויות תקשורת (מודל 1 / מודל 2)  התנהגות תקשורת אנליסט   התנהגות תקשורת

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

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

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

5.1.4. עמות וסיום של הפרויקט

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

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

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

מצאתי שזה באמת קל להשתמש [במערכת]. אני התרשמתי. [… IS אנליסט] הכניס הרבה בטבלה שהרגשתי שזה היה חדש להציע ושלא ראינו עוד את זה במערכות או במסגרות אחרות (טכנאי 2).

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

לא, היישום לא היה על לוח הזמנים (טכנאי בכיר).

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

5.2. סקירה של מקרה2: Regional Insurer

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

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

לאנליסט של Regional Insurer היה נסיון של שלוש שנים בשיטות Agile, ונסיון של יותר מעשר שנים בתכנות. למרות שהוא לא הכיר את Regional Insurer והיה לא נסיון מועט בתחום הכספים,

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

5.2.1. התקשרות של האנליסט Regional Insurer

כפי שרואים בטבלאות 7 ו- 8, אנליסט Regional Insurer אסף מידע בעיקר ממנהל המשתמשים ומקבוצתו באמצעות פעילויות פורמליות ובלתי פורמליות שהתמקדו בהשגת מטרות ספציפיות על מידע על תהליכים עסקיים ועל התכונות שיש לשלב במערכת. במסגרת של מתודולוגיית Scrum Agile, הוא חילק את הפרויקט למחזורים בן שלושה שבועות בשם “ספרינט” במהלך שלהם הוא התקשר כל יום וכל שבוע עם המשתמשים כדי להבין את הצרכים שלהם, להעריך את ההתקדמות, ולהציג הדגמות של מערכת.

5.2.2. שלב בחינה

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

במשך השבועיים [תחילת הפרויקט] אני חושב שנפגשנו כמעט כל יום, אולי חצי יום כל יום – בבוקר … מה שעשינו בפיתוח המודלים הוא להקים שפה משותפת: לסגור את הפער בין IT לעסקים […] מין נסיון לעבוד ולהקים רשימת מונחים איתה נוכל לעבוד (אנליסט IS).

הבנו בנקודה זאת כי למנהל לה היה את כל המידע […], לכן הרגשנו כי אנו צריכים כמה משתמשים כבדים כדי באמת … [לגלות] “מה קורה בתחום זה” […] (אנליסט IS).

בנוסף, הוא בילה יום אחד עם שני משתמשים להתבונן ולשאול שאלות איך שהם ביצעו משימות היומיום שלהם. הוא ציין שבאינטראקציות ראשוניות אלה הוא התמקד בהבנת תהליכים עסקיים של כל אחד מהמשתמשים ובמשימות על ידי כך שביקש מהם להסביר “מה [הם] עושים” בלי לדון במערכת החדשה.

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

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

5.2.3. שלב מתן משמעות

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

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

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

יתר על כן, בסוף כל מחזור, צוות הפיתוח הציג את האב טיפוס הפונקציונלי במהלך “ביקורת איטרטיבית” במפגשים עם בעלי העניין בפרויקט, עם קבוצת המשתמשים, ו עם מנהל הפרוייקט ומנהל כספים. אנליסט Regional Insurer הדגים פונקציונליות ספציפית של המערכת (כלומר, “סיפורי משתמש”) על ידי ביצוע משימות ספציפיות במערכת החדשה, תוך מתן משוב של הנוכחים. כפי שניתן לראות בטבלה 8, הפגישות הללו העידו על ידע של האנליסט בתהליכים העסקיים של המשתמשים ובדרישות המידע. יתר על כן, הם גם קידמו דיאלוג משתמש – IT על תהליכים עסקיים ופונקציונליות המערכת, עזרו לגלות תכונות לשילוב לתוך המערכת, וכן חשפו דעות מתנגשות של המשתמשים על העסק תהליכים עסקיים והמטרות החדשות של המערכת. לכן, בהתקשרות במפגשים האנליסט הגן על נקודת המבט שלו לגבי תכנון המערכת. הוא שימש בנתונים שנצפו כדי להפגין איך תבוצע משימות בעזרת אב-טיפוס פונקציה מסוימת, ועל ידי הבקשה למשוב מהמשתמשים שאותו אפשר היה לקשור לנתוני האב-טיפוס ולבחון.

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

[במשך ההדגמה] הם [קבוצת IS] העבירו לנו קורס: ” איך זה יתפקד, האם זה יעשה עבודה שלכם, האם משהו לא עובד בו, האם ישנם חלקים שאפשר לשפר?”, וכד’. לאחר מכן, אם היה תקל (באג),[…] הם באו … “אם אנחנו עושים את זה, מה התגובה שאתם רוצים לקבל, מה צריך העסק שלכם?” (המשתמש, תורגם מצרפתית).

טבלה 7. התקשרות של מנתח IS ופעילויות למידה ב- Regional Insurer בשלב בחינה

תוכן המידע                     מאפייני התנהגותיות של התקשרות      התנהגות של התקשרות   התנהגות התקשרות

(מודל 1 / מודל 2)                                   האנליסט

טבלה 8. התקשרות של מנתח IS ופעילויות למידה ב- Regional Insurer בשלב מתן משמעות

תוכן המידע                     מאפייני התנהגותיות של התקשרות      התנהגות של התקשרות   התנהגות התקשרות

(מודל 1 / מודל 2)                                   האנליסט

5.2.4. עמות וסיום של הפרויקט

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

אני זוכר כי למשך [מפגש] תכנון כאשר בחרנו סיפור [של המשתמש] של הדפסה בצ’קים, אני בטוח כי הסברתי “זה מה שיקרה, תבחרו סוכן, ואז בשדה הסוכן תבחרו את טופס הצ’ק, ותדפיסו אותו ותשמרו”. הם כולם אמרו מצויין, זה היה מצויין עבורם [אז] (אנליסט IS ב- Regional Insurer).

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

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

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

המשתמשים היו מרוצים, ואני אף פעם לא ראיתי משתמשים מרוצים (מנהל פרויקט IS)).

בהחלט! אני אומר לכם, זה [IS] עונה על כל צרכי הצוות. […]המערכת מאוד ידידותית למשתמשים. לא מסובך לעבוד איתה (משתמש – תרגום מצרפתית).

6. פעילויות התקשרות של אנליסט ולמידה של דרישות מידע

כפי שניתן לראות בטבלה 9, הדמיון הקונטקסטואלי בין שני הפרויקטים מביא לניתוח משתנים חשובים בתוך כל מקרה בוחן (Yin, 2003); כלומר, פעילות התקשרות של האנליסט ותוצאות פרויקט. שני הפרויקטים בוצעו בחברות בנות גדולות של ארגונים רב לאומיים כדי להחליף מערכות קיימות, היו בעדיפות גבוהה בשני הארגונים, קיבלו תמיכה מההנהלה העליונה, ונהנה מהשתתפות ומעורבות של משתמשים – מומחים. יתר על כן, שני האנליסטים עקבו אחר מתודולוגיית פיתוח אבולוציונית באמצעות פעילות התקשרות דומה וערוצי תקשורת. עם זאת, למרות חוסר הניסיון שלו עם התחום העסקי, האנליסט מ- Regional Insurer היה מסוגל לספק מערכת מוצלחת יותר מאשר עמיתו שלו מ- LifeSci. הניתוח שלנו מראה כי התוצאות השונות שנצפו בשני הפרויקטים נבעו בעיקר ממה שכל אנליסט למד, ומפעילויות ההתקשרות שלהם.

לפי Argyris and Schon  (1974, 1978), התנהגויות לפי מודל 1 מעכבות את הגילוי והתיקון של ליקויי ידע שהופכים את הפעולה ללא יעילה, ואת האירועים שהתרחשו ב- LifeSci הם בקנה אחד עם טענה זו. למרות שהאנליסט LifeSci ציין כי סוגיית ניתוח הרגישות הועלתה על ידי הטכנאים, האופן שבו זוהתה דרישה זו וטופלה (כלומר, התנהגות התקשרות לפי מודל 1) לא אפשר לאנליסט לראות עד כמה חשובה הפונקציונליות הזו עבור המשתמשים במשימות שלהם. בפרט, האנליסט לא צפה כיצד ההחלטה שלו להוציא את הפונקציונליות הזו תשפיע על המשימות של המשתמשים.

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

יש אולי 10 דברים קריטיים אנחנו דאגנו להם, והם פספסו עם 9 מהם (טכנאי 2).

נכון לעכשיו, שביעות רצון [מהמערכת] היא אפס. […] אני מניח שבהקשר לדרישה המקורית, אנחנו במרחק 75% מסה”כ הדרך אליה (טכנאי בכיר).

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

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

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

על תוצאות הפרויקט

טבלה 9 (המשך).

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

על תוצאות הפרויקט

טבלה 9 (המשך).

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

על תוצאות הפרויקט

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

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

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

הניתוח של שני המקרים תומך גם במחקרים הקודמים בהם מציינים כי התועלת של IS תלוי בין השאר על כמה טוב פונקציונליות המתוכננת בה תומכת בדרישות המשימה (Dishaw & Strong, 1999; Goodhue תומפסון, 1995). הממצאים מראים כי האנליסטים יותר נוטים לבצע פונקציונליות של המערכת העונה על צרכי המשימות של המשתמשים, כאשר הם מזהים את חסרונות הידע שלהם על תהליכים עסקיים של המשתמשים, אשר ניתן לזהות בקלות רבה יותר באמצעות מודל 2 של פעילויות התקשרות. למשל, מנהל המשתמשים של Regional Insurer  ציין כי ניסיונות האנליסט לזהות את חוסר הידע שלו בתהליכים העסקיים של המשתמשים היו נרחבים:

לפעמים אני מדבר על נושאים עסקיים אותם [אנליסט IS] לא מבין, אבל אם הוא לא מבין ולא אומר לי שהוא לא מבין, אז בוודאות יהיו בעיות באיזשהו חלק. אבל הוא [אנליסט IS] שואל אותי 322 שאלות להיות בטוח הוא הבין היטב (מנהל המשתמשים Regional Insurer, תרגום מצרפתית).

ובכן, ממצאי המחקר הנוכחי תומכים, בהקשר ל- ISD, את ההסבר של  Argyris and Schon’s (1974, 1978) כי פעילויות לפי מודל 2 מביאות לקבלת החלטות יעלה יותר, והממצאים מאפשרים לטעון כי, בפרט, פעילויות התקשרות במודל 2 בהקשר לתהליכים עסקיים של המשתמשים, הן אלה שמאפשרות ליצור החלטות יעילות בתכנון אשר עונות על צרכים של משימות המשתמשים. לכן:

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

6.1. פעילויות התקשרות של אנליסט IS

מפעילות ההתקשרות המתוארת בטבלה 10 עולה כי בעוד שני האנליסטים השתמשו למעשה במודל 2 של פעילויות התקשרות כדי ללמוד על הצרכים של המשתמשים במערכת, הם גם התמקדו בנושאים שונים בפרויקט, אשר ככל הנראה הביא לתוצאות הפרויקט השונות. יותר ספציפית, בעוד שיש הבדל קטן בין פעילויות התקשרות של שני האנליסטים מנקודת מבט של מודלים 1 ו- 2, נתוני המקרים מצביעים על הנחות שונות לגבי הפרויקטים שלהם, וממקדים את תשומת הלב שלהם בנושאים שונים של פרויקטים. תצפית זו עולה בקנה אחד גם עם ההשקפה כי פעילויות ומסרי התקשרות של פרט נשלטים על ידי הנחותיהם (Argyris & Schon, 1978), ומציעה כי האינטגרציה של מסגרת הלמידה במודלים 1 ו- 2 עם הספרות על הנחות והתמצאויות, יכולה לספק הבנה יותר לעומק של פעילויות התקשרות של האנליסט בפרויקטים IS.

לפי Hirschheim and Klein (1989) ו- Markus and Benjamin (1996), פעילות האנליסטים

ומסרים של תקשורת ב- ISD הם פונקציה של ההנחות שלהם כלפי הפרויקט, מטרות שלו, והתפקידים של בעלי העניין שלו. אוריינטציות אלה מסוכמות בטבלה 11, ואפשר לתאר אותן לגבי תפקידים שונים של אנשים מעורבים: יועצים רגילים או של המערכת, מנחים ותומכים  בפיתוח המערכת. אנליסטים ויועצים של מערכות אמורים להניח כי בעלי עניין שונים משתפים במטרות מערכת ברורות אשר נקבעו על ידי ההנהלה ומיועדות לשפר יעילות ומועילות ארגונית (Hirschheim & Klein, 1989). מומחים במערכות, הרואים תפקיד שלהם כספק של טכנולוגיה, מפנים את מאמציהם ל- “פתרונות טכניים פרודוקטיביים”(Hirschheim & Klein, 1989, p. 1204)  (כלומר, לנושאי מסגרת הבעיה). מצד אחר, המנחים אמורים להאמין כי המציאות מורכבת וסובייקטיבית, ורואים את התפקיד שלהם כלעזור למשתמשים להבין את המציאות (Hirschheim & Klein, 1989; Markus & Benjamin, 1996). כיוון שהם עוזרים ללקוחות ליישב אינטרסים אישיים וקבוצתיים על מנת להגיע להסכמה על צרכי המערכת (Hirschheim & Klein, 1989; Markus & Benjamin, 1996), מנחים עוסקים בפעילויות התקשרות נרחבות כדי ללמוד את משימות המשתמשים ואת צרכי המערכת.

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

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

אנחנו לא רוצים ניהול שינויים, אנחנו רוצים שהשינויים יהיו פשוט חלק מהתהליך […] (מנתח IS).

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

ברור, הם [משתמשים] לא יודעים במדויק ויש בינם סתירות לגבי איך הם עובדים. […] אנסה לוודא ו- […] לבחון מחדש או לברר את הסתירות (מנתח IS, Regional Insurer).

במשך התכנון [מפגשים שבועיים] היה לנו פתרון, אנחנו סקרנו [מפגש של הדמיה], אנחנו הדגמנו, אומר [מנהל חשבונות] “אני לא בטוח, אני חושב שמשהו חסר כאן, …”, הם דנו בזה; עשינו שיחות אינטנסיביות בסיבוב הבא, ועיצבנו מחדש את המערכת (מנתח IS, Regional Insurer, תרגום מצרפתית).

לכן, זה ממש בעיה שלהם [המשתמשים] לומר לנו מה אנחנו רוצים ליצור [במונחי מערכת שפותחה] (מנתח IS, Regional Insurer)

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

למשתמשים של LifeSci היו גם צרכים ושיטות שונים של ביצוע התהליכים העסקיים שלהם. עם זאת, בניגוד לאנליסטים Regional Insurer, פעילויות התקשרות אינטנסיביות של אנליסט LifeSci  לפי מודל 2 היו עם קבוצת ה- IT וה- ITPM, ומכוונות להבנה טובה יותר של מערכות ארגוניות (כלומר, מסגרת הבעיה). כפי שמוצג בטבלה 10, הוא השקיע רק כמה שעות בפעילויות התקשרות עם משתמשים כדי ללמוד על התהליכים העסקיים שלהם.

היו סתירות מסויימות בתוך הקבוצה. לחלק מהם [טכנאים] לא היה צורך [בניתוח רגישות] ולחלק – היה (טכנאי 1, LifeSci).

טבלה 10. מודלים של למידה בהם השתמשו אנליסטים של LifeSci ו- Regional Insurer

אובייקט של למידה

מספר שעות        מסגרת הבעיה                תהליך עסקי              דרישות מידע               התנהגות           שלב

(בערך)              מערכות ארגוניות קיימות     של משתמשים    של משתמשים              התקשרות

טבלה 11. אמונות (ממדים אידיאליים) מוצגות על ידי התמצאות שונה בתפקיד

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

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

טענה 2: כאשר צרכי משתמש מפוצלים או דו-משמעיים, פעילויות התקשרות לפי מודל 2 של אנליסטים IS המכוונים אל תהליכים עסקיים של משתמשים, תהיינה יעילות יותר מאשר פעילויות התקשרות שלהם לפי מודל 2 כאשר הם מכוונים אל לימוד מסגרת הבעיה.

חשוב לציין כי ממצאים אלה עשויים להיות מוגבלים תוכן הפרויקטים הנחקרים כאן. לדוגמה, Markus (2004) מבדיל בין פרויקטים IS עסקיים המשפיעים על תהליכים עסקיים של המשתמשים, כמו שני הפרויקטים שנחקרו במאמר זה, ופרויקטים IS טכניים אשר מכוונים אל שיפור יעילות טכנית ואמינות. בניגוד לפרויקטים IS טכניים, Markus (2004) טוען כי פרויקטים עסקיים משפיעים על תהליכי משתמשים, ודורשים “התייחסות מסוג שונה למאפייני ה-‘פתרון‘ ותהליך שינוי אחר” (עמ’ 5, גופן נטוי במקור). ואכן, הניתוח של שני המקרים הצביע על כך שגישת “סיוע” היא הולמת יותר עבור פרויקטים IS עסקיים מאשר גישה של מומחה מערכות, כפי שמוצג בטבלה 12.

אפילו אם משתמשים מזהים צרכי מערכת משותפים ומובנים היטב במהלך פרויקטים IS עסקיים, יש לפחות שתי סיבות לכך שגישת סיוע עשויה להיות עדיפה על גישת מערכות. ראשית, גישת סיוע יכולה ללמד משתמשים לגבי היתרונות ושינויים פוטנציאליים אותם המערכת תביא לעבודתם (Kirsch & Beath, 1996). שנית, גישת הסיוע מאפשרת למשתמשים להיות מעורבים בצורה אינטנסיבית בפרויקט, אשר בתורו יכול להגביר את מעורבותם ואת קבלתם של המערכת (Hartwick & Bararki, 1994). לפיכך, למרות המחקר החדש של פיתוח מוצר ממנו עולה כי מידע מקודד פשוט דורש אינטראקציות מוגבלות עם המקור (Hansen, 1999), אנו מאמינים כי גישה של סיוע צפויה להוביל להצלחה בהקשר לפרויקטים IS עסקיים.

לעומת פרויקטים IS עסקיים, פרויקטים טכניים מוערכים בהתבסס על התפעול שלהם ועמידה בתקציבים ובלוחות זמנים ולא לפי קבלה על ידי משתמשים (Markus, 2004). בהתאם לכך, מומחי מערכות עשויים להיות מתאימים יותר לפרויקטים טכניים מאשר מנחים/מסייעים, בהנתן הם מפנים את מאמציהם לפעילויות התקשרות לכבי הסביבה הטכנולוגית הדרושה לתמיכה ביעדי המערכת כ-“מוגדרים מראש” על ידי ההנהלה (Hirschheim & Klein, 1989). יתר על כן, מומחי מערכות יכולים לעסוק בפעילויות התקשרות במודלים 1 או 2 כדי לזהות אמצעים טכניים היעילים ביותר להשגת היעדים המשותפים של פרויקט טכני. לדוגמה, מומחי מערכות עשויים להשתמש בפעילויות התקשרות של מודל 2 כאשר אפשרויות פיתוח המערכת הם מורכבים או רבים על מנת ללמוד עליהם, ולהסתמך על פעילויות מודל 1 כאשר אפשרויות טכניות הם מעטים. בכל מקרה, ההתמקדות של מומחה המערכות נותרה על האמצעים הטכניים של השגת מטרה מוגדרת.

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

טבע של צרכי מערכת

משותפות/ חד משמעי        משותפות/ חד משמעי

לפיכך, בעוד שמחקר בשינוי תפקיד של מנתח IS העלה את חשיבותו של “האוריינטציה הבסיסית כלפי המטרות והאמצעים של עבודת IS המעצבת את מה שעושה העובד בפועל” (Markus & Benjamin, 1996, עמ ‘387), המחקר הנוכחי מרחיב את הספרות הזאת על ידי מתן ראיות אמפיריות ראשוניות לגבי הקשר בין תוצאות הפרויקט ו-“הכוונה של תפקיד” של אנליסט IS, פעילויות התקשרות ותוכן שלהן, כאשר צרכים של בעלי עניין מפוצלים או דו-משמעיים. בנוסף, המחקר הנוכחי משלב את הספרות על אוריינטציה של תפקיד עם הספרות על למידה במודלים 1 / 2, כדי לספק מסגרת קונצפטואלית של פעילויות התקשרות של אנליסטים ואוריינטציות תפקידים שיכול להיות שימושי ליצירת הצעות מרובות למחקר עתידי.

7. מסקנה

ממצאי המחקר הנוכחי מצביעים על כך שאנליסטים של IS לומדים על איך צרכי המידע של המשתמשים משפיעים על תוצאות ה- ISD. בעוד מחקר בעבר הציע לעתים קרובות כי הידע של האנליסטים על התהליכים העסקיים של המשתמשים מביא להצלחת המערכת (למשל, Byrd et al., 1992; Curtis et al., 1988; Gallivan & Keil, 2003; Markus & Mao, 2004), עדויות מעטות מאוד, תיאורטיות או אמפיריות, קיימות בהקשר זה. כדי לפנות לפער חשוב זה, המחקר הנוכחי מאחד מושגים של לימודים במודלים 1 / 2, עם הספרות על התקשרות ואוריינטציה בתפקידים כדי לספק בחינה אמפירית מקדימה ועבודת הכנה של פעילויות התקשרות של אנליסטים IS והשפעה שלהן על תוצאות פרויקט IS.

ממצאי המחקר הנוכחי מציינים כי אנליסטים IS אשר משתמשים בפעילויות התקשרות במודל 2 כדי ללמוד על תהליכים עסקיים של משתמשים ולפתח מערכות אשר עונים על משימות משתמשים וצרכים ארגוניים בסבירות רבה יותר מהאנליסטים שמשתמשים פעילויות התקשרות במודל 1. באופן ספציפי יותר, אנליסטים אשר משתמשים באופן אקטיבי בדוגמאות קונקרטיות, בדיקות ואימות, ובקבלת משוב לגבי פעולות אותן עושים משתמשים כדי לבצע את המשימות שלהם, באופן סביר יותר מזהים מחסר בידע שלהם על משימות משתמשים. זה בתורו יכול לעזור להם לתכנן ולפתח מערכות העונות על צרכי משתמשים. על יד חקירה של השפעת פעילויות התקשרות של אנליסטים במודל 2 על ידע שלהם על צרכי משתמשים ועל תוצאות הפרויקט,  המחקר הנוכחי מרחיב גם את המחקר קודם בו נבחנה השפעת התנהגויות אנליסט על זיהוי טעויות מידע (Salaway, 1987). הממצאים שלנו תומכים במחקר הקודם בו טוענים כי מה שחשוב זה “טבע ואיכות” של ההתקשרות משתמש-אנליסט (Gallivan & Keil, 2003, p. 37; Boland, 1978; Majchrzak et al., 2005; Markus & Mao, 2004; Salaway, 1987),, ומרחיב אותו בעזרת זיהוי מספר פעילויות התקשרות ספציפיות אותן יכולים לאמץ אנליסטים.

יתר על כן, הניתוח שלנו גם מציע כי, כאשר צרכי המשתמשים במערכת הם מפוצלים או דו-משמעיים, האנליסטים המשתמשים בגישת הסיוע נוטים יותר לפתח מערכות העונות על צרכי המשתמשים מאשר אנליסטים המתמקדים בהבנת נושאי מסגרת הבעיה. הממצאים האלה מרחיבים את הספרות על שינוי בתפקיד אנליסט IS (Hirschheim & Klein, 1989, Markus & Benjamin, 1995) בכך שהם מבהירים את הקשר בין תוכן התקשרות האנליסטים לתוצאות הפרויקט.

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

7.1. מגבלות המחקר והצעות למחקר עתידי

יש להכיר במגבלות המאמר הזה. כיוון שהמחקר מתבסס על נתונים רטרוספקטיביים, מגבלה פוטנציאלית היא בכך שמרואיינים זוכרים את האירועים לא באופן מושלם. כדי למזער את בעית האמינות, תוך הראיון שאלנו את המרואיינים על אירועים עובדתיים, ובעיקר ביקשנו מהם לתאר את הפעילויות שנעשו על ידי אנליסטים ואת התוצאות. יתר על כן, הנתונים שנאספו, נבדקו באמצעות מקורות מרובים כדי לאמת את “מה שקרה”, אשר עשוי למזער את המגבלה הזו. המגבלה השנייה הייתה במשך שונה של כל אחד מהפרויקטים IS. בעוד הפיתוח ב- LifeSci היה במקור שישה חודשים, פיתוח ב- Regional Insurer נמשך 18 חודשים. לפיכך, משך הפרויקט הארוך עשוי לספק לאנליסט ב- Regional Insurer יותר זמן כדי לשאול כראוי ולבקש משוב על תהליכים עסקיים של המשתמשים. בעוד שהבדל בזמן אינו מאיים על תקפות ממצאי המחקר הנוכחי, הוא יכול לעזור ולהסביר את התנאים הדרושים להתקשרות נאותה. מגבלה אפשרית נוספת היא שחקירת המקרים שנבחרו, נערכו במסגרת פרויקטים ISD מורכבים בתוך ארגונים גדולים. אמנם זה עזר לשלוט על מספר גורמים המשפיעים על המצב, זה גם יכול היה להגביל את רמת הכלליות של ממצאי המחקר. לדוגמה, Hansen (1999) מצא כי כדי להבין משימות מורכבות, מקבל המערכת “צריך לקלוט הזדמנויות מרובות” ולרכוש ידע הדרוש לאינטראקציות אינטנסיביות עם מקור (עמ’ 88). לכן, מחקר עתידי נדרש כדי לאמת ממצאי המחקר הנוכחי ולבדוק פעילויות התקשרות של אנליסטים IS בתוצאות בהגדרות הקשר אחר. זה יכול לעזור לזהות פרויקט IS בו פעילויות התקשרות של מודל 1 מתאימות יותר מפעילויות של מודל 2. בנוסף, מחקרים עתידיים עם שליטה על הגדרות הקשר יכולים גם לבחון את השפעת פעילויות התקשורת של האנליסטים על תוצאות שונות. לדוגמה, שימוש בפעילויות התקשרות של מודל 1 יכול לגרום לפרויקטים קצרים יותר מאשר שימוש בפעילויות התקשרות של מודל 2.

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

הודעות תודה

מקורות