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!

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

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.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

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. Pay-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.

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.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

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.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

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.
    VinodkumarSales PersonActive Equipment500

    Sales Team Member Role Product Category Sales Target
    Priyesh Sales Person Active Equipment 1000
    Priyesh Design Consultant Active Equipment 2000
    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.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

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.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

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.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

Making LIMS Work

What is LIMS?

Laboratory Information Management Systems are specialized applications for laboratory automation that offer significant benefits:

  • Optimal utilization of laboratory resources
  • Reduction in manual operations and errors due to repeated data entry
  • Adherence to regulatory requirements
  • Standardization of procedures and enforcement during actual operation
  • Collaboration and sharing of laboratory information with other departments and customers
  • Automatic collation of test results into standard reports
  • Instant identification of anamolies and exceptions

Challenges in LIMS implementation

Several laboratories realize the need for installation of LIMS to automate the processes in the laboratory, but LIMS installations are not cheap, and certainly not easy. The main hurdles in LIMS implementations are:

  1. Wide vareity of testing equipment – Laboratories use a wide vareity of testing equipment such as pH meters, balances, spectrophometers, autoanalyzers, and chromatography data systems. In addition, specialized laboratories have testing equipment specific to the type of samples that are tested. Though most standard LIMS packages have built-in facilities for integration with most standard equipment, there is significant effort required to integrate LIMS with non-standard or non-computerized equipment.

    Based on our experience of studying LIMS requirements and solutions, we have a different view on handling this issue in LIMS installations. We have found that laboratory technicians, especially in smaller laboratories, are not overly bothered by having to record test results manually. In fact, we would venture to guess, that if a LIMS solution were to merely provide a mechanism to manually export data from computerized data loggers that are anyway used with most modern testing equipment, it would more than suffice the requirements of small and medium sized laboratories. As for those equipments that do not have any computerized data loggers, test readings anyway need to be recorded manually – in which case, the technicians can directly enter the data in the LIMS forms.

  2. Different operating procedures – each laboratory has its own operating procedure, based on the industry and nature of operations or tests carried out in the laboratory. The sequence of processes, data formats used to record test results, sources of information, formats of reports generated, everything changes from one laboratory to another. Standard LIMS packages do have facilities for customization or configuration to a certain extent. However, there is almost always a need to write custom code.

    As Colin Thurston, Senior LIMS Product Manager at Thermo Electron Corporation, in Altrincham, UK reports in Scientific Computing World – LIMS: WORKFLOWS

    In a typical LIMS, the sequence of work is broadly fixed, with no logic built into the sample lifecycle. Limited modifications are normally possible at each individual step, usually actioned by the system administrator. For example, changes in status of a sample such as ‘login’, ‘testing complete’, or ‘authorised’, would lead to different options being available to the user. Changing the sequence of events, or adding further logical branches (e.g. if . . . then . . . else nodes) to the sequence, usually requires the development of custom code, generally in the programming language of the LIMS. This can often be a proprietary language unique to that LIMS. Such customisation is not only complex and expensive, but it can lead to problems for the customer when upgrading or validating their LIMS. The consequence can be significant delays in going live. R&D and contract research laboratories handle many different types of analyses, so they need to be able to add or amend workflows quickly.

    One approach that is used by some LIMS providers such as Thermo Electron Corporation is to use workflow management technology to handle this burden of customization by providing graphical editors that can be used by the laboratory technicians themselves to customize the process at any time during the life cycle of LIMS.

    This is certainly a step in the right direction. As consultants for workflow management solutions, we completely identify with their vision in using workflow management to alleviate customization requirements. However, merely giving a graphical tool to edit process descriptions has its limitations.

    We have found that any workflow management solution that is purportedly easy to customize by using graphical process modelling requires significant skill enhancement of users. There is no doubt that simple process modifications are easy to handle in a graphical modelling tool. However, it is far easier to write a procedure in a programming language than using a graphical process representation, if a programmer is available when required, and if modifications to the process logic can be made on-the-fly.

    It is these two attributes :

    1. Availability of a programmer when required and
    2. Ability to modify workflow logic on-the-fly

    that makes a workflow solution successful. This is precisely the reason why we insist on LIMS, or any other workflow implementation as a software service and not a one-time product installation.

  3. Customization requirements during change in procedures or software upgrades – If a laboratory implements a standard LIMS package, but with significant amount of customization, the customized version may become incompatible with new upgrades of the LIMS package. As Thurston reports

    Upgrading will be complicated if there has been significant customisation. Is the code compatible with the new version of the LIMS? Do you have access to the people responsible for the code – contractors or in-house? If not, implementation services may need to be purchased, again, to re-implement the customisation. All this adds unwelcome complications to the upgrade process. And, of course, once re-implemented, the system needs to be revalidated.

    Having a LIMS customised this way also presents problems should there be changes to laboratory procedures. When changes to the mapped workflow are required, the client may have to re-program the LIMS. This may then entail revalidation of the affected subsystem.

    Again, this problem only occurs if LIMS is installed as a one-time package, and not when LIMS is treated as a software service.

  4. Integration with existing systems – Laboratories may already have some software systems and LIMS needs to be integrated with those systems. This integration is also case-specific, requiring additional efforts and cost.

    As Jason Simpson reports in Integration Of LIMS Offers Compelling Advantages For The Production Environment,

    Under increasing pressure to harmonize their business processes, science-based organizations are taking measures to standardize on computing applications such as Laboratory Information Management Systems (LIMS) and also to integrate these with enterprise platforms and systems. Often different locations within the same organization will employ information management systems from a variety of vendors for the same purpose. Industry mergers and acquisitions have only added to this diversity. For these reasons, it is no surprise that the standardization and integration of systems typically represents around 30% of IT budgets.

    Most standard LIMS packages have built-in facilities for integration with external systems using APIs (Application Programmers Interface). However, some LIMS packages like Thermo Electron Corporation’s SampleManager LIMS are beginning to use XML-based standard integration facilities, or Web Services to allow easier integration of LIMS with disparate systems.

    Our LIMS solution, offered as a completely Web based system, uses XML not only as a way to integrate data with external systems, but as a native object database technology.

