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…

Oracle has announced a partnership with Kepware to build OPC connectivity into their ERP solution.  This will be interesting.

As MES professionals, we are always debating “who will win?”  Is it the ERP companies, or the automation companies that will win the battle for the MES space?  This seems to be a play for Oracle that tells the world, “we are coming down into automation to get the data we want.”

I will be curious what type of data repository, or manufacturing execution system database schema Oracle has, or will, put together to house this information.  How will it be reported?  How will it be presented?  How will this data drive business logic?

I do like the acknowledgement from Oracle that there is valuable data in shop floor systems that needs to be integrated into ERP.  Perhaps one they get into some projects, they will see just how fun shop floor integration projects are!

As a side note, Kepware is an awesome company, and they have the best OPC Servers in the market. (IMHO)

Original news on MBT Magazine….