When performing business analysis, specification development, and project planning there are several process improvement fundamentals that I always take into consideration:
1. the business process must be fit for the purpose it is intended:
- Fundamentally it is free from quality defects and steps that add no value to the process
- Its steps are well defined and as straight through as possible
- It manages exceptions and hand-offs with minimal motion
- It follows industry best practices and meets regulatory and compliance requirements
2. the application design and particularly the underlying data models:
- Must support continuous process improvement
- Must support actionable business intelligence and data driven decision making
- Must support regulatory and compliance requirements without burdening the process or the people working within the process
- Must facilitate a regulatory or compliance audit
3. Business processes are difficult to analyze and automate because:
- They are typically slow because there is too much work in process, too much time spent on non-value-add work (e.g. over-lapping internal controls and re-keying of data), and they are rife with exception handling
- They are less visible in nature and have a tradition of individuality and freedom that makes problems harder to identify and fix
- They are characterized by a lack of meaningful and actionable data for decision making
- The computer application supporting the business process does not capture the necessary metrics to support a root cause analysis and continuous process improvement.
- They seldom follow a best practice model
- They often fail to ensure customer privacy or facilitate segregation of duties (e.g. SOX compliance)
4. Business process owners and their staff cannot articulate their needs to the level of detail needed to complete a specification:
- They seldom have sufficient knowledge of the process objectives
- They fail to remember the exception processing which is a real killer
- They do not thoroughly understand the elements of risk mitigation in a project
- The bottom line is that it is the Business Analyst and not the end user that is responsible for ensuring that the computer application will meet the business objectives. therefore he or she should hone their skills on understanding the traditional drivers, typical exceptions, and continuous process improvement requirements, for each step in a business process.
