Blog Archives | Page 3 of 3 | Spring Automation

July 10, 2018April 23, 2020Blog

8 Key Steps for Automating Processes

It would be great if everything in life could have an easy button that we press and know that things will get done. This is especially true at work where there are tasks that are repeated daily, monthly, quarterly, and so on. The thing is that this can be possible with automating processes. There are abundant benefits of automation that vary from team-to-team. They can range from reducing errors in more complicated tasks to reducing hours spent on easier tasks, which allows for more time challenging team members to innovate.

I started at a company late 2016 that was very committed to developing and automating processes that gave me many opportunities to work toward innovation and process automation. This year our controls group is growing as its own company with the same focus on innovation that is fostered in our family of companies. With what we do, we found that there are many tasks that our job requires that are consistently repeatable within a typical project. Many of these tasks are not always overly complicated but often are very time consuming. With this is mind, we have disrupted many standard processes and created new tools to automate parts of our job. Automation has given us more time to dedicate to further innovation that we will continue to build on. I believe there are 8 key steps to take to automate a process that we will apply as we continue to develop more tools.

1. Determine Repeatable Tasks

Start by determining the tasks that are repeatable. Review the current processes in place and see if there are steps within that process that are repeatable. Maybe it is a task that is done daily, monthly, or on every project, but be sure to evaluate tasks that will be done consistently over time. A task may already be a part of a process but avoid trying to automate too much of a process at one time. It is easier to determine milestones and set goals for completion if clear tasks are set instead of trying to change an entire process with many steps that can be automated. During this phase working to have clear tasks to automate versus an overall process will make it easier for when development projects are being “ranked” for priority.

2. Rank Tasks to be Automated

There are many factors that go into why a task should be automated. It could be that the task is time consuming, results consistently have errors, team members find the task complex, or team members may be bored by an overly simple task, for example. During this time communicate with team members who follow the current processes to fully understand where the most impact can be made. The earlier that the team who will be developing, using, and maintaining a tool feels ownership over the automated tool, the easier implementation will be and more committed the team will be to complete a successful tool. Also, be sure to take into consideration that amount of development time that is expected for a new tool and process. Sometimes a current task that may be considered easy to complete can be the best to start with if it can be automated quickly. The time it takes to automate a process can be just as important to consider as the overall impact it is expected to have. Once the biggest needs are determined and balanced with time restraints and other factors such as resource availability, rank the tasks in the order that they will be automated.

3. Prepare a Presentation

Most likely, the need for automation arises from within the team who follow the processes and need to present the ideas up. It may be that a gap needs to be filled and there is time to dedicate to improvements, so the idea needs to be presented to a development team and future users. Either way, a presentation catered to the specific audience that needs to buy in must be created. Know if numbers and graphs have impact or small demos are more effective. Be careful not to spend too much time at this point creating a demo because it is important that the development team has room for creativity. It can be limited to user interface or show the expected results and deliverables created by the tool, depending on what is most useful for the presentation. Most importantly make sure the ideas presented have clear timelines and deliverables associated with them to measure success and define completion.

4. Define the Development Teams

Once the approval for development is there, determine the key members for the development teams. Treat this team like a project team, meaning there are milestones and deliverables clearly defined. Development team size will be determined by the size of the group, timeline, and tasks to be completed. A leader is needed for each development project. This person will drive the team to hit milestones and have accountability for the end result. There need to be people developing but it is also very important to have someone different to assist with debugging and testing. Someone who is not as directly involved in the project may see things in a new or different way that better challenges what is in work.

5. Develop an Execution Plan

With a development team in place that has clear goals and due dates, plans can be made. This is the time where specific tasks that go into achieving the goals are outlined. If there is already a manual process in place that is clearly written out, defining the tasks to replace the different steps can be relatively easy. If a new process is being added with automation in mind, it is good to think through each of the steps that it takes to get the end result to define tasks that need to be done during development. After defining tasks, a schedule to complete, verify, and test each piece is needed. Team members will be able to make commitments to completion with measurable results.

6. Own It

After laying out the tasks that need to be done to achieve automation, it might be a bit overwhelming and could be easy to settle with continuing the current ways of working. Be prepared to show the team the potential impact the new way of working can have on the current operations. There will be challenging questions at time that need to be answered quickly and positively. There will also be the typical opposition to change from part of the team. This can be reduced by making sure the team feels ownership in the development and excited to share the results.

7. Execute the Development Plan

