WO2002088867A2

WO2002088867A2 - A network-based tender system

Info

Publication number: WO2002088867A2
Application number: PCT/SG2001/000071
Authority: WO
Inventors: Kow Hin Fan; Shuang Yuan Koo; Wee Hong Goh
Original assignee: Unig Pte Ltd.
Priority date: 2001-04-26
Filing date: 2001-04-26
Publication date: 2002-11-07
Also published as: AU2001252854A1; WO2002088867A3

Abstract

A computer system for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party is disclosed. The system comprises means for interfacing a buyer, at least one tenderer and at least one third party, and means for preparing a tender document by the client. The system also comprises means for transmitting the tender document via the interfacing means, and means for receiving and viewing the tender document by the at least one tenderer. The system further comprises means for submitting a tender by the at least one tenderer to the buyer in response to the tender document.

Description

A NET OKK-BASED TENDER SYSTEM

Field of the Invention

The present invention relates generally to tenders, but more particularly to a network- based computer system for preparation and posting offender documents and submission offenders.

Background

A tender provides a way of purchasing goods and services for a project through bidding or competition. During a tender, a buyer of goods and services posts a tender document to identify and specify the goods and services for inviting tenders. Prospective sellers who are referred to as tenderers then compete or bid to sell goods and services to the buyer by submitting tenders. The tenderer with the most appropriate tender submission then wins the tender by specifying an appropriate tender sum while promising to meet goods and services requirements prescribed in the tender document.

Tenders are most suitably used in cases where market prices of goods and services are difficult to ascertain due to the complexity, uniqueness or lack of transactions in relation to these goods and services. The important principle underlying all tenders is the buyer is allowed to buy goods and services at the best possible price through the process of bidding or competition.

Hence, a tender is the most ideal way of determining the market price of a project in certain industries, for example a project in the Architectural, Engineering and Construction (AEC) industry, which by nature is mostly large, complicated and unique. Other than price, key variables in a tender for an AEC project typically include schedule and specifications.

A conventional tender process in the AEC industry for a building or construction related project typically involves several stages. To acquire the goods and services of contractors, a project owner in the AEC industry conducts a tender exercise. In order to invite prospective contractors to participate in the tender exercise, the project owner posts a notice of invitation for the tender in major local newspapers and/or invites selected contractors via letters.

The prospective contractors, upon receiving the invitation letters or being notified via tender notices posted on newspapers, carry out a study on the project involvement and decide whether or not to participate in the tender exercise. Interested contractors then collect from a collection point specified in the invitation letter or notice a tender document, which includes a bill of quantity containing at least one set offender summary, specification, and drawings prepared with the help of consultants to the project owner.

A pre-tender review is usually carried out by the project owner to determine the completeness of the tender document and to check for discrepancies between the specification document and the drawings disseminated. Any discrepancies found during the pre-tender review are forwarded to consultants of the project owner for clarification.

Besides conducting in-house pricing activities to derive the tender sum, a contractor may prepare and forward a document known as a Request For Quotation (RFQ) to several subcontractors or suppliers for inviting quotations. RFQs usually contain component items listed in the tender document. This first tier of subcontractors/suppliers may in turn prepare and forward RFQs to other subcontractors/suppliers forming a second tier, and so forth.

Any further correspondences or clarifications received by the contractor are forwarded to the relevant sub-contractors/suppliers, so as to enable such third parties to make amendment to the respective quotations.

Upon receiving the tenders submitted by the prospective contractors, members of a tender committee, appointed and set up by the project owner, opens up all tender submissions. A tender evaluation exercise is carried out to ascertain that the tender submissions made by the prospective contractors are in order. If required, the project owners may arrange with short listed contractors for interviews. These interviews seek to facilitate clarifications on and confirmation of the contractors' offers, as well as to announce any changes made after the close of the tender. If there are any changes, the contractors carry out post tender reviews to establish the cost and implications on the tender sums submitted due to these changes, and re-submit new tender sums.

Upon awarding the tender, the project owner arranges a contract review to hand over a document containing the project details and drawings to the contractor that has won the tender.

The awarded contractor also forwards new RFQs to the corresponding subcontractors/suppliers as the time from the close of the tender to the award of the tender may be so long that the previously submitted quotations become invalid.

Conventional tender practices in the AEC industry suffer from a number of problems, including being time consuming, involving too much paperwork, and being prone to communication breakdown and human errors during calculations.

These problems are exacerbated by the complexity of an AEC project and the number of parties involved. The long lead-time required for the preparation offender documents also increases the risk exposure for project owners.

There is therefore clearly a need for a system for facilitating tenders that addresses the foregoing problems relating to conventional tender practices.

Summary

A computer system for facilitating an online tender via a network, particularly via the Internet, including the ability to communicate large amounts of information, complicated drawings, and to generate RFQs for goods and services, is disclosed. In accordance with a first aspect of the invention, a computer system for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party is disclosed. The system comprises means for interfacing a buyer and at least one tenderer, and means for preparing a tender document by the client. The system also comprises means for transmitting the tender document via the interfacing means, and means for receiving and viewing the tender document by the at least one tenderer. The system further comprises means for submitting a tender by the at least one tenderer to the buyer in response to the tender document.

