פיצול או איחוד מערכות

 

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

בשנות ה 90 אחד הויכוחים הסוערים במערכות מידע היה האם להתקדם באסטרטגיה של  Best of Breed או באסטרטגיה של ERP ? היו אז חבילות לוגיסטיות ו MRP נפרדות ומערכות פיננסיות נפרדות ו Best of Breed קבע שעל ידי חיבור שלהן נקבל את המיטב. באה תפיסת ה ERP , בעיקר מסאפ ולאחר מכן מאורקל, וטענה שהיתרון של ריכוז היישומים בבסיס נתונים אחד ובשרת אחד עם אינטגרציה טובה של התהליכים מביא לחסכון עצום והוא גובר על שיקולי פונקציונליות מחבילות נפרדות. החסרון בפתרון כולל לארגון המבוסס על ממשקים רבים ופיצול נתונים ותהליכים תמיד לוקה בהשוואה למערכת אחודה.

בשנים הראשונות של R3 הכל היה סבבה! מערכת אחודה, גם התוספת המאוחרת של מודול ה HR וגם הפתרונות לתעשיות ייחודיות , Industry Solutions, כולם שכנו על אותו שרת, אותו CLIENT. המידע היה אחוד ולא היו כפילויות וממשקים רבים. כל הדוחות התפעוליים והמנהליים הופקו מהמערכת המרכזית.

אז התחילו להתווסף מערכות נילוות חיצוניות: ה CRM של סאפ הוקם על מערכת נפרדת משתי סיבות: כדי לאפשר להתחבר למערכות שאינן סאפ וכדי לנצל טכנולוגיות פיתוח מתקדמות וממשק למשתמש מתקדם יותר. כנ"ל לגבי SRM. מערכות ה BW לדוחות מנהליים היו נפרדות כדי שלא להפריע לבסיס הנתונים היחסי וכדי לנצל את עקרון ה OLAP. (היום בסיס הנתונים HANA מערער על קביעה זו ומציע לאחד מחדש את מערכת ה ERP ומערכת הדוחות המנהליים תחת בסיס נתונים אחוד חדש בזכרון – HANA).

בנוסף נוצרו מנועים נוספים שפעלו על INSTANCES נפרדים: ICM, EWM, GRC והפורטל בטכנולוגית JAVA. במקום מערכת אחודה יש לנו היום בליל של מערכות שאנו נדרשים לקשר ביניהן ואז יש גם צורך ב HUB תקשורתי ומערך חיבור ממשקים הלא הוא ה PI/XI.

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

בארגונים גדולים אנו מוצאים היום גם פיצול במערכות הייצור של ה ERP  הארגוני עצמם! הסיבות לכך רבות:

סיבות לפיצול

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

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

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

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

פחד מפגיעה בשוטף – קורה שקיים בלבול בין נוף המערכות הפרויקטלי לבין נוף המערכות הקבוע. הם אינם זהים ! בפרויקט יישומי גדול המתווסף ליישום ERP משמעותי קיים יש להשתמש בפתרון ה RETROFIT לנוף הפרויקטלי הזמני. על זה כתבתי  ב נופי מערכות וכדאי גם לעיין בחוברת חדשה של סאפ על             Software Change Management + Transport Landscapes .

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

בעיות הנוצרות מפיצול במערכות יישומיות

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

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

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

למה לאחד?  כי הסיבות ההסטוריות כבר אינן בתוקף

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

מחקר של חברת RAAD בגרמניה ב 2010 קבע כי 15% מלקוחות סאפ טענו כי מערכות הסאפ שלהן מפוצלות מדי.

מחקר אחר של חברת HCL מצא כי חברות רב לאומיות שאיחדו את המערכות שלהן השיגו חסכונות רבים כאשר על כל 1 $ של חסכון בתחומי ה IT נוצרו 3.4 $ נוספים בצד העסקי.

http://www.news-sap.com/hcl-study-more-value-from-sap-landscape/

פרויקטי איחוד מערכות

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

בתוך סאפ עצמה קיימת יחידת שירות וותיקה לאיחוד מערכות בשם SLO – System Landscape Optimization  העוסקת כמובן באיחוד מערכות ומיזוגים אך בעיקר בהעברה מסיבית של מידע פיננסי עם כלים ייחודיים שלהם. https://Service.sap.com/sapslo

קיימת גם תוכנה המבוססת על ה SOLUTION MANAGER ונקראת Landscape Transformation. ומאפשרת חלק מהיכולות של ה LSO הקישור שלה הוא https://Service.sap.com/saplt

פרויקטים בארץ – בשנים האחרונות בוצעו בישראל לפחות שני פרויקטים גדולים של איחוד מערכות : איחוד מערכות הסאפ של שטראוס ושל עלית ( 2006- 2007) ואיחוד המערכות של בתי הזיקוק בחיפה עם המערכת של חברת הבת כרמל אולפינים (2010).

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

שלכם,

עודד