הטוב הרע והמכוער...

(תובנות מיישומי אורקל)

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

"הטוב" - בתור אופטימיסט, אני מתחיל בטיפים באזור של "הטוב"...

1.   יישום Oracle HR

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

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

·         המודול השני שהוסיף ערך מוסף משמעותי למש"א הוא מודול הגיוס החיצוני, החברה שלנו עובדת עם הרבה סוכנויות גיוס ולפחות 50% מהמועמדים מגיעים ממקורות גיוס חיצוניים, במצב זה מנהלות הגיוס עסקו הרבה מזמנם בהקלדת נתוני המועמדים למערכת במקרה הטוב, או במקרה הגרוע, ניהול תהליך הגיוס מחוץ למערכת עד לשלב מתקדם בו המועמדים הסופיים הוקלדו למערכת. עם יישום מודול iRecruitment חוברו כול סוכנויות הגיוס למערכת ולמעשה מנהלות הגיוס לא צריכות להזין עוד נתונים מועמדים במקום זה הם יכולים להקדיש את זמנן לתהליך הגיוס עצמו. ערך נוסף מתהליך זה היה השקיפות שקיבלו חברות הגיוס על התהליך והסטאטוס של המועמדים, כאשר הקלידו מועמד שכבר קיים המערכת התריעה בפניהם כי מועמד זה כבר נקלט במערכת, כמו כן כאשר התקדם מועמד שכבר הזינו בתהליך ראו חברות ההשמה את סטאטוס המועמד מבלי שהיו צריכים לכתוב או להתקשר למנהל הגיוס. שמעתי על הרבה חברות שפיתחו הרבה קוד בכדי להקים אתר גיוס מועמדים חיצוני באינטרנט, אולי מבחינת התדמית והLook & Feel מערכת כזו היא סקסית יותר אבל מבחינת עלות תועלת קיבלנו יתרון משמעותי.

2.   יישום מערכת רכש Oracle ERP

התובנה לגבי מערכת דרישות הרכש הגיעה אלי דווקא בגלל בעיות תקציב, היינו בעיצומו של CRP במסגרת פרויקט ERP  גדול וגיליתי כי התהליך שנבחר להזנת דרישות רכש למערכת כולל רפרנט אגפי (או מזכירה בלשון אחרת) שתקליד את דרישות הרכש למערכת בשם כל הדורשים באותו אגף. אצלי, שבאופן אישי סולד מתהליך עקום בו אני צריך לבקש ממשהו אחר לעשות בשבילי עבודה במערכת ולבדוק אותו ולתקן אותו וכו' וכו', נדלקו כל נוריות האזהרה של "משהוא עקום קורה כאן", בירור יותר קפדני גילה לי כי הסיבה המרכזית להחלטה הזו הייתה העובדה כי על מנת לתת את מסך דרישות הרכש לכל דורש בארגון עלינו לרכוש רישיונות PO  עבור כולם (כמה אלפי $ למשתמש לפני הנחה), ברור כי השקעה כזו אינה סבירה. טלפון מהיר למנהל המכירות של אורקל פתר לי את הבעיה, לאורקל יש מודול מיוחד לנושא בשם iProcurement , מודול זה מספר פורטל מכירות פנימי עבור הדורשים בארגון ומחירו כמה מאות $ בודדים (לפני הנחה). חווית המשתמש מוכרת מכל אתר קניות באינטרנט כאשר המשתמש מסייר בין חנויות קטלוג המחירים השונות, בוחר את המוצרים או את השירותים אותם הוא רוצה להזמין, מצרף אותם לעגלת הקניות ולבסוף מגיש את ההזמנה. מנוע המוצר עובד מול מנוע התהליכים של אורקל AME  ומאפשר לנו להגדיר תהליך אישור מורכב במאמץ קטן וסיימנו... החיסרון הראשון שנראה לעיין הוא בצורך של הקניינים לנהל את קטלוג הקניות בצורה יעילה וטובה עבור המשתמשים אולם אם החלופה היא הוצאת הזמנות רכש על נייר עם חוסר שקיפות ובהירות לגבי מה מזמינים ואיפה נמצאת ההזמנה שלי אני בוחר באופציה הראשונה.

3.   יישום מערכת Singel Sign On (SSO)

