Tuesday, December 21, 2010

Waterfall Development

Say the words "waterfall development" to most people and chances are they're going to be thinking of a bunch of condos under Niagara Falls. Imagine their surprise, then, when you tell them that waterfall development is actually a software developmentmodel which involves a phased progression of activities leading to the release of a software product. This article provides a quick and dirty introduction to the model, explaining what it is, how it's supposed to work, and why it can fail.

Overview

Waterfall development isn't new -- it's been around since 1970 -- but most developers still only have a vague idea of what it means. Essentially, it's a framework for software development in which development proceeds sequentially through a series of phases, starting with system requirements analysis and leading up to product release and maintenance. Feedback loops exist between each phase, so that as new information is uncovered or problems are discovered, it is possible to "go back" a phase and make appropriate modification. Progress "flows" from one stage to the next, much like the waterfall that gives the model its name.
A number of variants of this model exist, with each one quoting slightly different labels for the various stages. In general, however, the model may be considered as having six distinct phases, described below:
  1. Requirements analysis: This first step is also the most important, because it involves gathering information about what the customer needs and defining, in the clearest possible terms, the problem that the product is expected to solve. Analysis includes understanding the customer's business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and "shopping lists" of software features. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step.
  2. Design: This step consists of "defining the hardware and software architecture, components, modules, interfaces, and data...to satisfy specified requirements" (Wikipedia). It involves defining the hardware and software architecture, specifying performance and security parameters, designing data storage containers and constraints, choosing the IDE and programming language, and indicating strategies to deal with issues such as exception handling, resource management and interface connectivity. This is also the stage at which user interface design is addressed, including issues relating to navigation and accessibility. The output of this stage is one or more design specifications, which are used in the next stage of implementation.
  3. Implementation: This step consists of actually constructing the product as per the design specification(s) developed in the previous step. Typically, this step is performed by a development team consisting of programmers, interface designers and other specialists, using tools such as compilers, debuggers, interpreters and media editors. The output of this step is one or more product components, built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements. For projects involving a large team, version control is recommended to track changes to the code tree and revert to previous snapshots in case of problems.
  4. Testing: In this stage, both individual components and the integrated whole are methodically verified to ensure that they are error-free and fully meet the requirements outlined in the first step. An independent quality assurance team defines "test cases" to evaluate whether the product fully or partially satisfies the requirements outlined in the first step. Three types of testing typically take place: unit testing of individual code modules; system testing of the integrated product; and acceptance testing, formally conducted by or on behalf of the customer. Defects, if found, are logged and feedback provided to the implementation team to enable correction. This is also the stage at which product documentation, such as a user manual, is prepared, reviewed and published.
  5. Installation: This step occurs once the product has been tested and certified as fit for use, and involves preparing the system or product for installation and use at the customer site. Delivery may take place via the Internet or physical media, and the deliverable is typically tagged with a formal revision number to facilitate updates at a later date.
  6. Maintenance: This step occurs after installation, and involves making modifications to the system or an individual component to alter attributes or improve performance. These modifications arise either due to change requests initiated by the customer, or defects uncovered during live use of the system. Typically, every change made to the product during the maintenance cycle is recorded and a new product release (called a "maintenance release" and exhibiting an updated revision number) is performed to enable the customer to gain the benefit of the update.

Advantages

The waterfall model, as described above, offers numerous advantages for software developers. First, the staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) by both vendor and client. The emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer expectations not being met.
Getting the requirements and design out of the way first also improves quality; it's much easier to catch and correct possible flaws at the design stage than at the testing stage, after all the components have been integrated and tracking down specific errors is more complex. Finally, because the first two phases end in the production of a formal specification, the waterfall model can aid efficient knowledge transfer when team members are dispersed in different locations.

Criticisms

