Solution Assessment and Validation

This article considers the BABOK Knowledge Area, Solution Assessment and Validation, about which there is much confusion and inaccurate information on the Internet.  I have been intrigued by this topic for some time and truly believe it has great potential to deliver significant business value. According to BABOK, the Solution Assessment and Validation Knowledge Area describes tasks performed to ensure that solutions meet business needs and facilitates successful solution implementation. These activities are not just limited to application software, but address a variety of other areas such as business processes, organizational change, outsourcing agreements, and any other component of the solution. The knowledge area consist of six tasks, which are: Assess Proposed Solution Allocate Requirements Assess Organizational Readiness Define Transition Requirements Validate Solution Evaluate Solution Performance Let’s examine three of these areas where significant confusion exists: Assess Proposed Solution, Validate Solution, and Evaluate Solution Performance. The confusion among these areas is amazing. I read one article that described Evaluate Solution Performance as “performing various tests to confirm that the solution meets performance related goals such as response time, availability, and scalability.”  Wow—maybe it is time for IIBA to change the name of this task. Other articles seem to think these goals are all the same. Assess Proposed Solution (Pre Solution Acquisition) According to the BABOK, the purpose of Assess Proposed Solution is to “assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements.”  After requirements have been defined and prioritized, the proposed solution with its set of requirements is analyzed to determine whether the solution will deliver sufficient business value to justify its implementation....

Value Stream Accounting

A recently evolved management accounting model, Value Stream Accounting (VSA), has potential for providing valuable information in a format that encompasses costs as they relate to value streams within an organization.  This approach has the advantage of tying accounting information to lean management concepts and has proven effective in for-profit environments. Before we get into Value Stream Accounting, let’s explore a little history. VSA evolved from cost accounting and lean manufacturing principles. The objective of cost or management accounting is to produce information that can be used to support strategic planning and decision-making to achieve organizational objectives.  That is, management accounting is not about being a watchdog, but is meant to become an integral part of the continuous improvement process.  Traditional accounting based on generally accepted accounting principles (GAAP) provides information that is of little value for lean management and continuous process improvement as it major focus is accurate financial reporting of net income and the balance sheet. Governmental accounting is based on fund accounting that was developed with the objective of providing budget control, not as a tool to become more effective and efficient. In contrast, management accounting has evolved conceptually to meet the needs of Total Quality Management (TQM), continuous improvement, and lean management concepts.  All of these concepts require information on processes and activities within the processes in order to seek improvement strategies.  Managerial accounting was the popular flavor for the 70s and 80s. Through managerial accounting, organizations identified cost centers based on departments, lines, groups of machines, cells, etc., on which they initially charged the direct workforce dedicated to those centers, the amortization of machines,...

ERP: Customization vs. Configuration

Customization is one of the most controversial topics surrounding ERP software.   Most companies start out with the full intention of leveraging plain vanilla, off-the-shelf software when they upgrade, replace or implement a comprehensive Enterprise Resource Planning (ERP) application.  However, as organizations get into implementation details,  requests to make one or more customizations to the software are inevitable. According to a recent report by Panorama Consulting, only 23% of organizations implement vanilla ERP software without customization.  The majority of organizations make heavy or moderate customizations to ERP software as shown in the table below.  According to the same research study, large companies with over $500 million in annual revenue are even more likely to customize their software, as are companies in the aerospace, defense, and government industry verticals. In addition, an organization’s propensity to customize software seems to be at least partially driven by the specific ERP solution being implemented as shown in the table below. ERP Software Vendors Average Rate of Customization   Heavy Customization Moderate Customization Vanilla Implementation SAP 38.40% 40.60% 21.00% Oracle EBS 34.40% 40.00% 25.60% Microsoft Dynamics 32.80% 42.20% 25.00% Tier II ERP Software Packages 23.50% 48.10% 28.40% Whether or not to customize has been debated since ERP systems first came into existence. The controversy around customization is problematic for several reasons. Customization increases the cost, complexity and risk of an implementation and makes it more difficult and more expensive to upgrade software in the future. Customization makes it difficult or sometimes impractical to take advantage of best practices built into the software, which software vendors often spend significant R&D developing and pass onto customers...

Business Rules

This article provides a primer on business rules. Business rules describe in plain language policies for making decisions, formulas for calculations, definitions used in the business, and key facts and assumptions of how the business operates.  Business rules exist whether or not you have an automated system. Business rules are owned by the business and not IT, and not every business rule is implemented in software. Simply stated, business rules are lists of statements that tell you whether you may or may not do something, or give you the criteria and conditions for making a decision. Business rules include corporate policies, government regulations, industry standards (such as accounting practices), and computational algorithms. Below are some examples of some business rules. A past due account is an account that has not been paid in full after 5 business days of the payment due date. Past due accounts are subject to late fees, interest rate increases, and suspension of the customer’s credit limit. Net sale is defined as the total sales price of an order before discounts, allowances, shipping, and other charges. When an order is initiated via the Internet, sales taxes will be calculated by multiplying the net sale amount by the sales tax rate in effect in the state from which the order was placed. Business rules are not software requirements. They exist outside the boundaries of software and therefore should be regarded as an enterprise-level asset. However, business rules often require that specific functionality be implemented to ensure that the system enforces or complies with those rules.  Business rules may be implemented in a variety of ways. The...

Investment in Business Analysis Pays Off Big

Demand for good business analysis skills is high, and for good reason. An investment made in improving business analysis capabilities can have huge payback. Simply stated, organizations that have not developed strong business analysis capability are at a competitive disadvantage. Enterprises with strong business analysis capabilities have achieved many benefits, including: Implemented solutions that meet business needs Increased the ability of the business to adapt quickly to changes Reduced risk, complexity, redundancy Aligned business and IT Enabled re-use and faster time-to-market Presented one face to the business (customer) Increased business value Conversely, studies routinely conclude that poor business analysis is the root cause of many project failures, resulting in, among other things: Incomplete requirements capture and definition Poor strategic alignment leading to an inaccurate business case Solution design that does not deliver requested features and functions Applications that are not what the business needs The International Institute of Business Analysts (IIBA) describes business analysis as “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals.”   IIBA describes business analysis as a discipline, rather than as the responsibilities of a person with the job title of business analyst. According to IIBA, business analysis may be performed by people with various job titles such as systems analyst, process analyst, project manager, product manager, developer, QA analyst, business architect, or consultant, among others. In this article, I may refer to a business analyst but I am actually referring to the discipline of business analysis. Anyone...