Big Data-OK; Master Data Management–Yes; Critical Data Leverage–Absolutely!

This world of big data and analytics has somewhat overshadowed the data foundation that makes organizations run. Even the concepts of Master Data Management (MDM) and Data Governance sometimes mask the base that lies at the heart of doing business. Consider the following two scenarios:

Program 1 – Master Data Management (MDM)

A group of people from each functional area was brought together to determine the data needed to understand their business. Each was concerned that the data they cared most about was included in the data governance and maintenance process. While the group defined the core data elements that would tie all their individual pieces together, their main focus was to ensure that they could get the reporting that they wanted to run their function. The end result was a heavily attributed master data hub surrounded by complex integrations that was easily accessed and centrally maintained by the data stewards from each function. The data was then supplied (duplicated and/or transformed) to the reporting and analytics engines to deliver to the reporting requirements of each individual function and ultimately the needs of the corporation as a whole. This was more of a metrics/KPI /reporting based approach.

Program 2 – Critical Data Leverage (CDL)

A group of people from each functional area associated with the end-to-end business processes was brought together to determine the data attributes that drove the behavior of the company’s business. They were concerned that their company presented a consistent face to their customers at all times while managing their job functions. These people discussed (argued even) about the data used to segment customers, group offerings, drive the go-to-market strategy, determine geographical differences and so on. The end result was a small data steward team that governed the core data for the company as a whole. They managed the master data hub that integrated that core data to all consuming applications and the reporting and analytics engines. Each of the functions delivered their own reporting and fed the analytics engines to meet the needs of the corporation as a whole. This was more of an operations based approach.

Each of these approaches delivered the data foundation to tie the functions of the organization together and enable reporting and analytics. I have participated on programs that have used each of these approaches and I believe that critical data leverage comes first and master data management follows. In my experience the groups who used the critical data leverage approach created a more flexible and scalable foundation for their company to grow on and met their functional requirements as well. The metrics and KPIs came out of the operational model as opposed to the KPIs driving the operational requirements. Be careful what you measure, because that is what you will get; better perhaps to know where you’re going before determining how to measure if you got there (this kind of resembles the system integration cart being before the transformation horse ). At the core, know what data drives your organization.

Even with analytics, big data and the desire to discover unknown patterns, it is still important to have a purpose behind the quest. There is a difference between data, information, knowledge, understanding and wisdom. What you’re looking for is wisdom to make better decisions; big data is a method to provide you some understanding based on the knowledge of the information and data that’s out there. The question is what do you want to be wise about?

Maybe we should be talking about Critical Data Leverage, Master Information Management and Big Knowledge.

© Ellen Terwilliger 2012

Related articles

• Gartner IT/Expo 2012 Trip Report Day 4 (blogs.gartner.com)
• The difference between Master Data Management and Information Governance? (blogs.gartner.com)

Is your System Integration cart before your Transformation horse?

I was having discussions with some colleagues who are participating in transformation programs at their respective companies.  Each program is segmented in two; one part focused on business transformation led by one outside partner, the second on systems integration led by a different partner. 

The question: What approach should be used to ensure you get the best possible outcome for your company?  I suggest you get your dancing shoes on because you will be balancing on a fine line.  First it would be good to know what style dance and song you are going to dance to before you begin.   A lot of work was done before these partners were selected; I am sure there was a business case, budget projections, etc.  But is it clear if this is primarily a business transformation or systems implementation program?  These can be very different with very different outcomes, even though many of the areas addressed may be the same: business requirements, process flows and taxonomies.  The difference is where you start and who plays what role along the way.

A business transformation according to businessdictionary.com is a process of profound and radical change that takes a business in a new direction and entirely different level of effectiveness, a basic change of character with little or no resemblance with the past configuration or structure.  Unless it’s a startup (which wouldn’t need to transform anyway), there are already organization structures and go-to-market strategies in place.  But something has happened that makes the company believe that it needs to change and somewhat significantly to be competitive.  Does your program clearly know why the need to transform exists and what your executive sponsors believe success looks like?  This is the role of the business transformation partner:  to articulate why to transform and what to transform: business models, operational models, business process flows and organization structures.  It’s often in the business process flows where the transformation horse and the integration cart get sideways.

