How to automate, and eliminate, bottlenecks in your business operations
I’ve noticed a trend in tech lately, as more startups and firms begin adopting software development methodologies toward operations. It’s a useful paradigm, and one that I’m trying to implement personally and professionally in both my firm’s operations as well as those of our clients. There are some businesses that are more suited for this than others. Obviously software firms and startups trying to find traction are more likely to fit into this kind of approach, but traditional service and brick and mortar stores can see benefits from them as well, especially from a change management perspective.
Every business is a software business.
Watt’s S. Humphrey
If you haven’t realized it yet, all businesses are now software businesses. And if you haven’t, I guarantee one of your competitors has and is figuring out a way to do it. Customer’s want options, and if you’re not providing them with ways to reduce friction in their operations, then someone else is going to.
Make a decision once
In Principles, Ray Dalio writes about businesses as systems, and the importance of offloading the decision making process out of one’s heads, to series of standard operating algorithms that can be written down as a series of principles. These guides serve as a reference for future decisions, not just by yourself, but by the rest of your team, and can be invaluable for new hires. Of course this information can eventually be turned to an algorithm, and used to automate the decision-making process.
The challenge of course, is figuring out where to capture this information. If you’re not doing it personally, I recommend starting with pen and paper. Teams can use email, electronic documents, or whatever your current messaging platform, e.g. Teams, Slack, or even Discord. The important habit here is to make the decision criteria concrete, and to continually revisit these principles the next time a similar decision needs to be made. You may not be able to automate every decision in this way, but the process can serve as a filter for a majority of the decisions that come your way.
Writing down the decision making process also has another key benefit: defining your values and helping you focus on your market.
Agile Workflow
If your business is struggling to find it’s footing, either as a new venture or as a established firm that is dealing with a rapidly changing market, then you need to build, iterate, and refine, quickly. Whether that means refining your operations, or pivoting the product or service you deliver, you’ll need agility to survive.
Agile is the name given to a software management process first defined two decades ago. It uses the concepts of short sprints, usually a two to six week period, where a team focuses on delivering a particular feature, or refinement to an existing process. Agile is a contrast to the previous, waterfall style development process, which had long development times. By the time a usable prototype was delivered, the requirements might have changed considerably. Focusing on smaller chunks of time ensures that effort is not wasted on delivering services that don’t align with business objectives, and allows development teams to make sure their deliverables are in line with customer or internal requirements.
User stories
There’s another key component from Agile methodology that is extremely helpful for designing business processes and services: the user story.
One mistake often found in business is the solution in search of a problem. Tech people, myself included, have often seen a new product or tool and start trying to sell the product or process to internal or external client without having a clear idea off the use case around it. I have been particularly egregious about this in the past. During my conversations with clients, I find that while they may have a clear picture off the service that they would like or are trying to provide, they may have trouble providing a clear picture of what success looks like. They might know that they need new network infrastructure, or a web site, but their idea of what that means from a capabilities standpoint might be very different from the perspective of the team implementing it. This inevitably leads to friction, whether as scope creep, or service interruptions which impact the client.
The Agile approach to this, which I’ve begun implementing to business systems, is to focus on the user stories, and make sure that there is a clear sync between the business unit’s expectations and those of the technical team. In the case of a new project, this usually requires brainstorming to specifically flesh out the myriad ways that a deliverable will be used. For existing businesses, this may be as simple as shadowing workers to enumerate a list of their various activities through out the day. When I’m working with a client focusing on an external application, I usually ask them to start by describe the customer journey in as much detail as possible. This epic is then broken down into concrete, actionable user stories.
There are several criteria for a well-defined user story. It must focus on a specific type of user role, it must be discrete, and it must be testable. This last component is the most critical from a technical perspective. A lot of time, business goals might be defined in broad or vague language which lacks specific requirements for success. By writing your system goals down as individual, testable units, you define a way to test for success, while also providing your team with a target that can be accomplished within a short sprint time frame.
Give up the paper
Over the years, I’ve walked into too many businesses and looked with dismay on large stack of paper, whether they are service work orders, purchasing or other tracking materials. While there may be certain governmental regulatory environments that still require paper, for most commercial and consumer-based businesses, this is a sign of stagnation. It could be death knell. It’s 2020, and there is hardly a justifiable excuse for a business to generate huge volumes of paper documents as part of day to day operations. There are literally hundreds of app or software as a service (SAAS) vendors targeting most established business sectors.
The most common excuse that I hear as to why a firm hasn’t migrated their service operations or other processes to an electronic system is that it “doesn’t meet all of our needs”. This is usually used as justification to do nothing, continuing with labor-wasting inefficient duplication of work. Paper forms are scanned, copied and entered into another spreadsheet or accounting system, as employees keep up with the inefficient system. Instead of choosing a vendor that can meet a majority of their needs, they let one or two small use cases stop progress in its tracks.
Even if a business can’t find the perfect vendor or SAAS product to meet their needs, there’s no reason one can’t find ways to make smaller improvements. I find that most businesses aren’t even taking advantage of the software and vendors that they’re already using. One of the most common examples I find are Office365 Premium users who are just using it for desktop apps and email, and don’t even realize the services that they’re getting for free, like Teams, SharePoint, Planner. One of the things I’ve been focusing with my existing O365 clients is showing them how all these tools work together, and figuring out how to use Teams, Flow and PowerApps to eliminate phone and email traffic. Tools like Airtable are also fantastic, and I’m hoping to be able to build more services using the various text and voice tools available from Twilio.
Connect your services: APIs, APIs, APIs
If I had to guess, I’d say most firms currently have around a dozen different apps, vendors and services that they use on a regular basis, platforms for work and time tracking, accounting, inventory, communications, and so on. Ask yourself, how does data flow through these different systems? How is it generated? As with paper records, manual data entry from one system to another is usually cumbersome, inefficient, and most important of all, unnecessary. It can also lead to error.
![selective focus photography of computer code monitor display](http://dahifi.net/wp-content/uploads/2020/05/tjbk79tarie-1024x768.jpg)
Enterprise firms have long relied on electronic data interchanges (EDI) to transfer structured data between partners. These days, most applications allow some soft of import/export functionality via CSV files, but a more modern approach to this is via an application programming interface, or API. The most common API protocol is called REST, and it allows you to perform create, read, update, and delete (CRUD) operations on your data. Having a full REST API available to your all of your various services not only allows them to talk to each other, but also allows you to automate the various processes that you might perform via an application’s web or graphical interface. This is one of the most powerful tools that an organization can deploy. I’ve personally been building Python modules to pull data from our various management systems, allowing me to perform status checks on systems that would otherwise require me to login to a web portal and sign in via two-factor authentication. I’ve also built a number of scripts that I use as templates for various tasks, that I do on a regular basis.
Having an API is so important these days, that it’s one of the first things that I look for when evaluating a new vendor or app for myself or a client. These days, it’s unacceptable for a vendor to lock customer data behind a walled garden, but this is still a problem with a lot of legacy applications, which may not allow the ability to perform CRUD operations on internal data.
One more thing that is worth noting is the concept of a webhook, which is the ability to send or receive a message from one system to another based on a trigger. They’re not as dynamic as REST interfaces, but they do allow a system to send a one-way message to another. A simple example of this is the ability of a shipping vendor to send a notification to a client’s chat messaging system when a delivery status has been updated.
Corporation as Artificial Intelligence
One might think of the corporation, or even small businesses, as a prototypical artificial intelligence. They both have inputs and outputs, and along the way decisions and processes are made which transform the former into the latter. The main difference between the two might be the speed and the way in which those transformations occur. The question that business leaders need to ask themselves is how that transformation is happening within their own organization. If your organization has bottlenecks due to the decision making process or manual data entry requirements, then you should start implementing some of the tactics we describe in order to automate and eliminate these barriers to growth.
If you’re not taking these steps today, then you will find your business falling further behind organizations that are. Soon, you’ll be losing your clients to them. Beyond just the internal benefits, you’ll find that your customers also want the option on how they communicate and interact with you. And if they don’t have the freedom to chose, if your business isn’t flexible enough to provide that freedom, then they’ll eventually move where they have it.
My focus as a technologist is to assess current trends in business and technology, and extrapolate out where things are headed in the next five to ten years. My goal as your outside technology officer is to make sure that you not only have the tools to succeed today, but help provide the long term vision to get to where you need to be tomorrow. If you’d like help assessing your current operations or would like to discuss things further, please drop me a line.
2 Replies to “Businesses as operating systems”