Reach1to1 Technologies - scalable business tracking solutions for field and channel sales, order processing and customer support - Part 2
  • About

    Reach1to1 Technologies is a provider of business solutions using the latest web technologies. With a complete range of standard products that can be customized and setup in a matter of a few days, Reach1to1 can help your business integrate your entire workforce including employees, suppliers, channel partners and customers with web based applications.

Characteristics of Evolving Enterprises

Vivek Ranadive, the CEO of TIBCO – a highly acclaimed enterprise software company, has written a new book The Power to Predict: How Real Time Businesses Anticipate Customer Needs, Create Opportunities, and Beat the Competition. If we’re to go by his previous book The Power of Now, its a sure best seller!

A review of the book by Dennis Howlett says:

Essentially the book is a collection of stories covering a broad spectrum of industries and their efforts to see the next thing that is likely to impact their business, take corrective action or seize opportunity. It includes companies like Pirelli, casino giant Harrah’s, Spanish ex-pat bank Solbank, FedEX, Southwest Airlines, amazon.com, E&J Gallo Winery, Essent Energie. I wish they could have talked about a host of others I came across but am not allowed to mention. Believe me when I say TIBCO has a customer list to die for. More important are the characteristics these companies share:

  • Customer-driven – not focused but driven
  • Embrace cultural change – they don’t fight change
  • Management by exception – the routine stuff is assumed to be taken care of
  • Innovation – they don’t shy away from change
  • Merit-based alliances – there’s no entitlement in a relationship
  • Meritocratic and entrepreneurial – no consensus here
  • Leaders provide opportunity – organizing staff to empower themselves
  • Short planning cycles – event driven and highly responsive to market conditions

These are all characteristics I believe the modern professional practice should aspire to if it is to be super successful.

… an ideal set of characteristics that we would like to attribute to our favorite term Evolving Enterprises. Some of the visionary clients that we have the privilege of working with, like APW President constantly exhibit these very qualities, and continue to prosper in the face of ever changing market conditions. We salute their vision!

Waiting to get hold of the book…

Posted in Evolving Enterprises | Leave a comment

Expense Claims Workflow

Companies having employees distributed in small teams across multiple locations, such as sales teams, or project implementation teams spend a lot of effort in tracking expenses incurred by employees. Each expense claim needs to be verified and approved, so as to attribute it to the appropriate account head and apportion it to a profit center, such as a prospective customer or a project.

Some of our clients have sales teams and project teams that are located in different cities and towns acrosss the country. We have observed their process for routing expense claims to be slow, resource-intensive and cumbersome. The employees are typically expected to fill in vouchers and attach supporting documentation such as bills and submit them for approval. These claims are then approved by a local authority and then passed on to the central accounts department.

From our observations, having supporting documentation is a necessary evil. However, most of the paperwork is required primarily during initial approval by the local authority, and subsequent consolidation by centralized accounts can be much simpler if all the expense claims are digitally recorded in a central repository that is accessible to all locations.

The Expense Claims Workflow that we built provides the following procedure for expense claims:

Expense Claims Workflow

The workflow proceeds as follows:

  1. The employee situated at any location logs in to the application, enters expense claims using a simple form, that could be integrated with any other workflow such as the Sales Activity Management workflow, or Order Processing workflow.
  2. At the end of the week, the employee takes a print-out of the report showing the expenses incurred during the week. He hands over this report, along with supporting documents such as bills cash memos, etc. to the local area manager. The area manager logs into the same application and views the claims and verifies them against the supporting documents, where relevant. The area manager may mark expenses as:

    approved icon Approved: The area manager may approve all or part of the amounts claimed. Those expenses approved by the area manager are forwarded to Accounts on a weekly basis. (The collective printouts of the expense reports along with the documents are forwarded by courier each week).

    expense clarification icon Clarification: Expenses marked for clarification are sent back to the employee for clarifications. The employee gets an email alert with a link to the expense in question.

    expense denied icon Denied: Expenses marked as ‘Denied’ by the area manager may be reviewed later with the employee as required and can then be re-submitted subsequently.

  3. The Accounts department at the head office receives all claims approved and forwarded by area managers from all locations. Accounts then looks up these claims in the same application. Accounts can then mark each claim as:
    expense approved locked icon Approved and Locked: Expenses approved by accounts are considered Passed and Locked. Approval may be granted for the entire amount or part of the amount only. The area manager then cannot modify the approval status.

    expense clarification icon Clarification: Some expense claims may be returned to the concerned area manager or employee for additional clarification.

    expense denied locked icon Denied and Locked: Expenses denied by Accounts are considered final and locked. The area manager then cannot modify the approval status.

In the above workflow, all concerned persons, such as the employee who entered the claim, the area manager, or other persons with supervisory roles and permissions, may track the progress of each claim through the entire workflow. A stipulated time frame can be set within which claims are to be processed through the system, failing which alerts are generated and the defaulting claims are escalated to top management.

Finally, the expense information is tagged against other information in the workflow system, such as:

  • Employee who incurred the expense
  • Location / Division where the employee was located when the expense was incurred
  • Expense Account Head
  • Customer or prospect that was served
  • Sales opportunity, project, or order against which the expense was incurred
  • Travel, customer visit or other event that resulted in the expense claim

Due to the fact that each claim has all this information tagged to it, a detailed analysis can be provided that tracks the levels of expenditure by various above fields.

We shall soon post sample screen shots, analytical reports and graphs that the system generates.

We would like feedback and suggestions regarding any additional features that we could incorporate that may make the system more useful in different usage scenarios.

Posted in Affordable Technology, Agile Development, Evolving Enterprises, Laboratory Information Management, Sales Activity Management, Workflow Management | Leave a comment

Implementing Sales Management – Where to Start?

We recently got an enquiry from Manoj, a small business owner based in Bangalore. He runs a successful business that provides networking solutions, as well as another firm that provides contractual staff to large corporates. He wanted to know where and how he should start implementing ERP in his organization. “Can you ask me some questions that will get me started?”.

Small businesses owners like Manoj are seeking solutions that will help them grow and join the surge in the Indian economy. And most of them assume that the solution to their scaling up needs is the one-size-fits-all ERP solution. After all, do we not keep reading about how every large manufacturing company in India has spent millions on large scale ERP implementations? If it seems to work for them, maybe it should work for us too.

As technology providers, we know that “One size does not fit all”, as Andy Hayler likes to point out. But as a small business owner, what issues does one have to consider?

Here is the discussion we had with Manoj:

  1. Firstly, let’s begin by looking at what your existing pain points are. What fires do we need to douse? Where are we the most inefficient? What issues are waiting to become emergencies?
  2. What do we want to achieve in the next 3 months, next 6 months, etc.? How fast do we want to grow in size? How many people? How many locations are these people spread across? What is the level of computer-friendliness do the people have at different levels?
  3. Next, we look at the information base. As we grow in size, the main point of failure is lack of information availability. When we are a small team, its easy to keep in touch with every detail. As we grow in size, we lose touch with small details. The first issue to tackle is to plug the leaks of information flow from the bottom to the top. Now that’s not as easy as it sounds. Problem is, the information needs to be captured where and when it is being generated, in a format that can be re-used and analyzed. That means, you need:
    a. The infrastructure and systems to capture information at every point in the extended enterprise
    b. People who actually bother to enter the information
    Out of the above two, the latter issue is far far more difficult to achieve, especially with the kind of business processes Indian companies follow – ie, no processes – which is great when you’re small, but its un-scalable.

    So, we need to find a path of least resistance in creating the system to capture the information. This means finding a good balance between information value and ease of use. Creating a monster of a system makes it extremely difficult to implement. Its far healthier to do it stage-wise, in a way that we can change the plan as we go ahead, based on where we find least resistance and maximum value.

  4. Where do we start? Obviously, information that is directly related to business transactions is of paramount importance, without which the business would not run. So I assume that the basic accounting system must be in place. But accounting is an extremely inward perspective of the business. The main drivers of a service-oriented business is customer responsiveness. How fast, and how efficiently are we able to respond to a customer’s need and find and deliver a solution that fits . Unless you have some other pain points that need immediate attention, the area to look into is the process of capturing customer information and the process of servicing and retaining customers by keeping information about them up-to-date and accessible at any time.

So what do you think about this approach? We would like to hear…

Posted in Affordable Technology, Evolving Enterprises, Sales Activity Management, Workflow Management | Leave a comment

Business Scalability

Nicholas Carr had an interesting post on Scale and Scalability, where he points out the difference between the two similar sounding terms

It used to be you’d beat your competitors by achieving greater scale in your operations, enabling you to spread your costs over more products and thus push down the cost of producing each product. Scale was tangible, a manifestation of plant and equipment and other real assets. Today, you strive to beat your competitors by creating an idea or a model that can scale without constraint, expanding easily and flexibly to handle ever more business. Scalability is intangible.

So scalability is achieved as a net result of the entire business process being scalable, instead of merely increasing “production capacity” or efficient “resource planning”. As Nicholas points out, this scalability is easier to achieve in a pure technology business like Google, where building a good business is not all that different from building a good data-processing system. But in other industries that involve human actions and physical products, achieving this kind of scalability is not that straight-forward. The ability of a business to achieve scalability is directly proportional to its ability to create a standardized workflow that can then be scaled up to deliver higher throughput.

Scale and scalability both have strengths and weaknesses as business strategies. We know the strengths and weaknesses of scale pretty well by now. We’re only beginning to understand those of scalability.

It is our endeavour to try and unravel precisely this mystery for our clients. Its an interesting adventure!

Posted in Evolving Enterprises, Workflow Management | Leave a comment

How far can web applications go?

Five years back, we created our first web based enterprise application for a small gift manufacturing company. We were faced with all the bottlenecks that we face with web applications today – lack of good connectivity, server response times, network lag, browser incompatibility – but only several times worse.

One solution we created to overcome these hurdles was to create a Client Web Server. It was a small foot-print web server that was installed on each client computer, and which did all the work of the user interface, and made network calls to the server only to fetch data from the database. It worked great, because the network traffic was minimal and user interface was fast. We were thrilled with our solution. Based on its success in the small, two location installation, we later deployed the same solution in Branch Management System for an engineering company which had several branch offices spread around the country. This was when we faced the big hurdle – managing installations on several client computers was no mean task. With the Windows 95 OS that was prevalent in those days, we had to repeatedly re-install the web server every time there was virus infection or other such frequently occuring disasters.

Fortunately, by then the connectivity scene was much better, and we abandoned our Client Web Server model for a traditional centralized web server with normal browser clients.

Now, browsers are becoming more and more intelligent, capable of doing user interface tricks that could earlier be implemented only on native applications. Technologies such as DHTML – or Dynamic HTML allowed web applications to modify entities in the user interface dynamically using Javascript. CSS – or Cascading Style Sheets simplified the process of stylizing the interface – such as fonts, colors, and later, even the layout of entities on screen. The latest development termed AJAX – or Asynchronous JavaScript + XML – a term coined by Adaptive Path allows web applications to retrieve data from servers witout refreshing the page, thereby providing faster interfaces in the web browser. We have recently started using AJAX extensively in our applications and are thrilled by the performance enhancements.

The question that this all raises is how far can we, or should we push this model? Jason Kottke’s excellent article on Web based Operating Systems – or Web OS talks about how big guns like Google, Yahoo and Microsoft are tooling up for creating the next new frontier of the web. He talks about precisely the same model that we used five years back to overcome connectivity problems – a client side web server! How interesting. But hopefully, if one of the big guys are behind the effort, they will have the deep pockets required to see this model through its inevitable teething problems.

We’re all excited by the possibilities of where and how far we can push this model. Just to give a brief idea of how we’ve matured in web based applications, here are a few screen shots of applications we’ve built over the years:

Web based Order Manager Screenshot
Web based Order Manager – 2000

Web based File Manager Screenshot
Web based File manager – 2003

Web based Sales Management System Screenshot
Web based Sales Management System – 2005

As we stretch the possibilities of web applications into the enterprise, the capabilities of applications on the client side become increasingly important, and we hope to see the advent of a widely supported Web OS soon.

Posted in Evolving Enterprises, Workflow Management | Leave a comment

How to choose technology solutions

Information Technology enhances business performance

Everyone believes that Information Technology can do wonders to the productivity of an enterprise. Yet, as a business owner, it is far from easy to put your finger on exactly what IT can do for a small/medium sized enterprise. A previous article attempted to answer this question – What can Information Technology do for a Small/Medium Sized Business Enterprise?. It discussed how an enterprise can create a Business System, consisting of processes and policies that are used by people and resources, aided by information technology, to generate enhanced performance.

Once a business owner is convinced that IT can enable higher performance, and is prepared to upgrade processes and policies to make them techno-savvy, the next important questions are:

  • Which technology solution to choose?
  • What are the risks involved?
  • What are the costs involved?

We shall attempt to answer these questions here.

Which technology solution to choose?

Technology is undoubtedly one of the fastest growing industry sectors. And this growth is accompanied by innumerable options provided by IT service providers ranging from hardware manufacturers, operating systems, database systems, application software, connectivity, etc. that all form part of the solution. To complicate matters, each service provider introduces new jargon that purportedly differentiates their product or solution from the rest and rises above the noise. But as a business owner, all this makes the decision of choosing the right combination of technologies and providers extremely difficult.

In an attempt to reduce the noise and get some clear picture about what technological options one needs to consider, we have taken the metaphor of constructing a building. We have identified three basic areas in which one needs to make a choice, while selecting a technology solution:

  1. Architecture
  2. Construction
  3. Ownership

The diagram below lists out the choices in each of the above three areas:

Technology Choices

1. Architecture

The three types of architectures available for implementing an IT solution are:

  1. Stand-alone – where a single computer contains the entire solution – stand-alone solutions are useful for personal productivity applications like word processing, spreadsheets, email, etc. where a single individual creates information and accesses it from a single computer, with little or no requirement to access the information from anywhere else.
  2. Client-server – where the solution involves a server on which the main application and data is stored, and client computers where special client application software is installed for accessing and processing information from the server. This model is used extensively for conventional enterprise applications that require information to be captured and accessed by multiple people connected to each other by a network.
  3. Web-based – where the solution is primarily installed on a server, and is usable from any client computer with only a web browser – no special client application software is required to be installed. This model is suitable for applications where information is to be captured and accessed at multiple locations that can connect to the server via a network- including via the Internet. Web based solutions are gradually becoming widely available for all types of requirements.

2. Construction

The four construction options are:

  1. Standard Product – This option represents solutions that are available as standard products. The product encapsulates a set of built-in features, much like a pre-fabricated building. If the features available in the product are a good fit for the requirements of the business processes and policies, a standard product may be a good choice.
  2. Customized – Several standard products have facilities to configure and customize features, requiring varying amount of expertise. The amount of customization required to achieve the required facilities is the prime consideration to choose this option.
  3. Custom-built – Custom-built solutions have a high degree of flexibility and can be built to suit the exact requirements of the business. However, the costs and risks can be higher. New development methodologies like Agile Development, can minimize these costs and risks.
  4. Open Source – Open Source applications have emerged as a new option for constructing IT solutions. Built by teams of programmers who collaborate by volunteering their efforts without compensation and for mutual benefit, several open source applications have grown to become feature-rich products with complete source code available to any user. Enterprises can use open source applications with low upfront investments, and with relevant technical skills, can customize the code to match their requirements. Open source alternatives for basic requirements like email access, web site management, basic collaboration, etc. are now easily found, but applications for business process management are few and not yet mature enough. However, this is a space to watch.

3. Ownership

  1. Purchase (License) – Conventionally, most software products are available in this model. Payment is made once, and the purchaser is given a license to use the software with certain restrictions based on number of users, computers, servers etc. as per the license purchased. This model does not take into consideration, the frequency of use of the solution, or the features used. The purchaser usually pays for all the features in the product, irrespective of which ones actually serve the requirements. This model usually involves products that are physically installed on the purchaser’s own computers.
  2. Rental (ASP) – A new ownership model is emerging as an alternative for some IT solutions. Enterprises can rent an application that is physically installed on the service provider’s computers and accessed by the purchaser via the Internet. The service provider is called an Application Service Provider. This is still an emerging model and not many applications are available.
  3. Per-per-use – This model of ownership is an extension of the Rental model, but instead of paying a fixed recurring fee per user or per period (month or year), the pay-per-use model allows the user to pay for every usage. For example, online payment services usually allow a model where customers with a small number of transactions can use the service free with charge deducted for every transaction. Similarly, software solutions that are not used often – for example, online surveys, marketing campaigns etc. can follow a similar model of payment.

Choosing the right combination

We have seen above, that the permutations and combinations of options for choosing a technology solution are several. To choose the right mix of architecture, construction and ownership, a cost-benefit analysis needs to be made. The benefits one needs to consider are in terms of :

  1. Suitability to current requirements:
    1. Is the solution suitable to be used by the number and nature of people and resources in the business system?
    2. Is the solution suitable for handling the processes and policies of the business system?
  2. Flexibility to handle future requirements – For how long can the solution serve the business system? Can it handle the changes in the business system that are inevitable during the time frame planned? Will the solution handle the growth expected?

What are the risks involved?

The next important issue to be considered while choosing a solution are the risks involved. Statistically, the failure rates of software projects is extremely high – over 90%! The factors attributed to failure of software projects are :

Project Challenged
Factors
% of Responses
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%

(from the CHAOS Report by the Standish Group. See Why software projects fail – and how we make them work for more details)

As seen from the above list, some of the major causes of failure of software projects is related to user inputs, and requirements. In conventional software development methodologies, requirements were expected to be completely defined, and unchanging atleast through the lifetime of the project. However, if we look at how IT helps a business system, software is merely an enabler for a business system to deliver enhanced performance. It cannot be successful unless the processes and policies are re-designed to take advantage of the technology. In such a scenario, working out requirements needs an assumption about how the upgraded processes and policies will work. Such assumptions can easily be found lacking, and when actually implemented, may require changes and re-tuning – which in turn may require the software to be changed too! This is what causes the most failures in software projects.

These risks are minimized in the emerging technological options – such as web based architecture, agile development and rental applications.

What are the costs involved?

When choosing a technology solution, one needs to consider the total cost of ownership of the solution. An IT project typically involves the following costs:

  1. Hardware – servers, client computers, peripherals
  2. Platform – operating systems, basic server software applications like database servers, web servers etc.
  3. Application Software – License, Customization, Development, Hosting
  4. Connectivity – Network, Internet
  5. Training – upgrading manpower skills to utilize the new processes and policies in the context of the new technology
  6. Administration – Every solution needs to be administered. Administration requires expensive skills that an SME may not be able to completely justify
  7. Support & Maintenance

Costs are easier to manage with the emerging technology models – such as web based solutions, agile development and rented solutions.

Conclusion – go for IT as a service

If we look at the general trend in new technological developments in architecture, construction and ownership, the trend is to convert Information Technology Solutions into a full-service.

IT as a product v/s IT as a service

The above diagrams shows a comparison between implementing IT solutions as a product v/s IT solutions as a service. The diagram on the left shows the conventional options of IT solutions – stand-alone or client-server architecture with standard or customized products, owned by purchasing licenses. While the diagram on the right shows emerging IT as a service options – web based architecture, with custom-built agile applications or open source applications, owned as rental or pay-per-use solutions.

Bottom-line: Choose IT as a service
But where are these options available?
Contact Us to find out.

Posted in Affordable Technology, Agile Development, Evolving Enterprises | Leave a comment

What can Information Technology do for a Small/Medium Sized Business Enterprise?

Small businesses owners are hard-pressed for managing with scarce resources. How can technology ease their stress levels? Information Technology (IT) is often touted as the magic potion that has solutions for almost any business ailment. But IT is a confusing world of jargon, with incomprehensible abbreviations like ERP, CRM, SFA, SCM, EAI, BPM … and so on. How does a small business owner make sense of all this jargon, and what is a practical approach to adopting IT? This is the first article that begins the series to analyze and answer this question.

What is Business?

Before we begin to understand what Information Technology can do for business, let us define what we mean by Business

Definition:

Business is a System
consisting of:
Skills (People) - Employees, Suppliers, Partners etc.
and
Resources - Components, Equipment, Money etc.
that execute
Processes - Sequence of Tasks or Activities
governed by
Policies - Rules, Responsibilities, Standards, Norms
so as to deliver
Business Performance - Service, Product or Solution
to satisfy a
Demand - Customer requirements, Problem or Pain-point

Business Model

This system is held together as a cohesive entity by Information. People and resources are able to co-ordinate and perform processes and adhere to policies by using business information.

Information is the glue that binds the Business System

When the enterprise is small, with a few number of people and resources, sharing business information is easy – processes are easy to track, policies are easy to adhere to. In fact, no significant policies may be defined because individual judgement can be relied upon in a small team. However, as the demand grows and the enterprise grows to satisfy it, the number of people and resources need to be increased, and it becomes gradually more difficult to follow ideal processes, and policies need to be defined clearly so as to ensure quality of deliverables.

Business Performance of Evolving Enterprises

The red curve in the graph above represents the initial growth curve of the business system. As the system grows in size, information becomes more difficult to track, and the rate of growth starts to slow down. This is the time to change the system.

If Technology is added to Business Information, the ability of the system to Perform is enhanced. However, we need to realize that merely adding technology to the old system, consisting of old processes and old policies will not work. Technology is merely an enabler of new processes and policies that can together deliver enhanced performance.

How does Technology enhance the performance of the Business System?

What does technology really provide? The three basic abilities that technology brings to the business system are:

  • Data – re-usable information
  • Logic – business workflow model
  • Network – virtualizing the enterprise

Data – Re-usable Information

The first ability of technology is to convert information into data. With technology, information can be captured when it is generated, and not when it is required for consumption. For example, each member of the order execution team needs to have instant access to customer requirements without having to ask the sales person, or even worse, the customer.

Converting Business Information into Data

Logic – Workflow Model

The second ability that technology brings to the Business System is Logic. The processes and policies of the Business System can be codified into programming logic. The following flowchart illustrates a small sample. This kind of a model is called a Workflow Model of the processes and policies. It helps to ensure that the tasks and actions that are part of the process are performed in the correct sequence, by the right people utilizing the right resources. And also ensures that policies are adhered to.

Workflow Example

Network – Virtualize the Enterprise

The third ability that Technology brings to a business system is the network. When the enterprise grows to span multiple locations, the information backbone of the enterprise should not break-down and create silos of information at each location or division. Today, technology that can provide world-wide access to a single database source is practical and cost-effective. In addition to integrating data and workflow across multiple locations or divisions of the enterprise, networking can also integrate the enterprise workflow with the extended enterprise – consisting of suppliers, business partners, agents, distributors, and ofcourse, customers.

Network - Virtualizing the Enterprise

The IT-enabled Business System

The IT enabled business system consists would ideally consist of :

  1. Data Management System – to create a set of templates that capture information from all sources in the business system. Utilizing the data management capabilities will require processes to be modified in such a way that the seemingly extra effort of entering information into the Data Management System is built-in. Policies need to be defined where no significant business event escapes the system undocumented. Ofcourse, the technical solution needs to be built in a way that minimizes the pain of having to enter all the information in the system, and be as easy-to-use as possible.
  2. Workflow Management System – The workflow management system will consist of a model that maps out various tasks and actions that are required to be performed in various scenarious. Policies are converted into rules, responsibilities, roles and permissions. The workflow model, the processes and policies may morph over a period of time, so as to minimize the learning curve for each person and resources.
  3. Network Integrated Solution – If the workflow involves significant interaction between multiple divisions of the enterprise that are geographically spread apart, then the technical solution and processes need to be suitably networked. Technology needs to be selected that makes databases and workflows across multiple locations seamless and transparent. Systems may need to be tuned and evolved based on the speed and availability of network. In addition, policies need to be defined for integrating external business partners such as suppliers, agents, distributors etc. Customers may also be provided the ability to directly hook in to the workflow of the enterprise, and participate in the solution design and delivery process.

Conclusion

We have seen how technology can use data, logic and networking to enable processes that are designed to deliver enhanced performance. We need to realize that processes and policies need to be re-defined or tuned to take proper advantage of a technological solution.

In the next part of this series, we shall investigate into what are the various options for choosing technologies that can serve an SME.

Posted in Affordable Technology, Evolving Enterprises, Workflow Management | Leave a comment

Sales performance tracking in solution-driven enterprises

Solution Sales Process

A solution-driven enterprise provides custom-built solutions to customers based on their requirements. Processes in a solution-driven company can be represented as follows:

Sales Processes in a solution driven enterprise
(see Sales Bottleneck in solution-driven enterprises)

Solution selling involves a time-consuming and resource-intensive needs analysis and solution design process.

Collaborative Sales

Collaborative Sales Model

The needs analysis and solution design is a collaborative process. The skills required for needs analysis and solution design may not be available in the sales person alone. The sales process is more like a project, with a team of other experts – such as design experts for understanding the specific application requirements and designing/configuring a solution, financial experts for estimating cost, sales managers to arrive at a appropriate sales strategy etc.

For example, take the case of a company that manufactures and sells modular furniture. The sales person interacts with prospects and when the lead becomes hot, gets a team in place involving an architectural consultant who analyses the structural aspects of the customer’s site, a design expert who works out a design that satisfies the aesthetic and ergonomic requirements, a fabric expert to suggest fabrics utilized etc.

The sale cannot be closed until the customer is satisfied with each aspect of the solution suggested – the architecture, design, fabric and ofcourse, price. Hence, the sale cannot be completely attributed to the sales person alone. The entire team is responsible for the sale closure.

In a product provider, all these skills are utilized during the product design stage which is done before the selling process begins. The sales person merely sells the product. Customer requirements are assumed to be standard, and the solution is in the form of a standard product. No major needs analysis is required, and there is seldom any design process involved during sales. Sales strategies are not tuned for every customer.

Also, in a solution provider, the responsibility of the sales person does not end with closing the sale. The sales person is involved in the entire order cycle, becoming the single-point contact between the customer and the company. In a product driven company, the sales person is seldom involved in order fulfilment.

Thus, the measurement of sales effectiveness of a solution sales person is far more complex than a product sales person.

Role based targets

In a product provider, the sales targets and incentives can be assigned and measured largely on the volume or value of product sales. This simple model does not work in a solution provider, because the sale cannot be completely attributed to the sales person alone. Being a collaborative process, each person who is part of the sales project has a role to play. Sales targets can be assigned to each member based on the role.

Role Based Targets For example, the diagram here shows two sales projects. The one on the left involves a design consultant and a sales person, while the one on the right is handled directly by the design consultant. Skills and resources may be pulled in as and when required for the particular sale.

In this example, the design consultant plays two different roles for the two sale projects shown.

Sales targets can be assigned to each sales project team member based on the roles played. In this example, the design consultant is expected to participate (as a design consultant) in sales projects amounting to a specified value or volume over a period of say a year. Similarly, the sales person has to participate (as a sales enabler) in sales projects amounting to a specified value or volume. The design consultant also has another target, of sales carried out directly by him by playing the role of a sales person.

This flexible model of assigning targets allows a solution-driven enterprise to completely and efficiently utilize available skillsets, by assigning sales responsibilities dynamically, based on actual requirements of the customer.

Assigning role-based sales targets

In the Reach1to1 Sales Activity Management System (SAMS), a role-based sales targets assignment system is provided.

The following table illustrates the process of assigning responsibilities (targets) to members of the sales team based on available skills.

Sales Team Member Role Product Category Sales Target
Priyesh Sales Person Enclosures 1000
Priyesh Design Consultant Active Equipment 2000
Kumaraswamy Sales Person Active Equipment 500
Kumaraswamy Sales Person Enclosures 500
Vinodkumar Sales Person Active Equipment 500
Vinodkumar Sales Person Enclosures 500

Tracking Sales Performance

Sales performance is tracked by measuring the actual projected revenue from projects in the sales pipeline, and the actual orders received against the target value or volume.

The following table illustrates the sales performance of a hypothetical sales team:

Sales Team Member Role Product Category Sales Target Projects in Pipeline Orders Closed
Priyesh Sales Person Enclosures 1000 100 25
Priyesh Design Consultant Active Equipment 2000 1000 250
Kumaraswamy Sales Person Active Equipment 500 125 55
Kumaraswamy Sales Person Enclosures 500 200 35
Vinodkumar Sales Person Active Equipment 500 150 25
Vinodkumar Sales Person Enclosures 500 220 65

Sample Sales Project using SAMS

The way it works in SAMS is illustrated in the following example:

  1. Anand Nair, the Sales Manager, sets the following targets for Vinodkumar and Priyesh who report to him. Priyesh is an expert on applications of Active Equipment, while Vinodkumar is a sales person. Priyesh is responsible for helping all sales persons like Vinodkumar to configure active equipment into the solutions they propose to their customers. Priyesh is also expected to directly approach customers and close sales for active equipment.
    Sales Team Member Role Product Category Sales Target
    Priyesh Sales Person Active Equipment 1000
    Priyesh Design Consultant Active Equipment 2000
    Vinodkumar Sales Person Active Equipment 500
    Vinodkumar Sales Person Enclosures 500
  2. Vinodkumar comes across a prospective customer, and starts a new project in SAMS. He requires help in designing a solution using active equipment, for which he pulls in Priyesh in the project team by assigning him the role of design consultant for active equipment.
  3. Vinod and Priyesh visit the customer together, and create a solution that includes both, enclosure products and active equipment as follows:
    Description Rate Quantity Amount
    Active Equipment 25 2 50
    Enclosure 50 2 100
    Total 150
  4. As soon as the expected revenue figures are entered in SAMS, the sales performance report is updated as follows:
    Sales Team Member Role Product Category Sales Target Projects in Pipeline Orders Closed
    Priyesh Sales Person Active Equipment 1000 0 0
    Priyesh Design Consultant Active Equipment 2000 50 0
    Vinodkumar Sales Person Active Equipment 500 50 0
    Vinodkumar Sales Person Enclosures 500 100 0
  5. After several further discussions with the customer, a final solution is proposed, based on which the customer places an order for the solution as follows:
    Description Rate Quantity Amount
    Active Equipment 25 3 75
    Enclosure 55 2 110
    Total 185
  6. As soon as the order is booked in SAMS by filling in the Order Intimation Form, the sales performance report is updated as follows:
    Sales Team Member Role Product Category Sales Target Projects in Pipeline Orders Closed
    Priyesh Sales Person Active Equipment 1000 0 0
    Priyesh Design Consultant Active Equipment 2000 0 75
    Vinodkumar Sales Person Active Equipment 500 0 75
    Vinodkumar Sales Person Enclosures 500 0 110

Summary and Conclusion

Solution sales is a collaborative process that involves skills that are available with different people in the company. By using a flexible, dynamic role-based target assignment and tracking process, the Sales Activity Management System (SAMS) can enable solution-driven enterprises to optimally utilize available skills and manage the solution sales process effectively.

Posted in Evolving Enterprises, Sales Activity Management, Workflow Management | Leave a comment

Why software projects fail – and how we make them work

Success / Failure Factors

Software projects are known to have a high level of failure. How high? The often referred study on software project failures, published by the Standish Group is called the CHAOS Report. It is a result of analyzing software projects in the US.

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

This quote from the report draws a dismal picture for software projects. Another interesting finding of the report are the factors and their relative importance in contributing to the success or failure of projects.

Project Challenged
Factors
% of Responses
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%

Software developers are aware of these factors. And the fact that the first three factors being beyond the direct control of the development team only proves that the often used – ‘not my fault’ excuse by developers for failed projects is not totally unfounded.

Development Methodology

