Usually the first 45 to 60 days after taking responsibility for an operational area is focused on discovery. Take your time. Rushing through the discovery process will create more complications later. We’ve already discussed the main activities that you should be focused on during this period. Notably, developing conceptual models that describe the operating environment in its current state and starting to build out use cases. The former will help you understand what you have to work with and where your risk areas lie and the latter will help you understand all the moving parts.
Even so, you still might step into a big puddle as you try to formulate your plan for moving ahead. You need to drill down into the details of how each job function is done. One of the best ways to do this is to develop an “input/output” model. Keep in mind, that what you are doing as an operational managers is defining the best plan possible for the feed and caring of your operational machine. Just like with physical factories, raw materials go in one side and finished goods come out the others. The same is true for any operation whether it be in sales, client services or database operations.
The input/output model at its core represents the documentation of three key things. First, there is the boundary of the operation in question. Where does a marketing process start and where does the sales process begin? Who is responsible for what workflows and what work products? How many steps are there in the completion of a process? How many processes are they in a functional area? Etc.
Second, an input/output model includes a high level representation of the various workflows within the area of responsibility. A good process is defined by a series of steps. All processes need to have a beginning, a middle and an end. Some processes have key decision points. Some processes are linked or dependent on others. All processes are launched by a minimum of one condition or event. And all come to a conclusion when their core objectives are met. Good processes are scalable, repeatable and sustainable with limited exertion by the operations team.
Lastly, the input/output model will allow the operations manager to document and capture the various interaction points and dependencies that his function has on upstream and downstream processes. A clear understanding of these interactions will be crucial in mitigating risk and maintaining good connectivity to the rest of the business.
In any operation, the first step is to define the specific workflows that are required. For example, a typical company might describe its overall revenue workflow as follows:
In this over-simplified model, the marketing department generates leads and interest for the product in the market. The sales team follows up on those leads, qualifies them and works to move a potential deal through the pipeline to closing. When the deal is closed then someone else is responsible for assembly and delivery to the client. Lastly, a customer support team will have the responsibility for ensuring that the product or service is fully implemented and serving the clients’ needs.
Naturally, the scale of each of these functions is defined by the nature of the product or service being sold. For example, “order fulfillment” for a consulting engagement or enterprise software implementation is much more complex than ensuring that a widget that was ordered from a warehouse was packaged and shipped on time to the client. But to be clear, regardless of the industry and the nature of the product being sold there should be well defined boundaries between operational areas.
What is important to note is that the processes defined by one functional area are dependent on the conclusion of processes in the previous functional area in order to launch. Where these boundaries are not clearly defined what tends to happen is that the downstream process ends up picking up the slack form the previous process. This can result in an overall inefficiency for the business.
It is for this reason that it is critically important to define all of the specific processes within the operational area in order to be clear about what each operations manager is accountable for. In the above workflow the department that is responsible for order fulfillment has its own very specific workflows that it is accountable for.
For example, the fulfillment team may have responsibility for confirming the order details or product configuration. They may need to work with other departments in order to schedule an implementation or delivery. They may need to engage customer support to prep a customer and manage client expectations as to the timing of delivery. They may need to assemble the materials, whether they be parts for a sale of physical products or people for a services implementation. Each one of these specific tasks is controlled and executed by a sub-process that resides within the boundaries of the Order Fulfillment workflow.
Each of these individual sub-processes is idle without the appropriate inputs from the corresponding upstream process. So order fulfillment cannot happen until the sale is closed. Closing the sale is the function of the processes immediately upstream of the fulfillment team, which in this case is the sales department. In this way, the output from one process is the input for another. So if the sales team does a sub-optimal job in documenting the details of an order, it will complicate the job of the fulfillment team. That will manifest itself through the fulfillment team appearing to be inefficient in terms of their own processes. If this condition persists, it will likely create a backlog of orders and prevent the company from booking revenue in a timely fashion. Moreover, the sales team may appear to be more effective than they are resulting in management’s focus on the wrong area of the business.
By not providing appropriate documentation to the fulfillment team they create extra work downstream. This compromises the entire workflow and can cause downstream staff to not only not live up to their potential but can result in them rushing to hit targets that would be easily achievable if the sales team had submitted their orders properly in the first place.
If the operations manager responsible for the fulfillment department understands the inputs into his or her functional area and what they are supposed to be, then he will be able to set minimum standards and establish an operating level agreement with the sales team (in this case). This will enable him to also set predictable turnaround benchmarks for his team and produce quality outputs to support downstream processes owned by other teams. All of these efforts will combine to mitigate backlogs and establish a general ability to manage customer expectations better.
Developing the input/output model is a good place to being process design simply because it helps you define a number of critical features. You cannot build a successful process without a keen understanding of the inputs. Documenting the boundaries not only helps you work with your business stakeholders and partners but limits your risk by setting up operating level agreements with those areas that interact with your department.
For more information about this article or our services, reach out to us at info@coeurderoy.com.