The Industrial Science Blog: Complexity Science, Simulation, and Business
Wednesday, June 25, 2008
 
Inspirations from E2.0
I had the great privilege to attend Enterprise 2.0 this week in Boston with our friends from New Paradigm, now part of the nGenera Innovation Network. Perhaps it was the intellectual energy of Cambridge or the diversity and enthusiasm of the notable attendees...but something was "in the air" here that stimulated some great discussions, both on stage and off.

In the spirit of this confluence of social networks, collaboration, technological progress, new business models...I would like to offer some thoughts that came to my head...


1. Analytics and search. Think about web search...the form that comes back from a search expression is a list of links or an equivalent list of images. Rather primitive, don't you think? What if searches were "smart" - ie they had a point of view on how the returned information should be expressed.


My inspiration for this comes from an amazing Mathematica demonstration from Theo Gray, the front end designer at Wolfram Research. He built a periodic table of the elements where each entry is the top image from a search of that element name.



This is a great example of search results cast in a smarter, more contextualized form.


2. A simulation as a member of a social network. We think of a social network as comprised of human members. But how do we interact with those members? We ask them questions and we have information pushed our way. Hmmmm...can't an analytical model do the same thing? Why not go to the Facebook of my favorite model, post a question, such as ..."what is the current forecast for sales in Q4" and let it come at me with an answer? Why not let it receive my posted inputs and that of my colleagues (ex. "I think customers are enthusiastic about the new SuperWidget"). Intelligent but non-human actors on a social network could strengthen the collaboration that already exists.

3. Teaching the Net Generation on their terms. Lots of industries suffer from a demographic bubble - a large percentage of the workforce is within a few years of retirement, and with it goes all of that valuable experience and knowledge. The Net Generation is now entering the workforce and in some cases taking on key leadership positions. How do we make this work? I have suggested for a long time that the process of simulation is ideal for capturing and codifying human knowledge about a given system. The rigor and discipline that model development brings vets theories of the business from the participants in a comprehensive way. But until now I hadn't closed the loop on where this information goes...to the Net Generation! And how does this cohort learn? Through simulation...this is a very natural and comfortable medium for them. So perhaps simulation is an efficient way to transfer all of that great wisdom while allowing the Net Generation to find its own way?

George E. Danner
Monday, February 18, 2008
 
The role of intuition and experience in modeling
I was visiting with a client the other day. We were talking about the possibility of building a model to support a small airline’s operation. A gentleman in the room, a subject matter expert on aviation operations, turned to me and said, “Why do I need a simulation model? I can answer the questions we have by just sitting down and thinking it through.”

I was taken aback at first. Try to design a complex set of routes, maintenance bases, schedules and the like in your head? That seemed so foreign to mathematicians like me.

And yet, it was a great question. Why do we need models? And especially – why models when we have recognized experts in the field, just down the hall? After pondering this for a while I came to rest on a basic philosophy – models don’t replace human intuition, knowledge, and experience – they codify them. Done properly, models and human judgment are seamlessly interwoven into a single, organized body of knowledge. An institutional artifact that is worthy of preservation and continuous use.

Intuition plays a subtle but key role in all we do in the process of building models. First we start with a hypothesis, which is a problem statement that suggests an answer – to be proven or disproven by analysis. How do we come up with the problem statement? The answer, of course, is that humans have grappled with a complex problem and certainly know enough to restate its bounds.

During the course of model building, humans weigh in on how the system works, while the modeler translates that guidance into model-able form.

And finally, when the model is built, experiments are conducted. “What happens to the call center response time if we increase the number of resources in Brazil” or “how does our supply chain performance look when we add that customer in Peoria”. These are questions that arise from hunches about how the system at hand can and should perform under a variety of conditions. Again, not generated in a vacuum – but coming from human experience.

Perhaps pop culture has given us this false “zero sum game” between human brainpower and computer simulation. Hollywood certainly has its share of dark man v. machine portrayals. But best practice in simulation is diametrically opposed to this view – creating models that leverage humans in a way that simply transforms their knowledge into a fast and convenient format.

Pass the popcorn, please.
Thursday, January 03, 2008
 
What business can learn from...videogames?

