Bi and strategic decision making
•Transferir como PPTX, PDF•
1 gostou•1,759 visualizações
Presented at the NZ Effective Management Accounting Conference, 2011.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Bi and strategic decision making
Semelhante a Bi and strategic decision making (20)
Último
Último (20)
Bi and strategic decision making
- 1. BI and Strategic Decision Making Phillip Higgins Process Intelligence Ltd
- 2. Business Strategy • Strategic plans must be available to support strategic BI – BU level – Shared enterprise level • Coherent set of measures representing departmental objectives
- 3. Strategic Decision Making • Made by an organisations top leaders • Infrequent • Critically affect an organisations health
- 4. The BI Roadmap: Gartner's BI Maturity Model
- 5. Accountants Role • SME’s over financial and some operational data • Let IT handle implementation – Experts in avoiding technical debt • Reusability • Scalability • Integration
- 6. Technical Debt • Is about choosing solutions which are expedient in the short term • More costly over time
- 7. New Engagement Models • Agile approaches eg Scrum, XP • SME’s working closely with BI staff
- 8. Agile or planned? • Organisational culture • Requirements for BI – Tactical report development (perhaps more agile) – EDW implementation (perhaps more plan driven) • Both forms of BI development will require sitting with users to determine requirements – the second form is likely to be within a more structured framework
- 10. Assessing your Requirements for BI • Risk and complexity are the main determinants of either agile or planned engagement practices • User adoption is everything • Working closely with users is required for both agile and plan driven BI
- 11. Note on Planning • Rigid plans will generally fail for many BI solutions: – Impossible to fully specify solutions as problem domain too complex – Most solutions involve high degrees of technical and business complexity so unknowns omnipresent – For both planned and agile approaches requirement revision should be accounted for
- 12. Collaborate and Review • Engage throughout the entire delivery cycle • Review work frequently to ensure correctness • Insist on testing as new work becomes available soon as possible
- 13. The Two Big Gaps • The BI Delivery Gap – Delivery cant keep up with changing requirements • The Insight Gap – The business does not possess the required process or expertise in order to make sense of the data they are collecting
- 14. What's are we in for in 2012 • Mobile computing – Ubiquitous – Huge growth • by 2013 33% of BI features will be consumed via handhelds (Gartner) • Cloud will gain acceptance • Big Data gone mainstream • Visualisations and Mashups mainstream
- 15. Conclusions • Reaching a BI sweet spot – Advanced technology mainstream – Greater business relevance
Notas do Editor
- Today I’ll talk about a bit about requirements for strategic decision making and planning from a BI perspective.By that I don’t mean concrete business requirements such as scenarios or slice and dice or drilldown but will rather I’ll look at it from an implementation perspective and offer some strategies for achieving systems with the required flexibility given the often enormous overall complexity of strategic decision support and planning tools. BI assets can and should roll up into strategic perspectives and I’ll provide some insight into managing the overall complexity utilising agile development methods.
- It is increasingly becoming clear that organisational capabilities are more enduring than market positioning or tactics as an enduring source of competitive advantage.To incorporate strategic objectives into BI production, it goes without saying that business strategy must first be defined.Strategic objectives should be defined for the business unit, but also the enterprise as a whole. Whether you use and EPM or other framework to derive BI KPIs is up to you. But its crucial that strategic plans be translated into a coherent set of measures that gauge performance and align Bus and departments to common goals. An integrated strategy that encompasses both the business units and an integrated perspective should be considered.Strategic plans will inevitably translate to measures around financial, operational, customer and HR objectives. Business Unit scorecards will cascade in modified form to department and team objectives.
- Studies of strategic decision making have focussed on both the extent that decisions are rational and the extent to which power influences the decision making process.I’m not going to take up these debates but I would say I am truly surprised as to the immaturity of the research in this area. In any case one point that the researchers do roughly agree on is that strategic decisions are those decisions that are made by the top leaders of an organisation that critically affect an organisations health. They are typically infrequent in nature and sporadic. We’ll see that that has major impacts on the requirements placed on strategic score-carding and analytics systems. In particular it means that systems should be built to be very flexible and support a wide variety of data in order to provide an overall view of the enterprise. Strategic systems should roll up from operational and tactical management information systems but not be limited by them.Strategic planning that defines what the strategic direction of the company is, why it wants to get there, and how to get there. This may be part art and part science, but to complete the scientific portion accurate actual and forecast data is crucial.
- Gartner's BI maturity model is alongside the TDWI’s maturity model probably the most widely cited model for the BI roadmap.In level 1, companies are unaware of the value BI provides to the organisation.Unaware organisations are typically characterised by spread-marts and manual reporting.For companies who are positioned in level 2, tactical systems provide a small number of typically managerial users with actionable insight however systems tend to be stove piped and often results are not replicable. Systems may lake history and often lack integration. You won’t typically find a BI competency centre in such companies however they will contain staff dedicated to information management and analytical functions.Focused level three companies display successful BI initiatives that are often funded from specific business units. You’ll often find the finance department is leading the way in these companies however operational business units are often lacking the insight they need.Moving from a focussed to a strategic perspective will involve a degree of integration as varied data sources are conformed to provide an multi dimensional view of the business encompassing financial, operational, HR and customer dimensions. In addition you will see companies consolidate BI systems to support these objectives. In companies that are moving from the focussed level to the strategic level you will see a broadening of the user base to encompass users from various business units. In addition you would expect a business performance framework to have been selected or to have been discussed. For companies looking to move from the focussed to the strategic level it goes without saying that strategic plans and maps must have been finalised and available.
- Accountants have a unique part to play in BI as being watch guards over a companies financial data. They also form a core user group to BI. Finance departments are major users and sponsors of BI. The tendency is to want to get in and have a hand in implementation too however this may not always be ideal. I’d say, let your IT staff handle the implementation details but work very closely with them over the entire process to get the best outcomes. This engagement can be very conducive to successful outcomes if performed well. IT trained staff can help you meet the technical requirements that you have for a project. ReusabilityReusability will enable solution components to be reused across solutions; lowering costsExtensibilityExtensibility will enable your solutions to continue to be developed and extendedIntegrationIntegration will mean that data is collated just once and available to everyone to avoid these costs moving forward
- Technical debt is all about choosing solutions which although save time and money in the short term, are more costly to maintain over time.Often you will find very good reasons for doing so but this trade off must be made explicit. Technical debt is incurred both unintentionally and intentionally. Avoiding unintentional debt however is about getting it right first time but also ensuring reuse and conformance to an architecture that makes sense. Engagement with skilled IT staff is key here. The second type is performed for compelling ROI or other considerations which I wont go into here. I will say that you should document any tradeoffs and should budget for getting it right later. Otherwise it perhaps wont happen and you’ll wear it in the operational expense downstream.I like the comparison of technical debt to architecture. Architecture, although invisible, will provide positive value by ensuring the adaptability and maintainability of systems. Technical debt is also invisible but represents a cost instead of providing value. You should more attention to technical debt than bugs since bugs because they are visible will be more likely resolved. Both represent a cost to implementers.Some of New Zealands very best databases have been created with rigid attention to underlying architectural principles which aids in both analyst and business agility. New reports and mashups are a breeze since the data structures have been well thought out by skilled industry practitioners.
- Planned approaches to IT development are being complimented by agile methods that involve a high degree of interactivity between SME’s and IT staff. Agile methods favour adaptation over rigorous planning as requirements are elucidated by subject matter experts to technical staff. You can make big gains on turnaround times by looking at these alternative approaches. Its my opinion that agile approaches really come into their own when projects consist of very high levels of business complexity that would take a very long time to document and communicate fully. BI is becoming a lot more about decisions and a lot less about data and user-driven BI is becoming a reality. As a practitioner that’s exciting because it means a high uptake of solutions. The technical specs of old listing data columns, their length and type are still relevant but more and more users are working with IT staff to answer business questions. That entails a high degree of collaboration however agile is not always right and so I’ll look at some key variables on choosing an agile or planned approach to development.
- In deciding on an approach to engagement two major pieces of the puzzle to consider are the requirements for BI and the culture of the organisation we’re working within. We need to differentiate our approach somewhat depending the specific context we’re working in. Its been my experience that a single approach will not work in all situations.What I will stress however is the need to have development and implementation staff communicating with the analyst and management users. If you can get them sitting together on the project do that. If you’re working in different locations or even countries ensure you can use technology to get this communication happening. In terms of overall project duration, having IT and finance and accounting staff working closely together can really boost delivery times and enhance BI quality. So what I mean by that is not only the quality of the software, report or the model but the quality of the business relevance and insight.
- We assess the organisation along the dimensions of discipline and agility as part of the BI readiness assessment. This will help you to decide on the preferred engagement style to be adopted in the organisation.Organisations that have achieved high levels of both agility and discipline will provide the best BI engagement environments since it will be easier to merge tactical and strategic focuses by balancing time to market driven work with work that say, implements KPI dash-boarding for CPM objectives.Startups will tend to emphasise fast return on any investment utilising an agile approach whereas hierarchical organisations will often favour more planned approaches. In any case, its vital you understand the organisational environment you are in before determining whether to go agile or planned. Agile in bureaucratic organisation is unlikely to work in programme form and proposing an extensive plan for creating business insight in a start up is not going to work well either. You’ll often find that the IT department will think differently to the user base and that’s something you’ll have to work through. Generally your users will want stuff yesterday. That works for tactical report development but taking on a complex modelling project without a high level of organisational discipline could prove tough going. Along with looking at your organisation you’ll therefore need to examine your requirements for BI.
- The deliverables of the BI roadmap should be carefully assessed according to risk and complexity. Low complexity operations such as software upgrades and patches could be best be managed with lightweight planning; high complexity high risk (but nevertheless high return) projects could best be staffed with agile teams of SME’s. In assessing the requirements for BI we never lose sight of the goal of user adoption. We can ensure user adoption by working closely with them during all stages of the development process - whether agile or waterfall.Having business users feed into project conception, design, development and testing but also the support and maintenance processes will assist you in delivering value and encourage them to use the tools that you have been creating together. I don’t want to get to hung up on methodologies whether agile or planned as again the choice of method will depend on a range of factors including the skills you have in house and the experience you have had in the past with different methods.I don’t get too hung up on methods although I favour some flavour of agile for most BI. But I’ve done plenty of waterfall and its worked well too.What’s the difference between a methodologist and a terrorist? Answer: you can negotiate with a terrorist.
- It’s a truth that rigid plans are not often constructed and if they are then they often fail for many BI projects. It’s sometimes really hard to fully specify the solution as the problem domain is to great or too complex and so there's plenty of unknowns.So what we need to do is really to minimise the technical complexity as much as possible and make the most out of the toolset we have.Be ruthless when it comes to feature creep. A lot of developers will naturally want to add this or that technical feature when they’re not required. I’m sure you know what I’m talking about – it could be the Ajax calls in the UI that were never required or the report linking that the user doesn’t want. Just be ruthless here- don’t over complicate your application with unnecessary technical feature points.If you do lots of up-front planning utilising a waterfall approach, my advice is to have the plan validated. Intense scrutiny is one way of doing it- have both business and technical stakeholders examine and criticize the plan. Another option is to use multiple methods of estimation such as task a break down and a use case points style of estimation. Always focus on the areas of greatest risk in the plan – those areas where the technical or business unknowns are the greatest. You’ll still never cover all the bases and you’ll always have uncertainties but by concentrating on the big rocks you’ll reduce their impact.Complex data manipulation applications often involve some change in the requirements as the business reorganises and reinvents itself which should be accounted for in any planning.
- Demands on subject matter experts are increasing as we move from an older model of defined reports to a new model that produces flexible systems capable of meeting the demands of strategic and general change. The old model of defining column headers and elucidating roll up logic is moving to a more open ended model that involves working with techies throughout their entire delivery cycle. Modern BI involves testing throughout the entire delivery cycle and improves delivery reliability by presenting only well scrutinised data.
- Engagement from start to finish with IT will help bridge two of the big gaps that are flies in the ointment of BI projects.The first is the BI delivery gap where since elucidating the requirements the business moves on.The second gap occurs where you have a lot of data collected but staff working with the data do not fully understand its business significance.The new trend towards collaboration to achieving successful outcomes, by enabling rapid development and by promoting cross fertilisation of ideas is helping to bridge these gaps.
- No one here could deny the utility of handhelds for business. Handhelds provide unique opportunity for messaging and customer interaction scenarios and many other scenarios. Supplying data back to data consumers is the aim of BI and so mobile BI is a no brainer. Handhelds have further deepened the consumerisation of IT and defined a new paradigm for data accessibility. Most to benefit will be senior managers and executives who will use the accessibility features of their tablets to their advantage for performance management and decision support purposes. But any user requiring access to information for business purposes on the road or outside the office will benefit.This year I believe a number of companies will wrestle with end user empowerment and this will become an agenda for sales teams who do not possess what is becoming a powerful tool of advantage. Cloud solutions with their sometimes significant data transfer costs have not looked attractive to many firms however new competition in this space affords businesses the real chance to look at BI solutions utilizing cloud architectures. Appliances keep getting bigger and distributed storage and processing technologies are becoming attractive and somewhat available tools for massive data processing operations. So Big is Good.Bi is becoming increasingly pervasive and rich end user tools are becoming available with scale which we have never seen before. Multiple million rowset calculations are available in MicrosoftsPowerPivot tool and have astounding performance. Mashing up large data sets from multiple subject matter marts to provide coherent and complex insights is really enabled in this tool. You’ll also see advanced visualisation going mainstream with a number of new tools on the market that integrate with delivery portals such as sharepoint.
- So just to sum up, I think we are reaching a sweet spot where we see advanced technologies becoming mainstream with radically lower cost and new approaches to development leading to greater strategic insight than we’ve had in the past. In memory, mobile and big data are all available at a fraction of the procurement and maintenance cost of days gone by and at the same time we are seeing new approaches delivering fresh insight that is more business relevant than ever.Good luck with your reporting and analytics.
- If you do think of any questions after today feel free to send them to philliphiggins@gmail.comThanks you