2 January 2009 by Sanjay Saigal.

Weighing the opportunity to teach Analytic Decision-Making to executive MBA students, I realized that the value in such a project is essentially internal. The financial compensation, to not put too fine a point on it, was low. But the chance to explore the tools of my profession with highly motivated and skeptical, yet captive, mid-career professionals was too attractive to pass up.

I’m teaching something called a “breadth” course. Not quite a part of the core curriculum, but necessary to fulfill requirements of the specialization, e.g., Technology Management or Business Analytics & Technologies. The catalog describes breadth courses as specially focused on relevance. That led to my first surprise: the course description includes Optimization and Decision Analysis (DA), but no mention of Simulation or Queuing! (Forecasting is covered in another breadth course, and further in an elective. Data Mining and Business Intelligence are covered in an entirely separate data management elective, as if they were not part of the same Analytics continuum.)

The absence of Simulation in the syllabus initially struck me as astonishing. In the ill-structured fuzz of real-world business decision-making, Monte Carlo Simulation is the inescapable Swiss Army knife. However, as I began evaluating alternative texts, I had an epiphany! Textbooks purporting to teach quantitative decision-making to business students are typically adaptations of texts originally designed to teach Operations Research (OR) to engineering and other technical majors. For instance, a widely-used text has an entire chapter dedicated to Minimum Spanning Trees, an artifact I have not had to explain to a non-technical client in seventeen years! Authors also persist in continuing to sacrifice thickets, if not entire forests, explaining theoretical notions such as duality and sensitivity to students who would much rather be off discussing consumer product strategies!

After rapidly filtering through a number of OR-centric treatments, my choice reduced to two. The text I did not choose, though only by a hair, is Data, Models, and Decisions, by Bertsemas and Freund (both at MIT). I was nearly swayed by the authors’ smarts in simplifying very complex material, and a near-perfect pedagogic progression – starting with DA, proceeding through probability and statistics to Simulation and Regression, and finally to Optimization. The exposition is case-oriented and jargon-avoiding. However, its immersive use of mathematics raises the possibility that a treatment designed for the very technical Sloan School students might not work as well for more diverse audiences.

The text I chose is Decision Making with Insight, by Sam Savage. For business school use, this text has three key advantages: First, its DNA is that of practical business decision-making, not OR technology. Its spare style makes it practically useful as a cookbook (after the class is over) in the vein of the Numerical Recipes series. Second, Savage – a thought leader in spreadsheet-based Analytics – almost exclusively uses Excel as his computational sandbox. He reasons that while spreadsheets have easily-reached limitations in analytic use, they are the business analyst’s tool of choice, which guarantees a faster uptake than an unnatural specialized environment like, say, Lindo. Finally, the exposition is playful and exploratory. It elevates insight derived by computational experimentation over traditional mathematical development. The business school classroom requires business engineering, not business mathematics.

The main weakness of Savage’s book relates to its Excel-centrism. The book is designed to turn the reader into a self-motivated desktop analyst. But Savage doesn’t even hint at the vast and valuable world of specialized analytical tools and applications that power large-scale systems such as airline revenue management to power plant operations. Since there are few pointers on the possibilities and limits of Analytics, the book elides the equally important role of the reader as a potential consumer of hardcore Enterprise-level OR technologies. (Bertsimas and Freund do a better job in this respect.) Fortunately, given my background in large-scale system development, supplementing the text should be straightforward. So this lacuna does not concern me.

Tune in again after Q1 of 2009 for a postmortem on my choice!

Posted in Teaching, Business Intelligence, Operations Research | No Comments »

26 December 2008 by Sanjay Saigal.

The BBC recently reported on the long-simmering power struggle in Christiandom’s holiest site: the Church of the Holy Sepulchre in Jerusalem. This site – by tradition the place of Jesus Christ’s burial and resurrection – is contested by six denominations that occupy tiny bits of it: Roman Catholic, Greek Orthodox, Armenian Orthodox, Syrian Orthodox, Egyptian Copt and Ethiopian Orthodox. Each faction constantly maneuvers to improve its territory, their shenanigans (real and perceived) often boiling over in eruptions of violence.

The church itself is in a state of near-collapse. But since its ownership is in dispute, all attempts at repair are stymied. The situation is dismally Pareto optimal: any effort at improving matters makes at least one other party unhappy. The following heartrending yet funny anecdote captures the hopelessness of the situation:

The intractable nature of the territorial arguments over the site are epitomised by the short wooden ladder that rests on a ledge above the church’s main entrance.

It has been there since the 19th Century because rival groups cannot agree who has the right to take it down.

Under the Status Quo agreement, rights to the windows reached by the ladder belong to the Armenians, but the ledge below is controlled by the Greeks.

So the messiness persists, despite its ongoing cost to the Christian community. (Not to mention the potential catastrophic downside – complete collapse of the complex’s badly deteriorating roof.)

I was reminded of the Church of the Holy Sepulchre while navigating the recent brouhaha in the Analytics blogonook created by a post in the Intelligent Enterprise blog. Doug Henschen quizzes IBM’s Ambuj Goyal on Big Blue’s “analytics strategy” following its recent acquisition of Ilog, a leader in decision technology components (and my past employer). Henschen’s didactic frame is the notional question: “Will IBM Add Analytics to its Toolbelt?”

Henschen summarizes the interview’s takeaway in his lede as “[IBM contends that] predictive and statistical modeling — key offerings for the likes of SAS and SPSS — are overrated. IBM has what Goyal describes as better, cheaper alternatives in a mix of techniques developed for industry- and domain-specific challenges.” This startling conclusion has been met with (I’ll use a polite word) skepticism by Analytics-oriented blogs. James Taylor at the EDM blog smells the ghost of sales campaigns past:

Sadly this reminded me of the old days of IBM - when FUD (fear, uncertainty and doubt) was IBM’s reponse (sic!) to anything they did not do well. Predictive analytics are not overrated, at least not by anyone who understands them. It is true that predictive analytics, like all good technologies, are sometimes overused by over-enthusiastic supporters and that they can’t do everything. IBM’s lack of this technology is a mistake as without it their solution set is incomplete and no amount of FUD will change that.

Anne Milley at SAS’s company blog SAScom is predictably indignant in light of Goyal’s presumed attack on SAS’s knitting. Milley labels Goyal’s comments “dizzying spin” and suggests that IBM execs “deride the value [of Analytics] because they haven’t been able to monetize the analytics in their research labs even as others achieve significant returns”.

The BBC report came to mind because, as in Jerusalem, the disagreement occasioned by Goyal’s interview is fundamentally doctrinal. It centers on the existential (and ungrammatical) question – what is Analytics?

I have previously mentioned Tom Davenport’s HBR article called “Competing on Analytics”. (Davenport has also published a subsequent book with this title.) Davenport never quite defines Analytics, but his view is obviously expansive; his keystone success story is Marriott Corporation, whose Total Hotel Optimization system relies, at its core on Linear Programming (i.e., Optimization). Davenport sows confusion by using interchangeably using Analytics and labels like “statistical masters”. Analytics is not Statistics. Statistics is a tool in the arsenal of the Analytics professional. But it doesn’t describe the category.  

The SAS Institute has adopted the branding framework of Analytics to compete in the Decision Management space. Historically the purveyor of a statistical toolkit (which later morphed into a Data Warehouse platform,) SAS had weak or non-existent offerings in Optimization and Inferencing/Rules, and came late to the Business Intelligence and Predictive Analytics (BI/PA) wave. So its stance of statistical methods as somehow defining Analytics is natural.

Conversely, prior to the Cognos acquisition, IBM had negligible footprint in the BI/PA space. In terms of Optimization, while boasting incredibly qualified R&D and Consulting groups, it has been unable to develop a profitable software offering. (In the ‘80s IBM attempted to market an optimization toolkit called OSL, made many sub-optimal decisions along the way, and finally killed the product in the late ‘90s. More recently, IBM has tried to leverage an open source toolkit called COIN-OR as a brand-builder, in my opinion essentially futilely.) The acquisition of Ilog provides IBM immediately with best-of-breed offerings in Optimization and Inferencing (or Business Rules). However, it still lacks anything like SAS’s statistical platform. Goyal’s pitch suggests that they know it. And they are trying to advance the notion that what they have is what the market needs.

As is not uncommon, differences born of necessity are being painted in Marketing’s primary colors to manipulate each vendor’s “rightness”. While this makes perfect sense to advance each party’s immediate business imperatives, it does not help the cause of Analytics in the Enterprise. James Taylor correctly observes that:

