Many service calls, customer complaints, or plain purchasing functions have one common structure. They all follow a specific life cycle:
- creation of the request
- review and analysis of the request
- resolution of the request
- final approval of the request
- closeout of the request
|  |
A request (or a complaint, a requisition, or a claim) is initiated by a user. It typically gets analyzed. It may get rejected or accepted to be worked on.
Estimates and detail documents may be generated to proceed to the next level. The reviewer may add his/her own notes and attachments as well.
The resolution of the issue involves assigning the detailed tasks to various resources. Time, manpower as well as other tangible resources expended are tagged to the request during the course of the resolution process.
|  |
The department responsible for resolving the task, normally creates a project to handle it. It is possible that one project may handle several such requests. Time and resources expended are kept track of.
Once the project is completed, the work has to be tested and approved. This process is typically the QA step. The testing and acceptance can result in rejection or rework.
The final closeout of the project is conducted by an authorized person.
The costs need to be reported. Data such as timesheets and action messages are used to control the project.
The Request Management System allows us to handle this functionality across the organization in a transparent manner where appropriate information is available to the right people. This functionality is implemented in a very simple fashion.
The system can operate on any platform (AS/400, Unix, NT). The system has a Server-based or Client-Server option.
Backend database can reside in Oracle, Progress, DB2/400, SQL server or Access.
|
| |
| Requests |
|
Many service calls, customer complaints, or plain
purchasing functions have one common structure.
They all follow a specific life cycle:
- creation of the request
- review and analysis of the request
- resolution of the request
- final approval of the request
- closeout of the request
A request (or a complaint, a requisition, or a claim) is
initiated by a user. It typically gets analyzed. It may
get rejected or accepted to be worked on.
Estimates and detail documents may be generated
to proceed to the next level. The reviewer may add
his/her own notes and attachments as well.
The resolution of the issue involves assigning the
detailed tasks to various resources. Time, manpower
as well as other tangible resources expended are
tagged to the request during the course of the
resolution process.
The department responsible for resolving the task,
normally creates a project to handle it. It is possible
that one project may handle several such requests.
Time and resources expended are kept track of.
Once the project is completed, the work has to be
tested and approved. This process is typically the QA
step. The testing and acceptance can result in
rejection or rework.
|
|
The final closeout of the project is conducted by an authorized person.
The costs need to be reported. Data such as timesheets and action messages are used to control the project.
The Request Management System allows us to handle this functionality across the organization in a transparent manner where appropriate information is available to the right people. This functionality is implemented in a very simple fashion.
|
|
| |
| Projects |
|
Planning is an interesting process. This word sprinkled in the right quantity in any report, can make the report look authentic. Most managers love to talk about it, and some even do it. Creative usage of planning coupled with Management by Crisis can make life very exciting.
It is desirable to plan using some scheme. Unplanned projects have a tendency to drag on for ever. Unplanned projects have one advantage over the planned projects - they never fail. Since we do not know where we are going, we do not run the risk of not reaching at our goal. There are several different ways to plan a project - defensive planning, offensive planning, obtrusive planning, transparent planning and so on..
|
 |
| Then of course you could get the big consultants to plan. Most of the time they do not have a clue what they are planning. After spending considerable amount of time doing the so called analysis (ie learning on your cost), they normally give you a plan of a plan - which can only be implemented by them. Most companies agree to it because it is some plan - isn't it. |
| | |
| Messaging |
|
Communicate, communicate
Communication is critical to success of a project. Request module focusses on communication. It provides several means to achieve it. Communication schemes implemented in Request Module are:
- Leave an action message for a person or a group to respond. This message has to responded to by that person.
- Attach a person to a request - when something changes in the request, that person will be notified
- Leave a bullettin, which can be seen by all users
- Leave message for a specific user
All such actions (except bulletins and messages) become part of the request log, and this small feature brings a the sense of ownership to the project.
|
| Time Reporting |
|
| |
|
