Monday, October 25, 2010

Circle of change - CRM (1990 to 2010)


Change is expensive, disruptive, and often unpredictable. In the previous article in this series, we related rapid advances in technology fuelling new businesses and business processes and the consequent circle of change.

The picture below depicts how managed CRM became feasible with the advent of Database technologies in late 1980s. It helped automate management of several customer facing operations including support, sales, and marketing. Today CRM solutions are either delivered as a SAAS or are seamlessly integrated into enterprise applications using Service Oriented Architecture (SOA). The evolution of CRM business processes followed ground breaking changes in database, networking and computing technologies. A snapshot of this relationship is evident in the picture below.

crm

Some facts

Vantive, Clarify, Scopus and Remedy were one of the first CRM product vendors in early-mid 1990s. Vantive was acquired by PeopleSoft, which in turn was subsequently acquired by Oracle. Scopus was acquired by Siebel, which was subsequently acquired by Oracle. Clarify was acquired by Amdocs.

I worked for the core engineering team at Clarify from 1996 to 2007. Oracle, SAP, Microsoft are now leading vendors of CRM products.

Disruptive change #1: Client-Server to Internet

The first commercial-off-the-shelf CRM products were built using client-server (2-tier) architecture. Typically, the user-interface, database-interface, and business logic, which were implemented as static libraries in C/C++ programming language, constituted the client part of the application. The vendors of these applications focused their operational energies in supporting different combination of client platforms (Windows, Mac, Unix) and DB-server platforms (Sybase, Oracle, SQL).

Internet as a client platform was disruptive for these CRM vendors, as it put to waste a great deal of energy that went into supporting multiple client platforms. Vendors, like Siebel, who did not invest deeply in supporting multiple clients were able to transition to the internet platform faster than those who did.

Similarly businesses which did not invest deeply in customizing off the shelf products, found it easier to migrate to the newer versions.


clarify;

Migration challenges

Many businesses had liberally customized out of box features of the product by using the extension interfaces (VB scripts, custom metadata), and also added several of their own to fill the feature gaps.

Customizations could not be migrated to the new architecture. They had to be re-implemented in the new architecture.

Experience and skill-sets developed during prior customizations were not useful in the new architecture.

Many businesses chose not to upgrade and continued using the client-server version for a long time.

Architecture/Design Lessons – Clarify vs. Siebel

In retrospect, I realize that there were minor, yet fundamental differences between Clarify's and Siebel's product architecture. Siebel could win a substantial marketshare event though Clarify had early lead. Of course, at the next disruption point (SAAS), salesforce.com and new competitors beat Siebel at its game.


Siebel (early)

Clarify (early)

Supported only Windows client. Consequently its development processes were greatly simplified.


Supported multiple UI clients. Complexity of development and support increased many fold. The user interface was minimalist. Clarify subsequently moved to windows only client, but by then Siebel was focusing on other differentiators.


Invested in 3-tier architecture right from the beginning.


Was stuck with 2-tier architecture for a long time. Took a long time to see value in 3-tier architecture.


Provided metadata driven customizations. Migration of metadata was easy, than migration of code.


Clarify provided an integrated VBA (Visual Basic) engine. Customers were encouraged to write lots of custom-code in addition to creating metadata for customizations. Migrating custom code (automatically) to new architecture was later found impossible.


Downplayed customizations and insisted on usage of out of box features and simple customizations.


Showed ease of customizations as a key differentiator, and spent a lot of focus on getting the technology right.


Articulated technology attributes effectively as key differentiators – be it UI, active-synch, n-tier architecture, web-client or integration interfaces.


Even though Clarify had more successful deployments than Siebel, it was always playing a catch up on differentiators.

Amdocs-Clarify and its customers could smoothly tide over the second change-point, when the client framework was upgraded to smart-client. We had imbibed and incorporated the architectural lessons learnt during the first disruptive change.