This may come as a surprise to you, but I am not an avid player of videogames. One might think in my professional work in simulation that I would be a natural “gamer” as they call it. However, for one reason or another, I’ve taken a rather dim view of these things, both as a professional and as a parent.

My wife finally convinced me to buy a Nintendo Wii for the kids. The games were moderately interesting , and I was impressed with the graphics processing capability of modern games. As a mathematician I can appreciate the massive processing power that is required to show two irregular objects bouncing off each other or even hair blowing naturally in the breeze – what game developers call programmable physics. That is some kind of horsepower.

“Cute”, I thought, “and mildly impressive”.

Then for Christmas along comes this game called Guitar Hero III. Whoa. This game finally crystallized all of the thoughts I had about the possibility of convergence of business simulation and gaming. It was like a lightning bolt out of the blue.

It wasn’t the graphics…frankly the graphics in GH3 are pretty lame. No, it was several important things:

Outlier Subject. GH3 simulates something that would seem completely foreign to simulation – playing music. The developers have figured out a way to abstract the playing of music into a simulation using visual and tactile proxies – no easy feat. It just goes to show, once again, that there are very few subjects that are not candidates for simulation.

Innovative Visualization. The object of the game is to hit the chords by clicking a series of buttons on the “game console” – which is shaped just like a guitar. The chords scroll toward you as the song plays. You must time the chords in line with the song playing in the background. These designers have figured out how to place this scrolling object in the center of the screen yet still make the rest of the scene, including scorecard elements, viewable without distraction. I found that I had no trouble keeping a pulse on my overall performance while playing the game.

Naturally Collaborative by Design. A quick check of the associated GH3 website shows multiplayer tournament schedules, blogs, cheat codes, hints and tips. No one told these people to collaborate…they just did it as a way to become better, more informed players. Here’s a sample:

Q from Robocop00: “im new to guitar hero and am wondering what finisher guitars do”

A from Aokiji: “ You mean finishes? They're like new faceplates for the guitars you buy. When you purchase them from the store, you can select the face plate you use on that guitar when you select it when choosing which guitar you want to use. All of the finishes only work for certain guitars though.”

Its an Ecosystem. I counted 16 companies that were part of this game’s creation, from Neversoft, the software developer, to Gibson who made the hardware, to Pontiac that advertises inside the game. I wonder how all these companies came together? My suspicion is that it was far less command-and-control from a central authority and more a set of “ant rules” where each player did its simple thing to add up to a complex (and beautiful) result.

So let’s imagine an equivalent of GH3 for business. How about “Ford Motor 2: Legends of the Highway” or “Exxon 5: Masters of the Hydrocarbon”, or even “Chick-Fil-A 3: Cows Rule”. It is conceivable that companies could create engaging simulations of themselves for use by their employees, partners, and suppliers as a way to become better at the game of business.

So forget about Google and Apple and all those other companies that are held up as shining stars of modern industry. I’m putting my money on a corner of the economy that really “gets it”. Let’s rock, people!


George Danner

Saturday, November 10, 2007
 
What is a model?
George and I build models. It says so on our new business cards. So what is a model?

BTW, we are not the only ones who build models. We all build models, you probably build really good models and more often than you think. They may not be in Excel and may not be presentable on a PowerPoint slide... but you have built and used models... sometimes to save your own life.

Let me take driving as an example to illustrate two very important aspects of a good model.

1. A model is NOT reality, but a representation of reality.
2. A model is "good" or "bad" based on the purpose of the model.

You adhere to these key rules of good model building when you drive. We discus the first aspect in this entry.

A model is only a representation of reality. There is an apocryphal story about a king who wanted to create the best map of his kingdom. He commissioned a task force that was mandated to create the most accurate map of his kingdom. It was to show everything so there would be no mistake and confusion as to what was in his kingdom.

With this mandate, the task force went to work. After a few weeks, the king demanded to see the work in progress. They brought him their "latest version", rolling it in on a cart. As they started to unfold the huge map, the king realized that the map was "actual size". It started with his court, and showed where the throne was, depicted in the same size as the throne. It showed what the floor looked like, and every location of every wall and column.

This was not a good map. This is not a good model. It may be accurate, but it's impractical (among other things).