The main factors for software development failure are lack of user involvement and incomplete or changing specifications. The reason these factors are so commonly attributed to failure of development projects is largely the development methodology used for most software projects. Conventional development methodology involves creating up-front systems analysis and specifications design of a project spanning a large number of features that require several man-months or man-years of development. Development is then carried out in an extended development cycle assuming that:

  • the specifications are clearly written
  • the interpretation of the specifications by the developers matches the user’s expectations
  • the expectations of users do not change during the development cycle

All these assumptions are highly unreliable. User involvement in such a project begins only after the development cycle is almost or entirely completed. This results in the inevitable ‘this is not what I meant/want’ response.

Agile / Adaptive Software Development Methodology

Software development methodologies have evolved in the last decade that incorporate:

  • close collaboration between the programmer team and business experts
  • face-to-face communication (as more efficient than written documentation)
  • frequent delivery of new deployable business value
  • tight, self-organizing teams and
  • design of code and development teams in a way that minimizes the risks of inevitable change in requirements.
    These Agile or Adaptive Software Development are now following in various forms such as Scrum, Crystal, XP (Extreme Programming), etc. and are based on the realization that building software is not like building an immovable asset such as a house or a bridge. Software is a movable asset in the sense that it needs to change over time and space. Software is a tool for humans. Humans change, requirements change and hence software needs to change not just a few times in the form of project or product upgrades, but continuously, as a process of evolution.

    The Agile Manifesto is a statement of shared development values crafted by various originators and practitioners of these agile methodologies:

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    That is, while there is value in the items on the right, we value the items on the left more.

    Reach1to1 Methodology

    At Reach1to1, we have adopted a methodology that is based on the agile manifesto.

    1. Development of Process Scenarios (User Stories)
      A Process Scenario or User Story is a description of tasks that are performed by users in typical scenarios while interacting with customers. The stories will also describe how the processes will be facilitated by the software. The stories will not describe the software in technical terms, database layouts or algorithms. They will use the language and terminologies normally used by users.

    2. Release Plan for entire project
      The release plan specifies which user stories are going to be implemented in which development cycle, and dates for those releases. The release plan is finalized together by the entire team.
      Also during the release plan, the infrastructure requirements are laid out in terms of the hardware, operating systems, other supporting software platforms etc.

    3. Small Release Cycles (as planned in the release plan)
      Development is carried out in several small cycles lasting not more than 4 to 6 weeks each. Each development cycle will involve:

      1. Scope Planning
      2. User Interface Prototype
      3. Software Development
      4. Unit and Functional Testing
      5. Installation on site
      6. User Feedback
      7. Fine Tuning as required

      The scope for each cycle will be planned in a way that it can be completed in not more than 4-6 weeks from the start, and the results are usable and testable by the users. Each week there shall be a review meeting of the entire team for assessing the progress of the cycle, and modifying the scope if necessary so as to ensure its completion on time, and with acceptable results.

      Scope plans for a new cycle are started only after the previous cycle is completed. This ensures that the clarity achieved by the users and developers are incorporated into the plan for the next cycle.

    Other principles that maximize project success

    In addition ot using an agile development methodology, Reach1to1 also uses the following principles:

    to build and deliver custom-built solutions that automate business processes in a way that maintains the high levels of flexibility, scalability and efficiency that is required especially by evolving enterprises.

Posted in Agile Development | 1 Comment

The sales bottle-neck in solution-driven enterprises

Solution-driven enterprises quickly recognize an opportunity in the form of a problem or a pain-point in the market, then design and deliver a solution. Every small company typically starts as a solution-driven enterprise. It starts with the promoter(s) having this innovative ability to recognize problems and design solutions.

Business Processs

The processes of a solution-driven enterprise can be represented in the following simple model:

Processes of Solution-driven enterprises

When the company is small, the promoter(s) carry out the needs analysis and solution design, while other employees take care of execution, delivery and support. With increasing number of success stories with early customers, the company grows by increasing resources required for execution, delivery and support. If the product involves manufacturing, then manufacturing capacity is increased. If it is a service, then more manpower is hired. However, the functions of needs analysis and solution design are not easy to scale up.

Conventionally, the function of needs analysis has been a part of sales. The terminology is borrowed from a product-driven enterprise model, in which marketing, sales, exectution and support can be almost independant functions. In solution-driven enterprises, the sales person does far more than converting leads into orders. The sales person is a partner, helping the customer figure out the needs, and design a solution to meet those needs.

In a small company, the sales is typically restricted to either the promoter(s) or some sales heroes. These solution-sellers are able to pick up the skills required for needs analysis and solution design. As long as the heroes are able to handle the demand in the market, the company continues to grow successfully. If all goes well, the demand grows too large to handle. Increasing the sales force with fresh talent is of limited value. The skills for needs analysis and solution design are not easy to learn. New sales persons add overheads without significantly increasing volumes and reduce profitability. This creates the sales bottleneck in a solution-driven enterprise.

The Sales Bottleneck

Bottleneck in solution-driven enterprises

To tackle the sales bottleneck problem, the enterprise usually goes through its first big strategic transformation. The analysis goes something like this:

  • The bottleneck to growth is the needs analysis and solution design
  • How can we eliminate this bottleneck?
  • Why not eliminate the needs analysis and solution design altogether?
  • Answer: Productize the solution!