Despite the seemingly obvious advantages, the waterfall model has come in for a fair share of criticism in recent times. The most prominent criticism revolves around the fact that very often, customers don't really know what they want up-front; rather, what they want emerges out of repeated two-way interactions over the course of the project. In this situation, the waterfall model, with its emphasis on up-front requirements capture and design, is seen as somewhat unrealistic and unsuitable for the vagaries of the real world. Further, given the uncertain nature of customer needs, estimating time and costs with any degree of accuracy (as the model suggests) is often extremely difficult. In general, therefore, the model is recommended for use only in projects which are relatively stable and where customer needs can be clearly identified at an early stage.
Another criticism revolves around the model's implicit assumption that designs can be feasibly translated into real products; this sometimes runs into roadblocks when developers actually begin implementation. Often, designs that look feasible on paper turn out to be expensive or difficult in practice, requiring a re-design and hence destroying the clear distinctions between phases of the traditional waterfall model. Some criticisms also center on the fact that the waterfall model implies a clear division of labor between, say, "designers", "programmers" and "testers"; in reality, such a division of labor in most software firms is neither realistic nor efficient.

Customer needs

While the model does have critics, it still remains useful for certain types of projects and can, when properly implemented, produce significant cost and time savings. Whether you should use it or not depends largely on how well you believe you understand your customer's needs, and how much volatility you expect in those needs as the project progresses. It's worth noting that for more volatile projects, other frameworks exists for thinking about project management, notably the so-called spiral model...but that's a story for another day!

Monday, December 13, 2010

Hotel Software- a Complete Hotel Management Solution

The hospitality business needs to handle numerous processes simultaneously without missing out on anything. For any kind of hospitality endeavor be it a five-star hotel or a small sized motel, Hotel Software (HS) is a must-have that provides improved and better service to its customers. This type of software help you increase revenue and customer satisfaction by creating a better and stronger link between your business and your customers and partners.

Software developers across the world have been adding new and advanced features in the modern technology wonders to make things easier for those, who are involved in hotel management. Hotel software is wide-ranging software suite comprised of integrated modules for numerous features of hotel management. The significant modules in the hotel management software comprise hotel reservation software, hotel management system, hotel booking software (billing system), hotel reception and front desk software and hotel accounting software. With these modules, the HS assist you manage reservations, bookings, room stays, room planning, guests, accounts, agents, pricing plans, check-in/ check-out, basically front office and back office hotel operations. In short, this software is designed to help administrator or operator to track all records at just one mouse click. Fully featured, easy to install and use, hotel management software have now come at affordable rates ensuring exceptional guarantee, service and support.


Because of the growing demand of Hotel Software, a number of software development companies have focused on the platform bringing easy to use software for meeting all types of requirements and demands. They guarantee you competent hospitality services and you can modify the features that you wish for. If you are looking for such software companies to improve administration of your hotel and get a good profit, you will surly find a lucrative deal on the internet or reachus@woodappleunik.com to know more. 


There are many websites which allow you to download hotel management software without paying a single penny. Whether you're a motel owner who needs to automate the reservation process, a bed and breakfast owner who wants to get out from under the paperwork of a manual tracking system or a vendor who needs to turn guest history into additional sales, these companies have the complete solution that you need.


www.woodappleunik.com

Sunday, December 5, 2010

Code Comprehension

