In the Field with our Experts

The “And” Syndrome: How to Keep BI Development Proactive

By Mary Anne Hopper, Senior Consultant

Remember way back when your Business Intelligence organization was a small group of one or two people?  And then business found value in what you were producing so your group grew?   And then you created clear roles and responsibilities for the team?  And you started creating project backlogs?  And your group continued to deliver great results for the business?  And your team grew more?  And then things seemed to slow down in your ability to deliver and it was hard to figure out why?

Could it have been that each time you delivered new functionality, someone had to stop what they were doing to support it?   The impact of this can mean missed delivery dates and ticked off end users.

Each time the business needs something they have the ability to talk directly to the person who built the functionality for troubleshooting everything from data loads to data anomalies to report issues.  So, every time functionality is introduced into the environment, somebody is in charge of supporting it in addition to their ongoing project delivery responsibilities.

I call this the “and” syndrome.  Nobody can support “insert system/data/report functionality” and “insert system/data/report functionality” and “insert system/data/report functionality” and “insert system/data/report functionality” [I’ll stop here because you get the idea] without impacting the ability to deliver new functionality.

Here are some tricks and standards I’ve seen in different organizations along with their results.

Across the board reduction in project allocation (eg 10% of developer’s time is dedicated to support issues)	This can wreak havoc with project planning as the project team never knows when that “10%” will occur
The development takes turn with support on-call duties	This causes a lack of continuity with development efforts, especially when developers are moving in and out of support issues
The person with the least development impact supports the issue	This results in prioritization discussion each time there is an issue that needs to be addressed
The person who developed it will support it	This creates the “ands” scenario and does not accommodate staff or role changes as the organization grows

Does any of this sound familiar to your organization? If so, it’s time to step back and review your project plans. One of the biggest mistakes BI teams make is not acknowledging the fact that BI projects will likely have multiple releases.  Each new release will likely be a new project with its own plan.  Moreover IT management should acknowledge that BI needs support resources—including problem resolution experts, training, and documentation specialists—who will support new releases and enhancements to BI applications and the data they use.  Factoring in these issues will allow your group to get back to delivery, and stop supporting all the “ands.”

---

Mary Anne has 15 years of experience as a data management professional in all aspects of successful delivery of data solutions to support business needs.  She has worked in the capacity of both project manager and business analyst to lead business and technical project teams through data warehouse/data mart implementation, data integration, tool selection and implementation, and process automation projects.

MDM and All That Jazz

By Rob Paller, Consultant

Recently, senior consultant Bob Wall mentioned building the team as one of four proven starting points for getting your MDM program rolling. By now, you have probably identified the C-level executive experiencing the most pain as a result of working with unmanageable data. You have even gone so far as to identify a small project that allows you to demonstrate the value that MDM will provide the company.

However, the success of your MDM pilot project and overall MDM strategy will come down to the team you assemble to support it. Interestingly enough, there are a few parallels that can be drawn from what makes up a good jazz ensemble that can be applied to building your MDM team. Every musician must possess a core set of competencies—just like employees possess in order to do their jobs. However, in order for a jazz musician to excel, he must possess an additional set of skills that is, for the most part, unteachable, but enables him to reach a level where his inspiration and creativity matches his ability to execute. 

• A jazz musician must be a virtuoso of his instrument in order to communicate what he visualizes in his mind instantly through his instrument. An MDM team member must be a subject matter expert with an innate technical understanding of the source system or a similar understanding of the business processes surrounding the subject matter.

• A jazz musician must possess a trained ear that is not only able to identify something being "in tune" or "out of tune," but hear the melodic structures and chord progressions. A soloist must be able to adapt to the piano player making chord substitutions underneath the soloist's performance. Any member of your MDM team needs to be able to find the nuances in the business when it comes to defining the core subject areas of your business. For example, defining what a "student" vs "alumni" vs "donor" means to your university.



• Many jazz musicians are able to recall hundreds of songs at a moment’s notice—not only the melody, but the chords as well. Your MDM team must understand how and be able to explain the countless business processes and policies surrounding your master data.


• A good jazz musician must be able to listen and interact with the group in the present moment and contribute to improving the overall quality of the performance. This is one of the most important skills that an MDM team member needs to possess. The MDM team must be willing to listen to the rest of the business and communicate effectively. There are no ivory towers in MDM or jazz. 


Keep in mind when assembling your MDM team that it must be a balance of members from both the business and IT—much like a jazz ensemble consists of a balance among percussion, brass, and/or woodwind instruments. If you are unable to find a balance, you risk discord in what you produce.


photo by Fillmore Photography via Flickr (Creative Commons License)

---

Rob Paller is an expert at business analytics and database administration. Since joining Baseline, Rob has been responsible for developing a case analysis system to streamline the oversight of food assistance benefits, implementing a common citizen data model, and assisting in the rollout of a new public assistance data model integrating data from over 10 years of legacy with a new benefit eligibility determination system.

Why Data Governance Matters in 2010

By Andy Field, Senior Consultant

Imagine a large family with many teenagers and one car. It’s Friday night, the parents are out of town, and the teenagers have plans in different parts of the city.  On top of this, everyone is broke and the car is out of gas.  This situation has been coming up more and more over the last few years.  Over time some of the kids get jobs and buy their own cars, trucks, motorcycles to get around.  They don’t figure in the cost of insurance, repairs, maintenance, or parking.   In retrospect they realize they can’t afford to keep this up and some of the vehicles, especially the motorcycles, just don’t meet their needs when, say, the weather gets bad.

If you can envision this  then you have a pretty good idea of what occurs in many companies that have not implemented a data governance program.  There is no common data warehouse platform, let alone other shared data assets, costs are out of control and there is no room to grow. And there are no formal ways of making or delegating decisions. Things go from bad to worse.

What if the kids got together and met with their parents to lay out their transportation needs in advance?  They may figure out that if they had two cars and a truck, instead of one reliable car, an old clunker, a beat up pickup and two motorcycles that 90 percent of their needs would be met over the foreseeable future at half the cost.  The parents and kids could also lay out who is in charge in their absence and how conflicting needs are to be resolved and gas costs shared.  With the savings over the current situation some money could be put in a pot for a taxi or rental fund when there is an extraordinary need for transportation.

Hopefully you can appreciate what a sound data governance program can do for your company.  It may substantively end years of organizational friction, bringing with it the inherent benefits of a collaborative work environment while reducing costs and improving information accessibility and delivery for everyone to help address business opportunities. The question is: are you ready?

Data governance is an essential component of an overall Enterprise Information Management program.  It provides the forum and processes for making all significant organizational and policy decisions with respect to how data is managed in the enterprise.  It includes formalizing decision processes around privacy, security, and accessibility of corporate information. It enforces accountability at the business level, specifically among subject matter experts, key business users, and data stewards. And it sanctions standards around products, customers, and other master data.  

Data governance is difficult, often broad in scope, and requires a structured process to get right. Data governance is typically deployed incrementally to address issues that span functional, project and geographic boundaries.  For local decisions where the scope of the data decision will only impact one project the data decisions may be limited to a subset of data constituents (though sanctioned by the data governance council).  At the other end of the spectrum when decisions need to be made that may have serious consequences to the brand perception of the company (such as privacy policies)  then executive input is required to balance the perspectives of individuals directly representing this leadership such as legal (General Counsel), marketing (Vice President), operations (COO) and IT (CIO).

So if your company reminds you of the family described in this blog post there may be a better path to family harmony through the implementation of data governance.  Understanding that data governance can involve the whole “family” with benefits for all who use information in their jobs is key to ensuring that the right constituents and scope are considered when planning its long-term deployment. Maybe 2010 is the year you’ll get started. Good luck on your journey!

photo by brightroyalty via Flickr (Creative Commons License)

---

Andy Field has been involved in information management activities for over thirty years in both the private and public sectors internationally and domestically. He has held senior leadership positions accountable for establishing Enterprise Information Management practices in several organizations, including Fortune 500 companies. Andy has also consulted with clients from many industries and government sectors over the years and established and ran as president a consulting firm specializing in strategic information systems planning. He has broad experience in both operational and data warehouse projects from both a hands on and leadership perspective. Andy is currently a consultant specializing in Enterprise Information Management.

BI in Healthcare: Imagine the Possibilities (a Parting 2009 Holiday Wish)

