94% of enterprise businesses are using cloud software, a fast growing market that’s worth almost $900 billion, and by 2025 that could represent 100 zettabytes of data, according to Cloudwards. But what about the small-to-medium sized enterprise?
Lots of SMEs have super specific requirements that make it difficult to build a complete workflow when access to resources and know-how are limited.
Having had chance to talk with businesses owners up and down Yorkshire, a few themes come up again and again:
- Many would love to digitise everything and tap into that potential business intelligence, but most of what they have is in fragmented systems, different formats, or as printed documents.
- They’re on the move and need access to the same resources as the team in the office.
- Their customers need access to those same resources, but for different reasons. Perhaps they need to create their own? Ouch. Dropbox is good, but…
What we’re talking about here is a need for what’s known as digital transformation.
According to Salesforce:
Digital transformation is the process of using digital technologies to create new — or modify existing — business processes, culture, and customer experiences to meet changing business and market requirements. This reimagining of business in the digital age is digital transformation.
In simple terms, digital transformation is the willingness to adapt to change in this fast-paced modern world. While a willingness is important, resources and know-how are critical to taking digital transformation from concept to a successful execution.
Perhaps the most important thing Octane does is make people more effective at what they do. If someone is spending 5 minutes on 1 task, Octane creates a cloud-based application that allows anyone with the training to perform 5 or more of the same task in the same time or less.
Part of that creative process involves digital transformation, where the data that emerges from those tasks becomes part of the collective intelligence of the business.
I build products that digitise as much as is feasible, give everyone access to things they need when they need them, and that most of what they do contributes to a growing understanding of the business as a whole.
The trick is doing the same thing for businesses who make precision parts for engineering, healthcare, and defence, transient assets like in events and accommodation, wide-format 4 colour banners, and couriers looking for an edge in shipping and distribution.
Taking stock of engineering
Octane’s in the process of building a cloud-based stock management application for a local team of engineers, and it’s been one of the most fascinating projects to date.
Project requirements
I was recommended to them by a good friend, and I was intrigued by the challenge:
- build a replacement to an aging custom-build stock management system;
- allow for multiple users with different levels of access;
- keep within a budget;
- have a working prototype complete by April.
When I start a new project, I do a few things:
- establish who the stakeholders are and assign them to the relevant parts of the project;
- map out an architecture that includes the immediate short-term needs but also adjacent and related parts of the business that represent a long-term objective;
- then focus on building the most important parts of the project, much like a MVP (minimal viable product) and have a product working as soon as is viable.
What’s the importance of having stakeholders? In projects like these, the stakeholders are often the principle users of the application, and it has to reflect how they do things, but at the same time be an improvement on how they do things. I take time to listen, watch what they do, how they do it, and ask what they think would be an improvement.
A major benefit to having stakeholders involved is bringing them into the build process and testing the application as soon as possible, helping weed out bugs and other problems, which we manage through a series of cards in Trello, a kanban-based project management application.
Why look so far ahead? By asking questions about what the business does as a whole, I build a picture of what the application could look like, 3-5 years hence, and that allows me build an awareness of that possible future into the project. When I build with the future in mind, it often minimises the amount of refactoring of past code once we get there, something I find saves a lot of time.
Made to measure
A lot had happened before Octane became involved:
They first explored general productivity applications such as Microsoft Office, and while useful at important stages in difference processes, they were no substitute for a complete workflow.
They looked at commercial stock control applications, but few gave them any more than 70-80% of what they needed, and it was the remaining 20-30% that was the most vital to them.
They then built their own in house stock system, and as impressive as it was at the time, people took the vital knowledge and talent with them when they moved on. Years passed and by then the application had grown old, become difficult to maintain, and — as of the beginning of 2022 — failure crept in.
Understanding the workflow
Almost everything a business does revolves around managing the lifecycle of an asset, that:
- arrives or is created (be a precision part in aerospace, an event booking, or a brochure for bathrooms);
- passes through a series of stages specific to the asset, the business, or a combination of the two;
- and is then considered complete, passes into the hands of a customer, and so on.
This is the workflow, which consists of two basic types of process:
- something that’s digital in that it happens on a computer or some device;
- something that’s analogue in that it’s said, written, sketched, drawn, or fabricated, before spending much of its life in a physical format.
When it’s analogue, the main goal is to make sure evidence of its existence is recorded as something digital, to build an audit trail.
Tools of the trade
In the case of our engineers, one such physical product is the part, which could be anything from a single screw, to a bag of 50 to 1,000 of them, a flange, a box of a dozen washers, or an entire pumping system made up of dozens of individual parts.
Within the application, each part is an asset, which fields such as: name; location in storage; SKU; model number; description; and price.
Perhaps the most important fields are those representing: quantities, the number issued; and those that have been allocated to a job. I’ve created a system that uses these three values to build a complete audit trail of each part, recording the specifics of each action performed, tied to a specific person.
Another vital but ephemeral physical product is the quote sheet, which is printed and then distributed throughout the building. People write on the quote sheet with hands slathered in dirt and grease, explaining what additional parts were used, required, or both. The problems here are numerous. Assuming the quote sheet survives, like anything else written it’s prone to error, loss, and duplication. At some point, those annotations must be taken into account.
PDF, or Portable Document Format, was an obvious and perfect fit:
- we manage the quote sheet in the application;
- save versions via a cloud storage service for the purposes of auditing;
- print multiple copies for distribution;
- and add a watermark so that everyone understood where the asset was in its lifecycle.
Good though the PDF is, it doesn’t solve the problem of a sheet of paper fluttering around a workshop!
With a bit of training, anyone on the team could access the quote sheet and make changes, and we have a plan in place to install a ruggedised tablet device on a bracket in the workshop for that exact purpose.
During their recent stock stake, I built a spreadsheet in Google Sheets that allowed them to do the job with a few pivot tables but also automate and synchronise and create derived values to build the data we need when it comes to deploying the application.
Having demonstrated pivot tables and combined that with version histories, the spreadsheet fast became one of the most important and valuable assets in the business — in truth, it’s value is nothing compared to what the final application has been built to accomplish.
The challenges
I’m not a salesman, but I know how to talk about what I do lingo-free without the technical jargon … most of the time. The biggest challenges are perceptual.
“Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don’t know we don’t know.” — United States Secretary of Defense Donald Rumsfeld, in response to a question at a U.S. Department of Defense (DoD) news briefing on February 12, 2002.
How to get from A to Z
Most business owners and senior management know when they’re not working as smart as they could or should be, but knowing that isn’t as valuable as knowing what to do about it, which is often the great unknown.
I begin by asking questions and then wrapping a proposition around those answers to build a picture of what we would create. So we don’t go from A to Z, but from A to B, then C, and D, and so on.
How much?
Regardless of how articulate I am, the question of cost is the biggest challenge, but I turn this around and encourage the prospective client to see it from a different perspective. Given the obvious value of building a cloud application that would meet the precise needs of their business, it’s less of an expense than it is an investment in getting to where they need that business to be in 12-24 month hence.
Job done!
I built the prototype in half of the available budget while saving the same amount of time, which has allowed us to build the entire project out to completion.
If you’re hoping to tap into the true potential of your business, let’s talk!