Document Sample
Reynolds_The_Software_Game Powered By Docstoc


Presented By:
 John T. Reynolds, CPA
 First Assistant County Auditor
 Bexar County
 Tel: 210-335-2542
 Mitt Salvaggio, CPA
 Salvaggio, Teal & Associates
 Information Systems Consulting For the Public Sector
 Tel: 512-335-9348
There is no Genie……..

                            …and there is no magic!


Chapter I – Introduction……………………………………………..                               7

Chapter II – Who Are the Players……………………………….......                       9

Chapter III – Buy, Build, or Somewhere In Between
     Introduction…………………………………………………….                                    13
     Background…………………………………………………….                                      13
     Buy (Package Solution)………………………………………..                              14
     Build (Custom Application)…………………………………...                           15
     Now for the Bad News…………………………………………                                 16
     Somewhere In Between………………………………………..                                17
     Conclusion……………………………………………………...                                    18

Chapter IV – The Decision Making Process
     Introduction…………………………………………………….                                   19
     The Decision Making Process…………………………………                            21
     Steps to Follow in the Decision Process………………….……                23-31
           Establish a Steering Committee
           Prepare a ―needs assessment‖
           Flow charting
           Consider engaging an independent consultant
           Talk with the county’s current vendor
           Prepare a formal request (RFP)
           Contract negotiations

Chapter V – Looking For that Other Right answer – Business Intelligence
     Introduction…………………………………………………….                                    33
     Purpose………………………………………………………….                                       35
     Step One – Identifying the Business Problems……………….                  36
     Step Two – Determining Expectations of Use………………..                   36
     Step Three – Understanding Delivery of Data……………….                   37
     Step Four – Rolling Out Training Initiatives………………...                37
     Step Five – Choosing a Vertical or Horizontal-Based Solution         38
     Conclusion……………………………………………………...                                    39

Chapter VI – What is Enterprise Resource Planning (ERP)?
     What is ERP?...............................................................................     41
     How Can ERP Improve a Government’s Performance?........                                         42
     How Long Will an ERP Project Take?....................................                          44
     Will ERP Fix My Integration Problems?................................                           45
     What Will ERP Fix in MY Government…………………….                                                     46
     Will ERP Fit The Way I Do Business?....................................                         47
     What does ERP Really Cost?...................................................                   48
     When Will I Get Payback From ERP – and How Much
           Will It Be?.......................................................................         49
     What Are the Hidden Costs of ERP?.....................................                           50
     Why Do ERP Projects Fail So Often?....................................                           53
     How Do I Configure ERP Software?.....................................                            54
     How Do Governments Organize Their ERP Projects?........                                       54-58
                 Big Bang
                 Slam Dunk
                 Phase-In Approach
                 Single Instance Approach
     How Difficult Is It To Upgrade ERP Software?....................                                58
     Will Service Oriented Architecture Replace ERP?..............                                   59
     How does ERP Fit With e-Commerce?.................................                              60
Chapter VII – Is An Application Service Provider Right For You?
     Introduction………………………………………………….                                                                63
     How does It Work?.................................................................              63
     What Is Outsourcing?……………………………………….                                                            64
     A Short History………………………………………………                                                               64
     Application Software Outsourcing…………………………                                                      65
     Decision Criteria…………………………………………….                                                             67
     Critical Systems……………………………………………..                                                             68
     Failure Recovery Requirements……………………………                                                        68
     Performance Criteria……………………………………….                                                            69
     Specific Functionality……………………………………….                                                          69
     Why an ASP?..........................................................................           70
     Is an ASP Forever?.................................................................             70
     County Responsibilities……………………………………..                                                         70
     Why Do It?..............................................................................        73
     Why Not Do It?.......................................................................           73
     ASP Selection………………………………………………..                                                               73

Chapter VII – Is An Application Service Provider
           Right For You? (con’t)
     The ASP Contract…………………………………………..                                           74-77
           Establishing Standards of Service
           Contracts and Commitments
           Training and Technical Support
     The Service Level Agreement (SLA)………………….…..                                    77
     Selecting and ASP………………………………………….                                              78
     Outsourcing Categories……………………………………                                         80-82
           Application Software
           I.T. Infrastructure
           Business Processes Outsourcing
     Summary……………………………………………………                                                    82
     Recommendations for Outsource Providers……………..                                 84
Chapter VIII – The Vendor
     Beware of Vendors Bearing Solutions……………………                                    85
     What Are the Implications?................................................     87
     Recommendations…………………………………………                                                87
     The World of Software Buying Has Changed!
           Will Vendors Change With It?................................             89
     History Builds Skepticism………………………………..                                        89
     Economy…………………………………………………..                                                   90
     Risk………………………………………………………..                                                    91
     Vendors Face a Cross Roads…………………………….                                         91
Chapter IX – Contract Negotiations
     Always establish Position…………………………………                                         93
     Anticipating the Negotiations…………………………….                                      94
     Basic Rules of the Art of Negotiations……………………                                 95
     Closing a Deal……………………………………………..                                              96
     Understanding Contracts…………………………………                                           97
     Meeting of the Minds……………………………………..                                           97
     Consideration……………………………………………..                                               98
     Agreement to Enter Into the Contract…………………..                                  98
     Legal Competence………………………………………..                                              99
     Understanding Oral Agreements………………………..                                       99
     Formal Agreement………………………………………..                                             100
     Other Elements in a Contract…………………………….                                      102

Chapter IX – Contract Negotiations (con’t)
     Vendor Reliability…………………………………………                                                 103
     Customization……………………………………………..                                                   104
     Negotiating a Computer software Maintenance Contract                               105
     Guiding Principals………………………………………..                                                106
     Definitions…………………………………………………                                                     106
     Deliverables……………………………………………….                                                    107
     Pricing Options……………………………………………                                                   107
     Payment Terms……………………………………………                                                     108
     Continuance……………………………………………….                                                     108
     Product and Service Quality……………………………..                                           108
     Liability……………………………………………………                                                      109
     Financial Reporting………………………………………                                                 109
     Ratios………………………………………………………                                                        110
     Graphics…………………………………………………..                                                      111
     Hotlinking…………………………………………………                                                      111
     Event Triggered Reporting (Alarms)……………………                                         111
     What do YOU Need?..........................................................        112

―Attachment A‖–Glossary of Terms Related to Enterprise Applications                     113

―Attachment B‖ – Financial Package Software Selection RFP                               125
     (Sample Deliverables)

―Attachment C‖ - Human Resource Software Selection……                                    131
     (Sample Deliverables)

―Attachment D‖ – Reasons Why Strategic Plans Fail……..                                   135

―Attachment E‖ – Sample Project Charter ………………..                                   137 - 141

                                   CHAPTER I


       For many years now counties in Texas have focused on choosing a financial
software system that meets their ―accounting needs‖ and doesn‘t truly focus on
their particular business, reporting and information-collecting needs, and is based
on industry-standard best practices. Over the past several years the financial
summary and information-gathering requirements of governmental entities has
rapidly changed, and financial software packages that address these unique
concerns have become increasingly available. Enterprise resource planning (ERP)
software today encompasses all the functionalities of a fully integrated financial
system, from accounting to warehousing in one package. Financial needs that can
be served by software packages that are in the market include general ledger,
procurement, asset management, cash management, budget development, outside
reporting, fund accounting, year-end accounting, personnel management, cost
allocations, multiple bank account requirements, project accounting, grant
monitoring, customer relationships, and inter-fund activity. Today it is easier for
elected officials and department heads to find software that is responsive to the
specialized needs of their county structure. All counties need the sophistication,
but the organization needs to be sure that it can handle a complex system.
      Counties in Texas have unique reporting and information gathering needs
today, which have the tendency to change every two years. Before buying
software for a county it is important to evaluate various software packages to make
sure those unique needs are properly addressed. Therefore, it is critical that the
County perform an in-depth needs assessment.
      There's an old saying, ―If you ask the wrong question, you're likely to get the
wrong answer.‖ That certainly applies when a County is evaluating which
financial software product is the best. The fact is there is no best. There is no single
product that suits everyone's needs, but there are probably several that will suit a
County‘s specific requirements. So, since the problem is matching software
products with a user, the correct question is: ―How should I go about finding the
packages that are right for my County and that fit our business practices?‖
       When it comes to financial software, the search begins by examining the
entity‘s needs, current business practices, and anticipation for the future. The
County needs to define its business practices and needs in detail so that all
understand clearly of where the project needs to go. While financial reporting has
been a critical need in the past many software packages are available which will
allow not only for standard reporting but also ad hoc and on-the-fly reports to be
generated. But, the reporting process is tightly connected to the needs assessment.
The county will also have to come to terms with deciding if it is looking for
software to be a tool or if it is looking for a software company to be a technology
partner. Because financial software contains hundreds - if not thousands - of
features, this may seem like an overwhelming task. The County will need to be
prepared to be able to internally evaluate both the products' features and the
vendors behind the products, or to hire consultants to come in help in the process.
While such assessments are not exactly easy, they are not overly difficult, because
only a handful of features are critical to making the right choice. Features will
change depending on a county‘s internal capabilities, available funding and
politics. Some of the features that would probably be at the top of the list for all
would be:
           Vendor expertise
           Vendor support
           Vendor services
           Financial management capability
           Financial reporting capability
           Managerial capability
           Client/server architecture
           Capability to interface with 3rd party software
           Hardware requirements
           Implementation requirements
           Pricing methodology

                                   CHAPTER II

                           WHO ARE THE PLAYERS?

       Many ERP projects fail to meet their intended purpose, and/or experience
time and budgetary overages. And, what is strange about County government is
that the failure for financial issues never seems to roll downhill – it usually stays at
the top. What can be done to insure that a project will culminate in victory and not
       A good question, of course, but then there is no solid answer. I am always
reminded when this question comes up of an anecdote from Sam Clements ―Life
on the Mississippi.‖ It seems a transport barge was moving down the Mississippi
River and it was pushing another barge in front of it. Maneuvering down the
Mississippi was a difficult project in and of itself, let alone pushing another barge
in front of it. One night as the barge neared Hannibal, Missouri the Captain of the
barge put ashore and sent word that he needed a river pilot to help him steer
through the fog and sand bars. Shortly a young man came to barge – sleep still in
his eyes – carrying his book of notes and his twaining rope. The Captain was
alarmed at the young man‘s seemingly youthful appearance and barked at him ―Do
you know where all the hazards are young man?‖ Sam responded, ―No sir – I
don‘t.‖ as he began to open his notes.
       ―Then how the hell do you plan to get us down river tonight?‖ asked the
       ―Well, that is simple, sir, I know where they aren‘t.‖
       Understanding the problems that may lie ahead is critical to any financial
system implementation. There are several reasons for failure many of which seem
out of our control at the time, but in reality they can be anticipated for example:
           Inexperienced in project management
           Inability to hold the vendor accountable
           Unrealistic time line
           Inability to perform knowledge transfer
           Excessive modifications
           Inadequate training
           Unprepared for change management
          Additional reasons are set out in Attachment D

      Probably the one reason for failure that is most often listed is failure on the
part of the entity to commit the best and brightest to the project. The
implementation of a new financial system has more hazards lurking in the wings
than Sam could ever imagine of being present in the river. One has to identify
those hazards and possible mistakes in the beginning and preparing for them when
they occur, or better yet pulling their fuse before it is allowed to be lit. Sam had
notes – he had been there before – he was prepared for any eventuality. But, we
should never attempt this arduous task on our own – there are many others who are
stake holders in this process and then there are the pathfinders who have already
gone before and mapped some of the hazards. What they could not anticipate was
the local climate. So let us identify some who need to join in this effort and to
commit assistance.

Auditor’s Office
           All the staff in the county auditor’s office needs to be assessed as
           to their ability to assist in the selection process and the
           implementation. They all need to be on board once the decision to
           go forward has been arrived at. There should not be any nay
Commissioners’ Court
          All the members need to be aware of the needs of the county and
          they should all be allowed to participate in the assessment and at
          the least to be apprised of the assessment when it is complete. The
          Court is the entity that will eventually provide the financing for
          the project and they should be informed as to what hazards lay
          ahead. But, most of all they should know the reason for the
          county to have to make a change.
             One of the major modules in any financing package is the
             procurement module and one of the duties of purchasing is the
             issuance and monitoring of the Request for Proposal (RFP).
             Purchasing needs to be involved from the get-go. Purchasing will
             be one of the offices responsible for evaluating responses and for
             the development of a contract.
             In every county the development of financial needs will
             automatically lead to cash receipts, deposits, cash disbursements,
             accounts receivable and accounts payable as well as trust funds,
             credit cards, ACH, direct deposit, wires, and other forms of
             electronic payments and banking. The treasury module(s) will be
             important to everyone and therefore someone representing the
             treasury function needs to be included in all discussions.

Fee Offices
              Along with the treasury involvement are the fee offices. There
              needs to be a lot discussion and involvement by this group due to
              the fact that they will be the ones that will use several of the
              modules on a continuous basis. And, these will be the offices that
              encounter the greatest change in their business practices – and for
              once you want to try and standardized many of the practices
              across the county.
              If in the development stage it is foreseen that there is not
              currently within the county staffing adequate personnel to tackle
              the program, then it will well worth the county’s time to bring a
              consultant on board to assist the technology assessment committee
              (TAC) in each of the phases. And purchasing as well as the TAC
              will need legal advice on different issues and the best time to have
              an attorney involved with the program is in the beginning –
              always time well spent.
              Then there are others that need to be considered as you go
              forward – budget, human resources, payroll, judicial – many will
              not be physically present, but their needs and responsibilities in
              the process need to be taken into consideration – i.e. district
              judges, district attorney, county court at law judges, community
              supervision, the constituents, the customers, and last the vendors.

                                 CHAPTER III

                  Buy, Build, or Somewhere In Between

       There are several options available to most governments as to what the
shape their financial system will take. The majority of the vendors today have
gravitated to the Enterprise Resource Planning (ERP) management system.
Governmental entities considering the implementation of an ERP management
system are often faced with the decision of purchasing a packaged solution or
building their own custom application. Both choices have their pros and cons. A
decision that favors either route depends on a number of factors whose influence
on the decision process varies between governmental entities. As a result, there is
no golden rule that can help governments choose one route over the other.
Whatever the route, governments generally inherit all that is good and bad about
that option and are subsequently excluded from the good and bad of the alternative.
Furthermore, once embarking on a route it is difficult and expensive to change
      The decision factors that governmental entities have to weigh out in the
build versus buy debate are many and there are venues that each will need to
explore and in the search the answer will probably lay somewhere between build or
buy – but one has to seek the best solution.

      Prior to the advent of packaged software, governmental entities wishing to
implement software solutions had no choice but to build a custom application that
met their needs – and many times that construction took place on main frames.
This situation changed in the nineteen eighties as software developers realized the
commercial opportunity in developing applications that addressed the common
processes and needs of many governmental entities. Since then, the software
industry has seen the continuous return of the build versus buy debate and vendors
in both camps periodically switch sides, depending on which option enjoys the
strongest support and has the greatest potential to drive increased revenues at the
       During the nineteen nineties, accelerated technology advancement in the
market increased the number of business applications and core building blocks
available in the market. While this resulted in greater choice for customers, it also
led to greater confusion and complexity. Still, these options did little to squelch
the build versus buy debate. Now, instead of buying the technology stack and
applications of a single vendor, customers were deciding on a level of vendor-
centricity and augmenting this with other best-of-breed packaged solutions. If
anything, this only increased the number of arguments instead of improving the
customers‘ ability to take advantage of the benefits of both camps.
       For sake of brevity, this discussion is going to refrain from delving too
deeply into the differences between these options. Fully explaining both sides of
every option and comparing them against one another will take too long and in all
likelihood will just fuel an ongoing argument. Instead, the focus will only be on
the basic options which all other options fall under to a lesser or greater degree:
build or buy—packaged solutions versus custom applications. This discussion will
attempt to illustrate the benefits and abilities of new emerging technologies that
offer a more ―middle of the road‖ approach that should benefit all.

Buy (Packaged Solution)
        The advantage of the buy strategy is that, in theory, a package will enable
the government to go live with broad functionality in a short period. This is
primarily because the vendor has already developed the functionality and because
it is easier to plan an implementation timetable.
       Post-implementation factors also have to be taken into consideration. When
purchasing a package solution and outsourcing the implementation, the customer
is, in effect, shifting several aspects of risk. Generally the subject of risk is
associated only with the implementation. Yet, in the long run, what is being noted
in the market place is customers are also exempting themselves from the task of
maintenance, effectively placing the responsibility and cost for keeping abreast of
technological advancement and market trends on the vendor. Though leaving the
vendor responsible for technological advancement can be a risk in itself, the
buyer‘s risk is far reduced.
      These factors, combined with the fact that the majority of resources engaged
for implementation are outsourced, makes packaged solutions easier to budget for
and appear cheaper on paper. The level of control, accountability and reduced risk
makes for an attractive proposition when compared with custom development.
Generally, it is difficult if not near impossible to enjoy all of these benefits when it
comes to building custom applications, in-house or outsourced.
   However, for all these positives, packaged solutions also have their drawbacks.
The most well known of these is that packaged solutions:
    are never exactly tailored to meet all customer needs,
    customers almost always end up purchasing and paying for more
      functionality than they actually need,
    customer complains that their total cost of ownership (TCO) is higher than
      expected for the smaller portion of functionality they actually use

     Implementation teams have a tendency to change (adds to time to the
     Customization generates unanticipated costs
    For the most part these complaints are valid and expected. Packaged solutions,
by definition, strive to be a "one-size-fits-all" solution. They are, therefore,
designed to fit the broadest set of requirements and are void of industry or sector
specific functionality. Obtaining these enhancements often drives up cost
significantly, resulting in a cost to functionality ratio that is difficult to justify.
However, in some instances where vendors recognize that an enhancement will
have broad appeal in their customer base, they will include the feature or
functionality in the implementation at a much-reduced cost. While this was rare
twenty years ago we are now seeing a greater interest by vendors in the public
sector. Governments with shallow pockets soon learn that they are at the mercy of
the vendor when it comes to special programming requests.
    It is then that customers wish they had taken the build route. They start to seek
alternative packaged solutions or reconsider the build option with the intention of
integrating the new solution to their existing system. Integration is, however, not
always possible and often carries a heavy price tag especially when proprietary
technologies, such as electronic data interchange (EDI), are involved. Integration
also has the nasty side effect of increasing the costs of future upgrades, since
changes in any part of a system may cause the integration layer to no longer
operate as initially designed. A simple addition or modification to a field may
cause exceptions and even result in data corruption. The total cost of ownership is,
therefore, forced higher, flexibility is reduced and often it may have been a cheaper
long-term decision to have the main vendor develop the special requirements from
the onset.
    Understandably, this situation is undesirable from the customers‘ perspective
and often leads to tensions in the relationship or worse, a general disillusionment
with ERP as a whole. The customer expects to purchase a packaged solution free
from the constraints of the vendor and retain the ability to develop deep industry or
sector specific functionality that will improve their overall development of
customer relations, increase efficiency, reporting and productivity—all the items
for which they bought an ERP system in the first place.

Build (Custom Application)
      In the face of advanced packaged solutions, support for building custom
applications has waned but did not die a silent death, and it is, therefore, still
possible to find governmental entities that prefer to build their applications. When
asked why they prefer this route, the answer most commonly given is:

      "When we surveyed the market, we did not find a packaged solution
      that met all of our business requirements or could integrate to the
      existing systems."
       The key advantage of the build option is that governmental entities can
create applications that match 100 percent of the nuances particular to government
– and in Texas our business processes have a tendency to have to change every two
years. Most custom applications are also more closely aligned with user
requirements, and therefore increase usability, reduce training, and generally
promote the user experience and level of satisfaction with the system.
The additional advantage is that governmental entities only develop the
functionality they require and are, therefore, not paying for features or
enhancements for which they do not have a use. This comes with the added
benefit of not having to pay ongoing annual license fees (ALF). Object-orientated
development techniques that enable a building block approach to creating
applications have significantly reduced development time-scales. These factors,
combined with cost-effective, coding shops, have in many cases taken the shine off
packaged solutions. The result being that the build option is once again enjoying a
rise in popularity.

Now, for the Bad News.
       As mentioned in the previous section, it is difficult to accurately place a
timeline on custom development initiatives. Estimation of project duration and
costs is, therefore, often speculative. Functionality must be built from scratch, and
project scope and process modeling need to be completed and understood before
development begins. Getting either of these wrong may result in significant
overruns to timelines and budgets.
       Governmental entities that select the build route also assume the risks of
implementation, maintenance, and have the responsibility for keeping abreast of
technological advancement and market trends. Failing to do the latter may often
result in the custom system being rendered inept from technical and business
perspectives. When this happens, the result is often a scrapping of millions of
dollars in labor in favor of a packaged solution that can be quickly implemented in
order to avoid market fallout. So the argument for and against either option is ―six
of one, half a dozen of the other‖. Both routes offer great benefits, but without any
ability to reduce or eliminate their negative qualities. What governments need is
the ability to leverage the pros of both build and buy options while being able to
avoid the negative qualities. They really need something in between.

Somewhere In Between
   Does such a place really exist? Yes, new technologies have emerged that are
widely considered to be sufficiently mature as technology platforms that can be
used for development and solving business problems. These technologies include:
    Extensible mark-up language (XML)
    Managed code realized in Sun J2EE and Microsoft .NET
    Component architectures
    Full Web based architecture
    Data Warehousing
    On Line Analytical Processing (OLAP)
    Artificial Intelligence (AI)
    Business Intelligence (BI)
    Geographical Information Systems (GIS)
    Enterprise Performance Management (EPM)
    Customer Relationship Management (CRM)
    Leading vendors of packaged solutions have already incorporated many of
these key technologies into their product offerings, resulting in what can be
described as a system and platform providing the best of both the build or buy
strategies. Ironically, the drive behind providing customers with this choice has
not been due to the problems described previously. Instead, the driver has come
from the customers‘ demand for collaborative commerce (c-commerce).
   C-commerce involves collaborative, electronically-enabled, business integration
among a government‘s internal financial personnel, departments, inter-local
arrangements with business partners, and customers throughout a community. C-
commerce is made possible by means of ERP II, which is the next iteration in the
evolution of resource-planning systems. ERP II adapts ERP functionality,
technology, and architecture to enable the deployment and interoperation of
enterprise applications both internal and external to the virtual boundaries of the
enterprise network.
   The demand for "something in between" combined with the new environmental
requirements and demands of c-commerce and e-commerce has had the following
effect on vendors. It has made them aware that it is impossible for any single ERP
vendor to develop packaged solutions that cater to the thousands of imaginable
business applications that will deliver governmental specific functionality in all
vertical applications while continuing to assimilate applications and functionality
in the core processes. However, in order for vendors to qualify for entry to the
ERP II arena, they are required to provide customers with a way to create what
many call "next generation" applications. These factors demand change to the
functionality, architecture, and data of resource planning systems to accommodate
the characteristics of "next generation" applications that will:

    make extensive use of existing enterprise applications and business logic as
     a business process infrastructure – just what is required
    make significant use of freely available, open, and standard based
     integration and connectivity resources,
    have a small technological footprint relative to the core technology stack or
     core applications
    Resource planning systems that enable ERP II deployment capabilities are
finally helping governments to realize the "somewhere in between." They give
governments the basic functionality for which ERP is known, while enabling an
extension or expansion in functionality from this position. Furthermore, they give
the governmental entity the agility and flexibility to develop (build) or choose
other best-of-breed vendors (buy), and so craft a system that can be easily adapted
to business requirements and next generation applications.

       ERP II helps customers drive business change and innovation while
reducing IT costs and complexities. Going forward, governments that incorporate
an ERP II strategy will be better positioned to focus on their vertical strategies
through increased, deep, industry specific functionality or any unique functionality
to the government. As momentum grows, traditional core functionality will
increasingly be viewed as a commodity. Next generation applications will
undoubtedly become nothing less than the future of enterprise software. As we
move into this era, governments will be increasingly forced to rethink some of its
conventional wisdoms and traditional approaches to application development.
From the limited scope of this discussion, perhaps the most important of these is
the ―80/20 principle‖. This principle advocates that nearly 80 percent of any
custom development effort is focused on overcoming historical problems related to
core technologies, data access, security, query, and user interface. The remaining
20 percent is spent on actually developing the business end of the solution and
focused on needs for tomorrow and tomorrow. These new technologies and ERP
II compliant systems reverse this principle so that 80 percent of the development
time can be focused on developing the business processes for tomorrow. The
result should be custom business solutions built on the business logic inherent to
packaged solutions that more accurately meet both the business and user
Peter Cass, ―Software A Terrible Thing To Waste,‖ CFO IT (October 15, 2002)
G. Pleasants and B. Hayes, ―Financial Application Choice is Irrelevant in Achieving World Class
    Performance,” Hackett Perspective (April 30, 2004)

                                 CHAPTER IV
                        The Decision Making Process
    The strategy for finding the right financial software for a county is to
understand how the county functions and how many parts are related, or should be
    SHOPPING FOR FINANCIAL SOFTWARE is difficult. The software must
     be just the right size, it shouldn't contain more or fewer features than you
     need and you should feel secure that its publisher will be able to provide
     upgrades, fix bugs as needed and provide timely training on a continuous
    IT'S NOT ENOUGH TO EXAMINE the package's specifications and
     understand its myriad features; you must have both a comprehensive and
     intimate understanding of your organization's business operations and the
     various processes that it uses.
    IF THE COUNTY DOES ITS JOB CORRECTLY and diligently, it will
     discover it is developing a far more comprehensive and detailed picture of
     the county‘s financial relationships than were imagined, and which will give
     management the opportunity to create a financial structure that will allow the
     county to function more efficiently. For the analysis function will not only
     identify current needs, but also future requirements – and the needs
     assessment will develop the goals that the county will set its sights on.
      First time shoppers for a fully integrated financial system when asked to put
down their ten basic criteria usually list the criteria as follows in order of
   1. Functionality of the software
   2. The price of the system
   3. Ability of the software to integrate with other business needs
   4. Ability of the software to function with the existing hardware
   5. Ease of implementation of the software
   6. Quality of the documentation
   7. Is the software user friendly
   8. Will the software grow as your system matures
   9. The vendor‘s track record for performance (with confirmations)
   10.The level of support to be provided by the vendor
      However, when a government is contacted that has been through the process
on several occasions they will usually alter the order of importance as follows:
   1. The level of support to be provided by the vendor
   2. The vendor‘s track record for performance (with confirmation)
   3. The software‘s ability to fit the County‘s needs
   4. Growth potential of the software
   5. Cost of the software – cost of modifications – cost of annual maintenance
   6. Quality of vendor documentation
   7. Functionality of the software
   8. Ease of use (i.e. training of current employees – training of new employees)
   9. Ease of implementation of the new system (transfer of files)
  10. Existing hardware and software are compatible.
      It is important that the County examines itself carefully and put its priorities
in order and as one can see the order of priority has changed from internal
functionality to external support. And, as mentioned earlier the County needs to
evaluate whether it is looking for a tool, a technology partner – or both.
   In addition there are many other questions that one needs to make sure are
answered related to the decision. One county in Texas listed some 3,019 issues in
their Request for Proposal when looking for a partner to provide their financial
software. And, another listed some 752, but both failed to ask:
    Does the software provide customization tools?
    Is the vendor financially sound and reliable, and can it provide the technical
      resources my organization will need?
    Can the product deliver the type of financial reporting I require?
    Will the underlying technology meet my current and future needs?
    Is the product's account-number structure suitable for my business?
    Since e-business has become so important, does the package provide Web
    Can it handle foreign currency?
    What is the time frame for installation and implementation?
    Will it provide Grants management?
    Can it handle both project accounting and work order accounting?
    Can it handle electronic signatures?
    Can it provide trust funds management?
    Can it handle electronic banking?
    Can it handle cost allocation at various levels?
The Decision Making Process
       One of the most challenging tasks a county can face is the selection of a
financial software package that matches the needs of the county. The product must
be just right: It shouldn't contain more features than needed (which adds to its cost
and makes it more complicated and difficult to use), it should incorporate features
that streamline the operation of the county and it should be easy enough to
customize to the unique business needs of the county – the software shouldn‘t
require departments to take on more manual accounting operations to compensate
for the software's limitations. Finally, the county should feel confident during the
many years that the software is in service that its publisher will be able to provide
upgrades and modifications as needed.
       To be able to recognize the right product and therefore the right vendor, the
County first must have both a comprehensive and intimate understanding of the
organizational structure, workforce allocations and financial operations.
Understanding the various business processes that are being used and how they
translate into business "solutions" - the industry term for how the software will
handle tasks such as payroll, procurement, banking, inventory, accounts payable
and budgeting. And for some counties, that will include tracking and managing
employees' work hours and related benefit hours, as well as construction projects
and long term financial projects.
       As you can appreciate, such a search is not an afternoon assignment. It often
takes months of arduous research and evaluation. But there is a bright side to this
effort: If a county does the job diligently, it will discover that it is developing a
panoramic picture of its organization that is far more comprehensive and detailed
than was originally imagined. In the process the County will see how its various
business processes interlace, or don't interlace, with one another. Those insights
will provide the County with the opportunity to redesign current processes that, in
the long run, will make the County run smoother and more efficiently. It should
also be considered that the County will need to evaluate its current business
practices. To alter software to conform to current processes is a lot more
expensive than changing the current culture.
      You're probably thinking, "But I thought today's financial software was so
smart that it could adapt to run any kind of business?"

       There's some truth to that statement, but that's not the whole story. Even
today's $49 accounting software is "smarter" and, given its capabilities, far less
expensive than the most sophisticated packages of a generation ago, whose one and
only job was to keep a set of self-balancing books. But price notwithstanding,
users expect today's financial software for governments to do more than just
bookkeeping. Loaded into the latest packages are hundreds, if not thousands, of
sophisticated solutions capable of fully running a multitude of the financial
processes of a county. Since each software product has its own unique set of
solutions, in addition to basic bookkeeping--which remains common to all
financial software--it's not hard to understand why the search for the right product -
one that matches solutions to your needs - is so complicated.
       One of the biggest reasons that the implementation of new financial software
fails today is modification – modifying a system to function the way the old one
functioned. The second biggest reason is the opposition to change management.
Third is the customer‘s failure to have a well trained implementation team with a
qualified project leader. And, fourth is failure to provide continued education –
       Another reason why the selection process is so important: Fully installing a
new financial system is expensive and requires many hours of management's and
your technology staff's time. Personnel need to be dedicated to the project from
start to finish – and continuing education programs need to be established within
the County to insure that end users are able to get the maximum benefits out of the
system. If the County later learns the product is not up to the job, it will find itself
faced with having to repeat the whole process. So the County wants to get it right
– The First Time! None of us need to be reminded how highly charged the
political environment is that we work in. In the selection process a County needs
to be sure that all departments have an opportunity to participate and to be part of
the implementation. You want everyone to be on the same cart when the wheels
begin to fall off, and therefore, they can be part of the problem as well as part of
the solution
       It is interesting to note that in many counties that have moved towards
electronic processing of financial information that as time goes by, the software
and the organization tend to accommodate each other - that is, management
customizes the product to better suit its needs, while at other times, we see various
departments readjust their business processes to either compensate for the product's
shortcomings or take advantage of the software's better way of undertaking a
business process. At better-run counties that have successfully implemented well-
matched software to begin with, most of the adjustments result in streamlined and
automated operations. In counties that seem to have implemented ill-fitting
software, more of the tinkering to accommodate software deficiencies results in

slower and more manual accounting processes. And the county does not benefit
from many of the financial benefits available in modern software. In effect the
county has become a slave to the software. If truth be told, many counties are
either fully or partly enslaved by their accounting software, which is why installing
a new system is an opportunity to redesign the way that we do business.

Steps To Follow In The Decision Process
   When you're ready to determine which financial software product best suits
your county‘s needs, these steps provide a framework to be built on to insure that a
successful search, installation and implementation occur.
   1. Establish a Steering Committee: This first step is a must. The Steering
      Committee‘s job is to oversee the entire operation--from specifying the
      product to final implementation. The Steering Committee team should be
      recruited from every department so the needs of every part of the County are
      considered. However, in order to work efficiently with the vendors, there
      should be an executive management committee created from within the
      Steering Committee which is made up of four to six members. This may
      mean creating subcommittees that report to the management committee.
      The management committee should include a member of the commissioners‘
      court, a member of the county auditor‘s office, a representative from the
      information services department, the county treasurer, a representative from
      the criminal justice information system and possibly a representative from
      the tax assessor-collector‘s office. And, as we will see it may be advisable
      to include a consultant.
                Note: Be aware that when faced with a project as large
                and technical as selecting new financial software, some
                managers try to avoid being involved because they feel
                insecure about technology. As a result, they may try to
                shift key decisions to the technical staff. There's no
                doubt the IT staff should be fully involved, but since
                techies are not financial managers, their counsel should
                be limited to the technology itself.
       The Government Finance Officer‘s Association (GFOA) recommends that
the steering committee should establish a ―Project Charter‖ (see Attachment E).

   2. Prepare a ―needs assessment:‖ This requires the inclusion of a lot of staff
      from all offices for a considerable period of time. The County‘s ―project
      manager‖ should be the moderator of the meetings and provide for each
      function that is going to be considered to be addressed in a committee setting
      where everyone is comfortable speaking their mind and all ideas are worth
   being developed – as to be kept or      thrown. The functions that may be
   considered are:
         Fund Acctg./General Ledger         Asset Management
         Cashiering                         Accounts Receivable
         Procurement                        Accounts Payable
         Project Accounting                 Cost Allocation
         Grant Accounting                   Warehouse Inventory Management
         Budget Development                 Personnel Administration
         Payroll                            Position Control
         Time and Leave Reporting           Benefits Administration
         Applicant Services                 Classification and Compensation
         Employee Self-Service              Training
   Each office needs to have their needs met – maybe not 100% - but changing
   business practices will allow some do more with less. It should include all
   the functions of their office that affects either directly or indirectly a
   financial process of the county. Then have them separate the list of tasks
   into mission-critical (there is an economic impact if this task is not done)
   and those that are not mission-critical (it would be nice if it was available,
   but it has no major impact on the department, the department can continue to
   function as is). The needs assessment will develop deliverables that are
   requirements (See Attachment B and C for examples).

3. Flow charting: Each office should be asked to come to their meeting(s)
   with their office functions listed and if at all possible to prepare flowcharts
   to diagram how they perform those tasks--that is, the step-by-step processes
   for making decisions and the steps required for each action. In other words,
   you want a panoramic, full-dimensional map that shows how paperwork,
   information and decisions flow through the organization - or even how they
   get bottled up. The more detailed the flowcharts, the better you will be able
   to see how, or whether, a modern financial software program can handle
   many of these duties.
   During this analysis have the managers gather samples of every form
   (checks, receipts, invoices, purchase orders, payment authorizations,
   reimbursement requests, etc.) and every report the current software
   produces, and those reports that have to be prepared manually. Don't forget
   all those systems outside your financial software that handle supplemental
   duties: spreadsheet reports and analyses and word-processing documents.
   The analysis likely will determine that some are not needed, but many of the
   necessary ones probably can be integrated into the new financial system.

4. Requirements Definition - From the flow charting process the County will
   be able to develop a requirements definition - a detailed document that
   defines what each department needs from a financial software application.
   This document is the passport to a successful project. Don't try to make a
   purchasing decision without it. A well organized requirements definition
   will assist the County in:
         Matching a system to the real world
         Identifying user controls and freedoms that will be required
         Developing consistency and standards for the system
         Designating those areas where the system can assist in error
         Defining those aspects of the system where recognition is required
            and not just recall
         Assuring that flexibility and efficiency of use is incorporated
         Developing error recovery, and
         Insuring that help menus are designed to help the user

4. Consider engaging an independent consultant. After seeing how much
   time and effort must go into preparing a requirements definition and
   depending on how much time you have available and your technical
   resources, you may decide now that the project is beyond your capability. In
   that case, engaging a consultant is a wise choice. You will want someone
   familiar with your industry to prepare the requirements analysis and to help
   you make the final selection.
            Note: Be sure that the consultant is not connected to any
            specific software vendor or you'll be getting a biased
            sales pitch rather than an independent product
            assessment. Once you've made your product selection,
            you want a consultant who is familiar with, and even
            close to the vendor and has installed and implemented its
            software several times.

5. Talk with the County’s current vendor. Unless you're unhappy with the
   County‘s current financial software vendor, now's the time to see whether
   your current software product, or an update of it, plus some well-focused
   training, can spare you from having to go though the expensive and arduous
   task of buying and installing new software. The key to making that
   determination is the analysis you just went through. Present that detailed
   analysis to the vendor and see whether an upgrade will meet the county‘s
   needs. Assuming an upgrade is not the answer, you've now reached the
   point where the Steering Committee must select candidates that is,

   vendors/products that approximately fit the county‘s needs based on your
   organization's size and complexity.

6. Prepare a formal request (RFP): A proposal that would delineate each
   area of functionality that the vendors are to respond to as well as other
   questions for them to answer. Be sure as many vendors as possible are
   invited to participate, and don‘t discount those vendors who wish to
   collaborate jointly on the proposal.
       Note: Today it doesn‘t make much sense to ask for a price
       quote until you have selected a vendor. If you take a product
       right off the shelf without any modifications there is a standard
       price. But once you start modifying the existing programs the
       price will change. Also, one has to understand what is standard
       for one vendor is an add-on for another. The price tag is only
       part of the product's real cost. Other expenses, including
       maintenance and the long-term cost of operating the product,
       make up a significant portion of the full cost. Another factor
       that drives the total cost of a product is implementation--the
       expenditure, in dollars and in time--of loading the software and
       creating the appropriate data links and mapping pathways for
       the data to travel. Again, there is a relationship between a
       product's complexity and its implementation cost. In addition,
       accounting software carries with it an annual maintenance fee
       that ranges from 10% to 20% of the retail price.
       Remember - Governmental financial software is designed to
       meet the general needs of the industry that uses fund accounting
       and financial management systems. The market is divided,
       more or less arbitrarily, into four groups:
     Entry-level (Entry) software is designed for smaller not-for-profit -
      those with revenues of less than $10 million and with up to 99
      employees. And, not more than 20 simultaneous users on the system
      at the same time. It's estimated there are about 20 million non-profit
      entities in the country fitting this profile.
     Software for small to medium not-for-profit is engineered for entities
      with revenues $10 million to $100 million and no more than 1,000
      employees. And, there are no more than 100 concurrent users on the
      system at any one time. It is estimated that there are about 8 million
      not-for-profit entities that fit this profile.
     Small to medium enterprise (SME) software is designed for
      organizations with revenues of up to $500 million and as many as
       5,000 employees with 1,500 concurrent users. Some 400,000 not-
       for-profit entities are estimated to make up this category.
     Enterprise resource planning (ERP) software is for the largest
      governmental and not-for-profit entities with revenues exceeding
      $500 million and more than 5,000 employees, and more than 1,500
      concurrent users. An estimated 80,000 entities fit this profile.
      If your County‘s financial needs are complex, you may want to choose a
      software product one step up in order to insure maximum flexibility.
      Likewise, if your county‘s financial needs are relatively basic, you may
      be able to drop down a size. The County will save money if you can use
      a product in a lower category. Recognize that a lower-category product
      has fewer features, but your analysis may show you don't need those
      missing features.
      The reverse is true for a higher category product. Generally, the higher
      the category, the more capabilities and features you have - such as
      workflow, imaging, business intelligence and sophisticated analytical and
      accounting functions. It follows that the higher the category, the larger
      the initial and long-term costs.
      Be aware, too, that if the County selects a product with too little
      capability, it will usually have to recruit other applications, such as Excel
      and Access, to perform tasks the accounting software can't handle. Such
      fill-in resources are called "renegade" systems, and in the long run, they
      cost more to operate than systems built into the accounting software.
      That's because data usually have to be reentered into the fill in resources,
      and that can cause errors and duplications. It's estimated the annual cost
      of running renegade applications rises exponentially as the complexity of
      the accounting software they support increases.
7. Evaluation: Once all the responses are in they will need to be evaluated so
   that all can be placed on a comparative platform. List product features. The
   Steering Committee‘s list of features should prioritize those that are
   ―required‖ those that are ―needed‖ and those that the county could function
   without. In addition, Steering Committee members should talk to others in
   their particular area of functionality - even those in other states - and ask
   how they might assess a financial product. So that the products can be
   evaluated side by side, consider preparing a spreadsheet matrix listing key
   information for each functional aspect. For example, your spreadsheet
   might include information on budgeting, accounting, human resources,
   payroll, bar coding, customization capabilities, implementation, etc. Focus
   on the most important capabilities; don't be sidetracked by insignificant
   shortcomings. This matrix also will allow the county to share information
with others in the organization that may be able to provide input into the
ultimate decision. It will also allow vendors to better understand questions
that the county poses in attempting to clarify vendor responses. (Remember:
a ―not available at this time‖ response to a functionality question should be
placed as a ―No‖ in the response matrix.) Be prepared that a vendor will
need to include software from a third party – is third party software going to
be accepted and if so at what level.
In addition, add to the matrix a list of the features and facts that impress you
about the software vendor and the product. For example: mention key
awards the product received; or, the fact that the company provides great
support; or, describe an outstanding feature particularly beneficial to the
county. Don‘t forget the training function – this is one area that you will
need constant support for.
Once your list is complete eliminate the obvious poor choice - that is those
missing key modules and features or were unable to provide direct responses
to inquires and had to insert long discussions on issues of functionality. In
evaluating the functionality of a financial software package a county should
not include price as a factor for comparison. Price of a package should be
placed on a separate matrix for comparison. Price alone should not – repeat
should not be the decisive factor. Prohibitive as some higher-end packages
may seem, they may actually help you make money, thus giving the County
a good return on your investment.
As vendors are crossed out, note why the County eliminated them, in case
someone asks later why you did not consider a specific vendor – and they
will. Selecting the right package is mostly a process of eliminating the
wrong ones. In the County‘s assessment of the vendor‘s response, the
county should always consider:
      Need for IT operational and support personnel
      Training for users
      Data conversion
      Training
      Continuous upgrade of programs
      Training
      Business continuity provision
      Training
      System backup techniques
      Training

   Training must be adequate from the get-go. It must be through during the
   implementation and should be on going. This either requires proper staffing,
   or it requires a commitment from the vendor. If adequate training does not
   take place, and is not offered on an on-going basis, new employees will only
   find themselves being trained by old employees. This only means that
   whatever bad habits the old employee learned, have now been passed on,
   and the full usefulness of the system will not be obtained.
   Use the Internet to extend your research of the vendor. Visit vendors' Web
   sites, seeking the strengths and weaknesses of each product. To get
   independent reviews of products, use Internet search engines such as Google
   ( com) to find articles and comments from customers. Print
   key pages from these Web sites for later reference. And if one gets to the
   point of saying this is too difficult – that we are not able to discern among
   the responses – then it is time to bring in a consultant that does this for a
   living everyday – and there are several out there.
8. Demonstrations: Once the field has been evaluated and the playing field
   has been trimmed down to two or three possible contenders, the contenders
   need to be formally communicated with and demonstrations requested.
   Request live product demonstrations. Invite the leading candidates to
   demonstrate their wares for you. Provide each with a list of the top 10 to 20
   functions you want to see. Insist the vendor use live software to demonstrate
   the product - not some presentation software or a "canned" demo - one that
   promotes just the product in a general way; you want to see the product in
   action - showing how it handles your specific needs. The ideal presentation
   would be at a site where the software is installed and functional. Ask the
   vendor to be prepared to demonstrate specific components that make the
   product better or different than the competition. Each vendor should be able
   to do a full demonstration in two to four hours, but some bigger programs
   may require eight hours or more.
   Ask the vendor for two current customers that are relatively the same size in
   budget, personnel, volume of invoices, and governmental structure, for you
   to visit. A good visit usually takes three to four days to see the full cycle of
   the software at work.
   Ask the vendor about its method of installation, its track record for getting
   its system up and running on time and a list of up to five references that the
   county can call. Customers usually are happy to share their own experiences
   and give valid tips so you do not make similar errors. Call as many
   references as you can, but focus on three specific types:

             a) A customer who has been on the system for at least 13 months,
                because you want someone who has gone through a yearend
             b) A governmental user that is similar to your county‘s profile
                (that person will be able to relate to your county, your language
                and your needs and tell you how close the product comes to
                meeting your specific industry needs),
             c) A customer who has had the application for 120 days or less
                will be in the middle of an implementation and can tell you
                about problems discovered after starting the conversion (this
                information can save you a lot of money, time and headaches).
   Another consideration is to do a prototype testing. The county would
   download an evaluation copy. Take the time to load it with your sample
   data to insure the software meets your specific needs. Such a test provides
   important information:
             a) It validates the software against your data and the difficulties
                you may encounter during the conversion stage of
             b) It gives the IT staff an opportunity to develop deployment
                scenarios and determine how expensive the product will be to
             c) It allows the county to test the transaction formats and the
                reporting modules for flexibility, and
             d) It allows the county to test the month-end closing procedures.

9. Contract Negotiations: Once all vendors have been evaluated and once
   pricing has been considered, as well as budgetary constraints, the County
   should hire a contract attorney to assist the county during the contract
   negotiations. To assist the attorney there should be a negotiating team put
   together to do battle with the vendor. The vendor has to be aware that the
   negotiating team has the authority to consummate a deal for the county. The
   contract should include:
     i.   Spelling out in layman‘s terms as clearly as possible all the
          terms of the contract,
    ii.   There should be nothing left to interpretation, the definition
          section of the contract is very important,
   iii.   The support agreement is as important as the purchase and
          implementation part of the contract,
   iv.    Delivery dates for product need to be clearly stated,
    v.    Penalties for failure on either the parties to perform should be
       vi.   Payments should only be based on delivery,
      vii.   Continuing education and training should be established,
     viii.   What measures the county will be required to take if the
             software does not work,
       ix.   If the county has access to the source code, and
        x.   What if the vendor goes out of business or merges with
               Note: Include in the final contract a copy of your
               requirements definition and your RFP or RFQ to be sure
               there is agreement between what you asked for and what
               you got. You may have to update the documents slightly
               to include any final changes or compromises. Make sure
               all communications, including the vendor's response to
               the RFP, are part of the agreement you are signing. The
               County wants to be sure milestones and objectives are
               clearly defined so everyone knows what is expected.
               Important: Spread payments out so the vendor still has
               an investment in the success of the project.
      If you have followed all the steps above, you should be exhausted, but you'll
also be ready to make a qualified, informed decision.

                                   CHAPTER V
                     BUSINESS INTELLIGENCE

       Business Intelligence (BI) must be demand-driven, which means that the
business needs of the user dictate the technical solution, not the other way around.
In other words, it should let the business users drive the process, and remove the
problems of content relevance and software complexity. Namely, although IT-
driven BI projects frequently do not deliver what the end users‘ need. The BI
development cycle is inherently itemized and open-ended and therefore the
business decision maker needs to ―own‖ the process. Thus, the vendor‘s solution
should address the problem of content relevance by making the underlying data
architecture transparent to the users, who have access to information from multiple
systems, platforms, or locations, and view it in a functional user interface.
       To that end, in the software selection process one needs to ensure that the
appropriate business rules are applied and the information appears in a consistent,
integrated context (whereby the user environment allows business users to identify
and retrieve exactly the information they need), and provides easy-to-use tools for
analysis. The value of information increases dramatically when business decision
makers drive the process, by having precise control of the reporting and analysis
process. In the context of real-world customer deployments there needs to be an
approach that emphasizes a clear separation of responsibilities. That is to say,
business people, from front-line decision makers to strategic department heads are
the key users of the solution, and they are responsible for creating and using the
information, reports, and analytics.
       A core concept of any financial software solution is the automated
publication and delivery of analytic content to end users, as the deployment
module automatically generates and ―pushes‖ customized, updated information and
related views to business users. These ―information views‖ are user-defined,
personalized data sets, in the form of a client-side on-line analytic processing
interface, with intuitive data analysis, report writing, and graphing capabilities built
in. Further, with user-defined ―information views‖, which combine data from
single or multiple data sources, users view this information in close to real-time
without necessarily relying on a data warehouse or repository. Business users
receive ―information views‖ on a predefined schedule via e-mail, or over a
network, or by accessing a Web page.

       This application concept ensures that the majority of the analytical
processing of content occurs "off-line" on the user‘s PC, rather than over a network
connection. Users should be able to filter, drill-down, modify, and preview the
customized ―information views‖, whereby the level of customization and end-user
control is such that the user very rarely needs to generate ―live‖ queries against the
relational databases. This also significantly increases the scalability of the solution
by delivering compressed data sets during off-peak hours. The three most likely
common types of direct queries are:
            1. Content building - users are creating new ―informational views‖ for
               analysis or distribution to other users.
            2. ―Drill-backs‖ - end users, who receive a summary ―information
               view‖, analyze the data off-line, then drill back into the relational
               database for more information to support further analysis. (Drill-
               backs are typically targeted, exception-based result sets that are small
               and can be processed efficiently.)
            3. Pure ad hoc analysis - when operational and execution-based real-time
               queries—typically to support specific business decisions—are
               executed by a relatively small number of users.
       Since each of these types of direct query has significant business value, and
is therefore essential to the software solution, there would need to be a study
conducted to determine the frequency of each type of query. The software
application should be designed to support these users with a higher level of system
performance.      Further tuning of the system occurs during customer
implementations, to account for the specifics of their infrastructure and user base.
Overall, the software requirement should be focused on providing automated
content publishing and managed database access allowing for an efficient,
scaleable model for enterprise information delivery: for example:
            AP analytics
            GL analytics
            Purchasing analytics
            Receipt analytics
            Performance indicators
       There needs to be a concerted effort to share information across the
government as a whole. To do so the County needs to identify emerging trends
and specific needs more quickly and accurately. BI solutions need to be developed
that will give the County managers a competitive edge. To that end, predefined
analytics fully integrated with the financial software applications should be
developed to enable users to conduct on-line and off-line analysis, and consolidate
reporting on a wide range of business processes including position control, cash
flow, budgetary analysis, receipts, purchasing, and inventory.

       A new financial system should have a reporting application that includes a
suite of pre-defined ―information views‖, report templates, graphs, and
performance indicators, supported by a flexible information architecture - that
enables direct mapping to virtually any data base system. The reporting system
should have the capability to combine and compare data from multiple sources and
different internal business functions, and in addition to its above-described ad hoc
analyses, personalized reports.
        Successful business intelligence (BI) projects encompass more than
implementation of a solution on time and within budget. True success should be
measured by how the BI solution improves the government‘s overall performance
through increased efficiency in reporting, planning, financial functions, and
performance measurements. This will help ensure the government‘s BI projects
fall into a pre-defined success rate.
        Much has been written about measuring return on investment (ROI) for BI,
and the general conclusion is that gaining tangible insight into the initial benefits is
not easy. Identifying long-term benefits becomes more practical as planning and
analysis, compliancy, and forward-looking approaches become more mainstream
within an organization. To gain insight into how to implement a BI solution
successfully, a government should benchmark the success of other governmental
entities, including their implementations and use of BI, against their own current
initiatives. It is equally important that governments learn from other organizations'
failures—and avoid repeating them.

    Going forward with a BI solution the County needs to understand and explore
the five basic steps that a government should take to avoid common pitfalls
encountered by many entities when implementing a BI solution. These areas
     the identification of the business problem,
     BI tool use,
     the delivery of data,
     training initiatives, and
     development of a framework toward choosing the proper solution for the
These five areas provide an overview of items that should be identified before an
entity attempts an implementation of a BI solution.

Step One: Identifying the Business Problem
       Identifying the BI business problem is the first step to ensuring a successful
project. Once a government is able to identify what is broken, not only can it start
to find ways to fix the problem, but it can also identify the proper resources, create
buy-in, and prioritize how to tackle the project. To produce an ROI, a BI solution
needs to correspond to an entities business problem; otherwise, implementing an
ad hoc query tool, or an online analytical process will not create lasting benefits.
        Unfortunately, it is common for BI solutions to be pushed onto a business
unit in order to meet an information technology (IT) objective rather than an
organizational need. Sometimes, governments get caught up with general
initiatives and lose sight of the actual benefits BI provides in terms of performance
management, collaboration, workflow, process improvement, etc. To attain buy-
in, the end users should be a part of the problem identification process. An
implementation decision that comes from management still requires input from
users as to what their requirements are, and this information can make the
difference between the implementation of a tool that works as a value proposition
and an implementation that may be seen as useless.

Step Two: Determining Expectations of Use
       Once a BI solution is implemented within a government, its usage usually
grows beyond initial expectations. For example, an organization may assume that
its BI implementation will involve 10 to 20 users, when in reality; over 400 users
would query data on a monthly basis if they had the capability to do so. Based on
the initial design of the platform, the system may not be built to sustain such a high
number of queries, and will most likely "crash" (fail), causing users to lose faith in
the new system and potentially revert to their pre-BI environment for stability.
       In addition to a lack of confidence, getting an unstable system up and
running may not seem worth the effort, delays, or time it would involve. With
unrealistic expectations, frustration may cause the organization to rethink its use of
BI. Generally, once BI adoption occurs within one part of the organization, other
departments or business units see the benefits, and adoption begins to spread
throughout the organization. For a government to meet these needs, the anticipated
use of BI should be determined beforehand.

       Another consideration is the type of BI tool that is to be used. For example,
when a department manager is evaluating staffing requirements they may need to
analyze receipt trends, case distribution, and employee performance, and creating a
set of static reports will not produce the appropriate results. A data visualization
tool to manage these items and develop a plan based on trend analysis will more
likely produce the appropriate results.

Step Three: Understanding Delivery of Data
       The collection of the right information for reporting and analysis becomes
essential to deliver value to the operating departments. Although the identification
of required data is time consuming, it is the backbone of BI. Additionally,
identifying how data will be delivered, what the appropriate data cleansing
activities are, and whether data is delivered in batch or in real time should be
defined in advance. If data is not cleansed or delivered when needed, then the
front-end BI tools will not provide the proper value to the organization. BI
solutions provide value through the analysis of data, so it is essential for data to
arrive when required, in the proper format, and at the right time. In addition to
extract, transform, and load tools, data quality and data cleansing need to be
inherent aspects of the delivery of BI within the organization. In reality, short of
an organization-wide master data management initiative, the responsibility of
providing accurate data will fall on the shoulders of the operational units
implementing BI.
       `Some organizations are misguided and think that their BI solution will
provide them with the tools to fix their data problems. BI solutions can provide
ongoing data quality processes, but these are not innate to software offerings.
Some BI tools include enhanced data quality and integration features, and some
vendors assume this responsibility should fall to the organization. Governmental
entities Organizations should implement data management structures to minimize
frustrations that result from data issues.

Step Four: Rolling Out Training Initiatives
Deciding when to roll out training contributes to project success. Training
initiatives should begin right before or during the implementation phase. However,
in many organizations, training is rolled out months before actual implementation,
creating hype among the employees about the new system and what they will be
able to do with it. By the time implementation actually occurs—months later—the
initial excitement and buy-in has subsided, and more importantly, users have
forgotten their newfound skills. To build momentum again, training needs to be
repeated—wasting time and money.
       Buy-in related to change is never easily achieved within organizations.
Users become attached to their current processes whether or not those processes
are productive. Buy-in does not occur immediately upon showing users the
inherent value of BI, as their whole way of doing business will change. Creating a
training program and delivering that training in a timely fashion helps users apply
their newfound skills immediately, and helps to increase user buy-in.

Step Five: Choosing a Vertical or Horizontal-based Solution
       Organizations should identify whether more value will be provided by a
vertical solution that is built specifically for the governmental entity or just a
department, or by a horizontal solution that can grow with the entity. For example,
does the entity need a generic reporting, querying, and analysis tool that will
extend across the entity, or does the entity need to develop a process and
compliancy that will adhere to established standards? The answer will help the
entity define which type of solution will best meet its needs.
      In addition, the use of BI in the future and its anticipated usage may help
determine whether a horizontal or a vertical solution will best meet the
organization's needs. A governmental entity requiring compliance should take
advantage of vertical-based solutions because vendors have developed solutions to
meet specific compliance requirements. Horizontal solutions normally need
intense customization to bring them up to par, leading to extra time and money
spent on the developmental phase.
       Governments for the most part need vertical based solutions that will meet
their immediate needs out of the box. Vertical-based solutions are likely to meet
the general requirements of the government as a whole or a department, but since
horizontal BI solutions do not base themselves on specified data models, they are
usually more versatile to the changing demands of the organization. Therefore, if a
County anticipates rapid BI growth across the organization, having the ability to
develop solutions based on individual needs may be more beneficial. This relates
to identifying the business problem and anticipating the future needs of the

   All too often, BI projects fail to meet an organization's expectations. But with
research, planning, and a solid methodology, such failure can be avoided. To help
ensure BI project success, organizations should work through these five essential
   1. identifying their business problems,
   2. determining how they will use their BI solutions,
   3. knowing how and when data is delivered,
   4. rolling out user training initiatives at appropriate times, and
   5. developing a framework for selecting the type of solution that will best fit
       their organizations' needs

             What is Enterprise Resource Planning (ERP)?
What Is ERP?
      Enterprise resource planning software, or ERP, doesn‘t live up to its
acronym. Forget about planning—it doesn‘t do much of that—and forget about
resource, a throw away term. But remember the enterprise part. This is ERP‘s
true ambition. The software attempts to integrate all departments and functions
across a government onto a single computer system that can serve all those
departments‘ particular needs. Building a single software program that serves the
needs of people in finance as well as it does the people in human resources and in
the warehouse is a tall order. Each of those departments typically has its own
computer system optimized for the particular ways that the department does its
work. But ERP combines them all together into a single, integrated software
program that runs off a single database so that the various departments can more
easily share information and communicate with each other. That integrated
approach can have a tremendous payback if companies install the software
       Take a purchase order, for example. Typically, when a department places an
order, that order begins a mostly paper-based journey from inbox to inbox
throughout the government, often being keyed and re-keyed into different
departments‘ computer systems along the way. All that lounging around in inbox
causes delays and lost orders, and all the keying into different computer systems
invites errors. Meanwhile, no one in the government truly knows what the status
of the order is at any given point because there is no way for the finance
department, for example, to get into the computer system that controls procurement
to see whether the item has been shipped – and most of the time they won‘t know
anyway. "You‘ll have to call the vendor" is the familiar refrain heard by frustrated
       ERP vanquishes the old standalone computer systems in finance, HR,
procurement and payroll, and replaces them with a single unified software program
divided into software modules that roughly approximate the old standalone
systems. Finance, procurement and the human resources all still get their own
software, except now the software is linked together so that someone in finance
can look into the procurement‘s software to see if an order has been shipped. Back
in the ‗90s ERP was developed as a tightly integrated monolith, but most vendors‘
software has since become flexible enough that you can install some modules
without buying the whole package. Many companies, for example, will install
only an ERP finance or HR module and leave the rest of the functions for another

How Can ERP Improve a Government's Performance?
        ERP‘s best hope for demonstrating value is as a sort of battering ram for
improving the way your government takes a requisition (electronic) and creates the
purchase order (electronic) posts the shipping acknowledgment (electronic)
anticipates the receiving report (electronic) receives the invoice (electronic) assigns
the payment date (electronic) makes payment (electronic) and creates a file of all
documents – all without any paper hitting the table. That is why ERP is often
referred to as back-office software. ERP takes a department requisition and
provides a software road map for automating the different steps along the path to
fulfilling the order.
       People in different departments all see the same information and can update
it. When one department finishes with the order it is automatically routed via the
ERP system to the next department. To find out where the order is at any point,
you need only log in to the ERP system to track it down. With luck, the order
process moves like a bolt of lightning through the organization, and customers get
their orders faster and with fewer errors than before. ERP can apply that same
magic to the other major government processes, such as employee benefits or
financial reporting. That, at least, is the dream of ERP. The reality is not so rosy.
       Let‘s go back to those inboxes for a minute. That process may not have
been efficient, but it was simple. Finance did its job, purchasing did its job, and if
anything went wrong outside of the department‘s walls, it was somebody else‘s
problem. Not anymore. With ERP, the procurement process is no longer just
typists entering someone‘s name into a computer and hitting the return key. The
ERP screen makes all viewers part of the government process – has it been
ordered‖? – has it been shipped? – has it been received? – where? – who? – was it
partial or full? - has it been paid for? But it‘s not just the purchasing who has to
wake up – everyone in the supply chain. Accountability, responsibility and
communication have never been tested like this before.
       And, people in general don‘t like to change, and ERP asks every one of them
to change how they do business. That is why the value of ERP is so hard to pin
down. The software is less important than the changes governments make in the
ways they do business. If you use ERP to improve the ways your people purchase
products and bill for services and provide real time reports – then you will see
value from the software. If you simply install the software without trying to
improve the ways that your government does business you may not see any value
at all—indeed, the new software could slow you down by simply replacing the old
software that everyone knew how to use with new software that no one wants to
learn, let alone how they conduct business.

      Numerous departmental ―shadow systems‖ are required to meet the
enterprise and user department administrative business needs. The term ―shadow
system‖ is used to refer to department-specific systems that provide functionality
required to meet departments‘ administrative business needs that are not met by the
County‘s central administrative systems. Having such a fragmented legacy system
and PC-based environment has the following drawbacks:
      1. Data is fragmented, making it difficult to generate management
         information timely and accurately, especially on an enterprise basis;
      2. Systems are costly to maintain and operate (e.g., data must be reconciled
         among the various systems, numerous interfaces must be maintained,
         etc.); and
      3. Systems are difficult to use – often County employees must work with
         several of these systems, and each system has its own unique ―look and
   The technology of the County‘s administrative system is dated. Many of the
systems are twenty (20) to thirty (30) years old, and as a result:
      1. The County is unable to ―plug-and-play‖ with new (and even not so new)
         technologies (e.g., Internet-based technologies, bar coding);
      2. It is often difficult to modify the systems as the changes require ―hard-
         coding‖ (i.e., changes must be made to the actual computer code instead
         of simply changing data table entries to make the changes as is the case
         in more modern systems);
      3. The County is exposed to significant risk (e.g., some technologies are
         becoming obsolete and will eventually become difficult to replace, and it
         will become increasingly difficult to find technical staff to maintain these
      4. The staff with skills required to maintain these systems are rapidly
         approaching, or have reached, retirement age; and
      5. The systems are difficult to use as they lack the modern, Windows-based,
         common user interfaces that system users are accustomed to using (e.g.,
         e-mail, office applications, Internet browsing). This technology also
         negatively impacts the ability to gain efficiencies in related business

   A number of the County‘s business needs are not being met by the current
systems. As a result of these unmet needs:
      1. The County‘s business processes are significantly less efficient and
         effective than they could be.
      2. Departments continue to spend, and have plans to spend, significant
         amounts on enhancing their existing ―stand-alone‖ legacy systems or
         purchase their own department-specific integrated systems – this funding
         could be used toward the implementation of a single, enterprise ERP
      3. Continued investments in standalone systems – whether custom
         extensions to existing systems, new commercial ―off-the-shelf‖ products,
         or home grown have other disadvantages, too. Such systems require
         significant duplications of resources on an ongoing basis to design,
         implement, upgrade, and maintain significantly increasing the County‘s
         overall investment in this function above what would be required to
         perform those same duties for a centralized system. More importantly,
         this approach would continue to fragment and ―silo‖ data, perhaps
         increasing the view of state agency management into their own
         operations, but making it increasingly problematic to obtain financial
         data in aggregate in a timely manner that is needed to manager the
         County as a whole.

How Long Will an ERP Project Take?
       Companies that install an ERP product do not have an easy time of it. Don‘t
be fooled when ERP vendors tell you about a three - or six-month average
implementation time.        Those short (that‘s right, six months is short)
implementations all have a catch of one kind or another: The government was
small, or the implementation was limited to a small area of the government, or the
government used only the financial pieces of the ERP system (in which case the
ERP system is nothing more than a very expensive accounting system). To do
ERP right, the ways you do government will need to change and the ways people
do their jobs will need to change too. And that kind of change doesn‘t come
without pain. Unless, of course, your ways of doing business are working
extremely well – and there is a high level of efficiency, accuracy - in which case
there is no reason to even consider ERP.
       The important thing is not to focus on how long it will take—real
transformational ERP efforts usually run between one and three years, on
average—but rather to understand why you need it and how you will use it to
improve your government.

Will ERP Fix MY Integration Problems?
       No. It seems almost quaint to think of it today, but back in the days before
Y2K, enterprise software vendors, and, more forcefully, the management
consultants who installed the stuff, sold ERP as a magic bullet that companies
could use to escape the coming Y2K apocalypse, create seamless technology
integration across the government and force your silos of isolated, sociopathic
bureaucrats to start working together. It was an irresistible sell to government
       It‘s true that ERP was designed to solve integration problems, but it worked
only in the theoretical environment of the vendors‘ development labs. Developers
who believe they are modeling an entire government in software don‘t spend much
time thinking about how that system will connect with other systems – e.g.. the
Criminal Justice Case Management System. Who needs other systems when we‘re
creating the whole thing right here? Of course, as soon as companies began buying
these products, it became clear that enterprise software was another chunk—a
much larger and better integrated chunk to be sure, but still a chunk—of software
in a complex architecture of IT systems that desperately needed to talk to one
another and exchange information. The vendors created clunky, proprietary
methods of connecting their systems with others, which have improved over the
years, but that misses the point.
       The architecture of these systems, in a broad sense, was just like the ones
that they were intended to save you from — those that were monolithic, highly
integrated and difficult to change. No problem, said the vendors. Some of your
maintenance and support fees are going to future R&D. As we develop new pieces
to add in to our highly integrated suites, we‘ll let you upgrade to the next version
for free and you can gradually get rid of all those other troublesome chunks.
Again, it sounded great to the people buying the stuff — government people. But
who could afford to install enterprise software as it was envisioned in the vendors‘
R&D labs? Very few Finance officers built complex integration links from
enterprise software to other systems to keep the government running. Or they
chunked up the installation, building dozens or even hundreds of unique
installations of the same enterprise software to meet the needs of individual
departments or governments that all had to be linked together. The high degree of
integration envisioned in the R&D lab was tenuous at best inside most
      Gradually, enterprise software vendors came to realize that to serve
government customers better, they needed to break up their suites into application
components and create complex ways to link to them over the Internet so that
customers would not have to rewrite connections to pieces of the suite such as
financials, which didn‘t change much. The final death knell for the original

enterprise software architecture model came in 2004 when the major enterprise
software vendors all announced that they were offering packages of integration
middleware—tacitly acknowledging the reality that had been clear since
middleware was first invented decades ago: Integration happens best outside of
specific software applications, not inside them. The enterprise software vendors
have been conspicuously absent from the Web services standards movement,
looking ever more like the Dark Princes while the originators of the lock-in
concept, IBM and Microsoft, looked like White Knights for doing the lion‘s share
of work to create free (so far, anyway) standards for integration in Web services.
And it‘s great stuff. How ironic that those companies that were going to save your
CEO from integration in 1996 have been the laggards in developing truly useful
enterprise integration.
       This is not to say that ERP is a boondoggle, or even that the software isn‘t
valuable to the governments that bought it. Even though most vendors have had
some big bumps in the road, most of their products work well. The happiest
customers are those who used enterprise software to create new capabilities and
processes that they could not express in software with their old systems. But back
in 1996, many finance officers talked about ERP as an integration strategy, about
replacing systems that had more and better functionality than the enterprise
software they were installing in order to be more integrated, more efficient when
the new software was installed. For the few governments that could afford to
install enterprise software in the manner envisioned in the vendors‘ R&D labs, they
may have gotten there. Many are still maintaining the custom code they had to
write for outraged government users who lost capabilities they had in the old

What Will ERP Fix in MY Government?
     There are five major reasons why governments undertake ERP.
      1. Integrate financial information—; as the governmental managers try
         to understand their government‘s overall performance, they may find
         many different versions of the truth. Finance has its own set of revenue
         numbers, revenue accounting has another version, and the different
         government units may each have their own version of how much they
         have contributed to revenue. ERP creates a single version of the truth
         that cannot be questioned because everyone is using the same system –
         one data base.
      2. Integrate cash collection and customer service—ERP systems can
         become the place where the customer is handled with timely service.
         The cash receipting system becomes standardized and it can reside on
         everyone‘s computer at the same time. Customer service becomes a

           reality. By having this information in one software system, rather than
           scattered among many different systems that can‘t communicate with
           one another, departments can collect for other departments and
           collection data can be shared and customer information can be updated
           in a real time sequence instead of waiting for over night processing.
        3. Standardize and speed up the accounting processes—when
           governments are trying to merge activities and reduce the need for
           additional personnel it is often found that multiple government units
           across the government are performing the same function, but they are
           using different methods and computer systems. ERP systems come
           with standard methods for automating some of the steps of a
           manufacturing process. Standardizing those processes and using a
           single, integrated computer system can save time, increase efficiency
           and reduce headcount.
        4. Reduce inventory—; ERP has a tendency to reduce the need for
           departments to continually be ordering inventory – it provides a level of
           artificial intelligence to anticipate needs and allow for orders to be
           placed so that supplies will arrive just-in-time. That can lead to reduced
           inventories within the offices, it will allow for cash flow to be
           anticipated and therefore funds not required can be invested, it will
           allow users to better plan deliveries and thereby reduce the labor hours
           spent producing requisitions. To really improve the flow of your
           supply chain, you need supply chain software – an ERP specialty.
        5. Standardize HR information—; especially in governments with
           multiple departmental units, HR may not have a unified, simple method
           for tracking employees‘ time and communicating with them about
           benefits and services. ERP can fix that – and it can be real time with
           complete documentation.
      In the race to fix these problems, companies often lose sight of the fact that
ERP packages are nothing more than generic representations of the ways a typical
government does business. While most packages are exhaustively comprehensive,
each industry has quirks that make it unique. Most ERP systems were designed to
be used by discrete manufacturing companies (that make physical things that can
be counted), which immediately left all the process manufacturers, retail stores and
out in the cold. Each of these industries has struggled with the different ERP
vendors to modify core ERP programs to their needs – and by 1999 we had seen
some real progress in government capability.

Will ERP Fit the Ways I Do Business?
      Before the checks are signed and the implementation begins, it‘s critical for
governments to figure out if their ways of doing business will fit within a standard
ERP package. The most common reason that governments walk away from
multimillion-dollar ERP projects is that they discover the software does not
support one of their important governmental processes – e.g. Criminal Justice Case
Management. At that point there are two things they can do:
          They can change the governmental process to accommodate the
            software, which will mean deep changes in long-established ways of
            doing business (that often provide competitive advantage) and shake
            up important people‘s roles and responsibilities (something that few
            governments have the stomach for).
          Or they can modify the software to fit the process, which will slow
            down the project, introduce dangerous bugs into the system and make
            upgrading the software to the ERP vendor‘s next release
            excruciatingly difficult because the customizations will need to be
            torn apart and rewritten to fit with the new version.
       Needless to say, the move to ERP is a project of breathtaking scope, and the
price tags on the front end are enough to make the most placid county judge a little
twitchy. In addition to budgeting for software costs, financial executives should
plan to write checks to cover consulting, process rework, integration testing and a
long laundry list of other expenses before the benefits of ERP start to manifest
themselves. Underestimating the price of teaching users their new job processes
can lead to a rude shock down the line, and so can failure to consider data
warehouse integration requirements and the cost of extra software to duplicate the
old report formats. A few oversights in the budgeting and planning stage can send
ERP costs spiraling out of control faster than oversights in planning almost any
other information system undertaking.

What Does ERP Really Cost?
       There aren‘t any good numbers to predict ERP costs because the software
installation has so many variables, such as: the number of divisions it will serve,
the number of modules installed, the amount of integration that will be required
with existing systems, the readiness of the government to change and the ambition
of the project—if the project is truly meant to be a battering ram for reengineering
how the government does its most important work, the project will cost much more
and take much longer than one in which ERP is simply replacing an old transaction
system. There is a sketchy rule of thumb that experts have used for years to predict
ERP installation costs, which is that the installation will cost about six times as

much as the software license. But this has become increasingly less relevant as the
market for ERP has slowed over time and vendors have offered deep discounts on
the software up front.
       Research companies don‘t even bother trying to predict costs anymore. A
few years ago, the dearly departed Meta Group did a study looking at the total cost
of ownership (TCO) of ERP, including hardware, software, professional services
and internal staff costs. The TCO numbers include getting the software installed
and the two years afterward, which is when the real costs of maintaining,
upgrading and optimizing the system for your government are felt. Among the 63
companies surveyed—including small, midsize and large companies in a range of
industries—the average TCO was $15 million (the highest was $300 million and
the lowest was $400,000). While it‘s hard to draw a solid number from that kind
of range of companies and ERP efforts, Meta came up with one statistic that proves
that ERP is expensive no matter what kind of government is using it: The TCO for
someone who uses the system a lot (over 700 hours per year) over that period was
a staggering $53,320 per user per year. What Meta came to understand was it was
far cheaper to have the ERP systems hosted. Hosting reduced the cost per user per
year to less than $8,000 – nominal investment in hardware; nominal investment in
software; nominal investment in programmers. But, there is additional expense
incurred due to the extent of training that is continually required.

When Will I Get Payback From ERP—and How Much Will It Be?
       Don‘t expect to revolutionize your government with ERP. Its contribution is
optimizing the way things are done internally rather than with customers, suppliers
or partners. Again, value depends on ambition. If the focus of an ERP system is to
bring dramatic improvements to the way a government does government, it will
bring more value than if the project is treated as a simple systems replacement.
And even if ERP does bring dramatic change, because it affects mostly existing
"back office" processes such as purchasing, accounts receivable, cashiering and
order management rather than creating new revenue opportunities, the bottom-line
value may not be much. Veterans say ERP is more a cost of doing government to
make the government operate more efficiently than something that offers dramatic
payback. And most veterans say it takes six months or more to get the new
systems and processes running up to snuff. A Meta Group study of 63 companies
a few years ago found that it took eight months after the new system was in (31
months total) to see any benefits. The median annual savings from the new ERP
system were $1.6 million—pretty modest, considering that ERP projects at big
companies can cost $50 million or more.

What Are the Hidden Costs of ERP?
       Although different companies will find different land mines in the budgeting
process, those who have implemented ERP packages agree that certain costs are
more commonly overlooked or underestimated than others. Armed with insights
from across the government, ERP pros vote the following areas as most likely to
result in budget overrun.
          Training—Training is the near-unanimous choice of experienced
           ERP implementers as the most underestimated budget item. Training
           expenses are high because workers almost invariably have to learn a
           new set of processes, not just a new software interface. Worse,
           outside training companies may not be able to help you. They are
           focused on telling people how to use software, not on educating
           people about the particular ways you do government. Prepare to
           develop a curriculum yourself that identifies and explains the different
           government processes that will be affected by the ERP system. One
           enterprising government hired staff from a local school system to help
           him develop and teach the ERP government-training course to
           employees. Remember that with ERP, finance people will be using
           the same software as warehouse people and they will both be entering
           information that affects the other. To do this accurately, they have to
           have a much broader understanding of how others in the government
           do their jobs than they did before ERP came along. Ultimately, it will
           be up to your IT and finance staff to provide that training. So take
           whatever you have budgeted for ERP training and double or triple it
           up front. It will be the best ERP investment you ever make.

          Integration and testing—Testing the links between ERP packages
           and other corporate software links that have to be built on a case-by-
           case basis is another often-underestimated cost. A typical government
           may have add-on applications from the major—e-commerce and
           supply chain—to the minor—sales tax computation and bar coding.
           All require integration links to ERP. You‘re better off if you can buy
           add-ons from the ERP vendors that are pre-integrated. If you need to
           build the links yourself, expect things to get ugly. As with training,
           testing ERP integration has to be done from a process-oriented
           perspective. Veterans recommend that instead of plugging in dummy
           data and moving it from one application to the next, you should run a
           real purchase order through the system, from requisition – to purchase
           order – vendor notification – to delivery – receiving report – to

   payment. Preferably with the participation of the employees who will
   eventually do those jobs.
 Customization—Add-ons are only the beginning of the integration
  costs of ERP. Much more costly, and something to be avoided if at all
  possible, is actual customization of the core ERP software itself. This
  happens when the ERP software can‘t handle one of your business
  processes and you decide to mess with the software to make it do
  what you want. You‘re playing with fire. The customizations can
  affect every module of the ERP system because they are all so tightly
  linked together. Then when one decides to upgrade their ERP
  package the walk in the park has turned into a hike in the mountains -
  under the best of circumstances—you will have a real nightmare
  because you‘ll have to do the customization all over again in the new
  version. Maybe it will work, maybe it won‘t. No matter what, the
  vendor will not be there to support you. You will have to hire extra
  staffers to do the customization work, and keep them on for good to
  maintain it.
 Data conversion—It costs money to move information, such as
  customer and supplier records, product design data and the like, from
  old systems to new ERP homes. Although few finance officers will
  admit it, most data in most legacy systems is of little use. Companies
  often deny their data is dirty until they actually have to move it to the
  new client/server setups that popular ERP packages require.
  Consequently, those companies are more likely to underestimate the
  cost of the move. But even clean data may demand some overhaul to
  match process modifications necessitated—or inspired—by the ERP
 Data analysis—often, the data from the ERP system must be
  combined with data from external systems for analysis purposes.
  Users with heavy analysis needs should include the cost of a data
  warehouse in the ERP budget—and they should expect to do quite a
  bit of work to make it run smoothly. Users are in a pickle here:
  Refreshing all the ERP data every day in a data warehouse is difficult,
  and ERP systems do a poor job of indicating which information has
  changed from day to day, making selective warehouse updates tough.
  One expensive solution is custom programming. The upshot is that
  the wise will check all their data analysis needs before signing off on
  the budget.

Consultants ad infinitum—when users fail to plan for disengagement,
consulting fees run wild. To avoid this, governments should identify
objectives for which its consulting partners must aim when training
internal staff. Include metrics in the consultants‘ contract; for example, a
specific number of the user‘s staff should be able to pass a project-
management leadership test—similar to what the consultants have to pass
to lead an ERP engagement.
 Replacing your best and brightest—it is accepted wisdom that ERP
  success depends on staffing the project with the best and brightest
  from the government and IS divisions. The software is too complex
  and the government changes too dramatic to trust the project to
  just anyone. The bad news is a government must be prepared to
  replace many of those people when the project is over. Though the
  ERP market is not as hot as it once was, consultant and software
  companies that have lost their best people will be hounding yours with
  higher salaries and bonus offers than you can afford—or that you‘re
  HR policies permit. Huddle with HR early on to develop a retention
  bonus program and create new salary strata for ERP veterans. If you
  let them go, you‘ll wind up hiring them—or someone like them—
  back as consultants for twice what you paid them in salaries.
 Implementation teams can never stop—most companies intend to
  treat their ERP implementation as they would any other software
  project. Once the software is installed, they figure the team will be
  scuttled, and everyone will go back to his or her day job. But after
  ERP, you can‘t go home again. The implementers are too valuable.
  Because the implementers have worked so closely with ERP, they
  know more about the financial process than the accounting staff and
  more about the procurement process than the purchasing staff.
  Governments have found that they can‘t afford to send their project
  people back into the government because there‘s so much to do after
  the ERP software is installed. Just writing reports to pull information
  out of the new ERP system will keep the project team busy for a year
  at least – training is continuous going forward - and the ability to have
  analysis available on the fly – and, the ability to reduce the time
  requirement at the counter all one would hope would lead to some
  return on investment to the government. Unfortunately, few IT
  departments plan for the frenzy of post-ERP installation activity, and
  fewer still build it into their budgets when they start their ERP
  projects. Many are forced to beg for more money and staff
  immediately after the go-live date, long before the ERP project has
  demonstrated any benefit.
           Waiting for ROI—one of the most misleading legacies of traditional
            software project management is that the government expects to gain
            value from the application as soon as it is installed, while the project
            team is expecting a break and maybe a pat on the back. Neither
            expectation applies to ERP. Most of the systems don‘t reveal their
            value until after companies have had them running for some time and
            can concentrate on making improvements in the government‘s
            business processes that are affected by the system. And the project
            team is not going to be rewarded until their efforts pay off.
           Post-ERP depression—ERP systems often wreak havoc in the
            governments that install them. In a recent Deloitte Consulting survey
            of 64 Fortune 500 companies, one in four admitted that they suffered
            a drop in performance when their ERP system went live. The true
            percentage is undoubtedly much higher. The most common reason
            for the performance problems is that everything looks and works
            differently from the way it did before. When people can‘t do their
            jobs in the familiar way and they haven‘t yet mastered the new way,
            they panic, and the government goes into spasms. Worse yet many
            employees quickly see that their services won‘t be needed. Without
            proper education of the needs in the future personnel will become

Why Do ERP Projects Fail So Often?
       At its simplest level, ERP is a set of best practices for performing the various
duties in the departments of your government, including finance, accounting,
purchasing, reporting, warehousing, construction. To get the most from the
software, you have to get people inside your government to adopt the work
methods outlined in the software. If the people in the different departments that
will use ERP don‘t agree that the work methods embedded in the software are
better than the ones they currently use, they will resist using the software or will
want IT to change the software to match the ways they currently do things. This is
where ERP projects break down.
       Political fights erupt over how—or even whether—the software will be
installed. IT gets bogged down in long, expensive customization efforts to modify
the ERP software to fit the wishes of the powerful government barons.
Customizations make the software more unstable and harder to maintain when it
finally does come to life. The horror stories you hear in the press about ERP can
usually be traced to the changes the government made in the core ERP software to

fit its own work methods. Because ERP covers so much of what a government
does, a failure in the software can bring a government to a halt, literally.
      But IT can fix the bugs pretty quickly in most cases, and besides, few
governments can avoid customizing ERP in some fashion in Texas—every
government is different and is bound to have unique work methods that a vendor
cannot account for when developing its software. The mistake companies make is
assuming that changing people‘s habits will be easier than customizing the
software. It‘s not. Getting people inside your government to use the software to
improve the ways they do their jobs is by far the harder challenge. If your
government is resistant to change, then your ERP project is more likely to fail.
(See ―Attachment D‖ for additional detail)

How Do I Configure ERP Software?
       Even if a government installs ERP software for the so-called right reasons
and everyone can agree on the optimal definition of a customer, the inherent
difficulties of implementing something as complex as ERP is like, well, teaching
an elephant to do the hootchy-kootchy. The packages are built from database
tables, thousands of them, that IS programmers and end users must set to match
their government processes; each table has a decision "switch" that leads the
software down one decision path or another. By presenting only one way for the
government to do each task—say, run the payroll or close the books—a
government‘s individual operating units and far-flung divisions are integrated
under one system. But figuring out precisely how to set all the switches in the
tables requires a deep understanding of the existing processes being used to operate
the government. As the table settings are decided, these government processes are
reengineered, ERP‘s way. Most ERP systems are preconfigured for most of the
major processes, however, allowing just hundreds—rather than thousands—of
procedural settings to be made by the customer.

How Do Governments Organize Their ERP Projects?
     Based on observations, there were six commonly used ways of installing
ERP systems during the period 1995 – 2004:
         1. Big Bang -- Is the most ambitious and difficult of the approaches to
            ERP implementation - governments cast off all their legacy systems at
            once, and they install a single ERP system across the entire
            government. This method dominated early ERP implementations
            because of the need to revamp old systems for Y2K, few governments
            would dare to attempt it anymore because it calls for the entire
            government to mobilize and change at once. In many cases, the speed

   of the new system may suffer because it is serving the entire
   government rather than a single department. ERP implementation
   requires a direct mandate from the chief finance officer.
2. Franchising -- This approach suits large or diverse governments that
   do not share many common processes across governmental units.
   Independent ERP systems are installed in each unit, while linking
   common processes, such as accounting, purchasing, cashiering and
   reporting across the entity. Interestingly, many governments that
   initially installed ERP using a franchising strategy are now trying to
   consolidate as many of those different instances of ERP as possible
   down into a handful or even one for the entire government.
3. Slam Dunk -- ERP dictates the process design in this method, where
   the focus is on just a few key processes, such as those contained in an
   ERP system‘s financial module. The slam dunk is generally for
   smaller entities expecting to grow into ERP. The goal here is to get
   ERP up and running quickly, and to ditch the fancy reengineering in
   favor of the ERP system‘s "canned" processes. Few governments that
   have approached ERP this way can claim much payback from the new
4. Pilot All Functionality with Phased Deployment -- This approach
   involves the development of a ―prototype‖ for implementing all
   functionality at a single representative department or group of
   departments within the County, to be followed by a planned
   deployment of the ERP system to all remaining departments in phases
   upon successful deployment at the pilot department(s).

5. Big Bang Deployment of Core Functionality at All Departments /
   Phased Deployment of Future Functionality -- Using this
   deployment strategy, all departments within the project scope ―go live‖
   with all core functional modules simultaneously.             Non-core
   functionality would then be prototyped and deployed in a future
   phase(s) to those departments having a functional need for said
6. Function-by-Function Deployment -- This strategy is one in which
   major functional modules are deployed in a logical manner, usually one
   module after another. A single module is deployed across all County
   departments before work is initiated on the next module. This
   approach is sometimes used for software custom-development
   projects. This strategy is also occasionally considered for the Human
   Resources / Payroll components of an Enterprise Resource Planning

      (ERP) system, but not typically for financial management and
      procurement components.

       "Single Instance" Approach - An "instance" refers to the number of
discreet versions of ERP software you have in your government. The
original vision of ERP was that the entity should have a single instance—
that is, a single implementation of the software running on a single
database—that serves the entire government. It would mean no duplication
of information in different departments or in different geographic divisions
and thus better integration and information quality across the government.
Upgrading the software would also be easier than with multiple customized
instances of ERP across the government.
        But few governments attempted ERP installations in this manner.
First, there were the technology limitations: databases, networks and storage
systems couldn‘t handle the load, and bandwidth was still expensive enough
that linking globally based divisions together on a single database was
expensive. Worse, different government units often had unique processes or
resisted the ones that came in the ERP box. All these factors combined
caused many governments to install dozens of instances of software from a
single ERP vendor.

    Today, many of those early barriers have come down. So does it make
sense to create a single (or a significantly reduced number) of instances—
while also getting rid of outdated or feature-poor systems from other
vendors? Like most complex technology issues - it depends. There are
some compelling reasons to undertake such a project now. For starters, the
Sarbanes-Oxley Act, the government‘s post-Enron accounting legislation
requires that financial reports have a verifiable audit trail – an issue that is
critical in governments. With a single instance, all of a government‘s
financial data will live in one application and will originate from one source,
eliminating consolidation errors and greatly reducing the time it takes to
close the books. Having a single data source could also create new revenue
opportunities and cut costs. Governments would be able to run reports that
develop areas for consolidation of effort and high light areas where
performance needs improvement. Also, Mata estimated that governments
could budget $3.3 million for a single-instance of implementation instead of
$9.1 million for multiple instances.

   But despite these benefits, rip-and-replace is a difficult pill for finance
officers to swallow. And they‘re wondering if there isn‘t another cure for
their integration headaches: Web services and the promise of service-
oriented architecture (SOA). Web services could—with the emphasis on
could—allow finance officers who have invested in best-of-breed
solutions to integrate their standalone systems without either shelling out
millions for single instance or tying their government‘s future to a single
vendor. Trouble is, Web services are maturing and SOA are still in their
infancy and require complex planning and a long list of programming
and architectural talents inside the IT department—and don‘t forget
implementation time and cost.

    Most pundits believe some form of standard, simple, vendor-
independent integration will emerge over the long term, but that doesn‘t
help finance officers today. Most experts recommend waiting for better
integration standards if the costs of operating your systems as-is don‘t
outweigh the costs and benefits of ripping and replacing with a single
instance and the government is not missing out on important revenue
opportunities because of problems with the current system. Essentially,
single instance and Web services/SOA are two ways to get to the same
place, and finance officers will need to choose which path to lead their
government down. Here are some very basic guidelines:

You should consider single instance if you...
     Have fairly commonplace government processes that extend
      across all divisions
     Have older systems that need to be replaced
     Have multiple ERP instances from a single vendor
You should consider an integration layer if you...
     Have divisions with unique government processes that can‘t be
     Consider an existing investment in best-of-breed solutions a
      competitive advantage
     Want an environment in which it is easy to integrate new

How Difficult Is It to Upgrade ERP Software?
       It‘s extremely difficult - unless you are one of the rare entities that did not
tinker with the system while installing it. In the early days of ERP, vendors
pursued a vision that has since been disproven: Government processes built into
the software should be adopted by every customer. Change your government to fit
the system. Chief finance officers like the sound of reengineering, but take that
logic to the departmental head that won‘t be able to serve their customers as well
with the process in the software box and suddenly reengineering sounds less
compelling. Chief finance officers were forced (or acquiesced) to tinker with the
innards of these packages to avoid losing valuable chunks of their business
processes, and it made their lives hell. Vendors ignored this reality for years.
They thought changing the system to fit your own processes meant you were a
weak girly man who couldn‘t stand up to your government barons. Those
processes couldn‘t be any good anyway if they hadn‘t made it into the vendors‘
best practice pool when they developed the stuff. Modifying the core code of ERP
was like turning your Pinto into a low rider. You just voided the warranty, dude.
Tough luck. ERP vendors would not support customized versions of their
       When a new version of the highly integrated suite arrived with cool new
features, customers sometimes could not afford to install them because they had
made so many changes to the previous version. Chief finance officers had built so
many different links to the enterprise systems to get them working with other
systems in the government that an upgrade was akin to starting over. Many of the
old links had to be torn apart and rewritten to fit with the new version. And many
of those rewrites were completely pointless. The new suite might have one new
piece and nine others that had changed little since the last version. But it was all so
integrated together that every custom link had to be redone, even to the pieces that
didn‘t change.
       When vendors began breaking up and componentizing their suites to make
them easier to integrate with each other and with legacy systems inside the
government, they also broke up one of the value propositions that had been so
enticing in the first place: ―free‖ upgrades. Freed of the suite model, enterprise
software vendors started charging fresh license fees for the new components they
developed. Many early ERP suites had their development ―frozen.‖ Customers
could continue to get support, but newer features cost extra and worked much
better—or sometimes only—with the newer version of the vendor‘s software. And
chief finance officers stuck with the old suites began wondering where all their
maintenance fees had gone. They couldn‘t afford to upgrade to the newer,
componentized version of the vendors‘ software models and if they could, they‘d
pay a new license fee for their trouble.

       In theory, early users of ERP paid for those new versions of the software
through yearly maintenance fees to the vendor that every ERP vendor charges.
The largest percentage of those fees went to R&D rather than to support and
maintenance of existing software. But the economics became untenable for
vendors. When the ERP boom crashed after 2000, sales of new software slowed to
a crawl and vendors said they were forced to charge for new components. It may
be true, but it ended the short era of ―free‖ upgrades.

Will Service-Oriented Architecture (SOA) Replace ERP?
       No. Every government needs a core transactional system that records the
information from its most important government processes.              But today
governments are realizing that ERP is shifting from being the sum total of their
software architecture strategy to being a component of a larger strategy based on
expressing technology as specific government services that people can easily
understand—such as ―customer record‖ or ―get vendor number,‖ for example—
rather than arcane software applications like ERP.
       The services strategy entails building an integration layer that is separate and
distinct from any of the software applications—including ERP—in a government‘s
portfolio. The foundational piece—known as the messaging infrastructure—is like
a good executive assistant—translating, routing and monitoring information from
different systems without these systems needing to connect directly. Adding,
changing or removing a system becomes a matter of modifying a single link, rather
than ripping apart connections to all the different systems it may need to
communicate with. But while the messaging infrastructure makes connecting
systems easier, it doesn‘t free business processes from their mainframe prisons, or
eliminate redundancies in applications, or provide any impetus to create a useful
architecture. Indeed, a good messaging infrastructure can perpetuate the chaos by
making it easier to deal with.
       Messaging has long lacked a higher purpose, a strategy. Service objects (or
just plain ―services‖) are that strategy, and it is the second core piece of the
integration layer. This is an old concept, based on object-oriented programming
from the ‗80s. Services extract pieces of data and government logic from systems
and databases around the government and bundle them together into chunks that
are expressed in government terms.
       At telecom government Verizon, for example, the service called ―get CSR‖
(get customer service record) is a complex jumble of software actions and data and
government logic extractions that uses Verizon‘s messaging infrastructure to
access more than 25 systems in as many as four data centers across the country.
Before building the ―get CSR‖ service, Verizon developers wanting to get at that

critical lump of data would have to build links to all 25 systems—adding their own
links on top of the web of links already hanging off the popular systems. But with
the ―get CSR‖ service sitting in a central repository on Verizon‘s intranet, those
developers can now build a single link to the carefully crafted interface that wraps
around the service using the Web services standard simple object access protocol
(SOAP). Those 25 systems immediately line up and march, sending customer
information to the new application and saving developers months, even years, of
development time each time the service is used.
       The most interesting new ―feature‖ being developed by the ERP vendors
today is the extent to which they will make their software part of a service - SOA
using their own homegrown integration software, known as middleware, and Web
services so that customers can more easily link ERP with other types of software in
the architecture. Each vendor has claimed favoritism to the concept and each has
its own vision of how to create an integration layer independent of its own
software that is capable of linking to any other piece of software in the universe.
But view their pronouncements skeptically because if they do it well they will
eliminate an important piece of their competitive differentiation: dominance over
the software acquisition process of their customers.
       When chief financial officers or IT personnel call themselves a ―SAP shop‖
or an ―Oracle shop,‖ it‘s because software from those companies dominates their
architecture and new software from those providers works better with their existing
code base than does code from other vendors. Vendors who make integration with
their software truly universal eliminate the built-in advantage they have with
existing customers. Some ways that vendors use their new middleware strategies
to keep customers: The middleware is offered only to customers who upgrade to
the latest version of ERP, or customers are charged a fee for using the middleware
to link with software from another vendor.

How Does ERP Fit With e-Commerce?
      ERP vendors were not prepared for the onslaught of e-commerce. ERP is
complex and not intended for public consumption. It assumes that the only people
handling purchase orders will be your employees, who are highly trained and
comfortable with the tech jargon embedded in the software. But now customers
and suppliers are demanding access to the same information your employees get
through the ERP system—things such as order information, order status, inventory
levels and invoice reconciliation—except they want to get all this information
simply, without all the ERP software jargon, through your website.

       E-commerce means IT departments need to build two new channels of
access into ERP systems—one for customers (otherwise known as government-to-
consumer) and one for suppliers and partners (government-to-government). These
two audiences want two different types of information from your ERP system.
Consumers want to know the status of cases, fees owed, docket information, etc.,
and vendors want just about everything else. Traditional ERP vendors are having a
hard time building the links between the Web and their software, though they
certainly all realize that they must do it and have been working hard for years to
develop it – and today more is available than it was yesterday. The bottom line,
however, is those companies with e-commerce ambitions face a lot of hard
integration work to make their ERP systems available over the Web. For those
companies that were smart—or lucky—enough to have bought their ERP systems
from a vendor experienced in developing e-commerce wares, adding easily
integrated applications from that same vendor can be a money-saving option. For
those companies whose ERP systems came from vendors that are less experienced
with e-commerce development, the best—and possibly only—option might be to
have a combination of internal staff and consultants hack through a custom
       But no matter what the details are, solving the difficult problem of
integrating ERP and e-commerce requires careful planning, which is key to getting
integration off on the right track.

Shayne Kavanagh, ―ERP Market Dynamics for Midsize Governments.‖ Government Finance
   Review (December 2004)
Rowan Miranda, ―Poison Pills and White Knights: Doing Business With and ERP Industry in
   Transition,‖ Government Finance Review (August 2003)
Rowan Miranda, Shayne Kavanagh, Robert Roque:
   Technology Needs Assessment: Evaluating the Business Case for ERP and Financial
   Management Systems (Chicago, GFOA, 2002)
   A Guide For Preparing an RFP For Enterprise Financial System, (Chicago, GFOA, 2000)


       An Application Service Provider (ASP) provides an outsourced application
to a county, freeing the county from hardware costs, software costs, training on the
system operation, installation and system operation itself. Originally, ASP
applications focused on a fairly narrow functional scope, however, as the market
has matured, the functionality as well as the applications have grown. It is now
possible to contract for virtually any service or group of services required by a
      The ASP frees the county from many, if not all of the tasks associated with
the software such as hardware procurement and upgrades, software configuration,
application fixes and enhancements. Clearly, as the industry moves forward, ASP
applications will take on a larger part of the load of suitable applications.
       Virtually any application where functionality is consistent across multiple
counties is suitable for an ASP to provide. However, whether that application is
suitable to be implemented by a county is based on the requirements and
operations of that county. It's important to know not only what the application
does, but who the target for the application is and how current customers currently
are employing the system.

How Does It Work?
      How does a company engage and pay for the hosting services of an
outsourcing provider? Simply, the company contracts with an outsourcing
provider to do a defined scope of work, and the outsourcing provider charges the
company a fee. The fee can take many forms: by the transaction, by labor hour,
cost per unit, cost per project, an annual cost, cost by service levels, or other
possible arrangements.
       In exchange for the fee, the customer is provided a product or service at a
guaranteed quality or service level. Many contracts stipulate specific, measurable
metrics called Service Level Agreements (SLAs). These SLAs might define the
acceptable quantity of defects per lines of software code, quantity of rings to
answer a telephone call, quantity of calls to correctly answer a query, average
response time, quantity of transactions completed per unit of time, and so on.
Many times the SLAs also have penalties associated with not meeting the specified
metrics, and sometimes have rewards for exceeding the metric. Needless to say,
there are a multitude of ways to perform outsourcing that would provide hosting
for information technology, and a multitude of ways to construct the agreements.
What is Outsourcing?
      In the English language (and most likely in other languages), ―outsourcing‖
is a relatively new term. A 1967 edition of Merriam-Webster‘s Seventh New
Collegiate Dictionary does not carry a listing for ―outsourcing,‖ but a recent check
of Merriam-Webster‘s Online Abridged Dictionary (
found the following entry:
      out•sourc•ing - Function: noun: ―The practice of subcontracting
      manufacturing work to outside and especially foreign or nonunion
      companies‖ Though the term is relatively new, the concept of
      outsourcing has been around for a long time. Since 1982, the term
      outsourcing has evolved to include all parts of the enterprise process,
      not just manufacturing. In many ways, outsourcing is a synonym for
      sub-contracting. Literally any activity that is performed by a
      company can be, and probably has been, outsourced.

A Short History
       Outsourcing began to emerge a few thousand years ago - it started with the
production and selling of food, tools and other household supplies. If you go back
far enough in the history of humanity, each person or family provided everything
for themselves. They gathered their own berries and nuts, hunted their own food,
grew their own crops, skinned hides for clothing and so on. Then villages began to
spring up, and people began to specialize. As such, they began to barter with each
other for goods and services, and soon money was invented to help simplify the
bartering process. In effect, each worker was outsourcing some activities to others
       Fast-forward a few thousand years to the industrial age. Very few
companies, if any, in the 1800s and early 1900s outsourced any part of their
processes; they were vertically integrated organizations. They may have produced
or mined raw materials (steel, crops, rubber) and converted that raw material into
finished products, and then shipped the finished goods on company owned trucks
to company owned retail stores for sale to the public. They were self-insured, did
their own taxes, employed their own lawyers, and designed and constructed
buildings without assistance from other firms. In short, they outsourced very little.

       But specialization, especially of services, led to contracting, which
eventually led to outsourcing. The first wave of outsourcing began during the
boom of the industrial revolution, and fueled the large-scale growth of services
such as insurance services, tax services, accounting services, legal services,
architecture and engineering services, and others. The companies who performed
this work were typically located in the same country, most likely the same city, as
was the customer. In essence, this was onshore outsourcing.
       Next came manufacturing outsourcing for low-tech items such as toys,
trinkets, shoes, and apparel goods and later, higher value manufactured items like
high-tech components and consumer electronics. Manufacturing was the first
activity to begin to move to offshore locations in search of lower costs. As
transportation and logistics improved through improved infrastructure and the use
of computer technology, the cost of transportation went down, and offshore
manufacturing went up. As education and skills improved in lower wage
countries, manufacturers moved up the value-curve.
      More recently, outsourcing has moved into the world of information
technology, pension and 401k benefits, data transcription, and call center
operations. This realm is made more and more possible by continued investment
in education, improved information technology, the wide adoption of the Internet,
and the broad, but still emerging, availability of low cost telecommunications - and
in the early 1990‘s the concept of ―hosting‖ related to information technology
became associated with several of the outsourcing services.

Application Software Outsourcing
       During the past 30 years, software has automated and simplified many work-
processes, which has resulted in increased worker productivity and reduced costs
for products and services. Nevertheless, the development and support of software
is still a time-consuming and costly activity. As such, application software
outsourcing evolved and expanded to reduce costs, improve service and help
manage this growing area of work.
       Additionally, Y2K created a tremendous demand for software resources. As
there were not enough software resources in the U.S. and Western Europe to meet
demands in those locations, the demand spread to other countries with educated
resources. Consequently, the growth of outsourcing and the Y2K-driven demand
for software resources fueled a tremendous growth in application software skills in
many countries around the world. As a result, many countries invested heavily in
their education systems, and are now producing large numbers of highly educated
engineers and computer scientists who are quite capable of supporting and
producing excellent software code. The list of countries with firms that provide

application software services today include Belarus, Canada, China, India, Ireland,
Israel, Malaysia, Mexico, The Philippines, Russia, South Africa, Ukraine, United
States, and Vietnam. By far, the largest player today in application software
offshore outsourcing is India, which is estimated to have greater than fifty percent
of the market share in this outsourcing market, and more than 400 firms that
provide outsourcing services. These outsourcing firms provide many types of
services, including
        Maintenance and support of existing legacy software systems
        Enhancements to existing software applications
        Integration between multiple application software solutions
        Development of new software applications
        Migrating older applications to new technology, and
        Quality assurance testing
      Application software outsourcing firms provide these services to all types of
industries such as financial services, insurance services, healthcare providers,
manufacturing companies, as well as to independent software vendors who use
outsourcing as a way to develop the software products that they sell. As with
many trends, especially those involving technology, the Fortune 500 is leading the
way with application software outsourcing.
       Governments that wish to embark on application software outsourcing
efforts have multiple approaches to consider. In some cases, a government will
outsource its entire software organization. In other cases, a government will
choose to outsource a portion of its application software development or support
needs. A common approach is to outsource maintenance and support of older
legacy systems, while using in-house staff to develop news systems or migrate to
new technologies. Another approach is to use the outsourcer as a resource to
supplement the in-house software engineering team. Each of these approaches has
their individual strengths and weaknesses, and should be selected based on the
needs and requirements of each government.
       Additionally, there are multiple approaches to performing and delivering
application software services. These services may or may not be performed at the
government‘s location. Typically, there are some resources working at the client
site and some working at a remote, off-site location. Recently, the mix has trended
towards a small percentage (five to twenty percent) of resources working at the
client‘s location (onshore), and a larger percentage of resources working at a
remote location, usually in an offshore country. Some providers have strong
opinions regarding the recommended mix of onshore to offshore resources. In
most cases, governments should decide what mix is best for them given the skills,
experiences and maturity of their organizations. Regarding maturity, many
application software outsourcing firms are working towards or are already certified

at level three, four or five of the Capability Maturity Model (CMM). The CMM
was developed by The Software Engineering Institute (SEI) to be used as a
benchmarking process. The CMM consists of a set of criteria to evaluate an
organization‘s software development and maintenance efforts and considers,
among other factors, the level to which processes are standardized and followed
across an organization. The progression from an immature, unrepeatable software
process (SEI-CMM™ Level 1) to a mature, well managed software process (SEI-
CMM™ Level 5) is described in terms of maturity levels in the model.
       Certification implies a high-level of process consistency. However, this
process consistency comes at a price, both in terms of process rigor and probably
in terms of cost (and therefore price to the customer). Certain small development
projects or maintenance-only efforts may not require the same level of process
rigor as a large-scale mission critical development project. On the other hand,
many customers are not CMM certified, or do not operate at a level of process
consistency that would achieve level three, four or five on the CMM scale. As
such, the process rigor provided by the outsourcing provider may or may not be the
best approach for a given customer at a particular time. Again, the government
should decide the level of importance to place on selecting an outsourcing firm that
is CMM certified.

Decision Criteria
      Whether an application is best implemented as an ASP with a host provided
application or service, or built in-house or purchased generally depends on the
same criteria as what would be used for outsourcing a function or process, among
    How critical is a system is to day to day business operations?
    What are the failure recovery requirements for the system?
    How critical are performance requirements for the application?
    How specific its functionality is relative to the requirements of other
     counties desiring the service?
    What are the cost savings over the development period of an internal system
     vs. the perceived life of the system?
Each of these areas needs careful consideration and are generally addressed to
some extent in the contract and/or terms of service of the ASP.

Critical Systems
       Systems critical to the business operation are considered to be poor
candidates for ASP applications, primarily because of concerns over the loss of
control over critical data. While internal security may have less staff than a
particular ASP, the priorities and focus of the staff is controllable.
       While ASPs generally provide security as good as any county on the
Internet, by using their software, hardware and operations facilities a county is
relying on the ASP's ability to monitor and repair bugs in an expeditious manner.
These bugs may be resident in the ASP's software or in the applications purchased
from third parties. In the period of time between implementation and the time the
bug is identified and a patch released and applied data is at risk. It is advantageous
to keep all of these time periods to a minimum.
       The initial time period (between implementation and discovery of the bug) is
proportional to the number of users on the system and the complexity of
reproducing the bug. The second time period, between the first verifiable instance
of the bug and the production of a patch or software patch is related to the
resources of the software vendor in which the bug occurred and the priority of the
software vendor in investigating the bug. The large, well known software vendors
generally release patches fairly quickly. While open sourced software takes
longer. Finally, the third time period, from release of the patch to the installation
depends on the resources of the ASP, who must request the patch and test its
installation and the operation of their system under the new software.
       In most cases the ASP's monitoring and implementation resources will equal
or exceed those at the implementing firm simply because it is their core business.
Even when this is the case, there are situations where a specific bug may affect a
minority of the ASPs users or, where regardless of the ASPs capabilities it is wise
to not risk liability for loss or disclosure of data not under the firm's direct control.

Failure Recovery Requirements
       If an application has very strict requirements for recovery in the event of a
failure, the nature of ASP applications may make them more complicated to
recover. Simple recoveries such as hardware failure generally can be recovered
easily by an outside service. Complex recoveries, such as may be caused by a
latent bug related to data that brings down the system are generally more
complicated. In this case, familiarity with the application is less important than
familiarity with the data, something that is difficult or impossible for an ASP to
achieve at the same level as the county using the system.

Performance Criteria
      The shared nature of the services means that performance may be an issue.
To operate cost effectively, many ASPs operate multiple companies across the
same load balanced servers. In this case, operations and transaction loads at one
county may affect the performance of the system for another.

Specific Functionality
       If the functionality desired from the ASP application is essentially the same
as other companies' use of the application, then each firm already on the system
has acted as a "test group" for use of the system. This would make the confidence
level higher for successful cutover and operation. If, however, the functionality
differs even slightly, then the fact that other firms are on the system should be
discounted appropriately and a test period prior to launch utilized to verify system

Why an ASP?
       Initially, the cost to get an ASP application implemented is less than the cost
of development plus the cost of operation, and it comes to market faster. If a
system is such that heavy ongoing maintenance is under consideration (e.g.,
shipping costs and telephone rate calculation services), the cost benefit may stay
positive for some time.
      Eventually, however, the cost of utilizing the ASP may exceed the cost of
development. How a county handles this event is an important consideration for
whether or not the service is initially implemented as the solution to a business
issue or as an initial implementation to cover the period during which an internal
application is developed.
       If you believe the marketing hype, the ASP model will solve all the software
development, delivery and maintenance problems that governments have
consistently struggled with. While that can't be the case, the ASP model does
present an attractive option given the right situation. The existence of the right
situation depends on how well you have defined your business functionality need,
the IT resource constraints you face, and the cost issues you must address. A few
questions can help determine when that situation exists.
    What is the nature of the business functionality you need to deliver?
    Will it require significant customization to use an existing ASP offering?
    Does the functionality need to be integrated with existing systems?
       If you answer yes to these three questions, then the ASP option may not
offer the best option. Although it is evolving, the ASP model is based on the
economics of delivering similar functionality to multiple customers with minimal
integration. As soon as you start discussing significant customization and
integration, you step out of the ASP model into the systems integrator model.
      This is not to say that any customization or integration needs should prevent
you from examining ASP options. Most ASPs can handle some customization,
and their offerings may routinely support basic integration with enterprise systems.
However, significant customization or integration usually means you are faced
with a full-blown systems development and integration project.
      If you are considering the ASP route for mission critical functionality,
proceed with caution. This may be unavoidable with start-ups, but established
companies should experiment with the model on less critical functionality until the
market shakes out.
Does an ASP deliver functionality that you need but can't deliver alone due to
resource constraints?
      An ASP can help you address many of the issues those resource
      constraints present. Whether the issue is time, personnel, monetary
      pressure or skill constraints, an ASP may offer a feasible solution.
      That solution carries forward for ongoing maintenance. The ASP
      model minimizes the resource you will need to devote to the ongoing
      maintenance of the functionality.
      The ASP option doesn't eliminate your need to manage the delivery of
      the functionality. Managing the delivery of the ASP service is a
      critical function that you can't skimp on.
Do you lack the capital to purchase and install the software required to
deliver the functionality?
      The ASP model is a rental model. It has lower entry costs than a
      purchase or build-your-own option. If you need the functionality, but
      can't afford the capital to purchase it, the ASP option will provide you
      This does not mean that the ASP model guarantees the lowest total
      cost of ownership. Much of the ASP hype focuses on the cost savings
      picture, but that picture does not clearly show whether the ASP option
      will generate less cost over the life of the application.

Is an ASP Forever?
      If this question is posed to an ASP provider, the answer is a resounding
―yes.‖ They are organized to be able to meet the common requirements of their
user base, and at first glance, the system does everything you want it to and more.

In reality, ASP's should be considered IT software tools, similar to word processors
or browsers. In this respect, they can be utilized as a software platform or interim
solution while internal development is in process to develop an in house solution.
Care should be taken to ensure that the Terms of Service and/or contract do not
prohibit this activity and that common functionality is not deemed confidential and
proprietary. It should be noted that where hosting has failed to be cost-effective or
does not yield satisfactory service delivery, the organizations involved have
struggled to reinitiate in-house functions without impacting services.

County Responsibilities
       From an IT standpoint, ASPs are convenient and replace some, but not all of
the systems development work. User requirements still need to be collected and an
initial development schedule prepared in order to assess the cost savings of
selecting an ASP. The ASP provider will take care of the hardware and software
implementation, but the software still needs to be integrated into existing systems,
a cutover plan developed, internal users trained on the application, an integration
test plan created and executed, and depending on the application, custom
documentation created.

Why Do It?
      These benefits summarize the findings of numerous industry reports from
Gartner, IDC and the Meta Group.
       It can increase a government's financial strength.
        Outsourcing provides enterprises with an opportunity to improve return
        on investment (ROI) through divesting non-core assets and allows for
        predictable future cash requirements. This is a major driver of
        outsourcing solutions. Entities benefit from the variable nature of IT
        costs under an outsourcing arrangement by reducing risk and
        transforming fixed costs into variable costs.
       It alleviates the challenge of retaining skilled IT personnel.
        The escalating shortage of skilled IT professionals is the most serious
        barrier to enterprise growth. Outsourcing vendors offer the services of
        trained subject matter experts without the cost of retaining, hiring,
        training or re-training. The government has the ability then to focus
        resources on customer needs by realigning existing personnel into other
        critical areas within the company.
 • It helps a government adapt more easily to market changes.
  A government's viability is dependent on its ability to serve its
  customer‘s needs and its ability to react to changes in business
  conditions. By leveraging the outsourcing opportunity, governments are
  able to acquire best practices process expertise to facilitate the design,
  building, training and implementation of business solutions or functions.
  They also acquire experienced personnel who are able to accommodate
  changing business practices and conditions. This, in turn, helps the
  government achieve efficiency in performance as well as develops better
  customer relations.
 • It helps a government to keep pace with technological change.
  Rapid technological change exerts pressure on any entity in all industries,
  requiring them to revamp and upgrade their IT infrastructures on a
  regular basis to stay competitive and operationally efficient. For a
  government whose IT department is a non-core function, maintaining a
  "best-of-breed" status under these conditions is next to impossible. This
  is especially true for small and mid-sized entities, where cost is a critical
 It allows a government to focus more sharply on its core business.
  The high level of reorganization across mid-size and large governments
  has increased the demand for outsourcing as a means of sharpening the
  focus on core competencies. As population increase the demand for
  service expands accordingly and government should be able to tend to
  what it does best – tending to its core functions and integrating its non-
  core business functions into one business. While at the same time
  upgrading and enhancing existing system functionality to allow the
  public and customers access.
 Key Business Drivers Leading to a Decision to Outsource:
   Cost reduction and predictability
   Access to highly-skilled technical resources and emerging
   Risk mitigation
   Ease of manageability
   Speed to market
   Consistently reliable performance
   Improve company focus
   Control operating costs
   Free up resources
   Share risks

Why Not Do It?
    Outsourcing is not right for every municipal entity:
     The entity may be too small to effectively outsource (although a concept
       called ―shared services‖ could be right for such an entity)
     The entity‘s culture may not be appropriate for hosting
     There may be customer reasons that limit or prevent the entity‘s ability to
     Host takes a type of management leadership that may be different than
       that which exists within the entity today
     Most government agencies do not allow their contractors to outsource the
       host service to an offshore location.

ASP Selection
      Once a decision has been made concerning the suitability of an application
for ASP, the following questions should be considered in selecting an ASP
   1.    What hardware is utilized?
   2.    What is the upgrade path and implementation timeframe for hardware
         upgrades required for performance?
   3.    Where is the off-site backup and recovery?
   4.    How many entities will share the hardware platform?
   5.    What third party software is used?
   6.    What software version is each of the third party applications?
   7.    What is the process for monitoring for software bugs for third party
   8.    What is the process for monitoring for software bugs for internally
         developed software?
   9.    What is the procedure for alerting clients of bugs that may affect the
   10.   Is there an online bug tracking mechanism for clients to review and to
         prioritize fixes to internal software?
   11.   What entities are currently using the system?
   12.   To what transaction load is the application "rated"?
   13.   Have these results been audited by a third party?
   14.   Are transaction loads for your county's peak hours available?
   15.   What percent of capacity must be reached before a hardware upgrade is
         automatically triggered?
   16.   What is the current software version of the application software?
   17.   What is the release schedule for future releases?

      18.     When an upgrade is ready for installation, is it made available to internal
              IT members for some period of time for testing prior to installation on the
              production system?
      19.     What is the total uptime for 24 hours and for the hours comprising your
              county's peak usage period?
      20.     What are the policies for scheduled downtime?
      21.     Is there a "staging" system with essentially the same configuration as the
              production system?
      22.     Do internal procedures require third party software patches to first be
              installed and tested on the staging system prior to installation on the
              production system?
      23.     Are detailed cutover plans prepared with pre-identified failsafe points for
              all software upgrades/installations?
      24.     What are the procedures for requested enhancements?
      25.     How are these prioritized?
      26.     What are the contract provisions?
      27.     Are any restrictions placed on in house development that would prevent
              an internal development replacement program in the future?

The ASP Contract
      Today more and more business and governmental entities are choosing
hosted applications for their financial management requirements. Business
technology is changing faster today than it did 10 years ago and at light speed
compared to 20 years ago. In 2006 the number of hosted systems off premise
increase 37% and the number of hosted systems on premise increased 1%.
Microsoft was so impressed with growth that they began to examine the
phenomenon in 2002 and are now providing facilities to host all forms of software.
The rapid change was not even on Bill Gates‘ radar.
       Unfortunately, most buyers who are seeking a hosting solution focus on the
features and functions (95%) and very little (5%) on what happens after the sales
contract is signed. What was really surprising here is that the majority of those
entering into contracts between 2004 and 2006 (77%) were entering into contracts
with the providers for five (5) to seven (7) years.1
        Some have made the comment today that if you have read one ASP contract
you have read them all – much of the data is simply boilerplate. But, as we also
have heard many times ―the devil is in the details.‖ And, that is very true. It is
not uncommon to find clauses in ASP contracts that end up restricting the buyer‘s
access to their own company‘s data, or allow the vendor to skirt hidden charges, or
fail to properly ensure adequate data backup.
    Technology Evaluation – 2006 Survey

       Here are three elements that need to be evaluated and properly documented
in all ASP contracts.

   1. Establishing Standards of Service - When the decision is made to use a
      host (application service provider) for financial management one has to
      realize that they are fixing to hand over to a third party a very valuable asset
      for safekeeping – your financial data and documentation. But, one must also
      realize that the ―standard level of service‖ will very from vendor to vendor.
      There is no sense in entering into a contract and making monthly payments
      and not have a clear understanding of the responsibilities of all the partners –
      in writing. Some of the most often overlooked issues are:
            Where will my data and support be hosted from
            Does the facility have full security protocol
            Is a copy of the last internal control evaluation available
            Is the location available for on site examination
            Will there be full access to my data 24/7/365
            How often is my data backed up
            How long are back ups stored
            Are there charges for back ups
            Is there a list in the contract designating those services that are
             provided with the monthly payment
            Is there a list of services available, which are not covered by the
             contract the cost of each
            What is the provider‘s protocol for informing customers of down time
             and maintenance
            Is ―excessive‖ downtime clearly developed in the contract
            Is there a rebate for ―excessive‖ downtime – is it quantified
      We all understand that in the event of a natural disaster interruptions can not
      be entirely planned for. But, there needs to be provisions – in the event of.
      Most vendors anticipate interruptions and will have language in their
      contracts that protect them – which makes sense for any business. But what
      is fair for one should be fair for all.
      All application service providers should have a written service level standard
      that covers all customers. One should have a copy of this document and it
      should be an attachment to all contracts. And at a minimum the service level
      standard should guarantee 98 percent uptime to the customer – if not then
      there should be some statement that delineates the financial consideration to
      be received by the customer. Rights are important to both parties but you
      want to have a contract where the customer has some teeth.

2. Contracts and Commitments - When one is about to make a commitment
   to enter into a partnership with a vendor for application service – software
   only or hardware and software – both parties must make their intentions
   clear – probably a lot clearer than those a couple make when they get
   married. The service level standard as mentioned before is very critical to
   this arrangement. The customer has got to know the motivation of the
   vendor as well as understand the vendor‘s commitment. Some vendors are
   just interested in the sale, and then they are off to focus on the next sale.

   Ten years ago there wasn‘t much competition for those customers looking
   for hosts, but today the competition is vigorous. There are even vendors that
   have attachments to their contracts called ―voluntary contract policy.‖ The
   purpose of these types of documents is to add reality to the vendors offer and
   to provide something of value in the exchange – for a long term commitment
   there is a reduction n in the price. The major vendors today seem to feel that
   a seven (7) year commitment by a customer allows the vendor the ability to
   recoup their cost of investment in software and hardware and to turn a profit.
   What one has to recognize is that the vendor‘s cost and the customer‘s cost
   for hardware and software are not the same. But, there are financial benefits
   that each receives from the arrangement.
   There are elements that one needs to look for in the contract:
      Is there a service level standard for all customers
      Is the vendor ready to earn your business month in and month out –
         day in and day out
      Is the vendor offering more than the service required at a reasonable
      Long term contracts indicate mutual commitment, but they should
         always be the customers choice
      Are the discounts received for long term commitment adequate
      Is there a provision for extension of service

3. Training and Technical Support - Governments are in fact a service based
   industry. Governments are responsible for seeing that there customers are
   cared for. Governments are responsible for insuring that their personnel are
   well trained to handle what ever may walk in the door. This same attitude
   needs to be shared by the ASP that is contracting to host your financial
   management functions. As governments provide customer support so
   should the provider. The ASP should be attempting to win the customers
   loyalty every month. There needs to be the opportunity for each party to
   have an incentive for the arrangement to succeed.

     Support is the one element that the customer should be looking for.
     Technical support should be built into the contract and should be spelled out
     as to what one is getting for their money. If in fact the vendor has
     committed to support the software then they have committed to a
     relationship with the customer that is on going 24/7/365. There shouldn‘t be
     additional charges for service. But, there are vendors that have ―support
     packages.‖ The customer decides what level of service they are willing to
     pay for and picks a support package – not knowing what the future may
     hold. Then when you deviate from the support package you picked there are
     additional add on fees – which can be very pricey.
     The other element that many vendors are proud of is there training. Many
     vendor contracts will not even have a section on customer training. They like
     to wait till after the contract is signed and the first call comes in to drop the
     cost per hour on the table for consideration. Turnover in government is a
     given (personnel and financial requirements), and therefore there has to be
     constant training of personnel – old and new. No one wants someone
     untrained to get on their financial system and begin creating errors. Training
     requirements should be built into the contract:
            On sight at the county‘s facility
            On sight at the vendor‘s facility
            Electronically with the use of CD‘s and DVD‘s
            Electronically with the use of Webinars

The Service Level Agreement (SLA)
      As you construct the SLA, you need to think about three major aspects:
scope, mechanics, and remedies.
     Scope - Your SLA scope must be broad enough to address all the critical
     components of the ASP delivery model. A useful guideline is to include
     system, network, and application performance within the scope. This ensures
     coverage of the critical components, and provides a framework for end-to-
     end service levels regardless of whether the ASP directly provides all the
     delivery components.
     Mechanics - The SLA mechanics are crucial to the effective management of
     the service levels and the relationship. You must define specific and
     measurable performance metrics. The SLA should include both the metric
     definitions and measurement process. Any debate regarding the metrics and
     their measurement should end before you sign the contract. The SLA should
     also detail the change process and issue escalation mechanics. Define now
     the process for making any changes to your service in the future. Likewise,

     define and document the process for handling issues. If the first level of
     operational managers can't satisfactorily resolve an issue, how quickly does it
     escalate and to whom?
     Remedies - The final aspect of the SLA is the remedy. Unsatisfactory or
     untimely performance should trigger performance remedies. The purpose of
     discussing remedies is to first eliminate from consideration those ASPs that
     won't be able to deliver your required service levels and second to focus the
     selected ASP on meeting its guaranteed service levels.

Selecting an ASP
       About every eighteen to twenty-four months the technology industry
identifies the latest in a long line of silver bullets that will simplify the delivery of
technology's benefits to the business world. The Application Service Provider
(ASP) model has enjoyed that distinction and the accompanying hype.
Unfortunately, wading through the hype to determine if this particular silver bullet
can bring value to your governmental process is an arduous task. Selecting an ASP
is no different from selecting any other type of service provider. Your selection
criteria should be aimed at answering the following three questions:
     Does the ASP's offering meet your business requirements?
     Will the ASP be around as long as you expect to need it?
     Can the ASP deliver the functionality at your required service levels?
       The first question reflects the simplest and most important principle: clearly
define your requirements before selecting a solution to meet them. If you don't,
you can't adequately answer any of the questions. Also, when you are defining
your requirements, think beyond your current needs. How might your business
strategy impact your needs several years out? What's the minimum duration for
which you need this relationship to last? If you can answer that question, then you
only want to consider ASPs that will be around at least that long.
       That brings us to question number two. However, given the maturity of the
industry how do you evaluate the viability of the providers you consider?
Although the industry is immature, you still follow basic due diligence procedure.
You deal with the immaturity factor by setting your risk tolerance requirements at
a level that doesn't eliminate all the players. The due diligence questions aimed at
answering question two should include the following:
     How long has the vendor been in business?
     How long has the firm been delivering the specific functionality that you are
       interested in?
     How strong is its financials-income statement & balance sheet?
     What is the firm‘s funding sources?
     What does the firm see as its market?
    What are the firm‘s growth plans?
    How many customers does the firm have and how big are they?
    How many customers has the firm lost in the last year and why?
    What does the firm see as its competitive advantage?
    What portion of its infrastructure is internally provided and managed?
    What portion of its application portfolio is internally developed and
    Describe the firm‘s alliances/partners?
    How are they funded?
       Question three addresses the key issue.
          Can The ASP Deliver?
          Can the ASP deliver the functionality at your required service levels?
     In order to answer that question you need to examine the operations of the
ASP. Your examination should include the following major area:
           What components of the delivery infrastructure do you directly
             provide? Indirectly?
                 For components provided indirectly - Who provides them?
           What is their customer base and how do you compare with other
           What is your SLA (Service Level Agreement) with that provider?
           For all infrastructure components regardless of who is delivering
                 Examine the procedures, methodologies, and tools addressing:
                    Systems Management
                    Integration
                    Change Management
                    Performance Measurement
                    Upgrade installation
                    Security
                    Disaster Recovery
           Describe the current infrastructure capacity and any growth plans.
                 Administration
                 Human resources
           What is the staffing by function within the ASP?
           What are its staffing growth plans? - Change Management
           What is the process for handling changes to service? - Customer
             service model
           Who will own servicing your account?
           What staff will be working on your account?
           What is the problem notification process?
          How are issues escalated?
       The examination of the host's operations will help determine if it can meet
your service levels. The formal Service Level Agreement (SLA) will then
establish the framework for managing the service levels and the relationship with
the host.
      The ASP model is not a silver bullet after all. It is another selection in the
expanding menu of ways for businesses to access technology. The model brings
with it the strengths and weaknesses inherent in any third party sourcing model.
Organizations should look past the glitter, and seek to evaluate this model in a
systematic fashion to minimize business risk.

Outsourcing Categories
       Outsourcing is a very diverse market, and there are many different
outsourcing options and outsourcing service providers to choose from. There are
three broad outsourcing categories:
          Application software
          I.T. infrastructure, and
          Business process outsourcing (BPO)
    1. Application Software - is a subclass of computer software that employs
       the capabilities of a computer directly to a task that the user wishes to
       perform. This should be confused with system software which is involved
       in integrating a computer's various capabilities, but typically does not
       directly apply them in the performance of tasks that benefit the user. In
       this context the term application refers to both the application software and
       its implementation. There are many subtypes of application software –
       enterprise resource management software is one subtype. ERP addresses
       the needs of organization processes and data flow, often in large distributed
       systems with many differentiated users. Such as:
          Financial,
          Customer Relationship Management,
          Supply Chain,
          Databases,
          Information worker software,
          Product engineering software,
          Travel Expense Management,
          and IT Helpdesk)
    2. I.T. Infrastructure - I.T. infrastructure outsourcing involves the
       operations of the I.T. data center and the related network to or from all of
       the organization‘s various sites. This type of outsourcing was first

   pioneered by EDS, CSC, IBM and others.      Typically, an I.T. infrastructure
   outsourcer is responsible for some or all   of the following hardware and
   software components:
          Data communications                   Telecommunications
          Internal network                      Internet connections
          Firewalls                             Mainframe computers
          Servers                               Desktop PCs
          Laptops                               Handheld devices
          Printers                              Phones
          Operating systems,                    Desktop software
 A government will typically look to outsource its I.T. infrastructure in order
 to obtain a more predictable cost structure, while receiving a well-supported
 and highly reliable system, with very high system uptime, and rapid
 response to problems. The following activities are typically included in the
 I.T. infrastructure outsourcing arena:
            Physical facilities setup and maintenance
            Site security and environment control
            System security
            Data storage, backup and recovery management
            Disaster recovery
            Hardware/software procurement
            Help desk/end-user support
            Desktop break-fix
 Unlike application software, where a large percentage of the outsourced
 work will tend to be performed at a remote location (i.e. offshore), a
 majority of the I.T. infrastructure outsourced work will be performed at the
 client‘s locations (i.e. onshore or on-site). This is due to the nature of the
 work. Although new software solutions now make it easier to remotely
 monitor a client‘s I.T. infrastructure environment, much of the work must be
 physically performed on-site. And, with governmental clients we are seeing
 more and more require the host sight to be in the continental United States.
3. Business Process Outsourcing - Business process outsourcing (BPO) is
   the broadest category of outsourcing. It seems like almost every day some
   firm is introducing a new way to outsource a work process. There are
   some common activities that fall under the heading of BPO. These more
   typically outsourced activities include:
           Transaction processing              Tax processing
           Claims processing                   Check processing
           Card processing                     Finance and accounting
           Collection and billing              Receivables management

               Payment services                     Creditors management
               Financial accounting                 Customer relationship
               Call centers (non-IT)                Customer care
               Customer support                     Collections
               Human resources                      Payroll management
               Benefits management                  Payroll processing
               Training                             Recruiting
               Records management                   Supply chain management
               Physical material control            Inbound transportation
               Warehousing                          Outbound transportation
               IT-based supply chain services       Order management
               Warehouse management                 Inventory management
               Freight forwarding                   Transportation management
      Other areas that are emerging in the BPO space include:
                Engineering/design                   Drafting services
                Design digitization (paper to CAD) Design conversion
                Transcription                        Language translation
                Procurement services                 Accounts Payable
    4. Risks
       Political risk as county jobs may be eliminated (however, vendor may
         offer those displaced a position)
       Some transactions may be inappropriate for processing by non-County
       There may be a fear that data is less secure and less available
       Offer limited flexibility – these solutions seem to work well in a
         standardized environment, but tend to break down when an entity has
         unique needs

      When a vendor contracts work from a government, it is typically called
outsourcing. Outsourced work is usually performed locally (onshore outsourcing),
in other countries in roughly the same time zone (near shore outsourcing,) in
countries that are many time zones away (offshore outsourcing), or some
combination of the above. Literally any activity that is performed by a government
can be, and probably has been, outsourced.
      A government contracts with an outsourcing provider to perform a defined
scope of work, and the outsourcing provider charges the company a fee. The fee
can take many forms: by the transaction, by labor hour, cost per unit, cost per
project, or annual cost. Governments choose to outsource for many reasons. It is
common for companies to embark on an outsourcing effort in order to lower costs,

improve service, obtain expert skills, improve processes, or improve focus on core
       Nevertheless, outsourcing is not right for every government. A government
may be too small to effectively outsource. The government‘s culture may not
appropriate for outsourcing or there may be customer reasons that limit or prevent
the government‘s ability to outsource. Some government agencies do not allow
their contractors to outsource anything to an offshore location or management
leadership may not be prepared to manage an outsourcing relationship.
       Governments that are interested in outsourcing some or many of their
operations need to take a strategic look at their management structure and their
operations. Selecting a process to outsource, selecting the right provider for your
government, and establishing the new business processes required to support the
relationship, are not casual efforts. In fact, they are significant undertakings that
deserve management‘s attention and devotion to ensure that your government does
not embark upon a failed effort.       Governments must balance the potential
benefits of outsourcing with the potential pitfalls, and develop programs that
manage the risks and achieve the intended rewards.
       It is quite easy to jump into an outsource relationship, only to learn that you
have selected the wrong partner, your internal processes are inadequate or your
employees are unprepared to support and manage the relationships with your
outsource provider. Governments must make sure they undertake a focused
change management process that educates all of the company‘s employees to the
rationale behind the decision, the approach, and strategy going forward.
       Unlike software that has features and functions that can be readily reviewed
and compared, services (such as outsourcing) are much harder to evaluate and
compare. When selecting outsourcing providers, governments should identify and
prioritize the criteria that are most important to them. Each government‘s needs
are unique, and no one provider is right for all government. Additionally, no one
provider is necessarily the best choice to outsource all of the various processes of a
government. Governments should define which performance criteria are important
to them. These criteria become the basis for service level agreements (SLAs) in
the contract.
       Get help from an experienced consultant. The consultant can help you
create a list of suitable providers, select a provider, and construct a solid contract
with effective SLAs. Start with a pilot. Outsourcing is not an all or nothing
proposition. It is important to learn about your chosen provider, and about your
own government structure. Both entities need to be open to learning and accepting
different ways of communicating and doing business.

Recommendations for Outsourcing Providers
      Outsourcing providers need to ensure that they deliver strong value and
excellent service to their customers. The provider is providing a service, which
means if the customer is dissatisfied, the customer can skip the service and does it
themselves (barring contractual obligations). Outsourcing providers must invest in
implementing the right processes, and not just providing cheap labor.
       Smaller providers should consider specializing in a given vertical or set of
vertical markets, as well as specialize in a given area within outsourcing. Once the
provider builds its reputation in that arena, it can then begin to expand into nearby
verticals and outsource areas. Larger providers should look for ways to leverage
complementary strengths between their business units so as to provide one stop
shopping and a synergistic benefit for their customers. Ideally, providers should
ensure that customers receive added value when obtaining more than one type of
service from a given provider.
       There are literally thousands of outsourcing providers in the world today,
and more are being launched everyday. Providers need to establish a solid
reputation and brand, and should have very focused marketing efforts targeted at
their core target market.
     Unlike software that has features and functions that can be readily reviewed
and compared, services (such as outsourcing) are much harder to evaluate and
compare. Providers will find ways to differentiate themselves from their
competitors. Outsourced services that are not differentiated might be purchased as
a commodity, with the provider selection based solely on price instead of value.

Mary Lacity and Rudy Hirschheim, ―The Information Systems Outsourcing Bandwagon,‖ Sloan
   Management Review, Fall 1993
Michael Moss, Information Technology Outsourcing: A Handbook for Governments (Chicago,
   Gordon and Glickson LLC, 1998)
David Tapper and Cynthia Doyle, ―Recent Outsourcing Growth Results,‖ IDC Bulletin
   (International Data Corporation, 2002)
GFOA and the Center for digital Government, ―A Strategic Guide for Local Government on
   Outsourcing,‖ 2004

                                 CHAPTER VIII

                                 THE VENDOR

Beware of Vendors Bearing Solutions
       Years ago the industry called it "leaning into the wind." It was a
philosophy—maybe even an art of doing business — that enabled software
companies to be competitive, to build market share, and to sell sufficient product in
a timely enough fashion to fund ongoing development. If they leaned too far into
the wind, they would fall on their face. If they didn't lean far enough, they would
watch as their competition took the market share upon which dreams had been
       ―Leaning into the wind‖ is a metaphor that used to mean announcing,
marketing, demonstrating, and even selling something that you calculate will be
ready by the time the customer is prepared to actually use it. It was a complicated
calculation ten to fifteen years ago. Not quite the square root of development
effectiveness times the standard deviation of sales aggressiveness divided by the
total number of competitors in your market minus the pressure from the venture
capitalists - but close.
      Ten years ago the industry conducted business aggressively, but ethically.
The intent with most vendors was to deliver to the customer what they needed
when they needed it however close to the deadline it was. Once in a while the
vendor was late, but they would always make it up to the customer - Always.
        During the last five years, leaning into the wind has transformed itself into a
level of hype in the enterprise solutions marketplace that would make the
aluminum siding salesmen of the 1950's hide their wallets and run for cover. That
hype has been a major factor in the recent downfall of some of the industry's most
illustrious players.

      Were lie detector tests available to IT management today, fewer of them
would have to leave their former jobs in embarrassment, fewer companies would
be at the brink of survival due to new system implementation "snafus" and far
fewer vendors would be out there Power Pointing their way to the next quarter's
sales goal or the next big IPO. Two of the reasons for that hype are the vast
number of competitors that are transforming what were differentiated solutions
into commodities and the pressures felt by the publicly held companies to deliver
numbers aligning to Wall Street expectations.

     Consider these examples of how serious the hype has become that IT
management is facing:
   A sales team employed by a publicly-held enterprise resource planning
     (ERP) provider surreptitiously coded an application prototype matching
     customer-required functional capabilities, and then represented that as
     standard product to win the deal. When the customer found out what
     happened, the vendor was sued. It was not the first time this happened with
     that vendor.
    A well-known solutions provider's sales teams routinely "forgot" to tell
     prospects that an additional (and expensive) piece of hardware was required
     in order to run that vendor's next generation version of their product. Even
     after the requirement was mentioned in an industry report, the practice
     reportedly continued.
    Some vendors routinely announce partnerships with other vendors. In many
     cases, this is not strategic, but rather slapped together to win an individual
     sales campaign where the prospect requires integration of both products. A
     press release is issued, the deal is signed, and three months later the
     customer is left without the answers to such questions as, "what happens to
     me when there is a new release of either product." By the way, most often
     the names of those partners remain on the web sites of both vendors as proof
     that they are offering a "broad footprint." Prospective buyers are left with
     the mistaken impression that something more valuable than the distribution
     of a press release was accomplished. This too is hype.
    Some of the vendors who failed to turn a profit for 2003 and 2004 and
     whose very survival is at risk today are the same vendors who cut their
     prices far below profitable levels to win deals out of desperation because
     none of their other questionable selling tactics worked. (And they managed
     to convince those buyers they were getting a good deal.)
    Some vendors who claim hundreds if not thousands of customers have
     trouble producing five good references when pressed by a prospective
    By now we are familiar with how the large consulting firms and others steer
     software evaluations to the vendors with whom they have partnerships. At
     the same time the fact that those very consultants have trained, in some
     cases, thousands of their own people on those vendors' products is not
     hidden from those who would look on the vendors' and consultants'
     websites. Is it possible that the consultants steer the customer not toward the
     best solution, but toward the consultant's partner's solution to keep that

      consultant's thousands of employee's utilization rates high? If you believe
      that this is possible, you understand hype.
    As the tier one software players have begun to drive downward into the mid-
     market, pictures are painted and visions are portrayed of the benefits of
     Fortune 500-like systems in those $80 million companies. It just doesn't
     work that way. More hype - The people implementing and using the
     systems are different and the cultures are different. Smaller companies
     generally have very limited experience managing complex projects and most
     importantly, the financial, and personnel tolerance for mistakes is
     dangerously low. A mid-market company is not a small Fortune 500

What Are the Implications?
       When these systems fail to do what was promised there is always a hefty
price to pay: Increased costs, unhappy end users customers, angry officials, unpaid
suppliers, out of control budgets, faulty reporting, and damaged careers. Then
those responsible for some of these unfortunate decisions move on to other jobs in
the government and only now are we beginning to see the impact of the hyper-
marketing and hyper-selling trend of the past five years: Software that has never
been implemented and companies are still paying annual license fees, as well as
past due bills for all the consultants who were part of the "solution;" aborted
projects where replacement packages were quickly found driving the cost as high
as two to ten times the original project projections; governments missing critical IT
deadlines for the development of critical integrations; leaving personnel and
officials severely exposed from a financial and personal perspective; and the very
companies that did the hyping are losing money, or in some cases out of business,
leaving their customers in an understandable state of fear.
       With news about the latest IT disaster coming every week, evaluation
committees are trying desperately to figure out how to assure themselves and the
companies for whom they work that every risk is at least recognized, if not
eliminated. In many cases they are going about it the wrong way. The elimination
of risk is not the result of a thicker Request for Proposal (RFP).

      Without intending to outline a comprehensive evaluation process, there are
some very simple things that you can do to protect your county from being
tomorrow's lead story in the industry trades. If you are going to hire a consulting
firm to assist you with your requirements, consider using a different firm to
manage the implementation, so there is no conflict of interest. Better yet require
the vendor to do their own implementation – don‘t allow a third party to do it.
    If you use an RFP as a tool, warn each vendor that you will be spot-checking
     the answers. Then spot-check the answers. If any vendor is found
     misrepresenting their capabilities in any way, eliminate them from
    Require a minimum of ten references from each vendor who makes your
     short-list. They should be governmental references, of your size, and with
     similar requirements. If the vendor claims they have hundreds of customers
     and can't produce ten, eliminate them because they have a sales ethics or
     customer service problem. Call every reference and speak to at least two
     people at each company. That will likely eliminate the "friend of the sales
     rep" effect.
    Carefully measure how well the vendor understands how their solution will
     impact your county. If the sales team doesn't take the time and effort to
     understand your needs and has no knowledge of or experience in our
     industry, history suggests you will lose.
    Check on the employment longevity of the sales and services teams. If
     attrition is high, there are likely problems.
    Make absolutely sure that you go to a user group meeting and don't let the
     vendor restrict your movements. If they try to control your access to other
     customers, they have something to hide.
    Finally, take the time to visit current users – on your own – without the
     vendor present. Take time to see how the system is being used, how
     operations are being conducted and how reports are generated and used.
     And, don‘t be in a hurry.
      There are certainly vendors who have great products and services that don't
oversell and over-market. They have happy customers who have been more
successful since implementing those vendors' products. But ironically, those
vendors are often not included on long lists because of lack of market presence.
That is most often due to relatively small marketing budgets, and a generally
unwillingness to play the hype card.
       Once the needs assessment has been completed and the deliverables have
been set down, the burden remains on management to understand and minimize the
risk involved with evaluating and selecting business solutions. Once the risks
posed by the negative trends affecting the enterprise solutions marketplace are
internalized, management will likely search out a greater number of potential
solutions, not just the obvious ones. Management must relentlessly qualify all of
them. Tough questions must be asked and answered. In some evaluations, for
example, one vendor's integrity (validated by their current customers) may be
given more weight than another vendor's future product announcements, long list

of partners, or the number of buzzwords embedded in their latest press release. In
this vortex of hype, when it comes to new ways of evaluating potential suppliers,
an open mind is definitely required.

The World Of Software Buying Has Changed; Will the Vendors Change With
      How governmental entity buys software has changed, forever. Buyers are
skeptical, risk adverse, and tighter with their budgets. What are those changes,
why did they happen, and what does it mean for the both the buying enterprise and
the selling vendor? For some buyers, they are very aware of the changes. For
most, the change has been subtler. The subjects they investigate have changed.
The buyers are better informed today. The subjects are more challenging, and
buyers want more detail and more proof. For software vendors that don‘t
recognize and address these changes, selling application software will become
increasingly difficult.

History Builds Skepticism
       Everyone saw the dot-com bubble burst and then re-inflate. For the software
industry, it had an obvious impact - the availability of venture capital became
scarce. A less obvious impact came with the skepticism of the buyer. The dot-
coms and others made many statements about their impact on the economy in
general (The New Economy) which at the time proved very false. The dot-com
hype has spilled over to all technology vendors and all are now seen as hyping
their benefits, and what their product can do, etc. Vendor claims are now met with
a healthy skepticism. Vendor claims are now met with a spoken or unspoken
reaction of ―Prove it!‖
       The late 90‘s and early 2000‘s heard a roar of outlandish vendor claims.
Vendors bragged about their products saving billions of dollars. Some of those
vendors are now shadows of their former self and these claims are now seen as
false claims or worse. The benefits hype of this period is another reason that
today‘s buyers are skeptical of vendor claims. If a vendor could be so very wrong
and even unethical about these claims in the recent past, why should buyers believe
any vendor today? Many software buyers recognize that the same people that were
hyping software with unsupported claims are still in the industry today - they are
just working for different companies.

       Today, all vendors suffer from a lack of credibility at the beginning of the
buying process. Vendors recognize this lack of credibility and are now marketing
their products in a way to overcome history. However, without credibility, their
claims will not be accepted and their efforts will suffer. Regardless of the true
value that their software may bring, without credibility that value sounds like the
unsupported, over-hyped claims of the past.

       Today the economy is strong and has been strong for four years. Those
Governmental entities that have a strong surplus balance are still conservative in
their spending on informational technology. This means tight budgets and fewer
buyers in the market. Tight budgets have resulted in buyers lacking the internal
resources to implement new software. This causes buyers to more fully investigate
the implementation requirements for any purchases they are considering. The lack
of internal resources can be compensated for with vendor services, but budgets are
often not available for these services.
       Fewer buyers in the market means increased pressure on vendors. Many
vendors rely on new buyers as their major source of revenue. As one vendor
executive stated, ―We have too many vendors chasing too few deals.‖ That
translates to desperate vendors that result in buyer questions about vendor integrity
and honesty. Can the vendors keep the promises they make? Major discounting is
a way of life for some vendors but buyers should think about such vendors‘
product and services being ―too cheap‖ such that the vendor cannot afford to meet
their commitments.
      Thus, the impact has been felt in the vendor community and we are now
seeing the Tier I products being fashioned to sell in the Tier II market, and the Tier
II products in the Tier III. In addition we have seen much of the market
consolidate in recent years. We have seen mergers and consolidations among
vendors to better address the needs in the market. And today the municipal
industry has been relatively uncharted until the early 2000‘s. The question of
business viability was long limited to smaller or start-up vendors. Buyers now
question the viability of all but the largest vendors and even then, they question the
financial independence of those vendors. The questions include, ―Will you be in
business?‖ and ―What happens to me if you are bought out?‖

       Buyers are more aware of the risk involved in major purchases and
implementation failures. The press and analysts have reported the wide spread
lack of return on investment ROI and run away implementation cost in many IT
projects. Risk comes in other varieties; the product not performing as promised,
intolerable business disruption, and others.          In the current employment
environment, decision makers and selection teams are also concerned about
personal risk: if I go with this project, and something goes wrong, what happens to
me? A failed implementation is truly a life changing event. Failure is the risk that
is seen as the greatest risk. And they get the most publicity - the lack of financial
and human resources means that a project failure resulted in the wasting of those
limited resources.

Vendors Face a Cross Roads
       Many vendors will tell you that they have faced some of the most difficult
sales cycles in their careers over the past few years. Many of these same vendors
remain hopeful that the economy will stay strong. They are anticipating some
normalcy to enter the market. ―Normal‖, however, has changed. The previous
overzealous buying environment is behind us, and the new buyer has emerged.
Vendors that stick to their knitting and believe that the good times will return have
missed the marketplace shift. Leading vendors have recognized this shift and
changed their marketing and sales approaches to compensate, or even take
advantage of the new buying scenario.
       Buyers should be prepared to ask the hard, tough, ugly questions that are
needed for the governmental entity to feel comfortable with the selection and
project. Be up-front about concerns and doubts, demand more detail and more
proof. Only by addressing these issues directly can you get the answers you need.
Vendors should be prepared to address these questions. The most effective
vendors will anticipate the questions and build their sales and marketing efforts to
directly answer the questions and to give your company the credibility required to
be believed in these skeptical times.

Being prepared takes on a completely different meaning!

                                 CHAPTER IX

                             Contract Negotiations

Always Establish Position
       In the art of negotiation, whether it is business or personal requires planning
and execution. Unlike toddlers, who negotiate by crying and rolling around on the
floor, adults need to employ a different skill set to get their point across. The
following are some tips for successful negotiation.
   1. Before the meeting be well rested and well fed - also visit the restroom
      before entering the arena as you don‘t want a nature call to have you leave
      the room or adjourn the meeting early.
   2. Wear comfortable, yet appropriate clothing - the commercial expression
      don‘t let them see you sweat is never more applicable. A tight collar and or
      tie or a skirt that is being hitched or hiked that will cause you to fidget will
      detract from your image.
   3. Focus on issues, not personalities- if you have to deal with persons you don‘t
      like (or those you do like) it is tempting to let your thoughts about that
      person influence your behavior. Focusing on your goal and treating
      everyone as an equal will help matters become resolved in your favor. By
      treating all fairly you will avoid simmering about grudges or worrying about
      feelings, which can be an obstacle in your success.
   4. Speak in supportive statements - Attach credibility to your statements by
      speaking in facts not feelings. Avoid sentences beginning with "I think I
      feel..." or "In my opinion..." When stating facts, be prepared to quote your
      sources and elaborate or deflect questions meant to deflate your position.
      Being armed with facts stands up better than trying to justify feelings.
   5. Listen (with more than your ears) - Listen for audible content but also watch
      the body language. Are your opponents sitting with an open body posture or
      are their arms tightly folded across their chest? Are they scratching their
      nose often in disbelief? Are they looking down or are they engaging you
      with their eyes in a game of blink to establish who is boss?
   6. Find points of agreement to build on- pick up points that you agree upon and
      incorporate them into your presentation. An example would be ―I agree with
      you on the importance of XYZ, and this is how the implementation of PDQ
      can benefit XYZ".

  7. Choose your battles wisely and place some decoy items on the table - a trick
     popular with attorneys is to ask for much more than you want so that you
     can sacrifice superfluous or unreasonable items to gain ground for the
     important issues. Compromise with care on items important to you - weigh
     carefully whether holding out will be in your best interest - sometimes a
     speedy resolution isn‘t the best.
  8. Take minutes - Have someone tape or take minutes so that all that has been
     said is recorded. Reiterate that your responsibility will be and that you will
     execute your part right away. If in a business meeting you can end by
     saying I will have this in a memo to distribute this afternoon or I will make
     the necessary phone calls to get this rolling right away. If contracts are
     involved, have them ready on the spot or as soon as possible to get a
     signature to what has been agreed. Although most contracts have a cooling
     off period of three days or so, getting a written commitment to your
     settlement brings you that much closer to your goal.

  9. Always end a session on a positive note - Shake hands and smile. A smile
     shows friendliness and confidence and that you are a person they want to do
     business with, even if everyone in the room wasn‘t altogether pleased with
     the outcome. Conversely, if you did not get all you wanted, don‘t appear a
     bad sport. Focus on your wins and play down the losses. Take honest notes
     to yourself on your tactics and see how you can improve for next time.

Anticipating the Negotiations
      Although you can do many things to get ready to negotiate, you should
always take these four essential steps before you open a session:
  1. Prepare your goals. Take time before you negotiate to determine your
     goals and how important they are to you. Would you be willing to give up
     certain goals in exchange for others? Know exactly what you need to
     achieve in your negotiation, and be prepared to get it.
  2. Research pertinent background information. What do you know about
     your clients? A wide range of information about the organizations you plan
     to negotiate with is usually available. (Do a few different searches on the
     Internet, for starters.) Use this information to help plan your negotiation
     strategies for achieving your goals.

   3. Evaluate your positions. What do you expect the vendor‘s positions to be?
      Put yourself in their shoes for a moment and anticipate their issues and
      positions on critical areas. After you do that, determine how you will
      counter them if and when the vendor introduces them.
   4. Prepare your own positions. Before you enter into any negotiation,
      prepare the positions, or wants that you communicate to the other party, that
      you will present and defend. Also, prepare back-up positions in the event
      that your primary positions are not acceptable to the vendor.

Basic Rules of the Art of Negotiation
      In negotiation, a number of basic rules have evolved over millions of years
of human existence. Master the following rules, and you will be a real pro at
   1. Be prepared. Being prepared gives you a definite advantage in every
      negotiating situation — so much so that the downside of not preparing for a
      negotiation far outweighs the small amount of time and effort that it takes to
   2. Leave plenty of room to maneuver. When you develop your negotiation
      goals and positions, build in enough flexibility to allow you to modify them
      to better achieve both your clients' goals and your goals.
   3. Have lots of alternatives in mind. For every possible reason that your
      client gives for not agreeing to one of your positions, you should have one or
      more alternatives ready to go.
   4. Keep your word. In business, as in life in general, your word should be
      your bond. Negotiation is built on a foundation of trust and mutual respect.
      If you aren't willing to keep your word, then you'll quickly lose both trust
      and respect.
   5. Listen more than you talk. One of the most important negotiating skills is
      the ability to listen — really listen — to the other party. If you ask the right
      questions and then let your counterpart talk about the answers, you usually
      find out exactly what it will take to successfully negotiate and close a deal.
   6. Don't give up too much too soon. Take your time when you are negotiating
      with your vendor. It's better for them to be in a big rush to close the deal
      than for you to be in a big rush to close the deal.

   7. Learn to say no - gracefully. When you're negotiating a deal, sometimes
      you have to say no if you want to achieve your own goals. For example, if
      your vendor wants you to allow for the insertion of third party products and
      you don't want to do so, then just say no. And if there is no alternative to be
      offered – then negotiation may have ended.

Closing a Deal
      Closing your deal successfully is the ultimate goal of every negotiation. The
more you do it the better you get. Here are a few tips to help ensure that you close
your deals efficiently and with a minimum of bumps along the way:
   1. Give your vendors lots of reasons to say yes. The more reasons your
      vendor has to say yes, the greater the chance that they will say yes. Find as
      many ways as you possibly can to make it easy for your vendors to say yes.
      If you do, you'll definitely close a lot more deals.
   2. Confirm your agreement. To ensure that your understanding of the final
      agreement matches the other party's understanding, confirm your agreement
      — first verbally, and then in writing.
   3. Don't be surprised by last-minute surprises. Have you ever been in
      negotiations where you reached (or at least thought you had reached) a final
      agreement with the other party only to have them toss in a new demand or
      condition at the last possible moment? Be prepared for clients who use this
      negotiation tactic to wring additional concessions from you. If this happens
      to you, it's a good idea to calmly tell your counterpart, "No, this is not what
      was agreed upon," and demand that they stick to the original deal. If your
      counterpart refuses, you may want to find a more dependable negotiating
   4. Follow up with a thank-you note. Not only is sending a thank-you note a
      nice way to express your personal thanks to your counterpart, but it is a great
      way to build rapport.

   5. Move on if you can't close the deal. Despite all your efforts to reach a
      mutually beneficial agreement, some deals are just not meant to be. If this is
      the case, and there's nothing you can do to bring negotiations to a successful
      close, then simply walk away. By breaking off negotiations, you show your
      vendor that you're serious, and they may very well make the final
      concessions necessary to close the deal. If not, then you can get on with
      your life and direct your efforts to more fruitful pursuits — such as lining up
      the next possible choice.

Understanding Contracts
      Business contracts are used to memorialize important agreements your
government enters into with others. So what's an "important" agreement? Any
agreement on which you are relying and that can affect the future of your
governmental functions. Sure, small business owners operate all the time on
informal understandings that they may never write down or even completely
verbalize to the other party. But with County government a formal contract is
required. Contracts allow the parties the opportunity to:
      Clearly define their obligations to and expectations of each other
      Limit their liability
      Lay out payment terms
      Divide up business risks
      Make sure each side understands its responsibilities
     Here's a quick rule: If you've spent more than five minutes worrying about
whether you need a contract, guess what? You probably do.
      So, what makes a contract a contract? A valid contract typically requires the
following four elements:
   1. A meeting of the minds between the parties demonstrating they both
      understand and agree to the essentials of the deal
   2. Consideration (something of value exchanged by each of the parties, such as
      cash, goods, or a promise to do something)
   3. An agreement to enter into the contract (typically evidenced by both parties
      signing a written contract, although oral contracts can be valid, too, in some
   4. The legal competence of each party, meaning the parties are not minors and
      are of sound mind

Meeting of the Minds
        The first step in creating a contract is making sure that both parties are
talking about the same deal, so that when they subsequently agree to enter into the
contract they are both agreeing to the same thing. Seems obvious, right? Until you
realize that the "vintage red car" you planned on buying from your brother-in-law
isn't the Ferrari, it's his Pinto. Take the time to communicate your understanding
of the deal to the other party, and listen carefully when they talk back.

      After the parties reach a meeting of the minds regarding the deal, they must
both exchange something of value in order to create a contract. Often, one party
provides its goods or services in exchange for the cash of the other party. But
consideration can take many other forms, as long as each party is giving up
something of value to it to convince the other party to enter into the contract. You
can read law treatises defining consideration until the cows come home, but in the
real world your biggest issues related to consideration are how much and when.
If cash is exchanging hands in your contract, think through any assumptions you
are making about the way payment will be made. If you expect to be paid at the
time the contract is signed, say so. If one of the parties will be paying after the
contract is signed, say whether the payment will be in cash, by check, by cashier's
check, or by wire transfer. Be explicit about the way the money will change hands.
For example, you likely want a cashier's check if you're turning over title to a car
or other significant assets.
      If payments will be made over time or based on external factors, such as the
amount of work completed, you may need to define the payment schedule by using
a formula. Keep the formula simple and feel free to put examples of how the
formula works right in the body of the contract. If you have to use a complex
royalty or other payment formula, test the formula with the other side to be sure
you both understand it.
Be wary of gift contracts, where someone gets something for nothing. If the value
one party is receiving is truly free, so that only the other side is giving up
something of value, then the parties probably haven't formed a contract. You
usually can't make someone give you a true gift, no matter how many times the
giver promised to do so.

Agreement to Enter into the Contract
       After both parties understand the deal and understand what type of
consideration will be exchanged by each party, they are ready to form an
agreement. Usually, the parties demonstrate that negotiations have ended and an
agreement has been reached when the parties sign the contract, unless it is an oral
agreement. In business as in opera, it's not over until the fat lady sings — or, signs.
Its fine, within reason, to negotiate changes in a written contract up until the
moment you sign it.

Legal Competence
       Be sure that the party you're working with is legally competent to enter into
a contract. Otherwise, your signed contract may be void and unenforceable. Even
if the other party wears a lampshade on his head, he may be legally competent. But
watch out for the following situations:
    Persons lacking sound mind usually cannot enter into contracts because, the
     reasoning goes, they lack the ability to understand what they are doing and
     to create a "meeting of the minds." Persons lacking sound mind generally are
     those who are mentally handicapped or impaired by the use of drugs or
     alcohol to such an extent that they cannot understand the significance of
     their acts. So try not to do deals at your local watering hole late into Saint
     Patrick's Day.
    Minors can not enter into contracts – in Texas that is 18 years old and one
    Persons who lack authority to act on behalf of someone else may not be able
     to legally bind that other person or company. So make sure that the person
     signing on behalf of a company or other person has the legal authority to do

Understanding Oral Contracts
       Oral contracts can be as binding as written contracts. But have fun proving
what you've agreed to without a written record. If your deal goes south, you may
feel like Sylvester to the other party's Tweety Bird, endlessly chasing the truth.
Make it easy on yourself and write up an agreement. Often, parties enter into
agreements that are partially oral and partially written, based on a handshake and a
few letters or memos that may indicate some of the aspects of the agreement
without actually being contracts themselves. In this case, the agreement is
contained partly in the oral agreement and partly in the letters and memos. It's best
to put all of the information relating to your agreement in one place — a single,
clear, and complete written contract. Some oral contracts are unenforceable.
These four types of contracts, which involve a high risk of fraud, typically must be
in writing by law:
   1. Contracts for the sale or purchase of land
   2. Contracts for the sale or purchase of goods priced at $500 or more (with
       some significant exceptions)
   3. Marital settlement contracts (a promise to do something swapped for a
       promise to marry, such as a promise by Dad to give the groom a job after the
       groom marries his daughter) or prenuptial contracts
   4. Contracts that cannot be performed within one year of the time the contract
       is made (such as a contract to buy your office 13 months in the future)

       It's true that a written agreement is not final until signed — unless you
indicate your agreement to the deal otherwise; say, with a handshake. Don't let an
oral agreement sneak up on you by verbally agreeing to a deal before you are really
ready to sign it.
      Lousy reasons for an oral contract:
       1. I'm too busy to write it down. Overworked businesspeople fail just as
          often as lazy ones. Find the time.
       2. The other party won't agree to write it down. News flash — you may
          be entering into an unstable business relationship. The world is full of
          honest people, and none of them mind putting what they promise in
       3. I trust the other party. Uhmmm, hello?! We're all nice people here, but
          remember the old Richard Nixon line: "Trust everyone, but cut the
       4. The deal is too complicated to write down. Odds are that it's not too
          complicated; you just don't understand it. Take the time to write out the
          deal and hash out any unclear points with the other party as you go
          along. If you don't understand, how will a judge or jury understand it
          when you enforce it?
       5. It's a great deal for me — I don't want the other party to think it through
          too much. Guess what? The other guy is thinking the same thing about
'Nuff said. Get it in writing.

Formal Agreement
       A formal agreement which outlines the responsibilities of the parties is
obviously the best way to proceed. However, the disadvantages are the time delay,
costs and the friction that may be caused between the parties. All of these
disadvantages can be overcome by selecting an appropriate practitioner who is
skilled in the area and familiar with the technology.
      Evaluate the risk, choose a method which achieves the objectives, and
remember investing time and money in documentation now can save a great deal
of time, money, loss and damage in the future. During contract negotiations,
"customers often come up with great ideas to tie value to performance," said Todd
Larson, director of application development at Eaton Vance Management, a mutual
fund company in Boston. But by the time a contract is signed, said Larson, "most
of those ideas have dissipated." One of the big problems that leads to what he
described as contract "value leakage" is a lack of coordination within technology

      There are big gaps between vendor salespeople, contract managers and the
people who deliver [products and services]," Larson said. Contract negotiations
are beset by other problems, Kliman noted. "In practice, most organizations
believe there's a trade-off that has to occur between obtaining either a good
working relationship (with vendors) or obtaining good business results," he said.
When confronted with such a choice, most IT contract negotiators opt for good
business results instead of making organizational changes to try to accommodate
Another option, Larson said, would be to present these choices to end users and
other stakeholders, let them prioritize the most important goals of a project "and
then present their interests at the negotiation table."
      ―IT contracts are often hamstrung by outdated performance measurement
metrics, said Michael Mah, a Cutter Consortium consultant. "We're in a
knowledge society, but we're using industrial economy metrics," such as output per
unit cost, to measure performance, said Mah, who is also a partner at QSM
Associates Inc. in Pittsfield, Mass.
      "The relationship is the most important thing in an outsourcing deal," said
Joseph Imbimbo, vice president of IS Technology operations at Tufts Health Plan
in Boston. Imbimbo, who helped negotiate a seven-year, $20 million applications
outsourcing deal with Keane Inc. four years ago, said, that "you can't get to know a
vendor" sufficiently under a request-for-proposal bidding process. He said he
spent a year working with Keane, a business and IT outsourcing firm based in
Boston, to craft the applications outsourcing deal for Tufts.
       Imbimbo said he spent a lot of time during pre-contract due diligence
considering all of the things that could go wrong under the pact and how or
whether Tufts would be able to extricate itself should Keane fail to meet
performance targets. Martha Crow, managing director of the New England region
for Keane, said many of the contracts the consulting firm now signs contain an
"above-and-beyond clause," where the two companies agree in writing that they
will share the benefits of any innovation that Keane delivers.
       A project suddenly takes off and you needed to finalize your contractual
arrangements last month. What can you do? How can you best protect your
position? In this paper, we will examine the essential elements of a contract and the
options available to the parties to provide a legal framework so that the project can
be successfully completed on schedule.
The options available to the parties are:

Other Elements in a Contract
       In addition to the common elements of a contract mentioned earlier there are
other elements one should consider for inclusion.
           I s there an intention to create a legal relationship
           Details not covered in the agreement may need to have been covered
            in engagement letters or the RFP responses
           Intellectual Property Copyright - works, geographic locations, future
           License - exclusive, permitted use and copying, backup, site(s),
            modification, sub-license, term, irrevocable
           Confidentiality
           Payment - Quantum, when, how, expenses
           Specifications - Software, Documentation, Input, Milestones
            (Deliverables), Output, Standards
           Variation of Specification
           Pre-requisite Hardware and Software
           Consequences of a failure to achieve a milestone
           Acceptance of the Software (linked to payment and maintenance
           Installation and Migration (non-trivial)
           Training
           Maintenance Obligations
           Training
           Time (windows)
           Scope
           Failure
           Training
           Exclusions
           Compulsory software and hardware upgrades
           Training off site?
           Insurance
           Personal Guarantees for development obligations
           Performance Bonds
           Warranties
           Software Design and Code
           Ownership of Software
           Indemnities
           IP infringement for materials supplied by both parties
           Loss and Damage to parties and third parties
           Statutory Requirements and professional advice

          Limitation of Liability
          Escrow
A written agreement, even if not formally structured, which is signed by the parties
to the agreement is at least an undisputed record of the agreement. A bad written
agreement always gives a start point to apply some implied warranties under the
Trade Practices Act, the Fair Trading Act (Vic) 1984 or the Goods Acts or some
express oral terms. As a minimum a Deed of Intellectual Property Assignment and
confidentiality may well get you running from a position of strength.

Vendor Reliability
       If the County has only used simple software programs, it is easy to fall into
the trap of thinking of software as nothing more than a tool. The county may want
to think of it as buying an ―off the shelf‖ package like a carpenter buying a new
hammer. You pick one that feels right and think you are set for a while. This
approach may work for the simplest financial situations, but not for integrated
office functionality. As financial situations become more complex, the typical
―off-the-shelf‖ software solution struggles to track data efficiently and to produce
meaningful reports.
       A more effective way of purchasing software is to view it as establishing a
relationship with a technology solution provider. Start this process by evaluating
firms who focus specifically on the governmental market. This means the
company has more industry expertise from which you can benefit. Try to find a
company that has spent years building products and providing solutions to fill the
County‘s specific needs. In addition to providing software products, the company
must know the challenges the County faces on a daily basis. That way the
company will be there to propose solutions to the County‘s challenges and to assist
the County in implementing them. The company will train your staff and provide
answers to the questions that will inevitably arise as they use the software in the
County‘s specific culture. Over time, a good solution provider learns your
business and knows how to add value to its products through telephone support,
training and consulting. The County should feel that it is receiving a solution built
to serve its needs and delivered specifically for its situation. There is no sense in
today‘s market to think that your county alone is going to have to re-invent the
       In short, by working with a company whose mission it is to meet the needs
of your County, you have a partner who is committed to helping the County to
succeed. No matter how good a product is users still must rely on continued
support from the vendor. For this reason, you want to be sure your vendor is
reliable, has the resources to meet your requirements and will be available when
       Many first-time financial software users are inclined to disregard vendor
reliability - focusing primarily on the product's quality, price or both. However,
selecting a product and then entrusting it with all your financial data is not unlike
the goals of a marriage: the County wants a fruitful, long-term relationship. Once
the product is installed, the customer depends on the software vendor to supply
updates for payroll taxes, sales taxes and even depreciation rates. The customer
also must rely on the vendor to provide training, fix the inevitable bugs, provide
support and continually enhance the product to run on the latest platforms and
operating systems. The continued success of the financial software vendor has a
direct bearing on the customer's continued success with the product.
       The bottom line is that it's usually best to avoid vendors with limited
resources. Typically, the best financial software vendors are profitable and
supported by staffs that are both knowledgeable and large enough to meet the
needs of its customers. In addition, they should have large distribution channels.
Those that sell software as a sideline tend to be less committed to the business. If
the vendor is publicly traded, it's relatively easy to gather information about its
financial health. But if the vendor is privately held, you'll have to do some
investigating: calling on its current customers and insisting that they provide
sufficient in-depth information on its resources. One needs to be especially
mindful of those vendors that are in the market to sell hardware as well as
software. Be sure that the County can discern the vendor's primary focus.

       The single most important question the County needs to resolve before
deciding on a financial software package is whether the software can be
customized - and, if it can, whether the customization will meet your requirements.
In the 1980s, the most successful financial software developers allowed users to
modify their products' source codes - the underlying programming that could be
altered only with the vendor's permission - and even then only a programmer with
knowledge of the product could modify the source codes to add fields, calculations
and capabilities to the product.
       Many users accepted vendors' invitations to modify the software. But they
soon discovered modification was a very expensive and complicated job, involving
months of programming. Worse, while such efforts were successful for many
customers, others were left in chaos when the modifications didn't work properly,
leaving their financial recording and reporting tools inoperative or badly
compromised. Source code modification had an even graver drawback. Once a
code was changed - even slightly - the product no longer could be upgraded
without losing those modifications. So the product's users faced a no-win choice:
If they wanted to upgrade, they had to forgo all the modifications that had made
the product fit their specific needs. The vendors also were unhappy: They couldn't
generate new revenue because, after spending a fortune modifying a product, users
generally opted to stick with the old version rather than risking - and financing - a
second source code modification.
       A further complication was the fierce competition among vendors to add as
many features to their software as possible on the theory that, if they didn't, their
products wouldn't rate well against the competition in the comparison reviews
featured in many professional magazines and trade journals. And as more features
were added, the software became more difficult to use.
       Today, most of the leading financial software products offer a good
alternative to source code modification. Instead of changing the underlying codes,
the developers now develop their products with built-in customizing tools that are
easy to use. For example, many of today's products provide user-definable fields -
those that aren't earmarked for any particular function but that allow customers to
attach their own custom functions and labels to them. Thus, users can create
special fields to accommodate additional information for budgeting, purchasing,
human resources, vendors, employees, inventory items, etc. User-definable fields
now are found in accounting software packages of all price ranges.
important to remember that if the County can use software right off the shelf as
written, it is far cheaper than having it modified. The cost to modify will always
get out of hand, and before you know it the cost is twice as much as the original
software. It is cheaper to change the way the County does business than it is to
alter the software. The second issue is that when upgrades are initiated by the
vendor, modified software does not normally accept the modifications as easily as
the original shelf model. Thus, once a system is modified to meet special needs
upgrades will require additional costs to be incurred to allow the enhancements to
take. Or, the county can just forgo the enhancement all together. Many will tell
you that extensive customization will increase the probability that the
implementation will have problems.

Negotiating a Computer Software Maintenance Contract
       When negotiating a contract with a computer maintenance management
system (CMMS) vendor the guiding principals and definition of the project must
first be determined. Deliverables, pricing options, payment terms, continuance,
product and service quality, and liabilities are additional areas that must be
considered in negotiations.
      Many people find negotiating contracts intimidating, regardless of which
side of the table you happen to be on. This is understandable given what's at
stake—a price, quality of product and service to be provided, and a long-term
relationship. As a result, some governments prefer to retain a lawyer, accountant
or consultant to help them through the process.
      The following are some key elements found in a typical contract with a
CMMS vendor. This by no means, however, constitutes a legal opinion. Rather, it
provides a basic understanding of what might go into the contract from a technical

Guiding Principles
     Mutual gain - building a true partnership with your CMMS vendor requires
     a solid contractual foundation that's fair to both parties. It's too easy to draft
     terms that favor one party over the other, especially when there are major
     differences in the size of the entities entering into the contract. A contract,
     therefore, should allow either party to back out of the relationship at any
     time and remain whole (value for the government in exchange for reasonable
     profit for the vendor).
      Single contract - as much as possible, strive for a single contract, even if
      multiple vendors are involved. This avoids vendors pointing fingers at each
      other, while you get caught in the middle lacking satisfactory service.
      Clear roles and responsibilities - What are the expected deliverables from
      the vendor? What's the timing and at what cost? In turn, make sure the
      expectations of the vendor are well understood, such as what needs to be
      completed ahead of implementation.
      Keep it simple - The document should be easy to read and understand.
      Maintenance providers are frustrated having to wade through pages and
      pages of complex legalese.

       Every contract should begin by defining common terms used throughout the
document. For example, "software materials" might be defined as "the XYZ
Company software in object code and source-code format, and all documents—
including but not limited to—specifications, flow charts, diagrams, and user
manuals, provided by XYZ Company to the supplier under the terms of this
contract." The document can then define some of the terms within the first

       The contract must specify what goods and services are being purchased. A
detailed software specification is usually attached as an appendix. Other
deliverables include documentation, hardware, data conversion services,
implementation assistance, training, and ongoing support.
      It's essential to be as clear as possible in terms of what you've purchased.
For example, how many copies of the software did you buy? Which sites within
your government can use the software? Can you sell access to the software by
suppliers and customers? What type of training comes with the package, for what
audience, at which location, for how long, at whose expense?
      (Please see ―Attachments B and C‖ for additional detail)

Pricing Options
      Price is fundamental to any contract. Some of the more common pricing
options include the following:
    Per module, per concurrent user: Some CMMS vendors have adopted this
      scheme for larger installations. It's the closest thing to paying only for what
      you use. For example, suppose the vendor charges from $100 to $200 per
      concurrent user per module. If a maximum of forty users will be logged into
      the maintenance module at any given time, twenty people working on the
      payroll or human resource module and four people maximum for the
      purchasing module—your cost would be 40x$200 + 20x$150 + 4x$100 =
      $11,400. When the twenty-first user tries to log into the inventory control
      module, access is denied and a polite message explains that you've reached
      the maximum number of users for that module. Some systems will
      automatically log out a user, if the activity level drops to zero for a pre-
      determined period of time.
    Per concurrent user: One of the most popular pricing options is based on
     the maximum number of users expected to be logged onto the CMMS
     application at any given time, regardless of which module they're currently
    Per seat: Many CMMS vendors still insist on a per seat charge, regardless
     of how many users may be running the application concurrently. There may
     be a volume discount available for companies with a large user base. One
     difficulty is how much to charge remote users with limited access to the
     software via the Internet - for example to submit work requests.
    Site license: Although there are many variations on the theme, a site license
     provides a ceiling on what you have to pay, regardless of how many users
     you have. The price may be based on the expected average number of users

      annually.   Large governments should obtain unlimited use and national
    Other: Hourly rates should be agreed to for consulting, training, software
     customization, implementation, etc. Out-of-pocket expenses are usually
     extra. Maintenance charges are typically 10 to 25 percent of base software
     costs, including minor upgrades.

Payment Terms
       There aren't any rules governing how a CMMS is paid but one approach
might be to have four payments. The first is a small amount given as a deposit
while you conduct user-acceptance testing or a small pilot. Five to ten percent of
the base software cost might be a fair amount. The next payment of approximately
30 percent covers shipment of the software. A further 30 percent covers a
successful install. The final 30 percent comes after a reasonable "warranty" period
of 90 days. Some governments have successfully negotiated an incremental per
seat fee, for example, as the number of users increases, the CMMS vendor is paid
more, to a maximum of the site license ceiling. An expiration date or back-out
clause for the license fee is handy, in case you don't grow to the number of users
originally anticipated.

       In today's dynamic environment, it's essential to cover the possibility of
vendor or customer mergers, acquisitions and divestitures. The contract should
protect both parties from rendering the license and warranty void, if either party
grows, shrinks or changes ownership. In the case of vendor bankruptcy, make sure
the source code is at least held in escrow. Some CMMS vendors ship source code
with the application, or make it available at additional cost. In this case, make sure
you always have source code for your current version.

Product and Service Quality
      Regarding the quality of products shipped and services rendered, ensure that
expectations are well articulated, whether buried in detailed specifications or
described in the body of the contract. Examples are hours of operation for on-line
support, response time for on-site support, hardware uptime guarantees and
acceptable sub-contractors to be used by the vendor.
      An effective way to promote a long-term relationship with vendors is to
provide both a performance incentive and penalty for non-performance. This
should cover delivery promises, service levels agreed to, and product quality
guarantees. Remember, this is a two-way relationship. Any performance clauses,
therefore, should be subject to customers fulfilling their end of the deal, such as
proper back-up and recovery procedures, preparation of facilities for
implementation, adequate documentation of errors, timely notification of problems,
and other requirements.

      Any legal contract should deal with liability issues. From a technical
perspective, make sure that use rights and limitations of the software license are
well understood.

Financial Reporting
       A primary objective of any financial accounting system is to provide
accurate financial statements on a timely basis. Yet, it is one of the biggest
problems to be encountered. A frequent complaint is that a product won't produce
the kind of financial reports a County needs. Yet, considering the importance of
financial reporting, users typically fail to fully consider financial reporting
capabilities when evaluating products. First, the County‘s decision should be
based on the end result you want to receive from its financial system. For financial
management software, this means the County needs to ask: ―How well will the
reports work for me?‖ Although this is a difficult question to answer, a series of
other questions can help you determine your reporting needs.
          Are there extensive options I can set on each report to tailor it to meet
           my needs?
          Can I easily create custom reports and save them to rerun with new
           data in the future?
          Can I easily produce reports for just one entity?
          Can I focus on just one group of accounts?
          Can I exclude many different accounts and report on just one segment
           of my Balance Sheet or my Budget or my Statement of Revenues and
          Can I get reports across multiple funds?
          Is there an advanced module I can license that will give me more
           reporting capabilities if I determine a need.?
          Can data be uploaded and/or down loaded into one or more
           spreadsheet formats?
      When it comes to financial reporting, many financial software products
incorporate third-party products into their packages rather than develop their own.
And in recent years there are products which have become industry standards.

And, they function seamlessly with many of the top financial software packages.
Financial reporting is critical today in order for a County to properly manage the
counties assets and to prepare and monitor the County‘s budget.
      When evaluating financial software, you should ask whether it has the
following capabilities:
       Links financial data from either a general ledger or other products such as
        a spreadsheet or database application.
       Creates calculations: e.g. expenses divided by units produced
       Produces provisional financial statements - that is, as if all un-posted
        transactions have been posted
       Views reports on screen and easily drills down from financial summary
        information into account and transaction details
       Sends e-mail reports directly to remote users from the report preview
       Exports and imports reports to and from spreadsheets
       Handles complex calculations such as conditional if-then statements
       Provides a drag-and-drop utility in the reporting tree so users can see the
        financial effect of restructuring
       Creates virtual roll-up structures for reporting at different levels - that is,
        by project, division, department, organizational unit
       Prepares and distributes presentation-quality reports using customized
        fonts, colors and other formatting options
       Compares revenue and expense figures for different organizational
        departments by creating side-by-side reports
       Operates in a client-server environment
      It is not uncommon for vendors to say ―Reports are very simple to develop
and to run on our system.‖ But, no County should accept this at face value. The
functionality should be one of the requirements in the RFP, and the vendor should
not be paid until the system produces the reports that are required.

       Another important aspect of financial reporting is built-in ratio reporting.
Unfortunately, most financial software and third-party application developers
either ignore this function or don't give it the attention it deserves. Many vendors
say they provide built-in ratio reporting, however, the number of ratios most of
them provide is hardly adequate. There are a few products that do adequately
address this need. Each module contains what are referred to as flash reports.
These reports are controlled by a function key that summarizes key financial ratios
and highlights key information. For example a general ledger flash report could
displays 20 pre-determined key ratios for the following periods: current, year-to-
date and prior-year. In addition reports related to balance sheet accounts for up to
24 months could be established. Budgetary reports could be developed at various
levels within the County and within each department. And, payroll relationships
could be put into a report that would allow for management to obtain vital
information that would help management detect problems in time to take corrective
measures. Each County office should be receiving financial as well as managerial
information on a monthly basis – or at least have access to the information.

      A picture is indeed worth a thousand words, but it's probably worth several
thousand numbers. The County should check to be sure the software package that
is being considered can convert numbers into graphics. Several accounting
packages can produce pie, line and area charts from the numerical data.

       Another important financial report feature is the ability to hotlink accounting
data directly to an Excel spreadsheet - a feature first found in Windows. Such a
feature allows the user to export financial statements directly to Excel as easily as
sending the report to a printer. Once in Excel, Windows automatically inserts the
@SUM formulas everywhere, a feature that makes what-if scenarios a snap to

Event -Triggered Reporting (Alarms)
       Many financial software products have the ability to alert users to predefined
financial conditions. With such a feature the county auditor or the county judge
can create simple calculations that the financial software continuously compares
against a preset value. When that value is exceeded, an alert pops on the computer
screen. For example, the county auditor might create calculations to sound an alert
if cash on hand falls below $100,000, or budgeted expenditures at the department
level reach 80%, or that the budgeted level of revenue is above or below
anticipated levels. Many high-end financial products - the enterprise resource
planning (ERP) products - offer event-triggered reporting. Some products have the
ability to send e-mail messages to managers of the event that has generated the
alert. For financial packages that don't provide event-triggered alarms, a third-
party solution often is available. For example, there are software packages that can
extract data from a host of financial software packages, spreadsheets and other
databases. In addition, the software can dial your phone or beeper if it spots a

potential problem. Thus, it can warn of impending problems on a real-time basis,
whether you're in a meeting or gone fishing.
What Do You Need?
      As you can see making a buying decision requires close investigation of
many diverse areas. One area that often gets lost in the technical assessments of
the products is the long-term needs of your organization. It is critical that you
evaluate your requirements beyond the immediate future. Just as businesses have
the tendency to grow, so will counties--and so do their financial software and
technology need.
       Also, you must assess how others in your organization might be able to use
the application and be sure they are included when you make the buying decision.
That is not to imply that everyone's needs should be given equal weight. For
example, bookkeepers and data-entry staffers tend to place more emphasis on the
data-entry task of getting cash and transactions in and out the door, while CPAs
focus on providing management with the necessary financial reports. Too often
those making buying decisions rely heavily on the bookkeepers' and the data-entry
clerks‘ assessment of needs - giving short shift to the product‘s reporting
       Journal of Accountancy, September 2003, ―A Strategy for Finding the Right
Accounting Software‖
       Journal of Accountancy, August 1999, ―How to select The Right Accounting
       Accenture, ―Driving High Performance in Government,‖ The Government
Executive Series (2004)
       Government Finance Review, June 2003, ―Evaluating Internal Control‖
       Government Finance Review, June 2003, ―Monitoring Local Government
Fiscal Health‖
       Government Finance Review, August 2003, ―Managing Your Virtual
       Information Today, May 2001, ―The Open Source Movement‖
       Shane Peterson, ―2004 Year in Review,‖ Government Technology
(December 2004): pp 12-23

                                ―Attachment A‖


ERP (enterprise resources planning) was an important step in an ongoing
evolution of computer tools that began in the 1960s. Each evolutionary step is built
on the fundamentals and principles developed within the previous one. As systems
developed over time, a continuous stream of new terminology surfaced.
This is a glossary of those terms.
accounts payable (AP): The value of goods and services acquired for which
payment has not yet been made.
accounts receivable (AR): The value of goods shipped or services rendered to a
customer for whom payment has not yet been received. Usually includes an
allowance for bad debts.
advanced planning and scheduling (APS): Techniques that deal with analysis
and planning of logistics and manufacturing over the short, intermediate, and long-
term time periods. APS describes any computer program that uses advanced
mathematical algorithms or logic to perform optimization or simulation on finite
capacity scheduling, sourcing, capital planning, resource planning, forecasting,
demand management, and others. These techniques simultaneously consider a
range of constraints and business rules to provide real-time planning and
scheduling, decision support, available-to-promise, and capable-to-promise
capabilities. APS often generates and evaluates multiple scenarios. Management
then selects one scenario to use as the "official plan." The five main components of
APS systems are demand planning, production planning, production scheduling,
distribution planning, and transportation planning.
APICS: A nonprofit educational organization consisting of over 70,000 members
in the production and operations, materials, and integrated resource management
areas. application Software: A program that performs a task or process specific to a
particular end-user‘s needs, or solves a particular problem. Enterprise applications
are typically large-scale business systems that organizations use to manage their

application programming interface (API): A set of routines, protocols, and tools
for building software applications or for communicating with programs or other
systems. A good API makes it easier to develop a program by providing all the
building blocks that a programmer needs Although APIs are designed for
programmers; they are ultimately good for users because they guarantee that all
programs using a common API will have similar interfaces, which makes it easier
for users to learn new programs. On the other hand, many enterprise applications
vendors provide APIs for integrating other applications with their systems.
application service provider (ASP): A third-party entity that manages and
distributes software-based leased services and solutions to customers across a wide
area network from a central data center. In essence, ASPs are a way for companies
to outsource some or almost all aspects of their information technology needs.
architecture: A structured set of protocols that implements a system‘s functions.
available-to-promise (ATP): The uncommitted portion of a company‘s inventory
and planned production, maintained in the master schedule to support customer
order promising.
artificial intelligence (AI): The capability of a device to perform functions that is
normally associated with human intelligence, such as reasoning and the ability to
learn and adapt through experience. Note: AI is the branch of computer science
that attempts to approximate the results of human reasoning by organizing and
manipulating factual and heuristic knowledge. Areas of AI activity include expert
systems, natural language understanding, speech recognition, vision, graphics, and
back scheduling: A technique for calculating operation start dates and due dates.
The schedule is computed starting with the due date for the order and working
backward to determine the required start date and/or due dates for each operation.
bill of material (BOM): A listing of all the subassemblies, intermediates, parts,
and raw materials that go into a parent assembly showing the quantity of each
required to make an assembly.
browser: Software used on the Web to retrieve and display documents on-screen,
connect to other sites using hypertext links, display images, and play audio files.
business intelligence (BI): Sets of tools that provide graphical analysis of business
information in multidimensional views thus enabling people to make better
decisions and improve their business processes.
business-to-business e-commerce (B2B) (A): Business being conducted over the
Internet between businesses. The implication is that this connectivity will cause
businesses to transform themselves via supply chain management to become
virtual organizations, reducing costs, improving quality, reducing delivery lead
time, and improving due-date performance.
business-to-consumer sales (B2C) (A): Business being conducted between
businesses and final consumers largely over the Internet. It includes traditional
brick and mortar businesses that also offer products online and businesses that
trade exclusively electronically.
capable-to-promise (CTP): The process of committing orders against available
capacity as well as inventory. This process may involve multiple manufacturing or
distribution sites. Capable-to-promise is used to determine when a new or
unscheduled customer order can be delivered. Capable-to-promise employs a
finite-scheduling model of the manufacturing system to determine when an item
can be delivered. It includes any constraints that might restrict the production, such
as availability of resources, lead times for raw materials or purchased parts, and
requirements for lower-level components or subassemblies. The resulting delivery
date takes into consideration production capacity, the current manufacturing
environment, and future order commitments. The objective is to reduce the time
spent by production planners in expediting orders and adjusting plans because of
inaccurate delivery-date promises.
capacity requirements planning (CRP): The function of establishing, measuring,
and adjusting limits or levels of capacity. The term CRP in this context refers to
the process of determining in detail the amount of labor and machine resources
required to accomplish the tasks of production.
client/server system: A distributed computing system in which work is assigned to
the computer best able to perform it from among a network of computers. client: In
information systems, a software program that is used to contact and obtain data
from a server program on another computer. Each client program is designed to
work with one or more specific kinds of server programs, and each server requires
a specific kind of client. A Web browser is one type of client.
computer-assisted software engineering (CASE): The use of computerized tools
to assist in the process of designing, developing, and maintaining software
products and systems.
computerized maintenance management systems (CMMS): Automated
software systems for handling maintenance work orders, as well as associated
inventory, purchasing, accounting, and human resources functions. In some
industries—particularly process production, in which manufacturers look to
optimize use of capital-intensive equipment—maintenance management systems
play a leading role as the enterprise system. Maintenance management systems
have similar basic functionality, including:

   1. use of work orders for preventive and predictive maintenance,
   2. equipment recording and tracking,
   3. inventory control,
   4. scheduling labor and resources, and
   5. purchasing.
corporate performance management (CPM): An overarching term that
describes the methodologies, metrics, processes and systems used to monitor and
manage the business performance of an enterprise. Applications that enable CPM
translate strategically focused information to operational plans and send aggregated
cost of goods sold (COGS): An accounting classification useful for determining
the amount of direct materials, direct labor, and allocated overhead associated with
the products sold during a given period of time.
customer relationship management (CRM): Software systems that range from
simple, off-the-shelf contact management solutions to high-end interactive selling
suites that combine sales, marketing, and executive information tools. These
include product configuration, quote and proposal management, and marketing
encyclopedias. Some systems extend functions to include complex pricing,
promotions, commission plans, team selling, and campaign management.
Enterprise-level solutions installed at large companies with hundreds or even
thousands of users have capabilities for call center and help desks; field service;
forecasting; and analysis.
database: A data processing file-management approach designed to establish the
independence of computer programs from data files. Redundancy is minimized,
and data elements can be added to, or deleted from, the file structure without
necessitating changes to existing computer programs.
database management system (DBMS): The software designed for organizing
data and providing the mechanism for storing, maintaining, and retrieving that data
on a physical medium (i.e., a database). A DBMS separates data from the
application programs and people who use the data and permits many different
views of the data.
data warehouse: A repository of data that has been specially prepared to support
decision-making applications.
discrete manufacturing: Production of distinct items such as automobiles,
appliances, or computers.

e-Business: The generic name given to any type of business conducted using the
Internet from online trading to self-service.
engineer-to-order (ETO): Products whose customer specifications require unique
engineering design, significant customization, or new purchased materials. Each
customer order results in a unique set of part numbers, bills of material, and
enterprise application integration (EAI): The unrestricted sharing of data and
business processes throughout the networked applications or data sources in an
organization, since early software programs in areas such as inventory control,
human resources, sales automation and database management were designed to run
independently, with no interaction between the systems. There are four major
categories of EAI:
   1. database linking: databases share information and duplicate information as
   2. application linking: the enterprise shares business processes and data
      between two or more applications;
   3. data warehousing: data is extracted from a variety of data sources and
      channeled into a specific database for analysis; and
   4. common virtual system: the pinnacle of EAI; all aspects of enterprise
      computing are tied together so that they appear as a unified application.
enterprise asset management (EAM): A term used by maintenance management
software vendors to connote the wide-ranging functionality that their systems
include, for example inventory management and financials. A company‘s total
assets might include labor, tools, equipment, materials, and information. The goal
of asset management is to optimize asset use and manage all maintenance efforts
involved in making assets as reliable, accurate, and efficient as possible. A further
crucial element in enterprise wide asset management is integration with financial,
human resources, and purchasing functions, as well as production, material
requirements planning, and enterprise resources planning systems.
enterprise resources planning (ERP) system:
   1. An accounting-oriented information system for identifying and planning the
      enterprise-wide resources needed to take, make, ship, and account for
      customer orders. An ERP system differs from the typical MRP II system in
      technical requirements such as graphical user interface, relational database,
      use of fourth-generation language, and computer-assisted software

      engineering tools in development, client/server architecture, and open-
      system portability.
   2. More generally, a method for the effective planning and control of all
      resources needed to take, make, ship, and account for customer orders in a
      manufacturing, distribution, or service company.
finite scheduling: A scheduling methodology where work is loaded into work
centers such that no work center capacity requirement exceeds the capacity
available for that work center.
flow manufacturing: A form of manufacturing organization, in which machines
and operators handle a standard, usually uninterrupted, material flow. The
operators generally perform the same operations for each production run. A flow
shop is often referred to as a mass production shop or is said to have a continuous
manufacturing layout. Each product, though variable in material specifications,
uses the same flow pattern through the shop. Production is set at a given rate, and
the products are generally manufactured in bulk.
fourth-generation language (4GL): A general term for a series of high-level
nonprocedural languages that enable users or programmers to prototype and to
code new systems. Nonprocedural languages use menus, question-and-answer
combinations, and a simpler, English-like wording to design and implement
systems, update databases, generate reports, create graphs, and answer inquiries.
graphical user interface (GUI): A connection between the computer and the user
employing a mouse and icons so that the user makes selections by pointing at icons
and clicking the mouse.
infinite loading: Calculation of the capacity required at work centers in the time
periods required regardless of the capacity available to perform this work.
Internet: A worldwide network of computers belonging to businesses,
governments, and universities that enables users to share information in the form of
files and to send electronic messages and have access to a tremendous store of
information. Also referred to as Web, it is a universal mass of web pages
connected together through links.
just-in-time (JIT): A philosophy of manufacturing based on planned elimination
of all waste and continuous improvement of productivity. It encompasses the
successful execution of all manufacturing activities required to produce final
product, from design engineering to delivery and including all stages of conversion
from raw material onward.

lead time: A span of time required to perform a process (or series of operations).
In a logistics context, the time between recognition of the need for an order and the
receipt of goods. Individual components of lead time can include order preparation
time, queue time, processing time, move or transportation time, and receiving and
inspection time.
lean production: A philosophy of production that emphasizes the minimization of
the amount of all the resources (including time) used in the various activities of the
enterprise. It involves identifying and eliminating non-value-adding activities in
design, production, supply chain management, and dealing with the customers.
Lean producers employ teams of multi-skilled workers at all levels of the
organization and use highly flexible, increasingly automated machines to produce
volumes of products in potentially enormous variety. It contains a set of principles
and practices to reduce cost through the relentless removal of waste and through
the simplification of all manufacturing and support processes.
mass customization: The creation of a high-volume product with large variety so
that a customer may specify his or her exact model out of a large volume of
possible end items while manufacturing cost is low because of the large volume.
An example is a personal computer order in which the customer may specify
processor speed, memory size, hard disk size and speed, removable storage device
characteristics, and many other options when PCs are assembled on one line and at
low cost.
mass production: High-quantity production characterized by specialization of
equipment and labor.
master production schedule (MPS): The anticipated build schedule for those
items assigned to the master scheduler. It is a set of planning numbers that drives
material requirements planning (MRP). It represents what the company plans to
produce expressed in specific configurations, quantities, and dates.
material requirements planning (MRP): A set of techniques that uses bill of
material data, inventory data, and master production schedule to calculate
requirements for materials. It makes recommendations to release replenishment
orders for materials. Further, because it is time-phased, it makes recommendations
to reschedule open orders when due dates and need dates are not in phase.
manufacturing resource planning (MRP II): A method for the effective
planning of all resources of a manufacturing company. Ideally, it addresses
operational planning in units, financial planning in dollars, and has a simulation
capability to answer what-if questions. It is made up of a variety of processes,
each linked together: business planning, production planning (sales and operations
planning), master production scheduling, material requirements planning, capacity

requirements planning, and the execution support systems for capacity and
material. Output from these systems is integrated with financial reports such as the
business plan, purchase commitment report, shipping budget, and inventory
projections in dollars. Manufacturing resource planning is a direct outgrowth and
extension of closed-loop MRP.
manufacturing execution system (MES): A factory floor information and
communication system with several functional capabilities. It includes functions
such as resource allocation and status, operation/detailed scheduling, dispatching
production units, document control, data collection and acquisition, labor
management, quality management, process management, maintenance
management, product tracking and genealogy, and performance analysis. It can
provide feedback from the factory floor on a real-time basis. It interfaces with and
complements ERP systems.
on-line analytical processing (OLAP): A category of software tools that provides
analysis of data stored in a database. OLAP tools enable users to analyze different
dimensions of multidimensional data. For example, it provides time series and
trend analysis views. The chief component of OLAP is the OLAP server, which
sits between a client and a database management systems (DBMS), and which
understands how data is organized in the database and has special functions for
analyzing the data. There are OLAP servers available for nearly all the major
database systems.
order entry: The process of accepting and translating what a customer wants into
terms used by the manufacturer or distributor. The commitment should be based
on the available-to-promise line (ATP) in the master schedule. This can be as
simple as creating shipping documents for finished goods in a make-to-stock
environment, or it might be a more complicated series of activities, including
design efforts for make-to-order (MTO) products.
portal: A personalized web site or service that offers a broad array of resources
and services, such as e-mail, forums, search engines, and on-line shopping malls.
The first web portals were online services that provided access to the Web, but by
now most of the traditional search engines have transformed themselves into web
portals to attract and keep a larger audience.
process manufacturing: Production that adds value by mixing, separating,
forming, and/or performing chemical reactions. It may be done in either batch or
continuous mode.
product data management (PDM): a system, which controls all product-related
data and associated work flow, processes within an enterprise. Product data
management systems replace paper-based processes and information storage with a

single, centralized data repository that enables authorized users throughout a
company to access and update current product information, while ensuring they
follow specific procedures. PDM vendors recently have emphasized the
similarities between PDM and groupware technology appropriate to a range of
business environments. Besides ensuring data integrity using relational database
technology, both include workflow and web-based applications that ease
collaboration efforts.
product configurator: A system, generally rule-based, to be used in design-to-
order, engineer-to-order, or make-to-order environments where numerous product
variations exist. Product configurators perform intelligent modeling of the part or
product attributes and often create solid models, drawings, bills of material, and
cost estimates that can be integrated into CAD/CAM and MRP II systems as well
as sales order entry systems.
product life cycle: The stages a new product goes through from beginning to end,
i.e., the stages that a product passes through from introduction through growth,
maturity, and decline. The time from initial research and development to the time
at which sales and support of the product to customers are withdrawn. The period
of time during which a product can be produced and marketed profitably.
product lifecycle management (PLM): A process for guiding products from idea
through retirement to deliver the most business value to an enterprise and its
trading partners. The applications that support the business activities enabled
through PLM includes product ideation, design, engineering, manufacturing
process management, product data management, and product portfolio
real time: The technique of coordinating data processing with external related
physical events as they occur, thereby permitting prompt reporting of conditions.
The immediate availability of data to an information system as a transaction or
event occurs.
relational database: A software program that allows users to obtain information
drawn from two or more databases that are made up of two-dimensional arrays of
reorder point (ROP) system: Inventory method that places an order for a lot
whenever the quantity on hand is reduced to a predetermined level known as the
reorder point.
return on investment (ROI): A financial measure of the relative return from an
investment, usually expressed as a percentage of earnings produced by an asset to
the amount invested in the asset routing: Information detailing the method of
manufacture of a particular item. It includes the operations to be performed, their
sequence, the various work centers involved, and the standards for setup and run
sales force automation (SFA): Technology used to improve the efficiency and
effectiveness of the sales force by streamlining and speeding up processes and
eliminating errors. It allows the sales force to access up to date information of
customer accounts and pricing. It also eradicates errors involved with placing
server: A computer, or software package, that provides a specific kind of service
to client software running on other computers. The term can refer to a particular
piece of software, for example a Web server, or to the machine on which the
software is running. A single server machine could have several different server
software packages running on it, thus providing many different servers to clients
on the network.
supplier relationship management (SRM): Evolving set of applications enabling
enterprises to create a more comprehensive lifecycle view of suppliers' operational
contribution to the top and bottom lines. Strategic sourcing and spend
management would be some of SRM parts.
supply chain management (SCM): The design, planning, execution, control, and
monitoring of supply chain activities with the objective of creating net value,
building a competitive infrastructure, leveraging worldwide logistics,
synchronizing supply with demand, and measuring performance globally.
supply chain planning (SCP): The determination of a set of policies and
procedures that govern the operation of a supply chain. Planning includes the
determination of marketing channels, promotions, respective quantities and timing,
inventory and replenishment policies, and production policies.           Planning
establishes the parameters within which the supply chain will operate.
supply chain execution (SCE): Execution-oriented software applications for
effective procurement and supply of goods and services across a supply chain. It
includes manufacturing, warehouse, and transportation execution systems, and
systems providing visibility across the supply chain.
supply chain inventory visibility (SCIV): Software applications that permit
monitoring events across a supply chain. These systems track and trace inventory
globally on a line-item level and notify the user of significant deviations from
plans. Companies are provided with realistic estimates of when material will

strategic sourcing: The development and management of supplier relationships to
acquire goods and services in a way that aids in achieving the immediate needs of a
business. It is entirely aligned with the sourcing portion of managing the
procurement process.
warehouse management system (WMS): Systems that integrate work performed
within warehouses and distribution centers with a transactional-type information
system. Simple storage and retrieval of materials is superseded by strategies to
increase throughput and productivity by managing the full range of warehouse
resources to effectively manage warehouse business processes and direct
warehouse activities, including receiving, put away, picking, shipping, and
inventory cycle counts. Most support radio-frequency communications, allowing
real-time data transfer between the system and warehouse personnel.
work in process (WIP): A good or goods in various stages of completion
throughout the plant, including all material from raw material that has been
released for initial processing up to completely processed material awaiting final
inspection and acceptance as finished goods inventory. Many accounting systems
also include the value of semi-finished stock and components in this category.
World Wide Web (WWW) (A): A set of software, protocols, hypertext
conventions, and multimedia techniques that enable use of the Internet.
Web Services: A standardized way of integrating Web-based applications using
the XML, SOAP, WSDL and UDDI open standards over an Internet protocol
backbone. XML is used to tag the data; SOAP is used to transfer the data; WSDL
is used for describing the services available; and UDDI is used for listing what
services are available. Used primarily as a means for businesses to communicate
with each other and with clients, Web services allow organizations to communicate
data without intimate knowledge of each other's IT systems behind the firewall.
Unlike traditional client/server models, Web services do not provide the user with
a GUI, but instead share business logic, data, and processes through a
programmatic interface across a network.           Web services allow different
applications from different sources to communicate with each other without time-
consuming custom coding, and because all communication is in XML, Web
services are not tied to any one operating system or programming language, and
they do not require the use of browsers or hypertext markup language (HTML).
extensible markup language (XML): This language facilitates direct
communication among computers on the Internet. Unlike the older hypertext
markup language (HTML), which provides HTML tags giving instructions to a
Web browser about how to display information, XML tags give instructions to a
Web browser about the category of information.

But, then Einstein never had to computerize……..

                               ―Attachment B‖

               Financial Package Software Selection RFP
                         (Sample Deliverables)

Accounting packages encompass modules for bookkeeping, budgetary control and
making sure that accounts are paid or received on time. Enterprise resource
planning (ERP) software today encompasses all the functionalities of a fully
integrated financial system, from accounting to warehousing in one package.
Financial needs that can be served by software packages that are in the market
include general ledger, procurement, asset management, budget development,
outside reporting, fund accounting, year-end accounting, personnel management,
cost allocations, multiple bank account requirements, project accounting, grant
monitoring, customer relationships, and inter-fund activity

Goal: The selection of comprehensive financial software which is knowledge
based and provides a superior technology selection engine which affords the
county opportunity for growth as well as provides the highest match to functional
requirements. This financial software knowledge base anticipates as many factors
as possible that will contribute to efficient and effective county operations.

General Ledger
       General ledger keeps centralized charts of accounts and corporate financial
       It supports all aspects of the business accounting process.
       In this module, financial accounting transactions are posted, processed,
summarized, and reported.
       It maintains a complete audit trail of transactions and enables individual
departmental units to view their financial information, and allows the county the
ability to roll up all activity and view the consolidated information.

      The software should support the functionality such as
         chart of accounts structure;
         ledger development and maintenance;
         separate fund analysis
         financial consolidation and reporting;
         budgeting,
         multi-year budgeting
         journal entry;
         journal voucher ledger transactions;

            project cost ledger;
            project accounting
            ledger controls;
            multicurrency accounting and conversions;
            on-line inquiry reporting;
            financial statement reporting;
            financial report writer;
            variance analysis; and
            additional financial reporting

Accounts Payable
       Accounts payable schedules bill payments to suppliers and distributors, and
keeps accurate information about encumbrances and outstanding liabilities, due
dates, and available discounts.
       It provides functionality and integration to other areas such as customer
service, purchasing, inventory, and manufacturing control.
       The software should support the following functionality:
            AP company policies and procedures;
            Purchase orders
            suppliers/voucher master data;
            payment controls;
            invoice processing and aging analysis;
            payment processing;
            journal voucher processing;
            AP ledger posting;
            check processing;
            AP transactions and controls; and
            AP reporting.

      Supplemental detailed requirements are:
              o Policies and Procedures
              o Supplier Master Data
              o Invoice Process and Aging
              o Journal Voucher Process
              o AP Ledger Posting
              o Payment Controls
              o AP Transactions and Controls
              o Payment Processing
              o Check Processing
              o Reporting
Fixed Assets
       A fixed assets management module should manage depreciation and other
costs associated with tangible assets such as buildings, property and equipment.

      The software should support the following functionality:
         fixed assets records;
               o date of acquisition
               o physical location
               o original cost
               o date of improvements
         asset transactions;
         asset depreciation;
         depreciation books;
         revaluation and interest calculation; and ,

Fixed Assets Records
         Asset Transactions
         Depreciation
         Depreciation Books
         Reporting

Cash Management
       Cash management involves the capability of the system to record cash
charges or deposits, recording of cash payments and receipts, cash projection
reporting, calculation of expected cash uses/sources, current cash availability, etc.
       Functionality should include, but not be limited to:
           Monitoring and analyzing cash holdings and availability.
           System should be able to Calculate expected cash resources
           System should be able to project expected cash uses
           Forecast effects of cash resources and uses on cash availability
           Expected pay date maintenance
           Cash projection reporting
           Cash projections by department,
           System should be able to retain departmental history
           Book inflow and outflow by bank account
           Recording of cash payments and receipts from bank statements
           Statement discrepancy exception flagging and reporting
           Recording of miscellaneous charges and deposits
           Process cancelled AP checks
            Integrate with financial institution for positive pay
            Allow for electronic banking
            Facilitate ACH and wire payments and deposits
            Recording of GL journal entries to cash
            Printing of statement of account
            Recording of cash receipts automatically from bank

      Budgeting involves budgetary controls, budget accounting, budget
development, and budget allocation.
      The software should provide sufficient tools to enable detailed budget
development, analysis, and flexibility.
      Additional functionality should be available to integrate with project
management software applications either natively or with external interfaces.
      Functionality should include:
         Budget Controls
               o Single year budget
               o Multi-year budgets
         Budget Accounting
         Budget Development
         Budget Allocation
         Position Control
         Interfund transfers

Financial Reporting
       Financial reporting should allow the county to perform robust analysis of
county performance through delivered reports.
       These reports will allow individual departmental units to view their financial
information, and will allow for the county-wide to roll up all departmental and
fund activity and view the consolidated information at either the detailed level or
the budgetary level or the county wide level.
       Additionally, solutions should provide user generated reporting tools that are
easy to use and provide sufficient depth of and access to the financial data to
permit comprehensive analysis.
       The system should have the ability for the county to develop financial
reports for departments, work orders, projects and funds independent of other
reporting requirements.

Project Accounting
      Project accounting monitors costs and work schedules on a project-by-
project basis.
      It should include the following sub-modules:
           project control,
           project analyzer,
           project budgeting,
           project timekeeping,
           project billings,
           contract management, and
           workflow communicator

Product Technology
      This category defines the technical architecture of the product, and the
technological environment in which the product can successfully run.

      Criteria include:
           product and application architecture,
           software usability and administration,
           platform and database support,
           application standards support,
           communications and protocol support and integration capabilities

       The product technology category usually houses the majority of the selecting
organization's mandatory criteria, which usually include server, client, protocol,
and database support, application scalability and other architectural capabilities.
       The definition of mandatory criteria within this set often allows the county
to quickly narrow the long list of potential vendors to a short list of applicable
solutions that pass muster relative to the most basic mandatory selection criteria.
       During the process of product selection a great deal of attention is given to
the functional capabilities of the software being evaluated.
       While this aspect is obviously important, ignoring the technical mechanisms
by which the software actually operates can be fatal to a project:
           Architecture
           User Interface
           Platforms
           Application Tools
           Workflow and Document Management
           Reporting

It is always the little things that matter in the end…..

                               ―Attachment C‖

                  Human Resources Software Selection
                       (Sample Deliverables)

      Human Resources encompasses all the applications necessary for handling
personnel-related tasks for all county employees.
      Modules will include Personnel Management, Benefit Management, Payroll
Management, Employee Self Service, Data Warehousing and Health & Safety.

Personnel Management
       Personnel management automates personnel processes, and should support
the following functionality:
           recruitment management;
           personnel information and tracking;
           organizational structuring;
           position control and salary profile;
           career development,
           training;
           compensation management;
           budgeting and cost control;
           government compliance reporting;
           expenses management;
           union information;
           discipline actions and grievances tracking; and
           employment history/personnel reporting

     Benefits module administers a diverse range of benefit plans such as:
          health and medical,
          life and supplemental life insurance,
          accidental death and dismemberment (AD&D),
          disability plans,
          flexible benefits (cafeteria plans),
          Section 457 plans,
          county retirement,
          vacation and sick leave accruals
          compensated leave
          overtime.

         The software should support the following functionality:
            base benefits;
            employee benefit plan profile;
            benefits administration; and
            pension administration

       Payroll handles accounting and preparation of checks related to employee
salaries, wages, benefits, and deductions.

      The software should support the following functionality:
         employee payroll profile;
         earnings and deductions;
         eligibility controls;
         user balances;
         tax deductions and calculation;
         payroll calculation;
         payroll and payment processing;
         check processing and printing;
         direct deposit
         positive pay
         labor distribution and accounting;
         payroll and regulatory reporting;
         IRS documentation;
         security and audit;
         automated timesheets and
         integration with the financial system

Employee Self-Service
        Employee self-service lets workers access their personal information and
benefit allocations on-line to manage life events and benefit selections without
having to send forms to human resources.
        The software should also support benefit enrollment programs and new hire
        Software will be required to support the following:
            Review and maintain name, address, telephone number, etc.,
            Review or enroll in benefits for open enrollment period
            Change benefits related to a life event

         Update W-4 information such as tax filling status, number of
          exemptions, and withholding information
         View pay stub info: gross pay, taxes, other deductions, net pay, pay
          period, and year-to-date totals
         Maintain dependents and beneficiaries related to life event
         Maintain emergency contacts
         Review vacation and sick day balances and submit leave requests
         Review and maintain bank info for direct deposit and reimbursements
         Review and enter or submit expenses
         Account for time based on type of absence or attendance
         Allocate time to multiple projects and assignments
         Internal and external application for a job and view the status of the
         Choose and maintain personal passwords
         View personal training history
         Review and maintain deduction information

Data Warehousing
       Data warehousing simply defined, is a place for data, whereas data
warehousing describes the process of defining, populating, and using a data
       The software will be required to create, populate, and querying a data
warehouse for information related to an individual, a group of individuals, a
particular job classification and or the county as a whole with the following

     At a minimum the software will be required to:
         Staff headcount, movement, and turnover trends analyses and reports
         Workforce planning reporting
         EEO/affirmative action /disabled employee reporting
         Absence and leave accrual reporting
         Wage and salary costs data, with detailed breakdowns across, for
           example, earnings, deductions, and disbursements
         Reports on vacancies and the effectiveness of filling them such as:
              o time to fill,
              o cost per applicant, and
              o average time of retaining the position
         Competency profile of the workforce, with breakdowns per
           departments, positions, etc.
         HR budgeting reports (dollars, hours, FTE, and headcount)
         Budgeting versus actual comparisons by position
          External and internal training requirements reports, with detailed
           breakdowns per departments,
          Positions control to include
              o Approved budget level
              o Overtime level authorized
              o Current level of expenditures
              o Remaining level of expenditures
          Reports on training history,
          Alert supervisor when an employee is out of compliance in training or
          Report on benefit leave usage and alert supervisors when allocation is

Product Technology
      This category defines the technical architecture of the product, and the
technological environment in which the product can successfully run.

      Criteria include but are not limited to:
          product and application architecture,
          software usability and administration,
          platform and database support,
          application standards support,
          communications and protocol support, and
          integration capabilities.

      During the process of developing the deliverables it is not uncommon that
the product selection absorbs a great deal of the attention and the functional
capabilities of the software is focused on for evaluation.

     While this aspect is obviously important, ignoring the technical mechanisms
by which the software actually operates can be fatal to any project.
          Architecture needs to be defined to include all applications
          User Interface is to be available for all applications
          Platforms that will be required should be set out
          Application Tools (Web Base Browser, etc.)
          Workflow and Document Management
          Reporting

                                ―Attachment D‖

                     Reasons Why Strategic Plans Fail

      In 2003 Kevin Lewis, PhD, and senior manager for Quorum Business
Solutions, after conducting a survey, noted in an article that he wrote for Power
and Gas, that there are eight basic reasons why strategic software implementation
projects fail. The priority of those reasons are:
           Lack of line sponsorship – stakeholders buy-in
           No clear vision – of goals
           Unprepared for the changes that the implementation will cause
           Poor training and poorer documentation
           Unprepared for change management
           No encouragement, no support built internally, no cheer leaders
           No incentives for employees to change behavior
           Lack of willingness – no discipline
       As previously noted there are many things that can go wrong in a software
implementation, whether it is an enterprise resource project, a criminal justice
project or just a new cash receipting system. The trick to making them work with
the least amount of fall out is to understand where the pitfalls occur and taking
steps at the get-go to prevent them. The following is a list of those pit falls and
they are not assembled in any particular order:
            1.    Inexperienced in project management
            2.    No real depth to project management team
            3.    Insufficient project management team
            4.    Responsibilities of project management team not clearly stated
            5.    Inability to hold the vendor accountable
            6.    Unrealistic time line
            7.    Inability to perform knowledge transfer
            8.    Excessive modifications
            9.    Inadequate training
            10.   Unprepared for change management
            11.   Failure to commit the best and brightest personnel
            12.   No Leadership – at the top
            13.   Politics
            14.   Communication – failure to keep informed
            15.   Great ideas – but no formal plan
            16.   Poorly articulated goals and objectives
            17.   Unclear performance measures and targets

18.   Vendor assistance – not enough, poor quality
19.   Inadequate reference checks on vendors
20.   Passive management
21.   Motivation – no real by-in from stakeholders
22.   Inadequate budget for acquisition
23.   Inadequate budget for implementation
24.   Inadequate budget for long term maintenance
25.   Inadequate facilities
26.   Inadequate hardware
27.   Politics
28.   No clear understanding of consequences in the event the project
29.   Not prepared for change management
30.   Lack of seamless integration
31.   Inadequate testing
32.   No process established for issue resolution
33.   No risk management process
34.   Inadequate training – before and after
35.   Over reaching architecture and technology