This blog will cover Strategic Business Functions approach in detail with a brief of Critical Success Factors approach.
CSF - Critical Success Factors- Different functional managers are asked question about the important things they would like to enquire/know about their business once they are back from a vacation. The answers are then analysed to define the critical success factors. Critical success factors are difficult to define because the definition of critical success factors can conflict between different function divisions example - inventory manager would like to keep his inventory low and maximise deliveries and at the same time, transport managers would like to minimise deliveries and increase inventory.
Strategic Business Functions approach- This is one of a technique used but is not well known. Failures of CSF techniques led to the rise of SBF approach. Does not ask individuals but only analysts about their views.
Characteristics-
1. Develops an understanding of the executive roles
2. What functions the business does it is important (Strategic)
3. Identifies linkages between the strategic functions
4. Allows for prototyping
5. Aids in well prioritised development
6. More of a wish list.
Talk to executives in groups so that conflicts are not ignored but resolved. The time to arrange such meetings is often through retreats (excursions, workshops, brainstorming sessions) . Discussion is about what is important to business and their linkages. Prioritise the SBF's. Once SBF's are identified, the data sources are identified. Then development takes place as per the prioritised SBF's.
SBF are easier to start off and are less demanding of exec's time. Real strategic business objectives are identified and clarification of inter-dependency between functions is identified. Clear understanding of critical needs of the organisation and more consistent reports. Achieve the SBF's by questioning "WHY" we need rather than focusing on "WHAT" we need.
Cause Effect understanding is achieved...how one change effects other function units.
TQM - Total Quality Management
Collect data, use simple statistical tools like Histograms, Pareto Charts, Run Charts, Shewhart Charts etc. to analyse data and take actions to improvise systems. Interestingly, there is no evidence that graphs improves a decision maker's understanding of data.Wow! why use them??
Business Performance Measurement -
1) Productivity Measurement is measurement of the ability of a firm to create something having exchange value.
EIS/DSS/BI applications often report productivity by measuring inputs being transformed into outputs through some production process and it does not limit to a manufacturing organisation.
Steps - Measure inputs ,measure outputs ,know the process of transformation in detail.
Productivity is increased getting more outputs from same number of inputs.
Law of diminishing returns - Varying one input and keeping others constant, some productivity increase is adopted.
Production Function is mathematical expression that states the maximum amount of output that can be produced by same number of input. Shifting to a new production function represents a change in productivity.
Exam date-sheet is up and is giving me goosebumps....I am still struggling with assignments...Phew! never realised time flies this fast. I had promised myself to get a head-start on BIA assignment and well I did, if you count connecting to database and checking out the data. Well, I have been punctual with my tutorials and Aroma case study is going on well. Will try to give more time this weekend and post my updates.
P.S - If you mistake the blog for a 'lecture note', then apologies in advance. Actually, I typed it during the lecture itself to save some time.
Tuesday, September 21, 2010
Wednesday, September 15, 2010
Week 8 -IBM Cognos' 24 Ways
Learnt about IBM Cognos' 24 ways to design a multi-dimensional models which cover different functional domains- Sales, Marketing, Human Resources, Distribution, Purchasing, Production, Customer Service and last but not the least IT Systems. These models are a good reference points for someone who wants to develop a Multi-dimensional model for a particular functional area.
Cognos' 24 ways are based on some assumptions as mentioned below with my personal comments in bracket-
1. Good quality data is available.
(High hopes!)
2. Iterative implementation.
(BI systems generally follow iterative approach)
3. Believe that organisations have a lot in common.
(True for some functional domains like Finance, HR, Sales etc.)
4. Dimensions are shared between functional domains
(Good approach)
5. Focus is on business people and not IT people
( Pragmatic approach, not really beneficial)
They promote that sharing the dimensions will lead to better co-ordination in decision making across functional areas and following the 24' ways will result in better ROI( Return on Investment). They start up with a consultant led 90 days implementation of the FINANCE domain which is a pragmatic approach as Finance is the only division wherein a company would have good quality data readily available.
Lectures are going well in terms of content....only slightly behind in schedule but never mind, I m sure one day we will catch up! POD literally gives away so much of information in one lecture that you feel rich in terms of knowledge.
Tutorials are going fine as well and I don't face difficulty in doing things as the specifications are so descriptive. However, people in our lab face challenge in 'processing' the dimensions due to some stupid privilege issues which props up if we try to save our workspace on C:/ drive. The people who save on their flash drives can apparently run successfully. I will make sure to take my flash drive from now onwards. And of-course it works fine in my laptop's work environment as well.
Unfortunately, I have not started with my assignment yet. There is just too much of writing work for other units which I am still slogging to meet the due dates. Hopefully, I will have some progress done till I write my next blog. AMEN!!
Cognos' 24 ways are based on some assumptions as mentioned below with my personal comments in bracket-
1. Good quality data is available.
(High hopes!)
2. Iterative implementation.
(BI systems generally follow iterative approach)
3. Believe that organisations have a lot in common.
(True for some functional domains like Finance, HR, Sales etc.)
4. Dimensions are shared between functional domains
(Good approach)
5. Focus is on business people and not IT people
( Pragmatic approach, not really beneficial)
They promote that sharing the dimensions will lead to better co-ordination in decision making across functional areas and following the 24' ways will result in better ROI( Return on Investment). They start up with a consultant led 90 days implementation of the FINANCE domain which is a pragmatic approach as Finance is the only division wherein a company would have good quality data readily available.
Lectures are going well in terms of content....only slightly behind in schedule but never mind, I m sure one day we will catch up! POD literally gives away so much of information in one lecture that you feel rich in terms of knowledge.
Tutorials are going fine as well and I don't face difficulty in doing things as the specifications are so descriptive. However, people in our lab face challenge in 'processing' the dimensions due to some stupid privilege issues which props up if we try to save our workspace on C:/ drive. The people who save on their flash drives can apparently run successfully. I will make sure to take my flash drive from now onwards. And of-course it works fine in my laptop's work environment as well.
Unfortunately, I have not started with my assignment yet. There is just too much of writing work for other units which I am still slogging to meet the due dates. Hopefully, I will have some progress done till I write my next blog. AMEN!!
Friday, September 3, 2010
Multi-Dimensional Design
Learnt about multi-dimensional database designing this week. Assuming we all know what a Cube...errr a multi-dimensional Structure is, let us know more about their design. A multi-dimension database is a collection of many such related cubes. The dimensions of the multi-dimensional structure provide slice and dice features for the data. Following points should be kept in mind while designing such database-
1) Identify additive and non-additive items(or facts) - For example price of products are non-additive while the number of units of a product are additive.
2) Sparsity and Density of the dimension -
Sparse dimension means that only a small fraction of the available data positions are filled. For example - if a cube has a dimension "Top 10 customer"then only few data positions will be filled as only few customer would fit in that dimension and rest all customers will have that data position empty.
Dense dimension would have larger percentage of available data positions occupied.
3) Star schema or Snowflake schema for storing the data.
Star schema has one main table(fact table)having composite primary key connected to the dimension tables through foreign key - primary key relationship.
From star schema example
Snowflake schema is similar to a star schema having normalised dimensions. There is still 1 fact table joined to various dimension tables which are further broken into closely related tables after proper database normalisation.
Snowflake is useful to handle sparse dimensions but star schema is good if the queries are expected to be simple as less number of joins will be required than a snowflake schema.
From snowflake schema example
4) Calculating measures from other measures - The decision has to be carefully made if a calculated measure has to be stored pre-calculated in the fact table or calculated on the fly as requested. The storage space, computational time and also the cross dimension nature of such measures are to be kept in mind.
5) Keep room for changing dimensions like customer addresses
Various tools used for designing multi-dimensional databases are MS Analysis Services ( which we are using in the tutorials :), Palo, Pentaho etc.
There are various methods to conceptualise a multi-dimensional model like-
1) Thomsen's diagram - A few vertical & horizontal lines is all you need to represent the model.
Its beauty is its Simplicity. Also POD's favourites!
2) Adapt's diagram - Symbolic representation of the model. Microsoft is one of its patron, so it might gain popularity.
3) Miscrosoft PivotDiagrams - Graphical representation.
Too much for today! Time to say goodbye and work on the assignments which are running faster than me towards the due date.
Cognos 24 ways coming up in next blog. It reminds me to order the free book from Cognos before they figure out from their BI reports that Monash students are among their TOP 10 buyer's and they stop shipping freebies!
Keep Blogging!
1) Identify additive and non-additive items(or facts) - For example price of products are non-additive while the number of units of a product are additive.
2) Sparsity and Density of the dimension -
Sparse dimension means that only a small fraction of the available data positions are filled. For example - if a cube has a dimension "Top 10 customer"then only few data positions will be filled as only few customer would fit in that dimension and rest all customers will have that data position empty.
Dense dimension would have larger percentage of available data positions occupied.
3) Star schema or Snowflake schema for storing the data.
Star schema has one main table(fact table)having composite primary key connected to the dimension tables through foreign key - primary key relationship.
Star schema requires a separate fact table called as Aggregate table for each hierarchy level.
From star schema example
Snowflake schema is similar to a star schema having normalised dimensions. There is still 1 fact table joined to various dimension tables which are further broken into closely related tables after proper database normalisation.
Snowflake is useful to handle sparse dimensions but star schema is good if the queries are expected to be simple as less number of joins will be required than a snowflake schema.
From snowflake schema example
4) Calculating measures from other measures - The decision has to be carefully made if a calculated measure has to be stored pre-calculated in the fact table or calculated on the fly as requested. The storage space, computational time and also the cross dimension nature of such measures are to be kept in mind.
5) Keep room for changing dimensions like customer addresses
Various tools used for designing multi-dimensional databases are MS Analysis Services ( which we are using in the tutorials :), Palo, Pentaho etc.
There are various methods to conceptualise a multi-dimensional model like-
Its beauty is its Simplicity. Also POD's favourites!
2) Adapt's diagram - Symbolic representation of the model. Microsoft is one of its patron, so it might gain popularity.
3) Miscrosoft PivotDiagrams - Graphical representation.
Too much for today! Time to say goodbye and work on the assignments which are running faster than me towards the due date.
Cognos 24 ways coming up in next blog. It reminds me to order the free book from Cognos before they figure out from their BI reports that Monash students are among their TOP 10 buyer's and they stop shipping freebies!
Keep Blogging!
Subscribe to:
Posts (Atom)