In my last post I explored the importance of language & communication in diplomacy and, by extension, the BI practice. In this post I'd like to consider two more tools of diplomacy and how they can be applied to the BI practice.
The Summit
A Summit provides a forum where all sides have the opportunity to speak directly with each other in a highly focused and most importantly, face-to-face format. In today's business environment it is too easy to fall victim to the limitations of email, telephone or even video communications. Even with the best video conference, few mediums of communication replace the extraordinarily "high bandwidth" of physical presence. (As an example within BI Consulting Group's experience, read my colleague Ed Martin's recent post reporting on our company-wide Summit held last week in Minneapolis.)
But common focus is also important. Well-organized summits often have a stated purpose agreed upon by all participants before or immediately at commencement. Sometimes ground rules even require that participants not leave until specified goals are met (think the Catholic Church's "White Smoke" summit -- or Conclave -- of Cardinals that elects a new Pope).
Of course a typical run-of-the-mill business meeting is a similar exercise... But when signficant, concrete progress must be made between parties of disparate backgrounds, framing the discussion in the specific terms of a Summit can be an effective way of setting the stage for the quality of interactions that will ensue.
The Treaty
The ultimate formal goal of any diplomatic effort is the execution of an agreement between all parties that sets specific parameters for behavior. The most obvious parallels in the BI practice are requirements documents, functional specs and service level agreements. In each case, the agreement clearly specifies the "rules" under which the signatories are required to behave.
In BI of course, one of the actors is the technology itself. In a Treaty, individual countries are held accountable for the performance of their borders, regulations and tarriff; in a Service Level Agreement, the IT support staff is accountable for the timely and stable operations of servers and applications. Well-written Treaties, SLAs and really any legal contract are useful to all signatories because they clearly define the expected performance of each participant and actions to be taken when that performance is breached. But the key concept is "well-written" -- a good agreement is clear and specific but not so obtuse that a lawyer is needed to interpret it.
An important component of an effective BI "Treaty" is the data validation report. A good BI implementation will include data audit reports -- confirmed as authoritative by all parties -- that compare warehoused data against source transactional data. These audit reports serve as the arbiters of performance that determine objectively and decisively whether the warehouse (in the "Tech Nation") is holding up its end of the Treaty by correctly reflecting source data (coming from the "Business Nation").
I plan to explore more tools of diplomacy in posts to come (trying to work "the Spy" into this discussion!), but as usual, in the meantime I'd love to hear your feedback and especially any other examples of Treaties and Summits in the BI practice.
Friday, September 25, 2009
BI and the Tools of Diplomacy: Summits and Treaties
BICG Summit 2009
The BICG Summit 2009 was excellent in helping meet other BICG employees, and becoming familiar with some of processes within BICG. As a new employee the timing of the Summit was perfect. The learning break-out sessions were very informative, and will helpful in future projects. Also the team building exercises and the evening cruise was enjoyable, and helped me get more acquainted with some of the BICG employees.
I look forward to the next Summit. Hopefully we can them more often than annually.
Read more about the BICG Summit at: http://www.biconsultinggroup.com/news.asp?newsid=68
Monday, September 21, 2009
Recommended Reading . . . "A Whole New Mind"
Time to share one of my favorite books of recent years. It's titled "A Whole New Mind: Why Right-Brainers Will Rule the Future" by Daniel Pink (www.danielpink.com). What does this have to do with business intelligence (BI)? Answer: it explains the benefits of combining left-brain (analytical) and right-brain (creativity) thinking in a fun, quick read.
Here's a book description from Dan's web site: "The future belongs to a very different kind of person with a very different kind of mind. The era of "left brain" dominance, and the Information Age that it engendered, are giving way to a new world in which "right brain" qualities - inventiveness, empathy, meaning - predominate."
There are so many important ideas in this book. Some are obvious . . . we live in an age of abundance and knowledge workers at lower cost are now plentiful overseas. The book offers valuable insight on how we in America can compete, differentiate ourselves and retool for the future. First and foremost, unlocking your right-brain creativity will be a deciding factor in this success.
Let me extend Mr. Pink's ideas and state that a BI professional needs to develop both sides of their brain. The most valued people are those who can understand complex analytical requirements (left-brain alert!) while empathizing with others and developing creative solutions to business problems (right-brain alert!). Sounds like the job of a BI expert to me.
For Star Trek fans, left-brain is pure logic (Mr. Spock). Right-brain is pure emotion (Scotty). Why not a combination of both (James Tiberius Kirk anyone?). Become the leader to which people gravitate. Adopt the correct mindset going in and help the corporate "Enterprise" reach its BI goals.
The author provides a very brief description in this short video (worth one minute and twelve seconds of your time): http://www.youtube.com/watch?v=syo6ecgclR0.
Your comments are appreciated.
Amazon link to book:
(http://www.amazon.com/s/ref=nb_ss?url=search-alias%3Dstripbooks&field-keywords=A+Whole+New+Mind&x=0&y=0)
Wednesday, September 16, 2009
BICG Hosting Two-Day Continuing Education Conference
The first-ever company conference, titled the BICG Summit, is taking place this week, September 17th and 18th in the Twin Cities Area of Minneapolis and Saint Paul. BICG staff members are participating in educational sessions on advanced topics specific to Oracle BI and EPM.
Complete details can be found here: http://www.
Monday, September 14, 2009
Essbase Is Music To My Ears
Take an informal poll of your fellow Business Intelligence (BI) associates. You may be surprised how many are also musicians. Guitarists, pianists and drummers lurk beneath their surface. I fall into this category. We can't be a Beatle, so instead we let BI applications rock our world.
Designing a successful Essbase cube is like playing a beautiful song:
- One has an established structure to follow (verse, chorus, bridge). The other has the structure of outlines, dimensional hierarchies and load rules.
- One has 4 beats to a measure (mostly) to create balance. The other requires its financial numbers to balance to their source.
- One allows us to venture out a bit and improvise. The other allows for creativity such as shared member rollups, custom formulas and more efficient calc scripts.
It takes many orchestral instruments to play a score. Likewise, Essbase is one of many players in the Oracle product suite. Make these products work together in concert and we have our own little BI symphony.Essbase brings music to my ears. How about you?
Friday, September 11, 2009
BI and the Tools of Diplomacy: Language & Communciation
In my last post I made a case for comparing the role of the Business Analyst in general technical projects to that of a diplomat carefully negotiating the interactions between the "nations" of business and technology. For this post I had planned to take that comparison to its logical next step and consider a variety of tools & techniques of traditional diplomacy and apply them to a typical Business Intelligence practice. In the interest of everyone's time I will split up this discussion among several posts, starting with what I consider the single most important tool in the practice of diplomacy: language and communication.
By far the biggest barrier between nations has nothing to do with physical separations -- political borders, distance or even geographic features like deserts, mountains, rivers and seas. For example, Australia, the UK and the United States are phsyically divided from each other by thousands of miles of open ocean, yet they are some of the best friends among the international community. I argue that the single most difficult impediment between nations is language and open communication. How can two people possibly be friends if they don't talk to each other? And what's the point of talking if they can't understand what the other is even saying?
Let's look at language first. A good example in Business Intelligence projects is financial reporting. The world of finance has a rich and well-established vocabulary of terms that have very specific and often complex meanings and implications for a business user, yet may have a completely different meaning, if any, to the technologist. Consider the two most basic of these financial terms: Debit and Credit. What these terms represent in a business context is the complex system of balance sheet accounting that is fundamental to all modern businesses but is also, well, foreign to most technologists.
The most rudimentary, bare minimum approach to crossing this barrier is the use of a simple dictionary or phrasebook - so that at the very least, the technologist will know how to find her way to the metaphorical bathroom in the business world. Of course, in the long run, a phrasebook definition of "Debit" will be of little help. The technologist will forget to multiply a "debit" by -1 when the business user expects her to, and the business user will end up the butt of a Dilbert cartoon about using or not using SOAP. A better way is to teach the whole language, not just piecemeal phrases, with the end goal of achieving a level of proficiency that will allow the technologist and the business user to have a meaningful conversation about complex issues that are important to each side.
The takeaway for your BI practice? Establish some way for each side to learn the other side's fundamental professional terminology and the concepts behind the language. Imagine the quality of conversations we would have if technologists were to learn the basics of Balance Sheet Accounting, or if the business users could learn the concepts of star schema design. When designing the instruction, remember that the detail needn't be exhaustive - the point is to encourage a meaningful conversation, so that the business user can understand the importance of conformed dimensions and the technologist knows the difference between a debit and a credit.
A good, low-impact, "Web 2.0" approach to encouraging this conversation would be to set up a company Wiki so that representatives from each side can contribute and respond to content (even by refering to existing content available elsewhere) that explains their fundamental professional terminology and the underlying concepts. Even better would be examples to illustrate how these concepts apply to their organization's operations.
Having a common language is important, but we need to use it too: Establishing active and effective paths of communication between nations is a cornerstone of a healthy relationship. Other tools of diplomacy - standards, summits, treaties, even espionage - can all be considered ways of enriching the communication between nations. I will focus on these tools in my next post.
Until then, I'd like to hear your thoughts. Do you have any other suggestions or better, good examples of successful strategies in your BI practice for breaking the barrier of language?
DAC -Prune Days Can Now Be Set By Source System
In the previous releases of DAC, prune date parameter was set at the execution plan level. In DAC 10.1.3.4.1, prune dates can be set at the execution plan level for the entire plan or in the execution plan parameters for specific source connections. Dates set at the source level in the parameters override the date set at the overall execution plan level. If no dates are set at the source level in the execution plan parameters, the dates default to the execution plan level.
Posts
