Table Of Contents
I. INTRODUCTION
D. NETWORK
V. GUIDELINES
Appendix A: NRP for ERP Planning Book
Even now IT-for-ERP infrastructure planning is more art than science. The intent of this document is to focus on fundamental policies, procedures, and concerns that will have a direct impact on whether or not you succeed with an on-time, on-budget, and adequately performing (from an IT point of view) ERP implementation.
The urge to cram a maximum amount of acronyms and discourses about trendy technologies that have recently emerged from laboratories into this paper is hopefully contained. This may be disappointing if your ERP solution is already running on top of a rock-solid and proven IT foundation and you want to find out how to go from leading to bleeding edge.
Those of you in this category are clearly not the intended audience. The intended audience are those of us regular folk who are preparing for an ERP implementation, or have already implemented and still have a ways to go in establishing the aforementioned rock-solid and proven IT practices.
Figure 1: A sampling of the wide array of tier 1 and 2 ERP vendors.
A. Your IT Landscape: Before and After ERP . . .
1. A Double Whammy. Whatever your IT landscape looks like now, it will likely look a lot different after implementing an ERP solution. Why? Most ERP products are intense business applications that happen to use a client/server (typically 3-tier) architecture.
So here we have, on one hand, an ERP product that is probably a lot more complex (and more powerful) compared to your existing business systems, and on the other hand is a client/server application. Client/server computing itself is much more complex, from an IT point of view, than the good old integrated, monolithic host/terminal legacy systems.
2. Critical Vs. Mission Critical. An ERP initiative is possibly the first foray into truly mission critical client/server computing for your company. Even if you have experience in this area, this may be the first time you are dealing with a client/server application that is literally running your core business! The client/server model is daunting because it is comprised of many layers, and many components within each layer. In other words, there is a lot more that can go wrong, and frequently does, with client/server systems. Having said this it should be pointed out that client/server is clearly here to stay and is absolutely required to better align IT with your core business objectives.
Figure 2, Client/Server Complexities: the lack of tight
inter- and intra-layer integration presents critical challenges
to ERP deployment.
It is the inherent client/server complexities that are usually underestimated. Nothing reveals and exacerbates these complexities as intensely as an ERP application.
B. Who Does What?
1. Outside Implementation Partners. Many companies decide to engage an outside consultant to lead their ERP implementation effort. Examples of Tier 1 implementation partners are the Big 6 (or is it 5? Or 4?) consulting companies such as Andersen Consulting, Price Waterhouse, Deloitte & Touche, etc., and many of the large systems manufacturers—Hewlett-Packard, Digital Equipment Corporation, IBM, etc. There is also a galaxy of Tier 2 and Tier 3, or boutique, implementation partners. These companies usually differ from their Tier 1 brethren in one or more of the following: size, breadth, geographic presence, average experience levels, and fees.
2. Common Or Advisable Staff Ratios. Having outside consultants make up about thirty to forty percent of your ERP implementation staff seems to be a healthy range. Anything much less may not provide you with enough expertise and knowledge transfer; anything much more runs the risk of generating excessive costs and poses management control problems.
3. ERP Cross-section. In very general terms, there are three fundamental ERP implementation layers. In order of executive-level visibility and awareness they are:
4. Resource Alert. Most implementation partners focus primarily on the first two categories. Some attempt to provide "one-stop shopping" by addressing all three—and go even further by trying to provide the underlying hardware platform.
Heads-Up! Although it would clearly be the optimal theoretical solution, alarms should sound whenever an implementation partner attempts to be the primary provider for all three categories. All partners, regardless of focus, have resources that are likely stretched very thin. This is true for any one of the categories; it becomes even more pronounced if they attempt to take on two or all three.
What is almost always the case—and the real topic of this paper—is that insufficient or delayed attention and resources are invested in the IT-for-ERP Planning and Implementation category.
There are many possible reasons for this. Perhaps the most common is that a companies’ decision to implement an ERP solution is almost always driven by one or more core business needs. It is natural to expect that those areas closest to the bottom line need top priority—sales order entry, MRP, accounts payable/receivable, etc. These are the areas where you see the most up-front and generous investments in business and application configuration consulting—either external or internal.
It is not all that rare to find a company intentionally excluding its own IT group from the ERP application evaluation and decision making process. This is not necessarily a faulty strategy. What is at fault is, for whatever reason, IT not getting to work soon enough or seriously enough on IT-for-ERP planning.
Figure 3: The vast majority of ERP planning resources are spent above the water line.
A. N-Tier Client/Server Architectures
Most major ERP products use a two- or three-tier client/server architecture. Additional client/server "glue" is required to connect one tier to the next, and will be discussed later in this document. The following diagram shows a somewhat simplified diagram of a 3-tier approach.
As complex as the above sample may appear, in reality it most likely represents a simplified version of everything that is truly required to make a three tier client/server ERP application work. On the other hand, as simplified as this diagram may be, there is no way it could be seen as near as simple as an old-fashioned (but maybe making coming back!) two-tier host/terminal architecture—where you have a centralized mainframe, or mainframe-class, host with relatively "dumb" character-based terminals.
IV. CRITICAL IT-FOR-ERP COMPONENTS
The above box contains a minimum set of ten IT-for-ERP components that should be scrutinized. At first glance there may not appear to be anything ERP-specific about them—that they are simply standard requirements for any client/server IT infrastructure. Despite this possible first impression, you will hopefully derive two key benefits:
Number 1, you will either be acquainted or re-acquainted with many or most of the major client/server disciplines—which is certainly advisable given that you may be new to client/server, or have not had to build a truly mission-critical client/server environment.
Number 2, each category will include ERP-specific commentary and examples, which will further drive home the issues under discussion.
The system running your ERP application is most likely running your business. It is possible that you will not be able to take down the system to do a backup, or will be able to take it down only for a short period of time, e.g., Monday through Saturday from midnight to 2:00am; Sunday from midnight to 6:00am.
|
A careful up-front analysis of your backup/restore requirements along with formal or informal service level agreements should yield a fairly obvious solution—in terms of required hardware, software, and procedures.
|
1. Key Questions: Your ERP application will need to be available for use most—if not all—of the time. After all it is running your business. The extent of this availability should ultimately be determined by answers to basic business questions:
|
2. Recommendations:
|
1. Key Questions
|
2. Recommendations:
|
1. Key Questions: ERP applications are becoming ever more network-centric. Understanding their impact on your LAN and WAN is critical. A clear "red alert" situation is exemplified by degraded, or erratic, sales order entry response times due to excessive network latencies. Network bandwidth is a finite resource. Knowing exactly what resources are required for your ERP application calls for a lot more than estimating or using rules of thumb.
|
2. Recommendations:
|
1. Key Questions:
|
2. Recommendations Few companies have, on a large scale, achieved a true proactive, correlated, end-to-end IT management capability. Their number has recently, however, begun to grow substantially (hopefully you will soon join their ranks!). There are a couple of reasons that explain this trend: 1. ERP is truly mission critical. Anything and everything that has a potential impact on it needs to fall under a management umbrella. Maintaining high availability depends on this discipline more than any other hardware or software product. 2. Qualified IT staffers are in extreme short supply. You need to do two things: 1) leverage their resources by embracing increased productivity measures, and 2) augment their expertise as much as possible by using tools that help make predictions and correlate cause-and-effect data. 3. ERP solutions have a voracious appetite. You constantly need to feed them ever-increasing amounts of memory, network bandwidth, storage space, etc. Getting a handle on the magnitude and timing of these upgrades is critical for budget planning and service level reasons.
|
1. Key Questions:
|
2. Recommendations:
|
Appendix A: NRP for ERP Planning Book
(from: http://www.makesystems.com/nrp_book/nrp_book.html)
Annette Clewett, et al.Network Resource Planning For SAP R/3, BAAN IV, and PEOPLESOFT:
A Guide to Planning Enterprise Applications
This "how to" book with real-life examples is a guide for network planners, technical staff and managers who are responsible for ensuring a wide area network infrastructure can support mission-critical enterprise application deployments. Learn about Network Resource Planning methodologies and how to assure existing applications and planned deployments achieve performance and cost objectives.
Authored by Annette Clewett, senior network consultant at Make Systems who has helped define and deliver Network Resource Planning.
This book will help you understand how to do the following: