Shadow IT - כיצד מתמודדים?

עודכן ב: יול 17


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


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

ואיפה האמת?: כרגיל, לא בוחרת צד באופן מובהק...

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

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

1. כיצד יכול להיווצר Shadow IT?

מערכות מידע כצוואר בקבוק

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

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

שליטה או יחסי הון-שלטון

אף אחד לא אוהב לעמוד בתור. עובדה.

כל גורם בארגון רוצה לקבל שירות VIP שהרי הוא הוא ליבת הארגון והרי מה שהוא עושה הכי חשוב...

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

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

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

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

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

הענן כפלטפורמה, שלל ספקי ה SaaS, כגורמים מאפשרים ו..דוחפים

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

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

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

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

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

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

הלחץ לחדשנות

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

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

הצד השני של התנהלות, מאד נכונה זו, הוא שהגוף הטכנולוגי, במידה מסוימת "בולם חדשנות".

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

יצירתיות של עובדים

ישנן יוזמות שמשפרות את הארגון.

אם כתוצאה מהתור הארוך ארגון יאלץ לכבות יוזמות מבורכות, זהו סוף דרכו של הארגון.

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

והכי חשוב - המהות.

קורה שהמציאות מזמנת ודורשת תגובה ארגונית למצב בשוק. ממש בלי תיאום עם התוכנית והתקציב של ה IT....

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

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

ה Time To Market לפתרון עד "התפוצצות" ה SaaS היה מדד שכולו IT. כיום לאו דווקא. ארגון יכול להרים קולאג' של פתרונות SaaS עובדים ולפעמים טוב יותר ממה שהארגון היה עושה בעצמו.

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

2. מה הבעיה עם Shadow IT?

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

היעדר תובנות ארגוניות כתוצאה ממאגר מידע נפרד ולא מחובר.

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

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

דוגמה 1: לקוח שחייב כסף לארגון בעבור שירות שקיבל ולא שילם עליו, יכול לקבל שירות חדש ללא התחשבות בחובו.

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

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

תהליכים ארגוניים וחוקי הארגון

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

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

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

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

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

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

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

תחזוקה

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

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

להתמודד עם תקלות, לא נעים.

לחיות את עולם הגיבויים, השיחזורים המלאים או החלקיים - לא מרגש.

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

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

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

אורך החיים של פתרונות Shadow

אורך החיים של פתרונות עוקפים הוא קצר.

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

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

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

לכן: לרוב, פתרונות ה Shadow סופם להיאסף אל ה IT או להיות מוחלפים בפתרון ארגוני.

3. מספר דרכים להתמודדות

דיקטטורה

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

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

שינוי בתפיסת ה IT

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

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

לא יותר יחידת סמך, אלא זרוע ביצועית של יעדי הארגון.

רה-ארגון ה IT: מיקבול תוצרת, הטמעת מתודולוגיה מתאימה, חיבור הדוק יותר לשטח

גם אם לגוף הטכנולוגי אין כל מגבלת תקציב, ה "Time to Market" מיידי? ממש לא. גם אותו צריך לקדם ולייעל. להלן 3 נקודות שאני מוצא שהן רלוונטיות בלא מעט יחידות טכנולוגיות:

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

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

  • אחת הסיבות לתופעת ה Shadow IT הוא היעדר הקשר בין אגף ה IT לחלק מהאגפים והמשתמשים האחרים. בהיעדר הקשר הרציף גם תאבד תחושת השליטה והשותפות של משתמשים לפתרונות הטכנולוגיים להם הם זקוקים וההפך, גם המודעות של ה IT לצורכי המשתמשים תאבד. מומלץ לשפר את הקשר בדמות תפקיד BRM-Business Relation Manager, שהוא משקף ל IT צרכי אגף מסוים יחד עם תיאום ציפיות בכיוון ההפוך. BRM מכיר את העסק ברמה גבוהה. תחת התפקיד הזה ניתן לנהל נכון את צרכי המשתמשים ולהביא אותם נכון יותר ליחידה הטכנולוגית. בכך ניתן יהיה לקצר את התור "להוציא הרבה אויר" מפתרונות גראנדיוזים ולמקד פתרון בצורך אמיתי. ולאפשר ל IT לתכנן את "הכלי הבא" שיענה לצרכים עוד לפני שהפכו לבעיה כואבת.

תיעול הפתרונות או If you can’t beat them – JOIN:

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

אפשר להשליך זאת על ההתמודדות עם ה Shadow IT ולתת השראה לפתרונות אפשריים.

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

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

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

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

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

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

4. סיכום

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

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

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