Identifying and designing process-driven applications is both an art and a science. Many times you will know which departments could benefit most when pursuing an incremental adoption of K2 blackpearl. Other times you will need to take a look at your company's organizational entities, how they interact with each other, and which ones are the most process-based already.
Take a minute to think about a process in your company. Keep that process in mind as you read this chapter. When you are finished reading, write down the major pieces of the process and ask yourself some of the questions included at the end of this chapter. Does your process fit some or most of the criteria of a good process for automation?
Also keep in mind that the methodologies and project roles identified in this chapter are meant for an organization that has a relatively mature Business Process Management (BPM) initiative in place. While you can strive toward this "ideal" environment, don't let a few missing pieces discourage you from designing your first process-driven application. Many times the first few applications that you build will be a great learning experience and can help you identify what you realistically need to build your next process-driven application.
This chapter covers the following topics:
Evaluating potential processes for automation
Running a process-driven application project, including methodologies, time estimation, and project roles
Identifying the business requirements of a process
Evaluating potential benefits of process automation
While there is no "typical" enterprise, many enterprises share a common organizational structure. An enterprise is nothing without employees or customers. You are in business for a reason, whether that is to sell a physical product or a Service. You probably have partners, suppliers, one or more banks that you deal with, and possibly a manufacturing plant and a warehouse. All of these departments, or business entities, form a critical part of your organization. They all interact with one or more of the other entities in your organization. The bank issues payroll checks to your staff, your sales staff contacts your customers to identify new business, and your customers contact your staff for support; every day there are many points of contact that each business entity makes with the other business entities. Figure 3-1 shows a high-level view of a company.
Drilling in to a particular business entity (see Figure 3-2), you'll find more points of contact with other business entities, which will lead you to even more business entities. In addition to your sales and support staff interacting with your customers, when you look closer you'll see that Finance also has a key role to play when making payments and collecting invoices. At the macro-level, Finance and HR didn't appear at all. This is the nature of every business — the more you look, the more points of contact you will find among your employees, customers, and partners. Each of these points of contact is a process. You may be surprised at the number of processes that you will be able to identify in just a few hours.
Earlier in the chapter, we asked you to identify a process that you want to investigate further. Now it's time to take that process and break it down into some pieces (see Figure 3-3). What are the building blocks? Common to almost all processes are the following items:
Forms: The way information is gathered and displayed.
Information: The data that is gathered, displayed, or collected while the application is running.
People: People are involved in all business processes, either directly through taking some action or indirectly by monitoring performance and viewing a report.
Policies: The rules that govern a process and the business.
Actions: Steps users take to move the process along.
Reports: A view of related information useful to decision makers and process optimizers.
Event Monitoring: The ability for a process to respond to external events.
These building blocks, in turn, bring up some good questions about the process, such as:
What type of forms does your organization currently use?
What type of information is gathered and used in those forms?
Where is the information stored?
Who is using those forms?
What are they doing with that information or those forms?
Who gets alerted when there is a problem with the form or data?
Who needs to see the aggregated view of the data?
What type of aggregation of the data is needed?
When you start learning about the process there will be more questions than answers. There are individuals within your organization who know the answers to one or more of these questions, and you will have to find them and ask them more about the process. Be thorough and cautious in this process discovery phase. A thorough approach allows you to put together a complete picture of the process, or as complete as you can get. This allows you to identify noncritical or potentially wrong information that you receive from people. It also allows you and the business owners, if that isn't you, to take a critical, objective view of the process. You don't want to automate a bad process; it will just go bad quicker than it used to.
While being thorough and cautious is good, it's not something that has to introduce anxiety or overwhelm you. Keep pushing through the process until you have enough information to work with. As you begin to understand the process, you and those you are working with will already begin to identify pieces of the process that can probably be improved. That's good. Write those down. These are precisely the items that process discovery helps illustrate.
Many times you will find people who know the "what" or "how" of the process, but the "why" of the process is "because that's the way we've always done it." This is not necessarily bad. If the culture of your company typically takes a critical eye to how it does business, the accepted way of doing things is probably okay (but maybe it could be improved). If your company does not typically pursue best practices, then your job of separating out the real process from noncritical aspects of the process will be more difficult.
Speaking of culture, many businesses are open and accepting of change. In this type of environment, making a complete assessment of a process will be less difficult than in a business environment that is not open and accepting of change. The best option in these latter environments is to pick a department that seems more likely to accept change (the "least bad" option), get executive-level support, or better yet, ownership of the process, and identify a process that will add immediate value.
A lot of this sounds more like project management than identifying and building a process-driven application. That's because it is. Therefore, it's useful to spend some time looking at project management and get back to the process itself toward the end of the chapter.
Like any successful project, having a strong methodology for process-driven application design will help ensure a successful deployment. We all know that we should follow a strict methodology and not skip any steps. Theoretically that makes sense, but it is hard to be disciplined with the documentation when deadlines are looming. There are many excuses why people shortcut the project methodology, but without proper planning and a structured design and development methodology, project success is at risk.
There are several reasons why development projects fail:
Corporate goals are not understood at the lower organizational levels.
Plans encompass too much in too little time.
Plans are based on inefficient data.
No attempt is made to systematize the planning process.
No one knows the major milestone dates and the ultimate goal of the project.
Project estimates are best guesses, not based upon standards or history.
Not enough time is given for proper estimation.
Resources are not available with the necessary skills.
People are not working toward the same specifications.
There is high turnover in the project team, without regard to schedule.
There is poor risk foresight.
These are some of the major pitfalls that many projects encounter. The basis for all of these is poor planning or no proper insight into a project methodology. A well structured methodology can ensure the successful delivery of any project and can steer the project clear of the pitfalls just mentioned.
In the last section of Chapter 2, we talked about a very agile method of developing and deploying process-driven applications. But agile development methodologies are not always suited to business process development projects, especially when the project team and the processes are large. In the end, the processes need to be well understood and analyzed before any development can begin. The following approaches can be successfully employed:
Big bang approach: Develop all forms, processes, and subprocesses and integration components.
Pros: If processes and technology are very well understood, this approach will bring about major changes at once.
Cons: Business processes can change between analysis and deployment phases, which may be a longer elapsed time than in iterative approaches.
Iterative approach: Develop a small number of workflow steps, with only the corresponding forms, and then keep reworking this based on stakeholder feedback.
Pros: Technology is understood rapidly by stakeholders, and small changes in business process appear almost immediately.
Cons: Feedback loop can be long, and requirements can change more rapidly than the project team can keep up with.
Quick wins approach: Develop the simplest processes first.
Pros: Technology can be proven, and the platform can be adopted faster.
Cons: More complex processes will lead to refactoring steps that might push the need to revisit the simple processes.
Slice approach: Develop a single process from the front end through the workflow all the way to the system integration.
Pros: Entire architecture proven and risks and problems identified up front, making subsequent processes faster to deploy.
Cons: In some organizations, this approach can be challenging when all stakeholders have to be involved in a short period of time.
The best approach can be different for each organization, and the methodology will evolve as the process team becomes more mature. Many organizations choose to combine aspects of these approaches. For example, an iterative/simple/slice approach will automate a simple process from the front-end to the back-end integration in an iterative fashion.
Another important aspect of your approach to process design is whether your process is linear or nonlinear. Linear processes typically follow the same set of steps that remain constant over time, such as procurement within a government agency. Other processes (nonlinear ones) change frequently, adjusting to outside business factors. Some are long running, and some are temporary. Others are ad hoc, requiring reallocation of work and flexibility in the number of users involved. When designing process-driven applications, it is important to consider dynamic activities, reassignments, unanticipated events that change actions or information, integration with other systems, nonlinear communication, and other unanticipated activities.
Just as with business processes, the BPM implementation process can sometimes be linear, following the standard flow of design: assemble, execute, monitor, and optimize (see Figure 3-4).
However, many times the implementation process looks more like a spiral. There may be multiple, coexisting spirals that have dependencies on one another. Or, the first process may be a subprocess of another with dependencies on others. Figure 3-5 illustrates a nonlinear model of process-driven application development.
For a successful project, there are several key roles that must be filled on your project team. A single person may fill more than one of these roles, or many people may play a single role. If you are just starting down the BPM path, your entire team could be two or three people, which is fine for now.
Project Manager (PM): The Project Manager is responsible for the project timeline and plan, organizing meetings, ensuring the project stays on time and on budget, filling roles with available project resources, identifying risks, and removing obstacles to the success of the project.
Business Owner: The Business Owner is responsible for the business process, which may span multiple departments or areas of responsibility. The Business Owner works closely with the PM to ensure that resources from the business are available and are responding promptly to the needs of the project. The Business Owner is also responsible for all approvals, or sign-offs, of the project. If the Business Owner is not an executive-level employee, they are responsible for getting executive-level sponsorship of the project, when necessary.
Subject Matter Experts (SMEs): SMEs have intrinsic knowledge of the business process or technical system and play a critical role in the design of the application. They can also play a key role in making decisions during the building and testing of the application.
Information Owner: The Information Owner is responsible for the underlying technology and knows the system and data better than anyone.
Business Analyst: The Business Analyst is responsible for the documentation of the process, including the business requirements, use cases, form design, and data requirements. The Business Analyst is a key conduit of information from the SMEs and Business Owners to the Process Designers.
Process Designer: The Process Designer is responsible for the design of the application. Many times, a Process Designer can also be the Business Analyst and can use tools like the K2 Designer for Visio to develop the business processes. It is the role of the Process Designer to translate the business requirements to the K2 features that will fulfill the needs of the application.
Developer: The Developer is responsible for developing any custom code that is needed as well as the integration points into line-of-business systems. The Developer will use tools such as the K2 Designer for Visual Studio to leverage the K2 API to build custom forms, custom reports, or custom applications to support the application.
Tester: The Tester is responsible for documenting the test cases based on the use cases provided by the Business Analyst. Once the system has been developed, the Tester will test the application and provide feedback to the project team. The Tester is responsible for sign-off that the application has passed all critical test cases and is ready for release.
Change Management: Change Management is responsible for the communication and training plan for the application. While usually an afterthought, the change management portion of a project is critical for the successful implementation.
Releaser: The Releaser, sometimes referred to as the Product Manager, is responsible for the release of the application. They are usually not a dedicated member of the project team, but it is critical that the Product Manager clearly communicates to the Project Manager what the release guidelines and regulations are to avoid any surprises near the release date.
The preceding roles are those most commonly found in business process projects. For a large project, each role listed could be a team in and of itself, with a team lead and team members. For a small project, a single person may play more than one role listed. The important part is not how many people make up the team, but that each role is filled and that resources are not over allocated.
Time management is important for all members of the project team. A culture of effective time management must be created in order to ensure the success and promptness of milestones within a project' lifecycle. There are several rules for time management that should be practiced during the project:
Conduct time analysis.
Plan solid blocks for important things.
Classify activities.
Establish priorities.
Establish opportunity cost on activities.
Practice delegation.
Practice calculated neglect.
Practice management by exception.
Focus on opportunities, not on problems.
Alongside the rules, there are several questions that team members can ask when trying to manage their time effectively:
What am I doing that I don't have to be doing at all?
What am I doing that can be done better by someone else?
What am I doing that could be done sufficiently well by someone else?
Am I establishing the right priorities for my activities?
While time management is crucial for ensuring the project is delivered on time, proper estimation of the project tasks is also essential. In order for the Project Manager to effectively plan and control a project, it must be estimated correctly from the beginning. The Estimator's task is to predict the project's parameters by building a model of the project on paper. The quality and accuracy of the estimate should be seen as the best approximation based on:
Time available
Information available
Techniques employed
Expertise and experience of available resources
Because of the nature of any business, it is expected that the project is committed to a budget and a deadline early in the project's life. Limited information regarding a project is available during the beginning phase of a project. This makes it very important that all resources participating in the estimation process be skilled in time estimates to provide accurate estimates based on incomplete information.
Due to organizational nuances, it is important to estimate projects based on the known constraints of an organization. For example, if the Releaser for your project works only on Fridays, it is important to take that restraint into account when setting up your timeline.
One of the key success criteria for a project is that expectations are met with the final project. The Project Manager should start setting expectations early when you are defining your project methodology and team members. This should include:
Meeting schedule: Be sure to let people know when and where the project meetings will occur, as well as an agenda ahead of time.
Communication schedule: Publish the communication schedule, for both internal project communications and external communications. Be sure to include review and approval time for external communications.
Deliverable checkpoints: Publish the checkpoints and deliverable dates and hold meetings for feedback. Be sure to allow enough time for the Business Owners and SMEs to review. Remember, this project may not be their full focus and be respectful of their other obligations.
Collaboration mechanism: Decide where documents, decisions, issues, and all project-related information will be stored.
Once you've set the expectations, be sure to hold to what you promise. Having a good track record with your Business Owner and SMEs will ensure that future projects will be more predictable.
Now that you understand the project methodologies and roles, you can get back to the business process itself. Note that the methodology and roles are completely independent of the business process you will tackle in this project; they are common across all projects.
If the process is large and complex, this phase will take significantly longer to complete than you might first estimate. Plan for and expect a long discovery phase. The amount of time and effort that you put into this phase will make the rest of the process implementation phase much faster and less prone to errors and rework.
The best way to find out the answers to your questions is to ask. There are three basic categories of questions that you want to ask and the next three sections give some examples. Though not an exhaustive list of the types of questions you need to ask, these can give you a good start toward identifying your process requirements and building the basis for evaluating the benefits of automating the process.
It is always good to know as much as you can about the process. This can give you insight into where the process is currently working and perhaps where it is not. It also helps you start to identify the requirements of the process and eventually, its main goals. Process questions include the following:
What is the process today?
Where does stuff live (that is, Where is the data? Where are the forms?)
How do people interact with the application and/or process?
What are the external requirements (for example, Audit, Legal)?
What are some of the issues or bottlenecks with the process today?
Without people a process is just a programming exercise. People are key to understanding the business process and often have knowledge about the process that no one else does. People questions include the following:
Who owns which aspects of the process?
Who participates in the process?
Who knows how this process works today? Should work tomorrow?
Your entities could simply be the departments within your company, or they could represent functional roles that span multiple job titles and departments. They could also encapsulate internal business policies, or external governmental laws, or business association standards. Understanding your entities helps you round out the process requirements. Entities questions include the following:
What are the primary organizational entities in this process?
What are the business entities or objects associated with this process?
What are the business rules that govern this process?
When an organization is looking at process automation, the reality is that any process can be automated. It is a matter of deciding whether or not it makes sense to the business to automate the process.
The following questions can be used as guidelines and criteria for determining if your processes should be automated:
If this process did not exist, what would the impact be to your business? With the response to this question, the perceived value of the process can be determined. Based on this perceived value, you can perform a cost/benefit analysis either to justify the project or to discard the process from the selection. In the next chapter we discuss ROI calculations. Make these numbers part of your project plan.
Has this process been mapped or optimized before? If yes, then there is probably a good definition of the process that can be used as a starting point for the project. Even a Visio diagram of the process can help identify where additional questions should be asked to see if the process is a good fit. If no, then the process probably needs to be defined in more detail to understand if it is a good fit.
Do you have disparate business systems that need to participate within a single business process? Do you need to obtain data from other information systems? If yes, then it is a good candidate for a process-driven application as integration with LOB systems is a key component of the K2 platform. Additional questions around this topic will help clarify the data requirements and determine if custom development work is required to retrieve and update data in the line-of-business (LOB) systems.
Is there data or a form that needs multiple people to review and/or approve? If yes, then it is a good candidate for a business process. Additional questions around this topic will help identify the data and form requirements, tracking and auditability, as well as the process roles.
Does this process require more than one type of review or decision at the same time? If yes, then it is a good candidate for a process application as handling the routing and tracking of decisions is a key component to the platform. Additional questions around this topic will help identify parallel or serial processing for activities.
Is this process time sensitive? For example, are there Service Level Agreements (SLAs)? If yes, then it is a good candidate for a process application, as escalations are a key component of the platform. Additional questions around this topic will help identify escalations and notifications to enforce SLAs in the process definition.
Is it important to notify the process users of the status? Is overall process visibility important? If yes, then it is a good candidate for a process application, as notifications and process visibility are key components to the platform. Additional questions around this topic will help identify interfaces such as e-mail notifications, dashboards, and reports based on the audience.
Does this process require reporting across systems or auditing for compliance? If yes, then it is a good candidate for a process application. Additional questions around this topic will help identify the integration pieces for the process as well as the reporting and auditing requirements.
Do you believe that automating this process is going to be more cost-effective in the future? If yes, then it is a good candidate for a process application. If you do not believe that automating the process will be beneficial, then do not try to force it as a solution. However, if you do see some benefits to automation, those can be key selling points to get business owner and process user buy-in, especially when the benefits of automation tie in with departmental or even corporate goals.
Aside from questions that you ask yourself about the process, think about other benefits to the users of the process as well as to the business.
A process may be a good candidate for a process-driven application if such an implementation can produce some of the following benefits for users who will be involved in the process:
Hide business processes: To some users, particularly those involved in a single step, the process may not look like a process at all; they will not know what the next step is or where the data came from. They are just filling out an InfoPath, SharePoint, or ASP.NET form that they received a link to in an e-mail.
Consistency: The ability to design and consolidate user interfaces and views of data, while maintaining the core of the process can make it easier to standardize a series of forms and reports.
Transparent applications: Information about process-driven applications with the K2 blackpearl platform can be easily surfaced in a report or in a graphical way using the View Flow component. Anyone who has the right security can find out where the process is and get data about the process, whether that is tracking information or business information.
Reduced inefficiencies: When designing the process, you may be able to streamline and optimize some of the steps.
If the following aspects of the process are true, it increases the chances that the process you have identified is a good candidate for automation:
Large number of participants
Process crosses organizational boundaries
Large number of instances that must be tracked
Geographically dispersed participants
Processes that last over long periods of time ("long-running" processes)
Processes that currently involve costly mistakes, such as legal ramifications, fines, damage to the business's reputation, and sensitive intellectual property leaks.
Each one of these aspects of a current process can benefit from automation, if only to improve tracking and increase security in relation to which users have the necessary rights to view data about the process.
Identifying the process and forming a project team are the first steps towards delivering a process-driven application. From a project management perspective, it's not all that different from other projects. The same diligence and thoroughness are required for a successful process-driven application project as they are for other technical and nontechnical projects alike. If you are just starting down the road of process-driven applications, do not let the methodologies and roles overwhelm you. Gain some experience with delivering a few simple process-driven applications before you tackle the larger, more complex ones. In this way, you will learn what works for your company. While the best practices are outlined here, the only thing that really matters at the end of a project is whether or not it is successful.
In the next chapter, we'll look at how to measure the success and Return on Investment (ROI) of a process-driven application project.