מחשוב עננים (cloud computing), אינו חדש, אך תופס תאוצה (והייפ). והסיבות אינן רק טכנולוגיות, אלא יותר עסקיות וכלכליות. המחשבה המנחה: טכנולוגיה הופכת למוצר צריכה, והגיוני יותר לרכוש אותה כמו כל מוצר צריכה או שרות אחר, יתר על כן, חברות אינן רואות את מערכות המידע כמעניקות ערך מוסף לארגון.
מאידך, ישנה רתיעה מהוצאת מערכות המידע מהארגון. לעיתים מתוך חשדנות במוטיבציות של הספקים, לעיתים מתוך דאגה לרמת אבטחת המידע ולעיתים מתוך דאגה על ביצועים.
יתר על כן, תמחור מחשוב העננים עדיין לא מאפשר השוואה מובהקת מספיק לבחון את יתרונותיה או חסרונותיה הכלכליים מול ה-Data center הקלסי.
המודל המתבקש לעתיד הנראה לעין, הוא לפיכך מודל היברידי. והנה דוגמה לכך – מערכת דואר של ארגון בינוני, המפוזר בין מספר אתרים, ואולי גם מספר מדינות.
במודל הקלסי, שרת הדואר הארגוני נמצא במטה הארגון. הסניפים המרוחקים מתחברים דרך קוי תקשורת יעודיים או בתקשורת VPN למרכז. אם הסניף המרוחק גדול במיוחד, יתכן כי יהיה בו שרת משני לטובת המשתמשים של אותו סניף. עובדים מחוץ לאתרי החברה מתחברים באמצעות פורטל Web, קישורי VPN או ניתוב דואר למחשבי כף יד או טלפונים חכמים.
כעת נבחן מספר חלופות של מחשוב עננים:

• שרות יעודי: במקרה של דואר אלקטרוני, ספקי אינטרנט נתנו שרות זה כבר שנים, וספקי דואר יעודיים (Hotmail למשל) התחרו ומתחרים בהם. כיום שרותים אלו כמעט פסו מן העולם. ספקיות האינטרנט מציעות תיבות דואר זעומות ובסיסיות, וספקי הדואר נבלעו בפורטלים (Hotmail הוא חלק ממערכת Microsoft Live) או נעלמו.
• שרותים מאורחים (Co-hosted): כאן אפשרו ספקיות אינטרנט ללקוחות להחזיק שרת דואר יעודי באתר הספק, כאשר נטל האחזקה והשרות של החומרה והתוכנה מתחלקים בצורות שונות בין הספק ללקוח. מודל זה כמעט זהה למודל הקלסי, למעט מיקומם הפיזי של השרתים, בעיקר בעסקים קטנים ובינונים, בהם אין יחידת IT מובנית.
• ענן, או grid: הספק מעניק את תשתית החומרה, התקשורת (ולעיתים גם את מערכת ההפעלה), עליה מתקין הלקוח את מערכת הדואר. דוגמא לכך הוא ה"ענן האלסטי" של אמזון.
• תוכנה כשרות, או SaaS: כאן מקבל הלקוח סביבת עבודה השייכת במלואה לספק ובאחריותו. הדוגמה המובהקת היא שרותי Google Apps, אך גם ספק תכנה קלסי כמו מיקרוסופט מציעה את שרת הדואר שלה כשרות. לעיתים השרות קיים כחלק מסביבת שרותים נוספת, כמו במקרה של השרות לעסקים קטנים של יאהו.

המודלים של ענן או שרות הם המעניינים ביותר, היות ואלו הם המעניקים את הערך המוסף לעסק. במקרה שלנו (דואר אלקטרוני), ניתן לראות את היתרונות הבאים:

• חומרה: אין צורך בחומרה יעודית לשרתים בתוך הארגון.
• עומס תקשורת: ירידה בעומס על התקשורת מחוץ לאתר המרכזי של החברה (מאתרי משנה או ממשתמשים העובדים מבחוץ).
• מורכבות תקשרות: אין צורך בניהול מערכות  VPN

עם זאת, יש להביא בחשבון מגבלות וסיכונים:

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

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

מספר נקודות שיש לבחון מול כל ספק.

• תנאי השרות והזמינות, הידועים בראשי התבות SLA או Service Level Agreement: אלו קובעים את קוי הבסיס לזמינות השרות ומה זמן התגובה לתקלה והקנס לאי עמידה בו.
• יבוא: מה הכלים והאפשרויות של יבוא מידע (המקרה זה דואר קיים) למערכת החדשה
• יצוא: לא פחות חשוב – מה האפשרויות של יצוא המידע במצב של סיום השרות.
• שימור ואיחזור מידע: מה הכלים לשימור מידע, גיבויו (האם ניתן למשל לגבות את הדואר למערכת מקומית?)
• ממשקים: האם קיימים ממשקים למערכות בהם משתמשים בחברה (למשל טלפונים חכמים)

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

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

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

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

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

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

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

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

