Why Plan?

The disposition of IS, whether they involve network, hardware, or software components, requires significant preparation and planning. Upgrading or installing system components, whether it is within the context of a finance strategy or not, will have many key dependencies and considerations. Whenever a complex systems project is taken on, competent, proven professionals must be sought out to help in the planning and implementation. This is imperative when such projects involve intricate knowledge of technical specifications and specialized concepts and theories related to networks, systems, and the like. Although small and emerging business owners may have built their businesses with a strong do-it-yourself attitude, the systems aspect of business development works best when qualified professionals are involved.

Strategizing the finance function involves conceptualizing and planning the role of IS, a step the strategist must fully engage in, long before equipment purchases, consulting contracts, and time-consuming implementations begin. Conceptualizing the layout and design of systems will require choosing a particular philosophy of design and maintenance and understanding the impact of the general approach and philosophy chosen. Depending on where the organization is in developing a finance function, this process can be seen as either a subset of strategizing or a part of the finance strategy itself. Regardless of the motivation and form, this planning process must consider the general philosophy of decentralization versus centralization, the suitability of the organization to implement and maintain applications, and the capacity to develop relevant documentation.

Centralized versus Decentralized Designs

Early in the planning/strategizing process the finance strategist must determine to what degree applications and processes will be centralized. Determining whether the IS and finance function will be centralized or decentralized often is rooted in the management style of owners or culture of the business. Dictating uniformity in processes, as well as application and system components, embodies centralization. Centralization also may prescribe the location of all core hardware and software applications in one designated site company-wide. The true characteristic of centralization is the use of uniform, prescribed processes throughout the organization. Decentralization in its purest form is the opposite of centralization, especially as it relates to location and specifications of core applications and network tools. It is also characterized by the propagation of nonstandard processes made up of tasks that are conceptualized and implemented by the various components of the organization.

In reality, no finance function is totally centralized or decentralized. Processes and systems, in practice, fall somewhere on the continuum that bridges these two polar concepts. The finance function usually is more centralized or decentralized; hence the terms refer to the general philosophical approach to finance. Centralization in some cases is a more rigid approach to managing the finance function. Centralization travels with words such as accountability, discipline, and structure. Nevertheless, decentralized approaches can include all these things as well. Key factors in applying centralized and decentralized approaches to the finance function are often related to the geographical and cultural scope of the business. Small or domestic organizations often are more suited to centralized infrastructure. Commonality in time zones, issues faced, and competence level of process participants makes centralization more palatable to the organization. Multinational organizations face challenges related to statutory reporting rules and availability of qualified finance staff. Limited infrastructure may be a challenge in some countries. Challenges like these may require varying approaches to data flow and systems issues. As a result, the finance function for multinational companies ends up with a core, centralized component and peripherals that are decentralized.

Advantages of one philosophy over the other are circumstantial. Centralization implies uniformity, which makes troubleshooting easy and minimizes the impact of turnover. Decentralization, however, implies flexibility and the capability to overcome challenges in unique ways. Centralization often leads to rigidity and the inability to accommodate unique circumstances or presents solutions that create more challenges than they solve. If planned poorly or applied inappropriately, centralization can result in unnecessary hierarchy and bureaucratic hurdles. Decentralization may enable the development of processes or systems that are counter to the overall objectives of the finance function. Allowing the loose development of finance function components may enable blatant inefficiencies to infiltrate the finance dynamic and degrade the function as a whole. Centralization and decentralization can and often do exist simultaneously. Regardless of the approach, accountability and results-oriented management still can be preserved.
Discussing the concept of centralization and decentralization is particularly germane when defining the organization’s IS configuration. Systems and processes will serve as the backbone for the functionality of the finance function. Beyond understanding the difference in philosophies, the issue of centralization and decentralization will manifest itself in these key areas:

- Maintenance and management. Centralized systems and applications are of ten the norm with small and emerging businesses. In the case of multinational or geographically spread out organizations with users in remote locations, centralization presents challenges as well as advantages. Maintaining system components in one secured location will allow for the concentration of expertise in the application location site and make changes and updates simple and quick. Decentralized systems design requires a degree of application administration to occur locally, something for which small local sites may not be suited. Changes and updates often can be incorporated incorrectly or untimely. In the case of a worldwide user community, the application may be accessed 24 hours a day, seven days a week, which may make downtimes for maintenance or other reasons detrimental to the user community, a drawback to centralization. Server space and hardware costs will play a role in utilizing a centralized versus decentralized system. Having one application in a central site is cheaper to care for than multiple, remote applications. License issues and hardware expenditures also will factor into the design solutions.

