יום שבת, 28 ביוני 2008

When and Which application vendor will Google acquire?

Google is very serious about the applications market and is aggressive with pushing and further developing its Google Apps. Its vision for the applications market is to develop consumer oriented applications delivered within the “cloud” or simply put: software delivered through a browser and accessed from anywhere.

In my opinion, now is a right time for Google to make a further step in its applications strategy and acquire a vendor that can fit well into its cloud computing vision.

Lately we have heard about partnerships between Google and application vendors that share a common Cloud Computing vision. The first one is Salesforce.com, the second one is much smaller but so familiar in the Israeli market - Panorama. Does that mean that Google will make the extra move and acquire one of them? Let’s check these 2 options:

What if Google buys Salesforce?

Is Salesforce.com a possible acquisition for Google? This type of “strategic” acquisition It is definitely a possibility. Salesforce’s SaaS offering as well as their Web 2.0 initiatives (for example, AppExchange) offerings fit well into Google’s application vision as a “good option” to traditional application vendors’ software models. Salesforce and Google believe in the same model: software delivered through a browser and accessed from anywhere, or In other words, software delivered through the “cloud”. Salesforce can act as a good sales channel for Google Apps, Google is already doing a great job in consumers and enterprises’ advertising, but it can definitely use SF’s experience in selling software for the enterprise (the current partnership between Google and Salesforce is already doing exactly that - expanding Google into enterprises). Rumors about the possibility of Google acquiring Salesforce were already running around from about a year ago and pops up every now and then.

However, even if Google decided is does want to acquire Salesforce, it won’t be so easy, Oracle and Microsoft are likely to get into a bidding war. This will also be VERY EXPENSIVE acquisition, in a recent report by “451 Group” research company the evaluated cost of acquiring Salesforce.com these days can be around $10 Billion, that’s a very expensive price to pay.

What’s in it for Salesforce?
Some people say that the time is right for Salesforce to sell. It has made its mark and actually disrupted the software market. The SaaS model is now becoming quite common, and “traditional” vendors are starting to catch up – Oracle, Microsoft, SAP.

What if Google buys Panorama?

This is a very difference scenario. Acquiring Panorama would be a technological acquisition and a small one for Google to handle. It would provide Google the ability to incorporate dashboards and business intelligence on top of its apps (BI has become a must have piece of ANY application package).
Panorama recently partnered with Google and is investing a lot in this partnership. The interest from Panorama is very clear: Panorama had a stream of incidents that forced her to change its business model a couple of times (Microsoft’s acquisition of Proclarity, SAP’s acquisition of Business Objects). The traditional BI market has changed dramatically lately due to the major vendors’ aggressive acquisitions into this market. Panorama HAD to find something new, something that will position it as a faster, more innovative player in the BI space. In this respect, the Google partnership is great for panorama, and lets it move elegantly into could computing space by delivering BI on demand. On the other hand, Panorama is a Microsoft technological partner, the partnership with Google already puts it in a delicate position of partnering with 2 rivals - Google and Microsoft.

So what’s next for Google Apps? Google seems very determined about the applications area, I think several acquisitions are going to happen but it will have to be either point-specific, technological acquisitions that solve a particular issue (for example, an email encryption vendor called Postini that Google acquired in order to make their on-demand mail offering a more viable option for enterprises), or a large strategic acquisition that fits right into its application through a cloud vision (main visible one seems Salesforce but it can also be one one of the other on-demand players).

יום שני, 23 ביוני 2008

מה קורה בשוק ניהול המסמכים בישראל? רשמים משולחן עגול

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

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




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


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




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




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


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

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

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

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

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

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

Trips 2008 - Tanzania/Safari; South India

