I have the pleasure of discussing software industry trends with CIO’s of the world’s largest brand name companies. These executives are moving from very tired to angry about vendor software “suites”. As one CIO said to me – “I don’t care if my ERP vendor buys up every small software company in the world. I do not buy into the story of tight integration down the road.”
This was refreshing to hear on many levels. Why should a company have to implement multiple software modules to address a single business problem? Why is the “suite” such a “sour” issue for companies? They have to first license each software module, then integrate the modules, and continually invest in IT support to satisfy users.
If you took the software suite analogy to another industry it shows the absurdity of things. Imagine if the auto industry starting out by selling you separately: wheels, engines, seats, chassis, etc. All a customer wants to do is get to their point of destination – not create an infrastructure to support an incomplete product. This is the same reason why so many software projects are late, over budget, or unsuccessful.
What do you think?
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=44c8c7b1-0c8c-4642-9ef7-b09204535733)
TrackBack
• Digg This
• Add to del.icio.us
Tags: Enterprise resource planning (ERP), Supply chain management software
Posted in CEO viewpoint
You can leave a response, or trackback from your own site.
You are right on. A suite is what you have when you lack the skills or the desire to integrate what was a standalone package into your main product.
You may call me biased (I belong to one of those big software companies that buy up modules and connect them together into a suite) and I will say that the company does it to make money. It is the purpose of being in business.
However, the reason that software companies engage in this is because 1) customers are asking for it; 2) because it works.
You can have an ERP system that controls inventory, helps with planning and processes the sales orders, OK job done… or is it.
When you manufacture what you need to fulfill the sales orders, there is a need to know what to make and customers are demanding faster response times to fill the sales orders.
So taking that sales order, lets say for your desktop computer (which is for 50 computers each with custom configuration because the customer expects that they can do it), you now have to get these computers built.
So you can print out the sales order and walk it down to the manufacturing floor and get it built or you can press the “order release button” on your ERP and have your ERP send it to your MES system because you have configured “one of those suites”.
Manually, the paper may get lost or the customer may change their mind on 4 of them (but which ones). If the “suite” is sending it, there is always the ability to “retrieve the order” infinite times across the floor to get the correct instructions or recall the order to update and re-release.
It just makes sense to connect the systems together to keep up with the demands of customers.
The issue that I have is that the CIO should not be getting involved in that discussion. These “suites” are to help the COO, the CEO and/or the Dir. Of Marketing keep the business running. It is not for the CIO. He/She just needs to keep the “&^*%$$” thing running
.
BTW, using the suites, also makes it easier for the CIO to keep the “&^*%$$” thing running.
Grant
The most obvious answer is that software companies make more money by building suites and selling ala carte, rather than putting everything into one complete package.
The other side of the issue is that one could make an argument that some clients wouldn’t need a “complete” package. For example, most wholesale distributors would certainly want a good forecasting and replenishment system, but don’t have a need for a planning system. Why buy the whole stable when you just need a horse?
The really frustrating thing for most clients is when the software companies separate functionality that obviously should be incorporated together. It is like buying candles, then having to pay extra for the wicks.
Taking Rob’s explanation a bit further, the packaging of suites (from the marketing perspective) is usually put together to satisfy the needs of a particular industry (business vertical). With the larger companies, the number of applications available is large as a result of applications needed to support Banking, manufacturing, utility management, etc…
The banking industry is not going to want to pay for an application (or suite of applications) that were designed to support utility management. So the company packages the applications to provide the support requested by the customer.
Understanding the frustration of separated functionality…
This frequently happens as a result of a software company wanting to expand their services. Instead of designing an entirely new package, they acquire a smaller company with software already capable and then go through the “painful” process of getting them to work together. This is not always easy, and sometimes meets with limited success. Frustration noted (and felt as well).
I have a couple of observations …
1- Software is generally organized to mesh with how businesses are organized. Since a great many business problems occur at (internal or external) organizational boundaries, it follows that the business problems will also occur at the software boundaries.
2- There is an “evolutionary cycle” going on. Things are working until something changes, and a business problem arises. The problem gets fixed (perhaps well, perhaps not), and things settle down. Then something changes … and so on.
3- The question itself is flawed. It is as unanswerable as “Why is the sky blue?” There is a technical answer, but nothing can be done about it. Until someone creates the system that is perfectly integrated *and* perfectly open, there will be boundary issues.