I’ve been thinking a lot this week about code and documentation—more precisely, I’ve been thinking about code as documentation. The idea of "self-documenting code" is certainly not a new one. When, as a relatively inexperienced developer, I first read about self-documenting code in Steve McConnell’s Code Complete, it was a revelation to me. My first real-world experience with programming was maintaining and debugging someone else’s horrible code, and I knew intuitively from that trial by fire how important it is to make one’s code clear and understandable. From that experience, I started concentrating on code-level comments as the key to making sure that code is properly documented and can be easily understood by others.
But McConnell’s Code Complete really opened my eyes. Self-documenting code, he writes, is "the Holy Grail of legibility...Such code relies on good programming style to carry the greater part of the documentation burden. In well-written code, comments are the icing on the readability cake." (page 456) While reading the 450 pages leading up to this statement, I began to see how writing good quality code is really a matter of making thousands of tiny decisions along the way. Quality code does not happen by accident. It really takes true desire in the heart of the developer, because at each of those thousands of tiny decision points, there are so many opportunities for shortcuts, and so many opportunities to do something that reduces the quality of the code.
The key to achieving self-documenting code is what McConnell calls "good programming style." To achieve this "Holy Grail of legibility," it really takes constant attention, and an ongoing dialog with myself as I work. I don’t know that I’ll ever achieve it, but I’m always trying. I try to approach the writing of code as if I were making art. In my mind, the metaphor of the musician is most apt, since the musician must work within the mathematical confines of his medium, but at the same time can lend so much personal style to the end product.
Architecture is another useful analogy. The architect designing a building must obviously work within the confines of physics, engineering principles, and municipal building codes, but people pay huge premiums for the best architects, who infuse the building design with their unique stylistic statements.
But is self-documenting code enough? Clearly not, because the code itself can never capture the intent of the developer writing the code. The code documents the solution, but knowledge of the problem can only be inferred. This is where comments come in. Here is a quote from my description of The Principle of Comments:
The code is the solution to the problem being solved. Ideally, the code should speak for itself. A person can read the code, and if it's good code, should be able to readily see what the code is doing and how it's doing it. However, what is lost over time is what was in the mind of the developer who wrote the code. In general, this is what needs to commented on. What was the intent of the developer? How is this code intended to be used? How does this code intendto solve the problem at hand? What was the idea behind the code? How does this code explicitly interrelate to other parts of the code? One of the greatest sins a developer can commit is to leave his code without his intent being clear to subsequent readers of the code.
What I try to capture most in my comments is to explain, at a high level, what my code is doing. I try to illustrate what my "scheme" is—how it all interconnects and works. I try to picture myself in the position of the maintenance developer, coming to my code for the first time, trying to figure out how it all works. What would he want to know about this code? I try to picture myself looking over the shoulder of that maintenance developer. How would I explain this code to him? What’s not immediately obvious? What would his questions be? How would I explain to him why I did it this way? The answers to these questions are what I put in my "at the level of intent" comments.
There is a lot of controversy today over which methodology or "family" of methodologies is the best one (the truth is that different methodologies are better or worse in different circumstances), but the larger issues of process and methodology fall away when a developer is by herself, at the computer, writing code. The writing of code is a very personal act. It’s just the coder and the code, alone at the computer. The opportunity exists for the developer (or pair of developers) to stamp his or her own unique signature and style onto the code, just as the musician or architect does.
However, while the desire to develop a truly advanced coding style is essential, it is not enough. The other essential part of the equation is knowledge. Can the musician produce beautiful music without knowledge of the rules of music? Can the architect design a beautiful building without knowledge of the laws of physics and the principles of structural engineering? Can we as developers produce beautiful code without the knowledge of what it takes to accomplish that?
In order to develop a style that leads to beautiful, self-documenting code (as if the two could be separated), in order to make the best choice in those thousands of tiny decisions—indeed, in order to even recognize the opportunity to make those decisions—we must have the knowledge of where the potential trouble spots are. We must know the techniques and conventions and standards. How can we choose the best data and routine names or use ideal layout techniques if we’ve never learned what the programmers of the last forty years have learned by trial and error? How can we properly modularize a system and make it tolerant to change if we are not intimate with the concepts of cohesion and coupling?
If one has that true desire to make one’s code the best it can be, one must acquire the knowledge of what works, and what doesn’t. One must learn the situational subtleties that go into making the best choice in those thousands of tiny decisions that a developer makes when writing a system. Choice A might be the best choice in Situation 1, but in Situation 2, Choice B might be preferable. The rules and conventions are not necessarily absolutes. But if one does not know the rules and conventions, one cannot know when to adjust them to the situation. This is another way of phrasing the old adage, "First master the rules, then you can discern when to bend and break them."
(One must also master the peculiarities of the language being used, even if that language is not the developer’s favorite. Each language is different, and has its own conventions for naming, layout, exception handling, etc. We should try to respect these differences, and not force the conventions of another language onto the one we are writing in today. Too many developers learn a style (good or bad) with their first language, and then impose that style on every other language they use in the future.)
If one desires to develop his or her own unique style, reading lots of great books, articles, and essays is an excellent first step. Make reading a continuing activity.
The next step would be practice, since the code editor and IDE is where theory gets put to the test. Strive to make each program better than the last one you wrote, and then move on to the next one.
Third, read and analyze other people’s programs. If your team is not performing peer-based code reviews, suggest that you start. If you are learning on your own, download code from programming web sites, or look through the code that comes on the CD-ROM with a programming book. You will find plenty of bad code, and, if you’re lucky, some exceptionally good code too.
Finally, if you are able, find a mentor. Identify someone around you that you look up to, whose opinion you respect, and who has the experience you would like to acquire. Ask that person if she will read your code and help you make it better. This can provide amazing leaps forward that might otherwise take months or years—or that might not ever happen at all.