In accordance with a second aspect of the invention, a method for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party using a computer system is disclosed. The method comprises the steps of interfacing a buyer and at least one tenderer, preparing a tender document by the client. The method also comprises the steps of transmitting the tender document via the interfacing step, and receiving and viewing the tender document by the at least one tenderer. The method further comprises the step of submitting a tender by the at least one tenderer to the buyer in response to the tender document.

In accordance with a third aspect of the invention, a data processing and storing system for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party using a computer system is disclosed. The system comprises computer processor means for processing data, and storage means for storing data on a storage medium. The system also comprises means for processing and storing data for interfacing a buyer and at least one tenderer, and means for processing and storing data for preparing a tender document by the client. The system further comprises means for processing and storing data for transmitting the tender document via the interfacing means, and means for processing storing data for receiving and viewing the tender document by the at least one tenderer. The system still further comprises means for processing and storing data for submitting a tender by the at least one tenderer to the buyer in response to the tender document.

Brief Description Of Drawings Embodiments of the invention are described hereinafter with reference to the following drawings, in which:

Figure 1 is a flow diagram illustrating a scenario in which a tender process is carried out in relation to a project using a system according to a preferred embodiment of the invention;

Figure 2 is a block diagram showing the components of the system of Figure 1;

Figures 3 and 4 are a block diagrams illustrating transactions involving Web-based documents facilitated by the system of Figure 1;

Figure 5 is a flow diagram providing an overview of a tender process flow facilitated by the system of Figure 1;

Figure 6 is a flow diagram illustrating a tender creation process in the tender process of Figure 5;

Figures 7a and 7b are flow diagrams illustrating a process for a bill of quantity module in the tender process of Figure 5;

Figure 8 is a flow diagram illustrating a process for a post tender module in the tender process of Figure 5;

Figure 9 is a flow diagram illustrating a tender addendum process in the tender process of Figure 5;

Figures 10 to 15 are flow diagrams illustrating a tender pricing process in the tender process of Figure 5;

Figure 16 is a flow diagram illustrating an RFQ respond process in the tender process of Figure 5; Figure 17 is a flow diagram illustrating a tender opening process in the tender process of Figure 5;

Figure 18 is a flow diagram illustrating a tender evaluation process in the tender process of Figure 5;

Figure 19 is a flow diagram illustrating a process for a view comparison module in the tender process of Figure 5;

Figure 20 is a flow diagram illustrating a process for an evaluation module in the tender process of Figure 5;

Figure 21 is a flow diagram illustrating a tender resubmission process in the tender process of Figure 5;

Figure 22 is a flow diagram illustrating a final evaluation process in the tender process of Figure 5; and

Figure 23 is a flow diagram illustrating a tender award process in the tender process of Figure 5.

Detailed Description

An online network-based computer system is disclosed hereinafter for addressing the foregoing problems associated with conventional tender practices, particularly in the AEC industry. The problems associated with conventional tender practices in the AEC industry is addressed by the system according to embodiments of the invention, in which all communications may be done through the system, hence rendering tender processes paperless and fast, thereby mitigating communication breakdown. Additionally, the implementation of automatic calculations in the system eliminates human errors. Also, a history offender processed is kept for record and thereby help to prevent disputes. Furthermore, the system is accessible from anywhere as long there is an Internet access, thereby broadening the reach of the system to numerous projects owners, consultants, contractors, subcontractors, suppliers, etc.

With reference to a flow diagram in Figure 1, a scenario in which a tender process is carried out in relation to a project, specifically in the AEC industry as an example, using an online network-based computer system 100 according to a preferred embodiment of the invention, is described. The tender process facilitated by the online network-based computer system 100, hereinafter referred to generally as a system 100, involves a project owner, hereinafter referred to generally as a client 102 of the system 100 solution provider, contractors 104, and subcontractors/suppliers 106/108. The client 102 makes information regarding the concerned AEC project available to the contractors 104, including the nature and scope of work, the type of contract, the terms and conditions of the tender, the tender closing date/time, and any other relevant information. Such information is found in a tender document, which includes a bill of quantity that contains a listing of items requiring quotations, a tender summary, a set of specification and drawings, and any other relevant attachments. The client 102 appoints members of the client 102 organisation to assume specific roles, which include the tender creator, approver, opening committee, evaluator and awarder. Through the system 100, the client 102 disseminates the tender document to the contractors 104.

The contractors 104 respond with tender submissions within the time period (ie. closing date/time) stipulated by the client 102. The contractors 102 have to provide all the necessary information and tender sum as specified and requested in the tender document. The date/time of the tender submission is recorded by the system 100.

A tender may be either public or private in nature. Public tenders are opened to all tenderers while private tenders are only reserved for invited tenderers. Tender documents and tender submissions may be amended, withdrawn and/or reinstated before the closing date/time.

Each tender may be subjected to a few rounds of evaluation before a tenderer is awarded the tender by the client 102. The system 100 enables the client 102 and the contractors 104 to communicate and negotiate during such evaluation rounds. Results of the each evaluation round and the final award is posted in the system 100. The system 100 also maintains historical reports of such results.

The project may consists of numerous composite items. The contractors 104 may further break these composite items down into smaller component items. The system 100 allows the contractors 104 to select these component items and raise Request For Quotations (RFQs) to all or selected first tier of subcontractors/suppliers 106.