- User community/data customers. Knowing how many users and where they will be located is key when determining whether the finance function will be centralized or decentralized. A large number of remote users may dictate maintaining regional applications or data sites. Such a quasi-centralized configuration requires that regional administrators or knowledge champions exist to enable troubleshooting and general application maintenance. This configuration will enable process users who are in various time zones or geographic locations to avail themselves of maintenance programs that are timely and relevant, as opposed to purely centralized processes and system components. The goal is to alleviate issues related to periodic maintenance downtimes that would impact the user community. Although this configuration requires strategically placed professionals, adept at systems administration, it will ensure that system issues (if encountered) do not paralyze the entire user community but rather the local or regional site in question. Small user communities or those in very close proximity would benefit from centralized configurations as the administrative function would be less apt to fall in the hands of the users themselves. Applications can be centrally located and maintained.

The ability to roll out the system and transfer knowledge to new and remote users will be an issue if the organization is in a growth mode. It may not be an issue if the company is static or in a purely emerging state; however, if the company is expanding via acquisitions or otherwise, taking on new users and data customers will be a constant. Should the finance function demand the adaptation of a uniform centralized process or allow the freedom for employing nonstandard, homegrown solutions? How will new users view a prescribed data flow process? How long will it take for them to master a new process? What level of expertise will be required at the local site? If centralized system components and processes are employed, a quickly expanding user community will require good documentation and logical processes that are easily transferred. Will old, existing processes have to run parallel with newly adopted processes? Undoubtedly redundancy will be required during the transition period to a centralized system. The finance strategist must have a plan in place that allows for fast and effective transfer of system components, especially higher-level finance/ accounting applications. Initial setup and conversion to the prescribed process will take time and depend on the competence and cooperation of the user community and data customers inherited or new to the organization. Decentralization allows for less coordination but embodies more risk. Process and system development is left to the discretion of the new user community. Matters of motivation and commitment may be more relevant here than that of documentation and knowledge transfer.

- Scalability. The finance strategist must address the need to expand both the scope and the functionality of systems in the finance function. The finance strategy must address the capacity to incorporate new applications or adapt to infrastructure changes. Addressing the issue of scalability is different in centralized environments compared to decentralized ones. Will a highly centralized, inflexible finance application deny new users the functionality they need for local statutory reporting? Would simple data requirements suffice if full-blown process participation is not feasible? Although welldocumented, highly structured systems and process requirements may seem easy to transfer, they may not be relevant. Conversely, relying on new users or expanded reporting sites to develop their own solutions for data and reporting requirements could leave too much to chance and expose the finance function to breakdowns in reporting. The challenge of scalability goes beyond measuring how long solutions will be relevant and instead must address the ease of system expansion.

- Support/maintenance. Once the system is in place, how will ongoing support be handled? Are dedicated IS professionals available for support if systems issues are encountered? The landscape of the support model is dictated by the degree of centralization of the system itself. A centralized system lends itself to a focused IS support team in one location. Decentralized systems require a level of expertise distributed throughout the organization. Creating a network of knowledge spread evenly throughout the organization is essential to maintaining the applications and maximizing their usage. This may be the method of choice for a 24/7 application with many users in geographically remote locations at varying levels of expertise. Establishing and maintaining a remote support web may be a difficult initiative to execute. Establishing power users or application champions at local and regional locations may foster the transfer of knowledge and develop adequate support expertise. Maintaining a certification process and reward structure for achieving a level of readiness from a system standpoint may inoculate the organization from latent weaknesses in the data flow dynamic.

Finance function design depends on the management philosophy as it relates to centralization and decentralization of tasks. The finance strategist must understand the particular philosophy to which the company subscribes, especially as it relates to systems design. Understanding the basic approach to the finance function will enable more accurate systems design planning and cue the finance strategist to consider the organization’s ability to follow through with implementation strategies.

Ability of the Organization to Implement and Maintain