Monday, November 29, 2010

Good Customer Service Is Simple

Outstanding customer service is a competitive advantage. Most companies salute good customer service as a key objective. But in its simplest form, what is good customer service?



Customer Service—A Simple Definition
Customer service means meeting your customer’s expectations. That means you and your customer need to have a mutual understanding of what is expected and you have to deliver on that expectation. The expectation can be very high or very low; the point is that you do not disappoint your customers relative to their expectations.
I sometimes shop at a local discount store. The goods are not high quality, the store is far from clean, I get little or no assistance from the store’s staff, but the prices are great. The last point defines my expectations; they have consistently great prices, so I like the store—they meet my expectations. I also go to a very nice restaurant in my neighborhood. The waiters wear tuxedos, the food is fantastic, my water glass is never empty, they call me by my first name, and it is very expensive. My expectations for this restaurant are very high. If they fail to meet my high expectations, I am not a happy customer. My expectations for these two establishments are very different, but in both cases, I measure my satisfaction against my expectations.
What do your customers expect from you? How do you know? That’s simple, too: you ask them. If their expectations are different from yours, there’s a problem. It is very important that you have a mutual understanding. This often means managing the customers’ expectations. If they have expectations that you know you cannot meet, tell them that you cannot. In both the short and long term, any mismatch in expectations leads to a poor relationship—and you may lose a customer.
Who should talk to the customer about expectations? Of course, you have sales people or customer service representatives talking to the customer on a frequent basis. But they are frequently focused on people in the buying department. You need a broader view of the customer’s expectations. Your engineers should talk to their engineers, your quality people to their quality people, and your executives to their executives. Talk to many people. The greater the interaction, the better the mutual understanding and the greater your ability to deliver great customer service.
Here’s a tip: your largest customers are typically the most demanding, but they are also trendsetters. What they expect today, others will expect in the future. Your largest customers usually have a more formal statement of their expectations, making it easier for you to meet those expectations. 


What Do Your Customers Expect?
In customer service, there are two essential rules:
1. Make promises you can keep.
2. Keep the promises you make.
If you go along with your customers’ expectations, you have made a promise to meet them. This sounds—and is—very basic. The tests of customer service are the many interactions that happen every day—deliveries, invoices, returns, price quotes, and many others. Every interaction is an opportunity to build or tear down customer satisfaction. If you say you are going to deliver at 10:00 AM, be at the dock at 10:00 AM. If you say you will call at 3:00 PM, call at 3:00 PM.
If you interviewed a large segment of your customers about their expectations, you would get a wide variety of responses. Reducing their expectations to a few basic issues, you would do well to abide by the following requirements:


