SAAS series Introduction 10: SaaS business model

1 Introduction

There are many ways to make money, but you cannot find the seeds to make money. As a professional software engineer, we all seek to use an effective and economical process to build a usable product that can work.

________ Grady booch

The fundamental goal of an enterprise is to "legally earn as many profits as possible to maximize the overall interests of the enterprise ". All specific goals and actions (such as R & D and marketing) of an enterprise are carried out around the fundamental goals and cannot conflict with the fundamental goals. The SAAs business model focuses more on the economic profits created by software as a service for enterprises.

2. New Transformation of SAAS business model

The transformation of business models will involve the transfer of "ownership" of software from customers to external suppliers; the transfer of technical infrastructure and management (such as hardware and professional services) the responsibility of the customer is re-allocated to the supplier from the customer; the cost of providing software services is reduced through specialization and economies of scale; the lowest cost of software sales is reduced, and the long tail market for small enterprises is done.

L consider software as a service

In order to transform from providing internal deployment software to software as a service, software vendors should change their thinking in three interrelated fields: business model and application architecture; the third is the operation structure.

　　

Figure 1 three related SaaS Fields

L change business model

Changing business models will involve one or more of the following situations:

2. "ownership" of the software is transferred from the customer to external suppliers;

2. Reassign the responsibilities of technical infrastructure and management (such as hardware and professional services) from the customer to the supplier;

2. Reduce the cost of providing software services through professional and economies of scale;

2. Reduce the minimum cost of software sales and work in the long tail market of small enterprises.

In order to realize the advantages of SAAS concept, both suppliers and customers should carry out thinking transformation, and suppliers should also help customers achieve this transformation.

L long tail sales strategy

Chris Anderson, author, introduced why online retailers such as Amazon.com are in a favorable position in his long tail article 3, published in The October 2004 Journal of wired, why can the new concept of "long tail" be easily understood by filling in gaps in the field where traditional retailers are difficult to provide services at a low cost.

　　

Figure 2 Long Tail Theory

The demands for books, CDs, and other commodity categories often comply with the power law distribution ". In this case, there are countless books, CDs, and DVDs published each year, but only a few of them can become famous products for a long time. Others are usually published in the long tail category: A large number of publications only interest a small number of people who have special interests. The number of publications is small, and even thousands of copies are missing.

Traditional real-size retailers are dedicated to selling the most popular publications because they cannot take millions of books, CDs, DVDs, and other publications into stock. However, online retailers do not have to worry about inventory issues. They can deliver goods directly to customers from major warehouses around the world, even if the publications they sell are very low, its advertising and sales costs are also unaffected, and they are publicized like the best-selling publications. Therefore, long-tail publications with low sales volumes can also win a large amount of revenue.

Large real bookstores can store 0.13 million different types of publications on their shelves. Anderson pointed out that most of the books sold by Amazon.com come from more than 0.13 million popular publications. In other words, most of the books sold by Amazon.com are not available in traditional real bookstores.

The basic principle of the long tail theory is: as long as the storage and circulation channels are large enough, the market share shared by products with low demand or poor sales can be equal to or greater than the market share of a few popular products. That is to say, a large number of small markets converge into market energy that can rival major markets.

　　

Figure 3 Economic Model of Long Tail Theory

From the above, we can see that, unlike the 20/80 Law, the "tail" function in the long tail theory cannot be ignored. operators should not focus only on the role of the header. The Long Tail theory has become a new economic model and has been successfully applied to the network economy field. For example, Google uses the long tail policy effectively. Google's adwords ads allow countless small and medium-sized enterprises to freely serve online ads, while traditional online advertising is only a field that large enterprises can get involved in. Its AdSense ads allow a large number of small and medium-sized websites to automatically receive ads from advertisers. Adwords and AdSense have therefore gathered tens of thousands of small and medium-sized enterprises and small and medium-sized websites. The huge value and market energy they have produced is enough to compete with the traditional online advertising market. If Google only focuses on 20% of large enterprises (like the online advertising policies of many portal websites), it is hard to create the present glory. Similarly, the online retail giant Amazon's products are all-encompassing, not just a few products that can create high profits. The results prove that Amazon's model is successful, but those that ignore the long tail, it is not ideal to focus only on the operating status of a few top-selling products.

Complex enterprise software solution providers face similar market conditions.

　　

Figure 4 2/8 law of Long Tail Theory

