Part One of the two-part series The Post-implementation Agility of Enterprise Systems: An Analysis.
Indeed, leading enterprise resource planning (ERP) systems now offer broad functional coverage which nears best-of-breed capabilities and end-to-end process scope. Other notable evolutions include vertical industry extensions; ever-improving technical architecture; training, documentation, implementation, and process design tools; continual product enhancements; global support; and an extensive list of software, services, and technology partners. A good example might be SAP's application management platform, SAP Solution Manager, which offers improved processes and tools for managing SAP applications portfolios. By providing tools, integrated content, services, and best practices from SAP, this centralized platform aims at helping customers implement, operate, and monitor applications with improved visibility across the entire SAP landscape.
Yet the current state of the market consists of largely "standard, best-practice, configurable" applications; the (often false) assumption is that standard "vanilla" software applications can bring best practices to a business, and be made flexible enough to accommodate the majority of businesses without significant modification. Through the use of complex tables, parameters, and switches, the software can be pre-configured to handle a large number of predetermined, supposedly "flexible" options. But in truth, such commoditized flexibility only means choosing from a list of existing, predetermined options, and if the required option does not exist in the vendor's menu, there is no real flexibility available. For more information, see Commodity Software, Best Practice and Competitive Advantage.
Furthermore, once the options are selected, the flexibility to change any of the options is often nonexistent, or comes at a hefty price. In other words, it might be possible (since almost everything can be achieved in the realm of information technology [IT]), but only by leveraging an army of well-paid consultants and programmers who are glad to oblige any specific customer's requirement. However, the point is to achieve user self-sufficiency, and to leave users feeling as though they can tweak the system to their personal needs, at will.
Moreover, this limited, parameterized configuration approach ironically comes with heavy costs in terms of the increased complexity of software code, which leads in turn to erratic quality, extensive implementation lead times, and difficulties in changing the software once implemented. The issue of flexibility might be solved for an initial implementation, but ongoing business innovation and change is not supported. Software templates and quick implementation tools might help to solve the problem of long implementations arising from complex tables and switches, but they do nothing to address the underlying problem of inflexibility after implementation (see Fast-path Implementations—Are They Good or Bad?).
A key objective of "standard, best-practice, configurable" applications has been to eliminate the need for modifications. While this has been the stated goal (and nirvana) of many user companies, the statistics repeatedly prove that it is not, in fact, how the majority of companies are running their enterprise software in real life. There have been many indications that the majority of ERP customers have modified their systems "quite a lot." The real truth about standard software applications is that very few companies really run them as standard or "as implemented" products, since every business changes constantly, in small ways and large. Successful companies are increasingly taking on new business models and business processes in an ongoing effort to outmaneuver their competition (see What's Wrong With Application Software? Business Changes, Software Must Change with the Business).
These companies have found that there is an inherent conflict between the fluidity and agility with which they want to run their businesses, and the rigidity and control with which their enterprise systems operate. This incompatibility between agile businesses and static, underlying enterprise systems has hampered efforts to change the business effectively and rapidly—changes that are required to capitalize on ever-occurring business opportunities. Whether a company is aggressive or conservative in its adoption of change, change is inevitable and ongoing. Some vendors have recently made attempts to enable some post-implementation flexibility via improved product connectivity and openness, role-based user access and communication, improved analytics and reporting tools, user-definable processes, and workflow modeling (see What Do Users Want and Need?).
However, it is dubious whether and how software originally built for static business environments can accommodate today's indisputably dynamic business environment. The fact is that most current commercial enterprise systems are architecturally imperfect, inflexible, and entrenched in outdated concepts of some pre-implementation flexibility and almost total post-implementation rigidity. The analogies to "pouring concrete over the users' feet" or "being as flexible as a PVC pipe after the glue has set" have become proverbial by now. In other words, the ability to support the user company in staying competitive usually involves working around the system and waiting for the next re-architected release, or completely implementing a redundant system that overrides the base ERP system. In addition to unnecessary time and cost, this leaves companies at a competitive disadvantage because they are continuously suffering from either the opportunity cost of not changing the business, or the operational cost of working around the system—or often a combination of the two. What's more, ironically, the core objectives of installing an ERP system in the first place (best practices, integration, etc.) are themselves eroded over time.
At this stage, we might also want to note that most enterprise systems were designed to cater to the needs of material-centric (material managing or "make, move and maintain") organizations, whose typical system requirements have traditionally been common group-wide process control and reporting systems. For such organizations with centralized control from the head office (and with divisions with similar operations that run under standard procedures and standard reports), current vendors' post-implementation flexibility (or lack thereof) might be enough. In fact, ERP system tables and parameters allow for fairly easily changing or adding new machines, operations, warehouses, and so on.
Some might even say that the key design goal of such manufacturing- and supply chain management (SCM)-oriented environments is control, and that the supporting enterprise systems were designed to resist change (and not only because of architectural inabilities and product design concepts at the time that these products were devised and deployed). In other words, maximized efficiency of processes and enforcement of best practices are often mandated by management. Also, although there might be heavy investment in the material management infrastructure, the information needs (while not necessarily minimal) are mostly aimed at a limited number of users.
Certainly, there are a number of issues working against the complacency of such environments, including increasing globalization, shorter economic cycles, regulatory pressures, acquisitions, consolidations, public offerings, and trading partners' collaboration and agility requirements. Soon, most of us will realize that intelligent implementation is not only about meeting the needs we can see today, but also about the needs we do not even know about yet. Thus, "post-implementation-no-modifications" is one of the most basic (and yet flawed) assumptions made by companies about their enterprise applications. Consequently or not, most enterprise vendors believed the "no modifications" assumption when they architected their products. However, this assumption is basically untrue, since even the largest customers using software from the largest vendors require customization and agility.
From a structural point of view, people-centric organizations often consist of different units or operations, each with their own goals and objectives. The management within each unit has a big need to feel independent, and the underlying enterprise system they use should be tuned towards their own specific needs and requirements. From a geographical point of view, there are all types of scenarios—from organizations with a local or regional structure, to organizations that are spread around a country or continent, or even around the world. All these organizational characteristics have an impact on architectural needs and requirements when it comes to selecting a business information system. In other words, typical system requirements for people-centric organizations include tailored business systems for each unit with different operations, geographies, objectives, etc.—but also the ability to provide a holistic view of the business at the top.
The trick is thus to maximize overall efficiency and reduce overhead by streamlining core competencies and outsourcing non-core activities. Functionality without a sound and flexible technological foundation is often not enough to accommodate requirements related to the organizational characteristics of people-centric organizations. These requirements might include dealing with decentralization and devolved responsibilities of units, diverse demographics of the organization and its users, and different users with different requirements. Again, these environments are collections of a large number of services that are impossible for a single set of individuals to run. Although it is important to set corporate-wide directives, one has to empower the people in each of the service areas, and enable all business managers to have online access to accurate, relevant, and up-to-date information.
One example of dealing with complex requirements involves divisional procurement departments with requisition self-service capability and intrinsic review and approval processes. These might arise from delegated budgets, different authorization rules, different locations, different ways of information access, different types of users, external partners and outsourcing (subcontractors), and many other complicating factors. Furthermore, systems supporting these requirements need to support casual users with a little computing experience, since information needs to be easily accessible by and disseminated to everyone who needs it—at all levels and from remote locations. On the other hand, they have to allow information to be updated directly by those who know it best.
The very nature of these people-centric organizations calls for fluid, project-oriented teams. The makeups of the teams are ever-changing, with skill set requirements and individuals changing frequently. Change comes in many other ways and has to be managed adequately, quickly, and in a qualitative way, and one has to be able to measure, understand, and improve, with accuracy, timeliness, and relevancy in the background. For relevancy, it is important to note that transactions alone do not provide enough depth without analytic and business process context. Also, to complicate things even more, what is relevant to a chief financial officer (CFO) is not necessarily relevant to a project manager—what is relevant to department A is not necessarily relevant to department B, and the information needs of today will not necessarily match the requirements of tomorrow.
Because of these organizational characteristics, people-centric organizations have typically had to invest in a variety of enterprise solutions. One of the facts to be recognized here is that the bigger the organization gets, the more applications and data sources it has to implement. Unfortunately, IT projects have often been relatively piecemeal and unconnected, whereas packaged applications have as a rule enjoyed architectural isolation (whereby integration and ease of change were afterthoughts). Furthermore, until recently, enterprise standards were circumvented or overridden, and their focus was on the individual processes, not on the overall big picture of end-to-end processes (from the supplier's suppliers to the end customer).
Consequently, such organizations have been overloaded by a network of "spaghetti code" and "multiple versions of the truth," depending on the user group (which might consist of human resource [HR] professionals, trading partners, program management, top management, buyers, controllers and accountants, etc.). Yet, for any organization (people-centric or not), adequate information delivery is crucial. As mentioned before, it is all about the accuracy, timeliness, and relevancy of data. Moreover, the well-known "one version of the truth" still has to be presented differently to different constituencies, since no one can change what they are not aware of.
For these reasons, the reporting and analyses information portfolio has to be disseminated, both in a push and pull manner (as required), and in a form appropriate to various audiences. For instance, the finance department speaks in a language of division, budget type, property, credit controller, and so on; but the sales department understands sales person, campaign, channel, market, etc. Furthermore, the operational folks speak in terms of contracts, projects, work orders, and activities, whereas purchasing wants info about suppliers, buyers, requesting employees, cost centers, etc.
Yet, what has been keeping many managers awake at night has been a number of disconnected applications and data sources that do not make sufficient analysis easily available. Not only can business changes not be accommodated quickly enough, but the bad consequence of this is that it might also stop the flow of information altogether, which will make the situation even worse. Finally, when decisions have been made (based on often outdated and unpredictable information), the time it takes to implement the necessary changes will take so long that the next change has already occurred. In other words, implementation times are much longer than the change cycles.
To recap, people-centric or "staff, source, and serve" organizations have more pronounced requirements for complete business support, complex reporting and communication, flexibility, and adaptability. To enable these, one needs a tightly integrated functional system (including solid capabilities for financial management, budgeting, payroll, HR, resource planning, resource deployment, training and skills management, recruitment, estimating and bidding, project follow-up, project control and billing, travelling, time and expense capture, procurement, etc.). And the system must also be architecturally sound. In other words, the system has to be not only a data and transaction repository, but also an application featuring a single data model for the data dictionary (which defines technical attributes about the data fields within an enterprise system's database), business logic, information delivery, and process control— all of these spanning the entire application portfolio. On one hand, the user has to be able to capture all relevant data in multiple ways and transactions have to feature multiple analytical dimensions; on the other hand, data and logic must be more tightly connected so that "intelligent" alterations can be made quickly, easily, and correctly.
Indeed, leading enterprise resource planning (ERP) systems now offer broad functional coverage which nears best-of-breed capabilities and end-to-end process scope. Other notable evolutions include vertical industry extensions; ever-improving technical architecture; training, documentation, implementation, and process design tools; continual product enhancements; global support; and an extensive list of software, services, and technology partners. A good example might be SAP's application management platform, SAP Solution Manager, which offers improved processes and tools for managing SAP applications portfolios. By providing tools, integrated content, services, and best practices from SAP, this centralized platform aims at helping customers implement, operate, and monitor applications with improved visibility across the entire SAP landscape.
Yet the current state of the market consists of largely "standard, best-practice, configurable" applications; the (often false) assumption is that standard "vanilla" software applications can bring best practices to a business, and be made flexible enough to accommodate the majority of businesses without significant modification. Through the use of complex tables, parameters, and switches, the software can be pre-configured to handle a large number of predetermined, supposedly "flexible" options. But in truth, such commoditized flexibility only means choosing from a list of existing, predetermined options, and if the required option does not exist in the vendor's menu, there is no real flexibility available. For more information, see Commodity Software, Best Practice and Competitive Advantage.
Furthermore, once the options are selected, the flexibility to change any of the options is often nonexistent, or comes at a hefty price. In other words, it might be possible (since almost everything can be achieved in the realm of information technology [IT]), but only by leveraging an army of well-paid consultants and programmers who are glad to oblige any specific customer's requirement. However, the point is to achieve user self-sufficiency, and to leave users feeling as though they can tweak the system to their personal needs, at will.
Moreover, this limited, parameterized configuration approach ironically comes with heavy costs in terms of the increased complexity of software code, which leads in turn to erratic quality, extensive implementation lead times, and difficulties in changing the software once implemented. The issue of flexibility might be solved for an initial implementation, but ongoing business innovation and change is not supported. Software templates and quick implementation tools might help to solve the problem of long implementations arising from complex tables and switches, but they do nothing to address the underlying problem of inflexibility after implementation (see Fast-path Implementations—Are They Good or Bad?).
A key objective of "standard, best-practice, configurable" applications has been to eliminate the need for modifications. While this has been the stated goal (and nirvana) of many user companies, the statistics repeatedly prove that it is not, in fact, how the majority of companies are running their enterprise software in real life. There have been many indications that the majority of ERP customers have modified their systems "quite a lot." The real truth about standard software applications is that very few companies really run them as standard or "as implemented" products, since every business changes constantly, in small ways and large. Successful companies are increasingly taking on new business models and business processes in an ongoing effort to outmaneuver their competition (see What's Wrong With Application Software? Business Changes, Software Must Change with the Business).
These companies have found that there is an inherent conflict between the fluidity and agility with which they want to run their businesses, and the rigidity and control with which their enterprise systems operate. This incompatibility between agile businesses and static, underlying enterprise systems has hampered efforts to change the business effectively and rapidly—changes that are required to capitalize on ever-occurring business opportunities. Whether a company is aggressive or conservative in its adoption of change, change is inevitable and ongoing. Some vendors have recently made attempts to enable some post-implementation flexibility via improved product connectivity and openness, role-based user access and communication, improved analytics and reporting tools, user-definable processes, and workflow modeling (see What Do Users Want and Need?).
However, it is dubious whether and how software originally built for static business environments can accommodate today's indisputably dynamic business environment. The fact is that most current commercial enterprise systems are architecturally imperfect, inflexible, and entrenched in outdated concepts of some pre-implementation flexibility and almost total post-implementation rigidity. The analogies to "pouring concrete over the users' feet" or "being as flexible as a PVC pipe after the glue has set" have become proverbial by now. In other words, the ability to support the user company in staying competitive usually involves working around the system and waiting for the next re-architected release, or completely implementing a redundant system that overrides the base ERP system. In addition to unnecessary time and cost, this leaves companies at a competitive disadvantage because they are continuously suffering from either the opportunity cost of not changing the business, or the operational cost of working around the system—or often a combination of the two. What's more, ironically, the core objectives of installing an ERP system in the first place (best practices, integration, etc.) are themselves eroded over time.
At this stage, we might also want to note that most enterprise systems were designed to cater to the needs of material-centric (material managing or "make, move and maintain") organizations, whose typical system requirements have traditionally been common group-wide process control and reporting systems. For such organizations with centralized control from the head office (and with divisions with similar operations that run under standard procedures and standard reports), current vendors' post-implementation flexibility (or lack thereof) might be enough. In fact, ERP system tables and parameters allow for fairly easily changing or adding new machines, operations, warehouses, and so on.
Some might even say that the key design goal of such manufacturing- and supply chain management (SCM)-oriented environments is control, and that the supporting enterprise systems were designed to resist change (and not only because of architectural inabilities and product design concepts at the time that these products were devised and deployed). In other words, maximized efficiency of processes and enforcement of best practices are often mandated by management. Also, although there might be heavy investment in the material management infrastructure, the information needs (while not necessarily minimal) are mostly aimed at a limited number of users.
Certainly, there are a number of issues working against the complacency of such environments, including increasing globalization, shorter economic cycles, regulatory pressures, acquisitions, consolidations, public offerings, and trading partners' collaboration and agility requirements. Soon, most of us will realize that intelligent implementation is not only about meeting the needs we can see today, but also about the needs we do not even know about yet. Thus, "post-implementation-no-modifications" is one of the most basic (and yet flawed) assumptions made by companies about their enterprise applications. Consequently or not, most enterprise vendors believed the "no modifications" assumption when they architected their products. However, this assumption is basically untrue, since even the largest customers using software from the largest vendors require customization and agility.
From a structural point of view, people-centric organizations often consist of different units or operations, each with their own goals and objectives. The management within each unit has a big need to feel independent, and the underlying enterprise system they use should be tuned towards their own specific needs and requirements. From a geographical point of view, there are all types of scenarios—from organizations with a local or regional structure, to organizations that are spread around a country or continent, or even around the world. All these organizational characteristics have an impact on architectural needs and requirements when it comes to selecting a business information system. In other words, typical system requirements for people-centric organizations include tailored business systems for each unit with different operations, geographies, objectives, etc.—but also the ability to provide a holistic view of the business at the top.
The trick is thus to maximize overall efficiency and reduce overhead by streamlining core competencies and outsourcing non-core activities. Functionality without a sound and flexible technological foundation is often not enough to accommodate requirements related to the organizational characteristics of people-centric organizations. These requirements might include dealing with decentralization and devolved responsibilities of units, diverse demographics of the organization and its users, and different users with different requirements. Again, these environments are collections of a large number of services that are impossible for a single set of individuals to run. Although it is important to set corporate-wide directives, one has to empower the people in each of the service areas, and enable all business managers to have online access to accurate, relevant, and up-to-date information.
One example of dealing with complex requirements involves divisional procurement departments with requisition self-service capability and intrinsic review and approval processes. These might arise from delegated budgets, different authorization rules, different locations, different ways of information access, different types of users, external partners and outsourcing (subcontractors), and many other complicating factors. Furthermore, systems supporting these requirements need to support casual users with a little computing experience, since information needs to be easily accessible by and disseminated to everyone who needs it—at all levels and from remote locations. On the other hand, they have to allow information to be updated directly by those who know it best.
The very nature of these people-centric organizations calls for fluid, project-oriented teams. The makeups of the teams are ever-changing, with skill set requirements and individuals changing frequently. Change comes in many other ways and has to be managed adequately, quickly, and in a qualitative way, and one has to be able to measure, understand, and improve, with accuracy, timeliness, and relevancy in the background. For relevancy, it is important to note that transactions alone do not provide enough depth without analytic and business process context. Also, to complicate things even more, what is relevant to a chief financial officer (CFO) is not necessarily relevant to a project manager—what is relevant to department A is not necessarily relevant to department B, and the information needs of today will not necessarily match the requirements of tomorrow.
Because of these organizational characteristics, people-centric organizations have typically had to invest in a variety of enterprise solutions. One of the facts to be recognized here is that the bigger the organization gets, the more applications and data sources it has to implement. Unfortunately, IT projects have often been relatively piecemeal and unconnected, whereas packaged applications have as a rule enjoyed architectural isolation (whereby integration and ease of change were afterthoughts). Furthermore, until recently, enterprise standards were circumvented or overridden, and their focus was on the individual processes, not on the overall big picture of end-to-end processes (from the supplier's suppliers to the end customer).
Consequently, such organizations have been overloaded by a network of "spaghetti code" and "multiple versions of the truth," depending on the user group (which might consist of human resource [HR] professionals, trading partners, program management, top management, buyers, controllers and accountants, etc.). Yet, for any organization (people-centric or not), adequate information delivery is crucial. As mentioned before, it is all about the accuracy, timeliness, and relevancy of data. Moreover, the well-known "one version of the truth" still has to be presented differently to different constituencies, since no one can change what they are not aware of.
For these reasons, the reporting and analyses information portfolio has to be disseminated, both in a push and pull manner (as required), and in a form appropriate to various audiences. For instance, the finance department speaks in a language of division, budget type, property, credit controller, and so on; but the sales department understands sales person, campaign, channel, market, etc. Furthermore, the operational folks speak in terms of contracts, projects, work orders, and activities, whereas purchasing wants info about suppliers, buyers, requesting employees, cost centers, etc.
Yet, what has been keeping many managers awake at night has been a number of disconnected applications and data sources that do not make sufficient analysis easily available. Not only can business changes not be accommodated quickly enough, but the bad consequence of this is that it might also stop the flow of information altogether, which will make the situation even worse. Finally, when decisions have been made (based on often outdated and unpredictable information), the time it takes to implement the necessary changes will take so long that the next change has already occurred. In other words, implementation times are much longer than the change cycles.
To recap, people-centric or "staff, source, and serve" organizations have more pronounced requirements for complete business support, complex reporting and communication, flexibility, and adaptability. To enable these, one needs a tightly integrated functional system (including solid capabilities for financial management, budgeting, payroll, HR, resource planning, resource deployment, training and skills management, recruitment, estimating and bidding, project follow-up, project control and billing, travelling, time and expense capture, procurement, etc.). And the system must also be architecturally sound. In other words, the system has to be not only a data and transaction repository, but also an application featuring a single data model for the data dictionary (which defines technical attributes about the data fields within an enterprise system's database), business logic, information delivery, and process control— all of these spanning the entire application portfolio. On one hand, the user has to be able to capture all relevant data in multiple ways and transactions have to feature multiple analytical dimensions; on the other hand, data and logic must be more tightly connected so that "intelligent" alterations can be made quickly, easily, and correctly.
No comments:
Post a Comment