System design and development, as a general rule, follows the one-third, one-third, one-third rule; planning, system construction, and testing must be dealt with in equal measure. Because systems design and development is not mutually exclusive of the finance strategy, the strategist must keep these three phases of design and development in mind as the finance function is built. The finance strategist must consider the capacity of the organization to initiate and finalize the systems design, implementation, and maintenance aspect of the finance strategy. Planning this aspect of the strategy will demand knowledge of the resources available and a level of expertise that can be lent to systems development issues.
Many organizations fall prey to the part-time bug—that is, the resources that will be dedicated to systems development on a part-time basis. Implementing IS infrastructure is a challenging task and should garner full-time, qualified resources. Dedicated human resources will have the time and focus for troubleshooting that part-timers will lack. Specifically, a full-time project manager will strengthen the odds of finishing a project on time and within the means estimated. The finance strategist may decide either to preside over systems development or to delegate to another. Regardless, this task must be undertaken by qualified professionals who are subjected to as few distractions as possible.

The systems roll-out plan should focus on utilizing as many in-house professionals as possible. The temptation to outsource may be high. Outside specialists and consultants may be necessary, particularly when it comes to installing systems initially. In the early phases of planning and development, the opportunity to transfer knowledge and cultivate a wide base of understanding for the systems configuration must be clearly grasped. The finance strategist must keep in mind that the strategic aspect of systems development should remain within the company’s control and that use of outsiders should be carefully managed to ensure proper knowledge transfer. Technical expertise should be procured to keep projects on time and within budget. Keeping the knowledge transfer and learning curves in-house will facilitate future development of the overall systems structure and user community in the end.

Choosing Applications

The finance strategist will spend considerable time and effort determining what systems components will fit the organization’s needs. What software applications will be relied on to perform the critical tasks that make the data flow process effective? What network components will be put in place to house these applications and make them work? Will the finance strategist choose simple off-the-shelf applications or internally generated ones? Perhaps the plan will involve building a database from scratch using the various languages and architectures that facilitate data storage. Maybe the final solution will end up somewhere in between, utilizing a proprietary out-of-box database augmented by a made-to-order system of code and languages.

Buying systems components can be a confusing and daunting process. Making well-informed decisions is a challenge, given the numerous choices, options, and combinations of hardware, software, and consulting support. Although this discussion will not provide all the answers to selecting the right applications for all finance strategies, it provides some areas to consider before signing contracts with vendors. Every situation is different; the one constant is the need to research and carefully evaluate needs and the tools that will address them.

The first step in moving forward with application purchases is understanding organization needs. This is often a circular equation, as needs will dictate the tools to address them, which in turn may shape the needs of data customers. Rather than jumping in and putting expensive solutions into play before finding an equilibrium between systems tools and data customer needs, employing a model like the multilevel approach to strategizing will allow the strategist to plug in solutions and judge the impact on data customer needs. Having a firm grasp of customer needs and the resources available to address them will be key to this aspect of strategizing.

The finance strategist will have to be prepared to endure presentations from software vendors who are not only good at what they do (selling) but are under tremendous pressure to sell product. Expenditures for finance software can range from tens of thousands to millions of dollars. This is perhaps the most important reason why the strategist must have a solid grip on the company’s needs. Strategists must base buying decisions on software offerings that are available now. Buying software applications based on prospective upgrades is dangerous and often leads to unfulfilled expectations. Getting key users and technical people involved in the buying process also helps. The application is what it is, and its capacity to generate appropriate solutions should be obvious to the vendor representing or selling the application. Having key users (who have a stake in the application’s functionality) and IS experts (who have a stake in maintaining the application) ask questions directly to the vendor during demonstrations and sales meetings will ensure that all performance requirements are clearly articulated to the vendor. Including them in the process also secures their cooperation as the finance function continues to develop. Good sales reps appreciate pointed questions, which will help them to match the right tool to the customer.

When a major purchase is at hand (usually for the small and emerging business this is a purchase above $500,000), the finance strategist may want to designate a team to evaluate the options for a particular solution. The team may be composed of a group of key users, an IS professional, and the finance strategist or business owner. Companies may choose to hire a consultant to evaluate applications for their business needs. The company may or may not have the money for this option; however, hiring professionals who understand the technical specifications of tools on the market and how they accommodate needs for other businesses in similar industries may be worth the money. They also will be adroit agents for the company in meetings with vendors, insisting on seeing all functionality and features of software clearly demonstrated. If it is a substantial purchase, vendors may let a company try the product out in a limited setting in-house before buying the application outright. This will allow for the user community to put the software through its paces and ensure it possesses the functionality being sought.