When you drive, you are constantly building, using and rebuilding models in your mind to run "projections" and ready yourself for or to directly take actions.. Will that car move over to my lane? Do I need to cover my brake? You use a "map" in your head to plot out where you need to go. You incorporate this info with your knowledge of physics, how a car operates, your state (are you in a rush or are you enjoying a leisurely ride?) and many more elements to help you drive.

Whew! To illustrate the first aspect of modeling... have you realized that your model is not reality? It's only in your mind. It's also probably filled with incorrect and incomplete information. And yet you rely on this as you make your way down the streets and highways. This incomplete, sometimes inaccurate model, is used by you and the other drivers as each of you go about your driving day.

Good thing, too. You have learned to only include things in your model that is needed, to abstract and simplify things. In my next post, I will continue by talking about the second aspect of "what is a model".
Wednesday, November 07, 2007
 
Business Analytics, Defined (Sort Of)
You’ve probably heard a lot about Business Analytics lately – it is a term that is thrown around with other vague notions like added value, ecosystem, and integration. If we keep it vague, firms won’t be able to embrace it, won’t recognize when they’ve got it, and can’t compare it to “not having it”. Yet Business Analytics is one of those things that defy strict definition, even to those of us who build Business Analytics every day.

Business Analytics “feels” different from simple graphs derived from a spreadsheet, even different from a finely tuned executive dashboard using the best available Balanced Scorecard practices. It is different from Six Sigma measures of process performance. But if these aren’t it, what is it?

For the moment I’ll sidestep the challenge of strict definition and try to lend some identifying characteristics to Business Analytics. Think of these as signature features that if present, probably mean that you are somewhere in that space, somewhere near the arena of good practice – a place we like to call a Next Generation Enterprise.

Business Analytics has the feel of search. BA is not static, not a bunch of numbers in a pre-ordered format…good BA starts with nothing but a notion of “I know what I want when I see it”. Therefore you might start with typing a phrase such as “how many blue widgets with the optional thingy did we produce last quarter?” Hmmm…lower than I thought…was it a seasonal thing? I’ll now compare that to different quarters across the years…hmmm…yep…it does appear to be seasonal. I wonder if the red widgets are similarly effected…? If such free-flowing navigation is not on par with your favorite search engine, you probably don’t possess Business Analytics.

Business Analytics allows for user-driven, rule-based automation. If people are thinking about their jobs, and thinking about their firms, they also should be thinking about what vital information might trigger an important action. Let’s say that you’ve noticed that whenever a competitor adds a new product line, unit prices follow a distinctive curve over two quarters. Any BA system worth its salt should let you take that idea, describe it in a non-programmatic way, and have the system automatically support or refute that hypothesis over time.

Business Analytics measures everything. I know a certain software CEO who has measured every hit to the company’s website since 1994. They’ve committed every email archive to a freeform searchable repository. Each year when the Nobel Prizes are awarded, they know within minutes whether the winner owns their software, uses it regularly, and how many interactions they’ve shared. Now this is a bit radical, I know…but the overarching point here is that storing data comes at a near-zero cost, and data is the basic fuel of good analytics. You can’t hope to know in advance what data someone might need to do some innovative study -- why not err on the side of too much data than the more frequent stance of collecting just enough data to get by?

So your homework is this: think of one basic, fundamental question that you could ask about your company – a question that anyone outside the firm might want to know. Then see how much energy, time, and consternation this question generates.

If you are in a car company, you might ask: How many white XLC pickups did we sell in Nebraska in 1987?

If you are in a drug company, you might ask: how many labor-hours went into the development of our latest cholesterol drug?

If you are in a retailer, you might ask: which store has the best ratio of sales to floor space?

These are fairly simple, straightforward questions, wouldn’t you agree? This is data the company should be studying regularly, and therefore should be within someone’s grasp at a moment’s notice. I suspect that you will find that more often than not, this data will be surprisingly difficult and expensive to acquire.

Firms talk a big game these days about innovation – unleashing the intellectual power of its talent to solve tough problems. But if we haven’t given our talent access to the most basic ingredient of innovation, such talk is exactly that.

George Danner
Wednesday, April 18, 2007
 
Smart Brains and Stupid Computers
In building business simulations, we are often called upon to create systems that mimic what humans do manually. Call them business rules, work processes, whatever you like – these are the minute-by-minute decisions and analyses that people perform, often without even thinking very hard about the complexity of their own solutions.

