לבנות חדש או לשפץ קיים?

(בהשראת מאבק הורדת מחירי הדיור)

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

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

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

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

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

לבנות חדש...

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

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

אז לשפץ...

מה זאת אומרת לשפץ במערכות מידע? בשבילי לשפץ זה להתחיל לקחת קוביות, קוביות של יכולות פונקציונאליות ותהליכים עסקיים מהמערכות הקיימות ולהחליף אותם במערכות חדשות. תהליך זה יכול להתבצע מבחוץ פנימה – כלומר מהמערכות ההיקפיות (כגון מערכות הכספים, השירות והמכירה) לכיוון מערכות הליבה (מנועי המוצר, Billing וכו') או מבפנים החוצה תלוי במבנה המערכות הקיים והיעדים העסקיים של התוכנית. המתנגדים יקפצו ויגידו כי מהלך כזה מחייב הרבה דו קיום והרבה ממשקים בין החדש לישן וכי במהלך כזה עלולים להיות מספר שלבים שחוזרים על עצמם (Re-work) ואכן כך הדבר אולם היתרונות גוברים על החסרונות. מודל עבודה כזה הוא מודל גמיש יותר, ניתן להתאים את קצב הפעילות של ההחלפה לפי תוכנית שנתית המושפעת מהשינויים העסקיים המשפיעים על החברה, המודל מאפשר לשנות לא רק את קצב הביצוע של התוכנית אלה גם את התכולות וסדר הביצוע כך שאם אחרי שנה נושא חדש נהיה פתאום "בוער" אפשר להתאים את פעילות התוכנית לטפל בנושאים אלו. והחשוב ביותר, המודל הזה מאפשר להתחיל ליהנות מהפירות של המאמץ תוך כדי ביצוע התוכנית. כל תת פרויקט בתוכנית כזו מביא תועלות עסקיות בפני עצמו.

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

שימו לב! דור הY מאחורינו – פוסט מעודכן

לפני שנתיים כמעט פרסמתי פוסט אורח בבלוג של בלינק (http://www.blinkit.co.il/?p=335) בנושא גיוס ועבודה עם דור ה Y, לאחרונה יצא לי לחשוב שוב על הנושא דרך ראיונות עבודה שקיימתי לגיוס עובדים למחלקה שלי ואחרי הרצאות בנושא ששמעתי וחשבתי לפרסם פוסט מעודכן בנושא. אז הנה הוא לפניכם:

גלובס - אחד מכל 5 מנהלי משאבי אנוש: פייסבוק ומסנג'ר בזמן העבודה תורמים לארגון

http://www.globes.co.il/news/article.aspx?did=1000435748&fid=594

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

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

אז אומנם אני חובב הי-טק ומשחק עם כל מני גאדג'טים אבל בתור מי שעבר את גיל ה40 אני בהחלט לא יכול להיקרא דור ה Y. אני מאמין כי If you can’t beat them, Join them, כלומר בואו נלמד איך אפשר למשוך את החברה' האלה אלינו ולמנף את האנרגיות שלהם לטובת העסקים שלנו.

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

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

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

היתרון שבניסיון או המשולש הקדוש

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

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

הניסיון האישי שלי

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

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

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

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

ספק הטכנולוגיה

1. המטרה המרכזית של ספקי הטכנולוגיה היא לעודד את הלקוח ליישם מוצרים ובכך להגדיל את נתח הרישוי שלהם נשמע טריויאלי אולם הבנה של הWhat's in it for me שלהם חשובה ביותר כאשר נכנסים לביצוע פרויקטים. שלב יישום המוצר בחברה הוא שלב הכרחי לרוב ספק הטכנולוגיה ירצה לוודא כי הלקוח יצליח ביישום (כי זה יבטיח את המשכיות הקשר) אולם אם ניתן לבצע את היישום ע"ב אינטגרטורים אחרים זה עדיף.
2. למרבית הטכנולוגיות יש Roadmap, חשוב להבין עם הספק את הכיוון העתידי של הטכנולוגיות האלה ולראות מכך מה קיים היום ומה יהיה מחר. שמעתי הרבה פעמים את המונח Best Practice ואת הציפייה כי "יש שם משהו במרכזי הפיתוח שיודע יותר לגבי פתרון הבעיות של הלקוח", הניסיון שלי לימד אותי כי ספקי הטכנולוגיה יודעים הרבה על הטכנולוגיות שלהם אולם הם לומדים מהלקוחות לגבי אופן השימוש בטכנולוגיות שלהם בסביבה העסקית, אל תצפה מספק הטכנולוגיה לומר לך מה התהליך העסקי העדיף בשבילך.

אינטגרטורים

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

הלקוח

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

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

בין אסטרטגיה למציאות

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

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

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

בעיית ההחלטות הגדולות

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

The best IT strategy is no IT strategy

במאמר הנ"ל Patrick Gray טוען כי בחברה טוב שתהיה רק אסטרטגיה אחת – אסטרטגית החברה וכל השאר הוא טקטיקה. מוטב שגוף ה IT יתרכז בexecution של המערכות שמקדמות את העסקים ולא בקידום טכנולוגיות כאלה או אחרות. פטריק טוען כי בהחלט יש מקום ואף רצוי לקדם טכנולוגיות כאלה או אחרות שישפרו את מצב הארגון בכך שיורידו את עלויות הIT  אולם תהליך זה אינו הבסיס למסמך אסטרטגית IT.

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

אז למה בלוג?

אז למה בלוג? כי אפשר גם אחרת...

בדצמבר 2007 עזבתי את חברת הסטארט-אפ שבה הייתי סמנכ"ל מוצרים ופיתוח על מנת לבוא לנהל את התוכנית האסטרטגית להחלפת מערכות המידע בחברת Cal. חברת הסטארטאפ ההיא עסקה בתחום של פיתוח מוצרי בדיקות תוכנה בעולם האינטרנט, אולם אין זה הדבר החשוב כאן, המעניין הוא שהחברה הסבה את המוצר שלה לסביבת הקוד הפתוח והצטרפה למהפכה העולמית של שיתוף, שילוב ובניית קהילה של משתמשים שתורמים זמן, ידע ולפעמים גם קוד רק בגלל שזה מעניין אותם ובא להם לעשות את זה. עולם ה Web 2.0 בלוגים, tag, twitter היו הבסיס לעבודה שלנו... ואיך הסיפור הזה קשור אלינו אתם בוודאי שואלים? אז בשבילי, התפיסה של שיתוף, שקיפות ופתיחות הם הבסיס לעבודת ניהול טובה גם אם הם מתרחשים בסטארט-אפ או בארגון פיננסי מוביל כמו חברת Cal.

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

קצת עלי...

אני בן 42, נשוי לדנה ואבא לאורי, גאיה ושגב. אני בוגר תואר ראשון במדעי המחשב וחקר ביצועים ותואר שני במנהל עסקים. עבדתי כ6 שני במיקרוסופט ישראל בליווי של פרויקטים אסטרטגים בארץ, 3 שנים באלביט חיפה בפיתוח מערכת שליטה ובקרה למטוס ללא טייס ובחברת סטארטאפ כסמנכ"ל מוצרים ופיתוח בתחום מוצרי בדיקה באינטרנט. אני מאמין כי ניהול הוא מקצוע בפני עצמו ומנסה ליישם את זה הלכה למעשה בסביבת העבודה שלי. ומי שרוצה ללמוד עלי קצת יותר מוזמן לבקר באינטרנט eranwitkon on twitter, facebook & gmail...

You don't need eyes to see you need VISION (faithless)

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