Unlike a simple software package, enterprise software must be tailored to the needs of different customers, which may include on-site installation, on-site service by the manufacturer's service team, etc, specialized server hardware and support personnel are usually needed for management. The cost of providing the above specialized services will increase to some extent the lowest cost of software sales by the supplier. Therefore, this kind of software is usually oriented to large enterprises, and only large enterprises have the strength to pay for specialized services. However, compared with the number of large enterprises that buy Enterprise Solutions, the number of small and medium enterprises with the same requirements is much larger, but they cannot afford high costs.

　　

Figure 5 "Long Tail" in the Long Tail Theory"

SAAS vendors can eliminate maintenance costs and integrate customers' hardware and service needs with economies of scale to provide solutions that are much lower than traditional vendors, this not only reduces the financial cost, but also greatly reduces the customer's need to increase IT infrastructure. Therefore, SaaS providers can work in the market for brand new customer groups, which are beyond the reach of traditional solution providers, because they have no way to provide low-price services for these customers.

Effectively targeting small customers, which requires suppliers who are accustomed to marketing through interpersonal communication and traditional manufacturers and customer relationships to carry out thinking transformation; it is difficult for most suppliers to provide personalized services to larger customer groups at a lower price in large-scale markets.

SAAS marketing is like selling a mobile phone ringtone or music download service. It should allow customers to access your web site and become the paying users of the services you provide, you can start to enjoy the service by paying by credit card. The whole process requires no human intervention from the supplier. This does not mean that you do not need to do interpersonal work on a large number of customer groups with a wide range of needs. However, the design, marketing, supply, and customization processes of sales work are automated from start to end. Therefore, we can not only provide automated services, but also simplify your support for department employees, therefore, you no longer need to help the customer complete related tasks.

3 "ordering" Mode

What is the "ordering" mode? Everyone is used to going to dinner in a restaurant. before dinner, they should try some food. The waiter took out a menu and ordered the dishes by name. This most familiar method will make great innovations in software development. We call each of the smallest user function modules that can run independently "one dish ". A system is divided into several dishes, and several dishes can be assembled into one system at will.

When SAAS provides functional services, it first provides a menu for the customer. When the customer checks the menu, the SAAs platform system automatically provides a table based on the customer's choice. This table appears in front of the customer as a portal. What users seem to see is a system made for themselves. In fact, software vendors do not need to invest any other costs. Almost no human computer is needed to complete all this. Think about how many systems can be assembled if there are 10 dishes? 20 dishes? 100 dishes? These 100 dishes are almost included in the software.

3.1 Overview of "ordering" Mode

Definition of "Dish"

"Food" refers to the minimum functional unit that can be run independently (relative to the platform) according to the category of software functions and can meet the user's needs and be selected by the user. We can intuitively understand it as a small application system, but it is as small as it can no longer be divided. "Food" consists of the user's function page, the set of implemented code (class, package, Component Library), data tables, related documents and configuration files (from the development perspective ).

In terms of software, "food" is a functional component. An independent functional component is a dish ".

Based on the concept of food, software functions should be divided. What is food? How to subscribe food? How to implement the "ordering" mode? With "food", we can use "a la carte", "food", and "processed food" to meet user needs.

"A la carte" is for users to come. If software vendors have existing "dishes", these "dishes" can meet users' needs without any intuitive assembly. This is the best way for software vendors.

However, not all user requirements can be met through "a la carte", and configuration should be considered for unordered dishes, which can be implemented through the "catering" method, if a user wants to eat the "fried rice with eggs" dish, will you reselect a new dish for the user or add the fried eggs with the existing meal to the user quickly? The so-called "food" refers to the latter.

If the food cannot be matched, it is only necessary to perform an operation. This requires modifying and supplementing the Code to meet the user's needs. This is the "processing dish ".

Since everything is based on the idea of "food", it does not matter the system or subsystem. In fact, as long as "food" has been developed, other systems are implemented through "ordering", "catering", and "processing.

Therefore, we regard "food" as the smallest system. The development of "food" includes the entire software lifecycle process, from requirement analysis, design, implementation, testing to maintenance. It should be emphasized that the demand analysis only analyzes a dish, and the design is the same. That is to say, only one dish can be analyzed in the requirement analysis instruction manual. The architecture design instruction manual and detailed design instruction manual are used to design the dish. The relationship between a dish and a dish is implemented through an interface. Dishes are independent and documents are independent. Personnel Organizations engaged in this dish development and design are also relatively independent. This breaks the traditional concept of dividing software by system. Strictly speaking, the so-called "people", "finance", "things", and "things" systems do not exist. There is no ERP, no HR, no OA, etc. To construct these systems, the solutions are implemented through solutions. The solutions also use "ordering", "catering", and "processing" to achieve the ultimate goal.

