Bob:...2015. We've already started in 2014 the system integration. We think it is vital to the continuing growth of American manufacturing. We already
have on our two websites, www.planetengineering.com and www.controleng.com, our system integrator database which you can access and get a lot of
information on areas involving how to find the correct system integrator for your business. Bailey Rice, Bailey raise your hand. Bailey, Bailey Rice,
raise your hand. Bailey is in charge of our system integration program for CFE media. And we are going to continue that emphasis going on into 2015.
Our first presentation here this morning ties very closely into that. System integrators have come into increasing prominence in manufacturing and we're
going to offer an insider's view from a company that does system integration and how to get the most out of that process.
Tim Jager is a project director and member of the senior management team of DMC, a project-based engineering and software firm headquartered here in
Chicago. He heads the embedded project development team, as well as a number of Siemens projects. Since starting his career in engineering, his primary
focus has been on automation and control systems. He has a B.S. in Mechanical Engineering from the University of Illinois (Go Fighting Illini) and a P.E.
in Control Systems. We're very pleased to welcome from DMC, Tim Jager. Tim...
Tim: Thanks, Bob.
Bob: Thank you.
Tim: I'm going to do a little IT support here for a second. There we go. Okay. As Bob mentioned, my name is Tim Jager. I went the University of Illinois.
I'm a project director in a system integration company. And I've been doing this for 15 years. I started at DMC in 1999. I'm going to tell you a little
bit about DMC first and then we will get right into the presentation.
We are a system integration company, software engineering firm with offices in Chicago, Boston, and Denver. We've got about 70 employees. And we are work
in a lot of different industries, just about every industry you can imagine. We're members of CSIA which I will talk a little bit more about later. And
we're Microsoft Gold Certified Partners.
We break our areas of expertise down into really four categories. The biggest one and the one that's probably the most applicable in this show is what we
call Manufacturing, Automation, and Intelligence. What that boils down to is any system in any factory that has some kind of programmability or software
component, we probably get involved with it. We do some other things too. We have a group that focuses a lot on test and measurement applications. Think
of high-speed data acquisitions systems, high-speed signal analysis, end-of-line product testers. We do a lot of work with National Instruments products,
and do a lot of programming in LabVIEW with that group.
Another category that we work on, this is kind of a catch all category, but we call it Custom Hardware and Software Development. We will help companies
develop products, electronic products from the ground up. We'll do electronic design, firmware programming, and then we will do complete application
development for PCs or mobile apps, etc. And then, I mentioned earlier, we're Microsoft Gold Partners. So we'll do SharePoint implementations, Microsoft
CRM, and Office 365.
Enough about DMC. Let's talk a little bit about why we are here today by starting with what is a system integrator? So if you ask a dozen system
integrators what they do, they'll give you a dozen different answers. Probably the most concise definition is it's a company that brings together a bunch
of disparate components into a unified system. That's what a system integrator does. That's what I have been doing pretty much my whole career.
So why am I here today talking to all of you? The purpose of this talk today is to take all the lessons that I've learned over the last 15 years and
distill the most important points down into 45-minute presentation. That's giving back to people that would be our customers or end-users, anyone that
would work with the system integrator. Like all lessons in life, I've learned all these the hard way. So hopefully everyone gets one or two little nuggets
from this presentation that they can take away.
Here is a quick agenda. We are going to talk about when you might use a system integrator, reasons why you might decide to work with one. And then if you
do decide, how to select one? Or if you decide not to, maybe a couple of alternatives. And then we are going to get into some dos and don'ts in order to
have a successful relationship with the system integrator. I may use the term system integrator, SI. I may even throw the word solution partners, they are
Let's start with when would you use a system integrator? One of the primary reasons for working with a system integrator is ... everyone in this room
works for a company that does something special. Something that gives you a competitive advantage in the market place. Something that other companies
don't do. That's your core. Anything that's not part of that core is simply a means to an end. When you need a new toilet, you call a plumber. When you
need a new roof, you call a roofer. When you need a new automation system, you call a system integrator.
If the automation part of your business is just a means to an end, then you may decide that you just want to push that off to a system integrator and not
dilute your internal stuff in making them be experts on system integration as well as all the things that make your company special. A lot of our
customers do exactly this. We have some very large companies that we work with that have actually kind of downsized their teams over the years. They have
teams that focus purely on things the they do best. And anything external, they outsource.
Another reason is simply expertise. As automation systems get more and more complicated and advanced every day, it's not fair to expect every company to
have all their engineers always up to speed on the latest and greatest technologies and at a comfort level where they can implement them. So you might use
a system integrator when you need a little bit of extra expertise. When a system gets put into a plan, a lot of times of the life cycles of the system is
10 years, 15 years, sometimes 20 years. Well, in that 20 years, a lot of advancement have been made. And there are companies whose job are to stay up on
that technology, they're system integrators. You can leverage that experience, especially if you are doing an update something like that.
There are a lot of gorges and pitfalls when upgrading a system. Hopefully you can find a system integrator to that has gone through the learning curve and
can accelerate your upgrade process. Here is a really important one. A lot of our automation projects fall into this category. We work for a lot of
manufacturers and OEMs, especially I guess OEMs. They have a product that they make and they have an automation platform that they're comfortable with.
That's their standard platform they sell. They'll get an order from a customer and says, "Hey, we want your machine but we don't want your control system.
You're using Allen Bradley. We want you to use Siemens. Give us your exact machine, but put our preferred control system on there."
You have two choices when this happens, either you get your team to get all the correct software for whatever this new platform is, ramp up on it,
translate your code or rewrite it to work with the new platform, hope that everything works right. Or you can say, "Hey, that's not our core this is a one
off. We want to service this customer. We want them to be happy. We're going to put on a system integrator to take care of this odd ball request and we
are going to focus on our core platform. And then maybe over time, if we start selling more and more of these we might decide to add this to core offering
and then our team will ramp up on it, but not right away. So for the one ask, we use a system integrator.
This is one that a lot of people probably don't realize. When you need an influx of new ideas, what do dirt and automotive seats have in common? They both
kind of squishy. So we did a project several years ago for a soil lab where they wanted a testing apparatus that would compact dirt to an exact pressure
and hold it. It was a really challenging control system because dirt doesn't behave like normal mechanical components. We did it and it worked. It was
challenging. We came up with some unique algorithms to get it to work.
Fast forward a couple of years, an automotive seat manufacture came to us and said, "Hey we need a system that will compact an automotive seat to an exact
pressure and hold it." It was the exact same system. It just wasn't dirt, it was automotive seat. So we were able to take all this stuff that we learned
in one industry and apply to another. These two industries never would have crossed paths.
You can think of a system integrator as your eyes and ears into all these different industries. Because, as I said in the beginning, we don't have a
vertical that we specialize in. We work in a lot of industries and most system integrators are like that. They can take one thing that they learn from one
industry and apply it to another. The problem that your industry is trying to solve may have been solved many years ago somewhere else and no one knows
Another reason to use integrators is when you need a jumpstart. This can mean a lot of things. But specifically the cases where we get involved with the
jumpstart type situation, it's where a company wants to get ramped up on a new technology. They want their team to understand it and be able to move
forward with that technology whatever the platform maybe. And they need to do it quickly. Maybe they have kind of a young or a green team that they are
ramping up. A really good system integrator will be able to come in and work with your team and get them ramped up. Their job in this case is not to come
in and look like the heroes and show you how smart they are. Their job is to come in and get you up to speed as quickly as possible.
Anyone that has ever taught someone how to ride a bike, knows that there is only one way to teach someone how to ride a bike. You put them on the bike and
you get them peddling and you hold on to the back of the seat. When they start to veer off, you give them a correction. You get them back of track. And
over time, you will be doing less and less corrections, until you just can let go. The relationship with the system integrator can be just like that. They
can put you in the driver's seat, get you moving forward with a specific platform or technology or software. And when you veer off, they'll correct you
and get you back on track.
We do a lot of work with a lot of manufacturers. We are pretty involved with Siemens and their automation equipment. A lot of times, we'll get projects
that are referrals from Siemens where they will say, "Hey, we've got a customer. They're struggling ramping up on our PLC technology for some reason." And
they say, "Hey, this is going to be a tiny project. You probably are not going to make a lot of money. But hey, can you go in and get them running? Make
sure they don't fall down and make everyone look good." And we say, "Sure." Because it builds good will with the customer. Maybe someday they'll need help
and they'll remember us. And it make Siemens happy for us. A good SI would be to give you a solid jumpstart.
Short terms helps. Sometimes you may have a situation where you're completely self sufficient. You've got a team. You're ramped up on whatever it is,
whatever technology, whatever automation technology you use, and everything is great. But you might want to pull in the system integrator because you can
have them do things and then kick them out. You can pull them in and say, "Hey we need some help with this," and then they are gone. If your business, if
this blue line at the bottom of the screen is a graph of your business cycle, it's perfectly consistently flat and this slide doesn't apply to you.
But if it looks more like this where there is ups and downs and you may have a massive influx of project work you need to get done. And you don't want it
to double your staff and then have to un-double your staff, because that can be awkward and bad for morale. You might want to pull in the system
integrator temporarily and say, "Hey, augment our team for a little while, and then when things balance out, get out the door." We have customers that are
just like that. They call us when they need us, and we step in, and when we are done, the project is over. There is no expectation that we come back until
they get in a jam again. And that's okay.
The last time when you might need the system integrator is when you are in big trouble. We've all found ourselves in a situation where something just
isn't working. Something bad is happening where there is a deadline and we have to figure out a solution. So we need to call in the wolf. Most system
integrators will have some people that are particularly good at troubleshooting, random challenging problems and maybe they've seen the problem that you
are experiencing. There is a lot of cases where you need to call in the calvary and an SI is a good option for that.
We've got a couple of wolfs at DMC. There is a guy named Boris that works at DMC. He is this Russian guy and he has a particular knack for being able to
solve any problem with any system, no matter what. I had a customer call not too long ago, and they were in a complete panic. And this guy, his name is
Jefious. He was talking a mile a minute and he was saying, "Tim, the system is not working. Our customer coming in. They are going to look at the system
in two days and we've got to get up and running." He was panicking. I said, "Jef, how about this. I'll send Boris over tomorrow and he'll help you out."
And I could hear his sigh of relief. He says, "Oh, Boris is coming? Okay." It completely diffused the situation. So having an SI that has some really good
people and knowing who those people are can be a good benefit when you need them.
Let's assume that you've decided you're going to work with the system integrator but you want to know how to select one. What are the things that you
should think about? What should you ask them? First is that you want to evaluate the stability of this firm. Hopefully you are looking for a long-term
partnership where you don't just need them for right now. You want to be able to call upon them from time to time. You really want to evaluate the
stability of the company. How do you do that? What are the things to look for in an SI?
Several things. First is how long have they been around, right? If they have been around a long time, maybe they are doing something right. Coupled with
that is, are they profitable? Do they actually make money? You want a system integrator. You want to work with a system integrator that is profitable
because that means they are healthy. That means they can hire good employees and retain them. That they are not going to disappear anytime soon. It's a
good thing to work with an SI that's profitable.
Ask them about their turnover. Are they are revolving door? System integration can be a tough job and it's not the right job for everybody. Ask
specifically about the turnover at the company. "Hey, who are the last three people that left and why? Tell me about it." Get a feel for why people are
leaving the company. Every company is going to have turnover but get a feel for it. Is it because they were burned out? Or because they got other awesome
Ask them for kind of breakdown, a pie chart, or something of where all the business comes from. That's an okay question to ask. You want to know do they
get all their business from one or two big customers? And what happens if that customer disappears? Do they cut their business in half? Do they have to
cut staff? Or are they fairly diversified? You really want to know this when working with a system integrator.
Let's see. Asks them about their infrastructure, their systems. A lot of times you might be working with a system integrator and the end product that they
developed for you, you may spend $100,000 with them and they give you some drawings and some software. Is really the deliverable? You want to make sure
that those are stored properly. They are backed up. That they've got a really good infrastructure in place. You don't want to know that your critical
software that they've been developing for you is on someone's laptop somewhere and hopefully they'll back it up one of these days. So ask them
specifically to walk you through their systems.
The next three things to look at can be easily remembered by thinking of the story of Goldilocks. You're looking for things to be just right. You want a
good fit with the system integrator. Look at the firm size. Are they too big or too small? What that means is how big is your project compared to their
typical project that they are doing? Is your project a little teeny tiny project that they have to slide in and they don't care too much about? Or
conversely is this the biggest project that they will have ever done? That could be a little scary.
Along with that firm size, I said earlier on, we've got 70 people at DMC. So in your mind, you are thinking, "Oh, they've got 70 people that can do
exactly what it is that I need them to do." Ask them specifically how many people do you have that do whatever it is you need them to do. If it's Allen
Bradley PLC program, how many Allen Bradley PLC programmers do you have of your 70, 20 or 30? You may be talking to a company with 30 people, but maybe
they have one or two people that do the thing that you need them to do. It's okay to ask that question.
Too hard or too soft? With all system integration there is a hardware component and a software component. And some system integrators, they are better at
the software side and some are better at the hardware side. Evaluate where their sweet spot is and where your projects fits. If your project has a ton of
hardware and a little bit of software, you probably want a company that's better at the hardware side of things. At DMC, most of the projects are really
heavy on the software side. So if a customer comes to us and says, "Hey we want you to build this hardware and this little tiny bit of software," we might
tell him, "Hey this might not be the best fit for us."
The last thing is how busy are they? Are they too hot or too cold? Are they so busy that they are not going to be able to fit you in? Or your project
might be delayed? It's okay. Ask them, "What's your pipeline like? How's this project going to work? How busy are you? What's your capacity?" Conversely
are they too cold? Are they not busy at all? The plus side of that is that you are going to get the attention that you need. The downside is like kind of
like walking into an empty restaurant. It just doesn't feel right. Some things seems odd. If they are too cold, they are not busy enough, maybe the
engineer that's working on your project sees the writing on the wall and he is actively looking for another job. So you don't want them to be too cold or
too hot. You are looking for just right.
Another thing to think about is technology versus industry expertise. Ideally when you hire a system integrator, they know all the technology that you are
using and they know your industry inside and out. It's not always the case though. You may have to decide what's more important. For us, most of the
projects that we get are based on the technology. The customer is more concerned that we know the technology that we are programming. But there are
certain cases where industry experience is more important.
Couple of examples. We have a large customer in a semiconductor industry. When we started working with them first, they were very concerned with us
knowing the technology. And it just so happened that we're really, really good with the technology that they were using in their process. They really
didn't care that we knew much about the ins and out of semiconductor processing. I think they were actually kind of happy that we were sort of
disconnected from the industry because it allowed them to keep the proprietary nature separated from us more easily.
Conversely, we've done a lot of work in the automotive industry. And the first question that we are always asked is, "What work have you done in the
automotive industry?" And there is no second question if you don't answer the first one properly. They want to make sure that you understand the demands
of the automotive industry. That you understand just in time manufacturing and new manufacturing. Sure, the technology stuff is important. You have to
understand that, but you won't get a foot on the door easily if you haven't worked in that industry. So figure out where that fit is when selecting an
integrator. They may or may not have worked in your industry or they may have worked in your industry and know it inside and out but may be they are not
as keen on the technology. Figure out what's important to you.
Who remembers the story of the tiny engine, makes it up the steep hill through sheer determination and perseverance? What can we learn about selecting a
system integrator from that story? That we want a company with determination and perseverance? Not really, that's not what we learn. The reason this is a
good story is that we don't find out until the end whether the little engine makes it over the hill. That's what makes it exciting and suspenseful. Who
wants the project to be exciting and suspenseful? Who wants to find out at the very last second whether it's going to work or not?
What we can learn from this is that there is very big difference between "can do" and "have done". Specifically ask them, "Have you done the thing that I
want you to do on my project? And if not, what have you done that's close to it? Have you made a seat-squishing system?" "No, but we've made a dirt-
squishing system." So dig into that a little bit. Because we can do things and there is things that as system integrators, we do things all the time that
we've never done. But it's easier to do things that we have done. So if you find yourself in the "can do" category, realize a few things that you need to
ask them, "Tell me about projects where you were in this "can do" category but you've never done it before and tell me about some that are succeed and
failed," and figure out where you fit in the spectrum.
The other thing with the "can do" versus "have done" is probably one of the most challenging things that a system integrator does is estimate how long
it's going to take to do something. It's a whole lot easier to estimate something that you have done versus something that you can do. If you're in the
"can do" category, you might want to scrutinize the estimates you are giving a little more.
Next thing to think about is certifications. We are the members of the Control System Integrator's Association. And it's a question to ask your potential
system integrators, "Are you a member of the Control System Integrator's Association?" If the answer is yes, that's good. If the answer is no, that's not
necessarily bad, but Control System Integrator's Association is kind of like an ISO:9000 for Control System Integrators. It's a badge of approval. You
have to go through several hundred point inspection where they look at all of your systems and your processes.
Remember I was talking before about ask them about how they backup things and how their infrastructure works? By having the CSIA symbol, it answers a lot
of those questions for you because you can't get this without having sufficient systems in place. Makes that job a lot easier. Ask them if they are
certified in a particular hardware platform that you are working with. If they are, that's good. If they're not, ask them about projects they've done.
Because really what is most important is their track record with that hardware or software platform. It's not the end of the world if they are not
certified, but it's a bonus if they are, so you should ask.
All right, references. This probably seems like a super lame slide but in reality, this is possibly the most important slide of this presentation.
Reference seem like a useless formality because clearly I'm going to give you the references of people that are going to speak highly of me. I guess it's
a concern if you can't get a couple of references from an SI, that's a red flag. But there is a special kind of reference that you can get that's just
pure gold. And I will recommend you try for this.
If you have a system integrator that's working...I'll give you a specific example. I mentioned we do a lot of work with Siemens. Let's say they are
working on a Siemens PLC for you. If you can get a referral from someone at Siemens that says "Yes, this team is good. This system integrator will do a
good job for you." That's huge because one thing that may not be obvious is that system integrators get a lot of their business through referrals. They
get business from the manufacturers that they work with and the distributors that they work with. If they get a referral from a manufacturer, they're
hypersensitive to that and they have to do a good job on your project. They are going to want to do a good job anyway, but they have to do a good job
because this person or this company that vouched for them and throws the business their way, they put their name on the line.
We were talking earlier about how maybe your project is really tiny and it won't get the attention that it deserves. If you get a referral and your
project is tiny, you'll get extra attention. Because there is this whole relationship in play that is separate from you and the SI that we want to keep
intact. So that's a really critical thing. I would ask for a referral from the manufacturer that you are working with.
In addition to asking a bunch of questions of the SI, really critically analyze the questions they ask you. It can be really telling. You really want them
to be excited about your project. You want to get a good feel that based on the questions that they are going to be able to meet your needs. We had a
sales lead come in through our website not too long ago. It was this company that wanted, they wanted an electronic system for controlling part of an
engine. The engineer that took the sales lead, his name is Johnny, he is an electrical engineer and he is also a total gear head. So he loves cars and
motors so this was the perfect project for him.
He got so excited that instead of sending the standard email back, "Oh this sounds like an interesting project. I'd love to talk to you about it," he sent
this nine-page email which was ridiculously long. It had tons of questions. It had all these ideas and brainstorms. He was fully engaged in this project.
And the customer, maybe he was too engaged, but the customer realized that, "Well, this person is excited about this project. They're going to do a good
job." We got the project and it has been a great success, and it's because we found that fit. Listen to the questions they ask you. How engaged are they?
How much do they really want to know? Do they keep asking questions and questions and questions? That can be really a good thing.
Do they play well with others? System integrators, I said that basically they collect all these systems and they make them work together. Well, there is
people involved with all these different people different systems a lot of times. So they really have to work well together. You really have to interview
them from the standpoint of, is this person going to be working with your team, are they going to get along? Are they going to mesh well with your
engineering team? Are they going to work side by side or are they going to butt heads? Definitely try to interview the actual engineers people that will
be working on your project and get a feel for how well they will play with others.
There is a couple of really challenging questions you can ask a system integrator. You can ask them, "Will you train my team so that I will never have to
call you again?" That's a tough question. But a good SI will say, "Absolutely." Because they know that if you want to get trained on this technology, you
are going to do it anyway. Why not be they be the ones to do it for you. The next and more challenging question is, "Will you train a local competitor so
that I never have to call you again?" That's seems like a crazy question, but is something that we do quite often.
We have a large customer that's based in Chicago but it's a global company with factories throughout the world. And we do full system deployments in these
factories and they’re master projects. Let's say we have a team of people we send over to China to deploy the system. The customer says, "Hey will you
train a local integrator in China to support the system so that we don't have to ship you back and forth from the U.S. to China?" And we say, "Sure." One,
because they are going to do it anyway. Two, we are looking at the big picture. This is a huge account for us. It's important to keep the customer happy.
A good SI will not be short sighted on that. Lastly, it's actually kind of a benefit to our engineers. It can be challenging to send people overseas for
long periods of time. So the shorter we can make that for our engineers, the better.
Try to peer behind the curtain a little and identify their commercial interest. So what does that mean? We've already talked about the referral. So what
other political situations and play that you can maybe leverage or better understand? But other commercial interests thing to think about, how do they
make their money? A lot of system integrators have really basic model. We charge X amount of dollars per hour for our time and how much time we spend, we
multiply that rate, and that's the cost. Others may have a more hybrid model. Some may make a lot of money on actually selling you the hardware or the
software licenses and things like that.
Understand where they get their money from. There is no right or wrong answer but understanding it will help you make better decisions throughout the
process. For example, if the system integrator is selling you hardware and they make a profit on that, a good system integrator will always pick the right
solution for the customer. But sometimes solution A, solution B will both work and solution A has a high profit margin. There may be some commercial
interests that you want to be aware of.
Transparency, open-door policy. Can you stop by anytime? Can you just call up and say, "Hey, I'm the neighborhood. Can I swing by and see how my project
is going?" We work with a company that they are really big on their open-door policy. There is a company that makes electrical control panels. They say,
"You can stop by anytime. Walk in the door and we'll show you where your project is in the process." I was talking to one of the principals of one company
and I said, "Oh, that's great. How often do people stop by?" and he said, "Never, it's just knowing that they can is important." So I recommend if your
system integrator has an open-door policy, actually use it, actually stop by once in a while. See how things are going.
Right, let's talk about some alternatives. Maybe a system integrator isn't quite right for what you are looking for. So we have to acknowledge that they
maybe some options out there. Let's talk about them briefly. You can use a technical staffing agency or freelancer. Maybe you just need a person for an
extended period of time. You are not looking for someone to come in and do a full project for you. You just need a person with a specific skill set.
That's where like a sterling engineering or an aerial tech or a technical staffing agency could provide someone.
The advantage of that over a system integrator is generally the hourly rate is lower for something like this. The downside is that you are buying this
person for a certain amount of time and when you set them free, they may not ever come back. They may move on to the next job. The idea with the system
integrator, hopefully, is that when they leave the project, you can call them back later and they can do some follow up and hopefully it's the same people
that were working on it originally.
There are some wild cards out there. Don't rule out Craigslist and guru.com and things like that. We've had some mixed success with that. As an
experiment, we tried to outsource some stuff to India using guru.com and it was really challenging. We ultimately were able to kind of get something
working but when we looked at the hours that we had to spend managing the person and finding the right person, it just wasn't worth it. Craigsist is the
Do you remember Boris, the wolf I was talking about earlier? We found him on Craigslist. It was probably the luckiest thing that's ever happened to our
company. We needed someone with a very specific skill set and we needed them really quickly. This is about ten years ago. So we placed ads everywhere
including Craigslist. Boris had just come over from Russia. He was just really, really strong technically but since he had just come over, he just got the
first job which he could get which was delivering pizzas. He went from pizza delivery to one of our most stellar engineers of all time. That was a pure
diamond on the rough. So if you are going to go down this route you have to be prepared to do a lot of interviewing to really screen these people.
Unfortunately if you are looking for help, it means that time is something you don't have so it's a little bit of a catch-22.
Remember that there is always going to be a less expensive option, you get what you pay for. That's the lesson that we learned from the guru.com. It was
really painful to get what we wanted. The last option is just hire someone. Preferably try to find someone that works with the system integrator just hire
them away. That's actually happened to us. We have a really big customer that we've done tons of business with. And one of our engineers wanted to move
out east and that's where this customer is located. And they said, "Hey, we want to hire your guy." And we said, "Okay." Because he such a huge customer
and we're looking at the big picture and he was going to move anyway, so it worked out great, honestly. So if you find people that are at system
integrator and you can entice to come work for you, go for it.
Let's get into the do's and don'ts of a successful relationship. These are based on all the horror stories throughout the years that I've run into. I've
just kind of distilled it down into just a bunch of do's and don'ts. How do you eat an elephant one bite at a time? The idea here is do startup project.
If you are going to engage with a system integrator, start out small. Give them a one-week project or a couple of day project.
Nothing scares me more than engaging with a new customer and having them drop a massive purchase order on us and we've never worked together. It seems
great to get that big purchase order, but we haven't established this dynamic. So I don't know, are they going to like us? Are they going to work together
smoothly? It would be nice if we kind of start out slow. It's like getting married after the first date. You want to take a step back and plan your
project out if possible with the system integrator so that you can ease into things. It minimizes risk on everyone's part.
This one seems obvious, the key to any successful relationship is communication, we all know this. Specifically with working with an SI, set up the lines
of communications right up front. Get a phone tree list from them of all the people that are going to be working on the project and their managers.
Understand the org chart, say, "Hey, can you show me the org chart so that I know where these people fit into your organization?" Figure out how you are
going to communicate. Are we going to have a weekly status meeting? Are we going to have emails? Are we going to do web meetings, in person meetings?
Figure that out upfront, and then ask the questions of, "Okay, how are we going to communicate problems when they happen?"
If you figure out how you are going to communicate those, "What happens when we start exceeding the budget?," and things like that: let's talk about that
early. It hasn't happened yet, let's figure out how you're going to deal with it when it does. Add your own expertise, definitely do this. When you think
of a system integrator coming in, you think of them, "Oh they are experts. They are going to teach us all these things." But keep in mind that you are all
really intelligent people and they are working at your company doing these really special things for a long time and you have gained all this knowledge.
Share that with them. The project will be better.
I mentioned in the previous slide about getting this phone tree and understanding who the players are in the project. Give the system integrator your
information, your phone tree. Say, "Hey, where are all the internal experts that we have on this, that and the other thing," so that when the system
integrator runs into trouble, they know who is the expert on your end to call for help. It will shorten the development cycle if they can have questions
answered really quickly. Tell them all the things that you've done wrong. Tell them the failures that you had. You don't want them to replicate a failure.
You don't want them to do something that you've already done. That's just a waste of time. So definitely add your own expertise.
Be realistic, here is what that means. At some point in any project there is going to be a specifications that you are trying to hit. Some of the things
in that specification, it's just a document. There were things that were typed in. Some of them are super critical and some were typed in, maybe
arbitrary. If the system integrator doesn't know the real importance of every single one of those specifications, they may find themselves battling a spec
or requirement that they can't quite reach. If you set a requirement of how fast a machine is going to run, and that requires to push everything to the
max. And they get it to 95% point, but it's going to be an extraordinary effort to get it to the hundred, constantly re-evaluate that. Instead of just
saying, "Hey, that's the specs we have to do." Really reevaluate that.
We've got some projects that we've done where we've pushed the system to the max to get it to pass the spec. But then when we go into the plant, a couple
of weeks later, they are running at 85% because there is some other bottle neck in the line or maybe their systems doesn't run that well that fast. It
never really could but we spent a lot of time proving that it could even when never has to. Really think that time is money in a lot of cases and you may
want to reevaluate your specifications as you get closer to hitting them.
Predict failure. There is a concept known as the pre-mortem that I like to talk about. When you get a system integrator and you are talking to them about
a new project, they are going to tell you all the reasons that this project is going to succeed and all the successes that they had. And they are going to
be excited about telling you how they are going to push you to the finish line. Let them take off the salesmen hat for a second. And tell them, "Hey, I've
got this crystal ball. I believe you. I believe this project is going to be a success but the crystal ball is telling me that we failed. I want you to
think about all the reasons that this project could possibly fail."
You will be surprised. The engineers that you were talking that were a moment ago, telling you all the ways it was going to succeed, they'll start to
think about, they'll take the blinders off and they'll start to think about ways that it could fail. Write those down and say, "Okay, these are all good
possibilities. Now, how do we address them?" Have that as part of your initial kick off with them. A lot of times, you can solve problems early and ensure
that more cheaply, inexpensively by doing this than waiting until they happen.
The ideal system integrator would always be there when you need them. We have a guy named Ken at DMC. He was working with the customer and this guy's name
was Vin. They got into this weird habit where Vin would call up and say, "Hey, Ken. I've got a project I need you to come work on it." And Ken would say,
"Okay, I'll be there tomorrow." A couple of weeks later, Vin would call up and say, "Hey, Ken. I need you to come out and work on something." And Ken
would say, "Okay, I'll come out tomorrow."
It just so happened that Ken happened to be free the day after Vin was calling. It was just coincidental. So one day, Vin calls up and said, "Hey, Ken.
I've got a project for you. I need you to work on it." Ken says, "Okay, I'll come out next week." And Vin said, "Wait. What? I've got the whole team ready
for you. They are expecting you tomorrow." He'd gotten this pattern of setting the expectations of the customer that he was always there, right?
System integrators, they are generally billing for their time and keeping busy as one of the important things that system integrators do internally. So
understanding their schedule and assuming that you can't necessarily always call them at a moment's notice. If you need to be on the call them at a
moment's notice, have that phone tree in place. Say, "Hey, okay. If Ken is not available, who then do I call?" and have that back up plans so that you are
not panicking when he says, "I can’t come out until next week." Also try to get them as much heads up as possible. Now, Vin and Ken have a great
relationship. Vin gives Ken a heads-up. He says, "Hey, I need you to come out in two weeks." And Ken says, "Okay."
When working on specifications, you really need to be specific or you may get what you asked for. System integrators are pretty good at reading between
the lines and taking a vague specification and giving you what you wanted versus what you asked for. But sometimes, that's not the case. If a rough spec
comes into a system integrator, they may deliver a rough system. If there are ambiguities or things missing from a specification, you need to be very
clear that they are missing, and not assume that they'll fill in the blanks. Ask them to fill in the blanks and have them send them back to you with their
assumptions. Instead of saying, "Okay, we can do what you said in the spec." Have them repeat it back to you in text or fill out an assumption list of,
"Hey, this is vague. Here is what we are going to do instead." Have that discussion earlier on, or you might end up with a situation where they didn't
properly interpret what you were asking for.
Okay don't expect software to fix hardware problems unless you are NASA. When NASA sends something into space, it's in space. So if something is wrong,
they scramble to try to find a firmware fix. "Let's update the software, hopefully that it will fix it." When I was a younger engineer, I used to be
really good at fixing hardware problems with software because I knew I could, "Oh, I'm so smart. I can find this work around. Even though the hardware is
not quite adequate, I'll figure it out in software." But as I got more experience, I learned that ... well let's look at the time value of money versus
the cost of pulling that bad hardware out and doing that analysis. And a lot of times, you can spend a whole lot of time which equals a whole lot of cost
fixing some hardware problems with software when maybe you should have just yanked out that hardware and done it the right way.
Conversely you can't fix bad software with hardware. So identifying really where the problem is, is the most important thing and then figuring it out the
proper solution. This is a really important slide. Ideally when you work with the system integrator, they will create all these drawings, all this
software for you. And they will turn it over to you without exclusions, so that you have full license for it. But that's not always the case. Really
understand how the software licensing works when you are working with a system integrator because everyone is different. There is nuances to every
integrator and how they do that. We've had a lot of cases where we've worked with customers that have worked with another integrator or supplier and had
just assumed that they were getting kind of the software and maybe had a falling out with the integrator. And looked at the fine prints in their contract,
and no, they weren't getting it. So we've had to rewrite it from scratch because they didn't ask this question up front. Really understand and be okay
with the way that they license their software and it's really critical.
Learn from the integrator. Let's say that you are working with these people on a project and these engineers are coming to your facility and working with
your team for x number of days or weeks or months. Pick their brain the whole time they are there, right? They may have experience with all sorts of other
things that maybe are not related to the project that are working on, but they are generally very happy to answer questions. If you're out to lunch, ask
them, "How would do this? How would you do that? What do you think about this? Hey, lets go look at the other part of the plant. Let's do a plant tour and
give us some advice," pick on their brains.
If they are in your facility working on something for you, you don't have to wait until you have the next project to pre-engage with them. Get a feel of
how they might handle another project and learn from them. Have them build training into their proposal. So that at the end of the project, instead of
just walking out of the door, they sit down with you and maybe they run through all the code they developed with your team. So that maybe because your
team didn't develop it, but at least they can maintain and understand it. Definitely try to learn as much as you can from them.
I alluded to this before, but don't ignore an over budget situation. Set up those lines of communication very early on so that if budget ever becomes a
concern that you talk about it before it's too late. We've been in a lot of situations where maybe a customer is in a panic situation. And they just need
something done and they say something like just do whatever it takes. That's a red flag when you hear that, "Do whatever it takes." Because that implies a
blank cheque book and there is no such thing as blank cheque book. Talk about those budget situations earlier on before they get out of control. You never
want to say, "Hey, just get it done and we'll figure it out later," because there may be a huge gap in where your budget was and where it needs to be to
finish up the project.
Also, no one has a time machine. So when a system integrator is working on a project, let's say they're doing a lot of software, there is levels of
software complexity and feature sets that can go in. Maybe you can cut down on some feature sets that aren't really critical and get the project back on
track. So really be thinking about critical path the whole time. If there is something that isn't absolutely necessary, maybe put that to the end.
We had a project that we were working on. The customer that was directing our team, he was relatively new at the client. He was giving us guidance on what
he wanted to work on. We ended up in a situation where there was a system that wasn't quite working yet. They had to ship it out to their client. And this
particular project manager was really focused on how the look and feel of the touch screen was. He wanted to look like an iPhone. He was worried about the
corner bevels of the buttons and things like that. And he was having the team spend a lot of time on these nuances, and yet the system didn't even work.
So the critical path there completely fell down.
Give your system integrator the latitude to tell you, "Hey, time out. This doesn't make sense." Because we want to please you. We want to do what you are
asking us to do. Give us that latitude earlier on. Say, "Hey, if I tell you something and you don't think it's right, I want to know. Tell me right away
that this is a bad idea. If I tell to focus on the color of a button and the system doesn't work say time out, and let's talk about it."
Don't ship early. This is a tough one. I don't want to pretend I know everyone's business and the challenges of being late on the shipment but I will say
this. When you ship a system early, you may do that because it's not quite ready but you have a penalty with your client if you don't ship it on time.
Really do a cost benefit analysis of paying that penalty versus the extra cost of shipping the system integrator to wherever this machine ends up.
The development cost can rapidly escalate. If we're working on your shop floor, helping you get a machine up and running, we've got access to your whole
team, we can take the system up and down as we need. But once it gets to the end customer's plant, they are in charge. And the development process can
come to a grinding halt, especially if we are trying to develop while production is running. That's a question to pose early on. If you find yourself in a
situation where you may have to ship on, you really sit down with the integrator and say, "Hey, let's walk through this. How is this going to impact the
budget? Because it's not going to be a linear progression." If you need an extra week to get it working, that maybe an extreme week of lots of overtime
and weekend time certainly your costs are doubled for that week and you weren't expecting it.
Think about cost options. Generally there are some other nuance versions of this, but generally you’re working with the system integrator either on a
fixed-bid project where you give them a spec and they give you a price, and that's agreed upfront, or it's hourly where you're just paying for their time.
Figure out what makes sense for you. And really realize that it all comes to risk. It seems great to say, "I always want a fixed price for everything,
that way I am minimizing my risk." But if the integrator is taking in a lot of risk, they have to put a lot of buffer in their quote. Sometimes the hourly
may be better. It may end up being less expensive than the fixed. Also if you are doing an R&D project, it's really tough to do that on a fixed-bid basis
because you want them to be able to adjust quickly when needs change. You want them to be able to stop what they are doing over here and shift focus
somewhere else. It's really had to do that in a fixed-bid basis because they may have to hit you up with change orders and say, "Hey we didn't talk about
this. This is going to cost more." Versus when you are hourly, they do what you tell them to do.
This is my last slide here. Negotiate. Anything is negotiable. So when you talk to your system integrator, they're going to tell their rates and those
rates are based on what they can get, the market demand. But realize that there is things where you can have some latitude there. Generally system
integrators, they want to stay busy. They want to keep their people billing all the time. So if you can offer them some large block of hours, some kind of
guarantee, they might give you a lower rate for that certainty. There may be a situation where there in a "can do" and not a "have done” situation where
they say, "Hey we can do this," and you say, "Hey I believe you we are taking a risk by going with you. Give us a break on the cost." And they might say,
"Sure, we'll do it."
There may be situations where you can't really negotiate. When you call in the wolf, and it's a Saturday or something like that, you just have to bite the
bullet and pay the rate. But there is definitely a lot of latitude for negotiations. All right any questions?
Bob: Thanks, Tim. That was great presentation. We appreciate that. We have time for some questions. I'm the roaming microphone if anybody has any
questions. Yeah, I will ask a couple at the outset. Obviously your business has gotten bigger and better and faster over the last few years. You guys seem
to be the midpoint between the supplier base that is looking to get into some of these manufacturing facilities. And the manufacturers who either don't
have the time or the in house expertise to be able to deliver on their vision for improving their facility. Can you talk a little bit about what the
market has been like and also a little bit about what, from a manufacturer's stand point you are seeing, the most kind of request for?
Tim: The most kind of request I get ... well, I mentioned in the presentation that we are doing a lot of conversions where a lot of our customers we're
seeing that they typically were selling domestically and now they're shipping a lot of products overseas. They've kind of opened up the European market.
And with that, there is a demand for different platforms. The most classic one is they sell Allen Bradley as their processor in the U.S. and they need
Siemens for the European market. So we actually do a fair amount of projects like that. We call it a conversion project, a lot of times it ends up being a
Bob: And different standards between the U.S. and Europe.
Tim: Different standards, different preferences, programming language preferences for sure.
Bob: Our distinguished representative for Control Engineering.
Audience 1: Tim, a lot of great information. Of all the tips that you gave, what are the three top things that people usually miscommunicate when talking
to system integrators or misunderstand? What could they take away as key improvements and their communications with the system integrators?
Tim: Key improvements? Let me think about that for a second. I guess we struggle the most with customers that have maybe been burned in the past by
another company. So it's hard to establish that initial trust. So that's why we push the early communication, the open-door policy, things like that. We
invite them to come to the company and really evaluate the team. I guess building that initial trust, that rapport. Ultimately you buy things from people
you like and trust. So it's establishing that initial trust is probably the most important thing.
If you are working or considering a system integrator and it just doesn't feel right, you just don't like them, then don't work with them. Because it's a
relationship like any other. And if you really don't like the people you are working with it's not going to go well. So establishing that initial rapport
I think is really critical. I mentioned this but the licensing terms are really important. Really make sure you understand that upfront or you can get
Audience 2: Can you walk through ... good presentation, Tim ... how you get started to work with the company like DMC? Are you working, in food and
beverage company let's say for example, and they contact you? Is that the plant manager? Is it the design engineer? How does that get started? You have a
list of questions that you ask back to the client so you make sure that you guys are on the same page?
Tim: A lot of times, it maybe a plant manager. If it's a larger cooperation, they may have a global engineering team and it maybe someone from that global
engineering team. I guess the questions that we ask, they are always related to understanding their capabilities in-house and how we can supplement them.
Sometimes their capabilities are extensive. And we're just helping them out in a few areas. It's finding out the Venn diagram of what we do and what they
do. And where there is overlapping and it isn't and figuring out that fit.
So we ask a lot about their technical expertise in-house. We ask about budget is a good one. You can really have a really short conversation if you are
talking to a customer and they have large ambitious project but not a lot of budget for it. There is now a whole lot of room for moving forward unless we
breaking it up into little tiny steps. Usually we try to get that information up front. Other questions?
Bob: Other questions? Well, I want to thank Tim for the presentation. Great job, thank you very much, Tim.
Tim: Thank you all. Thanks, Bob.