Business Process Management: A Developer's Business

A Developer’s Business 🔗

Knowing a thing or two about the mindset of someone on the “business” side of your company can be very valuable. That doesn’t mean you need to spend two years of your life getting a MBA to learn about this (but don’t let me stop you).

This post won’t be about accounting, marketing, entrepreneurship, or making quarterly revenue projections. Instead, it will focus on a concept I learned in business school that helps me in my day-to-day as a developer.

Business Process 🔗

Companies run by following repeated steps to produce a given output. Some companies are more explicit at defining and recognizing these activities than others. If you look hard enough - you’ll find them.

Dr. Thomas Davenport defines a process as:

a structured, measured set of activities designed to produce a specific output.

As software developers, we translate these processes into systemic rules or features.

Business Process Management 🔗

People need to tend to these processes. The processes must serve the needs of the organization in the best possible way. The person completing the steps may be responsible for that. There may be a separate team to optimize the work that the operational team is conducting.

The Association of Business Process Management states that Business Process Management

enables an enterprise to align its business processes to its business strategy.

Manage and deliver iterative improvements of a business process with the following steps:

Design 🔗

The design step must start with documenting the existing process. Observe the current activities taken to achieve the goal. Write those steps down without alteration. Stopping here still has value to the organization. It may lead to greater standardization. It may be easier to hire and train new people. It can improve transparency, visibility, and awareness in the organization.

The design phase goes one step further. Propose an incremental improvement to the current state. This may be a new activity that wasn’t done before. It may be removing steps of the process. It could be changing the number of people or who the people are that complete the work. The change must meet the process goals and the team’s challenges with the current process.

Model 🔗

In this phase, test the designed future improvement before making the change. Seek to determine with greater confidence that it will improve the process. Conduct various “what if” analyses to attempt to validate that the change is a good fit before enacting it. For processes that resemble assembly line production, statistical software can predict quantitative results.

Execute 🔗

Now that you have some evidence that this change will be beneficial - do it! However, don’t do more than is necessary to prove efficacy of the process change. This may mean implementing these changes as “manual” workarounds first. Invest the resources to automate the change or codify it in the system in a future iteration.

Take an approach that yields the signal to confirm the change is having the affect you want with minimal disruption to your business. In software development, this may look like an incremental roll-out. The process change starts with a pilot program. After that, incrementally introduce it to more and more of the population that interacts with the process.

Monitor 🔗

It’s not enough to make the change. Now we need to verify that it’s having the affect we want. Should we continue the incremental roll-out approach we’re taking? Should we should roll the change back? To know, we must track and report on key performance indicators (KPIs) previously defined. We will observe the actual impact of the change to ensure that it is meeting the anticipated goals.

Optimize 🔗

Now that we’ve introduced a change and verified it’s benefiting the process, it’s time to start all over again. Business Process Management is an exercise in continuous improvement. Identify the next bottleneck to address and design a proposed a solution to alleviate it.

Developing Business Processes 🔗

Much of our work as software developers involves managing processes. Some of us are constantly working to optimize our individual workflow. That magical keyboard shortcut, or the custom alias, that’ll save you precious seconds of typing over the course of your entire career? That’s improving your personal business processes.

Our feature delivery work focuses on business process management. We may be automating a “manual” process. We may be changing an existing flow in our application to make it better for users. We may be lovingly putting a spreadsheet on the Internet. In all those cases, we need to consider business process management steps. Using this framework will ensure the changes we’re making are having the impact we desire.

When building computer systems that didn’t exist before, we need to consider if the context change should affect the process. It may not make sense to recreate the existing process when using a computer to manage it. The team may need to re-engineer the process, re-imagining it from the ground-up.

Whether incrementally changing business processes, or re-engineering them, don’t forget that we design systems and software for humans. Ensure that the ultimate focus is not on solving the optimization problem. Consider the impact and consequences of the work we do, both for users of the system and those impacted by the decisions made by the system.