The "ordering" mode is actually to use the least development to implement as many user software as possible, and the scale effect is achieved through quantitative change. The effective combination of the SAAs model with the "ordering" model will greatly reduce the development costs of software vendors, thereby improving the software utilization rate and then generating economies of scale.

For example, we are used to shopping in supermarkets. A supermarket is a hypermarket. It provides all kinds of products with reasonable prices. Why do customers like shopping in supermarkets? One of the reasons is that many varieties are available. Customers can choose their own. When the SAAs model develops to a certain maturity stage, it will also be transformed into a software supermarket. A large number of software companies will be acquired to complete a job in software supermarkets under the unified coordination of division of labor and cooperation. In theory, all major systems are assembled by components. Our development is divided into the production and assembly of parts.

Parts are fully embodied in the traditional manufacturing industry. It is easy to understand. However, the software industry is completely different. software is an invisible and difficult-to-control intangible High-Tech material with great flexibility. The food is visible, controllable, and easy to grasp. Let's take a look at the composition of the "ordering" Mode 1:

　　

Figure 6 Composition of the "order" Mode

The "order" mode consists of four parts:

1) food source and Division: Various "dishes" are defined based on the demand source ".

2) Implementation of dishes: "dishes" are produced by the configuration development mode, modification mode, and development mode ".

3) food warehouse receiving: Put the prepared "food" into the component library.

4) Assembly: assemble the "food" into a product as needed by the user.

3.2 "ordering" Model Development Process

　　

Figure 7 Development Process of "ordering" Mode

The development process of the "order" mode is as follows: the following 11 sub-processes are involved: component discovery belief, component analysis, component development, Component Warehouse receiving, product release, product testing, internal acceptance, product delivery, and product maintenance:

1) source of demand: Collect stakeholder needs, expectations, restrictions and product component requirements.

2) Requirement Analysis: refine customer requirements and develop product and product component requirements.

3) configuration mode: use custom tools to quickly develop functional components.

4) modification mode: develop functional components by modifying the source code.

5) Development Mode: develop functional components through software program development.

6) Component Library: Manages and maintains functional components.

7) "A la carte" (product assembly): Assemble functional components from the component library according to project business requirements.

8) system test: verify the correctness of the system from the perspective of requirements.

9) Acceptance: the customer confirms the product and delivers the product to the customer.

10) maintenance: the management process in the product maintenance phase.

11) Software problem management: records and manages various software problems found during software project development/maintenance.

3.3 requirement source and Analysis

The requirement source process includes 8:

　　

Figure 8 requirement Source

L demand source channel

1. Sales, 2. Market, 3. intended customers, 4. Contract, 5. Company positioning, 6. Industry agreements

L requirement collection

Collect various requirements, including industry standards, industry solutions, and consulting service information.

L requirement sorting

Filter and sort out the raw materials of the "Dish" formed after the review.

The requirement analysis process includes 9:

　　

Figure 9 requirement analysis process

Function component definition: Define functional components based on the requirement source according to the "food" standard.

Function component list: lists the function components in the template format, and names and numbers each function component. This list is the basis for functional component warehouse receiving and system testing and acceptance.

Component Library search: If this function component is available in the library, skip the development process.

Determine the Development Route: analyze and evaluate the functional component requirements, determine the development mode, and select the fastest and most suitable component production pipeline in the configuration mode, modification mode, and development mode.

3.5 Component Library

　　

Figure 10 Component Library

L Component Library Definition

A component library is a repository used to store functional components. It is equivalent to the inventory of logistics companies. This repository is often implemented by databases. Function components are stored in the database by category and regularity. Different products can be packaged into users according to their needs.

L Component Library Design

A rational and practical component library is the key to ordering food. The visibility of the software increases the difficulty of Component Library Design. The product Decoration in supermarkets is very exquisite. It is an artistic knowledge.

The component library design includes the framework, components, logical structure design, technical implementation, physical structure, operation interface, definition of warehouse receiving and warehouse picking standards, interfaces, and class relationships of the component library.

L Component Library Development

Function of component library, including data model creation, operation interface, warehouse receiving and warehouse receiving, searching and matching, code compilation, unit testing, and assembly testing.

3.6 product assembly

Product Assembly extracts functional components from the component library according to the customer's function list and assembles them into products and submits them to users through the assembly process. The customer may be the product department of the company.