This first tier of subcontractors/suppliers 106 then responds to all RFQs by furnishing the required prices within the time periods set by the contractors 104. In turn, these subcontractors/suppliers 106 may raise RFQs to a second tier of subcontractors/suppliers 108, and so forth.

With reference to a block diagram in Figure 2, the system 100 components are described in greater detail. Through the Internet 202, the system 100 communicates with the client 102, the contractors 104, the first tier subcontractors/suppliers 106, and the second tier subcontractors/suppliers 108. To do so, the system 100 includes and relies on a gateway router 204, which is identifiable by an Internet Protocol (IP) address for enabling the system 100 to communicate with the client 102, the contractors 104, and the subcontractors/suppliers 106/108 via the Internet 202.

Behind the gateway router 204 is a firewall 206, which operates to prevent unauthorized access or entries into the system 100 by using known techniques. The firewall 206 helps to ensure that data theft and hacking do not occur.

Protected by the firewall 206 are the other components of the system 100, which include a switch 208, a business application and Web server 210, a database management server 212, and a data backup server 214. The switch 208 performs data switching operations to ensure that data is communicated and shared among the various servers 210, 212 and 214 for performing various processes and steps necessary for enabling the functionality and operations of the system 100. The business application and Web server 210 performs the dual roles of serving out and receiving Web documents for interfacing the system 100 with the clients 102, the contractors 104, and the subcontractors/suppliers 106/108, and processing data contained in the Web documents according to the business logic of the system 100.

The database management server 212 provides and manages storage of information extracted from or attached to Web documents that are received from the various parties 102, 104, 106 and 108. The data backup server 214 performs backup operations for maintaining the integrity of information stored on the database management server 212 and therefore the reliability of the system 100.

With reference to block diagrams in Figures 3 and 4, transactions involving Web-based documents facilitated by the system 100 in relation to the tender process is described in greater detail. The client 102, through the system 100, first prepares and makes available a tender document 302 to the contractors 104 via the system 100. The tender document 302 is stored on the database management server 212 by the client 102 and retrieved by the contractors 104 via the Internet 202. The tender document 302 includes a summary of the tender and a bill of quantity, which are entered into the system 100 with the help of Web documents known as Web forms containing entry fields into which information is entered to form the summary and bill of quantity. Such information is thus collected and embedded in the Web forms provided by the system 100, while the other portions of the tender document 302, namely the specification and drawings, are pre-prepared and attached to the Web forms before tender document 302 is sent to the database management server 212 for storage and subsequent access by the contractors 104.

When the tender document 302 is received by the contractors 104, the contractors 104 evaluate the concerned project by reviewing the specification and drawings attachment. The contractors 104 also enters information into the bill of quantity, including pricing information. Where the contractors 104 are capable of quoting the prices, such information is filled directly into the Web forms for the bill of quantity for preparing tender submissions. However, if the contractors 104 are unable to provide the pricing information for any items, the contractors 104 may identify these items to the system 100 for preparing Web forms representing RFQs 304 and forwarding to the subcontractors/suppliers 106/108. Depending on the need for information, the contractors 104 may forward through the system 100 the same RFQs 304 to different subcontractors/suppliers 106/108, or different RFQs to different subcontractors/suppliers 106/108.

The respective subcontractors/suppliers 106/108 then fill pricing information into the relevant entry fields in the Web-based RFQs 304 and by doing so form RFQ responses 402. These responses 402 are then returned through the system 100 to the respective contractors 104 seeking the pricing information, who through the system 100 then consolidate the pricing information from the various responses 402 into tenders 404. These tenders 404 are then submitted to the client 102 through the system 100 for evaluation before the close of the tender.

The business logic of the system 100 is described in greater detail with reference to flow diagrams in Figures 5 to 23. Although these flow diagrams depict the application of the system 100 to specifically tender processing in the AEC industry, such an application may be modified to suit the practices of any other industries in which the tender process prevails as an important way of procuring goods and services through bidding or competition.

In Figure 5, an overview of the tender process flow facilitated by the system 100 is described. Processes and steps that occur within processes are described hereinafter for providing an understanding of the business logic implemented in the system 100 for the AEC industry in relation to the tender process.

The tender process has a number of stages, and begins with the creation of a tender document in a process 1.0. The creation process 1.0 categorically falls into a drafting stage in the tender process flow, in which the client 102 is the party controlling this process. The creation process 1.0 next flows to a process 3.0 in which the pricing of the tender takes place. Before the tender pricing process 3.0 occurs, the client 102 may also perform a process 2.0 in which tender addendums are prepared and added to the tender document 302 created in process 1.0. In response to the tender pricing process 3.0, a process 4.0 in which the subcontractors/suppliers respond to RFQs generated by the contractors 104 during the tender pricing process 3.0 occurs. All three processes occur during a tendering stage in the tender process flow, in which the tender addendum process 2.0 is controlled by the client 102, the tender pricing process 3.0 is controlled by the contractors 104, and the RFQ respond process 4.0 is controlled by the subcontractors/suppliers 106/108.

The tendering stage is followed by a closing stage in the tender process flow, which includes in the flow a process 5.0 in which there is an opening offenders submitted by the contractors 104. This process is followed subsequently by a process 6.0 in which there is evaluation offenders. During the occurrence of the tender evaluation process 6.0, a process 7.0 may occur during which there is resubmission offenders. After evaluation, the tenders are evaluated once more in a final evaluation process 8.0. All the processes are controlled by the client 102 in this stage.

Thereafter, the process enters an awarding stage in the tender process flow, in which a process 9.0 where the client 102 awards the tender occurs. After this process, which is controlled by the client 102, the tender process flow ends.

The more important processes that occur during the tender process flow and any processes triggered by steps in these processes are described hereinafter with reference to Figures 6 to 23. The processes and steps that are performed and described hereinafter may involve interactions and/or interfacing among the various parties and the system 100, which typically involve communication using Web forms provided by the system 100 and documents provided by the client 102 and/or any other party.

With reference to a flow diagram in Figure 6, the tender creation process 1.0 is described in greater detail. The process begins when the client 102 performs a login into the system 100 in a step 1.1, followed by a step 1.2 in which the client 102 creates a new tender document using the Web forms provided by the system 100. The client 102 starts creating the new tender document by providing basic information to the system 100 in a step 1.3, which includes information such as company details, followed by a step 1.4 in which the client 102 appoints a creator, an approver, an opening committee, and an evaluator from the client 102 organisation and enters information regarding the same into the system 100.

The client 102 next in a step 1.5 selects the contractors 104 from a list of members to whom a notification of tender or tender invitation letters are to be presented. These selected contractors 104 are also to receive electronically a copy of the tender document 302.

The system 100 next in a step 1.6 allows the client 102 to choose to prepare the bill of quantity or terminate this process. If the client 102 chooses to prepare the bill of quantity, the client 102 proceeds in a step 1 PI to choose the type of bill of quantity to prepare. If the client 102 does not choose to prepare the bill of quantity, the client 102 leaves this process and proceeds to the tender pricing process 3.0.

In choosing to prepare the bill of quantity, the client 102 also has an option of preparing bills of quantity for a base tender or any tender options. This option is only available if the project involves a base component and optional component(s). An example is a building project which involves building a house and an optional swimming pool.

If the client 102 wishes to create the bill of quantity for the base tender, the client 102 in a step 1.8 enters the necessary information into the system 100 followed by preparing the bill of quantity in a step 1.10. By preparing the bill of quantity, the client 102 completes the preparation of the tender document 302 and posts the same in a step 1.11 through the system 100 for the selected contractors 104 to retrieve.

If the client wishes to create the bill of quantity for the tender option, the client 102 in a step enters the necessary information into the system 100 followed by preparing the bill of quantity in a step 1.10. By preparing the bill of quantity, the client 102 completes the preparation of the tender document 302 and posts the same in a step 1.11 through the system 100 for the selected contractors 104 to retrieve.

In order to allow the client 102 to create a bill of quantity, the system 100 triggers in the step 1.10 a bill of quantity module within the system 100 which carries out a further process according to flow diagrams shown in Figures 7a and 7b.

A bill of quantity may have several tender summaries, while each tender summary may contain several sections of items, which are categorical groupings of items, and each section of items may include several items. An item is the smallest unit of goods or services for which a price is sought from the contractors 104 or the subcontractors/suppliers 106/108. The tender sum in a tender submission is the total aggregate of the prices of all items indicated in a tender document, in particular in the bill of quantity.

In the bill of quantity module, the process flow begins with a step 1.10.1 in which the client 102 is given an option to create a tender summary or proceed to attach the specification and drawings. If the client 102 chooses to create a tender summary, the process flow proceeds to a step 1.10.2 in which the client may choose the format in which to create the tender summary, followed by the creation of the tender summary in a step 1.10.3.

In a next step 1.10.4, the client 102 is given an option to create a section of items, in which if the client 102 chooses not to do so is looped back to the step 1.10.1. If, however, the client 102 chooses to create a section of items, the client 102 does so in a step 1.10.5 and proceeds to a next step 1.10.6 in which the client is given an option to create items. If the client 102 choose not to create any item, the client 102 is looped back to the step 1.10.4, while if the client 102 choose to create items does so in a step 1.10.7.

If the client 102 chooses not to create a tender summary, the process flow in the bill of quantity module proceeds to a step 1.10.8 in which the client 102 is given an option to upload specifications to the system 100. If the client 102 wishes to do so, the client 102 in a step 1.10.9 chooses from the system 100 a category into which the specification falls or creates in a step 1.10.10 such a category. The client 102 then confirms in a step 1.10.11 to attach the specification in the choosen or created category, and if the category is appropriate the client 102 uploads the specification to the system 100 in a step 1.10.12. Otherwise, the client 102 is looped back to the step 1.10.8.

If the client 102 in the step 1.10.8 does not wish to load the specification, the client 102 is given a further option to upload the drawings in a step 1.10.13. If the client 102 does not wish to upload any drawings to the system 100, the process flow in the bill of quantity module terminates. Otherwise, the client 102 proceeds to choose a category into which the drawings fall in a step 1.10.14 or creates in a step 1.10.15 such a category. The client 102 then confirms in a step 1.10.16 to attach the drawings in the choosen or created category, and if the category is appropriate the client 102 uploads the drawings to the system 100 in a step 1.10.17. Otherwise, the client 102 is looped back to the step 1.10.13.

After the client 102 confirms and attaches the drawings in the step 1.10.17, process flow loops back to the step 1.10.16.

In order to allow the client 102 to post the tender document 302, the system 100 triggers in the step 1.11 a post tender module within the system 100 which carries out a further process according to a flow diagram shown in Figure 8.

