The Value Proposition and Strategy for an Agile Enterprise Systems Vendor
The final building blocks of the agility value proposition of Agresso, one of the world's top five providers of people-centric enterprise resource planning (ERP) solutions, are "business views," which are the result of combining attributes, relations, and rules. Such information delivery is quite user self-sufficient, since different users can define their own hierarchy for viewing information in the database. This is again in sharp contrast to many competitors' greater reliance on third party tools for business intelligence (BI) and reporting. Agresso's architecture and all of the associated embedded BI is maintained in the integrated data model, and is available via a wide variety of reporting and analytics tools.
Part Three of the series Enterprise Systems and Post-implementation Agility—No Longer an Oxymoron?
Background information on Agresso and its product Agresso Business World (ABW) 5.5 can be found in Enterprise System and Post-implementation Agility—No Longer Necessarily an Oxymoron?. How Agresso achieves this agility is covered in How One Vendor Supplies Agility to Post-implementation Enterprise Systems. For information on the opportunity Agresso is addressing, see The Post-implementation Agility of Enterprise Systems: An Analysis and The Modelling Approach to Post-implementation Agility in Enterprise Systems.
One of the most popular ways of accessing data within the Agresso system is by using the "balance table," allowing user-defined views that can aggregate information by specific parameters, time periods, and company divisions across any modules within ABW (users can combine data from Agresso and non-Agresso sources). In broad terms, the process of defining a balance table requires the user to define which attributes are to be used to view the data, together with which amounts are to be reported. The balance table enquiry is linked to the reporting hierarchy, and is generated rapidly. The user can then drill down through the enquiry, taking different paths as appropriate, by defining filter options "on the fly."
Thus, Agresso provides extensive role-based views (or reports, or analyses), increasing the efficiency of information retrieval and the correlating business actions. Users can drill through the integrated information warehouse to underlying transactions, but also to documents and images appended by the Agresso document management system. The integrated Document Archive provides the ability to link transactions or master file information to documents (scanned images, Microsoft Excel workbooks, Microsoft Word documents), and to make hyperlinks to Web pages or any number of other file formats. Document sources can be external to Agresso (such as vendor invoices), or created within Agresso itself (as with the user's own customer invoices), and users can track changes to documents and maintain version control through the "check in/check out" function.
Ad hoc reporting is supported in a variety of ways, including inquiries on transactions, balances, and master file information within the information warehouse. Simple "point and click" technology defines report formats and saves templates as menu options for repeated and shared use, while embedded alerting and drilldowns can be free-format, or guided via links between successive templates. These templates can be exposed in other reporting tools to take advantage of additional functionality. The information delivery framework provides a common reporting platform that consists of the data source (database) layer, the data extraction (query engine) layer, and the data presentation layer, which can render the user interface (UI) in multiple ways.
One way of handling these presentational issues in ABW is to use its reporting engine, called Excelerator, which allows the output to be dynamically surfaced in Excel (or Word), while retaining the underlying financial intelligence. This means that the Excel workbook the tool creates is "live" on the ABW database, so that drilldowns, queries, and modifications are supported and updated on demand, with the latest updated values and figures in the database.
Alternatively, for even more control over presentation, there is Analyzer, which provides a wide variety of graphing options, or "information pages" that allow groupings of favorite reports or inquiries to be displayed as executable options on a start-up page. More traditional production reporting is supported through tools such as Agresso Report Writer, a text-based reporting tool that is well suited for audit reports, or Agresso Report Creator, a graphical reporting tool that provides a Crystal Report-like interface.
This liberal offering of reporting choices aims at catering to all possible user needs and tastes. Namely, whereas casual users will often be happy with web views or template viewers, controllers and accountant will require other, more sophisticated data presentation and manipulation means. The tight integration between information delivery and the underlying data model means that changes to metadata within the model are immediately exposed in the information layer. Operational reporting can be realigned almost immediately with new responsibilities following management reorganization; and by retaining old and new hierarchies, the system can readily support matrix style management reporting.
Owing to this virtually unlimited possibility of reconfiguring system capabilities without having to re-architect the system, Agresso's mission of late has been to change the entrenched (and often false) assumptions of chief executive officers (CXOs), starting with the idea that legacy ERP systems do not have to be replaced or re-architected every five to seven years (and much more frequently in constant change environments). Other assumptions or behaviors that will not be so easy to dispel include a lemming-like predilection for the same, restrictive "usual suspect," "biggest few" ERP choices that currently may deliver some pre-implementation flexibility, but that stop short at post-implementation agility.
Agresso strongly believes—and wants to instill the belief—that this ERP "poison pill" option is an unnecessary and even irresponsible choice, from both a fiduciary and business strategy perspective. Quite to the contrary, post-implementation business agility should be the primary goal of most CXOs in their ERP selection process, and should also be the fundamental goal for fast-paced people- and service-centric businesses.
Consequently, Agresso is launching quite aggressively into North America around the trademarked theme "ERP with NO Expiration Date." The company is targeting professional services and public sector organizations that are characterized by dynamic levels of business change and that can leverage Agresso's experience achieved within its large installation base in the commercial services sector (financial, accounting, insurance, etc.); architecture, engineering, and construction (A/E/C) firms; IT services organizations; and not-for-profit (NFP) and public sector organizations.
As elaborated earlier, these are change-driven people-centric business environments with frequent rescheduling, reorganizations, project go/kill decisions, etc. They have to compete in the industry consolidation landscape (laden with mergers, acquisitions, divestments, etc.), with frequent changes of organizational direction due to compliance or new accounting rules (in other words, due to obsolescence of old practices), while some initial public offering (IPO) pursuers are requiring the "best margin" practice. Agresso's solution (which is based on a coherent architecture that combines the transaction, information, and business process realms without compromise) certainly comes in handy here over traditional ERP platforms. This is particularly true since the latter were architected merely around processing large volumes of transactions, with analytics and business processes being afterthoughts.
To be fair, Agresso is not the only vendor with such a novel and brave approach. In a Technology Evaluation Centers (TEC) article from 2003, some vendors like Ramco Systems were praised for a similar approach with resulting reductions in the time, effort, and cost in building applications (see What's Wrong with Application Software? - A Possible Solution?; What Is It, Why And How Does It Fit Into Your Future). Customizations, which have traditionally been viewed as an undesired practice, thereby become much more sustainable. Also, the high cost of rebuilding applications as technologies change is greatly reduced, since the business process and rules of the application are stored independently from the software code, and can be regenerated onto new architectures. Business changes are also thereby analyzed based on changes to business processes and business rules, and the impact on the application can be assessed; changes can then be incorporated and visualized by the business analysts. Once the business is satisfied with the new application, new application code can be automatically generated.
Furthermore, applications using model-based architectures are built on business processes and rules, which allows business analysts to understand and make customizations to the application without compromising the quality of the application. This also obviates complex switches and parameterized tables for configuring the application with simple changes to rules. Custom applications can be built rapidly for very unique businesses or business functions, and such architectures allow for less complexity in the code and significant automation of software code development, which promises significantly increased application quality.
Notable modifiability and agility has also been reported by the fellow North European vendors Jeeves and IFS (see The Formula for Product Success: Focus on Flexibility and Cooperation and Enterprise Applications Vendor Reverses Fortunes - But Will Perseverance and Agility Be Enough?), and possibly by some Microsoft .NET-centric ERP vendors (see Subtle [or Not-so-subtle] Nuances of Microsoft .NET Enablement). However, without getting into a discussion about which vendor's idea is the best and most revolutionary (allowing modifications via, say, the metadata layer; intuitive macro programming language development environment; and so on), it suffices to say that none of these vendors directly competes within Agresso's target markets, and they might in fact just validate each other's approaches. A bigger threat or hurdle comes from the fact that all these agility messages from intuitive vendors might possibly be diluted by the service-oriented architecture (SOA)-based "magic bullet" messages from larger direct competitors.
As seen in Architecture Evolution: From Mainframes to Service-oriented Architecture, the SOA concept should, in theory, be able to help businesses respond more quickly and cost-effectively to changing market conditions by reconfiguring business processes. It should eventually enable agility, flexibility, visibility, collaboration with trading partners (and between functional and IT departments), and so on, by promoting reuse at the coarser (software component) service level rather than more granular (and convoluted) object levels. In addition, SOA—again, in theory—should simplify "plug and play" interconnection and usage of existing IT assets, including legacy assets.
According to Forrester, from the vantage point of business drivers, the concept should in the long run enable users to adapt their system to processes (and not vice versa), improve system intuitiveness and usability; deliver relevant analytics; connect to external data and services; and leverage readily available best practices and industry knowledge within the vendor repositories. In the technology lingo, SOA should reduce custom coding through configuration; promote open standards to reduce integration costs; enable end user self-sufficiency (meaning no reliance on nerdy programmers); and provide more flexibility to use best-of-breed products (possibly within composite applications). Except for the very last benefit, all these benefits coincide with Agresso's value proposition tenets, which might leave prospective customers at least confused and undecided.
Ironically, although seen as helping heterogeneous and legacy environments rejuvenate themselves, SOA might best function within homogenous domains and contexts, where data and processes are well aware of each other, as in Agresso's case. Lawson has recently embarked on a major SOA-based product rewrite called Landmark, to automatically generate product code (and services) and to avoid the possible SOA traps mentioned above, since the code generator will have all the validation rules and constraints within the scope of the Lawson S3 product (see A New Platform to Battle Software Bloat?).
These provisos aside, we still have a ways to go before the post-implementation change process becomes a solid, controlled process with built-in management and quality, while providing the business user with visualization and evaluation of potential modifications.
To recap, while SOA does facilitate standardization, allow for loosely coupled software components (services) assembly and integration, accommodate customized portal-based presentation, and thus perhaps facilitate integration, it is not a panacea yet. Hence, it is a fallacy to expect that the mere concept will turn rigid products written in ancient code into flexible applications providing analytic information that has not been natively enabled, and similar benefits. To radically change, the underlying product has to be either properly architected from the ground up (as with Agresso, which likes to compare its agility to a chameleon's ability to adapt to the environment), or totally rewritten in new, modern languages and technologies. For more information, see Rewrite or Wrap-around Old Software. Without true modernization of underlying applications, the SOA embellishments will largely be analogous to "putting makeup on a pig."