By Carol Newcomb, Senior Consultant

Imagine, for a moment, that we have moved on from the ugly, tedious healthcare debate of 2009 and the year is 2014. Pretend that Lieberman has joined the Republican Party and that the 2010 ‘Kennedy Healthcare Reform Bill’ passed with a sweeping majority of both Democrats and Republicans, and healthcare providers and insurers are cooperating to provide decent, affordable, cost-justified healthcare. No death panels for grandma and even people without jobs can see a doctor. Now, what have those healthcare organizations been able to achieve in the last four years with their eye on BI? 

The Healthcare Providers

When the bill first passed, healthcare providers received Federal grant money to shore up their internal IT infrastructure. But it wasn’t just for technology; it was expected that CIOs would work with the Medical Directors, Nursing Directors, Lab Directors and Admitting Department to inventory the myriad of ‘systems’ and ‘packages’ that struggle to support daily operations.

They had to talk to Finance, Engineering, Purchasing and Human resource users. They had to reach out to the Physician Contracting Group, specialty physician networks that lease space in the hospital facilities, and even the Community Outreach Office to understand how they were handling transactions, contracting, marketing and recruiting.

They were responsible for taking the time to build a comprehensive logical data model of the entire organization, from Building & Grounds to Legal that every system user could understand and that reflected the operational AND analytical objectives their data was intended to support. Even a comprehensive data dictionary, two years in the making and still a work in progress, is available in 2014. That dictionary has information about source systems, data definitions, transformation logic and business rules for appropriate usage.

Customized dashboards for supervisors, managers and directors are available 24/7 that contain a myriad of types of summaries, from staffing and productivity to patient safety alerts or orthopedic device failure rates. End users can customize their dashboard and drill into multiple levels of detail, depending on their question of the hour.

ER physicians can look up the history of a patient that appears on their doorstep and get a comprehensive longitudinal history with shared data from other regional hospitals, since data can now be shared for patient care purposes. If an ER physician needs to speak with a patient’s regular physicians, that information is available at the touch of a button. The price of treating patients in the ER has dropped 40% due to the availability of data that was never there before, a reduction in unnecessary tests and more appropriate treatments.

The Insurance Companies

Insurance companies have NOT been given any Federal funding, but they HAVE been saddled with the responsibility to revisit their actuarial models and include beneficiaries with chronic diseases and pre-existing conditions. As it turns out, they are not that much more expensive to insure, when the cradle-to-grave concept of preventive services, coordinated care, counseling and therapy are included in an individual’s benefits.Instead of selling to employers and unions, insurance companies are responsible for covering populations in an entire geographic region, which prevents them from cherry-picking on the healthiest beneficiaries. If an insurance company can prove, with sufficient data, that the population they provide coverage for is indeed sicker, costlier and in need of more intensive services, then they need to work with both the State government and local physician networks to ensure that physicians are providing cost-effective care.

As a result, the variability across regions, previously attributed to doctors driving up the ratio of services-to-patient, reflects the true healthcare needs of the population, not the doctor’s income expectations. And insurance companies are held accountable by the Federal government to work hand-in-hand with physician advisors to determine which are the cost-effective treatments versus which are unnecessary. These studies are grounded in broad, population-based studies and are backed up with solid statistics.

Insurers are also expected to help medical and nursing students bear the cost of their education, and will place students in medically underserved parts of the country where skilled labor is scarce, so that students don’t incur massive debt to become medically qualified in their profession. Since insurers have been collecting claims data for decades, they are best equipped to use that data in forecasting the need for services, and underwriting studies to investigate emerging technology and preventive services.

The Professional Network

Finally, the professional network of doctors, nurses, social workers, mental health workers and long-term care providers have started on an ambitious, but not impossible, effort to share patient information. This is possible because the States sanction transfer of data based on security and visibility rules as determined through statewide data governance panels. Since platforms for data storage have been standardized based on the ICD-10 and SNO-Med codification systems, it is expected that all qualified professionals have ready access to relevant patient detail at the point of care. This is still a work in progress, but the goal is to have data that support the provision of services to ensure they are appropriate for the individual, and coordinated with other services.

