By Thomas Kaufmann
Thanks to increasingly affordable processing power, bandwidth, and a greater awareness of the strategic value of automating business functions, many companies have spent years building function-specific applications in all areas of their organization. However, the ability to automate discrete processes— for marketing, finance, sales, or manufacturing, for example— has created its own daunting challenges.
Today, enterprise IT organizations are often charged with maintaining these vast portfolios of data-centric applications—special-purpose, “siloed” systems—many inherited from the user departments themselves. A data-centric application typically embodies a narrow view of its purpose. It stores the data it needs in its own dedicated relational (or proprietary) database management system without regard to how other processes or functions may need or update that data. For instance, think of a Customer Relationship Management (CRM) system that manages call center requests. When a customer calls in with an address change, the rep updates that customer record in the CRM system. However, other systems, such as accounts receivable or order entry, could use that same updated data. Traditionally, that’s meant serial, manual updates of multiple systems—often using cobbled-together, time-intensive, and error-prone processes.
The term “data-centric” shouldn’t be considered derogatory. Data-centric applications have offered tremendous value for decades. Unfortunately, these data-centric applications too often are built on varying standards and platforms (e.g., mainframe or n-tier client/server), suffer from data integrity issues, and don’t integrate well with one another.
While these applications add value by focusing on precise tasks, they typically fail to address the broader business context in which they function. For example, a purchasing application needs to work with—and share data with—other financial systems such as accounts payable or inventory applications. It’s not hard to see what quickly happens when these dedicated, data-centric applications proliferate: redundant data and fragmented processes.
Responding to these challenges, software vendors have created integrated, data-centric applications that shared a common data platform. Enterprise Resource Planning (ERP) is perhaps the best-known example of this approach. As with other data-centric applications, ERP systems are proven to effectively automate repeated, structured transactions. By sharing a common data platform, they vastly simplify data management and improve accuracy. When a procurement manager changes the address of a vendor, there’s no need to change it a second time in a separate accounts payable system.
Although this integration at the data level is a significant improvement, it still uses a data-centric approach and falls short in the increasingly crucial area of managing the overarching business process.
The Process-Centric Application
While integrating at the data level can improve accuracy and yield some modest tactical efficiencies, it doesn’t address the need to automate a business process. Business process automation happens through the rules and roles that live outside the data-centric application. Recognizing this, a growing number of enterprises are seeking to implement process-centric applications that monitor and govern the processes automated by data-centric applications.
Process-centric applications are unconstrained by artificial or arbitrary functional, system, organizational, or enterprise boundaries. They eliminate unnecessary touchpoints and duplicate data entry. In some circles, this is known as Business Process Management (BPM). It is important to note the distinction between BPM and Business Process Re-Engineering (BPR). Typically, in BPR, you totally replace existing legacy applications and redesign processes from scratch. BPR is a discipline that leads to rather drastic, sometimes revolutionary, changes in how a company performs its processes.
By contrast, BPM is evolutionary, adding an intelligent layer of process orchestration based on carefully defined rules to extend and enhance the existing IT portfolio of data-centric applications. The process-centric application goes beyond mere data integration to create a smarter, more efficient process that’s less isolated and restricted. The result is lower risk and higher return.
How Do You Create a Process-Centric Application?
Rather than hard-coding policies directly into each application, a process-centric application often (and ideally) leverages a carefully designed and centrally managed repository of rules—a store of enterprise policies and procedures that any application developer can refer to and reuse. Rule reuse dramatically reduces development and maintenance costs and improves reliability.
Some technologies automatically analyze the business’s data to determine which business rules apply, initiate the appropriate business processes, and prompt users for any additional inputs required. The rules automatically recognize changes such as a different age or account balance, and initiate the appropriate business processes for that change, such as a notification of eligibility for an account upgrade.
Process-centric application technology also typically provides the ability to model, simulate, execute, monitor, and analyze a process. Since business users, not IT staff, are the ones with the process knowledge, those design tools often use an intuitive visual interface while generating the necessary underlying code behind the scenes. While different process-centric development environments can vary, many include these facilities and components:
• Process modeling: Using a shared environment, business and IT users can collaboratively design the business process to be managed. This modeling of processes should be a drag-and-drop visual paradigm that captures the rules, roles, and routings.
• Process analysis: The ability to analyze historical and simulated data to continuously improve processes is an essential feature of process-centric applications.
• Process simulation: A test environment helps simulate a new business process before it goes live to quantify and compare potential for increased service levels and reductions in time, error, and costs.
• Enterprise integration: Many solutions use a Service- Oriented Architecture (SOA) to integrate their various data-centric applications.
• Case management: A smart case-management application helps identify and handle exceptions.
• Content management integration: Most enterprise process applications need the ability to integrate multiple image repositories and document- and content-management systems to manage global policies and processes.
• Portal integration: Businesses turn to Web portal technology to enable collaboration with their trading partners and offer self-service capabilities to customers.
Perhaps the easiest way to get a clear picture of a process-centric application is to look at the following example of a system that handles procurement, fulfillment, and receiving. Note how the application transcends the typical boundaries to automate an inter-departmental process. In this example, an employee requests a flat-panel display for his desktop computer:
1. Employee goes to Web intranet portal and completes form requesting a 22-inch, flat-panel LCD monitor.
2. The application looks up the estimated price of $324, determines which managers need to review and approve the purchase, and routes the request to them. It also can issue reminders to these approvers and even escalate the request to higher-level managers if approval delays arise.
3. Once approval is obtained, the system checks to see if the requested LCD display is available in the IT department’s current inventory on hand.
4. Since no inventory is on hand, the system automatically initiates procurement, checking item availability from an approved vendor list (pre-defined by the purchasing department based on negotiated volume discounts and similar arrangements). It then verifies that the requested item conforms to the company’s IT-approved specifications. If the hardware or vendor is non-standard, the system initiates an exception-handling routine.
5. Assuming the vendor and hardware are approved, a PO is issued and the order placed with the preferred vendor by fax or electronic mail.
6. Since this is a tangible good—not a service—the system uses the appropriate set of rules to receive the item. When the item arrives, the receiving dock team inspects it to ensure it’s the requested model and that there was no damage during shipment. The receiver uses a PC to access the application and enters the acknowledgment of receipt. The system then notifies the requester that the item is available (and asks about delivery preferences).
7. The accounts payable system receives an authorization to pay the vendor according to previously agreed terms.
This, of course, is a simplified example. If there were multiple items from the vendor and some back-ordered items, the system would have to follow rules based on payments for partial shipments. If items were damaged or missing, there would have to be separate sub-processes to handle those situations. It’s easy to see that even a basic business process can quickly become complex when you factor in exceptions and related events.
Conclusion
As businesses continually strive to derive the maximum possible value from their multi-year IT investments, many are finding that overlaying a process-centric layer of rules and logic onto their data-centric applications is a compelling, visionary strategy. By forsaking artificial departmental boundaries and instead focusing on automating processes across functional, organizational, and enterprise boundaries, process-centric applications extend the life of those investments and achieve new levels of efficiency and competitiveness.
Latest Comments
RSS