You can't turn around in the field of IT today without tripping over "ERP." Enterprise Resource Planning has been around long enough to have expired as a fad and become a reality that looms over everything, from the job market to the major software packages to most of the training available to you. There's no getting away from it.
The problem is, everybody slaps the initials "ERP" on to almost everything, till it's hard to sort out where it really applies. And even a concise definition of ERP has broad implications. What's needed for developers is a perspective that strips away the non-essentials and provides some tactical direction.
Put simply, Enterprise Resource Planning refers to the integration and extension of a business's operational IT systems, with the end goals of making information flow within (and beyond) a company more immediate and dynamic; increasing the usefulness and shelf life of information; eliminating redundancy and automating routine processes; and making information system components more flexible. Departmental boundaries generally become softer, accessibility of data is increased for partner companies and customers, and the company's ability to respond to the marketplace is generally enhanced.
What are ERP's tactical objectives?
If your company is going ERP, then there are probably several driving forces behind the decision, possibly including: the need to increase supply chain efficiency; the need to increase customer access to products or services; the need to reduce operating costs; the need to respond more rapidly and flexibly to a changing marketplace; and the need to extract business intelligence from data over time.
All of this is fine for the decision-makers, but what does it mean to you as a developer? To achieve senior management's objectives above, IT needs to make the following things happen:
- Consolidate the databases. One of the most prominent features of any ERP system is that it is built around a "super-database," or an integrated, all-inclusive data storage system that encompasses all of your company's operational data. The major ERP software packages convert your in-house databases, usually system- or department-specific, into an interfaced conglomeration of thousands of database tables, integrated more tightly than before. Whether or not you convert to a new database platform, the integration of tables across systems and departmental boundaries is a key step in mobilizing for ERP.
- Integrate legacy apps with new development. Most ERP software systems offer all the standard business systems as canned packages, which you can use if you like. But it's probable that you've got some legacy systems that are so specific to your business that they'll need to prevail, even if you implement some of the new stuff. That being the case, you need to reconfigure your legacy software so that it will live productively alongside your new applications.
- Make information flow throughout the company. In the past, your IT systems have always broken data down into "master data" and "transactional data." The relationship between them is simple: transactional data is built out of master data (a purchase order, for instance, is made out of customer information and product information). And master data has tended in the past to be "owned" by a particular department. In an ERP system, the relationship between master data and transactional data remains, but the departmental "ownership" goes away. Most in-house users will have access to most master data, and more transactional data than before, primarily for decision support processes.
- Increase data access beyond the company. For better or worse, the internet is now the tail that wags the dog. Your company is probably no exception! And it's not just about selling products and services over the Web: real-time data access between your company and your partner companies, the economy of web services for distributed systems, and the convenience of web-based interfaces for systems both remote and in-house have made the need for flexible data access a core architectural component in your ERP development.
What do ERP systems look like?
From what we've covered so far, ERP systems take on an overblown "miracle software" fagade: they have to do everything; they have to do it more efficiently than it was done before; and they have to be much easier to modify and extend than ever.
These capabilities aren't as unreachable as you might think. Broken down into clear specifics, your new systems will have these features:
- ERP systems are non-serialized. Most business processes are "hot potato." A handful of data is passed along a chain, from person to person or company to company, until all steps have been completed. In the world of ERP, the potato passing is largely automated, and the people in the processes begin to serve a new purpose - that of making the information feeding the processes more accurate and immediate. The resulting systems pass information in many directions, not just one, serving not only the original business process but feeding real-time information into other processes concurrently.
- ERP systems are dynamic. The flexibility of ERP permits extended decision-making in business processes. The linear Step A - Step B - Step C mindset can go away, permitting a far more dynamic If-Then environment. Your company's IT systems will enable business processes to change direction rapidly when market conditions, customer need or changes in partner relationships demand it.
- ERP systems have many interfaces. One idea that some developers find hard to wrestle with is the idea that applications are no longer bridges between the database and the user; instead, applications are now communications facilitators between systems. Your legacy apps and ERP app components are now more about passing data to other systems, and to users outside your company than they are a means of informing your own staff. In the more "static" pre-ERP universe, people were information processors, so applications informed people. Now, applications inform other systems, and people are decision-makers. So your job in IT is to get those apps interfacing with other systems, as often or more than they interface with people.
- ERP systems are integrated with other systems. See above. Your IT systems' "audience" has greatly expanded. It is no longer a few hundred people staring at monitors in your building. It now includes human users far and wide, by internet, intranet and other paths, and other systems - meaning that your development team needs to become protocol-savvy, to facilitate the many different connections you'll now be needing to make.
How do you achieve this? In a word, architecture. The task of IT is to begin building systems on a new foundation, using a new kind of blueprint. First, adopt the following rule: Business processes define database table relationships; database table configurations drive application components; applications drive interface development.
This hierarchy is powerful and effective, as long as you stick to it. Break away, and start redefining database tables to serve apps, or basing apps on interfaces (two long-standing standards from the old days), and your ERP framework will not bear the weight of it long.
The architecture that makes the data-to-interface hierarchy possible has three tiers, all generalized and all designed with convenient access to the next tier in mind. The foundation is the data tier; your company's databases populate this layer, and a set of generalized (but highly customizable) access components must exist to open this layer to the next one.
That layer is the business tier, where application logic happens. The "guts" of what would be called an "application program" in a more traditional system exist in this layer; however, instead of self-contained, function-specific logic, a business tier is usually inhabited by a great many "components," or re-usable chunks of business process logic that can be reassembled endlessly into many different applications.
Finally, the business layer feeds the next and final tier, the presentation layer. Interface with human beings, other systems, and the Internet happens in this layer. And, like the layers before it, you'll be filling it with modular, reusable components that can be recombined into a wide range of interfaces, riding a broad spectrum of protocols.