When, in 2014, I look back on 2009, I hope this year represents the year that healthcare finally emerged from the dark ages. That is my holiday wish for BI in healthcare. Imagine the possibilities……

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.

’Tis the Season for a Data Governance Carol (Part Two)

By Rob Paller, Consultant

 

The writing was on the wall, and Ebenezer was beginning to comprehend that while the mergers and acquisitions looked good on Wall Street, the company was imperiled by the aftermath of poorly integrated systems, an absence of proper data management, and a gaping void in the governance of the company’s data. Furthermore, Ebenezer knew that one more ghost had yet to call upon him. Never before had the fear of uncertainty enveloped Ebenezer, but tonight was different.

The Ghost of Data Governance Future

No sooner did Ebenezer begin to calm his nerves, when from the shadows of Ebenezer’s office, the Ghost of Data Governance Future appeared. Ebenezer’s pulse quickened as he did not want to acknowledge the ghost’s presence or what the ghost would ultimately share with him. It was with great reluctance that Ebenezer agreed to go with the final ghost.

Much to Ebenezer’s surprise, their travels did not take them very far into the upcoming decade before trouble surfaced. Poor Bob had suffered through another year and a half of cobbling reports together before reaching his saturation point and submitting his resignation. The remaining analysts scrambled to glean what they could from the frazzled, empty shell that was once the brightest among them. Surely a lone analyst would not beckon the fall of a Fortune 500 company, but it would begin the unraveling that followed in the months to come.

After Bob left the company, the remaining analysts fought to produce the fiscal reports on time. The data fixes that Bob orchestrated in the various systems to reconcile the reports were not being done. Some analysts were entertaining the idea of bringing in an outside firm to try and help address the problems, but IT was adamant they could shore up the problems on their end. Slowly the company’s competitive advantage began to erode and confidence on Wall Street went with it. It wasn’t long before rumors of bankruptcy began circulating. By then, Ebenezer had seen enough.

He couldn’t stand to see the company he so proudly guided through the first decade of the new century crumble before his eyes. He asked the Ghost of Data Governance Future if it was too late to turn things around. And if he promised to acknowledge all the data management, quality, integration, and governance issues that had been brought to light, would the company be able to avoid an inevitable collapse? But the ghost made no promises and offered no reassurances that the company could be saved. He simply returned Ebenezer to his office and quietly retreated back into the shadows of the office.

Ebenezer Wakes Up

Ebenezer, startled awake by the sensation of falling, quickly realized that he was still seated in his office chair. However, the relief was short-lived as he wiped the sleep from his eyes, only to see that the once-organized stacks of paper on his desk were strewn across the floor. Dream or no dream, the gravity of the situation was beginning to weigh on him:  The single most vital asset neglected for the past decade would be responsible for saving or crippling Ebenezer’s company.

There would be no quick solution. In order to build the momentum necessary to stay the course, Ebenezer needed to identify projects that would make an impact with the right sponsors who would, in turn, spread the word.

Slowly, over the course of several quarters, Ebenezer began to see the results of his mission to properly manage his company’s data as an asset. There were policies in place that supported the data governance initiative, and there were regular meetings to review the company’s progress with regards to an industry-approved maturity model. Data quality was being driven back to the source systems whenever possible.

There were formalized processes in place to deal with exceptions. There were master data hubs that dealt with integrating the various sources of master data across the company.  Data was beginning to move with the precision of a fine time piece.

---

Rob Paller is an expert at business analytics and database administration. Since joining Baseline, Rob has been responsible for developing a case analysis system to streamline the oversight of food assistance benefits, implementing a common citizen data model, and assisting in the rollout of a new public assistance data model integrating data from over 10 years of legacy with a new benefit eligibility determination system. He also believes in Christmas, and he'll gladly give you a shilling to buy the prize turkey for Christmas  day.

’Tis the Season for a Data Governance Carol

By Rob Paller, Consultant

Charles Dickens wrote the classic story A Christmas Carol over 165 years ago, and since then, there have been countless adaptations from the stage to the silver screen. While watching Disney’s latest adaptation with my family, it dawned on me not long after Scrooge declared Marley “dead as a doornail” that there was one adaptation of this classic that isn’t nearly as dead as Marley. It was when Marley came back to visit Ebenezer that this adaptation started to solidify.

