Reducing the cost of IT system development by modeling processes first

What happens if your company wants to cut costs or automate parts of its operations but fails to redesign processes?
This usually results in a costly and/or 'hated' IT system that no one wants to use. What is the solution? Model (or redesign) processes first, involve users in the early stages of information system development, and save money in the short and long term.

The story of lost money

I worked for an IT firm that purchased a brand-new, off-the-shelf CRM (customer relationship management) system from a software vendor who claimed their solution could "adapt to any sales process”.

The intentions of the company were noble. They wanted to boost the productivity of their sales and marketing team and make their jobs easier. At the same time, they wanted to lessen the administrative burden on sales staff. "Salespeople should focus on their core tasks: selling our IT products and services!" they said.

The management team wanted insight into their sales process, including leads, business opportunities and prospective customers. Most importantly, they required financial projections for the next few months. They wanted to know what business opportunities were in the works, how ripe those opportunities were, and how likely they were to win new customers.

At the end of the day, all they wanted was an answer to a simple question: "How much could we earn in 6 or 12 months, and what is the likelihood of that?"

Anyone in the IT industry knows that selling IT services is difficult. A sale can take a long time, sometimes more than a year.

To cut a long story short, the company's project to implement a CRM system failed. They spent a lot of money on a CRM system that was never really used. There was a direct financial loss because the software package they purchased was not cheap – it cost several hundred thousand euros. An even greater indirect loss was the countless hours spent configuring, adapting, and implementing the new CRM system, not to mention trying to persuade people to use it alongside their traditional sales methods. Huge losses in terms of expert hours.

The project was eventually shelved. The sales team went back to their old ways of doing business, with each person following their own slightly different process and storing data about leads, business opportunities and customers in their own Excel files. This is shown in Figure 1:

According to some authors (for example, Gartner), implementing a CRM system in an organization has a significantly higher failure rate (30%–70%) than implementing other IT systems.

You might believe that IT companies have no trouble automating their own processes. Not exactly. What did we learn as a result of this failure?

Lesson learned

What is the most expensive IT system?

One that fails to meet customer expectations and whose development requires major changes and contract amendments. The company spends money on unnecessary software/functionalities or, as in our case, the company cannot adapt, and the project is eventually abandoned.

What caused the failure in the previous story?

There are several reasons why such a project can fail, including:

• poor objectives
• poor strategy
• scope creep
• user adoption resistance
• lack of management sponsorship

But I see one root cause: the users (the sales team) were not involved in the process identification or modeling.

The processes were not previously identified, analyzed, and agreed (synchronized in a team). The sales team was not involved in the project from the beginning. The software's requirements should have been clear from the start. The CRM system was purchased first and then 'thrown' to the sales team without regard for processes.

This lesson was difficult. However, I have since learned that implementing a new information system in an organization can be successful and cost-effective.

In theory, this seems feasible. In practice, however, employees are not always aware of or agree with how processes are carried out. Furthermore, writing software requirements is difficult. How do we solve this puzzle?

Let’s make automation cheaper

I frequently compare the development of an information system to building a house. Do you call bricklayers and give them vague verbal instructions to build something? Then, if you change your mind during construction, you can move the walls, windows, and wires on the fly, right? Of course not. It would be too costly and unsafe, and we would break some laws in the process.

Instead, we consult with an architect first. They create blueprints that reflect our preferences: how many rooms we want, their orientation, perhaps a garage? Along with our wishes, architects must adhere to various building codes. When architects complete their work, the blueprints (construction, statics, electricity, plumbing, and so on) become mandatory instructions for the builders. More importantly, the blueprints serve as the foundation for estimating the cost of the house.

It is very similar when we are developing an information system for a business or organization. The software developers will need detailed instructions ('blueprints') on how to build it. Especially if we want to keep costs within the projected range.

That’s why we need consultants and business analysts (external or internal). They are capable of converting unstructured requirements and wishes into process models. And, of course, we need a good process-modeling tool (such as the Cardanit BPMN modeler).

Another successful project of mine comes to mind. It had to do with introducing a new CRM system to an IT service provider. We began the development by creating the following 'blueprints' in accordance with established standards:

• A typical document that describes what the system should do is an SRS (system/software requirements specification). We used the ISO/IEC/IEEE29148 standard for this.
• Models of processes. The system's behavior is described in the SRS document (chapter 'Functional requirements'). To describe the overall future system behavior, we used BPMN process models. Did you know that BPMN is standardized as ISO/IEC 19510:2013?
• We also used BPMN (execution model) to describe the detailed behavior of an IT system and its interactions with employees and legacy IT systems.

For this project, we used a traditional software development approach. Nonetheless, BPMN process models are extremely useful in agile development too, particularly for detailing user stories.

All these blueprints were used as input for the next phase, which was to acquire and adapt a new CRM system.

Yes, the initial price was slightly higher due to the preparation activities (see frame below, text in bold). However, the CRM system was successfully implemented and is still in use. This means we can treat it as an investment rather than a loss (as in the previous failed case).

We also discovered the most intriguing side effect of the preparatory activities. Modeling existing (AS-IS) processes almost always leads to a business process redesign.

Business process redesign – a natural consequence of process mapping

Something usually happens during or shortly after the process is modeled and exposed to multiple viewers (in our case, sales, engineers, and management).

Somebody will start paying attention and say: “Wait a minute; this looks very inefficient. We should do it another way.”

When engineers saw the process model above, for example, they said, "We have no idea what is coming in the next few months. It would be helpful to know which quotes are in the sales queue. We could organize our work better." Or, when the previous process was modeled, management asked, "Why is there no standardized way of reporting prospective sales? Can we include it in our process?”

I consider these moments of clarity the most important trigger for a process redesign.

Almost always, it became clear to all participants that current processes are inefficient and should be changed. This leads to process redesign.

During a process redesign, the team brainstorms how processes could be performed differently than they are now.

When manual processes are about to change, process redesign is especially important. This happens when we introduce new software into an organization.

Directly converting manual processes to IT-supported ones (1:1) rarely works or makes sense. As a result, immediately following the modeling phase of existing processes, we should redesign processes that will be supported by the IT system.

This can involve eliminating unnecessary steps, automating tasks, and improving communication and collaboration.

Furthermore, process redesign should be triggered on a regular basis, ideally every few months. But why? Because business is always changing. Technologies evolve. People evolve. The market shifts. It is simply not sustainable to have fixed processes.

Let us look at how we can redesign the sales process to make it more efficient and ready for use with a CRM system.

Improving cost efficiency of business processes by redesigning them

The cost efficiency of business processes can be improved by:

• identifying inefficiencies in existing processes,
• optimizing the process/preparing for automation.

When we design a process model, we can more easily identify bottlenecks, redundancies, and delays.

There is no shortage of general guidelines for redesigning processes. However, concrete examples are far harder to come by. I wish I’d had specific CRM process examples when learning how to model business processes, so I’ve prepared a couple for you.

An example of a bottleneck (and redundancy) in the CRM process

What could be a bottleneck in the sales process? A bottleneck is a position in a process where queues are forming. Somebody is waiting for somebody else’s work to be done. If a salesperson cannot handle all the incoming quote and report requests, they are the bottleneck. Customers are waiting for quotes, and management is waiting for sales reports.

This bottleneck scenario is shown in Figure 2.

How can we get rid of this bottleneck? We could hire more people or reduce the burden on existing employees by redesigning the process and eliminating some activities that can be automated, for example, sales-report preparation.

We could offload the burden of sales-report preparation to a CRM system. For one client, we redesigned a process so that salespeople only store lead information and update the status of business opportunities in a CRM system. We eliminated the manual report-preparation step, which typically took several hours. The following process allows management personnel to run a query about the current status of sales directly from the CRM database:

Not only does the redesigned process eliminate the need for manual sales report preparation, but it also reduces errors and mistakes. Sales reports are now uniform and comparable across salespeople.

An example of a delay in CRM process

Let’s take a look at a non-optimal sales (quoting) process. A potential customer requires a specific IT service (for example, web server setup and maintenance). They discover a salesperson's contact information on a company's website and send them a quote request.

