Process Rules

 < Day Day Up > 

Along with the business process mapping and the defining of participant roles and responsibilities, the project's analyst should capture all of the business rules underlying the now documented process. Just as workflow steps, task assignments, and customer deliverables are all part of the framework that governs a business process, each process has its decision points and associated approval workflows. If automated systems are to be employed, approval rules must be explicit so that the rule-based engines in these systems may be appropriately programmed for use within the process. In our solution selling example, the process approval rules include the following:

  • Sales and BU leadership approve targeted prospects

  • Sales leadership approves contact person and process for initial prospect contact

  • Consultants must inform sales management when they contact an existing client or targeted prospect concerning a new opportunity

  • Assigned solution selling team (made up of sales and consultants as the case may be) develops the initial opportunity analysis

  • Appropriate sales/delivery team deals with the prospect on the problem statement

  • Sales and finance management qualify the prospect

  • Sales, delivery, and finance management approve pricing and the proposal going to the prospect

  • Sales, finance management, and legal sign off on the contract before it goes to the prospect

  • Delivery drives the kickoff process with the support of sales

Such rules may direct the flow of information from one process stakeholder to the next and hence influence the overall design of the process's underlying IT platform. Similarly, when a process calls for the calculation of values or other data manipulations, there could be any number of business rules associated with these functions within the process.

Yet another consideration in process mapping and subsequent design is the rules governing stakeholder access. Depending on the sensitivity of and legal restrictions placed upon information employed by a particular process, the enterprise must exercise control over employee and customer access rights. In a fairly open corporate culture, where the content of a particular knowledge base is generally free of legal and operational concerns, access rights and individual user profiles may be broadly defined. In many instances, however, rigorous access rules are required. During the mapping process, the IT project team will collect access requirements and build standard user access profiles as need be. In the case of the HG & Co. consulting firm, solution selling data, though highly confidential to the outside world, is readily shared within the organization. The firm therefore employs rather modest access rules:

  • Sales and delivery teams will have full access to all enabling systems, including the sales force and professional services administration systems as needed

  • Sales and delivery teams will have full access to all data, templates, tools, etc., via the intranet and the professional services administration system portal

  • Modeling templates will retain individual employee confidentiality concerning salaries, etc., to the extent possible, while providing sales and delivery teams with the information they require to scope and commit to projects

Note the clear and unambiguous implications of these rules for the eventual design of an enabling IT platform. Your system's access rules may be much more complicated, especially if they involve content delivery to customers who reside outside the perimeter of your information security firewall. In most instances, you will want to involve both those with fiduciary responsibility for the data and the enterprise's information security officer in deliberations concerning access controls.

 < Day Day Up > 

The Hands-On Project Office(c) Guaranteeing ROI and On-Time Delivery
E-Commerce Security: Advice from Experts (IT Solutions series)
EAN: 2147483647
Year: 2006
Pages: 132 © 2008-2017.
If you may any questions please contact us: