Modeling Business Processes

Now that you at least have an idea of what you'll be modeling, let's proceed with translating the application functions you defined earlier into business process models.

Getting Started Modeling Your Business Processes

To see how the functions-to-processes transition works, let's return to the sample application I mentioned earlier. Recall that I mentioned an app whose statement of purpose was the following: "The RENTMAN System will facilitate rental property management."

Some sample application functions for RENTMAN were:

• It will log and maintain property leases.

• It will track ongoing property maintenance work.

• It will generate tenant billing information.

• It will provide historical information on individual properties.

Modeling is like swimming: The best way to learn is simply to jump in. To see how you model the business processes that correspond to application functions, let's model the processes required to accomplish the first functionlogging and maintaining property leases.

The task of modeling any business process goes like this:

1. Determine the external entities, processes, flows, and stores that are needed.

2. Decide how these elements relate to one another.

3. Diagram these elements and their relationships in the process model.

Because you know you'll be modeling rental property lease management, the following questions need answers:

• What external entities are needed to log and maintain property leases?

• What processes are involved?

• What resources will these processes require?

• What data stores will be needed?

• How does data flow from one element to another?

In this case, you can already deduce the following:

• You'll need at least one external entitythat of the prospective tenant.

• Separate processes will be required to handle lease processing and lease execution.

• Assuming the rental management company wants to track calls from prospective tenants, and wants to store tenant, lease, and property information separately, you'll need four data stores. These stores will stockpile calls, tenants, properties, and leases.

• As far as data flow between these elements, you can assume the following:

  • Prospective tenants contact the lease clerk at the property management office to inquire about available properties or enter into a lease contract.

  • The lease clerk logs each call as it is received, regardless of whether it results in a lease.

  • The lease clerk checks available properties before forwarding a lease to the lease manager.

  • Once a lease has been verified by the lease clerk, it is forwarded to the lease manager for execution.

  • Tenant information that is received during the lease is kept on file by the lease clerk.

  • The lease manager keeps a record of executed leases.

With these facts in mind, let's begin building the business process model for managing lease information.

Adding External Entities

Begin by starting your modeling tool of choice and creating a new business process model. Next , find your tool's external entity object and drop it on to the upper left corner of your blank model. Set its name to Prospective Tenant. This object will represent the prospective tenant who will either inquire about available properties or who will call to enter into a lease on a particular property. Figure 5-3 illustrates what your model might look like so far.

Adding Processes

Drop two process objects onto your model: one onto the upper middle and one onto the upper right. Set the name of the first process to Lease Processing and the second to Lease Execution. The Lease Processing object represents the receipt and verification of lease information. It's the focal point of the whole leasing process. The Lease Execution process represents actual leasing of the property. It entails turning over the keys and other items to the new tenant and making a record of the new lease. Figure 5-4 illustrates what your model might look like with these two processes in place.

Adding Stores

Now drop four data store objects onto the bottom of the model. These will represent the data stores with which the other model elements will interact. Name the first one CALL, the second PROPERTY, the third TENANT, and the fourth one LEASE. Your process objects will send and receive data from these stores. Figure 5-5 shows what your model might look like at this point.

Adding Flow Objects

Now that all your objects are in place, you're ready to define how they interrelate. You'll do this using flow objects.

Connect the Prospective Tenant and Lease Processing objects using a flow object that runs from left to right. Set the text label of the flow to Applies for Lease. This represents the application by the prospective tenant for a new property lease.

Now connect the Lease Processing and Prospective Tenant objects using a flow object that runs from right to left. Set its text to Notifies of Acceptance. This object represents the interaction between the leasing office and the prospective tenant.

Connect the Lease Processing and Lease Execution objects using a left-to-right flow object. Set its text to Verifies Lease. This represents the fact that a lease is forwarded to the manager for execution after it has been verified.

Now connect the Lease Execution and Prospective Tenant objects with a flow object that runs right to left. Set its text to Leases Property. Figure 5-6 illustrates what your model might look like with these objects in place.

The remaining connections all have to do with interacting with your data stores. Study Figure 5-7 carefully , then add the flow objects necessary to make your model match it.

Adding Data Structures

You've now successfully modeled the process of leasing a property to a new tenant. You could further enhance the model, but the one you have so far is quite functional.

A useful (but optional) thing to do at this point is to define the structures representing the data your store objects will contain. Most modeling tools allow you to specify attributes for your store data that can be used later during the E-R modeling process. These are often termed data structures or something similar, and correspond roughly to entities in E-R diagrams and tables in a relational database design.

Often, you can determine attribute-level information from source documents and forms provided by your client or through user interviews. What you want to do is find out as much about the information the system will store, as early as possible. Enumerating your database attributes early on will save you time later.

The task of adding data structure definitions to a business process model usually has two parts : First, define the data structures; second, associate data structures with store objects.

Begin by adding three data structuresCALL, LEASE, and TENANTto your existing model (Figure 5-8).

Once you've added all three data structures, the next step is to define their attributes. In some tools, this can be done in one step; in others, it takes multiple steps. Figure 5-9 illustrates the process of adding data structure attributes.

Let's now set up the attributes for each of the data structures you defined earlier. Add these elements to the CALL data structure:

• Call Number

• Call DateTime

• Property Number

• Call Description

Add these attribute elements to the LEASE data structure:

• Lease Number

• Tenant Number

• Property Address

• Property City

• Property State

• Property Zip

• Property Addition

• Property Bedrooms

• Property LivingAreas

• Property Bathrooms

• Property GarageType

• Property SchoolDistrict

• Property Deposit

• Property Rent

• Property Range

• Property Refrigerator

• Property Dishwasher

• Property CentralHeat

• Property CentralAir

• Property GasHeat

• Property PrivacyFence

• Property LastSprayDate

• Property LastLawnDate

• Lease BeginDate

• Lease EndDate

• Lease MovedInDate

• Lease MovedOutDate

• Lease Rent

• Lease PetDeposit

• Lease RentDueDay

• Lease LawnService

Add these elements to the TENANT data structure:

• Tenant Number

• Tenant Name

• Tenant Employer

• Tenant EmployerAddress

• Tenant EmployerCity

• Tenant EmployerState

• Tenant EmployerZip

• Tenant HomePhone

• Tenant WorkPhone

• Tenant ICEPhone

• Tenant Comments

Information such as this may come directly from lease applications, tenant records, and the like. Note that you're not attempting to normalize your data at this point. That comes later. For now, you just want to model, as closely as possible, the real-world objects with which your system will interact.

Notice that each attribute we add is prefixed with a store name. This is a good convention because these stores will later evolve into tables in the physical database. Doing things this way will likely help us during the E-R modeling stage.

Once you've set up your data structures, you're ready to link them to your store objects (Figure 5-10).

Now let's link your data structures with their corresponding store objects. Link the CALL data structure to the CALL store object, the TENANT data structure to the Tenant store and the LEASE data structure to the LEASE store object.

Once your data structures are linked to their corresponding stores, you're finished with modeling the business processes associated with leasing rental properties. The next step is modeling the entity relationships necessary to service the business process model you just built.

Before you're ready to begin, though, you need to save the business process model you just defined to disk. If your tool has the option of adding your model to a repository for reuse in other models, save it to the repository as well. This will likely make creating E-R and logical data models easier down the road.