Be Dependable—Being dependable means being consistent. Your customer has to be confident that you will always keep your promises. Of course, things happen (it does snow in winter, for example), and when you cannot keep a promise, they expect to learn about the problem as early as possible so they can adjust accordingly. They need to trust that you will notify them as soon as possible. Being dependable also means being predictable. If a need or problem arises on their side of an interaction, they want to be able to predict what you will do. Predictability is built upon having a consistent history and mutual understanding.


Be Easy to Do Business With—Being easy to do business with is a competitive advantage. Customers will actually pay more for a vendor who is easy to do business with. The administrative issues must work and work well. You do not want to be an exception to their normal business processes. Meet with other people than the buyers to understand how you can make their life easier. For example, should an advance shipping notice be sorted by your item number, their item number, the same sequence as on the purchase order, or some other sequence? Using the right sequence can save them time, money, and aggravation. Asking them about the sequence lets them know you care about being easy to do business with.


Be a Long-term Supplier—Switching suppliers is difficult. Your customers would rather keep you as a long-term supplier than have to switch. They need you to continue to meet their changing needs in the future, be it the type of products you supply, or the quality standards you adhere to, or the business processes you use. They also expect you to continue to be sound financially. That means they expect and want you to make a fair profit. What constitutes “fair profit” is up for debate, but they need you to be profitable for their long-term health.


What about Exceeding Your Customer’s Expectations?
We often hear that a company has a strategy of exceeding customer expectations. As a general statement, exceeding your customer’s expectations is good, but not always. Exceeding expectations is good only if it is meaningful to the customer. Let’s look at an example where exceeding customer expectations had no impact and even some negative impact.
A chemical company decided that quality was very important. They therefore tightened their specifications for certain products. But these products were used by many customers, and those customers had engineered their production processes around the original specifications. For many, the tighter specifications were meaningless. As long as the product met the original standards, their production processes continued to work, and the customers did not even realize that the new specs were tighter. For some customers, the tighter specs caused some production problems, and they had to do some engineering to account for the tighter specs. The chemical company saw tighter specs as an improvement to customer service, but it had no impact on most customers and a negative impact on a few. If the customer does not see value in the “improved customer service,” it is not an improvement. Changes in any direction can have unforeseen consequences.


The Role of Systems
At a tactical level, making promises you can keep and keeping those promises is enabled by internal systems. We stated that good customer service means making promises you can keep. To make these promises, your systems need to predict what you can and cannot do; if you cannot meet a customer’s request, your systems need to give you the information to manage that request. If a customer needs a delivery on a specific day, your systems need to tell you if you can make that date. If you cannot make that date, the systems should tell you when you can and what you need to do to make it happen. 
Your customers want consistency. Good systems have well-defined business processes that produce consistent results. They even have well-defined processes for exceptions.
An investment in standard business processes is an investment in customer service.


Summary
Good customer service is simple. Your customers have expectations, and if you meet those expectations, you are doing a good job. The key to good customer service is a mutual understanding with your customers on what they should expect. If they have higher expectations than you can deliver, they will be dissatisfied; you may lose a customer, or go from being a preferred supplier to an occasional supplier. If they have lower expectations, you may have an easier job of meeting them, but you are also at risk of being replaced by a supplier who will provide better service.

Thursday, November 25, 2010

Custom Software Development - Necessity and Advantage

Custom Software Development services are growing day by day. One of the major reasons behind it is the flexibility custom made software solution offers which almost every business is in need of to modernize and to change with the often changing working patterns. Further, to stay ahead in this fast paced and competitive world, companies have to be highly adaptable and to suit such transforming needs customized software solutions play a key role.

In order to get smartest programs, businesses need to use client-oriented approach or project management. Companies should be well aware of the requirements of their customers. If you are a company you can take help of specialists to learn about the products of your customers and meeting closest to the needs of your customers in most efficient way. It is the duty of the manager to contact customers and update them about the progress of their work. A manager also helps in making corrections with possible mistakes that are done by entry level software developers. Custom software development proves useful and fits the need of customization to be done.

