Supply Chain בישראל - סוף 2008

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

• רוב פעילויות ההתקשרויות מול ספקים הנן ידניות, דברים רבים שיכלו להיות ממוכנים ולחסוך עלויות כוח אדם נכבדות אינם ממוחשבים. מיכון פעילויות אלה יכול לא רק לחסוך בעלויות כוח אדם אלא להוביל לשיפורים נוספים כגון חיזוק הקשר מול הספקים, יותר נתונים שיאפשרו ניתוח הספקים, רמת אמינותם, רמת השירות, וכד'.
• ברוב הארגונים קיים טיפול (חלקי בלבד) בנושא ה Execution ולא בנושא ה Planning, ורוב ההתייחסות שמחלקות עסקיות מקבלות הנה במסגרת ה ERP + פתרונות משלימים קטנים אחרים. דווקא לחלק ה Planning שעוסק באופטימיזציה של תהליכים יש פוטנציאל עסקי גבוה ביותר, במיוחד כאשר ניתן לחבר אותו באופן הדוק לתהליכים השוטפים (Supply Chain Execution) כך שהתהליכים מושפעים מתובנות אנליטיות. כלומר, יישומי BI אקטיבי בתחום שרשרת אספקה מציעים ערך עסקי גבוה ביותר, כאמור, רוב הארגונים כלל אינם שם. רוב ניתוחי הBI הקיימים כיום מתרכזים סביב נתוני מכירות, פיננסים ולקוחות. יישומי BI אקטיבי שמשפיעים ישירות עם תהליכי ומערכות תפעוליות מתרכזים לרוב סביב איך להוציא יותר כסף מלקוחות. הם הרבה פחות מתרכזים בשאלה רלוונטית מאוד לעיתות משבר – איך נייעל את אופרציות הארגון: רכש יותר מושכל, רמות מלאי יותר מבוקרות, חיזוי דרישה וקישורו לפעילויות הארגון, איזה ספק לבחור לתהליך ספציפי וכד'.
• מנהלים עסקיים לעתים מדברים ישירות מול ספקים בתחום הSupply Chain, כאשר לעתים ה IT כלל אינו מעורב. העסק בדר"כ מסתבך כשמערבים את ה IT לקראת סוף התהליך, באופן טבעי נוצרות התנגדויות והתהליך מסתבך. כמובן שאחת מהתוצאות היא שהIT נתפס כמעכב תהליכים עסקיים לארגון.
• סינדרום ה-ERP. מנמ"רים רבים ציפו שמערכות ה-ERP ייתנו להם מענה לתהליכי שרשרת אספקה באופן די מקיף. פעמים רבות מסתבר שחבילות אלה לא מטפלות בתהליכים ספציפיים, או שהן מטפלות בו בצורה חלקית בלבד. פעמים רבות מתעורר הוויכוח הוותיק שבו ה IT לרוב יטען שכדאי להשתמש במה שיש בחבילת הERP ככיוון אסטרטגי מבחינתו. התוצאה היא ששוב מחלקת הIT נתפסת כגורם מעכב.
• תדמית שלילית. מחלקות IT שכיום מתייעצות עמנו בנושא SCM שונים מביעים רתיעה מתחומים שונים שקיבלו מוניטין רע, ובמיוחד תחומי B2B, Ecommerce. קיים פחד להיכנס לנושא זה בשל זיכרון של כישלונות עבר בתחומי זירות מסחר ויוזמות שונות שהתפוצצו.

להערכתי, מחלקות IT כיום רחוקות מדי מצרכי שרשרת האספקה של הארגון. אין ספק שתחום ה Supply Chain Planning הולך להתפתח בצורה משמעותית ביותר, לכלים בתחום תכנון שרשרת האספקה יש פוטנציאל עסקי משמעותי ביותר עבור חברות שחלקו קשור להתייעלות וחיסכון כספי בסדרי גודל מרשימים ביותר, לא רע לתקופות משבר. התחום יתפתח, ולהערכתי זה יקרה עם או בלי מעורבות מחלקות הIT (מה גם שתחום ה SaaS צפוי לחדור משמעותית לשוק זה כך שחלק מהיוזמות ייעשו לעתים ללא ידיעת הIT כלל). לי נראה שלמחלקות הIT כדאי להיות חלק מהעניין, מה גם שפרויקטי ERP גל ראשון יוצבו ברובם, כך שיוזמות SCM יכולות למנף חלק מהתשתית האפליקטיבית שארגונים כל כך התאמצו להשיג. מהצד השני של המתרס, ספקי הIT צריכים להיכנס יותר לתחום (דבר זה ידרוש השגת יכולות והתמחויות חדשות מבחינתם), רוב הספקים הגדולים בישראל מחוץ למשחק זה כיום, ומשאירות את השוק לחברות יחסית קטנות שפועלות כחברות ייעוץ + יישום + מוצר. הן אלה שפיתחו קשרים טובים עם מחלקות עסקיות בתחום זה וכן לעתים מול מחלקות הIT.

Software Maintenance in "Post traumatic IT" times

I've been talking to organizations that heavily rely on packaged enterprise applications (SAP/Oracle/Siebel etc.) and are paying considerable annual maintenance fees (typically between 18% - 22% of the software license price). This means that within 5-6 years time the organization has paid the equivalent of a full software license.

On top of this expense, internal dedicated staff that support the ERP/CRM packages is a considerable expense and, meanwhile, it doesn't look like it's getting any smaller.

Enterprise applications have become what is sometimes called "Applistructures" – a combination of software and infrastructure components bundled together. This advent has an implication on the ERP support staff: it is becoming more diverse, more skills are required, and the packages are more difficult to maintain (one CIO told me that in the "good old days" when a specific model had performance issues they knew exactly what to do, nowadays you can never know if the problem is in the application level, portal server, web server etc. so the maintenance is getting more and more complicated as the packages vendors provide more "SOA" elements).

ERP staffing ratios in Israel
A survey we performed among large Israeli enterprises revealed that it takes 1 ERP professional to support 30-50 users (this is in organizations that are relying quite heavily on ERP for a large percent of their business operations); and it takes 1 ERP professional to support 80-100 ERP users in which ERP is "just another application", or, in other words, not a critical one. This means that ERP departments in organizations are quite large, and are usually above 10 people.

How much does it cost to run ERP after going live?
A general "rule of thumb" stated that the cost of maintaining ERP after going live is 1% of the organizations' revenues! This is a very disturbing figure, especially since most ERP packages are not helping companies grow or transform, they are usually helping companies to "keep the lights on" and continue operating pretty much the same way they did.

So - What can companies do to lower these maintenance costs in post traumatic IT times, such as the one we are most likely facing in 2009 and possibly beyond that?

New application packages maintenance models?

An interesting phenomenon (in the worldwide IT market) lately is the use of 3rd party vendors that are offering software maintenance services (for specific software packages such as Peoplesoft, Siebel etc.), for about 50% of the maintenance costs that are paid to the software provider. In exchange, these companies are offering Help Desk services, updates and fixes (at the application level, not technical level), and also tax and regulations updates. For example, Rimini St., (which also lately announced it will soon support SAP at a time when SAP shops are faced with maintenance fees increase from SAP). Another example which was actually founded by the same founder formerly is (was) TomorrowNow, it was acquired by SAP which was sued by Oracle and recently had to close these operations.

While this is a very interesting model that provides some alternative to CIOs, it is definitely not for everyone. It seems to me that a CIO would have to be quite brave to take on this adventure. Sure, it provides great savings each year and frees up much of the budget to be used for better purposes, but it also means that he doesn't have anyone to talk to if there are serious technical issues that can only be solved in the product technology level. The other big implication is that once a major release is out, and an organization has not paid maintenance fees to the vendor, he would have to buy the package all over again.

