רקע
מזה למעלה משני עשורים ברור לקהילת ה IT שפתרון מחשובי אינו מצוי בחבילה אחת או בפלטפורמה אחת. המחשוב המבוזר, הפתרונות הרבים בפלטפורמות השונות וההבנה שצריך למחשב את התהליך העיסקי ולא יחידה ממנו היוו את הבסיס להיווצרות הצורך במערכות מבוססות טכנולוגיה עיסקית.
המצב הכלכלי המשתנה חידד בשנים האחרונות את הצורך של מנהלים ובכירים בארגון כמו גם פועלי הייצור והמשתמשים להבנה וניהול תהליכים בארגון. תהליכים אינם נמדדים רק במורכבותם וביצועיהם אלה גם בתועלת העסקית שבהן, כמה עולה לממשם וכמה עולה לתחזקם. המערכות המרכזיות במרבית הארגונים מעבר לרצפת הייצור הינם מערכות דוגמת כגון ERP, CRM שנדרשות לתת מענה לניהול התהליכים בארגון ולקשרים בין יחידות הארגון פנימה לשותפים עסקיים ולסביבה החיצונית של שותפים ולקוחות המגיעים דרך האינטרנט.
התהליכים עסקיים הינם "ליבת מערכות המידע" של כל ארגון. תהליכים עסקיים משפיעים על ביצועי הארגון, עלויות, רווחים, מערכת היחסים עם לקוחות, שותפים עסקיים ועובדים. תכנון וניהול נכון של תהליכים עסקיים יכול לייעל את האופן בו פועל הארגון, להגדיל את ההכנסות, להקטין את ההוצאות, לשפר את הרווחית ושביעות רצון הלקוחות, השותפים העסקיים והעובדים.
ניהול תהליכים עסקיים מאפשר לנו להתאים את התהליכים ליעדים האסטרטגיים של הארגון.
מערכות לניהול תהליכים (BPM) מבצעות קישור בין אסטרטגיית החברה למשאביה – ידע, מידע עובדים, לקוחות, שותפים, המערכות חושפות את הקשר בין ביצועי החברה במונחים עיסקיים לבין התהליכים הקורים בארגון. לא עוד הקשר רק ל IT ראייה ברורה של הארגון, יכולת שליטה ובקרה על ביצועים עיסקיים סימולציות של תהליכים חדשים או שינוי קיימים ובדיקת השפעתם.
הקשר בין האסטרטגיה העסקית, לתהליכים הארגוניים ולהטמעתה בארגון אינו ברור כלל. החוקרים קפלן ונורטון פיתחו את תפיסת ה Balanced Scorecard שמטרתה הפיכת האסטרטגיה העיסקית לטקטיקה. בספרם The Balanced Scorecard: Translating Strategy into Action מציגים כלים למדידה, "כימות", וקשרים בין יעדים עיסקיים (אסטרטגיה) לתהליכים עיסקיים (טקטיקה). פעולה ראשונית זו בהבנת הארגון הינה קריטית להבנה של איזה תהליך תורם וכמה להשגה של היעדים של הארגון.
מחקרים רבים מציגים מציאות קשה, רק 10% מהארגונים מצליחים ליישם את האסטרטגיה העסקית שלהם, בעוד 90% נכשלים בשלב היישום. ממצא נוסף עליו הצביע שבכ 70% מהמיקרים שמנכ"ל ניכשל, הכשלון נובע מחוסר היכולת ליישם את האסטרטגיה העסקית, הסיבה המרכזית הינה שרק 5% מהעובדים בארגון אכן מבינים את האסטרטגיה העסקית.
אחד המאמרים ש"הקפיץ" את קהילת הIT היה של העיתונאי Nicholas G carr במאמרו מעורר המחלוקת והתגובות IT doesn’t Matter העריך שתרומת ה IT לעסקיות החברה שולי. אינני רוצה להיגרר לניתוח המאמר ולהציג עמדה בזכותו או בגנותו, דבר אחד ברור: הוא זעזע את קהילת ה IT וגרם למנהליה לחשוב. מאמר חשוב זה בצד ניתוחי אנליסטים על ביצועי ה IT גרמו לארגונים להבין שהם "לא בכיוון" .
לא פלא אם כך שה IT הוא "סובל ראשי" מחוסר הקשר וההבנה של האסטרטגיה. חברות מחקר ואנליסטים מציגים נתונים לא מחמיאים : 85% מפרויקטי ה IT נכשלים בהשגת יעדיהם. 32% מהם מבוטלים תוך כדי תנועה, בממוצע רק 7% מהפונקציונליות של תוכנה ששולם עבורה נמצאת בשימוש המשתמשים.
מחקר שנערך ב 2002 הראה קשר מיקרי בין הוצאות ה IT לעובד לבין החזר ההשקעה למחזיקי המניות.
פרויקטי IT סובלים מהתמשכות הפרויקטים בסידרי גודל של בין 18-24 חודשים בין ייזום לפעולה – Standish Group (2003) .
על הקשר בין SOA ל BPM
SOA מוגדר לא פעם בעת האחרונה כ BPM Enabler. זוהי ארכיטקטורה (או יותר נכון אוסף של כלים, מדיניות, סטנדרטים) המאפשרים מחד אוטונומיה של "יחידות שרות" ומאידך מיקוד בשרות שמורכב מאוסף יחידות מודולריות.
ה SOA הינו התגשמות התובנה של יחידות מחשוב אוטונומיות המאפשרות יצירת תהליך מחשוב אחד. שרות זה המאפשר שמירה על האוטונומיות של היחידות ושיתופם כשרות מחשובי אחד.המודולאריות הזו מאפשרת גמישות מרבית לשילובם בתהליכים עסקיים שונים. ה"חזון" של ארכיטקטורת מחשוב מונחית שרות הנראה ברור מאי פעם. – טכנולוגיות הבשילו, חברות הסכימו על סטנדרטים ל"חשיפה" ושיתוף מידע, לחץ גדול על היצרנים לתקנים של אבטחת מידע וההבנה של היצרנים שאם הם לא יהיו במשחק הזה – הם לא יהיו.
ההבטחה נראית אדירה וכולם עסוקים ב SOA כגודל ההבטחה גודל הסיכון. מיחשוב מבוזר של פלטפורמות שונות פותח "חורים" של אבטחת מידע, נגישות עובדים למידע לא להם, והמורכבות תהיה גדולה יותר ויותר. די אם ניקח את המשפט הידוע – חוזק השרשרת בחוזק הטבעת החלשה ביותר כדי להבין שWeb Services ש"חושף" Mainframe הופך להיות קריטי כמוהו והתלות בו מעלה מיידית את הצורך לשרידות, ביצועים, יתירות וגמישות על מנת להבין את המורכבות הטכנולוגית.
אולם הסיכון הגדול ביותר הוא ההגדרה הראשונית. פרויקטים רבים רצים ליישום SOA תוך דילוג על השלב הראשוני של הגדרת האסטרטגיה, הגדרת המדדים להשגתה והקשר בין התהליכים לאסטרטגיה.
הקשר זה לא ברור מאליו. ה"ריצה" ל SOA ללא התרגום למדדים עיסקיים והפיכתם לתהליכים וארכיטקטורה מוביל להרבה "שטחים אפורים" וחוסר תפיסה כוללת של ארכיטקטורה. אחד חוקרים המובילים בתחום שהגדיר את ה Enterprise Architecture , ג'ון זכמן פירסם ספר
Framework for Enterprise Architecture : A Primer on Enterprise Engineering and Manufacturing.
הספר דן במיבניות של ארכיטקטורה ובניית הקשרים בין הגורמים. אותם קשרים שיאפשרו לכל גורם לדעת על הסובבים אותו ואיך הוא "מתקשר" עמם.
השאלות המפורסמות שמוצגות הן
- Why – Motivation description
- How - Function description
- What - Data description
- Who – People description
- Where – Network description
- When – Time description
הערכות ליישום טכנולוגיה עיסקית
הערכות ליישום טכנולוגיה עיסקית תהליך מורכב שלעצמו. התהליך "מחקה" תפיסות ותיקות בעולם ה IT שמצריכות רענון. החזרת המשתמש למרכז, הגדרת יעדים עיסקיים, בניית מדדים להצלחה ובדיקה עצמית וקישורם לעיסקיות החברה, החזרת יכולת תכנון וניתוח למנתחי מערכות עיסקיים Business Analysts.
שלב Business Process Analysis & Modeling.
הגדרת המונח "תהליכים עסקיים", מודלים לניתוח תהליכים, אופן הגדרת תהליך עסקי והצגת הישויות המשתתפות בהגדרתו, שינוי, ROI בניהול תהליכים הגדאת ביצועים עסקיים, ביצועים, אסטרטגיה ומדידת ביצועים, Balanced Scorecard סוגי מדדים, מדידת סיכונים.
ניתוח התהליכים ו"מידולם"
שלב הקמת התהליכים העיסקיים – עם הכרת הכלים והתפיסות מגיע שלב בחירת המתודה ומימושה. כלי BPM מאפשרים שלב של סימולציה. לאחר הגדרת התהליך, ה"משקלות" (עלויות, זמן, סיכונים). הרצה של הסימולציה תחשוף בצורה משמעותית יותר את צווארי הבקבוק, מרכיבי העלויות, סיכונים.
מימוש טכנולוגי – השלב הטכנולוגי הינו שלב מאוחר בו ממשים (מעבירים לייצור) את התהליכים למערכות הייצור בחברה. שלב זה מבוצע לאחר הטמעת המערכת, הדרכת משתמשים, QA לתהליכים ולמערכות. בדר"כ ישנו שלב מקדים המוכר כ Staging & Integration בו נבחנת המערכת בקישורה למערכות סמוכות באירגון ובחינת "ביצועים טכנולוגיים".
שלב ההיזון – מערכת נכונה אינה מסתיימת במימוש טכני אלא בלמידה ושיפור. שלב זה שגם הוא מקוטלג תחת המושג BPM – Business Process Measuring, מאפשר יכולת המערכות ללמוד את הביצועים העיסקיים לנתח את צווארי הבקבוק, סיכונים ומדדי הצלחה, הינו מפתח לשיפור הארגון והתייעלותו המתמדת. היתרון במערכת BPM היא ביכולת לאפשר את השיפור בצורה פשוטה ומודולרית ולא במהפכות.
סכום
הפתרון אינו מצוי בטכנולוגיה בלבד. הפרשנות העכשווית שאנו מוצאים באירגונים רבים היא ריצה אחר SOA . אנחנו מיישמים SOA…. הינו משפט מצוי במחוזותינו ובמחוזות רבים. תפיסה זו הינה חזרה לתפיסה של פתרון "מוטה טכנולוגיה" בלבד לבעיה העיסקית. פרויקט נכון אמור להתחיל כמו תמיד בהגדרת הבעיה, הגדרת יעדי ומטרות הארגון, הגדרת ה"שחקנים" במשחק התהליכים האירגוניים, הגדרת אסטרטגיות אירגונית, מיגבלות (תקציביות, טכנולוגיות..), סיכונים ותרומתם לעיסקיות.
או אז שתהיה לנו "מפת דרכים ברורה" שתאפשר מתן ערך למושג Service במשוואה של Service Oriented Architecture.
אשמח לקרוא תגובות בנושא
תודה
מני