Chapter 13. Supporting Organizational Change

Image

So far, we have looked at different ways that Domain Storytelling helps build software. When this software comes into use, it will influence how people in the company work.

The goal of a new software system is usually to make work easier, faster, more efficient (or in short: better). This goal will not be achieved by digitalizing bad manual processes. Neither will a pile of requirements magically turn into a seamless business workflow. To build good business software, you need to go beyond merely modeling the current situation. You will need to design the future way of working. Domain stories help to do this and visualize how new software will change the way people work.

This chapter is for you, if you want to do any of the following:

• Design how work should be done in the future

• Optimize business processes

• Want to discuss and promote change in business processes

• Have to bring new software into use

• Have to roll out a new version of an existing software

Stefan’s State Authority Story

Once, a state authority commissioned us to help them gather requirements for a new software system. The domain involved a lot of legal matters and expert decisions. The domain experts’ tasks were not supported by specialized software systems. Basically, they just used typical office software.

There was a big obstacle on their way to better software support: The authority had offices in four cities, and each office had to do the same tasks—but they all did them differently. This meant either they needed a software system that supported a high degree of flexibility or they had to align their business processes. The state authority decided to do the latter.

To design a new way of working, we first looked at how the domain experts worked currently. To get an overview of their tasks, we met with representatives from all offices and mapped their current responsibilities to a UML use case diagram (see Chapter 7, “Relationships to Other Modeling Methods”). Then, we had follow-up workshops where we modeled the use cases as domain stories—office by office. We had at least four domain stories for every use case (one for each office, and some use cases required several stories for us to understand them sufficiently). The scope of these domain stories was FINE-GRAINED (sea level), AS-IS, and DIGITALIZED (even though there was hardly any software involved).

Once we had modeled the different versions of the business processes, we started to compare them and used colors to indicate differences. In a workshop that again included participants from all offices, the differences were discussed, and the domain experts explained to each other why they worked that way. It turned out that many differences were actually negligible. In these cases, deriving a consolidated business process from the existing ones was straightforward. However, if a common process was not obvious, we chose to design one starting with an empty canvas rather than basing it on an existing one.

When the domain experts returned to their offices, they found it easy to explain to their colleagues what was discussed in the meetings. They just needed to compare the AS-IS and TO-BE domain stories for each use case to understand how their work would be affected by the change.

Changing People’s Workflows

During the average employee’s career, the way their work is done will usually change several times. The reasons for this change may be manifold: because new tasks are to be done, because the company is re-organized, or because the process is optimized.

Modeling the Change

Change is always hard—hard to understand and hard to achieve. In More Fearless Change, Mary Lynn Manns and Linda Rising point out that head, heart, and hand have to be addressed equally by the change agent [Manns/Rising 2015]. When bringing change to an organization, it is important for everybody to understand the following:

• What changes

• Why it changes

• How it affects me

• How I can help

Domain stories can help by visualizing what will be different in the future (and what stays the same):

• Because of change in the work itself

• Caused by process optimization

• Caused by legal obligations

• Because of the introduction of a new software system

To make the change between the processes visible, it often helps to modify the domain stories by coloring the symbols. Figure 13.1 shows a typical legend for such domain stories. Removed or changed elements are red in the e-book or light gray in the print version of this book. New or changed elements are green (e-book) or dark gray (print). Elements that do not change stay black.

Image

Figure 13.1 Visualizing change—a typical legend

The resulting stories visualize the output of a discussion, but they don’t carry all the explanations. Hence, you should at least write down the key decisions and the rationale behind them, either as an annotation or in a separate document.

Back to the Leasing Example

In the Alphorn auto leasing case study (see Chapter 8), we modeled the risk assessment process with Raymond the risk manager. In doing this, he recognized that the process was suboptimal. Since the team did not want to just digitalize a bad process, the AS-IS story Alphorn 3 (see Figure 8.3) was developed further into the TO-BE story Alphorn 4 (see Figure 8.4). The latter shows the optimized process.

He now wants to visualize what is changing from a business point of view. Therefore, he compares the two PURE domain stories. To make the change between the processes visible, the team modifies the domain stories by coloring the symbols according to the legend from Figure 13.1. The results of this modification are the AS-IS story Alphorn 3a (see Figure 13.2) and the TO-BE story Alphorn 4a (see Figure 13.3).

Image

Figure 13.2 Alphorn 3a: Risk assessment—FINE-GRAINED, PURE, AS-IS—colored

Image

Figure 13.3 Alphorn 4a: Risk assessment—FINE-GRAINED, PURE, TO-BE—colored

When the two domain stories are side by side, it is easy to spot the difference. This makes it easy to explain the difference, too.

In the collaborative modeling sessions that led to the previous stories, not all risk managers were present. Raymond can now use the stories to explain the new process to the other risk managers.

Every member of the risk management team can see the following:

• This icon represents me.

• The red arrows connected to that icon show which tasks will change for me.

• The green arrows connected to that icon show what will be new for me.

Using the domain stories Alphorn 3a (see Figure 13.2) and Alphorn 4a (see Figure 13.3), Raymond explains: “The management has decided: You don’t have to pass on the voted contract (step 3) anymore; you just sign the contract yourself.”

As we have seen, using color can help highlight changes. An alternative to colors is to use groups: one group to show what is changing and one group to show what stays the same. In our experience, this is not as helpful as using colors. This is mainly because the different parts in the story that change cannot easily be grouped. Also, readability can suffer. However, for simple domain stories like Alphorn 3 and Alphorn 4, grouping changes can be a viable option, as you can see in Figures 13.4 and 13.5.

Image

Figure 13.4 Alphorn 3b: Risk assessment—FINE-GRAINED, PURE, AS-IS—grouped

Image

Figure 13.5 Alphorn 4b: Risk assessment—FINE-GRAINED, PURE TO-BE—grouped

Digitalizing Work

Another reason for changing a process is because of the introduction of a new software system.

Designing Viable, Software-Supported Processes

TO-BE processes played an important role in Chapter 11, “Working with Requirements.” There, we advised you to not just blindly model what your users tell you. We discussed the limitations to a collaborative design process: Domain experts often find it difficult to imagine software solutions other than the ones they are familiar with. They also do not know what is possible with modern technology. Other limiting factors include organizational structures and reward systems. In our experience, many domain experts favor small improvements over significantly changed processes.

Back to the Leasing Example

When we started working with Alphorn, they had a somewhat old-fashioned, in many parts paper-based, way of operating their business. When the new online leasing service is introduced, it will change the daily work of its users, both because they will now use software instead of the old system and because the process itself will be a bit different.

Alphorn 2 describes how the work is done today (see Figure 8.2). Alphorn 5 contains the to-be-built system (see Figure 8.5). With the latter, the team explored how the system will influence the business process. Both stories are now colored to visualize the changes. Figures 13.6 and 13.7 show the result.

Image

Figure 13.6 Alphorn 2a: Risk assessment—FINE-GRAINED, DIGITALIZED AS-IS—colored

Image

Figure 13.7 Alphorn 5a: Risk assessment—FINE-GRAINED, DIGITALIZED, TO-BE—colored

The members of the risk management team can see the following:

• This icon represents me.

• The red arrows show which tasks will change for me or will be done by the system in the future.

• The green arrows show what will be new for me.

Raymond explains the new process with the help of domain stories: “You will not have to fill out the credit rating form (step 1 in Figure 13.6) or create a risk assessment (step 3) anymore; this will be done automatically by the new online leasing service. It will notify you when a credit rating has arrived. Then you decide the voting result in the same way that you always have (step 5). Finally, you have to sign the voted contract in the new online leasing service.”

Putting AS-IS and TO-BE situations side by side highlights what will be different with the new system. The people designing the process can see if their ideas can work, and the people who will use the new system can see how their work is affected.

What to Read Next?

Organizational change is interwoven with other topics covered in this book:

• Designing TO-BE processes will uncover requirements for new software systems. That’s why organizational change and working with requirements (see Chapter 11) often go hand in hand.

• Also, organizational change can move domain and team boundaries around. In Chapter 10, we described an analytical way of finding boundaries for software systems and teams. However, boundaries cannot only be identified, they can be designed by changing the communication structure of an organization. That means you can make use of Conway’s Law [Conway 1968] to design communication structures to promote your desired software architecture (the so-called inverse Conway maneuver).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.199.212.254