What's important to the business?
Analysts, and the solutions they present, have far-reaching influence within an organization. The information and solutions for the design of a system provided by an analyst may be the only basis on which the organization's stakeholders will make their decisions. The impact of a system on an organization tends to be measured by the most easily discernible factors, such as the cost of building and maintaining a system. Other influences are more esoteric, and they tend to emerge only after a solution has been adopted. The following list summarizes the types of impact a solution will have on an organization.
Financial: If there is a single perspective that shapes all businesses, it is money. For any solution, one of the first questions will be, "How much will it cost?". In some cases, this may be the only question asked by your stakeholders. In most enterprises, IT systems are seen only as a cost, and not as a competitive advantage or differentiator. Other financial questions will be along similar lines such as: "how will it save us money?"; "how will we make money from this?".
Operational: Usually the most influential perspective after Finance is that of Operations. Organizations are built and shaped around how they do their work, and operational processes are the strongest reflection of this. Typically some of the questions will be: "how will this make things more efficient?"; "how will it build customer loyalty"; "how will it lead to better employee satisfaction?". Operational questions tend to be tactical in nature, and usually focus on the shorter-term goals of an organization. If you are designing a system for internal use, the operational perspective will be the most important after the financial perspective.
Strategic: Some of the benefits of a solution may not be realized immediately, but contribute towards the organization's longer-term goals. Some of these questions will be: "how will this contribute towards of our goal of being a market leader?"; "how will this shape the way the brand is perceived in the market?". If you are designing a system for external use, such as customers, the strategic perspective will be of equal or of more importance than the operational perspective.
Cultural: Any solution, whether it is internal or external, will have significant impact on organizational culture. Organizational culture is rarely translated into tangible artifacts. This makes it difficult for an analyst to judge a solution's fit with an organization's culture. An organization's culture can be quantified in terms of what it values, and these values can help determine a solution's fit with existing ways of working. Even the simplest of features can have far-reaching cultural impact. Let's consider the example of a timesheeting application, a business application common to most organizations. Users of the application will enter a task they performed, and the duration they required to complete the task. The task can be linked to a broader collection of tasks, such as a project. The duration is defined by a start and end time. In the pursuit of designing a very flexible system, it is possible to design a system where tasks can be broken down to the most granular and minute of tasks. Similarly, it is possible to design a system where time can be entered in months, days, hours, or minutes. In a large enterprise, where the users of the system are far removed from the designers of the system, such a design may induce profound cultural change. Not every solution is accompanied by clear intentions and goals, so it might be left to a middle manager how best to use such a tool. A middle manager with strong micro-management values might feel compelled to demonstrate his or her effectiveness as a manager by asking people to constantly log every task they perform, and to account for every minute of their working day. Another different middle manager may value productivity over timekeeping, and will ask employees only to log tasks that take a day or more to complete. The flexibility of a system will result, in this case, to inconsistent results, to the extent that pockets of different organizational culture will emerge. The inability of an analyst to take account organizational culture results, in this case, in a fragmented culture.
Understanding Business Values
Understanding what is important to a business, or business values, is a fundamental pre-requisite in system design. The smaller the business, the easier it is to extract these business values. In a small business, the personal collection of values (value set) of an individual is likely to become business's value set. An organization is essentially a group of people, and it's easy to extract business values from a group that chose to work together in an organization for similar reasons.
A larger businesses, with several departments, can be seen as consisting of several different types of groups, each with different values and goals. The goals of a financial administrator in one organization may be to reduce cost as much as possible. The goal of a welder in the same organization may be to produce the best welding jobs in the industry, which may be in direct conflict with the financial administrator's goals to reduce costs. If the business were a small one, focused on only providing welding services, the goals of the welder should probably be considered the organization's goals. If the welder works in an automobile assembly plant, and is only one of several types of workers, then the goal of producing the best welding jobs irrespective of cost will only be realized if it can be mapped to the organization's goals.
Personal values are an intrinsic part of an individual, and they usually influence the decisions individuals make in their roles outside the workplace. For instance, the product choices we make as consumers are a good reflection of what we value. Given the same budget, different people will choose to buy different cars or mobile phones. A high-income single male (male yuppie) may choose to buy a BMW convertible, while a family man with the same income may choose to buy an MPV. In the case of the male yuppie, there isn't much rationalization required about buying the BMW convertible. He need not stop to think about his core values, and make a decision based on rationale. He can simply buy the car because it makes him feel good. When the male yuppie becomes a family man, he will need to think about the needs of others in the family. His wife and children may have other values than his own, and the family car should be a reflection of those values. He may value performance, his wife may value fuel economy, and his children may value the amount of room in the car. The yuppie could also just choose to ignore the values of others in the family and buy a convertible, but that would constitute placing his own values before others in the family.
Fig.1: The choices we make as consumers for cars and phones are usually a reflection of our individual values
Similarly, the designer of a system must understand an organization's values, and ensure that a system reflects those values. If the designer does not attempt to understand an organization's values, the resulting application will end up reflecting the values of the people that directly influence the designer. If the designer does not attempt to understand values at all, either an organization's or that of other people, the application will probably end up reflecting the designer's personal values. The designer may not even be conscious of the imposition of personal values upon the organization, but the consequence will be that the system will not be useful for the organization.
Fortunately, it is possible to obtain some consensus on an enterprise application's characteristics quite easily. These are that the system should be scaleable (adding more users to the system should not impede performance), responsive (system actions should be carried out promptly), extensible (adding new functionality should be easy), stable (the system should be highly-available), and integration-capable (the system is able to talk to other enterprise applications). Usually these characteristics should be a part of any enterprise application, so it really isn't useful to bring them into a value analysis.
The fundamental differences of opinion tend to occur on the functionality of the system itself. How much functionality should a system have? Let's consider a system with extensive functional features. If the extent of functionality provided by a system directly translates into value, then this is certainly useful. On the other hand, each additional functional feature means that the complexity of the system increases.
This results in additional costs for development, integration, testing, training, and organizational coordination. On the other hand, let's consider a system that only provides 20% of the functionality that is used 80% of the time. This results in a system that is easier to maintain, with significantly lower costs for development, integration, testing, training, and coordination. However, as it is a "barebones" system that doesn't have 80% of the functionality used 20% of the time, it may lack some useful features that users may occasionally require.
Fig.2: Mapping the different opinions on the required functionality of a system
Another point of difference is the level of moderation required for users in a system. Should users be allowed to do whatever they want, or should there be strict controls on the users? This issue is a fundamental decision for the design of a system. Take for instance the requirement to have a text field to describe a product. If users are allowed to do whatever they want, then the text field will be designed with rich text support, and users can enter an unlimited amount of content. This approach places complete trust with the user, and puts them in a situation where they can best judge how to structure and format the content. This approach will also result in inconsistent results. If strict controls are required, then there will be multiple fields, each with strict requirements for the type and amount of content that can be entered. This approach will result in an application that is much harder to use, will require more development, testing, and user documentation (help), but it will produce consistent results.
Usually, there won't be a clear-cut answer on either of these questions, and different people will have different opinions. The basic questions essentially amount to the following.
1) What is the extent of functionality required by a system?
2) What level of moderation is required for users of the system?
If you are unable to obtain consensus on the necessary level of moderation and extent of required functionality, a good point of reference would be the organization's broader goals. These may be stated explicitly in the company's mission statement or corporate values. If this is unavailable, they can be gauged from the organization's primary goals. Retail banks are primarily responsible for ensuring that the money of depositors is managed securely.
Fig.3: An un-moderated (left) and moderated (right) application screen for the same functionality (a text description for a product)
Logistics companies are primarily responsible for delivering packages. Shops are primarily geared around selling merchandize. In each of these businesses, there can be several other goals, but the primary goal of the company can usually be extracted from its core business.
If you are designing a banking application for use by internal staff, it will have to contain a lot of moderation-oriented logic. If you are designing a consumer oriented application for a retail bank, such as an online banking application, you have the challenge of finding the right balance between utility and moderation, so that users find the online banking application useful, but cannot use it to violate strict banking regulations. No matter what kind of application you build in the banking domain, moderation will remain a primary driver of functionality. Similarly, the value of a logistics application can be judged by the extent to which it increases efficiencies in the booking, pick-up, transportation, and delivery process. The value of a webshop can be judged by the extent to which it increases sales.
In conclusion, spend some time trying to understand the core values of the organization before designing anything. A good understanding of a business's values will become your compass in deciding the functionality required by the system.
Situation trumps Values
Values are a useful reference to shape application functionality, but specific situations will often trump values. An organization that generally values flexibility will probably require some inflexible functionality. For instance, a logistics company may require an application usable by several customers with different processes. To obtain flexibility, the company may decide to keep only the parts of the process that are common to all of the customers within the application, and the parts of the process that are different are managed by human operators. Flexibility is achieved through training and instructing staff, who are aware of the broad range of requirements by the different customers. However, specific customers will have different legal (e.g. transaction archiving) and financial (e.g. logging all billable events) which will require the introduction of customer-specific functionality into the application. This will reduce the flexibility of the system, and may be in direct conflict with the organization's values, but the customer-specific logic will still be required.
Similarly, there are situations when a company that values controls will have to exhibit flexibility. A bank, which values strict controls, can have very detailed processes that are unique to itself. These processes are reflected in internal applications, and new employees at the bank will receive training to orient themselves on functionality that isn't intuitive or universal. However, for consumer-oriented applications provided by the same bank, such as Internet banking, it will have to abandon its strict internal controls and processes in favour of the flexibility demanded by consumers. A consumer-oriented application will still display some of the bank's values that consumers also value, such as security controls, while other functionality for transferring money between accounts will need to be lot more intuitive than internal applications.
