After several years (if not decades, even) of painstakingly corralling and setting up all their custom data, objects, tables and whatnot, and making sure that these static and/or dynamic transactional data are secure, many enterprise applications users have realized that the time is long overdue for them to start looking at ways to make their applications more process-savvy.
Companies are increasingly trying to adopt and implement standardized (and yet flexible and easily modifiable) business processes to help their operations run more consistently and smoothly. For example, the chief executive officer (CEO) might decide that as of, say, next month “All customer service cases must be resolved within 24 to 48 hours,” or, “We are going to institute a new sales process for all deals worth over US$100,000.”
However, these business processes often get communicated to employees in an ad hoc and unregulated manner. A process document with instructions may exist on a network file share, but people have not the foggiest idea that it’s there. And some employees might rely on word-of-mouth information from co-workers (so called “tribal knowledge”) to learn the processes for their jobs.
Consequently, standardizing and instituting new business processes can prove challenging for most companies, particularly larger organizations.
Indeed, until recently most enterprise applications have hardly been anything more than glorified databases — they could hold all of the information users may need and allow users to search for records based on various criteria, but they could not really help users to perform the functions of their daily jobs more effectively.
There’s still often no native automation and agility within the system that lets, e.g., a recruiter instantly know when the status of a candidate has changed or when a new position requisition has been entered into the system.
Indeed, when any changes are made somewhere in the organization, users have to remember to notify one another of the change or else rely on others finding the updates on their own. Neither solution is practical in the long term and invites the possibility that the software solution or best practice will not be adopted consistently by all employees at the company.
How can one then build processes into enterprise applications so that users won’t need to, time and again, rely on manual (pedestrian) methods of communication to inform others of changes, increasing the risk that many issues will fall through the cracks?
Introducing Workflow Automation
To that end, a built-in or an external standalone add-on tool (or capability) that can be used to solve the process automation problem is called workflow automation (or workflow management). Some will refer to it as business process management (BPM), and we will shortly try to point out the differences between the two – i.e., workflow and BPM.
Traditional enterprise applications typically feature some built-in functionality, such as a human resource management system (HRMS) or a procurement application, with some capability to tailor the base functionality through parametric configuration options (e.g., via “order types” that entail different mandatory and optional “order steps”) that users have to learn by heart.
To be fair, some enterprise applications have introduced workflow capability into their products to give users some ability to control the process behavior of documents such as an invoice or an engineering specification. But in most enterprise applications workflow is implemented through hard-coding, which means that programmers must develop and maintain the code.
In addition, workflow automation of the typical enterprise application is generally limited to a single document or task routing. This usually means that companies implementing an enterprise application must choose between accepting the vendor’s pre-built business process behavior or paying the vendor dearly to make expensive modifications to accommodate more complex processes, which will then make upgrades either costly or impossible.
In contrast, a specialized workflow tool enhances a single task and/or document routing by providing an integrated capability to include rich user interfaces (UIs), system integration, rule processing and event handling.
Rules are necessary to determine which path users should take next in a process that has multiple possible paths, e.g., an order worth less than US$1,000 does not need manager approval, but over that amount it does. On its part, an example of event handling would be a necessary step after a product recall: a “pull from shelves” notification must be sent throughout the distribution channels.
These capabilities can be pretty powerful, since in general, if users can come up with a standard rule that specifies when a particular event should happen, they can make it happen automatically with workflow. In other words, workflow becomes the magic ingredient that transforms many traditional transactions-capturing applications from a glorified database into fully functional tools that basically everyone in the company should find useful.
Workflow Components
The individual components that make up workflow are rules and associated actions — tasks, field updates, and alerts.
In general, a workflow rule is the main container for a set of workflow instructions. It includes the criteria for when the workflow should be activated, as well as the particular actions that should take place when the criteria for that rule are met. Every workflow rule must be based on a single object that users will choose when they define the rule, as this object then influences the fields that are available for setting workflow activation criteria.
For example, if a user defines a workflow rule for the “Job Application” object in an HR application, he/she will be able to set workflow activation criteria based on the values of fields like “Job Application Number” and “Status”. Users can also set workflow activation criteria based on standard fields, like “Record Owner” or “Created Date”, as well as fields based on the currently active user when a rule is evaluated, such as their “Role” or “Time Zone”.
When a workflow rule is triggered, there are many types of actions that can occur, starting with a workflow task (or step), which assigns a task to a user according to a particular template. Just as in Microsoft Outlook, tasks include information about something that needs to be done by a certain time, such as making a telephone call, creating an order, shipping goods, or paying an invoice. Typically, assigned tasks appear in a user’s “My Tasks” related list on their home tab (or page) and generate reminder messages that pop up when a user logs in.
When an administrator defines a workflow task, he/she provides default values for data fields like “Assignee”, “Subject”, “Status”, “Priority”, and “Due Date” for tasks that are generated by its associated workflow rule. Administrators can also make sure that a notification email is sent to the assignee when a task is automatically generated.
In additon, a workflow field update changes the value of a particular field on the record that initially triggered the workflow rule, while a workflow alert sends an email according to a specified email template. Unlike workflow tasks, which can only be assigned to users of the application, workflow alerts can be sent to any user or contact, as long as they have a valid email address.
A workflow rule can include any combination of these actions when the rule is triggered. For example, one rule might send out an alert and update two fields on a particular record. The action that one workflow rule takes can also trigger the execution of another workflow rule.
Workflow-enabled Applications
Many enterprise applications today come with built-in workflow management capabilities, such as the Salesforce.com Enterprise Edition on-demand customer relationship management (CRM) suite and its on-demand Force.com (formerly Apex) platform, Agresso Business World (ABW) or Exact E-Synergy, to name only some.
Microsoft Dynamics CRM too includes a workflow module that users can use to automate their business processes based on the rules, logic, and actions that they design. Microsoft has revamped the workflow functionality in Microsoft Dynamics CRM 4.0 so that it now uses the Microsoft Windows Workflow Foundation (WF), whereas previous versions of Microsoft Dynamics CRM used their own proprietary workflow engine.
The result of the revised workflow functionality is that users, administrators, and developers can design and create business processes using the workflow tools with new features and a new UI for creating and monitoring the workflow processes.
Windows WF provides a comprehensive programming model, run-time engine, and tools to manage workflow logic and applications. The Microsoft Dynamics CRM workflow UI relieves users and administrators from the need to interact with WF directly. Therefore, users do not necessarily have to understand the underlying workflow technology to create workflow logic in Microsoft Dynamics CRM.
As a recap, a built-in workflow provides a tool to help companies set up and define business process activities (including the proper sequencing) that involved employees can use when working with the enterprise system’s data. Conceptually, one should think of a workflow as an application or service that runs in the background, 24 hours a day, 7 days a week, constantly evaluating the data and the multiple workflow rules in the company’s deployment.
When the workflow service encounters a trigger event, it activates the appropriate workflow rules to run the workflow actions. Typical workflow actions include sending an e-mail message, creating a task, and updating a data field on a record.
By implementing workflow processes in the enterprise resource planning (ERP), supply chain management (SCM) or CRM systems deployments, users can enjoy many benefits, such as:
1. Ensuring that users track and manage their customer data and processes in a consistent fashion — instead of relying on users to remember the appropriate steps for processing data, managers or administrators can create workflow rules that will automatically determine the next required steps and assign activities as necessary;
2. Processing the customer data more quickly so that, for example, new sales leads or customer service requests are assigned and routed immediately upon record creation; and
3. Allowing users to focus on more value adding activities — instead of having to perform a large number of manual repetitive steps.
Workflow vs. BPM
Both Workflow and BPM are systematic approaches and technologies to improve a company’s business processes (and performance). From a business perspective, they are ways to make people, information and computers work together more consistently and efficiently to produce needed results.
For example, a workflow/BPM-enabled application could monitor receiving systems for missing or defective items, or walk an employee through the steps to troubleshoot why an order arrived late or not at all.
Both technologies foster ongoing collaboration between information technology (IT) and business users to jointly build applications that effectively integrate people, processes and information. They provide organizations with the ability to define, execute, manage and refine processes that:
* Involve human interaction (such as placing or approving orders);
* Integrate and work with multiple diverse applications; and
* Handle dynamic process rules and changes, not just simple static flows, (i.e., those flows that enable tasks with multiple choices and contingencies/escalations).
The market for workflow and BPM applications is highly stratified and fragmented, in part because the currently available products stem from different origins. Namely, there are former pure integration vendors or document management/enterprise content management (ECM) vendors that have meanwhile encroached into the BPM space.
The difference between workflow tools and BPM suites is largely a semantic distinction, and the gist of the matter is that a workflow engine is at the heart of BPM suites with process execution capabilities. Also, in most cases vendors who sell applications labeled as BPM are aiming at a bigger scope and more complex projects, with elaborate software supporting even more elaborate methodologies, process defintion and modeling, collaboration methods, and so on.
Features and capabilities are not necessarily the only differences between tools, since usually the products aimed at simpler processes focus strongly on “ease of use.” The designers’ assumption is generally that the users are non-IT experts within the company. Such workflow products might be built around the concept of an intelligent form. Basically, the user develops the workflow by filling in a familiar-looking form (e.g., a “tasks vs. actions” matrix), including the business rules.
Yet the limitations of the simpler workflow tools become evident when they attempt to manage inter-process dependencies amongst several applications, handle complex database integration and handle tasks that partake in larger, more complex processes.
For more information on BPM, see TEC’s earlier articles entitled “Business Process Management: How to Orchestrate Your Business” , “Giving a Business Process Management Edge to Enterprise Resource Planning” and “Business Process Analysis versus Business Process Management.”
Special credit also goes to CIO Magazine’s articles entitled “ABC: An Introduction to Business Process Management (BPM)” and “Making Workflow Work and Flow for You.” Some useful concepts and examples were also adapted from the Salesforce.com’s AppExchange Developer Network (ADN) book entitled “Creating On-Demand Applications with AppExchange: An Introduction” and from the Microsoft Press book entitled “Working with Microsoft Dynamics CRM 4.0.”
Companies are increasingly trying to adopt and implement standardized (and yet flexible and easily modifiable) business processes to help their operations run more consistently and smoothly. For example, the chief executive officer (CEO) might decide that as of, say, next month “All customer service cases must be resolved within 24 to 48 hours,” or, “We are going to institute a new sales process for all deals worth over US$100,000.”
However, these business processes often get communicated to employees in an ad hoc and unregulated manner. A process document with instructions may exist on a network file share, but people have not the foggiest idea that it’s there. And some employees might rely on word-of-mouth information from co-workers (so called “tribal knowledge”) to learn the processes for their jobs.
Consequently, standardizing and instituting new business processes can prove challenging for most companies, particularly larger organizations.
Indeed, until recently most enterprise applications have hardly been anything more than glorified databases — they could hold all of the information users may need and allow users to search for records based on various criteria, but they could not really help users to perform the functions of their daily jobs more effectively.
There’s still often no native automation and agility within the system that lets, e.g., a recruiter instantly know when the status of a candidate has changed or when a new position requisition has been entered into the system.
Indeed, when any changes are made somewhere in the organization, users have to remember to notify one another of the change or else rely on others finding the updates on their own. Neither solution is practical in the long term and invites the possibility that the software solution or best practice will not be adopted consistently by all employees at the company.
How can one then build processes into enterprise applications so that users won’t need to, time and again, rely on manual (pedestrian) methods of communication to inform others of changes, increasing the risk that many issues will fall through the cracks?
Introducing Workflow Automation
To that end, a built-in or an external standalone add-on tool (or capability) that can be used to solve the process automation problem is called workflow automation (or workflow management). Some will refer to it as business process management (BPM), and we will shortly try to point out the differences between the two – i.e., workflow and BPM.
Traditional enterprise applications typically feature some built-in functionality, such as a human resource management system (HRMS) or a procurement application, with some capability to tailor the base functionality through parametric configuration options (e.g., via “order types” that entail different mandatory and optional “order steps”) that users have to learn by heart.
To be fair, some enterprise applications have introduced workflow capability into their products to give users some ability to control the process behavior of documents such as an invoice or an engineering specification. But in most enterprise applications workflow is implemented through hard-coding, which means that programmers must develop and maintain the code.
In addition, workflow automation of the typical enterprise application is generally limited to a single document or task routing. This usually means that companies implementing an enterprise application must choose between accepting the vendor’s pre-built business process behavior or paying the vendor dearly to make expensive modifications to accommodate more complex processes, which will then make upgrades either costly or impossible.
In contrast, a specialized workflow tool enhances a single task and/or document routing by providing an integrated capability to include rich user interfaces (UIs), system integration, rule processing and event handling.
Rules are necessary to determine which path users should take next in a process that has multiple possible paths, e.g., an order worth less than US$1,000 does not need manager approval, but over that amount it does. On its part, an example of event handling would be a necessary step after a product recall: a “pull from shelves” notification must be sent throughout the distribution channels.
These capabilities can be pretty powerful, since in general, if users can come up with a standard rule that specifies when a particular event should happen, they can make it happen automatically with workflow. In other words, workflow becomes the magic ingredient that transforms many traditional transactions-capturing applications from a glorified database into fully functional tools that basically everyone in the company should find useful.
Workflow Components
The individual components that make up workflow are rules and associated actions — tasks, field updates, and alerts.
In general, a workflow rule is the main container for a set of workflow instructions. It includes the criteria for when the workflow should be activated, as well as the particular actions that should take place when the criteria for that rule are met. Every workflow rule must be based on a single object that users will choose when they define the rule, as this object then influences the fields that are available for setting workflow activation criteria.
For example, if a user defines a workflow rule for the “Job Application” object in an HR application, he/she will be able to set workflow activation criteria based on the values of fields like “Job Application Number” and “Status”. Users can also set workflow activation criteria based on standard fields, like “Record Owner” or “Created Date”, as well as fields based on the currently active user when a rule is evaluated, such as their “Role” or “Time Zone”.
When a workflow rule is triggered, there are many types of actions that can occur, starting with a workflow task (or step), which assigns a task to a user according to a particular template. Just as in Microsoft Outlook, tasks include information about something that needs to be done by a certain time, such as making a telephone call, creating an order, shipping goods, or paying an invoice. Typically, assigned tasks appear in a user’s “My Tasks” related list on their home tab (or page) and generate reminder messages that pop up when a user logs in.
When an administrator defines a workflow task, he/she provides default values for data fields like “Assignee”, “Subject”, “Status”, “Priority”, and “Due Date” for tasks that are generated by its associated workflow rule. Administrators can also make sure that a notification email is sent to the assignee when a task is automatically generated.
In additon, a workflow field update changes the value of a particular field on the record that initially triggered the workflow rule, while a workflow alert sends an email according to a specified email template. Unlike workflow tasks, which can only be assigned to users of the application, workflow alerts can be sent to any user or contact, as long as they have a valid email address.
A workflow rule can include any combination of these actions when the rule is triggered. For example, one rule might send out an alert and update two fields on a particular record. The action that one workflow rule takes can also trigger the execution of another workflow rule.
Workflow-enabled Applications
Many enterprise applications today come with built-in workflow management capabilities, such as the Salesforce.com Enterprise Edition on-demand customer relationship management (CRM) suite and its on-demand Force.com (formerly Apex) platform, Agresso Business World (ABW) or Exact E-Synergy, to name only some.
Microsoft Dynamics CRM too includes a workflow module that users can use to automate their business processes based on the rules, logic, and actions that they design. Microsoft has revamped the workflow functionality in Microsoft Dynamics CRM 4.0 so that it now uses the Microsoft Windows Workflow Foundation (WF), whereas previous versions of Microsoft Dynamics CRM used their own proprietary workflow engine.
The result of the revised workflow functionality is that users, administrators, and developers can design and create business processes using the workflow tools with new features and a new UI for creating and monitoring the workflow processes.
Windows WF provides a comprehensive programming model, run-time engine, and tools to manage workflow logic and applications. The Microsoft Dynamics CRM workflow UI relieves users and administrators from the need to interact with WF directly. Therefore, users do not necessarily have to understand the underlying workflow technology to create workflow logic in Microsoft Dynamics CRM.
As a recap, a built-in workflow provides a tool to help companies set up and define business process activities (including the proper sequencing) that involved employees can use when working with the enterprise system’s data. Conceptually, one should think of a workflow as an application or service that runs in the background, 24 hours a day, 7 days a week, constantly evaluating the data and the multiple workflow rules in the company’s deployment.
When the workflow service encounters a trigger event, it activates the appropriate workflow rules to run the workflow actions. Typical workflow actions include sending an e-mail message, creating a task, and updating a data field on a record.
By implementing workflow processes in the enterprise resource planning (ERP), supply chain management (SCM) or CRM systems deployments, users can enjoy many benefits, such as:
1. Ensuring that users track and manage their customer data and processes in a consistent fashion — instead of relying on users to remember the appropriate steps for processing data, managers or administrators can create workflow rules that will automatically determine the next required steps and assign activities as necessary;
2. Processing the customer data more quickly so that, for example, new sales leads or customer service requests are assigned and routed immediately upon record creation; and
3. Allowing users to focus on more value adding activities — instead of having to perform a large number of manual repetitive steps.
Workflow vs. BPM
Both Workflow and BPM are systematic approaches and technologies to improve a company’s business processes (and performance). From a business perspective, they are ways to make people, information and computers work together more consistently and efficiently to produce needed results.
For example, a workflow/BPM-enabled application could monitor receiving systems for missing or defective items, or walk an employee through the steps to troubleshoot why an order arrived late or not at all.
Both technologies foster ongoing collaboration between information technology (IT) and business users to jointly build applications that effectively integrate people, processes and information. They provide organizations with the ability to define, execute, manage and refine processes that:
* Involve human interaction (such as placing or approving orders);
* Integrate and work with multiple diverse applications; and
* Handle dynamic process rules and changes, not just simple static flows, (i.e., those flows that enable tasks with multiple choices and contingencies/escalations).
The market for workflow and BPM applications is highly stratified and fragmented, in part because the currently available products stem from different origins. Namely, there are former pure integration vendors or document management/enterprise content management (ECM) vendors that have meanwhile encroached into the BPM space.
The difference between workflow tools and BPM suites is largely a semantic distinction, and the gist of the matter is that a workflow engine is at the heart of BPM suites with process execution capabilities. Also, in most cases vendors who sell applications labeled as BPM are aiming at a bigger scope and more complex projects, with elaborate software supporting even more elaborate methodologies, process defintion and modeling, collaboration methods, and so on.
Features and capabilities are not necessarily the only differences between tools, since usually the products aimed at simpler processes focus strongly on “ease of use.” The designers’ assumption is generally that the users are non-IT experts within the company. Such workflow products might be built around the concept of an intelligent form. Basically, the user develops the workflow by filling in a familiar-looking form (e.g., a “tasks vs. actions” matrix), including the business rules.
Yet the limitations of the simpler workflow tools become evident when they attempt to manage inter-process dependencies amongst several applications, handle complex database integration and handle tasks that partake in larger, more complex processes.
For more information on BPM, see TEC’s earlier articles entitled “Business Process Management: How to Orchestrate Your Business” , “Giving a Business Process Management Edge to Enterprise Resource Planning” and “Business Process Analysis versus Business Process Management.”
Special credit also goes to CIO Magazine’s articles entitled “ABC: An Introduction to Business Process Management (BPM)” and “Making Workflow Work and Flow for You.” Some useful concepts and examples were also adapted from the Salesforce.com’s AppExchange Developer Network (ADN) book entitled “Creating On-Demand Applications with AppExchange: An Introduction” and from the Microsoft Press book entitled “Working with Microsoft Dynamics CRM 4.0.”
No comments:
Post a Comment