I struggle to explain to people what it is that is unique about Oco and what we do that is different from all the other "SaaS BI" companies, which are rushing into the playing field.
I always try to say something which briefly summarized is "It's the business semantics stupid!". I've harped on Oco does solutions, everyone else is doing just tools.
Ok, that's a bit polemical, but the point here is that what we do is VERY different, ... but what is the difference between a solution and a tool anyway?
Here goes....
Oco was founded (back in 1999) by a gentleman named George O'Connor (hence the name. ... yup. I'm naming my next company after myself too.)
George was in a very interesting situation which allowed him to make a rather unique insight which is just blindingly obvious in hindsight, but is really quite profound. So in order to completely slap you in the face with it, let me digress.
Suppose you are at the 50,000 foot level. You are IBM, or Oracle. You are trying to decide how to understand all the data in businesses. If you are looking across dozens or hundreds or thousands of businesses, then you would have to adopt a computer science kind of posture and say to yourself "I think we need a relational database system here. All these businesses can represent everything they're doing in that common framework and then we'll be able to exploit commonalities". You would be right of course. Most businesses today use lots of relational database systems, and they are the tool of choice to represent business information.
Now suppose you are looking at just a single business, trying to decide how to understand all its data. You would adopt a very precise focus and say "I think our orders can be a table with columns for the amount of the order, tax, who sold it, what division they are part of..." and so forth. You would create something very tailored to what you need for just that business.
Ok, now here's the point. George O'Conor worked for a company that owned 10 others that he was responsible for. He had exactly 10 companies to look at. Not one, not hundreds, but ten.
This changes everything. There aren't too many jobs where you are responsible for 10.
His insight was this. Among the 10 companies, there are not an infinite number of different ways they need to represent their orders. There are only 3. Their shipments have only 2 variations actually, their pricing policies - 4 different kinds.
At the perspective of 10, you don't invent something as general as the relational database. You look at the common business behaviors, and you invent software that represents each of the different behaviors. You don't need infinite flexibility, you need limited flexibility.
So far so good, but why was this article title about "genomics" anyway.
Well, we all know all life is based on DNA, and there's a gazillion base pairs organized into genes, and there is the potential there for infinite variability.
Yet, how many different human eye colors are there? Answer: it's not an infinite number of variations, it is 6. They are Amber, Blue, Brown, Gray, Green and Hazel. (Sorry Liz. Wikipedia says violet is just not real!)
Just 6.
The database of DNA supports infinite variability, yet we humans boil down to exatly 6 variations.
Could that be because our environment didn't NEED more than 6 variations. Certainly had it been to evolutionary advantage there'd be many more colors, but 6 proves to be enough for us humans even in our complex social world. In fact having too many variations would be problematic. It is comforting to us to see similarities across people. Not uniformity, but not total diversity either.
And so it is with businesses. In businesses today, how many different pricing strategies are really out there being practiced? How many different ways to manage orders. A relational database can represent, like DNA, an infinite number of variations on business concepts, yet businesses really only do any given business behavior a few different ways. And this is because competition hasn't required more variations. And, if every business did each of these behaviors entirely differently.... well it would be awfully hard to hire experienced help. It's useful for us that there aren't so many variations.
In other words: There are lots of better ways to make money than constantly inventing different pricing strategies for your business. 'nuf said.
Bruce Richardson from AMR coined this idea as "Oco discovers the business genome". It is a very appropriate analogy.
So for pricing, there's some variations, but not so many. For order management, again a few variations. Inventory, again a few. Combining them together there's lots of combined variations, but in each individual area, we could call it each business gene, there's not so many variations.
Just like hair color, eye color, etc.
This is truly compelling and entirely obvious once you see it. Yet people tend to believe that businesses just are full of endless variations of practices and what they do is unique in so many ways. And it simply isn't the case.
We exploit this big time at Oco.
Oh yeah, the ERP companies do also. Funny that.
How do we take advantage at Oco? Well we have a central database design in our product which can represent a few variations on say, pick pricing again. Will we change it if we find another variation? Sure we will, but we don't expect to do that often now. If you can cover the variations we have now, we think it's likely we can already handle many other variations.
Here's the sweet part: All our tools can exploit the fact that this database is quite stable in theme and design. We don't have to transform data from what the business has in hand to whatever database design is created for a particular project. We've got a fixed database design. That whole variable drops out of the equation.
Back to Solution vs. Tool.
A tool is like a relational database. It does whatever you want to do with it.
A solution has more of the genome built up in it. It's closer to a living thing, a living business.
To tell them apart, well if you are considering a BI system, ask the vendor what they know about pricing for your industry? Do they recommend managing orders (i.e., what customers buy from you) and purchases (what you buy from others) the same way, or differently? Heck, can they even comment on these topics? What about transportation logistics? Can they comment on fuel surcharges, or why trucking is different from rail?
If the answer is "however you want to do it", then you are purchasing a tool, not a solution.
Recent Comments