Evaluating Enterprise Software - Business Process or Feature/Function-Based Approach? All the above, Perhaps? Part Two
Enter The Business Processes-Based Approach
Recently, there has been much noise created about the appropriateness of evaluating software by asking vendors to complete (and periodically update) the large feature and function criteria-based requests for information/proposal (RFI/RFP) documents. Namely, some pundits and vendors have begun to belittle selecting software in the supposedly "archaic" way through functions and features. Contrary to that, they would rather sell "business processes" or "solutions," further confusing the already overwhelmed customer. The nagging doubts and questions like "Have we been selecting software the wrong way all this time?!" naturally abound.
The other side of the medal comes from exactly the same dismayed prospects, who after their initial confusion and subsequent sobering up, emphasize the fact that they always tend to come back to the "good old" features/functions checkup at the end of the day. In other words, it always comes back to whether some functions can be performed or not, regardless of whether they are classified within for example, the order-to-cash process, or merely within the traditional "horizontal" sales, manufacturing, or financial modules. Even one analogy was quoted with that regard by a prospect "So, if I go to that 'process selling' vendor and say I need a place to stay,' I should be satisfied with its offer of a home, sight unseen, without regard to the number of bedrooms, bathrooms, etc.?! No buyer of enterprise software will accept a vendor's blanket description of an order-to-cash or procure-to-pay solution, as some vendors choose to call their products of late, without looking under the hood. Software buyers still have to define their needs in terms of functions and features."
Additionally, vendors will also suggest that the processes available in their software solutions incorporate the best practices of the industry. Consequently, clients who do not accept these processes "as is," are intimidated by rejecting these practices, appearing not to be interested in improvements and state-of-the-art solutions. For unprofitable companies, the panacea of best practices may inhibit them from exploring what the software really has to offer.
Hence, as a backfire, the users often suspect that vendors that preach too much about solutions and processes are trying to obfuscate the facts that they might not really have the functional wherewithal. Namely, coincidence or not, the unwillingness to compete in a feature/function manner typically comes from the vendor that has not been known as a force in the market it is trying to crack. On the other hand, some vendors that are well-known for their broad and deep functional strengths, but that also support numerous business processes and vertical industry solutions, typically do not have qualms about filling the functional RFI (well, they will have grumbled after seeing the large document, which is only human).
There is certainly room to ask the fundamental question of whether the traditional practice of RFI/RFP-based selection processes has been adequate to the task of selecting complex systems. The record indicates there is much room for improvement. In essence, for complex selections like the case of enterprise applications, the human-machine combination has to work together to drive the solution. Both sides have to be understood and complement each other in the process. It is easy for the human to be overwhelmed, or simply run out of time, and the machine interface and engine to be inadequate to the task requiring expert and empirical knowledge. This is especially true given that the software selection process is typically an iterative, changing process in terms of requirements and priorities. However, the results must benefit the process if human and machine can function effectively together to process information and avoid the pitfalls of past selection processes.
This is Part Two of a three-part note.
Part One presented an overview.
Part Three will discuss the use of knowledge bases and make user recommendations
The Value of Combining Both Methods
If vendors have their say, as we should expect, each will want to show its software in the best light for the products. In general, that will fall into the following two approaches, 1) focusing on business processes or 2) focusing on features and functions. Proponents of both approaches will cite reasons why their approach is the "right way." Does it make a difference at all, or maybe they both have valid points, and the truth is somewhere in a middle? To answer this question, let us see where horizontal functional modules and business processes come from. Checking out most vendors' sites, under their "solutions" or "products" tabs, one will typically be able to drill down to both vertical solutions (e.g., automotive, electronics, food & beverage, etc.), sometimes to business process-based solutions (e.g., design-to-produce, source-to-settle), but always to horizontal functional modules (e.g., general ledger, accounts payable, procurement, engineering and design, shop floor control, etc.).
The reasons for grouping functions and features horizontally are numerous, but the first one would be the traditional staff's specialization into different functional areas. It is often unreasonable to expect a financial expert who knows the nitty-gritty of generally accepted accounting practice (GAAP) to know equally well the concepts of different manufacturing environments and consequent different planning and execution techniques, which should be the fortes of production planners and production engineers. Not to mention the differing expert knowledge of design engineers, procurement personnel, marketing managers, service staff, and so on. Having to pour through a melting pot of functions and features without any stratification runs to the risk of overlooking critical elements as to the way a company does business.
For that reason, first application software instances (and many of the still up-and-coming ones) have been conceived in a functional silos way—i.e., different functional experts have created the functional specs they have deemed essential for the software to exhibit. As a result, many of today's legacy systems that are still in use happen to cover individual functional modules (e.g., asset management or payroll), which are nowadays considered islands of automation.
Starting with the late 1980s and throughout the 1990s, ERP systems have attempted to group these functional islands into a more integrated, cohesive whole. Consequently, the RFI documents have traditionally mirrored that functional modular approach, given that within any vendor's organization, even nowadays, these documents still have to be passed through several functional experts' hands, in order to be answered to. Even during the pre-sales software demonstrations, vendors still have to bring several experts focusing mainly on their peculiar functional area. This is particularly true for the large monolithic tier one ERP vendors' products, where a basic module within financial accounting seems more intricate than the US Federal and State Tax Code.
While vendors may find it easier to homogenously group features into modules, client personnel typically must still wade through their specific area of expertise. Consequently, the traditional function/feature-oriented RFI facilitates this analysis. However, this does leave open the issue of how a client's particular function and feature requirements will be satisfied in a vendor's particular module. Through a cooperative discovery process, the client and vendor need to jointly define this mapping.
Influence of Global Competition and the Internet
Conversely, ever since the 1980s, businesses have been subject to increased global competition, resulting in a pressure to lower production costs, improve product performance and quality, increase responsiveness to customers and shorten product development and delivery cycles. Furthermore, globalization has greatly increased the scope and complexity of multinational manufacturing organizations. Therefore, companies have long been urged to develop or purchase and implement software applications to automate their business processes, leverage their transnational data stores in order to make more informed decisions, and ultimately, decrease operating costs. Companies realized the need to be able to react rapidly to change due to increasing competition, deregulation, globalization, and mergers and acquisition activity.
Moreover, the second half of the 1990s also marked a dramatic and fundamental shift in the enterprise applications market with the emergence of the Internet as a viable platform for business-to-business (B2B) e-commerce transactions. The transition of core business processes to the Internet has been a primary driver for continued, albeit slowed down, deployment of enterprise applications use in the 2000s. The new generation of enterprise systems has become more customer-focused and has extended beyond the enterprise through interaction and collaboration with business partners. The key to the Internet-driven, dynamic trade environment is agility, which is where traditional ERP packages have stumbled in the past.
Thus, business processes must be enabled across the artificial boundaries of disparate applications and of the four walls of the enterprise that must work together to support business processes. This paradigm shift has required everyone to look outside their functional silo mindsets and to discern how their actions affect their internal and external customers. The next generation of application architectures also must address the reality that business processes cross application boundaries. The architecture will need to provide business process integration, application integration, and application extension in order to allow companies to realize the full potential of their current applications (see What's Wrong With Application Software? Business Processes Cross Application Boundaries).
Hence, the need for providing business process-oriented solutions has largely been a virtue made out of necessity—it has definitely not come from the goodness of vendors' hearts and their proactive attention to customers' needs, or from some analyst's ingenuity. Therefore, the processes versus functions debate is rather a top-down or a bottom-up discussion. Business processes are made up of a series of steps that are each, in turn, composed of a set of features and functions. In other words, a process is a series of functions tied up by a workflow. No matter if you start at the top or the bottom, you must look at both ends to see if the software works for you. A business process goes from steps A to Z but to work, all the functions that make up the steps A to Z must be in place. It is a matter of packaging and presentation.
Business Process Success Requires the Right Functions
That is particularly the case with so called "fatal flaws," which are missing functions and that may make it extremely difficult, if not impossible, for the application software to run the physical business (see Find The Software's Fatal Flaws To Avoid Failure and The Fatal Flaws for Process Manufacturers). If we list all the things that enterprise application software has to do, we typically get a very long list. The reality is that most application products that claim to serve a specific need (SCM, CRM, ERP, etc.) do most of the things on the list. But every business has a few essential requirements that do not appear in some or most products, and these requirements are vital to your success, and are thus non-negotiable. These are your fatal flaws. The business does not have flaws; the software packages have flaws relative to your specific needs.
The fatal flaws are most often found in application areas but can also appear in technology areas, but a more common source for fatal flaws is industry standard business practices. For example, all businesses buying and selling in the meat industry use a concept called "catch weight" (inventory is carried by both the package units and their associated varying weight). If you are in the meat industry and your applications do not support catch weight, how do you conduct business? As another example, you may do business with a very large and powerful customer (the big three auto manufacturers, larger retailers, etc.) they may dictate how business is conducted. If your applications cannot accommodate the demands of these large customers, e.g., General Motors or Wal-Mart, you have fatal flaws. Even if you do not need the catch weight functionality, you may have peculiar units of measures (UOM) and UOM conversion requirements. Or, you may use unique methods for determining product yields. You may have special governmental reporting requirements, which are all examples of non-negotiable fatal flaws.
Thus, if one fatal flaw step within the business process is missing or is not appropriate for your needs, the entire business process will likely not work for you. The point is that for the meat packing prospect, the "catch weight" feature needs to be accounted for, whether it will be in a horizontal modular manner (e.g., under inventory management, master data/units, or elsewhere), or specified somewhere within, for example, the "order-to-delivery" process. Similar would hold true for e.g., the "release accounting" functionality for an automotive OEM supplier, regardless of whether it will be specified within the traditional cost accounting or invoicing module or within a step of a trendier "procure-to-pay" business process.
In any case, be very careful not to overlook this essential functionality somewhere within the process-based solutions touted by vendors. It may appear that finding fatal flaws should be easy, but it is not always so. Prospects' staff knows the business and therefore knows what is required. Namely, since they work there everyday what the business needs may be considered common practice and part of any software product. What the people inside the company think is a common business practice across the industry may not be so at all. The identification and evaluation of key needs is often a source of problems, since hardly any company has ever fully evaluated the entire product that they were buying—time does not permit such a complete evaluation. Also, reality says that people spend more time looking at functions they feel comfortable with, not the ones that are difficult.
Based on the above, one could then conclude that only ensuring that the fatal flaws have been addressed should suffice for painless performance of the selected software in live environment. However, there are at least several hundred other less important functional nuggets within the project scope, which are nevertheless important. The lack of these will not necessarily put you out of business, but will make practices (the actual way the things are done in your business) awkward and your staff miserable, resentful and even want to sabotage the system (see Programs, Processes and Practices: Planning Implementations and Evaluating Systems). For example, not natively supporting the three-way invoice matching practice will require either a costly system modification or a work around outside your software system that supports only two-way matching. A similar example would be if you need an account receivable (AR) module in an ERP solution to invoice customers, receive payments, and post to correct entries to the general ledger, but without the provision for unique use of factoring so that you can establish credit limits based on these factored balances.
In fact, the fatal flaws and their less important functional counterparts should be treated in a manner similar to the ABC classification method of managing inventory. Namely, while the stringent attention (e.g., more frequent cycle counting, economic order quantities (EOQ), or appropriately higher safety stock levels) should be paid to the critical, show-stopping "A" items, some sort of less stringent attention should be applied to the "B" and "C" items (e.g., statistical inventory control [SIC], backflushing, etc.). Still, these need to be controlled accordingly, since, at the end of the day, an out of stock widget will stop the production line as equally as a missing critical "A" item.
The advantage of the traditional RFI approach is that your basic "everyone needs this" functionality is typically already documented and available from a software selection service. It is a simple matter of reviewing a list to confirm the necessity of the function or feature. For example, it is commonly known what a general ledger does. Do you need to take the time re-document what already exists in the literature? Of course not. More importantly, the traditional approach allows clients to focus their attention on the critical aspects of their business. What makes the company unique in the marketplace? Why do customers continually go back to the company to place orders? What is the company's competitive advantage? These are the "must have" functions that a vendor's software must satisfy successfully and whose oversight can be the fatal flaws.
SOURCE :http://www.technologyevaluation.com/research/articles/evaluating-enterprise-software-business-process-or-feature-function-based-approach-all-the-above-perhaps-part-two-17095/
Recently, there has been much noise created about the appropriateness of evaluating software by asking vendors to complete (and periodically update) the large feature and function criteria-based requests for information/proposal (RFI/RFP) documents. Namely, some pundits and vendors have begun to belittle selecting software in the supposedly "archaic" way through functions and features. Contrary to that, they would rather sell "business processes" or "solutions," further confusing the already overwhelmed customer. The nagging doubts and questions like "Have we been selecting software the wrong way all this time?!" naturally abound.
The other side of the medal comes from exactly the same dismayed prospects, who after their initial confusion and subsequent sobering up, emphasize the fact that they always tend to come back to the "good old" features/functions checkup at the end of the day. In other words, it always comes back to whether some functions can be performed or not, regardless of whether they are classified within for example, the order-to-cash process, or merely within the traditional "horizontal" sales, manufacturing, or financial modules. Even one analogy was quoted with that regard by a prospect "So, if I go to that 'process selling' vendor and say I need a place to stay,' I should be satisfied with its offer of a home, sight unseen, without regard to the number of bedrooms, bathrooms, etc.?! No buyer of enterprise software will accept a vendor's blanket description of an order-to-cash or procure-to-pay solution, as some vendors choose to call their products of late, without looking under the hood. Software buyers still have to define their needs in terms of functions and features."
Additionally, vendors will also suggest that the processes available in their software solutions incorporate the best practices of the industry. Consequently, clients who do not accept these processes "as is," are intimidated by rejecting these practices, appearing not to be interested in improvements and state-of-the-art solutions. For unprofitable companies, the panacea of best practices may inhibit them from exploring what the software really has to offer.
Hence, as a backfire, the users often suspect that vendors that preach too much about solutions and processes are trying to obfuscate the facts that they might not really have the functional wherewithal. Namely, coincidence or not, the unwillingness to compete in a feature/function manner typically comes from the vendor that has not been known as a force in the market it is trying to crack. On the other hand, some vendors that are well-known for their broad and deep functional strengths, but that also support numerous business processes and vertical industry solutions, typically do not have qualms about filling the functional RFI (well, they will have grumbled after seeing the large document, which is only human).
There is certainly room to ask the fundamental question of whether the traditional practice of RFI/RFP-based selection processes has been adequate to the task of selecting complex systems. The record indicates there is much room for improvement. In essence, for complex selections like the case of enterprise applications, the human-machine combination has to work together to drive the solution. Both sides have to be understood and complement each other in the process. It is easy for the human to be overwhelmed, or simply run out of time, and the machine interface and engine to be inadequate to the task requiring expert and empirical knowledge. This is especially true given that the software selection process is typically an iterative, changing process in terms of requirements and priorities. However, the results must benefit the process if human and machine can function effectively together to process information and avoid the pitfalls of past selection processes.
This is Part Two of a three-part note.
Part One presented an overview.
Part Three will discuss the use of knowledge bases and make user recommendations
The Value of Combining Both Methods
If vendors have their say, as we should expect, each will want to show its software in the best light for the products. In general, that will fall into the following two approaches, 1) focusing on business processes or 2) focusing on features and functions. Proponents of both approaches will cite reasons why their approach is the "right way." Does it make a difference at all, or maybe they both have valid points, and the truth is somewhere in a middle? To answer this question, let us see where horizontal functional modules and business processes come from. Checking out most vendors' sites, under their "solutions" or "products" tabs, one will typically be able to drill down to both vertical solutions (e.g., automotive, electronics, food & beverage, etc.), sometimes to business process-based solutions (e.g., design-to-produce, source-to-settle), but always to horizontal functional modules (e.g., general ledger, accounts payable, procurement, engineering and design, shop floor control, etc.).
The reasons for grouping functions and features horizontally are numerous, but the first one would be the traditional staff's specialization into different functional areas. It is often unreasonable to expect a financial expert who knows the nitty-gritty of generally accepted accounting practice (GAAP) to know equally well the concepts of different manufacturing environments and consequent different planning and execution techniques, which should be the fortes of production planners and production engineers. Not to mention the differing expert knowledge of design engineers, procurement personnel, marketing managers, service staff, and so on. Having to pour through a melting pot of functions and features without any stratification runs to the risk of overlooking critical elements as to the way a company does business.
For that reason, first application software instances (and many of the still up-and-coming ones) have been conceived in a functional silos way—i.e., different functional experts have created the functional specs they have deemed essential for the software to exhibit. As a result, many of today's legacy systems that are still in use happen to cover individual functional modules (e.g., asset management or payroll), which are nowadays considered islands of automation.
Starting with the late 1980s and throughout the 1990s, ERP systems have attempted to group these functional islands into a more integrated, cohesive whole. Consequently, the RFI documents have traditionally mirrored that functional modular approach, given that within any vendor's organization, even nowadays, these documents still have to be passed through several functional experts' hands, in order to be answered to. Even during the pre-sales software demonstrations, vendors still have to bring several experts focusing mainly on their peculiar functional area. This is particularly true for the large monolithic tier one ERP vendors' products, where a basic module within financial accounting seems more intricate than the US Federal and State Tax Code.
While vendors may find it easier to homogenously group features into modules, client personnel typically must still wade through their specific area of expertise. Consequently, the traditional function/feature-oriented RFI facilitates this analysis. However, this does leave open the issue of how a client's particular function and feature requirements will be satisfied in a vendor's particular module. Through a cooperative discovery process, the client and vendor need to jointly define this mapping.
Influence of Global Competition and the Internet
Conversely, ever since the 1980s, businesses have been subject to increased global competition, resulting in a pressure to lower production costs, improve product performance and quality, increase responsiveness to customers and shorten product development and delivery cycles. Furthermore, globalization has greatly increased the scope and complexity of multinational manufacturing organizations. Therefore, companies have long been urged to develop or purchase and implement software applications to automate their business processes, leverage their transnational data stores in order to make more informed decisions, and ultimately, decrease operating costs. Companies realized the need to be able to react rapidly to change due to increasing competition, deregulation, globalization, and mergers and acquisition activity.
Moreover, the second half of the 1990s also marked a dramatic and fundamental shift in the enterprise applications market with the emergence of the Internet as a viable platform for business-to-business (B2B) e-commerce transactions. The transition of core business processes to the Internet has been a primary driver for continued, albeit slowed down, deployment of enterprise applications use in the 2000s. The new generation of enterprise systems has become more customer-focused and has extended beyond the enterprise through interaction and collaboration with business partners. The key to the Internet-driven, dynamic trade environment is agility, which is where traditional ERP packages have stumbled in the past.
Thus, business processes must be enabled across the artificial boundaries of disparate applications and of the four walls of the enterprise that must work together to support business processes. This paradigm shift has required everyone to look outside their functional silo mindsets and to discern how their actions affect their internal and external customers. The next generation of application architectures also must address the reality that business processes cross application boundaries. The architecture will need to provide business process integration, application integration, and application extension in order to allow companies to realize the full potential of their current applications (see What's Wrong With Application Software? Business Processes Cross Application Boundaries).
Hence, the need for providing business process-oriented solutions has largely been a virtue made out of necessity—it has definitely not come from the goodness of vendors' hearts and their proactive attention to customers' needs, or from some analyst's ingenuity. Therefore, the processes versus functions debate is rather a top-down or a bottom-up discussion. Business processes are made up of a series of steps that are each, in turn, composed of a set of features and functions. In other words, a process is a series of functions tied up by a workflow. No matter if you start at the top or the bottom, you must look at both ends to see if the software works for you. A business process goes from steps A to Z but to work, all the functions that make up the steps A to Z must be in place. It is a matter of packaging and presentation.
Business Process Success Requires the Right Functions
That is particularly the case with so called "fatal flaws," which are missing functions and that may make it extremely difficult, if not impossible, for the application software to run the physical business (see Find The Software's Fatal Flaws To Avoid Failure and The Fatal Flaws for Process Manufacturers). If we list all the things that enterprise application software has to do, we typically get a very long list. The reality is that most application products that claim to serve a specific need (SCM, CRM, ERP, etc.) do most of the things on the list. But every business has a few essential requirements that do not appear in some or most products, and these requirements are vital to your success, and are thus non-negotiable. These are your fatal flaws. The business does not have flaws; the software packages have flaws relative to your specific needs.
The fatal flaws are most often found in application areas but can also appear in technology areas, but a more common source for fatal flaws is industry standard business practices. For example, all businesses buying and selling in the meat industry use a concept called "catch weight" (inventory is carried by both the package units and their associated varying weight). If you are in the meat industry and your applications do not support catch weight, how do you conduct business? As another example, you may do business with a very large and powerful customer (the big three auto manufacturers, larger retailers, etc.) they may dictate how business is conducted. If your applications cannot accommodate the demands of these large customers, e.g., General Motors or Wal-Mart, you have fatal flaws. Even if you do not need the catch weight functionality, you may have peculiar units of measures (UOM) and UOM conversion requirements. Or, you may use unique methods for determining product yields. You may have special governmental reporting requirements, which are all examples of non-negotiable fatal flaws.
Thus, if one fatal flaw step within the business process is missing or is not appropriate for your needs, the entire business process will likely not work for you. The point is that for the meat packing prospect, the "catch weight" feature needs to be accounted for, whether it will be in a horizontal modular manner (e.g., under inventory management, master data/units, or elsewhere), or specified somewhere within, for example, the "order-to-delivery" process. Similar would hold true for e.g., the "release accounting" functionality for an automotive OEM supplier, regardless of whether it will be specified within the traditional cost accounting or invoicing module or within a step of a trendier "procure-to-pay" business process.
In any case, be very careful not to overlook this essential functionality somewhere within the process-based solutions touted by vendors. It may appear that finding fatal flaws should be easy, but it is not always so. Prospects' staff knows the business and therefore knows what is required. Namely, since they work there everyday what the business needs may be considered common practice and part of any software product. What the people inside the company think is a common business practice across the industry may not be so at all. The identification and evaluation of key needs is often a source of problems, since hardly any company has ever fully evaluated the entire product that they were buying—time does not permit such a complete evaluation. Also, reality says that people spend more time looking at functions they feel comfortable with, not the ones that are difficult.
Based on the above, one could then conclude that only ensuring that the fatal flaws have been addressed should suffice for painless performance of the selected software in live environment. However, there are at least several hundred other less important functional nuggets within the project scope, which are nevertheless important. The lack of these will not necessarily put you out of business, but will make practices (the actual way the things are done in your business) awkward and your staff miserable, resentful and even want to sabotage the system (see Programs, Processes and Practices: Planning Implementations and Evaluating Systems). For example, not natively supporting the three-way invoice matching practice will require either a costly system modification or a work around outside your software system that supports only two-way matching. A similar example would be if you need an account receivable (AR) module in an ERP solution to invoice customers, receive payments, and post to correct entries to the general ledger, but without the provision for unique use of factoring so that you can establish credit limits based on these factored balances.
In fact, the fatal flaws and their less important functional counterparts should be treated in a manner similar to the ABC classification method of managing inventory. Namely, while the stringent attention (e.g., more frequent cycle counting, economic order quantities (EOQ), or appropriately higher safety stock levels) should be paid to the critical, show-stopping "A" items, some sort of less stringent attention should be applied to the "B" and "C" items (e.g., statistical inventory control [SIC], backflushing, etc.). Still, these need to be controlled accordingly, since, at the end of the day, an out of stock widget will stop the production line as equally as a missing critical "A" item.
The advantage of the traditional RFI approach is that your basic "everyone needs this" functionality is typically already documented and available from a software selection service. It is a simple matter of reviewing a list to confirm the necessity of the function or feature. For example, it is commonly known what a general ledger does. Do you need to take the time re-document what already exists in the literature? Of course not. More importantly, the traditional approach allows clients to focus their attention on the critical aspects of their business. What makes the company unique in the marketplace? Why do customers continually go back to the company to place orders? What is the company's competitive advantage? These are the "must have" functions that a vendor's software must satisfy successfully and whose oversight can be the fatal flaws.
SOURCE :http://www.technologyevaluation.com/research/articles/evaluating-enterprise-software-business-process-or-feature-function-based-approach-all-the-above-perhaps-part-two-17095/
0 Responses to "Evaluating Enterprise Software - Business Process or Feature/Function-Based Approach? All the above, Perhaps? Part Two"
Post a Comment