Sunday, October 3, 2010

Circle of Change

Information Technology has evolved considerably over past few decades, and has contributed significantly to the value chain of businesses. However, in spite of significant improvements in software project management processes over the past several years, the percentage of failed and delayed IT implementations remains staggeringly high (68% as per the Standish Chaos report 2009). On the other hand, the average shelf life of an IT solution is shrinking, due to rapid advances in technology and pressures in adopting them for competitive advantage. Consequently, applications are found to be churning more than optimum resources in the maintenance phase of their lifecycles. A significant percentage of these resources are spent on ensuring seamless upgrades.

 

circle

advances

IT advances feeding into complexity of business processes

Example of IT advances over a timeline

 

Figure-1 above depicts a continuous cycle of rapid advances in technology causing changes in business processes, and business processes in-turn fuelling IT changes. For example, Java and Internet brought about significant changes in the way business was conducted. The consequent needs of businesses triggered new technologies such as SAAS, Cloud computing and SOA.

It is therefore an imperative for organizations to not only design IT solutions to address current business needs, but also to architect them for continuity in a constantly changing landscape. A rigorous architectural practice, along with well defined implementation governance plays a crucial role in achieving this goal. There are tens and hundreds of design best practices, reference architectural patterns, and architectural frameworks to address these needs. A mature architectural practice identifies the best design and architectural solution patterns in addition to addressing the functional and TTM (time to market) priorities of a business.

Thursday, December 3, 2009

Social CRM - Plausible Solution Model

Social CRM, per Paul Greenberg definition, is a philosophy & a business strategy, supported by a technology platform, business rules, workflow, processes & social characteristics, designed to engage the customer in a collaborative conversation in order to provide mutually beneficial value in a trusted & transparent business environment. It’s the company’s response to the customer’s ownership of the conversation.
While a great deal of work is in progress in identifying the business models and architecture artifacts for Social CRM, I present a plausible concept diagram, from a technology solution perspective.


The proposed model builds on existing traditional CRM solutions, and leverages "Corners Social Platform" for interfacing with all popular social networks and smart devices. Corners supports build once, and deploy anywhere (on any social network, device) paradigm. More than 1500 popular widgets / applications, built on Corners platform, are live on Facebook, Orkut, MySpace, Hi5 (and other social networks).

Monday, November 16, 2009

Business plan framework - "Who" is your customer

In the previous blog (part-1) "Framework for creating a Business Plan", I proposed an ontology (framework) to organize a business plan. In continuation of the previous article, we will examine how to structure information in the "who" column of the Business plan matrix.

Whats a business?

A business can be defined as an organization that provides goods and services to others who want or need them.

We can safely postulate that the most important "thing" for a business is its customers who "want or need" the product/service offered and "who will pay for the same". The identification and categorization of potential customers of a business is done in the "who" column of the business plan matrix. In this column, we also identify other key sets of people who are/will-be part of your business. For example - Partners, Employees, Suppliers, Board members etc.

Terminology and guidelines

Aritifact - An artifact is a work product such as a catalog (list of things), network diagram, a use-case specification, diagrams, a matrix, an office document, or even a hand written paper. Every cell in the business plan matrix contains one or more artifacts.

Lets now examine the artifcacts that go in the individual cells in "who" column of the business plan matrix. Each row is vantage point or perspective of the business that provides a different level of detail on the entities involved in the business. For example, If in the conceptual scope (row-2) you identified the need for a manager to run restaurant operations, in the execution scope you will list the qualifications of such manager and estimate salary ranges for different grades of experience.


Row-1 : Contextual Perspective
The cell in the first row is a reference perspective. Assume there are reference business plans spanning domains such as restaurant business, online portals, retail, online bookstore, training etc. These community contributed plans will serve as a starting point (reference) for anyone planning to start a business on similar model. For example, an "online music store" can use the "online bookstore" and "online portals" as references. The diagram below shows an example artifact for the restaurant business.