The important thing is to focus on the decision and then figure out how to solve it… Business rules, optimization, data mining, predictive analytics and adaptive control [are all] necessary ingredients for Enterprise Decision Management and business success.

Indeed.  Let me illustrate with an Analytics success story. In a highly successful Space and Assortment Planning project at Hallmark Cards, most of the techniques in Taylor’s list were invoked. SAS was used to derive the space elasticity curves that drove revenue forecasts, CPLEX was used to optimized a complex sequence of layout models, and JRules was used to manage scenarios, preferences and exceptions. As the then Ilog project lead, I cannot recall a discussion where we, or any technology partisan on the large project team, attempted to push a technology agenda. The team uniformly focused on creating the fastest-performing, most accurate and most efficiently usable application.

Along similarly cooperative lines, instead of advocating the relative importance of one’s own bag of tricks and denigrating the competition’s, actors in the Analytics ecosystem need to adopt Davenport’s catholic approach. Let’s focus on expanding the impact of the field, on making it as pervasive a function in business as Accounting or Human Resources. To mash up the rallying cry of Bill Clinton’s 1992 campaign with the verbal stylings of the logorrheic Sarah Palin, “It’s All of the Above, Stupid”!

Posted in Business Intelligence, Operations Research, Vision, Intechné | No Comments »

19 December 2008 by Sanjay Saigal.

As a member of the advisory council for the upcoming INFORMS Practice Meeting in Phoenix, I am assembling what I hope will be a boffo slate of speakers for the track on Managing Risk & Uncertainty. Researching recent work in the area, I encountered an excellent 1997 paper by Dick Barr and Tom Siems titled Bank Failure Prediction Using DEA to Measure Management Quality. Early warning indicators (called Key Risk Indicators, KRIs, in the Risk Management community) of bank failure include one that is difficult to directly extract from balance sheets: Management Quality. Barr and Siems used Data Envelopment Analysis, or DEA (a linear programming-based efficiency measure, look here for a tutorial) to identify an analytically meaningful surrogate for Management Quality. The resulting multi-factorial risk model was remarkably predictive: it could correctly label a bank as strong or an incipient failure with 96% accuracy, a year to 18 months out.

I wonder whether the early warning system was used. Siems is listed as employed by the Federal Reserve Bank of Dallas, a regulatory body. So there appears a prima facie opportunity to apply the model. On the other hand, I would not be surprised to hear that the paper’s publication was its terminal “development milestone”.

Speaking later with Doug Smith, another financial risk estimation guru, I commiserated how often models such as Barr & Siems are left on the shelf. As Doug characterized the unfortunate imperatives facing his technical collaborators employed in finance: “The pressure to create profits meant that the results of risk models were ignored”.

Doug’s lament brought to mind a frequent problem for the analytics practitioner: the unfortunate habit of our “customers” (whether line managers within our own organizations or external consulting clients) to cherry-pick which analysis to use, and which to ignore. The situation becomes especially tricky when analytical findings collide with political winds. The latest such example comes from the British Isles, where a pay-as-you-go congestion charge system pushed by Newcastle University researchers was deep-sixed by Manchester voters. Feasibility, it turns out, is in the eyes of the customer. In this case, the citizenry decided that the traffic smoothing benefits of the congestion charge were trumped by the nefariousness of the new “tax”. Never mind the value of time!

While there are good estimates for project acceptance/failure (e.g., here) I have not come across estimates on how often analytics projects fail, or are shelved, for extraneous reasons. Do you have data, or even stories, to share?

Posted in Risk | No Comments »

12 December 2008 by Sanjay Saigal.

In recent weeks I have been working with Sam Savage, well-known OR personality and a consulting professor at Stanford. We’re focusing on developing a practice framework for Probability Management. Whazzat, you ask? In sum, Probability Management is all about robust decision-making in the presence of uncertainty. (Pretty much the vision for Intechné!)

Since real world decision problems are almost always ill-structured and fuzzy, our tools of choice belong to the worlds of simulation, and statistical visualization. Stochastic optimization plays a role too, but in a very different form than typically understood, say, in Operations Research circles. In general, we are not interested in creating IT systems that generate “best possible” recommendations. Rather, we enable managers to interactively explore the decision space of good solutions, using something similar to a business intelligence (BI) approach. The key difference between BI and Probability Management is that while BI is essentially descriptive (identifying multi-factorial relationships, typically for historical data) Probability Management is prescriptive: our clients learn what to do better.