The process flow in the post tender module begins with a step 1.11.2 in which the client 102 opens a listing offenders in the system 100, which the client 102 may have created in earlier sessions with the system 100 for other tender processes. The client 102 next in a step 1.11.2 select the appropriate tender document 302 to post on the system 100, and confirms to do so in a step 1.11.3. If the client 102 chooses not to post the tender document 302 on the system 100, the process flow in the post tender module proceeds to the tender pricing process 3.0. If the client 102 chooses to post the tender document 302 on the system 100, the client 102 continues in a step 1.11.4 to add the tender document 302 to tender offer lists viewable through the system 100 by the selected contractors 104 as a way of posting a private tender notification, while at the same time initating an automatic notification process performed by the system 100 to send tender invitation letters to the selected contractors 104 by electronic mail. By doing so, the system 100 effectively facilitates the invitation offenders from the selected contractors 104.

The system 100 then records information relating to the posted tender document in a step 1.11.5, including the capture of names of the approver, the creator, and date and time of the close of the tender.

With this information, the system 100 tracks the closing date of the tender, and if at any time the system 100 receives a request from the client 102 to create a tender addendum, the system 100 checks in a step 1.11.6 whether the the closing date is due. If the request occurs before the closing date, the system 100 accepts such a request and the process flow in the post tender module proceeds to the tender addendum process 2.0. If the request occurs after the closing date of the tender, the system 100 exits the post tender module and proceeds to the tender pricing process 3.0.

In the tender addendum process 2.0 shown using a flow diagram in Figure 9, the creator appointed by the client 102 first makes changes to the draft tender document in a step 2.1. The creator assigns a colour code to the changes and create an audit trail using the system 100 features in a step 2.2. This allows all changes made to any tender document 302 created using the system 100 to be track for recording a history of changes and allowing audits to be performed.

The system 100 then checks in a step 2.3 whether all changes have been completed, and if the creator is still making changes, the tender addendum process loops back to the step 2.1. If the changes are complete, the tender addendum process proceeds to a next step 2.4 in which the tender document 302 created earlier is replaced with the amended tender document 302. The name of the approver and creator of the amended tender document 302 is recorded in a step 2.5, as well as the date and time for the closing of the tender, so that any change to the closing date may be tracked. With reference to Figure 10, the tender pricing process 3.0 is described in greater detail. A number of steps performed in the tender pricing process 3.0 trigger a corresponding number of modules in the system 100 for performing further processes. These modules are described in greater detail in Figures 11 to 15.

In the tender pricing process 3.0, the workflow begins with a contractor 104 performing a login into the system 100 in a step 3.1. The contractor 104 then in a step 3.2 opens the tender offer list to which the contractor 104 as a selected contractor 104 has access. From the tender offer list the contractor 104 selects the appropriate tender document 302 to view in a step 3.3, and examines the tender document 302 in light of the basic information, bill of quantity, specification, drawings, and any tender addendums provided. The contractor 104 may choose in a step 3.5 to work on the tender submission via a number of modules in any order which are triggered by steps subsequently taken, including a step 3.6 for triggering a tender pricing module, a step 3.7 for triggering an RFQ module, and a step 3.8 for triggering a built-up rate module. After completing these modules, the tender pricing process 3.0 then proceeds to a tender submission module triggered by a step 3.9, or an online reporting module triggered by a step 3.10, again in any order the contractor 104 chooses to work. Thereafter, the tender pricing process 3.0 terminates.

The tender pricing module process flow as shown in a flow diagram in Figure 11 begins with a step 3.6.1 in which the contractor 104 selects the appropriate tender summary to work on, followed by the selection of a section of items in a step 3.6.2, then followed finally by the selection of an item in a step 3.6.3. The system 100 next in a step 3.6.4 checks if the pricing information relating to the selected item is made available during the respond to RFQ process 4.0. If the information is available, the process flow continues with a step 3.6.5 in which the contractor 104 selects the item from a list of items a RFQ respond list. The contractor 104 then in a step 3.6.6 transfers this information to the built-up rate module, which is triggered in a next step 3 8, for the calculation of the built-up rate of the item. The contractor 104 then marks up the built- up rate in a step 3.6.9 and saves this pricing information in a step 3.6.10. When the information is not made available during the respond to RFQ process 4.0, the contractor 104 is required to enter the pricing information which is the item markup rate for the item. If the contractor 104 already has this information, the process flow continues with the step 3.6.10 in which the information is entered into the system 100 and saved. Thereafter, the bill of quantity is updated with this information and the tender sum calculated in a step 3.6.11, followed by a step 3.6.12 in which the system 100 checks for further items for the contractor 104 to work on.

If the contractor 104 does not have the markup rate information for the item, the contractor 104 through the system 100 in a step 3.6.8 adds the item to a RFQ cart list, which is a list of items that is to be presented in an RFQ to be forwarded to the relevant subcontractors/suppliers for requesting price quotations. The process flow then continues with the step 3.6.12, in which if there are more items for the contractor 104 to process, each item is processed by a loop which begins with the step 3.6.3 in which a next item is selected. If there are no more items in the selected section, the process flow in the tender pricing module proceeds to a step 3.6.13 in which the process flow loops to the step 3.6.2 to check if there are further sections of items for the contractor 104 to process. If there are no more sections in the selected summary, the process flow in the tender pricing module proceeds to a step 3.16.14 in which process flow loops to the step 3.6.1 to check if there are further tender summaries for the contractor 104 to process. If there are no more tender summaries for the contractor 104 to process, the tender pricing module proceeds to either the tender submission module or the onling report module.

