The Interpreter
You’re the Implementation Manager for a large TMS / WMS implementation. You’ve gotten to the point where it’s time to sit down with the Finance group and talk about integration with your current financial package. Your company (let’s call it ABC Distribution) has a fairly complicated accounting process utilizing not only your standard credits and debits, but also accrual and reversal transactions. So Finance comes up with their ‘standard’ requirements using their jargon and passes them along to you. You then take them to the vendor who tells you what is feasible ‘out of the box’ and what is going to take development. Cost (as it always is) is an issue, so in trying to keep it down, you go back to Finance and see what they can bend on. Finance doesn’t understand why the software can’t handle their requirements without modifications. Surely ABC Distribution is not the only company out there that handles accounting in this manner?
After a couple of rounds of going back and forth between the two groups you think you have it all ironed out. Requirements are submitted and the interfaces created. The first cycle of testing comes around and your financial package won’t recognize the accrual transaction. After some research you find that although the vendor put the designator on the correct line item, Finance wasn’t as clear as you had originally thought on how the transactions would be passed. Something was lost in translation.
Sound familiar?
All too often in an implementation, a major gap is created between internal groups within a company. Let’s face it; IT talks a unique language, Operations and Finance as well. In fact, I often liken large companies to that iconic view of New York City…the ‘melting pot’ where people from all over the world come to gather…a multitude of cultures and languages existing in one central area. It can be hard to communicate at times with all those difference floating around. That’s when it’s nice to have an Interpreter. You can use someone who understands all the different cultures and their languages. Someone who has spent time with these people, knows how they work, the subtle differences between them and another group, and knows how to communicate those needs from one group to the other.
Interpreters come in handy during an implementation as well. In the example I outlined above, the Interpreter could have come in with knowledge of the vendor and the software and met with Finance as you had done. However, the Interpreter would have talked to Finance in their language when discussing the interfaces…explaining the software’s base capabilities up front in a language they could understand. Then that Interpreter could have translated those Finance requirements into something easily understood by the vendor. There would surely still be iterations of the requirements, but it’s the Interpreter’s job to ensure that they are fewer and more concise. That way, nothing gets lost in translation.
The role of Interpreter is one that Scott Sheldon takes very seriously. Our team has served in multiple industries as vendor, end client, and third party integrator. We’ve been through the pain of having that implementation go south because someone didn’t understand and we LEARNED from it. We’ve taken that experience, along with our depth of technical and operational knowledge and made it an integral part of our methodology. It’s right in there along with our belief in the ‘Working Practices’ talked about last week in this blog.
I’ll be writing more in the weeks to come on the Interpreter and bridging those internal gaps that can exist within a company during an implementation. In the meantime, if you think you would like to hear more or could use an ‘Interpreter’, please give us a call.
Author: Kevin Holmes
