Rules for software success
There are many new information technologies that can be effectively used in manufacturing environments. It is difficult to keep up with all of the new choices, and even harder to run effective projects that integrate new technologies with existing systems. The sad fact is that a lot of new-technology manufacturing IT projects fail to meet their goals. Some simple rules to apply to software projects that significantly reduce the risk of failure. Here they are.
There are many new information technologies that can be effectively used in manufacturing environments. It is difficult to keep up with all of the new choices, and even harder to run effective projects that integrate new technologies with existing systems. The sad fact is that a lot of new-technology manufacturing IT projects fail to meet their goals. However, there are some simple rules to apply to software projects that significantly reduce the risk of failure. My thanks to Michael Saucier, president of Transpara ( www.transpara.com ), for these simple but powerful rules for successful software projects.
To be successfully implemented, all software must:
Be fast and easy to install and configure.
Not require a business process change.
Have no impact on existing software or hardware.
Use the existing IT security strategy and deployment methodology.
Have a low total cost of ownership (TCO).
In essence, implementation and configuration should be measured in minutes and not hours or days. If the system is difficult to install or requires significant O/S and hardware expertise, then it indicates underlying problems. It may show immaturity of the software or the vendor, or it indicates a vendor’s “we are so smart” attitude that says a user has to be an expert in the system just to get it up and running.
Many manufacturing IT projects require controller hardware and I/O interfaces, so hardware installation can take significant time, but software should have self discovery and configuration features to eliminate installation problems.
Requiring business process changes for new software increases the installation, training, and reengineering effort. Required business process changes are usually the reason that enterprise resource planning (ERP) software is so difficult and expensive to install.
Manufacturing IT projects often affect the following business processes: configuration management, change management, inventory reporting, and business system integration.
Systems that force business process changes instead of adapting to your processes also may be inflexible in other ways, and should be avoided.
New software should have no impact on existing software or hardware because changing the existing infrastructure will be expensive and time consuming. Typically, this problem is a result of an infrastructure mismatch. For example, the new system may require a Linux server but you have standardized on Microsoft servers, or the new system may require a Microsoft SQL, but you have an Oracle database standard.
Regarding IT security strategy and deployment, if the new software or system has its own security strategy or deployment methodology, then it will come into conflict with corporate standards. This means there will be extra time required to modify the software or modify corporate standards. In addition, because of continuing IT based threats, many corporate IT security groups can veto any project considered unsafe or unreliable.
Total cost of ownership
Every installed system carries a maintenance burden measured in TCO. Programs that require manual updating of databases or manual copying of data with other programs will increase the maintenance burden. High “after first year” costs often result in systems that do not get needed support and attention, and their value quickly degrades over time.
My estimate is that violating any single rule mentioned here will cut your chance of success by at least a third or will double your development and deployment costs. It may be impossible to avoid breaking all of the rules because of hardware and control constraints in a manufacturing IT project, but when you have the choice, it is important to follow these simple rules for successful software projects.
Dennis Brandl is president of BR&L Consulting in Cary, NC, firstname.lastname@example.org .
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.