אחד האתגרים הקשים שנתקלנו בהם עם הוספת מערכות לארגון הוא העלות הגדלה במערך התמיכה של המשתמשים במערכות הנ"ל. שתי הנקודות הקרובות מתייחסות לפתרונות בתחום הזה. כמו כל מערכת, גם מערכות אורקל דורשות משתמש וסיסמא לצורך הזדהות ומתן הרשאות מותאמות למשתמש במערכת. במודל העבודה המקובל בהרבה ארגונים לכל משתמש יש שם משתמש וסיסמא עבור כל מערכת, ככול שדרישות אבטחת מידע למורכבות הסיסמא נהיות מסובכות כל ניהול הזהויות של המשתמש נהיה מורכב יותר ויותר. מבחינת עלויות הIT, הראשון שסובל מכך הוא מערך התמיכה שנדרש השכם וערב, להקים משתמשים, לאפס סיסמאות ולעזור למשתמשים להיכנס למערכת. הפתרון שמימשנו לנושא זה עבור מערכות אורקל היה מודול ניהול הזהויות של אורקל ומנגנוני ה SSO של אורקל. אורקל הבינו כי מרבית הארגונים עובדים בצורה כזו או אחרת עם Windows בכלל ועם Active Directory לניהול המשתמשים לכן Oracle Directory יודע להסתנכרן עם ה AD ומנגנון ה SSO מספק כניסה אוטומטית למשתמש ע"ב נתוני ההזדהות שהמשתמש הזין בכניסה הראשונה לWindows שלו. היום כל מה שנדרש לעשות זה ללחוץ פעמיים על הצלמית (Icon) של המערכת והופ אתה בפנים... "החיסרון" היחיד של המנהלים במערכת כזו היא שעכשיו הם לא יכולים לבקש מהמזכירה שלהם לחתום במקומם J

4.   יישום מערכת למידה UPK

אחת ההפתעות היפות שגיליתי ביישום מערכות אורקל היה דווקא בתחום ההטמעה וההדרכה, ההמצאה של אורקל בשם User productivity Kit או בשמו המקוצר UPK ממציאה דרך אחרת לבצע את הדרכות המשתמשים, לכתוב את מסמכי הOnline Help ואפילו לבחון את המשתמשים בידע על המערכת. הרעיון בבסיס המערכת הוא הכנת תרחישים ע"ב המערכת וצילום התהליך, מערכת הUPK יודעת לזהות את טכנולוגיות אורקל השונות ולהקליט את הפעילות על המסך, כך נוצר סרטון אקטיבי דמוי FLASH  אשר מאפשר למשתמש להפעיל את המערכת כאילו היה בסביבה אמיתית ולראות את תגובות המערכת. המוצר תומך ב3 אופני עבודה See It, Try It & Test it, כשמם הם. עם קצת תשומת לב אפשר לקשר את הכלי לF1 של המערכת וכך לקבל Online help למערכת. זה דרך נפלאה לחסוך נייר (לא צריך להדפיס ספרים), דרך נפלאה לבצע את ההדרכות המונחות ללא צורך בסביבה נפרדת שנופלת ועולה כל הזמן, דרך נפלאה להכשיר עובדים חדשים גם אחרי סיום שלב ההכשרות (הרבה יותר פרודאקטיבי מאשר לקרוא שקפים) וכול מתורגמים בסופו של דבר לחסכון בעלויות.

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

1.   Patch managment  

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

2.   אינטגרציה

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

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

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

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

3.   מודל תמחור טכנולוגיות

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


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

"המכוער" – ועל המכוער נוותר הפעם...

הדוגמאות שמופיעות בפוסט הזה מרכזות כמה מהתובנות שעלו במהלך היישומים שביצענו ב2010-2011, השנה אנחנו פועלים בתחומים נוספים באזור הERP והCRM ואני משוכנע כי יגיעו תובנות חדשות... נשתמע J

"הוא לא סתם ארכיטקט הוא באמת עוזר"

(על תפקיד הCTO  בארגון)

לתפקיד הChief Technology Officer  בארגון יש הרבה שמות, לפעמים מוגדר תפקיד "רשמי" שכזה בשם CTO, לפעמים קוראים לזה מנהל אגף/מחלקה ארכיטקטורה אבל בהרבה מובנים כל התפקידים האלה מתמקדים באותה עשייה. אם בוחנים מלמעלה את תפקידי משרד ה CTO נראה כי הוא מורכב משלושה תחומי פעילות – ארכיטקטורת מערכות מידע, תוכנית מחשוב רב שנתית, וחדשנות.  

ארכיטקטורה פרגמטית...

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

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

תוכנית מחשוב רב-שנתית...

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

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

"חדשנות או למות"...

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