We have not seen any vendor try to offer this model in Israel, and I'm not sure that we will. It is not a very widespread trend abroad as well, but is definitely expanding. However, this model shows that there is an interest to decrease "keep the lights on" budgets to make more room for "grow" and even "transform" budgets. I think we are expected to see more models around the area of software maintenance that provide lower TCO in the next years.

האם ארגונים כבר מוכנים לאמץ כלי Workflow?

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

יחד עם זאת, לאחרונה אנו רואים כי ארגונים מתחילים להביע יותר עניין ב Human oriented BPM – בתהליכים אשר יותר מכווני-אנשים (לעתים מכונים תהליכי person to person ). כלי Workflow מטפלים בתהליכי person to person , ולרוב מתלווים למסמך אלקטרוני/מסמך כלשהוא (לדוגמה, תהליך אישור נסיעת עובד לחו"ל, אישור בקשת רכש, תהליך קליטת עובד).

במטרה לבחון מהי רמת המוכנות של ארגונים לאימוץ שיטות וכלי Workflow, וכן גיבוש טיפים ולקחים מארגונים שכבר עוסקים בנושא, החלטתי לקיים שולחן עגול בנושא.

בין השאלות אותן נעלה בדיון:
· מה מצב שוק ה Workflow בישראל? האם ארגונים עושים שימוש בכלים אלה, ולאילו צרכים? האם לצרכים אדמיניסטרטיביים אשר אינם מטופלים על ידי מערכות אחרות, או האם גם לתהליכי ליבה?
· מה המאמץ הנדרש בכניסה לתחום זה? איך להיערך? מהי עקומת הלמידה?
· עד כמה אפשרי לתת למחלקות עסקיות/אנשי או"ש לתכנן תהליכים בעצמן באמצעות כלים אלה?
· עד כמה ארגונים מאמצים כלים למידול וניתוח תהליכים עסקיים ( Business process analysis, business process modeling tools )?
· כיצד מקשרים את סביבת המידול לסביבת האקטיבציה?
· איך מתמודדים עם מפת הספקים המבלבלת והעובדה שספקי Workflow מגיעים מכיוונים מאוד שונים (ספקי אפליקציות, ספקי WF ייעודיים, ספקי אינטגרציה ותשתיות, ספקי פלטפורמות, ספקי ניהול תוכן וכד')?

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

etty@stki.info ושמרית Shimrit@stki.info או טלפונית בטל': 09-7907000 (אתי או שמרית).
(המפגש מוגבל לארגוני משתתפים בלבד ולא לספקים או יועצים).

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

המפגש ייערך בתאריך 15.12 (יום שני) בין השעות 09:30 – 13:00 ויתקיים במשרדנו שבבני ציון.

איך אתם מקדמים חדשנות בארגון?

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

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

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

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

כיום רוב הארגונים אינם נהנים משירותי IT תומכים לחדשנות, השאלה היא מהם אותם כלים? האם ישנם כלי "מדף" לחדשנות (מושג קצת אירוני בפני עצמו)?

אתר שתפס את עיני הוא האתר הבא, שממפה כלים טכנולוגיים לחדשנות - http://www.innovationtools.com/

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

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

כלי חדשנות הם תחום לחלוטין לא מנוצל שטומן בחובו פוטנציאל רב לחילול שינוי משמעותי בארגון. האם יש מקום לכלים אלה, שנחשבים Nice to have ובוודאי לא נכנסים תחת קטגוריית Keep the lights on בסעיפים התקציביים, גם בתקופות כלכליות קשות כזו שמצפה לנו ב-2009? פרויקטי ה Nice to have יהיו הראשונים שיקוצצו, אך מצד שני - פרויקטים אלה אינם יקרים כלל. ניתן ליצור בקלות ובמהירות סביבות להעלאת רעיונות על ידי העובדים ודירוגם על ידי שימוש בכלי בלוגיים חצי חינמיים (במקרה זה האתגר היותר גדול הוא ליישם תהליכים ארגוניים שידעו לנצל רעיונות אלה כמו לדוגמה בעל תפקיד שאמור לעבור על רעיונות אלה).

אילו פתרונות מחלקת ה-IT מספקת למנהל הפיננסי?

במשך שנים התסמן פער ברור בין השוק הבינלאומי לשוק הישראלי בכל הנוגע לכלי תכנון פיננסי, או כאלה הנכללים תחת מונח המטריה: CPM - Corporate Performance Strategy. מונח זה כולל בתוכו תתי-תחומים רבים כגון תכנון תקציב, תמחיר, איחוד דוחות כספיים, Balanced Scorecards ועוד ובשנים האחרונות זוכה לעדנה בשוק הבינלאומי. אולם בישראל רוב הארגונים יישמו רק רכיב קטן מתוך מכלול זה, ורבים מהם מתחילים להתעניין בתחום לאחרונה בצורה יותר עמוקה. מעטים הארגונים בישראל שחיברו בין תהליך התכנון האסטרטגי והתכנון הפיננסי, לפעולתו השוטפת של הארגון כדוגמת יוזמות Balanced Scorecard חוצות ארגון.

כאמור, לאחרונה חלה התעוררות בקרב ארגונים ישראלים בכל הקשור לכלי תכנון ובקרה למנהל הפיננסי. בעוד שבעבר רוב הכלים אשר סופקו ל-CFO היו תפעוליים באופיים (כחלק משלב א' בפרויקטי ERP), כיום מנהלים פיננסים דורשים (וגם מקבלים) יותר כלי תכנון ובקרה.

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

במפגש נבדוק אילו כלים ופתרונות המנהל הפיננסי כיום צריך, וכיצד מחלקת ה-IT יכולה לתמוך בצרכים אלה? במפגש נעלה את השאלות הבאות (עד כמה שיאפשר הזמן):
· מה כבר נעשה בארגונים מבחינת פתרונות למנהל הפיננסי?
· מה יהיו הכלים הבאים אותן מחלקות IT תידרשנה לספק למנהלים פיננסים, במיוחד בתקופות של חוסר יציבות כלכלית? מהו הדגש בתוך מכלול כלים אלה (האם אנליטי? האם תפעולי?)
· מה בין ERP לפתרונות פיננסים? האם הפתרונות הפיננסים מגיעים מסביבות הERP או שיש להסתכל על תחום זה כייחודי, המצריך פתרונות Best of breed?
· המלצות וטיפים לארגונים הנכנסים לתחום

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

המפגש ייערך בתאריך 05.11 (יום רביעי) בין השעות 09:30 – 13:00 ויתקיים במשרדנו שבבני ציון. המפגש מיועד לארגוני משתמשים בלבד (ולא לספקים או יועצים). אם ברצונכם להירשם, אנא שלחו מייל לאתי etty@stki.info או שמרית shimrit@stki.info או טלפונית 09-7907000 (אתי או שמרית).

ODS - תמונת מצב

ODS - Operational Data Store, הנו מונח די היסטורי בעולם ה-DW והאפליקציות הארגוניות, או ליתר דיוק - בעולם ניהול הנתונים.
לאחרונה בדקנו מה סטטוס ה-ODS בארץ ובעולם, במטרה לבחון האם ה-ODS, שיטה טכנולוגית שצמחה מתתוך הכרח, הופכת להיות מיותרת בארכיטקטורת ה-IT של היום, או שעדיין אין לה תחליף ראוי.

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

ODS - פיתרון טכנולוגי
בדיוק כמו שה-DW צמח כשיטה לאפשר ניתוחים אנליטיים, ה-ODS צמח כפיתרון המספק סביבה מקבילה המספקת שירותי נתונים תפעוליים לכל דורש, בין אם מדובר באפליקציות תפעוליות הצורכות נתונים אלה, או בסביבת DW.
היתרון הגדול הנו הפחתת העומס על מערכ/ות המקור. מבחינה היסטורית, מערכות רבות נבנו בצורה עצמאית, ללא קשרים בין מערכת אחת לשנייה. אולם עם הזמן הסתבר שההחלטות שמערכות, (וגם אנשים), מבוססות יותר ויותר על מערכות אחרות. לסוגיה זו מספר משמעויות, גם המשמעות הפיזית של גישה למערכת לשלוף את הנתונים, גישה היוצרת עומס נוסף על המערכת ותוספת עבודה במהלך התכנות (כי צריך לפנות למבנה נתונים אחר שלא שייך לפרויקט) אבל גם משמעות של קשיים טכנולוגיות ומאמצים תפעוליים. אם ישנה מערכת תפעולית חשובה שפועלת 24*7 שצריכה נתון ממערכת פחות חשובה שפועלת רק 5*8, הרי שלפחות מסד הנתונים של המערכת הפחות חשובה חייב לקבל "שדרוג" של שרתים ואחסון זמינים (cluster , DRP), מדיניות הורדת מערכת וניהול שינויים "משודרגת" וכד'.
זהו הצורך הבסיסי ל- ODS – מקור נתונים תפעוליים זמין ואמין שמוריד את העומס בכל הרמות מהמערכות התפעוליות. בד"כ ה- ODS תומך ב- read only בלבד.

תמונת מצב - מה המגמה בעולם?
מבחינת המגמה בעולם, ODS עדיין די נפוץ אך הופך להיות פחות "טרנדי". הטרנדים מדברים הרבה על ה"דור החדש" של ה-ODS: MDM – Master Data Management, וה-CDI – Customer Data Integration (אם מדובר על נתוני לקוחות), אשר מתחילים להיכנס על חשבון ODS המסורתי יותר.
ישנם קווים דומים בין תפקיד ה ODS לתפקיד ה-CDI/MDM וחפיפה ביניהם. הODS הנו פתרון "טכנולוגי" טהור שתפקידו לשמש תווך בין מערכת תפעולית למערכות תפעוליות אחרות שצורכות data שנמצא במערכת. ואילו ה-CDI הנו פיתרון טכנולוגי אך הוא גם מספק אפשרויות "ניהול" ו governance של נתון – איך מוגדר נתון לקוח? חוקים עסקיים סביב הנתון? מה עושים בעת קונפליקט? ב CDI יש בדר"כ את הטיפול בטיוב הנתונים ובאופן כללי צריך משתמש עסקי שייקח בעלות על הנתונים.
הסבר לגבי ההבדלים העיקריים בין CDI ל ODS ניתן למצוא כאן.

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

לסיכום, נראה שה"דור הבא" של ה- ODS הנו ה-CDI/MDM שכולל בתוכו הרבה מיכולות הODS ויותר מכך (מספק גם פיתרון טכנולוגי אך גם פיתרון "פוליטי" – מה שמצריך ישות עסקית שלוקחת בעלות על הנושא וגם שינויים מהותיים במערכות שכבר קיימות בארגון). ה-ODS לא חילוף מהעולם כל כך מהר, אלא סביר שיוחלף על ידי מודלים דומים שמספקים את אותן יכולות בתוספת יכולות קיימות. בעיית ה governance של נתונים, הקושי ביצירת "תמונת לקוח"/ נתון פיננסי/ נתון ספק וכד', אחידים לכל אורך הארגון יהווה בעיה מטרידה עבור ארגונים גם בשנים הקרובות.

שולחן העבודה של נציג השירות - סיכום שולחן עגול

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

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

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

מפגש זה עסק בניהול, עיצוב, תכנון, ותפעול שולחן העבודה של נציג השירות. התחומים שהוזכרו בדיון:
EPSS - Electronic Performance Support Systems
Unified Desktop
כלי- Interaction Management לצורך שיפור וייעול התהליכים המתבצעים מול הלקוחות במוקדי שירות הטלפוניים.

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

• מהן הבעיות הקיימות כיום במוקד השירות?
• EPSS - מה התועלות וממה להיזהר? למי זה מתאים?
• Unified desktop - האם יש מספיק ניסיון, ובמיוחד בארץ, בתחום זה?
• מה הגבול בין מערכות תפעוליות ל-CRM?