Process Modeling:

Complexity is just a combination of simple things


Business Process Management (BPM):

How you manage complexity in a simple way

Welcome

Rick Geneva Welcome!

My name is Rick Geneva and I’m a business process expert, specializing in modeling of complex business processes in BPMN (Business Process Modeling Notation). I have worked in the IT industry since 1994 in various roles including network / database administration, web design, programming, software architecture, project management, and business analyst. You might say that I jumped around a lot, but in this diverse background I learned so much about the IT industry.

To become an expert process modeler, you must have a strong understanding of many industries, and many common IT job functions as well. Many people come from a pure business background, and many others come from pure IT, such as a software developer. Much of the challenges in today’s fast paced business world stem from the fact that IT and BA (business analyst) staff speak, write, and diagram in a different language. Much detail is lost in translating lengthy requirement documents in to technical specifications.

BPMN is the first language that addresses the needs of both business and IT. The notation that can be used to create high-level block diagrams can also be used to document the most technical things, such as a multi-threaded transactional service implementation. The shapes used in BPMN aren’t that much different than those of the flowchart diagrams, but you can achieve far greater detail with less shapes in BPMN.

After many years of working as a software programmer/architect I came to the conclusion that we were doing something wrong in the IT industry. I found myself editing hundreds of files containing software code that was just going to change in a few months. I realized that creating reusable libraries of code wasn’t getting me anywhere because it simply never got reused. Instead, I copied it and pasted it into even more files containing software code until eventually I created hundreds of megabytes of code that even I couldn’t remember what it was originally used for.

Business requirements are constantly changing to the environment. Processes must change to accommodate. However, these processes are backed by software that has been hard-coded to meet the demands of the last cycle, so often we once again start building from scratch. Much of the software can be salvaged if it’s something we built internally, but it still takes more time to build than what the business demand actually allows for. This was my constant struggle as an IT architect – to build something that could actually keep up with market demand.

We all have a few moments of clarity in our lives that define us. A few years ago I realized something important. Business requirements for custom business software are at best 50 – 70% accurate. The other 30 – 50% is made up of assumptions, lack of communication between BA and IT staff, and a general lack of knowledge of how the “as-is” business process actually works. Adding a new business system in an organization might show some initial gains, but the previous processes are likely to change as a result. Often, these changes hinder the process rather than adding efficiency as promised when the software was sold (or built).

Since July of 2000 I have been on a mission to change the IT industry. At the time, BPM was in its infancy and I wasn’t even aware that it existed. It wasn’t until 2004 that I was introduced to the formal BPM practice, and by that time I had several years of service oriented architecture (SOA) experience. The opportunity arose for me to start modeling processes in a way that allowed me to focus on the business objective, rather than the technical details of some stupid piece of software I had to create to make the thing work. Prior to this experience, like everyone else, I used a whiteboard.

Yes, I to wrote it on a whiteboard, copy it to a legal-size notepad (usually a yellow one), then copied it to a document on the computer. Next, distribute it to a dozen people who were in the same room and took different notes, only to have another meeting to argue about who’s notes were more accurate. Weeks later we finally got the specification figured out, then started to build it, only to find out that someone forgot something important so it was back to the drawing board.   By the time this was done, the business analyst came back and told us that the customer was changing the requirements due to some details overlooked, and changing market conditions. When the customer changes something, it means my team had to start all over from scratch. It’s amazing we ever got anything done. Later I had lunch with a former team member from that job. They were still working on that product, several years later, with no end to development in sight.

In 2004, for me, the process revolution had just begun. Elsewhere in the world, BPM had already carved out its niche and standards such as BPMN and BPEL were emerging. Initially I was skeptical, but now I am completely convinced that BPMN solves most of my requirements gathering problems. It’s not the notation its self, but the methodology and best practices I developed using the notation that made the biggest difference. In 2008, I wrote my first book and launched this site to share what I’ve learned.