A concept came to me today as I was driving, that is probably a well documented business concept (or dismissed as nonsense long ago), but it was new to me. I hope that doesn't reveal any lack of business acumen :-).

The concept is the correlation between a software company's focus and how it licenses its software.

Let's look at one software licensing scenario. Say that you charge $5,000 for your software license and then charge $1,000 each year for upgrades and maintenance. In order to grow and increase revenue, you need to concentrate your efforts on new customers. The maintenance revenue is important to you, but new sales are going to be your main focus as one new customer provides the same revenue as five existing customers. You tend to take the existing customers for granted, because losing one or two isn't that financially significant.

In a second software licensing scenario, let's say that you charge $2,000 each year for the license, upgrades and maintenance, but there is no up-front cost. In order for you to grow and increase revenue, you need to concentrate on maintaining your existing customers as well as adding new ones.

I believe that moving to the second scenario will change the way your software company works. Your focus will be on quality control and providing complete functionality that meets the needs of your customers, as opposed to meeting the needs of the sales demo or request for proposal currently sitting on your desk. I believe that the second scenario drives more of a long-term focus than a short-term focus. Your decisions will be based more on building a stable of loyal customers than on meeting your latest sales quotas. Functionality will be more attuned with the real world and will take less iterations to become usable. The net result is a better product and that will lead to long-term success and easier sales efforts. You also make it attractive for potential customers to try your software. "The proof will be in the pudding", not in the packaging.

Does anyone have any thoughts? This is basically the model that most Application Service Providers use, but I don't see it applied to Industrial Software products.

Recently, we started renting a house in Costa Rica, as we expect to be spending a lot of time in Costa Rica as we start up our operations there. The day we moved into our house, I was deeply concerned to discover the hot water did not seem to work in the shower. I looked around for the fuse box and the water tank and determined that there was no issue there. So what could be the problem? A few hours later, I turned on the cold water to brush my teeth and discovered that steaming hot water was coming out. Eureka... the taps are reversed. After I recovered from my embarrassment for not figuring this out sooner, I concluded that things were "backwards" here... As far as I know, the standard is always Hot on the Left, Cold on the Right.

Last weekend, I was ranting about this to a Costa Rican and they reminded me that in Spanish, Hot is "Caliente" and Cold is "Helado"... hmm... H = Cold and C = Hot. All of the sudden it began to make sense. The person who installed the taps put the H in the right spot, but put the "Helado" water into that tap.

The moral of the story is that when you are doing something that you assume is completely obvious, always take a step back and think about the un-obvious as well.

In a numerical methods computer course that I took in university (just a short time ago in my mind), one of the first things that we learned to deal with were limits and boundaries. We had to write a simple program that would divide two numbers. The numbers would be input parameters to our routine.

The exercise sounded simple enough to a first year university student. Was it though? We quickly learned that we were not going to be the only users of this simple little routine. When it was handed over to our professor, non-numeric inputs and a zero denominator quickly brought a poorly written routine to its knees. Lesson learned!

The evolution of Business Automation has occurred independently across many disciplines and technologies over the years. From the shop floor to the corporate offices expertise was developed independently across these disciplines and technologies. Boundaries and limitations were learned and understood.

With the advent of MES we are now being challenged to understand these boundaries across multiple disciplines and technologies. This is not an easy feat and definitely requires an array of inputs from various people and sources.

Who, and what, are the input parameters to your MES solution? Is it a multi-disciplined approach? Will your MES solution have limitless success or is there a hidden zero in one of your denominators? Taking the time to think about these answers could make the difference between getting an A+ or a B-.