ManufIT.com

Last week I saw an example of what not to do when developing manufacturing systems.  The manufacturer hired a programmer to “upgrade” older systems that existed in FileMaker Pro and Excel spreadsheets.  A gov’met agency recommended they move from Excel to a database, so the programmer used Oracle because that is what they knew.

What I would have done:

1. Start with what the business problem is.  What is the real problem and what would be the most efficient way to solve it?  A database might not be the right solution. (Right Kevin?)

2. If because of #1 or because there is a regulatory requirement, a database is required, make it as simple to build and own as possible.  That means starting with software that most people know or that you can get anyone to upgrade in the future.

2a - My opinion is there are way more people that know Microsoft technologies (ASP, .NET, SQL Server, etc.) than do Oracle.  Also, a PHP and MySQL solution would have more worldwide resources available than an Oracle solution.

3.  Get a couple opinions before you start (especially if you do not do this every day.)  Ask some friends, technical advisors, etc. before you start to spend money. 

Unfortunately for this manufacturer they spent about 5x more money than they should have for what they got and now they have something that no one is going to want to touch.  Because they knew the developer and she was only charging them $40/hour, they thought they were getting a deal!

oh, 1a - see if there is a good Commercial-off-the-shelf solution (COTS) that works before you build it.

My passion is to help manufacturing companies make good decisions about manufacturing systems and have those systems provide good value the the company.  I like to refer to it sometimes as “I try to keep people from doing stupid stuff.”  Well today I was too late.

I met with a smaller company today that I have been watching from afar for a while.  They have spent WAY TOO MUCH money on a simple application that they want to help them run manufacturing better.  This application has some functionality that exists in an old FileMaker Pro database application and the task was to bring forward that functionality and add to it.

The developer they hired to write the new application chose Oracle (the free express version) because that is what they knew.  Now the company is between a rock and a hard place because the developer is not done, they are way over budget, the application is not tested yet, and there is more scope they would really like to complete!!!

I was too late!  Tune in next post for what I would have done differently…

It was announced this week…

http://www.mbtmag.com/article/CA6570888.html?nid=3436&rid=1258896918

SAP to buy Visiprise.  Those of us in the business knew it was coming at some point, and it happened.  What will be really interesting is to see what this does to the relationships SAP has with other key players in the industry like Camstar, Apriso, Wonderware, Rockwell, etc.  All of these companies have some type of technical or strategic relationship with SAP so they can all say they can “connect to SAP with their MES solutions.”

So now what?  It was hard to argue with a customer that says something like “I spent $XXM on SAP to run my business and if I can leverage that investment to help me run my operations better, that is what I am going to do.”  In the mid to long term, it is going to be very hard to convince a company to use a different MES solution other than Visiprise if they are an SAP user.

I have often wondered who is going to “win” in the MES space - ERP or the Automation vendors.  This move would appear to be a swing in the direction of ERP winning the battle for MES.  I have been silent on posts for a while, but this will provide some good thoughts in the upcoming weeks.

I am constantly reminded that with risky projects, new ventures, or unknown territory that it is smart to start small and build on successes - especially when there are technical challenges.

With MES projects, there are so many factors.  I walked into our conference room yesterday and saw our guys working on a quote for a customer.  The list of risks they were talking over filled on whole white board.

We keep getting taught this lesson, but we need to start small, get something working very solidly, and then move on from there.  This approach lessons the risk for our customers and our team.

There is no substitute for good requirements, good specifications, and a good selection process in any IT project.  Especially those projects that are complex and touch so many people and disciplines, like MES projects.

I often liken MES projects to building a house.  It isn’t enough to go to a custom builder and give them requirements like this:

• 5 bedrooms
• 4 full baths
• 3 car garage
• 5,500 square feet
• Oh, and we want this to be our dream home.

NO, NO, NO!  We all know that a builder would laugh you out of his office and say, “Come back with some architectural blueprints, some specifications, and a budget.”  Even if the builder was a Design Build firm, you would expect the clock to start then, and to pay for the design of your new home!

However, so many times I see companies trying to do the same thing with MES projects.  Requirements go something like this:

• OEE
• Tracking and Genealogy
• Reporting (including drill-down and ad-hoc reports)
• Schedule dispatch
• Label printing
• NO, NO, NO!  There is no way the customer is going to get what they want.  There is no way they are going to get an apples-to-apples comparison from different vendors.

In coming posts, I will explore how manufacturing companies can do a better job of laying out requirements.  Who knows, maybe we will even post some templates!