Engineering a future for small businesses with cloud software

 Written by

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:

  1. build a replacement to an aging custom-build stock management system;
  2. allow for multiple users with different levels of access;
  3. keep within a budget;
  4. 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:

  1. arrives or is created (be a precision part in aerospace, an event booking, or a brochure for bathrooms);
  2. passes through a series of stages specific to the asset, the business, or a combination of the two;
  3. 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:

  1. something that’s digital in that it happens on a computer or some device;
  2. 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!

Side projects as an employee KPI

 Written by

Working long hours — at the office, a coffee house, or at home — is one of the more obvious indicators that an employee is dedicated to their job, but is it indicative of how productive or how good they are?

It’s possible the long hours are a sign that someone is struggling to accomplish in 5 hours what could or should have been done in 1 or 2, and if that’s the case, the job is encroaching on their personal life, which in turn would have a commensurate negative affect on their work like — and that’s when the downward cycle begins. Unchecked, these long hours would have negative consequences for both employer and and employee alike.

Gmail, Google Maps, Twitter, Slack, and Groupon started started as side projects, as did Under Cloud, the digital research assistant, which I’ve since spun out as a startup of sorts.

Side projects should be considered key performance indicator of an employee, something I imagine Google figured out a long time ago, giving rise to their famous 20% time set aside for their employees to focus on side projects. The powers at Google are no fools, and the fruits of that 20% me time become Google products, but that needn’t be the case for everyone else.

“Should I tell my boss I have a side project?”

… is a question I see asked a lot while on a number of groups for entrepreneurs, developers, and designers to talk, share ideas, and learn from their peers. If it were me, I’d want to know if an employee had a side project, not because I’d feel threatened, but because I’d like to help, where possible. As an employer, I see side projects as evidence of some notable qualities:

  1. proactive, forward thinking, and a willingness to look beyond their immediate environment;
  2. inventiveness, and a mind for both identifying and fixing problems, or seeking out new and novel niches;
  3. and a demonstration of a commitment to self improvement, and a desire to learn.

These are commendable qualities that are beneficial to the employer, too — more so if these side projects are work-related activities. It’s feasible an employee could be working on a side project without me knowing — and that’s not a problem in and of itself — but it’s inconceivable that their out-of-hours dedication to their craft wouldn’t be of benefit Octane to some extent, since they’d either be:

  • learning new or honing existing skills;
  • collaborating with others and improving their own project management and communication skills;
  • and perhaps learning to make more effective use of their time, and — through trial and error — create a productive work-life balance.

I’m sure there are other benefits, so what’d I not include, and what do you think of side projects?

Talking shop … store, booth, garage, and office…

 Written by

Business networking events aren’t for everyone. For some people, such things are the awkwardness of an office soirée but without the benefit of free alcohol for that bit of Dutch courage, and swapping out the unwelcome overtures of that not-so-special someone who you avoid like the plague for the overt advances of a bunch of salespeople who talk at, over, and through you.

Worse, the dreaded speed networking event — eek!

Choice of venue aside, I’ve found the optimal angle of approach is to ask the other person what it is they do and then wrap their explanation in a contextual proposition of what it is Octane does.

It’s the difference between:

“We help small businesses deal with big business problems.”

… and:

“We’d create a secure web application to manage the life cycle of [Widget X, Gadget Y, Service Z, or Events 1, 2, and 3], and…”

… or:

“We’d look at trimming your workflow down from 7 stages to about 5, or — if possible — 3, and then digitising the whole thing, then…”

… in each instance, continuing with additional, contextual ideas specific to their business, accompanied with essential benefits, such as reducing costs, and improving efficiencies, among others.

While apocryphal, it’s worth mentioning something that Albert Einstein never said because it’s a useful shorthand:

“If you can’t explain it simply you don’t understand it well enough.”

We often have an intuitive understanding of what we do, but then struggle to articulate that to someone else, so — as I said — context is everything, as is practice.

I often avoid explaining the specifics of what Octane does (because it’s technical and therefore either: 1. confusing; 2. boring; or 3. a combination of 1 and 2) and instead focus on the expected results, and the benefits we would bring to them.

In the end, simplifying the raison d’etre of a product or service isn’t so much a strand of self-promotion or some branch of your marketing strategies as it is the communication of an idea such that its purpose is self evident to someone, whether it’s applicable or relevant to them or not.

Because if someone else understands what you’re capable of accomplishing, then you have the makings of a message that is communicable to others by others, via word of mouth, and fingers to keyboard or touchpad, which could then — in modern parlance — go viral.

7 Steps to Workflow Nirvana

 Written by

Octane works with businesses to improve their workflows, moving them from analogue (paper) to digital (bits), helping to reduce data loss, error, and duplication.

Over the next few paragraphs I’ll provide some ideas to help you tame the worst business processes.

But I’m getting ahead of myself…

While at an event in Sheffield, I introduced myself to a fellow attendee, and after explaining a bit about what I do she began to regale me with the tale of a fascinating and somewhat alarming problem she once had while working for a major high street retail chain.

Understanding the process

As I understood things, during the summer months, certain parts of the store had a strict dress code, and signage was required to make a polite request (no vests or shorts).

