ארכיטקט ERP – תפקיד חדש בארגון?

הארגונים העוסקים ב ERP לרוב מכירים את המונח (ERP COE (Center of Excellence שמהווה מרכז ההתמחות של ERP בארגון. זה הפך להיות best practice לארגונים העוסקים ב ERP (ובמיוחד אלה המשלבים את ה ERP בפעילויות הליבה שלהם) להקים COE שמעבר למתן שירותי תמיכה "סטנדרטיים" גוף זה מתווה מפת דרכים להתפתחות ה ERP בעתיד, נמצא עם יד על הדופק בנוגע להתפתחויות עסקיות חדשות, בוחן את אופן ההטמעה, וחלק מתפקידו של ה-COE הנו גם התעדכנות לגבי ה roadmap העתידי של ספק ה ERP, מה שנעשה לרוב על ידי קשר הדוק עם הספק עצמו, התעדכנות על ידי אנליסטים ויועצים, וכן שותפות בקהילות משתמשים שונות.

יחד עם זאת, בארגונים לאחרונה צומחת פונקציה חדשה שנראה שרק תלך ותהפוך ליותר ויותר חשובה הן בעולם ERP והן בעולם הIT הקלאסי – Enterprise Architect (לעתים מתייחסים לתפקיד זה בתור ה CTO החדש, בניגוד ל CTO שאנו מכירים כיום שמרוכז בעיקר סביב נושאים תשתיתיים). תפקידו של הארכיטקט הנו להוות תווך בין הצרכים העסקיים המשתנים של הארגון ובין אופן התפתחות ה-IT, כולל התוויית תכנית עתידית וגיבוש ארכיטקטורה. כמו כן, חלק מתפקיד הארכיטקט/CTO הנו לבחון טכנולוגיות חדשות, כאשר היתרון העיקרי הוא שלפונקציה זו יש מידע עדכני לגבי הצרכים העסקיים של הארגון – לאן הארגון רוצה להגיע, אילו שירותים המחלקות העסקיות צריכות, סדרי עדיפויות בין הצרכים השונים. פונקציה זו – הארכיטקט – לרוב כפופה למנמ"ר.
תיאור תפקידי ארכיטקט הERP (לקוח מתוך אתר של קהילת Netweaver) ניתן למצוא כאן.

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

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

• הגדרה של פונקצית ה-CTO/ארכיטקט – ישנם ארגונים בהם ישנה הגדרה ברורה של CTO וארכיטקט, כאשר בד"כ הפונקציה של CTO הנה ותיקה יותר ובכירה יותר. באופן כללי, ה- CTO אחראי על בחירת טכנולוגיות בארגון באופן כללי (מהו הסטנדרט שיהיה מקובל בארגון ?) והארכיטקט אחראי על בחירת טכנולוגיות ספציפיות לפרויקט (באיזה שרתים ואחסון ישתמשו לפרויקט ספציפי- ERP? האם יהיה שימוש ב- CLUSTER? וכו'). ישנם ארגונים בהם התפקידים של CTO וארכיטקט הנם תפקידים מקבילים, כאשר ה- CTO עוסק בתשתיות והארכיטקט עוסק באפליקציות\תוכנה. ישנם גם ארגונים בהם תפקודי ה- CTO או הארכיטקט מהווים חלק מתפקידו של מנהל התשתיות.
• מעורבות הארכיטקט\CTO בפרויקטים חדשים – ישנם ארגונים בהם ישנו תהליך מובנה וברור של התנעת פרויקטים חדשים בהשתתפות נציגי גוף ה- CTO\ארכיטקט. לעיתים ההתנעה מלווה בהליך של Architecture Review ולאחר מכן בתהליכים של Design Review. מצד שני, ישנם ארגונים בהם תהליך זה לא קיים כלל או שלחילופין, השתתפות נציגי גוף ה- CTO\ארכיטקט הנה וולונטרית – כלומר, על פי הצורך. אז מתגלה לעיתים שישנה בחירה בטכנולוגיה לא מתאימה או פיתוח של פונקציונאליות שכבר קיימת בארגון. ברוב המקרים פרויקטים גדולים זוכים במלוא תשומת הלב, אולם פרויקטים קטנים או לחילופין פרויקטים דחופים לא עוברים במסלול המלא וגם אז מתגלות בעיות – כשהפרויקט נמצא כבר בייצור\תחזוקה ואז כמובן עלות התיקונים גבוהה. כלומר, ישנה חשיבות גדולה לעובדה שה- CTO\ארכיטקט יהיה דמות שרוצים להתייעץ איתה ולא מאוימים על ידה. הערה חשובה: אין ספק שתהליך מסודר ומובנה של התנעת פרויקטים מעכב את הפרויקט ויוצר תקורות. אכן, נציג אחד הארגונים היעילים בתחומו (לעומת ארגוני IT מקבילים בתעשייה) ציין שבארגונו לא קיים תהליך מובנה וכבד. חשוב לציין שבפורום זה של CTO וארכיטקטים לא נשמע קולם של מנהלי הפרויקטים שעשויים להתלונן על "בירוקרטיה" באישור הפרויקט...
• אכיפה – רוב הארגונים ציינו שבכל מקרה לא מדובר באכיפה קפדנית של החלטות (והסטנדרטים) של ה- CTO\ארכיטקט. הסיבה לכך היא קיומה של דילמה בין האכיפה של סטנדרטים והמלצות של גוף ה- CTO\ארכיטקט לבין האינדיבידואליזם של הפרוייקטור\מפתח. ברור שלא רוצים "לדרוס לגמרי" את האינדיבידואליזם.