תגית: ניהול

קטגוריות
כללי

10 צעדים לטרוף סינכרוני

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

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

  1. שועל האש מסנכרן את ספר הכתובות לפלאקסו ((יש להם כלי נוח לזיהוי רשומות כפולות ולשליחת עדכונים))
  2. פלאקסו מסנכרן את ספר הכתובות ויומן הפגישות מול החשבון שלי ב-Yahoo ((חשבון בעל ערך היסטורי בעיקר))
  3. פלאקסו מסנכרן את ספר הכתובות ויומן הפגישות מול החשבון שלי ב-Google
  4. פלאקסו מסנכרן את חשבון LinkedIn שלי
  5. שועל האש מסנכרן את ספר הכתובות ל-Scheduleworld,
  6. תוסף Lightning מסנכרן את יומן הפגישות ל-Scheduleworld
  7. Scheduleworld מסנכן את יומן הפגישות לחשבון הפרטי שלי ב-Google
  8. החשבון הפרטי של ב-Google מסתנכרן מול החשבון ב-Google Apps ((יש בעית API מול חשבונות ב-Google Apps))
  9. טלפון נוקיה E61 מסנכרן את ספר הכתובות ויומן הפגישות מול Scheduleworld
  10. את ספר הכתובות והיומן אני שומר גם כקובץ LDIF ו-iCAL

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

ישנם גם פתרונות חלופיים (או משלימים):

  1. GCalSync לא יציב מספיק לטעמי
  2. שרות Hosted Exchange עם ActiveSync לאלו השבויים בידי Outlook.
  3. להתקין Exchange אצלי ((מה עשיתי רע)).
  4. לקרוא את היומן דרך דפדפן הטלפון ולקבל התרעות על פגישות ב-SMS
  5. להפוך את הארון ולמצוא את יומן הנייר הישן שלי ((חלופה מפתה מאוד בשלב מסויים))
  6. לשמור הכל בראש…

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

קטגוריות
מערכות מידע ניהול

עצור סיסמה!

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

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

  • לאנשים יש יותר סיסמאות מסינפסות ((ואני מתיחס גם לאנשים חכמים)). אין סיכוי שהם יזכרו את כל הסיסמאות שלהם.
  • פורצים אינם משתמשים ב-Brute force נגד סיסמאות, זהו בזבוז זמן ומשאבים. רוגלות והנדסה חברתית הם הכלים להשגת סיסמאות.

התוצאות ידועות:

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

אז מה לעשות? כמה כללי אצבע:

  1. להגביל מראש את יכולות המשתמש במערכת (הרשאות על ספריות, תוכנות או מחשבים).
  2. להשתמש רק בפרוטוקולים מאובטחים (SSL לאתרי אינטרנט, SSH להעברת נתונים).
  3. להסיר מהמערכות כל רכיב שאינו חיוני (סרגלי כלים תמוהים למיניהם על הדפדפן).
  4. לחסום את גישת המשתמש כאשר אין לו צורך בגישה (כאשר עובד עוזב את החברה).
  5. ודאו כי מנגנון ניהול הסיסמאות שלכם בטוח (ראיתי מספיק מנגנונים ניהול סיסמאות מבוססי MS-SQL,שסיסמת ברירת המחדל של מנהל המערכת לא שונתה….)

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

קטגוריות
מערכות מידע דעה

האם כל כך קשה לכתוב תכנה נכון?

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

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

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

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

במקרה של תכנות ישנות ישנם מצבים בהם על מנהל המערכת (היחידי לו אמורות להיות הרשאות גישה מיוחדות) לאפשר קריאה או כתיבה לספריות או קבצים במיקומים לא סטנדרטים. בדרך כלל מדובר בתכנות שנכתבו לסביבות Window 3.X או Windows 95.

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

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

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

ההמלצה שלי היתה: להחזיר את התכנה ולדרוש את הכסף חזרה.

קטגוריות
ניהול

RE: RE: RE – רע! רע! רע!

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

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

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

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

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

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

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

כמה לקחים:

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

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

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

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

קטגוריות
דעה

דילמה טכנולוגית פוליטית

לאחרונה שקלתי ליישם שרת Xandros אצל לקוח. זהו שרת המבוסס על הפצת דביאן לינוקס, הכולל הין השאר שיתוף קבצים למערכות Windows דרך Samba, דואר ושיתוף יומנים מבוסס Scalix (לשעבר HP OpenMail), מערכת גיבוי Bru וממשק ניהול אחיד.

כעת מתפרסם כי Xandros נכנסה לשיתוף פעולה מול Microsoft. זהו חוזה דומה לזה שנחתם מול Novell לא מזמן. שיתופי פעולה אלו מטרידים אותי.

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

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

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

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

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

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