SPEEDING UP PLANNING & BUDGETING.

Rapid technological change is fostering the ability to enhance collaborative processes throughout organizations. Internet- and intranet-enabled tools, although not the panacea they were recently envisioned to be, are being increasingly and intelligently employed to fulfill a variety of functions for the enterprise. A fertile area for these technologies is in the planning and budgeting process.

Corporate planning and budgeting processes are well-suited to benefit from the Internet and other Web-enabled collaborative tools, for a number of reasons.

Enterprise-Wide Participation. First, organizations are requiring increasingly greater input from line managers during the development of corporate budgets. Gone are the days when a small group of financial analysts were solely responsible for the physical development and compilation of budgets. Collaborative, Web-based software tools facilitate the distribution of the planning process to a wider audience.

Faster Feedback and Response. Secondly, budgeting and planning processes are inherently iterative. Organizations must "see where they're at" before making prescriptive changes. As the speed of business continues to accelerate, organizations are requiring faster feedback/response cycles in the planning process. Internet collaborative tools can help speed up that cycle.

Low-Cost Deployment. Finally, Internet-based planning tools typically (although not always) offer low-cost deployment. For example, the client-side program code may be "packaged" within a Web page, or all of the business intelligence may be maintained on the server, lessening the IT and labor costs associated with deployment.

Unique Challenges

Successfully adapting planning and budgeting processes to the Internet environment presents unique challenges. Planning and budgeting are inherently different from the typical domain of Web-based applications (such as B2B or B2C) in that they require intelligent modeling.

Intelligent modeling goes way beyond the basic "x times y." For example, it allows the calculation of employee benefit costs based on specific job classes and contracts. Or, it enables predictive forecasting of sales volumes based on complex historical trends. In short, intelligent modeling allows organizations to build a true picture of their business environments based on real-life, complex and sophisticated relationships.

Simple data-input grids or forms of departmental revenues and costs are not adequate tools for intelligent modeling. Many enterprise resource planning (ERP) vendors have offered these simplistic mechanisms for years, yet most enterprise organizations find them insufficient for budgeting and planning.

However, most early version Web budgeting applications provide little more than this very basic, data input grid functionality. These simplistic implementations reflect inherent limitations in browser-based and Web-based technologies. HTML and DHTML (dynamic HTML), although extremely dynamic at presenting information, provide only very basic interactivity and data input abilities as compared to higher-level programming tools including Visual Basic, C++, Java, or .Net.

To circumvent these limitations and provide the necessary intelligent modeling, other vendors have implemented client-side ActiveX technologies. While this approach is more powerful, it is still not perfect. Drawbacks typically include a need to perform large client installations and reliance on a particular browser and operating system.

Despite the challenges, progress is being made to extend the functionality of these distributed tools. These issues need to be vigilantly monitored and evaluated as the technology develops.

Collaboration Architectures

The use of the Internet alone does not guarantee a suitable architecture for these next-generation collaborative tools. Web-enabled budgeting and planning systems use several different architectural styles:

Connected vs. Disconnected

Distributed planning and budgeting can either be "connected" or "disconnected." With connected applications, users must maintain an active session with a server. In a disconnected environment, the user's data subset is sent from a master system to that user, who can manipulate the data locally, then send it back to the master system periodically.

The following areas differentiate a connected versus a disconnected application:

1. Data Timeliness. In connected applications, the master system is updated in real time as users modify their data. Disconnected systems are only up to date as of the last time a user has saved back to the main system.

2. System Complexity. Connected architectures avoid the additional "layer" of software responsible for the dissemination, tracking and collection of data because the data, by definition, is always "live" on the master system. Data synchronization and process control issues require a significantly more complex application on a disconnected basis.

3. Bandwidth. In a connected system, the volume and frequency of data transfer increases, since data is updated in the master system in real time. Disconnected systems may be more appropriate for low-bandwidth situations, since connection with the server is sporadic and required only when retrieving or saving data.

4. Full-time connection. A connected application requires a full-time connection to the server (typically an Internet, virtual private network (VPN), or wide-area network (WAN) connection), which may not be practical for certain geographies or for personnel traveling with notebook computers. In a disconnected application, users can update their budgets or models without requiring an active connection to the server.

Because organizations' user bases and operating environments rarely fall neatly into one category, it is imperative that planning and budgeting systems support both a connected and a disconnected environment.

Push vs. Pull

There are two distinct methods of getting data to users. Users can "pull" the data themselves, or a system administrator can "push" it out to them. The pull method allows users to select and check out data on their own, typically via a Web site or some other centralized tool.