Reference - "Who" column for Restaurant business

Row 2: Conceptual Scope
This cell identifies all the sets of people who are likely to be involved with your business. The artifacts for this cell include -
  • A comprehensive list of potential customers of your business (ex: Corporate customers, retail customers, college students etc.)
  • A list of key employees/positions required to manage the business and to execute the business plan.
  • A list of potential partners (types of organizations that you can partner with)
  • A list of potential suppliers (or types of organizations that will serve your resource requirements)
  • List of potential board of directors of the organization.
  • List of venture funds who can bring strategic value to the business.

The artifacts for this cell are mostly documents with list of entries. These artifacts can be created as a list of handwritten papers, text documents, excel spreadsheets, schematic diagrams or even UML diagrams.

Note: If your product is a free web portal, then the users of your portal do not qualify to be categorized as customers, as they do not pay you for the services. However they are an integral part of your business plan. You can classify them as partners in the "who" column or as "assets" in the what column (explained in a subsequent article).

Row 3: Planning scope
In this cell you identify the attributes of the key people involved with your business. The attributes to be identified are those that are important to your business. For example, if your business is about online-dating, then attributes such as age, sex, demographics are important identifiers of your customers - you are likely to segment your customers as college students, single male, single female, metropolitan etc.

The following set of documents are likely to be created as artifacts for this cell -
  • Divide your target customers into all possible segments (artifacts can be UML diagrams, text document, excel sheet or hand written)
  • Identify attributes of the key employees of the business (example - experienced software architect, hotel management graduate, Management graduates from reputed business schools). This could be an UML diagram, or an office document.
  • Identify 3-4 key partners and explain the value they bring to the business. If you cannot identify any names, attempt to list down attributes of potential partners (example - Reputed 5-star hotels, can provide access to high networth indiviiduals)
  • Identify key suppliers for each type of resource you will require.
  • If you have a large list of potential board members, business partners, create 2-3 best combinations that will enhance the value of the business.

By now you might have realized that filling the cells is an iterative process whereby you are likely to visit each cell several times or create several versions of the matrix before you have it all mapped out. Here is an example artifact identifying key employees/divisions for an online-dating portal business.

Row 4: Execution scope
In this cell you organize information from your virtual and real execution of your preliminary plans. For example, notes from the discussion you had with a potential supplier or partner or list of the salary ranges for the key employees (based on your research in the employee market). This information will help you fine-tune your planning. For example, if you realize that salaries for hotel management graduates are beyond your budget, you can change your plans to hire diploma holders instead for your restaurant business. The following set of documents are likely artifacts for this cell.
  • Potential market size for each customer segment identified in planning phase. The artifacts here include summary excel sheet along with references to market research document.
  • Market salary ranges for the key employees identified.
  • Notes of discussions with potential partners, suppliers.

Row 5: Competition scope
  • Identify the customer segments being served by your competitors.
  • Identify the organization structure of your competitors (this serves as a reference)
  • Identify suppliers, partners of your competitors.
  • Identify the board members and the value they bring to the business.
  • Identify the funding sources of your competitors.
Identifying and listing out important attributes of competition is a key step. It helps you not only in expediting your planning process, but also in improving your marketing pitch.

to be continued...

Tuesday, November 10, 2009

Framework for creating a (real) Business Plan

Recently I was looking for some help (guide, tool or template) for documenting a business idea, related market opportunities and other details to create a comprehensive business plan. The templates and guides I managed to find on the internet, were about creating (executive) business-plans targeted towards venture-fund audience. But I was not thinking about funding yet (venture or my own). I wanted to organize my thoughts around a business idea and iteratively improve them. Finally I devised my own methodology (framework) which I present here.

In this article, I propose a framework for systematically organizing information required and related to converting an idea into a business plan - A framework to create a real “plan” for a business idea.