1. או מה שעלול להראות כמשקל עודף בעיני בעלי המניות

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

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

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

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

בעקבות מאמר של גל מור, החלטתי לבחון את Geni, אתר לבנית עצי משפחה¹.

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

לאחר שבעץ המשפחתי ישנו כבר כ-550 נפשות, מהן כ-40 חברים יש לי תשובה חלקית.

אנו נותנים למחלקות מערכות המידע להחליט היות:

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

התשובה, במשפט אחד היא: מי שמקבל החלטה, הופך להיות מחלקת מערכת המידע.

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

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

1. אלו החפצים לבחון כלים אלו לעומק צריכים גם להביט ב- My Heritage או ancestry.com
2. למעט סבתי שהביוגרפיה הקצרה שלה הוותה את בסיס הידע לעץ המשפחה
3. בדואר אלקטרוני, דהיינו לא ממקורות מידע המנותקים מהרשת

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

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

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

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

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

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

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

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

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

שימור המידע והידע הוא מטרה טובה. יעד של 50 או 100 שנים הוא יומרני. מאז לימודי התואר הראשון שלי עברתי 3 מערכות הפעלה (ובכל אחת 4 גרסאות לפחות), השתמשתי בשישה או שבעה מעבדי תמלילים, שלושה גליונות אלקטרונים, ארבעה סוגים של מחשב כף יד ולפחות שונה מחשבים אישיים. אני עדיין מסוגל להגיע לטקסטים שלי משנה א', אך המאמץ איננו מינימלי.

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

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

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

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

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

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

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

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

הצעתי להם לחפש בכל תיקיות הדואר היוצא (Sent Items בלע"ז), כל דבר דואר העונה לקריטריונים הבאים:

1. מתחיל ב-RE: RE: RE
2. כולל את הביטוי "ענק!"
3. כולל שניים או יותר סימני קריאה

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

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

כמה לקחים:

• גם אם קיבלתם את הבדיחה או המצגת האולטימטיבית – חשבו פעמיים לפני שאתם מעבירים אותה הלאה. אם החלטת כי היא ראויה, אולי עדיף להתשתמש באחד מאתרי השיתוף, ולשלוח קישור.
• התיחסו לנמענים שלכם בכבוד. אל תלחצו Forward ומיד Send. נקו מהדואר את כל שאריות התכתובות הקודמות ופרסומות אתרי ה-WebMail. נסו לפחות להראות כאילו אכפת לכם מהנמענים.
• הפעילו מעט שיקול דעת לפני שאתם מקישים Ctrl-A על רשימת הכתובות שלכם ושולחים את הדואר לכוווולם.
• האם אני באמת צריך להזכיר לכם כי לא שולחים לכל רשימת התפוצה תחת TO:?
• אם הדואר הוא בתוך הארגון, אל תשלחו את הקובץ. שימו אותו במקום משותף ושילחו קישור.

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

למרבית הצער, לא מעט תוכנות דואר מתעקשות להשתמש ב-Sent Items. במקרה זה, פשוט נקו אותו אחת לשבועיים או שלושה.

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

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

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

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

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

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

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

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

מוסר השכל, כלים שימושים רק אם משתמשים בהם.

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

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

גם זו דרך.

כבר נאמר, תן לאדם פטיש וגו'. ג'ון טימר ב-Ars Techina מפנה למאמר ב-Journal of Consumer Research הטוען כי נעילת לקוח (Lock In) קוגניטיבית היא חזקה לא פחות מנעילה הנובעת מתלות חומרית או עלויות מעבר. כאשר הרגלים נרכשי, המתשמש משוכנע כי הדרך (או הכלי, לענין זה) הוא הטוב ביותר, ולו היה עליו (המשתמש) לפתח כלי או דרך, התוצאה היתה זהה.

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

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

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

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

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

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

לפרוטוקול זה קיים מתחרה בשם IMAP הקיים משנת 1998. בפרוטוקול זה הדואר נשמר ומנוהל על השרת, ותוכנת הדואר משמשת רק ככלי ניהול. שני הפרוטוקולים ניתנים להצפנה על ידי שימוש ב-SSL (קיים משנת 1996).

מדוע, אם כן, ממשיכים לראות שימוש נפוץ כל כך ב-POP3 ועוד בסביבות אירגוניות על ידי אנשים טכניים?

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

קשה להתמודד ישירות עם רזוננס קוגניטיבי. העמדה של טיעונים לוגיים בלבד לשינוי יכולה ליצור התנגדות משני כיוונים עיקיריים:

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

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

• יצירת רזוננס חלופי. הצגת מערכות או שיטות כמובנות מאליהן.  ("קוד פתוח, כולם משתמשים בקוד פתוח: גוגל, יאהו, תע"א, בנק מזרחי…")
• הצגת התחליף כמקור. (התקנת שרת Scalix או Zimbra במקום Exchange).
• הגחכה (פרסומת ישנה של Sun אמרה "Running mission critical applications on NT Server, what do you people do for FUN?")

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