Custom software solutions are specialized solutions, well crafted and developed primarily for catering unique needs. It is usually not targeted for the mass market, but generally created for particular companies, business entities, and organizations to serve their specific needs. Also it is designed on special requests of the company and therefore, final output is different matching exact budgets or project managing needs of the company.

Besides there are other Advantages and features which include following:
  • Easy and User-specific: Custom Software will not have UNWANTED functionalities which makes it easy to use and more user friendly or user specific.
  • HIGHLY Cost EffectiveNo need to pay for UNNCESSARY functionalities; no EXTRA cost for customizing as it would already have a provision and capability for it and may not require license fees to create more copies. Thus it becomes more affordable.
  • Saves Time: Custom Software Development may take less time as it is for specific or focused group.
Custom Software Development is a niche of experts and requires a very good skill, technique, experience. Therefore one must be very cautious while hiring efficient developers for such services.

Sunday, November 21, 2010

Custom Software Development and the Management In Organizations

Custom software application development is in a mature state and is now providing exclusive solutions to businesses in the form of various management systems such as supply chain, content management, human resource management etc. Once developed and incorporated, these systems become vital assets to the organizations as fulfillment solutions with extraordinary utility and efficiency. Software applications are tailored for organizations to perform many different functions like financial analysis, valuation, reporting, forecasting etc. These are some of the factors determining the functionality of an organization and evaluating its proficiency.

Custom software applications are built entirely on the expertise and skills employed in custom software development. By providing unique solutions to organizations for a number of functional aspects, these applications help them to function in a more effective and dynamic manner. Custom software development is the result of a practical approach that business identities started adopting to address various issues related specifically to them and possess unique products that stand out in the market. The new ideas and practices brought a variety in the kind of solutions as the use of technology and the skills involved came from different perspectives. Offshore software development is the current preferred practice for getting innovative software solutions on low budgets.

No such belief exists now that an offshore software application developer is under-resourced or lacks the skills and expertise required to develop high-end solutions. As a matter of fact, many of these developers are now believed to have greater project management and streamlining proficiency than what many West-based developers would have. They are helping organizations worldwide by providing solutions based on new technologies that can meet the organization-specific requirements and address those issues which hinder their growth. With someone like a custom software developer India, organizations can easily get tailored solutions to help them achieve success and growth regardless of their location.

The process involved in custom software application development includes a strategic planning in advance for the project. It combines the domain expertise and the use of latest technologies for delivering effective outcomes. The projects in the undertaking of experts of the field run in a streamlined manner reducing the deployment cycle time and cost and providing a faster rate of return. These days, a special emphasis is laid on developing scalable custom web applications, which enable organizations to benefit greatly with a smooth management even with the increasing load.

Wednesday, November 17, 2010

Customizing ERP Software

Customizing is an integral part of ERP solutions. This is a crucial decision which needs to be taken by the organization as it is detrimental in ERP'S success. The rate of customization is directly proportional to ERP success. Customization tends to pose a challenge to time and the funds allocated. The challenge of a successful management lies in balancing them and making both ends meet. It is a difficult task but the success speaks for the process.

Burning Issues

The major issues that require attention in the process of customizing ERP are strong knowledge about the current system and the likelihood of innovations in ERP. These two issues have their own say in the process of ERP customization. The process of customization will not take place properly unless or otherwise there is a strong working knowledge about ERP systems. Even if it does the rate of success won't be to that of the desired or atleast required extent. The chances of innovation in ERP will have a say on the customization of ERP because whatever modifications are done now would not have any relevance if they are already covered in the new systems. If the management addresses these two issues properly then the chances of ERP's customization are pretty high which also speaks for ERP'S success. A proper ERP solution can be provided by the Right ERP company.

Features of ERP innovations