Deciding whether to go with an off-the-shelf solution or an internally generated one will also be a challenge. Prepackaged applications are advantageous because they can be put in place quickly. The concern is, though, that they may create scalability issues. Can the application be expanded? Can additional applications be attached to it as needs change? Is there a capacity limit for data storage or design? Although prepackaged applications are advantageous when it comes to ease of implementation and support, the strategist will have to factor in the need to expand when considering an off-the-shelf product as a long-term solution. Free-designed applications provide flexibility and scalability; however, documentation must be meticulous as it relates to design and support. Using languages such as Oracle and SQL provide a broad canvas to create databases and storage applications. Consideration must be made, however, of the ability to create reports and generate dynamic analysis. Does a user need to be an expert in the application architecture to create reports? If a barrier to usage exists, users may become frustrated. The time horizon for a final, usable product also may be unreasonable. Many small and emerging businesses do not have the luxury to play hit-or-miss with application designs. Uptimes or completion dates need to be predictable and occur within a reasonable time period.

The organization may decide to outsource the applications and the functions they perform altogether. The most popular form of outsourcing is employing an ASP. ASPs provide benefits in the form of quick uptime, good support, and reliable backup/disaster recovery procedures. Before signing a contract with an ASP, however, the organization must be sold on the longevity of the company and feel comfortable with the financial commitment. While the organization can avoid the hefty capital outlays that characterize application purchases in the short to mid term, the finance strategist must be aware of the breakeven point where an up-front investment in application software equals the ASP contractual payments. The company also must be aware of the requirements to customize interfaces with the ASP and ensure connectivity is adequate. These IS-intensive topics must be addressed before the contract is signed to secure the full benefits these tools will offer.

Documentation

The development of systems and processes, if done correctly, will produce enough documentation to aid users in support and further development. Comprehensive documentation will inoculate the organization from turnover and provide guidance to users who do not have ready access to support personnel. New employees or users with shifting roles will especially benefit from comprehensive documentation.
The first step in preserving documentation is to mandate its existence. The finance strategist must make the accumulation and creation of relevant documentation a standard component of development and implementation. Those responsible for developing systems components must be tasked with providing comprehensive, easy-to-read, graphical documentation that describes applications and processes. Additionally, such documentation must be available to those who will need it. Useful documentation should be easily accessible and user friendly.
Documentation must exist, but what exactly does good documentation include? Descriptions of hardware and software components? Outlines of processes? The objective is to establish enough written documentation on all aspects of the finance function to provide enough guidance for a person new to the environment to succeed. Armed with this approach, documentation should cover:

- People. Who does what? This may be as simple as a roster of individuals and their role in the data flow process or as complex as a detailed list of job descriptions. This documentation should include notations from support staff and from those with intimate knowledge of systems configurations.

- Processes. Detailed outlines of the data flow process will be crucial to provide guidance for new users and a context for systems components. Maintenance and development will be dependent on understanding not only what applications and systems components exist but how they are employed by the data flow process.

- Applications/hardware. Documentation of software and hardware components will be referenced by many individuals, from laypeople to technical types. Detailed descriptions of configurations, settings, and alignments must be available in the case of breakdowns or maintenance. It must be assumed that those implementing and installing system components will not necessarily be the people maintaining them in the future. Key points of interest relate to clarity, completeness, and relevance. Extra effort should be put into writing in easy-to-read terms, without leaving out crucial technical matters. Graphics and illustrations in documentation can make it more easily understood. Keeping documentation in tune with upgrades and configuration changes is also important. Often the best documentation exists with initial implementations but degrades as applications, network components, and hardware upgrades are undertaken. Making documentation a priority when systems changes are engineered will be key to maintaining good written knowledge of the systems.

To be effective, the documentation must be in an accessible location for all relevant parties, whether they are users, data customers, or maintenance professionals. Intranet or network directories are often the best locations for frequently referenced material. Making documentation usable will be key to ensuring that system configurations and updates will be timely and appropriate. Availability, relevance, and completeness are factors that the finance strategist must focus on to ensure that documentation shadows system needs.