CI and innovation are closely related. Both promote operational excellence and can provide competitive advantage. The difference to me, from a practical standpoint, is that CI is more structured and incremental in approach, whereas innovation involves taking bigger steps while often using out-of-the-box thinking, unique combinations of capabilities, and even serendipity. That’s a generalization, but that’s how I tend to differentiate them.
What does innovation mean in the context of an EDI team? Let’s see, you have the standards, you have maps, data comes in and gets processed and dumped into your ERP, right? And data generated by the ERP is processed by your translator and goes out to the VAN, correct? What’s there to innovate? Well, not much if you define your role like that. However, if you look at challenges you face in the end to end process, as well as in tangential activities like project management and workforce management, you can identify a plethora of opportunities for innovation. I’ll give you a quick example, one that I’ve used before.
A common challenge we faced was with Unit of Measure for our customer orders. We classified everything as EA (each), while some customers ordered in other UOMs (pieces, cases, pairs, etc.). Often the quantities would differ, so one EA of a light bulb on our end would equal a single bulb (at, let’s say $1), but a customer would order one case and expect 12 bulbs (at $12). To make a long story short, we used the customer expected price condition in SAP, set up price tolerance percentages, passed the relevant mismatched codes into text fields on the order, and kicked out mismatches for review. A support person would then note the discrepancy and either contact the customer or fix it. There are a lot of ways to skin that cat, I think, but the more logical approach of building customer-specific cross references didn’t appeal to us due to the size of our catalog (hundreds of thousands of items) and the number of customers we dealt with in our program. That’s just an example of taking a little bit of existing functionality on both sides of the intersection of our ERP and translator and putting together an approach that, while not perfect, did the job for us and our customers.
So, how do you innovate? Does your boss allot you some time to sit around and think deep thoughts? Is there a prize each month for the best idea? There’s no right way or wrong way. As a manager, I tried to create an atmosphere on the team that encouraged ideas and let people know their thoughts were valued and would be properly evaluated.
Through the years, we used a few different techniques to develop solutions to both ad hoc problems/projects and to develop roadmaps for innovation of our processes and technical environment. What these techniques had in common was getting together key people from among our analyst/mappers, technical staff, and operations support who were smart, knew their own roles very well, were opinionated, and had a passion for what we were trying to accomplish. For ad hoc situations, we’d pull a small group together in a conference room, explain the problem, and then talk it through. For longer term issues or for planning purposes, we would convene a group either on a scheduled basis, for example once a quarter for a long meeting, or would get the group together over breakfast or lunch weekly or on some other scheduled basis. We tended to call them ‘brainstorming’ sessions, although we didn’t strictly utilize traditional brainstorming techniques. The outcomes were generally excellent- we would exit the ad hoc meetings with either an approach we agreed would work, or at least a direction that required further analysis. For the planning sessions, we would generate ideas, add them to our project list, and prioritize them. A key area of focus, for example operational support, might be how we would group together several ideas so that we could talk about and address them together.
The cross-team discussion and willingness to question, challenge, and propose ideas produced some of the most powerful innovations we developed. We didn’t have breakthroughs at every meeting, but we did knock off quite a few while developing the camaraderie and level of trust necessary for future advancement. I can’t emphasize enough the great feeling that can result from the creation of a truly cross-functional solution to a problem.
I’d strongly encourage you to introduce brainstorming or a small group ‘SWAT’ team approach to problem solving into your workplace. If you have a management role, it’s up to you to make it happen. If you’re an analyst or support person, talk to your boss about it or take it upon yourself to start down that path. The key thing is to recognize that no one can do it by him or herself, and that innovation is often the result of collaboration. Here are some guidelines I’d recommend:
Get the right people involved.
- They need to be bright, skilled, and committed.
- Include roles from across the team.
- Broad skills are extremely helpful. Our key technical people in the group had experience on the mapping and project management side, our strongest analysts came up through the operational support ranks, and one analyst had very strong technical skills from a prior consulting role.
- Keep the group at a manageable size. If you have a small team, everyone can take part, but for a large team you should be somewhat selective.
Make it informal, but make sure discussions are documented and there’s someone keeping track of commitments and assignments. These meetings can ‘run long’, so be careful with scheduling. You really don’t want to prematurely end a discussion that has the opportunity to yield far-reaching results.
Ensure you have your manager’s support. Don’t go behind anyone’s back.
Have an idea of what you want to accomplish each time you meet. Just having an open-ended ‘brainstorming’ session can sometimes produce results, but it can also end up as a free-for-all. A good example would be to get together to talk about ways to automate some of the manual work that operational support people are performing.
Somebody needs to be at least nominally ‘in charge’ of the meeting. You can rotate the responsibility, but it’s important to keep the discussion on track.
Don’t allow personal agendas, personality conflicts, and the like to hijack the discussion. This goes back to the original selection of participants- if you don’t think someone will respect the goals of the group, don’t invite him or her.
Make sure you have some guidelines in place to pull the group, or a subset of it, together to address a specific issue. An analyst having a problem with a map isn’t generally a good enough reason to pull your most valuable people away from their work. However, to evaluate an idea that came from another department to automate something in their process may be a great time to get ideas from across the team on the best approach.
If the manager wants to participate, that’s fine. You need to make sure he or she isn’t an impediment to people freely expressing their ideas, though.
Make sure you share information about successes across the team. We made it a point to recognize important improvements and solutions during team meetings.
Some of the most fun I had at work over the years came from participating in our team’s brainstorming sessions. It was great to see the interaction among talented people who truly had our team’s and partners’ best interests in mind. As a manager, I was able to better appreciate the quality and skill of my people, and as a participant I’d like to think that I was actually able to contribute from time to time.
“Innovate or die” is a quote that’s been around for a few years. It’s very true in our world. The pace of change is accelerating, and to keep up you can’t depend solely on incremental improvements. You need some home runs from time to time. Use your brain, and try some brainstorming, to make those breakthroughs that can keep you ahead of the curve!