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

419: זה כן לטלפון….

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

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

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

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

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

"ללמד אותם לקח"

כתבה דה-מרקר על תביעה של חברת הראל נגד נס על סך של 100 מיליון שקלים ((ידיעה לא חדשה ממש)) מהווה קדימון למאמר מתלהם של רפאל פוגל. פוגל קורא לתביעה "שלב התבגרות הכרחי שצריכה לעבור תעשיית התוכנה הישראלית" ומסיים:

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

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

לשון אחר: אין חדש תחת השמש.

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

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

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

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

לכל המקרים מכנה משותף: הנכונות לקבל מורכבות של פרויקטים בתחום מערכות מידע ולקבל החלטות קרות ושקולות.

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

מי צריך מנמ"ר

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

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

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

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

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

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

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

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

עצור סיסמה!

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

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

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

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

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

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

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

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

קטגוריות
אינטרנט דעה

קליק קטן, כאן ושם

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

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

כאשר נתקלתי בבעיה להתחבר ב-Internet Explorer 7 ((שועל-אש? הצחקת אותם)) הופנתי למסמך המצורף: change_settings.pdf.

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

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

למה?