תגית: zimbra

terms
service

פגישה, חצי פגישה….

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

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

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

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

blog

לא אוהב Outlook

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

Has not the Jewish people suffered enough

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

Outlook הוא הפרה החולבת של מיקרוסופט. היות והוא היה "חינם", כחלק מחבילת ה-Office, הוא הצליח להוציא מהשוק תכנות דואר וניהול מידע אישי משובחות ממנו, שנמכרו או הופצו בתכנות עצמאיות – Ecco, Act, Eudora, zMail ואחרים. יתר על כן, על מנת לנצל את מלוא היכולות שלו, היה צורך בשרת Exchange שמצדו חייב מערכת הפעלה Windows. גרסאות אחרונות של Exchange מחייבות גם שימוש בשרותי Active Directory.

לכאורה, מאפשר Outlook שימוש במקשרים גם לסביבות אחרות (Lotus Notes, Novel GroupWize, Zimbra ו-Scalix למשל). מקשרים אלו רק מוסיפים לתקורה המנהלתית וחוסר היציבות של Outlook, בין השאר משום ש-Outlook נבנה לשימוש בממשק תכנה בשם MAPI, בעוד שכל כלי אחר פעל על ידי פרוטוקולים פתוחים כמו IMAP, או ממשקי תכנה כלליים יותר כמו DDE או OLE. לא בכדי יצירת רשימות תפוצה לדואר מתוך רשימת הנמענים של Outlook ל-Word היא תהליך לאנשים עתירי זמן וסבלנות.

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

אני מוצא את הנטיה לראות ב-Outlook כאבר הבוחן למנהלי המידע האישיים כעצובה. Evolution ו-Kontact, מעולם הלינוקס, עושים מאמצים אדירים להדמות ל-Outlook מבחינת ממשק המשתמש והיכולות. מבט חטוף ב-Zimbra או eGroupware מראה מה שרת שיתוף יכול לעשות. Yahoo, Plaxo ו-Google Apps מאפשרים זאת גם ללא השקעה תשתיתית.

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

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

מדוע, אם כן לא להשתמש ב-Ecco? חברת NetManage, שרכשה את הזכויות לתכנה, החליטה להפסיק לפתח אותה. למרות שהתכנה ניתנת להורדה ללא תשלום, קשה להצדיק את השימוש בה. היות והופסק הפיתוח של התכנה היא איננה מאפשרת שימוש בכלים ויכולות חדשים כמו vCard ו-vCal, שיתוף דרך WebDAV או סינכרון בפרוטוקולים כמו ActiveSync או SyncML, שפותחו לאחר שהחברה הפסיקה את הפיתוח. אני משתמש בתוכנה אך רק לצרכים פנימיים, והיא עדיין עובדת (אפילו על Windows XP או Wine).

Ecco היא הראיה כי תיוג מידע היה קיים עוד לפני ימי ה-Web 2.0 העליזים, וממשק ה-Explorer אינו חזות הכל.

 

participate
research

רזוננס קוגינטיבי

כבר נאמר, תן לאדם פטיש וגו'. ג'ון טימר ב-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?")

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

forum