A framework can be defined as a logical structure that organizes for a specific subject, a set of related artifacts, shows the relation of the artifacts of the chosen subject area, and brings a totality perspective to hitherto individual ideas. A framework, therefore makes, the unorganized, organized and coherent.

A framework that helps structure and organize a business plan should have the following characteristics.
  1. It should provide a structure for organizing information that defines the scope of the business and how the areas of business relate to each other.
  2. It should help in comprehensive and impassionate analysis of the idea as an investment opportunity.
  3. Help prioritize and identify your core competencies enabling you to assign key resources to critical needs first.
  4. Help identify and mitigate potential risks in your selected paths of action and investment.
  5. It should help in clearly identifying and segmenting the market opportunity
  6. Guide in estimating the investment required to start and sustain the business.
  7. A summary extracted from such framework should serve as an executive business plan for venture funds.
  8. Finally, the framework should be easy to understand and use, and should not require knowledge/usage any specific tool(s).
The Business Planning Framework (BPF) I propose is inspired by the Zachman Enterprise architecture framework, which in turn is inspired by the descriptive representations(the architecture) of buildings, aeroplanes and other complex industrial products.
The BPF is a classification schema, represented visually as a table of columns and rows. Each row represents a distinct view of the business, from a unique audience perspective. A row is allocated to each of the following audiences
  • Theorists - Generic/Reference contextual view of the business
  • Owner / Funder - Has a conceptual view of business and its processes
  • Planner - Strategic view of the business
  • Executor - Nuts and bolts view of the business
  • Competition - A perpsective and analysis of competition
The columns of the framework consist of six functional areas best described by a set of interrogative questions –
  • What – The product / service that constitutes the idea
  • How – Strategies for running the business
  • Where – Location of the business and its related entities
  • Who – People; customers, partners, executive team and employees
  • When – Schedule of important events from pre-inception to succesful running of business
  • Why – Motivation for the business. The customer pain points your business addresses. The cost your customer will be willing to pay you for the product/service.
What
How
Where
Who
When
Why
Contextual Scope
eg: List of products and services.
List of processes the business performs.
Types of locations.
List customer segment, org. structure...
typical lifecycle of business.
goals and strategies of the business.
Reference model
Conceptual Scope
brief desc. of idea
Overview of core business processes. eg: marketing
list ideal locations.
Potential customers, partners. list founding team members.
high level schedule plan.
Identify the customer pain points that this business will address.
Owners / Investors
Planning
Detailed Product / Service specification. eg: Entity-Rel, workflow diagrams.
eg; marketing strategy, essential partnerships.
location and logistics
Segment your customers (ex: by age). org structure for development/delivery.
Master schedule
ex: identify each pain point and
Business Planners
Execution
eg: phased development, agile methodologies.
ex: Business process models for core business functions.
Systems, Hardware
ex: Identify the market size for each segment (numbers and purchasing power), class diagram for detailed org-structure
Component schedule
Cost structure for each service type (per customer), and profit after expenses.
Operations and Management
Competition
List competitors and their product/service. (ex: GAP analysis comparison)
List marketing strategies, business processes of competitors.
Locations charecterstics of competitors
Document the customer segment catered by competition (eg: GAP analysis). List the executive team, partners and venture funds.
ex: Important events in competition since inception.
Customer pain points addressed by competition and the price charged by competition for it.
Competition Perspective
Description
Strategy
Location
People (clients/providers)
Schedule
Motivation

