Platform
Features
System Requirements
Architecture
The Power of Process
Click for Contextware Demo

Business process is the glue that connects
people with information.

Contextware technology is simply and elegantly the convergence of business process logic with content categorization — we use business processes to create a framework for categorizing information, then use the same processes as literal interface for retrieving information. However, something interesting happened as we rolled out Contextware to early adopters — the simple notion of retrieving content within context turns out to have a major impact on the entire organization, functionally and culturally.

Why is our approach better? Because businesses are really nothing but transactions — they produce things, goods and services, for less than the market will bear.

Transactions are business processes in action. In fact, we have heard several customers proclaim to us, "We don't have any processes." Of course they do, they must. But what they don't have is any coherent idea of what those processes are, much less what they should be. That's where we can help, quickly and easily.

Perhaps the biggest challenge to us in creating our technology was building the interface. Since business processes are the engine, we had to have a way to capture the process data from the subject matter experts (generally done with consultants). Instead of taking the easy route, and creating a drag and drop flow visualization toolset (the standard approach in most software, but complex and confusing), we did it the hard way — we embedded a business process toolset into the code and user interface of our software, so you don't need to know process "thinking."

You just need to know what your job, and Contextware does the rest. Oh, and you need a lot less consulting as well.

Is Contextware a process modeling tool?  

Part of it certainly is. But it doesn't look like any modeling tool you have ever seen before. The challenge to us was to build an interface that motivated users think about what they do (their processes) then document it without realizing they were modeling a process. Why? Because most process modeling tools are hard to use and intimidating, and result in graphics and flows that look like electronics schematics.

A brief history: process modeling was developed as a way to look at an organization and break it down to a useful level that identified data types ("employee" consists of "potential employee," "new employee," "ex-employee," etc). Then a "data model" could be designed, which would become the foundation for a database schema. Along the way, many people realized the more complex and baffling this process became, the more they could charge their clients.

The conceptual leap we made was to bring the process model back into play as an interface to the data (or information) so that information retrieval is done from within a familiar organizational context. Our software also holds management consultants accountable — by putting their "to be" models into it, you can very quickly see how your employees interact with the process, validating (or not) the consultant's value. And instead of bringing back the consultant each time your processes change (which they must) you can modify and evolve the processes on your own. 

Why is it so important to "validate" my processes?

Because what you think your employees do and what they actually do, surprisingly, may not be the same thing. If your organization is large enough to care about process, then you're too large for one person can manage all aspects and all details of your business. So even though you may capture what you think are critical processes, your employees will show you otherwise. Our software lets you analyze user actions by capturing frequency of interaction between users and activities, topics and content, and lets you aggregate that data so you can view trends over time. It also lets you track individuals as they interact with every single activity within a process.

The understanding gained from this feedback gives you critical insight into reengineering your processes to make them more useful and usable, all in real time. Each change you make is seen the very next time a user logs onto the system.

This aspect offers an important benefit for businesses and government agencies who have spent considerable amounts on process consultants whose ultimate deliverables consisted of a "to be" process delivered in a three ring binder. Previously, implementing improved processes consisted of training sessions, manuals and then more training sessions, generally resulting in a low rate of adoption. We provide a Web-based, interactive, organic environment for information retrieval via a process interface. To the end user, the fact they are interacting with a process is secondary to the fact they find the right information quickly and easily. 

Why does Contextware have a methodology "embedded" in it?

Our proven methodology helps you think "better", that is, think clearly and thoroughly through the many dimensions of your business activities.

The methodology enforces consistency of data capture, which enables scalability and organizational evolution. Most similar software is "hard coded" for an industry or functionally-specific process, and allows minimal modification ("do it our way because we know best"). Our software can capture any process at any level, then grow left, right, up or down, and still minimize redundancy by sharing the same relevant information throughout all the processes, greatly increasing the usefulness of the system across an entire business or many businesses.

The methodology is embedded at both the code and interface levels, so that users are only allowed to make certain choices — they cannot make "bad" decisions, and are warned of the consequences of poor decisions. Visual cues also reinforce the logic where rules may sometimes need to be broken, but generally shouldn't. As a result, we provide layers of understanding so that if users so choose, they can develop a rich comprehension of not just "what" but "why." 

What is Contextware's magical methodology?

The embedded methodology in our technology is evolved from a modeling language developed in the 1970s by the U.S. Air Force called Integrated Definition Language, or IDEF. The US Government invested over $100 million to develop it. Originally there were two versions, IDEF0 and IDEF1X, IDEF0 being for process modeling, IDEF1X for data modeling (there are numerous more variations today, none worthy of discussion). IDEF was initially applied in process-intensive environments like manufacturing and the Department of Defense then became popular with corporate management consultants. It began to fall out of vogue in the mid 90's as it was too poorly used too widely, and does have weaknesses, especially in the software development environment (object oriented being preferable to IDEF — however, while OO is fine for focusing on components, it fails when applied to the whole (as in whole organization, as in process) — it simply becomes too complex too rapidly). But today, post Bubble, process modeling and IDEF both are being rediscovered by companies seeking a better understanding of how to operate.

IDEF0 was selected for Contextware's engine as it is one of the few methodologies that provide a rich "system" view of a process, meaning it captures the many dimensions of the process. It is hierarchical (as are processes) and has just a few important, "hard" rules, but many "soft" ones for guidance. A key benefit is that it not only decomposes processes but that it also maps the changing relationships of information as the hierarchy decomposes, so as the process becomes more granular and precise so does the relevant information. We've evolved the methodology to more fully take advantage of electronic media, freeing IDEF from its tradition boxes and arrows interface (which limited information relationships of the model to the four sides of a box) as well as developed a system-wide concept of a topic hierarchy that is shared across processes, thus freeing the modeler to capture processes in a way that is most meaningful to them while minimizing redundancy of topics/assets across the organization.

IDEF is the only process modeling methodology that is a government standard, covered by a Federal Information Processing Standard (or FIPS, IDEF is FIPS 183). The standard is maintained today by IEEE as 1320.1-1998 "Standard for Functional Modeling Language." Simply put, IDEF users cannot be held hostage by vendors selling proprietary solutions and technology, nor can they be sold a bill of goods that may never be delivered (see BPML). 




© 2001- Contextware, Inc.