In this adaptation, Ebenezer is played by the CEO of a Fortune 500 company, Marley is the CIO, and Bob Cratchit represents one of the many white collar workers at this company.

This tale begins with the present-day departure of Marley from the company. The past decade had presented this company with the usual challenges: Y2K, September 11, the market meltdown, and lingering economic woes. The company had weathered most of these storms but faced an uncertain future—even after completing several successful mergers and acquisitions. Ebenezer was a frugal CEO, but even he knew that the current economic climate would be hard on the company. Even with careful planning.

Ebenezer was working late one night in December trying to plan for the upcoming year as the year-end figures were coming in. He realized that with several companies still reporting their information independently, it was going to be another long night. As each minute passed spent digesting spreadsheet after spreadsheet, Ebenezer fought to stay awake—but it wasn’t long before Ebenezer drifted fast asleep. He would soon be visited by Marley in his dreams.

Marley was shackled in chains, carrying the burden of every system introduced by a past merger and acquisition—only to be poorly integrated. Marley warned Ebenezer that if these systems were not properly integrated, if the data was not properly managed and mastered, and if they didn’t get a grip on their data governance, he could either risk being ousted by the board or losing the company under the weight of these mergers and acquisitions. To make sure Ebenezer understood the gravity of the situation, Marley told him he would be visited by three more apparitions.

The Ghost of Data Governance Past

The Ghost of Data Governance Past was the first to visit. This ghost would bring Ebenezer back to see how the company operated long before the mergers and acquisitions. While things were far from perfect, the issues surrounding data quality, compliance, security, and master data management were easier to address. This was a time long before many of these issues were on the radar of many CIOs. Back then, data warehouse teams did their due diligence to mitigate the risks associated with the lack of formalized processes and technology solutions to address these problems

As a result, there was a semblance of a single version of the truth and trust placed in the reports produced. But as the decade went by, the company grew organically, and through each merger and acquisition, the ability to integrate information became impossible. Ultimately, the company was left supporting federated systems that fed multiple warehouses and relied on multiple reporting systems.

Upon Ebenezer’s return to the lobby of his office building, he rushed to the elevators in a panic. Now that he had seen the 30,000-foot view of the path his company had traveled, he was scrambling to figure out how and where to start solving his company’s massive data disaster. Unfortunately, for Ebenezer, he would be visited by the next ghost before he could jot down a few scant ideas.

The Ghost of Data Governance Present

The Ghost of Data Governance Present was seated at Ebenezer’s desk and offered Ebenezer a seat in one of his own guest chairs. The ghost laughed while looking over the stack of reports that Ebenezer had left behind. With a swipe of the ghost’s arm, the stack of papers flew through the air, landing haphazardly across the floor. The ghost went on to explain that it didn’t matter whether the reports were collated or not—they couldn’t be trusted any longer. The ghost only needed to bring Ebenezer back a few weeks to show him all the trouble that Bob Cratchit had gone through to finalize the numbers for these reports.

Bob scoured over the numbers—only to be forced to dive deep into the tables in the countless systems to validate the numbers. When Bob discovered what he thought was a data quality problem, there was no process in place to fix the data. The subject matter experts could only commiserate with Bob about the problems and had little recourse in solving them. When all was said and done, Bob’s effort required a 60-hour week every fiscal period. Before he had a single iota of confidence in the results. Before he could send them on to Ebenezer.

The ghost reminded Ebenezer that he had only witnessed a single day of Bob preparing these reports, and that Bob had been suffering through this for years. He was the lone analyst capable of producing these reports since he had been around the longest and understood the intricacies that each new merger and acquisition introduced. But Bob could only be the unsung hero for so long. Eventually he would burn out and move on. The thought that Bob could leave the company was a burning question that Ebenezer tried to get answered, but the ghost of Data Governance Present offered no affirmation of Bob’s actions. The ghost returned Ebenezer to his office to ponder an uncertain future.

To be continued...

---

Rob Paller is an expert at business analytics and database administration. Since joining Baseline, Rob has been responsible for developing a case analysis system to streamline the oversight of food assistance benefits, implementing a common citizen data model, and assisting in the rollout of a new public assistance data model integrating data from over 10 years of legacy with a new benefit eligibility determination system.

