Graduating Bentley University with a Degree in Computer Information Systems, I knew I always was interested in technology and how it could improve our lives. I felt that just a technology degree was not enough, and went back in for a Master's Degree at Bentley which would help me better understand a businesses needs and priorities.
Starting my career early on, I implemented an early version on an ERP system at a small manufacturing company. Since it was a small company, I was also involved in putting together the financials and closing the fiscal months. From there, programmed in Foxpro prior to moving to GE as a Business Analyst during the .com days where the goal was to put everything on a computer. I overlapped into a more technical role there as one of the data collection applications was poorly designed and needed to be rewritten from the ground up.
From there, I migrated to an Inventory position helping to define and communicate the KPI's around inventory to the Power Business at GE. A key part of the inventory position was that my boss was also the Lean Leader for GE Energy where we traveled to many of the locations hosting lean events which were used to remove waste, but also to help train the locations on some of the Lean practices. This naturally fed me into a role to be the Functional Track Lead for the Oracle implementation for the Wind Energy Business. After the Wind implementation, I transitioned to the Oil and Gas division where I managed a planning department, and also worked on another Major Oracle implementation.
Next, I left GE to work at Exterran where I managed the planning department improving the OTD to near 100% from in 35% by effectively managing the ERP system to provide the right visibility to the business. The compression division was then sold to Compass where I defined processes and data elements to align to the business needs using Microsoft NAV. I then formalized some of the data required to run the business into Power BI, which involved some complex SQL queries in the back end.
Get to know me by reading through some of these pages. I tried to break down my technology background to give an idea of what I have done as well as the supply chain to see where the two might overlap. I have not included a section on Finance, but in addition to doing some programming projects on the side, I am an avid investor and enjoy analyzing balance sheets, income statements and cash flows of various companies and industries.
My first love is computers and all things technical. Ranging from recursive SQL Queries, to massaging the data in Python, JScript, or Power BI, I have worked in all areas, but my natural strengths are understanding data structures and reporting.
With a Master's Degree in Finance, I am conversant in much of the Financial reporting needs of your business. Whether it is related to analyzing cash flow to pulling the NPV for an investment opportunity, I have the educational background for your needs.
Having worked Lean in much of my career, I have been involved in countless Kaizan events, worked to migrate a business to single piece flow and remove waste from various processes. From the shop floor to IT solutions, I have applied Lean Principals to many areas.
Relevant Degrees
Years expERIENCE
ERP implementations
Languages (computer)
One of the things that often gets overlooked in one's career is that people want a simple answer. Let me give an example where an ERP system was providing a lot of unneeded messages to the business that were causing confusion. The messages were a result of customer changes, engineering changes in schedule and design, desire to balance the workload in the shop, etc. This was the business model, they wanted to be flexible, but needed firm answers, and based on the size of the team, could not manage through a large volume of messages. After some long, complex discussions trying to educate the team on how specifically the ERP engine was calculating the needs and messages, I asked the purchasing manager, "What is it that you need to be successful?" His response shocked me in
that it was very simple. He did not care about the origin of things, he realized that things shift naturally, but wanted to know the answer to 4 questions:
1) What do I need to order?
2) What do I need to expedite?
3) What do I need to cancel?
4) What can I defer?
I was able to work with the BI team to put these answers in a simple format that all would understand. As a result, it improved the communication for the purchasing team, but also manufacturing and planning who now had better visibility to when their material was coming in, and if it was going to be late, they knew how late it would be.
Do not every sell yourself short, and think outside of the box. The day prior to Labor Day, I was the Bangor ME site manager for an international company and a virus hit at 8:00am. The IT Security team called and mentioned that they had run a scan of all of our PC's and we were infected. They needed me and my team to go to each PC (which we had to find by name), unplug it, load the antivirus, then wait for the whole network to be cleaned prior to putting it back on the network. These were the experts, but it seemed like it would take forever to accomplish, so I rounded up my team, and by lunch time, we had put together our own network scan, and patching of all PC's, and the site was clean by lunch time. We broke up the tasks into smaller components. First, get a list of PC''s attached to the network, next if the PC was not infected, then patch it so that it could not be. Finally, if it was infected remotely run the AV software. We broke these tasks down by expertise among my team, and different from the corporate team who was experts on the virus only, our team was versed in many disciplines from scripting, to desktop support, to security. Using the team with diverse backgrounds and expertise allowed us to put together a solution that played to the strength of the individual and made us stronger as a team.
One of my bosses had a favorite saying. Is it scalable? At the time, I did not give that too much thought, but it has been one of my favorite questions to ask prior to setting out on something. An example of this, was when we were looking at how to represent a Bill of Material. The BI team I was working with wanted a rigid structure and to know how many levels the BOM consisted of, what was contained at each level, etc. They wanted the basic BOM, but without specific item numbers.
Then came the question, is it scalable? Ironically, many programmers will understand this logic perfectly, but in this case the programming team was thinking in a fixed box. They did not consider that things change, the company may want to restructure the BOM, or they may want to enter into a different product line which has a completely different BOM. In this case, the design looked at things at a higher level. Instead of having a widget that consisted of x number of components, the solution was forced to zoom out a little and see things as make or buy.
If we made something, then one of the components could be a make, and one of those subcomponents could be a make and so on. If you look at the world through that prism, then it makes no difference what the structure looks like, or how many levels it is. The solution will become nested until it reaches the natural conclusion. So, in the final answer, is yes. The solution was scalable.
Having something that does not scale will essentially be throw away, and single purpose use. If you are designing a software solution, or a manufacturing process, the logic applies the same. What benefit can I derive from my solution?