Should We Build Our Own Business System? (Part One)
Can you believe that it's been a month since I did one of these! Don't worry, I'm still here, I'm still alive, and I have in fact - when not watching Clarkson's Farm - have been preparing a multi-part series explaining stuff about business systems (for logistics).
Last time, I described how logistics is a system and how that system is meant to be used by others and... what was the other stuff I said? It was something about the people you get into business with and how you buy into a relationship with the people who support your system as much as the ones, zeros, and hardware that comes along with them.
In the month that just passed, this was a topically convenient story that happened.
You might look at this and at the increasing amount of capital that's flowing into logistical startups and at how much the word "supply chain" has been used since 2020 because of COVID and you might start to think... You might start to have ideas. Aspirations. Ambitions. You might be also be saying stuff like "we really can't find something [a system] that meets our needs" or "how hard can it be?"
No matter how your get there, you may end up thinking "Hey, here's an idea, we should build our own system". To address this I'd like to welcome you to;
Should We Build Our Own Business System? (Part One)
Now rather than straight out saying 'No' do not do it. I'm going to give you a series of lists, because who doesn't like a good list, and this is even better because there's three of them!
List 1) All the reasons you shouldn't build your own digital software system.
- Building a system takes a lot more time and effort than you first think.
- It costs a lot of money (staff, hardware, licensing, Red Bull, snacks, office space, stress leave).
- Building a system is difficult (developing the code is one part of it, there's also the design of the UI, testing, data collection, process design, integrations, database management, customer support and customer service design, escalations, approvals, and a bunch more that I can't remember off the top of my head).
- Since building a system is a complex process, to do it properly, you will need to divert your existing technical staff (and your operations staff) towards the project. Also, and this isn't limited to just systems but the more complicated something is the more it adds to the expensiveness.
- Just because "every Gen Z can code now" doesn't mean they can or that they can do it competently.
- When you don't build something properly you expose your business to cybersecurity attacks.
- Building a system has a lot of hidden costs associated. For example, the cost of your staff working on the system build as opposed to their other projects. Or the ballooning Amazon Web Services bill that's the result of the previous point about people not building something properly.
- Once you build something, you then need to support it, any fault or failure needs to be managed by you as a business.
- To build and support a piece of software means you're going to divert energy from your core business towards being a software development company. This means the customers who actually pay you money for stuff will start to suffer.
- The time you take away from your developers towards making your system means they have less time to spend on their "normal" work, and we don’t need that, developers and IT people are already angry enough as a species.
- Assuming you have no interest in becoming a software business, building your own system makes your business harder to scale. Because anything you do means you need to beef up your system (which costs development time, buying hardware devices, buying server space, allocating testing time, all while doing maintenance and customer support). In this example, you are your own customer so you might think "we can avoid that and just not make changes or updates". Don't do that because it means the thing you build will likely be out of date in less than six months and make your business open to cyber-attacks, failing integrations or upset employees.
- When you build your own system, you have to manage your own documentation. Which you probably won't do because you're working out how to do things - on the fly. Each part of the system which isn't documented properly (and I'm talking about the coding notes as well as the operational documents for users) adds to the upgrade and scaling issues mentioned a moment ago.
A summary of everything so far, if you build a bad system it's going to be harder for your business to serve your customer. There are a lot of things to know. It's likely to make you very stressed.
List 2) Here are the circumstances under which you should attempt to build your own system.
- You have a lot of time.
- You have a lot of money.
- You have a competent team.
- You know how to run and support that team.
- The team has worked together on a project in the past.
- The team has worked on a software project in the past.
- You know specifically what you want the system/solution to do.
- You have a workplace environment that allows for the frequent exchange of ideas and approaches, basically, when you release a version of your system for testing, you can handle the feedback properly and iterate.
- Support from senior managers, who probably won't understand a word of the techno talk, but without their encouragement, the system will go nowhere. It's like a car, I have no idea how the engine works but I know how to operate it and I trust the mechanics to make it go faster and help me get to where I want to go. Your development team are your group of mechanics.
- You see the system as unique and fundamental to your business. I.e. if you don't control this digital process and the associated data, you are at risk from attack, at business risk from your competitors, or another example would be if not having control over a given data flow stops you from securing large or government contracts.
Tip: in most cases, your business, be it unique and special and amazing, is not so unique that it justifies the enormous investment of time and resources that it would take to build a bespoke addition to the digital toolset currently being used.
It's like an accounting system, when you don't get the answer you need, you don't immediately rush off to build a whole new accounting system. Because it's complicated and boring. Logistics stuff is, of course, more exciting, I mean we get to play with forklifts for goodness sakes but that doesn't mean the data flows are any less intricate and to be treated with any less respect.
I think people get caught up in the idea that 'it's just inventory' or 'if you can do it in a spreadsheet, how hard would it be to build an app' because, by my own words, logistics is a whole bunch of simple processes combined. But what people don't realize is that there's usually a struggle just to get the basics consistently right.
That's not meant to be an insult because there are multiple reasons for this happening. From Mergers and Acquisitions ruining things to people not doing the right steps to system failures.
Plus there are no baselines or agreed-upon process that are common across industries. For example, by nature, an automotive supply chain that is delivering headlights is going to have different handling characteristics when compared to bananas being shipped from Queensland to Victoria. Nobody is saying "this is the way we should all process bananas" because A) most people won't listen and B) there are competitive advantages to doing things differently.
Let's expand on that for a moment. One of the ways you compete against other businesses is to, sure, do some new marketing in a fun and edgy way. Another is to develop processes that your competitors haven't thought of or paid attention to.
Look at eBay versus Amazon. Both are marketplace sellers and both facilitate a transaction between sellers. But it was Amazon that said - hold on - what if we went to the next step and actually control how things move around. They turned their cost centre into a competitive advantage and now have one of the most advanced and capable supply chain networks the world has ever seen.
Note: my long-term dream is to have a factory or a … lair lab somewhere. There I can work on weird ideas like flying forklifts or spider-pallet wrap or other stuff I'm not putting in writing. Just like a playground of cool s@#$ ya know?!
List 3) If you haven't been discouraged thus far, here is what I'd suggest you do each time the 'let's just build it ourselves' thoughts come to mind:
- Stop and document your process - literally draw pictures of how things are moving around right now.
- Understand your problem - which part of that picture is causing issues?
- Brainstorm - you'll often find that solutions can be fixed from the bottom up, the people on the front lines (who deal with the problem all the time) usually have ideas on how to fix them. Combine this with managements insight, direction, and executive sign-off and you'll be surprised at how quickly you make change happen.
- Look at your existing systems to see if they can do it.
- Remember that for every problem a consultant offers to fix for you, you can usually fix yourself with enough time.
As tempting as it is to rage quite whatever convoluted piece-of-crap you have in place now. The headaches become far worse when you need to spend time and money and stress on something you build yourself. It's a bit like complaining to the waiter in a restaurant rather than hating yourself for making a bad sandwich. Except building a system is like building the restaurant, hiring the staff, finding suppliers, making the sandwich and then when your own team complains about the crappy food - you have to deal with the whole restaurant and your ungrateful workers.
I hope this rant can add to your file of 'stuff I am now aware of when thinking about building a system'.
Have a great day and I'll see you next time when I go on about 'How To Buy A System'.
(I sincerely apologize for the terrible grammar and the premium Grammarly subscription costs money so... eventually, it'll get better).