The RFQ module process flow as shown in a flow diagram in Figure 12 begins with a step 3.7.1 in which the contractor 104 opens the RFQ cart list and selects an item to be included in the RFQ in a next step 3.7.2. The system 100 then creates the RFQ in a step 3.7.3 in which information relating to the item selected from the RFQ cart list is automatically downloaded to an RFQ form by the system 100. The contractor 104 in a step 3.7.4 selects one or more subcontractors/suppliers 106/108 from whom the pricing information is requested, and in a next step 3.7.5 sets the conditions via the system 100 for closing the RFQ process. The conditions set include the closing date and time for the RFQ, and the minimum number of replies to be received before closing. The system 100 then posts the RFQs through the system 100 on the corresponding subcontractor/supplier's RFQ request list which is viewable only by the selected subcontractors/suppliers 106/108. The name of the creator and approver of the RFQ and the closing date and time of the RFQ process are recorded in a step 3.7.7. The process flow continues in a step 3.7.8 in which the contractor 104 continues to process other items in the RFQ cart list if there are any, or terminates if there are none.

The built-up rate module flow process as shown in a flow diagram in Figure 13 begins with a step 3.8.1 in which the tender summary on which the contractor 104 wishes to process is selected, followed by a step 3.8.2 in which a section of items is selected, and further by a step 3.8.3 in which an item is selected. The values of the built-up rate for each item is entered into the system 100 in a step 3.8.4, which includes costs relating to labor, overheads, wastage, and profit. The process flow next continues with a step 3.8.5 in which the markup rate is calculated using the unit rate and built-up rate, and with this information the bill of quantity is updated in a step 3.8.6. Thereafter, the system 100 checks whether the contractor 104 wishes to process anymore items in a step 3.8.7, anymore sections in a step 3.8.8, and anymore tender summaries in a step 3.8.9. The process flow loops back to the step 3.8.3 if the contractor 104 wishes to process other items, to the step 3.8.2 to process other sections, and to the step 3.8.1 to process other tender summaries.

The tender submission module flow process as shown in a flow diagram in Figure 14 begins with a step 3.9.1 in which the contractor 104 fills information into a basic tender submission form provided in the tender document 302 by the system 100 and attaches any other information to the basic tender submission form in a step 3.9.2. The system 100 checks if there are further attachments, and loops back to the step 3.9.2 if there are more attachments. If there are no more attachments, the tender submission module process flow continues in a step 3.9.4 in which the contractor 104 uploads the basic tender submission form and any attachments to the system 100 and completes a mandatory contractual form of tender specifying the tender sum. The contractor 104 is then given an option to create a password for the opening committee with which the opening committee opens the tender submission in a step 3.9.5. If the contractor 104 wishes to create a password, the contractor 104 does so in a step 3.9.6 and sends such a password to the opening committee. Otherwise, the process flow continues with a next step 3.9.7 in which the contractor is given an option to add an alternative tender submission. The alternative tender submission allows the contractor 104 to counter propose a list of items with which the contractor 104 uses when undertaking the project. If the contractor 104 does not wish to submit an alternative tender, a next step 3.9.9 follows in which the contractor 104 posts the tender submission to the client 102 via the system 100. If the contractor 104 wishes to submit an alternative tender, the contractor 104 does so in a step 3.9.8, which is followed by the posting of the alternative tender submission in the step 3.9.9. At the completion of any tender submission, the system 100 records the names of the creator and approver of the tender submission, and the data and time at which the tender submission is made.

The online reporting module flow process as shown in a flow diagram in Figure 15 begines with a step 3.10.1 in which the tender document including the bill of quantity, tender addendum, and tender sum is shown to the contractor 104.

In the RFQ respond process 4.0 as shown by a flow diagram in Figure 16, the workflow begins with a subcontractor/supplier 106/108 performing a login into the system 100 in a step 4.1. The subcontractor/supplier 106/108 in a next step 4.2 opens the RFQ request list, in which only the subcontractors/suppliers 106/108 selected by the contractor 104 receive have the RFQ prepared by the contractor 104 listed in the RFQ request list. The subcontractor/supplier 106/108 then selects an item in a step 4.3 and provides the price information for that item in a step 4.4, on which the system 100 processes for adding to an RFQ response list in a step 4.5. The system 100 in a next step 4.6 checks the conditions set by the contractor 104, and if the conditions are met, the system 100 adds the price information for that item to the RFQ response list in a step 4.8. Thereafter, the names of the creator and approver for the RFQ response list and the date and time at which the same is created is recorded by the system 100. But if the conditions are not met, the system 100 generates an apology message and shows the same to the subcontractor/supplier in a step 4.7. The process flow then continues with a step 4.10, in which the subcontractor/supplier 106/108 may process more items whereby the process flow loops back to the step 4.2, or none whereby the process flow terminates.

