This book is licensed under a Creative Commons by-nc-sa 3.0 license. See the license for more details, but that basically means you can share this book as long as you credit the author (but see below), don't make money from it, and do make it available to everyone else under the same terms.
This content was accessible as of December 29, 2012, and it was downloaded then by Andy Schmitz in an effort to preserve the availability of this book.
Normally, the author and publisher would be credited here. However, the publisher has asked for the customary Creative Commons attribution to the original publisher, authors, title, and book URI to be removed. Additionally, per the publisher's request, their name has been removed in some passages. More information is available on this project's attribution page.
For more information on the source of this book, or why it is available for free, please see the project's home page. You can browse or download additional books there. To download a .zip file containing this book to use offline, simply click here.
So now you realize managers have a whole host of options when seeking to fulfill the software needs of their firms. An organization can purchase packaged software from a vendor, use open source offerings, leverage SaaS or other type of cloud computing, outsource development or other IT functions to another firm either domestically or abroad, or a firm can develop all or part of the effort themselves. When presented with all of these options, making decisions about technologies and systems can seem pretty daunting.
First, realize that that for most firms, technology decisions are not binary options for the whole organization in all situations. Few businesses will opt for an IT configuration that is 100 percent in-house, packaged, or SaaS. Being aware of the parameters to consider can help a firm make better, more informed decisions. It’s also important to keep in mind that these decisions need to be continuously reevaluated as markets and business needs change. What follows is a summary of some of the key variables to consider.
Competitive Advantage—Do we rely on unique processes, procedures, or technologies that create vital, differentiating competitive advantage? If so, then these functions aren’t a good candidate to outsource or replace with a package software offering. Amazon.com had originally used recommendation software provided by a third party, and Netflix and Dell both considered third-party software to manage inventory fulfillment. But in all three cases, these firms felt that mastery of these functions was too critical to competitive advantage, so each firm developed proprietary systems unique to the circumstances of each firm.
Security—Are there unacceptable risks associated with using the packaged software, OSS, cloud solution, or an outsourcing vendor? Are we convinced that the prospective solution is sufficiently secure and reliable? Can we trust the prospective vendor with our code, our data, our procedures and our way of doing business? Are there noncompete provisions for vendor staff that may be privy to our secrets? For off-site work, are there sufficient policies in place for on-site auditing? If the answers to any of these questions is no, outsourcing might not be a viable option.
Legal and Compliance—Is our firm prohibited outright from using technologies? Are there specific legal and compliance requirements related to deploying our products or services? Even a technology as innocuous as instant messaging may need to be deployed in such a way that it complies with laws requiring firms to record and reproduce the electronic equivalent of a paper trail. For example, SEC Rule 17a-4 requires broker dealers to retain client communications for a minimum of three years. HIPAA laws governing health care providers state that electronic communications must also be captured and stored.D. Shapiro, “Instant Messaging and Compliance Issues: What You Need to Know,” SearchCIO, May 17, 2004. While tech has gained a seat in the board room, legal also deserves a seat in systems planning meetings.
Skill, Expertise, and Available Labor—Can we build it? The firm may have skilled technologists, but they may not be sufficiently experienced with a new technology. Even if they are skilled, managers much consider the costs of allocating staff away from existing projects for this effort.
Cost—Is this a cost-effective choice for our firm? A host of factors must be considered when evaluating the cost of an IT decision. The costs to build, host, maintain, and support an ongoing effort involve labor (software development, quality assurance, ongoing support, training, and maintenance), consulting, security, operations, licensing, energy, and real estate. Any analysis of costs should consider not only the aggregate spending required over the lifetime of the effort but also whether these factors might vary over time.
Time—Do we have time to build, test, and deploy the system?
Vendor Issues—Is the vendor reputable and in a sound financial position? Can the vendor guarantee the service levels and reliability we need? What provisions are in place in case the vendor fails or is acquired? Is the vendor certified via the Carnegie Mellon Software Institute or other standards organizations in a way that conveys quality, trust, and reliability?
The list above is a starter. It should also be clear that these metrics are sometimes quite tough to estimate. Welcome to the challenges of being a manager! At times an environment in flux can make an executive feel like he or she is working on a surfboard, constantly being buffeted about by unexpected currents and waves. Hopefully the issues outlined in this chapter will give you the surfing skills you need for a safe ride that avoids the organizational equivalent of a wipeout.