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

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

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

למה דווקא הם? מה מייחד את הגישה של מומחי התהליכים? התשובה היא שלראייתם הכוללת מתווספים שני מרכיבים חשובים: המרכיב הראשון – נטייה לשימוש בשפה אנושית, והשני – יכולת לראות את המערכת מנקודת המבט של מי שאמורים להשתמש בה. המאפיינים הללו הם שעומדים בבסיס השיטה של IT Solutions.

כיצד זה עובד בפועל? שיטת עבודה זו באה לידי ביטוי כבר בשלבי האפיון הראשונים בפרויקט:

שלב כתיבת המכרז (RFP)

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

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

שלב האפיון המפורט

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

– מן ההיבט הטכני, התהליך ייראה כך:

הקמת לקוח חדש>>סימון הטבת חייל משוחרר>> הפעלת הנחה בתכנית המנוי ל- 12 חודשים

– לעומת זאת, באפיון התהליך מכיוון המשתמשים, אותו תהליך ממש יוגדר כך:

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

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

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

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

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

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

כיצד הפרויקט כולו מרוויח מעבודה נכונה בשלבים שטרם הפיתוח?

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

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

אורנה ראובני היא מנהלת פרויקטים ותחום מתודולוגיות ב-IT Solutions