No ... OBIA is not included ... there is a plugin available - you might have to request it from Oracle.

Are you using on-prem OBIEE or BICS (cloud)?

Are specific fact tables for each department at play here?

Reference to customized leads me to believe that you have a pre-built solution of some sort ... Using a prescribed customization scheme allows you to quickly identify customized items. If you didn't do that, then perhaps you can do a 'diff' on the vanilla pre-built versus what you have currently. 

try the AGGREGATE( AT ) - providing you have the dimensional hierarchies in place to support this. Learn Oracle and OBIEE: Aggregate at NOTE: I still encourage you to have the total measure and the % of Total built in the RPD ... build once use many.

I assume you are talking Opaque View which is deployed to database? when you speak of control ... I'm curious.

or OBIEE 11G - Aggregate At Function [Gerardnico] will do similar...

http://gerardnico.com/wiki/dat/obiee/measure_level_based

Opaque view selects ALL data unfiltered then OBIS does filtering ... DB View/Mat View can be predicate filtered on the database Probably not noticeable on a small volume - in large databases it's a no-no ... so I always do the DB way regardless of the volume.

Dimensional aggregate rule for time should be LAST (others set to SUM) ... then pick a month - would return last day row for that month. But then you won't be able to SUM across time ... a logical fact star answers a specific set of questions - you may need more than one logical fact star to satisfy your business…

You need a level-based measure for the Total ... then you need a logical column that does 100*(Hires / Total Hires) Department A hires = 10 Department B hires = 15 Department C hires = 5 Level based total = 30 Then if I filter that logical calculation for a department I expect: Dept A % of Total = 100*(10/30) = 33 Dept B %…

+1 to your answer .... In addition, the more you push back to the database the better ... within reason ... especially calcs like this you don't want to store the end result, but want to fetch, aggregate then divide -- it's logical in nature.

Dimensional Modeling Laws: 1 - the fact maintains relationship between ALL cross-dimensional attributes 2 - EVERY fact has a dimensional context (grain) So if you need dimensional browsing (similar to oltp system) then you need an additional fact that provides the maintenance of that relationship -- often referred to as a…

Materialize a view and auto refresh via your ETL cycle ... use it like a table in RPD. This works with billions of rows where table sizes are in the 100s of GB.

why semi-colon and not comma separating the values?

I did give you a solution (not a workaround) ... you know the pivot works when using a fact (it's designed to do just that) ... what you are doing (counting dim attributes) is actually logically creating facts ... so put those in the RPD in your logical fact table (or create a logical fact table at the same LTS grain as…

http://hussaindba.com/obiee-11g-cloning-using-t2p-process/

From the documents: https://docs.oracle.com/cd/E28280_01/bi.1111/e10544/format.htm#BIEUG2860

build your counts as measures in the fact ... that's what they are.

I suspect OBIA is what's being asked for ... I strongly recommend the enlistment of a partner (especially given the lack of detail and the general knowledge conveyed in the question) ... OBIA is too expensive to risk it on an inexperienced installer / 'configurer'.