Summary

LIMS can make a huge difference to the productivity of an R & D Laboratory. However, a standard LIMS package may not be the most suitable solution, due to the amount of ongoing customization required as is typical in an evolving enterprise – of which a Laboratory is a prime example.

However, if a LIMS solution is built and delivered as a software service by utilizing workflow modules as building blocks, with a scripting language that can be used for on-the-fly customization, evolution of the code can match changing requirements of the laboratory.

Also, creating LIMS as a web-based service, with a native object database to store and retrieve data, integration with other disparate software systems can be done with a minimal overhead and cost.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

Characteristics of Evolving Enterprises

Nicole Dunlop, Jadwiga Indulska and Kerry Raymond of the School of Computer Science and Electrical Engineering, University of Queensland, Australia have written a paper titled Dynamic Policy Management for Large Evolving Enterprises in which we found an interesting set of characteristcs of evolving enterprises :

  1. Scalability

    Due to the continually varying nature of the market within which enterprise operates, it is imperative that systems be scalable. Scalability refers to the ease with which a system can adapt to and accommodate increasingly complex requirements without the need for substantial changes to system structure or application algorithms.

    Some factors which have a direct impact on the level of scalability within distributed enterprise systems are, increasing user base, evolving and escalating functionality requirements, emerging distributed computing domains and heterogeneity of distributed computing domains.

    Our vision about how to achieve this scalability in systems for evolving enterprises:

    1. Component based architecture – for making code scalable
    2. Object databases – for making the database scalable
    3. Agile Development – for making the process of evolution scalable
  2. Rate of Change

    Evolving enterprises must be able to cope with the extraordinarily high rate of change ubiquitous in such environments. Including, merging distributed computing domains which often results in the introduction of new services and a need for heterogenous applications to co-operate.

    Web services with with a open XML based common language spoken between distributed computing domains is the ideal approach

  3. Trust

    Trust is essential for the efficient operation of large, evolving enterprises. Communities within an enterprise frequently recognise common organisational objectives and the members of those communities must typically exhibit a level of qualification, experience and responsibility in order to be included within the community. It is therefore reasonable that we allow those members to operate with a degree of independence deemed appropriate to their level of qualification and the nature of the actions they are performing in order to ensure efficient interactions within the enterprise.

    This is a pivot for the issue covered by the rest of the paper – how to determine policies in distributed computing environments so as to support dynamic roles, dynamic policies and the subsequent dynamic conflict analysis. Very interesting!

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0

Evolving Enterprises as Virtual Organisms

Cells, Organisms, Ecosystems

Virtual Cell
We consider our “self” as one single “individual”. But we are actually made of millions of individually self-sufficient units called cells. Similarly, we as individuals form a cell of one or more virtual organisms – such as our family or our business.

Virtual Organism
As compared to biological cells, we as cells of virtual organisms, are far more complex. Physical cells perform a fixed role in our body. The little toe on your left foot cannot suddenly feel like becoming the heart. But as virtual cells of virtual organisms, we are capable of transforming ourselves by playing different “roles” according to the “organism” that we happen to belong to from time to time.

For example, Joe plays the role of “Chief Developer” when he is in office. While going home in a crowded suburban train, he is playing the role of a “commuter” expected to behave in a certain way. Then he plays the role of a “husband and father” when he reaches home. And he’s the perfect “party animal” who cracks great jokes when he’s among his friends.

As children, we ape adults who play their roles, and as we grow up, learn to play our own roles as we begin recognizing the virtual organisms we belong to.

Virtual Ecosystem

