How to Think and Talk about Business Technology with Ben V.
Business technology can be daunting, but it doesn’t have to be. What can be done to make it more approachable?
LIDD founder, Charles Fallon, and guest speaker Ben VanderBeek, discuss how best to think and talk about the selection and implementation of business technology.
Click the video below to watch the complete episode, full of friendly banter and informative insights as Charles and Ben address some key discussion points:
1. The importance of bridging the gap between business needs and technology solutions
2. The significance of clearly defining the problems and requirements before implementing technology solutions.
3. The need for change management during software implementation.
Watch the full video below:
Click here for the Transcript
*Elements of the video have been paraphrased for readability.
Charles, LIDD President
Ben… this is really exciting. You are here in Montreal, and you are famously the oracle of Long Beach. A name earned because of your great wisdom when it comes to all things technology. For those who don’t know Ben, he is a partner and lead of the NetSuite practice at LIDD. So you help clients continually improve and manage their installs and as importantly, implement NetSuite for new clients. I think we can have a very exciting conversation about that, but I’d first like to point out that you’re an icon! You wrote and produced the theme song for this podcast and even enlisted your daughter to help.
Ben, Senior Partner at LIDD
That’s correct. I was in our backyard and hit record on my phone and I was saying phrases to her to repeat. Some of them she said no problem on the first try, but others she had some issues. After 4 or 5 tries at best, she was finally able to come close enough to say digital transformation.
It’s so funny, I think it’s the coolest thing.
The thing that’s great about having you here Ben is that the folks that are listening to this are just like me. Every business is so fundamentally tied to technology, and we tend to treat it with a great deal of anxiety and intimidation. We are lay-people, and then we have these technology people like you who have insights into these technologies. It would be great to have a conversation where we talk to those folks who are the directors of purchasing departments or a CEO. They know technology is needed to run a business, but they are scared of it. I’d like to spend some time demystifying these technologies and what’s going on.
Yeah. I think there are a lot of different angles we can look at it through. One of them is that there is an intersection between what the business needs and how technology should solve that problem. However, there is frequently a chasm between those two. There can be a chasm for multiple reasons but ultimately its that either you need a finance and operations person who is thinking enough about technology and about how it should work, or you need someone on the technology side that is curious, business oriented, and empathetic enough to lean into that gap.
There can be an oversimplification on each side of “well, we’re just like every other company so the technology should just exist and work”. For simple things, that’s true like for help desk software or accounting software. And there can also be an oversimplification on the technology side of “well the business people should know what they want so we’re going to take an order and make the technology do what they want”. I think that having a human being on each side to step into that chasm is crucial to end up with something that is some combination of software and features that support what all the company’s workers need to do.
So I think that’s one thing to demystify. When talking about Enterprise Resource Planners (ERP), we see people from finance and operations departments all needing to update and input data in real time so there can be no chasm between the two. So somebody needs to think about how all this stuff will work at the company and make the technology support that. This may seem trivial and obvious, but it’s just a very frequent gap that often is the root cause of why technology isn’t doing what people want it to do. It’s because some combination of conveying what is needed and having the curiosity to probe for what is needed has not happened. So who cares what’s being implemented because no one really figured out what needs to be implemented anyways.
It’s interesting what you just said. I was thinking it’s a universal problem, right? Just take that example of operations and finance. They both exist in their own language and frame of reference. And even if it’s not a technology question, like racking. The finance folks just don’t have that depth of lived experience to understand some of the critical components that the operations people are giving. But the operations people are so deeply in that world it’s hard for them to pull themselves out enough to express the need properly. I think that’s a universal problem coming from a 25-year consultant. And it’s probably fundamental for all of us to keep that top of mind. It’s a language problem.
Yeah. Every communication has the thing you want to convey (your thoughts), and encoding (the language), transmission, and then decoding. And if you don’t know who your audience is and what they are able to decode, then there is no possible way to convey your message correctly.
That’s right. And we all know, the most difficult people in the world in that process are technology nerds.
Yeah, I think that the skillset that enables somebody to get into the weeds enough and dissect the problem enough to solve it from the ones and zeros level rarely accompanies an incredibly high level of empathy.
So now, what I’m always curious about: as an ignoramus let’s say I run a business. Well, LIDD is a great example. LIDD starts life using a basic accounting package. And we start adding on as needed and ad hoc pieces of software. Expense reports, then time sheet reporting, then managing licenses to be able to use Office software. There are all these things that accrete to an accounting package. And what I think is that there is a certain point where I need something more comprehensive. The way we understand that is “well I hit a certain level of sales, therefore I need”. And I think you don’t subscribe to that point of view.
Yeah. I think that there will inevitably be correlation between headcount or revenue and the complexity of a company’s various pain points and gaps. But it needs to come from that level of intolerable pain points and gaps or things that are preventing you from scaling. So I think that breaking these problems down into “why are we talking about this”, which I would say again is not an easily stated thing.
The why is probably obvious to everyone in the conversation, but its likely not that same for everyone. So for example to ask the question “why does LIDD need an ERP?”, you can ask five people and get five answers: “We don’t”, “it’ll help our budget vs actual”, “it’ll help our reporting and business intelligence”, “our resourcing”. So it needs to start at the level of “well why are we talking about this software anyway” and answering it for that company and for that set of human beings that are trying to work together in that context.
We’re sort of aligned on our high level business objective and why we’re considering a software. That’s great. But what does success look like? Use your imagination, we’re in the future. We have this perfect toolset, what are the types of capabilities that are happening more seamlessly without emails, checking, spreadsheets and all that. I would argue that taking the time to write these things down is great, which many people have a big aversion to. I took a class when I was studying computer science called software engineering. And so this was 23 years ago…
Can’t tell by looking at you! I would have said 8 years ago.
Well thank you. So the word software engineering now is sort of synonymous with software development. But at the time the focus was the engineering process of designing software analogous to designing a building. So the whole class was to write down the requirements of what the software needed to do and then the specifications of how it was going to be built. At the time I thought: “this is for sure the biggest waste of time there ever will be”.
It was so absurd because in school, you’re handed assignments. You don’t have to probe and ask and check, but in the real world especially in consulting nobody is handing you the assignment. Your first job is to identify the assignment then find a solution. So there is a natural aversion to writing down the problem that needs to be solved. But one, it doesn’t actually take a lot of extra time compared to the back and forth conversations that can sometimes take weeks, months or years. And two, it’s very eye opening because it forces everyone to state “these are the must-haves, these are nice-to-haves”.
So now if we go back to the classic situation of me as the average Joe who says “I’ve hit a point where I think our sales have reached a level where we need an ERP”. So what do I do next? I contact three ERP companies who gleefully send sales reps to demo and close as quickly as possible any kind of selection process. And through that demo process, which is a completely sales rep controlled environment, I am going to be looking at must-haves through the lens of “well what do you have for me” and having them demonstrated to me. But your process that you say will be fundamentally more productive in the end is to do the hard work of defining pre-technology “what are the business technology gaps I am trying to close”. Fair?
Yeah. And it doesn’t have to be a 25 tab Excel workbook RFP with 75 questions on each tab. It can just focus in on the things that are particularly top of mind to you. You don’t need to tell your ERP software that it needs to produce financial statements. There are things here you can cut and skip over and say “sure it will do all this stuff”, but if it does not automate this process or support advanced pricing rules… For example I buy and sell food so the prices fluctuate and we have all these contracts where some are dollar markups some are percentage markups. What are those things that are core to your business to solve that are pain points now and approach it from that angle.
Do you feel there is a tendency to fall in love with look and feel more than function, or is look and feel very important.
For me, look and feel isn’t very important. Yeah there can be a tendency to be wowed by the user interface, but that’s the danger of shopping and looking at a few stuff and saying “oh ok great”. So yeah I think that what’s more important than the interface is something that both you and I would argue which is that an ERP is a platform on which and around which to build out the tools to run your business. And there are a bunch of things it does perfectly out of the box on the first try like accounting and journal entries and a bunch of other things.
But to get it to the point you need where initially its doing maybe 75% – 85% of what you need correctly out of the box, to the end of that, you need a trusted human being internal or external who is going to identify and define and close those gaps. So I think that whoever that person is, I ask that person what tool they want to use. If I’m going to hire a professional I’m not going to pick the drills and the hammers and then say “ok, now that I have picked my tools…”
Yeah, build my house but here’s the equipment you must use to do it.
Right. So who do I trust to do this and get me there and to navigate the inevitable hiccups because there’s a cone of uncertainty at the beginning of the project when you make up budgets. And then throughout you become increasingly knowledgeable. It’s a silly practice to say down the line “why didn’t we plan for this?”. Because we know more today, so why do we continue to compare ourselves now to our ignorant selves in the beginning.
So who is going to do this for me, and then what is the tool. And then sure, if something is so off putting about the interface that it’s going to be disruptive then that becomes a must-have which must be considered.
We can go on forever but we try to keep this to a semi manageable half of an average commute.
So let’s pretend I’ve done a selection and I am not about to implement a business software. Whether that be NetSuite, a fabulous product. Or Microsoft’s Business Central, another fabulous product. Or even at the more multinational level those big giant systems. What are the things as a CEO, I have just signed off to go and implement, what should I be keeping my eye on and letting me worry about at night.
Change management. So the internal person running the project rarely also has the authority to make all of the required people change all of their behaviour. So you get a couple of people who are dragging their feet on it who weren’t really bought in or maybe they are being asked to change all of their behaviours and they weren’t involved in the selection process.
Can I just say one thing? Just to put that into people’s minds. We like to say there is a procure to pay process and a order to cash process right? And on the journey from an order to cash there are so many departments that are involved in that complete storyline. And the same thing with procure to pay. So your point is that the internal implementor like the project manager is not going to be able to tell purchasing “here’s how we’re going to do it”. They have to buy in and have a participation in that.
Right. And you should expect and anticipate and actively glean what are the current risks, what are the current blockers, what are the current personality dynamics at play here that are slowing us down and how can I as the sponsor go give everybody a pep talk and here’s why it’s best for the company and that we’re so grateful for your participation and flexibility.
If that is present, and there is some level of morale and some level of “well I’m giving up this thing but I’m being recognized for giving up this thing and recognized that there are trade offs”. So I don’t feel so bad about it, I feel known, I feel like I’m appreciated and now I’m a little more willing to do a little more work to go through the learning curve.
Yeah. Well this has been a great joy. I know you will definitely be back here in the fall, so let’s do a part two when you are.
Alright! We’re done.
Looking to continue the conversation on business technology? Click the button below to speak with an expert.
Visit our website to view our business technology services and solutions.