The push method allows system administrators to send data to endusers, typically via e-mail. This approach can be very effective for several reasons. First, e-mail is ubiquitous and, relative to Internet connections, quite reliable. In addition, even if the amount of budget data and code is somewhat sizable, the data transfer is being done asynchronously on the email backbone (i.e., the user isn't waiting while data is being transferred). Therefore, this method is suitable in low-bandwidth environments.

As with the connected versus disconnected approaches, the best strategy is to find a vendor that provides both push and pull options, so various

constituents can be served appropriately.

Thin vs. Thick Clients

"Thin client" is a commonly used and commonly abused phrase. There is a considerable amount of confusion in the industry about what it means to be a "thin" or "thick" client (user workstation). Thick clients typically require the program code to be resident and running on the client machine. Thin clients perform most of the business intelligence on a server while transferring smaller amounts of data back and forth.

Thick isn't necessarily bad (although many people mistakenly have this impression). Remember that planning and budgeting applications should have intelligent modeling, which usually requires a thicker client. A vendor's thin-client claim often means that there isn't much intelligent modeling going on, though this may be fine in simplistic modeling situations.

To confuse matters even more, different types of thin-client architectures are currently being employed. The browser-only architecture, albeit thin, usually suffers from a lack of intelligent modeling. Another thin client/low bandwidth option that still allows for robust modeling is the architecture popularized by Citrix Systems Inc. and embraced by Microsoft, where the client is acting as a "terminal" for a Windows-hosted application on a remote server.

In the vendor evaluation process, it is imperative to make sure that all clients, thick or thin, allow for intelligent modeling capabilities. Also, ask vendors for the size of their system's client footprint (the size of the program code downloaded to the local machine). Anything under roughly 5 to 10 megabytes should be considered acceptable. If the installation footprint is much larger, one of the key advantages of collaborative systems disappears -- namely easy deployment.

Bandwidth -- Perceptions And Reality

Bandwidth can be thought of as the capacity of the connection between the server and the client. Some collaborative architectures are efficient users of bandwidth, and some are not. Much confusion exists in the marketplace, fueled by promises in the not-too-distant future of virtually unlimited bandwidth. Although there has been some improvement in the last few years, in practice, unlimited capacity is still a distant dream, and effective bandwidth (as discussed below) is far less than most people assume.

Stated bandwidth is often far different from effective bandwidth. Stated bandwidth is the "size of the pipe." It is often described by both the type of connection (dialup, DSL, T1, cable, etc.), and more importantly, as capacity in terms of bits per second (bps). For example, a T1's stated capacity is roughly 1,500 bps.

However, most organizations are surprised to find that their effective bandwidth is much less than the stated bandwidth, for several reasons. First, multiple users compete for the same "pipe" at any given point in time. Second, latency (the packet delay between routers from the client computer to the server) increases as distance increases, since there are typically more routers involved. (You can get a quick idea of latency using the tracert utility from a command prompt.)

The best way for an organization to determine effective bandwidth is to test the throughput from a client computer to the server. There are also a number of Internet sites that will measure bandwidth, such as http://msn.zdnet.com/partners/msn/bandwidth/speedtest500.htm. Bandwidth should be tested at various times, since data volumes typically have peaks and valleys throughout the day.

Understanding the bandwidth requirements of an application should be a key part of any evaluation of budgeting and planning software.

What The Future Holds

Web-enabled collaborative tools will continue to develop and improve in many ways and increase their value to enterprises. The most significant improvements should be in these two areas:

1. Sophistication. Early releases have often had a very limited feature set, constrained both by the development tools and platforms, as well as effective bandwidth. As the developer tools mature, and as effective bandwidth increases, vendors will be able to significantly expand available features.

2. Ease of Use and Deployment. Due to maturing developer tools in the Web area, the sophistication of user interfaces will continue to improve, which will eventually bring Web-enabled products on par with their client/server predecessors. In addition, continuing improvements in deployment technologies should continue to lower total cost of ownership.

Although Web-enabled collaborative tools offer a wealth of opportunity for improving the planning and budgeting process, they should not be viewed as a panacea. Due to tool immaturity and bandwidth constraints, buyers must strive to understand the choices available. The best vendors will offer multiple architectures to meet a wide range of situations.

Stephen D. Reiff is Director of Development for SRC Software, a Portland, Ore., firm specializing in budgeting, forecasting, consolidation, financial reporting and analysis software. Reach him by email at [e-mail].