Now it is time to start implementing the plan and creating tools that are usable. This part of the process should be tracked with the measured progress reported regularly. The execution is very specific to what is needed for the operations. It could range from writing automation programs to creating reusable templates to defining standard processes. As mentioned in the planning, work toward making pieces testable and usable as soon as possible while keeping the big picture in mind.

8. Debug and Test in Real-Time

Debugging and testing are critical parts to the success of adding any new tools and processes. Properly testing out an automated process may be the most important of all the steps for automation. Knowing that a team can already be more critical of using something new, it is important to make sure that the new way of working does work. This cannot be rushed and can often take several test projects before it is ready to be rolled out to the team. It is often helpful to be able to even use old projects for testing that have a clear result to compare to. The earlier the testing can begin, the better. Starting testing before a final product is complete can be helpful because at some point development must stop so that the tools can be applied to execution. Once testing is complete, the new tools are ready to be applied.

Now that the automation has started, there are a few things that are important for the continued success. There need to be clear procedures for how to use the tools developed as well as a clear process for implementing changes and improvements over time. As key users use the new tools, it is important that they can provide feedback. Keep data to show improvements to report to the group to increase excitement as well as the executives to get more R&D time for the team. The team should clearly feel the benefits of the automation, encouragement on the new success, more time for development projects, or even more time off. Know that once automation is introduced, there is always more that can be done. Be open to improvements and changes as the team adapts and enjoys the automation.

Chelsey Arnold - VP, Operations

Chelsey joined Spring in 2016. She has worked for two large, full system integrators based out of Atlanta in various roles ranging from hardware design engineer to controls engineer to controls group lead.

Click to Read

March 22, 2018April 23, 2020Blog

My name is Tim, and this is my story

People always ask me, “What’s your degree in?” And my response is typically, “Which one?” Like many others my age, I spent my first four years of my liberal arts education undecided. In fact, I spent most of my twenties indecisive. It’s a trait that is by and large frowned upon. After my snarky response, if that individual inquires further, I then explain my first Bachelor of Science is in Psychology. Although I am currently advancing my career that sprung from my Bachelor of Science in Engineering, the looks at this point are always enjoyable. “What in the world do Psychology and Engineering have in common?” The commonality of my two degrees is irrelevant. Sure, I can make out the correlations, but really, those degrees are documented proof that I cannot make up my mind. However, instead of indecisive, I prefer the label of “Jack of all Trades.” After all, isn’t that what makes great engineers?

I made a pit-stop studying History and becoming a teacher. I completed my first practicum at a middle school and quickly discovered my love for history and teaching didn’t go together for me. Following graduation, I became an In-Home Family Counselor. The title sounds rather important, but I was essentially a case worker along with other social work majors. I helped develop treatment plans that parents and guardians implemented to keep their at-risk youth out of trouble. For seven months I saw a multitude of things that caused me to mature quickly. Between barely being able to keep it together emotionally some days and getting married in month six of those seven, I decided to leave that job. Growing up with a solid family structure in the suburbs of Chicago where nothing happened, these seven months as a counselor gave me a completely new view of the world and how I perceived myself in it.

To be a good husband that provides, I worked several temporary jobs over the next couple years. My favorites were being a light technician and a waste water tech. With the former I got to hang lights on trusses, wire them up and then program shows per the director’s request (sounds like engineering). With the latter I spent mornings collecting waste water samples from around the city to then be tested in the afternoon to create data points that could be analyzed (sounds like engineering). I applied for a permanent position with the waste water facility and was turned down because I didn’t have the “correct degree.” It was a rather disappointing and dejecting moment.

Almost immediately after that moment, however, I was presented with an opportunity. Since my wife worked at the University where I had previously graduated from, I could take advantage of the spousal tuition discount and maybe get a degree I “can actually use.” But what do I want to do with my life? At 25, I found myself asking the same thing I did at 18. I knew I had a good heart, but counseling showed me I didn’t have the stomach for trying to fix social issues that plague our society. However, I was kind of good at math and my favorite jobs up to that point had some sort of hands-on technical aspect. It was so obvious, wasn’t it? It was plain as day the whole time.

In Engineering 101, the professor said, “Welcome to the major. The next four years will be challenging, but afterwards, you can go do whatever you’d like.” Music to my years. I chose Mechanical Engineering, but fast forward to the present and, SURPRISE, I’ve done nothing mechanical engineering related. It’s been all electrical as a Design Engineer and now a Controls Engineer. The degree was difficult to obtain while balancing a marriage, work, and a new baby. But now, I had something that said I was not only good at math, but that I can probably figure out any problem that faces me or my team. That’s the magic of being an Engineer. You don’t get pigeon-holed into a singular career path. Not only are there endless engineering disciplines to choose from but I don’t have to stay technical. Engineering also opens the door to managing projects or managing people (Psychology actually helps here).

This article has been very self-focused because it’s super easy to talk about yourself, but my hope is that this is viewed as a sales pitch for being an Engineer. Career opportunities are limitless, and the demand is high. It seems that companies are always hiring, and recruiters are trying to be your LinkedIn friend every five seconds. Now there is one catch, and it’s the same with almost any career choice: You can earn the degree, but experience gives you a story to tell.

Allow me to once again indulge into my story, but I learned this quick, fresh out of graduation. I was all in with the finding the perfect first job. I researched almost 100 companies, sent introductory letters followed by another letter with my resume informing when they could expect a call from me. I called and spoke with managers, directors, VPs, and presidents selling who I was and requested an in-person interview whether they were hiring or not. I got several interviews that way but got only one job offer. It was with a small startup company, and all I got were verbal commitments. Nothing was in writing (don’t do that by the way). So, I moved my family to Nashville, showed up the first day to start and discovered the President who hired me was ousted and that I no longer had a job offer.

I found myself without a Job, my wife and I were expecting baby number two and we were living with my father-in-law. I had the right degree, I knew I could be anything and the “Mechanical” part of my degree was not a hinderance because the “Engineer” part is what mattered. I pulled together all the humility I could muster and went back to the temp agency I worked with before my Engineering degree because I still needed to put bread on the table. My only request to the agent was, “put me in a place with lots of engineers.” When you don’t have experience yet, it’s all about creating a network (not to date me but this was before LinkedIn did a lot of this for you). The agent got me a job where I would braze and weld since no “office jobs” were available. I talked to anyone who had engineer in their title while I was there. After only two months, a Design Engineer position opened, and I was hired rather quickly.

Side note: it’s important to remember to make the most out of the day that’s given to you. Since I have kids, we watch a lot of family animation movies. In Kung Fu Panda, Oogway tells Po, “Yesterday is history, tomorrow is a mystery, but today is a gift. That is why it is called the "present.” Course this saying doesn’t originate in this movie but it’s still great. “Carpe Diem” is also popular. Matthew 6:34 says, “Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own.” When I found myself with a degree and no job, I couldn’t worry about if I would ever be an Engineer. I just needed to walk into that temp agency office and ask a simple question, “What’d ya got for me?”

I now work as a Controls Engineer with Spring Automation. Working at Spring is considered a career change when compared to what I was doing, but I decided I wanted to get involved with PLCs, HMIs, and integration. It seemed cool, seemed fun, and offered new challenges. I made this change with little impact to my overall career because I still had that key word in my title; “Engineer,” the profession that’s the “Jack of all Trades.” When I meet other engineers, I love to ask what they did before being an engineer. It is rarely someone who went straight into it from high school. These engineers I meet were once construction workers, farmers, mechanics and family counselors. Nothing is wrong with those professions, it’s just engineering caters to the one who always wants a challenge or changing environment, who might have a little A.D.D. or who might be indecisive. Problem solving skills help too. Other professions offer these caterings as well, but Engineering is more fun than work. Trust me, I’m an Engineering Psychologist.

Tim VanCleave - Controls Engineer

Tim joined Spring in 2016 and has led projects for multiple parcel customers. Over the course of a project, he has completed engineering work such as design, programming, and system start-up while also overseeing electrical installers and procurement.

Prior to Spring, he worked for Chromalox designing heater control panels. He served as a design engineer where he designed relay and PLC control panels, wrote stepper PLC programs and oversaw the panel builds.

Click to Read

January 17, 2018April 23, 2020Blog

Stop Confusing Operators With Your HMI Screens

How many times have you been on a job site and been asked to solve an unexpected problem that arises with the system? Every controls engineer who has been in an industrial setting, for even a short time, has faced this situation. Typically, the first move is to check the HMI, or Human-Machine Interface. An HMI is one of the best ways for employees to interact with and observe the state of the equipment they work on. While there are many factors that go into the development and design of an HMI application, the two most important things to take into consideration are clarity and simplicity.

Clarity