In the tender opening process 5.0 as shown in a flow diagram in Figure 1 , the workflow begins with the opening committee performing a login into the system 100 in a step 5.1. In a next step 5.2, the opening committee is shown a tender submission list by the system 100, from which the opening committee selects in a step 5.3 a tender submission which the opening committee wishes to open. The system 100 then in a step 5.4 checks whether the closing date for the tender is due. If the closing date is not due, the system 100 generates an apology message in a step 5.5 to inform the opening committee that the tender submission cannot be opened. If the closing date is due, however, the system 100 in a step 5.6 checks if the contractor 104 who prepared the tender submission encrypted the tender submission with a password. If a password is needed, the opening committee enters the password into the system 100 in a step 5.7. Otherwise, the opening committee opens the tender submission in a step 5.8, and thereafter the details of the opening committee is recorded in a step 5.9.

In the tender evaluation process 6.0 as shown in a flow diagram in Figure 18, an evaluator first performs a login into the system 100 in a step 6.1. The evaluator is then shown a tender submission list in a step 6.2, from which the evaluator selects in a step 6.3 a tender submission which the evaluator wishes to evaluate. The system 100 checks if the selected tender submission is already opened by the opening committee in a step 6.4, and if this is not the case the system generates an apology message in a step 6.5 to inform the evaluator that the tender submission is yet to be opened by the opening committee.

If the tender submission is already opened by the opening committee, the tender evaluation process 6.0 proceeds to a next step 6.6 in which the evaluator is given an option to proceed to a step 6.7 for triggering a view comparison module or a step 6.8 for triggering an evaluation module, and the process terminates thereafter. In the view comparison module as shown by a flow diagram in Figure 19, the evaluator first chooses from different sorting methods to compare the various tender submissions that are opened by the opening committee in a step 6.7.1. The system 100 checks if the evaluator needs any clarification from the contractors 104 in a step 6.7.2. If the evaluator does not require any clarification from the contractors 104, the workflow of the view comparison module terminates thereafter. However, if the evaluator requires clarification from the contractors 104, the evaluator with the help of the system 100 creates a clarification form in a step 6.7.3, and the system 100 in a next step adds the completed clarification form to clarification form lists of only the concerned contractors 104 in a step 6.7.4, and the contractors 104 are notified accordingly. The name of the creator and approver of the clarification form and the date and time at which the same is created is recorded by the system 100. Thereafter the workflow for the view comparison module terminates, and the tender evaluation process 6.0 proceeds to the step 6.8 in which the evaluation module is triggered.

In the evaluation module as shown by a flow diagram in Figure 20, the evaluator first adds comments pertaining to the tender submission to a comment list in a step 6.8.1, and shortlists the contractors 104 to form a recommendation list in a step 6.8.2. The system 100 next records the name of the evaluator and the date and time at which the shortlisting occurs in a next step 6.8.3.

In the tender resubmission process 7.0 as shown by a flow diagram in Figure 21, the contractor 104 begins by receiving from the system 100 a notification of a clarification form in a step 7.1, which therefore enables the contractor 104 to resubmit the tender with the clarification raised by the evaluator addressed in a step 7.2. The pricing of the tender is thereafter repeated via the tender pricing process 3.0 before the tender resubmission.

In the final evaluation process 8.0 as shown in a flow diagram in Figure 22, a chief evaluator appointed by the client 102 first performs a login into the system 100 in a step 8.1. The chief evaluator is then shown a tender submission list in a step 8.2, from which the chief evaluator selects in a step 8.3 a tender submission which the chief evaluator wishes to evaluate. The system 100 checks if the selected tender submission is already opened by the opening committee in a step 8.4, and if this is not the case the system generates an apology message in a step 8.5 to inform the chief evaluator that the tender submission is yet to be opened by the opening committee. The chief evaluator adds comments pertaining to the tender submission to the comment list in a step 8.6, and therefore in a step 8.7 is given an option to recommend another round of evaluation. If the chief evaluator does not recommend another round of evaluation, the chief evaluator shortlists the contractors 104 to form a recommendation list in a step 8.8. The system 100 next records the name of the chief evaluator and the date and time at which the shortlisting occurs in a next step 8.9. Thereafter, the chief evaluator notifies the client 102 to award the tender in a step 8.10.

If the chief evaluator recommends another round of evaluation, the system 100 records the name of the chief evaluator and the date and time at which the recommendation is made in a step 8.11, and the final evaluation process 8.0 loops back to the tender evaluation process 6.0.

In the tender award process 9.0 as shown in a flow diagram in Figure 23, an awarder appointed by the client 104 first performs a login into the system 100 in a step 9.1, and in a step 9.2 awards the tender. The awarder is given an option to post the result of the tender award on the system 100, and if the awarder chooses to do so the system 100 records the name of the awarder and date and time at which the tender award is made in a step 9.4. In a next step 9.5, the result of the tender award is posted on the system 100 for notifying all the relevant parties involved. If the awarder does not choose to post the result yet, the tender award process 9.0 loops back to the step 9.2.

In the foregoing manner, a network-based computer system for facilitating tender processes is described according to an embodiment of the invention for addressing the foregoing disadvantages of conventional tender practices. Although only one embodiment of the invention is disclosed, it will be apparent to one skilled in the art in view of this disclosure that numerous changes and/or modification can be made without departing from the scope and spirit of the invention. In particular, the implementation of the system for application in the AEC industry may be varied for application in other industries, with minor modifications made to the system which are known to those skilled in the art.