And pushing the metaphor further, each such virtual organism is part of an even larger virtual organism such as an industry, state or country. A business organism learns to play a certain role in the industry, based on the particular “market”. The same business organism could play the role of a supplier, customer, investor, advisor, consultant, facilitator etc. based on the requirements of the “market”.

In this heirarchy, each higher level of organism functions as an “ecosystem” to the sub-organisms that it is composed of. For example, the business organism is the ecosystem to the employees functioning as organisms. An Industry is an ecosystem to the individual companies functioning as organisms.

Ecosystem <==> Organism <==> Cell

Virtual cells also differ in one more aspect from biological cells – they not only can change from one functional role to another, they can play these multiple roles simultaneously. Multiple virtual organisms can share the same virtual cells. The same Joe is simultaneously a “Chief Developer” and a “husband and father” – as can be illustrated when Joe gets a call in office from his daughter asking for a new toy. Joe does not stop being a “husband and father” when he is in office. He is always playing the roles that he has learned to play.

Similarly, business organisms simultaneously play the different roles they have learned to play.

Evolution

Evolution

Just as biological organisms evolve, so do virtual organisms. Evolution is a process of continuous adjustment that individual entities make so as to adapt to their surrounding system.

Charles Darwin invented the term “natural selection” – a process by which organisms best suited to their environment become the ones most likely to survive and leave descendants. The outcome of the process is an organism that is well adapted to its environment.

Virtual organisms follow exactly the same process of natural selection. The probability of survival of a business organism through evolution is directly proportional to its ability to adapt to its environment.

Reproduction

Evolution in biological organisms occurs via heredity – a natural outcome of reproduction. Evolution occurs by parent organisms reproducing and passing “winning traits” down to the offspring. “Traits” are codified in “genes”. In sexually reproducing organisms, the genes of both partners combine to form the genes of the offspring.

What is the metaphorical “reproduction” process in virtual organisms?

Let us define reproduction as the combination of “traits” of separate organisms to form new organisms that inherit the traits of the parent organisms.

What are “traits” in a virtual organism – especially a business organism? The closest parallel I can draw is the “skills” of the organization – ie the core strengths.

Then, reproduction in the context of a business organism, as per the above definition, would mean the process whereby two business organisms combine their “skills” to form new business organisms that inherit the traits of the parent organism.

Does reproduction occur in business organisms?

Businesses do collaborate, form joint ventures, form mergers, acquisitions, all of which combine traits of two or more business organisms to form new business organisms. But the frequency of occurrence of this type of reproduction in business ecosystems is far far less than its frequency in biological ecosystems, and is ridden with failures.

A merger or acquisition is an extremely stressful process for those involved: job losses, restructuring, and the imposition of a new corporate culture and identity can create uncertainty, anxiety and resentment among a company’s employees

– Appelbaum, Steven H., Gandell, Joy, Jobin, Francois, Proper, Shay, and Yortis, Harry (2000), “Anatomy of a merger: behavior of organizational factors and processes throughout the pre- during- post-stages”, Management Decision, Vol. 38, Numbers 9 and 10

Virtual Reproduction

Could it be that the reason business reproductions fail isbecause they do not have a well-defined mechanism to reproduce – to really stretch the metaphor – no “reproductive organs”? If reproduction were to become a norm among businesses, would it not make sense to define pre-determined ways in which business organisms can combine traits to form new organisms – virtual reproductive organs, so to say?

An interesting paradigm that seems to successfully spawn such dynamic combination of traits is the open source movement, which relies more on a person-to-person (1to1) trust network that is unstructured, undocumented, flexible and result-oriented.

In addition, with the networking tools available today – email, instant messaging, online forums, networking sites etc. the process of interaction between small virtual organisms for combining traits to form new virtual organisms could be far easier, faster and painless.

So what are we headed towards? Virtual Organisms that get created as and when required to fulfill any requirement or opportunity in the environment (market). These virtual organisms are formed by a reproductive process between small, specialized virtual organizations (traditional companies), or individuals.

Its unlikely that the decomposition of conventional business organizations will be stretched to an extent where only individuals with skills will combine to form virtual organisms whenever any requirement arises. The efficiencies of close, continuous interactions have their benefits, and there will always be a certain optimal size for each business organism within which components have fixed functions.

Conclusion

Evolution of business enterprises and biological systems seem to have many parallels. The most interesting of the parallels is the process of reproduction. Biological organisms have mastered the process with a magnificent result of a biologically diverse ecosystem. This has been facilitated by a highly efficient, and structured process of reproduction. Now, with the increasing collaborative capabilities of the Internet, enterprises are likely to evolve new models for collaborating with each other, similar to how biological organisms have mastered the process of combining genetic traits to form new organisms by reproduction. Paradigms such as the Open Source movement have proven that highly successful products can be created with dynamically structured teams of individuals working together in a loose structure. It will be interesting to see how this phenomenon evolves further to allow larger business units to combine dynamically and create virtual organizations that have the combined strengths of each component business unit.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0
Page 8 of 8« First...45678