BPF process summary
I will follow up with a series of blogs explaining each of the rows, columns, and cells in this ontology. Lets briefly examine some concepts here -
Whats inside a cell - Each cell in this matrix contains one or more artifacts. An artifact is a work product such as a network diagram, a use-case specification, a a catalog (list of things), diagrams, or even matrices. For example, a class diagram describes the organization structure, or a GAP-analysis document is part of competition scope.
Iterative process - Planning a business is an iterative process. As you continue organizing your ideas systematically, you may run into new ideas, plans and dependencies. You will perhaps go back to a cell multiple times till you get it right.
Mistake focussing only on column-1 - Without an organized plan several of us focus only on the product-design and service-delivery planning (which constitutes only 5 cells in column-1). This is mostly true for those in software development and services field. As we can now relate, a business-plan constitutes 25 cells of information gathering and analysis. Focussing only on 5 cells (in column-1) is a recipe for disaster. With more insight (from 20 other cells), your plan is more prabable to succeed.
Contextual Scope (Row1) - This is a contextual/referential representation of the business. Example-For a generic "dating portal" business, the "who" cell (column-4, row-1) will include "single men/women". Similarly the "who" cell for a generic "restaurant" business will include "customers, suppliers, employees and partners".

Next Steps


I will appreciate any feedback to improve this framework. If you want to work with me on this task, please email me at sanjeev(at)corners(dot)in.

Apart from completing the blog series I intend to do the following over a time period -
  • Create reference contexts (row1) for some common scenarios such as Restaurant business, dating portal, offshore software development service
  • Define in necessary detail, a methodology to fill each of the 30 cells - through example artifacts such as ER diagrams, documents
  • Identify open-source tools that can help in creating different artifacts
  • Create an open-source project to store reference plans
  • If time and resources permit, create an Eclipse based EPF project to automate the steps

Thursday, October 15, 2009

Facebook.createApplication API - a great utility for developers

Facebook has recently released the Create Application API to make integration of websites with Facebook more easy and seamless. With Create Application API, the process of creating Facebook applications can be automated. Thus a website can provide easy interfaces for the visitors to encapsulate interesting content into interactive facebook applications. Here is an example on how useful this API really is -Corners enables users to encapsulate a collection of videos, pictures, events, expressions, opinions on any given topic into a facebook application. Currently users have to go through a manual process of collating information from the Facebook application to Corners Application. With the Create Application API, any user can create a rich fully functional Facebook application with just one mouse-click. However, the API does not seem to be complete yet to be really of any significant use. The API contains two variation of a createApplication method - This method creates an application with a given name and assigns it an application id, app-key and authentication secret values. However, other application settings are left empty. It will be really useful if this method is complemented with API to get/set other application settings programmatically.

Thursday, September 17, 2009

A new facebook application from Corners

Corners is readying a new facebook application called 'repartee' for release in a day or two. Try it out. This application uses advance facebook integration API - streams API and notifications API. The application is a simple fun game involving friends, where friends tease each other, repartee (quick reply), and exchange comments on teasers involving common friends. The application uses Facebook Stream API to publish every "teaser" action on a wall feed. When a teaser is sent, it is published to the friends wall as a feed. When the reciever replies to this feed, the reply is logged as a comment to the original feed. Similarly when common friends (of sender and reciever) comment on the teaser, the comments get logged to the original feed. Facebook notifications API helped us solve a technically difficult problem, which was related to privacy of exchanges between friends. Below is a brief description of the problem and how we solved it. Problem Statement 1. A teaser should be accessible to the sender of the teaser and the reciever from inside the application. 2. A teaser should be accessible to common friends of sender and reciever from inside the application. This is to enable friends to comment on the teaser and make it more interesting. Technical challenge Assume a user "John" logs into the application. Presenting the teasers sent or recieved by him is easy as this information is logged in Corners database. Presenting teasers involving friends of John would require us to get a list of ids of John's friends (using Facebook API), and query for teasers sent and recieved by those ids (in Corners database). This would be an expensive query. Facebook notifications API came to our rescue. Every action on a teaser is sent as a facebook notification to the sender, reciever and their common friends. These facebook notifications are now available to applications through Notifications API. When John logs into our application, we present him with the list of notifications from this application. Each notification contains a link to the teaser that originated the notification. Try teaser application and discover how we used facebook API to convert a simple exchange of information into a social game.