Let’s back up for a moment though.  What is the systems integrators role?  If why and what are the transformational piece; then how to map the models and process into technology solutions is the systems integrations piece.  This will be affected by both the application landscape currently in place and by total cost of ownership (vanilla or custom, fit for function, cloud based, etc.) The “how” is focused on technology, balanced with process and guided by transformation.

This is where the dancers can step on each other’s toes. Both the transformation and integration partners have input into the business requirements and process areas and need to work together. Dare I say it; a RASCI is probably required in order to define who does what. It is likely this was not done initially when the partners were selected because that was too deep of a level of detail at the time. More important though, your company has to define how to make decisions between model, process and technology tradeoffs. Your organization’s magnitude of transformation, appetite for differentiation and budget will all play a part in establishing these guiding principles; this is the balance on the fine line. These tradeoff guiding principles will help to define the responsibilities of the transformation and integration roles and make decision making more rapid all along the way.

 It is essential that the transformation horse is ahead of the system integration cart.  Without consensus on why and what (the horse), your program will not know the style of the dance.  And without the tradeoff guiding principles (the reins), you won’t know the song to dance to.  Both of these are necessary to determine how (the cart) to dance your dance.

I may have mixed a couple of metaphors, but I hope you can see that the transformation (why and what) should be clearly defined before bringing in systems integration (how) and determining the right balance of differentiation and total cost of ownership for your company.

© Ellen Terwilliger 2012

Related articles

• What is business transformation? (petertarhanidis.wordpress.com)

CIO of the Cloud (or not)

Chief Information Officer is an interesting title; what is the CIO accountable for?   Here’s a definition from Gartner:

CIO (Chief Information Officer)

The person responsible for planning, choosing, buying and installing a company’s computer and information-processing operation. Originally called data-processing managers, then management information system (MIS) directors, CIOs develop the information technology (IT) vision for the company. They oversee the development of corporate standards, technology architecture, technology evaluation and transfer; sponsor the business technology planning process; manage client relations; align IT with the business; and develop IT financial management systems. They also oversee plans to reinvest in the IT infrastructure, as well as in business and technology professionals. They are responsible for leading the development of an IT governance framework that will define the working relationships and sharing of IT components among various IT groups within the corporation.

That’s pretty encompassing and I think accurately describes what I call “Enterprise IT”, or what it takes to help your business run efficiently and effectively from an internal perspective.  But what happens when your business is the business of technology?  What if your revenues are based on a cloud offering?  It’s one thing if internal operations are compromised, but it’s a whole different level if your livelihood is on the line.  This situation can still be considered your company’s computer and information-processing operations and the domain of the CIO.  However, product development and perhaps the CTO have some pretty big influence on the technology architecture; in fact they probably own those standards and decisions.  So what’s a CIO to do?   

That’s where “Cloud IT” and being CIO of the Cloud comes into play.  While the CIO may have little to say about what’s running, they may have a lot to say about how it runs.  There is still no one better equipped to understand the operational and support aspects of running IT.  And the truth of the matter is; the product people aren’t so interested in running the cloud as they are in creating the cloud.  By the way, the Gartner definition sort of neglects the operational and support aspects of the CIO role since they stopped at install.  Here is where the CIO must align IT not with “the business” as in the Gartner definition, but with the “business of the business”.  They know the IT professionals and processes it takes to run technology, the CIO should be the partner entrusted with running revenue operations. 

Are the Cloud CIO and the Enterprise CIO the same person?  I remember one time when the company I was working for was acquired, the network was being run by the product development organization.  You never knew what was going to happen when you plugged into the wall (this was a while ago obviously), would there be connectivity or not?  There is definitely segregation required between Cloud and Enterprise IT, security and access are very different between the two not to mention the application set.  There are also common skills required in both aspects of the CIO role and within the organization, the focus and priorities are very different though.  Of course, not every organization is faced with this dilemma but it is becoming more prevalent as the cloud continues to evolve and grow.

What kind of CIO are you?  What kind of IT organization are you a part of?  Which one keeps you up at night?

© Ellen Terwilliger 2012

Related articles

• State of IT: what will the post-cloud CIO look like? (siliconrepublic.com)
• The CIO Paradox by Martha Heller – a book review (ericbrown.com)