The innovations of new ERP applications help users to include all the specific details in ERP system itself. This means they don't have to input these details into the ERP systems every time they login. This also implies that the operators need not recompile ERP softwares as and when there is a change in the attributes or methodology of data fed. Customization has also helped the users to act independently rather than depending on the vendors whenever a modification is required. The innovations in New ERP systems have made it so userfriendly that the customers go to the extent of modifying the systems to perform functions exclusive to the organization. ERP solutions are now handier to customize than ever. ERP company offers numerous and flexible ERP solution.

Sound knowledge about ERP System

The features be it old or new or modern or traditional will not be of any use unless the users are aware of the ERP Systems features and modalities. This knowledge has to be imparted to the end users apart from IT personnel. They should have a clear knowledge about the entire system in finger tips. If questioned or demanded they must be capable of bringing that particular function into effect. The services of an expert ERP consultant will come in handy for an organization to supply this information to the user. The consultant will make a decision on the basis of the organizational needs and system configuration. He will be a part of the organization for quiet some time. This will also help him in know the organization and people better. He will therefore be able to work easily. Customization is an important part in implementation of ERP.ERP Company can decide the proper ERP solution for the organization.

Conclusion

The extent of customization does not solely decide the success of ERP. If it results in user satisfaction another important criterion then customization and ERP success go hand in hand. The best choice has to be made from ERP solutions.


www.woodappleunik.com

Monday, November 15, 2010

The Seven Truths About CRM for SMB's

SMBs have strikingly unique requirements for CRM. Obviously, they have fewer people, less time, and less money to spend on implementing software. But they do take their businesses and customers very seriously (maybe even more so than bigger, bureaucratic organizations), so SMBs want tools that can specifically address their requirements. Presented here are seven truths about SMB CRM: 

1. You can't put 10 pounds of CRM in a 5-pound SMB bag. 
SMBs simply don't have the money to acquire and customize a large, horizontal system. A handful of vendors now offer comprehensive CRM specifically designed for SMB budgets and domain knowledge. 

2. Vertical solutions are more than a beachhead. 
Vertical application solutions are primarily about data and processes. The CRM system must be able to reflect industry-unique information like customer and product profit, customer value, next best product recommendations, and customer retention assessment. It must also be easily adaptable to current and future company processes. 

3. When the lines are blurred, the more, the merrier. 
As more and more companies are crossing lines of businesses (e.g., banking into brokerage, insurance into banking), the ability of the CRM system to understand and manage multiple lines of business simultaneously is critical. 

4. Wahoo for Yahoo!--don't assume customization is configuration. 
Unlike configuration options or service-based customization, tailoring offers an affordable solution for SMBs to obtain a highly customized solution that fits the organization's own specific data and process needs. 

5. Admit it--you like your data integration cheap and easy. 
Data needs to be tightly integrated into the CRM and refreshed regularly to enable an accurate picture of the customer. Ideally, the CRM system comes built to handle this out of the box. 

6. Toggling is dirty application integration. 
In most SMB environments companies already have core systems that run their businesses. As such, they don't want a separate system to be on their desktops. 

7. Keep your ASP to yourself--you ain't touching my data. 
While the ASP model seems to be a gift to SMBs, it does not provide enough data integration or security for many businesses. Therefore, a new model, in-house application hosting, brings the affordability and ease of use of the ASP model, with the security and integration capability of the traditional in-house systems. 

If you ever read the story of "The Emperor's New Clothes," you remember the little boy in the crowd who noted that the Emperor was naked--the rest of the kingdom followed along accepting the vendor's deception that the Emperor was dressed. SMBs can't use the same software and business practices that have been used by the large and horizontal CRM companies. Disguising an all-purpose CRM application for SMBs is just unfit. In fact, the confusions created by the CRM industry would make anyone fit to be tied, but SMBs can be treated like kings when they can have CRM fit for them and only them. 


www.woodappleunik.com
reachus@woodappleunik.com