Owner of Lecky Integration (Little Falls, NY) and regular columnist and member of the Vision & Sensors’ editorial advisory board, Ned Lecky addresses several questions on how to achieve successful integration with machine vision applications. He also discusses best practices and the criteria involved when determining if an outside integrator is right for a company’s application.
Vision & Sensors:
The integrator is going to perform a variety of services for the customer. Each of these services needs to be considered and evaluated. They also are going to cost money to work with, and require management, oversight and monitoring time. Companies need to be sure that the rewards outweigh the risks. Source: Lecky Integration
Is there a particular type of criteria that affects an integrator’s overall success?Ned Lecky:
Generally, there are four main criteria that influence the success of a system integrator. The first is clearly technical expertise. If the job at hand requires knowledge and capability in three different technical areas, say robotics, software development and communications, and the integrator has no experience in robotics, being successful is much more difficult and the complete project carries much more risk.
The second criterion for success is project management. An integrator with excellent technical experience and capability with no project management discipline is unlikely to succeed. System integration almost always involves pulling together disparate products, technologies, some off-the-shelf and some home-grown. Planning, scheduling and executing such an endeavor is challenging-no management, no project.
The third criterion for success is engineering bandwidth. Integrators are notorious for having one of two things: too little work or too much work. The former have a nasty habit of going out of business, and the latter have an equally nasty habit of delivering too little or too late. The vagaries of the business cycle, possibly exacerbated by inadequate management, contribute to a vacillation between both extremes at many integrators.
This leads to the fourth, and perhaps most important criterion-general business ethic. Doing business with an unethical company is always unsatisfactory. Similarly, unhappy experiences come from dealing with poorly managed companies, disorganized companies and difficult or unsavory people. In many ways, this last criterion is the first one to look at. If the company is going to be hard to deal with, the long-term satisfaction with a project and relationship is bound to be low.
While laid out in the standard order, companies thinking about using a systems integrator should evaluate the criteria last-to-first. The technical issues are much easier to address and augment than any of the other issues.
Discuss the development lifecycle for a project. NL:
Listed below is a spiral process for product development:
1) First, a need is recognized. Usually, the customer recognizes this need, but an astute integrator working with a customer can often spot a need that the customer has not even thought of yet. An efficiency enhancement, new product or product accessory can be equally well conceptualized by the customer or the integrator.
2) Next, a potential business deal has to be conceptualized. What will this cost to develop? What will the parts cost to buy? What will the assembly and testing costs add up to? How much should be charged for it? Many ideas will die at this stage.
3) Then the spiral begins. Go back to concept and design, and start to fill in details. After a few details are added, one needs to re-evaluate the business opportunity. Does this all make sense? There can be several iterations of steps 1 and 2.
4) If the concept is fleshed out and the business case still looks good, one still needs to decide to fund the project. Is there enough commitment to attempt to make this product a reality? This discussion involves the business decision makers and finance people. A compelling case for cost, value and ability to complete the design and development must be constructed.
5) If funded, prototyping starts up. Get in some of the components and test them. Write some demonstration software. Identify some of the key risk areas and determine whether the hurdles are small or large. At this stage, the product may seem like a rogue project within the company. If so, that is a very good sign.
6) Eventually, there must be a transition from rogue to mainstream. It is time to bring in professional management practice. The product idea is solid, the business case is good, major risks are retired and most of the team is on-board. Now it is time to lay out a formal plan, divide the work into components, schedule those components and assign each to a team member. From here on out, it is a much more predictable process.
7) Establish division of labor, milestones and deliverables.
8) Manage to plan and update plan if and as necessary.V&S:
What are some questions an end user should ask to determine whether a systems integrator is needed?NL:
The integrator is going to perform a variety of services for the customer. Each of these services needs to be considered and evaluated. They also are going to cost money to work with, and require management, oversight and monitoring time. Companies need to be sure that the rewards outweigh the risks. Here are some good questions to help reveal the need: Do they have the technical expertise internally to do this themselves?
If there is no capability in this area, a consultant, vendor or integrator is needed. If expertise is world class, no integrator may be good enough to do what they do. Most of the time, the reality is somewhere between these two extremes. One must decide where.
Do they have the resources to execute a technical plan to make this happen? Even if they are best-in-class at doing something, if their resources are all committed, it may be acceptable to take a less-than-perfect solution from an integrator, particularly if they are working on non-mainstream additions or enhancements to an existing product line. If they do not have the resources, they need either to hire or subcontract, or start postponing some other project.
Can they describe what they need well enough that in integrator can figure out what is needed? Sometimes the development idea is so obscure that it is hard to imagine how to even communicate it to an integrator. Other times, the need is so simple and easily carved out that an integrator approach is completely compelling. Again, real situations usually live somewhere between these extremes, and an estimate needs to be made as to where.
Do the engineers involved in the project have experience working with integrators? Working with an integrator requires the in-house engineers to have some experience working with an outside team. If the integrator contacts are incapable or managing and directing the integrator relationship, the integrator is doomed. So having the right internal resources to work with the integrator is crucial.
Is there some benefit or upside in the project that will keep the integrator interested and enthusiastic about the work? Most projects are late, rushed and thinly manned at the end. While this is never planned for, it often winds up there. If an integrator feels that he has underbid a job and been talked into delivering way more than originally intended, there can be a foot-off-the-pedal response just at the moment when the hammer should be going down. Keeping an integrator involved in the business upside, either with royalties or simply with the promise of the next project, can keep everyone enthusiastic when those dark and exhausted final days arrive. Save something for the final lap.
Is there a liability or indemnification issue with this project that will be helped by using an outside integrator? There are hot potatoes in just about every project. Are they inspecting drugs? Ammunition? Trying to detect illegal substances or weapons? In situations like these, there can be considerable liability in the even that their product fails. In cases like these, it may be wise to involve another company to help improve the quality of the design and share some of the risk.
Conversely, in projects involving trade secrets, military secrets or proprietary formulas or processes, bringing in an outside integrator can increase risk by spreading sensitive information outside the company. These considerations can often drive the determination of whether an integrator is appropriate.
Are they developing a key internal technology that they want to own, control and protect as part of their fundamental intellectual property (IP)? Getting ready to sell the company? Or perhaps write a few patent applications? Anything critical to IP or the due diligence process should be held onto. Do not give the most valuable parts of the company to an outside integrator unless a very clear and well-constructed agreement is in place. Keep crucial development in-house if possible.
Is there an integrator available who has already done what they want to do? Do not reinvent the wheel. Many development efforts are incredibly similar, even if used for entirely different industries. There are many way to reuse the technology developed for one area, and if an integrator has expertise in that area, there may be a fast track to redeploying existing ideas for one’s own use. Many times, getting to market fast is more important than building a fully custom solution. This becomes a business call.V&S:
How should end users go about choosing an outside systems integrator?NL:
I think any integrator selection process has to involve a consideration of the original four criteria for success. Where are they technically? How good is their project management capability? How big-and available-is their team? How are they going to be to work with?
The customer’s engineering team can help with the technical evaluation, but all of the business issues really require discussions with other customers who have done business with the integrator. A well-run integrator will have numerous customers who are willing to talk enthusiastically about them. No company is perfect-always ask what was the best aspect of working with a particular integrator, and follow the question with what was worst.
If the best things are impressive, and the worst things are worth overlooking, or commonly overlook in other vendor relationships, then one has a winner. The question “Would you give this integrator another project?” reveals huge amounts of information. V&S
Coming Soon: Integration Certification Program
Last year, the Automated Imaging Association (AIA, Ann Arbor, MI) launched a basic certification program for machine vision professionals. Bridging off that was the introduction at the advanced level during Automate 2011 held at the McCormick Place in Chicago.
In response to member integrators wanting certification to verify their experience and capabilities, the AIA has stated that they are looking to certify system integrator companies toward the latter part of the year and has invited member integrators and end users to help share their expertise in developing the program. Company certification will include verification that integrators possess the employees, experience and resources to provide a successful system.
“Certification for machine vision system integrators could be an extremely valuable baseline consideration for end-users seeking integration support; if the certification is done by a qualified entity and in a way that truly represents the integrator capability,” says David Dechow, president of Aptúra Machine Vision Solutions LLC (Lansing, MI).
Dechow urges individuals in the machine vision profession to complete the AIA certification. However, he adds that individual certification is a long way from what is needed to competently certify a company in a way that is meaningful and useful to the end user.
Tech TipsAn integrator with excellent technical experience and capability with no project management discipline is unlikely to succeed.
Do not give the most valuable parts of the company to an outside integrator unless a very clear and well-constructed agreement is in place.
Working with an integrator requires the in-house engineers to have some experience working with an outside team.