An email is delivered to the inbox of the specific salesperson. Nobody else in the company is aware of the prospective customer's request. The salesperson may or may not confirm the received request. In the latter case, the potential customer has no idea whether or not their request was received. Sometimes, a salesperson may ask additional questions that are important for the quote.

Potential customers wait for the quote, which may not arrive for a variety of reasons: salespeople are too busy, forget, are sick, or are no longer employed by the company.

Whatever the reason, this process is inefficient, resulting in delays (which customers do not tolerate) and missed business opportunities.

Paying for CRM software and not using it is not the most expensive option in this case. Lost business opportunities and angry customers are the higher costs.

So, how did our redesigned, optimized, and automated process turn out? The interaction between potential customers, the website, the CRM system, salespeople, and the sales manager is depicted in the process model in Figure 5.

We redesigned the procedure as follows:

1. Customers no longer send quote requests directly to salespeople, but rather use a website to generate standard quotes. Standard quotes are saved automatically in the CRM system.
2. If they request a non-standard quote, the website creates a new business lead in the CRM system and notifies the salesperson to prepare the quote.
3. The sales manager assigns quotes to salespeople based on their workload and availability.
4. The CRM system always responds automatically to the customer.
5. The CRM system tracks time. If the non-standard quote is not completed on time, a reminder is sent to a salesperson and a manager.

What did we achieve with the redesigned process? The standard-quote preparation process was no longer delayed. We also made certain the customer was always aware of when the quote would be ready. Furthermore, the sales manager was aware of salespeople's workload and quote statuses.

The image of the redesigned process (Figure 5) not only serves as part of the SRS but also as a manual for employees to follow when performing processes. Some of them printed it and taped it to the wall.

What did we miss?

When redesigning processes, an important question arises: How do we know which parts of the process are inefficient? Do we rely on our gut feelings? Yes, in some cases. People who work within or manage a process typically 'know' how to improve it.

A better approach would be to use data analysis or simulation tools. But that’s a topic for another blog post.

All models are wrong, but some are useful

You may be wondering why more businesses aren’t using process modeling.

A model is a simplified or approximate representation of reality and thus will not reflect the whole truth. George Box, a British statistician, stated that "all models are wrong, but some are useful”. While a model can never be the ’truth’, it might be ranked as follows:

• very useful
• useful
• somewhat useful
• useless.

Box’s statement is applicable to statistical models, but it can also be applied to process models.

A process model is a simplified snapshot of reality. Let’s accept that a process model can never faithfully represent what’s going on in our organization. Rather, we could agree that it serves as an excellent communication channel between various members of the organization, such as consultants, IT developers, and managers.

While natural language is too vague and software code is too technical, graphical process models are the perfect 'language'. The BPMN (which has been around for more than 20 years!) is not only a communication language, but process models are now directly executable (with some technical modifications, of course).

Writing software requirements and modeling processes is difficult, but it pays off in the long run, especially if it prevents software implementation failures.

So, let’s normalize that everyone in an organization understands simple graphical elements used to build a process model. How are we going to do that? By making process models more accessible to our employees through appropriate tools such as the Cardanit process modeler.

Finally, here is a task for you

You, too, can begin redesigning your processes right now.

Take a look at these examples and try to (re)design your sales process. Begin with roles (pools), then add activities and link the elements together. You will see how simple it is. Play around with it. It’s the only way to learn process modeling.

Summary

The purpose of business process redesign using process modeling tools is to:

• Determine inefficiencies and improve processes: When we create a process model, we have a unified picture from which to identify areas for improvement. Unnecessary steps can be eliminated, and communication and collaboration can be improved. That’s a great cost-saver.
• Reducing errors and mistakes: By standardizing processes (everyone follows the same process), we can reduce errors and unnecessary delays caused by not knowing the procedures. Reducing errors also saves costs.
• Improving communication: When multiple departments or roles are included in a process model, we can reduce misunderstandings, double work, and re-work.
• Preparing for automation: We can eliminate some repetitive manual tasks by using a process model (and processing simulation data). This is usually the biggest cost-saver.

Although IT will never support all processes or parts of processes, all relevant processes should be agreed upon at the very least.