ProcessModeling.info

Often I hear from people that are looking to implement a new “workflow application” in their organization. This always gives me a reminder that we (the IT community) have not yet broken through that boundary yet to where everyone understands what is a process and what is an application. So to quickly clarify things, here’s my quick generic definitions to get everyone up to speed.

Application: Something you install on your hard drive that was designed to help you be more productive. Usually it’s some kind of tool such as a word processor or spreadsheet. Applications can also be online through a web browser, but this is just a difference of how it’s distributed and viewed. Usually an application creates data and stores it somewhere. Sharing data requires another application.

Enterprise Software: Something that took a lot of time and money to develop, for a specific purpose, usually in the form of records management. CRM, financial software, and inventory management are all classic examples of this type of software. Most often this type of application is developed as an online system viewed in a web browser. Many users are involved in this type of system. Data sharing and routing is a common feature.

Workflow: Steps that are required to complete a series of tasks in order to achieve a goal. Often multiple people are involved who collaborate on a data artifact. A good example is sending out a meeting request via Microsoft Outlook or Lotus Notes. This is an example of simple workflow that doesn’t need elaborate rules or custom configuration. It’s generic and can be applied to any business situation.

Note: Workflow methodology began in the 1920′s, and yet many organizations still use it to define their software. Interesting.

Business Objective: The reason why you wanted the software in the first place. You know, that thing that keeps making you change your requirements document all the time.

Business Rules: Policy and procedure that is both common practice for your industry and unique to my organization. Ensures consistency across an entire organization.

Business Process: A combination of all of the above. In our BPMN book Tom D. and I define the business process as:

• “A business process is a flow of decision-coordinated activities, conducted by participants and acting on data, information, and knowledge that reach a goal”

So if I have a business process system that is a combination of an application, enterprise software, workflow, my business rules, and ever-changing busines objectives, it looks something like this:

1. A window to the data. This can be online or installed on my hard drive.
2. Data will come in and out of my view.
3. Other people will log into the same system.
4. I will be alerted when there is something new for me to do, or when something interesting is happening that I should look at.
5. The system will handle the routing of my data for me, without the need for me to figure out how to send it, or where to send it to.
6. Much of my decision is automated through well-established business rules.
7. The system is capable of executing workflows specific to my organization.
8. The system will can easily adapt to an ever changing business objective.

The typical “workflow application” might be capable of achieving goals 1 through 5, and sometimes number 6. But 7 and 8 are the most important points, and often the most overlooked. Things that we cannot foresee are usually not included into our design. Therefore, changes don’t exist until they exist. This was fine 15 years ago when things didn’t change much, but today, changes need to occur much faster than ever before.

Usually, a workflow application is coded with certain rules and restrictions. Being flexible enough to accommodate constant change is usually not in the design. Some typical reasons for this inability to adapt include:

• Certain data flow rules and logic is usually created to be specific with an industry
• The original design was based on an idealistic view of the organization without a shred of proof that it will actually work.
• The system was configured to directly mirror the “as-is” workflow without considering the impact of introducing a new system into the ecosystem of the organization.
• The exception workflow is usually never considered. “Oh, that only happens every now and then, and we’ll just deal with that manually”. These are famous last words of every doomed multi-million dollar workflow development project.

I’m not suggesting that every system can account for every unforeseen event in the future. This would be impossible because by definition, unforeseen means that we don’t know about it yet. They key is in the ability to adapt to new requirements as they come. To achieve this goal, try using the following guidelines:

1. Don’t make any assumptions about what it should look like.

Model the business process first, then visualize what will be needed to solve the problem later. Often the mistake is make of creating a data model first, or mocking up some screen shots. Once you have created something and it’s in front of your team, the team will follow your lead and finish what you created. The problem is, most often the business process challenges were not solved before starting to build the foundation. So what you end up with is retro-fitting business requirements into a system before it’s ever completed in the first place.

2. Process models should be kept small enough to manage.

The larger to process diagram, the more complex the system becomes. Often the complexity is unnecessary. Several smaller diagrams tend to keep the system implementers focused on specific objectives, rather than trying to solve the entire problem all at once. Create many diagrams that cover the scope of one scenario or major use case. Link these scenario diagrams together.

3. Use a Service Oriented Architecture (SOA) approach

SOA allows you to create smaller services that are more general purpose, and can be reused in multiple places. Of course, the first time you invent a service there is the investment of creating it properly. But once build properly, it becomes part of a library of lower-level functions that can be consumed by processes. Chaining these SOA components together along with some existing applications and human workflow will get the job done nicely.

4. Limit the scope of your User interface(s)

User interaction is not always a simple form – Sometimes its a miniature application. These days it’s Ok to build a rich UI client application for your process. Technologies such as AJAX made it acceptable. But this does not mean build a big one. This means that for the scope of an interaction, build it as big as it needs to be. But when the scope of a single interaction is completed, the scope of the user interface is also done. Create another user interface for the next interaction task, and reuse components from the previous ones.

5. Don’t spend a lot of time shopping for your solution.

Odds are that you are trying to create a system that fulfills a need unique to your organization. This means that it probably does not exist out of the box. Refer to rule #1 – model it out first. Then you will know what you are looking for. After this, you can make a more educated decision on what you can use from your existing systems, what you need to buy, and what you need to build.

Trust me – it’s all about the business process first. All the other details usually fall into place very easily once you have the correct process model.