הצלחת ה-IT בשיפור הזמן להשגת הערך

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

המונח השיווקי TTM (ר"ת Time To Market) – הזמן הנדרש להשקת מוצר או שירות חדש בשוק, מוכר היטב. באופן דומה TTV (ר"ת Time To Value) – הזמן הנדרש להשגת הערך הוא מונח עסקי המתאר את פרק הזמן שבין הביקוש להשגת ערך מסוים לבין האספקה הראשונה שלו.

"יש לך רק הזדמנות אחת לעשות רושם ראשוני". אם רוצים להגדיל את הסבירות להצלחה עבור יישום והטמעה של מוצר או שירות IT, צריכים לעשות רושם ראשון בעוד הלקוח עדיין מתלהב מהחלטת הרכישה שלו. כך ביישום ארגוני, יישומים B2C ומה שביניהם, למרות המורכבות ומסגרות הזמן השונות לכל אחת מהקטגוריות. בעולם SaaS, המסע שלאחר המכירה לאימוץ הערך יכול להוות make or break עבור החברה.

כדי לעבור למנטליות של TTV, עלינו לשנות את האופן שבו מודדים הצלחה. ב-IT, עדיין משתמשים בערכי פעילות קלאסיים, כמו KPIs ,ROI ואחרים. אך כעת צריכים לחשוב על ערך באותם מדדים כמו לשותפים העסקיים; מכירות, רווחיות ועוד.

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

ה-IT "נמצא בסירה אחת" עם השותפים העסקיים שלו  – ואת הקשר ביניהם מפתחים על ידי דו שיח הדדי מתמיד והקצאת משאבים של IT לפיתוח היחסים בפונקציית BRM (ר"ת Business Relationship Management) המספקת משוב למנמ"ר על הביקושים ושביעות רצון הלקוחות.

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

Salesforce זיהתה מספר דרכים להקטנת ה-TTV המובאות בתמצית להלן:

פיתוח באג'ייל

צוותי IT השתמשו ועדיין משתמשים במודל "Waterfall" לפיתוח, אבל הוא  מוחלף בחברות רבות במודל פיתוח אג'ייל המהווה מתודולוגיה אמיתית ולא רק אופנתית.

מיקוד בארכיטקטורה

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

צוות מוכשר

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

התיעוד

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

הימנעות מרכישות הוניות

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

הימנעות מפיתוח שאינו אסטרטגי

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

פישוט האינטגרציה והשילוב

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

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

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

לחשוב בגדול, להתחיל בקטן, ולזוז מהר.