I intend to write further on this topic, but for now let me point interested readers to our newly redesigned web site. The organization is a loose consortium of academic and commercial folks involved in the field, as vendors, users, and advisors. Check out the Interact! tab. It contains illustrative Excel models that describe the relevant concepts far better than long-winded descriptions. If you find it interesting and wish to discuss further, contact me.

Posted in Probability Management, Business Intelligence, Intechné, Risk | No Comments »

29 May 2008 by Sanjay Saigal.

In 2001 INFORMS, the Operations Research professional society, hosted its first national conference on OR Practice in San Diego. Some 300 OR professional attended. Since that tentative beginning, the conference has become a “can’t miss” for OR professionals and practice-minded academics, nearly 500 of whom attended the 2008 conference in Baltimore, MD.

Among its other benefits, the Practice conference has been significant in triggering a wholesale appraisal of OR methodology. The discussion can be said to have been kicked off by Karl Kempf at the 2003 meeting in Phoenix, AZ. Karl’s talk in Phoenix, titled Optimization of a Semiconductor Supply Chain: Technical & Cultural Issues, identified numerous maxims to speed adoption of OR at Intel, his employer. He ended with the declaration that while technical issues (modeling, algorithms, software implementation, etc.) were – in his words - “enough to keep us busy for the foreseeable future”, they “pale in comparison with the organizational dynamic issues”.

Karl returned to his theme the following year in Cambridge, MA, where he focused specifically on Organizational Barriers to Applying Optimization in Business Operations. The key take-away from that presentation was the need for the OR professional to focus on the algorithm to solve the business problem, without being bound by a specific software tool or approach. At the same conference, Jeff Winters from UPS spoke on Why OR Projects Fail, a crab-wise approach to identifying what is not good methodology!

Over the next four years, presentations on the theory of OR practice became among the best-attended and most talked-about part of the Practice conference. Many highly respected thinkers of the field, both practitioners and academics, have taken their turn at bat. Selected highlights:

• Palm Springs 2005
  
  • Harlan Crowder in Stuff Happens: Why Practical OR Projects Fail, fingered “cognitive friction” in the difficulty of implementing OR because of its opacity for the non-technical user.
  • The late Rick Rosenthal in Secrets for Success with Optimization, suggested that solution persistence should be the default choice in optimization modeling.
• Miami 2006
  
  • Marshall Fisher in Eight Habits of Highly Effective OR Implementers laid out his best practices, while pointing skeptically to the goal of creating an actual theory of OR practice.
  • Glenn Wegryn in Sustaining a Vibrant OR Practice at Procter & Gamble, focused on the essentiality of communicating the value created by OR methods.
  • Gary Cross in OR Based Client Engagements, spoke of the need for gradual expansion of scope, and of project-integrated learning, while acknowledging the higher risk inherent in OR-based IT.
  • Harlan expanded on his rules of thumb for successful implementation in Practical OR.
• Vancouver 2007
  
  • Peter Kolesar in Creating a Theory of OR Practice, focused on consultative OR rather than IT implementation, with recommendations drawn from the broader world of business consulting.
  • Tom Baker in OR’s Curse & How to Deal with it, warned against narrow technique-orientation and reiterated the importance of communication, technical demystification, and risk management.
  • Karl Kempf drilling down on Collaborating with IT, hammered on the need for structured development methodology and iterated development.
• Baltimore 2008
  
  • Jean Pommier described the philosophy and artifacts underlying ILOG’s Methodology Implementation of Decision-Support Systems and how Ilog uses its methodology framework to better sell and deliver optimization technology.

(I also spoke in the “theory of OR practice” track in Baltimore on Towards a Theory of OR Practice: Are We There Yet? Material from that talk forms the basis of this and other recent blogposts on methodology.)

Over the years, the discussion on Theory of Practice has emphasized both types of value delivery: consultative (one-off analysis) and systems-based (IT-embedded). However the tenor of the discussion has trended from the general to the specific. Increasingly actionable best practices have been proposed by speakers such as Crowder, Rosenthal, Fisher and Kolesar, among others. Modes of integrating into broader IT implementation currents have been proposed by Cross, Kempf, Pommier, etc. Summarizing brutally, the main lessons from seven years of discussion are:

1. Customer-focused orientation: This can best be described by the directive – “get over your expertness!” It’s seductively easy for an OR professional to fall back on technology that is, to the non-technical end-user, indistinguishable from magic. It is not enough to conjure up an “optimal” solution. The solution also needs to be explicable to the planner who generates them today using decades of first-hand experience of the overlying process and after days of hacking with spreadsheets. The focus of the OR professional needs to be on the problem, not on her technical toolbag. (An especially difficult chore if the practitioner works for a software vendor or a consulting firm that closely identifies with a narrow technical approach!)
2. Communication: Nearly every speaker places the need to clear, regular, and structured client communication near the top of the OR practitioner’s checklist. Is OR special in this regard, different from, say, mainstream IT? The consensus is yes, based on its unique combination of technology “magic” and the expected unfamiliarity of the typical end-user with OR. Client buy-in comes from developing a shared vision for the project, at the managerial and the end-user levels. Maintaining that buy-in requires ensuring that ongoing end-user education is not sacrificed to the tyranny of delivery dates and feature commitments.
3. Methodology: While the notion of a development methodology is not native to the OR community, a consensus on the need for a formal framework appears to be developing. Given the early stage of evolution of an OR-specific methodology, one finds almost as many specific recommendations as recommenders. The need to rigorously assess data requirements and availability tops many lists. As does the inevitability of an iterative implementation framework. Some “technical” recommendations, such as Rosenthal’s emphasis on modeling solution persistence, also appear. (An interesting recommendation from more than one speaker, to “avoid failure”, appears to be a bromide. But it makes perfect sense in the context of the perception of OR as “black magic”; unfamiliar and disruptive technology is rarely allowed more than one strike. Perhaps this will change once – if? - OR captures the mainstream.)

Conclusion

The INFORMS Practice conference has been the locus of methodology-related discussion in the OR community. Based on the popularity of theory of practice-related talks, the need for a usable delivery methodology for OR – presumably based on a descriptive theory – is widely shared. As clearly, there is neither an existing theory of practice, nor a methodology based on a proto-theory. There are good-sounding suggestions for best practice frameworks, but nothing validated except by personal (”expert”) experience.

In the next post in this series, we will examine possible next steps for methodology development.

Posted in Methodology, Operations Research | No Comments »

15 May 2008 by Sanjay Saigal.

In a recent article, I examined the need for the practice of Operations Research to be driven by a formal methodology. The primary motivating factor is the increasing mainstreaming of OR (or more general Advanced Analytics) techniques in Enterprise IT. This in turn is forcing system developers and consultants to proactively manage scalability and management of risk by “industrializing” OR delivery.

The typical use of this word in OR-related discussion concerns specific techniques – usually mathematical or statistical in nature – for solving reasonably well-posed problems. (Fairly typical of this usage is the paper titled “A methodology for integrating cell formation and production planning in cellular manufacturing”, published in Annals of Operations Research.) This OR is replete with (so-called) methodologies to solve problems fitting into structured classes. However, in most cases, “methodology” is just a nickel cigar encased in a five dollar label. What is under discussion is essentially a “method” or “technique” (or perhaps a class of such methods.). When speaking of an OR Practice Methodology, we’re interested not in the tools but in the practical principles and artifacts governing the deployment of OR techniques and methods.

The focus of this series of articles is on embedding OR in Enterprise IT. (While OR value is often delivered through one-off analyses, the role of a practice methodology in that purely consultative model is less clear.) In the Enterprise IT context, software engineering provides a sound basis for exploration. Methodologies such as Agile Programming, eXtreme Programming (XP), CMMI and Rational Unified Process (RUP) provide the IT project manager with a variety of risk control frameworks and usable artifacts for standard software development. However, they do not directly address the needs of the OR practitioner. Neither are they well-understood or used in the OR community.

Attempts on OR-specific methodologies have failed to gain traction in the practice community. The CHIC methodology for constraint programming was extended in the late nineties to large-scale combinatorial optimization problems and named CHIC2. However, I do not believe that CHIC2 was ever taught or used anywhere outside its academic seedbed in Europe.