Assembly List: product packages, patch packages, basic platform support components, etc.

　　

Figure 11 Product Assembly Flowchart

3.7 System Test

L preparation

1. System Test Plan: Test scope (content), test methods, test environment and related tools, test completion criteria, personnel and Task Arrangement.

2. Design System test cases: the test cases should be able to fully verify the defined product demand customer functions.

3. peer review.

4. Prepare the test tool.

5. Create a test environment.

L test

1. Obtain products that have integrated all the product components to be delivered and pass the integration test, test the products according to the system test plan and system test cases, and compare the requirements.

2. Manage the defects/problems found during the test according to the software issue management process;

3. Compare the actual and expected results, identify the requirements that are not met by the product, and identify test methods, standards, and environmental issues;

3.8 acceptance

　　

Figure 12 acceptance process

L acceptance preparation

1. the developer, the customer, and other project stakeholders should establish a product acceptance group through joint negotiation and refer to the acceptance owner.

2. The acceptance team should formulate the acceptance plan and obtain approval from the owner of both parties.

L product confirmation

1. Provide training for members of the Acceptance team

2. Product Review

3. Acceptance Test

L hold acceptance MEETING

1. confirm that the product review and acceptance testing activities have been completed before the meeting;

2. the acceptance test team provides: Product Review records, acceptance test reports, and other materials;

3. Hold the acceptance meeting according to the arrangement of the Acceptance meeting;

4. Draw the acceptance conclusion based on the evaluation results and the defined acceptance criteria, and form the acceptance report.

5. If the product requires review, the developer shall provide corrective measures, and both parties shall re-Accept the time

6. negotiation.

L product delivery

Release products that have passed acceptance.

3.9 deliver products

Deliver the product to the customer according to the delivery method and delivery progress defined in the acceptance plan.

　　

Figure 13 Product Delivery Process

L Packaging Design

Product CD, album cover, installation instructions and other designs.

L Product Packaging

Product packaging, including database structure, database creation files, compiled program files, configuration files, and auxiliary

Files, page files, user Installation manuals, user help manuals, patches, platform support files, and other tool files are packaged into installation files.

The packaged files are carved into a CD or placed online for download and installation.

L product implementation

The packaged files are provided for the implementers to go to the customer's site for installation and implementation.

3.10 Maintenance

　　

Figure 14 maintenance process

L preparation

After the product passes the acceptance test and is officially released, product stakeholders (such as Development Department, sales department, product department, Technical Support Department, and customer) should negotiate with each other to establish a product maintenance team and designate the maintenance owner. Members of the product maintenance team can be members of the product development project team or not members of the project team.

L develop maintenance Implementation Plan

The maintenance owner is responsible for preparing the maintenance plan.

L implement product maintenance

1. Identify maintenance requirements

2. Maintenance Requirement Evaluation

3. Implement Maintenance

4. Follow-up work

If maintenance products need to be delivered to the customer and the affected customer software is updated, the period should strictly follow the Configuration Management Procedure Document and change the operation baseline after the approval of CCB.

3.11 software issue management

　　

Figure 15 software issue management process

L Problem Discovery and Registration

In the process of software project development or maintenance, once the development, integration or testing personnel discover software problems, they should fill in the software issue report form immediately. submit the software Issue Report to the problem management personnel designated by the project;

L analysis Classification

Confirm the problem type based on the development phase of the introduced problem;

The project manager is the final decision maker when there is a dispute over whether to modify resources or schedule for certain issues;

Specify the responsible group or owner for problem modification and priority for problem resolution.

L issue release

Issue management personnel distribute and track issues based on the analysis results;

Distribute copies of the software issue report to designated departments or personnel;

Tracks problem resolution and maintains the software issue status registration form to record relevant information,

L problems and solutions and Verification

The responsible department or personnel should further analyze the problem report, solve the problem, fill in the software problem report form, and modify the status of the Software Problem status registration form.

If the problem cannot be solved, you can choose not to solve it in this version. However, it must be approved by the Project Manager.

If the problem is modified, the configuration baseline changes will occur. The change process should follow the "configuration change management" sub-process in the configuration management procedure document.

After the problem is resolved, it must be tested and verified before the problem can be confirmed to be closed.

4. Enhance the commercial value of SAAS through the "ordering" Model

4.1 The "ordering" mode is different from the component development mode

In fact, the idea of componentized development and componentized development in the software industry already exists. Many companies are engaged in this work and have achieved good results. But there are a lot of failures. There are many reasons for its failure. The main difference is that the granularity of components and components is inaccurate. This kind of abstract things that can be big or small will be divided by different people with different opinions.

