This is the second column that I have focused on making a BPM methodology more agile.
As noted earlier, “agile” means different things to different people. My own introduction to Agile came from Kent Beck who was giving talks about Agile at Cutter Consortium's Conferences in the 90s. Kent was a software developer who was frustrated with the then-popular “waterfall method” of software development, with its rather ridged sequence of phases and steps. Kent put the emphasis was on taking a small step, completing one module of code, and having something that could be executed at the end of each day or week. It was also about using teams that worked closely together to get results without worrying so much about responding long term schedules or creating comprehensive documentation. The approach depended very much on new software languages and tools that had become available in the 80s that facilitated quick development and supported interpreted code.
Kent and several other software engineers who were promoting this more informal and modularized approach got together and wrote an Agile Programming Manifesto that laid out the basic principles on which the Agile Software Development movement is based. Some of the key points include:
- Individuals and interactions — Over processes and tools
- Working software — Over comprehensive documentation
- Customer collaboration — Over contract negotiation
- Responding to change — Over following a plan
If we apply these ideas to process transformation, we presumably will emphasize a more informal approach to process redesign. We will emphasize teams, doing something quickly, testing it, and then trying another iteration, and we will try to minimize formal documentation efforts.
As we mentioned earlier this approach opposes the formal process methodologies that put more emphasis on developing an architecture and surveying an organization looking for any and all opportunities. The main driver for this change is the growing role that transformative technologies are playing in our organizations. Where, in the past, we might have wanted to be more systematic, today, we are increasingly being driven by a much greater sense of urgency—a pressing need to incorporate a new technology before its use by a competitor places our organization as a significant disadvantage. This urgency leads us to disregard the more detailed analysis efforts of an earlier era and to use techniques that a team can use to more rapidly identify opportunities to use a radically new technology.
In this first article on an agile BPM approach, we will address one issue: identifying the opportunity to be addressed by the new technology.
The New Process
Everything begins with a team whose job it is to imagine how a new technology will impact your businesses processes. If another organization is already pioneering the technology, then you can draw ideas from the other organization's work. You can describe what they are doing and then try to imagine how you might do it better. If you are going to be the first, then you must start with a blank sheet of paper and imagine how the new technology will transform your organization.
Let me draw here on an example I know because I consulted with an organization that undertook a transformative change. In the late Seventies, banks began to use Automated Teller Machines (ATMs) that would allow customers to do banking via machine. Laws in various states set rules. For example, in some states the machines could be located independent of the bank, while in others, including the state I worked in, the machines had to be on the premises of an existing bank. In our state, we had to imagine where we could put the machines in existing banks. We knew they could operate 24 hours a day, 7 days a week, so we had to think about how to keep them stocked with money during busy weekends when the branch was closed, etc. The bank I worked with was the first to do this within our state, though ATMs had been installed in other states and we could draw some ideas from that.
As a process person, I worked as part of a team that considered the problem. At first I sat quietly and listened to ATM technicians talk about the machines and how they would install them at existing branches. Special teams would be created to bring money to the machines, etc.
After gaining an understanding of the basic technology that was to be employed, while some members of the team began to focus on programming changes to the bank's software systems, I began to focus on processes*. Working with branch personnel, we came up with a list of some 10 business processes that would need changes. A different way of thinking about this was that over 20 people would need to learn new things in order to do their jobs. Some existing jobs would change while other jobs would be created. In all cases we would need to define steps and procedures that would be done differently. These ranged from training tellers to answer questions from customers about their interactions with ATM machines, to training people to sit at phone banks and take phone calls about ATM problems. (e.g. “My dog has been chewing on my ATM card. What do I do to get a new card?”)
We came up with a list a major business processes that would have to be changed, and then developed a schedule for several parallel process improvement projects that would need to be undertaken to assure that new processes would be in place at the time that the ATMs were actually ready to be used. At the time this represented one of the largest process improvement and personnel training projects ever undertaken at the bank. Moreover, since senior management wanted to be the first to roll out ATMs in the state, technology implementation was driving the schedule, and all of the process change efforts were under considerable pressure.
I'd like to say that the bank already had all of its processes well defined, with flow charts and detailed documentation, but it didn't. Moreover, it was obvious to those of us working on the project that we wouldn't have time to develop detailed process models of the various processes to be changed. Instead, we were forced to focus on the specific activities we knew would need to be changed, and develop what was needed to support the specific changes that would be required.
In other words, we know that the teller process needed to be changed so that tellers could deal with new customer questions. We didn't seek to define the whole teller process, however. We simply identified specific activities, like Answer Customer Questions, and focused on specific changes in those activities. In a similar way, we extended Platform Officer's activities to include a new activity, Help Customer Apply for ATM Card. At the same time, we provided all bank branch personnel with an introduction to ATMs—each got a card, and learned to deposit and withdraw money from the ATM, etc.
Unlike a more traditional process analysis where we started from the top and defined the whole business context—in this case we skipped much that we might otherwise have done, and focused on figuring out the changes the new technology would create, and then defined the places the technology would cause changes and decided how to deal with specific changes in specific activities. This wasn't primarily a matter of flow charts and detailed analysis, though there was some, but it was mostly a matter of working with a team a technology and branch personnel, considering scenarios, and working out what customers and employees would be asked to do differently.
Mostly we documented changes with lists, although we used some diagrams and we'll touch on those in the next column on Agile change.
* Since ATMs would be open 24 hours a day, it meant that customer accounts could be updated at any time. Previously, customer accounts would only be updated during “banking hours.” Thus ATM machines began a major transition in how software people thought of account updating processes.
Paul Harmon
Latest posts by Paul Harmon (see all)
- Harmon on BPM: A General Management Model - July 4, 2022
- Processes and Capabilities - July 4, 2022
- Harmon on BPM: The Scope of Management - June 6, 2022
- Should Every Manager Be a Process Manager? - June 6, 2022
- Harmon on BPM: Management Processes - May 2, 2022
Speak Your Mind