Pictures from our trip to India - December 2008
.
Pictures from our trip to Tanzania/Safari - September 2008
BTW, watch out for the caution sign before some pretty "harsh" pictures... not for the "faint-hearted" - you may want to skip the following 20 pictures (pics #97 to #117).
.
Enjoy,
Einat & Lior

יום חמישי, 19 ביוני 2008

How to get MDM right?

I'm happy to tell you about our planned workshop for MDM & CDI (Master Data Management & Customer Data Integration) which will be delivered by Ed Allburn (http://www.datadelta.com/) on July 7, 2008.


We decided to do this workshop due to many questions we are receiving re MDM on the one hand, and the lack of real life experience in MDM/CDI projects in Israel, on the other hand. It is clear that there is a NEED for MDM/CDI methods and tools. But how to get started? How to get it right? How to chose a vendor and SI? How to budget for it? And who is responsible for this area in the organization, anyway?


For this reason we have asked Ed Alburn, an expert in this field, to share with Israeli organizations his knowledge and best practices.



What is MDM?

Master Data Management (MDM) – The authoritative, reliable foundation for data used across many applications and constituencies with the goal to provide a single view of the truth no matter where it lies.Generally Used Sub-Definitions for MDM (for most G5000 enterprises, multiple (often all) variants will be needed to make MDM initiatives successful)


Who is Ed Allburn?

Ed Alburn is a 19-year industry veteran and President/CEO of DataDelta, Inc. (http://www.datadelta.com/) which provides CDI-MDM consulting and patent-pending, vendor-neutral match accuracy analysis software used to analyze & optimize the match accuracy of Data Quality, CDI & MDM vendor match engines including custom, in-house match engines. Mr. Allburn has held senior technical and strategic management positions in the fields of Database Marketing, Data Quality, CDI and MDM for industry leading companies such as Metromail / Experian, the IBM TJ Watson Research Center, Firstlogic and Group 1 Software. During his career Mr. Allburn has been responsible for over 200 successful CDI projects in banking, telecom, catalog and other industries. He is an international speaker and instructor for CDI-MDM Workshops, a contributor to DM Review and other publications, and a leading Expert Witness in the Data Quality and CDI-MDM industries.


If you're interested please contact irena@stki.info.

יום ראשון, 15 ביוני 2008

השימוש בכלי ותפיסות Web 2.0 בתוך הארגון

למרות שאימוץ כלי Web 2.0 בתוך גבולות הארגון נמצא עדיין בצעדיו הראשונים, ארגונים בישראל מביעים התעניינות גבוהה, כאשר היוזמות אשר לרוב מוזכרות הם: יצירת Wiki ארגוני ובלוגים של העובדים בנושאים שונים. המטרה הנה הגברת השיתופיות בין העובדים, העברת יותר אפקטיבית של מידע וידע, צמצום תעבורת המיילים (ישנם יישומים עולמיים שכבר הראו חיסכון משמעותי בתעבורת מיילים עקב הכנסת WIKI), והגדלת המידע הקולקטיבי הארגוני ("Collective Intelligence").

ארגונים רבים בישראל ובעולם צמאים לפתרונות ניהול ידע מוצלחים ושמישים, לאחר כישלונות רבים מגישות ופתרונות קודמים. יש תחושה שהגישה הקודמת של סדר ושליטה על המידע נכשלה, ולאחר ניסיונות רבים של יישום חבילות מורכבות ויקרות, הגיע הזמן לגישה אחרת. אבל השאלה היא – האם גישות הרשתות החברתיות, שהוכיחו עצמן בעולם האינטרנט החיצוני, מתאימות גם לצרכים הפנים ארגוניים? התשובה היא כנראה השילוב הנכון, בהתאם לאופי הארגון ולמטרותיו, בין שתי הגישות. להערכתנו, רוב הארגונים ינקטו בגישה משולבת ויחפשו הן את הפתרונות המסודרים (לדוגמה, מערכות ניהול מסמכים שמארגנות את המסמכים, שומרות על גרסאות, הרשאות גישה, קטלוג המסמכים), והן את הפתרונות המגיעים מעולם Web 2.0 כגון Wikis, בלוגים, שמטרתם להגדיל את המידע הקיים ולהגביר את הידע המשותף. בארגון אחד יהיה צורך לכלים משני המחנות השונים, בהתאם לצרכיו השונים. כמו כן, בארגונים יותר "היררכיים" וקשיחים יוזמות Web 2.0 יתקשו לפרוח, בעוד שבארגונים המעודדים שיתוף ידע, גמישים ויותר שטוחים באופיים, יוזמות אלה יתקבלו ביתר קלות.

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

השוואת גישות מסורתיות בניהול ידע אל מול גישות Web 2.0
















שימושים פנימיים בכלי Web 2.0
  • בלוגים פנים ארגוניים. אחד השימושים הבולטים בבלוגים לצרכים ארגוניים הוא דווקא בלוגים חיצוניים – כלפי הלקוחות, אשר יתרונם הגדול הוא ה"פנים האנושיות" מאחורי החברה בצורת בלוג של מנכ"ל החברה שמדבר ישירות אל לקוחותיו ואף מקבל מהם תגובות. אולם בלוגים גם יכולים לשמש להעברת מידע פנים ארגוני בין עובדים על נושאים מסוימים, דרך בה עובדים יכולים לחלוק טיפים וללמוד מניסיון מצטבר, ובמיוחד במעקב אחר פרויקטים ותכנים הרלוונטיים לפרויקט. אחת מהתוצאות הברוכות היא הפחתת תעבורת המיילים הקשורים לאותו פרויקט משום שיש מקום אחד שכולם נכנסים אליו, מעדכנים ומתעדכנים. כמו כן, עובד חדש שמצטרף לפרויקט וצריך ללמוד על נושא מסוים יכול להיכנס לאותו בלוג ולהתעדכן, כך שפערי הידע מצטמצמים. בלוגים ארגוניים שבדרך כלל יותר "תופסים" הנם כאלה של אנשים שמוכרים כמומחים לתחום מסוים בארגון, אלה שבדרך כלל עובדים אחרים מתייעצים איתם, ולאט לאט סביב הבלוגים שלהם נוצרות מעצמן קהיליות של בעלי עניין משותף – Communities of Practice.


  • ויקים פנים ארגוניים. בין השימושים אפשריים בתוך חומות הארגון: Enterpedia - WIKI כלל ארגוני שמהווה מעין "אנציקלופדיה" של הארגון; וכן WIKIS ממוקדים יותר כמו למשל WIKI לצורך תיעוד מידע הרלוונטי לפרויקט מסוים; יש ארגונים שלאחר שלב ראשון של יישום WIKI ארגוני, בשלב השני הם פתחו את ה WIKI גם לשימוש חיצוני של לקוחותיהם – לדוגמה, מדריכי משתמשים שצמחו מיוזמות פנימיות.


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


  • Social Bookmarking יוצרים Bookmarks וקישורים שאינם אישיים אלא קבוצתיים. כלים אלה מאפשרים שיתוף של bookmarks שמשתמשים אחרים סימנו, הערות שרשמו, הפניות ששמרו... וכמובן שכל זאת תוך הקשר לנושא ספציפי. כך שיש כאן שיתוף במשאבים.



המלצות:

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


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


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


  • אם לא ברור כיצד הארגון יקבל את השיטות החדשות ועד כמה העובדים יהיו מוכנים לשתף מידע, כדאי להשקיע בהכנה וחינוך הארגון לקראת המהלך


  • מינוי של "אפוטרופוס" לכל קהילה


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


  • ישמו שיטת בקרה וניהול על יוזמות אלה כדי להבין במה משתמשים ובמה לא, איפה ישנן בעיות, ואילו עוד פתרונות נדרשים


  • החוקים והבקרה ייקבעו על ידי, או לפחות בשיתוף, של הקהילה עצמה – באמצעות האפוטרופוס

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

יום חמישי, 12 ביוני 2008

תובנות ממפגש שולחן עגול בנושא Business Intelligence

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

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

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

קחו לדוגמה את תחום חבילות האפליקציות – מערכות ERP ו CRM כיום כוללות שירותי-BI/DW/אפליקציות אנליטיות מובנים. לא אחת אנחנו נשאלים שאלות אשר בבסיסן הן שאלות של מדיניות – מי בארגון אחראי על פרויקטים מסוג זה? מתי לאפשר את ביזוריות ה-BI הזו ומתי לא?

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

כמה מאפיינים מעניינים שעלו באשר למאפייני מחלקת ה-BI בדיון:
אצל 75% ממשתתפי הדיון קיימת יחידת BI מרכזית (אולם במספר ארגונים קטן קיים ביזור של נושא ה-BI למרות שבדרך כלל יש איזה גוף שאחראי על מדיניות ה-BI והפיתוח עצמו מבוזר)
בעלי התפקידים הכלולים במחלקת ה-BI/DW: מנתחי מערכות, מנהלי פרויקטים, אנשי DW – נתונים שעוסקים ב ETL, מודל נתונים וכד', אנשי פיתוח ובדיקות.
לרוב מחלקות ה-BI אין DBAs משלהם (זאת למעט ארגוני Teradata) אלא הם צורכים שירותי DBAות ממחלקת תשתיות.

יחסי כוח אדם
מסקר שערכתי בין המשתתפים על נושא יחסי כוח אדם עלתה שונות גדולה. מספר העובדים במחלקת ה-BI נע מ 4-6 במחלקות הקטנות יותר, ועד 60< במחלקות הגדולות יותר. המספר הממוצע של מספר עובדי ה-BI בארגונים ישראליים גדולים הוא 10-15 עובדים (נתון זה מסתמך על סקרים נוספים שביצעתי מול חברות רבות). ניסינו למצוא יחס בין מספר עובדי ה-BI למספר המשתמשים שעושים שימוש בשירותי ה-BI אולם גילינו כי מדד זה מאוד בעייתי בשל השונות בהגדרה "משתמש BI”, ובשל המגמה של מערכות תפעוליות שהופכות להיות משתמשים הצורכים שירותי BI בעצמם. הייתה שונות גבוהה מאוד בין היחסים שציינו הארגונים: החל מעובד BI אחד לכל 6 משתמשי BI, ועד לעובד BI אחד לכל 185 משתמשים. שיטת מדידה נוספת ויותר מוצלחת הנה גודל מחלקת ה-DW/BI (או מספר העובדים הכולל בתחומים אלה) ביחס לכלל מחלקת ה-IT. מהנתונים שאספתי, הנתון הממוצע של עובדי מחלקת ה-BI/DW מתוך כלל מחלקת ה-IT (תשתיות + פיתוח): 6.5%. יש לציין שהאחוזים שקיבלתי נעו בין 3% לבין12%. מספר ארגונים אחדים עמם שוחחתי ציינו כי תחת מחלקת ה-BI יושבים גם אנליסטים, רוב המשתתפים (כ-80%) ציינו כי האנליסטים יושבים במחלקות העסקיות. בדיון עלה גם נושא ה"גבולות" – נושא מעניין בפני עצמו. מה מחלקת ה-BI צריכה לעשות ומה לא? בארגון אחד שהשתתף מחלקת ה-BI כמדיניות שקבעה לעצמה עקב משאבים מוגבלים נותנת שירותים רק במקרים בהם יש להם ערך מוסף (כלומר אינה מוכנה להעביר נתונים ממקום למקום איפה שאין לה ערך מוסף). ארגונים אחרים ציינו כי נושא הגבולות נבדק כל הזמן ואחד מהארגונים חלק מניסיונו כשסיפר שכל גבול אדום שמחלקת ה-BI הציבה לעצמה בסופו של דבר נפרץ. באופן כללי הוסכם כי מחלקת ה-BI צריכה להתמקד בפעילויות בהם יש לה ערך מוסף, ולבחון האם לא כדאי לבצע בקשות מסוימות דווקא ברמת המערכת התפעולית ולא ב-DW.