Custom-made, internally built applications cost more than vendor-supplied packages in the long run. For example, most people would not build their own automobile because it takes far less effort and cost to go to the dealer and buy it. Standardized industry software allows a vendor to spread development costs over a large base of customers and integrate industry best practices and new technologies more easily. This allows the company to use resources to build and support areas of applications that are truly unique and provide a competitive advantage rather than expending resources on reinventing the wheel. That is the piece that everyone knows and understands.
The real question is how to change an organization with a strong appetite for custom software to utilize standard software packages. Most organizations claim that they are so different, their business is unique, it has to be a certain way. In fact, just about every company makes that claim. Yet, there cannot be that many different ways to process general ledger, accounts payable, accounts receivable, payroll, purchasing, etc. In fact, at least 80 percent of all business functions or requirements are common to other companies in the industry. The key is to figure out what and where is that 20 percent that provides a true competitive advantage.
Some business units are accustomed to getting software crafted the exact way they want it so they do not have to go through the painful process of changing their business processes to match the software. The following are some suggestions to help make this transition from a custom culture to a vendor-package environment:
- Give them the facts. Communicate the costs of having custom software to the organization. Cite industry benchmark statistics and the fact that most companies are using vendor-supplied software. Cite competitors in the same industry that use vendor packages. Explain what the cost structure and environment would look like with vendor packages."A buy versus build strategy can backfire. You may think that buying is cheaper, but it can be more expensive when you do not have a clear understanding of what you are buying. You need to ask the right questions as the devil is in the details."—Deb Bauman
Sun Country Airlines
- Obtain executive commitment to changing to a buy-before-build strategy. Ask for their commitment, as there will be times you will need it. Changing to a buy-before-build culture is not only an IT issue, it is a business issue, and like most culture changes it needs to start at the top of the organization.
- Build only when it provides a critical, unique, and strategic advantage or if there is no product available to meet the need.
- Have formal reviews with all IT groups to ensure no other in-house product could provide the service.
- Educate the business users. Invite vendors to provide informational demos of software and provide examples of how other companies in similar industries use the software. Have consultants and vendors explain how an industry best-practice process would work in their environment. Then look at the new functionality these applications bring and determine the knowledge, time, and costs associated with customizing your own duplicate solution. Ask yourself if there are other things more important that your resources should be doing.
- Be consistent and relentless. Enforce the new strategy through the governance process. Have any requests resulting in custom solutions and package modifications go through additional approval steps. Challenge any project request to make sure they first looked at your current application capabilities and alternative vendor software. One company had adopted a buy strategy and then defined their project management process. When someone asked, "Did you look at purchasing a project management methodology?" the company had not even contemplated that as an area for a potential buy rather than build option.
- Engage vendor-neutral experts in the selection process. The project leader of any application selection should be someone who knows industry standard processes and is able to distinguish a requirement that calls for modification to fit within standard processes. The process of identifying the detail requirements and revealing what areas vendors cannot address will help project leaders to understand where and how much the business or the software needs to change rather than claiming they cannot use standard software."Buy versus build reduces costs. Think inside the box, in other words, don't customize it. The worst thing you can do is buy software and then customize it as you are dependent on both a third party and yourself to upgrade."—Mike Degeneffe
Ceridian
No comments:
Post a Comment