Bringing Data Governance to the Table

By Frank Dravis, Senior Consultant

It’s counter-intuitive how something as simple as a lookup table can drive a data governance initiative. At one client site I worked at, they had a reference table called Customer Level Code. In that table, there were nine records containing values such as Premier, Platinum, Invalid, etc. The table included a description column for the tier and a corresponding lookup code, but that was it. For years, this little table sat on the legacy data warehouse with no true source system from which to track its origins or authorized editors. From time to time, a code was added, such as Not Required. The person who told the mainframe DBA to add the value was an IT manager who worked with the business and saw the need.

Fast forward to the time of building a much better data warehouse. The architects, in their efforts to satisfy the business requirements, accumulated a list of over 50 such reference tables. These tables spanned the enterprise. They were referenced by many applications, and encompassed everything from employee pay grades to merchandise categories. In order to do things right, the new data warehouse needed a defined source for each data domain and table it would load, and for a large number of the reference tables, there was either no single source or defined owner or even an electronic repository to hold the original values. They were written in a notebook.

To wrap our arms around all of the reference tables, a solution was implemented where the contents of all 50 tables was loaded into one table in the landing area for the new data warehouse. This new table included columns such as change date, who authorized the change, previous value, etc.; in other words, all the rich metadata to describe how the code values were managed. Better still, this single table was published as the source of record for those tables that had no previous source system. The owners of specific records were identified, and standard extracts were written to pull data from those source systems that did exist. Taken in isolation, maintaining the Customer Level Code table was a small, informal activity below the data management radar. But when the cumulative effect of all 50 tables was considered with their errors, latency, and lack of linkage, a substantial benefit was gained by managing them as a corporate resource. That single table housing all code values aided the implementation of a data governance initiative by:  identifying gaps in ownership; establishing a central repository for management, common access routines, standardized interfaces; and better yet, uniform change management for policies and permissions.

So the next time you are working with a code table, ask yourself how many more are there like it, and wouldn’t it be nice to have one central place to go for every reference field you ever needed?

photo by p_a_h via Flickr (Creative Commons License)

---

Frank Dravis is a senior consultant with 21 years of experience in enterprise information management (EIM) and data quality solutions design, implementation, and consulting. He specializes in data integration, data quality, and data governance solutions, advising key clients and industry vendors.

Every Story Has a Beginning, a Middle, and an End

By Mary Anne Hopper, Senior Consultant

When not at work, I enjoy racing sailboats - sometimes day racing and sometimes offshore racing.  Last year while racing from San Diego, CA to Puerto Vallarta, Mexico, we spent a considerable amount of time drifting off of Cabo San Lucas in absolutely no wind.   In the middle of the night with no wind, conversation tends to drift to stories amongst the team on watch.  Call it a lack of sleep but some of my stories made complete sense to me but not to my two watch-mates.  So they told me, “Mary Anne, every story has a beginning, a middle, and an end – now why don’t you start over from the beginning?” 

That line has become somewhat of a joke since that day and night spent off Cabo.   But, one of the interesting places it plays in my mind is the BI Requirements process.   That process can be broken down into three steps – business, data, and functional requirements.  A beginning, a middle, and an end.   Starting at the beginning with business requirements sets the stage for what business questions need to be answered ensuring value is delivered.  Data requirements can be gathered to support those business questions.  In the end, that functional requirements can detail how to access that data. 

Oftentimes, I see clients start with a set of functional requirements with no idea of whether or not they can be delivered with available data or what business questions they will answer.   This approach can take the project down one of two paths.  The first is back-tracking back through the requirements process that inevitably takes the project team longer to deliver because they start over with each step backwards.   The other path delivers the functional requirement but only with work-arounds (logic built into reporting, extra spreadsheets, new desktop applications, and so on), also a costly alternative when others try to support or extend functionality.  Neither of these approaches deliver the needed business value with the agility required.So when you’re planning your next BI deliverable, remember that every story has a beginning, middle and an end.  Start at the beginning with the business requirement, work forward to the middle data requirements and then the functional requirement at the end and you’ll enjoy the success of a story well told.

photo by Gabriel Villena via Flickr Creative Commons License

