אתגרי הגישור בפרויקטים טכנולוגיים, כלים פרקטיים למגשרים
מי מפחד מטכנולוגיה?
העולם משתנה בקצב מהיר. טכנולוגיה הפכה להיות חלק בלתי נפרד מאסטרטגיית הצמיחה של עסקים וארגונים.
אחד ממחוללי השינוי המרכזיים ביותר הינם פרויקטי טכנולוגיה. פרויקטים אלו המשלבים חדשנות, תקציבי עתק ועולם תוכן מורכב ומאתגר מובילים לא פעם לקונפליקטים מול עובדים, ספקים, לקוחות וקבלני משנה.
אמנם קונפליקטים הינם חלק בלתי נפרד מחיי הארגון, ומנהלים מתמודדים עימם על בסיס יומיומי, אולם בהגיע קונפליקט לחדר הגישור מוצא עצמו המגשר הממוצע מול זירה ועולם תוכן מורכבים ומאתגרים עובדה המציבה בפניו אתגר משמעותי לביצוע הגישור באופן מוצלח.
במאמר זה אנסה לפשט מעט את עולם התוכן באופן שיקנה למגשר העסקי את הכלים הנדרשים להתמודד עם סיטואציות קונפליקטיביות המשלבות טכנולוגיה ואנשים.
המאמר נכתב מזווית ראייתו של מגשר (ולא של טכנולוג), ולפיכך הכלים והרעיונות שיוצעו במאמר אמורים לאפשר למגשרים להבין טוב יותר את הזירה ולהיערך לגישור באופן מקצועי.
הייטק - זירה של חדשנות ויצירה
בישראל, זירת החדשנות העולמית ואומת הסטארט-אפ, אימוץ טכנולוגיה על ידי חברות הינו עניין שבשגרה. אמנם בשנים האחרונות מסתמנת ירידה דרמטית בהשקעה בחברות הון סיכון בישראל (כפי שניתן ללמוד לדוגמא מסקר שנערך על ידי חברת סידביז[1] בשנת 2023), אך מדוחות שהתפרסמו על ידי חברות וגופי מחקר מובילים כגון רשות החדשנות[2] עולה כי ההייטק ההישראלי הינו קטליזטור קריטי לצמיחה ולפריון של המשק הישראלי. מגזר הטכנולוגיה אחראי לחלק הגדול ביותר בייצוא מישראל והינו בעל קצב הצמיחה הגדול ביותר בגיוסי עובדות ועובדים ורמות השכר.
הייטק , הרבה יותר מסטארטאפים
באופן כללי, ארגונים נוטים לקחת כיום פחות סיכונים, בעיקר כאשר מדובר בשילוב של טכנולוגיות מתקדמות בתהליכי הליבה הארגוניים.
אין מגזר שהקדמה זרה לו, מרשתות קמעונאיות גדולות עוברות לזירה הדיגיטלית לשיפור חוויית הקניה (Customer Experience), דרך קופות החולים המספקות פלטפורמות דיגיטליות למבוטחים לשיפור השירות (Patient Experience) ואיכות הטיפול ועד לגופים מסחריים חברות ביטוח, בנקים והמגזר הציבורי המשקיע מיליארדי שקלים בפיתוח מערכות ייעודיות לשיפור חוויית האזרח (Citizen Experience) בפרויקטים מורכבים ועתירי טכנולוגיה וממשקים.
פרויקטי מיחשוב הינם סינרגיה של תשתיות מחשוב (Infrastructure), פלטפורמות תוכנה, אפליקציות וכלים וסביבות פיתוח טכנולוגיות. פרויקטים הינם שילוב של תשתית (המותקנת במחשבים פיזיים או בענן), התאמה (יישום) וקונפיגורציה (פיתוח קוד) של מערכות כך שיתאימו לדרישות.
סביב הפרויקט פועלות מערכות בקרה, אבטחת מידע, ניטור, ניהול ועוד מערכות רבות. עם הגשת המערכת ללקוח לצרכי בדיקות ואישור נעזרים במערכות בדיקה ובקרה נוספות (ייעודיות) וכן במערכות לליווי ההטמעה וההדרכה של המשתמשים בשימוש בפתרונות החדשים שיושמו.
האחריות על הצלחת הפרויקט מוטלת על כתפי ספק שירותי האינטגרציה (וקבלני המשנה שלו) יחד עם צוותי הלקוח והיועצים המלווים את הפרויקט.
רק 15% מהפרויקטים מסתיימים בזמן ובתקציב!
כאמור, חברות וארגונים בישראל משקיעים תקציבי עתק להשקעה ופיתוח של פתרונות טכנולוגיים במנעד חדשנות רחב ומאתגר.
בשנת 2017 פרסם ארגון PMI (Project Management Institute) [3] סקר עולמי לבחינת אחוזי הצלחה של פרויקטים טכנולוגיים והגורמים המרכזיים לכישלונם. מהסקר עולים ממצאים מרתקים: כ-14% מבוטלים ללא כל תוצאה משמעותית, 31% אינם עומדים ביעדים שהובטחו, 43% חורגים מהתקציב ו-49% חורגים מלוח הזמנים המוסכם. רק 15% מהפרויקטים עומדים בלו"ז בתכולה ובתקציב. בסקר נוסף [4] שבוצע בשנת 2023 עלו ממצאים נוספים המצביעים על כך שככל שהצוותים מקצועיים יותר ורמת הסינרגיה והניהול גבוהה יותר אחוזי ההצלחה גדלים.
על פי דוח [5] שפורסם על ידי חברת המחקר STKI (חברה המתמחה בשוק הטכנולוגיה וה-IT הישראלי מזה עשרות שנים) שוק מערכות המידע הארגוניות בישראל נאמד בכ-9.4 מילארד דולר בשנת 2023 וצפוי לצמוח בכ-10% בממוצע בשנים הקרובות. כ-50% מתקציבים אלו, כ-4.8 מילארד דולר מושקעים בפרויקטי פיתוח, יישום ואינטגרציה של מערכות מיחשוב לארגונים ועסקים.
מערכות יחסים ארוכות שנים
הפרויקט לא מסתיים עם מסירת המערכת ללקוח אלא עובר לשלב תמיכה, תחזוקה, שינויים ושיפורים. ההתקשרות בין הצדדים ארוכת שנים ומחייבת מערכת יחסים יציבה, בריאה, מאוזנת והוגנת.
התשתית המשפטית של התקשרויות אלו מבוססת על הצעות מחיר, מסמכי מפרט דרישות, מסמכי מפרט טכנולוג, מכרזים, הסכמים משפטיים מורכבים ולא מעט תורה שבעל-פה. האחריות לתחזק את מערכת היחסים הזו מוטלת על כלל הגורמים המעורבים, על הארגונים וכמובן על מנהלים ואנשי מקצוע המעורבים בהתקשרות.
כבכל מערכת יחסים עיסקית, גם מערכות יחסים אלו חשופות לעליות ומורדות במהלך הדרך, קונפליקטים וויכוחים המגיעים לא פעם לפתחו של בית המשפט וכמובן לחדר הגישור.
נוסיף על כך את העובדה שבחלק ניכר מהפרויקטים משולבות חברות יעוץ אסטרטגי המביאות עימן מתודולוגיות ושיטות עבודה חדשניות. כך נוצרת זירה מרובת משתתפים (לקוח, ספק, יועץ) מה שמגדיל את פוטנציאל החיכוך והעימות בפרויקט ולאחריו.
מדוע זה כלכך מורכב?
לפני מספר חודשים קיבלתי שיחת טלפון ממנכ"לית של חברת אינטגרציה מובילה ששיתפה אותי במשבר מול אחד מלקוחותיה. המשבר נבע מעיכוב תשלומים של הלקוח בגין אי עמידת האינטגרטור בהתחייבויותיו (לדברי הלקוח) לאספקת מערכת עובדת. מכתבי איומים הדדיים בין עורכי הדין של הצדדים כבר נשלחו, זרעי העימות נשתלו והאמון שהיה בבסיס העסקה התערער ונשחק.
כיצד אני יכול לסייע? שאלתי. "אנחנו כבר בתהליך גישור" ענתה המנכל"ית. מצויין עניתי ובכל זאת מדוע התקשרת?
התשובה שקיבלתי היתה חדה וברורה "המגשר מנסה באמת ליצור דיאלוג בנינו אך אין לו קצה קצהו של מושג בתחום, וכך במקום לקרב אותנו לפתרונות הצדדים מוצאים עצמם מאבדים אמון גם ביכולת המגשר עצמו לסייע".
כפתרון הציע המגשר לשלב יועץ מומחה בתחום מערכות המידע על מנת שיוכל ללוות גם הוא את התהליך.
הסברתי שאשמח לקחת את התפקיד במידה ויתקיימו שני תנאים, הראשון הסכמה מלאה של שני הצדדים, והשני פגישה אישית עם המגשר ללא נוכחות הצדדים.
בפגישה עם המגשר פגשתי אדם חכם ומנוסה בתחום, מקצוען של מערכות יחסים אך ללא הבנה בסיסית בעולם התוכן. ביקשתי ממנו לפרוס בפני את סיפור האירוע וכבר אחרי 10 דקות הבנתי שהוא מבין את המחלוקת אך לא את הבסיס עליו היא יושבת. הוא אמנם ידע לנתח נכון את הרגישויות והתסכולים של כל אחד מהצדדים אך נשאר חסר תשובות באשר לשאלה הפשוטה ששאלתי "מה ניתן היה לעשות על מנת לא להגיע לאירוע המשבר?".
הכירו את מחוללי המשבר
את הקונפליקטים נפגוש בדרך כלל תחת מעטה של אסקלציה מקצועית (בעיה טכנולוגית המונעת מהצדדים להתקדם), משבר כספי (עצירת תשלומים), משבר תוצרים וזמינות (כח אדם לא מוקצה לפרויקט או כח אדם בלתי מיומן מוקצה בחלקי משרה) סוגיות של לוחות זמנים ועוד.
לכל קונפליקט יהיה את ה"סיפור המיוחד שלו" ריכזתי לפניכם מספר דוגמאות קלאסיות של קונפליקטים בתחום:
מחלוקות היקף ודרישות: בדרך כלל קונפליקטים הנובעים מהבדלים בהיקף הפרויקט, הדרישות והציפיות, הנפוצים בפרויקטים טכנולוגיים עקב מפרט מתפתח ותשומות של בעלי עניין.
חילוקי דעות בתקציב ובעלויות: קונפליקטים הקשורים למגבלות תקציב וחריגות עלויות ביוזמות טכנולוגיות, שכן הוצאות הפרויקט עלולות להסלים במהירות.
ציר זמן ועיכובים באספקה: מחלוקות הנובעות מהארכות ציר הזמן של הפרויקט ועיכובים באספקה, שיכולים להיות קריטיים בפרויקטים טכנולוגיים עם לוחות זמנים צפופים.
מחלוקות בין ספקים וקבלנים: בקונפליקטים עם ספקי טכנולוגיה וספקים, במיוחד בנוגע לאיכות המוצר, רמות השירות ומימוש החוזים.
אתגרי תאימות ואינטגרציה טכנית: קונפליקטים הנובעים מבעיות טכניות, בעיות תאימות וקשיי אינטגרציה בעת יישום טכנולוגיות חדשות בתוך מערכות קיימות או מערכות אקולוגיות.
סכסוכי קניין רוחני: סכסוכים הקשורים לפטנטים, זכויות יוצרים, סימנים מסחריים וסודות מסחריים בתעשיית הטכנולוגיה, שבה הערך של קניין רוחני הוא לרוב בעל חשיבות עליונה.
התנגשויות בסוגיות פרטיות ואבטחת מידע: סוגיות ואירועים הכוללים הפרות מידע, הפרות פרטיות ובעיות אבטחת סייבר, שיכולות להיות כרוכות במידע רגיש ובעמידה ברגולציה.
זוהי אמנם רשימה חלקית אך מיד נראה כי בפועל ישנם רק שלושה מחוללי משבר יסודיים (כל השאר הן גרסאות שונות של אותו האירוע).
לפיכך בבואנו לגשר קונפליקט טכנולוגי, עלינו לפעול בשכבות העמוקות יותר. חשוב להכיר ולזהות את מחוללי המשבר היסודיים, להבין על מה הם יושבים, להכיר את עולם המושגים והתפיסות.
כסף אינו סיבה למשבר, הוא אמצעי או אינדיקטור
אני מקבל פניות רבות מלקוחות או מספקים שנקלעו למשבר בפרויקט. כשאני מבקש להציג את האירוע כמעט תמיד "תקציב" או "כסף" מוצגים בפני כסיבה למשבר. צד אחד חדל לשלם ומצפה להמשיך ולקבל שירות, צד אחר מעכב מסירת תוצרים עד שלא יקבל את התשלום בגינם. כסף אינו סיבה למשבר – הוא אינדיקטור בלבד. וככזה כסף גם לא יפתור אותו. חשוב להבין, אילוצי תקציב מופיעים לעתים קרובות כגורם העיקרי לעימותים בפרויקטים טכנולוגיים, אך לעתים קרובות הם סימפטומטיים לבעיות יסוד עמוקות יותר. קונפליקטים אלו מתעוררים לעתים קרובות עקב תכנון לקוי, היקפי פרויקט מתפתחים, שינוי סדרי עדיפויות, תקלות בתקשורת ויעדים סותרים בין בעלי העניין. התמקדות קצרות טווח בסוגיות תקציביות יכולה לטשטש את הבעיות האמיתיות, ולמנוע הבנה הוליסטית של אתגרי הפרויקט.
פתרון יעיל מצריך התייחסות לגורמים השורשיים הללו, טיפוח תקשורת טובה יותר, ניהול שינויים בהיקף והתאמה של יעדי הפרויקט עם ציפיות בעלי העניין. בכך, צוותי פרויקט יכולים לנווט במגבלות תקציביות בצורה יעילה יותר ולשמור על מסגרת התקציב שאושרה.
מודל מעשי למגשרים – הבנת הסיטואציה הינה 50% מהדרך לפתרון
על בסיס נסיון מצטבר בניהול של מאות פרויקטי תוכנה ואינטגרציה, שהובילו לא פעם לעימותים וויכוחים ומשברים, מיפיתי את שלושת מחוללי המשבר העיקריים בפרויקטים אלו. להבנתי, שלושת מחוללי משבר אלו הינם הליבה והיסוד של הבעיה. על מגשר מקצועי לדעת לזהות את התשתית עליה יושב המשבר ועל מנת לאפשר לו להנחות את לצדדים להגיע להבנות והסכמות.
1. משבר מבוסס תכולה - Scope-Based Conflict
שלב התיחום הראשוני (High-Level design) או שלב האפיון המפורט (Detail Design) הם השלב הראשון של כל פרויקט תוכנה, פיתוח או אינטגרציה. שלב זה כולל הגדרת מטרות ויעדי הפרויקט, התוצרים, האילוצים וציפיות בעלי העניין בצורה ברורה ומקיפה (Scope). ללא תיחום ברור המגובה במסמכים ובמדדים ברורים להצלחה חשוף הפרויקט לקונפליקטים וויכוחים ועימותים. אחת התופעות השכיחות ביותר היא תופעת השו"שים (שינויים ושיפורים / Change Request) או בשפה מקצועית יותר "פריצת מסגרת התיחום", כאשר תכולת הפרויקט אינה ברורה או סגורה דיה, תוספות ושינויים מבוצעים בתדירות גבוהה וללא מדדי בקרה ואישור נאותים, יובילו השינויים לחריגה בלוחות הזמנים, פריצת מסגרת התקציב וכמובן חברי צוות מתוסכלים מה שבסופו של דבר מסכן את הצלחת הפרויקט. יתרה מכך, דרישות לא ברורות עלולות לגרום לאי הבנות בין חברי הצוות ובעלי העניין (הלקוח), פערי ציפיות וקצרים בתקשורת. כאשר למשתתפי הפרויקט פרשנויות שונות לתוצר הסופי (שמשתנה ומתגמש עם הזמן) יוביל הדבר לגרום לעיכובים, שגיאות ותסכול, ויעכב את התקדמות הפרויקט ושיתוף הפעולה. תיעוד היקף או דרישות לא מספק יכול גם הוא להקשות על זיהוי ולטפל בסיכונים פוטנציאליים בשלב מוקדם של הפרויקט, ולהגדיל את הסבירות לבעיות בלתי צפויות שיתעוררו בהמשך. חוסר הבהירות הוא מקור לוויכוחים בין אם מדובר על מספר הדוחות שאמורים להיות מיושמים, מי אחראי על ביצוע בדיקות אבטחת מידע, מי הגורם המגדיר את תשתיות המיחשוב הנכונות וכיצד תבוצע בדיקת המערכת לפני עליה לאוויר. אי בהירות בסוגיות אלו מוביל לבלבול, הסרת אחריות והטלתה על הצד השני מה שמוביל להסלמה ועימות. ניתן לזהות די בקלות משברים מסוג זה, הם יאופיינו בטענות כגון "לא היה ברור לכם שנרצה את הנתונים מהמערכת הקודמת?" (אשר הסבתה לא היתה בתכולה מראש...), או "הרי זה הסטנדרט בתעשיה תיעוד והדרכה הם חלק מהפרויקט אז מה אם לא כתבנו". טענה פופולרית נוספת "זו אינה דרישה חדשה, לא הבנתם את הדרישה המקורית אנחנו התכוונו מראש שהמערכת תשלול תכונה זו ולכן אתם מחוייבים לספק", או "אנחנו לא מוכנים לשלם על שינויים ושיפורים" מצביעות בראש ובראשונה על העובדה שהדברים לא היו סגורים מראש באופן ברור. אירועים סביב של ממשקים בין מערכות שלא מתקשרות (או ממשקים בלתי יציבים), הכנת נתונים להסבת מידע ממערכת וותיקה לחדשה (באחריות מי?) ועוד הם חלק מתיחום התכולה שאם לא בוצע כיאות מראש יחזור וייצר אסקלציות שיובילו למשבר בסופו של יום. המלצות: נסו להבין האם היה אפיון, האם הוא היה מקובל על כל הצדדים, אילו מנגנונים יושמו כדי להכניס שינויים בתכולה, מה היו הקפי השינויים והאם הגורמים המעורבים הסכימו על ההנהלות הזו לאורך זמן (או שמא אחד הצדדים הרגיש מנוצל לאורך זמן). פתרונות אפשריים: נסו להציע נקודת חיתוך, נוהל שינויים מסודר ומבוקר, חלוקת התוצרים למנות קטנות, שיטה ומתודולוגיה לביצוע שינויים. זהו מי מנציגי הצדדים יכול להוביל מתווה סדור ומאורגן ובעל יכולות מתודיות סדורות, פתרון משבר שכזה מחייב סדר, מתודולוגיה ושקיפות משני הצדדים להבטיח החזרת הפרויקט למסלול.
2.משבר מבוסס איכות - Quality Based Conflict
הגדרת מדדי איכות הכרחית להצלחת טכנולוגיית המידע ופרויקטי פיתוח. בפרויקטים טכנולוגיים זו דרישה בסיסית המשפיעה במישרין על תוצאות הפרויקט ועל שביעות רצון מקבלי המערכת (הלקוחות). ללא הגדרה ברורה של מדדי איכות, פרויקטים חשופים לקונפליקטים והסלמות. ראשית, חוסר בהגדרת איכות יכול לגרום לציפיות מעורפלות. לבעלי עניין, לרבות לקוחות וצוותי פרויקטים, עשויות להיות פרשנויות שונות לגבי מה מהווה תוצר איכותי. חוסר התאמה זה עלול להוביל לתסכול, מחלוקות ועיכובים כאשר כל המעורבים מנסים ליישב את הציפיות שלהם. שנית, ערפול של מדדי איכות יפגע ביכולת המבצע לספק אחריות ושירות למערכת. כאשר קריטריוני איכות אינם מוגדרים בבירור, קשה לייחס אחריות לליקויים כלשהם. חוסר אחריות מוביל לשיח האשמות המסלים ומחמיר את המשבר. כיצד יראה משבר איכות? הלקוח לא יהיה שבע רצון מביצועי המערכת ("זה לא מהיר מספיק"), טענות לגבי "חוסר ידידותיות ממשק המשתמש", או "במערכת הקודמת זה היה הרבה יותר קל ונוח". הלקוח יציף טענות על ניראות (זה נראה מיושן), יותר מידי "הקלקות" כדי להגיע למידע, חוסר בנתונים או נתונים חלקיים ללא יכולת להסביר (בשני הצדדים) מה בדיוק חסר ולמה ובגדול תחושה של חוסר מקצוענות בצד הלקוח וחוסר בהירות מצד הספק (הם לא באמת יודעים מה הם רוצים). גם סוגיות של אבטחת מידע כגון מערכת חשופה לאיומי סייבר שלא עברה ביקורת אבטחת מידע ייפול לקטגוריית איכות במידה ולא נלקחו בחשבון מדים אלו מראש. המלצות: נסו להבין האם יושמו מנגנוני בקרה כלשהם לזהות סוגיות איכות (כגון ביצועי מערכת, חווית משתמש, קלות שימוש, פשטות שדרוג המערכת, בהירות הטקסטים באפלקיציה, תהליכי הזדהות פשוטים ועוד). פתרונות אפשריים: הציעו הגדרה מחודשת של תהליכי אבטחת איכות, יצירת מדדי איכות ויעדים מוגדרים היטב, ביצוע סקירות ובדיקות סדירות ויישום בדיקות אוטומטיות במידת הצורך. הציעו לשלב מנגנוני זיהוי מוקדם, כגון סקירת קוד ואינטגרציה מתמשכת. קחו את הדיון לערוצי תקשורת בלתי פורמאליים (מהירות או ביצועים הינם סוגיה סובייקטיבית ולא תמיד אובייקטיבית מה שמהר לאחד, דווקא איטי מאוד לאחר), נסו להציע גורם חיצוני (מתמחה בבקרת איכות) שיקבע וידרג את מדדי האיכות למעשה, גישה פרואקטיבית לניהול איכות היא הפתרון הנכון ביותר אל מול המנעות מהבעיה מה שמוביל להסלמתה.
3. משבר מבוסס מחויבות - Commitment Based Conflict
פרויקט מחייב הנהלה חזקה. כניסה לפרויקט ללא בעלי עניין (Stake Holders) מעורבים לא יצלח. בין אם מדובר על מנכ"ל, סמנכ"ל כספים, מנהל מערכות מידע או מנהל פרויקט זוטר, אחריות, סמכות ומשאבים חייבים להינתן בידי מקבלי ההחלטות ובעלי העניין כדי להצליח. חוסר מחויבות, במיוחד בעלי עניין הינו מתכון להסלמה משמעותית ולכשל פוטנציאלי. כאשר גורם אחד או יותר המעורבים בפרויקט אינו מפגין מחויבות, הדבר עלול להתבטא בדרכים שונות. התנהגויות אופייניות המעידות על חוסר מחויבות זה כוללות מעורבות לא עקבית, היעדרות תכופה מפגישות הפרויקט, חוסר רצון להקצות משאבים נחוצים או גישה פסיבית-אגרסיבית לקבלת החלטות. יתרה מכך, חברי הצוות עלולים להפגין חוסר עניין או ספקנות לגבי מטרות הפרויקט, ומועדים עלולים להחמיץ ללא מאמץ יזום לתקן את המצב. סממנים אופייניים למשבר מחוייבות הינם מנהל המכירות או מוביל העסקה נעלם מהשטח עם תחילת הפרויקט, אין מנהל לקוח, מנהל הפרויקט לא זמין, הלקוח או הספק מבצעים מהלכים חד צדדיים (התקדמות במעמד צד אחד), מנהלת הפרויקט לא מתכנסת, אין ועדות היגוי, שאילתות לספק נענות בתשובות בסגנון "נבדוק ונחזור עם תשובה אחרי החגים", תמסורת "פינגפונג" בין הצדדים, ותחושה כללית ש"אין בעל-הבית" לפרויקט איש הישר בעיניו יעשה. המלצות: הכרה בסימנים אלו לבעיות מחויבות חיונית להתערבות בזמן. מנהלי פרויקטים צריכים לעקוב מקרוב אחר רמות ההשתתפות, להעריך את הקצאת המשאבים ולתקשר בגלוי עם מחזיקי העניין כדי לאמוד את רמת ההתלהבות והמעורבות שלהם. מפגשי משוב רגילים יכולים לחשוף חששות או הסתייגויות. פתרונות אפשריים: זיהיתם משבר מחוייבות, נסו להציע מתווה "חזרה למחוייבות" והובילו את הצדדים אליו. כדי לבנות מחדש מחויבות ולהבטיח את הצלחת הפרויקט, גישה פרואקטיבית היא חיונית. מובילי פרויקט צריכים להשתתף בדיונים אחד על אחד כדי לטפל בחששות ולהתאים את בעלי העניין עם מטרות הפרויקט. חיוני לתקשר את המשמעות והיתרונות של הפרויקט, תוך שימת דגש על הערך שהוא מביא לכל צד המעורב. בנוסף, יצירת תפקידים ואחריות ברורים, הצבת אבני דרך ברות השגה וטיפוח סביבה תומכת שיתופית יכולים להמריץ מחדש את המחויבות.
לסיכום
לא צריך להיות אנשי הייטק או מפתחי תוכנה מיומנים. היכרות עם עולם התוכן, שילוב של הגיון בריא יחד עם למידה והקשבה הם הכלים הנדרשים למגשר בבואו לגשר אירוע הנוגע בהיבטים של פרויקטי טכנולוגיה ואינטגרציה. קחו בחשבון שגם מגשרים מיומנים מוצאים עצמם לעיתים מול סיטואציות גישוריות מורכבות בזירה זו, הנובעות בעיקר מחוסר היכרות עם עולם התוכן, הז'רגון המקצועי, מבנה השוק, האינטריגות והפוליטיקות הפנים חברתיות והפנים ענפיות ומתקשים לקדם את הסכסוך לפתרון. אם נתקלתם באירוע מורכב, אל תהססו ושלבו יועץ מומחה בתחום בתהליך. מגשרים רבים משלבים בתהליך יועצים מומחים בתחום על מנת שילוו ויסייעו מתוך היכרותם עם עולם התוכן.
והכי חשוב, אסור לשכוח: טכנולוגיה והייטק – זה בסופו של דבר אנשים.
בהצלחה.
________
________
גדי רחלזון, יזם עסקי עם ניסיון של למעלה מ-25 שנה בליווי חברות וארגונים בתהליכי צמיחה עיסקית המשלבים טכנולוגיה ואנשים. בעל ניסיון רב בתחום הטכנולוגיה והמיחשוב הארגוני, וכן בגישור עסקי לפתרון קונפליקטים. שימש בתפקידים בכירים בחברות הייטק מובילות כגון, סמנכ"ל ב-SAP העולמית, מנהל בכיר בחברות נס טכנולוגיות, קונסיסט, אדוונטק ועוד. הקים וניהל בישראל נציגויות של מעל 40 חברות תוכנה בינלאומיות. ליווה עשרות חברות בתהליכי צמיחה והתרחבות עסקית תוך שילוב מוצלח של טכנולוגיה, אנשים וידע. כיום מנכ"ל Incrementum Business Devopment המלווה תהליכי צמיחה בחברות טכנולוגיה וארגונים באמצעות בניית שיתופי פעולה טכנולוגיים ישראליים ובינלאומיים. בוגר מכללת שנקר (תע"ונ), קורס דירקטורים של המכללה למנהל, ותוכנית גישור עיסקי בגומא-גבים. בוגר תוכנית לימודי ניהול בכיר בלהב – אוניברסיטת תל אביב.