Thursday, March 25, 2010

Word Cloud of this Blog

Just for fun I thought it was interesting to visualize what this blog is about. I found this tool called Wordle via the Duct Tape Marketing blog that I read. I think it is an amazing way to visualize out what a blog is about, in my case not surprisingly mine is about... well metrics, intelligence, and manufacturing. It is nice to get this verified.


Customize or Compromise

I am currently involved in a global project to rollout a specific MES (Manufacutirng Execution System) to a host of sites. This is an immense undertaking and therefore we are spending some time pondering some of the things that we can do to ease the pain and more importantly learn as we go along. I think that I will have quite a few more posts on this topic as we progress; initially I wanted to share some thoughts about using a commercially available MES software product, sometimes also called COTS (Commercial Off The Shelf) and the customizations that are always required.

The first topic is revolves around the question whether a COTS MES product can be productively used in a real world scenario only using the features that are available OOTB (Out-of-the-box). I believe that the answer is a resounding NO, but I may be wrong. It is obviously something that many practitioners are challenged with and therefore I think it makes a good discussion topic.

A COTS system will always be a compromise. The end customer wants his requirements satisfied based on his priorities. The vendor’s priorities, on the other hand, are driven by the need to pick the customer’s requirements that he knows the product can solve best – and then sometimes even persuade the customer that its best for him.

Such COTS MESs have a specific set of features that can be applied to a given scenario sometimes represented by a functional requirement. I like to call these "solution scenario" or "solution approaches" since sometimes a requirements is satisfied by a specific way to use a number of available features. This may be somewhat comparable to a software Design Pattern. Unlike a system that is a custom (or tailored) solution this presents some challenges.
  1. For specific scenarios there may exists one or more solution approaches using available OOTB features. This is the postive scenario - in such cases we are good to go.
  2. For specific scenarios the OOTB feature set may not provide a solution approach. In other words an OOB solution does not exist and hence a customization may be required. the question here becomes: "Can we live with out this?"
  3. For specific scenarios the OOTB feature set may be able to provide a solution approach but it is constrained or lacking. In such cases a decision has to be made to compromise or customize.
If you only encounter scenario #1 then there is no problem, however I have never seen this happen. Dealing with scenarios #2 and #3 can be summed up as "compromise or customize". What do you want to do?