We have recently been working in two projects where the essence of our software simulation is the duplication of a basket of these human cognitive tasks. Our clients were surprised by our seemingly slow and clunky process for creating software code, just to crudely mirror its human counterpart. “Why does it take so long for you guys to write code to do X?” was our client’s frustrated plea.

“Making software that competes with human intellect is hard”, was our less-than-profound response. But its true – the human brain processes an amazing amount of information very fast, and also in parallel. If I showed you, for example, a box of red colored balls with one yellow, the human can spot the yellow in an instant. If I build some code to do the same thing, I effectively have to write a loop that makes sure that it examines each and every ball exactly once, up to the total number of balls. I have to create a logic statement to determine the difference between yellow and red and apply it inside the loop. I have to command it to stop when it finds a yellow…you get the picture.

Of course, once the software is in place, it runs very fast, possibly as fast as or faster than a human. Computers are “brawny” – they execute brute force, single-minded logic very fast once programmed to do so. It is the creation of the logic that is a slow and arduous process that even a child perceives to be primitive.

Sometimes the work that we do is viewed as “magic” by our clients. Our ability to quickly turn a business process into a working simulation using a sophisticated 3D visualization simply amazes people (even me, at times). However, simulation is really hard work, and not for the reasons most people think – most people assume the work is in the technical integration. The “mechanics” of putting software componentry together are actually fairly straightforward. No, the hard work is in compressing the thousands of simple rules that humans readily apply into a finite number of lines of code in software. And these days it seems that fewer and fewer people “write things down” anywhere, making our job even more difficult.

I hear you saying - so what? So computers are dumb? This isn’t exactly a groundbreaking finding, so what is the big deal for me and my job at at ACME Corp.?

The big deal is this: a corporation survives or dies on its ability to make decisions based upon data. Fundamentally, that’s strategy, my friend. And the difference between good strategy and very good strategy is as high as its ever been. There is nothing more important to competitive advantage.

Therefore if decision making is a function of collective institutional knowledge, it serves you well to preserve that knowledge to as high a degree as possible. If that knowledge is hoarded inside of human brains, you’ve got a big problem, because brains are fallible, inconsistent, and portable.

Here’s what to do about it:

1. Encourage people to think deeply about the top 5 key decisions they make every day and commit to writing down (in a picture is best) the structure of that decision and all of the influencing factors.

2. Create an environment where people role-play and game-play with analogs that are appropriate to your industry (if you are in the real estate industry, encourage the game-play of monopoly and then debrief afterward).

3. If you’ve never used business simulation, try it out on one particular business process. Be observant as to how human subject matter experts (SMEs) express how they do what they do.

Now I have to get back to work…it’s a human thing.

George Danner
Friday, May 12, 2006
 
capturing data
I have written about data in a previous post. This one is about capturing data. Usually, we are simply given data for the models we build. Well... it's never THAT simple, but we are rarely given the task of capturing "raw data". In fact, it's been a while since I have personally been involved with physical task of raw data collection that will be used in some analysis. Or at least, I think so... one never knows for sure with the ease at which data is captured.

But I digress. It's really too bad that I've been removed from the process of collecting data. But in recent weeks, I have been involved with two different activities where I am physically capturing data. One is for a client. I have made visits to several sites where, with pencil and clipboard in hand, I follow someone from entrance into the parking the lot through all the "stations". All the while, I am collecting time and process data, as well as making observations. You see, the client has provided us with all kinds of data; we are on the lookout for "important stuff that is not captured by the data capturing systm". Nothing beats an on-the-ground investigation for getting good intelligence. Now... what to do with the info is another matter.

The second activity is for Arbitron. My family has been selected to become a radio ratings survey for this week. We carry a log around and make hand-written entries to capture our radio-listening habits. What station? When? Where did we listen, etc. This is facinating to me, since I often get to see the aggregation of such data collection, but I rarely get to participate as a "citizen". Hopefully, writing about this on this blog doesn't disqualify me.

Both examples activities have made me think a bit more about what is actually reliable about any kind of data that's collected through distributed means. How do you set it up so you minimize the variations across the different data collectors? How do you deal with fatigue, learning, changing habits? Does the act of capturing data actually change behaviors?

Come to think of it, I am probably NOT a good candidate for a Nielson or Arbitron servey.