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

קוד פתוח כנייר הלקמוס

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

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

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

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

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

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

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

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

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

מי צריך מנמ"ר

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

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

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

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

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

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

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

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

עצור סיסמה!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ווב X ופערים דיגיטליים

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

טעיתי. ליאור הנר כבר הגיע לווב 5, והגלוב כבר הגיע לווב 7.

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

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

לענין זה, ראו את הדיון בין אנדרו מקפי לטום דוונפורט על Enterprise 2.0, וכיצד ניתן לנהל דיון ענייני ללא הרבה רוח (2.0)…