Having a clear HMI display is crucial when the system goes down. The operator needs to be able to distinguish what a symbol or object represents in the field. If the operator spends more time searching screens to find the information he or she needs than they would chasing the physical problem in the field, then your HMI is not clear enough. This might sound obvious, but too many times, someone creates an HMI without considering the actual functionality. It is very important to keep the user in mind when designing your HMI. Giving objects clear and accurate labels and making the objects depict, as closely as possible, what the object physically looks like will greatly decrease the amount of down time a customer will experience when using your HMI. Another thing to consider when designing is the contrast between the colors that are used. If two aspects of the system are supposed to represent completely different things, make their colors distinctly different to avoid any confusion.

Simplicity

Simplicity of an HMI application, like clarity, is an important characteristic when it comes to finding a quick solution to a problem. The “Less is More” mantra is precisely the strategy you want your HMI design to follow. The main question to ask yourself is, “What information is essential to the operator?” A good practice is to give the operator only the information he or she needs to monitor and troubleshoot the system. The addition of extraneous detail will only lead users down the wrong path to the solution. A cluttered screen only overwhelms an operator when he or she instead needs composure to focus on solving the problem. The bottom line: keep it simple.

In the end, a break in production is one of the worst and most stressful things that can happen in an industrial setting. When creating an HMI application, keep in mind that you are creating a tool to help others in a huge way. Being able to quickly locate and solve a problem not only helps the employee succeed, but also ultimately helps the customer succeed. After all, as an integrator, that is our goal.

Brady Chandler - Engineering Scrum Master

Brady joined Spring in 2017 and has been involved with many projects for multiple parcel customers since. Over the course of a project, he has completed engineering work such as design, programming, and system start-up while also overseeing electrical installers.

Prior to Spring, while in college, he worked in a food manufacturing facility where he served as an intern guided by an engineering team that helped him to learn the basics of the manufacturing industry. He picked up many skills while working here, most of all learning the ins and outs of AutoCAD as well as getting the opportunity to assist in an expansion project in a new section of the facility.

Click to Read

January 17, 2018April 23, 2020Blog

7 Steps to Always Innovating

How to help your team to always be innovating and embrace the changes.

I am often asked to reproduce the results of my team in a more predictable/ faster way. I find the best way to accomplish any task is to automate every process possible. I love to innovate and have had some noteworthy success thanks to some awesome engineering teams, yet I have never truly run an R&D group. I’m always curious how to do things better, so I spent some time over the last few months reaching out to former compeers asking what they were doing to drive innovation. What I found was a little shocking. I was finding that many of my peers had little or nothing to do with the innovative process. My company doesn’t have an R&D department, yet each month we are making tools to improve our products and processes. Today we are growing a team at a rapid pace and time comes at a premium. In my career experience, innovation was all too often sacrificed for the needs of the individual project, but today my team feels the risks of not innovating outweigh the risk of caused by the change of innovating. If several projects can reap the benefits of one innovation project, it is time to analyze the use of your resources. More often than not my team is making small advances in changing how we work, and this year we expect some big leaps. Here are the 7 steps that opened my team up to always innovating.

1. Start with a good culture. People want to contribute more, when they feel valued. Spend some time each day learning new things about your team, and letting them learn about you. Work shouldn’t be all about making sure you have the right coversheet for your TPS reports.

2. Do spend time brainstorming with your team. Start with simple questions. “What processes are taking the most time? What could we be doing better? What do our customers say they want?”

3. Do not make decisions by committee or vote. You are there to lead, so own it. If you are not the most knowledgeable person on the subject matter, appoint the person who is. Give them the authority to make decisions, and challenge them on the “why” even when you agree. Collaboration is about working together, and good leadership makes it happen.

4. Ensure your team participates in the positive side of innovation. Have you ever heard “the best engineer is a lazy engineer?” Well, if your reward for a job-well-done is more work, you may find yourself without a good engineer. If the team creates an internal product that reduces their work load don’t immediately jump to finding more work to fill that available time. I have found the best use of that time to be given to more innovation. Many of my team members don’t see innovation as real work because of the enjoyment they have doing it.

5. Plan! No plan is perfect, but no-plan is a disaster. Who’s in charge? What are the deliverables, and when are they due? Being able to hold your team accountable to the plan is sometimes more important than the plan itself.

6. Kill bad decisions immediately. It doesn’t matter who made it, or why, the moment a decision is identified as the wrong one, correct it! I am often asked “Are you going to change your mind tomorrow?” My reply is always “Probably.” Initially I think this one is maddening to my team of engineers, but over time they adapt to it, and even grow to love the philosophy. Most of my team has worked at a place where something became an obviously “bad” decision, yet the same path was continually followed because it was part of the original “plan.” Would you rather stick to a bad plan, or risk looking like you change your mind from time to time?