Claims

1. A computer system for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party, the system comprising: means for interfacing a buyer and at least one tenderer; means for preparing a tender document by the client; means for transmitting the tender document via the interfacing means; means for receiving and viewing the tender document by the at least one tenderer; and means for submitting a tender by the at least one tenderer to the buyer in response to the tender document.

2. The system as in claim 1, wherein the means for interfacing includes a means for networking.

3. The system as in claim 1 or 2, further comprising means for preparing a second document by the at least one tenderer using a portion of the contents of the tender document.

4. The system as in claim 3, wherein the means for preparing the second document includes means for preparing a request for quotation by the at least one tenderer for requesting price information.

5. The system as in claim 4, wherein the means for interfacing includes means for interfacing the buyer, the at least one tenderer, and at least one third party.

6. The system as in claim 5, further comprising means for receiving and viewing of the request for quotation by the at least one third party.

7. The system as in claim 6, further comprising means for responding to the request for quotation by the at least one third party.

8. The system as in claim 7, further comprising means for consolidating a plurality of response to the request for quotation by the at least one tenderer.

9. The system as in any of the above claims, further comprising means for evaluating the tender submission by the buyer.

10. The system as in any of the above claims, further comprising means for notifying the at least one tenderer of the award of the tender.

11. The system as in any of the above claims, further comprising means for amending the tender document.

12. The system as in claim 11, wherein the means for amending the tender document includes means for tracking amendments to the tender document.

13. The system as in claim 12, wherein the means for tracking the amendments to the tender document includes means for colour-coding the amendments to the tender document.

14. A method for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party using a computer system, the method comprising the steps of: interfacing a buyer and at least one tenderer; preparing a tender document by the client; transmitting the tender document via the interfacing step; receiving and viewing the tender document by the at least one tenderer; and . submitting a tender by the at least one tenderer to the buyer in response to the tender document.

15. The method as in claim 14, wherein the step of interfacing includes a step of networking the buyer and the at least one tenderer.

16. The method as in claim 14 or 15, further comprising the step of preparing a second document by the at least one tenderer using a portion of the contents of the tender document.

17. The method as in claim 16, wherein the step of preparing the second document includes the step of preparing a request for quotation by the at least one tenderer for requesting price information.

18. The method as in claim 17, wherein the step of interfacing includes the step of interfacing the buyer, the at least one tenderer, and at least one third party.

19. The method as in claim 18, further comprising the step of receiving and viewing of the request for quotation by at least one third party.

20. The method as in claim 19, further comprising the step of responding to the request for quotation by the at least one third party.

21. The method as in claim 20, further comprising the step of consolidating a plurality of response to the request for quotation by the at least one tenderer.

22. The method as in any of claims 14 to 21, further comprising the step of evaluating the tender submission by the buyer.

23. The method as in any of claims 14 to 22, further comprising the step of notifying the at least one tenderer of the award of the tender.

24. The method as in any of claims 14 to 23, further comprising the step of amending the tender document.

25. The method as in claim 24, wherein the step of amending the tender document includes the step of tracking amendments to the tender document.

26. The method as in claim 25, wherein the step of tracking the amendments to the tender document includes the step of colour-coding the amendments to the tender document.

27. A data processing and storing system for facilitating a tender process which involves a buyer, at least one tenderer and at least one third party using a computer system, the system comprising: computer processor means for processing data; storage means for storing data on a storage medium; means for processing and storing data for interfacing a buyer and at least one tenderer; means for processing and storing data for preparing a tender document by the client; means for processing and storing data for transmitting the tender document via the interfacing means; means for processing storing data for receiving and viewing the tender document by the at least one tenderer; and means for processing and storing data for submitting a tender by the at least one tenderer to the buyer in response to the tender document.

28. The system as in claim 27, wherein the means for processing and storing data for interfacing includes means for processing and storing data for networking the buyer and the at least one tenderer.

29. The system as in claim 27 or 28, further comprising means for processing and storing data for preparing a second document by the at least one tenderer using a portion of the contents of the tender document.

30. The system as in claim 29, wherein the means for processing and storing data for the second document includes means for processing and storing data for preparing a request for quotation by the at least one tenderer for requesting price information.

31. The system as in claim 30, wherein the means for processing and storing data for interfacing includes means for processing and storing data for interfacing the buyer, the at least one tenderer, and at least one third party.

32. The system as in claim 31, further comprising means for processing and storing data for receiving and viewing of the request for quotation by at least one third party.

33. The system as in claim 32, further comprising means for processing and storing data for responding to the request for quotation by the at least one third party.

34. The system as in claim 33, further comprising means for processing and storing data for consolidating a plurality of response to the request for quotation by the at least one tenderer.

35. The system as in any of claims 27 to 34, further comprising means for processing and storing data for evaluating the tender submission by the buyer.

36. The system as in any of claims 27 to 35, further comprising means for processing and storing data for notifying the at least one tenderer of the award of the tender.

37. The system as in any of claims 27 to 36, further comprising means for processing and storing data for amending the tender document.

38. The system as in claim 37, wherein the means for processing and storing data for amending the tender document includes means for processing and storing data for tracking amendments to the tender document.

39. The system as in claim 38, wherein the means for processing and storing data for tracking the amendments to the tender document includes means for processing and storing data for colour-coding the amendments to the tender document.