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.
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.
No comments:
Post a Comment