7. Have Fun! Innovation is awesome! What better way to see the creativity and capability of your team come out? It should be something you and your team look forward to doing. Take time to enjoy the moments, and celebrate the wins.

January 17, 2018April 23, 2020Blog

Change – The Reason ‘Agile’ Will Elevate Your Controls Team

Successful projects require effective project management, and with multiple management styles at your disposal, how do you choose the most effective if you’re a controls engineer?

The most common approach is Waterfall. Think of a project schedule where each successive task requires the preceding task to be completed first. This traditional management style is a three-stage process. First, you Design. Next, you Build. Then, you Test.

Even though Waterfall is used most frequently, this doesn’t mean it’s the most suitable approach. In controls engineering, CHANGE is inevitable and constant. Project scope is frequently redefined, and design and installation tasks take longer or shorter than expected. For this reason, Agile is more conducive than Waterfall for controls projects.

What is Agile?

In short, Agile is an iterative process. It includes the three steps in Waterfall (Design, Build, Test), but these steps are repeated multiple times in Sprints. These are time based mini projects within an overall project. The goal of a project is called the Story. A backlog of tasks must be completed to fulfill this Story, and so before each Sprint, a set of these tasks are strategically chosen from the backlog and assigned to be completed.

Three Major Differences Between Agile and Waterfall

First, Agile is flexible while Waterfall is rigid. In Agile, you can go back and complete a task by simply moving it into the next Sprint. Waterfall, however, does not allow you to move backwards without changing the remaining tasks in the schedule. This is highly problematic when change inevitably occurs.

The second major difference involves customer interaction. In Agile, interaction is constant while in Waterfall, customer interaction varies. During testing, interaction is often high, but during development, it is often low. This lack of communication in Waterfall can cause a lot of re-work because mistakes or changes in scope are discovered much later.

A third major difference involves leadership roles. Waterfall has a traditional project manager who manages timeline and resources. Agile, on the other hand, has a scrum master, who focuses more on the team like a coach. A scrum master facilitates the so-called scrum, a collection of individuals who work together in the Sprint, by removing obstructions and monitoring individuals progress.

How Does This Apply to Common Controls Engineering Tasks?

Controls Design usually follows a common order. First electrical schematics are completed, then PLC programming, and then HMI programming. Waterfall sees a project as a sequence and waits for each of these design tasks to reach a certain stage of completion before starting the next task. An Agile solution views a project as multiple smaller projects. Each of these smaller projects designs, builds, and tests a “product”, even if it is not 100% complete from a Waterfall perspective. For example, in a Sprint, a PLC programmer can develop the tag database needed for an HMI, so the engineer designing the HMI screens can begin developing the HMI application sooner. By facilitating the development of another design application earlier, there is more time available for inevitable changes and adjustments for both PLC and HMI applications. These early “products” are sent to the customer for feedback immediately. This also creates the benefit of discovering mistakes or changes in scope sooner. An example of this is a device layout sent to the customer prior to completing an entire electrical package. Waterfall would wait until the end of the design phase to ask for this feedback.

The benefits of using Agile are also apparent when applied to installation tasks. Commissioning engineers and electrical subcontractors work as a team to deliver the project on time. Sprints can also be used during install to deliver a “product” early that will allow others tasks to begin. “Product” for installation includes things like running conduit and terminating field devices. For example, an electrical installer can focus their attention on terminating devices in a specific area of a system so it can be turned over for checkout. The commissioning engineer can then begin IO checkout and acceptance testing while the electrical installer continues terminations in a different area. This coordination results in shorter installation schedules, earlier startups, and more time at the end and throughout the project for punch list items.

The over-arching benefit in the Agile vs. Waterfall debate comes back to change. By working in sprints, you can deliver “product” early so that changes to scope can be made. By communicating with the customer constantly, you reduce risk because changes are discovered through feedback. Unlike Waterfall, Agile does not see change as a hindrance. Agile harnesses change and turns it into a competitive advantage.

Anthony Osbourne, P.E. - Director of Engineering

Anthony joined Spring in 2016 and has led projects for multiple parcel customers. Over the course of a project, he has completed engineering work such as design, programming, and system start-up while also overseeing electrical installers and procurement.

Prior to Spring, he worked for a systems integrator in Birmingham, AL with projects in the foundry and advanced material industries. He served as a controls engineer where he designed panels, wrote PLC code, created HMI applications, and commissioned systems.

Click to Read