More recently, French software vendor Ilog has extended its proprietary methodology for rule-based systems – ISIS – to optimization. Being a proprietary system that is viewed as a competitive advantage by Ilog, a list of OR-specific ISIS features has not been released. I do believe that ISIS has not, in any meaningful way, been used to develop a large-scale OR application. Ilog’s view of OR is limited to optimization, and thus ISIS is unlikely to be applicable to OR as a whole. But if opened to public view, it is the most promising methodological effort that I am aware of.

In the next article in this series, I will discuss practice methodology from the perspective of INFORMS, the leading professional society for OR.

Posted in Methodology, Operations Research, Risk | No Comments »

6 May 2008 by Sanjay Saigal.

Mike Trick writes about mutually assured incomprehension between the Business Intelligence (BI) and Operations Research (OR) communities. The two provide similar sounding approaches to intelligent decision-making, but appear to exist in parallel universes in terms of practice and research. He ends by expressing the hope that:

…OR people should see the BI community as a great source of problems and inspiration (and should make an effort to learn their language). But BI will inevitably use non-OR methods for some of their issues, so is rightly not “the same as” OR. But we as a field should know more about what they are doing if we are going to be part of this business direction.

Can BI and OR cooperate for mutual benefit? I look at the issue from the perspective of two technology experiences.

A traveling salesman story

The baffling non-communication between BI and OR immediately reminds me of Traveling Salesman Problem (TSP) research back in the late 80s. The OR (Groestchel, Cook, and others using polyhedral combinatorics), Computer Science (Bell Labs folks using Lin-Kernighan type heuristics) and Artificial Intelligence (using ANN, Simulated Annealing and related “bio-physical” approaches) communities were all working on the same problem, with little cross-pollination. I was fortunate to attend a conference at Rice University that invited leading lights from camp to develop a holistic vision of TSP research.

As a graduate student, I recall sharp surprise by how the limitations and strengths of each school drove its research. The AI folks armed with elegant learning-oriented methods, focused on small – say a few dozen cities – instances, often drawn directly from the real world. Their algorithms would solve series of iteratively changing instances, reliably and fast. Though there was little emphasis on mathematical optimality, their results were accessible to non-expert readers.

The CS folks were at the other end of the size spectrum. They were interested in instances drawn from telecom networks, with millions of cities, which needed to be solved in seconds. Their algorithms were essentially heuristics, so their results focused on empirical performance measures – solve time and distance from optimality. The application areas often involved real-time setting, so narrowing the range of outcome variability was the key research driver.

The OR approach – based largely on cutting plane methods for integer programming – implicitly assumed that provable optimality was the goal. The focus was on solving larger and larger problems to optimality ever faster. At that time, if I recall correctly, the largest solved involved a few thousand cities. However, the methods were extremely non-robust. There were many small “deviant” instances, for which known cutting planes were insufficient. Even worse, within any instance class and size, there could be 10x (or more) variability in solution times.

I recall that by the end of the conference, each research school far better appreciated the others’ methods. For example, in my own research (on a different but related problem) I discovered that a hybrid technique combining a randomized Lin-Kernighan type “kick” heuristic with a cutting plane method worked best. In the broader research community however, the TSP dialog did not lead to a common “business direction”. Perhaps this was due to the mechanics of the research enterprise, which can be quite territorial.
However, it is possible for commonality of goals to induce a commonality of trajectory. This is evident from the CPLEX experience at Ilog.

CPLEX et Ilog

In the late 90s, Ilog was an emerging vendor of optimization tools to the business community. Faced with the challenge of expanding beyond its European base, it found that its bread-and-butter CS-based optimization technology – Constraint Programming – was little known and unappreciated in the US. There, OR techniques such as linear and integer programming were pervasive. A small company called CPLEX Optimization was the leading US vendor. Though the initial idea was for Ilog to license and embed CPLEX technology, Ilog ended up acquiring the company.

The CPLEX acquisition created a host of integration issues for Ilog. Most of them are irrelevant to our story, but a key problem was the mix of mutual incomprehension and suspicion between the two technical groups. The Ilog folks, hailing from a CS background and flush with a string of European successes based on Constraint Programming (CP), viewed OR methods as non-robust and old school. (Constraint Programming gained prominence in the 1980s in the AI community. The simplex method in OR dates all the way back to 1948!) CPLEX folks had a hard time moving beyond the fact that CP offered neither provable optimality nor guaranteed solve times.

