The Like Cycle

In the absence of input I decided to ramble about something I call the “like-cycle”.  No that’s not a typo I said ‘like’ not ‘life’.  It sounds very much like something you’d use at the gym doesn’t it?  Maybe something that’s part of a spin class!  In terms of full disclosure I must admit I’m not sure what a spin class is except for what I’ve seen on that cruise line commercial.  (I said I was going to ramble and I guess I’m doing a pretty good job of it!)  The ‘like cycle’ is what I call the work that needs to be done to make BI successful locally - by a small team or department.  This may seem to contradict my earlier statement that BI practice is about using information strategically to drive competitive advantage.  It really doesn’t.  The reason is that you must succeed locally to succeed strategically.  Metaphorically the strategic BI is the chewy center and local BI is the hard candy shell.  So how many licks does it take to get the chewy center?  Well, you’ll never know unless they like the hard candy shell (or if you ask the owl).

A useful way to talk about it is in terms of a decision support system (DSS) like Business Objects, ProClarity or Cognos (knowing that it applies to any BI application).  If you’re not familiar with these applications they are used to give business folks (’suits’) or more properly quantitative analysts (’quants’) direct access to an information asset.  Sometimes they’re also referred to as ad-hoc query tools.  They represent a foundational component of a BI program that provide a lot of benefits.  They can be broadly distributed.  Once they have been you have quants looking at the data. They begin to act as a data quality engine (”Hey, why doesn’t this information match that information!”, they exclaim and the really good ones will run off and pick away at until they have the answer). They start doing things that are good for the business like discerning sales opportunities, finding ways to reduce costs, automating manual tasks and providing alerts to front line folks so they can act more quickly.  It can allow business departments to fill some of there own report requirements which takes some pressure of the IT team.  Delivering a DSS to the business isn’t a black box solution though.  It requires trustworthy data that the business understands.  That data needs to be accessible fast and served up so that it can be sliced and diced in dozens of different ways in seconds.  All of this is hard work and you can’t just do it once and walk away.  You have to make the commitment to not just understand and develop the resource, but sustain and grow it.  It becomes a cycle.

I’m sure you’ve been there for a typical business request for information.  It’s organized as a project.  From the perspective of the person fulfilling this request it becomes “deliver this set of DSS based reports to Pete who works for Manager Rob”.  Being diligent the technician delivers the reports to Pete.  Pete uses them to execute a set of actions as directed by Manager Rob.  Manager Rob likes the process and asks Pete to make it ‘better’.  Pete uses the DSS tool to get more information for the better process, but something is missing.   Pete comes and asks for help and the person who originally fulfilled the request says, “I’d like to but I’m on a new project.”  Pete’s disappointed.  Pete tells Rose that DSS was helpful, but has fleas.  Rose tells Joe that and three friends that the DSS is just a lot of talk.  They each tell three friends and so on.  Soon it comes back round to Manager Rob and he’s angry.  The next thing you know there’s toilet paper hanging from your trees and the trash isn’t being picked up!  So, maybe I’m exaggerating a little.  The reality is that this project based delivery of information requests is the status quo for most organizations.  The DSS tool  acts as a means for IT to deliver a reporting capability more rapidly than if it were written using a third or fourth generation programming language generation.  In a world of lean and agile organizations this isn’t surprising.  The quick delivery of a solution and on to what’s next!  I’ve heard it referred to as a SWAT team approach which seems appropriate to me.  SWAT only shows up when there’s a crisis.  In the project based approach invariably IT becomes a bottleneck.  The resulting competition for these resources results into a queue of projects.  The queue is prioritized and in for those requests without the necessary support it becomes their final resting place.  Have you ever had your idea pushed into this queue?  Have you ever felt the sense of despair and hopelessness that this engenders?  Imagine as day after day and week after week pass as it sits in line waiting to be picked for the team, all the while watching hopelessly as other requests make the cut and yours doesn’t.

Whether this is the case or not for your organization, doing the work to build this beneficial pattern is valuable.  Its also difficult.  Its changing expectations and behaviors across the organization from the technical resource administering the data, the analyst using it to the manager directing its application.  If you’re a fan of Goldratt (like me) its about moving the constraint to a new area, or at the very least increasing the capacity of the bottleneck so that more is done with the same resources.  Its more than that too.  Its about focusing not just on the deliverable but enabling a fact-based culture in a way that allows it to spread organically.  Reading back through that last sentence makes me feel like I’m asking you to drink a ’special’ Kool-aid.  I’m not.  What I am is out of time.  I’ll pick this thread up in next weeks blog!

Have a great week…

Tags: Add new tag, Business Intelligence, Collaboration, Consulting, Grand Rapids, Michigan, West Michigan