Sizing solution components for processes

In any estimating method, we rely on baseline assumptions. In the following sections, our estimates assume the following items:

򐂰 All time-based estimates assume that the work is completed by resources at a Level 1 proficiency, as described in 4.1, “Achieving BPM maturity through skills development” on page 100.

򐂰 The term development includes time for collaborative design, solution implementation, and unit testing.

򐂰 All estimates assume that IBM Business Process Manager V7.5 is used to its fullest capability for all solution components, unless specific exceptions are called out and sized individually.

򐂰 Estimates assume that process documentation and analysis is completed to a level of detail equivalent with Playback 0 or Playback 1. This situation means that the Business Process Diagrams including the details (SIPOC analysis) for each step are mostly complete and placeholders can be estimated for the

Business Process Definition

The characteristics that affect the level of effort to construct a Business Process Definition (BPD) are as follows:

򐂰 Number of activities (milestones, subprocesses, and tasks)

򐂰 Number of decisions (splits, joins, and gateways)

򐂰 Number of events (start/end, timer, message, and exception)

򐂰 Number of participant groups (swim lanes)

򐂰 Number of user stories documented in the activities

BPD development work includes the creation of BPD artifacts in Process Designer and all of the configuration of the swim lanes, milestones, events, and activities in each BPD. This work does not include the development work to implement the activities or events with human services, decision services, or other service development in Process Designer. The range in development effort (measured in man-days) required for BPDs of low, medium, and high complexity is illustrated in Table 4-5.

Table 4-5 Range in development effort

When estimating the overall complexity of a BPD, you need some level of detail as to the underlying complexity. Table 4-5 characterizes BPD complexity as a number of steps, decisions, events, and participant groups. The number of steps includes process milestones, subprocesses, and tasks. Decisions and events include any decision gateway or split on the process diagram. Events include start/end events, message events, timer events, and exception events. It helps to assess the relationship between events, gateways, and steps in the process model to get an idea of the number of valid pathways through the process. Is there a clear happy path and few exception paths? Or are there several dozen paths and loops in the process diagram? The latter case might have a high degree of uncertainty or much process complexity and should be reflected in your estimate.

BPD complexity Steps/Activities Decisions/Events Participant groups

Estimate

Low < 10 < 2 < 4 2 - 4

Medium 10 - 15 2 - 5 4 - 8 3 - 6

High 15+ 5+ 8+ 8+

Coaches and Services

Coaches are the user interface windows that allow a human user to participate in a process. Coaches show process data (simple and complex variables) to users and accept input from the user. Users can enter data fields into coaches or act by clicking buttons or other web form controls. There are a number of factors that influence the complexity of a coach, including the relative number of data elements and number of actions a user can take on a coach (Table 4-6). Form field validation on the coach also influences the level of effort required to finish implementing a coach.

Table 4-6 Factors influencing the complexity of a coach

For a non-coach service, there are a series of considerations. They are shown in Table 4-7.

Table 4-7 Considerations for non-coach services Activity/Service/

Service type Typical estimate for each service

Task Service 6 - 12 hours

Data Access Service 6 - 12 hours

Utility Service 6 - 12 hours

Event Service 4 - 8 hours

WebService Wrapper Service 8 - 24 hours Integration Wrapper Service 4 - 8 hours

Initialization Service 4 - 8 hours

Action Service 4 - 8 hours

򐂰 Is there any need for static reports?

򐂰 Are there chart types or visualizations that we do not know how to produce?

򐂰 Is the data being captured/readily available?

Collecting information to answer these and similar questions help you break down the complexity of reports into the categories shown in Table 4-8.

Table 4-8 Report categories

Table 4-8 does not include ancillary functionality such as:

򐂰 Multiple reports per scoreboard

򐂰 Filtering and drill-downs

򐂰 Events/Alerts based upon scoreboard results

Data persistence and business data system of record

It often happens that data persistence and creation of a business data system of record (BSOR) is overlooked during early project estimates. Whether a BSOR is needed might not be known until more details are known. This topic is a good one to discuss during process discovery and should be accounted for in a budgetary estimate. Here are some questions that can help during the early phases of a project:

򐂰 Is there an existing (legacy) BSOR?

For many processes, there already is a system (or multiple systems) that are the “source of truth” for business data. Examples of business data might include customer records, invoices, and purchase orders. In our sample scenario, employee records are maintained in an “HR Database” that serves as the BSOR. For some processes, business data has no formal (or

governed) system of record. The business data might exist in email, Excel Report Number of

򐂰 For each business entity identified in process discovery, where is that information stored today?

򐂰 If there is a BSOR, do other systems integrate with the BSOR today? If yes, how?

򐂰 Has there been mention of needing a “custom database” for business data?

򐂰 If we need to create a BSOR, do other systems need access to this data?

The order of magnitude per BSOR is shown in Table 4-9.

Table 4-9 Order of magnitude per BSOR

System Integrations

Complexity Approach Estimate

Low 򐂰 No requirement for a new

BSOR.

򐂰 Only the process needs access to business data.

Medium 򐂰 A BSOR must be created.

򐂰 Only the process needs access to business data.

Complex 򐂰 A BSOR must be created.

򐂰 Process and ^external

In general, for integrations, use the following criteria to determine the amount of work:

򐂰 The number of systems to integrate.

򐂰 The manner of the integration.

򐂰 The number of integrations per system.

In general, we plan 1 day per integration point and an additional 5 - 15 days per system (providing that direct access can be provided and no prerequisites need to be worked). Factors that affect this type of effort include the following ones:

򐂰 The first integration to any system can double the days to get it done. We call this process the “Handshaking integration”.

򐂰 Does the integration exist in IBM Business Process Manager? (If yes, this integration lowers the estimate.)

򐂰 Does the integration exist for another system? (If yes, this integration lowers the estimate.)

򐂰 What is the number and complexity of the data elements? (The more elements and complex, the higher the estimate.)

򐂰 Can we realize efficiency? (The 100th integration of the same type should take less time than the first.)

򐂰 If the integration team is using IBM Business Process Manager to unit test their integration time increases.

򐂰 This time does not include the creation of the integration on the external system.

򐂰 Java API integrations typically take 50% more time, and more time for ones dealing with binary data (document management, for example).

Other considerations

Other elements that should be considered when sizing and scoping a project include the following elements:

򐂰 Regulatory Compliance

򐂰 BPM Governance

򐂰 Policy regarding testing and change control

򐂰 Infrastructure Considerations

򐂰 Customizations to the BPM platform to support the deployment

򐂰 Notifications/Escalations

򐂰 Non-Process Deliverables: Functionality not in the process tasks, such as