As CPLEX rose to become Ilog’s most successful product over the years, an interesting convergence occurred. CPLEX increasingly incorporated CP-like heuristics into its core engine. And CP product development increasingly became driven by CPLEX’s strengths: fast performance and large-scale numerical robustness. Ilog also developed products incorporating CPLEX and CP, creating offerings still without competition in the marketplace. Today, tensions between the two product lines continue to generate tectonic rumbles. But ten years down the road, ILOG has surmounted the original mutual incomprehension between the two teams and grown to the premier player in its space.

BI and OR: Quo Vadis?

In TSP research, though all parties shared goals, convergence did not occur in any meaningful sense. Within Ilog, CP and CPLEX were able to cross-pollinate and cooperate to mutual benefit. What are we to make of these two cases?

One difference, perhaps the key difference, is that the cooperative motivations for TSP researchers were weak. Research is a Darwinian enterprise; schools of knowledge play in a zero-sum sandbox. At Ilog, it was clear that CPLEX needed to succeed for Ilog to grow. Shared purpose – helped along by managerial directives – drove the cooperation of two technologies.

On the face of it, the BI/OR situation is more akin to the TSP case: there is (in Al Gore’s evocative phrase) no controlling authority forcing cooperation. However, from the OR perspective, the situation is far more fraught. The OR profession is in a period of existential self-reflection. What is the proper domain of OR? Is OR mainly a research area or is it a profession (or both)? If it’s a profession, should it include the usual attributes such as licensure, professional closure, and a professional code of conduct?

In contrast, BI has captured much of the “intelligent decision-making” mind-share in the business world in a very short period of time. And all that, on the basis of market-ready IT-aware technologies, with a less established research base. The strengths and weaknesses of the two communities are starkly complementary. And as the need for smart IT expands, the multiplicative impact of cooperation (in whatever form) has inescapable logic.

Posted in Business Intelligence, Operations Research | No Comments »

26 April 2008 by Sanjay Saigal.

Over the past few years, as IT has grown to become a key enabler across business functions, software engineering practice has focused on implementation methodology. Frameworks such as Agile Programming, Rational Unified Process (RUP), and more recently, Eclipse Process Framework Project (EPF), promise to improve IT implementation by distilling industry best practices into usable tools and artifacts. The ultimate goal for these methodology frameworks is to industrialize IT project work, to make it scalable, repeatable and predictable. There is some evidence of success: the Standish Group estimates that over the 1994-2004 period, US IT project success rates more than doubled, to where one in three of all projects are deemed successful. They explicitly credit new IT methodologies: “Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

Figure 1: Standish Group 2006 US IT Survey

Note that even armed with full-featured methodologies such as RUP, IT projects are high-risk. As Figure 1 (above) shows, though the US success rate was up to 35% by 2006, one in five project still failed outright. The remaining 46% are condemned to the purgatory of “late, over budget, or below requirements”, presumably enroute to shelfware status.

In Competing on Analytics, a 2006 Harvard Business Review article (available here in research report form, and here as a teaching aid) Tom Davenport argues for a cross-Enterprise approach to integrating Operations Research (OR, also sometimes referred to as Advanced Analytics, Management Science or Quantitative Analysis) into a company’s decision-making. As organizational decision-making becomes increasing IT-based under competitive pressures, more tactical and operational decision-support systems (DSS) have cores built on integer programming, advanced forecasting, Monte Carlo simulation, ant colony optimization, and similarly complex techniques. Moving from piston aircraft to turbines to jets to rockets requires increasingly complex power plant engineering and operating regimes. Similarly, going from simpler rule-based systems that automate decision trees to optimization-driven systems that implement OR technology require a re-examination of IT development processes.

As Davenport documents with examples from companies such as Marriott and Procter & Gamble, OR can maximize value extraction from a company’s resource base. But it also throws up new risks and challenges in implementation. For instance, the major challenges in implementing a database query-driven system (for instance, a standard CRM) involve business process mapping, user adoption, server and bandwidth sizing, etc. However, turbo-charge that application with an OR engine (for example, by embedding a constraint programming-based product configurator,) and you now need to worry about reliable search performance, solution persistence, and other optimization artifacts. Though high-value in concept, OR-powered IT implementations increase project risks along new dimensions. As OR capabilities become checklist items on RFPs, the need for a robust, scalable, and practical OR-aware implementation methodology becomes more urgent.

In upcoming articles, I will discuss practice methodology development for OR-powere