yehuda parnes
16 אוק 2020
עודכן ב: לפני 5 ימים
נגדיר Shadow IT: כפתרון טכנולוגי לבעיה עסקית בארגון, אשר במצב תקין היה מובל ומנוהל על ידי המחלקה הטכנולוגית הייעודית בארגון לפתרונות מסוג זה (בד"כ מערכות מידע), אולם בפועל, הפתרון מובל ומנוהל על ידי גורמים אחרים.
הגדרה נפוצה אחרת תהיה "אי מידע". אי - מאחר ואין לו חיבור למערכות הארגון המרכזיות.
האם יש עם זה בעיה? התשובה תלויה בנשאל. אם שואלים את הגורם המוביל את הפתרון הזה, הרי שהוא יציג זאת בד"כ באור חיובי ביותר ויסביר מדוע הוא הוא זה שמצעיד את הארגון קדימה, פותר בעיה ארגונית משמעותית, כמה כסף חסך וגו'. מאידך, אם שואלים גורם מה IT הארגוני, רק נשמע עד כמה זה רע ונורא.
ואיפה האמת?: כרגיל, לא בוחרת צד באופן מובהק...
בפוסט זה נעלה סיבות בולטות להיווצרות Shadow IT, יתרונות אפשריים, נציין מדוע כיום התופעה שכיחה יותר מבעבר, נספר על הבעיות בShadow IT ולבסוף נציע כמה גישות להתמודדות.
הערה: הפוסט כתוב בלשון זכר מטעמי נוחות של הכותב, אך בוודאי שהוא מכוון לנשים וגברים כאחד.
מערכות מידע כצוואר בקבוק
בעידן הנוכחי, כשהכל מתבסס על הטכנולוגיה, כל ארגון תוסס ומצליח, נשען רבות על גוף ה IT שלו.
אולם, ברוב הארגונים עדיין מנהלים את מערכות המידע כהוצאה. מאחר שגוף זה עובד תחת תקציב, השינויים בכוח האדם שלו הם איטיים, ההתארגנות שלו מבחינת הטכנולוגיה, תמיד מאד איטית כתוצאה ישירה של חשיבה לטווח רחוק. עמידה ברגולציה, חשיבה על אבטחת מידע, אילוצי תקציב ועקומת הלימוד הגבוהה של כל רכיב. כל זה חובר יחד ל"זנב הארוך" של תחזוקת כל המערכות ורכיביהן והתוצאה: כל גוף טכנולוגי המחזיק מערכות ב Production, הוא צוואר בקבוק ארגוני. כך יוצא שהגוף שמחזיק את היכולת והידע לספק פתרונות טכנולוגיים מייצר תור משימות שלרובן הוא לא יגיע...
צריך לשנות זאת? בוודאי, אולם נקדיש לזה פוסט נפרד.
שליטה או יחסי הון-שלטון
אף אחד לא אוהב לעמוד בתור. עובדה.
כל גורם בארגון רוצה לקבל שירות VIP שהרי הוא הוא ליבת הארגון והרי מה שהוא עושה הכי חשוב...
לעיתים במודע ולעיתים לא במודע, כשאתה עומד בתור של מחלקה אחרת...נלקחה ממך השליטה. לרוב בעלי התפקידים זה לא יורד טוב בגרון, ליזמים שביניהם ובמיוחד בעלי האופי המקומי, הסבלנות אינה משאב זמין והמתנה בתור היא סוג הכרזת מלחמה.
חלק מבעלי התפקידים הנדרשים לפתרון טכנולוגי בכדי לקדם את משימתם, רואים בעיכובה ע"י המחלקה הטכנולוגית כאתגר ניהולי הבוחן עד כמה הנהלת הארגון תתמוך (ותקדם את הפתרון על פני צרכים אחרים) ובכך לוחצים את ההנהלה לפינה.
בנוסף, אם וכאשר הפתרון הטכנולוגי מיושם על ידי מחלקה אחרת (הגוף הטכנולוגי) הם שותפים לפתרון, להצלחה ולבעלות על הפתרון. כולם אוהבים את זה?
בארגונים בהן האספירציות האישיות מייצרות הרבה פוליטיקה, אין דבר מתבקש יותר מלעקוף את "המכשול" (הגוף הטכנולוגי). הרי שמאחורי הקלעים יש כאן עניין של שליטה, בעלות על שירות, בעלות על נתונים ומי שעדיין לא משוכנע שידע זה כוח, כנראה שלא בקהל היעד של הפוסט הזה.
כך שגם אם הגוף הטכנולוגי מעמיד אותך בתור, תוך תיאום עם ההנהלה ומסיבות עסקיות טהורות, קשה, אבל ממש קשה לא לראות בזה פגיעה באגו הארגוני.
הענן כפלטפורמה, שלל ספקי ה SaaS, כגורמים מאפשרים ו...דוחפים
עד לשנים האחרונות לייצר פתרון עוקף IT, נדרש ידע טכנולוגי נרחב. זה צמצם את התופעה לעולמות המחשוב האישי. הרבה Excel, Access ודומיהם.
אולם עם הרחבת השימוש בענן, הזמינות הגבוהה של שירותי SaaS הכוללים מגוון אדיר של פתרונות, זמינות של פתרונות פיתוח Low Code, אשר סף הכניסה התיאורטי אינו מצריך ידע עמוק במדעי המחשב (רמת ה Excel תספיק), פותחת "ים" של מעקפים אפשריים.
בד בבד אופי הפתרונות משתנה. במקום מערכת תפעולית ארגונית אחת החולשת על כל המחשוב הארגוני, ישנם פתרונות מתמחים בנישה ספציפית, כך שכל מה שצריך זה רק להתחבר...
מכאן שאם גורם ארגוני צריך פתרון ספציפי, יש לו בעידן הענן אלטרנטיבה ל IT.
הדילמה אם לעמוד בתור של ה IT, או לבחור פתרון מן החוץ הופכת לפשוטה. האם ללכת עם ספק "פרטי" (ללא גוף מתווך), עם בעלות ארגונית על הפתרון, הנתונים והתוצרים? אופציה אפשרית וגם מפתה ונראה ממש כאילו אין סיבה לחשוב פעמיים...
הלחץ לחדשנות
פאן נוסף להתנהגות של גופי הטכנולוגיה הוא ה ROI (ההחזר על ההשקעה). מאחר והגוף הארגוני הוא גוף מנוהל, חי בין הפטיש התקציבי לסדן "צרכי המשתמשים", כשהוא פועל כמצופה הוא תמיד ינסה למקסם כל השקעה ולהאריך את חייה בכדי להוזיל את העלויות לארגון.
בכדי למקסם השקעה טכנולוגית, דרושה מיומנות, מקצוענות, חשיבה טכנית ארוכת טווח וחוט שידרה ארגוני. למי שחסר את אלה, מוצא את עצמו מדלג בין פרויקטים כושלים.
הצד השני של התנהלות, מאד נכונה זו, הוא שהגוף הטכנולוגי, במידה מסוימת "בולם חדשנות".
אבל אופנה, היא אופנה, היא משפיעה על בני אדם, משפיעה על מקבלי החלטות, וכולם רוצים להיות חדשניים, מובילים, ומחוללי שינוי. זו הסיבה שבארגונים שתופסים את עצמם כחדשניים, מקימים מחלקות חדשנות. פעמים רבות, מחלקות אלה נמצאות במסלול התנגשות ישיר עם גופי הטכנולוגיה הקיימים כבר בארגון. והם כבר ידאגו להרבות בפתרונות...
פתרונות יצירתיים
ישנן יוזמות שמשפרות את הארגון.
אם כתוצאה מהתור הארוך של ה IT, ארגון צריך לכבות יוזמות מבורכות, זהו סוף דרכו של הארגון.
אבל לא להתבלבל. לעיתים התור ארוך, מאחר והארגון "מרשה לעצמו" לא לסנן היטב את היוזמות המבורכות מהיוזמות הפחות מבורכות ולהעמיס...
והכי חשוב - המהות.
קורה שהמציאות מזמנת ודורשת תגובה ארגונית למצב בשוק. ממש בלי תיאום עם התוכנית והתקציב של ה IT....
כך למשל הגוף הטכנולוגי הארגוני, קיבל משימה קריטית לארגון. אולם ממש על אותה משבצת זמן, נחתמה עסקה עם שותף אסטרטגי שבכדי לממשה חייבים לפתח פתרון חדש. אבל - אין יותר משאבים.
במציאות כזו, אפשר להוריד את העסקה, אפשר להפסיק את הפיתוח הקריטי, אבל אם מישהו ייזום מעקף ל IT, ההנהלה תתנגד?
ה Time To Market לפתרון עד "התפוצצות" ה SaaS היה מדד שכולו IT. כיום לאו דווקא. ארגון יכול להרים קולאג' של פתרונות SaaS עובדים ולפעמים טוב יותר ממה שהארגון היה עושה בעצמו.
ולכן לעיתים המהות מחייבת פתרון עוקף IT. האם זה אידיאלי? ממש לא ונסביר על כך בהמשך. אבל כמו בכל ההחלטות הניהוליות, לא לפסול מעקפים כשחייבים(!). תשאלו כל קרדיולוג...
ארגון נקרא "ארגון" מאחר והוא גוף המתארגן למטרה משותפת. סביב אותה מטרה נבחר צוות אנושי ולאותו צוות ניתנו כלים. מטרת הארגון הוא לעבוד יחד לכיוון אותה מטרה. אולם אם חלקים שונים בארגון ימשכו לכיוונים שונים לא תושג המטרה.
היעדר תובנות ארגוניות כתוצאה ממאגר מידע נפרד ולא מחובר.
אם אגף בארגון יאסוף וינהל מידע ארגוני בנפרד ממערכות המידע הארגוניות האחרות, הרי שהארגון לא יוכל להפיק את התובנות הנדרשות מהשילוב. וככה קורה שבארגון יש "אמת ארגונית" שונה בין מחלקה למחלקה.
כך קורה שפרטי הלקוחות אינם מטוייבים (כפילות נתונים, היעדר נתונים חיוניים, נתונים שלא עברו את חוקי הארגון).
דוגמה 1: לקוח שחייב כסף לארגון בעבור שירות שקיבל ולא שילם עליו, יכול לקבל שירות חדש ללא התחשבות בחובו.
דוגמה 2: במערכת ה CRM הארגונית מחייבים הקלדת ת.ז. (כנתון שנבדק) אולם במערכת עוקפת, לא חשבו על הצורך ובכך, איפשרו הקמת אותו לקוח מספר פעמים במערכות החברה. זה יכול להוות בסיס לחיוב של הלקוח הלא נכון, שירות למוצר הלא נכון וכיוצ'.
מערכות השדרה המרכזית של כל ארגון מתפתחות בתהליך אבולוציוני, יחד עם הארגון. עם הגידול בכמות הלקוחות, עם שיפור בתהליכי השירות, עם ייעול תהליכי המכירה ועם העצמות התובנות הארגוניות (BI) מה Data שנאסף, גם המערכות מתפתחות ומאמצות את התהליכים הנכונים, את נתונים הנכונים, מיישמות את חוקי הארגון על הנתונים והתהליכים ונמצאות בתהליך שיפור מתמיד.
מורכבות התהליכים וכמות החוקים גדלה עם הזמן ומהווה חלק מהסיבה ל Time to market ארוך של הגוף טכנולוגי.
במערכת שתעקוף את המערכות המרכזיות יישמרו אותם תהליכים? אותם חוקים? סביר להניח שרק חלקם או בכלל לא. כאן צומחים השורשים של הבעיות שמאוחר יותר קשה מאד לפתור. ויש להן מחיר מול הלקוחות, מחיר מול ה EcoSystem ותקורות גבוהות.
גם אם ננסה לחבר את איי המידע והמערכות הארגוניות, האם החיבור הוא קל? לעיתים נגלה שפיתוח "מהתחלה" של הרכיב, שחסרונו יצר את הצורך באי המידע קל יותר מלחבר. זה נובע מהשינויים בין הטכנולוגיות השונות, הגופים התומכים, תחזוקה של נתונים כפולים ועוד.
זילות בסוגיות אבטחת מידע (של הארגון, של הלקוחות ושל השותפים העסקיים ושל חובות רגולטוריות).
ארגון צריך לעמוד ברגולציה. כמעט כל ארגון המאחסן מאגר לקוחות, חייב לרשום מאגר מידע. רישום כזה מביא איתו רגולציה מינימלית של חוק הגנת הפרטיות (יש לא מעט עבודה בכדי לעמוד בחוק). כמו כן לכל ארגון יש שיתופי פעולה שבחלקם כוללים הסכמים הכוללים חוקים מסוימים על הנתונים הנאגרים בחברה (למשל ארגון הנותן שירות לארגון אחר, לא יכול לעשות בנתוני הלקוח של הארגון לו הוא נותן שירות, כבשלו).
בנוסף לכל אלה, בכל ארגון יש מאמץ לשמור על נתוני הלקוחות שלו, על המוניטין שלו ועל המשכיות העסק. זו השקעה גדולה.
כאשר עוקפים את ה IT ומשתמשים בפתרון חיצוני, מורכב יותר לאכוף אותה רגולציה. מסיבה פשוטה: ה IT, הגוף שאמון על הניהול והשמירה של המאגרים, לא יודע - כי עקפו אותו. והצד השני לא יודע על מה הוא צריך לשמור. וגם אם היה יודע, הקסם הטמון ב"מים גנובים" פג.
תחזוקה
העמדת פתרון טכנולוגי חדש, הוא אתגר יפה, בדרך כלל יש המון וייב חיובי מסביב והמון רצון טוב. אולם לתחזק את אותו פתרון שנים קדימה, זה כבר לא מגניב. כלומר, נניח שעקפת את הגוף הטכנולוגי ויצרת פתרון. הפתרון הצליח והוא עובד. כעת:
לוודא שכל השינויים שהארגון עובר, חלים גם על ההריונות שמחוץ לרחם, זה מתיש.
להתמודד עם תקלות, לא נעים.
לנהל תור בקשות לשיוניים עבור המשתמשים - תקורה מיותרת.
לחיות את עולם הגיבויים, השיחזורים המלאים או החלקיים - לא מרגש.
לעצור את המשתמשים בכל שידרוג ולהסביר להם מה השתנה בכל פעם - קצת משעמם.
למקסם את ההחזר על ההשקעה (ה ROI) זה ממש לא באג'נדה של מי שבנה את המעקף כתוצאה מאספירציות אישיות.
לוודא עמידה ברגולציה אליה מחוייב הארגון ולהכיל כללי אבטחת המידע - זה לא חדשני.
הרי כל העונשים האלה הם מנת חלקם של הגופים הטכנולוגיים ועשינו את הכל בכדי לעקוף אותם, לא?
אגב, יצרתם פתרון ארגוני, שלא סובל מהנושאים הללו - אל דאגה, כי כנראה מלבדכם, אף אחד לא משתמש.
אורך החיים של פתרונות עוקפים הוא קצר.
כפי שלמדנו בפסקאות הקודמות, לפיצול מאגרי המידע, לפיצול תהליכים, לפערים באבטחה ולכשל בתחזוקה יש השפעה על אורך חיי הפתרונות הנולדים וחיים מחוץ לרחם.
פתרונות אלה, שלעיתים מתחילים בקול תרועה גדולה (כתוצאה מעקיפת התור של ה IT ו"למרות" מחאות ה IT), בחלוף פרק הזמן המינימלי לשדרוג הראשון, לביקורת אבטחה הראשונה, לרה-ארגון ה BI הארגוני (וכד') מורידים נפח, מורידים התלהבות וציפיות ואט אט מחפשים לגיטימציה ארגונית דווקא בצל ה IT.
שכן אם אורך החיים של פתרון Shadow מתארך – נוצרת יחידה טכנולוגית מקבילה ל IT ונבנים עליה בדיוק אותם אילוצים כשל ה IT, מהתור הארוך ועד למגבלת התקציב. ואז נשאלת השאלה – מה הואילו חכמים בתקנתם? אם במקום לפתור את צוואר הבקבוק, פשוט הוספנו עוד אחד והכפלנו את התקורות והתקציב?
לכן: לרוב, פתרונות ה Shadow IT סופם להיאסף אל ה IT או להיעלם אל תהומות הנשיה.
ידוע שהיחס בין כמות המערכות המשרתות את הארגון לעלות הבעלות הוא נוטה לאקספוננציאלי. זה נובע מאחר שהיכרות עם כל מערכת דורשת התמחות. היכרות עם מימוש מערכת בארגון דורשת חידוד של אותה התמחות וריבוי מערכות משמעו ניהול ריבוי צוותים המתמחים באותן מערכות. זה מסביר את היחס הישר/לינארי בין ריבוי המערכות לTCO. אולם נסיון החיבור בין המערכות, והנסיון לשמור תמונה ארגונית נכונה בכל מערכת (כפילות נתונים או ממשקים מורכבים וזמן תגובה בעייתי ויקר) בתוספת חיבור לפתרונות הרוחביים שכבר קיימים בארגון (ניהול זהויות, אבטחת מידע, SSO, בסיסי נתונים, BI, AI, אוטומציה עסקית, BPM וכיוצ') גורמים להמון עבודה בכל אחד מהפתרנות הלוויניים ומכאן - עלות הבעלות מתפוצצת. מנמ"ר שמבין את החשבון הזה יפעל באופן אקטיבי "לייבש" איי מידע ולהשאיר בצללים כל Shadow IT.
דיקטטורה
כמובן שכאשר יש תיאום מלא בין ה 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 – outer JOIN:
לא ניתן להשתלט על מי הגשמים. הם יורדים מתי שהם רוצים, כמה שהם רוצים ואיפה שהם רוצים. אבל לגמרי אפשר לתעל אותם. כלומר להכין רשת תעלות, כך שלמי הגשמים יהיה "נוח" לזרום לאן שאנחנו רוצים.
אפשר להשליך זאת על ההתמודדות עם ה Shadow IT ולתת השראה לפתרונות אפשריים.
למשל, כאשר ה IT מוצף בדרישות למידע תפעולי וניהולי (עולמות ה BI וה Reporting) אנחנו יודעים לספק פלטפורמה של Self Service. בפלטפורמה כזו ה IT מכין סביבות עבודה הכוללות את כל הנתונים שהמשתמשים יכולים לרצות ומאפשרים הפקת דוחות קלה, באופן עצמאי.
על אותו רעיון, כאשר ה IT מוצף בדרישות לפיתוח, יש פתרון. נוצרה קטגוריה שלמה חדשה של כלים/פלטפורמות לפיתוח מהיר – Low Code.
הפלטפורמות אינן אחידות ביכולות, בתהליכי העבודה וגם לא בקהל היעד שלהן. אולם חלקן מקדמות מאד את תפיסת ה Self-Service. פיתוח שיבוצע על ידי מפתחים הנקראים Citizen Developer. שכאמור בשמם, הם אינם מקצועני IT, כנראה שלא הוסמכו במדעי המחשב, אבל הם טכנולוגיים דיים בכדי לפתח פתרון מקומי קטן.
את השאר מספקות הפלטפורמות, בתיעול והכוונה של ה IT. רובן שוכנות ענן, בעלות אפשרויות פיתוח ללא קוד אלא באמצעות כלים גרפיים.
בהינתן כלים כאלה, הארגון יכול להכין מראש את מה שנדרש בכדי לתעל את הפתרונות לאזור הבנוי לכך. מעין "Sand Box" ובכך למשתמשים ישנה עצמאות המאפשרת "מעקף" שימנע את ההמתנה בתור של ה IT. מן הסתם כך תשתפר הפרודקטיביות, ועימה את התחרותיות של הארגון, מבלי לפגוע באבטחת המידע, בחוקי החברה תוך מזעור הנזקים של הכפלת תהליכים.
פתרון טכנולוגי קטן שנבנה בפלטפורמה כזו, נבחן. אם הוא הולך בדרך כל ה Shadow IT, הנזק צומצם. אם הוא גדל, הוא יגדל לתוך מערכות השדרה המרכזית בארגון באופן קל וטבעי ובכך גם צומצם הנזק האפשרי שלה ה Shadow.
כאשר מבינים את הסיבות ליצירת Shadow IT, ארגון יכול להיערך לכך נכון.
לא תמיד אפשר למנוע את היווצרות הפתרונות שאינם תחת ה IT הארגוני, אולם אפשר לצמצם את הצורך למקומות שבאמת חייבים וגם שם, כיום ישנן פלטפורמות המאפשרות לתעל פתרונות אלה באופן שבסוף – יאספו אל הזרם המרכזי של הפתרונות בארגון. זאת יחד עם שינוי תפיסת ה IT וייעולו, יקטינו את התופעה והכותרת תהפוך מ Shadow" IT" ל"יזמות בתוך הארגון".
בקצרה: אם מחד נשפר את הפרודקטיביות של ה IT ונמקם/נשלב אותו נכון יותר בארגון ומאידך נכין את המתודולוגיה והכלים, בארגון שלנו, לתעל את הצרכים החריגים, הרי שנצליח לצמצם מאד(!) את התופעה יחד עם שדרוג יכולות הארגון.