It is time to think process.
Business intelligence as an enabler to business processes.
A well known, well published, and well respected leader in the data administration field recently relayed this story. Forgive me if all the details are not verbatim… but… early in his career
our young “guru to be” had the opportunity to attend a conference on data management. Having sat through a long afternoon session with a well respected (at the time) guru in the industry, our
wide-eyed conference attendee asked “doesn’t all this miss the underlying business process?” The speaker approached our brave, albeit naive data administration neophyte and with all the
arrogance that often comes with self-anointed guru status, leaned over, staring directly into the eyes of our young DA novice and declared “you sir, are a process bigot”.
A small salvo in a battle that has been long since raging – which admittedly, from time to time, found even myself switching allegiance. This article will discuss how (and maybe more importantly
why) data analysis and specifically Business Intelligence efforts must align with the overall business process.
My first exposure to the “data vs. process debate” happened to be while with a small consulting firm working on a large Business Process Reengineering (BPR) effort for the federal government back
in the early 90’s. In order to move forward, any new IT development project was required to be part of this extensive BPR undertaking and produce both process and data models. There were those who
felt that everything was data driven, and once you identified the key entities and relationships (in a logical data model) you could now delve into the processes that created, read, updated and
deleted that data. By knowing the relationships between entities, one also gained a deep understanding of the business rules that governed the business and its processes.
The “process first” camp insisted that by documenting the inputs, outputs, mechanisms and constraints to a process (a great feature of the IDEF0 modeling notation) one was now able to begin to
identify those entities. After all, if a person, place, thing, or concept (entity) wasn’t an input to, output of, or somehow an enabling mechanism for a process, why would we care about it. This
camp won those early battles and attempts were made to couple process with data. Unfortunately the tools at the time were not well suited to maintain/document this coupling (but that’s whole
different article).
The battles continued to rage. Data driven approaches and methodologies gained momentum and greatly contributed to sound data management principles. People began to discuss the importance of meta
data. Others began to tout data/information as a critical enterprise asset to be guarded and managed as you would a fleet of ships, stock portfolio, or a raw materials inventory. Data seemed to be
winning the good fight.
Enter Object Orientation. Needed ammunition was supplied to the process camp as OO analysis and design began to win the day. Use Cases and process flows were now in vogue and data models became
passé. Object models now reflected the behavior of objects (some might argue entities) and IT professionals, enamored with buzzwords quickly jettisoned the “baby” with the “bath water” –
when it came to data administration. Nothing that has been around as long as the relational data model could have any relevance in the brave new object world (or so some thought).
Fortunately, the writings of folks like Dave Haye and Fabian Pascal (to mention a few) have pulled the pendulum toward center. Once again I hear development shops around the country discussing the
importance of a sound logical data model to the development process.
But where do Business Intelligence and Data Warehousing (BI/DW) initiates fit into a discussion of business process (the original focus of this article)? I fear for too long, these types of
engagements have ignored business process. It’s all about extracting, transforming and delivering data after all (tongue in cheek). The success of well architected data marts that answer real
world business questions, in some ways, contributed to the lack of business process focus. Why would a technologist whose job it was to provide data long since locked away in monolithic,
nonintegrated legacy systems, become encumbered with how the business does business?
Answering business questions via a data mart isn’t enough. How we use those answers (the decision making process) and how that all fits in the bigger business process is critical to demonstrating
true return on investment. I’ll relay a few more stories.
At my first data warehousing conference I was first exposed to the “diaper and beer” example; a testimony to the value of data warehousing. I’m sure many of you have heard it – I’ve relayed it
several times myself and have no clue as to its authenticity. As the story goes… a large grocery chain began to “mine” their daily sales transactions matched up against demographic information
provided when the customer swiped his/her frequent shopper card. After analyzing the data, an interesting trend began to emerge. It was noticed that on Friday evenings, the sale of beer and diapers
seemed to have a complementary relationship. Upon further research, sure enough beer and diaper sales were up in the early Friday evening hours. It was surmised that husbands (by order of their
wives) stopped by the local Shop and Pack (not the real name) to replenish the weekend supply of diapers. Often taking the opportunity to toss a few six packs into the cart while they were at it.
The store, as lore would have it, went the next step in making this trend actionable. They strategically separated the beer and diapers so that more of the store would be traversed and the
reluctant shopper would be forced to pass by a host of pork rinds, beef jerky and other such items that might appeal to a more masculine target demographic.
An entertaining example of how BI might contribute to the bottom line. What was not clear is if the store actually modified business processes to judge the success of their actions. Thousands of
companies run campaigns to attract customers and increase market share. Many of these companies also have data warehouses which unfortunately are completely detached from the processes of creating,
implementing and reviewing the success of those campaigns. Training individuals involved in the execution of campaign related processes on how they might leverage the data warehouse is one part of
the equation. Designing data warehousing and Business Intelligence solutions with the intent of being a mechanism or enabler to those processes is where we as technologists should be moving.
Many BI/DW methodologies are starting to recognize and incorporate business architecture as part of the initial phases of analysis and design. Some might ask if business process modeling should be
part of the BI/DW build process and if data architects and the like should be doing it. Others may ask… if not then, when? And if not them, who? All good questions. Some organizations already
have robust, fully decomposed activity and process models which could be readily used as input to the BI/DW creation process. Even if that is the case, those “as-is” models should be enhanced
with new processes, inputs, outputs, etc. that reflects the role and more importantly – value add of the data warehousing initiative.
Future articles will discuss and provide examples of integrating BI/DW initiatives with the underlying business process. Until then, you may want to go out and hire, rent or train some true
“process bigots”.
