קטגוריות
משולחן המובטל משולחן היועץ

הגיג על אחריות אישית

בראיון עבודה לחברת יעוץ הסביר לי המראיין את השקפת עולמו:

אם אני היועץ, אין מצב שבו הפרויקט יכול להכשל

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

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

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

קטגוריות
מערכות מידע משולחן המנמ"ר אינטרנט

סקלביוליות

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

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

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

צחוק בצד, אחד הטיעונים של אנשי ה-IT היא: "תנו לנו משאבים כמו X, ותקבלו שרות כמו X". גוגל, למשל, מתחייבת לזמינות של 99.9% (חודשית). דהיינו 72 שעות כשל, עדיין מהווה עמידה בתנאים. אני מצליח לשמור על 99.4%. אבל זמינות ועמידה בתנאי שרות אינה מעניינית את המשתמש ברגע שבו הוא זקוק לשרות. לא בכדי מיקור החוץ זוכה לכותרות, הן בשרות והן בפיתוח.

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

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

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

קטגוריות
דעה

סיכום שנה?

התחושה המרכזית שלי בשנה זאת היא של ירידת רמת השרות וירידה ברמת האמון.

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

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

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

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

אבל אסיים בנימה אופטימית.

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

שרות טוב שומר על טריות. לידיעת שימור הלקוחות.

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

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

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

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

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

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

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

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

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

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

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

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

מי צריך מנמ"ר

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

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

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

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

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

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

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