הידעתם? – רק אחד מכל שני פרויקטים מערכות מידע ניתן להכתיר כ"הצלחה". כל השאר נכשלים לחלוטין או שהם מגיעים אל קו הסיום באיחור ניכר תוך חריגה מהתקציב.
חשוב לדבר על תפיסת agile- כיום לא עושים אפיון ארוך אלא מחלקים את הפרויקטים לחלקים. מתחילים אפילו עם נושא קטן שיביא ערך מהיר ויראה לארגון שניתן לסמוך על המערכת ומשם לבנות להמשך
למה?
לא משנה מה גודלו, כל פרויקט מערכות מידע כרוך בלא מעט סיכונים. על מנת להגדיל את הסיכויים שפרויקטים יצטרפו אל החצי המוצלח – אנו, ב-IT Solutions פועלים על פי מתודולוגיות ושיטות עבודה המבוססים על ניסיונם עתיר השנים של המנהלים בחברה. בפוסט זה אנו חולקים אתכם כמה מהם.
1. ניהול השינוי – בפרויקטים של הטמעת מערכות מידע ישנו כלל ידוע בשם אמיל"י – "אני, מה יוצא לי מזה". אכן חשוב שהלקוח יבין איזו תועלת אמור לייצר לו כל מרכיב במערכת אבל חשוב לא פחות שכל משתמש יידע באילו תהליכי עבודה הוא עומד להרגיש את השינוי, תוך ירידה לפרטים הקטנים ביותר.
לא תמיד מדובר במשימה פשוטה. למשל, כשמטמיעים מערכת מידע אצל אנשי מכירות מגלים שעצם החיוב של אנשי המכירות להשתמש במערכת אינו מובן מאליו. אנשי מכירות רבים אוהבים להשאיר את כל המידע אצלם בין אם באפליקציה פרטית, במחברת או באוגדן כרטיסי ביקור פיזיים, אשר מכילים את המשאב היקר ביותר של איש המכירות – הלידים.
על החסם הזה אפשר להתגבר בדרכים שונות. לדוגמה, עם עליית המערכת לאוויר ניתן לתגמל את אנשי המכירות כספית על הזנת הלידים ותהליכי המכירה. גם על עבודת היתר במהלך הפרויקט אפשר לפצות את העובדים, שבנוסף על העבודה היומיומית שלהם, צריכים ללמוד דברים חדשים ולהקליד נתונים למערכת. התגמול לא בהכרח חייב להיות כספי. התגמול יכול לבוא לידי ביטוי גם בקידום, הרחבת תחומי אחריות, או באופן חד פעמי – למשל חופשת סופשבוע.
2. לרוב פרויקט מוגדר כמוצלח על פי הפרמטרים של עמידה בלוחות זמנים ובתקציב, אבל כדי להוכיח שפרויקט הצליח באמת – אין בכך די.
פרויקט מערכות מידע הוא עסק יקר שעלותו נעה בין מאות אלפים לכמה מיליונים (ובפרוייקטי ענק גם מאות מיליונים ומיליארדים, כמו בדוגמאות בראשית הפוסט) בטרם מחליט הארגון על הפרויקט, המנכ"ל מבקש מהגורם שיזם את הפרויקט בתוך הארגון לפרט מהן ההצדקות לו, ובמיוחד מהו צפוי להיות ההחזר על ההשקעה (ROI). הבעיה היא, שאחרי שהפרויקט הושלם, אף אחד כבר לא טורח לבדוק האם ההבטחה מומשה, באמצעות מדידה כמותית של הפעילויות שבוצעו במערכת. תוצאות מדידה שכזו מאפשרות למנהלים להפיק לקחים ולדעת באילו תהליכים עליהם להתמקד ולאילו כיוונים לנתב את מאמצי השיפור של ותשומת הלב של העובדים.
לדוגמה: אחת המטרות של פרויקטי הטמעה במוקדי שרות, היא קיצור זמן השיחה הממוצע, המושג בין היתר באמצעות ריכוז כל פעולות הנציג במסך אחד. קיצור זמן השיחה אמור להיות מתורגם לנתונים מדידים נוספים כמו הקטנת ההוצאות וגידול בהכנסות. את המדידה הזאת אין לבצע מיד לאחר העליה לאוויר אלא כעבור תקופה, נניח שנה, במהלכה עובדי המוקד כבר התרגלו למערכת, והצטברו מספיק נתונים אותם ניתן לנתח ולהפיק מהם תובנות.
3. משתמשי המפתח נדרשים בעיקר בשלב האפיון, בדיקות הקבלה וההדרכות. כדאי להגדיר בתקופות אלו את סדר היום שלהם, כך שחצי יום יוקדש לפרויקט והחצי השני לעבודה שוטפת.
מסיבה לא ממש ברורה, כאשר באים להעריך את העלות הצפויה של פרויקט, ישנו מרכיב חשוב שקיימת נטייה שלא להביאו בחשבון – עלות המשאב הפנימי ארגוני. מדובר באנשי המפתח בתוך הארגון שחיוניים בכל שלביי הפרויקט. למשל, בשלב האפיון המפורט הם צריכים להגדיר איך רוצים לעבוד. לאחר מכן, במהלך בדיקות הקבלה, הם בודקים ממש מסך מסך במערכת. לכן, כדי לאזן בין חיוניותם הן לתפקוד השוטף והן לפרויקט, הפתרון המיטבי הוא לחלק את יום עבודתם כך שחצי אחד יוקדש לפרויקט והחצי האחר לעבודה השוטפת.
כמובן, אם לא ניתן לחלק את יום העבודה של משתמש מפתח ויש הכרח להחליפו או לשכור לו עוזר – יש לתמחר את עלותם במסגרת עלות הפרויקט.
4. רצוי ועדיף שהדרכות משתמשי הקצה יתבצעו על ידי משתמשי המפתח, בסיועו של הספק. כך ניתן למעשה תמריץ למשתמשי המפתח להיות מעורבים בכל שלבי הפרויקט, למן שלביו הראשונים, באופן שיסייע להפחית עלויות והתנגדויות בשלב ההטמעה.
כפי שצוין בסעיף הקודם – רצוי לשלב את אנשי הארגון בפרויקט מוקדם ככל שניתן. כך, כאשר יגיע השלב שבו המערכת אמורה להיכנס לפעולה, הם יחושו רתומים למשימה ולא יוכלו להגיד "רגע, סליחה, לא דיברו איתנו, מה זה התהליכים האלה?!".
יתרון נוסף הוא שכאשר משתמשי המפתח הם אלו שמקבלים את ההדרכה הראשונית, הם יכולים להעביר את הידע בעצמם לשאר אנשי הארגון. יש לכך שני יתרונות ברורים – קודם כל חיסכון בעלויות, משום שהדרכה שנעשית בידי אנשי הארגון מהווה חלופה להדרכה שמתבצעת על ידי גורם חיצוני. שנית, משתמשי המפתח יודעים לדבר בשפה של הארגון, כך שהדגש בהדרכה עסקי יותר, וטכני פחות, דבר התורם לאפקטיביות של ההדרכה.
5. על מנת להגדיל את הסיכויים שהפרויקט יעמוד בלוחות הזמנים להשלמתו, יש להתחיל את טיוב הנתונים לקראת ההסבות (העברה מושכלת של הנתונים מהמערכת הישנה לחדשה), מוקדם ככל שניתן. מומלץ למנות גורם בארגון שירכז את הנושא ויהיה אחראי על אספקת הנתונים ובקרתם. כמו כן, מומלץ לשכור גורמים חיצוניים, שעלות עבודתם נמוכה מזו של עובדי הארגון, אשר יעבדו על טיוב המידע בשלבים המוקדמים.
בכל ארגון מצטברים עם השנים הררי נתונים על לקוחות, שירותים, ספקים, וכן חשבוניות, תהליכי גביה – מי שילם ומי לא וכו'. כאשר עוברים ממערכת אחת למשנתה, האתגר הוא להגיע למצב שבו העבודה במערכת החדשה תימשך בדיוק מן הנקודה שבה היא הופסקה במערכת הישנה.
המשמעות של טיוב, הוא שלאחר שנים ארוכות במהלכן הצטבר הרבה "זבל" במערכת, הדבר האחרון שאנחנו רוצים הוא לעשות קופי פייסט מהמערכת הישנה לחדשה. למרות זאת, אולי בגלל שמדובר בתהליך מייגע ו"לא כיפי", התהליך שבו עוברים לקוח לקוח, בודקים כפילויות, ובוחרים איזה מידע להשאיר ואיזה לא, הוא שלב שארגונים מוצאים את עצמם דוחים לרגע האחרון, תוך אמירת "יהיה בסדר".
זו טעות. שלב טיוב ההסבות הוא שלב חשוב, מעין תת פרויקט בפני עצמו, שחייבים להתייחס אליו בתכנית העבודה – להקצות למשימה אדם שיפקח עליה לאורך כל הפרויקט, יחליט איזה מידע יועבר ובאיזה אופן, בעוד שהעבודה הטכנית עצמה תבוצע בידי גורם חיצוני שעלות עבודתו זולה יותר.
6. מיפוי תהליכי עבודה קיימים מול תהליכי עבודה רצויים: שינוי מהותי בתהליכים שאותם מנהלת המערכת. למשל, תהליך מכירה שהיה בנוי בדרך מסוימת, הולך להתנהל מהיום אחרת. הייתי מעלה את הנושא הזה יותר למעלה
בארגון שמשדרג מערכת מידע יכולים להתקיים שלושה מצבים. במצב אחד, הלקוח עבד במשך שנים ארוכות (יכול להיות אפילו בסדר גודל של 15-20 שנים), שכלל וייעל את תהליכי העבודה שלו, כך שכל מה שנותר הוא ללמוד את התהליכים הקיימים ולהסב אותם למערכת החדשה, תוך שינויים קלים, בהתאם לדרישת הלקוח.
במצב מן הסוג השני, הלקוח נצמד למערכת לא יעילה תוך שהוא מבצע מעקפים ואלתורים פרטיזנים שלא כחלק מהתהליך התקין, למשל באמצעות שימוש בכלים ידניים, או כלים חיצוניים כמו גיליונות אקסל.
במצב השלישי, הלקוח נשאר עם הליך עבודה לא יעיל מבלי לסטות ממנו.
לכן, כשעוברים למערכת חדשה יש קודם כל להגדיר את תהליך העבודה שמתאים לצרכים הנוכחיים, ורק אז ליישמו במערכת החדשה. קיימות כמה חברות המתמחות בהגדרת תהליכי עבודה, אשר צורת החשיבה שלהם היא כמו באקדמיה – "בואו נחשוב מה התהליך האופטימלי".
אולם פנטזיות לחוד ומציאות לחוד.
לאחר שהגדרנו עם הלקוח מהי דרך העבודה האופטימלית יש להתאימה למגבלות מוצר המדף שנבחר, אשר כולל כבר תהליכים מובנים, שמיושמים באינספור ארגונים. בזכות ניסיונה, יודעת IT Solutions לחבר באופן אופטימלי בין הכרותה העמוקה עם תהליכים ארגוניים, לבין היכרותה עם קרבייה של מערכת המידע. או בקיצור: אנחנו ב-IT Solutions יודעים לגשר בין התהליך העסקי הרצוי לבין התהליך כפי שהוא ניתן למימוש במערכת.
7. חשוב לקבל מראש פידבקים על צוות הפרויקט, ובעיקר על מנהלו, עימו חשוב גם לקיים ראיון אישי. אין להסתפק בממליצים שמעביר הספק על מנהל הפרויקט, ומומלץ לנסות להגיע באופן עצמאי לגורמים שעבדו עימו בעבר ולקבל מהם חוות דעת.
סוד גלוי בתחום המחשוב הארגוני הוא שאם ארגון מסוים מחפש מערכת מיחשוב, כמו למשל CRM, לא מאוד משנה באיזה מוצר הוא יבחר – סבירות גבוהה ביותר שהוא יקבל את מה שהוא צריך. אז מה עושה את ההבדל בין פרויקט מוצלח ללא מוצלח? – הספק המיישם. לכן, צריך לבדוק מי האנשים הספציפיים שהולכים לעבוד עליו, כאשר בעל התפקיד המשמעותי ביותר מביניהם הוא כמובן מנהל הפרויקט.
שוק המיחשוב בישראל אינו גדול. רבים מן העובדים הבכירים בו עבדו ביותר מחברה אחת. ניתן כמעט לומר שזהו שוק שבו כולם מכירים את כולם. ניסיונה רב השנים של IT Solutions מאפשר לה להגיע גם ללקוחות שהספק לא הציג כממליצים, על מנת לקבל חוות דעת מקיפה יותר על הצוות שמיועד להוביל את הפרויקט.

תמי זיתן היא מנכ"ל משותף ב-IT Solutions