---

Mary Anne has 15 years of experience as a data management professional in all aspects of successful delivery of data solutions to support business needs.  She has worked in the capacity of both project manager and business analyst to lead business and technical project teams through data warehouse/data mart implementation, data integration, tool selection and implementation, and process automation projects.

Portfolio Management and BI

Below is an excerpt from the white paper Planning Your BI Program: A Portfolio Management Approach by senior consultant, Kimberly Nevala. In this white paper, Kimberly discusses ways in which your BI Program is, in many ways, very similar to your personal financial portfolio, and how, by applying some of the same principles you apply to your own finances, you can create a sustainable approach to optimize and capitalize on your corporate information. You can download the full paper here.

Portfolio Management and BI

In a very real sense, your BI program is an investment akin to your corporate or personal financial portfolio. It is multifaceted, dynamic, and subject to sometimes unpredictable internal and external pressures. Just like a financial portfolio, BI represents a significant, strategic investment and requires a similar level of discipline relative to its ongoing, deliberate management and control.

Figure 1: Balancing BI Investments

As seen in Figure 1, taking a portfolio management approach to BI implies we must continuously:

• Understand business strategies and objectives
• Monitor internal business performance, as well as external industry and economic trends
• Identify business opportunities and needs
• Balance opportunities against available capital, enterprise resources and risk/reward ratios (aka ROI)
• Deploy appropriate business intelligence capabilities to confirm and/or capitalize upon selected opportunities

In the investment parlance, portfolio management can be active or passive. Immature BI programs tend to focus on passive—or reactive—capabilities. They are focused on basic reporting about events that have occurred and simple analytic extrapolations. They are usually based on ad hoc requests and lack of user prowess with toolsets. Mature BI programs include (pro)active capabilities such as forecasting, predictive analysis and data mining. In addition, these capabilities—or outputs thereof—are integrated into the business’s decision-making and management processes.

Continue reading here.

Did You Forget Something? Gaps in Execution in Data Governance Programs

By Carol Newcomb, Senior Consultant

Somewhere along the way to understanding the whole data governance thing, someone forgot to mention that data management really is central.  Did I say Mention?  I really meant Emphasize.  Urgently Emphasize.  Data management processes are critical to the establishment and maintenance of a data governance program.

The thing is, data governance is quite impossible without a fundamental data management process that provides tactical direction. For example, if you have a bunch of people running around acting as data stewards, asking people questions about metadata, source systems, definitions, use of data and implications of sharing it, what happens when they have to write a policy?  And when data stewards meet as a group, how can they describe the magnitude of issues to discuss with their users?  How do issues get prioritized?  How can anybody decide who is accountable if due diligence hasn’t been paid to the fundamental source data issues, and how can decisions about governance enforcement be made?

Data governance should never be undertaken as a project.  It is a long term program that needs to start with a foothold in core data problems, like the inability to use or share data.  To get that foothold, stewards need to identify data quality and consistency issues that resonate with end-users.  Find some tangible pain.  This requires a sound set of data quality profiling activities to prove where conflicts or inconsistencies are most problematic, and a quantifiable statement of what the impact is.  The problem needs to be quantifiable to get people’s attention, as well as to compare one set of problems against another.  The data management program should have the capacity to routinely analyze and reveal data quality issues,and keep bringing them back to end-users to build a sense of urgency towards taking restorative and preventive action. 

Data governance is all about People, Processes, Decision Rights and Controls.  But before you can even begin, you will need to have identified the problems through hardcore data management practices.  This involves understanding the data architecture, examining privacy and compliance mandates around data visibility and sharing, exploring metadata definitions and having the ability to make changes through sound data administration practices.  Without these systems and roles in place, data governance is just a hollow shell.

photo by limaoscarjuliet (via Flickr)

---

Carol Newcomb is a Senior Consultant with Baseline Consulting. She specializes in developing BI and data governance programs to drive competitive advantage and fact-based decision making. Carol has consulted for a variety of health care organizations, including Rush Health Associates, Kaiser Permanente, OSF Healthcare, the Blue Cross Blue Shield Association and more. While working at the Joint Commission and Northwestern Memorial Hospital, she designed and conducted scientific research projects and contributed to statistical analyses.