However, the "ordering" mode is different, and the dishes are visible. Division and development are much less difficult. Food is for the end user, rather than for the software practitioners. The food is functional and the problem is viewed from the user's standpoint. The food granularity is thicker than the component size. In fact, the component can be viewed as a raw material for food. Defining and developing raw materials is a great challenge.

4.2 correct use of the "ordering" Mode

The "la carte" model also adapts to the traditional software industry, but software companies are not doing enough research in this area. There are many difficulties in actual operations and the effect is not obvious. Here are some suggestions for solving these problems:

1. An expert group was set up to plan and define "dishes" as a whole, and to conduct relevant training, guidance and specifications.

2. define and develop the configuration mode, modification mode, and development mode.

3. Break the traditional project-oriented development model and establish a "food"-centered group. However, a group can also form a large group, which focuses only on management and coordination. A group of 3 to 5 persons is the most suitable, and a group of 3 to 5 persons is easier to communicate and manage, with extremely high development efficiency.

4. Standardize and clarify the development mode of "food", including rapid response from demand to design. Each disk "food" supports parameter customization, data model customization, and workflow customization.

5. configuration management gradually implements the "food" mode. It can be automatically and quickly assembled into different application systems through "dishes.

6. Organize and deploy the SAAs model. Click the "food" model to effectively integrate with SaaS to implement civilian software, take the path of software supermarkets, and establish a software service operation platform.

7. re-define and reconstruct the original system based on the "food" standard in stages and pay attention to interface design.

8. provides customers with quick online ordering components, and automatically configures and assembles the Customer Portal System. The platform provides a unified portal, and supports flexible billing based on actual usage.

9. Components in Saas are fragmented. To prevent components from being too fragmented, mashups can be applied based on topics such as an industry.

10. There are a large number of components under SaaS, and a large-scale multi-tenant architecture requires a scalable deployment platform and monitoring mechanism.

11. components are shared and combined at data, service, interface, and other levels, providing infrastructure such as data bus, service bus, and mashup server, and providing scalable industry data models; SAAS components must be customizable and scalable.

12. The customer's ordering and use of products should be greatly simplified, and a unified page style and user experience should be provided.

13. Researching and innovating the scalability of "food" and the Development of source code can provide secondary development.

14. Supports online testing and application deployment. The component facilities are well interconnected with the internal IT system of the enterprise. You can customize the enterprise portal.

15. Development for component libraries is completely separated from development for customers.

4.3 The SAAs Model facilitates the early arrival of software supermarkets

The commercialization of supermarket shopping methods has been deeply rooted in the hearts of the people, everyone has the right to shop in the supermarket. Sellers are not necessarily commodity producers. supermarkets are responsible for purchasing and selling goods. This not only greatly facilitates the provision of inexpensive goods to customers, also make yourself full of money. In fact, at the beginning of 1990s, we still went to a small grocery store or department store and pointed to the goods and asked the sales clerk to give it to us. In this way, there was no more choice and there was no way to ensure the quality of the goods, the price is also difficult to fall down. The appearance of commodity supermarkets has improved the quality of people's life, so that everyone can enjoy shopping. As software is a commodity, how can it not go to a supermarket? If you only sell software as a CD, it is not a supermarket, no matter how many types of software you have, or the number of CD. That's because we bought a whole set of software.

We can divide the organized software into modules. modules and modules can be combined. Users only need to purchase a system consisting of multiple modules according to their own needs, instead of buying financial software, you need to buy the OA system. A lot of software actually uses less than 20% of the features. Therefore, we can satisfy the real needs of users through the ordering Mode. We finally provide users with a system that can cover all functional requirements of users.

In this way, we open a software supermarket on the Internet, allowing users to choose functions by module, and then form an independent system through combined control methods, this will soon make the software more popular and popular. Everyone can enjoy the software, that is, everyone can enjoy the same food. The SAAs model will quickly promote the early arrival of software supermarkets.

5 Summary

Both SaaS and traditional industry business models aim to promote their own products, occupy more market share, and ultimately achieve more economic profits.

This chapter describes how to use the service-oriented SaaS model to understand software with commercial thinking and how to use the "order" model to improve the commercial value of SAAS. The configuration mode meets user customization requirements, starting from grasping more users. Through brand building and promotion, it is clear who is your own customer and what products are sold to the customer to promote SaaS software to create better economic benefits.