However, before anything could be printed, a couple of bureaucratic stages had to be navigated:

  1. there was a minimum budget requirement of £8;
  2. 5 signatures were required (signature 1 was needed before signature 2, and so on and so forth).

As you might imagine, this process of gathering signatures was glacial, somewhat difficult to orchestrate, and — as the woman explained — prone to failure as the paperwork, because of the flimsiness of the stock, often got blown from a desk by the merest breeze.

So that would be the loss part of what Octane works to reduce, along with duplication and error, a point I made to the woman, which earned a sardonic chuckle.

I’m guessing the minimum spend was intended to reduce costs and avoid needless activities, but after a quick calculation, things didn’t quite add up.

So imagine a scenario where this 5-level sign-off process is performed 5 times a week per store for various activities across 100 stores. Each time the process is performed, there’s an average loss of 48-72 hours (a figure gleaned from the discussion with the woman).
rusted-pipes

Defining the ideal business process

Now, let’s imagine a simple secure piece of software with a sign-in for the stakeholders: managerial signatories; and floor managers. After an initial investment of 5-8 hours of basic training it’s up and running.

A sequence of ‘signatures’ is required, and after the stakeholder signs into the application, he or she does nothing more than read the request before clicking either an “Approve” or “Reject” button:

  • If approved, an automated request is sent to the next person in the chain.
  • If rejected, the person who sent the request could then ask for further clarification, a process captured by a messaging component within the application.

Running the numbers

Let’s assume our ideal business process shaves a modest 12 hours from a number of workflows bound by the same rules. So that’s 12 hours, multiplied by 5 times each week, multiplied by 100 stores.

Our little application would have saved them 6,000 hours.

Imagine what would happen if we applied the same streamlining to mission-critical processes that are vital to operations?

I know, it’s that commingling of terrifying and amazing!

pipe-ends

Optimising a workflow

So now you understand how structured processes might lose time, let’s explore some ideas on how we might fix that.

  1. Reduce the number of stages. If you have 7-10 stages, that’s at least 7 different places for something to go wrong, and then you or someone else has to figure out where and then how to fix it. So examine the workflow with a mindset of simplification, liaise with the stakeholders, be on the look out for loss, duplication, and error and bring them down (elimination is the goal, but not often feasible — we are human).
  2. Keep the processes small and manageable. If your workflow must consist of 7 stages, keep them compact and understandable. Some other idiot (you, I’m guessing) has to read over the documentation in 6 months’ time and make sense of it.
  3. Document everything. Use something like Google Docs and share the documentation amongst the team. Use the ‘Track Changes’ feature, to follow who wrote what, why, and when.
  4. Automation. If feasible, automate your workflow. Don’t be afraid of a hybrid analogue-digital series of processes (paper and bytes), so long as you’ve documented everything and each analogue stage has a person responsible for it. Whatever shape the workflow takes, make sure the data it creates is in digital and not analogue format (at some point, you might need to analyse the data).
  5. Limit the number of people involved. I often have to explain to clients that design is not a democratic process. So unless you’re a multinational corporation, you won’t need to vote each time someone proposes a change. An ambassadorial approach is often required to deal with those protecting the borders to their fiefdoms, and then there’s the oft cited refrain: “But, we’ve always done it like this!” In each case, take the big-picture approach and be brave!
  6. Restrict the number of signatories. The fewer the number of chiefs, the more time the indians have to — you know — do the hard work. However, build in an audit trail (via the documentation in point 3), so the decision-makers know what happened and when.
  7. For goodness sake, communicate! If you suspect there’s a flaw in the process, speak up. If someone has a suggestion, listen. Neither of these two things should be a major problem (or another time vampire) if you’ve followed point 5. While this might sound obvious, engage with the people executing the processes because they’re the ones doing the hard work, so they know better than anyone.

Perhaps now you understand why I’m passionate about ideas because it’s often those in the smallest packages that are the greatest of gifts.

First published on LinkedIn.

How to respond to failure. Or, after the problem came the procedure.

 Written by

Encountering problems and making mistakes is a consequence of life, business, and everything else — and unavoidable. But the value is in how you respond to them.

As I said on Twitter this past week:

I’ve found that the best lessons in life — by far — are those where you learn how NOT to do something.

But still, as good as vicarious experiences are, they only get you so far.

In the beginning, there was the mistake…

By gum, was it a doozy! I’ll spare you the gory details (because they are — for the most part — irrelevant) but it was less a bug and more an infestation in the code. In the grand scheme of things, it has caused problems for our schedule, but the Under Cloud remains on course.

Stripping the whole problem down and tracing it to its source, it was — as these things often are — a failure to communicate, which resulted in team members and myself labouring under the assumption that something was when it wasn’t.

And then came the procedure…

So how did I respond?

We’re using a number of things to manage what we do. As a team of 3, we don’t need a lot, but we find that Slack and Trello are enough to keep things together, although we often find things said and done become lost inside the whirring cogs of the communication machine!

I created a list in Trello and added a card entitled: “Deprecated”, within which I wrote the following description:

“Here are all of the parts, components, and libraries of the application that have been deprecated, and what they’ve been superseded with.

Please update this card as and when required, but also refer to it, too!”

Some might argue it’s just a patching of holes, while some might claim it’s only of any use if people follow the procedure, but I would counter by saying that’s life, business, and everything else…