The easiest way to remove the bottleneck is to eliminate the constrained processes. Productizing the solution involves standardizing the product or service, thereby eliminating the functions of needs analysis and solution design. Commonly occurring requirements are served by standard solutions, with a bit of customization. Only high-value customers are given the luxury or personal attention, by the scarce solution designers in the company. There is obviously some amount of compromise in the match of the actual needs of the normal customer and the standard solution. However, if the demand in the market is higher than the supply, companies grow successfully by standardizing the product. The enterprise slowly transform from a solution-driven enterprise to a product-driven enterprise.

If the company gets totally involved in this phase of growth and does not give enough attention to the growing gap between the problem and the solution, this gap leads to a new pain point that some new entreprenuer recognizes and uses to start a new cycle. This phenomenon of the downfall of large companies due to a lack of disrtuptive innovation is explored beautifully by Clayton Christensen in his best-seller The Innovator’s Dilemma:

Finding new applications and markets for these new products seems to be a capability that each of these firms exhibited once, upon entry, and then apparently lost. It was as if the leading firms were held captive by their customers, enabling attacking entrant firms to topple the incumbent industry leaders each time a disruptive technology emerged.

So how does a solution-driven enterprise scale up while retaining the solution-driven approach? How does one remove the bottleneck in sales?

Sales Activities

Let us look at the solution-designer’s problem. If we measure the actual amount of time spent by a solution-designer-sales-person in utilizing the scarce skills of needs analysis and solution design, it usually adds up to a small fraction of the total available time. We did a brief survey of solution-driven companies, and asked sales persons to list out the activities they did. Here is a sample of those activities:

  1. Customer contact activities
    • Lead generation & capture
    • Handle Customer enquiries
    • Prospects for new Customers
    • Customer Visits
    • Phone Calls
    • Correspondence
    • Customer entertainment
    • Outstation travel
    • Arrange customer visits to reference sites or execution units
    • Conduct demonstrations
    • Negotiations
    • Preparation of proposals and quotations
    • Cost benefit analysis
    • Comparison with competitors
  2. Solution design activities
    • Requirements capture
    • Preparation of case studies
    • Configuration/design of solution
    • Preparation of Layouts/ Drawings/ Sketches
    • Cost estimation
  3. Co-ordination and follow-up activities
    • Purchase Order follow-ups with customers
    • Order Booking
    • Co-ordination with distributors & agents
    • Co-ordination with execution/manufacturing unit
    • Order/Project Tracking
    • Quality Checking
    • Oversee Installation
    • Installation Bugs / Damage / Short Supply Handling
    • Payment follow-ups and reporting
    • Complaint Handling
  4. Administrative activities
    • Weekly sales activity plan
    • Attendance reporting
    • Collection reporting
    • Order documentation
    • Expenses reporting
    • Daily/ weekly/ monthly reporting
    • Sales forecast
    • Post sales analysis (Profit & Loss)
  5. Self-education activities
    • Keeping track of market know-how
    • Attending seminars, presentations and meetings
    • Attending exhibitions & road-shows
    • Monitoring competitor activity

As this list shows, there are several activities carried out by sales persons in a solution-driven enterprise that are not related to the scarce skill of needs analysis and solution design. However, all these activities are highly inter-dependant, and are therefore typically carried out by the same sales person.

Sales Activity Management

One outcome of the observation of solution-sales sales activities is to divide the activities into separate roles, with customer contact activities being handled by field sales persons, and solution-design activities being carried out by a sales support team that can interact with the field sales force as and when required.

That is where technology plays a part. A Sales Activity Management System (SAMS) can provide a platform for structured interaction between various sales functions carried out by different persons at multiple locations.

Sales Activity Management System

A Sales Activity Management System also has other benefits such as:

  • reduce the overhead of administrative activities by reducing manual data entry,
  • provide a common communication platform, where sales persons, sales support, order execution and support personnel can interact seamlessly
  • provide a single view of all customer interactions to all concerned persons within and outside the company
  • co-ordinate tasks between various persons working on a customer project
  • provide automatic reports and analysis of sales activities so as to highlight inefficiencies in the system as pointers to process improvement

Smart Customization

The first part of the solution is to manage sales activities by dividing the activities into separate roles, and co-ordinating the activities by using a Sales Activitiy Management System. This will surely open the sales bottleneck significantly. The next level of systematization is to provide a way to automate the solution-design process itself.

There are several strategies than may work in different situations:

  1. Rule-Based Solution Design
    In many cases, it is possible to create a rule-based solution-design system. Such a system represents the solution-design logic into a set of rules that are applied to a series of questions that are asked at each stage of the solution-design process, which breaks down the needs or requirements into a set of parameters. These parameters are then used to suggest parameteric solutions.

  2. Experience Database
    In other cases where the solution-design process cannot be broken into a parameteric rule set, it may be possible to create an experience database. The process of solution-design is done manually, but the requirements and the solution is stored in the experience database. If the same or similar requirements are encountered again, the sales support person can look up the experience database to see the solution provided before, and merely tweak the solution as required.

  3. Modular Solution Configuration
    In some cases, the solution can be broken into a set of modular components. In such cases, a solution configuration system can be designed that helps the solution designer to quickly pick up modules from the component database and create a solution to match the requirements.

Conclusion

Using systems such as the Sales Activity Management System and various strategies for smart customization, a solution-driven enterprise can grow without losing its agility, and retain its innovative edge as the market gets crowded with competitive solutions and products.

Posted in Evolving Enterprises, Sales Activity Management, Workflow Management | Leave a comment