It’s About Process (or the Ability to be Responsive) -- Part III

Part II of this blog series continued the introduction of the concepts of workflow automation and business process management (BPM). It also zoomed in on similarities and subtle differences between the two related software categories. Finally, the idea of on-demand workflow and/or BPM solutions was introduced.

To that end, Webcom Inc. has leveraged its vast expertise earned while addressing many complex sales quote-to-order (Q2O) process issues (i.e., channel quote approvals, special pricing approvals, special non-standard product feature request approvals, etc.) and has created a brand new workflow engine, which can be (and is already) used for many generic business processes.

Such examples of processes would be: RMA (Return Material/Merchandize Authorization), NFR (New Feature Request), ECN (Engineering Change Notice), NPR (New Product Release), Bug Tracking, Engineering Change Request, and many other business processes that require approval steps.

The Ability to Respond, On-demand

In May 2008, Webcom announced the availability of ResponsAbility, its newest offering addressing the case management and workflow processing areas. ResponsAbility is designed to speed the "time-to-resolution" process, eliminate unnecessary time delays and improve overall value chain communications and productivity through improved transparency and collaboration.

The idea behind this case management and workflow solution was to help organizations keep their projects on track and their employees on the same page, thereby making the lives of internal and external team members much less complicated (and more productive and enjoyable).

This straightforward application provides a central location (repository) for managing the key aspects of many types of cases, including product and service defects, customer and supplier complaints, non-conformance issues, health and safety incidents, and RMAs. Separate tabs keep key information within easy reach, whereby team members can log issues as they arise, prioritize them, and update their status as appropriate.

Built-in reports let users see open issues by project, projects by stage, and many other categories. On a proactive side, the tool can be leveraged by companies to create and implement corrective and preventive actions (CAPA) and to support a plethora of regulatory and compliance requirements. All in all, users that have always had the responsibility now have the “ability to respond”, as required.

This case management software may not currently have all the bells-and-whistles associated with full-fledged BPM packages, such as programmatically driving a workflow engine, visual process modeling, process monitoring and optimization, or automatic task allocation based on workload. Still, it seems well suited for small and medium size companies, who can leverage such a software tool with an intuitive user interface (UI), for handling many, if not all of their processes, in an incremental manner.

The design and enforcement of processes is enabled because both administrators and end-users are able to design workflows, notifications, and data collection forms, as well as setting up permissions accordingly. The system manages cases by ushering each case through the resolution process, and by tracking the progress of each case throughout the entire process.

The multi-tenant software as a service (SaaS) delivery model ensures that a customer can be up and running quickly with all of the selected critical processes being modeled and functional. No onsite deployment is necessary and the software only requires a Web browser and some modest to minimal data and process setup to be up and running.

Brethren Software Vendors as Likely ResponsAbility Users?

For example, a software development company can deploy this tool within a day or two and allow its customers to report bugs. This information can then be internally routed according to a customized workflow to the support department, then to the engineering and testing staff, and then back to the customer for approval and case closure.

To elaborate, the Software Bug workflow logically starts with the customer reporting a software bug. Then a default assignee at the software vendor reviews it, and then either resolves it on the spot (hopefully) or assigns it to the software engineering staff by providing a test case. Then the software engineering team determines a cause for the bug and either provides a workaround, fully fixes the bug, or determines that the software behaves as designed after all.

At the same time, ResponsAbility can be used to allow customers to create new feature requests, which are then routed via a different customized workflow starting from project management, via development, release scheduling, back to development, quality assurance (QA), documentation (technical writers), product management, and finally to marketing teams.

Again, if the bug can be fixed, the case is assigned to the testing staff, back to the support team, and finally back to the customer for approval and  case closure. But, if the issue turns out not to be the bug after all, the case is then converted to a new feature request and follows an entirely different workflow.

To that end, the New Product Feature Request process starts with customers, sales & service people, channels and/or product managers requesting a new feature. Often, the existing users (install base special interest groups [SIGs]) are allowed to vote on it, and based on the number of votes and other factors, some new features are assigned to the engineering department to estimate the effort entailed to implement the requested feature.

Based on the estimate and other criteria, some new features are then assigned to the engineering or research and development (R&D) departments for implementation. Upon implementation, the new feature is assigned to the QA department for testing and approvals. Finally, based on the QA results, a new feature is returned back to engineering for a rework or is scheduled for production (or general availability).

Apparently, various instances of a process (called cases) can be changed midstream. For example, something that was initially entered as a bug upon investigation may be classified as an expected behavior. The customer who did not expect such behavior from the software can then change a case type of this instance from a bug to a new feature request, without having to re-enter any information and this case will then follow the prescribed new feature workflow process.

Also, a built-in notification and permissions engine ensures that all communication and collaboration happens within ResponsAbility, so everybody is aware of anything that anybody ever stated about the case via comments, file attachments, etc.

Unlike some of the simple issue tracking software packages mentioned in Part II, ResponsAbility can be used not only for tracking things, but also for enforcing a process in order to ensure that things get done correctly. For example, a workflow engine can be set up to make sure that a process status cannot be changed from "bug fixed" to "in testing" until a concrete test case scenario is provided by a user via customizable online forms.

Webcom -- “Eating Own Dog Food”

It might be interesting to note that Webcom, as a software developer itself, has since late 2006 been using ResponsAbility internally for its older sibling WebSource CPQ product's bug tracking and new product features introduction.

The traditional model, whereby the dedicated product/project manager and support staff were the only bidirectional conduit between the client’s team (i.e., WebSource CPQ users and administrators, local project manager, application owners, stakeholders, etc.) and Webcom’s team (i.e., developers, modelers, QA, consultants, product managers, etc.), has over time been shown to have many disadvantages.

Namely, despite the dedicated project manager’s intimate knowledge of the individual client’s installation and the established relationship and hand-holding comfort level, the challenges have repeatedly been the bottleneck nature of the dedicated project management and support team, with no significant value being added by this additional layer of communication.

Other disadvantages would be the all too often “black hole” syndrome due to the lack of a single project/client/tasks/issues depository. Therefore, priorities are often managed on an inefficient (and often redundant or conflicting) one-to-one basis.

The advantages of the new support model, with ResponsAbility providing a single repository of all cases (in a hub-and-spoke manner), start with collaboration and the ability for all parties to both instantly contribute to the case/task/issue and have instant visibility into the case status. Also, new resources that include clients, Webcom employees and third-parties (partners) can all immediately participate and be notified, while the enabler for everyone is also an advanced searching capability within the system.

The Webcom Q2O clients’ adoption was initially somewhat tepid due to the ingrained human habit of emailing or calling directly the preferred contact or due to the clients having their own issue tracking systems. Of course, there is always the need for a human touch and chatting (as a “bonus”) with Webcom associates about the "critical" issues like a “lovely” winter weather in Wisconsin or about the Green Bay Packers' revival.

Nonetheless, joking apart, from the end of 2007 ResponsAbility has been the sole vehicle for communication, tracking and managing tasks and cases at Webcom. Prior to that, Webcom had used the JIRA issue tracking system, which at the time allowed users to create a workflow based on a set of offered statuses.

However, at the time (the things might have meanwhile changed though) there was not the user’s ability to create statuses and workflows at will. For instance, the offered statuses were “open,” “in progress,” “closed,” etc., but the user could not create a custom status like “material returned”, “in engineering”, “being analyzed” or so.

Further, users could add custom fields, but they could not design forms in a drag-and-drop fashion. There was no way to specify forms and fields for each action (task) either, so that, e.g., when the process passes from the “bug fixed” into the “in testing” phase, the user could not create a mandatory field named “test case.” While administrators had ample controls, the end users had very little control over what fields they could see on the screen, and so on.

Key ResponsAbility Design Tenets

In contrast, ResponsAbility was built with several design concepts in mind, starting with scalability in terms of users’ ability to create an unlimited number of cases, processes, statuses, status transitions, custom fields, users, user types, departments, etc.

There is also flexibility in terms of creating permissions (e.g., by project, by process, by custom fields, etc.) and the assigning of rules and permissions is visible system-wide. As for data flexibility, there are custom fields and forms and process-related fields and forms, while at each process point (step) fields can be assigned as read-only (viewable), editable, and/or required (mandatory). There is also a flexible definition of assignments, notifications, and recipients, whereby conditional actions drive implicit and explicit notifications.

Furthermore, the ease-of-use concept translates into hardly any training required, whereby the idea for the tool is to be perceived by users as their enabler for getting things done instead of an enforced mandatory tracking tool by the “ivory tower.” Some examples of the ease-of-use features are:

  • An intuitive drag-and-drop interface for administrators to design and preview online forms;

  • An instant system feedback regarding the field size, informing users how many characters they still have left or by how many characters they have exceeded the maximum field size, and all of this happens dynamically while they are still typing;

  • When looking at the list of cases, dragging a mouse over a case will bring additional fields in a hover (a so called “mouseover”), so that a user can find out more about each case while browsing a list, without having to open each case (thereby saving valuable time); and

  • Each list of cases can be customized (personalized) by users in order to show fields as columns based on what that user is interested in or what a user considers to be important. If, e.g., a case type has 100 fields, it is impractical to put them all as columns in a list of cases on the screen. It is also impossible to select 10 most important fields universally because their importance depends on individual user needs. Therefore, each user can determine (select), in a drag-and-drop manner, which fields are truly important for them.

Last but not least, the ease-of-setup tenet starts with a pre-built library of processes, but companies can certainly create their own processes with an intuitive and flexible setup of forms, workflows, notifications and permissions. In addition to the abovementioned advanced search capability, users have a facility of unlimited comments and uploading of attachments.

The administrator is able to create brand new processes, new fields and forms and to define the workflow(s) for new processes. He/she can define which field and when in the process is mandatory, visible, hidden and for whom. The administrator is also able to define who has access to which types of cases and projects, who can oversee which users, and so on.

It is thus small wonder that ResponsAbility has reportedly been deployed in only a few days at some customers including setting up processes, users, permissions, and import of legacy data.

Part IV of this blog series will continue to delve into the Webcom’s ResponsAbility on-demand workflow/BPM offering. In the meantime, your comments, thoughts, suggestions or individual experiences with workflow/BPM tools are more than welcome.
comments powered by Disqus